Re: [dnsext] Issues in WGLC of dnssec-bis-updates

On Mar 8, 2012, at 3:35 PM, Samuel Weiler wrote:

> I know that Andrew posted a closing summary of this discussion.  I'm quoting the opening message since it provides much more context.
> 
> There are a couple of these default actions that I'm uneasy with.
> 
> 
> On Tue, 7 Feb 2012, Andrew Sullivan wrote:
> 
>> ISSUE 3: Alter section 5.10
>> 
>> Paul Hoffman requests a change to section 5.10 in
>> http://www.ietf.org/mail-archive/web/dnsext/current/msg12173.html.
>> Speaking only personally, I cannot see any objection to the proposed
>> sentence, "If a site has only a single trust anchor, the information
>> in this entire section can safely be skipped."  I'm less sure about
>> the motivational sentences; I'm not even sure they're true.  Does
>> anyone have any thoughts?
>> 
>>   DEFAULT ACTION: Include the "If a site has only a single trust
>>   anchor ?" sentence, and exclude the other proposed sentences.
> 
> If this document were aimed at operators, the above would make more sense.  Since this is a doc for implementers, the "ignore this section" guidance is dangerous -- the implementer of a validating resolver does not know what trust anchor(s) an operator will configure.  I prefer to not include this sentence.

This is actually a good point. I withdraw my previous wording, and suggest instead that the following be added as a separate paragraph before 5.10.1:

   When not presented with the situation that more than one trust
   anchor is configured, DNSSEC validators SHOULD NOT expose policy
   choices such as those shown in these subsections in configuration
   options. That is, these policy choices SHOULD only be exposed
   when there are multiple options.

>> ISSUE 4: Request to change the language in 5.6
>> 
>> This is also a request from Paul Hoffman, in the same review.  Is
>> there any objection to his first formulation?  I believe his second
>> formulation would actually be a significant change to the protocol,
>> and as shepherd I cannot accept it without a fairly strong signal from
>> the WG.
>> 
>>   DEFAULT ACTION: Use the first formulation proposed ("In order to
>>   interoperate with implementations that ignore this rule on
>>   sending, resolvers need to allow either the DO bit to be set or
>>   unset when receiving responses.")
> 
> I think the two formulations are equivalent, except that the second is stated in clearer and more normative language.  Yes, this is a change, but it's one we need to make.  Let's use the less muddled form of it.

FWIW, I agree with Sam here: my second proposal ("Because some implementations ignore this rule on sending, the rule for receivers is now that they MUST NOT expect the DO bit to be set as it was sent.") is the one I prefer. I proposed the first because I thought the second would be hard for some people to swallow.

--Paul Hoffman

_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext