RFC 3535

Overview of the 2002 IAB Network Management Workshop

📅 published May 2003, from ietf

Overview of the 2002 IAB Network Management Workshop ✨

okay bestie, this RFC is an informational report 📚 by J. Schoenwaelder from International University Bremen. It's RFC 3535, it lives in the Network Working Group, it's dated May 2003, and its category is Informational 🎀. It's a workshop recap, not a standard, so nobody's forced to implement anything here 🫶

Status of this Memo 📜

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

Copyright (C) The Internet Society (2003). All Rights Reserved.

Abstract 🌸

okay so this document gives an overview of a workshop the Internet Architecture Board (IAB) held on Network Management 🍓 It was hosted by CNRI in Reston, VA, USA on June 4 thru June 6, 2002. The whole point was to keep the important conversation going between network operators and protocol developers, and to steer the IETF's focus on future network management work ✨ This report sums up the discussions and lists the conclusions and recommendations for the Internet Engineering Task Force (IETF) community 💅

Table of Contents 🗂️

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
2. Network Management Technologies  . . . . . . . . . . . . . . .  3
     2.1 SNMP / SMI / MIBs  . . . . . . . . . . . . . . . . . . .  4
     2.2 COPS-PR / SPPI / PIBs  . . . . . . . . . . . . . . . . .  5
     2.3 CIM / MOF / UML / PCIM . . . . . . . . . . . . . . . . .  6
     2.4 CLI / TELNET / SSH . . . . . . . . . . . . . . . . . . .  7
     2.5 HTTP / HTML  . . . . . . . . . . . . . . . . . . . . . .  8
     2.6 XML  . . . . . . . . . . . . . . . . . . . . . . . . . .  9
3. Operator Requirements  . . . . . . . . . . . . . . . . . . . . 10
4. SNMP Framework Discussions . . . . . . . . . . . . . . . . . . 12
5. Consolidated Observations  . . . . . . . . . . . . . . . . . . 14
6. Recommendations  . . . . . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations  . . . . . . . . . . . . . . . . . . . 17
8. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 17
Normative References  . . . . . . . . . . . . . . . . . . . . . . 18
Informative References  . . . . . . . . . . . . . . . . . . . . . 18
Appendix - Participants . . . . . . . . . . . . . . . . . . . . . 19
Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . 19
Full Copyright Statement  . . . . . . . . . . . . . . . . . . . . 20

1. Introduction ✨

okay so the IETF has kicked off a bunch of operations and management work 🧚 to help network operators run their networks. The big network management technologies being built in the IETF right now are:

  • The Simple Network Management Protocol (SNMP) [RFC3410] was created in the late 1980s 🦋 The first version (SNMPv1) is widely deployed, and the newest one (SNMPv3), which handles security requirements, is just starting to get real deployment momentum 📈
  • The Common Information Model (CIM) [CIM], developed by the Distributed Management Task Force (DMTF), was extended in cooperation with the DMTF to describe high-level policies as rule sets (PCIM) [RFC3060] 💜 Mappings of the CIM policy extensions to LDAP schemas have been defined, and work is still going on to define specific schema extensions for QoS and security policies.
  • The Common Open Policy Service (COPS) [RFC2748] protocol was extended to provision configuration information on devices (COPS-PR) [RFC3084] 🎀 Work is underway to define data definitions for specific services, such as Differentiated Services (DiffServ).

During 2001, several meetings were organized at various events (NANOG-22 May 2001, RIPE-40 October 2001, LISA-XV December 2001, IETF-52 December 2001) to start a direct dialog between network operators and protocol developers 🗣️ In those meetings, several operators said the IETF's developments don't really address their requirements, especially for configuration management 😭 This naturally raises the question of whether the IETF should refocus its resources, and which strategic future activities in the operations and management area should get started 🤔

The Internet Architecture Board (IAB) held an invitational workshop on network management from June 4 thru June 6, 2002 🌈 The goal was to keep the important dialog going between network operators and protocol developers, and to steer the IETF's focus on future network management work.

