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

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.

> >>   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.

Best,

A

-- 
Andrew Sullivan
ajs@anvilwalrusden.com
_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext