[NNTP] Chair writeup for draft-ietf-nntpext-authinfo

[Russ Allbery]

[ Forwarding as I sent it, although note that the SASLprep reference had
  already been updated; I must have been looking at the wrong version of
  the document at the time. ]

| a) Have the chairs personally reviewed this version of the Internet
|    Draft (ID), and in particular, do they believe this ID is ready
|    to forward to the IESG for publication?

Yes, after an IETF Last Call.

| b) Has the document had adequate review from both key WG members
|    and key non-WG members?  Do you have any concerns about the
|    depth or breadth of the reviews that have been performed?

Yes.  The document or pointers to the document have been posted several
times to news.software.nntp and have received comments and review from
many NNTP software authors.  Several NNTP software authors, including
myself, have reviewed the document for divergence from existing practice
and to ensure that its provisions are implementable and reasonable.

| c) Do you have concerns that the document needs more review from a
|    particular (broader) perspective (e.g., security, operational
|    complexity, someone familiar with AAA, etc.)?

No.

| d) Do you have any specific concerns/issues with this document that
|    you believe the ADs and/or IESG should be aware of?  For
|    example, perhaps you are uncomfortable with certain parts of the
|    document, or have concerns whether there really is a need for
|    it.  In any event, if your issues have been discussed in the WG
|    and the WG has indicated it that it still wishes to advance the
|    document, detail those concerns in the write-up.

No.

| e) How solid is the WG consensus behind this document? Does it
|    represent the strong concurrence of a few individuals, with
|    others being silent, or does the WG as a whole understand and
|    agree with it?

I believe the WG consensus around this document is solid.  However, there
are two remaining objections to be aware of.

One is that many news servers require, in practice, an authentication
mechanism that transmits a password to the news server, but don't want to
use TLS for the entire session.  Currently, SASL does not provide a good
mechanism with that profile, and therefore use of the AUTHINFO USER/PASS
protocol discouraged by this document may continue until such a SASL
protocol is developed.  The feeling was, however, that this was an
inadequacy in SASL rather than a flaw in this protocol and that SASL is
still the correct long-term direction as this can be remedied within the
SASL framework.

The second is an objection that applies to both this document and the TLS
document, namely that properly using CAPABILITIES in conjunction with both
of these extensions requires quite a few round trips between the client
and the server, which can be a cause of perceived slowness in a client.
Some of those who have reviewed this document, Mark Crispin in particular,
wanted to see some mechanism whereby capabilities information could be
supplied as part of the response ot the AUTHINFO SASL and STARTTLS
commands to avoid another round trip.  The WG failed to reach consensus on
any good protocol for doing so and decided to defer this as future work.

| f) Has anyone threatened an appeal or otherwise indicated extreme
|    discontent?  If so, please summarise the areas of conflict in
|    separate email to the Responsible Area Director.

No.

| g) Have the chairs verified that the document adheres to all of the
|    ID nits? (see http://www.ietf.org/ID-Checklist.html).

I have reviewed the document against the ID checklist.

There is one reference in the Abstract that isn't fully explained (the
[NNTP-COMMON] reference to RFC 2980.  I will ask the document editor to
rephrase that reference to specify that it is referring to RFC 2980.

| h) Is the document split into normative and informative references?
|    Are there normative references to IDs, where the IDs are not
|    also ready for advancement or are otherwise in an unclear state?
|    (note here that the RFC editor will not publish an RFC with
|    normative references to IDs, it will delay publication until all
|    such IDs are also ready for publication as RFCs.)

The references are split.  This document has a normative reference to the
base NNTP specification (draft-ietf-nntpext-base-*) and the STARTTLS
extension for NNTP (draft-ietf-nntpext-tls-nntp-*) and should not be
published until that document has been published.  In addition, it has
normative references on the following other IDs:

    draft-ietf-sasl-rfc2222bis-*
    draft-ietf-sasl-rfc2831bis-*
    draft-hoffman-rfc3454bis-*

If these documents are not published before this document, the references
can probably be changed to RFC 2222, RFC 2831, and RFC 3454 respectively.
This is very easy to do for RFC 2831 and RFC 3454.  There are section
number references to draft-ietf-sasl-rfc2222bis-* that may need to be
reviewed to be sure they don't change when changing the reference to RFC
2222.

Finally, it has a normative reference to draft-ietf-sasl-saslprep-*, which
can be replaced with a normative reference to RFC 4013 since that document
has now been published.  I will ask the document editor to make that
change.

| j) Please provide such a write-up.  Recent examples can be found in
|    the "protocol action" announcements for approved documents.

Technical Summary

   This document defines an extension the Network News Transport Protocol
   (NNTP) which allows a client to indicate an authentication mechanism to
   the server, perform an authentication protocol exchange, and optionally
   negotiate a security layer for subsequent protocol interactions during
   the remainder of an NNTP session.

   This document updates and formalizes the AUTHINFO USER/PASS
   authentication method specified in RFC 2980 and deprecates the AUTHINFO
   SIMPLE and AUTHINFO GENERIC authentication methods.  Additionally, this
   document defines a profile of the Simple Authentication and Security
   Layer (SASL) for NNTP.

Working Group Summary

   The NNTPEXT WG achieved consensus on this document.

Protocol Quality

   The AUTHINFO USER/PASS authentication method specified here was
   previously defined less formally in RFC 2980 and is in widespread,
   interoperable use by existing NNTP implementations.  AUTHINFO SASL has
   been implemented for INN and the Cyrus IMAP server.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>