Subject: Core Drafts

From: Darren Moffat <[email-masked]>
Date: Wed, 14 Nov 2001 09:51:17 -0800 (PST)

I haven't had any comments yet on the latest revisions of the 4 core
drafts I sent out last week.  If there are no comments by Friday 16th
at 1200 PST I will be sumbitting these as the working groups latest
drafts.

--
Darren J Moffat

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 14 Nov 2001 13:04:37 -0500

> at 1200 PST I will be sumbitting these as the working groups latest

Actually, send them in now.

					- Bill

---

From: Markus Friedl <[email-masked]>
Date: Wed, 14 Nov 2001 20:03:33 +0100

> Actually, send them in now.

can you send them again with fixes?

-m

---

From: Markus Friedl <[email-masked]>
Date: Wed, 14 Nov 2001 20:03:08 +0100

> at 1200 PST I will be sumbitting these as the working groups latest

draft-ietf-secsh-architecture-10.txt 
	contains &lt instead of <=

the 'connect' document contains:

   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 (restricted to US-ASCII)
     boolean   want reply
     ... request-specific data follows

   request names follow the DNS extensibility naming convention outlined
   in [SSH-ARCH]

^^^ shouldn't there be some CAPS or trailing DOTS. ?

and:

   It is RECOMMENDED to request and check the reply for these messages.
   The client SHOULD ignore these messages.

   subsystem names follow the DNS extensibility naming convention
   outlined in [SSH-ARCH]

^^^^ same here

is the message:

   The response to an SSH_MSG_GLOBAL_REQUEST is of the form:

     bytes     SSH_MSG_GLOBAL_REQUEST_SUCCESS
     string    "tcpip-forward"
     unint32   port that was bound on the server

a MUST? because this would break the currently deployed protocol,
i think. moreover, SSH_MSG_GLOBAL_REQUEST_SUCCESS is not
defined. all you can do is send a
     byte      SSH_MSG_REQUEST_SUCCESS
or
     byte      SSH_MSG_REQUEST_FAILURE

i suggest you to remove the 

   The client may send 0 as the port to bind to, in this case the server
   should interpret this as meaning it should allocate the next availble
   non privileged port and return the value in the response packet.

and

  The response to an SSH_MSG_GLOBAL_REQUEST is of the form:

     bytes     SSH_MSG_GLOBAL_REQUEST_SUCCESS
     string    "tcpip-forward"
     unint32   port that was bound on the server

since these things should be delayed after the drafts advance.

---

From: Markus Friedl <[email-masked]>
Date: Thu, 15 Nov 2001 22:16:31 +0100

> at 1200 PST I will be sumbitting these as the working groups latest

does anybody care about the drafts?

draft-ietf-secsh-connect-12.txt is currently broken, because
SSH_MSG_GLOBAL_REQUEST_SUCCESS is not defined.

the 'connect' document says about SSH_MSG_GLOBAL_REQUEST:

   The recipient will respond to this message with
   SSH_MSG_REQUEST_SUCCESS, SSH_MSG_REQUEST_FAILURE, or some request-
   specific continuation messages if `want reply' is TRUE.

i suggest to remove the "," after SSH_MSG_REQUEST_FAILURE.

moreover, if SSH_MSG_GLOBAL_REQUEST_SUCCESS is a so-called
'request-specific continuation messages' then it should have a more
'request-specific' name.

but at this point i prefer to drop the addition of 
the 'bind to 0' feature.

-m