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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]