IETF 63 NETCONF minutes

[Simon Leinen <simon@limmat.switch.ch>]

Here are the minutes from our last meeting, in ASCII format.  You'll find
the HTML version on http://ops.ietf.org/netconf/63/minutes.html as I have
submitted it to the IETF secretariat.  If you have any corrections or
additions please send them to me.
-- 
Simon.

                          NETCONF WG Minutes, IETF 63

   IETF 63, Paris
   Thursday, 4 August 2005, 0900-1000, room 341

   Chairs: Simon Leinen, Andy Bierman (participating remotely)
   Scribes: Eliot Lear (Jabber), Dan Romascanu (off-line)
   Minutes: Simon Leinen.

   This was the 8th meeting of the WG (including the interim).

Document Status

  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.

Interoperability Testing

   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.

  Data Model

   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.

  SSH Mapping

   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.

  Pipelining

   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.

  Discussion

   Dan Romascanu: Are there any recommendations for what the data model
   should include regarding future work?
   Simon: Having guidelines would be helpful.

   Sharon asked how the ad-hoc data model was described.
   James Hong said that the common model was a very simple XSD.

   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.

Charter Discussion

  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:
     * "declare victory and go home"
     * finish notifications (to fulfill charter to the letter)?
     * go dormant until we have enough implementation experience and
       operating experience and then review.

   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"

   (see slides)

   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.

  Discussion

    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.

    Notifications/Asynchronous Messaging

   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.
   Juergen Schoenwaelder 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.