Network Working Group J. Peterson
Internet-Draft NeuStar
Intended status: Best Current June 2007
Practice
Expires: December 3, 2007
Normative Language and References
draft-peterson-informational-normativity-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 3, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document clarifies the definition of normative language, the
manner in which normative language should be used in Informational
documents, and the conditions under which a normative dependency
exists.
Peterson Expires December 3, 2007 [Page 1]
Internet-Draft Normativity June 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. What is 'normative'? . . . . . . . . . . . . . . . . . . . . . 4
3. Normative references . . . . . . . . . . . . . . . . . . . . . 5
4. Normative Language off the (Standards) Track . . . . . . . . . 6
4.1. Informational Publication of Protocols . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. Informational References . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . . . 10
Peterson Expires December 3, 2007 [Page 2]
Internet-Draft Normativity June 2007
1. Introduction
RFC2119 [1] provides a set of familiar directives to readers of IETF
specifications, specifically the imperatives: "MUST", "MUST NOT",
"REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "MAY", and "OPTIONAL". This set of normative
keywords, as they shall be known in this document, consists of a
number of grammatical variations which ultimately describe three
degrees of normative compliance: required, recommended, and elective.
The first two degrees may be used in either prescriptive or
proscriptive contexts (e.g. "MUST" and "MUST NOT", "SHOULD" and
"SHOULD NOT"), while for the third prescriptive statements only are
permitted (there is a "MAY" but no "MAY NOT", something can be
"OPTIONAL", but not "NOT OPTIONAL").
The use of normative keywords is one of the defining characteristics
of IETF specifications. Normative keywords remain an indispensable
tool for evaluating interoperability as specifications advance on the
standards track, and moreover for pruning unimplemented features as
protocols mature through deployment and usage. The application of
normative keywords to these functions is predicated largely on the
text of RFC2026 [2].
RFC2119 does not, however, contain the word 'normative', and nor does
RFC2026. The idea that a statement or reference can be 'normative'
or 'informational' (let alone the requirement that the References
section of an Internet-Draft be divided between the two) dates from a
much later time, as does the term 'normative language'. The
conditions that render a particular reference or statement
'normative' have never been specified; although there is a good
understanding in the community of the common distinctions, practices
can be very erratic in corner-cases.
An example of the resulting confusion is the use of normative
keywords in requirements documents, which here are to be understood
as Informational documents that apply constraints to future protocol
specification work, as opposed to implementation work. Authors of
standards-track protocol specifications intended to satisfy these
requirements sometimes include such requirements documents in the
"Normative References" section of their document, precisely because
they are referring to statements containing normative keywords. This
sort of downward reference is of course formally prohibited in
RFC2026, and thus must corrected, but the whole situation arises
needlessly. In the absence of some clarification, similar
misconceptions will continue to arise.
RFC3967 [3] and more recently RFC4897 [4] have revised the guidance
of RFC2026 regarding the advancement of standards-track documents
Peterson Expires December 3, 2007 [Page 3]
Internet-Draft Normativity June 2007
which refer to documents at a lower maturity level (or those not on
the standards track at all). The present document is entirely
compatible with the useful amendments introduced in those documents.
2. What is 'normative'?
Normative keywords are 'normative' in so far as they establish the
norms that are the foundation of interoperability. Implementations
of a particular specification can be considered to be a sort of
community, and that community has practices that are required and
prohibited, recommended and counterrecommended, or simply elective -
hence, they are norms.
'Normative language' or 'normative statements' are, broadly, passages
of text in IETF documents which contain normative keywords that
direct implementers, with varying degrees of stringency, to
incorporate particular features in order to assure interoperability.
Normative language, as originally described in RFC2119, is tooled
solely to describe how implementations are intended to behave. As
RFC2119 Section 6 states, in reference to normative keywords:
In particular, they MUST only be used where it is
actually required for interoperation or to limit behavior which has
potential for causing harm (e.g., limiting retransmissions)
Ironically, this normative statement is not internally consistent.
It urges authors of specifications to use normative keywords only in
reference to matters of implementation, but in order to amplify its
point from mere urging to absolute dictum, it relies on a normative
keyword. Therein lies the source of the confusion. Normative
keywords are used commonly, but incorrectly, in precisely this
fashion: for emphasis, in passages of descriptive text that in no way
could be construed to address implementations.
When authors of subsequent specifications see such normative keywords
used in an purely descriptive passage in an RFC, they may assume that
the document containing those normative keywords should be referenced
normatively. This can cause an unnecessary apparent need for a
downward reference.
Considering the flip side of the issue, passages that do not contain
normative keywords cannot be termed normative. Any statement that is
non-normative is by definition purely informational. Informational
or descriptive statements play a large role in IETF documents,
providing contextual information that is useful to implementers or
authors of future specifications but which does not, strictly
Peterson Expires December 3, 2007 [Page 4]
Internet-Draft Normativity June 2007
speaking, detail implementation behavior that will subsequently be
measured for compliance.
3. Normative references
This document follows the terminology of RFC4897 for a 'source
document' (a document in which the reference to another document in
embedded) and a 'target document' (the document so referenced). It
furthermore defines the 'referencing statement' as the statement in
the source document which invokes the reference to the target
document.
A reference to a document can be normative only if:
The source document is itself a standards-track document, BCP or
an Experimental document.
The reference statement contains one or more normative keywords
which predicate any degree of compliance upon the target document.
The target document, and in particular any subset scope designated
by the referencing statement (a section, or what have you),
contains normative keywords.
If any of the above conditions do not apply, then the reference in
question is non-normative. One additional possible condition, that
the target document have an equal or greater standards maturity level
to the source document, is not strictly speaking a necessary
condition for a normative reference; however, normative references
made when this condition prevails must successfully invoke the
downref exception procedures defined in RFC3976 in order to advance
on the IETF standards-track.
While this definition is logically sound, human language is capable
of many feats that defy logic, and which must be considered in the
review of IETF documents. Consider the following:
The citation of TLS above is merely exemplary; the referencing
statement does not actually require application developers to
implement TLS. Rather, it requires that any underlying transport
that is implemented have certain properties, though not terribly
specific ones. As such, this statement cannot be considered
normative - it suggests no norm to the implementation community.
Precisely for this reason, it is an example of poor specmanship.
Statements of this general form often seem attractive, however, to
specification authors who hope to reference work-in-progress or
Informational documents. The fix for this sort of specmanship is not
to require TLS to appear in the Normative references section of the
document, but rather to encourage the authors to make a stronger
reference statement, one actually conducive to establishing
Peterson Expires December 3, 2007 [Page 5]
Internet-Draft Normativity June 2007
implementation norms.
Another similar example is the use of disjunctive references like the
following:
Is this a normative reference to both SASL and (the fictitious) MB7?
It seems to read that implementers would only need to implement one
in order to be compliant, so perhaps only one of them is actually a
normative reference... but if so, which one? Again, a specmanship
issue.
A final source of ambiguity in determining whether or not a reference
is normative is the status of Best Current Practices (BCPs, as
defined in Section 5 of RFC2026). The BCP designation is a bit of a
catch-all in the IETF standards process. A BCP can prescribe
practices varying from operations, which are indeed critical to the
interoperability of the Internet, to IETF process, which is of a non-
technical nature. As such, it is entirely appropriate, in some
cases, to provide a normative reference to a BCP, and for a BCP to
contain normative keywords. In the case of IETF process documents,
it is less clear that they should be understood normatively, and
moreover less clear that it is appropriate for process documents to
employ normative keywords. When process documents do employ
normative keywords, as RFC2119 does in the citation above, it is
almost always inconsistent with the definition of those terms in
RFC2119 and their intended use in RFC2026. This in turn further
contributes to the perception that it is appropriate for non-
technical documents in general (such as requirements documents) to
employ normative keywords. Unfortunately, this appropriateness of
using normative language in BCPs must be assessed on a case-by-case
basis.
At least the negative test for normativity is straightforward. By
definition, all references that are not normative are informational.
4. Normative Language off the (Standards) Track
Despite the text of RFC2119, it is commonplace for normative keywords
to appear in Informational requirements documents today, in
statements that are intended to constrain the authoring of future
specifications. The laudable intent of requirements documents is of
course to establish consensus on the needs of the implementation
community prior to the evaluation of candidate protocols that might
satisfy these needs. The requirements document becomes a measuring
stick of the 'compliance' of a candidate protocol.
Undoubtedly some confusion arises from an accident of the language in
Peterson Expires December 3, 2007 [Page 6]
Internet-Draft Normativity June 2007
RFC2119. The Abstract of 2119 says that the normative keywords are
"are used to signify the requirements in the specification", which
could be read to suggest that Informational requirements that will be
used to constrain further protocol specifications should use
normative keywords. In fact, that interpretation clearly contradicts
the previously-cited dictum that normative keywords are to be used
only when required for "interoperation or to limit [implementation]
behavior."
Were we to grant that normative keywords apply to protocol
requirements by analogy, the interpretation of normative keywords in
this context would remain problematic. How are we to understand the
"SHOULD" keyword for protocol requirements. What does it mean for a
protocol that satisfies a given set of protocol requirements to be
merely "conditionally compliant"?
Along these lines, it might seem compelling to imagine that the
selection of two protocols X and Y, which were invented to satisfy a
set of requirements A, might be decided by a single "SHOULD"
statement specified in A which is support by X but not Y. But of
course, if that "SHOULD" in A were instead a "MUST", the same
selection would be made. The true utility of a "SHOULD" emerges when
we instead consider two implementations, X and Y, which have been
implemented to specification A and are attempting to interoperate.
In this case, if Y fails to implement a "MUST", a very different
result can occur than if Y fails to implement a "SHOULD". In short,
the normative keywords are designed to encourage cooperation, not
decide competition. Using them in the latter context is a strained
analogy, and the resulting strain is communicated to the IETF's
standards process.
It is moreover critical to appreciate that the use of normative
keywords is tied to the functions of 2026: that is, the pruning of
unused features of a protocol specification. From the guidance in
4.1.2 (where we understand 'features' to be at the 'required' degree
of compliance, and 'options' to be at the 'recommended' or 'elective'
degrees of compliance):
The requirement for at least two independent and interoperable
implementations applies to all of the options and features of the
specification. In cases in which one or more options or features
have not been demonstrated in at least two interoperable
implementations, the specification may advance to the Draft Standard
level only if those options or features are removed.
Normative keywords exist to ensure interoperability, and practically
speaking a requirements document will never be interoperable with
anything.
Peterson Expires December 3, 2007 [Page 7]
Internet-Draft Normativity June 2007
More rarely, normative keywords appear in other sorts of
Informational documents, such as frameworks that describe high-level
or abstract architectures. In this context they are primarily used
for rhetorical emphasis. This practice can still lead authors of
future specifications to improper referencing.
Finally, it is also possible for an Informational document to
redefine normative keywords in lieu of any reference to RFC2119.
This practice only adds further misery to the confusion surrounding
the use of normative keywords, and should be avoided. If there is a
genuine need for terminology to characterize adherence to a set of
requirements in the context of specification authoring, those terms
should be clearly defined and explicitly distinguished, semantically
and syntactically, from the RFC2119 normative keywords. A similar
direction should be taken regarding the use of normative keywords in
process statements. Further consideration is left as a possible
subject for future study.
4.1. Informational Publication of Protocols
There are a variety of circumstances in which protocol specifications
are published as Informational RFCs. Sometimes authors request
Informational publication of protocol specifications which were
rejected as candidates in a working group process in order to
preserve an historical record. Parties who do not participate
directly in the IETF may similarly request publication of their
designs as an Informational RFC. Some exceptional IETF procedures,
for example the SIP change (RFC3427 [5]) process, may stipulate a
lower bar of review and Informational publication for certain
protocol work.
These Informational documents often contain normative keywords, as
their authors aspire to specify something that will yield
interoperable implementations. One need not anticipate, or even
understand, the eventual intended status of a document in order to
invoke RFC2119 and use the normative keywords therein. The
distinctions between such Informational documents and standards-track
documents lie more so in the implications about review and community
consensus which the standards-track entails than in any consideration
about formatting.
Because such documents exist, it is not reasonable to bar
Informational specifications from containing normative keywords.
Indeed, the downref exception procedures largely exist so that it is
possible to refer to such documents, under the proper conditions and
with the required oversight.
Instead, we should prevent the casual or inappropriate use of
Peterson Expires December 3, 2007 [Page 8]
Internet-Draft Normativity June 2007
normative keywords that to refer to matters other the proper
implementation of protocols.
5. IANA Considerations
This document contains no considerations for the IANA.
6. Security Considerations
This is a IETF process document which does not impact the security of
IETF protocols.
7. Informational References
[1] Bradner, S., "Key words for use in RFCs to indicate requirement
levels", RFC 2119, March 1997.
[2] Bradner, S., "The Internet Standards Process -- Revision 3",
RFC 2026, October 1996.
[3] Bush, R. and T. Narten, "Clarifying when Standards Track
Documents may Refer Normatively to Documents at a Lower Level",
RFC 3967, December 2004.
[4] Klensin, J. and S. Hartman, "Handling Normative References to
Standards-Track Documents", RFC 4897, June 2007.
[5] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., and B.
Rosen, "Change Process for the Session Initiation Protocol
(SIP)", RFC 3427, December 2002.
Author's Address
Jon Peterson
NeuStar, Inc.
1800 Sutter St
Suite 570
Concord, CA 94520
USA
Phone: +1 925/363-8720
Email: jon.peterson@neustar.biz
URI: http://www.neustar.biz/
Peterson Expires December 3, 2007 [Page 9]
Internet-Draft Normativity June 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Peterson Expires December 3, 2007 [Page 10]