Subject: [NNTP] NNTP Extensions drafts

From: Ken Murchison <[email-masked]>
Date: Fri, 20 May 2005 16:44:09 -0400

Please accept the following updated drafts:

ftp://ftp.oceana.com/pub/drafts/draft-ietf-nntpext-authinfo-08.txt
ftp://ftp.oceana.com/pub/drafts/draft-ietf-nntpext-streaming-05.txt
ftp://ftp.oceana.com/pub/drafts/draft-ietf-nntpext-tls-nntp-06.txt

-- 
Kenneth Murchison     Oceana Matrix Ltd.
Software Engineer     21 Princeton Place
716-662-8973 x26      Orchard Park, NY 14127
--PGP Public Key--    http://www.oceana.com/~ken/ksm.pgp

---

From: Russ Allbery <[email-masked]>
Date: Sun, 22 May 2005 14:12:29 -0700

> ftp://ftp.oceana.com/pub/drafts/draft-ietf-nntpext-tls-nntp-06.txt

draft-ietf-sasl-saslprep-* has been published as RFC 4013.  Could you
update the reference in the authinfo draft accordingly?

The I-D checklist asks that the Abstract not have any references that
aren't fully explained.  The authinfo and streaming drafts have references
to [NNTP-COMMON].  Could you reword the Abstract to clearly indicate that
this is RFC 2980?

One route may be to drop the references entirely from the Abstract.  For
example, you could use these Abstracts (which are what I'm submitting for
the protocol writeup).

authinfo:

   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.

streaming:

   This memo defines an extension to the Network News Transport Protocol
   to provide asynchronous (otherwise known as "streaming") transfer of
   articles.  This allows servers to transfer articles to other servers
   with much greater efficiency.

   RFC 2980 summarizes some ad-hoc transport extensions currently used in
   the NNTP protocol.  This document updates and formalizes the CHECK and
   TAKETHIS commands and deprecates the MODE STREAM command.

tls:

   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.

I don't believe these changes have to be made immediately, but if our AD
wants them to be, I'll let you know.  Otherwise, they can probably be made
in an additional ID submitted at the end of the Last Call period.

Note that both the authinfo and tls drafts currently have normative
references on IDs.  The tls ones are on documents currently in Last Call,
so hopefully they'll finish before we do.  The authinfo ones are more
problematic.  We may need to back off the references to RFC 2222, RFC
2831, and RFC 3454 (and, in fact, since SASLprep was published with a
reference to RFC 3454, we probably should back off our reference
accordingly).  Changing the RFC 2831 reference looks trivial; RFC 2222 may
require reviewing section number references.

-- 
Russ Allbery ([email-masked])             <http://www.eyrie.org/~eagle/>

---

From: Ken Murchison <[email-masked]>
Date: Mon, 23 May 2005 10:28:17 -0400

> update the reference in the authinfo draft accordingly?

It already is, unless I'm missing something.

> to [NNTP-COMMON].  Could you reword the Abstract to clearly indicate that

Done.  I used your wording as a template and made some adjustments of my 
own.

Actually, both AUTHINFO and STREAMING had RFC 2970 (instead of 2980) 
listed as being updated in the boilerplate.  I fixed this as well.

> require reviewing section number references.

Actually all of the drafts in the references are updates to existing 
RFCs (except for NNTP-AUTH and NNTP-TLS).  I could just reference the 
current RFCs if you want.  Let me know what you want me to do, and I'll 
resubmit right away if necessary.

---

From: "Scott Hollenbeck" <[email-masked]>
Date: Mon, 23 May 2005 10:41:09 -0400

> resubmit right away if necessary.

I'd very much prefer corrected drafts before I start the last call
processes.

-Scott-

---

From: Ken Murchison <[email-masked]>
Date: Mon, 23 May 2005 10:44:47 -0400

> I'd very much prefer corrected drafts before I start the last call

So, do you recommend that I only reference the existing RFCs and not 
worry about the fact that they are being updated?

I suppose that if any of these updates move to RFC status later, either 
the editor will make the change, or I can make the change during the 
last 48 hour review.

---

From: "Scott Hollenbeck" <[email-masked]>
Date: Mon, 23 May 2005 11:04:36 -0400

Ken,

I'll let you and the working group decide which references are appropriate.
I just want the question resolved before I start the last calls.

Changing normative references would not be a good idea in auth48.  If you
reference I-Ds, the RFC Editor will take care of the needed updates.
They'll also hold the documents until all normative references are queued
for RFC publication.

-Scott-

> -----Original Message-----
> From: Ken Murchison [mailto:[email-masked]] 
> Sent: Monday, May 23, 2005 10:45 AM
> To: Scott Hollenbeck
> Cc: 'Russ Allbery'; [email-masked]
> Subject: Re: [NNTP] NNTP Extensions drafts
> 
> Scott Hollenbeck wrote:
>