The workshop kicked off with two breakout sessions to (a) identify a list of technologies relevant for network management, along with their strengths and weaknesses, and to (b) identify the most important operator needs 🍓 The results of these discussions are documented in Section 2 and Section 3. In the discussions that followed, many more specific characteristics of the current SNMP framework came up, and those are documented in Section 4. Section 5 defines a combined feature list that came out of the discussions after the breakout sessions. Section 6 gives concrete recommendations to the IETF 👑

The following text makes no explicit distinction between different versions of SNMP 🙈 For most of the SNMP-related statements, the protocol version doesn't matter. Still, some statements fit SNMPv1/SNMPv2c environments better, while others (especially the ones about security) fit SNMPv3 environments better.

2. Network Management Technologies 🛠️

During the breakout sessions, the protocol developers put together a list of the network management technologies that are available or under active development 💅 For each technology, they identified a list of strong (+) and weak (-) points. Some characteristics seemed neutral (o), too.

The list doesn't try to be complete 🙃 The focus was on IETF-specific technologies (SNMP, COPS-PR, PCIM) and widely used proprietary technologies (CLI, HTTP/HTML, XML). Other generic management technologies (such as TL1, CORBA, CMIP/GDMO, TMN), and specific management technologies for particular problem domains (such as RADIUS, DHCP, BGP, OSPF), were acknowledged but weren't the focus of the discussion 🫶

2.1 SNMP / SMI / MIBs 🌸

SNMP was created in the late 1980s and has since been widely implemented and deployed across the Internet ✨ There's loads of implementation and operational experience, so the technology's characteristics are well understood 🧠

  • + SNMP works reasonably well for device monitoring. The stateless nature of SNMP is useful for statistical and status polling 📊
  • + SNMP is widely deployed for basic monitoring. Some core MIB modules, such as the IF-MIB [RFC2863], are implemented on most networking devices 🔥
  • + There are many well-defined proprietary MIB modules, developed by network device vendors to support their management products 💜
  • + SNMP is an important data source for systems that do event correlation, alarm detection, and root cause analysis 🕵️‍♀️
  • o SNMP requires applications to be useful 🙄 From its early days, SNMP was designed as a programmatic interface between management applications and devices. So using SNMP without management applications or smart tools seems a lot more complicated 😵‍💫
  • o Standardized MIB modules often lack writable MIB objects that can be used for configuration. That leads to a situation where the interesting writable objects live in proprietary MIB modules 🙃
  • - There are scaling problems with the number of objects in a device 🐌 SNMP gives reasonable performance for retrieving a small amount of data from many devices, but it gets pretty slow when retrieving large amounts of data (such as routing tables) from a few devices.
  • - There's too little deployment of writable MIB modules 💀 There are some notable exceptions, such as cable modems, where writable MIB modules are essential. But router equipment is usually not fully configurable via SNMP, which is a bummer.
  • - The SNMP transactional model and the protocol constraints make it more complex to implement MIBs than to implement commands in a command line interface interpreter 🧩 A logical operation on a MIB can turn into a sequence of SNMP interactions, where the implementation has to keep state until the operation completes or a failure is detected. When there's a failure, a robust implementation must be smart enough to roll the device back into a consistent state.
  • - SNMP doesn't make it easy to retrieve and play back configurations 😩 Part of the problem is that it's hard to identify configuration objects. Another part is that the naming system is very specific, so physical device reconfigurations can break the ability to play back a previous configuration.
  • - There's often a semantic mismatch between the task-oriented view of the world that operators prefer and the data-centric view of the world that SNMP provides 🫠 Mapping from a task-oriented view to the data-centric view often takes some non-trivial code on the management application side.
  • - Several standardized MIB modules don't describe high-level procedures 🗺️ It's often not obvious from reading the MIB modules how certain high-level tasks get done. That leads to several different ways of reaching the same goal, which increases costs and hinders interoperability 💔

A more detailed discussion of the SNMP management technology can be found in Section 4 🦋

2.2. COPS-PR / SPPI / PIBs ✨

okay so COPS was defined way back in the late 1990s to handle policy control over QoS signaling protocols 🎀. Then the COPS-PR extension came along and let you provision policy information on devices 💅. It's giving "upgrade" energy, ngl.

