Subject: Re: Last Call: <draft-ietf-tsvwg-port-use-06.txt> (Recommendations for Transport Port Number Uses) to Best Current Practice

From: Alexey Melnikov <[email-masked]>
Date: Sun, 04 Jan 2015 19:13:56 +0000

On 08/12/2014 23:56, The IESG wrote:
> The IESG has received a request from the Transport Area Working Group WG
> (tsvwg) to consider the following document:
> - 'Recommendations for Transport Port Number Uses'
>    <draft-ietf-tsvwg-port-use-06.txt> as Best Current Practice
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2014-12-22. Exceptionally, comments may be
> sent to [email-masked] instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.
>
> Abstract
>
>
>     This document provides recommendations to application and service
>     designers on how to use the transport protocol port number space. IT
>     complements (but does not update) RFC6335, which focuses on IANA
>     process.
My apologies for late review of the document. I generally think that the 
document is well written and is nearly done, but I have some 
comments/concerns.

1. Introduction

    This document provides information and advice to system designers on
    the use of transport port numbers. It provides a detailed historical
    background of the evolution of transport port numbers and their
    multiple meanings. It also provides specific recommendations to
    system designers on how to use assigned port numbers. Note that this
    document provides information to potential port number applicants
    that complements the IANA process described in BCP165 [RFC6335], but
    it does not update that document.

I am a bit confused by the status and purpose of this document. It is a 
BCP, but the introducting
says that it is purely informational. But then the document has lots of 
RFC 2119 language.
Is there any intent for this document
to be of use to port expert reviewers, for example if they want to point
out why a particular port registration request is rejected?

In 7.1:

          Additional port numbers are not intended to replicate an
          existing service. For example, if a device is configured to
          use a typical web browser then it the port number used for
          that service is a copy of the http service that is already
          assigned to port number 80 and does not warrant a new
          assignment. However, an automated system that happens to use
          HTTP framing - but cannot be accessed by a browser - might be

I have some concerns about "be access by a browser".

One particular case I have in mind is when a service expose some data 
using JSON or ASN.1 (for example a certificate revocation list is 
returned), but also allow a browser to view certificate in a nice form 
using HTML (e.g. for debugging or convenience). I don't think the 
ability to return HTML automatically disqualify this from being an 
independent service, because the whole functionality supported by the 
service can't be implemented just by use of returned HTML.

Inserting "solely" before "by a browser" would address my concern.

          a new service. A good way to tell is "can an unmodified client
          of the existing service interact with the proposed service"?
          If so, that service would be a copy of an existing service and
          would not merit a new assignment.

In 7.4:

    Note however that a new service might not be eligible for IANA
    assignment of both an insecure and a secure variant of the same
    service, and similarly IANA might be skeptical of an assignment for

I don't think use of wording like "IANA might be skeptical" is correct 
here, because IANA doesn't define policy on this. IETF does. So let's 
call things with right names and don't misuse "IANA" here.

    an insecure port number for a secure service. In both cases,
    security of the service is compromised by adding the insecure port
    number assignment.

Similarly (in the same section): "IANA currently permits ..."

---

From: Joe Touch <[email-masked]>
Date: Fri, 16 Jan 2015 10:56:28 -0800

Hi, Alexey (et al.),

Suggestions on how to address these concerns below.

> out why a particular port registration request is rejected?

AFAICT, expert reviewers can use any reason they want to recommend an
approval or rejection; the same is true for IANA. There is an appeals
process to the IESG when a decision disagreement occurs, and they can
make decisions on a case-by-case basis.

The review team does try to provide a consistent set of responses, i.e.,
to treat similar requests as similarly as possible, but again that's not
scripted.

I don't think it's useful to closely or tightly constrain a process
which is both advisory and intended to deal with corner cases.

