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

Warren Kumari <> Sun, 04 November 2018 10:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7BAFA129C6A for <>; Sun, 4 Nov 2018 02:22:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DWMi_wewipU5 for <>; Sun, 4 Nov 2018 02:21:59 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::32d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 768DE12958B for <>; Sun, 4 Nov 2018 02:21:59 -0800 (PST)
Received: by with SMTP id s10-v6so5499111wmc.5 for <>; Sun, 04 Nov 2018 02:21:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=CyPBp90SqIy+lhTDWvu90rvGobPtnj6KRuUn5Ye1eDs=; b=bGQHQ70JVNYP5+dX2AcTtksfr9dz1F8JDBXK7pHvnvKpdHtcKZfFvvNUQfPQZDBStG ZL+IcywycZjoPEIBa3LeeBSZbMvoi7Pb79pEjoQDUSzXbW7h8SQzpMA0i9n7JV09nC2K 0nGzlpAvkPJSWQrRKH2yUU7uYkAAvHr9VrOYIy74NQWzRvrkh1+fBhv9Ehz+/2BVRsR2 b1Njoksbri+iDbDdfm/fNrZpUELbPcK8M9RoEocQOLcY/0mp/JUXC58sohg+5D1kJNMe wJBDI+c7rM0+4AHezmiafITr2Zc0eeXbg0GVspSrB3oVDTWqVQvgnK+n9sBZoIhavWc9 ac2w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=CyPBp90SqIy+lhTDWvu90rvGobPtnj6KRuUn5Ye1eDs=; b=Tj/lx6HYS8AzjjB+2NDaOLVFghdrn6LuyWwNUcpAOpqOSfOe8Zyee4jS3+bnjE67em Nh7qJ4z+PsqOatERNmmq3XGyf1EgU79e2g52ILgEQfeMvxQFzUkZnt8MgZJ5Wyhk9Y1t LyugRMJ4Do0l4BitSaUZdkNhBWZIeaE0WhO3YlbZorl4QEIPuXlmJW7Q/r6pbxVPbTUh jVux2/q3kEMAqj+x+4s+Hl/nXpkkzhOVxz1QRKpgneS45pvsW/Mw8tP8QB0v9lY/Q1pt VkwfCeWpqKvbSL/fQPMA5Uds/r/ypNnZT/NQIVpuduZ90ABA1r/kNWOGPihfFhJrmTsb disQ==
X-Gm-Message-State: AGRZ1gId8RUP3IIU7RwgMCBSQHSLZbbf9+ymVCSMH7IW+a59r52CwCER qztwtSXLh62SaTwqEgtIqhAH+ouiX5AmnI0Z/f9Xy4b68vUVaw==
X-Google-Smtp-Source: AJdET5cRWdsVqxIkq/Mhw0LkUeBZy2t2pOgbZcoEJU8yFsj5uk22gLuZsm6GEP6j6Cf0YsjlJlU/Q8c9Zy8YPqZvE3k=
X-Received: by 2002:a1c:bce:: with SMTP id 197-v6mr2798235wml.15.1541326917548; Sun, 04 Nov 2018 02:21:57 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <> <>
In-Reply-To: <>
From: Warren Kumari <>
Date: Sun, 4 Nov 2018 17:21:17 +0700
Message-ID: <>
To: Adam Roach <>, Alissa Cooper <>
Cc: dnsop <>
Content-Type: multipart/alternative; boundary="0000000000006750640579d42304"
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: Sun, 04 Nov 2018 10:22:02 -0000

So, the new version of draft-ietf-dnsop-attrleaf-fix is posted --
The diff from the previous is here:

I **think** that this addresses the outstanding issues (modulo some
formatting nits) -- Alissa / Adam, does this satisfy your concern?


On Mon, Oct 22, 2018 at 11:34 PM Adam Roach <>; wrote:

> 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 removed.
> 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.
> /a

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