Subject: Re: [dane] New Version Notification for draft-dane-registry-acronym-00.txt

From: Olafur Gudmundsson <[email-masked]>
Date: Fri, 6 Sep 2013 10:42:10 -0400

Sorry for the delay in responding. 

On Aug 9, 2013, at 10:10 PM, Scott Schmit <[email-masked]> wrote:

> On Fri, Aug 09, 2013 at 10:19:25AM -0400, Olafur Gudmundsson wrote:
>>> Abstract:
>>>  Experience has show that people get confused using the three numeric
>>>  fields the TLSA record.  This document specifies descriptive acronyms
>>>  for the three numeric fields in the TLSA records.
> 
> I do find myself a little puzzled that we feel this is necessary --
> nobody is calling for this for DNSKEY, RRSIG, or DS records?
> 
> Anyway, we aren't generating acronyms for the numbers -- we're
> identifying enumeration values.
> 
> In Table 2, "Hash" should be "SPKI", "Full" should probably be "Cert".
> In Table 3, "NoHash" should be "Full".

These are excellent suggestions and I have applied in the upcoming (hopefully final) version. 
> 
> I'm not convinced that Priv* will see enough use to be worth making an
> enumeration value for them. If you're going to have them, "PrivHash"
> needs to be "PrivMatch".
agree

> 
> Otherwise you'll end up with weird things like:
> * PKIX-CA Hash NoHash
> * DANE-EE Full SHA2-256
> * DANE-TA Full NoHash
> 
> instead of:
> * PKIX-CA SPKI Full
> * DANE-EE Cert SHA2-256
> * DANE-TA Cert Full
> 
> Other questions not addressed in the draft:
> * Case sensitive or not?
Not 

> * Probably should show some examples of use?

Will do

> * Can I mix enumerations with the numbers?
Why not

> * What if the enumerations are used out of order?
Same as when numbers are out of order except with textual use this might be easer to detect. 

thanks a lot for the good suggestions. 

> 
> -- 
> Scott Schmit
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 6 Sep 2013 15:11:54 +0000

> 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.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Thu, 19 Sep 2013 16:11:47 -0400

> replace DANE-TE with DANE-TA.  Also I have no idea wha "Sides example" means.

Removed, 

> not use this example at all.

Removed. 

> 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