Return-Path: 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 17BE7130DFD for ; Tue, 10 Jul 2018 07:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.908 X-Spam-Level: X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com 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 Bjk-7oMXNNps for ; Tue, 10 Jul 2018 07:21:27 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B88C6128BAC for ; Tue, 10 Jul 2018 07:21:27 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id i12-v6so42929152oik.2 for ; Tue, 10 Jul 2018 07:21:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WFSY2zoSCVEcgkfS5PVkyd8EYejmXLvk5ibAcepDmB8=; b=ZGpuyGCxKmFbCeg7CDG53pEPSrn5RRrzM55TaoVW3e5Fw052FHnA9nd9fk5E7RPkcg Xv2u4q57mf+v7Xdb93p4qGxWglxNao9a2HZnfaJqaobeUDdDlDE8YNzA0HRGIja+Zof7 dWciGqFkZYUAl3znAZRf8+KVs8LptjgT24QaMyP+fa3+Bg84y6lpa7HvlMcoN3wjtgYU 2fguTq/afDytDnuBFnqWJ0Ynzn6uk3nU6bTfgxvhIsU7/DYYFBRPN76gZmGgF9EaUwg/ gGL4QQuaxWoVbMaesqMQtE3MnZ40/Ti9va4eEL2sELjYUsUQ6Pq9QgQh93R9+DUKGToF BUuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WFSY2zoSCVEcgkfS5PVkyd8EYejmXLvk5ibAcepDmB8=; b=UJq7kar+RrOY+g0kq6eb7JMN0dtZLfETCB+FpfRn98rG6/cY58VW0kCsC8xtrf1OC7 yTIhhH1MLrYwQJCT7osLg4bCc1/RiBrVDMj4HO6dMCV8tb809ImhUzql99TM+Mr5aK3/ ZbwFg/wssub1cRA5CQItdi6i3BmeR1VXXYT+KgUIz9YTdzXPR/eIpLVGl0rl06kOUxS8 IIAfEjOU1dYzDRjFTgqkHts4UG04spch6lawIdl9LjmjFhewU05uOopfWwk7s61EyarM gyzLn+dTL7j2AHOWAaGvQ5N2JI5aayWEagWYXbGxC0rOcNzpkUbfxgYc6XvqGyVjnddc UuLw== X-Gm-Message-State: APt69E3XF2K8WABqLEIwRN21lwSstOWtOClFclZORo9gB+CRiRLgPuMU UHfcHe5uo8Hr2syppgK1AMfu8CJRvdAQYNSMjNgtNQ== X-Google-Smtp-Source: AAOMgpdsAtJWGzDPK+/5f57aNWBK74KkWqY3TAYYLwGkwgzs7/GlNg4KKgOuXXh1s1LGMpJNNkHvaUKPghgv+GPnqnk= X-Received: by 2002:aca:5a45:: with SMTP id o66-v6mr26072495oib.155.1531232486749; Tue, 10 Jul 2018 07:21:26 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Barnes Date: Tue, 10 Jul 2018 10:21:15 -0400 Message-ID: To: "Joel M. Halpern" Cc: rfcplusplus@ietf.org Content-Type: multipart/alternative; boundary="0000000000007109ea0570a5d89d" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 14:21:32 -0000 --0000000000007109ea0570a5d89d Content-Type: text/plain; charset="UTF-8" On Mon, Jul 9, 2018 at 6:32 PM Joel M. Halpern wrote: > This formulation assumes that change does not have a cost. It does. I > agree that not changing has some cost. However, absent indication that > the changes will actually address the claimed problem... People are presenting indications. Attach what caveats you need to my little study; it's still real data from a relevant population. Do you have better data? > If we really want to change something that causes confusion in a way > that actually causes us process problems, maybe we should actually > tackle one? Without commenting on whether this I-D problem is a worthwhile problem to solve, it is not the one this list is here to discuss. --Richard > In particular, in looking at kinds of confusion, one of the > ones that causes the IETF real and significant problems is when outside > groups look at individual Internet Drafts, and treat them like working > group adopted products. (I would like to fix folks treating adotped > I-Ds as if they were finished RFCs, but given that those already have > clearly distinct labels, that does not seem possible.) > In one sense, fixing that would likely require changing quite a few > moving parts in our process. It is clearly something the IETF owns. It > is something that causes myriad issues between us and other standards > bodies and between us an users. We often have to actually put in work > pushing back on folks mis-characterizing individual I-Ds as IETF work. > > Yours, > Joel > > PS: I do not see how we can draw any conclusion from the very informal > survey. We have been lectured, with good reason, in the past about the > dangers of drawing conclusions from even carefully formulated and > carefully distributed surveys. > > On 7/9/18 6:17 PM, Richard Barnes wrote: > > Hey all, > > > > I'm still catching up on the many emails on this list, so I might be > > missing something, but I wanted to surface two arguments that seem to me > > to be pretty dispositive that there is a problem here to solve: > > > > > > 1. A recommendation to hold is a recommendation to buy / sunk cost > fallacy > > > > 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. > > > > > > 2. This is not about us > > > > There are a total of a little over 30 unique senders on this list. The > > person closest to being a newcomer is Joe Hall, whose first IETF meeting > > was IETF 89, more than four years ago. This discussion isn't about us > > -- it's about the much larger group of people who read these documents > > and try to build products off of them that work. > > > > In an ideal world, some of those folks would be participating here. > > Until that happens, we should rely on what data we can gather. We've > > already head several anecdotes, and they're pretty much all on one side > > -- the current arrangement causes confusion and makes RFCs less useful. > > > > 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: > > > > - 52% of respondents thought that an RFC was "A document published by > > the IETF that defines a technical standard for the Internet" > > > > - While 93% of respondents agreed that the IETF can publish RFCs, the > > other streams came in much farther behind; the IAB was second-most > > recognized, at only 26% > > > > - Nobody has any idea that about the taxonomy of RFCs. A majority of > > people said they thought that there were 5 types, but I would conjecture > > that's just an artifact of the options I put in there. > > > > Based on those observations, I hope it's clear to folks that there is a > > problem to be solved here.. The survey data, sketchy as they are, also > > point toward the solution, which is to refine the RFC label to have a > > much more limited semantic, probably only IETF and possibly only > standards. > > > > Hope that helps, > > > > --Richard > > > > [1] > > > https://docs.google.com/forms/d/e/1FAIpQLSeMoeR0TBWkZNpBKXJN3Am6nUL04Vr4-12T2VgEbiRdBwzngQ/viewanalytics > > > > > > _______________________________________________ > > Rfcplusplus mailing list > > Rfcplusplus@ietf.org > > https://www.ietf.org/mailman/listinfo/rfcplusplus > > > --0000000000007109ea0570a5d89d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon= , Jul 9, 2018 at 6:32 PM Joel M. Halpern <jmh@joelhalpern.com> wrote:
This formulation assumes that change does not ha= ve a cost.=C2=A0 It does.=C2=A0 I
agree that not changing has some cost.=C2=A0 However, absent indication tha= t
the changes will actually address the claimed problem...
<= br>
People are presenting indications.=C2=A0 Attach what caveats = you need to my little study; it's still real data from a relevant popul= ation.=C2=A0 Do you have better data?

