Subject: Re: Eyeballs needed.

From: Chris Lonvick <[email-masked]>
Date: Thu, 3 Nov 2005 06:40:17 -0800 (PST)

Hi Folks,

I appreciate the input everyone has generated so far.  I, too, am going 
through these things very carefully now (besides doing the day job, and 
trying to get ready for next week).

The process that I plan on using:

- I'll post my edits to the proto-RFCs to this list for comments before I
   submit them to the RFC Editor.  Hopefully I'll have my review done by
   this weekend.

- I'll ask the RFC Editor post new proto-RFCs for review before
   accepting, and give everyone a few days to review those.

- I'll give the WG a final heads-up before accepting.

Thanks,
Chris

On Thu, 27 Oct 2005, Bill Sommerfeld wrote:

> The RFC Editor is nearly done with the five core drafts and two of the
> extension documents, and they have now entered the "AUTH48" ("Authors 48
> hours") period.  (Which almost never lasts that little time, but I
> digress..).
>
> At this point, when the listed authors say they're done, they're done.
>
> Since these documents have been the joint work of the entire working
> group, I'd like to ask interested parties to double check the changes
> made by the RFC editor in the course of converting from internet-draft
> to RFC.
>
> As a reminder, the time for wholesale changes is long past; typos and
> accidental changes to the protocol are what we're looking to correct at
> this time.
>
> Here are the current almost-an-RFC drafts and visual diffs with the
> underlying I-D:
>
> draft-ietf-secsh-assignednumbers-12.txt:
> 	ftp://ftp.rfc-editor.org/in-notes/authors/rfc4250-diff.html
> 	ftp://ftp.rfc-editor.org/in-notes/authors/rfc4250.txt
>
> draft-ietf-secsh-architecture-22.txt:
> 	ftp://ftp.rfc-editor.org/in-notes/authors/rfc4251-diff.html
> 	ftp://ftp.rfc-editor.org/in-notes/authors/rfc4251.txt
>
> draft-ietf-secsh-userauth-27.txt:
> 	ftp://ftp.rfc-editor.org/in-notes/authors/rfc4252-diff.html
> 	ftp://ftp.rfc-editor.org/in-notes/authors/rfc4252.txt
>
> draft-ietf-secsh-transport-24.txt:
> 	ftp://ftp.rfc-editor.org/in-notes/authors/rfc4253-diff.html
> 	ftp://ftp.rfc-editor.org/in-notes/authors/rfc4253.txt
>
> draft-ietf-secsh-connect-25.txt:
> 	ftp://ftp.rfc-editor.org/in-notes/authors/rfc4254-diff.html
> 	ftp://ftp.rfc-editor.org/in-notes/authors/rfc4254.txt
>
> draft-ietf-secsh-dns-05.txt:
> 	ftp://ftp.rfc-editor.org/in-notes/authors/rfc4255-diff.html
> 	ftp://ftp.rfc-editor.org/in-notes/authors/rfc4255.txt
>
> draft-ietf-secsh-auth-kbdinteract-07.txt:
> 	ftp://ftp.rfc-editor.org/in-notes/authors/rfc4256-diff.html
> 	ftp://ftp.rfc-editor.org/in-notes/authors/rfc4256.txt
>
> Send comments either to me, or to the list as a whole; I'll review them
> and relay them to the RFC editor.
>
> 				Thanks for your time...
>
> 					- Bill
>

---

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

Hi,

On Fri, 28 Oct 2005, Jon Bright wrote:

> Bill Sommerfeld wrote:
>> ftp: //ftp.rfc-editor.org/in-notes/authors/rfc4250-diff.html
>> ftp: //ftp.rfc-editor.org/in-notes/authors/rfc4250.txt
>
> I didn't catch anything.
>
>> ftp: //ftp.rfc-editor.org/in-notes/authors/rfc4251-diff.html
>> ftp: //ftp.rfc-editor.org/in-notes/authors/rfc4251.txt
>
> There are a couple of places where I disagree with the change from "which" to 
> "that", but I guess that's a taste thing.  I'm also told that British English 
> (which I speak) tends to use "which" more than US English, so maybe it's just 
> my dialect showing through.
>
> End of section 9.3.1: "If there are no unsent packages, ..." should be "If 
> there are no unsent packets, ...".

