Subject: [port-srv-reg] Fwd: Re: [DNSOP] New version of document for review

From: Magnus Westerlund <[email-masked]>
Date: Thu, 28 Oct 2010 14:52:07 +0200

Hi,

I am clearing backlog i my TSVWG mail folder. I found these review
comments. My question to the rest of the people. Has anyone addressed them?

No one appears to have responded to it, which make me think we can have
missed them.

Cheers

Magnus

-------- Ursprungligt meddelande --------
Ämne: Re: [DNSOP] New version of document for review
Datum: Mon, 1 Mar 2010 03:38:12 +0100
Från: Doug Barton <[email-masked]>
Till: Michelle Cotton <[email-masked]>
Kopia: [email-masked] <[email-masked]>, [email-masked]
<[email-masked]>,	[email-masked] <[email-masked]>

On 01/15/10 08:16, Michelle Cotton wrote:
> Attn: TSVWG Working Group, DNSOPS Working Group and APPS AREA Working Group
> 
> There is a new version of the Internet Assigned Numbers Authority (IANA)
> Procedures for the Management
> of the Transport Protocol Port Number and Service Name Registry document:
> 
> draft-ietf-tsvwg-iana-ports-04.txt
> 
> Please review and send comments.  Your feedback is much appreciated.

I'm writing to provide both review and support of this draft. Before I
do however it's probably useful for me to make some explicit statements,
some of the "should go without saying" variety and some to provide
context for my comments.

I was the General Manager of the IANA from late 2003 through mid 2005.
In that capacity I was proud to manage Michelle as one of my employees.
One of my responsibilities was to oversee the port number allocation
process, including occasionally making the final decisions on these
assignments myself. Other than her public messages regarding these
drafts I have had no communication from Michelle or anyone else from
ICANN regarding this topic. Other than this message today I've not
communicated with them about it. (IOW, ETINC.) I also have experience
with port numbers from the operating system implementer's perspective as
part of a large group of people who have "commit privileges" to the
FreeBSD code base.

With all that out of the way, I would like to commend Michelle and the
other authors on this much needed piece of work. It is clear, well
written, and covers the topic very well. I know that I would very much
like to have had such a clear set of guidelines to operate under while I
was making these decisions. I do have some feedback, none of which I
consider to be show-stopper issues. If the draft were to progress in its
current condition I would be supportive.

I also think it is important to move this draft forward sooner rather
than later since it will allow us to start using, and encouraging the
use of SRV in a much more meaningful way.

I've attached a diff with some mostly minor edits. Most of them are
simple English language nits such as:
1. Comma reduction (a topic which I'm very sensitive to since it's one
of my major faults when writing)
2. Capitalizing the first letter of bullet points

I've also included some textual changes which I hope improve and/or
clarify the text. In all cases the authors are free to adopt or deny my
suggestions as they see fit.

More substantive issues, in more or less increasing order of importance.
* In Section 3 I think the readability would improve by switching the
first and second paragraphs.
* In Section 7.2, paragraph 7, I think the change to "IANA converting
the reservation" makes the desired outcome (that designers not use the
port without IANA authorizing the change) more clear.
* In Section 8.1 (and/or perhaps elsewhere?) I think it would be useful
to suggest (perhaps at the SHOULD level?) that when appropriate the
administrative contact e-mail address should be a role account, and the
problem this is designed to mitigate (individuals sometimes leave the
company/organization that is responsible for the assignment resulting in
a dead e-mail address).
* In Section 6 (and elsewhere) there does not appear to be a normative
reference for the division of port numbers into the Well Known,
Registered, and Dynamic categories.
* Section 7.2 mentions several suggestions to designers for reducing the
number of port numbers that they need for an application. I think it
would be useful to add 2 explicit suggestions to that list, one is the
idea of a "master" application with one Registered port number that can
coordinate communications between the various components of more
complicated applications without requiring each element of the
application to have its own assigned port number. The other suggestion I
think should be made explicitly in the document is the use of multicast
DNS to avoid port number assignments altogether.