That's why I think it's appropriate for this doc to be BCP
recommendation to the user (which is how it's written), rather than
explicit constraints for expert review. However, I would expect that
recommendations for users from TSV would be taken as context for
reviews, as would any other TSV documents.

> Inserting "solely" before "by a browser" would address my concern.

Would "primarily" also work? It's hard to argue "solely" even for
conventional web access.

> call things with right names and don't misuse "IANA" here.

The document isn't written by IANA. We recommend to IANA, and IANA makes
a decision that the IESG can override. I don't think it's outside the
scope of the doc to indicate this context.

Would it be preferable to say that "applications asking for both...
might not be approved when..."?

> Similarly (in the same section): "IANA currently permits ..."

Same solution here?

Joe

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 16 Jan 2015 19:16:47 +0000

Hi Joe,

> reviews, as would any other TSV documents.
My concerns is that BCP are commonly used by ADs to enforce compliance. 
So I am wondering why this document is not just Informational?
> Would "primarily" also work? It's hard to argue "solely" even for
Yes, "primarily" is actually better.
> scope of the doc to indicate this context.
Actually I disagree. IANA is just following procedure prescribed by 
IETF. Experts are not really acting as advisors (although in practice 
there is always a dialogue, which is as it should be).
> might not be approved when..."?
Yes.
>> Similarly (in the same section): "IANA currently permits ..."
Sure.

---

From: Joe Touch <[email-masked]>
Date: Fri, 16 Jan 2015 11:26:49 -0800

Hi, Alexey,

> Hi Joe,
...
> So I am wondering why this document is not just Informational?

AFAIR, the WG wanted it to be BCP to be a stronger recommendation to
protocol designers than would be an Informational doc.

However, the way expert review and the appeals process already allows
ADs to either use BCPs or override them anyway, so I don't see this as
unduly constraining them. Besides, all sorts of docs - including
standards-track - are contradictory, so there's no one way to ensure
they're all followed.

...
>>> In 7.4:
...
> Yes, "primarily" is actually better.

OK. Will do.

> there is always a dialogue, which is as it should be).

IANA doesn't have to agree with expert reviewer recommendations. There
isn't anything binding that, though - as you note - there's a dialogue
and it's not an issue in practice.

>> might not be approved when..."?

OK - will do.

>>> Similarly (in the same section): "IANA currently permits ..."

OK - will do.

Joe

---

From: "Black, David" <[email-masked]>
Date: Sat, 17 Jan 2015 23:10:47 +0000

> Yes the document was marked BCP on 2011-01-26 after WG discussion and
> advice from our ADs, but this was not based on offering advice to IANA (as
> in RFC 6335), but rather guidance to protocol and applications designers
> needing to use transport ports.

I concur with Gorry's summary, and believe that BCP status is appropriate.
I suggest teeing this concern (whether BCP vs. Informational is the right
status for this sort of guidance document) up to the IESG for a decision.

In its ordinary English (dictionary) meaning, "best current practice"
certainly applies to this draft.  OTOH, the IETF notion of BCP has a
rather specific meaning and some definite implications in practice.  FWIW,
Alexey is not the only person who's made note of that concern wrt this draft.

In my view, the IESG owns the decision (and decision criteria) on what
should vs. should not be a BCP.  I think we should expand the draft writeup
to note this concern (BCP vs. Informational status) as one that needs IESG
attention and ask our ADs to ensure that it does get suitable IESG attention.

Much as I prefer to resolve open issues before IESG Evaluation, in this case,
I think the IESG needs to make a decision, and it is within reason for us to
ask them to do so ;-).

Thanks,
--David (as Gorry's tsvwg WG co-chair)

> -----Original Message-----
> From: tsvwg [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Saturday, January 17, 2015 11:51 AM
> To: Joe Touch
> Cc: Alexey Melnikov; [email-masked]; [email-masked]
> Subject: Re: [tsvwg] Last Call: <draft-ietf-tsvwg-port-use-06.txt>
> (Recommendations for Transport Port Number Uses) to Best Current Practice
> 
> HI,
> 
> I added a little history in-line to help inform comments on the intended
> status.
> 
> > Hi, Alexey,
> >
> Yes the document was marked BCP on 2011-01-26 after WG discussion and
> advice from our ADs, but this was not based on offering advice to IANA (as
> in RFC 6335), but rather guidance to protocol and applications designers
> needing to use transport ports
> 
> Gorry
>

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Sat, 17 Jan 2015 17:16:46 -0600

David and Gorry,

> --David (as Gorry's tsvwg WG co-chair)

That sounds exactly right. I'll wait until you are happy with the shepherd
writeup before I proceed.

Spencer

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 19 Jan 2015 11:51:13 +0000

On 19/01/2015 09:02, [email-masked] wrote:
> I submitted a new shepherd writeup, based on this and what I found on the
> list.
Sounds fair. Thank you for discussing this further in the write-up.
>>> I think the IESG needs to make a decision, and it is within reason for
>>> us
>>> to
>>> ask them to do so ;-).
>>>
>>> Thanks,

---

From: [email-masked]
Date: Sat, 17 Jan 2015 16:51:06 -0000

HI,

Gorry

---

From: [email-masked]
Date: Mon, 19 Jan 2015 09:02:16 -0000

Gorry