On Sat, Dec 07, 2013 at 06:34:40PM -0800, John Gilmore wrote:
> > Any (strong) objections?
>
> Yes, I object. If there is no consensus on acronyms, we should stick
> with what is in the current RFC 6698, rather than forwarding an
> acronym proposal for adoption as a standard, even though we can't
> agree on what it should say. It's unnecessary, which probably
> explains the paucity of responses, and divisive among those who did
> respond. It should be abandoned.
Perhaps the author is willing to take a look at the history of the
thread, and propose one final set of names for the 4 usages that
makes most sense to him. We can then object or concur with those
without (yet again) proposing changes.
I am not fundamentally opposed to human-readable TLSA RRs:
; _25._tcp.mx.example.com. IN TLSA 3 1 2
_25._tcp.mx.example.com. IN TLSA TRUSTED-LEAF PUBLIC-KEY SHA2-512 {blob}[
; _25._tcp.mx.example.com. IN TLSA 2 0 2
_25._tcp.mx.example.com. IN TLSA TRUSTED-CA CERTIFICATE SHA2-512 {blob}
; _25._tcp.mx.example.com. IN TLSA 1 0 1
_25._tcp.mx.example.com. IN TLSA VALID-LEAF PUBLIC-KEY SHA2-256 {blob}
; _25._tcp.mx.example.com. IN TLSA 0 1 0
_25._tcp.mx.example.com. IN TLSA VALID-CA PUBLIC-KEY VALUE {blob}
As much possible, the acronyms should avoid jargon unfamiliar to
their intended audience and in a full TLSA record should ideally
read like a complete sentence, as above.
The dichotomy between "TRUSTED" (sufficient on its own) and "VALID"
(not sufficient without external trust) is I think one reasonable
way to communicate the usage values.
Anyway, I think it is up to the author to propose a final revision,
or as John suggests, give up.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