Here's why COPS-PR is lowkey iconic 👑:

  • COPS-PR does high-level transactions for single devices, like deleting one configuration and swapping in another 🦋.
  • COPS-PR's instance namespace doesn't overlap with anyone else's, so no other manager can mess with a specific configuration 🫶. Every transaction for a given instance namespace MUST be executed in-order 💖.
  • Manager and device states are completely synchronized with each other at all times 🌸. If communication fails, the state gets resynchronized once the network is working properly again and the device's network configuration is valid ✨.
  • Transaction atomicity is well-defined 🔥. If a transaction fails, that specific failure gets reported to the manager, and the local configuration is supposed to be automatically rolled back to the state of the last "good" transaction 😭.
  • Capability reporting is part of the framework PIB, and COPS-PR implementations MUST support it 💜. This lets management applications adapt to what a device can actually do 🧚.
  • COPS-PR is all about configuration, and the protocol is optimized for that. For example, it uses TCP as its transport mechanism 🌈.

The downsides are real too, so let's be honest bestie 🙈:

  • Only a single manager is allowed to have control at any point in time for a given subject category on a device. (The subject category maps to a COPS Client-Type.) This single manager assumption keeps the protocol simpler because shared state is easier to maintain 💅.
  • Similar to SNMP, COPS-PR SHOULD be useful to applications, since it's also designed as a programmatic interface between management applications and devices 🍓.
Ngl, these ones are the real tea ☕💀
  • As of the time of the meeting, there are no standardized PIB modules 😭.
  • Compared to SNMP, there isn't yet enough experience to understand the strong and weak aspects of the protocol in operational environments 🙈.
  • COPS-PR doesn't support easy retrieval and playback of configurations. The reasons are similar to SNMP's 💀.
  • COPS-PR's view of the world is data-centric, just like SNMP's. Mapping from the data-centric view to a task-oriented view, and back, has similar complexities to SNMP 🌸.

2.3. CIM / MOF / UML / PCIM 🦋

The Common Information Model (CIM) [CIM] started developing in the DMTF in the mid 1990s 💖. It follows a top-down approach: core classes get defined first and extended later to model specific services 🧚. The DMTF and the IETF jointly developed policy extensions of CIM, known as PCIM [RFC3060] 🤝.

Why CIM is giving main character energy:

  • CIM follows object-orientation principles with full support for methods on data objects, which SNMP and COPS-PR just don't have 👑.
  • The MOF format lets you represent instances in a common format. SNMP and COPS-PR have no such common format 🎀. You could store instances as BER encoded ASN.1 sequences, but that's generally not great for human readability 🙈.
  • CIM has a query facility for locating CIM objects 🔍. However, the query language isn't specified as part of the CIM standards yet, so implementations use proprietary ones like the Windows Management Instrumentation Query Language (WQL) 💀.
  • CIM's information modeling uses Unified Modeling Language (UML) as a graphical notation. That attracts people with a computer science background who learned UML in school 🫶.

The tea on CIM 🍵:

  • The main practical use of CIM schemas today seems to be defining data structures used internally by management systems 🌸.
  • CIM schemas have pretty complex interrelationships that you need to understand before you can reasonably extend the existing schemas 😭.
  • Interoperability between CIM implementations seems problematic compared to the number of interoperable SNMP implementations available today 💅.
  • So far, CIM schemas have seen limited implementation and usage as an interface between management systems and network devices 🥲.

2.4. CLI / TELNET / SSH 💜

Most devices have a builtin command line interface (CLI) for configuration and troubleshooting 🖥️. Network access to the CLI has traditionally gone through TELNET, but SSH is gaining momentum to address the security issues associated with TELNET 🔐. In the following, only CLIs that actually parse and execute commands are considered. (Menu-oriented interfaces are difficult for automation and thus not relevant here 🙅‍♀️.)

The good stuff 🌈:

  • CLIs are generally task-oriented, which makes them easier for human operators to use 💖.
  • A saved sequence of textual commands can easily be replayed, and simple substitutions can be made with arbitrary text processing tools 🦋.
  • You usually have to learn at least parts of a new device's CLI to create the initial configuration. Once people know (parts of) it, it's natural to reuse the same interface and abstractions for automating configuration changes 🧚.
  • CLIs don't need any special purpose applications, since telnet and ssh are readily available on most systems today 🎀.
  • Most CLIs provide context sensitive help that reduces the learning curve 🌸.

