Subject: Eyeballs needed.

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 27 Oct 2005 16:51:08 -0400

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: Jon Bright <[email-masked]>
Date: Fri, 28 Oct 2005 08:46:46 +0200

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

I didn't catch anything.

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

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.

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...".  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 :-)

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

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

-- 
Jon Bright
Silicon Circus Ltd.
http://www.siliconcircus.com

---

From: "Tom Petch" <[email-masked]>
Date: Fri, 28 Oct 2005 10:32:16 +0200

Just to check the obvious, the underlying I-Ds that were given to the RFC Editor
are the ones that came out in September with an updated file name but with the
previous name on the first page eg
file name  draft-ietf-secsh-architecture-23.txt:
title inside draft-ietf-secsh-architecture-22.txt:

Yes?
Tom Petch

---

From: Jacob Nevins <[email-masked]>
Date: Fri, 28 Oct 2005 14:46:59 +0100

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

Only one of Ben Harris' comments from 14 June appears to have been
addressed here. (original message attached for convenience)

The IANA registry doesn't appear to have addressed any of those comments.
<http://www.iana.org/assignments/ssh-parameters>

I think all the comments I raised about the core drafts have been
addressed.

---

From: Jon Bright <[email-masked]>
Date: Fri, 28 Oct 2005 17:20:15 +0200

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

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.

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

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

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

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.

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

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

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

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.

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

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?

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

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

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

---

From: der Mouse <[email-masked]>
Date: Fri, 28 Oct 2005 16:42:36 -0400 (EDT)

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.

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

4.1, 4.2, 4.4, 4.5.2: I too would prefer "which" over "that" here, though I
agree the difference is slight.

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

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

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

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?

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.

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

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.

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

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

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

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.

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

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

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/

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

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"'?

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

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

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

---

From: Chris Lonvick <[email-masked]>
Date: Sat, 29 Oct 2005 19:09:51 -0700 (PDT)

Hi Tom,

Yes.  The diffs (.html files) are between the September drafts and what 
the RFC Editor has changed.

Thanks,
Chris

---

From: Jacob Nevins <[email-masked]>
Date: Mon, 31 Oct 2005 14:22:58 +0000

A couple more comments:

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

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? The reference to [5] in the body of the
new text is:

|    The method described here can provide out-of-band verification by
|    looking up a fingerprint of the server public key in the DNS [1][2]
|    and using DNSSEC [5] to verify the lookup.

(RFC2535 may not be the correct reference any more; it looks like it
should be one of RFC4033/4/5 these days.)

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

I echo Jon Bright's comment about the semantic change to the text
about normalizing passwords. However, I make it section 3.4, not
section 8.

In section 7.1 (Normative References), an extra "2005." has snuck in:

|    [SSH-ARCH]      Ylonen, T. and C. Lonvick, Ed., "The Secure Shell
|                    (SSH) Protocol Architecture", RFC 4251, November
|                    2005.  2005.

---

From: Jon Bright <[email-masked]>
Date: Mon, 31 Oct 2005 15:31:02 +0100

> about normalizing passwords. However, I make it section 3.4, not

Just to clarify: this appears in two places.  It's 3.4 in -kbdinteract 
and 8 in -userauth.

---

From: Jacob Nevins <[email-masked]>
Date: Mon, 31 Oct 2005 14:43:26 +0000

> Just to clarify: this appears in two places.  It's 3.4 in -kbdinteract

So it does. Sorry.