ietf-nntp Niggles

[ned+ietf-nntp at innosoft.com]

> P62.

>    An extension is either a private extension or else it is included in
>    the IANA registry and is defined in an RFC. Such RFCs either must be
>    on the standards track or must define an IESG-approved experimental
>    protocol.

> My reading of RFC 2026 is that the IESG does not approve experimental
> protocols. There is provision for the IESG to "review" them if the RFC Editor
> considers them to be a bit "iffy" and to insert a "disclaimer" or take other
> action, but failure to do that does not actually imply "approval".

Well, yes and no. What happens in practice is that the RFC Editor runs all
experimental protocol submissions it receives by the IESG. The IESG then
makes a recommendation as to whether or not the document should be
published as an RFC. The RFC Editor can override the IESG if it wants
to, but when this happens the IESG can (and almost always does) attach
a note to the document explaining why the IESG thinks it is a bad idea.

Actual cases where the RFC Editor and the IESG disagree are rare, and I believe
they have become rarer over time.

However, all this is totally irrelevant to the matter at hand. Why? Because the
whole point of including the phrase "IESG-approved" is to make IESG approval an
*additional* requirement for publication of an NNTP extension specification.
Just because this requirement does not normally exist for publication of an
experimental extensions doesn't mean a specification can't add it.

SMTP extensions are similarly constrained (I suspect this is where the idea
came from) and this set of constraints has worked very well in practice.

				Ned