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

Francis Dupont <> Sat, 14 May 2011 12:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 97BE8E06B4 for <>; Sat, 14 May 2011 05:11:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IBJj5FVdE+1r for <>; Sat, 14 May 2011 05:11:28 -0700 (PDT)
Received: from ( [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) by (Postfix) with ESMTP id 95D99E06B1 for <>; Sat, 14 May 2011 05:11:27 -0700 (PDT)
Received: from (localhost []) by (8.14.3/8.14.3) with ESMTP id p4ECBL5S043969; Sat, 14 May 2011 14:11:21 +0200 (CEST) (envelope-from
Message-Id: <>
From: Francis Dupont <>
To: Doug Barton <>
In-reply-to: Your message of Thu, 12 May 2011 15:33:02 PDT. <>
Date: Sat, 14 May 2011 14:11:21 +0200
Cc:, Paul Hoffman <>
Subject: Re: [dnsext] DNSSEC, robustness, and several DS records
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 14 May 2011 12:11:28 -0000

 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 (:-).