On Oct 6, 2013, at 5:38 PM, Jim Schaad <[email protected]> wrote:
> 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.
>
There two instances of MAY and MAY NOT
I reworded them and removed section 1.1
> 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.
>
There are two different set of references
a) the references for the Registry itself
b) the references for each allocation in the registry.
This document only applies to the first one
and that is what I said.
> 3 s/input>/input./
>
Fixed
> 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.
>
I agree and removed that sentence.
> 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.
I leave a call on that to the wise chairs :-)
I do not care personally
>
> 6. The note component at the end of section 2.1 should be deleted.
Gone
>
> 7. In section 3, the descriptive text and the example records do not match
> in very significant ways.
>
I must be dense, there is not supposed to be any correlation between the
two paragraphs in section 3 they are supposed to be separate examples.
thanks for good comments.
Olafur
> Jim
>
>
> _______________________________________________
> dane mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/dane
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
