Re: [DNSOP] [apps-discuss] Registry of non-service _prefix names and draft-crocker-dns-attrleaf-07

Dave Crocker <dhc@dcrocker.net> Sat, 14 November 2015 23:26 UTC

Return-Path: <dhc@dcrocker.net>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B88F1A8F44; Sat, 14 Nov 2015 15:26:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
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 eCC5rhABXZDD; Sat, 14 Nov 2015 15:26:07 -0800 (PST)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BFF801A8AAF; Sat, 14 Nov 2015 15:26:07 -0800 (PST)
Received: from [192.168.1.87] (76-218-10-206.lightspeed.sntcca.sbcglobal.net [76.218.10.206]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id tAENQ65I016446 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Sat, 14 Nov 2015 15:26:06 -0800
References: <20151114202844.9601.qmail@ary.lan>
To: John Levine <johnl@taugh.com>
From: Dave Crocker <dhc@dcrocker.net>
X-Enigmail-Draft-Status: N1110
Organization: Brandenburg InternetWorking
Message-ID: <5647C30C.10302@dcrocker.net>
Date: Sat, 14 Nov 2015 15:26:04 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <20151114202844.9601.qmail@ary.lan>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.17]); Sat, 14 Nov 2015 15:26:06 -0800 (PST)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/FjnTeKVj4dg2da_LjhqBBtbBohQ>
Cc: dnsop@ietf.org, dcrocker@bbiw.net, apps-discuss@ietf.org
Subject: Re: [DNSOP] [apps-discuss] Registry of non-service _prefix names and draft-crocker-dns-attrleaf-07
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dcrocker@bbiw.net
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: Sat, 14 Nov 2015 23:26:09 -0000

On 11/14/2015 12:28 PM, John Levine wrote:
> RFC 6335 came out five years after the
> first version of your draft and would have been a fine opportunity to
> de-mess.

Given what it was trying to do, I don't think they could reasonably have
tackled this topic.  However I suppose it's nice that they sought to
enfoce a "no underscores" rule for their table, since it facilitates the
re-use of the names under SRV.

The more serious problem, IMO, is that the SRV spec has such a fuzzy
spec for the alternative names that might be used besides _udp and _tcp.

I tried to accommodate this actively in the earliest versions of the
draft -- even to the point of having the registry be hierarchical -- but
seem to have fallen back to something as fuzzy as the SRV spec itself.
I finally decided flat organization suffices but didn't care the
requirement for explicit registration forward. Yuck.

At this point, after looking at the relevant SRV spec text again, I
believe the only respectable solution is to change that part of the SRV
spec and dictate that the service names must be registered in this IANA
table.  I do not see a "inherited from the IANA service names table"
model as being viable, since it almost encourages name collisions.



> Assuming the places in the draft where you refer to the left-most name
> you mean the right-most name for what gets registered, it needs to
> make clear what names enable what sub-names.

oh my.  ummm.  yes.  i only wish i could attribute this to alcohol or
dyslexia.


> For example, if a name is _tcp or _udp, all of the names in the RFC
> 6335 service name registry are eligible.  This includes _soap-beep and
> _xmlrpc-beep which are in that registry, and _certificates and _crls
> which should be but aren't.  But RFC 2782 is pretty casual about what
> protocols other than _tcp and _udp correspond to SRV names.  IANA has
> a protocol registry at
> http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml
> but a lot of the entries are not obvious candidates for SRV.  On the
> other hand, RFC 5509 makes _sip a SRV protocol name even though it's
> also a service.
> 
> DKIM currently allows _adsp as a subtag, probably not worth making a
> registry, since there don't seem to be any other likely DKIM subtags.
> Similarly there's _report._dmarc which seems to be a one-off.

For got that.  Thought it was indepedent. ADSP is now removed from the
draft.

d/


-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net