Re: [secdir] review of draft-ietf-dnsext-dnssec-gost-05

Jeffrey Hutzelman <jhutz@cmu.edu> Thu, 11 February 2010 17:54 UTC

Return-Path: <jhutz@cmu.edu>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F28EF3A7760 for <secdir@core3.amsl.com>; Thu, 11 Feb 2010 09:54:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.465
X-Spam-Level:
X-Spam-Status: No, score=-6.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qBCZCGrlStF6 for <secdir@core3.amsl.com>; Thu, 11 Feb 2010 09:54:47 -0800 (PST)
Received: from smtp01.srv.cs.cmu.edu (SMTP01.SRV.CS.CMU.EDU [128.2.217.196]) by core3.amsl.com (Postfix) with ESMTP id E64013A73F1 for <secdir@ietf.org>; Thu, 11 Feb 2010 09:54:46 -0800 (PST)
Received: from LYSITHEA.FAC.CS.CMU.EDU (LYSITHEA.FAC.CS.CMU.EDU [128.2.172.62]) (authenticated bits=0) by smtp01.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id o1BHthAY007203 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Feb 2010 12:55:43 -0500 (EST)
Date: Thu, 11 Feb 2010 12:55:43 -0500
From: Jeffrey Hutzelman <jhutz@cmu.edu>
To: Stephen Kent <kent@bbn.com>, Basil Dolmatov <dol@cryptocom.ru>
Message-ID: <9364B2468B4FBB516F5CEB46@lysithea.fac.cs.cmu.edu>
In-Reply-To: <28397_1265905809_o1BGU87p018787_p0624080cc799df651250@[128.89.89.170]>
References: <p06240810c76be77be756@[128.89.89.161]> <20100107222809.GA25747@shinkuro.com> <p06240818c76c1a38cbf8@[128.89.89.161]> <20100108144431.GB26259@shinkuro.com> <4B5B40FB.8060007@cryptocom.ru> <p0624080bc78249fa2c22@[10.242.22.104]> <4B5D1F85.1070900@cryptocom.ru> <p06240801c7837dde3143@[192.168.0.187]> <4B72F5A7.3050308@cryptocom.ru> <28397_1265905809_o1BGU87p018787_p0624080cc799df651250@[128.89.89.170]>
X-Mailer: Mulberry/4.0.8 (Linux/x86)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-Scanned-By: mimedefang-cmuscs on 128.2.217.196
Cc: Andrew Sullivan <ajs@shinkuro.com>, secdir@ietf.org, ogud@ogud.com, Ralph Droms <rdroms@cisco.com>
Subject: Re: [secdir] review of draft-ietf-dnsext-dnssec-gost-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Feb 2010 17:54:48 -0000

--On Thursday, February 11, 2010 11:29:55 AM -0500 Stephen Kent 
<kent@bbn.com> wrote:

> At 9:06 PM +0300 2/10/10, Basil Dolmatov wrote:
>>> ...
>> Good shift in modal verbs <girn>.
>> I am fully agree that implementations "ought to have" but not "must
>> have" a code.
>> This is the difference between MUST and SHOULD as I understand it.
>> If SHOULD is used then "it is advised to have a code", but you can
>> omit it (after "careful weighting") and still be compliant.
>> If MUST is used - then you must have a code, otherwise you are not
>> compliant. No options. Period.
>
> I think Andrew's characterization is better than mine, and his follow-up
> message to you provied good examples.
>
>> ...
>>> We're debating the issue of how broad a set of algorithms
>>> MUST/SHOULD be supported by RPs, which is an architectural (and
>>> political) issue.
>> Having no means to inform other side about algorithms used is the
>> thing that differs SIDR from DNSSec.
>
> I agree that there is a big difference between protocols where one can
> discover or negotiate protocol options and ones where this is not the
> case. But I believe that SIDR and DNESEC are pretty much the same in this
> respect. Both the RPKI and DNSSEC publish data that discloses what algs
> the publisher has chosen to employ. Relying parties either accommodate
> those choices or they do not make use of the signed data.
>
>>> ...
>>>
>>> I'm glad we agree on this. Since SHOULD is only a
>>> slightly-diminished form of MUST, ...
>> Either SHOULD is the synonym of MUST and then the question rises
>> what it is present for if there is no real difference between it and
>> MUST (it "should" <grin> be named as obsolete), or SHOULD has it's
>> own meaning and should not be treated in discussions as MUST
>> equivalent.
>
> See Andrew's message, to which Im alluded above.
>>> ...
>> I want to make a reservation that I am not native English speaking
>> person, so sometimes I use only literal meaning of the words when
>> writing (and reading).
>> In order to clarify I will use an example from my profession (I am a
>> physicist):
>>
>> Imagine that one astronomer will estimate the orbit of some comet
>> and say that "It is likely to hit the Earth".
>> Will it be the "threat" from the astronomer to the Earth? No, I
>> think that it will be just a "warning note", because the astronomer
>> have no influence on this process, he can only calculate the orbits
>> of comets.
>> Definitely, some people could say that "this astronomer threats us
>> with this comet", but it seems obvious that it is not the case. ;)
>
> OK. I'll interpret your comment as a comet warning :-).
>
>>
>>>> Maybe this is the way the DNS system will develop, but now I think
>>>> that the some effort to keep the DNS system united is justified.
>>>
>>> Unified is a goal we both agree upon, but mandated support for
>>> national algorithms is NOT a unifying principle, it is a
>>> Balkanizing principle (if you'll pardon the term).
>> I am not familiar with this term and once more I object against
>> putting the equal sign between MUST and SHOULD modal verbs.
>> I still think that there is a significant difference between them
>> which is worth keeping both of these verbs in the list of
>> instruments of IETF standards description.
>>
>> So, noone is talking about "mandated support" (which means MUST),
>> the bottom line is "to encourage support".
>
> MUST and SHOULD are not the same, but they are no so different as you
> seem to suggest.


It might be helpful for everyone to remember that while English has fairly 
loose definitions of "must" and "should", in this context MUST and SHOULD 
have precisely the meanings given them by RFC2119.  In particular, SHOULD 
is not mere advice or encouragement; it is a requirement almost as strong 
as MUST.  It doesn't mean "we think it's a good idea for you to do this"; 
it means "you absolutely have to do this unless...".

-- Jeff