Sorry for being late on getting this in. 1. I do not understand the reasoning behind the 2119 language in the introduction. How would one test this in a protocol fashion? The document states that it does not change DANE in anyway, but there are requirement language statements that can be made? This should be stated in natural language not requirement language. Section 1.1 can them be removed in its entirety.
It is expected that DANE parsers in applications and DNS software will adopt these acronyms for parsing and display purposes, however there are no requirements that they do so. 2. In section 2, it states that the references should be both RFC 6698 and this document, however that is not the way that the tables starting in section 2.1 are laid out. They only use RFC 6698 as a reference document. 3 s/input>/input./ 4. I don't think that this phrase "fewer bad TLSA records" is very helpful. What is meant by a bad TLSA record? Is this just ones where the fields were put out of order or does it include ones where the certificate is incorrectly hashed? If the goal is to avoid issues with the certificates and what is extracted, then doing something about what goes into the blob would make sense as well. I would agree that specifying how this would be done is out of scope, but noting it as an issue would be reasonable. 5. As I have stated before, I am not a fan of using DANE-TA for value 2. To me this loses the fact that there will be PKIX processing that occurs with this section. I would strongly recommend that this become PKIX-TA. The use of PKIX-TA for the value of 0 never made any sense since there is not trust anchor decision that is associated with the certificate in this record. The only two records currently that have a trust anchor, as oppose to a constraint, component are 2 and 3. 6. The note component at the end of section 2.1 should be deleted. 7. In section 3, the descriptive text and the example records do not match in very significant ways. Jim _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
