SM wrote:
In an Informational document, guidelines provide guidance. In a BCP
document, it can be read as "the IETF community agrees to adopt these
guidelines". In Section 1.2:
"This document does not impose a solution, or imply that a formal data
model is needed, or imply that using a specific management protocol
is mandatory."
The catch is in the following sentence:
"Any decision to make a Management Considerations section a mandatory
publication requirement for IETF documents is the responsibility of
the IESG, or specific area directors, or working groups, and this
document avoids recommending any mandatory publication requirements."
The IESG could come up with such a requirement for the IETF Stream if
this document is published as a BCP.
In practical terms, the IESG could come up with that requirement whether this
document is BCP or not. Language such as you quoted does not "enable" an IESG
action; it merely reminds the reader where a particular authority rests. So the
concern you raise is a non-sequitor.
More importantly, what is the purpose of having a consensus process for a
document that has no status reflecting a consensus, particularly when that
document seeks to alter behavior?
The term guidance means giving direction. That's not merely informative. It
is, by definition, directive. The IETF's labels for documents that are
directive are standards track and BCP.
Normative labels (stds trk & bcp) are particularly helpful when the community
needs to adjust its sense of priorities, to do things it probably should have
doing all along, but hasn't. The danger of a normative label, for non-protocol
documents, is that they can be taken as casting things into Procrustean
concrete. This draft has language that is reasonable cautious of such
over-application, although this does require the reader to pay attention to the
words that are actually written in the document...
If the job of this document were merely to provide a reference about some
issues, Informational would make sense. But it has a more directive intent than
that. It seeks to get specification writers to include considerations and
material that has been notably lacking in IETF development work.
That's not merely informational. It is, by definition, stating a really good --
probably even a Best -- current practice for developing specifications.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf