Re: Last Call: <draft-ietf-tsvwg-iana-ports-09.txt> (Internet AssignedNumbers Authority (IANA) Proceduresfor the Management of the Service Nameand Transport Protocol Port Number Registry) to BCP

"t.petch" <daedulus@btconnect.com> Wed, 02 February 2011 12:23 UTC

Return-Path: <daedulus@btconnect.com>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2141A3A6C14; Wed, 2 Feb 2011 04:23:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.799
X-Spam-Level:
X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vIiqJFOUmCcU; Wed, 2 Feb 2011 04:23:54 -0800 (PST)
Received: from mail.btconnect.com (c2beaomr10.btconnect.com [213.123.26.188]) by core3.amsl.com (Postfix) with ESMTP id 485413A7154; Wed, 2 Feb 2011 04:23:52 -0800 (PST)
Received: from host81-152-46-124.range81-152.btcentralplus.com (HELO pc6) ([81.152.46.124]) by c2beaomr10.btconnect.com with SMTP id BNW94587; Wed, 02 Feb 2011 12:26:53 +0000 (GMT)
Message-ID: <007101cbc2cb$8ee4cca0$4001a8c0@gateway.2wire.net>
From: "t.petch" <daedulus@btconnect.com>
To: Joe Touch <touch@isi.edu>, Paul Hoffman <paul.hoffman@vpnc.org>
References: <20110118212603.5733.34489.idtracker@localhost> <B88A8A82-9C4A-40AC-89AF-F177260760F7@cisco.com> <ECA80A72-4E72-44D2-B40E-C90D7197E8C5@nokia.com> <4D421795.70505@isi.edu> <EFADE5D0-BB33-4418-B743-DFEC11B12740@cisco.com> <4D44F85D.5030407@isi.edu> <4D457FD9.5030905@vpnc.org> <B1E38EDF-E78E-47E2-B9A9-D7320A908217@nokia.com> <4D46CC62.1040006@vpnc.org> <3EEDEA1C-C34B-4F39-8E6E-AEDE50C1E504@nokia.com> <4D46D1D3.10701@vpnc.org> <F2152494-8C79-4A0F-951F-B3DB1D274A61@cisco.com> <4D46E623.3080602@ericsson.com> <9E89C43A-EB2A-4DAB-9B12-A740612783E8@cisco.com> <4D47DCF2.1000200@ericsson.com><4D483C4F.3080507@vpnc.org> <4D484543.7010601@isi.edu>
Subject: Re: Last Call: <draft-ietf-tsvwg-iana-ports-09.txt> (Internet AssignedNumbers Authority (IANA) Proceduresfor the Management of the Service Nameand Transport Protocol Port Number Registry) to BCP
Date: Wed, 02 Feb 2011 12:22:57 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Mirapoint-IP-Reputation: reputation=Neutral-1, source=Queried, refid=tid=0001.0A0B0302.4D494D8C.00C8, actions=tag
X-Junkmail-Status: score=10/50, host=c2beaomr10.btconnect.com
X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0207.4D494D8E.011B, ss=1, fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine
X-Junkmail-IWF: false
Cc: Cullen Jennings <fluffy@cisco.com>, Magnus Westerlund <magnus.westerlund@ericsson.com>, IESG IESG <iesg@ietf.org>, IETF discussion list <ietf@ietf.org>, tsvwg@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Feb 2011 12:23:55 -0000

----- Original Message -----
From: "Joe Touch" <touch@isi.edu>
To: "Paul Hoffman" <paul.hoffman@vpnc.org>
"IETF discussion list" <ietf@ietf.org>; <tsvwg@ietf.org>; "IESG IESG"
<iesg@ietf.org>
Sent: Tuesday, February 01, 2011 6:39 PM

