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

From: Chris Lonvick <[email-masked]>
Date: Wed, 9 Nov 2005 18:30:12 -0800 (PST)

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 <[email-masked]>
To: [email-masked], [email-masked]
Cc: RFC Editor <[email-masked]>, Russ Housley <[email-masked]>,
     Sam Hartman <[email-masked]>, [email-masked]
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