Re: [secdir] Review of draft-ietf-l2vpn-oam-req-frmk-09

--On Monday, December 17, 2007 05:00:46 PM +0100 Tobias Gondrom 
<tobias(_dot_)gondrom(_at_)gondrom(_dot_)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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf