Re: Message Numbers and Disconnect Codes

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

Hi,

On Sun, 26 Sep 2004, [ISO-8859-1] Henrick Hellström wrote:

> Jeffrey Hutzelman wrote:
>
> > On Friday, September 24, 2004 10:25:01 -0600 Joseph Galbraith
> > <galb-list%vandyke.com@localhost> wrote:
> >
> >> This example implies that in the channel_open /
> >> channel_open_failure case we may want three ranges:
> >>
> >> 0x0000 0000 - 0xFDFF FFFF        IETF / connection layer
> >>
> >> 0xFE00 0000 - 0xFEFF FFFF        channel-type specific, numbers
> >> from this range for channel-types with @domain in their names are
> >> defined by the maintainer of the @domain.  For channel-types
> >> without an @domain are defined by IETF action, and these numbers
> >> are allocated by IANA.  This registery is currently empty for all
> >> IETF defined channel-types.
> >>
> >> 0xFF00 0000 - 0xFFFF FFFF        private range, used any way
> >> implemention wants, may not interoperate with other non-standard
> >> implementations, but will never conflict with a standard
> >> implementation.

Are there any objections to this allocation scheme?  If not, I'll use it
for the Disconnection Code 'reason code's and as the model for other
uint32 ranges.


> >
> >
> > Good, except we shouldn't set an allocation policy for the
> > channel-type-specific range.  It is up to the channel type to define
> > the meaning of these values and to establish a registry if one is
> > appropriate (I expect it will frequently not be needed, just as we
> > don't establish separate registries for the method-specific message
> > type ranges).

A reservation of the range is appropriate but it won't be a registry.
If the range 0xFE000000..0xFEFFFFFF is not for IETF registered codes then
it won't be appropriate to ask the IANA to maintain a registry.

Let me propose an example just to make sure that we're all on the same
page with this.

Let's say that some router company comes up with a great channel-type for
thingees between routers, which we'll call "greatchannel%routerco.com@localhost".
We can also say that it will use all of the IETF-defined Disconnection
Code 'reason code's plus an additional one locally defined as 0xFE000000.

Let's also say that a wonderful channel-type is defined specifically for
linux devices by some linux producer, which we'll call
"wonderchannel%linuxco.org@localhost".  We can also say that it will use all of the
IETF-defined Disconnection Code 'reason code's plus one additional one
locally defined as 0xFE000000.  Which is the same 'reason code' as that
defined by routerco.com.

While these are maintained at the whims of their respective organizations,
others may choose to utilize them; other manufacturors of routers may also
use the channel defined as "greatchannel%routerco.com@localhost", and other linux
producers may also decide to use "wonderchannel%linuxco.org@localhost".

>
> Right, but at a minimum the RFC should state that channel-type specific
> numbers or private numbers MUST NOT be sent unless a channel with
> @domain in its name has been requested.
>
> The same restriction should be applied to disconnect reason codes: They
> MUST NOT be sent unless the peers have previously negotiated a domain
> specific protocol feature (such as keyagreement@domain or service@domain).
>
> Any numeric code in a private range SHOULD be administrated by the
> entity that owns the @domain of the previously negotiated protocol
> feature. The specification of the domain specific feature MIGHT add
> further restrictions and implementations SHOULD respect these
> restrictions to avoid interoperability problems.

If Otherrouter, Inc. (owner of the domain otherrouter.com) uses the
channel of ""greatchannel%routerco.com@localhost" but they want to additionally
define another Disconnection Code 'reason code', then they have 3 ways to
try to do it:
 - get routerco.com to add it in (they would have to support it as well)
 - define a new channel-type as "greatchannel%otherrouter.com@localhost" with the
   new 'reason code'
 - produce an RFC that will define the new channel (superseding
   "greatchannel@*.com") along with all of the Disconnection Code 'reason
   code's.


>
> Also note that the phrase...
>
> >> 0xFF00 0000 - 0xFFFF FFFF        private range, used any way
> >> implemention wants, may not interoperate with other non-standard
> >> implementations, but will never conflict with a standard
> >> implementation.
>
> ...is illogical. If the standard states that an implementation MIGHT use
> numbers in the private range, and the implementation does use numbers in
> the private range, then the implementation *is* standard compliant. (I
> hope this point is made clear by the paragraphs I wrote above.)
>

If all of the above is as everyone expects, then I'll work in the
appropriate language.


Thanks,
Chris