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

From: Samuel Weiler <[email-masked]>
Date: Thu, 8 Mar 2012 18:35:19 -0500 (EST)

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.

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

-- Sam

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 8 Mar 2012 16:25:30 -0800

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

> 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

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 8 Mar 2012 20:05:15 -0500

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

> > 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
[email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 8 Mar 2012 18:07:38 -0800

> going to push us over the top.

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

> 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

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 08 Mar 2012 19:57:01 -0800

>>>>> On Thu, 8 Mar 2012 16:25:30 -0800, Paul Hoffman <[email-masked]> said:

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

The problem with the wording is that you're really trying to say
something that dictates software implementation practices.  And this is
nearly impossible to get right because most software stacks really can't
do what you want.  Specifically, if a software stack accepts a
configuration file as an input for policy knobs there is no way you
"SHOULD NOT expose" knobs based on the number of trust anchors defined
somewhere else in the file.

Wouldn't it be better to state your actual intentions?

  It is recommended (RECOMMENDED?) that the policy options in the
  following subsections only be configured when multiple trust anchors
  are also configured.

If someone is writing a GUI configuration set (ha ha, like those exist),
then they can actually hide things.  Otherwise it's up to the operator
to not use the knobs in the section when writing a config file.

-- 
Wes Hardaker
SPARTA, Inc.