Re: Message Numbers and Disconnect Codes

[Chris Lonvick <clonvick%cisco.com@localhost>]

Hi,

On Tue, 20 Jul 2004, Jeffrey Hutzelman wrote:

>
>
> On Tuesday, July 20, 2004 11:29:26 -0700 Chris Lonvick <clonvick%cisco.com@localhost>
> wrote:
>
> > - How are the Local Extension Message Numbers going to be used?
> > If implementor A defines 200 as SSH_MSG_just_use_xor and implementor B
> > defines 200 as SSH_MSG_Luke__use_the_Force, then there could be some
> > problems if they meet each other in the wild.  There doesn't appear to be
> > any way to say 200%careless.org@localhost or 200%deathstar.gov@localhost as is defined with
> > the non-numbered Local Extensions.
>
>
> The various named algorithms, methods, etc use the @domain mechanism to
> allow naming of algorithms originating outside the IETF without placing a
> burden on the IANA.  These apply only to the specific directions in which
> the protocol was designed to be extended.  Such names are intended to be
> globally unique, even when they originate outside the IETF; this is
> accomplished by delegating a portion of the namespace to domain
> registrants.  So, the user auth method "just_believe_me%cmu.edu@localhost" doesn't
> describe a method in use at cmu.edu; it describes a method _named by_
> someone at cmu.edu, regardless of where it is used.  Thus these are not
> "local" extensions; just delegated namespace.
>
>
> By contrast, the message number space is not intended to be extended in
> this fashion.  Message numbers are not a generic extension mechanism,
> though in limited cases the protocol may end up being extended by the
> addition of a new message type.  When that happens it will generally be
> through the IETF, and the message number will be allocated by IANA.  There
> is no expectation that entities other than the IANA will be able to
> allocate globally-recognized message numbers.

For Message Numbers, I can propose text such as:

   Requests for assignments of new message numbers in the range of 1 to
   127 MUST be done through the "IETF Consensus" method as described in
   [RFC2434].

   Requests for assigments of new message numbers in the range of 128 to
   191 MUST be done through the "Standards Action" method as described
   in [RFC2434].

   The IANA will not control the message numbers range of 192 through
   255.  These are designated as "Private Use" as described in [RFC2434].


RFC-2434 has some explicit language about these things.  To wit:

      Private Use - For private or local use only, with the type and
           purpose defined by the local site. No attempt is made to
           prevent multiple sites from using the same value in different
           (and incompatible) ways. There is no need for IANA to review
           such assignments and assignments are not generally useful for
           interoperability.

      IETF Consensus - New values are assigned through the IETF
           consensus process. Specifically, new assignments are made via
           RFCs approved by the IESG. Typically, the IESG will seek
           input on prospective assignments from appropriate persons
           (e.g., a relevant Working Group if one exists).

      Standards Action - Values are assigned only for Standards Track
           RFCs approved by the IESG.


The other options in this BCP are:

      Hierarchical allocation - Delegated managers can assign values
           provided they have been given control over that part of the
           name space.  IANA controls the higher levels of the namespace
           according to one of the other policies.

           Examples: DNS names, Object Identifiers

   (This doesn't seem to fit this numbered name space.)


      First Come First Served - Anyone can obtain an assigned number, so
           long as they provide a point of contact and a brief
           description of what the value would be used for.  For
           numbers, the exact value is generally assigned by the IANA;
           with names, specific names are usually requested.

           Examples: vnd. (vendor assigned) MIME types [MIME-REG], TCP
           and UDP port numbers.

   (I don't believe this is what we want here.)


      Expert Review - approval by a Designated Expert is required.

   (Close but I think the others above are better.)


      Specification Required - Values and their meaning must be
           documented in an RFC or other permanent and readily available
           reference, in sufficient detail so that interoperability
           between independent implementations is possible.

           Examples: SCSP [SCSP]

    (Perhaps this fits the 128..191] space?)


      IESG Approval - New assignments must be approved by the IESG, but
           there is no requirement that the request be documented in an
           RFC (though the IESG has discretion to request documents or
           other supporting materials on a case-by-case basis).

    (Or perhaps this fits?)


For the Disconnect Codes, I can propose this text:

   Requests for assignments of new disconnect codes in the range of 1 to
   255 MUST be done through the "IETF Consensus" method as described in
   [RFC2434].  Disconnect codes will be assigned sequentially.


>
> However, it is desirable to be able to carry out development and
> experimentation, and to deploy site-local (private) extensions, without
> allocating a globally-unique message number from IANA.  This is particular
> true because the space available is limited, and so we can't afford to have
> a couple hundred sites each have a globally-unique number allocated for
> their experimental extension.  The solution is the "Local Extensions"
> range, which is effectively a range of numbers guaranteed not to be
> assigned by IANA or used by the IETF.  Thus it is safe to use these numbers
> for local extensions without fear of colliding with a number allocated for
> a new standard feature.  Of course you don't get a guarantee of not
> colliding with a number allocated by another site, but that's what you get
> with a limited namespace.  In practice, this usually does not turn out to
> be a problem.

Then do we want to partition the Disconnect Code name space?  Perhaps
[1..191] are allocated via the "IETF Consensus" methods and [192..255] are
for "Private Use"?

Thanks,
Chris