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
