Re: [secdir] Review of draft-ietf-l2vpn-oam-req-frmk-09
Jeffrey Hutzelman <jhutz@cmu.edu> Tue, 08 January 2008 18:51 UTC
Return-path: <ietf-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCJXq-0000Zg-Ke; Tue, 08 Jan 2008 13:51:26 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1JCJXo-0000Uh-Ty; Tue, 08 Jan 2008 13:51:24 -0500
Received: from jackfruit.srv.cs.cmu.edu ([128.2.201.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1JCJXo-0005je-9v; Tue, 08 Jan 2008 13:51:24 -0500
Received: from atlantis.pc.cs.cmu.edu (ATLANTIS-HOME.PC.CS.CMU.EDU [128.2.200.132]) (authenticated bits=0) by jackfruit.srv.cs.cmu.edu (8.13.6/8.13.6) with ESMTP id m08Ip3S5026293 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 8 Jan 2008 13:51:04 -0500 (EST)
Date: Tue, 08 Jan 2008 13:51:02 -0500
From: Jeffrey Hutzelman <jhutz@cmu.edu>
To: Tobias Gondrom <tobias.gondrom@gondrom.org>, Dinesh Mohan <mohand@nortel.com>
Message-ID: <00C77782EBC1B564CDA73632@atlantis.pc.cs.cmu.edu>
In-Reply-To: <9162.1559.XFAIDVZHQ1c=.1197907246.squirrel@webmailer.hosteurope.de>
References: <2666EB2A846BAC4BB2D7F593301A786801CDBC67@MUCXGC2.opentext.net> <183DD1B052A11A40B76125E42F1CBAAB102CA1A2@zcarhxm1.corp.nortel.com> <9162.1559.XFAIDVZHQ1c=.1197907246.squirrel@webmailer.hosteurope.de>
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-Spam-Score: 0.0 (/)
X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024
Cc: philippe.niger@francetelecom.com, sajassi@cisco.com, ietf@ietf.org, secdir@mit.edu, iesg@ietf.org, sdelord@uecomm.com.au, jhutz@cmu.edu
Subject: Re: [secdir] Review of draft-ietf-l2vpn-oam-req-frmk-09
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Errors-To: ietf-bounces@ietf.org
--On Monday, December 17, 2007 05:00:46 PM +0100 Tobias Gondrom <tobias.gondrom@gondrom.org> wrote: >> DM>> Please note that the document explicitly states the requirements >> which are called out as Rxx. There requirements are meant to be coherent >> with RFC-2119 language and these are indeed covered as such. The text >> prior to the individual requirements is meant to provide context, >> justification as to why the requirement is needed. Therefore the authors >> feel that no changes are needed since the requirements' text is coherent >> with RFC-2119. Please let us know if this satisfies your comment. > > Hm, an interesting point of view on RFC-2119-usage. > I can agree with your explanation as all important information is covered > in RFC-2119 language and only redundant statements were made in > non-RFC-2119. > > Personal note: my fear was that the fact of two equivalent statements in > the text (one time in RFC-2119 (in the Rxx) and one not using RFC-2119 > might lead to confusion in the interpretation. Especially as the > explanaition you just gave in this email may not be obvious from the text > of the draft. > (e.g. I misread this as well.) However, this is only a minor disagreement > and so does not absolutely need mitigation. While I think a better job could be done of pointing this out (for example, in the introduction, or even under "Conventions Used in This Document"), it seems clear enough that this document consists of both normative text (the numbered requirements) and non-normative text (the explanatory text associated with each requirement, as well as whole sections of explanatory text). In such situations, it seems appropriate for the normative text to use RFC2119 requirements language while the non-normative text, which by its nature does not contain requirements, to avoid RFC2119 language. Note that personally, my preference is for documents which refer to RFC2119 to use the words "must", "shall", "should", "may", "required", and "recommended" _only_ when the RFC2119 sense is intended, and to use different wording in other situations to avoid confusion. However, not everyone shares this opinion, and in some cases alternate wording is awkward enough to be worse than the potential confusion. >> 5. Question: as the draft is heavily based on RFC4664 and 4665, I wonder >> whether they should not better be normative references instead of >> informative ones? >> >> DM>> The authors are open to moving the two references to normative >> section, however, the rationale had been that both 4664 and 4665 are >> informational therefore could well be in either of the two locations. >> Please let us know if you feel strongly about this editorial change in >> this document. > > I do not feel strongly about this. This was just a suggestion, which I > would have also given as advice to authors in my own WG as well. Please bear in mind that the fact that a referenced document has status "Informational" (which has to do with its (lack of) standards status) does not mean that a reference to such a document is not normative. A normative reference is one which affects the meaning of the document, or at least of its normative parts, such that if the content of the normative reference changed, it would change the meaning of your specification. This determination is (or should be) an objective one, not a matter of opinion. For example, if the requirements you specify use terms that are described in a referenced document, that reference is normative. The same applies if you import whole requirements by reference. If you have a protocol specification which uses MD5 (don't do that) and refers to RFC1321 for its definition, then that reference is normative even though RFC1321 is an informational document. On the other hand, if you refer to a document in a way that does not affect your specification (for example, "see RFC4459 for an explanation of why implementations of this protocol MUST NOT send larger-than-MTU packets"), then the reference is non-normative. In the present case, I haven't examined the reference in question and am not making an argument for either answer. I _am_ making an argument for the authors and/or chairs to examine the way in which the reference is used and place it into the appropriate section. -- Jeff _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
- RE: [secdir] Review of draft-ietf-l2vpn-oam-req-f… Tobias Gondrom
- RE: [secdir] Review of draft-ietf-l2vpn-oam-req-f… Dinesh Mohan
- RE: [secdir] Review of draft-ietf-l2vpn-oam-req-f… Tobias Gondrom
- RE: [secdir] Review of draft-ietf-l2vpn-oam-req-f… Dinesh Mohan
- RE: [secdir] Review of draft-ietf-l2vpn-oam-req-f… Tobias Gondrom
- Re: [secdir] Review of draft-ietf-l2vpn-oam-req-f… Jeffrey Hutzelman
- [secdir] Review of draft-ietf-l2vpn-oam-req-frmk-… Tobias Gondrom