Re: Back to the drawing board, was Re: Last Call: Registry Registrar Pro

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.