Network News Transfer Protocol (NNTP) Extension for Authentication
draft-ietf-nntpext-authinfo-10

[Ballot comment]
From review by Lakshminath Dondeti

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

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.

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

[Ballot discuss]
The authinfo draft needs to discuss internationalization of the
strings for the authinfo user and authinfo pass commands.  They are
listed as UTF8 but no issues like normalization are discussed.
Personally I'd recommend that the server should use saslprep on the
strings.  Regardless of what decision the WG comes to the issue needs
discussion and consideration.  There is somewhat of a discussion of
the complexities in the sasl plain draft.


The authinfo draft needs to discuss what happens if both a SASL
security layer and TLS are negotiated.  I'd recommend that the SASL
security layer be applied first, although double check against
existing implementations.  I would explicitly recommend against the
option of forbidding both security layers and TLS at the same time
although the WG certainly can make that decision if it chooses.

In the TLS draft, please check the text about resuming after TLS
failures with the TLS community.  It is my understanding that most
implementations make this difficult or impossible.  I don't need to
review any text changes in response to this item.  I'm simply
requesting that you double check with the TLS community and make an
informed decision.

The TLS document discusses certificate matching but does not discuss
certificate verification.  I'd recommend using the certificate
verification specified in RFC 3280.  You certainly need to say
something about verification.


Shouldn't the change controller for these extensions be the IESG not
the authors?

IANA Last Call Comments:
Upon approval of this document the IANA will register the SASL/GSSAPI service name "nntp" at the following location:
http://www.iana.org/assignments/gssapi-service-names.  The IANA will also register the NNTP extension AUTHINFO in the registry created by
draft-ietf-nntpext-base.

Updated AD evaluation comments:

draft-ietf-nntpext-authinfo
Abstract: an abstract must be able to stand in isolation from the rest of the spec, so references shouldn't be included.  Please replace [NNTP] with "(NNTP)", [NNTP-COMMON] with "RFC 2980", and [SASL] with "(SASL)".

Section 8.2: The UTF-8 reference should be normative.  It's cited as a MUST in section 2.3.2.

draft-ietf-nntpext-tls-nntp
Abstract: an abstract must be able to stand in isolation from the rest of the spec, so references shouldn't be included.  Please replace [NNTP] with "(NNTP)" and [TLS] with "(TLS)".

Both documents:
Please consider updating the [ABNF] reference to use draft-crocker-abnf-rfc2234bis instead of RFC 2234.  The IESG recently approved draft-crocker-abnf-rfc2234bis to obsolete 2234.  It's in the RFC Editor queue.

None of these are significant.  I will start the last call.  Please consider these in the same context as any other comments received during the last call process.

AD evaluation comments:

draft-ietf-nntpext-authinfo
Abstract: an abstract must be able to stand in isolation from the rest of the spec, so references shouldn't be included.  Please replace [NNTP] with "(NNTP)", [NNTP-COMMON] with "RFC 2980", and [SASL] with "(SASL)".

Section 8.2: The UTF-8 reference should be normative.  It's cited as a MUST in section 2.3.2.

draft-ietf-nntpext-tls-nntp
Abstract: an abstract must be able to stand in isolation from the rest of the spec, so references shouldn't be included.  Please replace [NNTP] with "(NNTP)" and [TLS] with "(TLS)".