On Sep 6, 2013, at 11:11 AM, Viktor Dukhovni <[email protected]> wrote:
> 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.
Removed,
>
> 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.
Removed.
>
> 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.
>
Well that depends on how well versed one is in reading TLSA records,
someone who is glancing at the record can make a guess what all the fields mean
in the second case but in the first case it is just numbers, that requires
reading registry or
RFC to comprehend.
The goal is to make life easier for the non-expert.
Olafur
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
