Minutes from NETCONF meeting at IETF65

[simon@limmat.switch.ch]

Here are the draft minutes from our meeting in Dallas last month.
If you have any corrections or additions, please send to the list.  
We have about two weeks for making corrections, but please review
them as soon as possible.  An HTML version can be found on 

http://www3.ietf.org/proceedings/06mar/minutes/netconf.html

Many thanks to Shane Kerr for taking notes!

Regards,
-- 
Simon.

              IETF65 Minutes: NETCONF (Network Configuration) WG

   20 March 2006, 0900-1045

   Chairs: Andy Bierman, Simon Leinen
   Security Advisor: Wes Hardaker
   Notes: Shane Kerr and Simon Leinen (Jabber)

IESG evaluation of the four initial WG documents

   The four initial WG documents ("NETCONF v1") are ready for approval by
   the IESG. One remaining issue concerns how many TCP port numbers
   should be assigned to the different protocol mappings (SSH, BEEP,
   SOAP/BEEP, SOAP/HTTP), and from which ranges.

  Port Assignments

   There was a discussion on whether all NETCONF protocol mappings
   require separate port number assignments, in particular the NETCONF
   over SOAP mappings.

   Wes Hardaker argues for separate port assignments, to allow the
   protocols to be filtered separately at firewalls. Andy and Sharon
   Chisholm agree that for the (mandatory) SSH mapping, a separate port
   is warranted, but wonder whether this use of known ports conforms to
   current practice with SOAP-based protocols.

   Wes points out that implementations will support configuration of a
   different port, such as the standard SOAP-over-HTTP port. David Black
   points to the usefulness of having separate ports in case of multiple
   SOAP engines on a device.

   No clear consensus in the room on whether all mappings (in particular
   the SOAP mappings) require assigments of separate ports. Wes notes
   that operators - rather than protocol developers - should say whether
   they want to be able to filter NETCONF separately.

  Well-known vs. registered ports

   The "well-known" port range below 1024 can only be used with special
   privileges on some systems, in particular those based on BSD. The
   "registered" port range between 1024 and 32767 can be used by any
   process. There had been vivid discussion on both the NETCONF and the
   general IETF mailing lists, with no clear consensus emerging.

   Andy started the discussion by arguing that if SSH uses a low port,
   then NETCONF, as a replacement for SSH, should use low ports as well.

   Margaret Wasserman notes that this means the process has to run with
   privileges at least for a short time to get the port. Simon counters
   that the protocol is used for configuration of device, so it needs
   some priviliges anyway. In addition, there are now least-privilege
   techniques for dealing with this.

   Wes notes that a privileged port makes it harder to spoof the NETCONF
   agent.

    Show of hands

   Andy asks for a show of hands - a large majority is in favor of
   requesting well-known ports.

Experimental NETCONF Registry

   Andy suggested that it could be useful to have a shared "sandbox"
   namespace for experimental extensions to NETCONF. This would be
   pursued without impacting the status of the current documents.

   In the discussion, Andy pointed out the advantages of such a registry,
   which could provide a vendor-neutral home for extension work that is
   not yet ready for standardization in the NETCONF WG, and a way for
   others to learn what extensions are being worked on elsewhere. Sharon
   is concerned about having to change namespaces twice when moving from
   a private namespace to the shared sandbox, and then to the official
   namespace when publishing the specification - this could mean three
   different versions in a shipped product. Andy points out that people
   don't have to use this. Ralph Weber would find such a registry useful
   for other working groups such as imss who consider building protocols
   based on NETCONF.

   Andy senses a lukewarm response to his suggestion, and proposes to ask
   for this registry as an individual. Bert Wijnen says that there is a
   template for such requests, and possibly a requirement for expert
   review.

Implementation Guide

   Andy suggests to attempt to publish an implementation guide as an
   informational RFC later, when enough operational experience has been
   gathered. Sharon likes the idea; in implementing NETCONF, we are
   starting to see a number of ambiguities, so some clarifications would
   be useful.

   A discussion ensued about whether it would be problematic to clarify
   things in an implementation guide rather than a standard. Dave
   Harrington is worried, if you have a document that clarifies a
   standard, what happens to that document if the underlying standard is
   revised? Eliot sees no problem unless normative text changes.

   Andy suggests that the implementation guide would tell things that you
   have to do that may not be in specifications. Eliot says that if
   normative text has to be interpreted, then it would be best to revise
   the standard. Wes notes that the chances of not having to revise the
   spec are slim. Andy thinks we need to actually see those problems that
   come up.

