Re: [art] Against BCP 190

[Adam Roach <[e-mail]>]

I write the following in my role as the area director holding the 
BCP-190-related discuss that Larry mentions below.


On 7/23/19 00:17, [e-mail] wrote:
> I don't understand
> https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/ballot/
> 5 DISCUSS on a document targeted to be Experimental where most of the
> objections
> don't seem to meet the criteria for raising a DISCUSS on a standards-track
> document.
> https://www.ietf.org/blog/discuss-criteria-iesg-review/#stand-disc
> much less Experimental.
> I'm especially baffled by the use of BCP 190 (which documents some
> guidelines)
> as somehow "blocking" anything in IESG Review.


Thanks, Larry, for raising these questions. I think it's important that 
everyone understands the situation that has arisen, and you've done a 
good job of crystallizing a couple of topics that I'm sure several other 
people are also concerned about.

Although a bit of a diversion, I do want to address your point about 
discuss criteria before I get into the status of BCPs in general and BCP 
190 in particular (at least as I understand them; I welcome feedback if 
people believe I'm off-base in my assertions). While I hesitate to 
litigate the list of "discuss criteria" you cite -- in large part 
because it is self-disclaimed by language that it is merely exemplary 
and "cannot be an exhaustive list" -- this specific situation does have 
a bullet point in that list that reads, at least in spirit, on the topic 
at hand. To wit:


> The IETF as a whole does not have consensus on the technical approach 
> or document. There are cases where individual working groups or areas 
> have forged rough consensus around a technical approach which does not 
> garner IETF consensus. An AD may DISCUSS a document where she or he 
> believes this to be the case. While the Area Director should describe 
> the technical area where consensus is flawed, the focus of the DISCUSS 
> and its resolution should be on how to forge a cross-IETF consensus.
>

In this specific case, the IETF wrote down consensus around the general 
principles of stewardship for the URI namespace, and then a working 
group without charter to deal with that topic came to a decision 
contrary to that consensus.

I want to make sure that everyone involved in this conversation is clear 
on a relevant role that BCPs play. BCP documents have the same level of 
maturity and receive the same level of scrutiny as Standards Track 
documents. Their normative statements authoritatively govern the topic 
they deal with -- at least, within the confines of IETF process -- until 
updated or obsoleted. Normative statements in BCPs are not mere 
guidelines; they are the documented and carefully-considered will of the 
responsible community. This is the mechanism the IETF has to make 
durable and binding decisions. Without that ability, we would waste a 
significant quantity of time re-litigating topics about which we had 
already reached conclusions.

That said, "durable" is not the same as "permanent", and it has been 
five years since the publication of BCP 190. It is reasonable for the 
community to revisit earlier decisions in the presence of additional 
experience. I welcome the discussion of whether a revision is warranted 
at this time, and encourage interested parties to present their 
positions politely, factually, and unemotionally.

Importantly, I do not think that I am allowed to stand out of the way of 
what appears to be one working group deciding to set aside established 
IETF consensus without buy-in from the responsible stakeholders. I 
believe that I would be derelict in my obligations as an area director 
in charge of the relevant area if I were to do so. If BCP 190 needs 
revision, that decision needs to come out of the ART community as a 
whole, not out of a single SEC-area working group with a charter 
unrelated to URI design and ownership.

I want to be ultra clear: I am not blocking this document because I feel 
any specific way about the provisions of BCP 190. I am blocking this 
document because the IETF has made a decision, and we need to either 
abide by it or revise it.

/a