20 March 2006, 0900-1045
Chairs: Andy Bierman, Simon Leinen
Security Advisor: Wes Hardaker
Notes: Shane Kerr and Simon Leinen (Jabber)
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.
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.
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.
Andy asks for a show of hands - a large majority is in favor of requesting well-known ports.
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.
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.
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.
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.
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.
Problem if use RPC model because you never get an end tag on your document.
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.
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.
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.
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.
The chairs closed the meeting with a plea for participants to review the notification draft.