On Oct 16, 2013, at 4:41 PM, Olafur Gudmundsson <[email protected]> wrote:
> > 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 I'm not sure where these "wise chairs" are, but I believe we have consensus for PKIX-TA. It's not ideal but seems good enough. Apologies for the delay, digging out from under backlogged mail from the NANOG/RIPE/IETF/ICANN roadshow… W > >> >> 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 > -- "I think it would be a good idea." - Mahatma Ghandi, when asked what he thought of Western civilization _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
