Subject: Re: [art] On BCP 190

From: Mark Nottingham <[email-masked]>
Date: Fri, 2 Aug 2019 11:55:14 -0700

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 <[email-masked]> wrote:
> 
> On Sat, Jul 27, 2019 at 11:26 PM Larry Masinter <[email-masked]> 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-hierarchical-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/

---

From: Adam Roach <[email-masked]>
Date: Fri, 2 Aug 2019 15:15:14 -0500

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:
> _______________________________________________
> art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/art

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Fri, 2 Aug 2019 13:16:42 -0700

> 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 t…
This sounds good to me, thanks.

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 2 Aug 2019 22:51:57 +0200

> On Aug 2, 2019, at 22:15, Adam Roach <[email-masked]> 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
> 

This does sound good to me.

I hope we don’t put the topic back on the shelves with that specific decision for TRANS; we still need to have a feeling of the general shape of that exception as it will apply for other web-based protocols we define.

Grüße, Carsten

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 2 Aug 2019 13:53:05 -0700

Agreed; I'm planning an -00 of a bis for discussion.

Cheers,

> On 2 Aug 2019, at 1:51 pm, Carsten Bormann <[email-masked]> wrote:
> 
> 
>

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 3 Aug 2019 00:27:16 +0100

On 02/08/2019 19:55, Mark Nottingham wrote:
> 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.
> 
No, I agree that's a good description of the situation.

S.

---

From: Rob Sayre <[email-masked]>
Date: Fri, 2 Aug 2019 16:33:21 -0700

This sounds good to me.

thanks,
Rob

On Fri, Aug 2, 2019 at 1:15 PM Adam Roach <[email-masked]> wrote:

> > 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.
> >
> >> 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.
> >>

---

From: Tony Finch <[email-masked]>
Date: Mon, 5 Aug 2019 16:25:45 +0100

Mark Nottingham <[email-masked]> wrote:
> 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.

Yes.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Faeroes, Southeast Iceland: Easterly or northeasterly 4 to 6. Slight or
moderate, occasionally rough later. Rain in Faeroes, but mainly fair in
Southeast Iceland. Moderate or good, occasionally poor in Faeroes.

---

From: Rob Stradling <[email-masked]>
Date: Thu, 8 Aug 2019 22:28:46 +0000

This sounds good to me.

On 02/08/2019 21:15, Adam Roach wrote:
>> 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.
>>
>> potential harm to other applications / the Web overall is pretty small.
>>
>>> 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.
>>>

-- 
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

---

From: Adam Roach <[email-masked]>
Date: Mon, 19 Aug 2019 16:47:57 -0500

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.
>
> 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
>

---

From: John C Klensin <[email-masked]>
Date: Tue, 20 Aug 2019 02:06:24 -0400

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
<[email-masked]> 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
> 
>> 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
>> 
>>> 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.
>>> 
>>>> On Sat, Jul 27, 2019 at 11:26 PM Larry Masinter
>>>> <[email-masked]> wrote: The use of / in the path of URLs was
>>>> supposed to
>>>> 
>>>> be restricted to hierarchical data, and yet CT doesn't
>>>> do that.
>>>> 
>>>> 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.
>>>>

---

From: Melinda Shore <[email-masked]>
Date: Mon, 19 Aug 2019 23:04:53 -0800

On 8/19/19 1:47 PM, Adam Roach wrote:
> can't reasonably be reached to weigh in on the topic. 

It's August and an awful lot of people are on holiday.  I'm
still digging through my email after two weeks away.  I've
sent a nudge to the trans mailing list in the interest of
getting more input on this, but discussion in Montreal and
afterwards suggested that the interest in finding some
reasonable compromise is broader than in just trans.

> more vigorous level of participation than we did on this thread.
Thanks very much - this sounds like a reasonable way forward.
We'll make sure to get more participation from the CT community,
since we're the ones with the most pressing use case, from what
I can see.

Melinda

-- 
Melinda Shore
[email-masked]

Software longa, hardware brevis

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 20 Aug 2019 17:34:14 +1000

John,

> On 20 Aug 2019, at 4:06 pm, John C Klensin <[email-masked]> wrote:

[ many words elided ]

> insist that new work conform to it.

[...]

> It arguably does not so much update 3986 as it reinterprets some of its

[...]

> So,

