Re: [Rfcplusplus] Conversation as metaphor

[Eliot Lear <[e-mail]>]

On 12.07.18 04:47, Martin Thomson wrote:
> On Thu, Jul 12, 2018 at 12:19 PM Joel M. Halpern <[e-mail]> wrote:
>> At least in the areas I work in, RFCs when published describe protocols
>> which have seen limited implementation or deployment.  Even when we are
>> revising widely deployed protocols, the revisions or enhancements have
>> usually experienced limtitd implementation or deployment.  We like to
>> have some experience (IDR for example requires two implementations).  We
>> rarely have large numbers of vendors implementing, since most vendors
>> wait for the document to stabilize and be published as an RFC before
>> they implement.
> Yes, this is common.  What we did with HTTP/2 and TLS is perhaps weird
> in that we deployed pretty widely well before the RFC was published.

In interdisciplinary work of some form, the standard is really a
starting gun for implementation.  Also true when purchasing managers are
looking for a combination of interoperability and stability.

> My point was that the ability for the RFC to predict and ultimately
> describe the reality of the Internet is grounded in either the actual
> deployment (ideal) or the strength of the commitment of those who
> participate in the process (the process you describe).  That RFCs end
> up describing reality with a non-trivial proability means that we are
> moderately successful in identifying which protocols will be deployed.

Yes.  This goes to a rule that Brian Kantor of UCSD laid out very early
on (1992ish) with the series: RFCs provide their greatest utility when
they document existing practice (yes, he predated Clark on that).  I
would point out that value can be found in the independent stream and in
what we label "Informational" documents that contain specifications
perhaps as often as can be found in nascent standards.  Good examples
from the past include IAX, NFS, syslog, PGP, BGP4, and MPLS-VPNs. 
Perhaps today Chacha20,   Arguably all of these were de facto standards
long before the IETF touched them (so was IPv4).

At a cursory level that would argue for labeling not based on whether
something has achieved rough consensus in the IETF, but rather based on
how well fielded an approach is.  That would require two things: a
measure of adoption, something we have greatly struggled with in the
past, and relabeling from time to time.  Imagine for a moment, charging
the RFC Editor with establishing such a methodology for ALL documents. 
Now that would really get interesting ;-)  STD was *sort of* intended to
cover this ground, but it is very coarse grain, and requires a very high
bar, and to me has somewhat more political connotations for us than is
any real signal to a market.

Eliot