Subject: [port-srv-reg] draft-ietf-tsvwg-iana-ports.xml updated

From: Stuart Cheshire <[email-masked]>
Date: Wed, 18 Nov 2009 22:13:35 -0800

I've checked in edits to draft-ietf-tsvwg-iana-ports.xml. Diffs are  
attached below.

Stuart Cheshire <[email-masked]>
* Wizard Without Portfolio, Apple Inc.
* Internet Architecture Board
* www.stuartcheshire.org

Index: draft-ietf-tsvwg-iana-ports.xml
===================================================================
--- draft-ietf-tsvwg-iana-ports.xml	(revision 27)
+++ draft-ietf-tsvwg-iana-ports.xml	(working copy)
@@ -113,9 +113,10 @@
        procedures and how they facilitate the long-term  
sustainability of the
        registry.</t>

-      <t>This document updates RFC2780 by obsoleting Sections 8 and  
9.1 of
-      that RFC, it updates the IANA allocation procedures for DCCP as
-      defined in RFC4340, and it updates RFC2782 to clarify what a  
service name
+      <t>This document updates IANA's procedures by obsoleting  
Sections 8
+      and 9.1 of the IANA allocation guidelines [RFC2780], it updates
+      the IANA allocation procedures for DCCP [RFC4340], and it updates
+      the DNS SRV specification [RFC2782] to clarify what a service  
name
        is and how it is registered.</t>
      </abstract>
    </front>
@@ -128,8 +129,8 @@
        <xref target="RFC0768"/> have had less than clear guidelines.  
New transport
        protocols have been added - the Stream Control Transmission  
Protocol
        (SCTP) <xref target="RFC4960"/> and the Datagram Congestion  
Control
-      Protocol (DCCP) <xref target="RFC4342"/> - and new mechanisms  
have been
-      developed (DNS SRV records <xref target="RFC2782"/>), each  
with separate
+      Protocol (DCCP) <xref target="RFC4342"/> - and new mechanisms  
like DNS SRV
+      records <xref target="RFC2782"/> have been developed, each  
with separate
        registries and separate guidelines. The community recognized  
the need for
        additional procedures beyond just assignment; notably  
modification,
        revocation, and release.</t>
@@ -146,7 +147,7 @@
        specifies post-assignment procedures that until now have been  
handled in
        an ad hoc manner. These include procedures to de-register a  
port number
        that is no longer in use, to re-use a port number allocated  
for one
-      application that is no longer in use for another application, and
+      application that is no longer in use for another application,  
and the
        procedure by which IANA can unilaterally revoke a prior port  
number
        registration. <xref target="iana-procedures"/> discusses the  
specifics
        of these procedures and processes that requesters and IANA  
follow for
@@ -158,16 +159,24 @@
        numbers and service names <xref target="RFC4020"/>, as  
described in
        <xref target="registration"/>.</t>

-      <t>This document updates IANA's allocation guidelines
-      <xref target="RFC2780"/> for UDP and TCP port numbers by  
obsoleting Sections 8
-      and 9.1 of <xref target="RFC2780"/>. (Note that different  
sections of
-      <xref target="RFC2780"/> were updated in February 2008 by
-      <xref target="RFC5237"/>.) This document also updates the IANA  
allocation
-      procedures for DCCP as defined in <xref target="RFC4340"/>. It  
updates
-      <xref target="RFC2782"/> to clarify what a service name is and  
how it is
-      registered, because <xref target="RFC2782"/> simply refers to
-      <xref target="RFC1700"/> when defining service names, which in  
turn contains
-      now-obsolete copies <xref target="RFC3232"/> of various IANA  
registries
+      <t>This document updates IANA's procedures for UDP and TCP  
port numbers
+      by obsoleting Sections 8 and 9.1 of the IANA allocation  
guidelines
+      <xref target="RFC2780"/>. (Note that different sections of the  
IANA
+      allocation guidelines, relating to the protocol field values  
in IPv4
+      header, were also updated in February 2008 <xref  
target="RFC5237"/>.)
+      This document also updates the IANA allocation procedures for  
DCCP
+      <xref target="RFC4340"/>.</t>
+
+      <t>This document also updates the DNS SRV specification
+      <xref target="RFC2782"/> to clarify what a service name is and  
how it
+      is registered, because that specification merely makes a brief  
mention
+      that the symbolic names of services are defined in "Assigned  
Numbers"
+      <xref target="RFC1700"/>, without stating to which section of  
that
+      230-page document it refers. The DNS SRV specification may  
have been
+      referring to the list of Port Assignments (known as /etc/ 
services on
+      Unix), or to the "Protocol And Service Names" section, or to  
both, or
+      to some other section. Furthermore, "Assigned Numbers" is now  
obsolete
+      <xref target="RFC3232"/> and has now been replaced by on-line  
registries
        <xref target="PORTREG"/><xref target="PROTSERVREG"/>.</t>
      </section>

