authors 48 hours: RFC 4254 <draft-ietf-secsh-connect-25.txt> NOW AVAILABLE (fwd)

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

Last one.

===

1)
Section 1, first paragraph
- insert references
OLD:
   SSH transport layer and user authentication protocols.  It provides
NEW:
   SSH transport layer and user authentication protocols ([SSH-TRANS] and
   [SSH-USERAUTH]).  It provides...



2)
Section 1, first paragraph
- The last sentence needs to be a separate paragraph (consistent with
  [SSH-USRAUTH]
OLD:
   TCP/IP connections, and forwarded X11 connections.  The service name
   for this protocol is "ssh-connection".
NEW:
   TCP/IP connections, and forwarded X11 connections.

   The 'service name' for this protocol is "ssh-connection".



3)
Section 4, packet definition after third paragraph
- change five dots to four
OLD:
      .....     response specific data
          ^
NEW:
      ....      response specific data



4)
Section 5.1, packet definition after fourth paragraph
- remove unneeded words
OLD:
      string    language tag as defined in [RFC3066]
                             ^^^^^^^^^^^^^^
NEW:
      string    language tag [RFC3066]


5)
Section 5.1, seventh paragraph
- add a comma to a line
OLD:
   to 0xFDFFFFFF MUST be done through the IETF CONSENSUS method as
NEW:
   to 0xFDFFFFFF MUST be done through the IETF CONSENSUS method, as
                                                               ^


6)
Section 5.1, seventh paragraph
- add a comma to a line
OLD:
   range are left for PRIVATE USE as described in [RFC2434].
NEW:
   range are left for PRIVATE USE, as described in [RFC2434].
                                 ^


7)
Section 5.2, fourth paragraph
- replace the paragraph
OLD:
   The maximum amount of data allowed is the current window size.  The
   window size is decremented by the amount of data sent.  Both parties
   MAY ignore all extra data sent after the allowed window is empty.
NEW:
   The maximum amount of data allowed is determined by the maximum
   packet size for the channel, and the current window size, whichever
   is smaller.  The window size is decremented by the amount of data
   sent.  Both parties MAY ignore all extra data sent after the allowed
   window is empty.

   Implementations are expected to have some limit on the ssh
   transport layer packet size (any limit for rececived packets MUST
   be 32768 bytes or larger, as described in [SSH-TRANS]). The
   implementation of the SSH connection layer

   o   MUST NOT advertise a maximum packet size that would result in
       transport packets larger than its transport layer is willing to
       receive.

   o   MUST NOT generate data packets larger that its transport layer is
       willing to send, even if the remote end would be willing to
       accept very large packets.



8)
Section 5.2, last paragraph
- add a comma to a line
OLD:
   'data_type_code' values in that range are left for PRIVATE USE as
NEW:
   'data_type_code' values in that range are left for PRIVATE USE, as
                                                                 ^


9)
Section 6.5, next to last paragraph
- replace the paragraph
OLD:
   It is RECOMMENDED that the reply for these messages be requested and
   checked .  The client SHOULD ignore these messages.
NEW:
   It is RECOMMENDED that the reply to these messages be requested and
   checked.  The client SHOULD ignore these messages.



10)
Section 6.9, packet definition following the first paragraph
- modify a line
OLD:
      string    signal name without the "SIG" prefix.
NEW:
      string    signal name (without the "SIG" prefix)



11)
Section 6.9, last paragraph
- replace the paragraph
OLD:
   'signal names' will be encoded as discussed in the "exit-signal"
   SSH_MSG_CHANNEL_REQUEST.
NEW:
   'signal name' values will be encoded as discussed in the
   passage describing SSH_MSG_CHANNEL_REQUEST messages using
   "exit-signal" in this section.



12)
Section 6.10, packet definition following the second paragraph
- modify a line
OLD:
      string    signal name without the "SIG" prefix.
NEW:
      string    signal name (without the "SIG" prefix)



13)
Section 6.10, third paragraph
- add a period to the line
OLD:
   The 'signal name' is one of the following (these are from [POSIX])
NEW:
   The 'signal name' is one of the following (these are from [POSIX]).
                                                                     ^


14)
Section 6.10, fourth paragraph
- do not break a hyphen segmented name
OLD:
   Additional 'signal name' values MAY be sent in the format "sig-
   name@xyz", where "sig-name" and "xyz" may be anything a particular
NEW:
   Additional 'signal name' values MAY be sent in the format
   "sig-name@xyz", where "sig-name" and "xyz" may be anything a particular



15)
Section 6.10, fourth paragraph
- correct spelling
OLD:
   implementor wants (except the "@" sign).  However, it is suggested
            ^
NEW:
   implementer wants (except the "@" sign).  However, it is suggested



16)
Section 6.10, last paragraph
- add a clause to a line
OLD:
   error message.  The message may consist of multiple lines.  The
NEW:
   error message.  The message may consist of multiple lines separated
   by CRLF (Carriage Return - Line Feed) pairs.  The...



17)
Section 7.2, SSH_MSG_CHANNEL_OPEN packet definition
- do not split this across a page break



