Subject: RE: netconf implementation guide

From: Zihong Lu <[email-masked]>
Date: Fri, 10 Feb 2006 17:27:53 -0800

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

-Zihong

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]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 [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Andy Bierman <[email-masked]>
Date: Fri, 10 Feb 2006 17:49:00 -0800

> inter-operate testing rules will benefit the community a lot.

An implementation guide is an Informational RFC, which means
it doesn't contain requirements and rules.  The protocol specifications
themselves provide all the normative compliance and interoperability 
requirements.

If even we wanted to add lots of CLRs (clever little rules), which we don't,
it is still too early for us to have enough collective wisdom to get it 
right.

Andy