@@ -188,12 +197,15 @@
        <xref target="SYSFORM"/> <xref target="USRFORM"/>.
        Even that length limit has not been consistently applied, and  
some
        assigned service names are 15 characters long. When service
-      identification via DNS SRV RRs were introduced, the  
ambiguities in the
-      syntactic definition of the service namespace, together with a
+      identification via DNS SRV RRs was introduced, the
        requirement by IANA to only assign service names and port  
numbers in
        combination, led to the creation of an ad hoc service name  
registry
        outside of the control of IANA <xref target="SRVREG"/>.</t>

+      <!--
+      This text duplicates what's said elsewhere in the document.
+      I also don't think that RFC 0952 (DOD INTERNET HOST TABLE  
SPECIFICATION)
+      sheds any light on this issue. -- SC
        <t>It has also been historically unclear if the "name"  
entries registered
        in the "Protocol and Service Names Registry" <xref  
target="PROTSERVREG"/>
        can be used as service names. <xref target="RFC0952"/>  
defines the names
@@ -202,6 +214,7 @@
        consequently have been used, e.g., in SRV records. This  
motivates why
        this document merges the 166 protocol and service names  
defined in that
        registry into the port number registry <xref target="PORTREG"/ 
 >.</t>
+      -->

        <t>This document aggregates all this scattered information  
into a single
        reference that aligns and clearly defines the management  
procedures for
@@ -212,9 +225,10 @@
        manner.</t>

        <t>This document defines rules for registration of service  
names without
-      associated port numbers, for such usages as DNS SRV records,  
which was
-      not possible under the previous IANA procedures. These new  
procedures
-      also merge service name registrations from the non-IANA "ad  
hoc" registry
+      associated port numbers, for such usages as DNS SRV records
+      <xref target="RFC2782"/>, which was
+      not possible under the previous IANA procedures. Theis document
+      also merges service name registrations from the non-IANA ad  
hoc registry
        <xref target="SRVREG"/> and from the the IANA "Protocol and  
Service
        Names" registry <xref target="PROTSERVREG"/> into the IANA  
"Port and
        Service Name" registry <xref target="PORTREG"/>, which from  
here on is
@@ -262,27 +276,27 @@
        together with the IP addresses of the communicating end  
systems uniquely
        identifies 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 both "http" and "www" for port number 80.</t>
+      port number 23 and "http" (and the "www" alias) for port  
number 80.</t>

        <t>Hosts running services, hosts accessing services on other  
hosts, and
        intermediate devices (such as firewalls and NATs) that  
restrict services
        need to agree on which service corresponds to a particular  
destination
        port. Although this is ultimately a local decision with  
meaning only
-      between the endpoints of a connection, most Internet  
components use a
-      single, shared view of this association, provided by the Internet
+      between the endpoints of a connection, it is common for many  
services
+      to have a default port upon which those servers usually listen,
+      when possible, and these ports are recorded by the Internet
        Assigned Numbers Authority (IANA) through the port number  
registry
        <xref target="PORTREG"/>.</t>

        <t>Over time, the assumption that a particular port number  
necessarily
        implies a particular service may become less true. For  
example, multiple
-      instances of the same service can run on different ports on  
the same
-      host, or NATs that support port mapping or registration
-      <xref target="I-D.cheshire-nat-pmp"/><xref target="UPnP"/>  
need to offer
-      service instances using the same port on several internal  
hosts available
-      to the public Internet on different ports. This document assumes,
-      however, that ports are most often used in a conventional  
manner - where
-      endpoints and intermediate devices all share the common view  
of the IANA
-      port number registry.</t>
+      instances of the same service on the same host cannot generally
+      listen on the same port, and multiple hosts behind the same NAT
+      gateway cannot all have a mapping for the same port on the
+      external side of the NAT gateway, whether using static port
+      mappings configured by hand by the user, or dynamic port
+      mappings configured automatically using a port mapping protocol
+      <xref target="I-D.cheshire-nat-pmp"/><xref target="IGD"/>.</t>

  <!--
        <t><list style="symbols">
