Balazs Lengyel wrote:
For us the main point is to allow the definition of new <exec>s with minimum modification to the management SW.Yes the full value of <exec> relies on data modeling. You really gain a lot only if you have something like this in place (an excerpt from our DTD that defines our modeling language like SMI)<!ELEMENT action (description, returnType, parameter*, raisesException*)> <!ATTLIST action name CDATA #REQUIRED> <!ELEMENT exception description,name, exceptionParameter*)>You have to define the number of parameters and for each parameter you have to define the exact type. This allows our management system to handle new actions (<exec>s) based on the data model without modification.I know that netconf does not have (yet) a data model in place, but I could think about a two stage introduction of this feature. 1) define a standard <exec> with opaque parameters to allow users who already have a proprietary data model (actually everyone) to easily implement the function
What are the implementation requirements? It seems like the one commonality is that the node used to "wrapper" the proprietary command is called 'exec'. IMO, this is not worth standardizing. In any event, this is not a chartered work item, and a written proposal would have to fly a lot further than "wrapper named exec" to get chartered.
2) define the necessary data model to gain the full value regards Balazs
Andy
Juergen Schoenwaelder wrote:On Thu, Aug 17, 2006 at 10:22:53AM -0700, Andy Bierman wrote:However, this is what the WG describes as <exec in the past: <exec> Takes 0 - N parameters of an opaque nature, and returns zero or more unspecified elements, and has zero or more unspecified side effects. IMO there is no point in this 'feature'. Unless there was more to it than this, the <exec> node has no real value.I am not sure I agree. Such an "exec" feature allows a data model to formally describe what the in/out argument for an exec are. For example, a data model could define that there is an operation called "ping", that it takes an IP address as input and returns some statistics. This moves the definition of operations out of the protocol into the data model (and thus requires that there is a data model framework to support this). The other approach is to introduce all new verbs as protocol extensions which does not require any data modeling agreement. (This is for those people who believe the IETF is good at protocols but less so on data models.) I am not arguing in either direction. I am just questioning the statement that there is "no point in this 'feature'" and "has no real value". /js
-- 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/>