Re: Last Call: <draft-ietf-tsvwg-iana-ports-09.txt> (Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry) to BCP

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Feb 1, 2011 at 10:26 AM, Joe Touch <touch@xxxxxxx> wrote:
>
>
> On 2/1/2011 10:00 AM, Eric Rescorla wrote:
>>
>> On Tue, Feb 1, 2011 at 9:39 AM, Joe Touch<touch@xxxxxxx>  wrote:
>>>
>>> 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.
>>>      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>
>> For the purposes of clarification, then, this document has no impact
>> whatsoever
>> on ports assigned through the IESG process? I.e., if my WG submits a
>> proposed
>> standard document to the IESG and it asks for two ports, I'm not going to
>> get
>> pushback based on the claim that this document imposes a presumption that
>> that's wrong?
>
> The ONLY impact is in the format of information required for an assignment.
>
> (i.e., yes, if you're asking that there's no change to the process, that's
> correct)
>
> However, IANA can still pushback, and can use whatever advice it sees fit to
> do so, during IESG review. You can get that pushback now. This document
> doesn't change that AT ALL.

I'm sorry, but I'm still not clear.

This document has an affirmative statement against the use of multiple
ports for TLS.

AFAIK that statement is not part of present written policy. Is that correct?

-Ekr
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]