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

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

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

> On 8/20/19 5:55 AM, John C Klensin wrote:
>> * 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.
> 
> 
> 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