Re: [DNSOP] [art] Another look - draft-ietf-dnsop-attrleaf-05.txt

Martin Hoffmann <martin@opennetlabs.com> Mon, 26 March 2018 15:56 UTC

Return-Path: <martin@opennetlabs.com>
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 584661252BA; Mon, 26 Mar 2018 08:56:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham autolearn_force=no
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 ZV5j-kbx9HhU; Mon, 26 Mar 2018 08:56:12 -0700 (PDT)
Received: from dicht.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2a04:b900::1:0:0:10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94220124B17; Mon, 26 Mar 2018 08:56:12 -0700 (PDT)
Received: by dicht.nlnetlabs.nl (Postfix, from userid 58) id A7EBA8477; Mon, 26 Mar 2018 17:56:10 +0200 (CEST)
Received: from smaug.local.partim.de (unknown [84.245.51.209]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id 0894F8471; Mon, 26 Mar 2018 17:56:10 +0200 (CEST)
Authentication-Results: dicht.nlnetlabs.nl; dmarc=none header.from=opennetlabs.com
Date: Mon, 26 Mar 2018 17:56:09 +0200
From: Martin Hoffmann <martin@opennetlabs.com>
To: Dave Crocker <dhc@dcrocker.net>
Cc: dcrocker@bbiw.net, art@ietf.org, dnsop@ietf.org
Message-ID: <20180326175609.497ffb10@smaug.local.partim.de>
In-Reply-To: <667675d4-0ff8-b236-eded-31f795b84af1@dcrocker.net>
References: <f7b85bac-b050-5003-2df0-a48b1ef2f929@dcrocker.net> <e1f41670-ada8-eaac-468c-c712b338a10b@dcrocker.net> <alpine.OSX.2.21.1803201804440.8940@dhcp-8344.meeting.ietf.org> <A7711F58-5145-49E8-9158-B2F94D0EABBF@redbarn.org> <7c168dc1-2ea7-d47e-78b7-0380e5d0aa84@dcrocker.net> <alpine.OSX.2.21.1803211104210.9553@ary.local> <5244d327-f8ea-1590-c663-1d92e0b194c4@dcrocker.net> <5F44FA5B42805C52479DE491@PSB> <alpine.OSX.2.21.1803211507380.9666@dhcp-935d.meeting.ietf.org> <1DF1564CC2B88726B2B54CF4@PSB> <20180326171842.0eacbdc4@smaug.local.partim.de> <667675d4-0ff8-b236-eded-31f795b84af1@dcrocker.net>
Organization: Open Netlabs
X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; x86_64-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/56-BQiVqTdaGDHZKAYxJjoUohWA>
Subject: Re: [DNSOP] [art] Another look - draft-ietf-dnsop-attrleaf-05.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 26 Mar 2018 15:56:14 -0000

Dave Crocker wrote:
>
> On 3/26/2018 8:18 AM, Martin Hoffmann wrote:
> > Which also reminds me: The DANE RRtypes, ie., TLSA, SMIMEA, and
> > OPENPGPKEY all use underscore labels and are currently missing
> > from the initial table in section 3.1.  
> 
> 
> The table there is for the right-most underscore name, which RFC 6698 
> seems to constrain to choices that are already list.

TLSA needs to be added to the RR column for _tcp, _udp, and _sctp.

RFC 7929 defines _openpgpkey for use with the OPENPGPKEY record type.

RFC 8162 defines _smimecert for use with the SMIME record type.

 
> The left-most underscore name appears to use a rule that differs from 
> the rule used by SRV, etc.  As such, these are second-level names
> being drawn from the same namespace but without coordination.  So it
> looks like there's a problem, but not with the proposed global
> registry (for now.)
> 
> Yes?

Agreed. Currently however, the text in section 2 does sound as if this
sort of collision doesn't happen:

| that is, a subordinate name is meaningful only within the scope of
| the first (top-level) underscore name.

It should probably call out either here or elsewhere that there may
be different hierarchies for different record types.

Kind regards,
Martin