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
