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

On Mar 8, 2012, at 5:05 PM, Andrew Sullivan wrote:

> On Thu, Mar 08, 2012 at 04:25:30PM -0800, Paul Hoffman wrote:
>> On Mar 8, 2012, at 3:35 PM, Samuel Weiler wrote:
>> 
>> 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.
> 
> I am opposed to that text.  If the WG really strongly wants it, I'll
> withdraw my objection, but I'm strongly opposed to it because I find
> it both confusing and untestable.  I know what this is about, and I
> still had to read that twice to parse it.  Also, what would be a case
> where a validator might permit this?  When is it ok?  And so on.
> 
> Moreover, I don't think we should be trying to boss around people and
> tell them how to make their software: if 50 years of evidence in
> favour of eliminating pointless options in software hasn't taught us
> to do it yet, I see no hope that a confusing paragraph in an RFC is
> going to push us over the top.

OK, I can see that. Maybe we should just drop my original objection.

>>>>  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.
>> 
> 
> My reasoning was that the first formulation, though more awkward and
> so on, is not actually a protocol change.  The second formulation is.
> The first one says, "People are violating this bit of the protocol,
> and you should know about that and act according to how you think
> best."  The second one says, "The protocol said that you could rely on
> this, and now you MUST NOT."  I think that an actual protocol change,
> no matter how teensy we might think it is, needs evidence that the WG
> agrees; so far, we have one commenter and two document editors, but
> nobody else who's spoken on it.  Therefore, WG participants, if you
> agree with Sam's proposed change please weigh in.  Otherwise, I don't
> feel very comfortable sending it to the IESG, and will have to
> highlight this change in the PROTO write-up.

I agree with Andrew that this is a protocol change. I agree with Sam that this proposed change is clearer than the wording Andrew chose from my first message.

--Paul Hoffman

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