My final area of concern is the idea people have that without an
assigned port number from IANA that no firewall administrators will
allow their traffic. You mention this issue briefly in 7.2, and in
Section 9 (Security Considerations) you include the text that I wrote in
number 2 of "PLEASE NOTE THE FOLLOWING" on the
http://www.iana.org/assignments/port-numbers page, both of which I think
are good things to include. However I believe that it would be useful to
have the whole concept described in more detail in 7.2. In my
communication with port number applicants this issue came up over and
over again, and was either the primary or sole consideration in filing
the application in the first place; resulting in more than one
otherwise-spurious application. I won't quibble if my opinion on the
importance of this topic isn't shared by others, but I felt it was
important to mention it.

I hope that these comments are helpful, and I apologize for not offering
them sooner.

Best regards,

Doug

--- draft-ietf-tsvwg-iana-ports-04.txt-orig	2010-02-28 13:22:59.000000000 -0800
+++ draft-ietf-tsvwg-iana-ports-04.txt	2010-02-28 17:44:08.000000000 -0800
@@ -209,7 +209,7 @@
    This document updates IANA's procedures for UDP and TCP port numbers
    by obsoleting Sections 8 and 9.1 of the IANA allocation guidelines
    [RFC2780].  (Note that different sections of the IANA allocation
-   guidelines, relating to the protocol field values in IPv4 header,
+   guidelines, relating to the protocol field values in IPv4 headers,
    were also updated in February 2008 [RFC5237].)  This document also
    updates the IANA allocation procedures for DCCP [RFC4340] and SCTP
    [RFC4960].
@@ -225,11 +225,11 @@

    uses the same set of port number values assigned by the IANA for use
-   by UDP".  Thus the update of UDP procedures result in an update also
-   of the UDP-Lite procedures.
+   by UDP".  Thus the update of UDP procedures also results in a
+   corresponding update of the UDP-Lite procedures.
 
-   This document also clarify what a service name is and how it is
-   registered.  This will impact the DNS SRV specification, because that
+   This document also clarifies what a service name is and how it is
+   registered.  This will impact the DNS SRV specification because that
    specification merely makes a brief mention that the symbolic names of
    services are defined in "Assigned Numbers" [RFC1700], without stating
    to which section of that 230-page document it refers.  The DNS SRV
@@ -254,7 +254,7 @@
 
    Similarly, the procedures surrounding service names have been
    historically unclear.  Service names were originally created as
-   mnemonic identifiers for port numbers without a well-defined syntax,
+   mnemonic identifiers for port numbers without a well-defined syntax
    beyond the 14-character limit mentioned on the IANA website [SYSFORM]
    [USRFORM].  Even that length limit has not been consistently applied,
    and some assigned service names are 15 characters long.  When service
@@ -268,8 +268,8 @@
    for both port numbers and service names.  It gives more detailed
    guidance to prospective requesters of ports and service names than
    the existing documentation, and it streamlines the IANA procedures
-   for the management of the registry, so that management requests can
-   complete in a timely manner.
+   for the management of the registry so that management requests can
+   be completed in a timely manner.
 
    This document defines rules for registration of service names without
 
@@ -292,7 +292,7 @@
    that guide the IETF and IANA in their role as the long-term joint
    stewards of the port number registry.  TCP and UDP have been a
    remarkable success over the last decades.  Thousands of applications
-   and application-level protocols have registered ports and service
+   and application-level protocols have registered port numbers and service
    names for their use, and there is every reason to believe that this
    trend will continue into the future.  It is hence extremely important
    that management of the registry follow principles that ensure its
@@ -321,7 +321,7 @@
    application and service identification on the Internet.  Ports are
    16-bit numbers, and the combination of source and destination port
    numbers together with the IP addresses of the communicating end
-   systems uniquely identifies a session of a given transport protocol.
+   systems uniquely identify a session of a given transport protocol.
    Port numbers are also known by their corresponding service names such
    as "telnet" for port number 23 and "http" (and the "www" alias) for
    port number 80.