As has been said, I think that we failed to distinguish between practices that could be harmful to other uses -- and therefore should be prohibited -- and those that are just ones you want to think about before engaging in. I committed to performing an update to reflect this, so before we spill too many bits on this topic, perhaps it would be good to look at that and then discuss.

To that end, I've just published a -00 [1] that's just a copy of the BCP; I'll do some refinement along the lines above and then see where we're at.

Cheers,

1. draft-nottingham-rfc7320bis, although <https://mnot.github.io/I-D/rfc7320bis/> might be easier on the eyes.

---

From: John C Klensin <[email-masked]>
Date: Tue, 20 Aug 2019 06:55:55 -0400

Mark,

Happy to wait, but a few comments going forward:

* For Adam, there is some question in my mind about whether it
is desirable to clear a Discuss based on a plan about a document
that has not been written yet, that has no firm schedule, etc.

* It seems to me that your "for the users" draft suffers from
some of the same issues as 7320.  It might be worth having a
look at that concurrently and in the same light.

* If you/we are going to do a 7320bis, a careful examination of
whether it should really be handled as a BCP or whether it is an
A/S or actual substantive update to 3986 would be in order.  In
addition, several of the comments in 7320 seem far more relevant
to locator-type URIs rather than name-type ones.  The revision
should probably be scrutinized to be sure that it doesn't say
things that does not invite a tangle or other awkwardness for
URNs or, even in theory, other name-type URI.

I guess the good news is that a 7320bis is likely to get much
closer examination in the community than it now appears that
7320 received.

best,
    john

--On Tuesday, August 20, 2019 17:34 +1000 Mark Nottingham
<[email-masked]> wrote:

>> 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.
> 
> [...]
> 
>> So,
>> 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
>> authors have to apply for an exception to BCP 190 or
>> relitigate it as a condition for moving forward.
> 
> As has been said, I think that we failed to distinguish
> between practices that could be harmful to other uses -- and
> therefore should be prohibited -- and those that are just ones
> you want to think about before engaging in. I committed to
> performing an update to reflect this, so before we spill too
> many bits on this topic, perhaps it would be good to look at
> that and then discuss.
> 
> To that end, I've just published a -00 [1] that's just a copy
> of the BCP; I'll do some refinement along the lines above and
> then see where we're at.
> 
> Cheers,
> 
> 1. draft-nottingham-rfc7320bis, although
> <https://mnot.github.io/I-D/rfc7320bis/> might be easier on
> the eyes.
> 
> --

---

From: Ben Campbell <[email-masked]>
Date: Tue, 20 Aug 2019 10:30:12 -0500

Commenting on just one point (I am agnostic on the others):

> On Aug 20, 2019, at 5:55 AM, John C Klensin <[email-masked]> wrote:
> 
> Mark,
> 

In this case, I think Adam is saying that we don’t have consensus that the draft in question is really wrong.

It could take months to years to figure out what we really want BCP190 to say. I agree with Adam that we should not hold  current work hostage to that. Holding up work due to non-critical externalities is a very good way to kill momentum.

[…]

Thanks!

Ben.

---

From: John C Klensin <[email-masked]>
Date: Tue, 20 Aug 2019 12:37:52 -0400

--On Tuesday, August 20, 2019 10:30 -0500 Ben Campbell
<[email-masked]> wrote:

>> is desirable to clear a Discuss based on a plan about a
>> document that has not been written yet, that has no firm
>> schedule, etc.
> 
> In this case, I think Adam is saying that we don't have
> consensus that the draft in question is really wrong.
> 
> It could take months to years to figure out what we really
> want BCP190 to say. I agree with Adam that we should not hold
> current work hostage to that. Holding up work due to
> non-critical externalities is a very good way to kill momentum.
> 
> […]

Then we are very much in agreement.  A different way of
expressing the concern about protocol-restricting documents that
are treated as requirements is that other work gets held up
while we try to converge on protocol models, philosophy of
protocols, or other externalities that become critical only if
we make them critical... and doing that is generally a bad idea.
Holding up work that way not only kills momentum, but may cause
critical people to simply give up and go away while others
debate the angel population of the heads of various pins.

best,
    john

---

From: Adam Roach <[email-masked]>
Date: Tue, 20 Aug 2019 12:03:28 -0500

On 8/20/19 1:06 AM, John C Klensin wrote:
> thinking.

