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.
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) <jhutz+%cmu.edu@localhost> Sr. Research Systems Programmer School of Computer Science - Research Computing Facility Carnegie Mellon University - Pittsburgh, PA