I'll get that changed.

>
> Middle of 9.3.3: "If the session stays active long enough, however, this 
> sequence number, will wrap." - the comma added after "number" seems 
> superfluous to me.

I'll get that changed.

>
> 9.5.1: "Implementors SHOULD provide mechanisms for administrators to control 
> which services are exposed to limit the..." - seems to me there should be an 
> extra comma here: "...which services are exposed, to limit the...".

It looks OK to me without the extra comma.

> Also, 
> we're using "implementor" here (which I prefer).  But at the start of 9.4.3, 
> we have "implementer".  Hopefully no-one's going to mention hobgoblins if I 
> suggest that one or the other should be picked and used :-)

I'm going to ask for a global change s/implementor/implementer/ since the 
sections at the end use the latter.

>
> 9.5.3: The sentence beginning "It is RECOMMENDED that X11 display 
> implementations default to allow the display..." seems to me more awkward 
> after the RFC Editor's changes than it was before them.  My version would be: 
> "It is RECOMMENDED that X11 display implementations default to allowing the 
> display to be opened only over local IPC.  It is RECOMMENDED that SSH server 
> implementations that support X11 forwarding default to allowing the display 
> to be opened only over local IPC.  On single-user systems systems, it might 
> be reasonable to default to allowing the local display to be opened over 
> TCP/IP."

It looks OK to me the way it is.

>
>
> That's all I saw in -architecture.  I'll be reading the others later.

Thanks,
Chris

---

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

Hi,

On Fri, 28 Oct 2005, der Mouse wrote:

> There are numerous changes made which I either agree with or don't care
> about; I'm mentioning only the things that I would change back or do
> entirely differently.
>
> I'm restricting myself to copy-edits.  I note at least one semantic
> point, but you say it's too late for them, and it's by no means a
> catastrophic showstopper.
>
> I'm also basing this on diffs between the drafts and the proto-RFCs.  I
> may miss a few things this way, but it means I can get this done in
> hours rather than days.
>
> Section numbers are those of the proto-RFC, when they differ from those
> of the draft.
>
> 4.1, 4.2, 4.4, 4.5.2: I too would prefer "which" over "that" here, though I
> agree the difference is slight.

Again, I'm not going to address these unless someone really pushes.

>
> 4.3.4, first bullet point: I prefer "...'reason code' value consistent
> with the...".  I'd also take the last sentence out of the passive
> voice; perhaps something like "Implementors should first attempt...".

I made a change.  Please review.

>
> 4.5.2, in the description of the XCASE value: a backslash processing
> glitch has struck here:
>
> -                             equivalents with "\".
> +                            equivalents with "
>
> (Despite the indentation difference in the diff output, the new text
> looks right when viewed alone - there presumably is a tab-vs-spaces
> difference involved.)

I'll get that reinstated.

>
> 4.9.5: I think this change is wrong, unless s/Names/names/ is also
> done, and even then I don't like it.

It's more -r- less consistent with the similar paragraphs in the rest of 
the document.

>
> 4.11.1: When describing des-cbc, I see "FIPS-46-3" on one line and
> "FIPS 46-3" on the next line, apparently referring to the same
> document.  Shouldn't they both be spelled the same?

Yup.

>
> 6.2: When describing [FIPS-46-3], I'd like to see it made explicit that
> the NIST is a *USA* body; I see nothing there indicating which nation's
> National Institutes of Standards and Technology is relevant.

OK.  That's many places.  Please review to make sure I caught them all.

> 4.5, second-last paragraph: I think the original text is substantially
> better here; I think this is more like synonyms used as parenthetical
> explanation than a list of qualifiers.

