Re: [DNSOP] A quick update on draft-ietf-dnsop-attrleaf / draft-ietf-dnsop-attrleaf-fix

Dave Crocker <dhc@dcrocker.net> Thu, 18 October 2018 19:26 UTC

Return-Path: <dhc@dcrocker.net>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38318124C04 for <dnsop@ietfa.amsl.com>; Thu, 18 Oct 2018 12:26:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dcrocker.net
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 vu_D6j9kOtA4 for <dnsop@ietfa.amsl.com>; Thu, 18 Oct 2018 12:26:28 -0700 (PDT)
Received: from simon.songbird.com (simon.songbird.com [72.52.113.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DEF21286D9 for <dnsop@ietf.org>; Thu, 18 Oct 2018 12:26:28 -0700 (PDT)
Received: from [192.168.1.168] (76-218-8-128.lightspeed.sntcca.sbcglobal.net [76.218.8.128]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id w9IJQuUW016827 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 18 Oct 2018 12:26:56 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1539890816; bh=N1VisQ6LCU1Uanf2PZuIKlq9ux7hjwhGIJ3eNDh9ok8=; h=Subject:To:References:From:Cc:Reply-To:Date:In-Reply-To:From; b=RTQi5vPQ+Egrkdzvp9Jsk3rSuITc7IpC1i2kd6kLiE+aPwEiMNMjra+UCz3x70cCC hwIVz9s62pY5kffpEyDWviK07UoaGfQs2cCUQA3OIBfQ1ZslR7DgpitFUTjOQ3RN7S TYOolS2asZCTucdhmVycxaxhlmFxOsLMXCuJ7Dno=
To: dnsop <dnsop@ietf.org>
References: <CAHw9_i+Hi_y2W+5sSLuZvtM0nLHVR=y5R--3D-UB2_W3TYJ8JA@mail.gmail.com>
From: Dave Crocker <dhc@dcrocker.net>
Reply-To: dcrocker@bbiw.net
Organization: Brandenburg InternetWorking
Message-ID: <27c9d56e-abd6-1ab1-029d-514036151517@dcrocker.net>
Date: Thu, 18 Oct 2018 12:26:20 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <CAHw9_i+Hi_y2W+5sSLuZvtM0nLHVR=y5R--3D-UB2_W3TYJ8JA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/dy2vwkpraZsIAxvF65sJSh7HM98>
Subject: Re: [DNSOP] A quick update on draft-ietf-dnsop-attrleaf / draft-ietf-dnsop-attrleaf-fix
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Oct 2018 19:26:30 -0000

On 10/18/2018 12:04 PM, Warren Kumari wrote:
> Dave has stated that he is unwilling to do this work. Instead of having 
> the WG document simply stall, Benno and I have agreed that we would 
> split them between us. If anyone would like to volunteer to help out, we 
> would not take it amiss.
> 
> Please note that this is not a normal situation - in general we expect 
> the authors to deal with IESG DISCUSS (and other ballots) - but we 
> wanted to move this document along.


(Oh boy. Had Warren merely said something neutral like 'Dave won't be 
able to do that' I wouldn't feel the need to post this.  But given his 
wording...)


Alissa's Discuss is based on an extrapolation of the Update semantic, 
beyond anything that is documented because, I'm told, the IESG hasn't 
been able to reach consensus on relevant details.

Worse, her concern is that someone editing one of the cited specs will 
not know which part of the -fix document applies to them.  Given the 
detail that /is/ provided in -fix, IMO the odds of that problem are 
lower than 'unlikely'.

There are 35+ documents cited, so the task that is being imposed is 
non-trivial.

My understanding is that it is not uncommon to have an Updates citation 
to something like the base Attrleaf document, with no additional detail 
guiding the update to a cited document.  From that perspective, the -fix 
document is already considerably more detailed than often/sometimes 
required.

I'll also note that I gave this feedback to Alissa directly, earlier and 
she did not respond to it.  That failure to engage is just one more 
problem with this Discuss.  (And it hearkens back to years ago when ADs 
would do this sort of thing regularly.  Not me, of course, but some...)

And just to be clear, obviously I'll add whatever text the wg agrees on. 
  My limitation is spending the significant on a task that appears to be 
entirely unnecessary.


d/


-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net