Skip to main content

Recommendations on Using Assigned Transport Port Numbers
RFC 7605

Revision differences

Document history

Date Rev. By Action
2020-01-21
11 (System) Received changes through RFC Editor sync (added Verified Errata tag)
2015-10-14
11 (System) Notify list changed from tsvwg-chairs@ietf.org, draft-ietf-tsvwg-port-use@ietf.org to (None)
2015-08-07
11 (System) RFC published
2015-08-04
11 (System) RFC Editor state changed to <a href="http://www.rfc-editor.org/auth48/rfc7605">AUTH48-DONE</a> from AUTH48
2015-07-20
11 (System) RFC Editor state changed to <a href="http://www.rfc-editor.org/auth48/rfc7605">AUTH48</a> from RFC-EDITOR
2015-07-12
11 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2015-05-04
11 Cindy Morgan IESG state changed to RFC Ed Queue from Approved-announcement sent
2015-05-04
11 (System) RFC Editor state changed to EDIT
2015-05-04
11 (System) Announcement was received by RFC Editor
2015-05-04
11 (System) IANA Action state changed to No IC from In Progress
2015-05-04
11 (System) IANA Action state changed to In Progress
2015-05-04
11 Amy Vezza IESG state changed to Approved-announcement sent from IESG Evaluation::AD Followup
2015-05-04
11 Amy Vezza IESG has approved the document
2015-05-04
11 Amy Vezza Closed "Approve" ballot
2015-05-04
11 Amy Vezza Ballot approval text was generated
2015-05-04
11 Amy Vezza Ballot writeup was changed
2015-04-24
11 Alissa Cooper
[Ballot comment]
Thanks for addressing my DISCUSS!

---

I think I may have some overlapping comments with Barry, but I wrote this before I saw …
[Ballot comment]
Thanks for addressing my DISCUSS!

---

I think I may have some overlapping comments with Barry, but I wrote this before I saw his comments, so my apologies.

-- Sec 5:
"Port numbers can also be useful for other purposes."

I would suggest s/useful/used/ because whether the purposes listed in the previous paragraph (e.g., monitoring, blocking, etc. based on port number) are considered "useful" is in the eye of the beholder.

-- Sec 7.4:
The term "security" is really vague. It would help to define what is meant by "security" or "secure service."

-- Sec 7.4 and 7.5:
Both of these sections contain recommendations that are good, but seem out of place in this document unless they could be made more specific to port use. The ones that jumped out at me are:

  >> New services SHOULD support security, either directly or via a
  secure transport such as TLS [RFC5246].

  >> Insecure versions of new or existing secure services SHOULD be
  avoided because of the new vulnerability they create.
 
  >> Version support SHOULD be included in new services.

I would say to either remove these or add in the context of what they have to do with port number assignment (e.g., "Version support SHOULD be included in new services rather than relying on different port number assignments for different versions.")

-- Sec 7.7:
"Deployments that use port numbers before deployment complicate IANA
  management of the port number space."

I think this is supposed to say "before assignment" rather than "before deployment."

-- Sec 7.8:
""Squatting" describes the use of a number from the assigned range in
  deployed software without IANA assignment. It is hazardous because
  IANA cannot track such usage and thus cannot avoid making legitimate
  assignments that conflict with such unauthorized usage.

  Such "squatted" port numbers remain unassigned, and IANA retains the
  right to assign them when requested by applicants."

This is a little confusing -- is the first sentence supposed to say "unassigned range"? If not, what is the assigned range, and why is IANA said to retain the right to assign numbers that are already assigned? I would have thought squatting would be understood as using unassigned numbers in the system and user ranges.

"In
  particular, any unassigned code from the assigned ranges will be
  assigned by IANA, and any conflict will be easily resolved as the
  protocol designer's fault once that happens (because they would not
  be the assignee). This may reflect in the public's judgment on the
  quality of their expertise and cooperation with the Internet
  community."

This seems a little over-the-top to me. I would suggest:

"IANA may assign any code from the system or user ranges to applicants that meet all of the relevant criteria, and is not obligated to take into consideration the existence of squatters when doing so. Squatting is viewed as uncooperative behavior in the Internet community."
2015-04-24
11 Alissa Cooper [Ballot Position Update] Position for Alissa Cooper has been changed to No Objection from Discuss
2015-04-24
11 Joseph Touch New version available: draft-ietf-tsvwg-port-use-11.txt
2015-03-30
10 Kathleen Moriarty
[Ballot comment]
Comments:

Thanks for your work on this draft and addressing my and other ADs prior discusses and comments.  I'll just leave the one …
[Ballot comment]
Comments:

Thanks for your work on this draft and addressing my and other ADs prior discusses and comments.  I'll just leave the one comment below as Alissa's discuss may not have been addressed yet.  I'll be interested to see any new text on it.

For what it's worth, I read 6.2 as informational background and think the text is helpful.  Alissa has a discuss on this, so if the text is changed, I'd be interested to see what the suggested changes would be so that the draft still conveys the helpful information (which she was not opposed to in the discuss).  I've configured hundreds of firewalls and what is described is what folks need to know when configuring such devices.  Alternate port use can be used to get around rules you put in place and services like FTP in the old days would have used an FTP proxy and today that type of analysis on traffic to open the correct ports is called DPI.
2015-03-30
10 Kathleen Moriarty [Ballot Position Update] Position for Kathleen Moriarty has been changed to No Objection from Discuss
2015-03-25
10 Joseph Touch New version available: draft-ietf-tsvwg-port-use-10.txt
2015-03-23
09 Ted Lemon
[Ballot comment]
Thanks for addressing my DISCUSS.  This is an excellent document and I support publication.  Thanks for doing this work--it's very complete and should …
[Ballot comment]
Thanks for addressing my DISCUSS.  This is an excellent document and I support publication.  Thanks for doing this work--it's very complete and should serve as a good guide for working groups designing new protocols.

One additional comment, the new version has a change in section five resulting in the following text:

  This is the primary reason for requesting assigned port
  numbers assigned by IANA

The double use of "assigned" here is likely to make the RFC editor want to change the text, so it might be nice to add a note explaining why this change was made so that that information isn't forgotten by the time this gets to the top of the editor queue.
2015-03-23
09 Ted Lemon [Ballot Position Update] Position for Ted Lemon has been changed to Yes from Discuss
2015-03-23
09 Joseph Touch IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2015-03-23
09 Joseph Touch New version available: draft-ietf-tsvwg-port-use-09.txt
2015-03-19
08 Kathleen Moriarty
[Ballot discuss]
I'd like to see this worked out, so I'm changing back to discuss to see what happens with this conversation.
This draft is …
[Ballot discuss]
I'd like to see this worked out, so I'm changing back to discuss to see what happens with this conversation.
This draft is making a point claiming consensus on the security of one port versus two and I do not agree that the IETF has such agreement on consensus and do not agree that the referenced draft provides that.  We showed a lack of consensus on the SecDir list and Ted Lemon provided a pointer to text in a newer RFC than the 15 year old one that Joe is referencing which states there is no consensus on this point.  I'd like to see what results from discussions with the WG and would like to see the language changed.


You may already have the few sentences queued up as a result of your response to the SecDir review:
https://www.ietf.org/mail-archive/web/secdir/current/msg05422.html

Essentially adding mention of DTLS and IPsec as options to secure sessions in addition to TLS.

I do think the point Dan raised was good and appreciated your response, but this draft version is prior to that discussion.  This is a placeholder to check for that text.  If you have a version to look at, let me know and I'll peek at that one.
2015-03-19
08 Kathleen Moriarty
[Ballot comment]


Comments:

Thanks for your work on this draft.  I do have some comments I'd like to chat about, but others already had discuss …
[Ballot comment]


Comments:

Thanks for your work on this draft.  I do have some comments I'd like to chat about, but others already had discuss items on a few of these, so I am either weighing in or providing suggestions to help resolve.

For what it's worth, I read 6.2 as informational background and think the text is helpful.  Alissa has a discuss on this, so if the text is changed, I'd be interested to see what the suggested changes would be so that the draft still conveys the helpful information (which she was not opposed to in the discuss).  I've configured hundreds of firewalls and what is described is what folks need to know when configuring such devices.  Alternate port use can be used to get around rules you put in place and services like FTP in the old days would have used an FTP proxy and today that type of analysis on traffic to open the correct ports is called DPI.

The following "much debated" text was raised on the SAAG list by Stephen & I and so far there's no consensus for multiple ports.  I'll update if there is, but I suspect there won't be.  I do think that some changes to the text could be helpful and I'm not sure where to look for changes that happened from Barry's review...  I am fine with the text Barry suggested to replace the first of the following two paragraphs and I don't think the second one is needed, perhaps deleting it as Barry's new text covers that enough.  I just wasn't sure if that was already part of the updates in the works.
    o  Separate port numbers are not intended for insecure versions
        of existing (or new) secure services. A service that already
        requires security would be made more vulnerable by having the
        same capability accessible without security.

        Note that the converse is different, i.e., it can be useful to
        create a new, secure service that replicates an existing
        insecure service on a new port number assignment. This can be
        necessary when the existing service is not backward-compatible
        with security enhancements, such as the use of TLS [RFC5246].

7.4 - I'm fine with the text in this section discouraging the use of a second port for an insecure version of the protocol as we are pushing back on creating insecure versions anyway.  Typically, this is all over one port with options to upgrade to increased security (encryption & authentication).  I don't think this draft is the right place to go further than you already have, so I'm good with most of it.

I think it was Alissa that raised a point on this sentence in the paragraph following the compliance bullets and I agree with it, so I suggest a change from:
  Either approach is currently permitted, although
  use of a single port number is consistent with port number
  conservation.
To:
  Either approach is currently permitted.

The second sentence of the paragraph after that should be deleted, leaving the argument just between performance and security.
Delete:  As discussed earlier, port numbers are a critical
  resource and it is inappropriate to consume assignments to increase
  performance.

Thanks!
2015-03-19
08 Kathleen Moriarty [Ballot Position Update] Position for Kathleen Moriarty has been changed to Discuss from Abstain
2015-03-19
08 Richard Barnes [Ballot Position Update] Position for Richard Barnes has been changed to No Objection from Discuss
2015-03-19
08 Adrian Farrel
[Ballot comment]
The most recent revision addresses the two remaining points from my Discuss. Thanks to the author for the (somewhat lengthy) discussion that resulted …
[Ballot comment]
The most recent revision addresses the two remaining points from my Discuss. Thanks to the author for the (somewhat lengthy) discussion that resulted in the changes.

I have also reduced my list of Comments according to this most recent revision and our discussions.

[Please recall that Comments are my voiced opinions, but are not mandatory. Please reach agreement with your AD on what needs to be done to the document.]

---

I agree with Ted's Discuss about secure and insecure variants on
different port numbers.