> To clarify some of this discussion, providing some context that might be
> useful:
>
> 1) the current doc already explicitly states the procedures for
> assignment in each range of ports (see Sec 8.1.1).
>
> 2) Sec 8.1.1 *already* states that IESG approval through IETF process is
> a valid path for assignment, distinct from Expert Review. Since that
> appears to be a point of confusion, I'll quote it directly:
>
>     o  Ports in the User Ports range (1024-49151) are available for
>        assignment through IANA, and MAY be used as service identifiers
>        upon successful assignment.  Because assigning a port number for a
>        specific application consumes a fraction of the shared resource
>        that is the port number registry, IANA will require the requester
>        to document the intended use of the port number.  This
>        documentation will be input to the "Expert Review" procedure
>        [RFC5226], by which IANA will have a technical expert review the
>        request to determine whether to grant the assignment.  The
>        submitted documentation MUST explain why using a port number in
>        the Dynamic Ports range is unsuitable for the given application.
>        Ports in the User Ports range may also be assigned under the "IETF
>        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>        Review" or "IESG Approval" procedures [RFC5226], which is how most
>        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>        assignments for IETF protocols are handled.
>        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Joe

I think that it is a point of confusion because the text is confused
(well, it confuses me:-(.

If you know in advance that there are two independent paths that
can be taken, then you can read that meaning into it.

If you do not know that, then having read
                                                                     "This
        documentation will be input to the "Expert Review" procedure
        [RFC5226], by which IANA will have a technical expert review the
        request to determine whether to grant the assignment"

then it is obvious that Expert Review always happens, even when a later
sentence talks about 'may also be assigned'.

To make the two paths clear, the text should be reordered eg

         Ports in the User Ports range (1024-49151) are available for
        assignment through IANA, and MAY be used as service identifiers
        upon successful assignment.  Because assigning a port number for a
        specific application consumes a fraction of the shared resource
        that is the port number registry, IANA will require the requester
        to document the intended use of the port number.

For most IETF protocols, ports in the User Ports range will be assigned under
the "IETF
Review" or "IESG Approval" procedures [RFC5226] and no further
documentation is required.

Where these procedures do not apply, then the requester must
input the documentation to

                                                            the "Expert Review"
procedure
        [RFC5226], by which IANA will have a technical expert review the
        request to determine whether to grant the assignment.  The
        submitted documentation MUST explain why using a port number in
        the Dynamic Ports range is unsuitable for the given application.

Tom Petch


>
>     o  Ports in the System Ports range (0-1023) are also available for
>        assignment through IANA.  Because the System Ports range is both
>        the smallest and the most densely allocated, the requirements for
>        new assignments are more strict than those for the User Ports
>        range, and will only be granted under the "IETF Review" or "IESG
>                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>        Approval" procedures [RFC5226].  A request for a System Port
>        ^^^^^^^^^
>        number MUST document *both* why using a port number from the
>        Dynamic Ports range is unsuitable *and* why using a port number
>        from the User Ports range is unsuitable for that application.
>
> 3) section 7 has NOTHING TO DO with the procedures this document
> updates. That section has plenty of words to avoid any such impression.
> And no, we don't need to define "strives", IMO - since NOTHING IN THAT
> SECTION IS BINDING.
>
> Again, since this is a persistent cause of confusion, I quote from that
> section:
>
>     This section summarizes the current principles by which IANA handles
>     the Service Name and Transport Protocol Port Number Registry and
>     attempts to conserve the port number space.  This description is
>     intended to inform applicants requesting service names and port
>     numbers.  IANA has flexibility beyond these principles when handling
>               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>     assignment requests; other factors may come into play, and exceptions
>     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>                                                            **************
>     may be made to best serve the needs of the Internet.
>     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>     ***********
>
> If you need more explicit words, the term "non-binding" can be added.
>
> -------
>
> There's a doc I drafted in TSVWG which is a more appropriate venue to
> discuss this issue (draft-touch-tsvwg-port-use0. I encourage those
> interested in these issues to continue discussion on that list, not on
> this general list.
>
> For this document, if this section is causing confusion, it should be
> removed, since it is already included in this other doc and can be
> vetted there.
>
> Joe
> _______________________________________________
> Ietf mailing list
> Ietf@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf