Re: [art] Call for Consensus: Re: On BCP 190

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

Adam,

I think you should consider an alternate hypothesis to "no one
cares" and/or people "who do or might care cannot be reached".
It is that the amount of traffic on a small number of subjects
on the ART, architecture-discuss, and IETF lists has just been
too great for those of us who have other responsibilities
(inside or outside the IETF) to keep up on.    A quick check of
my "I need to find time to read this stuff" mail queue shows
over sixty unread messages with "BCP 190" in the subject line
and I've read a good many other messages.  I don't track the
TRANS list; I assume that, if I did, the count would be even
higher.  

Of course, the BCP 190 threads have not been the only ones.  We
have, or recently have had, a number of other discussion threads
going on about such topics of clearly earth-shaking importance
as whether 128 is a sufficiently auspicious number, to say
nothing of whether and how much we can overspecify the IETF-ISOC
relationship.

I appreciate your good intentions in asking that people
summarize or reprise remarks on the previous BCP 190-related
threads but many of us, perhaps especially those of us who have
been beaten up multiple times for repeating ourselves, just
don't have time and/or consider it to be not in the best
interests of the Internet to give this topic priority over
everything else.  And I suggest that, with the amount of traffic
on the general subject of BCP 190 and its relationship to other
work and the health of the Internet, the conclusion from two
messages on this particular thread in two weeks should be "good
try, but people were already worn out on this topic or the
experiment of asking for summaries on a specific thread failed"
rather than "no one cares or those who do are hiding somewhere".


That said, let me try for a quick and inadequate summary of what
I tried to say nearly a month ago in
https://mailarchive.ietf.org/arch/msg/art/Ef09SVAnIMfGfkHSbEni9iCYRas
and to which you responded that same day.  

I think "should we allow an exception to BCP 190 for CT" and
"should we soften the language of BCP 190 a bit" (both very
crude summaries) are answers to the wrong question and that the
right question is very important to the future of the Internet
or at least the relevance of IETF going forward.  

Apologies to those who came along too late to be familiar with
the battles of the 1980s and 1990s and to those who were closer
to the details than I was an might summarize this differently.
But the Internet technology "won" the so-called OSI wars and
became the dominant networking and internetworking technology in
large measure because the the Internet's design, and the ARPANET
design before it, were pragmatic to an extreme.  We made
decisions for individual applications based on the actual
functions that application was intended to support and for
protocols based on whether they worked well enough, and were
described well enough, to interoperate and determined success
the same way.  What we didn't do was to build elaborate models
or norms about how protocols should behave and then treat those
models and norms as a sort of Procrustean bed, evaluating
protocol quality based on conformance to the model or deciding
whether something was or was not legitimate based on how it fit
the bed or whether it should be stretched or chopped off if it
didn't.  

>From that historical point of view, the problem is that BCP 190
was approved at all and the only surprise is that it took this
long for it to become clear that it over-constrained real-world
applications.

To be clear and respond directly to your note of 23 July, in
which you wrote:


> It's going to take a while for me to formulate my thoughts
> around what you say below. To make sure I understand the class
> of constraints you're concerned about below, can you clarify
> whether you think they apply to:
> 
>   * Documents like BCP 200, RFC 2804, and BCP 188?

I see those three as being at least a little bit different,
essentially problem identification and policy statements rather
than constraints on protocol design.  I would see them as
problems the moment a piece of work came around and someone said
"you can't do that work in the IETF, or you cannot design a
protocol in such-and-such a way because one of those documents
says you can't" and was taken seriously.  I do see a separate
problem with how they, and other privacy-oriented documents and
statements have been used, but that is part of a separate rant.

>   * Documents like BCP 9 and BCP 92?

Also a completely different set of issues.  These documents are
essentially IESG statements, albeit with the claim of sufficient
community approval to justify BCP status, about how the IESG
intends to do business.  They do not constrain the design of
particular protocols (or even, in the case of BCP 92, the
content of particular documents).

>   * Documents like BCP 25, BCP 54, and BCP 83?

I wonder why you didn't add BCP 9 to that list.  These are IETF
procedural documents, differing from the previous group in that
they specify how the IETF works, not how the IESG operates.
They again do not constrain particular protocols.

If I wanted to pick other documents that concern me the way BCP
190 does, I'd start with
draft-thomson-postel-was-wrong/draft-iab-protocol-maintenance
but with the qualification that the IAB is entitled to its
opinion and presumably can't publish it as a BCP and insist that
new protocols conform to its suggestions.  

The thing I find objectionable about BCP 190 is that it
specifies a design model for URIs generally and then tries to
insist that new work conform to it.  It changes a full Internet
Standard (RFC3986) by using the BCP mechanism, something that,
for many years at least, we would not allow.  It arguably does
not so much update 3986 as it reinterprets some of its
provisions.   While objectionable, that would be ok in a BCP if
"BCP" were taken seriously as a general statement of preferred
practices, not a "you can't do this in the future, no matter
what the circumstances, because we said so" protocol constraint.
 
> You might see an unstated agenda in the categories of
> documents I list above, so I'll state it explicitly: in the
> general case, one person's important protections against a
> tragedy of the commons is another person's annoying impediment
> to be ignored and defeated. I get that not all of the above
> read on protocol design;

actually none of them do in the sense that BCP 190 does.

> but they do share the common feature
> that they've gone through the IETF consensus process (at least
> to the degree that such a process existed at the time of their
> respective publications). If we're going to carefully parse
> out the meanings of some of them as the will of the community
> while treating others as light guidelines to be ignored when
> they become cumbersome, we're going to need to agree on a
> pretty bright line that divides those categories.

First of all, if you review RFC 2026 and understand it as I
always have, BCPs (other than those that specify IETF or IESG
procedures and the like) do not represent "the will of the
community" at all.   They represent community consensus about
desirable (or "best") contemporary practices.   They are not
protocol specifications ("Technical Specifications" in
2026-speak) and they are not Applicability Statements either.
Both types of traditional standards track documents (Section 3
or 2026)-- TS and AS -- presumably represent that will of the
community about what should be done and how.   From that
standpoint, a BCP is just commentary.   Section 5 of 2026 does
say "...best current thinking on a statement of principle or on
what is believed to be the best way to perform some operations
or IETF process function" but I don't think that contradicts
what I'm saying because best current thinking can change.  So,
if RFC 7320 represents  best current thinking as of July 2014
and some document comes along that represents newer thinking,
potentially involving conditions that 7320 did not consider, it
is probably entirely reasonable to insist that the authors of
the new document explain those conditions and resulting
thinking.   It is closer to that Procrustean bed if those
authors have to apply for an exception to BCP 190 or relitigate
it as a condition for moving forward.

I think that is at least close to your bright line.

best, 
   john

--On Monday, August 19, 2019 16:47 -0500 Adam Roach
<[e-mail]> wrote:

> I've seen precious little response to this (two messages in
> two weeks), and conclude that people either do not care; or,
> the people who do care can't reasonably be reached to weigh in
> on the topic. That said, I think that these responses combined
> with the input received during IETF 105 are a weak signal that
> that there is support for adjusting BCP 190 at least to the
> extent necessary to allow the "provisioned directory prefix"
> approach used by CT.
> 
> So I'm going to clear my DISCUSS under the assumption that
> Mark will be putting forth a proposed amendment to BCP 190 in
> the near future. I'm happy to AD sponsor publication of such a
> change, assuming we can get a more vigorous level of
> participation than we did on this thread.
> 
> /a
> 
> On 8/2/19 3:15 PM, Adam Roach wrote:
>> For the purposes of clearing my discuss, I intend to read the 
>> responses to Mark's message below as a reflection of
>> consensus from  the community. If you have thoughts on the
>> topic, please weigh in on  the ART-area mailing list no later
>> than Friday, August 16th.
>> 
>> People who have participated in the discussion in TRANS are
>> very much  welcome to re-express their opinions in this
>> thread. I'm also hoping  that we get some input from other
>> participants -- even if it's  something as simple as "this
>> sounds good to me" -- to make sure all  relevant perspectives
>> are taken into account.
>> 
>> Thanks!
>> 
>> /a
>> 
>> On 8/2/19 1:55 PM, Mark Nottingham wrote:
>>> It sounds like you (collectively) want an exception in
>>> BCP190 still,  correct?
>>> 
>>> If so, I think we just need to craft some language about
>>> that for  inclusion in the spec; I'd imagine it need only be
>>> a sentence or two  about it. Then the AD(s) need to convince
>>> themselves that it reflects  consensus.
>>> 
>>> The underlying issue is the text in 2.3 of BCP190; I think
>>> the  emerging consensus is that it's too strict, in that it
>>> can be read to  preclude using a prefix approach with a MUST
>>> NOT, when in fact the  potential harm to other applications
>>> / the Web overall is pretty small.
>>> 
>>> Does anyone disagree with that?
>>> 
>>> Cheers,
>>> 
>>> 
>>>> On 31 Jul 2019, at 2:10 pm, Jacob Hoffman-Andrews 
>>>> <[e-mail]> wrote:
>>>> 
>>>> On Sat, Jul 27, 2019 at 11:26 PM Larry Masinter
>>>> <[e-mail]> wrote: The use of / in the path of URLs was
>>>> supposed to
>>>> 
>>>> be restricted to hierarchical data, and yet CT doesn't
>>>> do that.
>>>> 
>>>> http://masinter.blogspot.com/2019/05/on-nature-of-hierarchi
>>>> cal-urls.html 
>>>> 
>>>> 
>>>> 
>>>> CT and all prefix-using APIs do that, with a single level
>>>> hierarchy.  The domain owner specifies a prefix, ending
>>>> with a "/". All of the  URLs that are part of the API
>>>> follow that prefix - they are  subordinate in the hierarchy.
>>>> 
>>>> Coming back to the main point: What remains in order to
>>>> find  consensus on this issue?
>>>> 
>>>> Thanks,
>>>> Jacob
>>> -- 
>>> Mark Nottingham   https://www.mnot.net/
>>> 
>>> _______________________________________________
>>> art mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/art
>> 
>> 
>> _______________________________________________
>> art mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/art
> 
> 
> _______________________________________________
> art mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/art