Re: [Tsvwg] IANA issue with RFC2960/draft-ietf-tsvwg-2960bis

[Michael Tuexen <[e-mail]>]

Hi Lars,

sounds good to me. Just two questions:
1. 2960bis is in the RFC editor queue. How will this change of text  
happen?
2. Do I need to write an ID or RFC to register a port? Or can I just  
contact
    IANA? I'm asking this only for registration of port numbers which  
are
    registered for TCP and/or UDP for a similar service like the discard
    port you use as an example.

Best regards
Michael

On Jun 28, 2007, at 7:53 PM, Lars Eggert wrote:

> Hi,
>
> during a second IANA review of the IANA considerations section in  
> draft-ietf-tsvwg-2960bis during the RFC Editor's "IANA" state, a  
> discrepancy has been identified. Basically, the text that describes  
> the port number assignment procedure - which had been taken  
> verbatim from RFC2960 - wasn't describing the procedure that IANA  
> has actually used since RFC2960 was published seven years ago.
>
> The IANA instructions in draft-ietf-tsvwg-2960bis and RFC2960  
> basically say "for each existing TCP/UDP port assignment, create a  
> similar entry in the SCTP port number registry", i.e., a blanket  
> assignment of SCTP port numbers for all existing TCP/UDP assignments.
>
> What appears to have happened is that the ADs at the time  
> identified an issue with the text that was in the ID that became  
> RFC2960 and instructed IANA to follow a different procedure,  
> namely, to not perform a blanket assignment and instead create  
> individual entries in the SCTP port number registry on request,  
> similar to how IANA handles requests for TCP/UDP and DCCP port  
> numbers. Unfortunately, the text in RFC2960 was never updated to  
> reflect this change in procedure.
>
> When I reviewed 2960bis I didn't question this, because it was what  
> I thought the policy was, and it wasn't for the -bis document to  
> change the policy. Now that we've found out that the IANA  
> procedures in RFC2960 were actually modified by the ADs at the  
> time, the situation has changed.
>
> In my (and Magnus) opinion, we should change the IANA  
> considerations text in 2960bis to describe the allocation policy  
> that has actually been in effect for the last seven years, i.e.,  
> allocate individual SCTP ports by request, instead of the blanket  
> registration that the text currently describes.
>
> I'll propose some text changes to 2960bis to that effect below,  
> which I'd like TSVWG and the IESG to review, but let me first  
> explain why I think this is the correct approach:
>
> 	(1) I find myself agreeing with the old ADs' argumentation.
> 	SCTP and TCP (and UDP) have different requirements, and it
> 	is not obvious that an application can substitute one transport
> 	protocol for another. (And yes, the current practice of allocating
> 	both TCP and UDP ports for an application if it requests either
> 	UDP or TCP only is for that reason also problematic, but let's get
> 	to that another time.)
>
> 	(2) For our other recent transport protocol (DCCP), we also didn't
> 	do a blanket port reservation for all existing TCP and UDP ports
> 	and instead require individual registrations, although one could
> 	similarly argue that UDP apps can simply migrate to DCCP. Doing
> 	something different for SCTP is inconsistent.
>
> 	(3) The scope of 2960bis was clarification and fixes. For that
> 	reason, the IANA registration that is used in practice should
> 	be described as part of 2960bis, i.e., 2960bis should "fix" that
> 	error in RFC2960.
>
> Several applications already use SCTP on port numbers that have  
> been assigned to them for TCP or UDP, because the authors were not  
> aware that they would need to request an allocation from IANA. I  
> propose that the change to the IANA Considerations section in  
> 2960bis register the SCTP ports of those applications, to "bless"  
> those existing uses.
>
> All that said, below is the proposal to update 2960bis. The text  
> mirrors the allocation procedure for DCCP ports (thanks, RFC4340  
> authors!)
>
> Please comment. IANA has agreed to put a hold on the document until  
> this issue has been clarified.
>
> Lars
>
>
> OLD TEXT:
>
> 14.  IANA Considerations
>
>    This protocol will require port reservation like TCP for the use of
>    "well known" servers within the Internet.  All current TCP ports
>    shall be automatically reserved in the SCTP port address space.   
> New
>    requests should follow IANA's current mechanisms for TCP.
>
>    This protocol may also be extended through IANA in three ways:
>
>    --   through definition of additional chunk types,
>    --   through definition of additional parameter types, or
>    --   through definition of additional cause codes within ERROR  
> chunks
>
>    In the case where a particular ULP using SCTP desires to have  
> its own
>    ports, the ULP should be responsible for registering with IANA for
>    getting its ports assigned.
>
>
> NEW TEXT:
>
> 14.  IANA Considerations
>
>    SCTP defines three registries that IANA maintains:
>
>    --   through definition of additional chunk types,
>    --   through definition of additional parameter types, or
>    --   through definition of additional cause codes within ERROR  
> chunks
>
>    SCTP requires that the IANA Port Numbers registry be opened for  
> SCTP
>    port registrations; Section 14.5 describes how.
>
>
> 14.5  Port Numbers Registry
>
>    SCTP services may use contact port numbers to provide service to
>    unknown callers, as in TCP and UDP.  IANA is therefore requested to
>    open the existing Port Numbers registry for SCTP using the  
> following
>    rules, which we intend to mesh well with existing Port Numbers
>    registration procedures.
>
>    Port numbers are divided into three ranges.  The Well Known  
> Ports are
>    those from 0 through 1023, the Registered Ports are those from 1024
>    through 49151, and the Dynamic and/or Private Ports are those from
>    49152 through 65535.  Well Known and Registered Ports are intended
>    for use by server applications that desire a default contact  
> point on
>    a system.  On most systems, Well Known Ports can only be used by
>    system (or root) processes or by programs executed by privileged
>    users, while Registered Ports can be used by ordinary user  
> processes
>    or programs executed by ordinary users.  Dynamic and/or Private  
> Ports
>    are intended for temporary use, including client-side ports, out- 
> of-
>    band negotiated ports, and application testing prior to  
> registration
>    of a dedicated port; they MUST NOT be registered.
>
>    The Port Numbers registry should accept registrations for SCTP  
> ports
>    in the Well Known Ports and Registered Ports ranges.  Well Known  
> and
>    Registered Ports SHOULD NOT be used without registration.  Although
>    in some cases -- such as porting an application from TCP to SCTP --
>    it may seem natural to use a SCTP port before registration  
> completes,
>    we emphasize that IANA will not guarantee registration of  
> particular
>    Well Known and Registered Ports.  Registrations should be requested
>    as early as possible.
>
>    Each port registration SHALL include the following information:
>
>    o  A short port name, consisting entirely of letters (A-Z and a-z),
>       digits (0-9), and punctuation characters from "-_+./*" (not
>       including the quotes).
>
>    o  The port number that is requested to be registered.
>
>    o  A short English phrase describing the port's purpose.
>
>    o  Name and contact information for the person or entity performing
>       the registration, and possibly a reference to a document  
> defining
>       the port's use.  Registrations coming from IETF working groups
>       need only name the working group, but indicating a contact  
> person
>       is recommended.
>
>    Registrants are encouraged to follow these guidelines when  
> submitting
>    a registration.
>
>    o  A port name SHOULD NOT be registered for more than one SCTP port
>       number.
>
>    o  A port name registered for TCP MAY be registered for SCTP as  
> well.
>       Any such registration SHOULD use the same port number as the
>       existing TCP registration.
>
>    o  Concrete intent to use a port SHOULD precede port registration.
>       For example, existing TCP ports SHOULD NOT be registered in
>       advance of any intent to use those ports for SCTP.
>
>    This document registers the following ports.  (These registrations
>    should be considered models to follow for future allocation  
> requests.)
>
>            discard  9/sctp  Discard  # IETF TSVWG
>                                      # Randall Stewart <[e-mail]>
>                                      # [draft-ietf-tsvwg-2960bis-05]
>
>            The discard service, which accepts SCTP connections on
>            port 9, discards all incoming application data and sends
>            no data in response. Thus, SCTP's discard port is analogous
>            to TCP's discard port, and might be used to check the
>            health of a SCTP stack.
>
>    <add further registrations here>