[ietf-nntp] RE: How to organize the base NNTP draft

[Clive D.W. Feather]

Scott Hollenbeck said:
> OK, I just wrapped up a conversation with Steve Bellovin re: the outstanding
> security-related comments for draft-ietf-nntpext-base-22.  He's OK with the
> idea of a document split as long as the base document includes a normative
> reference to an extensions document description of the needed security
> services.

So we need to get two documents going through the system anyway.

> However, the way the split is approached _might_ introduce a conflict with
> the WG's charter, which says:
> 
> "2. Include in the same document some reasonable group of existing
>   commonly used extensions forming a new base functionality for NNTP."

A possibility: can "document" be reasonably interpreted as "two RFCs, split
for convenience"? Rather like MIME is four RFCs and IDNA is three. Is
anyone really likely to object?

> and
> 
> "3. Upon completion of the RFC977 successor document, and presuming that
>   proposals for extensions to the NNTP protocol have been submitted
>   for consideration by IESG, the working group may be asked by the
>   IESG Applications Area Directors to review one or more extensions  
>   for NNTP."
> 
> So, the base document is supposed to incorporate some commonly used
> extensions.  What makes sense to stay in the base document?

My opinion is "all or none". The ones we included were those that were
already specified (though we made changes) and deemed worth having. I don't
think we left anything out that was well-specified (neither TLS nor
AUTHINFO fitted into that category *at the time*). But, if at publication
time we're going to have five extensions (AUTHINFO, HDR, LISTGROUP, OVER, 
TLS), there's no particular reason to split them 3:2. [Jeffrey's streaming
extension is also mostly-cooked, I think.]

> Anyway, we have a way forward with the IESG.  What's the best way to deal
> with the extensions while staying within the charter?

My personal opinion:

1st choice: split into base and extensions, and deem these to be "one
document" within the meaning of the charter.

2nd choice: merge TLS and SASL into the main document.

It seems to me that the SASL review means we've identified some tweaks to
the main document that are needed, so we're probably going to have to have
another draft of that.

As I said before, I'm happy to do all the integration and editorial work in
either case.

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