Hi Dave,
I'll mention that my previous message was to explain to the author of
the draft my point of view. Some of the content of this message is
not directed at you.
At 08:16 27-06-2009, Dave CROCKER wrote:
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
I agree with the basics of what you said.
Most of the references in the ID-Checklist are BCPs. For example,
Security Considerations are covered in BCP 72 and IANA Considerations
in BCP 26. There's also BCP 32 which has been used in arguments
about an unrelated Internet-Draft.
There isn't anything explicitly written in the draft that prescribes
a Management Considerations requirement. One of the comments on the
Last-Call mentioned that "Section 1 provides a potential
justification for imposing such a requirement". This draft does not
target Operations and Management Area WG documents only. The target
is documents from all areas. The question the different areas could
answer is whether it is current practice to have management
interoperability as part of interoperability.
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 consensus process here is on a document with BCP as the intended status.
I'll read your question as what is the purpose of having a consensus
process for a document with Informational status. I think that even
those documents do seek to alter behavior directly or
indirectly. The purpose of a consensus process is that it can
facilitate conflict resolution.
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...
On the whole, I agree with you there.
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.
There is currently a Secdir review for Internet-Drafts. If
operations and management considerations are included, the documents
will need an Opsdir review and a mandatory Management Considerations section.
Regards,
-sm
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