RFC 6335 says

      Note: At the time of writing of this document, there is no IETF
      consensus on when it is appropriate to use a second port for an
      insecure version of a protocol.

I don't see that Section 7.4 of this document has established that
consensus, and I believe that there are good reasons to distinguish
secure and insecure protocol versions (esepecially with legacy, insecure
protocols) by use of separate port numbers.

---

[This item removed from my Discuss]

I think that the "guiding principle" in 6.1 that says...

      o  Copies of an existing service can be differentiated by using
        different IP addresses, either on different hosts or as
        different real or virtual interfaces (or even operating
        systems) on the same host.

... describes an option, but it is wrong to suggest it as a solution.
The main thrust of the document says that it is wrong to include a
demultiplex reference at the transport layer when what is being
multiplexed is really at the application layer (or at last at the level
of the payload of the transport protocol). Yet this suggested remedy
actually pushes the demultiplex identifier to the network layer. That
really is not a good thing to recommend.

...Further to email discussion with the author, I think that this is describing
a situation where copies of a host are being made, not copies of a service.
It is not a significant Comment, but I feel that this bullet is distracting from
the main list of suggested solution.
2015-03-19
08 Adrian Farrel [Ballot Position Update] Position for Adrian Farrel has been changed to No Objection from Discuss
2015-03-18
08 (System) Sub state has been changed to AD Followup from Revised ID Needed
2015-03-18
08 Cindy Morgan New revision available
2015-03-15
07 Kathleen Moriarty
[Ballot comment]
Reason for abstain:
This draft is making a point claiming consensus on the security of one port versus two and I do not …
[Ballot comment]
Reason for abstain:
This draft is making a point claiming consensus on the security of one port versus two and I do not agree that the IETF has such a statement on consensus.  We showed this on the SecDir list and Ted Lemon provided a pointer to text in a newer RFC than the 15 year old one that Joe is referencing which states there is no consensus on this point.  The editor doesn't seem to be budging or checking with the WG and scoping that advice to the WG only (as it is not IETF advice), even though 5 ADs disagree with him.





Prior Discuss points, still should be checked in new version:
You may already have the few sentences queued up as a result of your response to the SecDir review:
https://www.ietf.org/mail-archive/web/secdir/current/msg05422.html

Essentially adding mention of DTLS and IPsec as options to secure sessions in addition to TLS.

I do think the point Dan raised was good and appreciated your response, but this draft version is prior to that discussion.  This is a placeholder to check for that text.  If you have a version to look at, let me know and I'll peek at that one.


Comments:

Thanks for your work on this draft.  I do have some comments I'd like to chat about, but others already had discuss items on a few of these, so I am either weighing in or providing suggestions to help resolve.

For what it's worth, I read 6.2 as informational background and think the text is helpful.  Alissa has a discuss on this, so if the text is changed, I'd be interested to see what the suggested changes would be so that the draft still conveys the helpful information (which she was not opposed to in the discuss).  I've configured hundreds of firewalls and what is described is what folks need to know when configuring such devices.  Alternate port use can be used to get around rules you put in place and services like FTP in the old days would have used an FTP proxy and today that type of analysis on traffic to open the correct ports is called DPI.

The following "much debated" text was raised on the SAAG list by Stephen & I and so far there's no consensus for multiple ports.  I'll update if there is, but I suspect there won't be.  I do think that some changes to the text could be helpful and I'm not sure where to look for changes that happened from Barry's review...  I am fine with the text Barry suggested to replace the first of the following two paragraphs and I don't think the second one is needed, perhaps deleting it as Barry's new text covers that enough.  I just wasn't sure if that was already part of the updates in the works.
    o  Separate port numbers are not intended for insecure versions
        of existing (or new) secure services. A service that already
        requires security would be made more vulnerable by having the
        same capability accessible without security.

        Note that the converse is different, i.e., it can be useful to
        create a new, secure service that replicates an existing
        insecure service on a new port number assignment. This can be
        necessary when the existing service is not backward-compatible
        with security enhancements, such as the use of TLS [RFC5246].

7.4 - I'm fine with the text in this section discouraging the use of a second port for an insecure version of the protocol as we are pushing back on creating insecure versions anyway.  Typically, this is all over one port with options to upgrade to increased security (encryption & authentication).  I don't think this draft is the right place to go further than you already have, so I'm good with most of it.

I think it was Alissa that raised a point on this sentence in the paragraph following the compliance bullets and I agree with it, so I suggest a change from:
  Either approach is currently permitted, although
  use of a single port number is consistent with port number
  conservation.
To:
  Either approach is currently permitted.

The second sentence of the paragraph after that should be deleted, leaving the argument just between performance and security.
Delete:  As discussed earlier, port numbers are a critical
  resource and it is inappropriate to consume assignments to increase
  performance.

Thanks!
2015-03-15
07 Kathleen Moriarty [Ballot Position Update] Position for Kathleen Moriarty has been changed to Abstain from Discuss
2015-03-05
07 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2015-03-05
07 Adrian Farrel
[Ballot discuss]
[Updated to remove the middle of three points to the Comments section]

Thanks for this work. I think it is helpful for authors …
[Ballot discuss]
[Updated to remove the middle of three points to the Comments section]

Thanks for this work. I think it is helpful for authors and protocol
designers to understand the way that the port experts approach this
issue. But I have some concerns that I hope we can work out quite
simply.

---

I understand that the current situation with the number of free ports
is in some respects due to the "policing" by the port experts. But I
disagree that the situation is such a severe state that fierce rules
are needed. And "compliance statements" are fierce rules not
recommendations or guidance.

Furthermore, this document brings to the fore the thin line between the
opinions of the port experts and the opinions of the IETF community. If,
for example, the community chooses (with appropriate discussion and
consideration) to request IANA to allocate a port via an IETF consensus
standards track document, I believe that request should be honored.
Obviously the port experts should express their opinions as firmly as
they hold them, and the TSV ADs may support their opinions, but I do
not think that the port experts should ultimately be able to override
the community consensus.

I would appreciate it if this document made it clearer that the "rules"
it defines are guidance only, and that exceptions may be made when there
is community consensus to make such exceptions.

---

Section 7.6 has

  >> Services SHOULD NOT use UDP as a performance enhancement over
  TCP, i.e., to circumnavigate TCP's congestion control.

Is this a port use issue, or guidance about how to use transport
protocols in a harmonious Internet? I think it is the latter and has no
place in this document.
2015-03-05
07 Adrian Farrel
[Ballot comment]
I appreciate that this document was sent for early cross-area review
as noted in the shepherd write-up. It's a little disappointing that
Routing …
[Ballot comment]
I appreciate that this document was sent for early cross-area review
as noted in the shepherd write-up. It's a little disappointing that
Routing wasn't included in that process given the recent interesting
debates about the use of ports for indicating UDP tunnel payloads, and
about ports for different types of BFD usage.

Well, no point in bitching about that now. There was an IETF last call,
and

---

I agree with Ted's Discuss about secure and insecure variants on
different port numbers.

RFC 6335 says

      Note: At the time of writing of this document, there is no IETF
      consensus on when it is appropriate to use a second port for an
      insecure version of a protocol.

I don't see that Section 7.4 of this document has established that
consensus, and I believe that there are good reasons to distinguish
secure and insecure protocol versions (esepecially with legacy, insecure
protocols) by use of separate port numbers.

