RE: netconf implementation guide

[Zihong Lu <zlu@extremenetworks.com>]

A document with netconf implementation guide, compliance requirements and
inter-operate testing rules will benefit the community a lot.

-Zihong

> -----Original Message-----
> From: owner-netconf@ops.ietf.org [mailto:owner-netconf@ops.ietf.org]On
> Behalf Of Andy Bierman
> Sent: Friday, February 10, 2006 4:51 PM
> To: Netconf (E-mail)
> Subject: netconf implementation guide
> 
> 
> Hi,
> 
> I think eventually we will keep collecting clarifications,
> maybe even enough for a NETCONF Implementation Guide RFC.
> 
> Are there any WG members willing to work on a
> NETCONF Implementation Guide (Informational) RFC?
> Is there community interest in having such a document?
> 
> If so, the first step is collecting implementation experience,
> FAQ material, document clarifications and errata, etc.
> 
> 
> ==========================================
> 
> 2 more issues that aren't very obvious
> (No, nothing more is going into prot-11;
> NETCONF Version 1 is in the can.)
> 
> 1) Error processing hierarchy
> 
> There are some errors that need to be processed before others.
> It is reasonable for an agent to stop looking for certain types
> of errors after particular errors have already occurred.
> 
> For example, if the target of an edit-config is an unknown
> configuration name, or the user doesn't have access rights to
> invoke the edit-config method, then the <config> element sub-tree
> may not be analyzed for errors, regardless of the 
> 'continue-on-error' flag.
> 
> It is therefore possible (e.g., big edit-config request) for a manager
> to receive an rpc-reply before it finishes sending the matching
> <rpc> request.
> 
> 2) Edit-config processing
> 
> The merge order is data model dependent.
> A NETCONF data model definition which allows
> multiple instances of an element must indicate the
> merge order somehow.
> 
> When processing a replace operation, it is important
> to know if a sub-node (in the data model, not the PDU!) is
>   1) mandatory
>   2) mandatory-with-default
>   3) optional
> 
> If (1) then missing sub-elements are errors.
> If (2) then missing sub-elements with defaults are filled in before
>    checking for missing elements.
> If (3) then this is not an error, but any corresponding nodes
>   in the target that match the missing nodes must be removed
> 
> A NETCONF data model definition must indicate the <edit-config>
> replace behavior somehow.
> 
> 
> 
> 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/>
> 

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