Re: [dane] Start of WGLC for draft-ietf-dane-registry-acronym

On Oct 3, 2013, at 4:31 PM, Wes Hardaker <wjhns1@hardakers.net> wrote:

> Warren Kumari <warren@kumari.net> 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
> dane@ietf.org
> https://www.ietf.org/mailman/listinfo/dane