Subject: Re: Message Numbers and Disconnect Codes (fwd)

From: Chris Lonvick <[email-masked]>
Date: Fri, 8 Oct 2004 10:41:15 -0700 (PDT)

Hi,

I'm working-in the text for this and need some clarification.

In [CONNECT], we describe the opening of a channel.  This message has the
format of:
     byte      SSH_MSG_CHANNEL_OPEN
     string    channel type in US-ASCII only
     uint32    sender channel
     uint32    initial window size
     uint32    maximum packet size
     ... channel type specific data follows
where the 'channel type' "is a name as described in [SSH-ARCH] and
[SSH-NUMBERS], with similar extension mechanisms."  (Not much to go on
there.)

Further in the document, we say, "Many 'channel type' values have
extensions that are specific to that particular 'channel type'.  An
example is requesting a pty (pseudo terminal) for an interactive session."

And still further in the document, we define "pty-req" as a specific
'channel type'.  As it is, we need to have the IANA set up a registry for
'channel type' values with the only current entry being "pty-req".  We
also need to tell the IANA that additional 'channel type' values may be
added through some mechanism.  I'll suggest that the mechanism be the IETF
CONSENSUS method [RFC 2434] but plese let me know if it should be "FIRST
COME FIRST SERVED", "EXPERT REVIEW", "SPECIFICATION REQUIRED", "IESG
APPROVAL", or "STANDARDS ACTION".  This is the IANA controlled namespace
which, as Jeffrey notes below, may contain the "@example.com" extension
space if they are defined through an appropriate method.  Having the
method be IETF CONSENSUS allows an Informational RFC to add an entry to
the IANA Registry.

Most importantly, are there any other 'channel type' values that need to
be defined in this initial registry?

Thanks,
Chris

On Mon, 27 Sep 2004, Jeffrey Hutzelman wrote:

>
>
> On Monday, September 27, 2004 13:45:59 +0200 Niels Möller
> <[email-masked]> wrote:
>
> > Chris Lonvick <[email-masked]> writes:
> >
> >> > >> 0x0000 0000 - 0xFDFF FFFF        IETF / connection layer
> >> > >> 0xFE00 0000 - 0xFEFF FFFF        channel-type specific,
> >> > >> 0xFF00 0000 - 0xFFFF FFFF        private range, used any way
> >
> >> 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.
> >
> > Note that the above scheme is applicable only to the reason codes in
> > SSH_MSG_CHANNEL_OPEN_FAILURE.
>
> Right; the channel-type-specific range makes sense only for messages which
> occur in the context of a particular channel.  Global mesasges like
> SSH_MSG_DISCONNECT cannot be associated with any particular channel, and
> should not define this range.
>
>
> Note that there is no reason to restrict the use of the 0xFE range to
> privately-defined channel types.  It is IMHO entirely reasonable for a
> standards-track channel type to defined a channel-type-specifc code.  Such
> a code would be specified in the document defining the channel type and
> would be drawn from the 0xFE range, without regard to use of codes in that
> range by other channel types.
>
> -- Jeffrey T. Hutzelman (N3NHS) <[email-masked]>
>    Sr. Research Systems Programmer
>    School of Computer Science - Research Computing Facility
>    Carnegie Mellon University - Pittsburgh, PA
>
>

---

From: der Mouse <[email-masked]>
Date: Sun, 10 Oct 2004 01:53:05 -0400 (EDT)

> 'channel type'.

That doesn't sound right.  I thought it was a channel *request* type.

As I read it, the defined connection types are "session", "x11",
"forwarded-tcpip", and "direct-tcpip".  At least in connect-19.

