idnits 2.17.1 draft-iab-nm-workshop-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2003) is 7739 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 3410 -- Possible downref: Non-RFC (?) normative reference: ref. 'CIM' ** Downref: Normative reference to an Historic RFC: RFC 3084 -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IAB J. Schoenwaelder 3 Internet-Draft University of Osnabrueck 4 Expires: August 2, 2003 February 2003 6 Overview of the 2002 IAB Network Management Workshop 7 draft-iab-nm-workshop-02.txt 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on August 2, 2003. 32 Copyright Notice 34 Copyright (C) The Internet Society (2003). All Rights Reserved. 36 Abstract 38 This document provides an overview of a workshop held by the Internet 39 Architecture Board (IAB) on Network Management. The workshop was 40 hosted by CNRI in Reston, VA, USA on June 4 thru June 6, 2002. The 41 goal of the workshop was to continue the important dialog which has 42 been started between network operators and protocol developers and to 43 provide advice to the IETF where future work on network management 44 should be focussed. This report summarizes the discussions and lists 45 the conclusions and recommendations to the Internet Engineering Task 46 Force (IETF) community. 48 Comments should be submitted to the mailing 49 list. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Network Management Technologies . . . . . . . . . . . . . . . 4 55 2.1 SNMP / SMI / MIBs . . . . . . . . . . . . . . . . . . . . . . 4 56 2.2 COPS-PR / SPPI / PIBs . . . . . . . . . . . . . . . . . . . . 6 57 2.3 CIM / MOF / UML / PCIM . . . . . . . . . . . . . . . . . . . . 7 58 2.4 CLI / TELNET / SSH . . . . . . . . . . . . . . . . . . . . . . 8 59 2.5 HTTP / HTML . . . . . . . . . . . . . . . . . . . . . . . . . 9 60 2.6 XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 61 3. Operator Requirements . . . . . . . . . . . . . . . . . . . . 10 62 4. SNMP Framework Discussions . . . . . . . . . . . . . . . . . . 12 63 5. Consolidated Observations . . . . . . . . . . . . . . . . . . 14 64 6. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 16 65 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 66 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 67 Normative References . . . . . . . . . . . . . . . . . . . . . 18 68 Informative References . . . . . . . . . . . . . . . . . . . . 18 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 19 70 A. Participants . . . . . . . . . . . . . . . . . . . . . . . . . 19 71 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 20 73 1. Introduction 75 The IETF has started several activities in the operations and 76 management area to develop technologies and standards which aim to 77 help network operators to manage their networks. The main network 78 management technologies currently being developed within the IETF 79 are: 81 o The Simple Network Management Protocol (SNMP) [RFC3410] was 82 created in the late 1980s. The initial version (SNMPv1) is widely 83 deployed while the latest version (SNMPv3) which addresses 84 security requirements is just beginning to gain significant 85 deployment. 87 o The Common Information Model (CIM) [CIM] developed by the 88 Distributed Management Task Force (DMTF) has been extended in 89 cooperation with the DMTF to describe high-level policies as rule 90 sets (PCIM) [RFC3060]. Mappings of the CIM policy extensions to 91 LDAP schemas have been defined and work continues to define 92 specific schema extension for QoS and security policies. 94 o The Common Open Policy Service (COPS) [RFC2748] protocol has been 95 extended to provision configuration information on devices (COPS- 96 PR) [RFC3084]. Work is underway to define data definitions for 97 specific services such as Differentiated Services (DiffServ). 99 During 2001, several meetings have been organized at various events 100 (NANOG-22 May 2001, RIPE-40 October 2001, LISA-XV December 2001, 101 IETF-52 December 2001) to start a direct dialog between network 102 operators and protocol developers. During these meetings, several 103 operators have expressed their opinion that the developments in the 104 IETF do not really address their requirements, especially for 105 configuration management. This naturally leads to the question 106 whether the IETF should refocus resources and which strategic future 107 activities in the operations and management area should be started. 109 The Internet Architecture Board (IAB), on June 4 thru June 6, 2002, 110 held an invitational workshop on network management. The goal of the 111 workshop was to continue the important dialog which has been started 112 between network operators and protocol developers and to provide 113 advice to the IETF where future work on network management should be 114 focussed. 116 The workshop started with two breakout session to (a) identify a list 117 of technologies relevant for network management together with their 118 strengths and weaknesses and to (b) identify the most important 119 operator needs. The results of these discussions are documented in 120 Section 2 and Section 3. During the following discussions, many more 121 specific characteristics of the current SNMP framework were 122 identified. These discussions are documented in Section 4. Section 123 5 defines a combined feature list which was developed during the 124 discussions following the breakout sessions. Section 6 gives 125 concrete recommendations to the IETF. 127 The following text makes no explicit distinction between different 128 versions of SNMP. For the majority of the SNMP related statements, 129 the protocol version is irrelevant. Nevertheless, some statements 130 are more applicable to SNMPv1/SNMPv2c environments while other 131 statements (especially those concerned with security) are more 132 applicable to SNMPv3 environments. 134 2. Network Management Technologies 136 During the breakout sessions, the protocol developers assembled a 137 list of the various network management technologies that are 138 available or under active development. For each technology, a list 139 of strong (+) and weak (-) points were identified. There are also 140 some characteristics which appear to be neutral (o). 142 The list does not attempt to be complete. Focus was given to IETF 143 specific technologies (SNMP, COPS-PR, PCIM) and widely used 144 proprietary technologies (CLI, HTTP/HTML, XML). Other generic 145 management technologies (such as TL1, CORBA, CMIP/GDMO, TMN) or 146 specific management technologies for specific problem domains (such 147 as RADIUS, DHCP, BGP, OSPF) were acknowledged to exist but not focus 148 of the discussions. 150 2.1 SNMP / SMI / MIBs 152 The SNMP management technology was created in the late 1980s and has 153 since then been widely implemented and deployed in the Internet. 154 There is lots of implementation and operational experience and the 155 characteristics of the technology are thus well understood. 157 + SNMP works reasonably well for device monitoring. The stateless 158 nature of SNMP is useful for statistic and status polling. 160 + SNMP is widely deployed for basic monitoring. Some core MIB 161 modules such as the IF-MIB [RFC2863] are implemented on most 162 networking devices. 164 + There are many well defined proprietary MIB modules developed by 165 network device vendors to support their management products. 167 + SNMP is an important data source for systems that do event 168 correlation, alarm detection and root cause analysis. 170 o SNMP requires applications to be useful. SNMP was from its early 171 days designed as a programmatic interface between management 172 applications and devices. As such, using SNMP without management 173 applications or smart tools appears to be more complicated. 175 o Standardized MIB modules often lack writable MIB objects which can 176 be used for configuration and this leads to a situation where the 177 interesting writable objects exist in proprietary MIB modules. 179 - There are scaling problems with regard to the number of objects in 180 a device. While SNMP provides reasonable performance for the 181 retrieval of a small amount of data from many devices, it becomes 182 rather slow when retrieving large amounts of data (such as routing 183 tables) from a few devices. 185 - There is too little deployment of writable MIB modules. While 186 there are some notable exceptions in areas such as cable modems 187 where writable MIB modules are essential, it appears that router 188 equipment is usually not fully configurable via SNMP. 190 - The SNMP transactional model and the protocol constraints make it 191 more complex to implement MIBs compared to the implementation of 192 commands of a command line interface interpreter. A logical 193 operation on a MIB can turn into a sequence of SNMP interactions 194 where the implementation has to maintain state until the operation 195 is complete or until a failure has been determined. In case of a 196 failure, a robust implementation must be smart enough to roll the 197 device back into a consistent state. 199 - SNMP does not support easy retrieval and playback of 200 configurations. One part of the problem is that it is not easy to 201 identify configuration objects. Another part of the problem is 202 that the naming system is very specific and physical device 203 reconfigurations can thus break the capability to play back a 204 previous configuration. 206 - There is often a semantic mismatch between the task-oriented view 207 of the world usually preferred by operators and the data-centric 208 view of the world provided by SNMP. Mapping from a task-oriented 209 view to the data-centric view often requires some non-trivial code 210 on the management application side. 212 - Several standardized MIB modules lack a description of high-level 213 procedures. It is often not obvious from reading the MIB modules 214 how certain high-level tasks are accomplished which leads to 215 several different ways to achieve the same goal and this increases 216 costs and hinders interoperability. 218 A more detailed discussion about the SNMP management technology can 219 be found in Section 4. 221 2.2 COPS-PR / SPPI / PIBs 223 The COPS protocol [RFC2748] was defined in the late 1990s to support 224 policy control over QoS signaling protocols. The COPS-PR extension 225 allows to provision policy information on devises. 227 + COPS-PR allows high-level transactions for single devices 228 including deleting one configuration and replacing it with 229 another. 231 + COPS-PRs non-overlapping instance namespace normally ensures that 232 no other manager can corrupt a specific configuration. All 233 transactions for a given instance namespace are required to be 234 executed in-order. 236 + Both manager and device states are completely synchronized with 237 one another at all times. If there is a failure in communication, 238 the state is resynchronized when the network is operating properly 239 again and the device's network configuration is valid. 241 + The atomicity of the transactions is well-defined. If there is 242 any failure in a transaction, that specific failure is reported to 243 the manager, and the local configuration is supposed to be 244 automatically rolled-back to the state of the last "good" 245 transaction. 247 + Capability reporting is part of the framework PIB which must be 248 supported by COPS-PR implementations. This allows management 249 applications to adapt to the capabilities present on a device. 251 + The focus of COPS-PR is configuration and the protocol has been 252 optimized for this purpose (by using for example TCP as a 253 transport mechanism). 255 o Only a single manager is allowed to have control at any point in 256 time for a given subject category on a device. (The subject 257 category maps to a COPS Client-Type.) This single manager 258 assumption simplifies the protocol as it makes it easier to 259 maintain shared state. 261 o Similar to SNMP, COPS-PR requires applications to be useful since 262 it is also designed as a programmatic interface between management 263 applications and devices. 265 - As of the time of the meeting, there are no standardized PIB 266 modules. 268 - Compared to SNMP, there is not yet enough experience to understand 269 the strong and weak aspects of the protocol in operational 270 environments. 272 - COPS-PR does not support easy retrieval and playback of 273 configurations. The reasons are similar as for SNMP. 275 - The COPS-PR view of the world is data-centric, similar to SNMP's 276 view of the world. A mapping from the data-centric view to a 277 task-oriented view and vice versa has similar complexities as with 278 SNMP. 280 2.3 CIM / MOF / UML / PCIM 282 The development of the Common Information Model (CIM) [CIM] started 283 in the DMTF in the mid 1990s. The development follows a top-down 284 approach where core classes are defined first and later extended to 285 model specific services. The DMTF and the IETF jointly developed 286 policy extensions of the CIM, known as PCIM [RFC3060]. 288 + The CIM technology generally follows principles of object- 289 orientation with full support of methods on data objects, which is 290 not available in SNMP or COPS-PR. 292 + The MOF format allows to represent instances in a common format. 293 No such common format exists for SNMP or COPS-PR. It is of course 294 possible to store instances in the form of BER encoded ASN.1 295 sequences, but this is generally not suitable for human 296 readability. 298 + There is support for a query facility which allows to locate CIM 299 objects. However, the query language itself is not yet specified 300 as part of the CIM standards. Implementations currently use 301 proprietary query languages, such as the Windows Management 302 Instrumentation Query Language (WQL). 304 + The information modeling work in CIM is done by using UML as a 305 graphical notation. This attracts people with a computer science 306 background who have learned to use UML as part of their education. 308 o The main practical use of CIM schemas today seems to be the 309 definition of data structures used internally by management 310 systems. 312 - The CIM schemas have rather complex interrelationships that must 313 be understood before one can reasonably extend the set of existing 314 schemas. 316 - Interoperability between CIM implementations seems to be 317 problematic compared to the number of interoperable SNMP 318 implementations available today. 320 - CIM schemas have seen limited implementation and usage so far as 321 an interface between management systems and network devices. 323 2.4 CLI / TELNET / SSH 325 Most devices have a builtin command line interface (CLI) for 326 configuration and troubleshooting purposes. Network access to the 327 CLI has been traditionally through the TELNET protocol while the SSH 328 protocol is gaining momentum to address security issues associated 329 with TELNET. In the following, only CLIs that actually parse and 330 execute commands are considered. (Menu-oriented interfaces are 331 difficult for automation and thus not relevant here.) 333 + Command line interfaces are generally task-oriented which make 334 them easier to use for human operators. 336 + A saved sequence of textual commands can easily be replayed. 337 Simple substitutions can be made with arbitrary text processing 338 tools. 340 + It is usually necessary to learn at least parts of the command 341 line interface of new devices in order to create the initial 342 configuration. Once people have learned (parts of) the command 343 line interface, it is natural for them to use the same interface 344 and abstractions for automating configuration changes. 346 + A command line interface does not require any special purpose 347 applications (telnet and ssh are readily available on most systems 348 today). 350 + Most command line interfaces provide context sensitive help which 351 reduces the learning curve. 353 - Some command line interfaces lack a common data model. It is very 354 well possible that the same command on different devices even from 355 the same vendor behaves differently. 357 - The command line interface is primarily targeted to humans which 358 can adapt to minor syntax and format changes easily. Using 359 command line interfaces as a programmatic interface is troublesome 360 because of parsing complexities. 362 - Command line interfaces often lack proper version control for the 363 syntax and the semantics. It is therefore time consuming and 364 error prone to maintain programs or scripts that interface with 365 different versions of a command line interface. 367 - Since command line interfaces are proprietary, they can not be 368 used efficiently to automate processes in an environment with a 369 heterogenous set of devices. 371 - The access control facilities, if present at all, are often ad-hoc 372 and sometimes insufficient. 374 2.5 HTTP / HTML 376 Many devices have an embedded web server which can be used to 377 configure the device and to obtain status information. The commonly 378 used protocol is HTTP and information is rendered in HTML. Some 379 devices also expect that clients have facilities such as Java or Java 380 Script. 382 + Embedded web server for configuration are end-user friendly and 383 solution oriented. 385 + Embedded web server are suitable for configuring consumer devices 386 by inexperienced users. 388 + Web server configuration is widely deployed, especially in boxes 389 targeted to the consumer market. 391 + There is no need for specialized applications to use embedded web 392 servers since web browsers are commonly available today. 394 - Embedded web server are management application hostile. Parsing 395 HTML pages to extract useful information is extremely painful. 397 - Replay of configuration is often problematic, either because the 398 web pages rely on some active content or because different 399 versions of the same device use different ways to interact with 400 the user. 402 - The access control facilities, if present at all, are often ad-hoc 403 and sometimes insufficient. 405 2.6 XML 407 Some vendors started in the late 1990s to use the Extensible Markup 408 Language (XML) [XML] for describing device configurations and for 409 protocols that can be used to retrieve and manipulate XML formatted 410 configurations. 412 + XML is a machine readable format which is easy to process and 413 there are many good off the shelf tools available. 415 + XML allows to describe structured data of almost arbitrary 416 complexity. 418 + The basic syntax rules behind XML are relatively easy to learn. 420 + XML provides a document-oriented view of configuration data 421 (similar to many proprietary configuration file formats). 423 + XML has a robust schema language XSD [XSD] for which many good off 424 the shelf tools exists. 426 o XML alone is just syntax. XML schemas must be carefully designed 427 to make XML truly useful as a data exchange format. 429 - XML is rather verbose. This either increases the bandwidth 430 required to move management information around (which is an issue 431 in e.g. wireless or asymmetric cable networks) or it requires 432 that the systems involved have the processing power to do on the 433 fly compression/decompression. 435 - There is a lack of commonly accepted standardized management 436 specific XML schemas. 438 3. Operator Requirements 440 The operators were asked during the breakout session to identify 441 their needs which are not sufficiently addressed. The results 442 produced during the breakout session were later discussed and 443 resulted in the following list of operator requirements. 445 1. Ease of use is a key requirement for any network management 446 technology from the operators point of view. 448 2. It is necessary to make a clear distinction between 449 configuration data, data that describes operational state and 450 statistics. Some devices make it very hard to determine which 451 parameters were administratively configured and which were 452 obtained via other mechanisms such as routing protocols. 454 3. It is required to be able to fetch separately configuration 455 data, operational state data, and statistics from devices, and 456 to be able to compare these between devices. 458 4. It is necessary to enable operators to concentrate on the 459 configuration of the network as a whole rather than individual 460 devices. 462 5. Support for configuration transactions across a number of 463 devices would significantly simplify network configuration 464 management. 466 6. Given configuration A and configuration B, it should be possible 467 to generate the operations necessary to get from A to B with 468 minimal state changes and effects on network and systems. It is 469 important to minimize the impact caused by configuration 470 changes. 472 7. A mechanism to dump and restore configurations is a primitive 473 operation needed by operators. Standards for pulling and 474 pushing configurations from/to devices are desirable. 476 8. It must be easy to do consistency checks of configurations over 477 time and between the ends of a link in order to determine the 478 changes between two configurations and whether two 479 configurations are consistent. 481 9. Network wide configurations are typically stored in central 482 master databases and transformed into formats that can be pushed 483 to devices, either by generating sequences of CLI commands or 484 complete configuration files that are pushed to devices. There 485 is no common database schema for network configuration, although 486 the models used by various operators are probably very similar. 487 It is desirable to extract, document and standardize the common 488 parts of these network wide configuration database schemas. 490 10. It is highly desirable that text processing tools such as diff 491 and version management tools such as RCS or CVS can be used to 492 process configurations, which implies that devices should not 493 arbitrarily reorder data such as access control lists. 495 11. The granularity of access control needed on management 496 interfaces needs to match operational needs. Typical 497 requirements are a role-based access control model and the 498 principle of least privilege, where a user can be given only the 499 minimum access necessary to perform a required task. 501 12. It must be possible to do consistency checks of access control 502 lists across devices. 504 13. It is important to distinguish between the distribution of 505 configurations and the activation of a certain configuration. 506 Devices should be able to hold multiple configurations. 508 14. SNMP access control is data-oriented while CLI access control is 509 usually command (task) oriented. Depending on the management 510 function, sometimes a data-oriented or a task-oriented access 511 control makes more sense. As such, it is a requirement to 512 support both data-oriented and task-oriented access control. 514 So far, there is no published document which clearly defines the 515 requirements of the operators. 517 4. SNMP Framework Discussions 519 During the discussions, many properties of the SNMP framework were 520 identified. 522 1. It is usually not possible to retrieve complete device 523 configurations via SNMP so that they can be compared with 524 previous configurations or checked for consistency across 525 devices. There is usually only incomplete coverage of device 526 features via the SNMP interface and there is a lack of 527 differentiation between configuration data and operational state 528 data for many features. 530 2. The quality of SNMP instrumentations is sometimes disappointing. 531 SNMP access sometimes crashes systems or returns wrong data. 533 3. MIB modules and their implementations are not available in a 534 timely manner (sometimes MIB modules lag years behind) which 535 forces users to use the CLI. 537 4. Operators view current SNMP programming/scripting interfaces as 538 being too low-level and thus too time consuming and inconvenient 539 for practical use. 541 5. Lexicographic ordering is sometimes artificial with regard to 542 internal data structures and causes either significant runtime 543 overhead or increases implementation costs or implementation 544 delay or both. 546 6. Poor performance for bulk data transfers. The typical examples 547 are routing tables. 549 7. Poor performance on query operations that were not anticipated 550 during the MIB design. A typical example is the following 551 query: Which outgoing interface is being used for a specific 552 destination address? 554 8. The SNMP credentials and key management is considered complex, 555 especially since it does not integrate well with other existing 556 credential and key management systems. 558 9. The SMI language is hard to deal with and not very practical. 560 10. MIB modules are often over-engineered in the sense that they 561 contain lots of variables operators do not look at. 563 11. SNMP traps are used to track state changes but often syslog 564 messages are considered more useful since they usually contain 565 more information to describe the problem. SNMP traps usually 566 require subsequent get operations to figure out what the trap 567 really means. 569 12. Device manufacturers find SNMP instrumentations inherently 570 difficult to implement, especially with complex table indexing 571 schemes and table interrelationships. 573 13. MIB modules often lack a description how the various objects can 574 be used to achieve certain management functions. (MIB modules 575 can often be characterized as a list of ingredients without a 576 recipe.) 578 14. The lack of structured types and RPC kind of interactions 579 (methods) makes MIB modules much more complex to design and 580 implement. 582 15. The lack of query and aggregation capabilities (reduction of 583 data) causes efficiency and scalability problems. 585 16. The SNMP protocol was simplified in terms of the number of 586 protocol operations and resource requirements on managed 587 devices. It was not simplified in terms of usability by network 588 operators or instrumentation implementors. 590 17. There is a semantic mismatch between the low-level data-oriented 591 abstraction level of MIB modules and the task-oriented 592 abstraction level desired by network operators. Bridging the 593 gap with tools is in principle possible but in general expensive 594 as it requires some serious development and programming efforts. 596 18. SNMP seems to work reasonable well for small devices which have 597 a limited number of managed objects and where end-user 598 management applications are shipped by the vendor. For more 599 complex devices, SNMP becomes too expensive and too hard to use. 601 19. There is a disincentive for vendors to implement SNMP equivalent 602 MIB modules for all their CLI commands because they do not see a 603 value proposition. This undermines the value of third party 604 standard SNMP solutions. 606 20. Rapid feature development is in general not compatible with the 607 standardization of the configuration interface. 609 5. Consolidated Observations 611 1. Programmatic interfaces have to provide full coverage otherwise 612 they will not be used by network operators since they have to 613 revert to CLIs anyway. 615 2. Operators perceive that equipment vendors do not implement MIB 616 modules in a timely manner. Neither read-only nor read-write 617 MIB modules are available on time today. 619 3. The attendees perceive that right now it is too hard to 620 implement useful MIB modules inside network equipment. 622 4. Because of the previous items, SNMP is not widely used today for 623 network device configuration, although there are notable 624 exceptions where SNMP is used for configuration today. 626 5. It is necessary to clearly distinguish between configuration 627 data and operational data. 629 6. It would be nice to have a single data definition language for 630 all programmatic interfaces (in case there happen to be multiple 631 programmatic interfaces). 633 7. There is a lack of input in general from the enterprise network 634 space. Those enterprises who provided input tend to operate 635 their networks like network operators. 637 8. It is required to be able to dump and reload a device 638 configuration in a textual format in a standard manner across 639 multiple vendors and device types. 641 9. It is desirable to have a mechanism to distribute configurations 642 to devices under transactional constraints. 644 10. Eliminating SNMP altogether is not an option. 646 11. Robust access control is needed. In addition, it is desirable 647 to be able to enable/disable individual MIB modules actually 648 implemented on a device. 650 12. Textual configuration files should be able to contain 651 international characters. Human-readable strings should be in 652 some least-bad internationalized character set and encoding, 653 which this year almost certainly means UTF-8. Protocol elements 654 should be in case insensitive ASCII. 656 13. The deployed tools for event/alarm correlation, root cause 657 analysis and logging are not sufficient. 659 14. There is a need to support a human interface and a programmatic 660 interface. 662 15. The internal method routines for both interfaces should be the 663 same to ensure that data exchanged between these two interfaces 664 is always consistent. 666 16. The implementation costs have to be low on devices. 668 17. The implementation costs have to be low on managers. 670 18. The specification costs for data models have to be low. 672 19. Standardization costs for data models have to be low. 674 20. There should be a single data modeling language with a human 675 friendly syntax. 677 21. The data modeling language must support compound data types. 679 22. There is a need for data aggregation capabilities on the 680 devices. 682 23. There should be a common data interchange format for instance 683 data which allows easy post-processing and analysis. 685 24. There is a need for a common data exchange format with single 686 and multi-system transactions (which implies rollback across 687 devices in error situations). 689 25. There is a need to reduce the semantic mismatch between current 690 data models and the primitives used by operators. 692 26. It should be possible to perform operations on selected subsets 693 of management data. 695 27. It is necessary to discover the capabilities of devices. 697 28. There is a need for a secure transport, authentication, 698 identity, and access control which integrates well with existing 699 key and credential management infrastructure. 701 29. It must be possible to define task oriented views and access 702 control rules. 704 30. The complete configuration of a device should be doable with a 705 single protocol. 707 31. A configuration protocol must be efficient and reliable and it 708 must scale in the number of transactions and the number of 709 devices. 711 32. Devices must be able to support minimally interruptive 712 configuration deltas. 714 33. A solution must support function call semantics (methods) to 715 implement functions such as a longest prefix match on a routing 716 table. 718 6. Recommendations 720 1. The workshop recommends that the IETF should stop to force 721 working groups to provide writable MIB modules. It should be the 722 decision of the working group whether they want to provide 723 writable objects or not. 725 2. The workshop recommends that a group should be formed to 726 investigate why current MIB modules do not contain all the 727 objects needed by operators to monitor their networks. 729 3. The workshop recommends that a group should be formed to 730 investigate why the current SNMP protocol does not satisfy all 731 the monitoring requirements of operators. 733 4. The workshop recommends with strong consensus from both protocol 734 developers and operators that the IETF focuses resources on the 735 standardization of configuration management mechanisms. 737 5. The workshop recommends with strong consensus from the operators 738 and rough consensus from the protocol developers that the IETF/ 739 IRTF should spend resources on the development and 740 standardization of XML-based device configuration and management 741 technologies (such as common XML configuration schemas, exchange 742 protocols and so on). 744 6. The workshop recommends with strong consensus from the operators 745 and rough consensus from the protocol developers that the IETF/ 746 IRTF should not spend resources on developing HTML-based or HTTP- 747 based methods for configuration management. 749 7. The workshop recommends with rough consensus from the operators 750 and strong consensus from the protocol developers that the IETF 751 should continue to spend resources on the evolution of the SMI/ 752 SPPI data definition languages as being done in the SMIng working 753 group. 755 8. The workshop recommends with split consensus from the operators 756 and rough consensus from the protocol developers that the IETF 757 should spend resources on fixing the MIB development and 758 standardization process. 760 The workshop also discussed the following items and achieved rough 761 consensus but did not make a recommendation. 763 1. The workshop had split consensus from the operators and rough 764 consensus from the protocol developers that the IETF should not 765 focus resources on CIM extensions. 767 2. The workshop had rough consensus from the protocol developers 768 that the IETF should not spend resources on COPS-PR development. 769 The operators so far have only very limited experience with COPS- 770 PR. In general, however, they felt that further development of 771 COPS-PR might be a waste of resources as they assume that COPS-PR 772 does not really address their requirements. 774 3. The workshop had rough consensus from the protocol developers 775 that the IETF should not spend resources on SPPI PIB definitions. 776 The operators had rough consensus that they do not care about 777 SPPI PIBs. 779 7. Security Considerations 781 This document is a report of an IAB Network Management workshop. As 782 such it does not have any direct security implications for the 783 Internet. 785 8. Acknowledgments 787 The editor likes to thank Dave Durham, Simon Leinen and John 788 Schnizlein for taking detailed minutes during the workshop. 790 Normative References 792 [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, 793 "Introduction and Applicability Statements for the 794 Internet-Standard Management Framework", RFC 3410, 795 December 2002. 797 [CIM] Distributed Management Task Force, "Common Information 798 Model (CIM) Specification Version 2.2", DSP 0004, June 799 1999. 801 [RFC3060] Moore, B., Ellesson, E., Strassner, J. and A. Westerinen, 802 "Policy Core Information Model -- Version 1 803 Specification", RFC 3060, February 2001. 805 [RFC2748] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R. 806 and A. Sastry, "COPS Usage for Policy Provisioning (COPS- 807 PR)", RFC 2748, January 2000. 809 [RFC3084] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, 810 K., Herzog, S., Reichmeyer, F., Yavatkar, R. and A. Smith, 811 "COPS Usage for Policy Provisioning (COPS-PR)", RFC 3084, 812 March 2001. 814 [XML] Bray, T., Paoli, J. and C. Sperberg-McQueen, "Extensible 815 Markup Language (XML) 1.0", W3C Recommendation, February 816 1998. 818 Informative References 820 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 821 MIB", RFC 2863, June 2000. 823 [XSD] David, D., "XML Schema Part 0: Primer", W3C 824 Recommendation, May 2001. 826 Author's Address 828 Juergen Schoenwaelder 829 University of Osnabrueck 830 Albrechtstr. 28 831 49069 Osnabrueck 832 Germany 834 Phone: +49 541 969-2483 835 EMail: schoenw@informatik.uni-osnabrueck.de 837 Appendix A. Participants 839 Ran Atkinson Extreme Networks 840 Rob Austein InterNetShare 841 Andy Bierman Cisco Systems 842 Steve Bellovin AT&T 843 Randy Bush AT&T 844 Leslie Daigle VeriSign 845 David Durham Intel 846 Vijay Gill 847 Wes Hardaker Network Associates Laboratories 848 Ed Kern 849 Simon Leinen Switch 850 Ken Lindahl University of California Berkeley 851 David Partain Ericsson 852 Andrew Partan UUnet/Verio/MFN 853 Vern Paxson ICIR 854 Aiko Pras Univeristy of Twente 855 Randy Presuhn BMC Software 856 Juergen Schoenwaelder University of Osnabrueck 857 John Schnizlein Cisco Systems 858 Mike St. Johns 859 Ruediger Volk Deutsche Telekom 860 Steve Waldbusser 861 Margaret Wassermann Windriver 862 Glen Waters Nortel Networks 863 Bert Wijnen Lucent 865 Full Copyright Statement 867 Copyright (C) The Internet Society (2003). All Rights Reserved. 869 This document and translations of it may be copied and furnished to 870 others, and derivative works that comment on or otherwise explain it 871 or assist in its implementation may be prepared, copied, published 872 and distributed, in whole or in part, without restriction of any 873 kind, provided that the above copyright notice and this paragraph are 874 included on all such copies and derivative works. However, this 875 document itself may not be modified in any way, such as by removing 876 the copyright notice or references to the Internet Society or other 877 Internet organizations, except as needed for the purpose of 878 developing Internet standards in which case the procedures for 879 copyrights defined in the Internet Standards process must be 880 followed, or as required to translate it into languages other than 881 English. 883 The limited permissions granted above are perpetual and will not be 884 revoked by the Internet Society or its successors or assigns. 886 This document and the information contained herein is provided on an 887 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 888 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 889 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 890 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 891 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 893 Acknowledgement 895 Funding for the RFC Editor function is currently provided by the 896 Internet Society.