Re: [DNSOP] redefining SRV, was New Version Notification for draft-ietf-dnsop-attrleaf-03.txt

"John R. Levine" <johnl@iecc.com> Tue, 20 March 2018 17:16 UTC

Return-Path: <johnl@iecc.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 2CFC51270AC for <dnsop@ietfa.amsl.com>; Tue, 20 Mar 2018 10:16:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level:
X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.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 mH5bMRs7aIOH for <dnsop@ietfa.amsl.com>; Tue, 20 Mar 2018 10:16:51 -0700 (PDT)
Received: from gal.iecc.com (gal.iecc.com [IPv6:2001:470:1f07:1126:0:43:6f73:7461]) (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 72411126E01 for <dnsop@ietf.org>; Tue, 20 Mar 2018 10:16:51 -0700 (PDT)
Received: (qmail 35774 invoked from network); 20 Mar 2018 17:16:50 -0000
DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:content-id:user-agent; s=8bbb.5ab14202.k1803; bh=55yrk2KSQrxToemlNctZVDqKImqwcy7VU97iC78K3wY=; b=K7WzigSusNcTbVnYj+m3kMpVnzoyP4nQnlH0TL2PyH5p2aSAVbXqPqtQwY8DbLzQKgJxPCxTLWnVUgLResNTnbyF7jaETu5rLOCKoWhjs06+vf1y5V9mLJXxYAyvsUx2+tMGC7/YImdHzXhklKTW5s4OKevdT42Xj3R7ap+r1kh/PxKzIL+0/Wz/woaW/QLl5f3z8Nl5xtQHEW+8bNwn0dtFP0uN/zj0rKP6sLJb10fsVhj3XiTAqAO0JpALcbbd
Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 20 Mar 2018 17:16:50 -0000
Date: 20 Mar 2018 17:16:48 +0000
Message-ID: <alpine.OSX.2.21.1803201716220.8834@dhcp-8344.meeting.ietf.org>
From: "John R. Levine" <johnl@iecc.com>
To: dnsop@ietf.org
User-Agent: Alpine 2.21 (OSX 202 2017-01-01)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="0-993134060-1521566170=:8834"
Content-ID: <alpine.OSX.2.21.1803201716240.8834@dhcp-8344.meeting.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/8wnX3AXFHR9EIiCOTcpfUB0S42s>
Subject: Re: [DNSOP] redefining SRV, was New Version Notification for draft-ietf-dnsop-attrleaf-03.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: Tue, 20 Mar 2018 17:16:54 -0000

>>>   2. SRV and URI
>  ...
>>   We need to change the description of the second level name registry to say
>>   that SRV and URI are special, they use names from Ports and Services at
>>   the second level and URI uses enumservice subtypes, and take out all of
>>   the SRV entries.  What's left is the grabbag of second level names used
>>   for other stuff like NAPTR and _adsp._domainkey.
>
>  No.  "Special" invites "errors", for on-going administration and operations.
>  I'm trying to make things simpler and less tangled.
>
>  We need to move away from the complexity created by having special rules for
>  some entries in the registry.

That would be fine except that the Port and Service registry has thousands of 
entries, and the named ones (nearly all of them) are valid SRV names. Importing 
a handful of names that we guess are commonly used with SRV is the worst of 
both worlds.

Either point at the real registry for SRV, or say that this explicitly 
redefines the namespace for SRV and see if dnsop will go for that.  I don't see 
any way you can just ignore RFC 6335 and its predecessors.

>  ps.  I thought the URI RR had no current actual use (or at least very
>  little.)

I belive that's correct, but again, either we deprecate URI or we deal with its 
naming rules.

To get rid of special, add another column to the first table which identifies 
the second level namespace.  In some cases it's empty, in some cases it's Ports 
and Services, in a few it's Enumservice, and in the rest it's the second table.

R's,
John