Re: [Rfcplusplus] Sunk cost + not about us

[Richard Barnes <[e-mail]>]

On Mon, Jul 9, 2018 at 6:32 PM Joel M. Halpern <[e-mail]> 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/rfcplusplus
> >
>