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

[Dave Crocker <[e-mail]>]

On 10/19/2018 3:05 AM, Alissa Cooper wrote:
>> 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...)

> Could you point out which message I did not respond to? After your
> last message in the thread about my DISCUSS we had the telechat and
> from my discussion there with Warren it seemed we had agreed on a way
> forward, which seemed more appropriate for him to communicate back
> than for me to.


Alissa,

Thanks for asking.

My wording was too facile, because I was frankly trying to avoid getting 
into the detail.

More accurate wording would have that you responded once, superficially 
and inaccurately, and then failed to respond.


The exchange was:

   1) On 10/10/2018 7:52 AM, Alissa Cooper wrote:
> DISCUSS:
> I think this document needs to state explicitly which updates apply to which
> existing RFCs. That is, I would expect to see in sections 2.1,  2.2, and 2.3
> the list of which documents are updated by each section. I realize this can be
> intuited, but typically for avoidance of doubt authors specify precisely which
> updates apply to which documents. This will also clear up the unused references
> that idnits is pointing out

   2) On 10/10/2018 11:32 AM, Dave Crocker wrote:
> What is the downside of using the existing text, as compared against
> the effort (and delay -- quite possibly infinite) caused by
> requiring development of the considerable detail that you are calling
> for?
> 
> My question is not about the difference in cleanliness but about 
> serious, practical risk.


   3) On 10/10/2018 11:48 AM, Alissa Cooper wrote:
> I think the downsides are (1) people reading the documents updated by
> this document are confused about which parts of the update apply,
> and (2) it sets a precedent that one RFC can update another without 
 > being specific about what is being updated.
> 
> I’m not asking for considerable detail, I’m asking for each of 2.1,
 > 2.2, and 2.3 to specify which documents out of the list in the Updates
 > header they update.


   4) On 10/10/2018 12:16 PM, Dave Crocker wrote:
 > So by my count, that requires going over roughly 35 documents (again)
 > to audit and document this additional detail.
 >
 > My guess is that the burden on someone updating one of those
 > documents, seeing the reference to -fix, and being able to properly
 > determine whether their document revision needs to attend to the
 > section on TXT RRset usage and/or SRV RRset usage and/or URI RRset
 > usage is minimal, and the risk of their getting it wrong is zero.

and THEN you stopped responding.


Above, I say 'superficially' because the two reasons you gave are 
intuitively appealing but lack the effort needed to balance against 
cost. That is, they are easy, pro forma tags, appealing in the abstract. 
  Casually deciding to add a task that is likely to take hours -- for 
someone you aren't paying to do the work -- is problematic, absent 
serious benefit.  This task doesn't come close.

I say 'inaccurately' on several counts.

First, consider the format and content of the -fix subsections of 
concern here.  Any editor who is revising one of the cited documents and 
can't figure out which of the 3 sub-sections applies to their document 
has bigger problems.  (Alternatively if folk really believe this is a 
decision moment that has any serious likelihood of the editor's making 
an error, we need to word those subsections better.)

Second, the assertion of 'precedent' presumes a policy that doesn't 
exist, as I had noted.  Worse, I fear you haven't reviewed all prior 
RFCs that did updating, to establish that it is at least a de facto policy.

But while ad hoc assertion of a non-existent policy is serious in the 
abstract, it is a minor point compared to the reality of this particular 
draft:  I am pretty sure we have never had an RFC that updated 35+ other 
documents.  Even better is that you are not calling for these 
subsections to match the precise and complete string-editing style 
typical for updating RFCs, since that would require 35+ subsectons and 
dramatically more work.

In other words, pragmatics require that this draft already be distinct, 
so citing 'precedent' fails on the facts.

That is why your not responding further was problematic.

The latter part of your latest note (quoted at the beginning of this 
message) points to a larger issue that I'm sure no one wants to pursue, 
namely the idea that an IESG discussion away from the working group and 
the author can make absolute decisions with no further discussion or 
recourse.  No matter how excellent the AD, they aren't a principal actor 
for the work being discussed.

Late-stage review and suggestions often produce significant benefit, but 
they also often lack context and encourage a failure to balance cost 
against benefits.  And in particular when the call for change comes from 
the IESG stage, there are two problematic forces: overworked folk 
lacking the time and inclination to engage in serous discussion and 
eager folk just wanting to finally get the darn thing published.  That 
encourages appeasement rather than careful consideration.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net