---

From: Russ Allbery <[email-masked]>
Date: Mon, 23 May 2005 09:51:19 -0700

Scott Hollenbeck <[email-masked]> writes:

> I'll let you and the working group decide which references are
> appropriate.  I just want the question resolved before I start the last
> calls.

> Changing normative references would not be a good idea in auth48.  If
> you reference I-Ds, the RFC Editor will take care of the needed updates.
> They'll also hold the documents until all normative references are
> queued for RFC publication.

Unless we're specifically using capabilities that were added in the
revisions, I'd rather not add the additional complexity to the publication
process of depending on I-Ds.  Ken, were there reasons why we were citing
the works in progress rather than the published RFCs in particular, or was
it just an effort to stay current?

---

From: Ken Murchison <[email-masked]>
Date: Mon, 23 May 2005 13:34:35 -0400

> it just an effort to stay current?

Mainly just to stay current, with the exception of RFC2222bis, which is 
now going to require the use of the SASLprep profile of StringPrep for 
authorization ID.  I don't believe that there any updates to the SASL 
mech docs or TLS docs which have any bearing on our work, so I can 
fallback to the current RFCs and let the editor update them if possible.

---

From: Russ Allbery <[email-masked]>
Date: Mon, 23 May 2005 10:37:57 -0700

Ken Murchison <[email-masked]> writes:

> authorization ID.

It looks like RFC2222bis is one of the ones that isn't even in Last Call
yet.  Hm.  We do require SASLprep ourselves; do we need to also depend on
the version of RFC2222 that requires it?

> I don't believe that there any updates to the SASL mech docs or TLS docs
> which have any bearing on our work, so I can fallback to the current
> RFCs and let the editor update them if possible.

That sounds good to me.

---

From: Ken Murchison <[email-masked]>
Date: Mon, 23 May 2005 13:48:28 -0400

> fallback to the current RFCs and let the editor update them if possible.

On second thought, RFC 2831bis (DIGEST-MD5) is deprecating the 3DES 
cipher (because of a CBC mode attack) and mandating AES.

We're currently mandating DIGEST-MD5 for interoperability, so I don't 
know how we want to handle this.  One alternative is to mandate CRAM-MD5 
(which is less secure), or TLS+PLAIN (which is what the latest IMAP4 
update does), but I'm guessing we'll get a big pushback from members of 
the WG.

Another alternative is to block this doc while waiting for a new SASL 
mech which resembles PASSDSS.  I've been meaning to write this up for a 
while, but haven't gotten to it yet.  Members of the SASL WG feel that 
such a mech would be a useful thing.

---

From: Russ Allbery <[email-masked]>
Date: Mon, 23 May 2005 10:53:30 -0700

> such a mech would be a useful thing.

If we don't publish all of our docs at right around the same time, we run
into the same problem we ran into with LIST EXTENSIONS where servers may
start implementing NNTPv2 and not advertise AUTHINFO.  I really don't want
to end up in that situation.

Because of that, blocking until we have PASSDSS really isn't appealing to
me.  Blocking the whole set of documents until some of the updates to
other documents have been published is annoying, but possible I guess.
Really, though, I'd rather get everything out with as few external
hold-ups as we can.

---

From: Ken Murchison <[email-masked]>
Date: Mon, 23 May 2005 13:56:22 -0400

> Really, though, I'd rather get everything out with as few external

I can ask the SASL WG how they feel (from a technical standpoint) about 
publishing a new SASL protocol profile which has normative references to 
RFC2222 and RFC2831.

---

From: Russ Allbery <[email-masked]>
Date: Mon, 23 May 2005 10:59:15 -0700

>> Because of that, blocking until we have PASSDSS really isn't appealing
>> to me.  Blocking the whole set of documents until some of the updates
>> to other documents have been published is annoying, but possible I
>> guess.  Really, though, I'd rather get everything out with as few
>> external hold-ups as we can.

> publishing a new SASL protocol profile which has normative references to

Yes, that sounds good to me.  Thank you!

---

From: "Charles Lindsey" <[email-masked]>
Date: Tue, 24 May 2005 11:13:21 GMT

>worry about the fact that they are being updated?

If there exist some ID for RFCxxxxbis and there is a reasonable prospect
that it will be accepted by the IETF on a suitable timescale, then the
draft should refer to RFCxxxxbis.

If this later turns out to be a critical item holding up final
publication, and supposing we are not absolutely dependent on some feature
in RFCxxxxbis, then the RFC Editor should be asked to fall back to
RFCxxxx.

Ideally, there should be some meta-text in the draft saying that such
might happen.

Is that a possible mechanism within the IETF framework? All the documents
involved, including our drafts, may or may not get held up during the Last
Call process, and it is hard to predict in advance the order in which they
will finally get released.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131 Fax: +44 161 436 6133   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5