IETF Logo Mail Archive

Re: [Add] Proposed charter and BoF request for IETF 106

Jim Reid <jim@rfc1035.com> Wed, 09 October 2019 13:52 UTC

Return-Path: <jim@rfc1035.com>
X-Original-To: add@ietfa.amsl.com
Delivered-To: add@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAAD312011F for <add@ietfa.amsl.com>; Wed, 9 Oct 2019 06:52:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
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 IXltH_rvMY65 for <add@ietfa.amsl.com>; Wed, 9 Oct 2019 06:52:23 -0700 (PDT)
Received: from shaun.rfc1035.com (shaun.rfc1035.com [93.186.33.42]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A50C112010C for <add@ietf.org>; Wed, 9 Oct 2019 06:52:23 -0700 (PDT)
Received: from gromit.rfc1035.com (gromit.rfc1035.com [195.54.233.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id 5F2CE242153C; Wed, 9 Oct 2019 13:52:21 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Jim Reid <jim@rfc1035.com>
In-Reply-To: <LO2P123MB2256A416C25822B08BCCF9409B950@LO2P123MB2256.GBRP123.PROD.OUTLOOK.COM>
Date: Wed, 09 Oct 2019 14:52:20 +0100
Cc: add@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <2D228282-0F33-43D5-8326-0271372230AF@rfc1035.com>
References: <CALaySJLxXVuHQNfTnaeKZ_R9xtBYWfbta+A1bWcE-ZQZwd3VZg@mail.gmail.com> <CABcZeBMkAFZW9mWjw92v+OR0Fa8ed+P80yc78eY07hCpsCNY6Q@mail.gmail.com> <LO2P123MB2256A416C25822B08BCCF9409B950@LO2P123MB2256.GBRP123.PROD.OUTLOOK.COM>
To: chris.box@bt.com
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/J3EcySbDThOas0QZrXGu-GTs_ws>
Subject: Re: [Add] Proposed charter and BoF request for IETF 106
X-BeenThere: add@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications Doing DNS <add.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/add>, <mailto:add-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/add/>
List-Post: <mailto:add@ietf.org>
List-Help: <mailto:add-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/add>, <mailto:add-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Oct 2019 13:52:26 -0000


> On 9 Oct 2019, at 14:36, <chris.box@bt.com> <chris.box@bt.com> wrote:
> 
>> This seems like it leaves all of the contested issues firmly
>> in scope. I can't imagine how we're going to get consensus on
>> best current practices, when we can't even agree on the terms
>> for resolver selection.
> 
> Yes it's hard, and some compromise will be required, but it's worth attempting this in ABCD.

Indeed. And when consensus isn’t achievable, I think it would be helpful to document the reasons why that’s the case. Even if those hypothetical Informational RFCs were little more than a statement of the bleedin’ obvious. For instance “The IETF has no BCP on query data retention because that topic is an intractable tar pit of conflicting/contradictory national regulations, legislation and local policy. Here’s why: ... The WG decided not to go on a quest for an unachievable compromise. Have a nice day.”.

IMO it will sometimes be helpful to document the things the WG doesn’t agree on and why as it is to document the topics where there is a (rough) consensus.

v2.23.0 | Report a Bug | By Email