Re: Back to the drawing board, was Re: Last Call: Registry Registrar Protocol (RRP) Version 1.1.0 to Informational

[ned.freed at innosoft.com]

John Klensin wrote, in part:

> In summary, I believe that our advice to the IESG should be

> "make certain this document is clear about what it is and what
> it proports to be, and that the authors (or author organization)
> take responsibility for that being true.  Make certain that,
> should a RRP WG effort be launched, this document doesn't
> unreasonaby constrain it.   If areas are identified in which the
> document isn't clear about what it calls for, get those fixed.
> Consider attaching a disclaimer that indicates the list of
> unresolved issues contains some fairly serious problems and that
> there may be equally serious issues not on that list.   Then,
> since it is relevant and not obviously stupid, go ahead and
> publish the thing."

I am in complete agreement with John on all of this. However, I would
like to add a couple of additional points:

(1) While it is true that publication as informational is sometimes
   misinterpreted as an endorsement, this is also something that is
   discussed a lot more than it actually happens. The RFC series
   contains many hundreds of documents describing protocols of dubious
   value and which don't receive a second glance by anybody, in some
   cases in spite of considerable marketing muscle being used to promote
   them.

   It isn't entirely clear why the publication == endorsement error
   happens in some cases, but it often involves some combination of people
   with no IETF standards experience, poor document labelling, a lack of
   a visible standards-track alternative or visible work underway on a
   standards-track alternative. In the present situation the first of these
   factors shouldn't apply and the second and third are things we control, so
   we should be able to minimize the risk of something bad happening.

(2) The publication of protocol specifications in order to document the
   history of Internet protocol evolution is actually pretty important when
   you're actually doing protocol development work. I find it incredibly
   useful, for example, to refer to RFC 733, RFC 788, RFC 1049, RFC 1154,
   FIPS PUB 98, and many other documents when tring to figure out why
   Internet mail has ended up where it has and what makes sense for the
   future.

(3) An alternative to putting a lot of comments about unresolved issues in
   given protocol document is to write a separate document critiquing the
   first and publish it as well. This approach used to be use quite a bit
   in the RFC series but has fallen into disuse in more recent times (probably
   because things move so fast these days). Perhaps this is an instance where
   the practice ought to be revived.

				Ned