NETCONF Event Notifications

   Only very few people in the room admitted to having read the draft and
   being familiar with it. The chairs would have liked it to have been
   more. In an effort to get people to pay attention to this draft, we go
   through the document in detail.

  Notification Architecture

    Share session with "normal" NETCONF RPCs vs. dedicated session for
    notifications (syslog and CLI on single channel?)

   Do we need to mix notifications and replies on a single channel?

   Eliot Lear: The model is flexible depending on transport, and we
   should take advantage of that; for example in BEEP it would be natural
   to use a separate channel for notifications. He finds it important
   that the direction of the connection is suitable for the type of
   device being managed.

   Sharon Chisholm: Anything that precludes shared types? When you get
   more advanced, you start seeing advantage to doing this on same
   connection. For example, future extensions such as notification replay
   are more natural when the channel is shared. Why preclude this?

   Andy Bierman: If it adds complexity without being useful, then it is
   harmful.

   Sharon: We went with the current model rather than a dedicated
   notification channel. There are times related to insuring everything
   is going well where you would want to do that. Andy asks why one would
   ever not be able to open another channel? Sharon claims this is just
   trading complexity in one place for another.

   Dave Perkins points out that if somebody is logging config changes,
   you would see more events. Andy counters that in his code, they are
   logged just the same.

   Rob Enns finds that the only real benefit is having fewer connections.

   Andy is worried that having operations and notifications on the same
   channel would lead to head-of line blocking. Sanjay Singh asks wheter
   if notifications are done on a different channel, wouldn't they still
   be subject to head of line blocking in routers? Simon clarifies we're
   not talking about blocking in the network, but rather blocking by
   ongoing RPC (in particular large RPC responses) on the NETCONF
   channel.

   Sharon suggests we should do a Plan A vs. Plan B list, then sit down
   with a table and make a less subjective decision. Dave Harrington
   believes we need to consider exactly how we plan to use notifications.

    Use RPC model or separate model for notification?

      One-way RPC vs. Plain Notification

   Sharon explains there were 3 options: (1) remove the RPC layer for
   notifications; (2) use "one-way RPC" enclosure as done in the current
   draft; or (3) keep this additional layer but call it something else,
   such as "one-way message". Andy suggests we should figure out what
   needs to go in the message, and make layering match that.

      Subscription vs. Long-lived RPC Model

   Problem if use RPC model because you never get an end tag on your
   document.

  Notification Configurability

   Do we need the ability to modify a notification subscription? Andy
   suggests that alternatively, one could just start a fresh connection
   with the new subscription. Sharon is concerned about resource
   limitations on the NMS side. For a manager managing 20000 routers,
   these additional connections might be too costly to maintain.

   Andy asks whether multiple subscriptions need to be supported on a
   channel. Sharon finds this a useful low-cost feature, for example to
   allow short-lived subscriptions to additional events. Eliot isn't sure
   whether it makes a real difference where the multiplexing is done.

  Notification Messages

   Andy asks why an event should have multiple classes. Shouldn't
   everything fit in one class? Sharon disagrees. Simon likes Sharon's
   approach, but finds the "class" terminology confusing. Maybe a concept
   of "tags" like used in Flickr would be more useful.

  Event Classes

   How should events be modeled?

   Andy sees lots of things that we don't need: The heartbeat could be
   provided by the underlying transport (Saron counters that these
   application-level heartbeats have different semantics); metrics seem
   way out of scope, such messages would belong to IPFIX.

   Sharon claims we either need an exhaustive list of what NETCONF
   implementations will be doing, or have an extensible mechanism. Rob
   finds that it sounds like we're discussing data modeling, to which
   Sharon responds that the intention is to maintain clear separation
   between data model and protocol. Andy concedes that we hvae to bring
   in a certain amount of data modeling, but comments that we should not
   invent a new syslog.

Other Topics

   Sharon thinks that statistics about NETCONF itself would be useful.
   Dave Harrington recommends to use a data model that already exists
   [SMI] until the NETCONF group does define a data model. Andy sees a
   lot of use in having simple counters for debugging.

   Sharon reports that the work on data modeling has been de-prioritized,
   but encourages discussion on the netconfmodel mailing list or
   informally at this IETF meeting. Input on access control would be most
   welcome.

   Dan Romascanu concerning both data models and access control: if
   people have been experimenting in these areas, it would be best to
   make this work known.

   Andy about access control: He initially thought the SNMP approach with
   its fine-grained controls would be best, but it doesn't seem to be
   that useful. He's looking at a container model now. That may not be
   enough, but less granularity than SNMP should be sufficient.

Closing

   The chairs closed the meeting with a plea for participants to review
   the notification draft.