I've trimmed most of the cc's on the theory that everyone
relevant except possibly Scott are on the IETF or IESG lists.
Ed, I've followed your comments very carefully, but, applying
your reasoning to what I see as long-standing principles for
handling Info RFCs, I reach nearly opposite conclusions. Please
forgive the length of this note; I think it is important that we
review and return to some principles here.
I don't have RFC 2223 in front of me and hope we can avoid
hair-splitting and protocol-lawyering over this, but, in
general, the RFC Editor has chosen to publish (and the IESG has
chosen to not recommend otherwise) when
* The proposed document covers material that is at least
potentially relevant and of interest to some reasonable fraction
of the internet community. E.g., a document that described the
operation of a toaster that was not designed for connection to
the network might well not be published.
* If the document covers a protocol or discussion about how to
perform some protocol-related act, it isn't likely to create
confusion with existing standards or standards-work-in-progress
or reasonable ways to implement them. E.g., a document that
described itself as "HTTP 1.3", but was not compatible with HTTP
1.1, and had not been through the standards process, would be
unlikely to be published (at least under that name and without a
lot of disclaimers).
* Whatever the document contains, it is not egregiously stupid.
My impression is that, while this principle --rejecting drafts
for publication on the basis of utter stupidity-- is discussed a
lot, it is rarely actually applied.
More recently, there has been a lot of thought given to whether
a particular document is part of a marketing plan to publish
something as informaitional and then present it to customers as
"an RFC" in a way that implies IETF approval and probably
standardization. My impression is that rejecting documents on
this basis is, like the "no stupidity" criterion often
discussed, but rarely applied. These documents often go through
with significant disclaimers attached, but they mostly go
through.
By contrast, IETF has (I believe wisely) always steered clear of
the certification process. We never make statements --even for
full Internet Standards-- that a given implementation works, or
that a particular implementation faithfully reflects a given
specification. People and companies make those assertions, we
don't try to stop them; we hope that the marketplace will
appropriately reward those who lie (intentionally or otherwise).
Usually that works, sometimes it doesn't, but, as you know, the
IETF-authorized "protocol police" have always been a myth.
Now, in the case of this draft document, I was a little
surprised that the IESG chose to Last Call this doc before
letting it go to the RFC Editor. They generally don't for
informational documents (for which I think we must be thankful).
I believe that the issues this has raised demonstrates that
their decison was wise, even though many of the comments have
contained more heat than light. But, if we look at the doc, it
is a protocol description, supplied by one organization. It
doesn't make that clear enough, and it should, but that point
was made and accepted long ago. It is arguably not quite clear
what NSI claims it describes, e.g.,
* the protocol they are running today
* the protocol they ran at one time
* the protocol they wish they were running
* the protocol they wish someone else were running, but have
no intention of running themselves.
If that isn't clear to all reasonable readers, it ought to be
fixed. Within the traditional domain of info RFCs, any of
those four (and others) are publishable, but we try to avoid
confusion, especially in the case of the fourth.
But, I think an argument about whether or not the document
actually conforms to some piece of code and making a decision to
publish or not publish on that basis is *very* dangerous for us.
As suggested above, we don't try to do that even for
standards-track protocols and putatively-comforming programs.
If, as you suggest has happened here, NSI (or someone else) has
submitted a document for info RFC publication, and it suggested
things that aren't true, that is a problem... but it is a
problem between NSI (again for example) and whomever tries to
implement the thing, not an IETF problem. I would expect that,
if such a situation occurred, registrars who implemented the
protocol as described in the RFC and then discovered that they
needed to do something rather different to make it work, would
be very annoyed. They might rationally express that annoyance by
* contacting their lawyers
* contacting the press
* writing proposed info RFCs with titles like "NSI RRP
description considered harmful"
Just a personal opinion here, but I can't imagine the RFC Editor
declining to publish documents of the latter type if they were
technically coherent and well-reasoned.
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."
regards,
john
Disclaimer: I wasn't a member of the review committee (I was
invited, but couldn't agree to the NDA in use at the time). I
did have a chance to look at a draft of this doc that preceeded
the I-D. My personal opinion is that, as a example of protocol
design work, the I-D gets no better than a C- and that it may be
an excellent example of why it is better to do protocol design
in the open, rather than in closed groups tied up in NDAs. But
I can't get to "don't publish" from finding the thing a little
distasteful: there are standards-track protocols I find a little
distasteful and I believe the long-standing tradition of freedom
to publish things that might be of use or interest is pretty
important.
