The IESG has approved the following document: - 'Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions ' <draft-ietf-opsawg-operations-and-management-09.txt> as an Informational RFC This document is the product of the Operations and Management Area Working Group. The IESG contact persons are Dan Romascanu and Ron Bonica. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-opsawg-operations-and-management-09.txt Technical Summary New protocols or protocol extensions are best designed with due consideration of functionality needed to operate and manage the protocols. Retrofitting operations and management is sub-optimal. The purpose of this document is to provide guidance to authors and reviewers of documents defining new protocols or protocol extensions, about covering aspects of operations and management that should be considered. Working Group Summary There was consensus in the working group to publish this document. Document Quality The document was reviewed by a number of experts with operational and management experience. An IETF Last Call was run and comments received during the Last Call were incorporated in the final version. Personnel Scott Bradner is the Document Shepherd for this document. Dan Romascanu is the Responsible Area Director. RFC Editor Note 1. In Section 1.2: OLD: This document discusses the importance of considering operations and management by setting forth a list of guidelines and a checklist of questions to consider, NEW: This document discusses the importance of considering operations and management by setting forth a list of guidelines and a checklist of questions to consider (see Appendix A), 2. In Section 7 s/Adrian Farrell/Adrian Farrel/ 3. In Section 1.6: OLD: This document is a set of guidelines based on current practices of protocol designers and operators. This document does not describe requirements, so the key words from RFC2119 have no place here. NEW: This informational document is a set of guidelines based on current practices of **some** protocol designers and operators. This document is biased toward router operations and management and some advice may not be directly applicable to protocols with a different purpose, such as application server protocols. This document **does not** describe interoperability requirements, so the capitalized key words from RFC2119 do not apply here. 4. Add in Section 4: This document does not describe interoperability requirements, but rather describes practices that are useful to be followed in dealing with manageability aspects in the IETF documents, so the capitalized keywords from RFC2119 do not apply here. Any occurrence of words like 'must' or 'should' needs to be interpreted only in the context of their natural English language meaning. 5. In section 1.5: OLD: SNMP [RFC3410], SYSLOG [RFC5424], RADIUS [RFC2865], DIAMETER [RFC3588], NETCONF [RFC4741], IPFIX [RFC5101]. NEW: Simple Network Management Protocol - SNMP [RFC3410], SYSLOG [RFC5424], Remote Authentication Dial In User Service - RADIUS [RFC2865], DIAMETER [RFC3588], Network Configuration Protocol - NETCONF [RFC4741], IP Flow Information Export - IPFIX [RFC5101]. 6. in Section 1.4 OLD: One issue discussed was the user-unfriendliness of the binary format of SNMP [RFC3410] and COPS Usage for Policy Provisioning (COPS-PR) [RFC3084], and it was recommended that the IETF explore an XML-based Structure of Management Information, and an XML-based protocol for configuration. NEW: One issue discussed was the user-unfriendliness of the binary format of SNMP [RFC3410] and Common Open Policy Service (COPS) Usage for Policy Provisioning (COPS-PR)[RFC3084], and it was recommended that the IETF explore an XML-based Structure of Management Information, and an XML-based protocol for configuration. 7. in Section 3.1: OLD: Other Standard Development Organizations (e.g. DMTF, TMF) NEW: Other Standard Development Organizations (e.g. the Distributed Management Task Force - DMTF, the Tele-Management Forum - TMF) 8. In Section 3.3.2: OLD: Would some threshold-based mechanisms, such as RMON events/alarms or the EVENT-MIB, be useable to help determine error conditions? NEW: Would some threshold-based mechanisms, such as Remote Monitoring (RMON) events/alarms or the EVENT-MIB, be useable to help determine error conditions? 9. In Section 3.4: OLD: There are two parts to this: 1. An NMS system could optimize access control lists (ACLs) for performance reasons NEW: There are two parts to this: 1. A Network Management System (NMS) could optimize access control lists (ACLs) for performance reasons _______________________________________________ IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
