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

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

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