Subject: I-D ACTION:draft-ietf-secsh-transport-10.txt

From: [email-masked]
Date: Mon, 19 Nov 2001 08:33:12 -0500

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Secure Shell Working Group of the IETF.

	Title		: SSH Transport Layer Protocol
	Author(s)	: T. Ylonen, T. Kivinen, M. Saarinen, 
                          T. Rinne, S. Lehtinen
	Filename	: draft-ietf-secsh-transport-10.txt
	Pages		: 27
	Date		: 16-Nov-01
	
SSH is a protocol for secure remote login and other secure network
services over an insecure network.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-secsh-transport-10.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-secsh-transport-10.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-secsh-transport-10.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Joseph Galbraith" <[email-masked]>
Date: Mon, 19 Nov 2001 10:27:56 -0700

Transport draft:

o In section 4.2, at the bottom there is an empty reference.
  (Right above the start of section 4.3) :

  "Additional methods may be defined as specified in ."

Connection Draft:

o As Markus has noted, the connection draft is broken
  in section 5.1; we can do one of several things:

  1. Remove the new text; revert to SSH_MSG_REQUEST_SUCCESS

  2. Define a message number for SSH_MSG_GLOBAL_REQUEST_SUCCESS,
     and give it a flexible format, i.e.,

     byte SSH_MSG_GLOBAL_REQUEST_SUCCESS
     string "response-name"
     ... response specific data

     in addition, for "tcpip-forward", specify that
     this response should only be sent if the bind
     request is for port 0; otherwise SSH_MSG_REQUEST_SUCCESS
     should be sent.

  3. Specify that SSH_MSG_REQUEST_SUCCESS has the format:

     byte SSH_MSG_REQUEST_SUCCESS
     ... response specific data

     where the response specific data is usually non-existent.

     And specify for "tcpip-forward" request, that
     if and only if the request port is 0, the
     response look like:

     byte   SSH_MSG_REQUEST_SUCCESS
     uint32 port that was bound on the server

  I would prefer 3; Markus has expressed a strong
  preference for 1.

  If anyone else has an opinion on the matter,
  can you please speak up?

  I would like to have this included, but more than
  that, I would love to have a version of the
  draft that we can go to last call with.

  Is there any chance we can get these fixes in
  this week, and resubmitted, so we can have
  version of the draft that is a candidate for
  last call?

All drafts:

o I believe the references section needs to be updated
  to refer to the new versions of the companion drafts --
  they are still referring to the previous version number.

- Joseph

---

From: [email-masked] (Niels Möller)
Date: 20 Nov 2001 13:58:48 +0100

>   If anyone else has an opinion on the matter,

The change you propose is small, clean, and backwards-compatible for
all cases I care about. So it looks good to me.

I think larger changes should wait until we want to bump the protocol
version number.

/Niels

---

From: Markus Friedl <[email-masked]>
Date: Tue, 20 Nov 2001 20:38:09 +0100

>   I would prefer 3; Markus has expressed a strong

well, i agree with #3.

then we can change:
   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.
to
   The recipient will respond to this message with
   SSH_MSG_REQUEST_SUCCESS or SSH_MSG_REQUEST_FAILURE
   if `want reply' is TRUE.

>   draft that we can go to last call with.

so do i. we really should move on.

-m