Apologies. There was a posting about this draft in apps-discuss and I
made the mistake of responding with a substantive proposal on that list.
John Levine then responded to the substance, also on apps-discuss.
I'm reposting this to dnsop to move the thread over to the correct list.
I'll forward John's note, to record it, and then finally send a
response to his note... sigh. /really/ sorry.
d/
-------- Forwarded Message --------
Subject: Re: [apps-discuss] Draft of interest in DNSOP:
draft-ietf-dnsop-attrleaf
Date: Wed, 3 Aug 2016 15:20:04 -0700
From: Dave Crocker <[email protected]>
Reply-To: [email protected]
Organization: Brandenburg InternetWorking
To: Patrik Fältström <[email protected]>, Tim Wicinski <[email protected]>
CC: [email protected]
On 7/20/2016 1:59 AM, Patrik Fältström wrote:
On 20 Jul 2016, at 7:57, Tim Wicinski wrote:
This draft is not just looking at SRV records, but TXT records which document
such behavior.
And URI.
URI:
I think I didn't respond to this: URI showed up after the original
drafting of the doc, but yes it needs to be included. However after
some very basic research it appears that the URI RR does not yet have
traction. So the current doc needs to account for its existence but I
think it does not create additional registry entries, especially since
it emulates SRV.
Subordindate Table(s):
More significant is the handling of the second-level underscore node
name for the two-level naming constructs (where the upper-level is a
protocol string, used by SRV and URI. Ray had suggested a way to deal
with this quite a long time ago and I promptly forgot what it was. When
the topic renewed during Berlin, I finally gravitated towards a model
that luckily was along the lines he proposed...
In practical terms, the second-level underscore names need to be
registered explicitly, although one might think the SRV doc has covered
this by pointing to a table. By my reading, that reference is more
conceptual than a detailed registry reference.
The set of protocol (upper-level) names is small and should be in the
registry explicitly. One might argue that the reference to the separate
protocol table suffices but this is a case that seems better handled by
the mild redundancy.
As for the second-level underscore names, I propose that they /also/ be
registered in this one table. In theoretical terms, one could argue for
a separate table, or maybe many of them (one under each top-level
underscore protocol name) but that purity-drive choice seems somewhere
between inefficient and silly.
If we thought there would be lots of independent uses of the same name,
but under different upper-level underscore (protocol) names, we'd need
all the separate, subordinate names. And indeed, this is what bogged me
down originally.
But no one, including me, so far thinks this is a realistic need. So
finding a way to simplify this down to one table seems eminently reasonable.
Thoughts?
d/
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