@@ -366,11 +366,12 @@
    to IANA for an assigned port number and service name for a specific
    application, and may - after successful registration - assume that no
    other application will use that port number or service name for its
-   communication sessions.  Alternatively, application designers may
-   also ask for only an assigned service name, if their application does
-   not require a fixed port number.  The latter alternative is
-   encouraged when possible, in order to conserve the more limited port
-   number space.  This includes, for example, applications that use DNS
+   communication sessions.  Application designers also have the option
+   of requesting an assigned service name without a corresponding fixed
+   port number if their application does not require one.  Because the
+   number of fixed port numbers is finite (and therefore conservation
+   is an important goal) the latter alternative is encouraged whenever possible.
+   This includes, for example, applications that use DNS
    SRV records to look up port numbers at runtime.

@@ -394,12 +395,12 @@
 
    registry.  This unique symbolic name for a service may also be used
    for other purposes, such as in DNS SRV records [RFC2782].  Within the
-   registry, this unique key ensures that different services can be
+   registry this unique key ensures that different services can be
    unambiguously distinguished, thus preventing name collisions and
    avoiding confusion about who is the administrative contact for a
    particular entry.
 
-   For each service name, there may exist zero or more associated port
+   For each service name there may exist zero or more associated port
    number assignments.  A port number assignment associated with a
    service name contains the transport protocol, port number and
    possibly additional data, such as a DCCP service code.
@@ -407,7 +408,7 @@
    There may be more than one service name associated with a particular
    transport protocol and port.  This SHOULD only occur when all such
    service names are aliases for the same service, such as with "http"
-   and "www".  In such cases, one of the service names MUST be
+   and "www".  In such cases one of the service names MUST be
    designated primary, for use with mechanisms such as DNS SRV Records
    [RFC2782], and the others MUST be designated as aliases of the
    primary service name.  This is necessary so that all clients and
@@ -485,7 +486,7 @@
 
    The details of how applications make use of DNS SRV should be
    specified in the documentation set of the application/service.  In
-   the absense of such specification, prospective clients of a given
+   the absence of such specification, prospective clients of a given
    service should not assume the existence of SRV RRs for this service
    or, if they have indications that this will be the case (e.g., by
    configuration), must assume the unextended naming scheme from
@@ -507,17 +508,17 @@
 6.  Port Number Ranges
 
    TCP, UDP, UDP-Lite, SCTP and DCCP use 16-bit namespaces for their
-   port number registries.  The port registries for all these transport
+   port number registries.  The port registries for all of these transport
    protocols are subdivided into three ranges of numbers, and
    Section 7.3 describes the IANA procedures for each range in detail:
 
-   o  the Well Known Ports, also known as the System Ports, from 0-1023
+   o  The Well Known Ports, also known as the System Ports, from 0-1023
       (assigned by IANA)
 
-   o  the Registered Ports, also known as the User Ports, from 1024-
+   o  The Registered Ports, also known as the User Ports, from 1024-
       49151 (assigned by IANA)
 
