Subject: [port-srv-reg] Specification requirement

From: Stuart Cheshire <[email-masked]>
Date: Sat, 21 Nov 2009 20:07:19 -0800

I've been thinking about the text for the "Reference" part of the  
registration request. This is what it used to say:

    o  Reference: A reference document describing the protocol or
       application using this port, including whether the protocol
       supports either broadcast, multicast, or anycast communication.
       ...

       "Early" registration requests can be made by IETF working groups
       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.

How realistic is this? Joe, how many registration requests currently  
include a document describing the protocol? Certainly, for  
registration requests we receive for service names only, almost none  
include a public specification.

I propose the following alternate text:

    o  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.

       For registrations requesting only a Service Name or a Service  
Name
       and Registered Port, 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 a Registered Port, the registration
       request MUST explain why a port number in the Dynamic Ports range
       is unsuitable for the given application.

       For registration requests for a Well Known Port, the registration
       request MUST explain why a port number in the Registered Ports or
       Dynamic Ports ranges is unsuitable, and a reference to a stable
       protocol specification document MUST be provided.  For requests
       from IETF Working Groups, IANA MAY accept "Early" registration
       requests referencing a sufficiently stable Internet Draft instead
       of a published Standards-Track RFC [RFC4020].

Comments?

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

---

From: Joe Touch <[email-masked]>
Date: Sun, 22 Nov 2009 10:32:56 -0800

See below...

Stuart Cheshire wrote:
> include a document describing the protocol? Certainly, for registration
> requests we receive for service names only, almost none include a public
> specification.

The item is a place where reference documents can be indicated. It's not
required, but I'd say about 1/3-1/2 of requests contain such links, and
they are useful. The information needs to be supplemental, so that
if/when the links disappear, the supplied info is still sufficient. We
often review past requests to understand whether new requests are justified.

>       describing) the protocol or application using this port. 

Disagree. See "Description", which serves the purpose of the
description. This section is only for supplemental references.

If anything, the remainder of this info would appear under the
"description" item.

I would encourage all such info to be an example, not 'required',
because it evolves over time, and IANA has shown fairly good judgement
in adding/removing issues as needed.

Examples include:
	whether multicast/broadcast/anycast is used
	whether a UDP service includes app-level cong/flow control
	why a Dynamic port is not sufficient
	(for well-known ports) why a Registered port is not sufficient

*ALL* of the above are currently required - as is a description of the
basic protocol - even for proprietary applications, in order to receive
an assigned port. No need to state that as a requirement, though.
There's no need for "MUST" in any of these descriptions. It's not a
protocol specification.

The only MUSTs/MAYs in this doc, IMO, are that:

	- users MUST NOT use well-known or registered ports prior
	to assignment

	- applications for well-known ports MUST include IESG
	approval of a standards-track specification, and MAY
	be made early (as noted below)

	- the spec of the service name

Everything about how to fill out an application seems useless to specify
in such language. The fact is that IANA controls the assignments, and
won't assign them to partial applications anyway. No need to get into
such process-oriented requirements.

I.e., keep the description, but remove the 2119-language. Ditto for 8.3-8.6.

Joe

>       The
>       For registrations requesting only a Service Name or a Service Name