18)
Section 7.2, fifth paragraph
- replace the paragraph
OLD:
   The 'originator IP address' is the numeric IP address of the machine
   where the connection request comes from, and the 'originator port' is
   the port on the host from where the connection originated.
NEW:
   The 'originator IP address' is the numeric IP address of the machine
   from where the connection request originates, and the 'originator
   port' is the port on the host from where the connection originated.



19)
Section 8, first two paragraphs
- combine the paragraphs into a single paragraph with clarification
OLD:
   All "encoded terminal modes" (as passed in a pty request) are encoded
   into a byte stream.  It is intended that the coding be portable
   across different environments.

   The tty mode description is a stream of bytes.  The stream consists
   of opcode-argument pairs wherein the opcode is a byte value.  It is
   terminated by opcode TTY_OP_END (0x00).  Opcodes 1 to 159 have a
   single uint32 argument.  Opcodes 160 to 255 are not yet defined, and
   cause parsing to stop (they should only be used after any other
   data).
NEW:
   All 'encoded terminal modes' (as passed in a pty request) are encoded
   into a byte stream.  It is intended that the coding be portable
   across different environments.  The stream consists of
   opcode-argument pairs wherein the opcode is a byte value.  Opcodes 1
   to 159 have a single uint32 argument.  Opcodes 160 to 255 are not yet
   defined, and cause parsing to stop (they should only be used after
   any other data).  The stream is terminated by opcode TTY_OP_END
   (0x00).



20)
Section 8, table of opcodes
- replace the argument header
OLD:
          opcode  argument       description
                  ^^^^^^^^
NEW:
          opcode  mnemonic       description

===


That's all, folks!

---------- Forwarded message ----------
Date: Wed, 26 Oct 2005 16:15:09 -0700
From: RFC Editor <rfc-editor%rfc-editor.org@localhost>
To: ylo%ssh.com@localhost, clonvick%cisco.com@localhost
Cc: RFC Editor <rfc-editor%rfc-editor.org@localhost>, Russ Housley <housley%vigilsec.com@localhost>,
    Sam Hartman <hartmans-ietf%mit.edu@localhost>, sommerfeld%sun.com@localhost
Subject: authors 48 hours: RFC 4254 <draft-ietf-secsh-connect-25.txt> NOW
    AVAILABLE

****IMPORTANT*****

Updated 2005/10/26

RFC AUTHOR(S):
--------------

This is your LAST CHANCE to make changes to your RFC to be:
draft-ietf-secsh-connect-25.txt, once the document is published as
an RFC we *WILL NOT* make any changes.

Please check your document at

   ftp://ftp.rfc-editor.org/in-notes/authors/rfc4254.txt

ATTENTION: The editing process occasionally introduces errors that
were not in the Internet Draft.  Although the RFC Editor tries very
hard to catch all errors, proofreading the text at least twice, typos
can slip through.  You, as an author of the RFC, are taking
responsibility for the correctness of the final product when you OK
publication.  You should therefore proofread the entire RFC carefully
and without assumptions.  Errors in RFCs last forever.

NOTE: We have run a diff tool that compares the approved internet-draft
against our edited RFC version of the document.  Please review this
file at:

   ftp://ftp.rfc-editor.org/in-notes/authors/rfc4254-diff.html

The document will NOT BE PUBLISHED until ALL of the authors listed in
the RFC have affirmed that the document is ready to be
published, as ALL of the authors are equally responsible for verifying
the documents readiness for publication.

** Please send us a list of suitable keywords for this document, over
and above those which appear in the title.

	Frequently INCORRECT information includes

	- Contact Information
	- References (are they up to date)
	- Section Numbers
	  (especially if you originally put the copyright somewhere
	  other than the VERY end of the document, or if you numbered
	  the "Status of the Memo" field)

Please send us the changes, *DO NOT* send a new document with the
changes made.  (If we think that the changes might be more than
editorial we will contact the AD or the IESG to confirm that the
changes do not require review.)

Send us the changes in THIS format.

	1)*** SECTION #'s***  [i.e. Section 5, 2nd paragraph]
	2) the text you want changed,
	3) the new correct text and
	4) if the changes are spacing or indentation than please note
	   that.

FOR EXAMPLE:

	Section 5.6, 3rd paragraph

 	OLD:
		The quick brown fox jumped over the lazy dog.

	NEW:
		The quick brown dog jumps over the lazy fox.
				^^^     ^               ^^^

If you have a whole paragraph to replace you do not need to use
the arrow to point out the differences

	INTRODUCTION, 2nd paragraph

	Replace OLD:

		alsdfja;sldjf;lajsd;fljas;dlfj;

	With NEW:

		nv;alkjd;lsf;aoisj;ltjka;sldkjf


Spacing or indentation problems...

	Section 10, 1st paragraph (remove spaces between bit
	and of, add space after butter)

	OLD:

	Better botter bought a bit
		of bitter butterMary mary quite contrary

	NEW:

	Better botter bought a bit of bitter butter

	Mary mary quite contrary


This document will NOT be published until we receive agreement, from
ALL listed authors, that the document is ready for publication.

Thanks for your cooperation,


-RFC Editor