Re: Message Numbers and Disconnect Codes (fwd)

[nisse%lysator.liu.se@localhost (Niels Möller)]

Chris Lonvick <clonvick%cisco.com@localhost> writes:

Sorry, but I still find this utterly confusing.

> I was saying that the IANA can control values for 'channel type' of
                                         ^^^^^^
> "session" and even "session%example.com@localhost", as long as "session%example.com@localhost"
> is registered with the IANA through an RFC - even an Informational RFC.

Exactly what "values" are you talking about here?

 1. Channel type id:s, example: "session"?

 2. Channel request type id:s, example: "pty-req"?

 3. Channel open failure reason codes in the "IETF / connection layer"
    range (0x0000 0000 - 0xFDFF FFFF), example: 0x0000 0001?

 4. Channel open failure reason codes in the "channel-type specific"
    range (0xFE00 0000 - 0xFEFF FFFF), example: 0xFE00 0017?

None of the alternatives make much sense to me (in particular, any
IANA registration of the id "session%example.com@localhost" seems absurd), but
I'd like to know exactly which values you are talking about before I
write more about it.

> From that:
> 
> > > >> > >> 0x0000 0000 - 0xFDFF FFFF        IETF / connection layer
> "session" and "foo%example.com@localhost" get to use this range (as long as any
> 'reason code' values have been registered with the IANA through an RFC
> action).

Ok, I only have one clarification: These reason codes should have a
meaning that is reasonably independent of any particular channel-type.
Ideally, the definition of any code in this range should not refer to
any particular channel type, except possibly for examples. Currently
defined values have this character, including SSH_OPEN_CONNECT_FAILED,
which is applicable to all the channel types which perform some kind
of forwarding.

> > > >> > >> 0xFE00 0000 - 0xFEFF FFFF        channel-type specific,
> "bar%example.com@localhost" gets to use this range.  Others may choose to also use
> "bar%example.com@localhost" and honor the associated codes.  These are not
> registered with the IANA.

Ok. Values in this range are defined in the specification for the
corresponding channel type.

> > > >> > >> 0xFF00 0000 - 0xFFFF FFFF        private range, used any way
> No one cares what is used in this range and it will not be honored by
> others.  There's also nothing to register with the IANA.

Ok.

Regards,
/Niels