=C2=A0
If we really want to change something that causes confusion in a way
that actually causes us process problems, maybe we should actually
tackle one?=C2=A0

Without commenting on wh= ether this I-D problem is a worthwhile problem to solve, it is not the one = this list is here to discuss.

--Richard
<= div>
=C2=A0
In particular= , in looking at kinds of confusion, one of the
ones that causes the IETF real and significant problems is when outside groups look at individual Internet Drafts, and treat them like working
group adopted products.=C2=A0 (I would like to fix folks treating adotped <= br> I-Ds as if they were finished RFCs, but given that those already have
clearly distinct labels, that does not seem possible.)
In one sense, fixing that would likely require changing quite a few
moving parts in our process.=C2=A0 It is clearly something the IETF owns.= =C2=A0 It
is something that causes myriad issues between us and other standards
bodies and between us an users.=C2=A0 We often have to actually put in work=
pushing back on folks mis-characterizing individual I-Ds as IETF work.

Yours,
Joel

PS: I do not see how we can draw any conclusion from the very informal
survey.=C2=A0 We have been lectured, with good reason, in the past about th= e
dangers of drawing conclusions from even carefully formulated and
carefully distributed surveys.

On 7/9/18 6:17 PM, Richard Barnes wrote:
> Hey all,
>
> I'm still catching up on the many emails on this list, so I might = be
> missing something, but I wanted to surface two arguments that seem to = me
> to be pretty dispositive that there is a problem here to solve:
>
>
> 1. A recommendation to hold is a recommendation to buy / sunk cost fal= lacy
>
> 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"?=C2=A0 We shouldn't keep supporting a system we= wouldn't build
> today.
>
>
> 2. This is not about us
>
> There are a total of a little over 30 unique senders on this list.=C2= =A0 The
> person closest to being a newcomer is Joe Hall, whose first IETF meeti= ng
> was IETF 89, more than four years ago.=C2=A0 This discussion isn't= about us
> -- it's about the much larger group of people who read these docum= ents
> and try to build products off of them that work.
>
> In an ideal world, some of those folks would be participating here.=C2= =A0
> Until that happens, we should rely on what data we can gather.=C2=A0 W= e've
> already head several anecdotes, and they're pretty much all on one= side
> -- the current arrangement causes confusion and makes RFCs less useful= .
>
> 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".=C2=A0 It got 115 responses, and the data [1= ] are consistent
> with the anecdata:
>
> - 52% of respondents thought that an RFC was "A document publishe= d by
> the IETF that defines a technical standard for the Internet"
>
> - While 93% of respondents agreed that the IETF can publish RFCs, the =
> other streams came in much farther behind; the IAB was second-most > recognized, at only 26%
>
> - Nobody has any idea that about the taxonomy of RFCs.=C2=A0 A majorit= y of
> people said they thought that there were 5 types, but I would conjectu= re
> that's just an artifact of the options I put in there.
>
> Based on those observations, I hope it's clear to folks that there= is a
> problem to be solved here..=C2=A0 The survey data, sketchy as they are= , also
> point toward the solution, which is to refine the RFC label to have a =
> much more limited semantic, probably only IETF and possibly only stand= ards.
>
> Hope that helps,
>
> --Richard
>
> [1]
> https://docs.google.com/forms/d/e/1FAIpQLSeMoeR0TBWkZNpBKXJN3Am6nU= L04Vr4-12T2VgEbiRdBwzngQ/viewanalytics
>
>
> _______________________________________________
> Rfcplusplus mailing list
> Rfcplusplus@= ietf.org
> https://www.ietf.org/mailman/listinfo/rfcplusp= lus
>
--0000000000007109ea0570a5d89d--