@@ -305,7 +319,7 @@
            share a single IP address, the computers can request that  
the NAT
            gateway create port mappings to enable them to receive  
inbound
            connections <xref target="I-D.cheshire-nat-pmp"/><xref
-          target="UPnP"/>, but they can't all get the same external  
port
+          target="IGD"/>, but they can't all get the same external port
            at the same time. Consequently, some applications on some  
of those
            computers may be receiving inbound connections on port  
other than
            the port usually used for the service in question. As  
ISPs begin to
@@ -319,50 +333,67 @@
        on UNIX, look up port numbers by performing queries for DNS  
SRV records
        <xref target="RFC2782"/><xref target="I-D.cheshire-dnsext-dns- 
sd"/>
        or determine port numbers in a variety of other ways
+      like the TCP Port Service Multiplexer (TCPMUX)
        <xref target="RFC1078"/>.</t>

        <t>Designers of applications and application-level protocols  
may apply
        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 and service name  
for its
+      other application will use that port number or service name  
for its
        communication sessions. Alternatively, application designers  
may also
-      only ask for an assigned service name, if their application  
does not
+      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 SRV records  
to look up
-      port numbers at runtime, or transports that use service names  
not coupled
+      port numbers at runtime.</t>
+
+      <!--
+      There have been many proposals over the years for putting names
+      instead of numbers into the TCP header. I think it's
+      inappropriate to list one such proposal here if we're not going
+      to list all the others too.
+
+      , or transports that use service names not coupled
        to port numbers, e.g., TCP portnames
-      <xref target="I-D.touch-tcp-portnames"/>.</t>
+      <xref target="I-D.touch-tcp-portnames"/>
+      -->
      </section>

      <section anchor="term" title="Conventions Used in this Document">
        <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",  
"SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"  
in this
-      document are to be interpreted as described in BCP 14, RFC 2119
+      document are to be interpreted as described in BCP 14,
+      "Key words for use in RFCs to Indicate Requirement Levels"
        <xref target="RFC2119"/>.</t>
      </section>

      <section title="Service Names">
        <t>Service names are the unique key in the Port and Service Name
        registry. This unique symbolic name for a service may also be  
used for
-      other purposes, such as <xref target="RFC2782">DNS SRV  
records</xref>.
+      other purposes, such as in <xref target="RFC2782">DNS SRV  
records</xref>.
        Within the registry, this unique key ensures that different  
services can
        be unambiguously distinguished, thus preventing name  
collisions and
-      avoiding confusion about who is the registration owner of a  
particular
+      avoiding confusion about who is the administrative contact for  
a particular
        entry.</t>

        <t>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. 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 "www" and "http".</t>
+      data, such as a DCCP service code.</t>

-      <!--I added the above regarding multiple serivce names to one  
transport
-      protocol and port number due to existing registry entries. If  
we don't
-      want this we need to deal with the legacy.-->
-
+      <t>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  
designated primary,
+      for use with mechanisms such as DNS SRV Records <xref  
target="RFC2782"/>,
+      and the others MUST be designated as aliases of the primary  
service name.
+      This is necessary so that all clients and servers using a service
+      discovery mechanism use a consistent name by which to refer to a
+      given service. Otherwise, if a server were to advertise that it
+      supports the "www" service, and a client were to seek  
instances of
+      the "http" service, that client would fail to discover that  
server,
+      defeating the purpose of having a service discovery  
mechanism.</t>
+
        <t>Service names are assigned on a "first come, first served"  
basis, as
        described in <xref target="registration"/>. Names should be  
brief and
        informative, avoiding words or abbreviations that are  
redundant in the
@@ -372,10 +403,10 @@
        identifiable suffix (e.g., "-disc").</t>

        <section title="Service Name Usage in DNS SRV Records">
