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

"John Levine" <> Mon, 06 March 2017 02:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 036AE1293D8 for <>; Sun, 5 Mar 2017 18:35:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.821
X-Spam-Status: No, score=-0.821 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_DYNAMIC=1.08, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qEBQSHsalTs1 for <>; Sun, 5 Mar 2017 18:35:25 -0800 (PST)
Received: from ( [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E7CC0126D73 for <>; Sun, 5 Mar 2017 18:35:24 -0800 (PST)
Received: (qmail 67335 invoked from network); 6 Mar 2017 02:35:23 -0000
Received: from unknown ( by with QMQP; 6 Mar 2017 02:35:23 -0000
Date: Mon, 06 Mar 2017 02:35:01 -0000
Message-ID: <20170306023501.22939.qmail@ary.lan>
From: John Levine <>
In-Reply-To: <>
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset="utf-8"
Content-transfer-encoding: 8bit
Archived-At: <>
Subject: Re: [DNSOP] [apps-discuss] Draft of interest in DNSOP: draft-ietf-dnsop-attrleaf
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 06 Mar 2017 02:35:26 -0000

In article <> you write:
>>>> For URI records RFC 7553 says they're either named the same as SRV
>>>> records, or they use enumservice names from the Enumservice

>> Patrik's and John 's postings notwithstanding, I'm still concerned about
>> the proposed way of handling this, namely to rely on IANA to do a manual
>> check of the two registries the URI RR might call on.  First, it does
>> not seem reasonable to me to impose that burden on the IANA staff and
>> second a manual process like that is almost certain to produce errors.

>Again, my concern is with handing IANA an on-going task -- making a 
>check every time they update the Attrleaf table -- that requires their 
>being perfect at detecting collisions with one or more other tables.

Has anyone asked IANA whether they have an opinion on how hard this
would be?  For that matter, are there other registries with similar
issues?  Do they have or would they plan to write software to do the
cross check automatically when one of the registries is to be updated?
I wouldn't think it'd be much different from checking whether a single
registry has duplicate entries.