Draft:  draft-ietf-nntpext-tls-nntp-07 & draft-ietf-nntpext-authinfo-09
Reviewer: Lakshminath Dondeti [ldondeti@qualcomm.com]
Review Date: Wednesday 7/20/2005 4:24 PM CST
Telechat Date: 21 July 2005

Summary: Ready.

Review:
-------
These drafts are ready for publication (I do have a request for 
clarification on the drafts)

Request for clarification
---------------------------
The applications of secure transport (from the authinfo I-D) are:   "to 
control resource consumption," "to allow abusers of the POST command to 
be identified," and "to restrict access to "local" groups."

The last one does require an encrypted channel, but I don't think the 
other two do.  An authenticated (integrity-protected) channel might be 
sufficient for some applications.  For applications which do not require 
confidentiality, why waste resources or put another way why slowdown 
downloads by making Encryption a MUST?  Thus, I think it would make 
sense for the drafts to specify an integrity only security layer as a 
MUST/SHOULD (e.g., TLS_RSA_WITH_NULL_SHA).

I am curious if the WG had this discussion.  If there was such a 
discussion and the drafts reflect the consensus, please ignore my 
comment above.  If not, perhaps it makes sense to specify such a mode 
for efficient operation.

<nit> RFC 2222 is in normative and informative references' sections in 
the authinfo I-D.  Is that intended? </nit>

<edit>Page 9, third paragraph from the bottom, last sentence of the 
-tls- I-D: "Furthermore, just because an NNTP server can authenticate 
..." is not clear, and may be incorrect: articles *from* the NNTP client 
... when the client *received* them.  Please correct/clarify that 
sentence. </edit>

<edit>  Please insert a "to" after the word "extension" in the abstract 
of -authinfo- ID.  </edit>

There may be a few other minor editorial things, but the RFC editor will 
catch them.