-        <t><xref target="RFC2782"/> defines SRV records for the DNS  
system.
-        One part of the DNS name of an SRV record includes what is  
called
-        "SERVICE", i.e., a symbolic name for the service. This  
document updates
-        <xref target="RFC2782"/> in order to clarify that the  
symbolic name
+        <t>One part of the DNS name of an SRV record includes what the
+        SRV specification <xref target="RFC2782"/> calls "SERVICE",
+        i.e., a symbolic name for the service. This document updates
+        that specification in order to clarify that the symbolic name
          ("SERVICE") SHALL only be a service name as defined in this  
document
          that has been registered with IANA and recorded in the port  
number and
          service name registry <xref target="PORTREG"/>. This to  
ensure that
@@ -385,7 +416,7 @@
      </section>

      <section anchor="types" title="Port Number Ranges">
-      <t>TCP, UDP (and UDP-Lite), SCTP and DCCP use 16-bit  
namespaces for
+      <t>TCP, UDP, UDP-Lite, SCTP and DCCP use 16-bit namespaces for
        their port number registries. The port registries for all these
        transport protocols are subdivided into three ranges of  
numbers, and
        <xref target="variances"/> describes the IANA procedures for  
each
@@ -490,7 +521,7 @@

      <section title="Past Principles">
        <t>Before the publication of this document, the principles of  
port number
-      and service name management followed a few mostly undocumented
+      and service name management followed a few mostly-undocumented
        guidelines. They are recorded here for historical purposes,  
and this
        document updates them in <xref target="upprinc"/>. These  
principles
        were:</t>
@@ -514,7 +545,7 @@
            assigning a corresponding port number at the same time</t>
          </list>

-      This document attempts to document, clarify and align these  
guidelines
+      This document clarifies and aligns these guidelines
        in order to more conservatively manage the limited remaining  
port number
        space and to enable and promote the use of service names for  
service
        identification without associated port numbers, where  
possible.</t>
@@ -548,7 +579,7 @@
          of the current Internet in a way that would not be backward  
compatible
          and interfere with both current and legacy applications.</t>

-        <t>Conservation of the port number space recognizes that  
because this
+        <t>Conservation of the port number space requires that  
because this
          space is a limited resource, applications are expected to  
participate
          in the traffic demultiplexing process where feasible. The  
port numbers
          are expected to encode as little information as possible  
that will
@@ -564,18 +595,21 @@
              mechanism, or for updated variants of a service)</t>

              <t>IANA will allocate only one assigned port number for  
all different types of
-            devices using or participating in the same service</t>
+            device using or participating in the same service</t>

-            <t> IANA will allocate port numbers only for the  
transport protocols
-            explicitly named in an registration request</t>
+            <t>IANA will allocate port numbers only for the  
transport protocol(s)
+            (if any) explicitly named in an registration request</t>

-            <t> IANA may recover unused port numbers, via the new  
procedures of
+            <t>IANA may recover unused port numbers, via the new  
procedures of
              de-registration, revocation, and transfer</t>

-            <t>IANA may begin assigning service names that do not  
request a
+            <t>IANA will begin assigning service names that do not  
request a
              corresponding port number allocation under a simple  
"First Come,
-            First Served" policy <xref target="RFC5226"/> (assignments
-            involving port numbers still require "Expert Review")</t>
+            First Served" policy <xref target="RFC5226"/>, instead  
of the
+            "Expert Review" policy required for port number  
allocations.
+            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.</t>

            </list>
          A given service is expected to further demultiplex messages  
where
@@ -604,12 +638,12 @@
          The process and protocol identifier use suggests that  
anything a
          single process can demultiplex, or that can be encoded into  
a single
          protocol, should be. The firewall filtering use suggests  
that some
-        uses that could be de-multiplexed or encoded must be  
separated to
+        uses that could be multiplexed or encoded must be separated to
          allow for firewall management. Note that this latter use is  
much less
          sound, because port numbers have meaning only for the two  
endpoints
          involved in a connection, and drawing conclusions about the  
service
          that generated a given flow based on observed port numbers is
-        inherently problematic.
+        not always reliable.
          <!-- (again, as discussed in detail in
          <xref target="I-D.touch-tsvwg-port-guidelines"/>).-->
          Further, previous separation of protocol variants based on  
security
@@ -617,13 +651,13 @@
          recommended for new protocols, because all should be  
security-capable
          and capable of negotiating the use of security in-band.</t>

-        <t>IANA will begin assigning protocol numbers only for those  
transport
+        <t>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  
only for
+        application for both TCP and a UDP, even if the request is  
for only
          one of these transport protocols. The new allocation procedure
