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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
