12th NMRG Meeting Minutes, 22-23 March, 2003 Location: Colorado Springs, Colorado, USA Host: Intelliden (John Strassner) Note-takers: John Strassner, Juergen Schoenwaelder Attendees: * Olivier Festor * David Harrington * James Hong * Torsten Klie * Emmanuel Nataf * George Pavlou * David Perkins * Aiko Pras * Phil Shafer * Juergen Schoenwaelder * Frank Strauss * John Strassner * Bert Wijnen The meeting was held in accordance with the published agenda, with some minor changes and additions. Thus, the revised agenda will be used as an outline for the notes. The Agenda is as follows: Saturday (2003-03-22) (13:00 - 17:00) * Welcome * Select note takers and minute producers * Status reports * Recent achievements * 11th meeting minutes * OID compression paper * ITU SG 4 input on SNMP over TCP * Latest IETF news (new/closed WGs, rumors and mysteries) * SMIng status report (F. Strauss, J. Schoenwaelder) * SMI -> XSD translation and gateway (T. Klie, F. Strauss) * Plans for dinner Sunday (2003-03-23) (09:00-12:00, 13:00-17:00) * Short summary of the Saturday meeting * Bert's input and comment on the latest IETF news * SMI -> XSD wrap-up discussion * Technical XMLCONF discussion (Phil) * Wrap up and action items * Plans for dinner Please note that on Tuesday, at IM03, there is an important discussion from 17:00-18:30. It covers the following two topics: * IAB research funding document feedback * Restructuring and refocus of the NMRG After a welcome from John (the host) and introductions of the participants, the meeting began. ITEM: Recent Achievements (under Status reports) * RFC 3430: Simple Network Management Protocol Over Transmission Control Protocol Transport Mapping. This was published December 2002. * RFC 3440: On the Difference between Information Models and Data Models. This was published January 2003 Both of these documents are available on the website and through the IETF repository. Regarding OID compression, Aiko and Juergen were going to collaborate and try and produce a paper. No date given for completion. ITU SG-4 input on SNMP over TCP document went to Bert. A university in Asia tried to implement it. Level of detail wasn't very precise, so Juergen wrote a response (copied the NMRG list) but hasn't received a reply to this yet. ITEM: Latest IETF news * SMIng and EOS working groups will be shut down very soon. * SNMP is going into maintenance mode. A working group may be chartered to do this, but it will be given one task at a time and if it fails to complete a task, then the working group will be shut down. The other approach is to have a design team reporting directly to the OPS ADs. It was restated that SNMP is not useful for configuring routers. A couple of operators from the cable and ATM community said that they use SNMP MIBs, at which point Randy narrowed this to routers running IP. * PIBs will no longer be allowed on the standards track. In fact, further PIB work is going to be discouraged. However, COPS-PR is on the standards track, so if it is to be released, they need to prove that people are using COPS-PR with some PIBs. * Readable MIBs are still required from WGs where applicable * Writeable MIBs can be worked on, but are NOT required any longer. Note that there have been different interpretations of statements from various sources have been observed, making a precise interpretation of this statement impossible; group will ask Bert when he arrives. * XML configuration management working group renamed NetConf, and will be started soon. NetConf looks promising - readable MIBs are required, writable MIBs are optional. Some operators agreed to work on the NetConf document. Had gotten feedback that they needed to work on some underlying data model issues. * It is desired that operators co-chair OPS area working groups. This is likely to be enforced for the XML configuration management working group. * Wes thinks that SNMP fixes/evolution are still needed, even if XML might take over in the future, and in spite of the demise of the EOS and SMing working groups. Wes also thinks that SNMPv3 might benefit from a session based security model in order to integrate better with established authentication mechanisms. * Since PIBs and MIBs couldn't coexist, how can the data models for SNMP and NetConf coexist? (open question) * The following are notes from Dave, who attended the OPS area meeting: * AAA stuff: Bernard presented, said that AAA was being used by IEEE, 3GPP, and 3GPP2. 802.11 (wireless) has more of a strained relationship because they weren't sharing information with the IETF; this is perhaps going to be fixed soon. * Most people are reusing Radius instead of Diameter. No documents to do Key Distribution. IESG is holding up Diameter because security concerns haven't been addressed. * SIP is beginning to use Radius. SIP has pushed back against Diameter. SIPPING also is pushing back against Diameter. SIPPING is expressing interest in writing SNMP v3 MIBs for accounting. Cellular requirements are influencing Diameter. PPVPN is looking at using AAA. * Margaret reported on IPv6 Operations - they are focusing on coexistence, not transition. Currently analyzing scenarios for 3GPP and unmanaged networks; they want more input for Enterprise and ISP networks. They believe that both 3GPP and unmanaged networks need a dual stack. Hypothesis: the IETF is lacking an overall vision for how different efforts can cooperate and work together. Perhaps the NMRG could help by providing a technical vision that would help the ADs focus the various WGs. Other ideas were to develop a session based security model as well as a common bootstrap model. ITEM: SMIng Discussion * Since the SMIng WG is going to be closed down, these documents will be published by the NMRG. Olivier and Emmanuel developed a proxy agent which implements Juergen's and Frank's draft. They wanted to demonstrate the co-existence of SMIng and COPS-PR. * SMIng objects for usage by management applications that only operate on SMIng objects. * With SNMP, you can easily turn SNMP instance data into a set of SMIng objects. Might be possible to get the SMIng updates into the implementation. Note, however, that if there are no follow-on projects from industries or fora, this work might be stopped. * Dave Perkins asks how much semantic checking is being done, and whether there is a list of ambiguities. It would also be good to have the INRIA implementation consistent with the final SMIng documents. However, it is unlikely that libsmi will be upgraded to support the final SMIng document any time soon, since the INRIA implementation uses Java CC. * Action items: * Emmanuel will talk to Frank to get comments integrated into the current documents * Frank will contact COPS-PR mapping authors to see how we can update this document ITEM: SMI XSD translation and gateway * Torsten started discussion of this topic by using his IM presentation (“Towards XML-Oriented Internet Management”). Following are notes from his presentation: * Problems - a "low-level" technology, quite complicated, requires expensive experts. Also, it is difficult to move configuration between devices. Programming is done by side effect (e.g., set variables without clear semantics). XML may be the way out? Torsten's work depended on XML Schemata, since through that it could ensure the integrity of XML documents through former grammars. Note that the "proprietary database of SNMP data" phrase on slide 4 causes some lively discussion. :) * Mapping MIB Definitions to XML Schema Definitions is inherently difficult. This is because there is no form for creating standardized instance data from SMI. There are also many differences between producing a database of SNMP data (from MIBs based on the SMI) versus producing an XML document (based on XSDs). Furthermore, it is important to note that there isn’t a standard interchange format to exchange instance data even if two devices support the same MIB. Thus, the approach is to follow the XML style as close as possible, but keep supporting automatic translations. This would save investments on MIB definitions and implementations. * It is desired (by the authors) to have multiple "contexts" per XML Document. Examples of contexts may be per agent (e.g., IP Address, hostname or port), per-agent communities, or multiple points in time. Each of these can be their own context tag. * Problem - there are security issues - for example, since everything is text based, how can you secure one community from the other? This is a topic for future work. * The authors have developed a four-level element nesting. They use XML Namespaces to Identify Modules. Each MIB is compiled to separate XML Schema that defines an associated namespace; imports from MIB modules are translated to imports of namespaces. Elements can be uniquely identified with namespace prefixes. * Slide 9 - the SMI is bad, in that you can change enum values per rev of the MIB, leading to ambiguous data. Hopefully the XML mapping won't allow this? * Some suggestions for improving the structure of the document were given, including the use of complex types and a better explanation of how XPath or XQuery woudl be used to search within the documents. * Applications of this are potentially very powerful, and include configuration management (moving configuration data between devices and managers), notification processing (post-processing notifications that are stored as XML documents); agent validation (validating agent implementations of MIBs); SNMP/XML gateway (translate HTTP requests on XML documents to SNMP operations) * The following are comments given to the authors by the group: * Dave Harrington asks whether storing communities in the XML is not a security issue. * Dave Perkins asks what is being done about different versions of MIB modules. The SMIv2 allows to change names of named numbers which means the value representation might legally change between different MIB module revisions. * There are corner cases of OCTET STRING display hints which are not reversible. (Juergen might be able to find an example in his mailing list archives.) * Some information is lost in the translation (descriptors of intermediate node, OID identities and constants). * Dave Perkins asked whether it was considered to more index values into an index element rather than using XML attributes. Furthermore, the xpath example misses namespaces and looks nicer than it would be if it were spelled out. * Aiko asks whether the xpath filter interpreter really belongs into the gateway or not better into the management application using the gateway. Dave Perkins says that data might be stored in the gateway and updated regularly by a poller so that time domain queries are possible. * Both Daves think more future work is needed. * Bert asks what Frank's experiences are with writing XML Schema definitions. DAY TWO Juergen gave a quick summary of yesterday's meeting for the new people arriving. Bert was asked for further clarification on his view on MIBs. Bert stated that writeable objects for MIBs were no longer required, but if the working group deemed them appropriate, then they should be designed that way. Bert's concern is that operators aren't using SNMP or COPS-PR - therefore, writeable objects and configurable MIBs are probably not appropriate. People expressed to Bert a feeling that constructing writeable objects were discouraged. Bert responded that he was concerned that operators wouldn't use writeable objects; however, so long as the target audience needed writeable objects, go ahead. This is why he used the word 'discouraged'. Bert thinks that he should probably make a clearer expression, perhaps through an I-D, defining this. Bert said that NetConf will likely be started. However, one of his issues is finding the proper chairs. One of the chairs MUST be an operator. Regarding delaying work on the data model, Bert still isn't sure whether an additional working group focused on data modeling should be chartered or whether this work should be added into NetConf. Bert clarified that with respect to SMI fixes/evolution, they had tried very hard not to do SMI 2.1 because people had expressed the need for 'more'. However, SMIng has failed, so it appears that the best thing is to simply go to a working group focused on maintenance mode. We reviewed Torsten's paper again. It was observed that there needs to be a translation layer that will convert the MIB into the native objects required by the device. There is data that can be obtained from standard MIBs and even agents. However, there is no standard way to exchange or interoperate. ITEM: XMLCONF discussion * Phil starts with giving a presentation about XMLCONF. * Problem to solve directed at manual typing or usage of expect scripts. 50% of outages that triggered SLA violations at AOL were due to manual configuration errors. In addition, there is a fear that when an OS is upgraded, configurations will break in different ways. * Juniper has never had a customer request to enable SNMP writes. * Strategy – enable implementation to mirror native capabilities of the device. XML enables tight integration with CLI. Moreover, XML is all about data portability. XML works as conversion language between database and devices. * Phil's slide titled “The Real World” should really be called “The Ideal World”. NetConf is the line that can enable the transport to the device. Juniper has very few customers that operate like the "ideal world" model where the authoritative information is kept in a central database and all changes have to be made in the central database to be pushed to the devices. * NextHop Technologies, Cisco, Laurel or Foundry, Wind River, Juniper, RiverStone, and Intelliden all have XML APIs. Feedback from the NMRG is that the draft appears to be too full of compromises (i.e., the optional features that really need to be mandatory). * Dave Perkins said that XMLCONF is very different because there is an explicit asynchronous notification channel which is bound to a session. Additional channels might be added to support distribution of binary software images or for retrieval of statistics. * George says that XMLCONF could be improved by looking more at existing management protocols. * Remember that currently, the main focus of NetConf is configuration. Quite a bit more work is required to turn it into a complete management protocol. * Dave Perkins explains on the white board why getting access to SNMP notifications is hard for management application writers. * Olivier asks whether there is a mechanism to subscribe to certain sets of notifications. Currently, XMLCONF does not have this capability. * Juergen makes a statement that design decisions seem to be made out of feelings rather than being based on hard facts. For example, is BEEP as a transport a good viable choice? Is the home grown RPC layer really better than any of the existing layers? * A lengthy discussion ensues about SOAP vs. XMLCONF RPC and BEEP vs. SSH/TLS and the various implications on the manager/agent side. There is a tension between what the best technology is (e.g., the ongoing BEEP, SOAP, WSDL, et. al. arguments) versus what technologies the operators are currently using. On the one hand, we are a research group. On the other hand, we need to stay relevant. ITEM: Action items * Emmanuel will talk to Frank to get comments integrated into the revised SMIng documents * Frank will contact COPS-PR mapping authors to see how they can update this document * Torsten's and Frank's slides will be made available on the NMRG web site * Aiko will finish the minutes of the last NMRG meeting this week! * Dave Perkins will explain what a common model for booting is before the IM 2003 NMRG meeting and try to document things in written words * Phil to send his slides to the NMRG * Documentation of compression etc. work (Aiko, Juergen) * John Strassner to produce final minutes from the notes taken ITEM: Possible future NMRG items * Work on the network management vision that some people think is missing * Develop a session based security mechanism that integrates with AAA * Develop a common model for booting * Investigate XMLCONF design decisions and their implications, such as protocol mappings and RPC mechanisms * Map XMLCONF onto SOAP and prove that it does work (or does not work) * Experiment with Web Services for management (IF-MIB done as Web Services, Web Services toolkits, and prototypes that enable comparison of different functionality between web services vs. current management approaches * How to manage IPv6 networks * Management of upcoming technologies (e.g., VPNs) * Disappearing management and increased dependability – reduce the amount of management that is required while increasing the dependability of our networks * Cooperative (peer-to-peer) management rather than hierarchical management The Meeting adjourned.