-        conserves resources by only allocating a port number to an  
application
-        for those transport protocols (TCP, UDP, SCTP and/or DCCP)  
it actually
+        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
@@ -640,8 +674,7 @@
          a new application. <xref target="iana-procedures"/> 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, e.g., because they can use
-        service-name-based lookups, chose this option and only  
register a
+        do not require an allocated port chose this option and  
register only a
          service name.</t>

        </section>
@@ -709,12 +742,12 @@
          statement explaining the reason a Reserved number or name is
          appropriate for this action.</t>

-        <t>When a registration for one or more (but not all) transport
-        protocols is approved, the port number for the non-requested  
transport
+        <t>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 Unassigned in the requested range. The current
-        registration owner of a port number MAY register these  
Reserved port
+        administrative contact for a port number MAY register these  
Reserved port
          numbers for other transport protocols when needed.</t>

          <t>Service names, on the other hand, are not tied to a  
specific
@@ -722,19 +755,36 @@
          (but not a port number) allocate that service name for use  
with all
          transport protocols.</t>

-        <t>A port number or service name registration consists of the
-        following information:</t>
+        <t><vspace blankLines="11" />A port number or service name  
registration request contains
+        some or all of the following information:</t>

          <t>
+          <list style="empty">
+            <t>
+            Registration Administrative Contact (required)<vspace />
+            Registration Technical Contact (required)<vspace />
+            Service Name (required)<vspace />
+            Port Number (optional)<vspace />
+            Transport Protocol(s) (if port number requested)<vspace />
+            Service Code (for DCCP only)<vspace />
+            Description (required)<vspace />
+            Reference (required)
+            </t>
+          </list>
+        </t>
+
+        <t>
            <list style="symbols">
-            <t>Registration Owner: Name and email address of the  
owner of the
+            <t>Registration Administrative Contact:
+            Name and email address of the administrative contact for  
the
              registration. This is REQUIRED. For registrations done  
through
-            IETF-published RFCs, the registration ownership will  
belong to the
+            IETF-published RFCs, the administrative contact will be the
              IETF and not the technical contact persons.</t>

              <t>Registration Technical Contact: Name and email  
address of the
              technical contact person for the registration. This is  
REQUIRED.
-            For individuals, this is the same as the Registration  
Owner; for
+            For individuals, this is the same as the
+            Registration Administrative Contact; for
              organizations, this is a point of contact at that  
organization.
              Additional address information MAY be provided. For  
registrations
              done through IETF-published RFCs, one or more technical  
contact
@@ -744,7 +794,7 @@
              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 <xref  
target="RFC2782"/>).
-            Valid service names MUST only contain these US-ASCII
+            Valid service names MUST contain only these US-ASCII
              <xref target="ANSI.X3-4.1986"/> characters: letters  
from A to Z, digits
              from 0 to 9, and hyphens ("-", ASCII 0x2D or decimal  
45). They
              MUST be at least one character and no more than fifteen  
characters
@@ -757,35 +807,39 @@
              registry with mixed case (e.g., for clarity), but for  
the purposes
              of comparison, the case is ignored.</t>

-            <t>Port Number: If assignment of port number(s) is  
desired, either
-            the currently Unassigned port number(s) the requester  
suggests for
-            allocation or the tag "ANY" MUST be provided. If only a  
service
-            name is to be assigned, this field MUST be empty. If  
specific port
-            numbers are requested, IANA is encouraged to allocate the
-            suggested numbers. If the tag "ANY" is specified, IANA  
will choose
+            <t>Port Number: If assignment of a port number is  
desired, either
+            the currently Unassigned port number the requester  
suggests for
+            allocation, or the text "ANY", MUST be provided. If only  
a service
+            name is to be assigned, this field MUST be empty. If a  
specific port
+            number is requested, IANA is encouraged to allocate the
+            requested number. If the text "ANY" is specified, IANA  
will choose
              a suitable number from the Registered Ports range. Note  
that the
-            applicant MUST NOT use the suggested ports prior to the  
completion
-            of the registration.</t>
+            applicant MUST NOT use the requested port prior to the  
completion
+            of the registration<!-- or the IETF will be very very cross
+            and will glare at you in a most disapproving manner-->.</t>

