On Oct 3, 2013, at 4:31 PM, Wes Hardaker <[email protected]> wrote:
> Warren Kumari <[email protected]> writes: > > Looks like a good start and thanks for writing it Olafur! But it's not > ready for publication without some cleanup. Too many standard-things > are missing, such as acronym expansion and I'd feel guilty passing it > to the RFCEditors without us having caught such things. > > Nits: > > 1) > handle any case use in the input> The expectation is that by using > ^^^^^^ > ?????? Fixed > > 2) my alternate suggested should descriptions (I like the acronyms > themselves): > > +-------+----------+-------------------------------------+-----------+ > | Value | Acronym | Short Description | Reference | > +-------+----------+-------------------------------------+-----------+ > | 0 | PKIX-TA | PKIX Validated CA Reference | [RFC6698] | > | 1 | PKIX-EE | PKIX Validated End-Entity Reference | [RFC6698] | > | 2 | DANE-TA | Validation TA Reference | [RFC6698] | > | 3 | DANE-EE | Domain-issued certificate Reference | [RFC6698] | > | 4-254 | | Unassigned | | > | 255 | PrivCert | Reserved for Private Use | [RFC6698] | > +-------+----------+-------------------------------------+-------------+ > I ask chairs to rule if your rewording has traction I like it but there were no voices of support and this changes the registry more than the one column that I set out to add. > Table 1: TLSA Certificate Usages > > 3) intro text (1 sentence?) to sections needed and expansion of other > acronyms earlier in the document (PKIX, EE, ) > No > 4) ideally space align the section 3 records > > inserted one space here > v > _666._tcp.first.example. TLSA PKIX-CA CERT SHA2-512 {blob} > _666._tcp.second.example. TLSA DANE-TA SPKI SHA2-256 {blob} fixed. > > 5) security considerations > > There is definitely something to consider if someone publishes both > name records along with number records, and the client only parses > number records. What happens with this: > > _666._tcp.first.example. TLSA 3 1 1 {blob} > _666._tcp.first.example. TLSA DANE-TA SPKI SHA2-256 {blob} This is impossible as the DNS wire fomat is numbers. > > Something needs to be said for that case; what would an existing > implementation do? drop both? take one? Either way, it should be > discussed/mentioned. > > -- > Wes Hardaker > Parsons > _______________________________________________ > dane mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dane _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