Certainly; and if the thinking had come out of, say, a working group 
whose charter dealt primarily with URIs or with HTTP, then it would be 
somewhat more plausible that people with an appropriate depth of domain 
knowledge had been involved in that process.

I suspect that part of the problem is that you're too close to ART 
technologies to see the forest for the trees, and so assume a level of 
expertise in ART technologies across the entirety of the IETF that is 
somewhat higher than actually exists.

This might become clearer if we hypothesize an identical situation with 
the players reversed: if an ART working group had specified the 
population of an initialization vector for an encryption algorithm in a 
way that had been documented by the SEC area as problematic, I would 
hope that the SEC ADs wouldn't write that off as simply representing 
"newer thinking" about cryptography, and that they would insist that the 
document conform to documented security practices; or, failing that, at 
least involve the SEC community in a discussion about whether the 
specific use of security technology was, in fact, problematic.

If you think that would be the wrong outcome, then I believe we simply 
have an irreconcilable difference of opinion. I will, of course, 
consider input from the community on this topic and act accordingly, but 
I suspect that most people will, after careful consideration, agree that 
these kinds of backstops are actually useful.

/a

---

From: Adam Roach <[email-masked]>
Date: Tue, 20 Aug 2019 12:14:50 -0500

> that has not been written yet, that has no firm schedule, etc.

I agree that it's not ideal. I'm having to balance the possibility that 
the end result of community discussion will result in not removing this 
restriction against delaying the TRANS document until we're 100% 
certain. Given that we've done a reasonable shaking of the trees over 
the past month, and no one has dropped out to strongly defend the 
specific provision in question, it appears likely that the end result 
will work out. Is this perfect? No. Is it pragmatic? Yes; and you've 
been championing pragmatism in this thread, so I would expect you to be 
on board.

/a

---

From: John C Klensin <[email-masked]>
Date: Tue, 20 Aug 2019 14:33:49 -0400

--On Tuesday, August 20, 2019 12:14 -0500 Adam Roach
<[email-masked]> wrote:

> I agree that it's not ideal. I'm having to balance the
> possibility that the end result of community discussion will
> result in not removing this restriction against delaying the
> TRANS document until we're 100% certain. Given that we've done
> a reasonable shaking of the trees over the past month, and no
> one has dropped out to strongly defend the specific provision
> in question, it appears likely that the end result will work
> out. Is this perfect? No. Is it pragmatic? Yes; and you've
> been championing pragmatism in this thread, so I would expect
> you to be on board.

I am on board (a bit more explanation in my response to Ben).   

I don't think we are far apart, so let me try saying this in a
different way.  I think there is at least rough consensus that
parts of RFC 7320 were a mistake, whether because their were
overly prescriptive or for some other reason.  I don't think
there is consensus about which parts or what the right remedy
for them is.  The best way to deal with that problem is exactly
what you and Mark have proposed -- get a new, replacement, I-D
up and focus on it rather than on picking 7320 apart.

In a more perfect world, I'd like to see 7320 deprecated, with
the focus on that new document and no actual or apparent
conflict between CT and anything.  If that were proposed now,
I'd oppose it because it would hold the other work up by at
least four weeks to no good purpose.  On the other hand, while I
don't think it is important enough to hold things up either, I'd
be happier with a statement from you that, instead of saying
that you are clearing the Discuss because Mark is working on a
revision, said something closer to that you are clearing the
Discuss because there is a plan about a revision but, if that
doesn't happen, you will open a discussion about deprecating
7320.  Don't waste time with it now, but I believe that thinking
about the difference might inform future actions and might
better explain what I'm objecting to.

Also...

>...
> I suspect that part of the problem is that you're too close to
> ART technologies to see the forest for the trees, and so
> assume a level of expertise in ART technologies across the
> entirety of the IETF that is somewhat higher than actually
> exists.

I actually don't think so in this case.   FWIW, remember that
I'm spending most of my IETF time these days on
Internationalization, a topic area that has been rooted in Apps
and now ART but that his implications in many IETF areas.  It
would it would be quite difficult to underestimate the level of
expertise across the entirety IETF or even in ART as a whole.
So I am reasonably familiar with that problem. 
 
> This might become clearer if we hypothesize an identical
> situation with the players reversed: if an ART working group
> had specified the population of an initialization vector for
> an encryption algorithm in a way that had been documented by
> the SEC area as problematic, I would hope that the SEC ADs
> wouldn't write that off as simply representing "newer
> thinking" about cryptography, and that they would insist that
> the document conform to documented security practices; or,
> failing that, at least involve the SEC community in a
> discussion about whether the specific use of security
> technology was, in fact, problematic.

