Re: [Rfcplusplus] Sunk cost + not about us

[Eric C Rosen <[e-mail]>]

On 7/9/2018 6:17 PM, Richard Barnes wrote:
>
> Suppose someone came to you with the following problem statement:
>
> - We have 16 (or so) types of document that we want to publish
> - We need readers of one of these documents to be clear on which type 
> they're reading
>
> Is there anyone here who would look at that problem statement and say, 
> "The ideal way to do that is to throw all the documents into one 
> linear series, and have the reader look for distinguishing marks in 
> the text of the document"?  We shouldn't keep supporting a system we 
> wouldn't build today.

The bias here is in the statement of the problem.

One could equally frame the problem as:

- We have a long-standing and well-recognized series of documents 
containing a lot of useful information about how the Internet works, and 
about how one can interoperate with existing Internet deployments.

- There are a number of different procedures for getting a document 
published in that series.

- Sometimes it is of interest to the readers to know which procedure 
resulted in the publication of a particular document.

How would you solve this problem?

Well, you could add some text to each document saying which procedure 
resulted in the publication of the document.

Alternatively, you can say, "Well, we need to break the series up into 
16 different series, each with its own name, and with no apparent 
relation to the pre-existing series.  Then when one wants to understand 
some aspect of the Internet, one has 15 more places to look.  And before 
one can find out how to interoperate with an existing deployment, one 
has to figure out which of the series is likely to have the documents 
one needs.  Of course, to see all the relevant documents, one may have 
to look at two or three series, good luck finding them."

I can't see that the latter alternative has much to recommend it. The 
former alternative seems much more sensible.

BTW, the statement "we need readers of these documents to be clear on 
which type they're reading" is not a correct statement of the problem 
anyway.  Most of the anecdotes about confusion have to do with folks 
that have never read the documents and never will.  The RFP-writers who 
list RFC numbers without having a clue what's in those RFCs will still 
generate confusing and non-implementable RFPs.  The need to educate the 
customer could be regarded as a waste of time, but really it's just 
another aspect of sales support.

Even the folks who do read the documents don't necessarily have to be 
clear on the procedure that caused the document to be published. If 
you're reading a protocol spec, it's probably because you need to 
interoperate with some existing deployments, and whether the protocol 
went through some particular process is irrelevant.

>
> To try to be slightly more systematic, I sent a survey out over the 
> weekend to a bunch of communities I participate in that are 
> "IETF-adjacent".  It got 115 responses, and the data [1] are 
> consistent with the anecdata:

I think this pseudo-survey has been fully debunked by others.

If one wants to show that there is a problem, one should provide 
evidence that there have been many cases where folks have implemented 
and deployed the wrong protocol, because they got confused about the 
status of the RFCs that specify the protocol. The fact that folks not 
involved in the publication process cannot say which procedures caused 
the documents to be published is really of no importance at all.