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

Andrew Sullivan <ajs@shinkuro.com> Thu, 11 February 2010 14:14 UTC

Return-Path: <ajs@shinkuro.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 5AB573A74EB for <secdir@core3.amsl.com>; Thu, 11 Feb 2010 06:14:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.733
X-Spam-Level:
X-Spam-Status: No, score=-1.733 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, J_CHICKENPOX_21=0.6]
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 f6Hmt2+Im8RX for <secdir@core3.amsl.com>; Thu, 11 Feb 2010 06:14:35 -0800 (PST)
Received: from mail.yitter.info (mail.yitter.info [208.86.224.201]) by core3.amsl.com (Postfix) with ESMTP id 9C58B3A70CF for <secdir@ietf.org>; Thu, 11 Feb 2010 06:14:35 -0800 (PST)
Received: from crankycanuck.ca (69-196-144-230.dsl.teksavvy.com [69.196.144.230]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.yitter.info (Postfix) with ESMTPSA id 252C31ECB4E8; Thu, 11 Feb 2010 14:15:49 +0000 (UTC)
Date: Thu, 11 Feb 2010 09:15:47 -0500
From: Andrew Sullivan <ajs@shinkuro.com>
To: Basil Dolmatov <dol@cryptocom.ru>
Message-ID: <20100211141547.GD9592@shinkuro.com>
References: <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> <20100210190509.GQ5187@shinkuro.com> <4B732624.7040303@cryptocom.ru>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4B732624.7040303@cryptocom.ru>
User-Agent: Mutt/1.5.18 (2008-05-17)
Cc: 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 14:14:36 -0000

On Thu, Feb 11, 2010 at 12:33:24AM +0300, Basil Dolmatov wrote:
> Could you be so kind to point to a couple of examples of such usage of
> SHOULD in IETF documents?<br>
> Where SHOULD is used and exceptions&nbsp; are clearly listed.<br>
> <br>
> That will help to understand the situation with this verb better.<br>
> Thanks in advance,<br>

[Note that it's much easier for me if you send your mail multipart, so
I don't have to read plain HTML.]  

A good example of this style, I think, is in RFC 4308.  For instance, look at these bits:

   Implementations that use UI suites SHOULD also provide a management
   interface for specifying values for individual cryptographic options.
   That is, it is unlikely that UI suites are a complete solution for
   matching the security policies of many IPsec users, and therefore an
   interface that gives a more complete set of options should be used as
   well.

   IPsec implementations that use these UI suites SHOULD use the suite
   names listed here.  IPsec implementations SHOULD NOT use names
   different than those listed here for the suites that are described,
   and MUST NOT use the names listed here for suites that do not match
   these values.  These requirements are necessary for interoperability.

The first paragraph says you SHOULD provide a management interface,
because it's unlikely the UI suite is a complete solution for matching
the security policies.  By implication, the case in which you need not
provide the management interface is the case where the UI suite is
_guaranteed_ to provide the complete solution.  There could be such
cases, though (I can imagine an organization that had tight rules
about exactly what was allowed, and that could control the UI for
everyone).

The second paragraph says SHOULD and tells you what the requirements
are needed for.  By implication, if you don't care about
interoperability, then you could violate this.  (I like this example
because it's a bizarre exception, since the whole point of an RFC is
interoperability.)

Clearer?  (If not, trim the cc:s when following up: I doubt everyone
else needs to be seeing all this.)

A

-- 
Andrew Sullivan
ajs@shinkuro.com
Shinkuro, Inc.