Agreed.  But not quite an identical problem.  If this had been
about, e.g., an issue with calendaring, I'd say "nearly
identical problem".  If there were reasonably high confidence
that the active participants in the WG understood the issues
(and, btw, there were more than three or four of them), I would
also expect that most of us would be comfortable going forward
within in-depth review from elsewhere in the IETF.   However,
that is much less true of things like URIs or some other
web-associated technologies, especially when the IETF is
considering foo-over-HTTP protocols and XML and JSON as general,
and perhaps mandatory, data representation structures.  Similar
comments can be made about i18n because, while much of the
action is in ART, there are issues about identifiers and other
issues in multiple areas --Security and Internet being obvious
examples-- that the IETF is in trouble if all of the expertise
is in ART and others become inclined to just let things go
(especially given how little expertise there actually appears to
be in ART).

There is another difference.  In the example you used, it would
be reasonable to assume that the documentation in the SEC area
actually represented consensus  in the area and among experts (I
think, at least historically, almost the same thing in SEC,
although not quite) about the problems.   I don't believe that
is the case about 7320 across the ART area, as some of the
discussion _among active participants in ART_ in the various
recent threads about BCP 190 illustrates.  I don't believe it
was the case five years ago either, but that would be hard to
prove at the time.  That suggests an intra-ART problem and is
closely connected to why I've felt from the beginning of this
discussion that the IETF had a BCP 190 problem and not a problem
with the CT work.  

So, should ART have flagged this?  Absolutely.  But then I think
we should have figured out, much more quickly than we have, that
there are fundamental problems with BCP 190, started addressing
those problems a month or two ago, and figured out how to Do the
Right Thing and move on -- both to clear the CT work to progress
and to start cleaning up 7320.  

> If you think that would be the wrong outcome, then I believe
> we simply have an irreconcilable difference of opinion. I
> will, of course, consider input from the community on this
> topic and act accordingly, but I suspect that most people
> will, after careful consideration, agree that these kinds of
> backstops are actually useful.

I think that is the right outcome.  I also think that at least
part of that outcome is tied up with what we (at least used to)
call cross-area review.  I don't think the IETF is doing nearly
as well about that as we used to.  That is mostly a separate
topic, but I think it calls for extra caution.  

best,
    john

---

From: Adam Roach <[email-masked]>
Date: Tue, 20 Aug 2019 14:22:12 -0500

On 8/20/19 1:33 PM, John C Klensin wrote:
> I'd
> revision

Thanks for giving me a chance to clear this up, since it's not what I 
meant, although I can see how the structure of my email may 
inadvertently give that impression.

The rationale for clearing my DISCUSS is:

> 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.

The mention of updating the document is a follow-on from this 
observation, but not at all the rationale for clearing the discuss.

/a

---

From: John C Klensin <[email-masked]>
Date: Tue, 20 Aug 2019 16:35:10 -0400

--On Tuesday, August 20, 2019 14:22 -0500 Adam Roach
<[email-masked]> wrote:

> Thanks for giving me a chance to clear this up, since it's not
> what I meant, although I can see how the structure of my email
> may inadvertently give that impression.
> 
>> 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.
> 
> 

That helps.  But it also takes us full circle because:  

* RFC 7320 is either normative, and the 2119 language in it lays
out firm requirements, or it isn't.  It reads as it it is
normative, it contains MUST statements, and it cites 2119
normatively.   Both that, and the discussions of the last few
weeks, strongly imply that the community thinks it is normative
and its author thought it was normative at the time it was
approved.

* Nothing in that document, or in any more general IETF
procedural specification I can find, gives either a single AD or
the IESG the authority to waive a normative requirement of a
standards-track document without at least an IETF Last Call that
addresses the specific issue and, normally, a Last Call on a new
document that waives or eliminates the requirement in question.

* Independent of how you interpret the discussions of the last
few weeks (we agree that there is at least weak consensus within
the ART Area that 7320 needs some adjustment), there is, AFAIK,
no posted document that makes those adjustments or allows the
IESG to make exceptions, much less an IETF Last Call on such a
document.

