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

["Patrik Fältström " <[e-mail]>]

On 29 Aug 2016, at 3:42, John Levine 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.
>
> Well, either you can persuade Patrik and Olaf to revise RFC 7553 to
> add a _enumservice psedudo-transport to disambiguate, or you can't.
> When I look at the enumservice registry, I see that it's not very big
> and doesn't change very often.
>
> Rather than speculating about how hard this would be for IANA, why
> don't you ask them.  Do they have any other groups of registries that
> they have to monitor for name collisions?  How much harder is that
> than the checking they have to do in a large registry like ports and
> services to be sure they don't reuse a name?

First, when creating the URI RR I felt a registry WAS needed. The mess with SRV could not be accepted.

Secondly, creating the registry while doing URI was just not something I had energy for. It was enough to get IETF accept a new RR Type at all.

Thirdly, the ENUM Registry process requires RFC for the registration of an ENUM Service requires an RFC (see RFC 6117) that have a specific IANA Considerations section.

Forth, as part of the ENUM Service Registration, Expert Review is required.

Conclusion: I think the above can resolve _future_ conflicts.

We do though have a few other issues here:

1. Merge of all sources we have, i.e. what will the initial list of prefixes look like?

2. When adding things to this table, what is really required?

To answer your question: I am perfectly happy to update the spec for URI so that it clearly says that:

A. Primary source for prefixes is this new registry created by Daves document

B. When registering an ENUM Service, according to RFC 6117, this registry created by Dave should also be updated, and how to be updated should be in the RFC that specifies the ENUM Service. The Expert Review is to ensure that is done in a proper way.

I.e. I agree we should and can not have more than one registry for prefixes, and of course we should move all references regarding prefixes to point to this new registry by IANA.

Actions for me, I guess, given consensus:

- Write a new RFC updating 6117 and 7553 so that this new registry is referenced in a correct way. Unless people think such text should go into this RFC that Dave is already writing/creating.

    paf