Subject: [NNTP] Re: GenART reviews of draft-ietf-nntpext-tls-nntp-07 and draft-ietf-nntpext-authinfo-09

From: Ken Murchison <[email-masked]>
Date: Sat, 23 Jul 2005 08:30:35 -0400

Lakshminath Dondeti wrote:

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

RFC 2222 currently includes the description of SASL/GSSAPI, but the 
update to RFC 2222 will not, SASL/GSSAPI will be its own document.  So, 
the informative reference to RFC 2222 is there as a placeholder for the 
separate SASL/GSSAPI document when its published.  Perhaps this is the 
wrong way to handle this.  Any suggestions?

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

This was taken almost verbatim from RFC 3207.  I'll see if I can rewrod it.

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

Done.

-- 
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: Ned Freed <[email-masked]>
Date: Sat, 23 Jul 2005 07:28:46 -0700 (PDT)

> wrong way to handle this.  Any suggestions?

Why not simply refer to draft-ietf-sasl-gssapi-02.txt - I assume that's
the document you're talking about. There's nothing wrong with having
a reference to an I-D; the RFC Editor knows how to handle them.

> This was taken almost verbatim from RFC 3207.  I'll see if I can rewrod it.

I have to say I'm always amused when this happens: Wording which was good
enough to be published in one RFC doesn't pass muster when reused.

				Ned

---

From: Ken Murchison <[email-masked]>
Date: Sat, 23 Jul 2005 11:06:51 -0400

> a reference to an I-D; the RFC Editor knows how to handle them.

That's what I originally had, but discussion on the list urged/forced me 
to only reference RFCs and include the note to the editor to update the 
references if the appropriate I-Ds moved to RFCs before our document. 
I'll gladly go back to referencing the most current I-Ds.

Russ?

> enough to be published in one RFC doesn't pass muster when reused.

Me too.  Its happened a few times with both docs, which pretty much 
stole all applicable text from the SASL and TLS profiles for IMAP, POP3 
and SMTP.

---

From: Russ Allbery <[email-masked]>
Date: Sun, 24 Jul 2005 15:52:36 -0700

>> the document you're talking about. There's nothing wrong with having a
>> reference to an I-D; the RFC Editor knows how to handle them.

> references if the appropriate I-Ds moved to RFCs before our
> document. I'll gladly go back to referencing the most current I-Ds.

> Russ?

For informative references, I believe it's fine to just reference the
draft and let the RFC Editor deal with it.  The concern with referencing
drafts was additional hold-up at the publishing stage when we don't
actually care whether we go with the current reference or the later
reference, but my understanding is that that this concern doesn't apply to
informative references.

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

---

From: "Clive D.W. Feather" <[email-masked]>
Date: Mon, 25 Jul 2005 11:04:17 +0100

> reference, but my understanding is that that this concern doesn't apply to

I handled all this through a note to the RFC Editor:

   The normative reference to RFC 2234 [RFC2234] and the informative
   reference to RFC 2629 [RFC2629] may be replaced by
   draft-crocker-abnf-rfc2234bis and draft-mrose-writing-rfcs
   respectively should either or both of those documents reach RFC
   status before this one.

   The informative references to [NNTP-AUTH], [NNTP-STREAM], and [NNTP-
   TLS] are documents which are expected to be published simultaneously
   with this one and so can be replaced by references to the resulting
   RFCs.

-- 
Clive D.W. Feather  | Work:  <[email-masked]>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <[email-masked]>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            |

---

From: Ken Murchison <[email-masked]>
Date: Mon, 25 Jul 2005 15:28:01 -0400

> I handled all this through a note to the RFC Editor:

I have the same language in AUHTINFO, but the problem is that SASL 
(normative) and SASL/GSSAPI (informative) are being split into separate 
I-Ds which I originally referenced.  After our last discussion on this, 
we decided to only use RFCs, which then makes RFC 2222 both normative 
and informative.

---

From: Ken Murchison <[email-masked]>
Date: Mon, 25 Jul 2005 15:28:30 -0400

> reference, but my understanding is that that this concern doesn't apply to

Didn't we decide tht AUTHINFO was going to block on SASL anyways?

---

From: Russ Allbery <[email-masked]>
Date: Mon, 25 Jul 2005 12:59:37 -0700

>> draft and let the RFC Editor deal with it.  The concern with
>> referencing drafts was additional hold-up at the publishing stage when
>> we don't actually care whether we go with the current reference or the
>> later reference, but my understanding is that that this concern doesn't
>> apply to informative references.

> Didn't we decide tht AUTHINFO was going to block on SASL anyways?

Oh, I'm sorry, for some reason I thought this was TLS.  Yes, for AUTHINFO,
let's just block on SASL.