RE: LC summary for draft-ietf-opsawg-operations-and-management
-Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On 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. Just to clarify - there is an OPS-Dir review process in place now for Internet-Drafts as well, but no requirement for a mandatory operations and management considerations section. Dan ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: LC summary for draft-ietf-opsawg-operations-and-management
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
Re: LC summary for draft-ietf-opsawg-operations-and-management
+1 Tom Petch - Original Message - From: SM s...@resistor.net To: David Harrington ietf...@comcast.net; IETF Discussion ietf@ietf.org Cc: Romascanu, Dan (Dan) droma...@avaya.com; ops...@ietf.org Sent: Thursday, June 25, 2009 12:35 AM Subject: Re: LC summary for draft-ietf-opsawg-operations-and-management Hi David, At 13:51 23-06-2009, David Harrington wrote: 3) Bernard Aboba concerned that IETF should focus on making successful protocols, and Management Considerations may be an unnecessary requirement. [dbh: this document went to great lengths to say that it was NOT prescribing a Management Considerations requirement. sigh] The problem is not about what your document is not prescribing. It is about how it may be used. In Section 1: This document provides guidelines to help protocol designers and working groups consider the operations and management functionality for their new IETF protocol or protocol extension at an earlier phase. 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 Section 1.3: The IESG policy to require working groups to write a MIB module to provide manageability for new protocols is being replaced by a policy that is more open to using a variety of management protocols and data models designed to achieve different goals. The insistence on BCP could be seen as a way to set the stage for that. At 13:40 24-06-2009, Eric Rosen wrote: Since assigning responsibilities to the IESG is presumably out of scope of this document, why not shorten this sentence to: This document avoids recommending any mandatory publication requirements I suggest a slight change to the proposed sentence: This document does not recommend any mandatory publication requirements I also suggest publishing the document as Informational. Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: LC summary for draft-ietf-opsawg-operations-and-management
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@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: LC summary for draft-ietf-opsawg-operations-and-management
Looking through your summary of the LC comments, it appears that there is considerable sentiment to publish this document as Informational rather than as a BCP. Yet the new revision still says Intended Status: BCP. [dbh: this document went to great lengths to say that it was NOT prescribing a Management Considerations requirement. sigh] If this document were to proceed as a BCP, the following text could be interpreted by an AD as license to require a Management Considerations section: 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. Since assigning responsibilities to the IESG is presumably out of scope of this document, why not shorten this sentence to: This document avoids recommending any mandatory publication requirements ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: LC summary for draft-ietf-opsawg-operations-and-management
Hi David, At 13:51 23-06-2009, David Harrington wrote: 3) Bernard Aboba concerned that IETF should focus on making successful protocols, and Management Considerations may be an unnecessary requirement. [dbh: this document went to great lengths to say that it was NOT prescribing a Management Considerations requirement. sigh] The problem is not about what your document is not prescribing. It is about how it may be used. In Section 1: This document provides guidelines to help protocol designers and working groups consider the operations and management functionality for their new IETF protocol or protocol extension at an earlier phase. 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 Section 1.3: The IESG policy to require working groups to write a MIB module to provide manageability for new protocols is being replaced by a policy that is more open to using a variety of management protocols and data models designed to achieve different goals. The insistence on BCP could be seen as a way to set the stage for that. At 13:40 24-06-2009, Eric Rosen wrote: Since assigning responsibilities to the IESG is presumably out of scope of this document, why not shorten this sentence to: This document avoids recommending any mandatory publication requirements I suggest a slight change to the proposed sentence: This document does not recommend any mandatory publication requirements I also suggest publishing the document as Informational. Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
