Thanks, glad there wasn’t a thread that I missed. Given Warren’s quick progress 
on this I suspect there is not any value for me to respond further to your 
points below. 

Alissa

> On Oct 19, 2018, at 11:52 AM, Dave Crocker <d...@dcrocker.net> wrote:
> 
> 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

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to