Sorry for the delay in responding. On Aug 9, 2013, at 10:10 PM, Scott Schmit <[email protected]> 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 protected] > https://www.ietf.org/mailman/listinfo/dane _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
