Suppose there is a problem here that needs solving, i.e., that
this document is not just part of some external agenda about
which the IETF has not been informed (given the normative
reference to RFC 2860, I can imagine it might be). Then I
suggest that...
There are real requirements that we need to have people follow
to ensure interoperability. It is possible that some of those
requirements, like the requirement to maintain, really are
generic although I argued in my prior note that the maintenance
one would likely reduce the number of implementations,
especially reference implementations, resulting in some harm and
little if any gains. Others, including whatever is said in
Applicability Statements and BCPs that are based on consensus of
actual experience and practice, are much more document-specific.
If such requirements apply to a given technical specification,
then an offspring of this document should be created, given
normative status as a BCP or, preferably, as a generic
Applicability Statement, and then a normative reference to it
should be incorporated into the RFC boilerplate or 2119-like
language for technical specifications and other relevant
documents. That would solve the problem of how implementers and
others are supposed to find this sort of statement.
For particular specifications, this document indirectly opens up
some longstanding (and interrelated) problems, e.g.,:
(i) When a standard (with or without an STD number) consists of
multiple technical specifications, maybe an applicability
statement or two (which may precede some of the technical
specs), and maybe one or more BCPs, what actually is the
standard? What extensions are considered mandatory, which ones
optional, and, since we aren't consistent about deprecating old
cruft, which ones have quietly become Not Recommended. [1]
(ii) What, actually, is a conformance clause in our world? RFC
2119 says that both SHOULD and MUST are used to describe things
that are important for interoperability. The present document
adds a lot of generic requirements that are claimed to be
important for interoperability. Other comments have identified
the importance to some protocols of a doctrine of "fail early"
to improve robustness against, e.g., careless implementations
even if the relevant provisions are not strictly needed for
interoperability. Some of the normative language in RFCs 1122
and 1123 is consistent with that model, 2119's definitions
probably are not. And this draft essentially makes all BCPs
that have impact on a particular technical spec mandatory to
implement/support. My sense is that many BCPs, including some
that are about operations rather than implementation, have been
approved with no community intent that they be considered
mandatory and that, had that been the intent, the consensus (or
at least the level of scrutiny) would have been much different.
If we intend to make support of a BCP associated with a given
technical spec mandatory, it should, IMO, be done on a
case-by-case rough consensus basis, not as a side effect of a
document that appears to promote all relevant BCPs to mandatory
status [2].
The IETF has had many discussions about how to solve the above
problems, several of which would also provide authoritative
forward reference from earlier specs to later changes, advice,
and description.
One is represented exactly by RFC 1122 and 1123: publication of
Applicability Statements that draw the pieces of a conceptual
standard together and bind it to implementation and operational
advice.
A second (extended a bit from the last discussion I remember)
would have us use STD numbers more broadly and aggressively,
assigning them when (or before) Proposed Standards are approved
and using them to group supplemental documents, including
appropriate BCPs and Informational implementation reports, as
well as the technical specs themselves. [3]
THe third is to create new documents that actually describe what
is in a standard and what the associated implementation and
operational advice or norms are as appropriate. Such a document
could also serve as a sort of AS because it could identify the
difference between mandatory, recommended, and optional
specification components as thinking about those evolved [4].
The IESG has declined to consider any of those ideas, at last in
part because all of them would involve additional work. But I
think that the problems that presumably led to the current draft
make that work important enough that we should find the
resources to do something along those lines. If the problems
are not important enough to justify the effort to do things at
least reasonably well, then I suggest that they aren't important
enough to justify publishing a generic document that is unlikely
to be seen by a large fraction of its most important audience
and that is likely to have bad side-effects.
best,
john
[1] I note in passing that the new IESG practice of documenting
decisions to move a technical specification to Historic may
require that the sort of document search the present (-02) draft
implies needs to extend, not just to the BCP Index, but to the
RFC Index/Database and the whole history of IESG actions on
Historic and, in many cases, updated or obsoleted, documents.
[2] This also raises interesting questions when a document is
proposed as a BCP whose associated technical specifications are
not IETF-stream documents that are appropriate for normative
references and over which IETF has change control.
[3] See draft-klensin-std-numbers and draft-otis-newtrk-rfc-set
for very different takes on this.
[4] This idea was developed by a WG in
draft-ietf-newtrk-repurposing-isd although a contemporary
version of the ideas would undoubtedly be different.