Re: I-D ACTION:draft-ietf-secsh-transport-18.txt

[Bill Sommerfeld <sommerfeld%east.sun.com@localhost>]

> I don't understand why new changes are being made to the drafts again
> - I was under the impression that they were just about ready for
> publication. Can someone more familiar with the process please explain
> what stands in the way of this happening?

The documents are currently under review by the IESG.

Any changes at this point should be primarily driven by comments from
the IESG, which can be found in the IETF draft tracker at:
	
	https://datatracker.ietf.org/public/pidtracker.cgi

Enter "secsh" in the WG acronym field) and hit "SEARCH".

Then pick a document, click on DETAIL to see its history.

In the Detail Info section, click on "IESG evaluation record" to see
IESG comments.

> The new text in Section 4.2 includes:
> 
> >    Since the protocol being defined in this set of documents is version
> >    2.0, the 'protoversion' MUST be "2.0".  
> 
> Which renders several deployed implementations non-compliant and
> is contradictory with section 5.1:
> 
> >    Server implementations MAY support a configurable "compatibility"
> >    flag that enables compatibility with old versions.  When this flag is
> >    on, the server SHOULD identify its protocol version as "1.99".
> >    Clients using protocol 2.0 MUST be able to identify this as identical
> >    to "2.0".  In this mode the server SHOULD NOT send the carriage
> >    return character (ASCII 13) after the version identification string.
> 
> I suggest that the old text be restored or the validity of offering
> a protocol version of 1.99 be mentioned in section 4.2.
> 
Chris: can you clarify the intent of this change?  It appears to be
part of an attempt to respond to the following IESG comments:

    2. Section 3.3. This is clearly here to allow servers to interoperate with
    SSH version 1. However, there is no specification for SSHv1. The WG decided
    to not document SSHv1, even as an informational RFC. There are many SSHv1
    implementations, and at least one very large vendor has no intention of
    moving to SSHv2. A reference to some kind of SSHv1 specification is needed
    to provide context.

and
	
    4. Page 6, first paragraph. The SHOULD NOT conflicts with the MUST at the
    bottom of page 4. Suggestion: change the MUST at the bottom of page 4 to
    SHOULD.

(these may be a bit tricky to follow as sections were renumbered in
-17)

As Damien says, this is creating an internal inconsistancy within the document.

I suggest changing the "MUST" to something along the lines of:

    the 'protoversion' SHOULD be "2.0" unless the 
    compatibility flag described in section 5.1 is enabled.

Regarding a stable reference, 	

    For those interested, the SSH 1.x protocol.  The only known
   documentation of the 1.x protocol is contained in README files that
   are shipped along with the source code.

In section 5.0, I think we can generate a formal reference along the
lines of "The file named RFC within ftp://.../ssh-1.2.x.tar.gz";
given a suitably stable URL..

						- Bill