Re: message to nanog

[Rob Enns <rpe@juniper.net>]

Looks good. Going to NANOG (Miami in February) would not suck :-)
but I'd like to have this nailed down long before then.

Rob

On Mon, Nov 17, 2003 at 10:59:42AM -0800, Eliot Lear wrote:
> At the plenary, we agreed that I would draft a message to NANOG to ask 
> for feedback on features such as notifications & channels.  Here is my 
> first cut at such a message.  Let me propose that if we don't get enough 
> responses, we actually go to NANOG and do a presentation.
> 
> Subject: YOUR opinions needed for Network Configuration Protocols
> Reply-to: netconf@ops.ietf.org
> 
> 
> 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.
> 
> 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.
> 
> 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 provide a number of benefits.  First, they divorce the idea of 
> who is the session initiator and who is the device manager.  This means 
> that either the network element or the manager could initiate a TCP 
> connection.  This is useful when NATs and firewalls exist between a 
> device and the manager.  Channels are also necessary to implement a way 
> to determine progress of a configuration operation.
> 
> 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?
> 
> 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
> 
> Eliot
> 
> --
> to unsubscribe send a message to netconf-request@ops.ietf.org with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://ops.ietf.org/lists/netconf/>

--
to unsubscribe send a message to netconf-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>