Subject: [Rfcplusplus] Comments on "The label "RFC" (RFC++) BOF

From: Bob Hinden <[email-masked]>
Date: Fri, 1 Jun 2018 15:59:35 -0700

I do not support what is being proposed in this BOF.   I have a number of issues with the proposal.

The problem the BOF says it is addressing, namely that not all RFCs are IETF created Standards caused confusion.  I note that some very basic Internet protocols like RFC791, RFC792, and RFC793 that are essential for the Internet are not IETF standards as they were published prior to the IETF being created.  When the IETF decided to use the RFC series it made an active decision to do this knowing that not all RFCs were IETF Standards.

The "regrettably well spread misconception” is something we are all aware of, but is not something that can be measured.  It is anecdotal and can’t be measured.  Other than saying "regrettably well spread misconception”, is there any data that this causes a serious problem that is worth fixing?  Especially since there have been about 7300 RFCs published since the IETF was created.  It’s hard to fix the past.

The notion of an experiment where there is not a clear criteria for measuring the result (for example, how do you measure there is less “misconception”) and proposing that the experiment runs for three years would appear to have the result of making the change permanent.  Essentially not have an experiment at all.  This seems to me to be disingenuous.

Is is not correct to call “RFC” a label.  It’s not a label, it’s the name of the series.  There isn’t a series with several labels.  There is only the RFC Series.  We have an RFC Series Editor, RFC Series Production Center, and a number of RFC defining what the series is.  None of this calls it a label.

This proposal also seem to me to have it backwards.  Instead of making changes to the IETF Stream, it proposes that all of the other streams have to change.  I think it would be better to make changes in the IETF Stream to make it clearer that a specific RFC is an IETF Standard.  Several things come to mind.  The header on the document could have in large letters that clearly indicate that the RFC is an IETF Standard.  Perhaps even adding something in the header like:

*****************************************
*****************************************
******                             ******
******        IETF Standard        ******
******                             ******
*****************************************
*****************************************

I suspect we could do something nicer once the new format work is completed, like adding an image of an IETF Logo.

The places where RFCs are searched for (ietf.org, rfc-editor.org, datatracker.ietf.org, etc.) could display that an RFC is an IETF Standard in clearer ways.  Only the .txt version can’t change, the pdf and html that are probably used the most these could make the status clearer.

I also think that the ambiguity between what is an IETF Standard and what is not an IETF Standard has served the Internet well.  Vendors, operators, researchers, and individuals get benefit from this ambiguity.  Even the IETF Stream that publishes documents that are not IETF Standards like BCP, Experimental, and Informational takes advantage of this ambiguity.  Perhaps this is a feature and not a problem.

Lastly, I think this experiment will do harm.  Besides harming the other Streams that will no longer be able to use RFC series, the creation of new series other than the RFC series will  create even more confusion over what is an IETF Standard.  RFCs produced earlier before the split happens, will now effectively all become IETF Standards. I think this proposal will have exactly the opposite effect as was intended.

Bob

---

From: "Paul Hoffman" <[email-masked]>
Date: Tue, 05 Jun 2018 09:40:07 -0700

> of issues with the proposal.

+1 to (literally) every paragraph of Bob's message.

It is easy to demonstrate that some people are confused about not all 
RFCs being standards. Each time this problem comes up, we ask "and what 
tangible damage has come of that conclusion" and I have yet to hear of a 
single credible instance that would mean much. In order to justify the 
harm to the IAB, IRTF, and ISE streams, we would need to see a 
reasonable set of such instances.

--Paul Hoffman