Last Modified: 2005-07-13
|Done||Working Group formed|
|Done||Submit initial Netconf Protocol draft|
|Done||Submit initial Netconf over (transport-TBD) draft|
|Done||Begin Working Group Last Call for the Netconf Protocol draft|
|Done||Begin Working Group Last Call for the Netconf over (transport-TBD) draft|
|Done||Submit final version of the Netconf Protocol draft to the IESG|
|Done||Submit final version of the Netconf over SOAP draft to the IESG|
|Done||Submit final version of the Netconf over BEEP draft to the IESG|
|Done||Submit final version of the Netconf over SSH draft to the IESG|
NETCONF WG Minutes, IETF 63
IETF 63, Paris
Chairs: Simon Leinen, Andy Bierman (participating remotely)
This was the 8th meeting of the WG (including the interim).
AD Feedback on Submitted Documents
All 4 WG documents (prot, ssh, beep, soap) were submitted for publication. Bert Wijnen, the Area Director in charge of our WG, already provided some feedback. Besides a few minor bugs, Bert noticed that the prot document had a null IANA considerations section although it seems clear that the document does have IANA considerations. This issue may require discussion. "You may need/want a few registries".
Grouping of Documents for Publication
On the way through the approval process towards RFC publication, the prot and ssh documents should be treated together, while the beep and soap documents should advance separately.
MOME had an interoperability testing event last week, featuring nsis/ipfix/netconf. There were four netconf implementations present, two from commercial vendors and two from academic institutions. As a participant in the tests, James Hong provided some feedback.
Since there is no standard NETCONF data model, an ad-hoc one was defined for the tests. Some incompatibilities on the data model level were found between the implementations. In addition, the data model used for testing concerned interfaces. This made testing <edit-config> difficult, as successful configuration changes would typically break connectivity to the NETCONF agent.
Only the mandatory SSH mapping was tested. Participants reported there were small issues getting SSH to interoperate, in particular the message separator and the use of SSH subsystems posed problems. As these particular parts of the SSH mapping were modified during the WG process, the issues may be the result of implementations initially based on earlier versions of the specification, rather than issues with the current specification.
Two agent implementations lacked SSH transport and weren't tested.
there was one SOAP implementation. we felt it would have been easier to test. we did NOT really test edit-config.
According to James Hong, there were issues on how to handle "pipelined" requests. In the absence of the principal prot authors, this stirred some discussion on whether request pipelining is in fact permitted by the protocol as currently specified. Although each message can only contain a single <rpc> element, and each <rpc> element only a single method call, pipelining is explicitly permitted in the sense that an additional request may be send before the response was read.
The organizers will forward a summary to the NETCONF mailing list.
Dan Romascanu: Are there any recommendations for what the data
model should include regarding future work?
Sharon asked how the ad-hoc data model was described.
Bert has a generally positive impression from the results of the interoperability tests. There didn't seem to be any major problems with the protocol itself.
Status With Respect to Current Charter and Options for Going Forward
Simon reminds that the charter is a contract between the Working Group and the IETF. We have completed our current action items, but we have unmet goals, specifically around (fine-grained) locking and notifications. Notifications once were in the protocol but were dropped. The current charter also talks about XML usage guidelines that the group should develop, but this is very open ended - we should consider scope. Access control is another area that (like locking) was deferred because of interactions with the data model.
Simon listed several possible ways to go forward:
Lastly, the big question is whether or not to take on data modeling, and if so what would the scope of that work be?
Sharon's "NETCONF Phase 2 Musing"
Sharon presents her view of NETCONF development. Phase one has been completed now. Primary focus for protocol is on configuration, but we shouldn't preclude discussion on other forms of management, such as monitoring.
Notifications are useful for informing operators when a configuration has changed, as well as for security auditing purposes.
There is a draft available on an "SMI" for NETCONF. The intent is to foster interoperability without creating unnecessary rules. We should be careful as to what - if anything - gtes taken forward from the SNMP SMI.
As a proof of concept, there is an initial set of definitions for reusable application-level data types. There is also a definition of a schema for NETCONF reporting - which could be turned into a configuration schema. Other areas to work on include asynchronous messaging/event notification, access control, a method for deliverying software loads for NETCONF, and a method for multi-channel support. Some of this will have to be moved to a phase 3/phase N.
As next steps, Sharon proposes that the NETCONF event and data modeling work be added to the NETCONF charter as phase 2. Other work can be added as there is interest and resources available.
Gauging Interest in Additional Work and Experience with Existing Protocol
Simon: we must update the charter, and that charter will receive review by AD and IESG, and (provided IESG accepts it) the IETF. He asks Bert about his and the IESG's decision criteria. Bert responds that the normal criteria apply, such as the need for significant interest etc. But first he has a few questions to the room:
Bert asks the attendees Concerning any of the proposed new work items - who is in favor of those? About 10-12 people. Among these people, who has an implementation of NETCONF (including the SSH mapping)? Hardly any positive response, although one proponent claimed an implementation-in-progress. Bert points out that the one person in the room who was at the interoperability event last week didn't raise his hand. Bert has an issue with the fact that the people who want to add work items haven't worked on or experimented with implementations of what we have defined right now.
Dan Romascanu is in favor of additional work in the data model area in particular. The absence of a data model and the consequent lack of interoperability is a problem when talking about NETCONF both with customers and internally (about a proprietary system that could be migrated to a NETCONF base). He did not raise his hand on the second question because his company does not write protocols; they expect commercial or public domain products to become available, and are already experimenting with what's available.
Bert has more questions for the proponents of additional work items: How many of you have downloaded and experimented with the publicly available implementations? Still only a subset of the 10-12. How many have actually been working with operators to see if they'll use this protocol? A relatively large number. However it's not clear how useful this kind of feedback is until operators actually had the opportunity of playing with implementations. Bert reminds the group that we got here because operators weren't using many of the features that were added to SNMP over the years, such as writable MIBs, and he wants to be very prudent that we not miss the operators again. Through the OPS directorate, we asked operators - who made us start this work because they weren't happy with SNMP - to review the work and play with this stuff and make sure we've done the right thing before put in additional person-years to continue to develop this work. Please get other operators to comment.
Sharon: We have a preliminary implementation we've put in front of operators and they like the direction.
Sharon: Every single project group asks about asynchronous messaging. If we don't standardize asynchronous messaging, we'll have an interoperability mess in a few years as vendors will do their own thing. "Asynchronous messaging" describes a subscription-based information retrieval model as opposed to a poll/response one. A lot of applications - not just configuration-related - need this, but often it is used for supporting the bigger picture of configuration management. Sharon avoids the word "notifications" because people often think about the specific SNMP mechanism.
Kathleen Moriarty shares some thoughts from the perspective of a NETCONF customer, a large enterprise network and operator of various IPS (Intrusion Prevention Systems) from different vendors. Central management based on open standards would be very useful. Regulations such as Sarbanes-Oxley or the Federal Information Security Management Act (FISMA) mandate auditability of what changes were made when and by whom. A requirement for implementing NETCONF would be an open standard to do rollbacks. Another trend is to automate changes and rollbacks. Andy points out that detailed audit logs are different from rollback; NETCONF provides some rollback, but no auditing.
Simon hears this as another request for notifications. Existing configuration systems that we use already have very good notifications for configuration-related events, using SNMP traps/notifications and syslog. SNMP traps and syslog are perceived as too hard to integrate with configuration applications, so it seems attractive to integrate this into the NETCONF protocol. But we're not the only ones having this problem! He agrees with Andy that this group could work on notifications, but maybe we would duplicate existing work, or do work that should better be done elsewhere.
David Martin points out that although we decided early on that Web Services would be too heavy for NETCONF, it may be worthwhile to look at WS work in the area of notifications.
Andy reminds the group that the original NETCONF proposal was to use reliable syslog (RFC 3195), and explicitly not to invent anything new. Jürgen Schönwälder cautions that RFC 3195 has not seen widespread use in the almost four years since it was published. Sharon was involved in the syslog stuff, trawled through the Web Services stuff, and also looked at event subscription in SIP. The intent is not to invent unnecessarily.
Dave Perkins: On the auditing issue, we have a management application has the identity when you do a transaction. the user who pressed the button is not captured. [proxied discussion]
Darren Loher agrees with Andy's comment that an event system such as reliable syslog would be extremely valuable in general. Andy isn't sure whether RFC 3195 is the right choice, but he wants to avoid reinvention if possible
Data Model (and more on Notifications...)
Azita Kia: On the data model, and that there was a lot of work done in SNMP. NETCONF has been successful so far, but without a data model, it's just a protocol to exchange generic data. Creating a data model is a very big task. Can we do some incremental work, leveraging the wealth of SMI definitions and MIBs that have already been done, by XMLizing some of those?
Simon concedes that this could be a way forward, but also notes that MIBS and SNMP haven't been very successful for configuration.
Jim Golvinsky: Not having a reference data model makes the protocol useless. We end up with N-square integration points. I'm going to be flamed now. He finds notifications important, but is concerned that we would be ignoring all the work that has been done in Web Services and also in the DMTF.
Glenn Waters opines that the only way to build an integrated solution is to include notifications. Without them the protocol has a big hole. As to data models, we currently don't have a language to talk about data modeling. It's not sufficient to say "XML Schema". We need an SMI for XML, and need those rules to be put down in a single document. And we have to develop the language and then push the data model.
Closing Remarks of our Area Director
Bert says that in the past we've often heard "I'm channeling my customer's requirements." While I understand that few customers can make it here, we need to hear from them. I am willing to keep those communications private, but I'd like to hear from them. This was done because operators had expressed discontent with what was there, so they should be expected to review and comment.