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

[Francis Dupont <[e-mail]>]

 In your previous mail you wrote:

   "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.
   
=> if something can introduce an interoperability problem a MUST is
required. Here it is not the case so IMHO it is why a SHOULD is used.

   And my point is that the language of the spec is unclear, which makes 
   the proper implementation questionable.
   
=> it seems you are the only person which argues about the meaning
of "present"... i.e., I argue the languafe of the spec is clear.

   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 the "if it doesn't work" could matter it would be in the text,
there is no such thing so it doesn't matter.

   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.
   
=> it is what I said and I maintain.

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

=> it seems there are 25 years of IETF just proving the opposite...
And ss an implementor I'd like to get more than MUSTs in technical
requirements (:-).

Regards

[e-mail]