Re: [dnsext] DNSSEC, robustness, and several DS records

[Doug Barton <[e-mail]>]

Francis, FYI your peculiar style of quoting previous text makes your 
messages very hard to read. More so when they are part of a 
traditionally quoted message like this one.


On 5/12/2011 3:18 PM, Francis Dupont wrote:
>   In your previous mail you wrote:
>
>     A) Insert obligatory rant about why "should" and "may" should never be
>     used in standards documents.
>
> =>  I don't follow your idea...

"Should" and "may" introduce ambiguity and allow different implementors 
to follow different paths, leading to multiple implementations that all 
arguably follow the spec, but don't interoperate.

>     B) I don't think it takes even the smallest leap of imagination to say
>     that if the SHA-256 DS is invalid, and the SHA-1 DS is valid, the SHA-1
>     should be used and the SHA-256 should be ignored.
>
> =>  it is not a problem of imagination: either you implement what the
> spec says or you implement something else. And IMHO the first option
> is never a "bug".

And my point is that the language of the spec is unclear, which makes 
the proper implementation questionable.

>     I think we could have a fine "angels-on-the-head-of-a-pin" debate about
>     what "present" means in the RFC text
>
> =>  present == is an element of the set

My point was that the debate centers around whether or not a DS record 
can be said to be "present," "an element of the set," or whatever other 
equivalent term you want to use; if it doesn't work. If what you are 
saying is that if it exists in any form, functional or not, then it is 
said to be "present," that's where we disagree.

>     but I have a hard time believing that the intent of the text is
>     that if you have something that works it should be ignored in favor
>     of something that doesn't.
>
> =>  but it is the intent: this is why I wrote there is no "valid"
> in the spec (where my "valid" means your "works").

And I think one could argue just as effectively that if what is meant is 
what you're interpreting then a sentence to the effect of "This is true 
even if the SHA-256 record doesn't work." should have been included. Or 
maybe not. I recognize that I could be wrong, but I don't agree that 
things are as cut and dry as you make them out to be.

> So I don't expect to see bind or unbound to change their behavior
> unless/until a new rfc is published with another spec.

And now we get to the heart of why "should" and "may" are bad for 
technical requirements documentation. If I were an implementor I could 
very easily look at the spec and say, "Francis is right, I SHOULD skip 
the SHA-1 record here whether SHA-256 works or not. But I don't like 
that interpretation of the spec, so I won't." Such an implementation 
would be just as compliant, by the letter of the spec, as one that did 
skip the SHA-1.


Doug

-- 

	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/