OK.

>
> 5, describing a name-list: I think the last comma here needs to go (it
> was in the original; there is a change here - ; to , - but I think it's
> good).  That is, s/names, nor/names nor/.

OK.

>
> 8, last paragraph: everywhere else "as described in [RFC2434]" has been
> preceded by a comma; for consistency, I think it should be here too.

OK.

>
> 9.1: I'd
> 	s/when knowing/given/
> 	s/in properly implementing/of properly implementing/

"when knowing" can be different from "given".  I'm going to leave these.

>
> 9.2: s/messages to the user/messages, to the user/ - "such as error or
> debug messages" is an explanatory parenthesis, so it needs a comma
> after it as well as before.

I modified it.  Please check.

>
> 9.3.1, end of third paragraph: s/longer/long/

OK.

>
> 9.3.3, second paragraph: s/more so true/more true/

OK.

>
> 9.3.3, third paragraph: the editor inserted a comma into the "If the
> session stays active lojng enough" sentence; I think this comma is
> wrong and should be removed: s/sequence number,/sequence number/

Yup.

>
> 9.3.4, last paragraph: s/non-security critical/non-security-critical/.

OK.

>
> 9.3.7: shouldn't the reference to [SSH-TRANS] give an explicit section
> number instead of just saying `the section "Diffie-Hellman Key
> Exchange"'?

Nah.

>
> 9.3.9: I'd like to see s/attempts of traffic/attempts at traffic/.

OK.

>
> 10: As in 4250 section 6.2, I'd like to see the NIST explicitly called
> out as a USA body.

OK.

>
> That's all I have time for right now.  I'm going to be AFK all weekend;
> if the authors want to push them out before I get done, then, well, I
> just won't get a proofread done on the rest. :-/
>
> /~\ The ASCII				der Mouse
> \ / Ribbon Campaign
> X  Against HTML	       [email-masked]
> / \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
>

Thanks,
Chris

---

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

Hi,

On Fri, 28 Oct 2005, Jon Bright wrote:

>> ftp: //ftp.rfc-editor.org/in-notes/authors/rfc4252-diff.html
>> ftp: //ftp.rfc-editor.org/in-notes/authors/rfc4252.txt
>
> Section 5.2: "Otherwise, the server MUST return SSH_MSG_USERAUTH_FAILURE and 
> MAY return it with a list of authentication 'method name' values." - the 
> "that can continue" phrase has been lost here.  I remember recently seeing a 
> discussion about OpenSSH being unable to determine what can or cannot 
> continue and hence returning a list of all available methods - but was this 
> change in the draft desired?

Good catch.  It's been that way for some time but SSH_MSG_USERAUTH_FAILURE 
only has 'authentications that can continue' - which can only come from 
the server.

>
> Section 8, third paragraph: "Systems supporting non-ASCII passwords SHOULD 
> always normalize passwords and user names whenever they are added to the 
> database, or compare them (with or without hashing) to existing entries in 
> the database." - the "username" -> "user name" change seems fine, but the 
> "compared" -> "compare them" change seems to have erroneously changed the 
> meaning of the sentence.

I'll change that.

>> ftp: //ftp.rfc-editor.org/in-notes/authors/rfc4253-diff.html
>> ftp: //ftp.rfc-editor.org/in-notes/authors/rfc4253.txt
>
> Section 4: "SSH works over any 8-bit, clean, binary-transparent transport. 
> The underlying transport SHOULD protect against transmission errors, as such 
> errors cause the SSH connection to terminate." - the first comma added here 
> is incorrect.  The transport's "8-bit clean", not "8-bit" and "clean", much 
> as the concept of a clean and tidy transport is appealing.  Changing it to 
> "8-bit-clean" might emphasise the point.

I'll go back to "8-bit clean".

>
> 6.1: "The maximum of 35000 bytes is an arbitrarily chosen value that is 
> larger than uncompressed size." - should probably be something like "...that 
> is larger than the uncompressed payload length above."

See later note.

>
> 6.3: "The ciphers in each direction MUST run independent of each other." 
> ->  "The ciphers in each direction MUST run independently of one another."?

I'll stick with the original.

>
> 6.5: "SSH maintains its own group identifier space that is logically distinct 
> from Oakley..." - I found "which" much better in this context, but see the 
> note at the start of my previous mail.  Maybe it's just me.
>  Maybe I'm wrong.

I'll reconsider "which"es and "that"s if someone really presses.

>
> 8, paragraph 2: "...and I_S is S's KEXINIT message that have been exchanged 
> before this part begins." - again, I preferred "which".  But it should 
> definitely be "has", not "have".  "Exchanged" also seems wrong.  Maybe 
> "...and I_S is S's KEXINIT message, as previously sent from S to C."?

I made some changes to this paragraph but it really is "have".  See my 
note about the proposed changes.

>
> 8, further down: "Either side MUST NOT send or accept 'e' or 'f' values that 
> are not in the range [1, p-1]." should probably be "Values of 'e' or 'f' that 
> are not in the range [1, p-1] MUST NOT be sent or accepted by either side."

Again, I've made some changes.  Please review.

>> ftp: //ftp.rfc-editor.org/in-notes/authors/rfc4254-diff.html
>> ftp: //ftp.rfc-editor.org/in-notes/authors/rfc4254.txt
>
> 6.5, penultimate paragraph: "It is RECOMMENDED that the reply for these 
> messages be requested and checked ." - an extra space has crept in here.

Yup.

>
> 6.9: "'signal names' will be encoded as discussed in the "exit-signal" 
> SSH_MSG_CHANNEL_REQUEST." - there's no field here called 'signal names'.
>  I think the text should be "Signal names..." as before.

Got it.

>
> 6.10: If I'm following the quoting conventions used here correctly, 'signal 
> name' here should be swapped for "signal name".

Yup.

>
> 7.1: ""localhost" means to listen on all protocol families supported by the 
> SSH implementation on loopback addresses only ([RFC3330] and [RFC3513])." - 
> probably add a "see" at the start of the parenthesis?

OK

>
> 7.2: "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." - should probably be 
> "...from which the connection originated."?

I made some changes here.

>> ftp: //ftp.rfc-editor.org/in-notes/authors/rfc4255-diff.html
>> ftp: //ftp.rfc-editor.org/in-notes/authors/rfc4255.txt

Not my document.  :)

>
> 1: In other places, at least initial references to "SSH" have been expanded 
> to be "Secure Shell (SSH)".  Here not.
>
> Didn't spot anything else in this document.
>
>> ftp: //ftp.rfc-editor.org/in-notes/authors/rfc4256-diff.html
>> ftp: //ftp.rfc-editor.org/in-notes/authors/rfc4256.txt
>
> Abstract: "The Secure Shell Protocol (SSH) is..." should perhaps be "The 
> Secure Shell (SSH) protocol is..."?
>
> 3.1: If the "language tag is deprecated and SHOULD be the empty string", then 
> it's surely not "as defined in [RFC-3066]"?  Should the 3066 reference maybe 
> move down to the "If the language tag is not the empty string..." paragraph?
>
> 3.2: As for 3.1 (or not, if I'm wrong).  Further down, I'm pretty sure 
> "backended" isn't a word (since "back end"/"backend" isn't a verb).  I'm not 
> too vehement on the point, but this may be a stumbling block for non-native 
> English speakers.
>
> 3.4: (Similarly to section 8 of userauth.) "Systems supporting non-ASCII 
> passwords SHOULD always normalize passwords and user names whenever they are 
> added to the database, or compare them (with or without hashing) to existing 
> entries in the database.".  The "username" -> "user name" change from 
> userauth hasn't been applied here (though that doesn't really bother me). 
> Again, the "compared" -> "compare them" change seems to have erroneously 
> changed the meaning of the sentence.
>
> -- 
> Jon Bright
> Silicon Circus Ltd.
> http://www.siliconcircus.com
>

Thanks,
Chris

---

From: Jon Bright <[email-masked]>
Date: Thu, 10 Nov 2005 08:16:31 +0100

Chris Lonvick wrote:
>>
>> 6.3: "The ciphers in each direction MUST run independent of each 
>> other." ->  "The ciphers in each direction MUST run independently of 
>> one another."?
> 

I maybe shouldn't have put that question mark there.  The original is 
grammatically wrong.  "Independent" is an adjective, "independently" is 
the adverb.  Since we're modifying the verb "run" here, we need the 
adverb.  The "each other"/"one another" thing, I don't care about.

---

From: Chris Lonvick <[email-masked]>
Date: Thu, 10 Nov 2005 14:00:41 -0800 (PST)

Hi,

On Thu, 10 Nov 2005, Jon Bright wrote:

> grammatically wrong.  "Independent" is an adjective, "independently" is the 
> adverb.  Since we're modifying the verb "run" here, we need the adverb.  The 
> "each other"/"one another" thing, I don't care about.

Ahh...  that language thing...  OK.  I'll get the change submitted.

Thanks,
Chris

---

From: Jacob Nevins <[email-masked]>
Date: Thu, 17 Nov 2005 22:22:44 +0000

I wrote:
> Bill Sommerfeld writes:
> The following change appears:
> 
> |    [5]  Eastlake, D., "Domain Name System Security Extensions", RFC
> |         2535, March 1999.
> 
> has been changed to
> 
> |    [5]   Berc, L., Fenner, W., Frederick, R., McCanne, S., and P.
> |          Stewart, "RTP Payload Format for JPEG-compressed Video", RFC
> |          2435, October 1998.
> 
> That's utterly wrong, surely?

I note that this has already been fixed on rfc-editor.org. (It now
refers to RFC4033/4/5.)

---

From: Jacob Nevins <[email-masked]>
Date: Thu, 17 Nov 2005 22:29:05 +0000

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

Values for SSH_MSG_USERAUTH_INFO_REQUEST and _RESPONSE appear in the
section "IANA Considerations", even though they're no concern of IANA,
being method-specific. (This is also true of the document that went to
the RFC Editor.)

Since Chris has removed SSH_MSG_KEXDH_INIT and _REPLY from the table in
assignednumbers, I assume we should remove these from this section too
(although they'll have to go somewhere else to avoid being lost
entirely).

---

From: Jacob Nevins <[email-masked]>
Date: Fri, 18 Nov 2005 00:15:52 +0000

Jon Bright writes:
> 3.1: If the "language tag is deprecated and SHOULD be the empty string",
> then it's surely not "as defined in [RFC-3066]"?  Should the 3066
> reference maybe move down to the "If the language tag is not the empty
> string..." paragraph?

Agree, I think.

> 3.2: As for 3.1 (or not, if I'm wrong).

In addition, I think the second language tag paragraph in section 3.2
("If the language tag is not the empty string...") should be mostly cut.
It seems to have been lifted straight from 3.1 and doesn't make much
sense in 3.2 (talking about requirements it places on the server when
it's emitted _by_ the server).

However, if that's too drastic at this stage, so be it.

---

From: Frank Cusack <[email-masked]>
Date: Thu, 17 Nov 2005 16:24:01 -0800

> However, if that's too drastic at this stage, so be it.

Sorry, I haven't really been paying attention here.  Does Martin or
myself need to do anything?  The changes being proposed sound fine to me.

-frank

---

From: Jacob Nevins <[email-masked]>
Date: Fri, 18 Nov 2005 00:46:12 +0000

> myself need to do anything?  The changes being proposed sound fine to

From the forwarded messages Chris has included, it looks like you need
to send corrections to the RFC Editor. I've just collated them and
posted my interpretation to the list, but I'm not sure that the RFC
Editor will accept corrections from me.