The messy part 😭:

  • Some CLIs lack a common data model. The same command can behave differently on different devices, even from the same vendor 💀.
  • The CLI is primarily targeted at humans, who can adapt to minor syntax and format changes easily. Using CLIs as a programmatic interface is troublesome because of parsing complexities 🙈.
  • CLIs often lack proper version control for syntax and semantics. It's therefore time consuming and error prone to maintain programs or scripts that interface with different CLI versions 🥲.
  • CLIs are proprietary, so they can't be used efficiently to automate processes in an environment with a heterogeneous set of devices 💅.
  • Access control facilities, if present at all, are often ad-hoc and sometimes insufficient 🔓.

2.5. HTTP / HTML 🌸

Many devices have an embedded web server that can be used to configure the device and obtain status information 🌐. The commonly used protocol is HTTP, and information is rendered in HTML. Some devices also expect clients to have facilities such as Java or JavaScript ☕.

The wins 🏆:

  • Embedded web servers for configuration are end-user friendly and solution oriented 💖.
  • They're suitable for configuring consumer devices by inexperienced users 🫶.
  • Web server configuration is widely deployed, especially in boxes targeted at the consumer market 🧚.
  • No specialized applications are needed to use embedded web servers, since web browsers are commonly available today 🦋.

The not-so-cute part 💀:

  • Embedded web servers are management application hostile. Parsing HTML pages to extract useful information is extremely painful 😭.
  • Replaying configuration is often problematic, either because the web pages rely on active content or because different versions of the same device interact with the user in different ways 🙈.
  • Access control facilities, if present at all, are often ad-hoc and sometimes insufficient 🔓.

2.6. XML 🎀

In the late 1990s, some vendors started using the Extensible Markup Language (XML) [XML] to describe device configurations, and for protocols that retrieve and manipulate XML formatted configurations 📄.

Why XML is slay 💅:

  • XML is a machine readable format that's easy to process, and there are lots of good off the shelf tools available 🛠️.
  • XML allows the description of structured data of almost arbitrary complexity 🦋.
  • The basic syntax rules behind XML are relatively easy to learn 🌈.
  • XML provides a document-oriented view of configuration data (similar to many proprietary configuration file formats) 🌸.
  • XML has a robust schema language, XSD [XSD], for which many good off the shelf tools exist ✨.

The catch 🙃:

  • XML alone is just syntax. XML schemas MUST be carefully designed to make XML truly useful as a data exchange format 💜.
  • XML is rather verbose. This either increases the bandwidth required to move management information around (an issue in e.g., wireless or asymmetric cable networks), or it requires the systems involved to have the processing power to do on-the-fly compression and decompression 😭.
  • There's a lack of commonly accepted standardized management-specific XML schemas 💀.

3. Operator Requirements 📋✨

okay so during the breakout session, the operators were asked to spill the tea on needs that haven't been properly addressed yet 💅. The results got discussed afterwards and turned into this list of operator requirements 🎀

  1. Ease of use is a key requirement for any network management technology from the operators point of view 💖.
  2. It is necessary to make a clear distinction between configuration data, data that describes operational state and statistics. Some devices make it very hard to determine which parameters were administratively configured and which were obtained via other mechanisms such as routing protocols 🙈.
  3. It is required to be able to fetch separately configuration data, operational state data, and statistics from devices, and to be able to compare these between devices 🔍.
  4. It is necessary to enable operators to concentrate on the configuration of the network as a whole rather than individual devices 🌐.
  5. Support for configuration transactions across a number of devices would significantly simplify network configuration management 🧚.
  6. Given configuration A and configuration B, it should be possible to generate the operations necessary to get from A to B with minimal state changes and effects on network and systems. It is important to minimize the impact caused by configuration changes 🦋.
  7. A mechanism to dump and restore configurations is a primitive operation needed by operators. Standards for pulling and pushing configurations from/to devices are desirable 💜.
  8. It must be easy to do consistency checks of configurations over time and between the ends of a link, so you can figure out the changes between two configurations and whether those configurations are consistent 🔥.
  9. Network wide configurations are typically stored in central master databases and transformed into formats that can be pushed to devices, either by generating sequences of CLI commands or complete configuration files that are pushed to devices. There is no common database schema for network configuration, although the models used by various operators are probably very similar. It is desirable to extract, document, and standardize the common parts of these network wide configuration database schemas 🌸.
  10. It is highly desirable that text processing tools such as diff, and version management tools such as RCS or CVS, can be used to process configurations, which implies that devices should not arbitrarily reorder data such as access control lists 📝.
  11. The granularity of access control needed on management interfaces needs to match operational needs. Typical requirements are a role-based access control model and the principle of least privilege, where a user can be given only the minimum access necessary to perform a required task 🔐.
  12. It must be possible to do consistency checks of access control lists across devices 🧐.
  13. It is important to distinguish between the distribution of configurations and the activation of a certain configuration. Devices should be able to hold multiple configurations 🎀.
  14. SNMP access control is data-oriented, while CLI access control is usually command (task) oriented. Depending on the management function, sometimes data-oriented or task-oriented access control makes more sense. As such, it is a requirement to support both data-oriented and task-oriented access control 👑.

