Subject: Message Numbers and Disconnect Codes

From: Chris Lonvick <[email-masked]>
Date: Tue, 20 Jul 2004 11:29:26 -0700 (PDT)

Hi Folks,

I'm working on adding the "@"-extension rules into [NUMBERS] and have some
questions.

The "Message Numbers" section allocates the ranges of numbers to specific
payload types - e.g.,
  1 - 19 for Transport layer generic
 20 - 29 for Algorithm negotiation
etc.
It then goes on to RESERVE the values [128..191], and then allocates
[192..255] for "Local Extensions".

However, the subsequent subsection on "Disconnect Codes" just has a
sequential list of codes with no instructions for range allocation.

My questions:

- 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 [email-masked] or [email-masked] as is defined with
the non-numbered Local Extensions.

- If we resolve that one, should we declare a range of Disconnect Codes
for Local Extensions?

Is anyone using the Local Extension Message Numbers and can they state how
they are trying to avoid interoperability problems?

Thanks,
Chris

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 20 Jul 2004 21:27:10 -0400

> 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 "[email-masked]" 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.

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.

-- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA

---

From: Chris Lonvick <[email-masked]>
Date: Wed, 21 Jul 2004 05:40:11 -0700 (PDT)

Hi,

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

> with a limited namespace.  In practice, this usually does not turn out to

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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 21 Jul 2004 11:18:42 -0400

>    255.  These are designated as "Private Use" as described in [RFC2434].

Yes, I think that pretty much captures what we're trying to do.

> [1..191] are allocated via the "IETF Consensus" methods and [192..255] are

Yes, it might be good to reserve a chunk of this space for private use.

---

From: Derek Fawcus <[email-masked]>
Date: Thu, 22 Jul 2004 10:16:04 +0100

> Yes, it might be good to reserve a chunk of this space for private use.

Well the other option would be for one code be allocated as "Private Use"
and the user then utilise the description string to demux any particular reasons.

Mind I'm not sure if it's worth the effort,  simply to save .25 of the code
space.

DF

---

From: Chris Lonvick <[email-masked]>
Date: Thu, 22 Jul 2004 08:48:16 -0700 (PDT)

Hi,

> Mind I'm not sure if it's worth the effort,  simply to save .25 of the code

We could say that 1..254 are assigned via IETF Consensus and 255 is
reserved for Private Use.  Any objections to that?

Thanks,
Chris