-            <t>Transport Protocol: The transport protocol(s) for  
which the
-            allocation is requested MUST be provided. This field is  
currently
+            <t>Transport Protocol(s): If assignment of a port number is
+            desired, the transport protocol(s) for which the allocation
+            is requested MUST be provided. This field is currently
              limited to one or more of TCP, UDP, SCTP, and DCCP.</t>

-            <t>Service Code: A desired unique service code for the  
service
-            associated with the registration request. Service codes are
-            specific to the DCCP protocol
-            <xref target="I-D.ietf-dccp-serv-codes"/>; the request MUST
-            include a desired service code when the registration  
requests
-            includes DCCP as a transport protocol, and MUST NOT  
include one
-            otherwise.</t>
+            <t>Service Code: The request MUST include a desired unique
+            DCCP service code <xref target="I-D.ietf-dccp-serv-codes"/>
+            if the registration request includes DCCP as a transport
+            protocol, and MUST NOT include a requested DCCP service
+            code otherwise.</t>

              <t>Description: A short description of the service  
associated with
              the registration request is REQUIRED. It should avoid  
all but the
              most well known acronyms.</t>

-            <t>Reference: A reference document describing the  
protocol or
-            application using this port, including whether the protocol
-            supports either broadcast, multicast, or anycast  
communication.
+            <t>Reference: A description of (or a reference to a  
document
+            describing) the protocol or application using this port.
+            The description must include whether the protocol uses  
either
+            broadcast, multicast, or anycast communication. A  
statement that
+            the protocol is proprietary and not publicly documented is
+            also acceptable provided that the above information
+            regarding use of broadcast, multicast, or anycast is given.
              For registration requests for Registered Ports, this  
documentation
              MUST explain why a port number in the Dynamic Ports  
range is
              unsuitable for the given application. For registration  
requests
@@ -797,20 +851,20 @@
              without including such a reference document, although  
it is
              RECOMMENDED that at least a reference to an Internet Draft
              describing the work in progress is provided.</t>
-          </list></t>
+          </list>
+        </t>

          <t>When IANA receives a registration request containing the  
above
-        information, they SHALL initiate an "Expert Review"
-        <xref target="RFC5226"/> in order to determine whether an  
assignment
-        should be made. For requests for service names that do not  
include
-        port number assignments, IANA MAY, at its discretion, skip  
the "Expert
-        Review" procedure and assign the service name under a simple  
"First
-        Come First Served" policy <xref target="RFC5226"/>.</t>
+        information requesting a port number, IANA SHALL initiate an  
"Expert
+        Review" <xref target="RFC5226"/> in order to determine  
whether an
+        assignment should be made. For requests that do not include a
+        port number, IANA SHOULD assign the service name under a simple
+         "First Come First Served" policy <xref target="RFC5226"/>.</t>
        </section>

        <section anchor="deregistration"
                 title="Port Number and Service Name De-Registration">
-        <t>The original requesters of a granted port number  
assignment can
+        <t>The administrative contact of a granted port number  
assignment can
          return the port number to IANA at any time if they no  
longer have a
          need for it. The port number will be de-registered and will  
be marked
          as Reserved. IANA should not re-assign port numbers that  
have been
@@ -833,7 +887,7 @@
        </section>

        <section anchor="reuse" title="Port Number and Service Name  
Re-Use">
-        <t>If the original requesters of a granted port number  
assignment no
+        <t>If the administrative contact of a granted port number  
assignment no
          longer have a need for the registered number, but would  
like to re-use
          it for a different application, they can submit a request  
to IANA to
          do so.</t>
@@ -908,20 +962,16 @@

          <t>With the help of their IESG-appointed Expert Reviewer,  
IANA SHALL
          carefully determine if there is a valid technical,  
operational or
-        managerial reason before performing the transfer.</t>
+        managerial reason to grant the requested new assignment.</t>
        </section>

        <section title="Maintenance Issues">
-        <t>The previous procedures help IANA manage the defining  
properties of
-        the port name and service name registry. There are additional
-        procedures which are administrative and help IANA maintain
-        non-defining information in a registration. This includes  
changes to
-        the Port Description and changes to Technical Contact  
information.
-        (Note that Registration Owner cannot be changed; see
-        <xref target="transfer"/> above.) These changes are  
coordinated by
+        <t>In addition to the formal procedures described above,  
updates to
+        the Description and Technical Contact information are  
coordinated by
          IANA in an informal manner, and may be initiated by either the