So far, there is no published document that clearly defines the requirements of the operators 😭.

4. SNMP Framework Discussions 🕸️

during the discussions, a bunch of properties of the SNMP framework got identified, and honestly some of them are a lot 💀.

  1. It is usually not possible to retrieve complete device configurations via SNMP, so you can't compare them with previous configurations or check them for consistency across devices. There is usually only incomplete coverage of device features via the SNMP interface, and there is a lack of differentiation between configuration data and operational state data for many features 🙃.
  2. The quality of SNMP instrumentations is sometimes disappointing. SNMP access sometimes crashes systems or returns wrong data 😬.
  3. MIB modules and their implementations are not available in a timely manner (sometimes MIB modules lag years behind), which forces users to use the CLI 🥲.
  4. Operators view current SNMP programming and scripting interfaces as being too low-level, and thus too time consuming and inconvenient for practical use 🐢.
  5. Lexicographic ordering is sometimes artificial with regard to internal data structures, and causes either significant runtime overhead, or increases implementation costs or implementation delay, or both 🧮.
  6. Poor performance for bulk data transfers. The typical examples are routing tables 📚.
  7. Poor performance on query operations that were not anticipated during the MIB design. A typical example is the following query: Which outgoing interface is being used for a specific destination address? 🤔
  8. The SNMP credentials and key management are considered complex, especially since they do not integrate well with other existing credential and key management systems 🔑.
  9. The SMI language is hard to deal with and not very practical 🙅‍♀️.
  10. MIB modules are often over-engineered in the sense that they contain lots of variables that operators do not look at 🫠.
  11. SNMP traps are used to track state changes, but often syslog messages are considered more useful, since they usually contain more information to describe the problem. SNMP traps usually require subsequent get operations to figure out what the trap really means 📣.
  12. Device manufacturers find SNMP instrumentations inherently difficult to implement, especially with complex table indexing schemes and table interrelationships 🧱.
  13. MIB modules often lack a description of how the various objects can be used to achieve certain management functions. (MIB modules can often be characterized as a list of ingredients without a recipe 🍰.)
  14. The lack of structured types and various RPC interactions (methods) makes MIB modules much more complex to design and implement 🧩.
  15. The lack of query and aggregation capabilities (reduction of data) causes efficiency and scalability problems 📉.
  16. The SNMP protocol was simplified in terms of the number of protocol operations and resource requirements on managed devices. It was not simplified in terms of usability by network operators or instrumentation implementors 💁‍♀️.
  17. There is a semantic mismatch between the low-level, data-oriented abstraction level of MIB modules and the task-oriented abstraction level desired by network operators. Bridging the gap with tools is in principle possible, but in general it is expensive, as it requires some serious development and programming efforts 🛠️.
  18. SNMP seems to work reasonably well for small devices which have a limited number of managed objects and where end-user management applications are shipped by the vendor. For more complex devices, SNMP becomes too expensive and too hard to use 📱.
  19. There is a disincentive for vendors to implement SNMP equivalent MIB modules for all their CLI commands, because they do not see a valued proposition. This undermines the value of third party standard SNMP solutions 🙄.
  20. Rapid feature development is in general not compatible with the standardization of the configuration interface 🚀.

part 3 of 4 is done, bestie 🌿✨ and we're really getting into the good stuff!

5. Consolidated Observations ✨

