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

From: Warren Kumari <[email-masked]>
Date: Thu, 18 Oct 2018 21:04:22 +0200

Hi there,

Dave suggested I send this out.

draft-ietf-dnsop-attrleaf and draft-ietf-dnsop-attrleaf-fix have completed
IESG review.
Alissa is holding a DISCUSS position on draft-ietf-dnsop-attrleaf-fix -
this can be seen here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf-fix/ballot/

Alissa (and a number of other ADs) feel that each of the (37!) updated
documents should be classified into 2.1. (TXT RRset), 2.2. (SRV RRset)
or 2.3. (URI RRset).

Basically, we need to go through each document in
draft-ietf-dnsop-attrleaf-fix,
figure out which class it falls into (TXT, SRV, URI), and add it to a list.
We then add a sentence to each of those sections saying "Documents in this
category include RFCxxxx, RFCyyyy, RFCzzzz".

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.

So, if you would be willing to take a few documents to classify, please go
to this spreadsheet:
https://docs.google.com/spreadsheets/d/1oTs8ZJy6EZdSt4NXZJbcIRd771V9Rbg9TqddE5KlLGE/edit?usp=sharing
[0]

Change the reviewer from Benno or Warren to your name **before** starting
the review (we really don't need multiple reviews of the same document!),
and then update the spreadsheet with what "class" of update it is. Please
have the review done by Wednesday Oct 24th.

Review help would be appreciated, but if you are not able to (I know people
are really busy before IETF week), Benno and I will manage...

W
[0]: Posting a public link to a spreadsheet.... what could *possibly* go
wrong!?

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf

---

From: Dave Crocker <[email-masked]>
Date: Thu, 18 Oct 2018 12:26:20 -0700

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

---

From: Warren Kumari <[email-masked]>
Date: Fri, 19 Oct 2018 09:34:35 +0200

On Thu, Oct 18, 2018 at 9:04 PM Warren Kumari <[email-masked]> wrote:

> Basically, we need to go through each document in draft-ietf-dnsop-attrleaf-fix,
> 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.
>
> Review help would be appreciated, but if you are not able to (I know
> people are really busy before IETF week), Benno and I will manage...
>

... and my plane was delayed by an hour, so I decided to take a start on
this - I’ve done ~20 so far, so please remember to check the spreadsheet
before starting any...

W

> I don't think the execution is relevant when it was obviously a bad idea
> in the first place.

---

From: Warren Kumari <[email-masked]>
Date: Fri, 19 Oct 2018 11:49:33 +0200

On Fri, Oct 19, 2018 at 9:34 AM Warren Kumari <[email-masked]> wrote:

>> draft-ietf-dnsop-attrleaf and draft-ietf-dnsop-attrleaf-fix have
>> completed IESG review.
>> the authors to deal with IESG DISCUSS (and other ballots) - but we wanted
>> to move this document along.
>>
>> So, if you would be willing to take a few documents to classify, please
>> go to this spreadsheet:

... and I got basically all of the rest done on the flight.

I have a few which I really cannot figure out what category they are, and
so I’ll ask for your help figuring them out...

W

---

From: Alissa Cooper <[email-masked]>
Date: Fri, 19 Oct 2018 12:05:28 +0200

Hi Dave,

> On Oct 18, 2018, at 9:26 PM, Dave Crocker <[email-masked]> 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 req
> 
> 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.

I am getting on a long plane flight so can take a look at Warren’s progress thus far if I find WiFi — looks like this is close to done (thanks, Warren!).

Alissa

> 
> 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
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Warren Kumari <[email-masked]>
Date: Fri, 19 Oct 2018 14:08:31 +0200

So, there were a few documents where I was not able to quickly figure out
which of the classes it should be placed in.

RFC3861 describes how to use SRV, but it is updated by RFC6121, which
largely says "Don't!" -- what do we do here? Update both? Just RFC3861?
Juast RFC6121?
I couldn't figure out RFC3404, and RFC6011.
Clue appreciated.

RFC3404 -- Dynamic Delegation Discovery System (DDDS) Part Four: The
Uniform Resource Identifiers (URI) Resolution Application
Perhaps SRV? But it doesn't really seem to be underscore scoped...

RFC6121 -- Extensible Messaging and Presence Protocol (XMPP): Instant
Messaging and Presence
This updates RFC3921 and explicitly recommends against SRV.
"Interoperability Note: RFC 3921 specified how to use the _im._xmpp and
_pres._xmpp SRV records [IMP-SRV] as a fallback method for discovering
whether a remote instant messaging and presence service communicates via
XMPP. Because those SRV records have not been widely deployed, this
document no longer specifies their use, and new implementations are not
encouraged."
Should this be in this list?

RFC3861 -- Extensible Messaging and Presence Protocol (XMPP): Instant
Messaging and Presence
See above. It would be SRV, but was updated by RFC6121.

RFC6011 -- Session Initiation Protocol (SIP) User Agent Configuration
I got confused here -- I cannot really see the underscore names here as
anything other than a target name.

W

On Fri, Oct 19, 2018 at 11:49 AM Warren Kumari <[email-masked]> wrote:

>>> Change the reviewer from Benno or Warren to your name **before**
>>> starting the review (we really don't need multiple reviews of the same
>>> document!), and then update the spreadsheet with what "class" of update it
>>> is. Please have the review done by Wednesday Oct 24th.
>>>

---

From: "John Levine" <[email-masked]>
Date: 19 Oct 2018 16:19:26 +0200

>which of the classes it should be placed in.

Honestly, some of these don't look updated to me.  The clues are in the
table in attrleaf-14

>Should this be in this list?

RFC 3861 implies the _xmpp protocol tag for SRV, 3921 defines it, 6121
says not to use it but it already exists so it's in the registry.  I
don't see anything updated or to update.

>Perhaps SRV? But it doesn't really seem to be underscore scoped...

I believe that all SRV records are supposed to have _names and the examples
in 3404 without them are wrong.  An erratum might be appropriate but I don't
see anything to update.

>anything other than a target name.

Me neither.  I wonder if some of these are left over cruft from earlier
revisions that included service names.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Fri, 19 Oct 2018 08:00:49 -0700

> revisions that included service names.

I also believe they are leftovers, due to my not having done the final 
audit I mentioned after Adam noted them, when I posted the current 
drafts quickly, so the IESG could have them.  (I still have to do that 
audit.)

d/

---

From: Dave Crocker <[email-masked]>
Date: Fri, 19 Oct 2018 08:52:08 -0700

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/

---

From: Alissa Cooper <[email-masked]>
Date: Mon, 22 Oct 2018 06:19:46 -0400

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 <[email-masked]> wrote:
> 
> 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:
> 
>> My question is not about the difference in cleanliness but about serious, practical risk.
> 
> 
> 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.
> 
> 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.
> 
> 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

---

From: Warren Kumari <[email-masked]>
Date: Mon, 22 Oct 2018 15:59:53 +0200

I believe that adding, at the end of Section 2.1.  TXT RRset Use

"Documents which fall into this category include:
RFC6763, RFC6120, RFC5518, RFC5617, RFC6376, RFC7208, and RFC7489"

and Section 2.2. (SRV RRset Use)

"Documents which fall into this category include:
RFC3263, RFC3529, RFC3620, RFC3832, RFC3887, RFC3958, RFC4120, RFC4227,
RFC4386, RFC4387, RFC4976, RFC5026, RFC5328, RFC5389, RFC5415, RFC5555,
RFC5679, RFC5766, RFC5780, RFC5804, RFC5864, RFC5928, RFC6186, RFC6733,
RFC6763, RFC6120. "

will cover this.

It seems that:
RFC3861, RFC3404, RFC6121 and RFC6011 should all be removed from the list.

I was not able to find any URI documents in the list - can anyone educate
me?

W

---

From: Adam Roach <[email-masked]>
Date: Mon, 22 Oct 2018 11:33:59 -0500

On 10/19/18 7:08 AM, Warren Kumari wrote:
> So, there were a few documents where I was not able to quickly figure 
> out which of the classes it should be placed in.
>

tl;dr: my analysis is that all four of the mentioned documents should be 
removed from the list. Details below.

> largely says "Don't!" -- what do we do here? Update both? Just 
> RFC3861? Juast RFC6121?

That's sort of true. 3861 defines rules for _im._x and _pres._x (for 
arbitrary values of "x"), while 6121 says "don't do this for x = xmpp."  
For example, RFC 5509 builds on RFC 3861 for SIP, and it's technically 
still in effect (although the practical case is probably the same as 
XMPP, no one has produced a revision to 5509 that says as much).

