Secure Shell core drafts ready for IESG rereview.

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

Russ,

I believe the most recent revisions of the five Secure Shell core drafts
have resolved all outstanding IESG issues and represent the consensus
of the secure shell WG.

The documents are fundamentally sound; as with any document set 
of this size we could spend unbounded time tweaking the wording.
There have been multiple independant interoperable implementations 
written from these specs.  Publishing them as Proposed Standard is 
long overdue.

I'm turning them over to you to pass to the IESG:

	draft-ietf-secsh-architecture-22
	draft-ietf-secsh-assignednumbers-12
	draft-ietf-secsh-connect-25
	draft-ietf-secsh-transport-24
	draft-ietf-secsh-userauth-27

Editorial Notes:

1) There was a trivial typo introduced in the latest round of edits,
most
obviously seen in the tools.ietf.org diff page:

http://tools.ietf.org/wg/secsh/draft-ietf-secsh-transport/draft-ietf-secsh-transport-24-from-23.diff.html

namely:

   "The "serpent128-cbc" ciphera is the same as above but with a 128-bit
key."

"ciphera" should of course be "cipher".

2) You requested that we proceed based on the assumption that the
in-room
consensus of the IPR-WG of last week would stand.

The contents of the tradmark notice are the result of my interpretation 
as an IPR-WG participant of a reasonable combination of the IPR-WG's 
apparent in-the-room consensus, and the provision in RFC3667 requiring 
the IETF to preserve trademark notices provided by contributors.  
  
Due to limitations of the xml2rfc tools used by the document editor, the
"trademark notice" section restored (in modified form) to these drafts 
appears as an Appendix rather than as an unnumbered section.

3) SHA1 is referenced as [FIPS-180-2] as we were unaware until recently
that SHA1 is also described in RFC 3174 (which includes a reference 
implementation in C combined with text from FIPS 180-2).  
Either reference alone or both together works for us.  

4) The current idnits script generates a few "weird spacing" false 
positives due to the multi-column notation used within these drafts to 
describe on-the-wire message formatting.  These should be ignored.