-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160
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
- --
... and that's just a little bit of history repeating.
-- Propellerheads
Improve the effectiveness of your Internet presence with
a domain name makeover! http://SupersetSolutions.com/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (FreeBSD)
iEYEAREDAAYFAkuLKJQACgkQyIakK9Wy8PtcaACg5lEBJw12OwUGCn6i98VDlkHQ
oI0AoLfNB0fMMGJ42dPV6d38V+i3pPr0
=giEw
-----END PGP SIGNATURE-----
--- 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
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