-        registrant or by IANA, e.g., the latter when requesting an  
update to
-        current contact information.</t>
+        registrant or by IANA, e.g., by the latter requesting an  
update to
+        current contact information. (Note that Registration  
Administrative
+        Contact cannot be changed; see <xref target="transfer"/>  
above.)</t>
        </section>
      </section>

@@ -929,8 +979,8 @@
        <t>The IANA guidelines described in this document do not  
change the
        security properties of UDP, TCP, SCTP, or DCCP.</t>

-      <t><!-- adapted from http://www.iana.org/assignments/port- 
numbers -->Assignment
-      of a port number or service name does not in any way imply an
+      <t><!-- adapted from http://www.iana.org/assignments/port- 
numbers -->
+      Assignment of a port number or service name does not in any  
way imply an
        endorsement of an application or product, and the fact that  
network
        traffic is flowing to or from a registered port number does  
not mean
        that it is "good" traffic, or even that it is used by the  
assigned
@@ -952,19 +1002,25 @@
        <t>This document obsoletes Sections 8 and 9.1 of the March  
2000 IANA
        Allocation Guidelines <xref target="RFC2780"/>.</t>

+      <!-- This is trivia that belongs in an email messsage, not in a
+      public document that exists in perpetuity. A year from now what
+      people will care about is how to register their service, not a
+      tedious exhaustive history of how it came to be that way.
+
        <t>Upon approval of this document, IANA is requested to  
contact the
        maintainer of the <xref target="SRVREG"/> registry, in order to
        merge the contents of that private registry into the official  
IANA
        registry. It is expected that the contents of
        <xref target="SRVREG"/> will at that time be replaced with  
pointers to
        the IANA registry and to this RFC.</t>
+      -->

-      <t>Similarly, IANA is instructed to create a new service name  
entry in
+      <t>IANA is instructed to create a new service name entry in
        the port number registry <xref target="PORTREG"/> for any  
entry in the
        "Protocol and Service Names" registry <xref  
target="PROTSERVREG"/> that
-      does not already have one assigned. After that, IANA should  
investigate
-      if the "Protocol and Service Names" registry <xref  
target="PROTSERVREG"/>
-      can be retired.</t>
+      does not already have one assigned. After that, IANA should  
retire
+      the "Protocol and Service Names" registry <xref  
target="PROTSERVREG"/>
+      and accept no further requests to create new entries in that  
registry.</t>

        <section anchor="consistency" title="Service Name Consistency">
          <t><xref target="registration"/> defines which character  
strings
@@ -983,20 +1039,22 @@
          suitable to be used directly as well-formed service names  
because they
          contain illegal characters such as asterisks, dots,  
plusses, slashes,
          or underscores. All existing "Short Names" conform to the  
length
-        requirement of 15 characters or less. For these unsuitable  
"Short
+        requirement of 15 characters or fewer. For these unsuitable  
"Short
          Names", listed in the table below, the service name will be  
the Short
          Name with any illegal characters replaced by hyphens. IANA  
SHALL add
-        an alias to the registry that assigns a well-formed service  
name for
-        the existing service but otherwise duplicates the original  
assignment
-        information. In the description field of the new alias, IANA  
SHALL
-        record that it assigns a well-formed service name for the  
previous
-        service and point to the original assignment. In the  
description field
-        of the original assignment, IANA SHALL add a note that the  
service
-        name is historic, is not usable with many common service  
discovery
-        mechanisms, and provide a reference to the new alias, which  
can be
-        used in this way.</t>
+        an entry to the registry giving the new well-formed primary
+        service name for the existing service, that otherwise  
duplicates
+        the original assignment information. In the description  
field of
+        this new entry giving the primary service name, IANA SHALL  
record
+        that it assigns a well-formed service name for the previous
+        service and reference the original assignment. In the  
description
+        field of the original assignment, IANA SHALL add a note that
+        this entry is an alias to the new well-formed service name, and
+        that the old service name is historic, not usable for use  
with many
+        common service discovery mechanisms.</t>

-        <t>Names containing illegal characters to be replaced by  
hyphens:</t>
+        <t><vspace blankLines="40" />Names containing illegal  
characters
+        to be replaced by hyphens:</t>

          <texttable><ttcol/><ttcol/><ttcol/>
            <c>914c/g</c>
