--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