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

From: Dave Crocker <[email-masked]>
Date: Sun, 5 Mar 2017 16:46:16 -0800

Hi, folks,

I've been reminded that the attrleaf draft is still pending.  I've 
re-submitted the -00 draft as -01, just to restart the timer on the 
document.

On reviewing the discussion history, I see some items for the list that 
I believe weren't resolved...

On 8/28/2016 4:04 PM, Dave Crocker wrote:
>>> 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.
>
> 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.

This needs discussion and resolution by the working group.

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.

If the wg decides this is acceptable, I'd like to document the basis for 
the decision.

> On 8/3/2016 9:05 PM, John R Levine wrote:
>> I suppose, but since the two registries exist and the URI RFC says to
>> use both of them as _name, that horse has left the barn.
>
> I think it left the theoretical barn, but not the practical one.  We've
> been told that there is not yet any uptake in the URI RR.  That makes it
> plausible to modify its spec to eliminate this problem.

Can we get a working group assessment of the real-world uptake of the 
URI RR?

> Really, the burden of trying to have on-going coordination for the URI
> RR, between two different registries is worth finding a way to avoid.
> The problem is that I am not sure what to suggest that will work for URI
> usage.
>
> Suggestions?

Suggestions are still solicited.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: "John Levine" <[email-masked]>
Date: 6 Mar 2017 02:35:01 -0000

>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.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Sun, 5 Mar 2017 19:11:27 -0800

> registry has duplicate entries.

The advocate gets to pursue the questions.  Thank you for offering...

d/

---

From: Dave Crocker <[email-masked]>
Date: Sun, 5 Mar 2017 19:21:57 -0800

On 3/5/2017 4:46 PM, Dave Crocker wrote:
> On reviewing the discussion history, I see some items for the list
> that I believe weren't resolved...

For those more interested in linguistic issues, as well as protocol
details, there is a 'comment' in Introduction of the _Attrleaf draft
that I'd like to get agreement on -- possibly with refinement -- and
move from 'comment' to 'note':

> The terms "resolution context" and "scoping rules" have been
> suggested, in place of "semantic scope". In order to avoid concern
> for matters of semantics, this specification uses the term "scoping
> rules", to create a focus on the mechanics being defined, rather than
> nuances of interpretation for the mechanism.

Comments?

d/