All of that notwithstanding, 3861 most definitely does not deal with 
"Global" underscored node names as -attrleaf- defines that term. It 
deals only with labels further down the tree. I believe it should be 
removed from the list.

> Perhaps SRV? But it doesn't really seem to be underscore scoped...

This one is quite perplexing, and I don't know how it got caught up in 
Dave's net. The character "_" appears only 12 times in this document, 
all in variable names in the pseudo-code in its appendix. Neither of the 
English words "underscore" nor "underline" appear at all.

As far as I recall (and a quick skim seems to validate this), the only 
reservations DDDS makes are under "urn.arpa." and "uri.arpa." -- there 
aren't any global name reservations, with or without underscores.

I think this document was included in error.

> "Interoperability Note: RFC 3921 specified how to use the _im._xmpp 
> and _pres._xmpp SRV records [IMP-SRV] as a fallback method for 
> discovering whether a remote instant messaging and presence service 
> communicates via XMPP. Because those SRV records have not been widely 
> deployed, this document no longer specifies their use, and new 
> implementations are not encouraged."

RFC 6121, as you point out, only mentions _{im,pres}.xmpp as an 
historical note while deprecating its use. I believe it should also be 
removed.

> See above. It would be SRV, but was updated by RFC6121.

[see above]

> I got confused here -- I cannot really see the underscore names here 
> as anything other than a target name.

6011 shouldn't be updated by this document. The only underscored node 
names in that document are in non-normative examples, and they're 
actually incidental to the purpose of the example. Presumably, they're 
included to demonstrate that querying for NAPTR records can return both 
UA Config records *and* other, unrelated records, and that 
implementations need to ignore the unrelated records.

Thanks for doing the heavy lifting on this. I think it has dramatically 
improved the document to figure out why each updated RFC is included, 
since it flushed out several that should not be.

/a