Re: [DNSOP] [apps-discuss] Draft of interest in DNSOP: draft-ietf-dnsop-attrleaf

Dave Crocker <dhc@dcrocker.net> Thu, 04 August 2016 16:55 UTC

Return-Path: <dhc@dcrocker.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 A58C512D178 for <dnsop@ietfa.amsl.com>; Thu, 4 Aug 2016 09:55:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.209
X-Spam-Level:
X-Spam-Status: No, score=-1.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dcrocker.net
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 bAtQvdyeVvdR for <dnsop@ietfa.amsl.com>; Thu, 4 Aug 2016 09:55:30 -0700 (PDT)
Received: from simon.songbird.com (unknown [72.52.113.5]) (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 AFECE12D0AA for <dnsop@ietf.org>; Thu, 4 Aug 2016 09:55:30 -0700 (PDT)
Received: from [192.168.1.168] (76-218-8-128.lightspeed.sntcca.sbcglobal.net [76.218.8.128]) (authenticated bits=0) by simon.songbird.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id u74GtUCh029278 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for <dnsop@ietf.org>; Thu, 4 Aug 2016 09:55:30 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dcrocker.net; s=default; t=1470329730; bh=wGQ/cbG2ViLMEY8QYVvweA7TiGZbywGw+ZhzLwA9kG4=; h=Subject:To:References:Reply-To:From:Date:In-Reply-To:From; b=T3Bl5mLChN99820oHaXOpFxse/qhIEEyqf9vf94WWF+ScBX5eul7gcLbAIP+6cz8U WzEDIZ6n0UuR4ZrqOig55pZUwJaDyw7uoxjeR2rlM5KKi+ttkcOnTC7Of4mXmnx1Eg Bko8KMtr0EkdtQneoXuvi2SAKFaH5Yo0VXuhUDZg=
To: dnsop@ietf.org
References: <20160804015840.60405.qmail@ary.lan> <dd070788-bf7a-e7de-b07b-b81151f101db@dcrocker.net> <alpine.OSX.2.11.1608032350220.10321@ary.lan> <f42e91bb-19fd-99d6-bd64-e2ec5b8ebf2f@bellis.me.uk>
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
Message-ID: <ae82cc80-fdfe-8876-7459-db61c7abc52d@dcrocker.net>
Date: Thu, 04 Aug 2016 09:55:14 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <f42e91bb-19fd-99d6-bd64-e2ec5b8ebf2f@bellis.me.uk>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/zByMRnfeGAmaM0jIdKR8v7cSE_Q>
Subject: Re: [DNSOP] [apps-discuss] Draft of interest in DNSOP: draft-ietf-dnsop-attrleaf
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
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: Thu, 04 Aug 2016 16:55:32 -0000

On 8/4/2016 1:54 AM, Ray Bellis wrote:
> The one I thought was a deviation was "xmpp-client" (5222), but it turns
> out that's just because my macOS /etc/services file is out of date and
> still lists that as "jabber-client".

Thanks for the clarification, Ray.

Absent anyone else raising concerns, I'll change the draft to remove any 
normative specification of second-level underscore names, and add some 
informative (non-normative) language pointing to the spiffy new(ish) and 
improved IANA table.


That leaves what I think is still a significant open question:

>> For URI records RFC 7553 says they're either named the same as SRV
>> records, or they use enumservice names from the Enumservice
>
> Declaring a namespace as the union of two, independently-maintained
> registries is a very efficient way to encourage -- actually in
> theoretical terms, it guarantees -- collisions.
>

I see this as a fundamental problem with the URI spec, for the reason 
cited.  I also think the current spec should be careful not to promote 
that problem.

Suggestions?

d/
-- 
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net