* Given that, whatever agreement you see (and cite) does not
justify your taking a position that sounds a lot like "well, BCP
190 prohibits this but there is a 'weak signal that that there
is support for adjusting BCP 190' and therefore never mind what
it actually says".   The IESG does not have the authority and
withdrawing the Discuss and having the IESG let this go through
has the appearance of the IESG thinking that whatever it wants
to do supercedes most or all of the IETF's procedural rules
about document approval.

Because I'd rather have a discussion than have this note
interpreted as a thread, I promise to not appeal should the IESG
follow that course, but I suggest it would set a precedent about
claims of IESG authority independent of even a pretense of IETF
consensus that the IETF would probably come to regret.

So, it would seem to me that, without violating any fundamental
procedures and in the interest of Doing the Right Thing and
unblocking the CT document, you (and the IESG) could do any of
the following.   The first would involve a certain amount of
nose-holding, but, IMO, that is far less objectionable than
simply kissing off our procedures.

(1) Go back to what I thought you said and approve this with a
clear understanding that either a replacement for 7320 or an
action to deprecate it, killing its advice until a more
temperate replacement was approved.

(2) Put normative language into the CT document pointing to
Mark's draft.  That would allow the IESG to approve it but would
introduce an RFC Editor normative reference hold on publication.
I don't know whether that would block important work or not.

(3) Have someone write a document that either deprecates 7320 or
updates it sufficiently to turn it into general guidance, not a
collection of normative requirements.   Push that document
through the system (presumably requiring a four-week LC).

(4) Have someone write a document that adds language to 7320 to
update it to allow the IESG to make exceptions on its own
judgment and without community consensus.  Same comment about
pushing that document through and four-week Last Calls.

(5) Section 6.4 of 2026 has been widely interpreted as not
requiring a replacement document to change the classification of
a standard.  So, presumably the IESG could reclassify 7320 to
Informational or Historic on the basis of a Statement.  I'd hope
that would involve an IETF Last Call too, but I'm not sure that
is a firm requirement (remember that, once upon a time, the RFC
Editor could reclassify documents on his own initiative).

I'm open to other ideas if you have them, but I think that going
down the path toward a "never mind what BCP 190 says, do what
seems sensible on the IESG's say-so" decision would be a really
bad idea for the future of the IETF.  Because I really do want
to see progress here, if you conclude that (3) or (4) above is
the right course of action and you can't find a volunteer, I'll
try to push everything else in my queue aside and do some
writing.  

Again, from my perspective, the problem here is RFC 7320, not
the new work.  And, if there is a lesson here, it is either "no
more documents like that, especially as normative Standards
Track documents disguised as BCPs"  or "if we are going to have
one, even as an Applicability Statement, it MUST (sic) include a
clear exception procedure.

Sorry about this, but I've very concerned about the precedents
this would set.
best,
   john

---

From: Adam Roach <[email-masked]>
Date: Tue, 20 Aug 2019 15:36:03 -0500

> and to start cleaning up 7320.

You are, of course, entitled to a differing opinion; but I find your 
characterization of the speed with which I've moved on this topic to be 
either misinformed or misleading, and I'm troubled by the implications 
of either case.

To be clear about the timeline: although the document was reviewed by 
the IESG in March, the first hint from its authors or any of the working 
group participants indicating that the provisions of BCP 190 might be 
considered a serious obstacle was on June 26th [1], and even that 
message was rather circumspect, indicating that the working group was 
positing "alternate means of satisfying BCP 190." It wasn't until the 
second week of July that it became completely clear that the WG believed 
that none of the alternate approaches offered by BCP 190 were acceptable 
to them.

Given the, as you've pointed out, summer vacation schedule that many 
people have, I believe that taking on the order of one to two months to 
gather input on this topic and come to a conclusion that allows them to 
move forward is eminently reasonable (especially given the level of 
urgency implied by the three months they took to provide initial 
responses to any of their several IESG review comments).

/a

____
[1] https://mailarchive.ietf.org/arch/msg/trans/aq9Ojwqw8cPtXsUsofJhE_YO4Q0

---

From: Adam Roach <[email-masked]>
Date: Tue, 20 Aug 2019 16:20:04 -0500

> temperate replacement was approved.

The understanding that Mark will produce such a document definitely 
exists; and if there were no clear path to getting a such revision in 
place, the plan would would look different. If that document doesn't 
materialize and progress, we'll have to consult the community to 
determine support for alternate solutions (of which deprecation would be 
an option); but I don't see value in churning mailing list traffic 
coming to consensus on the course of action for every potential failure 
case. I do want to thank you for standing ready to contribute to the 
effort if such a failure does occur.

