[NNTP] Chair writeup for draft-ietf-nntpext-tls-nntp

[Russ Allbery]

| 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, following 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
is one remaining objection (also applying to the AUTHINFO document) to be
aware of.

Properly using CAPABILITIES in conjunction with both AUTHINFO and TLS
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).

Yes, I have reviewed the document against the ID checklist.

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

Yes, the references are split.  This document has a normative reference to
the base NNTP specification (draft-ietf-nntpext-base-*) and should not be
published until that document has been published.

In addition, this document has normative references to the following IDs:

    draft-ietf-tls-rfc2246-bis-*
    draft-ietf-tls-rfc3546bis-*

Both of these documents are currently in last call, so I'm hopeful that
they will be ahead of this document in the publication queue regardless
and can be replaced with references to the appropriate RFCs.  Failing
that, it should be possible to drop back to references to RFC 2246 and RFC
3546 respectively, but section number references may have to be reviewed.

There is an informative reference to draft-ietf-nntpext-auth-*.

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

Technical Summary

   This memo defines an extension to the Network News Transport Protocol
   to provide connection-based security (via Transport Layer Security).
   The primary goal is to provide encryption for single-link
   confidentiality purposes, but data integrity, (optional)
   certificate-based peer entity authentication, and (optional) data
   compression are also possible.

Working Group Summary

   The NNTPEXT WG achieved consensus on this document.

Protocol Quality

   This protocol has been implemented in the Cyrus IMAP server and will be
   implemented in INN.

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