@@ -1097,8 +1155,9 @@
            <c>z39.50</c>
          </texttable>

-        <t>In the case of "whois++", the service name will be
-        "whoisplusplus".</t>
+        <t>Following the example set by the "application/whoispp-query"
+        MIME Content-Type <xref target="RFC2957"/>, the service name  
for
+        "whois++" will be "whoispp".</t>
        </section>

        <section anchor="sctpdccpexp"
@@ -1120,23 +1179,23 @@
          non-experimental deployment.</t>

          <texttable><ttcol/><ttcol/>
-          <c>Registration Technical Contact</c> <c>IESG  
&lt;[email-masked]&gt;</c>
-          <c>Registration Owner</c>             <c>IETF  
&lt;[email-masked]&gt;</c>
-          <c>Transport Protocol</c>             <c>SCTP, DCCP</c>
-          <c>Port Number</c>                    <c>1021</c>
-          <c>Port Name</c>                      <c>RFC3692-style  
Experiment 1</c>
-          <c>Service Name</c>                   <c>exp1</c>
-          <c>Reference</c>                      <c>[RFCyyyy]</c>
+          <c>Registration Administrative Contact</c> <c>IETF  
&lt;[email-masked]&gt;</c>
+          <c>Registration Technical Contact</c>      <c>IESG  
&lt;[email-masked]&gt;</c>
+          <c>Service Name</c>                        <c>exp1</c>
+          <c>Port Number</c>                         <c>1021</c>
+          <c>Transport Protocol</c>                  <c>SCTP, DCCP</c>
+          <c>Description</c>                         <c>RFC3692- 
style Experiment 1</c>
+          <c>Reference</c>                           <c>[RFCyyyy]</c>
          </texttable>

          <texttable><ttcol/><ttcol/>
-          <c>Registration Technical Contact</c> <c>IESG  
&lt;[email-masked]&gt;</c>
-          <c>Registration Owner</c>             <c>IETF  
&lt;[email-masked]&gt;</c>
-          <c>Transport Protocol</c>             <c>SCTP, DCCP</c>
-          <c>Port Number</c>                    <c>1022</c>
-          <c>Port Name</c>                      <c>RFC3692-style  
Experiment 2</c>
-          <c>Service Name</c>                   <c>exp2</c>
-          <c>Reference</c>                      <c>[RFCyyyy]</c>
+          <c>Registration Administrative Contact</c> <c>IETF  
&lt;[email-masked]&gt;</c>
+          <c>Registration Technical Contact</c>      <c>IESG  
&lt;[email-masked]&gt;</c>
+          <c>Service Name</c>                        <c>exp2</c>
+          <c>Port Number</c>                         <c>1022</c>
+          <c>Transport Protocol</c>                  <c>SCTP, DCCP</c>
+          <c>Description</c>                         <c>RFC3692- 
style Experiment 2</c>
+          <c>Reference</c>                           <c>[RFCyyyy]</c>
          </texttable>

          <t>[RFC Editor Note: Please change "yyyy" to the RFC number  
allocated
@@ -1261,16 +1320,15 @@

      <references title="Informative References">
        <?rfc include="reference.RFC.0959" ?>
-      <?rfc include='reference.RFC.0952' ?>
        <?rfc include="reference.RFC.1078" ?>
        <?rfc include="reference.RFC.1700" ?>
        <?rfc include="reference.RFC.2782" ?>
+      <?rfc include="reference.RFC.2957" ?>
        <?rfc include="reference.RFC.3232" ?>
        <?rfc include="reference.RFC.3692" ?>
        <?rfc include="reference.RFC.4342" ?>
        <?rfc include="reference.RFC.4960" ?>
        <?rfc include="reference.RFC.5237" ?>
-      <?rfc include="reference.I-D.touch-tcp-portnames" ?>
        <?rfc include="reference.I-D.cheshire-dnsext-dns-sd" ?>
        <?rfc include="reference.I-D.cheshire-nat-pmp" ?>
        <?rfc include="reference.I-D.ietf-dccp-serv-codes" ?>
@@ -1360,7 +1418,7 @@
          </front>
        </reference>
  -->
-      <reference anchor="UPnP">
+      <reference anchor="IGD">
          <front>
            <title>Internet Gateway Device (IGD) V 1.0</title>
            <author fullname="UPnP Forum">