On Fri, Sep 06, 2013 at 10:42:10AM -0400, Olafur Gudmundsson wrote:
> Sorry for the delay in responding.
>
> These are excellent suggestions and I have applied in the upcoming (hopefully
> final) version.
One more correction, in the text:
Sides example: "In the case of FOO for practical cases you can treat
PKIX-CA == DANE-TE" (see talk at IETF-87 on DANE for email)
replace DANE-TE with DANE-TA. Also I have no idea wha "Sides example" means.
Also since in SMTP the mapping from usage 0 to usage 2 will be
incomplete, a better example would be "PKIX-EE == DANE-EE". The
final DANE for SMTP spec will likely say that PKIX usages are simply
unsupported, and SHOULD NOT published, so perhaps it is best to
not use this example at all.
FWIW, while when speaking of an individual TLSA RR elements, I
find acronyms helpful, when reading a complete TLSA RRset, I
find
mail.example.com. IN TLSA 3 1 1 ...
much easier to quickly parse at a glance than
mail.example.com. IN TLSA DANE-EE SPKI SHA2-256 ...
which requires a lot more cognitive effort.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