Furthermore, Section 7.4 goes *way* beyond the scope of the document by
stating how new "services" should be designed. Is it the place of this
document to tell protocol designers what security they should put in
their protocols? (It doesn't matter whether the advice is good or not,
it seems unlikely that this section has been reviewed by people who
believed that the document was only about recommendations for port
number assignment and uses). [I almost made this a Discuss in it's own
right, but I think it can piggy-back on Ted's Discuss.]

---

Notwithstanding our disagreement about quite how critical conservation
may be and how practical some of the principles in 6.1 are, I find the
compliance requirement in Section 6 hard to parse.

  >> Each port requested MUST be justified as independently necessary.

Could you explain or reword "independently necessary"? Independent of
what?

"Justified" by whom / to whom (I think that is more obvious, but it
wouldn't hurt to spell it out).

---

Section 7.6 has
  However, to
  conserve space and to reflect increasing use of other transports,
  assignments are now specific only to the transport being used.

Can you clarify what space you are referring to? If this is text space
on a web page, then this is not a particularly meaningful reason.

---

Section 7.6 has

  >> Services SHOULD NOT use UDP as a performance enhancement over
  TCP, i.e., to circumnavigate TCP's congestion control.

Is this a port use issue, or guidance about how to use transport
protocols in a harmonious Internet? I think it is the latter and has no
place in this document.

---

Shouldn't Section 7.6 say something about the use of the same port
number for different services with different transports?

That is, you have that port xyz will only be registered for the
transport protocols that service A uses. But you don't go on to say that
port xyz having been registered for service A on transport protocol Z
MUST NOT be registered for service B on transport protocol Y.

---

Section 7.7

  Deployments that use port numbers before deployment complicate IANA
  management of the port number space. Keep in mind that this

I think s/before deployment/before assignment/

----

[This item removed from my Discuss]

I think that the "guiding principle" in 6.1 that says...

      o  Copies of an existing service can be differentiated by using
        different IP addresses, either on different hosts or as
        different real or virtual interfaces (or even operating
        systems) on the same host.

... describes an option, but it is wrong to suggest it as a solution.
The main thrust of the document says that it is wrong to include a
demultiplex reference at the transport layer when what is being
multiplexed is really at the application layer (or at last at the level
of the payload of the transport protocol). Yet this suggested remedy
actually pushes the demultiplex identifier to the network layer. That
really is not a good thing to recommend.

...Further to email discussion with the author, I think that this is describing
a situation where copies of a host are being made, not copies of a service.
It is not a significant Comment, but I feel that this bullet is distracting from
the main list of suggested solution.
2015-03-05
07 Adrian Farrel Ballot comment and discuss text updated for Adrian Farrel
2015-03-05
07 Brian Haberman [Ballot Position Update] Position for Brian Haberman has been changed to No Objection from No Record
2015-03-05
07 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko
2015-03-04
07 Richard Barnes
[Ballot discuss]
Some of the ">>" compliance points here are only marginally related to the subject matter, e.g.:

">> New services SHOULD support security, either …
[Ballot discuss]
Some of the ">>" compliance points here are only marginally related to the subject matter, e.g.:

">> New services SHOULD support security, either directly or via a secure transport such as TLS [RFC5246]."

">> UDP over IPv4 multi-host services SHOULD use multicast rather than broadcast."

">> Services SHOULD NOT use UDP as a performance enhancement over TCP, i.e., to circumnavigate TCP's congestion control."

While these may be good things to say, they don't belong in this document.
2015-03-04
07 Richard Barnes
[Ballot comment]
I share Alissa's comments that the rationale for conservation is a bit shaky.  Clearly conservation is prudent, but it doesn't seem like there's …
[Ballot comment]
I share Alissa's comments that the rationale for conservation is a bit shaky.  Clearly conservation is prudent, but it doesn't seem like there's a crisis here.

Section 3: The values in the "Binary" column are decimal, as indeed they are labelled in RFC 758.

Section 7.4: I agree with Stephen here.  Separate ports and STARTTLS are equivalent from a security/downgrade POV -- either you need to know to use the secure port, or you need to know to require STARTTLS to succeed.  The only difference is that STARTTLS adds latency if you're doing TLS. You can avoid that by starting secure (STOPTLS?), but in either case, there's a loser.  But ISTM that the document addresses this point sufficiently.
2015-03-04
07 Richard Barnes [Ballot Position Update] New position, Discuss, has been recorded for Richard Barnes
2015-03-04
07 Alia Atlas [Ballot comment]
I agree with Adrian's DISCUSS
2015-03-04
07 Alia Atlas [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas
2015-03-04
07 Stephen Farrell
[Ballot comment]

- I share the concern that this needs to be in-whack with
RFC6335 but sometimes overstates things, e.g. some of the
MUST NOTs …
[Ballot comment]

- I share the concern that this needs to be in-whack with
RFC6335 but sometimes overstates things, e.g. some of the
MUST NOTs in 7.7.  I'm fine that that's being discussed
already.

- The one-port/two-port thing: I don't think there's a real
seurity difference here in general, so that is not a basis on
which to prefer to discourage the registration of two ports,
nor is it a reason to prefer to do that. It is however, also
reasonable to want two ports, one e.g. using TLS and one not,
and it is equally reasonable to use STARTTLS.  Basically,
please move on, there's nothing to see here, find another
argument:-)

- I would like to see a statement that, in allocating a new
port for a "secure" variant of an existing protocol, the port
experts will consider actual deployment, even if it is the
case that some RFC says that one can do security stuff on the
currently assigned port. If we do not allocate such ports,
then we would be getting in the way of improving real
security, and that would be bad.  I'm not sure from the text
what the port experts do in such cases, but as that is not
addressed by the current document, the RFC that results won't
be a block on such allocations (where justified).

- 7.8, "easily resolved" to be the squatter's fault is not
true - in general people will I think consider the most
widely deployed use of a port to be in the right, and most
people won't even go look at the IANA registry. (Some will,
including no doubt the port experts.)
2015-03-04
07 Stephen Farrell [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell
2015-03-03
07 Kathleen Moriarty
[Ballot discuss]
You may already have the few sentences queued up as a result of your response to the SecDir review:
https://www.ietf.org/mail-archive/web/secdir/current/msg05422.html

Essentially adding mention …
[Ballot discuss]
You may already have the few sentences queued up as a result of your response to the SecDir review:
https://www.ietf.org/mail-archive/web/secdir/current/msg05422.html

Essentially adding mention of DTLS and IPsec as options to secure sessions in addition to TLS.

I do think the point Dan raised was good and appreciated your response, but this draft version is prior to that discussion.  This is a placeholder to check for that text.  If you have a version to look at, let me know and I'll peek at that one.
2015-03-03
07 Kathleen Moriarty
[Ballot comment]
Thanks for your work on this draft.  I do have some comments I'd like to chat about, but others already had discuss items …
[Ballot comment]
Thanks for your work on this draft.  I do have some comments I'd like to chat about, but others already had discuss items on a few of these, so I am either weighing in or providing suggestions to help resolve.

For what it's worth, I read 6.2 as informational background and think the text is helpful.  Alissa has a discuss on this, so if the text is changed, I'd be interested to see what the suggested changes would be so that the draft still conveys the helpful information (which she was not opposed to in the discuss).  I've configured hundreds of firewalls and what is described is what folks need to know when configuring such devices.  Alternate port use can be used to get around rules you put in place and services like FTP in the old days would have used an FTP proxy and today that type of analysis on traffic to open the correct ports is called DPI.

The following "much debated" text was raised on the SAAG list by Stephen & I and so far there's no consensus for multiple ports.  I'll update if there is, but I suspect there won't be.  I do think that some changes to the text could be helpful and I'm not sure where to look for changes that happened from Barry's review...  I am fine with the text Barry suggested to replace the first of the following two paragraphs and I don't think the second one is needed, perhaps deleting it as Barry's new text covers that enough.  I just wasn't sure if that was already part of the updates in the works.
    o  Separate port numbers are not intended for insecure versions
        of existing (or new) secure services. A service that already
        requires security would be made more vulnerable by having the
        same capability accessible without security.

        Note that the converse is different, i.e., it can be useful to
        create a new, secure service that replicates an existing
        insecure service on a new port number assignment. This can be
        necessary when the existing service is not backward-compatible
        with security enhancements, such as the use of TLS [RFC5246].

7.4 - I'm fine with the text in this section discouraging the use of a second port for an insecure version of the protocol as we are pushing back on creating insecure versions anyway.  Typically, this is all over one port with options to upgrade to increased security (encryption & authentication).  I don't think this draft is the right place to go further than you already have, so I'm good with most of it.

I think it was Alissa that raised a point on this sentence in the paragraph following the compliance bullets and I agree with it, so I suggest a change from:
  Either approach is currently permitted, although
  use of a single port number is consistent with port number
  conservation.
To:
  Either approach is currently permitted.

The second sentence of the paragraph after that should be deleted, leaving the argument just between performance and security.
Delete:  As discussed earlier, port numbers are a critical
  resource and it is inappropriate to consume assignments to increase
  performance.

Thanks!
2015-03-03
07 Kathleen Moriarty [Ballot Position Update] New position, Discuss, has been recorded for Kathleen Moriarty
2015-02-28
07 Adrian Farrel
[Ballot discuss]
Thanks for this work. I think it is helpful for authors and protocol
designers to understand the way that the port experts approach …
[Ballot discuss]
Thanks for this work. I think it is helpful for authors and protocol
designers to understand the way that the port experts approach this
issue. But I have some concerns that I hope we can work out quite
simply.

---

I understand that the current situation with the number of free ports
is in some respects due to the "policing" by the port experts. But I
disagree that the situation is such a severe state that fierce rules
are needed. And "compliance statements" are fierce rules not
recommendations or guidance.

Furthermore, this document brings to the fore the thin line between the
opinions of the port experts and the opinions of the IETF community. If,
for example, the community chooses (with appropriate discussion and
consideration) to request IANA to allocate a port via an IETF consensus
standards track document, I believe that request should be honored.
Obviously the port experts should express their opinions as firmly as
they hold them, and the TSV ADs may support their opinions, but I do
not think that the port experts should ultimately be able to override
the community consensus.

I would appreciate it if this document made it clearer that the "rules"
it defines are guidance only, and that exceptions may be made when there
is community consensus to make such exceptions.

---

I think that the "guiding principle" in 6.1 that says...

      o  Copies of an existing service can be differentiated by using
        different IP addresses, either on different hosts or as
        different real or virtual interfaces (or even operating
        systems) on the same host.

... describes an option, but it is wrong to suggest it as a solution.
The main thrust of the document says that it is wrong to include a
demultiplex reference at the transport layer when what is being
multiplexed is really at the application layer (or at last at the level
of the payload of the transport protocol). Yet this suggested remedy
actually pushes the demultiplex identifier to the network layer. That
really is not a good thing to recommend.

---

Section 7.6 has

  >> Services SHOULD NOT use UDP as a performance enhancement over
  TCP, i.e., to circumnavigate TCP's congestion control.

Is this a port use issue, or guidance about how to use transport
protocols in a harmonious Internet? I think it is the latter and has no
place in this document.
2015-02-28
07 Adrian Farrel
[Ballot comment]
I appreciate that this document was sent for early cross-area review
as noted in the shepherd write-up. It's a little disappointing that
Routing …
[Ballot comment]
I appreciate that this document was sent for early cross-area review
as noted in the shepherd write-up. It's a little disappointing that
Routing wasn't included in that process given the recent interesting
debates about the use of ports for indicating UDP tunnel payloads, and
about ports for different types of BFD usage.

Well, no point in bitching about that now. There was an IETF last call,
and

---

I agree with Ted's Discuss about secure and insecure variants on
different port numbers.

RFC 6335 says

      Note: At the time of writing of this document, there is no IETF
      consensus on when it is appropriate to use a second port for an
      insecure version of a protocol.

I don't see that Section 7.4 of this document has established that
consensus, and I believe that there are good reasons to distinguish
secure and insecure protocol versions (esepecially with legacy, insecure
protocols) by use of separate port numbers.

Furthermore, Section 7.4 goes *way* beyond the scope of the document by
stating how new "services" should be designed. Is it the place of this
document to tell protocol designers what security they should put in
their protocols? (It doesn't matter whether the advice is good or not,
it seems unlikely that this section has been reviewed by people who
believed that the document was only about recommendations for port
number assignment and uses). [I almost made this a Discuss in it's own
right, but I think it can piggy-back on Ted's Discuss.]

---

Notwithstanding our disagreement about quite how critical conservation
may be and how practical some of the principles in 6.1 are, I find the
compliance requirement in Section 6 hard to parse.

  >> Each port requested MUST be justified as independently necessary.

Could you explain or reword "independently necessary"? Independent of
what?

"Justified" by whom / to whom (I think that is more obvious, but it
wouldn't hurt to spell it out).

---

Section 7.6 has
  However, to
  conserve space and to reflect increasing use of other transports,
  assignments are now specific only to the transport being used.

Can you clarify what space you are referring to? If this is text space
on a web page, then this is not a particularly meaningful reason.

---

Section 7.6 has

  >> Services SHOULD NOT use UDP as a performance enhancement over
  TCP, i.e., to circumnavigate TCP's congestion control.

Is this a port use issue, or guidance about how to use transport
protocols in a harmonious Internet? I think it is the latter and has no
place in this document.

---

Shouldn't Section 7.6 say something about the use of the same port
number for different services with different transports?

That is, you have that port xyz will only be registered for the
transport protocols that service A uses. But you don't go on to say that
port xyz having been registered for service A on transport protocol Z
MUST NOT be registered for service B on transport protocol Y.

---

Section 7.7

  Deployments that use port numbers before deployment complicate IANA
  management of the port number space. Keep in mind that this

I think s/before deployment/before assignment/
2015-02-28
07 Adrian Farrel [Ballot Position Update] New position, Discuss, has been recorded for Adrian Farrel
2015-02-28
07 Ted Lemon
[Ballot discuss]
The -07 version of the document encourages the use of a single port for both secure and non-secure communication.  I am concerned that …
[Ballot discuss]
The -07 version of the document encourages the use of a single port for both secure and non-secure communication.  I am concerned that the outcome will be to encourage the use of mechanisms analogous to STARTTLS in future protocol specifications.  A two-port secure/non-secure model is preferable to any mechanism that supports a downgrade attack: the port number signals that the connection must be secure, or is not expected to be secure.

Barry raised a DISCUSS on this text, but unfortunately it looks like the conversation that followed did not fix the issue, and indeed may have made it worse.  I am concerned that the document as written and with the proposed changes will lead protocol designers to rely on a single port for secure and non-secure communications in situations where this unavoidably exposes the communication to a man-in-the-middle downgrade attack.  I would expect that pretty much any dual-use port would be subject to this risk: dependably preventing it is possible, but hard, and only possible if the thing that signals the initiator to connect to that port can securely indicate whether to use the secure or non-secure mode.

I would therefore like to see the text emphasize this concern, rather than emphasizing the concern that if two ports are used, administrators will default to using the non-secure mode.  I agree that this latter issue is a concern, but it is a concern for any protocol that allows a non-secure mode, whether it uses the port number to signal that or the signaling is done out of band.  The only sense in which using a single port mitigates this concern is if the single port _only_ support secure, authenticated communication.

An alternative would be to simply not take a position either way, but the text currently makes some good points about the tradeoffs, which would have to be lost in order to avoid taking a position, so I don't really want to encourage that solution.
2015-02-28
07 Ted Lemon
[Ballot comment]
Overall this is an excellent document and I support publication: the DISCUSS I've entered should not be taken as an indication otherwise.  Thanks …
[Ballot comment]
Overall this is an excellent document and I support publication: the DISCUSS I've entered should not be taken as an indication otherwise.  Thanks for doing this--it's very complete and should serve as a good guide for working groups designing new protocols.
2015-02-28
07 Ted Lemon [Ballot Position Update] New position, Discuss, has been recorded for Ted Lemon
2015-02-17
07 Spencer Dawkins Telechat date has been changed to 2015-03-05 from 2015-02-19
2015-02-17
07 Pete Resnick
[Ballot comment]
Mostly for the IESG: I agree that this document does not update 6335. I agree that it is supplemental. And I agree that …
[Ballot comment]
Mostly for the IESG: I agree that this document does not update 6335. I agree that it is supplemental. And I agree that it's a BCP. So let's make it part of BCP165. This doesn't need a new BCP number. It's part of the same series.

1: A bit of clarification would be useful:

OLD
  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.
NEW
  Note that this document provides information to potential port number
  applicants that complements the IANA process described in BCP165
  [RFC6335], but it does not change any of the port number assignment
  procedures described therein.

I don't think you need to say anything about the "update" status.

2:

  In this document, the characters ">>" preceding an indented line(s)
  indicates a compliance requirement statement using the key words
  listed above. This convention aids reviewers in quickly identifying
  or finding the explicit compliance requirements of this RFC.

Generally, this sort of things simply produces eye-rolling in me and nothing more. 2119 keywords are not about "compliance", and so to claim above that you are using them "as described in RFC-2119" and then go on to include them in "compliance requirements" is bogus. However, most of these "compliance requirements" in the rest of the document are simply summary advice regarding what's going to be useful and what won't, so really what's in the ">>" is not a "compliance requirement", but rather an "Important Summary Note". I'd really prefer you call them that here. That said, one of them in 7.4 actually gave me pause:

  >> When simultaneously requesting both a secure and an insecure
  port, strong justification MUST be provided for the insecure port.
  Precedent (citing other protocols that use an insecure port) is not
  strong justification by itself.  A strong case for utility of the
  insecure service is REQUIRED for approval of the insecure port.

Here it sounds like you *are* imposing a requirement, and it sure sounds to me like you're specifying a registration procedure to be enforced by the Designated Expert or IANA, not giving a piece of advice to the registrant. If it wasn't for the last sentence in the above, I wouldn't have thought twice about it. So my two suggestions are:

- Change the text in section 2 to not call these "compliance requirements". If you don't like "Important Summary Note", choose something else.

- Change or delete the last sentence in the paragraph from 7.4. (I think delete is fine; it's repetitive anyway.)

7.4/7.5: I agree with Alissa's comments regarding the ">>" statements. Either re-word them to be about port assignment or ditch them.
2015-02-17
07 Pete Resnick [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick
2015-02-17
07 Alissa Cooper
[Ballot discuss]
Thanks for writing this. Overall I agree with its conclusions. But the way that it reaches those conclusions seems lacking or misguided in …
[Ballot discuss]
Thanks for writing this. Overall I agree with its conclusions. But the way that it reaches those conclusions seems lacking or misguided in a couple of respects, so I'd like to discuss those.

The document argues that port numbers should be conserved and gives basically three reasons why (my summary):

1. Port numbers are designed for a specific purpose and conservation helps maintain that specificity.

2. The port number space is smaller than other number spaces.

3. Because of firewall and NAT interactions.

Reason (1) seems unobjectionable.

Reason (2) is true, but it doesn't really offer a compelling argument in light of the pace of assignments to date. The document indicates that about 11% of the port number space has been allocated over several decades. Does that really create cause to worry about running out of space? Are we suddenly being flooded with port number requests? If the rate of assignments doubled or tripled, would we worry about running out of port numbers? Again, I'm not saying this isn't worth pointing out, but in terms of making a compelling argument to developers about the need to conserve port numbers, I don't think this works.

That leaves reason (3), and in this case it seems like the document is making contradictory statements at times. On the one hand, many of the recommendations seem motivated by the fact that firewalls make judgments on the basis of port numbers, and therefore conservation makes firewall configuration easier and reduces application fragility that can arise from having some ports blocked. On the other hand, the document notes that port numbers should only be considered meaningful to endpoints and details some of the complications that arise when firewalls instead associate meaning to them. The message comes across as contradictory -- intermediaries are interpreting port numbers in all kinds of ways that they shouldn't, but we should take a conservative attitude towards port number assignment so that they can keep doing it.

I think it's totally fine to represent the state of affairs when it comes to how firewalls treat ports. But if that treatment is in some ways a perversion of the motivation for having port numbers in the first place (and if it wreaks some havoc on application development/deployment, which it does), I don't think it's appropriate for us to publish a BCP that predicates its recommendations on that perversion.

The upshot of these comments would result in some editing of sections 5 and 6, but I wanted to have the discussion before suggesting edits.
2015-02-17
07 Alissa Cooper
[Ballot comment]
I think I may have some overlapping comments with Barry, but I wrote this before I saw his comments, so my apologies.

-- …
[Ballot comment]
I think I may have some overlapping comments with Barry, but I wrote this before I saw his comments, so my apologies.

-- Sec 5:
"Port numbers can also be useful for other purposes."

I would suggest s/useful/used/ because whether the purposes listed in the previous paragraph (e.g., monitoring, blocking, etc. based on port number) are considered "useful" is in the eye of the beholder.

-- Sec 7.4:
The term "security" is really vague. It would help to define what is meant by "security" or "secure service."

-- Sec 7.4 and 7.5:
Both of these sections contain recommendations that are good, but seem out of place in this document unless they could be made more specific to port use. The ones that jumped out at me are:

  >> New services SHOULD support security, either directly or via a
  secure transport such as TLS [RFC5246].

  >> Insecure versions of new or existing secure services SHOULD be
  avoided because of the new vulnerability they create.
 
  >> Version support SHOULD be included in new services.

I would say to either remove these or add in the context of what they have to do with port number assignment (e.g., "Version support SHOULD be included in new services rather than relying on different port number assignments for different versions.")

-- Sec 7.7:
"Deployments that use port numbers before deployment complicate IANA
  management of the port number space."

I think this is supposed to say "before assignment" rather than "before deployment."

-- Sec 7.8:
""Squatting" describes the use of a number from the assigned range in
  deployed software without IANA assignment. It is hazardous because
  IANA cannot track such usage and thus cannot avoid making legitimate
  assignments that conflict with such unauthorized usage.

  Such "squatted" port numbers remain unassigned, and IANA retains the
  right to assign them when requested by applicants."

This is a little confusing -- is the first sentence supposed to say "unassigned range"? If not, what is the assigned range, and why is IANA said to retain the right to assign numbers that are already assigned? I would have thought squatting would be understood as using unassigned numbers in the system and user ranges.

"In
  particular, any unassigned code from the assigned ranges will be
  assigned by IANA, and any conflict will be easily resolved as the
  protocol designer's fault once that happens (because they would not
  be the assignee). This may reflect in the public's judgment on the
  quality of their expertise and cooperation with the Internet
  community."

This seems a little over-the-top to me. I would suggest:

"IANA may assign any code from the system or user ranges to applicants that meet all of the relevant criteria, and is not obligated to take into consideration the existence of squatters when doing so. Squatting is viewed as uncooperative behavior in the Internet community."
2015-02-17
07 Alissa Cooper [Ballot Position Update] New position, Discuss, has been recorded for Alissa Cooper
2015-02-17
07 Dan Romascanu Request for Telechat review by GENART Completed: Ready. Reviewer: Dan Romascanu.
2015-02-17
07 Martin Stiemerling
[Ballot comment]
Thanks for writing this document!

Just one nit:

On page 6 in this paragraph:

  As a concept, a service is the combination …
[Ballot comment]
Thanks for writing this document!

Just one nit:

On page 6 in this paragraph:

  As a concept, a service is the combination of ISO Layers 5-7 that
  represents an application protocol capability. For example www (port
  number 80) is a service that uses HTTP as an application protocol
  and provides access to a web server [RFC7230]. However, it is
  possible to use HTTP for other purposes, such as command and
  control. This is why some current service names (HTTP, e.g.) are a
  bit overloaded - they describe not only the application protocol,
  but a particular service.

This paragraph introduces the term „service names“ which has not been used before. It would be good to define the term in contrast to the port numbers for naive readers. The explanation of service names comes later, probably too late (just before the beginning of Section 6). How about introducing service names just before?
2015-02-17
07 Martin Stiemerling [Ballot Position Update] New position, Yes, has been recorded for Martin Stiemerling
2015-02-17
07 Barry Leiba
[Ballot comment]
Thanks for quickly addressing my DISCUSS points, two of which are cleared and two of which are now comments here:

-- Section 7.4 …
[Ballot comment]
Thanks for quickly addressing my DISCUSS points, two of which are cleared and two of which are now comments here:

-- Section 7.4 --
  >> New services SHOULD support security, either directly or via a
  secure transport such as TLS [RFC5246].

In this context, "security" is too vague a term: what, exactly, does "SHOULD support security" mean?  Are you talking about authentication?  Access/authorization controls?  Confidentiality?  Specifically, encrypted communication?  I think you mean the last.

<<
Joe Touch responds:
It would be useful to explain.
Security depends on the service being offered; for some, encryption, integrity protection, and source identity are all expected, but for many services only a subset of these might be relevant.
>>

We should add such an explanation.

-- Section 7.4 --
  >> When simultaneously requesting both a secure and an insecure
  port, strong justification MUST be provided for the insecure port.
  Precedent (citing other protocols that use an insecure port) is not
  strong justification by itself.  A strong case for utility of the
  insecure service is REQUIRED for approval of the insecure port.

This seems significantly stronger than what RFC 6335 said, and this point was hotly debated in the development of that document.  RFC 6335, Section 9, says this:

  Services are expected to include support for security, either as
  default or dynamically negotiated in-band.  The use of separate
  service name or port number assignments for secure and insecure
  variants of the same service is to be avoided in order to discourage
  the deployment of insecure services.

As this document does not update 6335, I don't see how the MUST and the REQUIRED are appropriate.  But perhaps I can be convinced by some discussion.

Joe Touch responds:
<<
Again, one doc applies to IANA, the other to protocol designers. RFC6335 explains why IANA should avoid such an assignment; this doc explains that a designer is expected to justify the need in an request to IANA.

It might be useful, as a result, to remove the 2119 language, e.g., to write this from the perspective of advice to the applicant:

    >> When simultaneously requesting both a secure and an insecure
    port, strong justification is expected for the utility and safety
    of a separate insecure port.
    Precedent (citing other protocols that use an insecure port) is not
    strong justification by itself.
>>

The rest of these are non-blocking, but please consider them -- many are meant to clarify the text, and I hope they succeed in that.

In three places:

-- Abstract --
  This document provides recommendations to application and service
  designers on how to use the transport protocol port number space.

-- Section 1 --
  It also provides specific
  recommendations to designers on how to use assigned port numbers.

-- Section 2 --
  In this document, the characters ">>" preceding an indented line(s)
  indicates a compliance requirement statement using the key words
  listed above.

First, recommendations on how to use *port number space* is not the same as recommendations on how to use *assigned port numbers*.  I interpret the former as recommendations about making requests for port numbers, and the latter as recommendations about use of the port numbers after they've been assigned.  These should be worded consistently.

Second, recommendations, whichever type of recommendations they be, are not the same as compliance requirements.  I read the former as suggestions, and the latter as, well, requirements.  If the document is giving requirements that cover port-number requests -- and it is, complete with MUSTs -- it needs to clearly say that up front, and get rid of the "recommendations" stuff (or say both, that there are both requirements and recommendations here).

-- Section 5 --

  Consider a user wanting to run a web server. That service could run
  on any port number, provided that all clients knew what port number
  to use to access that service at that host. Such information can be
  distributed out-of-band, e.g., in the URI:

      http://www.example.com:51509/

It's a fine point, but having the port number in the URI doesn't actually distribute it "out of band" (which doesn't need hyphens in this context).  I would say, "Such information can be explicitly distributed -- for example, by putting it in the URI:".

  IANA assigns port numbers so that Internet endpoints do not need
  pairwise, explicit coordination of the meaning of their port
  numbers. This is the primary reason for requesting assigned port
  numbers with IANA - to have a common agreement between all endpoints
  on the Internet as to the default meaning of a port number.

This only says half of it, and omits a very important piece, I think.  May I suggest this?:

NEW
  IANA assigns port numbers so that Internet endpoints do not need
  pairwise, explicit coordination of the meaning of their port
  numbers. This is the primary reason for requesting assigned port
  numbers with IANA - to have a common agreement between all endpoints
  on the Internet as to the default meaning of a port number, and to
  provide the endpoints with a default port number for a particular
  protocol or service.
END

  >> Each port requested MUST be justified as independently necessary.

This is a fair statement, and yet I worry that including "necessary" may result in arguments between protocol designers and port experts about what is and isn't "necessary", and what the community's consensus is on it.  I'm not sure how to minimize that.  I'd say "MUST be independently justified," which does get the point you want (the independent justification) without using the loaded word "necessary".  I'd prefer that wording, though I admit that it can just as easily result in the same arguments.

-- Section 6.1 --

      o  Copies of an existing service can be differentiated by using
        different IP addresses, either on different hosts or as
        different real or virtual interfaces (or even operating
        systems) on the same host.

As a guiding principle for protocol designers, this worries me: it's an operational point, not a point of protocol design.  I'd have no objection if this were explicitly cast as an operational suggestion.

      o  Services requiring varying performance properties can already
        be supported using separate endpoint associations (connections
        or other associations), each configured to support the desired
        properties.

I can't figure out what you mean here.  Do you have an example, or can you tweak the explanation?

-- Section 7 --

  7. How to Use Assigned Port Numbers

  Port numbers are assigned by IANA by a set of documented procedures
  [RFC6335]. The following section describes the steps users can take
  to help assist with the use of assigned port numbers, and with
  preparing an application for a port number assignment.

In both the title and the paragraph, you refer to the "use" of "assigned port numbers", and yet the entire section talks about getting port assignments, not about using the port numbers after they're assigned.  I suggest this instead:

NEW
  7. Considerations for Requesting Port Number Assignments

  Port numbers are assigned by IANA by a set of documented procedures
  [RFC6335]. The following section describes the steps designers can
  take to help assist with the responsible assignment of port numbers,
  and with preparing an application for a port number assignment.
END

-- Section 7.1 --

      o  Port numbers are not intended for indicating different service
        versions. Version differentiation should be handled in-band,
        e.g., using a version number at the beginning of an
        association (e.g., connection or other transaction). This may
        not be possible with legacy assignments, but all new
        assignments should incorporate support for version indication.

Is this meant to say "but all new protocols should incorporate support for version indication."?  It's not the assignment that does that.

  Some users may not need assigned port numbers at all

Is this meant to say "some uses may not" (or "some protocols", but not "some users")?

-- Section 7.2 --

  There are a
  variety of known ways to reduce port number use. Although some may
  be cumbersome or inefficient, they are always preferable to
  consuming additional port numbers.

1. I think "reduce port number consumption" might be a better way to say what you mean here.

2. I don't think "always preferable" is consistent with the consensus on RFC 6335.  I would accept "usually preferable", but not something as strong as "always".

  Although
  automatic configuration protocols have been proposed and developed
  (e.g., STUN [RFC5389], TURN [RFC5766], and ICE [RFC5245]),
  application and service designers cannot yet rely on their presence.

I wouldn't call STUN, TURN, and ICE "automatic configuration protocols".  I'd refer to them as "NAT traversal protocols".

-- Section 7.3 --

  Would a TCP (or other transport
  protocol) port number assignment be useful by itself?  If so, a TCP
  (UDP) port number can be assigned whose port number is already (or
  can be subsequently) assigned to a different transport protocol.

I'm not sure what you're getting at here.  Are you saying that if you need a TCP port, you might pick one where the UDP port of the same number is (or can be) used for something else, and vice versa?  If so, I don't think it says that at all clearly.  In any case, can you please rephrase this to make it clearer?

  >> Developers SHOULD NOT apply for System port numbers because the
  increased privilege they are intended to provide is not always
  enforced.

Hm.  This sounds odd to me: it seems that it's setting up a feedback loop that's self sustaining.  You might want a system port number to get protection against running on that port by non-root.  But you won't always get that protection.  So you shouldn't ask.  So no one asks, and so no one gets the protection even when it's available.

Do you think this works as well for you?:

NEW
  >> Developers SHOULD request User port numbers, to avoid using
  the more limited System port number space.  Consider that the
  increased protection that System ports are intended to provide
  is not always enforced.
END

I would also move that paragraph down one, so that it's after the "Even when developers" paragraph.

-- Section 7.4 --

  >> Security SHOULD NOT rely on port number distinctions alone; every
  service, whether secure or not, is likely to be attacked.

I find this underspecified.  I don't know what I should be doing about this.  As in the DISCUSS, "security" is a vague term, and I don't know how to determine whether I've met this requirement, nor how to assess whether my situation is suitable one for not following it.

  Optional security can penalize performance, requiring additional
  round-trip exchanges before a connection or other association can be
  established. As discussed earlier, port numbers are a critical
  resource and it is inappropriate to consume assignments to increase
  performance. As a result, the need for separate ports for both
  secure and insecure variants is not justified merely for performance

Where was this discussed earlier?  The only thing I see related to performance that was discussed earlier is that it's not appropriate to have different ports to support different performance levels.  That's not the same thing that you're talking about here.  I agree with the conclusion (in the final sentence I quote).

  - either for the connection or association establishment performance
  or differences in data performance between secure and insecure
  variants.

I can't parse this.  Are there words missing or some such?

  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 applications requesting assignment for both
  an insecure port number for a secure service might not be
  appropriate.

I'm having trouble with this one also; I can't parse what comes after the comma.  Maybe split the sentence into two, and rephrase?

-- Section 7.5 --
How can this apply retroactively to current assignments?  And "the multiple versions" should probably lose the "the".

-- Section 7.6 --
Spencer has been picking on the use of 793 as a reference for TCP.  Spencer, is 793 an acceptable reference for TCP here?

It would probably be better to attach the references to their protocols, rather than to have them in a group at the end of the list.

  Originally, IANA port number assignments were concurrent for both
  UDP and TCP; other transports were not indicated.

Total nit: I think this sentence doesn't work well with a semicolon, and would prefer changing the ";" to ", and".

  When the services differ, their service names and descriptions
  should reflect that difference.

I had a little trouble with this and the discussion leading up to it, which I think can be fixed by saying explicitly that in this case, it's OK (perhaps even encouraged) to use the same port, but different service names.  Perhaps something like this?:

NEW
  When the services differ, it may be acceptable or preferable
  to use the same port number, but the service names and
  descriptions should be different, reflecting the differences
  in the services.
END

  The following convention has been used by IANA
  for several years to distinguish discovery services, such as are
  used to identify endpoints capable of a given service:

  >> Names of discovery services SHOULD use an identifiable suffix;
  the suggestion is "-disc".

It reads oddly to have "the following convention" point to a normative requirement, and not just to the convention.  Again, a nit, but I think it would read better like this:

NEW
  IANA has, for several years, used the suffix "-disc" in service
  names to distinguish discovery services, such as are used to
  identify endpoints capable of a given service.

  >> Names of discovery services SHOULD use an identifiable suffix;
  the suggestion is "-disc".
END

  because IP routers do not forward "all nodes" (all 1's, i.e.,
  255.255.255.255 for IPv4) broadcasts and have not been required

The phrase << "all nodes" broadcasts >> needs to stay together, and splitting it with the explanation made me trip over it.  I suggest moving the word "broadcasts" before the parenthesized bit.

  >> Services SHOULD NOT use UDP as a performance enhancement over
  TCP, i.e., to circumnavigate TCP's congestion control.

Is circumventing congestion control the only possible performance enhancement here?  This sentence really makes one ask whether "i.e." is correct, or you mean "e.g.", and I think it'd be better done one of these ways:

If you mean to say that congestion control is the only reason:
NEW
  >> Services SHOULD NOT use UDP to enhance performance by
  circumventing TCP's congestion control.
END

If there might be other performance-enhancement reasons:
NEW
  >> Services SHOULD NOT use UDP as a performance enhancement over
  TCP.  For example, do not use UDP to circumvent TCP's congestion
  control.
END

(The right word is "circumvent", not "circumnavigate".)

-- Section 7.7 --

  Applications made through Internet Draft / RFC publication (in any
  stream)
...
  When a document has been approved for
  publication and proceeds to IESG Approval

The first sentence tries to make this stream-independent, but the "IESG Approval" later in the paragraph is specific to the IETF stream.  Because you already say "approved for publication", you can just omit the "and proceeds to IESG Approval" phrase.

-- Section 7.8 --

  Such "squatted" port numbers remain unassigned, and IANA retains the
  right to assign them when requested by applicants.

It might be good to be completely clear and say "requested by other applicants," lest readers think you mean to be talking about when the squatters make an application later.

The last paragraph in this section starts by encouraging squatters to make registrations now, but then shifts to a discouraging tone.  I wonder if you mind changing the tone a little, maybe changing the idea of "not justified" to something more like "unable to accommodate".  Perhaps like this?:

NEW
  Designers who are using such
  port numbers are encouraged to apply for an assignment.  Every
  effort will be made to accommodate such requests, though even with
  widespread de-facto use, if the port number has already been
  assigned to another applicant such accommodation might not be
  possible.  Note also that the application must pass review by the
  IANA Ports Expert Review team, as must any port application.
END

-- Section 8 --

  The port number alone should not be used
  to avoid denial of service or firewall traffic because their use is
  not regulated or validated.

To "avoid ... firewall traffic"?  What's that mean?

I think you mean "to avoid denial-of-service attacks or to manage firewall traffic", yes?  And then what is the "they" in "their use"?
2015-02-17
07 Barry Leiba [Ballot Position Update] Position for Barry Leiba has been changed to No Objection from Discuss
2015-02-17
07 Brian Haberman [Ballot comment]
I have many of the same questions as Barry.
2015-02-17
07 Brian Haberman Ballot comment text updated for Brian Haberman
2015-02-17
07 Barry Leiba
[Ballot discuss]
I have four things I'd like to discuss, three of which have to do with the fact that this document does not update …
[Ballot discuss]
I have four things I'd like to discuss, three of which have to do with the fact that this document does not update 6335, and, therefore, needs to stay in line with what 6335 says.  I don't think it'll be a big deal: let's talk, please.

POINT 1:

-- Section 5 --
  IANA aims to assign only one port number per service, including
  variants [RFC6335]

The "including variants" part is not correct; from 6335, Section 7.2:

      Note: At the time of writing of this document, there is no IETF
      consensus on when it is appropriate to use a second port for an
      insecure version of a protocol.

What is correct is what 6335 states:

NEW
  IANA aims to assign only one port number per service or
  application.
END

POINT 2:

-- Section 7.1 --
      o  Separate port numbers are not intended for insecure versions
        of existing (or new) secure services. A service that already
        requires security would be made more vulnerable by having the
        same capability accessible without security.

I understand that this is meant only in the secure -> insecure direction, and in that direction it's probably mostly right.  And, yet, it does seem to go against the statement that I quoted above from 6335, Section 7.2, which also goes in the same secure -> insecure direction:

      Note: At the time of writing of this document, there is no IETF
      consensus on when it is appropriate to use a second port for an
      insecure version of a protocol.

I'm not sure we can say this as strongly in a document that claims, multiple times, not to be changing 6335.  Perhaps this is a reasonable way to make this point?:

NEW
      o  Separate port numbers should not normally be used for
        insecure versions of existing (or new) secure services. A
        service that already requires security would be made more
        vulnerable by having the same capability accessible without
        security.
END

POINT 3:

-- Section 7.4 --
  >> New services SHOULD support security, either directly or via a
  secure transport such as TLS [RFC5246].

In this context, "security" is too vague a term: what, exactly, does "SHOULD support security" mean?  Are you talking about authentication?  Access/authorization controls?  Confidentiality?  Specifically, encrypted communication?  I think you mean the last.

It would be good to replace "security" in this and much of the subsequent paragraphs with some clearer specification of what you're addressing.

POINT 4:

-- Section 7.4 --
  >> When simultaneously requesting both a secure and an insecure
  port, strong justification MUST be provided for the insecure port.
  Precedent (citing other protocols that use an insecure port) is not
  strong justification by itself.  A strong case for utility of the
  insecure service is REQUIRED for approval of the insecure port.

This seems significantly stronger thaan what RFC 6335 said, and this point was hotly debated in the development of that document.  RFC 6335, Section 9, says this:

  Services are expected to include support for security, either as
  default or dynamically negotiated in-band.  The use of separate
  service name or port number assignments for secure and insecure
  variants of the same service is to be avoided in order to discourage
  the deployment of insecure services.

As this document does not update 6335, I don't see how the MUST and the REQUIRED are appropriate.  But perhaps I can be convinced by some discussion.
2015-02-17
07 Barry Leiba
[Ballot comment]
These are non-blocking, but please consider them -- many are meant to clarify the text, and I hope they succeed in that.

In …
[Ballot comment]
These are non-blocking, but please consider them -- many are meant to clarify the text, and I hope they succeed in that.

In three places:

-- Abstract --
  This document provides recommendations to application and service
  designers on how to use the transport protocol port number space.

-- Section 1 --
  It also provides specific
  recommendations to designers on how to use assigned port numbers.

-- Section 2 --
  In this document, the characters ">>" preceding an indented line(s)
  indicates a compliance requirement statement using the key words
  listed above.

First, recommendations on how to use *port number space* is not the same as recommendations on how to use *assigned port numbers*.  I interpret the former as recommendations about making requests for port numbers, and the latter as recommendations about use of the port numbers after they've been assigned.  These should be worded consistently.

Second, recommendations, whichever type of recommendations they be, are not the same as compliance requirements.  I read the former as suggestions, and the latter as, well, requirements.  If the document is giving requirements that cover port-number requests -- and it is, complete with MUSTs -- it needs to clearly say that up front, and get rid of the "recommendations" stuff (or say both, that there are both requirements and recommendations here).

-- Section 5 --

  Consider a user wanting to run a web server. That service could run
  on any port number, provided that all clients knew what port number
  to use to access that service at that host. Such information can be
  distributed out-of-band, e.g., in the URI:

      http://www.example.com:51509/

It's a fine point, but having the port number in the URI doesn't actually distribute it "out of band" (which doesn't need hyphens in this context).  I would say, "Such information can be explicitly distributed -- for example, by putting it in the URI:".

  IANA assigns port numbers so that Internet endpoints do not need
  pairwise, explicit coordination of the meaning of their port
  numbers. This is the primary reason for requesting assigned port
  numbers with IANA - to have a common agreement between all endpoints
  on the Internet as to the default meaning of a port number.

This only says half of it, and omits a very important piece, I think.  May I suggest this?:

NEW
  IANA assigns port numbers so that Internet endpoints do not need
  pairwise, explicit coordination of the meaning of their port
  numbers. This is the primary reason for requesting assigned port
  numbers with IANA - to have a common agreement between all endpoints
  on the Internet as to the default meaning of a port number, and to
  provide the endpoints with a default port number for a particular
  protocol or service.
END

  >> Each port requested MUST be justified as independently necessary.

This is a fair statement, and yet I worry that including "necessary" may result in arguments between protocol designers and port experts about what is and isn't "necessary", and what the community's consensus is on it.  I'm not sure how to minimize that.  I'd say "MUST be independently justified," which does get the point you want (the independent justification) without using the loaded word "necessary".  I'd prefer that wording, though I admit that it can just as easily result in the same arguments.

-- Section 6.1 --

      o  Copies of an existing service can be differentiated by using
        different IP addresses, either on different hosts or as
        different real or virtual interfaces (or even operating
        systems) on the same host.

As a guiding principle for protocol designers, this worries me: it's an operational point, not a point of protocol design.  I'd have no objection if this were explicitly cast as an operational suggestion.

      o  Services requiring varying performance properties can already
        be supported using separate endpoint associations (connections
        or other associations), each configured to support the desired
        properties.

I can't figure out what you mean here.  Do you have an example, or can you tweak the explanation?

-- Section 7 --

  7. How to Use Assigned Port Numbers

  Port numbers are assigned by IANA by a set of documented procedures
  [RFC6335]. The following section describes the steps users can take
  to help assist with the use of assigned port numbers, and with
  preparing an application for a port number assignment.

In both the title and the paragraph, you refer to the "use" of "assigned port numbers", and yet the entire section talks about getting port assignments, not about using the port numbers after they're assigned.  I suggest this instead:

NEW
  7. Considerations for Requesting Port Number Assignments

  Port numbers are assigned by IANA by a set of documented procedures
  [RFC6335]. The following section describes the steps designers can
  take to help assist with the responsible assignment of port numbers,
  and with preparing an application for a port number assignment.
END

-- Section 7.1 --

      o  Port numbers are not intended for indicating different service
        versions. Version differentiation should be handled in-band,
        e.g., using a version number at the beginning of an
        association (e.g., connection or other transaction). This may
        not be possible with legacy assignments, but all new
        assignments should incorporate support for version indication.

Is this meant to say "but all new protocols should incorporate support for version indication."?  It's not the assignment that does that.

  Some users may not need assigned port numbers at all

Is this meant to say "some uses may not" (or "some protocols", but not "some users")?

-- Section 7.2 --

  There are a
  variety of known ways to reduce port number use. Although some may
  be cumbersome or inefficient, they are always preferable to
  consuming additional port numbers.

1. I think "reduce port number consumption" might be a better way to say what you mean here.

2. I don't think "always preferable" is consistent with the consensus on RFC 6335.  I would accept "usually preferable", but not something as strong as "always".

  Although
  automatic configuration protocols have been proposed and developed
  (e.g., STUN [RFC5389], TURN [RFC5766], and ICE [RFC5245]),
  application and service designers cannot yet rely on their presence.

I wouldn't call STUN, TURN, and ICE "automatic configuration protocols".  I'd refer to them as "NAT traversal protocols".

-- Section 7.3 --

  Would a TCP (or other transport
  protocol) port number assignment be useful by itself?  If so, a TCP
  (UDP) port number can be assigned whose port number is already (or
  can be subsequently) assigned to a different transport protocol.

I'm not sure what you're getting at here.  Are you saying that if you need a TCP port, you might pick one where the UDP port of the same number is (or can be) used for something else, and vice versa?  If so, I don't think it says that at all clearly.  In any case, can you please rephrase this to make it clearer?

  >> Developers SHOULD NOT apply for System port numbers because the
  increased privilege they are intended to provide is not always
  enforced.

Hm.  This sounds odd to me: it seems that it's setting up a feedback loop that's self sustaining.  You might want a system port number to get protection against running on that port by non-root.  But you won't always get that protection.  So you shouldn't ask.  So no one asks, and so no one gets the protection even when it's available.

Do you think this works as well for you?:

NEW
  >> Developers SHOULD request User port numbers, to avoid using
  the more limited System port number space.  Consider that the
  increased protection that System ports are intended to provide
  is not always enforced.
END

I would also move that paragraph down one, so that it's after the "Even when developers" paragraph.

-- Section 7.4 --

  >> Security SHOULD NOT rely on port number distinctions alone; every
  service, whether secure or not, is likely to be attacked.

I find this underspecified.  I don't know what I should be doing about this.  As in the DISCUSS, "security" is a vague term, and I don't know how to determine whether I've met this requirement, nor how to assess whether my situation is suitable one for not following it.

  Optional security can penalize performance, requiring additional
  round-trip exchanges before a connection or other association can be
  established. As discussed earlier, port numbers are a critical
  resource and it is inappropriate to consume assignments to increase
  performance. As a result, the need for separate ports for both
  secure and insecure variants is not justified merely for performance

Where was this discussed earlier?  The only thing I see related to performance that was discussed earlier is that it's not appropriate to have different ports to support different performance levels.  That's not the same thing that you're talking about here.  I agree with the conclusion (in the final sentence I quote).

  - either for the connection or association establishment performance
  or differences in data performance between secure and insecure
  variants.

I can't parse this.  Are there words missing or some such?

  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 applications requesting assignment for both
  an insecure port number for a secure service might not be
  appropriate.

I'm having trouble with this one also; I can't parse what comes after the comma.  Maybe split the sentence into two, and rephrase?

-- Section 7.5 --
How can this apply retroactively to current assignments?  And "the multiple versions" should probably lose the "the".

-- Section 7.6 --
Spencer has been picking on the use of 793 as a reference for TCP.  Spencer, is 793 an acceptable reference for TCP here?

It would probably be better to attach the references to their protocols, rather than to have them in a group at the end of the list.

  Originally, IANA port number assignments were concurrent for both
  UDP and TCP; other transports were not indicated.

Total nit: I think this sentence doesn't work well with a semicolon, and would prefer changing the ";" to ", and".

  When the services differ, their service names and descriptions
  should reflect that difference.

I had a little trouble with this and the discussion leading up to it, which I think can be fixed by saying explicitly that in this case, it's OK (perhaps even encouraged) to use the same port, but different service names.  Perhaps something like this?:

NEW
  When the services differ, it may be acceptable or preferable
  to use the same port number, but the service names and
  descriptions should be different, reflecting the differences
  in the services.
END

  The following convention has been used by IANA
  for several years to distinguish discovery services, such as are
  used to identify endpoints capable of a given service:

  >> Names of discovery services SHOULD use an identifiable suffix;
  the suggestion is "-disc".

It reads oddly to have "the following convention" point to a normative requirement, and not just to the convention.  Again, a nit, but I think it would read better like this:

NEW
  IANA has, for several years, used the suffix "-disc" in service
  names to distinguish discovery services, such as are used to
  identify endpoints capable of a given service.

  >> Names of discovery services SHOULD use an identifiable suffix;
  the suggestion is "-disc".
END

  because IP routers do not forward "all nodes" (all 1's, i.e.,
  255.255.255.255 for IPv4) broadcasts and have not been required

The phrase << "all nodes" broadcasts >> needs to stay together, and splitting it with the explanation made me trip over it.  I suggest moving the word "broadcasts" before the parenthesized bit.

  >> Services SHOULD NOT use UDP as a performance enhancement over
  TCP, i.e., to circumnavigate TCP's congestion control.

Is circumventing congestion control the only possible performance enhancement here?  This sentence really makes one ask whether "i.e." is correct, or you mean "e.g.", and I think it'd be better done one of these ways:

If you mean to say that congestion control is the only reason:
NEW
  >> Services SHOULD NOT use UDP to enhance performance by
  circumventing TCP's congestion control.
END

If there might be other performance-enhancement reasons:
NEW
  >> Services SHOULD NOT use UDP as a performance enhancement over
  TCP.  For example, do not use UDP to circumvent TCP's congestion
  control.
END

(The right word is "circumvent", not "circumnavigate".)

-- Section 7.7 --

  Applications made through Internet Draft / RFC publication (in any
  stream)
...
  When a document has been approved for
  publication and proceeds to IESG Approval

The first sentence tries to make this stream-independent, but the "IESG Approval" later in the paragraph is specific to the IETF stream.  Because you already say "approved for publication", you can just omit the "and proceeds to IESG Approval" phrase.

-- Section 7.8 --

  Such "squatted" port numbers remain unassigned, and IANA retains the
  right to assign them when requested by applicants.

It might be good to be completely clear and say "requested by other applicants," lest readers think you mean to be talking about when the squatters make an application later.

The last paragraph in this section starts by encouraging squatters to make registrations now, but then shifts to a discouraging tone.  I wonder if you mind changing the tone a little, maybe changing the idea of "not justified" to something more like "unable to accommodate".  Perhaps like this?:

NEW
  Designers who are using such
  port numbers are encouraged to apply for an assignment.  Every
  effort will be made to accommodate such requests, though even with
  widespread de-facto use, if the port number has already been
  assigned to another applicant such accommodation might not be
  possible.  Note also that the application must pass review by the
  IANA Ports Expert Review team, as must any port application.
END

-- Section 8 --

  The port number alone should not be used
  to avoid denial of service or firewall traffic because their use is
  not regulated or validated.

To "avoid ... firewall traffic"?  What's that mean?

I think you mean "to avoid denial-of-service attacks or to manage firewall traffic", yes?  And then what is the "they" in "their use"?
2015-02-17
07 Barry Leiba [Ballot Position Update] New position, Discuss, has been recorded for Barry Leiba
2015-02-16
07 Joel Jaeggli
[Ballot comment]
  At some future date, it might be useful to deprecate the distinction
  between System and User port numbers altogether. Services typically …
[Ballot comment]
  At some future date, it might be useful to deprecate the distinction
  between System and User port numbers altogether. Services typically
  require elevated ('root') privileges to bind to a System port
  number, but many such services go to great lengths to immediately
  drop those privileges just after connection or other association
  establishment to reduce the impact of an attack using their
  capabilities. Such services might be more securely operated on User
  port numbers than on System port numbers.

operationaly we already have dropped the distinction. there is not practical distiction for a new service allocated out of the remaining 180 system ports and one allocated out of the user ports so we might as well treat the port space as flat.
2015-02-16
07 Joel Jaeggli [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli
2015-02-12
07 Jean Mahoney Request for Telechat review by GENART is assigned to Dan Romascanu
2015-02-12
07 Jean Mahoney Request for Telechat review by GENART is assigned to Dan Romascanu
2015-02-11
07 Spencer Dawkins IESG state changed to IESG Evaluation from Waiting for Writeup
2015-02-11
07 Spencer Dawkins Ballot writeup was changed
2015-02-05
07 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Dan Harkins.
2015-01-27
07 (System) IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2015-01-27
07 Spencer Dawkins Telechat date has been changed to 2015-02-19 from 2015-02-05
2015-01-27
07 Spencer Dawkins Placed on agenda for telechat - 2015-02-05
2015-01-27
07 Spencer Dawkins Changed consensus to Yes from Unknown
2015-01-27
07 Spencer Dawkins Ballot has been issued
2015-01-27
07 Spencer Dawkins [Ballot Position Update] New position, Yes, has been recorded for Spencer Dawkins
2015-01-27
07 Spencer Dawkins Created "Approve" ballot
2015-01-27
07 Spencer Dawkins Ballot writeup was changed
2015-01-23
07 Joseph Touch IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2015-01-23
07 Joseph Touch New version available: draft-ietf-tsvwg-port-use-07.txt
2015-01-19
06 Gorry Fairhurst
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.
Changes are expected over time. This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.
Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)? Why is this the
proper type of RFC? Is this type of RFC indicated in the title page
header?

BCP

The document provides guidance to protocol and application designers on
best current practices for requesting and using ports; BCP status clearly
conveys the nature, importance and relevance of that guidance.

Some  reviewers have noted that this application of BCP status
may not be aligned with their understanding of BCP status (RFC 2026,
Section 5) and/or with current IETF usage of BCP status in practice.

Since this is intended to document best practice and design recommendations
for areas beyond TSV, the IESG should consider whether BCP status is
appropriate (e.g.,  vs. Informational status).

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:
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.

Document Quality:
During document review the intended status was carefully considered. This
resulted in changes, omission of some material
and greater attention to the recommendations. This document is now thought
ready for publication by TSVWG.

Personnel:
Who is the Document Shepherd?
G Fairhurst (TSVWG Co-Chair)

Who is the Responsible Area Director?
Spencer Dawkins (TSV AD)

(3) Briefly describe the review of this document that was performed by the
Document Shepherd. If this version of the document is not ready for
publication, please explain why the document is being forwarded to the
IESG.

The document shepherd reviewed this document, and the recommendations that
it makes. The shepherd,
and TSVWG reviewers think this is ready to be published. The document does
impact other IETF Areas
and was therefore subject to cross-area review during the initial WGLC. I
am happy that the comments
received during this process have adequately been addressed in the current
draft.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
No

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that took
place.

Yes - The material on allocation of secure and non-secure ports, the
discussion of firewall interactions, and other matters,
means that this draft contains significantly more security material than
is typical for TSVWG drafts.
The chairs therefore recommend a security directorate review.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the IESG
should be aware of? For example, perhaps he or she is uncomfortable with
certain parts of the document, or has concerns whether there really is a
need for it. In any event, if the WG has discussed those issues and has
indicated that it still wishes to advance the document, detail those
concerns here.
No

(7) Has each author confirmed that any and all appropriate IPR disclosures
required for full conformance with the provisions of BCP 78 and BCP 79
have already been filed. If not, explain why?
Confirmed.

(8) Has an IPR disclosure been filed that references this document? If so,
summarize any WG discussion and conclusion regarding the IPR disclosures.
None are known

(9) How solid is the WG consensus behind this document? Does it represent
the strong concurrence of a few individuals, with others being silent, or
does the WG as a whole understand and agree with it?

The document has been presented and discussed at IETF TSVWG meetings since
IEWTF-80.
Production of a document on this topic had the strong support of TSVWG
when adopted after IETF-86, March 2013.

The ID completed a first WGLC completing in June 2014 including cross-area
review requests to RAI, APPS, and SEC Areas, and comments
received from people within an outside TSVWG. Comments were also received
from IANA.
This resulted in changes to the style of presentation and to the
recommendations, including ensuring that
the relationship to RFC 6335 was made more clear.

To confirm these changes the document subsequently had a second TSVWG WGLC
(14/10/2014, concluding 29/10/2014)
The second stage reviewers were D Black, G Fairhurst and E Lear. There
were no additional comments.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)
No

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

Some references are marked by the tool as Obsolete, the document editor
and shepherd have reviewed these and checked these are correct.
As context, all obsolete references are cited in the section that
describes the history of ports. In many cases, the earliest occurrence
of an idea is cited in preference to later (in some cases obsoleting) RFCs.

(12) Describe how the document meets any required formal review criteria,
such as the MIB Doctor, media type, and URI type reviews.
None

(13) Have all references within this document been identified as either
normative or informative?
Yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?
OK

(15) Are there downward normative references references (see RFC 3967)? If
so, list these downward references to support the Area Director in the
Last Call procedure.
No

(16) Will publication of this document change the status of any existing
RFCs? Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction? If the RFCs are not listed in
the Abstract and Introduction, explain why, and point to the part of the
document where the relationship of this document to the other RFCs is
discussed. If this information is not in the document, explain why the WG
considers it unnecessary.
No

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes are
associated with the appropriate reservations in IANA registries. Confirm
that any referenced IANA registries have been clearly identified. Confirm
that newly created IANA registries include a detailed specification of the
initial contents for the registry, that allocations procedures for future
registrations are defined, and a reasonable name for the new registry has
been suggested (see RFC 5226).

This document requires no actions from IANA

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful
in selecting the IANA Experts for these new registries.
None

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.
None
2014-12-28
06 Gunter Van de Velde Request for Last Call review by OPSDIR Completed: Has Nits. Reviewer: Tim Wicinski.
2014-12-22
06 (System) IESG state changed to Waiting for Writeup from In Last Call
2014-12-19
06 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2014-12-19
06 Pearl Liang
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-tsvwg-port-use-06, which is currently in Last Call, and has the following comments:

IANA has one comment about the text …
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-tsvwg-port-use-06, which is currently in Last Call, and has the following comments:

IANA has one comment about the text in the IANA Considerations section of
this document.

We understand that, upon approval of this document, there are no IANA Actions that need completion.

While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object.

Comment:  The following text is described in the IC section.  We would like to edit
the text as follows:

CURRENT:

> 9. IANA Considerations
>
> The entirety of this document focuses on IANA issues, notably
> suggestions that help ensure the conservation of port numbers and
> provide useful hints for issuing informative requests thereof.


NEW:
> 9. IANA Considerations
>
> The entirety of this document focuses on
> suggestions that help ensure the conservation of port numbers and
> provide useful hints for issuing informative requests thereof.

Reasoning: Removed "IANA issues" here as the document really is focusing on
the use of port numbers and not really issues related to IANA. IANA does get
the benefit from users doing the right thing when it comes to port use as it
helps with the process for applying for port numbers.

If this assessment is not accurate, please respond as soon as possible.
2014-12-15
06 Dan Romascanu Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Dan Romascanu.
2014-12-15
06 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Tim Wicinski
2014-12-15
06 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Tim Wicinski
2014-12-11
06 Jean Mahoney Request for Last Call review by GENART is assigned to Dan Romascanu
2014-12-11
06 Jean Mahoney Request for Last Call review by GENART is assigned to Dan Romascanu
2014-12-11
06 Tero Kivinen Request for Last Call review by SECDIR is assigned to Dan Harkins
2014-12-11
06 Tero Kivinen Request for Last Call review by SECDIR is assigned to Dan Harkins
2014-12-08
06 Cindy Morgan IANA Review state changed to IANA - Review Needed
2014-12-08
06 Cindy Morgan
The following Last Call announcement was sent out:<br><br>From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: <tsvwg@ietf.org>
Reply-To: ietf@ietf.org
Sender: …
The following Last Call announcement was sent out:<br><br>From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: <tsvwg@ietf.org>
Reply-To: ietf@ietf.org
Sender: <iesg-secretary@ietf.org>
Subject: Last Call: <draft-ietf-tsvwg-port-use-06.txt> (Recommendations for Transport Port Number Uses) to Best Current Practice


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
ietf@ietf.org mailing lists by 2014-12-22. Exceptionally, comments may be
sent to iesg@ietf.org 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.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-tsvwg-port-use/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-tsvwg-port-use/ballot/


No IPR declarations have been submitted directly on this I-D.


2014-12-08
06 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2014-12-08
06 Spencer Dawkins Last call was requested
2014-12-08
06 Spencer Dawkins Last call announcement was generated
2014-12-08
06 Spencer Dawkins Ballot approval text was generated
2014-12-08
06 Spencer Dawkins Ballot writeup was generated
2014-12-08
06 Spencer Dawkins IESG state changed to Last Call Requested from AD Evaluation
2014-12-08
06 Spencer Dawkins IESG state changed to AD Evaluation from Publication Requested
2014-11-19
06 David Black IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2014-11-12
06 Cindy Morgan IESG state changed to Publication Requested from Dead
2014-11-12
06 Cindy Morgan
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.
Changes are expected over time. This version is dated …
As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.
Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet
Standard, Informational, Experimental, or Historic)? Why is this the
proper type of RFC? Is this type of RFC indicated in the title page
header?

BCP.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:
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.

Document Quality:
During document review the intended status was carefully considered. This
resulted in changes, omission of some material
and greater attention to the recommendations. This document is now thought
ready for publication by TSVWG.

Personnel:
Who is the Document Shepherd?
G Fairhurst (TSVWG Co-Chair)

Who is the Responsible Area Director?
Spencer Dawkins (TSV AD)

(3) Briefly describe the review of this document that was performed by the
Document Shepherd. If this version of the document is not ready for
publication, please explain why the document is being forwarded to the
IESG.

The document shepherd reviewed this document, and the recommendations that
it makes. The shepherd,
and TSVWG reviewers think this is ready to be published. The document does
impact other IETF Areas
and was therefore subject to cross-area review during the initial WGLC. I
am happy that the comments
received during this process have adequately been addressed in the current
draft.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
No

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that took
place.

Yes - The material on allocation of secure and non-secure ports, the
discussion of firewall interactions, and other matters,
means that this draft contains significantly more security material than
is typical for TSVWG drafts.
The chairs therefore recommend a security directorate review.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the IESG
should be aware of? For example, perhaps he or she is uncomfortable with
certain parts of the document, or has concerns whether there really is a
need for it. In any event, if the WG has discussed those issues and has
indicated that it still wishes to advance the document, detail those
concerns here.
No

(7) Has each author confirmed that any and all appropriate IPR disclosures
required for full conformance with the provisions of BCP 78 and BCP 79
have already been filed. If not, explain why?
Confirmed.

(8) Has an IPR disclosure been filed that references this document? If so,
summarize any WG discussion and conclusion regarding the IPR disclosures.
None are known

(9) How solid is the WG consensus behind this document? Does it represent
the strong concurrence of a few individuals, with others being silent, or
does the WG as a whole understand and agree with it?

The document has been presented and discussed at IETF TSVWG meetings since
IEWTF-80.
Production of a document on this topic had the strong support of TSVWG
when adopted after IETF-86, March 2013.

The ID completed a first WGLC completing in June 2014 including cross-area
review requests to RAI, APPS, and SEC Areas, and comments
received from people within an outside TSVWG. Comments were also received
from IANA.
This resulted in changes to the style of presentation and to the
recommendations, including ensuring that
the relationship to RFC 6335 was made more clear.

To confirm these changes the document subsequently had a second TSVWG WGLC
(14/10/2014, concluding 29/10/2014)
The second stage reviewers were D Black, G Fairhurst and E Lear. There
were no additional comments.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)
No

(11) Identify any ID nits the Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

Some references are marked by the tool as Obsolete, the document editor
and shepherd have reviewed these and checked these are correct.
As context, all obsolete references are cited in the section that
describes the history of ports. In many cases, the earliest occurrence
of an idea is cited in preference to later (in some cases obsoleting) RFCs.

(12) Describe how the document meets any required formal review criteria,
such as the MIB Doctor, media type, and URI type reviews.
None

(13) Have all references within this document been identified as either
normative or informative?
Yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?
OK

(15) Are there downward normative references references (see RFC 3967)? If
so, list these downward references to support the Area Director in the
Last Call procedure.
No

(16) Will publication of this document change the status of any existing
RFCs? Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction? If the RFCs are not listed in
the Abstract and Introduction, explain why, and point to the part of the
document where the relationship of this document to the other RFCs is
discussed. If this information is not in the document, explain why the WG
considers it unnecessary.
No

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes are
associated with the appropriate reservations in IANA registries. Confirm
that any referenced IANA registries have been clearly identified. Confirm
that newly created IANA registries include a detailed specification of the
initial contents for the registry, that allocations procedures for future
registrations are defined, and a reasonable name for the new registry has
been suggested (see RFC 5226).

This document requires no actions from IANA

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find useful
in selecting the IANA Experts for these new registries.
None

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.
None
2014-11-12
06 David Black Tag Revised I-D Needed - Issue raised by WGLC cleared.
2014-11-12
06 David Black IETF WG state changed to WG Consensus: Waiting for Write-Up from Waiting for WG Chair Go-Ahead
2014-11-11
06 Joseph Touch New version available: draft-ietf-tsvwg-port-use-06.txt
2014-11-11
05 David Black Tag Revised I-D Needed - Issue raised by WGLC set.
2014-11-11
05 David Black IETF WG state changed to Waiting for WG Chair Go-Ahead from WG Document
2014-09-17
05 Joseph Touch New version available: draft-ietf-tsvwg-port-use-05.txt
2014-05-14
04 Joseph Touch New version available: draft-ietf-tsvwg-port-use-04.txt
2014-05-08
03 (System) Document has expired
2014-05-08
03 (System) IESG state changed to Dead from AD is watching
2014-03-05
03 Gorry Fairhurst Document shepherd changed to Gorry Fairhurst
2013-11-04
03 Joseph Touch New version available: draft-ietf-tsvwg-port-use-03.txt
2013-07-15
02 Joseph Touch New version available: draft-ietf-tsvwg-port-use-02.txt
2013-05-20
01 Cindy Morgan Shepherding AD changed to Spencer Dawkins
2013-03-06
01 Martin Stiemerling State changed to AD is watching from Dead
2013-02-25
01 Joseph Touch New version available: draft-ietf-tsvwg-port-use-01.txt
2012-12-02
00 (System) Document has expired
2012-12-02
00 (System) State changed to Dead from AD is watching
2012-07-23
00 Martin Stiemerling Intended Status changed to Best Current Practice
2012-07-23
00 Martin Stiemerling IESG process started in state AD is watching
2012-05-31
00 Joseph Touch New version available: draft-ietf-tsvwg-port-use-00.txt