Re: [Rfcplusplus] Sunk cost + not about us

John C Klensin <john@jck.com> Tue, 10 July 2018 19:37 UTC

Return-Path: <john@jck.com>
X-Original-To: rfcplusplus@ietfa.amsl.com
Delivered-To: rfcplusplus@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9231D1292AD for <rfcplusplus@ietfa.amsl.com>; Tue, 10 Jul 2018 12:37:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2asLGmBAzHDM for <rfcplusplus@ietfa.amsl.com>; Tue, 10 Jul 2018 12:37:49 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27E2013104C for <rfcplusplus@ietf.org>; Tue, 10 Jul 2018 12:37:49 -0700 (PDT)
Received: from localhost ([::1] helo=JcK-T100) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john@jck.com>) id 1fcySJ-0005uq-Og; Tue, 10 Jul 2018 15:37:47 -0400
Date: Tue, 10 Jul 2018 15:37:47 -0400
From: John C Klensin <john@jck.com>
To: Eric C Rosen <erosen@juniper.net>, rfcplusplus@ietf.org
Message-ID: <B754964B3BD2C910AF6A3622@[10.99.23.6]>
In-Reply-To: <4624709a-1bca-f5d6-4012-3f83147bd39b@juniper.net>
References: <CAL02cgQbT8s0493SdbM7Gbw2ZiSV1kMHk+6=Z4BdC2Ky664CNg@mail.gmail.com> <4624709a-1bca-f5d6-4012-3f83147bd39b@juniper.net>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Mail-From: john@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/rfcplusplus/Sbs8l0mzd2dfbp-Fiujtxi_FQms>
Subject: Re: [Rfcplusplus] Sunk cost + not about us
X-BeenThere: rfcplusplus@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: For discussion of the RFC++ BoF proposal and related ideas <rfcplusplus.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rfcplusplus>, <mailto:rfcplusplus-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rfcplusplus/>
List-Post: <mailto:rfcplusplus@ietf.org>
List-Help: <mailto:rfcplusplus-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rfcplusplus>, <mailto:rfcplusplus-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Jul 2018 19:37:52 -0000

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
<erosen@juniper.net> 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
> Rfcplusplus@ietf.org
> https://www.ietf.org/mailman/listinfo/rfcplusplus