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

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