/a

---

From: John C Klensin <[email-masked]>
Date: Tue, 20 Aug 2019 17:31:31 -0400

--On Tuesday, August 20, 2019 15:36 -0500 Adam Roach
<[email-masked]> wrote:

>> So, should ART have flagged this?  Absolutely.  But then I
>> think we should have figured out, much more quickly than we
>> have, that there are fundamental problems with BCP 190,
>> started addressing those problems a month or two ago, and
>> figured out how to Do the Right Thing and move on -- both to
>> clear the CT work to progress and to start cleaning up 7320.

> You are, of course, entitled to a differing opinion; but I
> find your characterization of the speed with which I've moved
> on this topic to be either misinformed or misleading, and I'm
> troubled by the implications of either case.

Adam, no personal criticism intended.   And I was looking at a
different timeframe, specifically...
 
> To be clear about the timeline: although the document was
> reviewed by the IESG in March, the first hint from its authors
> or any of the working group participants indicating that the
> provisions of BCP 190 might be considered a serious obstacle
> was on June 26th [1], and even that message was rather
> circumspect, indicating that the working group was positing
> "alternate means of satisfying BCP 190." It wasn't until the
> second week of July that it became completely clear that the
> WG believed that none of the alternate approaches offered by
> BCP 190 were acceptable to them.

And I was counting from March.  If the first hint of an issue
was in late June, that certainly isn't an ART problem although,
by your argument about cross-area reviews, one might have hoped
that some ARTarea reviewer would have caught it.  Note "hoped"
-- no blame either way.

> Given the, as you've pointed out, summer vacation schedule
> that many people have, I believe that taking on the order of
> one to two months to gather input on this topic and come to a
> conclusion that allows them to move forward is eminently
> reasonable (especially given the level of urgency implied by
> the three months they took to provide initial responses to any
> of their several IESG review comments).

That sounds completely reasonable.  But, IMO, it also eliminates
most of the arguments against simply taking the time now to
patch RFC 7320 as suggested in my options (3) or (4) and doing
the one month Last Call.  I was trying to figure out a way to
speed things up because of the time since March (again, not in
any way your fault) but, if you and/or  the WG believe that the
relevant date is sometime in June or July, then the right
answer, IMO, is to do this right.  

Again, I'm not blaming anyone, least of all you.  I'm just
trying to find a way to get this done that doesn't violate our
procedures for approving or modifying/updating standards track
documents.

best,
   john

---

From: Larry Masinter <[email-masked]>
Date: Wed, 21 Aug 2019 07:50:19 -0700

Just back from an August vacation, apologies for brevity
IMHO 
An update to BCP 190 should take into account the fact that
there is not a consensus for the "best" of various "current
practice" for avoiding the URL squatting identified (namely
using a hypermedia format to let the server control the
URL format completely rather than the API control the
URL syntax and making the client do string processing.

As far as process goes, I think it's ok to drop the DISCUSS in
 question because it is Experimental and not Standards track.

As  Carsten Bormann <[email-masked]> wrote  Sunday, July 28, 2019 1:43 AM
Re: [art] On BCP 190

> 
> On Jul 28, 2019, at 08:26, Larry Masinter <[email-masked]> wrote:
> >
> > Now, why JSON-HAL is still an expired  Internet Draft is a puzzle.
> 
> (Slightly, but not completely off-topic:)
> 
> Probably because there are multiple ways to skin this cat and we never 
> tried to converge on one.
> 
> As a data point, for the applications in the CoRE working group, we 
> have mostly been able to avoid BCP190-style arguments by using 
> /.well-known, mainly because simple devices only tend to have one 
> service offered directly under / and because IoT device platforms tend 
> to provide the application developer full control over the URI space.  
> /.well-known/core provides a discovery mechanism for the entry point URIs
actually offered by a server.
> 
> For where this is not enough, the WG has just last week adopted CoRAL 
> (not yet resubmitted as draft-ietf, so you can find it at 
> draft-hartke-t2trg-coral) as our idea of a hypermedia format like HAL.  
> Up to now, we tried to make everything work with RFC 6690 link format, 
> but that has too many idiosyncrasies that started to get in the way of a
long-term way forward.