New version addressing this call by the chairs posted.
Olafur
On Dec 1, 2013, at 2:00 PM, Warren Kumari <[email protected]> wrote:
>
> 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
