On Wed, Jan 13, 2016 at 06:42:21AM -0000, John Levine wrote:
> > ... But what's the real benefit to all this?
>
> You're avoiding name collisions down the road.
Please don't get me wrong, I'm not zealous about this, just don't
yet see any value in the additional labels, and surely we should
add them for a good reason. I would expect the RRtype to provide
all the collision avoidance that's required. Plus the fact that
these are intended to be host-specific records, while, the various
proposed example collisions are generally published at the parent
domain of the various hosts.
If we have to insert "_client" and that's the WG consensus, fine,
just extra bits on the wire. As for "_tcp", that is really just
excess baggage. Once we move move away from port numbers to
application names the transport protocol to disambiguate numeric
ports really does not seem at all helpful.
Anyone voting for application OIDs to avoid collisions? The OID
space is plausibly in better shape than the flat IANA service name
registry...
> >James makes a plausible point about _client as a way to carve out
> >a zone for clients, but because unlike SMIME/A or OPENPGPKEY the
> >base domain is here typically not a zone apex, but rather a specific
> >host, carving out a new zone under each host scales poorly.
>
> Surely we don't have to review the difference between name components
> and zone cuts. Nobody has proposed putting a new zone under each host
> name.
I guess James is "nobody". :-)
On Tue, Jan 12, 2016 at 03:05:51PM -0500, James Cloos wrote:
>
> For draft-huque-dane-client-cert I'd still prefer RR names like:
>
> _smtp._client.example
>
> for the cert provided by an smtp client which HELO/EHLOs as example.
> And similarly for other protocols. Rather than things like _smtp-client.
>
> Putting all of the client TLSAs under a single label allows (but
> obviously does not require) them to be in their own zone.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
