RE: draft-lengyel-netconf-granular-locking-00.txt

["David B Harrington" <dbharrington@comcast.net>]

Hi Balazs,

Thanks for submitting this document as a starting point.

Can you add a section to your draft that discusses the potential
issues that arise from having different operators working on different
pieces of a configuration simultaneously, and any suggestions for how
to address those issues? I assume that since this is required for some
of your company's devices, that there is existing knowledge of issues,
and how to address the problems that result from this, and having some
of the issues and potential solutions identified here would be useful.

Can you also address which other netconf operations might need to be
changed to support partial configuration? The :granular-locking
"target 
can be specified using a combination of a target datastore and a
subtree filter or an XPATH filter expression." So, for example, will
the copy-config, delete-config, and validate commands need to be
changed to accept a filter as well? 

Your draft says "A granular lock will succeed only if no parts of the
scope to be locked are locked by other management users including
users of NETCONF or any other management method." Can you define scope
in the document, so it is clear how one would determine overlap? 

Some issues surrounding separate configuration of pieces of the
"grand" configuration were discussed in 2003. One such thread can be
found in the archive at
http://ops.ietf.org/lists/netconf/netconf.2003/msg00867.html.

Thanks,
David Harrington
dbharrington@comcast.net

> -----Original Message-----
> From: owner-netconf@ops.ietf.org 
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Balazs Lengyel
> Sent: Monday, December 19, 2005 7:12 AM
> To: netconf@ops.ietf.org
> Subject: draft-lengyel-netconf-granular-locking-00.txt
> 
> I wrote a short document about granular locking for Netconf.
> 
> We in Ericsson feel that there is a strong need for granular
locking.
> 
> Some of our configuration databases are so big that we can 
> not use candidate 
> configurations and for the same reason we must allow 
> simultaneous paralel configuration 
> sessions to manipulate different parts of the configuration.
> 
> I believe that we dont need to know the contents of the data 
> model before we can devise a 
> granular locking mechanism, just as the mechanism of the 
> subtree-filter is not dependent 
> on the data model it is filtering.
> 
> Any comments ?
> 
> regards Balazs
> -- 
> Balazs Lengyel                       Ericsson Hungary Ltd.
> TSP System Manager & AXD Operational Suite (AOS) OPM
> 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/>