Re: [art] BCP190

The decision we've arrived at is to address the open DISCUSS so we can move
forward with RFC 6962-bis, not to disregard IETF consensus. This was the
driving force behind getting time yesterday during ART with in-person and
remote participation by many of the contributing stakeholders from TRANS.
Ensuring wide and open representation in these discussions is also why I'm
hesitant to rely on an ad-hoc side meeting at IETF 105 that precludes
remote participation, as this will likely lead to incomplete representation
and/or a complete rehashing on-list.

The TRANS discussion as well as the points summarized in the 105 ART slides
[1] present a summary of the alternatives considered and why many in TRANS
feel they are not appropriate in the context of CT. If there is a specific
concern with the 6962-bis draft 31 approach [2] beyond the stated
non-conformity with BCP 190, I would really like to hear it so we can make
a better-informed decision and better weigh the alternatives.

If there are not concrete concerns to that effect, I'd like to better
understand the route forward. It seems like we can either:
1) Acknowledge BCP 190 non-conformity within RFC 6962-bis with a brief
description and rationale
2) Begin the process to edit BCP 190 such that RFC 6962-bis is no longer
out of compliance using pre-draft-32 language

Due in part to the aforementioned delays incurred throughout RFC 6962-bis's
process, including dropping it down to Experimental track, several members
of TRANS appear to not be keen on holding this up for an attempt to address
general concerns with BCP 190 prescriptiveness. This sentiment was echoed
by some in the mic-line at yesterday's ART session, but it was too brief to
fully address comments from attendees and might not have allowed for folks
to raise compelling counter-arguments. Not being an expert here, I'd like
input on which is the best approach to pursue.

-Devon

[1]
https://datatracker.ietf.org/doc/slides-105-dispatch-rfc-6962-bis-and-bcp-190/
[2] https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/31/

On Tue, Jul 23, 2019 at 8:40 AM Adam Roach <adam@nostrum.com> wrote:

> On 7/23/19 11:21, Stephen Farrell wrote:
> > On the general topic, I don't think it's realistic nor wise
> > to try always strictly enforce BCPs. BCP107 is a fine case
> > in point - attempts by the SEC ADs over the years (including
> > this former instance of the animal;-) haven't IMO made the
> > Internet better in most cases - some yes, but mostly not, and
> > while the general guidance is correct, being too strict with
> > it is not, in the end, a good plan.
>
>
> I think you're correct here. I also think that it's important that we
> agree where these BCPs get things wrong, and adjust them to reflect the
> conclusions the community has reached. If BCP 107 needs occasional
> overrides, a minor revision of that document to explain that point would
> seem in order, so as to save heartburn for all parties further down the
> road.
>
> I'll repeat what I've said to the TRANS chairs on this topic: if we can
> get an agreement in principle on the ART mailing list that BCP 190 is
> too strict and needs to be updated to allow the kinds of exceptions
> envisioned by TRANS, then I'm willing to clear as soon as consensus in
> support of that proposition becomes evident, even in advance of a draft
> that proposes the concrete updates to the BCP. Absent that, the decision
> on the TRANS mailing list looks too much like one working group
> discarding established IETF consensus without input from the appropriate
> stakeholders.
>
> /a
>
> _______________________________________________
> art mailing list
> art@ietf.org
> https://www.ietf.org/mailman/listinfo/art
>