Note that "pty-req" is listed in assignednumbers-06 in 4.2.2.3, not
4.2.2.1.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       [email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: Chris Lonvick <[email-masked]>
Date: Sun, 10 Oct 2004 19:25:15 -0700 (PDT)

Hi,

> That doesn't sound right.  I thought it was a channel *request* type.

Doh!  You're right.  "pty-req" is defined as a value for 'request type' in
a SSH_MSG_CHANNEL_REQUEST packet type in [NUMBERS].

> "forwarded-tcpip", and "direct-tcpip".  At least in connect-19.

Got it.  Those are the values for the 'channel type' in
SSH_MSG_CHANNEL_OPEN packets.

> Note that "pty-req" is listed in assignednumbers-06 in 4.2.2.3, not

Yup.  I'm going to duplicate the tables from [NUMBERS] into [CONNECT].  I
believe that I got confused from this paragraph in [CONNECT].
   Many channel types have extensions that are specific to that
   particular channel type.  An example is requesting a pty (pseudo
   terminal) for an interactive session.
I made the intellectual leap that a "pty-req" was a 'channel type'.
Thanks for the corection.  :)

As far as the pointers in [NUMBERS], I'm going to make sure that all else
is straightened out and then I'll go back and get the pointers straight.

Thanks,
Chris

---

From: [email-masked] (Niels Möller)
Date: 11 Oct 2004 22:50:43 +0200

> [SSH-NUMBERS], with similar extension mechanisms."  (Not much to go on

I think the intention is fairly clear. Names like "[email-masked]" can be
defined by whoever owns the "example.com" domain. Names without "@"
in them needs standardization.

> example is requesting a pty (pseudo terminal) for an interactive session."

channel types and channel request types are different. But I think the
intention is that they should live in one single name space. So if
"pty-req" is a channel request type, that name should not be reused
for a channel type. And a channel request type like "pty-req" is
intended to imply *one* operation, with *one* format for the
corresponding message.

Currently, the channel type "session" is the only standardized channel
type where "pty-req" make sense.

But it is fully possible to define a new channel type, say
"[email-masked]", where the request type "pty-req" is also
meaningful. It is however *not* approproate to define a new channel
type "[email-masked]", and say that for channels of this type,
"pty-req" has a different unrelated meaning, or that requests of type
"pty-req" should use a different format.

That is my understanding of the spec, do you agree with this? I know
it's technically possible to let "pty-req" have a totally different
meaning and a totally different request format for each channel type
(like we do for the numerical open failure codes), but I don't think
that's how the name space is intended to be used.

> I'll suggest that the mechanism be the IETF CONSENSUS method [RFC
> 2434]

I think "IETF CONSENSUS" is reasonable, since the namespace is for all
practical purposes unlimited, but we still want some level of review
to keep the namespace from cluttering up.

> This is the IANA controlled namespace which, as Jeffrey notes below,
> may contain the "@example.com" extension space if they are defined
> through an appropriate method.

I can make no sense out of this comment. I think the context for
Jeffrey's comment was the allocation of the *numerical* reason codes
in SSH_MSG_CHANNEL_OPEN_FAILURE, where the point was that the
specification for any channel type (no matter if it's standardized or
a local "[email-masked]" type) can allocate open failure codes from
the "channel-type specific" range in

> > >> > >> 0xFF00 0000 - 0xFFFF FFFF        private range, used any way

Regards,
/Niels

---

From: Chris Lonvick <[email-masked]>
Date: Tue, 12 Oct 2004 05:11:55 -0700 (PDT)

Hi,

> the "channel-type specific" range in

I was saying that the IANA can control values for 'channel type' of
"session" and even "[email-masked]", as long as "[email-masked]"
is registered with the IANA through an RFC - even an Informational RFC.

> > >> > >> 0x0000 0000 - 0xFDFF FFFF        IETF / connection layer
"session" and "[email-masked]" get to use this range (as long as any
'reason code' values have been registered with the IANA through an RFC
action).

> > >> > >> 0xFE00 0000 - 0xFEFF FFFF        channel-type specific,
"[email-masked]" gets to use this range.  Others may choose to also use
"[email-masked]" and honor the associated codes.  These are not
registered with the IANA.

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

Make sense?

Thanks,
Chris

---

From: [email-masked] (Niels Möller)
Date: 12 Oct 2004 15:33:35 +0200

Sorry, but I still find this utterly confusing.

> I was saying that the IANA can control values for 'channel type' of
                                         ^^^^^^