-   o  the Dynamic Ports, also known as the Private Ports, from 49152-
+   o  The Dynamic Ports, also known as the Private or Ephemeral Ports, from 49152-
       65535 (never assigned)
 
    Of the assignable port ranges (Well Known and Registered, i.e., port
@@ -537,7 +538,7 @@
       e.g., 0, 1023, 1024, etc., which may be used to extend these
       ranges or the overall port number space in the future.
 
-   In order to keep the size of the registry manageable, IANA typically
+   In order to keep the size of the registry manageable IANA typically
    only records the Assigned and Reserved port numbers and service names
    in the registry.  Unassigned values are typically not explicitly
    listed.
@@ -571,7 +572,7 @@
    for experimentation with new application-layer protocols over SCTP
    and DCCP in Section 10.2.
 
-   Unfortunately, it can be difficult to limit access to these ports.
+   Unfortunately it can be difficult to limit access to these ports.
    Users SHOULD take measures to ensure that experimental ports are
    connecting to the intended process.  For example, users of these
    experimental ports might include a 64-bit nonce, once on each segment
@@ -589,22 +590,22 @@
    well as coordination of information about existing allocations.  The
    latter includes maintaining contact and description information about
    assignments, revoking abandoned assignments, and redefining
-   assignments when needed.  Of these procedures, port number allocation
-   is most critical, in order to continue to conserve the remaining port
+   assignments when needed.  Of these procedures port number allocation
+   is the most critical in order to continue to conserve the remaining port
    numbers.
 
-   As noted earlier, only ~9% of the Registered Port space is currently
+   As noted earlier only ~9% of the Registered Port space is currently
    assigned.  The current rate of assignment is approximately 400 ports/
    year, and has remained linear for the past 8 years.  At that rate, if
    similar conservation continues, this resource will sustain another 85
    years of assignment - without the need to resort to reassignment of
    released values or revocation.  Note that the namespace available for
    service names is even larger, which allows for a simpler management
-   procedures.
+   procedure.
 
 7.1.  Past Principles
 
-   Before the publication of this document, the principles of port
+   Before the publication of this document the principles of port
    number and service name management followed a few mostly-undocumented
    guidelines.  They are recorded here for historical purposes, and this
    document updates them in Section 7.2.  These principles were:
@@ -639,20 +640,21 @@
 
 7.2.  Updated Principles
 
-   This section summarizes the basic principles by which IANA handles
+   This section summarizes the basic principles by which IANA both handles
    the Port and Service Name registry, and attempts to conserve the port
    number space.  This description is intended to inform applicants
-   requesting service names and port numbers.  IANA decisions are not
-   required to be bound to these principles, however; other factors may
-   come into play, and exceptions may occur where deemed in the best
-   interest of the Internet.
+   requesting service names and port numbers.  
+   However other factors may
+   come into play, and exceptions may occur when deemed in the best
+   interest of the Internet. Thus applicants should be aware that
+   IANA decisions are not required to be bound to these principles,
 
    IANA will begin assigning service names that do not request a
    corresponding port number allocation under a simple "First Come,
    First Served" policy [RFC5226].  IANA MAY, at its discretion, refer
    service name requests to "Expert Review" in cases of mass
    registrations or other situations where IANA believes expert review
-   is advisable.
+   is advisable [RFC5226].
 
    The basic principle of port number registry management is to conserve
    use of the port space where possible.  Extensions to support larger
@@ -694,8 +696,8 @@
       de-registration, revocation, and transfer
 
    A given service is expected to further demultiplex messages where
-   possible.  For example, applications and protocols are expected to
-   include in-band version information, so that future versions of the
+   possible.  For example applications and protocols are expected to
+   include in-band version information so that future versions of the
    application or protocol can share the same allocated port.
    Applications and protocols are also expected to be able to
    efficiently use a single allocated port for multiple sessions, either
@@ -705,11 +707,11 @@
 
    Ports are used in various ways, notably:
 
-   o  as endpoint process identifiers
+   o  As endpoint process identifiers
 
-   o  as application protocol identifiers
+   o  As application protocol identifiers
 
-   o  for firewall filtering purposes
+   o  For firewall filtering purposes
 
    The process and protocol identifier use suggests that anything a
    single process can demultiplex, or that can be encoded into a single
@@ -736,26 +738,27 @@
    IANA will begin assigning protocol numbers for only those transport
    protocols explicitly included in a registration request.  This ends
    the long-standing practice of automatically assigning a port number
-   to an application for both TCP and a UDP, even if the request is for
+   to an application for both TCP and UDP, even if the request is for
    only one of these transport protocols.  The new allocation procedure
    conserves resources by allocating a port number to an application for
    only those transport protocols (TCP, UDP, SCTP and/or DCCP) it
-   actually uses.  The port number will be marked as Reserved - instead
-   of Assigned - in the port number registries of the other transport
-   protocols.  When applications start supporting the use of some of
-   those additional transport protocols, their implementors MUST request
+   actually uses.  In the port number registries of the other transport  
+   protocols the port number will be marked as Reserved instead
+   of Assigned.
+   When applications start supporting the use of some of
+   those additional transport protocols, their implementers MUST request
    IANA to convert the reservation into an assignment.  An application
    MUST NOT assume that it can use a port number assigned to it for use
    with one transport protocol with another transport protocol without
-   asking IANA to convert the reservation into an assignment.
+   IANA converting the reservation into an assignment.
 
-   When the available pool of unassigned address has run out in a port
-   range, it will be necessary for IANA to consider the Reserved ports
-   for assignment.  This is part of the motivation to not automatically
-   assigning ports for other transport protocols than the requested
-   ones.  This will allow more ports to be available for assignment at
-   that point.  It also shows the importance to register the transport
-   protocols that are in fact used.
+   When the available pool of unassigned numbers has run out in a port
+   range it will be necessary for IANA to consider the Reserved ports
+   for assignment.  This is part of the motivation for not automatically
+   assigning ports for transport protocols other than the requested
+   one(s).  This will allow more ports to be available for assignment at
+   that point.  It also shows the importance of registering only the transport
+   protocols that are actually used.
 
    Conservation of port numbers is improved by procedures that allow
    previously allocated port numbers to become Unassigned, either
@@ -764,7 +767,7 @@
    number to a new application.  Section 8 describes these procedures,
    which so far were undocumented.  Port number conservation is also
    improved by recommending that applications that do not require an
-   allocated port chose this option and register only a service name.
+   allocated port choose this option and register only a service name.
 
 7.3.  Variances for Specific Port Number Ranges
 
@@ -842,7 +845,7 @@
 
    name is appropriate for this action.
 
-   When a registration for one or more transport protocols is approved,
+   When a registration for one or more transport protocols is approved
    the port number for any non-requested transport protocol(s) will be
    marked as Reserved.  IANA SHOULD NOT assign that port number to any
    other application or service until no other port numbers remain
@@ -903,9 +906,9 @@
       one or more technical contact persons SHALL be provided.
 
    o  Service Name: A desired unique service name for the service
-      associated with the registration request MUST be provided, for use
-      in various service selection and discovery mechanisms (including,
-      but not limited to, DNS SRV records [RFC2782]).  The name MUST be
+      associated with the registration request MUST be provided. This name will be used
+      in various service selection and discovery mechanisms including,
+      but not limited to, DNS SRV records [RFC2782].  The name MUST be
       compliant with the syntax defined in Section 5.1.  In order to be
       unique, they MUST NOT be identical to any currently registered
       service names in the IANA registry [PORTREG].  Service names are

---

From: Lars Eggert <[email-masked]>
Date: Thu, 28 Oct 2010 16:05:46 +0300

Hm. I checked my mail folder, and I don't have Doug's original email? Yes, we should address the comments.

On 2010-10-28, at 15:52, Magnus Westerlund wrote:

> <draft-ietf-tsvwg-iana-ports-04.txt-diff>_______________________________________________
> Apps-Discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
> <ATT00001..txt>

---

From: Joe Touch <[email-masked]>
Date: Thu, 28 Oct 2010 09:16:29 -0700

I don't think they were addressed.

Some comments below:

> 2. Capitalizing the first letter of bullet points

The RFC-Editor process will catch what needs to be corrected on these 
points.

> first and second paragraphs.

Disagree.

> port without IANA authorizing the change) more clear.

Agree - right now, the wording implies that the application is the one 
asking IANA for the change ;-(

> company/organization that is responsible for the assignment resulting in

That might be useful to mention in the application, but it's not clear 
that this belongs in this doc (and certainly not at a SHOULD level).

> Registered, and Dynamic categories.

RFC 1340 introduces the term "registered" ports, and explains the 
differences in the ranges.

> number of port numbers that they need for an application.

7.2 describes IANA actions that conserve port numbers.

Suggestions for ways users can comply are out of scope for this doc. 
(and if this ever gets finished, they'd be in the other doc on port use 
I'm writing, which has a history on the port number space and is why I 
know about RFC1340 above).

> allow their traffic.

This is out of scope for this doc as well; it belongs in the other doc.

Joe