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
