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

Stephen Kent <kent@bbn.com> Thu, 11 February 2010 16:28 UTC

Return-Path: <kent@bbn.com>
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 77D1C3A773D for <secdir@core3.amsl.com>; Thu, 11 Feb 2010 08:28:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.504
X-Spam-Level:
X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599]
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 eT89lscXuKUs for <secdir@core3.amsl.com>; Thu, 11 Feb 2010 08:28:51 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 84E483A773C for <secdir@ietf.org>; Thu, 11 Feb 2010 08:28:51 -0800 (PST)
Received: from dhcp89-089-170.bbn.com ([128.89.89.170]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1NfbvY-000Mdh-0i; Thu, 11 Feb 2010 11:30:04 -0500
Mime-Version: 1.0
Message-Id: <p0624080cc799df651250@[128.89.89.170]>
In-Reply-To: <4B72F5A7.3050308@cryptocom.ru>
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>
Date: Thu, 11 Feb 2010 11:29:55 -0500
To: Basil Dolmatov <dol@cryptocom.ru>
From: Stephen Kent <kent@bbn.com>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Cc: Andrew Sullivan <ajs@shinkuro.com>, Ralph Droms <rdroms@cisco.com>, ogud@ogud.com, secdir@ietf.org
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 16:28:52 -0000

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.

Steve