Re: Please advance draft-ietf-secsh-auth-kbdinteract-05.txt

[Frank Cusack <fcusack%fcusack.com@localhost>]

On Tue, Jul 29, 2003 at 04:25:11PM -0400, Bill Sommerfeld wrote:
> Please start the ball rolling on:
> 
>             Generic Message Exchange Authentication For SSH
>                <draft-ietf-secsh-auth-kbdinteract-05.txt>
> 
> .. for publication as a Proposed Standard.  

Here are a few typo fixes (ie, nothing substantive, but still worth fixing
before publication) I meant to get in earlier.  The diff here is
against my nroff source.  Should I submit a -06 draft?

--- pwplus.n	2003/04/29 06:03:05	1.5
+++ pwplus.n	2003/07/31 05:31:23	1.6
@@ -83,7 +83,7 @@
 1. Introduction
 
 The SSH authentication protocol \%[SSH-USERAUTH] is a general-purpose user
-authentication protocol. It is intended to be run over the SSH transport
+authentication protocol.  It is intended to be run over the SSH transport
 layer protocol \%[SSH-TRANS].  The authentication protocol assumes that
 the underlying protocols provide integrity and confidentiality protection.
 
@@ -178,7 +178,7 @@
 does not support the requested language is implementation-dependent.
 
 The submethods field is included so the user can give a hint of which
-actual methods he wants to use.  It is a a comma-separated list of
+actual methods he wants to use.  It is a comma-separated list of
 authentication submethods (software or hardware) which the user prefers.
 If the client has knowledge of the submethods preferred by the user,
 presumably through a configuration setting, it MAY use the submethods
@@ -186,7 +186,7 @@
 the empty string.
 
 The actual names of the submethods is something which the user and the
-server needs to agree upon.
+server need to agree upon.
 
 Server interpretation of the submethods field is implementation-dependent.
 
@@ -221,7 +221,7 @@
 The server may send as many requests as are necessary to authenticate the
 client; the client MUST be prepared to handle multiple exchanges.  However
 the server MUST NOT ever have more than one SSH_MSG_USERAUTH_INFO_REQUEST
-message outstanding. That is, it may not send another request before
+message outstanding.  That is, it may not send another request before
 the client has answered.
 
 .KS
@@ -293,7 +293,7 @@
 the name and prompts.  If the server presents names or prompts longer
 than 30 characters, the client MAY truncate these fields to the length
 it can display.  If the client does truncate any fields, there MUST be
-an obvious indication that such truncation has occured.  The instruction
+an obvious indication that such truncation has occurred.  The instruction
 field SHOULD NOT be truncated.
 
 Clients SHOULD use control character filtering as discussed in \%[SSH-ARCH]
@@ -363,7 +363,7 @@
 If the server intends to respond with a failure message, it MAY delay
 for an implementation-dependent time before sending to the client.
 It is suspected that implementations are likely to make the time delay
-a configurable, a suggested default is 2 seconds.
+a configurable; a suggested default is 2 seconds.
 
 .ti 0
 4. Authentication Examples
@@ -485,7 +485,7 @@
 .ti 0
 6. Security Considerations
 
-The authentication protocol, and this authentication method, depends
+The authentication protocol, and this authentication method, depend
 on the security of the underlying SSH transport layer.  Without the
 confidentiality provided therein, any authentication data passed with
 this method is subject to interception.
@@ -494,8 +494,8 @@
 authentication using this method may be variable.  It is possible that an
 observer may gain valuable information simply by counting that number.
 For example, an observer may guess that a user's password has expired,
-and with further observation may be able to determine the frequency of
-a site's password expiration policy.
+and with further observation may be able to determine the password lifetime
+imposed by a site's password expiration policy.
 
 .KS
 .ti 0
@@ -561,7 +561,7 @@
 .in 3
 .KS
 .ti 0
-8. Author's Addresses
+8. Authors' Addresses
 
 .nf
 .ne 5