Subject: NETCONF clarifications

From: "Peter, Christian" <[email-masked]>
Date: Fri, 8 Jun 2007 17:19:03 +0200

Hi,
I have been reading the NETCONF standard and noticed a lot of common
things with
our XML management infrastructure.
We are considering to also adding the NETCONF standard to our product.
Now some
questions are coming up. Probably some questions are out of scope of the
NETCONF
protocol or maybe already discussed or even stupid:-).
I apologize ahead of time if the question I'm asking has already been
answered,
but I would really appreciate it, if someone could give me some
clarifications.

Non-configuration data (commands):
In the RFC it's not mention about setting non-configuration data (e.g.
setting clock time).
Is there any good way to do this.  In our system we have such a
functionality mapped
with following structure: 
- operation name
- in parameters  (only for the request)
- out parameters (only for the reply)

Should the data directly wrapped in the <rpc>?

<rpc>
 <operation-name>
   <in parameters>
    ...
 </operation-name>
</rpc>

<rpc-reply>
 <operation-name>
   <out parameters>
    ...
 </operation-name>
</rpc-replay>
 
Timeout:
Requests can have some time to process. A example could be the
<copy-config> or
gathering a lot of statistics at once. Is there any timeout behaviour or
feedback
mechanism to the client, when processing for a longer time (e.g. 15
minutes). 

Attachments:
I see that NETCONF is mainly an interface for configuration and status.
But are
there any ideas of having some mechanism to attach real binary data
(e.g. firmware)
to a request or reply? 

Regards,
Christian

Christian Peter
R & D Software Switzerland 
---------------------------------------- 
KEYMILE AG
Schwarzenburgstrasse 73
CH-3097 Berne-Liebefeld, Switzerland
www.keymile.com

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

---

From: Balazs Lengyel <[email-masked]>
Date: Fri, 08 Jun 2007 17:45:37 +0200

Hello Peter,
I had earlier submitted a draft about operations or as I called them generic-actions. I think 
this is what you are looking for. The draft is not perfect and I already have some ideas how to 
update it. Ericsson and Tailf have both implemented a non-standard solution for such 
operations/actions.

I would happily and actively support anyone trying to push for support such a draft.

regards Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Fri, 08 Jun 2007 13:59:23 -0700

> In the RFC it's not mention about setting non-configuration data (e.g.

I call this middle ground "transient configuration (tconfig)"
It is writable, but not saved in NV-storage.

> Should the data directly wrapped in the <rpc>?

You could define your own non-standard RPC method or
use the standard operations.

The data classification that is critical to implementation
(i.e., state vs. tconfig vs. config) is not officially part of NETCONF,
but the standard <edit-config> operation can be used on the
<in-parameters> data anyway.

   <rpc xmlns="netconf-base" message-id="101">
     <edit-config>
       <target><running/></target>
       <default-operation>none</default-operation>
       <test-option>set</test-option>
       <error-option>rollback-on-error</error-option>
       <config>
         <in-parameters xmlns="example.com">
           ...
         </in-parameters>
       </config>
     </edit-config>
   </rpc>

> mechanism to the client, when processing for a longer time (e.g. 15

There was -- it was removed from an early version of the protocol.
A set of standard notifications may be produced, which would include
a 'delayed rpc-reply'.  For now, I suggest sending an <ok> back
right away and using a proprietary notification (or <get> data model)
to indicate the progress and/or final status.

> there any ideas of having some mechanism to attach real binary data

This has come up in the past and I suppose if a proposal
existed which got enough support, it could be standardized.
For now, define your own <download-binary> RPC and use
a 'hexBinary' parameter.

> R & D Software Switzerland 

Andy

---

From: Phil Shafer <[email-masked]>
Date: Fri, 08 Jun 2007 18:36:39 -0400

>We are considering to also adding the NETCONF standard to our product.

Excellent news!!

>In the RFC it's not mention about setting non-configuration data (e.g.

NETCONF allows you to define your own RPCs, with custom input
parameters (encoded in xml) and custom XML output.  So you
can do something like:

  <rpc xmlns="oh-i-forget">
    <set-clock xmlns="your-own-here">
      <format>+%y%m%d%H%M.%S</format>
      <time>0706081820.52<time>
    </set-clock>
  </rpc>

and you reply can contain whatever data you want.  We do similar
stuff in the JUNOScript API, which is available over NETCONF, as
well as our older ssl-based access method.  Check out:
  http://www.juniper.net/support/junoscript/
for details and examples.

>Is there any timeout behaviour or feedback mechanism to the client,
>when processing for a longer time (e.g. 15 minutes).

Early drafts of the NETCONF spec had the <abort/> operation from
JUNOScript, but it was tossed out for reasons I don't remember.
Without a way for the client to tell the server to stop (and the
server to acknowledge it), you are stuck.  You can make the server
implement a timeout, like;

  <rpc>
    <install-software>
      <image>/tmp/sw.tgz</image>
      <timeout>10</timeout>
    </install-software>
  </rpc>

>there any ideas of having some mechanism to attach real binary data

We do this with an <encoding> parameter, like:

  <rpc>
    <get-file>
      <filename>core-file.tgz</filename>
      <encoding>base64</encoding>
    </get-file>
  </rpc>

The reply is something like:

  <rpc-reply>
    <file-contents>
      <base64>some-totally-awful-unreadable-and-long-stuff-here</base64>
    </file-contents>
  </rpc-reply>

This shipped in JUNOS 8.3, for which the docs are not yet available on
the public web site.  If you want the full details, holler and I'll
get them for you.

Thanks,
 Phil