Balazs Andy Bierman wrote:
Hi, A couple points: 1) The term 'standard' is being used rather loosely here. IMO, standards are produced by independent SDOs and independently implemented in an interoperable manner by many vendors.
BALAZS: Sorry, I meant the netconf-protocol draft or some similar IETF draft/RFC.
2) The prot document clearly states how to add your own RPC operations in your own namespace. Hijacking the <get> operation is just about as "wrong" as you can get (from a standards POV).
BALAZS: I agree that this is a misuse of get, I see it as a strictly temporary hack.
AndyHello,I don't want to restart a debate that happened before I joined the mail group, so just asan observation:Ericsson widely uses standard <exec> operations; both on netconf and also on other similarhierarchical configuration interfaces.All custom commands share some common specifics that could be part of a standard, and their standard format would greatly help management tools. This is much more then just an extra XML layer as we (only) standardize the common features. Common features include: - all generic <exec> calls are executed on a specific managed object e.g. on interface=eth0, - have parameters that can be defined in the data model and type checked during execution- have return types and sometimes generic exception methodsBy defining a generic <exec> method you don't need to update capabilities and protocolmechanisms (new RPCs) just the data model for a new proprietary command.Most management tools will anyway be able to handle model based execution which can beeasily formalized, but few will be able to handle extra capabilities.What Ericsson has done is to misuse the <get> operation which can take input parameters and can supply back data. Later we will hopefully make our own generic <exec> RPC as it ismissing in the standard.Some other protocols like LDAP also have a generic <exec> method (Extended operations).Balazs Andy Bierman wrote:Hi, The <rpc> method itself can be a reload operation: <rpc message-id="101" xmlns="netconf-blah"> <reload xmlns="example.com/blah"/> </rpc> There is no value in a standard <exec> operation using proprietary CLI commands. It justs adds a layer of XML with no real purpose. The reload operation is actually much harder to standardize than it appears. In any case, this is a data model issue, and out of current WG scope. Andy >...I have been reading the NETCONF standard and think you people have done=a=20great job! As I was reading, I thought of a question for which I haven='t=20found an answer. (I did find some posts that mentioned 'operational'=20=commands when talking about what the WG should work on next---notificat=ions,=20or whatever---I hope my question doesn't just re-kindle an unrelated=20=discussion topic and my question is left un-answered!) Please help me=20=understand how this use case should work:There are commands in network devices, like "sdm prefer routing" on a C=isco=203750, that require a reload. However, I didn't see any built-in operat=ion=20for rebooting a device. How should this interaction with a device, whe=n the=20 configuration option requires a reboot, work using NETCONF=3F I thought of a few options:0. NETCONF does only configuration--operational commands like "reload" =are=20 outside the scope.1. Ooops, we forgot about reload (not likely!) or just haven't got to i=t=20 yet.2. It's left to the data model--devices can expose a configuration elem=ent=20 that results in a reload. Something like:<rpc message-id=3D"101" xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.=0"> <edit-config> <target> <running/> </target> <config> <cli xmlns=3D=94http://example.com/schema/1.0/config/=94> reload </cli> </config> </edit-config> </rpc> The device would respond with a reply of <ok/>, close the NETCONF=20connection, and then reload. (After typing this in, it seems really ho=key.)3. A device manufacturer can add a capability that adds a new operation=. =20 Something like this: <hello xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0"> <capabilities> <capability> urn:ietf:params:netconf:base:1.0 </capability> <capability> http:/example.com/schema/1.0/reload </capability> </capabilities> <session-id>4</session-id> </hello>And then you could send the device a NETCONF rpc with this new "reload"==20 operation when required. The rpc would look like this:<rpc message-id=3D"102" xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.=0"> <reload/> </rpc> The device would respond with a reply of <ok/>, close the NETCONF=20connection, and then reload. (If NETCONF doesn't include a native "rel=oad"=20 operation, then this makes the most sense---to me anyway!) 4. <your idea here...> How should it work=3F Thanks! Henry -- 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/>
-- Balazs Lengyel Ericsson Hungary Ltd. TSP System Manager ECN: 831 7320 Fax: +36 1 4377792 Tel: +36-1-437-7320 email: Balazs.Lengyel@ericsson.com -- 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/>