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

Adam Roach <> Mon, 22 October 2018 16:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7F50E130EDF for <>; Mon, 22 Oct 2018 09:34:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.879
X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jh5UacvyuqTl for <>; Mon, 22 Oct 2018 09:34:09 -0700 (PDT)
Received: from ( [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F41EA130E62 for <>; Mon, 22 Oct 2018 09:34:08 -0700 (PDT)
Received: from Svantevit.local ( []) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id w9MGY44C057585 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 22 Oct 2018 11:34:05 -0500 (CDT) (envelope-from
X-Authentication-Warning: Host [] claimed to be Svantevit.local
To: Warren Kumari <>, dnsop <>
References: <> <> <> <>
From: Adam Roach <>
Message-ID: <>
Date: Mon, 22 Oct 2018 11:33:59 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------00507EDE736924ED6771273C"
Content-Language: en-US
Archived-At: <>
Subject: Re: [DNSOP] A quick update on draft-ietf-dnsop-attrleaf / draft-ietf-dnsop-attrleaf-fix
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 22 Oct 2018 16:34:20 -0000

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.

> 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?

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.

> 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...

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 "" and "" -- there 
aren't any global name reservations, with or without underscores.

I think this document was included in error.

> 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?

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 

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

[see above]

> 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.

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.