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

Warren Kumari <warren@kumari.net> Sun, 04 November 2018 10:22 UTC

Return-Path: <warren@kumari.net>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BAFA129C6A for <dnsop@ietfa.amsl.com>; Sun, 4 Nov 2018 02:22:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DWMi_wewipU5 for <dnsop@ietfa.amsl.com>; Sun, 4 Nov 2018 02:21:59 -0800 (PST)
Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 768DE12958B for <dnsop@ietf.org>; Sun, 4 Nov 2018 02:21:59 -0800 (PST)
Received: by mail-wm1-x32d.google.com with SMTP id s10-v6so5499111wmc.5 for <dnsop@ietf.org>; Sun, 04 Nov 2018 02:21:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; 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; d=1e100.net; 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: <CAHw9_i+Hi_y2W+5sSLuZvtM0nLHVR=y5R--3D-UB2_W3TYJ8JA@mail.gmail.com> <CAHw9_i+OrDZPD7go_KHC0MWWv6Bn6=X7C2_Ps6SvxU8+BrdynQ@mail.gmail.com> <CAHw9_iJdTv4XmjhhSptZ0q9AjztqS+HzTww4OFX+tUB2ybqb6w@mail.gmail.com> <CAHw9_iKRxsR9ufbUDHhk7J7URsXV3Kenz90LtQ+Why1MYba4fA@mail.gmail.com> <d18fe49e-52ed-c46f-1dc3-f1f84c8633b8@nostrum.com>
In-Reply-To: <d18fe49e-52ed-c46f-1dc3-f1f84c8633b8@nostrum.com>
From: Warren Kumari <warren@kumari.net>
Date: Sun, 4 Nov 2018 17:21:17 +0700
Message-ID: <CAHw9_iJRVypLWHkR1aGkJX98b5MSDE2L49j+ARwtE9X4hjh-=A@mail.gmail.com>
To: Adam Roach <adam@nostrum.com>, Alissa Cooper <alissa@cooperw.in>
Cc: dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000006750640579d42304"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/3XDOtjgK695avTxNs0jIYgZKbVI>
Subject: Re: [DNSOP] A quick update on draft-ietf-dnsop-attrleaf / draft-ietf-dnsop-attrleaf-fix
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=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 --
https://datatracker.ietf.org/doc/draft-ietf-dnsop-attrleaf-fix/
The diff from the previous is here:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-attrleaf-fix-06

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

W

On Mon, Oct 22, 2018 at 11:34 PM Adam Roach <adam@nostrum.com>; 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 "urn.arpa." and "uri.arpa." -- 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
pants.
   ---maf