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

[Chris Lonvick <clonvick%cisco.com@localhost>]

Hi,

On Fri, 4 Jun 2004, Bill Sommerfeld wrote:

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

That's correct.  I've also placed it here:
  http://www.employees.org/~lonvick/secsh-wg/may19/transport-16-18.html

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

Doh!  That wasn't my intent.  I was hoping to say that you MUST have "2.0"
for _this_ protocol but you MAY have "1.99" for backwards compatibility.

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

I'll work on that.


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

I'll get that into the Informational References section.


All:  I really do need feedback on any changes that are made.  These
changes need to appease the IESG reviewers _AND_ they need to be
technically correct.  The goal of the IESG in this is to ensure that we
produce a quality document that is very clear even to someone reading it
for the first time without any background in the subject.  This is really
required for a Standards Track RFC.  They, and ourselves, would also like
to get this done fairly quickly as they are creating a backlog - not only
for our documents but also for things relying upon SSH such as the NetConf
WG documents.

Keep those cards 'n letters comin' in.  :-)

Thanks,
Chris