Re: NETCONF clarifications

[Andy Bierman <ietf@andybierman.com>]

Peter, Christian wrote:
> 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).


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


> 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>?

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>



> <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). 


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.

> 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? 

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.

> Regards,
> Christian
>
>
> Christian Peter
> R & D Software Switzerland 

Andy


--
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/>