[replies to either the netconf list if you are a member or to me, and I will forward them *directly* to the netconf list unless instructed NOT to do so.] Dear NANOG folk, The NETCONF working group of the IETF is currently developing a collection of protocol specifications for the configuration of network elements. This work originated from a roadshow that many of us went on to learn what operators of different types want in such a protocol. Now we would like to checkpoint with you on some of the contents of those specifications. What follows a highlight of two issues I believe are important to NANOG. There are, however, many unresolved issues with NETCONF, some more important than others, that have been posted by the chair today to the netconf mailing list. They can be viewed by going to http://ops.ietf.org/lists/netconf/netconf.2003. The working group solicits your opinion on as many of these issues as you care to comment on. The protocol itself is split into two parts: an abstract set of functions, and a binding to specific protocols, including SSH, BEEP, and SOAP over HTTP(s). Each protocol has its pluses and minuses. As envisioned, the base protocol supports an option for notifications. The idea is that a manager would be notified of configuration-related events, such as a card insertion or removal, and act appropriately to configure the element. The envisioned format of notifications is either reliable syslog from RFC 3195 or something similar. Because notifications are asynchronous, one writes code that implements a dispatch mechanism that discriminates on the type of event. Notifications would be an option that not all managers would have to implement. Our first question is whether or not you are interested in receiving such notifications? Related, do you use such a mechanism today? The working group is attempting to determine whether notifications should remain as part of the base specification. Here are the choices facing the group: Option A. Leave them in as currently specified, and require all protocol mappings to support them. Option B. Allow them to be asynchronous, but don't use RFC 3195, and require all mappings to support them. Option C. Remove them entirely from the specification and let vendors implement RFC 3195 or other notification mechanisms as they see fit (for instance, existing syslog). Do you have an opinion on which of these options you would like? Related, the NETCONF base protocol currently makes use of the notion of channels. Channels are a basic concept in the BEEP protocol, and they exist in SSH as well. However, use of multiple channels in SSH is not supported in common SSH applications. They are completely absent in HTTP, and so the notion of a session would have to be introduced in the mapping. Channels are a means of maintaining multiple communication streams within a single session. In NETCONF, there are three types of streams: management, operations, and notifications. Channels allow these different message types to be multiplexed within the same session without the need to interleave the messages in a way that preserves their integrity (e.g. valid XML instance documents). NETCONF utilizes channels to separate asynchronous messages (notifications or RPC progress reports) from normal operations, as well as separate high priority operations (RPC abort) from normal operations. The working group has three choices: Option A. Keep channels in the base document and require each mapping to support them. Option B. Make channels optional. Option C. Remove channels from the base protocol and allow their use in the protocol bindings. Which option do you prefer? Again, these are important protocol issues that will affect your ability to build tools. There are others. If you would like to read the entire set of documents, you will find them by going to the NETCONF working group charter page: http://www.ietf.org/html.charters/netconf-charter.html. If there is sufficient interest we will seek another BOF at Miami. Thanks for your help, Eliot