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

New version  addressing this call by the chairs posted. 

	Olafur

On Dec 1, 2013, at 2:00 PM, Warren Kumari <warren@kumari.net> wrote:

> 
> On Oct 16, 2013, at 4:41 PM, Olafur Gudmundsson <ogud@ogud.com> wrote:
> 
>> 
>> On Oct 6, 2013, at 5:38 PM, Jim Schaad <ietf@augustcellars.com> 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
>>> dane@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dane
>> 
>> _______________________________________________
>> dane mailing list
>> dane@ietf.org
>> 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
> 
> 
> 