Okay bestie, here are the big takeaways the workshop kept coming back to 🧠💖

  1. Programmatic interfaces have to provide full coverage, otherwise network operators won't use them and will just fall back to CLIs anyway 💅
  2. Operators feel equipment vendors aren't implementing MIB modules on time. Neither read-only nor read-write MIB modules show up when they're needed today 😭
  3. The attendees feel it's way too hard to implement useful MIB modules inside network equipment 🙈
  4. Because of the previous items, SNMP isn't widely used for network device configuration today, though there are some notable exceptions 🌸
  5. It is necessary to clearly distinguish between configuration data and operational data 📋
  6. It would be nice to have one single data definition language for all programmatic interfaces (in case there happen to be multiple programmatic interfaces) 🧚
  7. There's a general lack of input from the enterprise network space. The enterprises that did show up tend to run their networks like network operators do 🏢
  8. It is required to be able to dump and reload a device configuration in a textual format, in a standard manner, across multiple vendors and device types 📄
  9. It is desirable to have a mechanism to distribute configurations to devices under transactional constraints 🔁
  10. Eliminating SNMP altogether is not an option. Literally not happening 🚫
  11. Robust access control is needed. It's also desirable to be able to enable or disable individual MIB modules actually implemented on a device 🔐
  12. Textual configuration files should be able to contain international characters. Human-readable strings should use the least-bad internationalized character set and encoding, which in this year almost certainly means UTF-8 🌈 Protocol elements should be in case insensitive ASCII 🎀
  13. The deployed tools for event and alarm correlation, root cause analysis and logging are not sufficient 😤
  14. There is a need to support both a human interface and a programmatic interface 🫶
  15. The internal method routines for both interfaces should be the same, so the data exchanged between these two interfaces is always consistent ✨
  16. The implementation costs have to be low on devices 💜
  17. The implementation costs have to be low on managers 💜
  18. The specification costs for data models have to be low 📝
  19. Standardization costs for data models have to be low 📝
  20. There should be a single data modeling language with a human friendly syntax 👑
  21. The data modeling language must support compound data types 🧩
  22. There is a need for data aggregation capabilities on the devices 📊
  23. There should be a common data interchange format for instance data that allows easy post-processing and analysis 🔍
  24. There is a need for a common data exchange format with single and multi-system transactions, which implies rollback across devices in error situations 🔙
  25. There is a need to reduce the semantic mismatch between current data models and the primitives operators actually use 🎯
  26. It should be possible to perform operations on selected subsets of management data 🍓
  27. It is necessary to discover the capabilities of devices 🔎
  28. There is a need for a secure transport, authentication, identity, and access control that integrates well with existing key and credential management infrastructure 🔐🦋
  29. It must be possible to define task oriented views and access control rules 👀
  30. The complete configuration of a device should be doable with a single protocol 🎀
  31. A configuration protocol must be efficient and reliable, and it must scale in the number of transactions and devices 🚀
  32. Devices must be able to support minimally interruptive configuration deltas 🌷
  33. A solution must support function call semantics (methods) to implement functions, such as a longest prefix match on a routing table 🧠

6. Recommendations 🔥

Here's what the workshop actually recommended, bestie. The consensus levels are doing a lot of work here 👀

  1. The workshop recommends that the IETF stop forcing working groups to provide writable MIB modules. It should be the decision of the working group whether they want to provide writable objects or not 🙅‍♀️
  2. The workshop recommends that a group be formed to investigate why current MIB modules do not contain all the objects operators need to monitor their networks 🔍
  3. The workshop recommends that a group be formed to investigate why the current SNMP protocol does not satisfy all the monitoring requirements of operators 🕵️‍♀️
  4. The workshop recommends, with strong consensus from both protocol developers and operators, that the IETF focus resources on the standardization of configuration management mechanisms 🏆
  5. The workshop recommends, with strong consensus from the operators and rough consensus from the protocol developers, that the IETF/IRTF should spend resources on the development and standardization of XML-based device configuration and management technologies (such as common XML configuration schemas, exchange protocols and so on) 💜
  6. The workshop recommends, with strong consensus from the operators and rough consensus from the protocol developers, that the IETF/IRTF should not spend resources on developing HTML-based or HTTP-based methods for configuration management 🙅‍♀️
  7. The workshop recommends, with rough consensus from the operators and strong consensus from the protocol developers, that the IETF should continue to spend resources on the evolution of the SMI/SPPI data definition languages as being done in the SMIng working group 🌸
  8. The workshop recommends, with split consensus from the operators and rough consensus from the protocol developers, that the IETF should spend resources on fixing the MIB development and standardization process 🛠️

