Re: Core Drafts

[Markus Friedl <markus%openbsd.org@localhost>]

On Wed, Nov 14, 2001 at 09:51:17AM -0800, Darren Moffat wrote:
> 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.

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.