> 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 "[email-masked]" seems absurd), but
I'd like to know exactly which values you are talking about before I
write more about it.

> 'reason code' values have been registered with the IANA through an RFC

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.

> registered with the IANA.

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

> others.  There's also nothing to register with the IANA.

Ok.

Regards,
/Niels

---

From: Chris Lonvick <[email-masked]>
Date: Wed, 13 Oct 2004 19:57:00 -0700 (PDT)

Hi Niels,

> Exactly what "values" are you talking about here?

I'd like to try to clarify the "parameter" from the 'value' that fills the
"parameter" in the packet in the documents.  Currently, there are places
where the characters of ` and ' set off the 'values', and in other places,
nothing sets off the values.  I'd like to make that consistent throughout
the documents.  Do these examples work:

-------current text in [CONNECT]--------
   There are several kinds of requests that affect the state of the
   remote end "globally", independent of any channels.  An example is a
   request to start TCP/IP forwarding for a specific port.  All such
   requests use the following format.

     byte      SSH_MSG_GLOBAL_REQUEST
     string    request name in US-ASCII only
     boolean   want reply
     ... request-specific data follows

   Request names follow the DNS extensibility naming convention outlined
   in [SSH-ARCH].
----------------------------------------
"Request names" in the last sentence is not distinguished.

-------proposed text in [CONNECT]-------
   There are several kinds of requests that affect the state of the
   remote end globally, independent of any channels.  An example is a
   request to start TCP/IP forwarding for a specific port.  All such
   requests use the following format.

     byte      SSH_MSG_GLOBAL_REQUEST
     string    request name in US-ASCII only
     boolean   want reply
     ... request-specific data follows

   The value of 'request name' follows the DNS extensibility naming
   convention outlined in [SSH-ARCH].
------------------------------------------
'request name' is denoted as a parameter.

In another place:
-------current text in [CONNECT]--------
   If want reply is FALSE, no response will be sent to the request.
   Otherwise, the recipient responds with either SSH_MSG_CHANNEL_SUCCESS
   or SSH_MSG_CHANNEL_FAILURE, or request-specific continuation
   messages.  If the request is not recognized or is not supported for
   the channel, SSH_MSG_CHANNEL_FAILURE is returned.
----------------------------------------
I first thought that the first sentence was a grammatical error. :)

-------proposed text in [CONNECT]-------
   If 'want reply' is FALSE, no response will be sent to the request.
   Otherwise, the recipient responds with either SSH_MSG_CHANNEL_SUCCESS
   or SSH_MSG_CHANNEL_FAILURE, or request-specific continuation
   messages.  If the request is not recognized or is not supported for
   the channel, SSH_MSG_CHANNEL_FAILURE is returned.
----------------------------------------
This qualifies 'want reply' as a parameter.

Does this clarify things?  Does anyone have a better suggestion?

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

Yes.  The values are in the left-hand column in the table in Section
4.2.2.1 in [NUMBERS]-06.  They are "session", "x11", "forwarded-tcpip",
and "direct-tcpip".

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

Yes.  Section 4.2.2.3 in [NUMBERS]-06.

>     range (0x0000 0000 - 0xFDFF FFFF), example: 0x0000 0001?

Yes.  This will be included in the next set of IDs.

>     range (0xFE00 0000 - 0xFEFF FFFF), example: 0xFE00 0017?

Yes.  This will be included in the next set of IDs.

> I'd like to know exactly which values you are talking about before I

Sorry.  I took my finger off of the statement in [ARCH] where we say that
names that contain the "@" character will not be registered with the IANA;
Section 6 in [ARCH]-16 and in various places in [NUMBERS]-06.  (Which is
why I ask for clarification. :)

> > 'reason code' values have been registered with the IANA through an RFC

Change that.  It should be
     0x0000 0000 - 0xFDFF FFFF        IETF / connection layer
     "session" and the other values will use this range as long as they
     are registered with the IANA through an RFC action.

> which is applicable to all the channel types which perform some kind

OK.  That should just be a few sentences in the appropriate places.  Does
anyone disagree with this?

Thanks,
Chris