Re: [art] Against BCP 190

Adam Roach <adam@nostrum.com> Tue, 23 July 2019 06:33 UTC

Return-Path: <adam@nostrum.com>
X-Original-To: art@ietfa.amsl.com
Delivered-To: art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF771200D6 for <art@ietfa.amsl.com>; Mon, 22 Jul 2019 23:33:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.98
X-Spam-Level:
X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N6GCUdEeZ4gR for <art@ietfa.amsl.com>; Mon, 22 Jul 2019 23:32:58 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C06421200B2 for <art@ietf.org>; Mon, 22 Jul 2019 23:32:58 -0700 (PDT)
Received: from dhcp-9c35.meeting.ietf.org (dhcp-9c35.meeting.ietf.org [31.133.156.53]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x6N6WubU001230 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 23 Jul 2019 01:32:57 -0500 (CDT) (envelope-from adam@nostrum.com)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1563863578; bh=FCBxqgYy5nThFLa0U3zzyDuc0ny8gplpUJB3cjANf6g=; h=Subject:To:References:From:Date:In-Reply-To; b=cDdklCJRJH1M6RLYxaj4Sa99moyNeO3UCfrEd99Gp3y8L4cFaAG8GAuh0ToO3+uAm Enz14LicLV7V3ye8Q27c7uPBtiRm87CnrQmF1aZNPCMG8G20ok2JlIHiUOPAchnplG IsRA2agKfLZ9lDbyiQzVfUMiaxAuWv+1Rhaqjwxc=
To: Leif Johansson <leifj@mnt.se>, art@ietf.org
References: <791b33b8-4696-f69c-aca3-8838b2caafd8@sectigo.com> <6.2.5.6.2.20190713054207.0bbd9b58@elandnews.com> <008901d5410d$90607b00$b1217100$@gmail.com> <529b1f23-75e7-c426-f884-8dd07825182d@nostrum.com> <f834b9cd-0dff-7725-a959-6514c22d3ae4@mnt.se>
From: Adam Roach <adam@nostrum.com>
Message-ID: <eb6485fa-d3dd-8eb9-7886-b17ef9d10f81@nostrum.com>
Date: Tue, 23 Jul 2019 02:32:55 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <f834b9cd-0dff-7725-a959-6514c22d3ae4@mnt.se>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/art/fDcXucX7An1yX8ddPsfpPO9WjPc>
Subject: Re: [art] Against BCP 190
X-BeenThere: art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications and Real-Time Area Discussion <art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/art>, <mailto:art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/art/>
List-Post: <mailto:art@ietf.org>
List-Help: <mailto:art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/art>, <mailto:art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Jul 2019 06:33:00 -0000

On 7/23/19 01:44, Leif Johansson wrote:
> Thank you Adam,
>
> This was a great summary for somebody like me who sorta heard about
> the issue for the first time today.
>
> Your summary provokes a questions tho:
>
>> 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.
> Has there been any similar situations before involving BCP190 and how
> where those issues resolved?


There have been a number of similar situations involving BCP 190, at 
varying phases of document development. In my time on the IESG, I can 
recall roughly two cases in which draft authors contacted the ART area 
directors to ask advice while a specification was under development in a 
working group, and there have been probably as many that reached IESG 
evaluation before the issue was identified as blocking.

In the cases where the issue was discussed while still the document was 
under development, the documents were easily adapted to conform to the 
normative requirements of BCP 190. One of these discussions did form 
part of the impetus that eventually led to the revision of RFC 5785 
(which defined .well-known) by RFC 8615, as that discussion did turn up 
a desire in the community to relax some of the constraints that 
originally existed in RFC 5785 (including the one mentioned during 
today's ARTAREA meeting).

In the cases where the issue was only discovered in IESG review, the 
documents have gone back to their respective working groups for further 
discussion. Prior to the current conversation involving the TRANS 
document, the working groups whose documents were found to have BCP 190 
issues made the minimal protocol changes necessary to meet its requirements.

It's notable that discovering these issues earlier in the process 
universally had better outcomes than discovering them during IESG 
review. To that end, the IESG has begun the effort of compiling a list 
of technologies that are likely to require expert input if used outside 
the working groups in which core expertise resides. The final steps of 
this task are on my plate, and I hope to get to them shortly after I 
recover from the current face-to-face meeting. The hope is that we will 
be able to keep the chairs of various working groups apprised of this 
list of technologies, so that such expert input can be sought earlier in 
the process, when it is less likely to cause unwelcome surprises for 
working group participants.

/a