The workshop also discussed the following items. They achieved rough consensus, but didn't make a recommendation 🤷‍♀️

  1. The workshop had split consensus from the operators and rough consensus from the protocol developers that the IETF should not focus resources on CIM extensions 🧊
  2. The workshop had rough consensus from the protocol developers that the IETF should not spend resources on COPS-PR development. So far, the operators have only very limited experience with COPS-PR. In general, though, they felt further development of COPS-PR might be a waste of resources, since they assume COPS-PR doesn't really address their requirements 💀
  3. The workshop had rough consensus from the protocol developers that the IETF should not spend resources on SPPI PIB definitions. The operators had rough consensus that they don't care about SPPI PIBs 😌

7. Security Considerations 🚨

This document is a report of an IAB Network Management workshop. As such, it does not have any direct security implications for the Internet. Phew 😮‍💨

8. Acknowledgments 🫶

The editor would like to thank Dave Durham, Simon Leinen and John Schnizlein for taking detailed minutes during the workshop. Real MVPs 👑

Normative References 📚

[RFC3410]  Case, J., Mundy, R., Partain, D. and B. Stewart,
           "Introduction and Applicability Statements for Internet-
           Standard Management Framework", RFC 3410, December 2002.

[CIM]      Distributed Management Task Force, "Common Information
           Model (CIM) Specification Version 2.2", DSP 0004, June
           1999.

[RFC3060]  Moore, B., Ellesson, E., Strassner, J. and A. Westerinen,
           "Policy Core Information Model -- Version 1
           Specification", RFC 3060, February 2001.

[RFC2748]  Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R.
           and A. Sastry, "The COPS (Common Open Policy Service)
           Protocol", RFC 2748, January 2000.

[RFC3084]  Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie,
           K., Herzog, S., Reichmeyer, F., Yavatkar, R. and A. Smith,
           "COPS Usage for Policy Provisioning (COPS-PR)", RFC 3084,
           March 2001.

[XML]      Bray, T., Paoli, J. and C. Sperberg-McQueen, "Extensible
           Markup Language (XML) 1.0", W3C Recommendation, February
           1998.

Informative References 📖

[RFC2863]  McCloghrie, K. and F. Kastenholz, "The Interfaces Group
           MIB", RFC 2863, June 2000.

[XSD]      David, D., "XML Schema Part 0: Primer", W3C
           Recommendation, May 2001.

Appendix - Participants 🧚

Ran Atkinson          Extreme Networks
Rob Austein           InterNetShare
Andy Bierman          Cisco Systems
Steve Bellovin        AT&T
Randy Bush            AT&T
Leslie Daigle         VeriSign
David Durham          Intel
Vijay Gill
Wes Hardaker          Network Associates Laboratories
Ed Kern
Simon Leinen          Switch
Ken Lindahl           University of California Berkeley
David Partain         Ericsson
Andrew Partan         UUnet/Verio/MFN
Vern Paxson           ICIR
Aiko Pras             Univeristy of Twente
Randy Presuhn         BMC Software
Juergen Schoenwaelder University of Osnabrueck
John Schnizlein       Cisco Systems
Mike St. Johns
Ruediger Volk         Deutsche Telekom
Steve Waldbusser
Margaret Wassermann   Windriver
Glen Waters           Nortel Networks
Bert Wijnen           Lucent

Author's Address 💌

Comments should be submitted to the <nm-ws@ops.ietf.org> mailing
list.

Juergen Schoenwaelder
International University Bremen
P.O. Box 750 561
28725 Bremen
Germany

Phone: +49 421 200 3587
EMail: j.schoenwaelder@iu-bremen.de
Copyright (C) The Internet Society (2003).  All Rights Reserved.

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works.  However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement 💖

Funding for the RFC Editor function is currently provided by the Internet Society. Thank you, Internet Society 🌈

📦 where this page comes from