idnits 2.17.1 draft-ietf-opsawg-survey-management-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2, 2009) is 5528 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'DISCUSS' is mentioned on line 152, but not defined == Missing Reference: 'TODO' is mentioned on line 693, but not defined == Unused Reference: 'RFC3444' is defined on line 877, but no explicit reference was found in the text == Unused Reference: 'RFC3585' is defined on line 890, but no explicit reference was found in the text == Unused Reference: 'RFC3644' is defined on line 903, but no explicit reference was found in the text == Unused Reference: 'RFC3670' is defined on line 911, but no explicit reference was found in the text == Unused Reference: 'RFC3805' is defined on line 920, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-opsawg-operations-and-management-05 == Outdated reference: A later version (-13) exists of draft-ietf-sipping-rtcp-summary-05 -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) -- Obsolete informational reference (is this intentional?): RFC 4133 (Obsoleted by RFC 6933) -- Obsolete informational reference (is this intentional?): RFC 4741 (Obsoleted by RFC 6241) -- Obsolete informational reference (is this intentional?): RFC 4930 (Obsoleted by RFC 5730) -- Obsolete informational reference (is this intentional?): RFC 5101 (Obsoleted by RFC 7011) Summary: 1 error (**), 0 flaws (~~), 12 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Harrington 3 Internet-Draft HuaweiSymantec 4 Intended status: Informational March 2, 2009 5 Expires: September 3, 2009 7 Survey of IETF Network Management Standards 8 draft-ietf-opsawg-survey-management-00 10 Status of This Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. This document may contain material 14 from IETF Documents or IETF Contributions published or made publicly 15 available before November 10, 2008. The person(s) controlling the 16 copyright in some of this material may not have granted the IETF 17 Trust the right to allow modifications of such material outside the 18 IETF Standards Process. Without obtaining an adequate license from 19 the person(s) controlling the copyright in such materials, this 20 document may not be modified outside the IETF Standards Process, and 21 derivative works of it may not be created outside the IETF Standards 22 Process, except to format it for publication as an RFC or to 23 translate it into languages other than English. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on September 3, 2009. 43 Copyright Notice 45 Copyright (c) 2009 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents in effect on the date of 50 publication of this document (http://trustee.ietf.org/license-info). 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. 54 Abstract 56 This document provides a survey of existing IETF standards-track 57 network management protocols and data models. The purpose of this 58 document is to help protocol designers, implementers, and users to 59 select appropriate standard management protocols and data models to 60 address relevant management needs. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2.1. SNMP . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2.2. SYSLOG . . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 2.3. IPFIX . . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 2.4. PSAMP . . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 2.5. NETCONF . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 2.6. COPS-PR . . . . . . . . . . . . . . . . . . . . . . . . . 7 73 2.7. RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 2.8. Diameter . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 2.9. EPP . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 2.10. VCCV . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 77 2.11. ACAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 78 2.12. XCAP . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 79 3. Draft and Standard Level Data Models . . . . . . . . . . . . . 10 80 3.1. Fault Management . . . . . . . . . . . . . . . . . . . . . 11 81 3.2. Configuration Management . . . . . . . . . . . . . . . . . 11 82 3.3. Accounting Management . . . . . . . . . . . . . . . . . . 12 83 3.4. Performance Management . . . . . . . . . . . . . . . . . . 12 84 3.5. Security Management . . . . . . . . . . . . . . . . . . . 13 85 4. Proposed Standard Data Models . . . . . . . . . . . . . . . . 13 86 4.1. Fault Management . . . . . . . . . . . . . . . . . . . . . 13 87 4.2. Configuration Management . . . . . . . . . . . . . . . . . 14 88 4.3. Accounting Management . . . . . . . . . . . . . . . . . . 15 89 4.4. Performance Management . . . . . . . . . . . . . . . . . . 15 90 4.5. Security Management . . . . . . . . . . . . . . . . . . . 15 91 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 92 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 93 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 94 8. Informative References . . . . . . . . . . . . . . . . . . . . 16 95 Appendix A. Open Issues . . . . . . . . . . . . . . . . . . . . . 21 96 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 21 98 1. Introduction 100 This document provides a survey of existing IETF standards-track 101 network management protocols and data models. The purpose of this 102 document is to help protocol designers, implementers, and users to 103 select appropriate standard management protocols and data models to 104 address relevant management needs. 106 Guidelines for Considering Operations and Management of New Protocols 107 and Extensions [I-D.ietf-opsawg-operations-and-management] recommends 108 working groups consider operations and management needs, and then 109 select appropriate management protocols and data models. This 110 document is designed to ease this process by surveying the IETF 111 standards-track network management protocols and management data 112 models available at the time of this document's publication. 114 Section 2 discusses IETF standards-track management protocols and 115 their uses. Section 3 discusses Draft and Full Standard data models, 116 such as MIB modules, that have been designed to address specific sets 117 of issues.Section 4 describes Proposed Standard management data 118 models that have been designed to address specific sets of issues. 120 1.1. Terminology 122 This document deliberately does not use the (capitalized) key words 123 described in RFC 2119 [RFC2119]. RFC 2119 states the keywords must 124 only be used where it is actually required for interoperation or to 125 limit behavior which has potential for causing harm (e.g., limiting 126 retransmissions). For example, they must not be used to try to 127 impose a particular method on implementers where the method is not 128 required for interoperability. This document is a survey of existing 129 IETF network management technologies. This document does not 130 describe requirements, so the key words from RFC2119 have no place 131 here. 133 CLI: Command Line Interface 135 Data model: A mapping of the contents of an information model into 136 a form that is specific to a particular type of data store or 137 repository. 139 Information model: An abstraction and representation of the 140 entities in a managed environment, their properties, attributes 141 and operations, and the way that they relate to each other. It is 142 independent of any specific repository, software usage, protocol, 143 or platform. 145 o [DISCUSS] markers indicate a lack of consensus on what should be 146 written. 148 o [TODO] markers indicate the editor has a reasonable understanding 149 of what needs to be (re-)written. Contributions of text would be 150 welcome. 152 o Note to RFC Editor - All [DISCUSS] or [TODO] marks should be 153 resolved before RFC publication. If any still exist, including in 154 the Terminology section, then please return the document to the 155 editor for resolution. 157 2. Protocols 159 This Section reviews which protocols the IETF has to offer for 160 management and discusses for which applications they were designed 161 and/or already successfully deployed. These are protocols that have 162 reached Proposed Standard status or higher within the IETF. 163 [DISCUSS: Juergen: I like to perhaps see even stronger guidelines] 165 The Overview of the 2002 IAB Network Management Workshop [RFC3535] 166 documented strengths and weaknesses of some IETF management 167 protocols. In choosing existing protocol solutions to meet the 168 management requirements, it is recommended that these strengths and 169 weaknesses be considered. Some of the recommendations from the 2002 170 IAB workshop have become outdated, some have been standardized, and 171 some are being worked on in the IETF. 173 Some Area Directors have formed directorates composed of experienced 174 members of the IETF and the technical community. The details of the 175 role for each group differ from area to area, but the primary intent 176 is that these groups assist the Area Director(s) with the review of 177 specifications, and serve as technical advisors when needed. At the 178 time of this writing, the OPS Area has directorates focused on 179 Address Management, Operations, DNS, and MIB modules. Other areas 180 have directorates that might apply as well. Protocol designers 181 should consider asking for help from the IETF directorates 182 knowledgeable in available existing solutions. 184 2.1. SNMP 186 SNMP is widely used for monitoring fault and performance data. Some 187 operators use SNMP for configuration in various environments/ 188 technologies while others find SNMP an inappropriate choice for 189 configuration in their environments. 191 SNMPv1 [RFC1157] is a Full Standard that the IETF has declared 192 Historic and it is NOT RECOMMENDED due to its lack of security 193 features. SNMPv2c [RFC1901] is an Experimental specification (not a 194 standard of any kind) that the IETF has declared Historic and it is 195 NOT RECOMMENDED due to its lack of security features. SNMPv3 is a 196 Full Standard that is RECOMMENDED due to its security features, 197 including support for authentication, encryption, timeliness and 198 integrity checking, and fine-grained data access controls. An 199 overview of the SNMPv3 document set is in [RFC3410]. 201 SNMP utilizes the Management Information Base, a virtual information 202 store of modules of managed objects. MIB module support is uneven 203 across vendors, and even within devices. The lack of standard MIB 204 module support for all functionality in a device forces operators to 205 use other protocols such as a command line interface (CLI) to do 206 configuration of some aspects of their managed devices. Many 207 operators have found it easier to use one protocol for all 208 configuration than to split the task across multiple protocols. 210 SNMP is good at determining the operational state of specific 211 functionality, but not necessarily for the complete operational state 212 of a managed device. 214 SNMP is good for statistics gathering for specific functionality. 215 The wide-spread use of counters in standard MIB modules permits the 216 interoperable comparison of statistics across devices from different 217 vendors. Counters have been especially useful in monitoring bytes 218 and packets going in and out over various protocol interfaces. SNMP 219 is often used to poll a device for sysUpTime, which serves to report 220 the time since the last reinitialization of the device, to check for 221 operational liveness, and to detect discontinuities in some counters. 223 SNMP traps and informs can alert an operator or an application when 224 some aspect of a protocol fails or encounters an error condition, and 225 the contents of a notification can be used to guide subsequent SNMP 226 polling to gather additional information about an event. 228 Standards exist to use SNMP over multiple network protocols, 229 including UDP, Ethernet, Appletalk, OSI, and others.. 231 2.2. SYSLOG 233 The SYSLOG protocol [I-D.ietf-syslog-protocol] allows a machine to 234 send system log messages across networks to event message collectors. 235 The protocol is simply designed to transport these event messages. 236 No acknowledgement of the receipt is made. One of the fundamental 237 tenets of the SYSLOG protocol and process is its simplicity. No 238 stringent coordination is required between the transmitters and the 239 receivers. Indeed, the transmission of SYSLOG messages may be 240 started on a device without a receiver being configured, or even 241 actually physically present. Conversely, many devices will most 242 likely be able to receive messages without explicit configuration or 243 definitions. This simplicity has greatly aided the acceptance and 244 deployment of SYSLOG. 246 Since each process, application and operating system was written 247 somewhat independently, there has been little uniformity to the 248 message format or content of SYSLOG messages. 250 The IETF has developed a new Proposed Standard version of the 251 protocol that allows the use of any number of transport protocols 252 including reliable transports and secure transports. The IETF has 253 also standardized the application of message security for SYSLOG 254 messages using TLS, and has defined a mechanism to digitally sign log 255 data to ensure its integrity as log data is moved across the network 256 and/or copied to different data stores. 258 The IETF has standardized a new message header format, including 259 timestamp, hostname, application, and message ID, to improve 260 filtering, interoperability and correlation between compliant 261 implementations. 263 SYSLOG message content has traditionally been unstructured natural 264 language text. This content is human-friendly, but difficult for 265 applications to parse and correlate across vendors, or correlate with 266 other event reporting such as SNMP traps. The IETF syslog protocol 267 includes structured data elements to aid application-parsing. The 268 structured data element design allows vendors to define their own 269 structured data elements to supplement standardized elements. 271 The IETF has standardized MIB Textual-Conventions for facility and 272 severity labels and codes to encourage consistency between syslog and 273 MIB representations of these event properties. 275 IETF working groups are encouraged to standardize structured data 276 elements, extensible human-friendly text, and consistent facility/ 277 severity values for SYSLOG to report events specific to their 278 protocol. 280 2.3. IPFIX 282 There are several applications such as usage-based accounting, 283 traffic profiling, traffic engineering, intrusion detection, and QoS 284 monitoring, that require flow-based traffic measurements. 286 IPFIX [RFC5101] is a Proposed Standard approach for transmitting IP 287 traffic flow information over the network from an exporting process 288 to an information collecting process. 290 IPFIX defines a common representation of flow data and a standard 291 means of communicating the data over a number of transport protocols. 293 2.4. PSAMP 295 Several applications require sampling packets from specific data 296 flows, or across multiple data flows, and reporting information about 297 the packets. Measurement-based network management is a prime 298 example. The PSAMP standard includes support for packet sampling in 299 IPv4, IPv6, and MPLS-based networks. 301 PSAMP standardizes sampling, selection, metering, and reporting 302 strategies for different purposes. 304 To simplify the solution, the IPFIX protocol is used for exporting 305 the reports to collector applications. 307 [TODO: this is in IESG review to become a PS. update as needed] 309 2.5. NETCONF 311 The NETCONF protocol [RFC4741] is a Proposed Standard that provides 312 mechanisms to install, manipulate, and delete the configuration of 313 network devices. It uses an Extensible Markup Language (XML)-based 314 data encoding for the configuration data as well as the protocol 315 messages. The NETCONF protocol operations are realized on top of a 316 simple Remote Procedure Call (RPC) layer. 318 A key aspect of NETCONF is that it allows the functionality of the 319 management protocol to closely mirror the native command line 320 interface of the device. This reduces implementation costs and 321 allows timely access to new features. In addition, applications can 322 access both the syntactic and semantic content of the device's native 323 user interface. 325 The contents of both the request and the response can be fully 326 described in XML DTDs or XML schemas, or both, allowing both parties 327 to recognize the syntax constraints imposed on the exchange. As of 328 this writing, no standard has been developed for data content 329 specification. 331 2.6. COPS-PR 333 COPS-PR and the Structure of Policy Provisioning Information (SPPI) 334 have been approved as Proposed Standards. COPS-PR [RFC3084] uses the 335 Common Open Policy Service (COPS) protocol for support of policy 336 provisioning. The COPS-PR specification is independent of the type 337 of policy being provisioned (QoS, Security, etc.) but focuses on the 338 mechanisms and conventions used to communicate provisioned 339 information between policy-decision-points (PDPs) and policy 340 enforcement points (PEPs). COPS-PR does not make any assumptions 341 about the policy data model being communicated, but describes the 342 message formats and objects that carry the modeled policy data. 343 Policy data is modeled using Policy Information Base modules (PIB 344 modules). 346 COPS-PR has not had wide deployment, and operators have stated that 347 its use of binary encoding (BER) for management data makes it 348 difficult to develop automated scripts for simple configuration 349 management tasks in most text-based scripting languages. In an IAB 350 Workshop on Network Management [RFC3535], the consensus of operators 351 and protocol developers indicated a lack of interest in PIB modules 352 for use with COPS-PR. 354 As a result, the IESG has not approved any policy models (PIB 355 modules) as an IETF standard, and the use of COPS-PR is not 356 recommended. 358 2.7. RADIUS 360 RADIUS [RFC2865], the remote Authentication Dial In User Service, is 361 a Draft Standard that describes a protocol for carrying 362 authentication, authorization, and configuration information between 363 a Network Access Server which desires to authenticate its links and a 364 shared Authentication Server. 366 This protocol is widely implemented and used. RADIUS is widely used 367 in environments, such as enterprise networks, where a single 368 administrative authority manages the network, and protects the 369 privacy of user information. 371 2.8. Diameter 373 DIAMETER [RFC3588] is a Proposed Standard that provides an 374 Authentication, Authorization and Accounting (AAA) framework for 375 applications such as network access or IP mobility. DIAMETER is also 376 intended to work in local Authentication, Authorization, Accounting 377 situations and in roaming situations. 379 Diameter is designed to resolve a number of known problems with 380 RADIUS. Diameter supports server failover, transmission-level 381 security, reliable transport over TCP, agents for proxy and redirect 382 and relay, server-initiated messages, auditability, capability 383 negotiation, peer discovery and configuration, and roaming support. 384 Diameter also provides a larger attribute space than RADIUS. 386 Diameter features make it especially appropriate for environments 387 where the providers of services are in different administrative 388 domains than the maintainer (protector) of confidential user 389 information. 391 2.9. EPP 393 The Extensible Provision Protocol [RFC4930] is a Draft Standard that 394 describes an application layer client-server protocol for the 395 provisioning and management of objects stored in a shared central 396 repository. EPP permits multiple service providers to perform object 397 provisioning operations using a shared central object repository, and 398 addresses the requirements for a generic registry registrar protocol. 400 2.10. VCCV 402 VCCV is a Proposed Standard protocol that provides a control channel 403 associated with a Pseudowire. It is used for operations and 404 management functions such as connectivity verification over the 405 control channel. VCCV applies to all supported access circuit and 406 transport types currently defined for Pseudowires. 408 2.11. ACAP 410 The Application Configuration Access Protocol (ACAP) is designed to 411 support remote storage and access of program option, configuration 412 and preference information. The data store model is designed to 413 allow a client relatively simple access to interesting data, to allow 414 new information to be easily added without server re-configuration, 415 and to promote the use of both standardized data and custom or 416 proprietary data. Key features include "inheritance" which can be 417 used to manage default values for configuration settings and access 418 control lists which allow interesting personal information to be 419 shared and group information to be restricted. 421 ACAP's primary purpose is to allow users access to their 422 configuration data from multiple network-connected computers. Users 423 can then sit down in front of any network-connected computer, run any 424 ACAP-enabled application and have access to their own configuration 425 data. Because it is hoped that many applications will become ACAP- 426 enabled, client simplicity was preferred to server or protocol 427 simplicity whenever reasonable. 429 2.12. XCAP 431 XCAP [RFC4825] is a Proposed Standard protocol that allows a client 432 to read, write, and modify application configuration data stored in 433 XML format on a server. 435 XCAP is a protocol that can be used to manipulate per-user data. 436 XCAP is a set of conventions for mapping XML documents and document 437 components into HTTP URIs, rules for how the modification of one 438 resource affects another, data validation constraints, and 439 authorization policies associated with access to those resources. 440 Because of this structure, normal HTTP primitives can be used to 441 manipulate the data. XCAP is meant to support the configuration 442 needs for a multiplicity of applications, rather than just a single 443 one. 445 XCAP was not designed as a general purpose XML search protocol, XML 446 database update protocol, nor a general purpose, XML-based 447 configuration protocol for network elements. 449 3. Draft and Standard Level Data Models 451 [DISCUSS: JS: The weakest part of the document is IMHO section 6. It 452 is not clear to me what David's intention were here; sometimes he 453 gives general advise while at other places he kind of surveys data 454 models and such things. I am also not sure all the stuff listed 455 there is actually useful to list; for example, has anybody ever 456 deployed the technology which came out of the snmpconf working group? 457 So we need to be more selective and probably also organize our 458 pointers based on the protocol layer people are working on 459 (transmission specific MIB modules are kind of widely used, people 460 managing application servers usually do not use much of SNMP; the 461 IETF application management MIBs we have produced have not gained 462 large deployments as far as I can tell). ] 464 [DISCUSS: David: Some MIB modules may not be deployed because few 465 people know about them and have never tried them. Others may have 466 been tried and been found to be inadequate. We have very little 467 feedback concerning which ones are useful and which are widely 468 deployed, which have been found useful by operators, and which have 469 been found to be junk. ;-) I hesitate to make recommendations that 470 people should avoid a MIB module unless there is real evidence that 471 it is unsuitable for its designed task. Even then, I hesitate 472 because maybe the MIB would be found useful in a different 473 environment that is just emerging. Maybe the IETF needs to perform a 474 de-crufting operation for data models, similar to that done for 475 protocols a few years ago. But I think that would require feedback 476 from LOTS of operators and application developers - and these tend to 477 be scarce in the IETF. ] 479 The purpose of this section is to inform protocol designers about 480 solutions for which information or data models have been standardized 481 in the IETF, so they can reuse existing solutions or apply the 482 information model to new solutions. 484 This section discusses management data models that have reached at 485 least Draft Standard status in the IETF. IETF specifications must 486 have "multiple, independent, and interoperable implementations" 487 before they can be advanced to Draft Standard status. Management 488 data models have a slightly different interpretation for 489 interoperability. This is discussed in detail in BCP 27: Advancement 490 of MIB specifications on the IETF Standards Track [RFC2438] discusses 491 special considerations about the advancement process for management 492 data models. Most IETF management data models never advance beyond 493 Proposed Standard. T his section will focus on those data models 494 that have reached at least Draft status. This is supplemented by a 495 chapter that lists additional data models that are Proposed Standard 496 status. 498 [TODO] discuss specific MIB modules, SDEs, XML schemas that are 499 designed to solve generic problems. This might cover things like 500 Textual Conventions, RFC3415 Target tables, SYSLOG SDEs defined in 501 -protocol-, SYSLOG -sign-, IPFIX IEs, etc. 503 3.1. Fault Management 505 RFC 3418 [RFC3418], part of STD 62 SNMP, contains objects in the 506 system group that are often polled to determine if a device is still 507 operating, and sysUpTime can be used to detect if a system has 508 rebooted, and counters have been reinitialized. 510 RFC3413 [RFC3413], part of STD 62 SNMP, includes objects designed for 511 managing notifications, including tables for addressing, retry 512 parameters, security, lists of targets for notifications, and user 513 customization filters. 515 An RMON monitor [RFC2819] can be configured to recognize conditions, 516 most notably error conditions, and continuously to check for them. 517 When one of these conditions occurs, the event may be logged, and 518 management stations may be notified in a number of ways. See further 519 discussion of RMON under Performance Management. 521 3.2. Configuration Management 523 It is expected that standard XML-based data models will be developed 524 for use with NETCONF, and working groups might identify specific 525 NETCONF data models that would be applicable to the new protocol. At 526 the time of this writing, no such standard data models exist. 528 For monitoring network configuration, such as physical and logical 529 network topologies, existing MIB modules already exist that provide 530 some of the desired capabilities. New MIB modules might be developed 531 for the target functionality to allow operators to monitor and modify 532 the operational parameters, such as timer granularity, event 533 reporting thresholds, target addresses, and so on. 535 RFC 3418 [RFC3418], part of STD 62 SNMPv3, contains objects in the 536 system group that are often polled to determine if a device is still 537 operating, and sysUpTime can be used to detect if a system has 538 rebooted and caused potential discontinuity in counters. Other 539 objects in the system MIB are useful for identifying the type of 540 device, the location of the device, the person responsible for the 541 device, etc. 543 RFC3413 [RFC3413], part of STD 62 SNMPv3, includes objects designed 544 for configuring notification destinations, and for configuring proxy- 545 forwarding SNMP agents, which can be used to forward messages through 546 firewalls and NAT devices. 548 RFC2863 [RFC2863], the Interfaces MIB is used for managing Network 549 Interfaces. This includes the 'interfaces' group of MIB-II and 550 discusses the experience gained from the definition of numerous 551 media-specific MIB modules for use in conjunction with the 552 'interfaces' group for managing various sub-layers beneath the 553 internetwork-layer. 555 3.3. Accounting Management 557 TODO: RADIUS Accounting MIBs are PS; are there any DS data models for 558 accounting? ] 560 3.4. Performance Management 562 MIB modules typically contain counters to determine the frequency and 563 rate of an occurrence. 565 RFC2819, STD 59 RMON, defines objects for managing remote network 566 monitoring devices. An organization may employ many remote 567 management probes, one per network segment, to manage its internet. 568 These devices may be used for a network management service provider 569 to access a client network, often geographically remote. Most of the 570 objects in the RMON MIB module are suitable for the management of any 571 type of network, and there are some which are specific to managing 572 Ethernet networks. 574 RMON allows a probe to be configured to perform diagnostics and to 575 collect statistics continuously, even when communication with the 576 management station may not be possible or efficient. The alarm group 577 periodically takes statistical samples from variables in the probe 578 and compares them to previously configured thresholds. If the 579 monitored variable crosses a threshold, an event is generated. 581 The RMON host group discovers hosts on the network by keeping a list 582 of source and destination MAC Addresses seen in good packets 583 promiscuously received from the network, and contains statistics 584 associated with each host. The hostTopN group is used to prepare 585 reports that describe the hosts that top a list ordered by one of 586 their statistics. The available statistics are samples of one of 587 their base statistics over an interval specified by the management 588 station. Thus, these statistics are rate based. The management 589 station also selects how many such hosts are reported. 591 The RMON matrix group stores statistics for conversations between 592 sets of two addresses. The filter group allows packets to be matched 593 by a filter equation. These matched packets form a data stream that 594 may be captured or may generate events. The Packet Capture group 595 allows packets to be captured after they flow through a channel. The 596 event group controls the generation and notification of events from 597 this device. 599 The RMON-2 MIB [RFC4502] extends RMON by providing RMON analysis up 600 to the application layer. The SMON MIB [RFC2613] extends RMON by 601 providing RMON analysis for switched networks. 603 3.5. Security Management 605 Working groups should consider existing data models that would be 606 relevant to monitoring and managing the security of the new protocol. 608 The IETF has no standard data models for managing security protocols 609 such as TLS and SSH. 611 4. Proposed Standard Data Models 613 4.1. Fault Management 615 The IETF SYSLOG protocol [I-D.ietf-syslog-protocol] is a Proposed 616 Standard that includes a mechanism for defining structured data 617 elements (SDEs). The SYSLOG protocol document defines an initial set 618 of SDEs that relate to content time quality, content origin, and 619 meta-information about the message, such as language. Proprietary 620 SDEs can be used to supplement the IETF-defined SDEs. 622 DISMAN-EVENT-MIB in RFC 2981 and DISMAN-EXPRESSION-MIB in RFC 2982 623 provide a superset of the capabilities of the RMON alarm and event 624 groups. These modules provide mechanisms for thresholding and 625 reporting anomalous events to management applications. 627 The ALARM MIB in RFC 3877 and the Alarm Reporting Control MIB in RFC 628 3878 specify mechanisms for expressing state transition models for 629 persistent problem states. There is also a mechanism specified to 630 correlate a notification with subsequent state transition 631 notifications about the same entity/object. 633 Other MIB modules that may be applied to Fault Management include: 635 NOTIFICATION-LOG-MIB in RFC 3014 637 ENTITY-STATE-MIB in RFC 4268 639 ENTITY-SENSOR-MIB in RFC 4268 641 4.2. Configuration Management 643 The Entity MIB [RFC4133] is used for managing multiple logical and 644 physical entities managed by a single SNMP agent. This module 645 provides a useful mechanism for identifying the entities comprising a 646 system. There are also event notifications defined for configuration 647 changes that may be useful to management applications. 649 RFC3159 [RFC3159] discusses the Structure of Policy Provisioning 650 Information, an extension to the SMI standard for purposes of policy- 651 based provisioning, for use with the COPS-PR protocol defined in 652 RFC3084 [RFC3084]. RFC3317 [RFC3317] defines a DiffServ QoS PIB. At 653 the time of this writing, there are no standards-track PIBs. During 654 the IAB Workshop on Network Management, the workshop had rough 655 consensus from the protocol developers that the IETF should not spend 656 resources on SPPI PIB definitions, and the operators had rough 657 consensus that they do not care about SPPI PIBs. 659 The Policy Based Management MIB [RFC4011] defines objects that enable 660 policy-based monitoring and management of SNMP infrastructures, a 661 scripting language, and a script execution environment. 663 RFC3165 [RFC3165] supports the use of user-written scripts to 664 delegate management functionality. 666 Proposed Standard RFC4011 [RFC4011] defines objects that enable 667 policy-based monitoring using SNMP, using a scripting language, and a 668 script execution environment. 670 Few vendors have implemented MIB modules that support scripting. 671 Some vendors consider running user-developed scripts within the 672 managed device as a violation of support agreements. 674 [TODO] Informational RFC3317 defines a DiffServ QoS PIB, and 675 Informational RFC3571 defines policy classes for monitoring and 676 reporting policy usage feedback, as well as policy classes for 677 controlling reporting intervals, suspension, resumption and 678 solicitation. At the time of this writing, there are no standards- 679 track PIBs During the IAB Workshop on Network Management, the 680 workshop had rough consensus from the protocol developers that the 681 IETF should not spend resources on SPPI PIB definitions, and the 682 operators had rough consensus that they do not care about SPPI PIBs. 684 4.3. Accounting Management 686 DIAMETER [RFC3588] accounting might be collected for services, and 687 working groups might document some of the RADIUS/DIAMETER attributes 688 that could be used. [TODO: what data models?] 690 RADIUS Authentication Client MIB [RFC4668] and RADIUS Authentication 691 Server MIB [RFC4669] allow the gathering of accounting data. 693 [TODO] The IPFIX protocol [RFC5101] can collect information related 694 to IP flows, and existing Information Elements (IEs) may be 695 appropriate to report flows of the new protocol. New IPFIX 696 Information Elements might be useful for collecting flow information 697 useful only in consideration of the new protocol. As of this 698 writing, no IEs have reached Proposed Standard status yet, but a base 699 set of IEs has been submitted to IESG for advancement. These include 700 IEs for Identifying the scope of reporting, Metering and Export 701 Process configuration, IP and Transport and Sub-IP header fields, 702 Packet and Flow properties, timestamps, and counters. 704 4.4. Performance Management 706 RAQMON [RFC4710] describes Real-Time Application Quality of Service 707 Monitoring. 709 The IPPM WG has defined metrics for accurately measuring and 710 reporting the quality, performance, and reliability of Internet data 711 delivery services. The metrics include connectivity, one-way delay 712 and loss, round-trip delay and loss, delay variation, loss patterns, 713 packet reordering, bulk transport capacity, and link bandwidth 714 capacity. [TODO: detail the RFCs - 4737, 3393, 2681, 2680, 2679, 715 2678] 717 SIP Package for Voice Quality Reporting 718 [I-D.ietf-sipping-rtcp-summary] defines a SIP event package that 719 enables the collection and reporting of metrics that measure the 720 quality for Voice over Internet Protocol (VoIP) sessions. 722 4.5. Security Management 723 5. IANA Considerations 725 This document does not introduce any new codepoints or name spaces 726 for registration with IANA. Note to RFC Editor: this section may be 727 removed on publication as an RFC. 729 6. Security Considerations 731 This document introduces no new security concerns. 733 7. Acknowledgements 735 8. Informative References 737 [I-D.ietf-opsawg-operations-and-management] Harrington, D., 738 "Guidelines for 739 Considering Operations 740 and Management of New 741 Protocols", draft-ietf- 742 opsawg-operations-and- 743 management-05 (work in 744 progress), October 2008. 746 [I-D.ietf-sipping-rtcp-summary] Clark, A., Pendleton, 747 A., Johnston, A., and H. 748 Sinnreich, "Session 749 Initiation Protocol 750 Package for Voice 751 Quality Reporting 752 Event", draft-ietf- 753 sipping-rtcp-summary-05 754 (work in progress), 755 October 2008. 757 [I-D.ietf-syslog-protocol] Gerhards, R., "The 758 syslog Protocol", draft- 759 ietf-syslog-protocol-23 760 (work in progress), 761 September 2007. 763 [RFC1157] Case, J., Fedor, M., 764 Schoffstall, M., and J. 765 Davin, "Simple Network 766 Management Protocol 767 (SNMP)", STD 15, 768 RFC 1157, May 1990. 770 [RFC1901] Case, J., McCloghrie, 771 K., McCloghrie, K., 772 Rose, M., and S. 773 Waldbusser, 774 "Introduction to 775 Community-based SNMPv2", 776 RFC 1901, January 1996. 778 [RFC2119] Bradner, S., "Key words 779 for use in RFCs to 780 Indicate Requirement 781 Levels", BCP 14, 782 RFC 2119, March 1997. 784 [RFC2438] O'Dell, M., Alvestrand, 785 H., Wijnen, B., and S. 786 Bradner, "Advancement of 787 MIB specifications on 788 the IETF Standards 789 Track", BCP 27, 790 RFC 2438, October 1998. 792 [RFC2613] Waterman, R., Lahaye, 793 B., Romascanu, D., and 794 S. Waldbusser, "Remote 795 Network Monitoring MIB 796 Extensions for Switched 797 Networks Version 1.0", 798 RFC 2613, June 1999. 800 [RFC2819] Waldbusser, S., "Remote 801 Network Monitoring 802 Management Information 803 Base", STD 59, RFC 2819, 804 May 2000. 806 [RFC2863] McCloghrie, K. and F. 807 Kastenholz, "The 808 Interfaces Group MIB", 809 RFC 2863, June 2000. 811 [RFC2865] Rigney, C., Willens, S., 812 Rubens, A., and W. 813 Simpson, "Remote 814 Authentication Dial In 815 User Service (RADIUS)", 816 RFC 2865, June 2000. 818 [RFC3084] Chan, K., Seligson, J., 819 Durham, D., Gai, S., 820 McCloghrie, K., Herzog, 821 S., Reichmeyer, F., 822 Yavatkar, R., and A. 823 Smith, "COPS Usage for 824 Policy Provisioning 825 (COPS-PR)", RFC 3084, 826 March 2001. 828 [RFC3159] McCloghrie, K., Fine, 829 M., Seligson, J., Chan, 830 K., Hahn, S., Sahita, 831 R., Smith, A., and F. 832 Reichmeyer, "Structure 833 of Policy Provisioning 834 Information (SPPI)", 835 RFC 3159, August 2001. 837 [RFC3165] Levi, D. and J. 838 Schoenwaelder, 839 "Definitions of Managed 840 Objects for the 841 Delegation of Management 842 Scripts", RFC 3165, 843 August 2001. 845 [RFC3317] Chan, K., Sahita, R., 846 Hahn, S., and K. 847 McCloghrie, 848 "Differentiated Services 849 Quality of Service 850 Policy Information 851 Base", RFC 3317, 852 March 2003. 854 [RFC3410] Case, J., Mundy, R., 855 Partain, D., and B. 856 Stewart, "Introduction 857 and Applicability 858 Statements for Internet- 859 Standard Management 860 Framework", RFC 3410, 861 December 2002. 863 [RFC3413] Levi, D., Meyer, P., and 864 B. Stewart, "Simple 865 Network Management 866 Protocol (SNMP) 867 Applications", STD 62, 868 RFC 3413, December 2002. 870 [RFC3418] Presuhn, R., "Management 871 Information Base (MIB) 872 for the Simple Network 873 Management Protocol 874 (SNMP)", STD 62, 875 RFC 3418, December 2002. 877 [RFC3444] Pras, A. and J. 878 Schoenwaelder, "On the 879 Difference between 880 Information Models and 881 Data Models", RFC 3444, 882 January 2003. 884 [RFC3535] Schoenwaelder, J., 885 "Overview of the 2002 886 IAB Network Management 887 Workshop", RFC 3535, 888 May 2003. 890 [RFC3585] Jason, J., Rafalow, L., 891 and E. Vyncke, "IPsec 892 Configuration Policy 893 Information Model", 894 RFC 3585, August 2003. 896 [RFC3588] Calhoun, P., Loughney, 897 J., Guttman, E., Zorn, 898 G., and J. Arkko, 899 "Diameter Base 900 Protocol", RFC 3588, 901 September 2003. 903 [RFC3644] Snir, Y., Ramberg, Y., 904 Strassner, J., Cohen, 905 R., and B. Moore, 906 "Policy Quality of 907 Service (QoS) 908 Information Model", 909 RFC 3644, November 2003. 911 [RFC3670] Moore, B., Durham, D., 912 Strassner, J., 913 Westerinen, A., and W. 914 Weiss, "Information 915 Model for Describing 916 Network Device QoS 917 Datapath Mechanisms", 918 RFC 3670, January 2004. 920 [RFC3805] Bergman, R., Lewis, H., 921 and I. McDonald, 922 "Printer MIB v2", 923 RFC 3805, June 2004. 925 [RFC4011] Waldbusser, S., Saperia, 926 J., and T. Hongal, 927 "Policy Based Management 928 MIB", RFC 4011, 929 March 2005. 931 [RFC4133] Bierman, A. and K. 932 McCloghrie, "Entity MIB 933 (Version 3)", RFC 4133, 934 August 2005. 936 [RFC4502] Waldbusser, S., "Remote 937 Network Monitoring 938 Management Information 939 Base Version 2", 940 RFC 4502, May 2006. 942 [RFC4668] Nelson, D., "RADIUS 943 Authentication Client 944 MIB for IPv6", RFC 4668, 945 August 2006. 947 [RFC4669] Nelson, D., "RADIUS 948 Authentication Server 949 MIB for IPv6", RFC 4669, 950 August 2006. 952 [RFC4710] Siddiqui, A., Romascanu, 953 D., and E. Golovinsky, 954 "Real-time Application 955 Quality-of-Service 956 Monitoring (RAQMON) 957 Framework", RFC 4710, 958 October 2006. 960 [RFC4741] Enns, R., "NETCONF 961 Configuration Protocol", 962 RFC 4741, December 2006. 964 [RFC4825] Rosenberg, J., "The 965 Extensible Markup 966 Language (XML) 967 Configuration Access 968 Protocol (XCAP)", 969 RFC 4825, May 2007. 971 [RFC4930] Hollenbeck, S., 972 "Extensible Provisioning 973 Protocol (EPP)", 974 RFC 4930, May 2007. 976 [RFC5101] Claise, B., 977 "Specification of the IP 978 Flow Information Export 979 (IPFIX) Protocol for the 980 Exchange of IP Traffic 981 Flow Information", 982 RFC 5101, January 2008. 984 Appendix A. Open Issues 986 [TODO: need to verify all citations have references (in xref 987 format)] 989 Organize data models by layer? 991 Appendix B. Change Log 993 Changes from being part of opsawg-operations-and-management to being 994 opsawg-survey-00 996 Author's Address 998 David Harrington 999 HuaweiSymantec 1000 1700 Alma Dr, Suite 100 1001 Plano, TX 75075 1002 USA 1004 Phone: +1 603 436 8634 1005 Fax: 1006 EMail: dharrington@huawei.com 1007 URI: