Re: [Rfcplusplus] Sunk cost + not about us

[John C Klensin <[e-mail]>]

Eric,

Thanks for, IMO, a very good summary.   One addition: because
the BOF request starts from a very old description of/assertions
about the supposed confusion problem, it seems to me to be
incumbent on those who claim there is still a problem serious
enough to require drastic action to demonstrate that the many
changes we have introduced to clarify the status of documents
since then have been ineffective.

thanks again,
   john
  

--On Tuesday, July 10, 2018 13:59 -0400 Eric C Rosen
<[e-mail]> wrote:

> 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.
> 
> 
> _______________________________________________
> Rfcplusplus mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rfcplusplus