[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: partial locking
> -----Original Message-----
> From: owner-netconf@ops.ietf.org
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman
> Sent: Friday, August 31, 2007 2:33 AM
> To: David Harrington
> Cc: 'Netconf (E-mail)'
> Subject: Re: partial locking
>
> David Harrington wrote:
> > Hi,
> >
> > For partial locking, since the lock applies not only to
> Netconf but to
> > other NM interfaces as well, it is imperative that the
> managed entity
> > understand just what **instrumentation** is being partially locked,
> > not just what Netconf data model subset is being partially locked.
> >
> > In SNMP, we use strings to identify a "naming scope" - a
> community or
> > a context, and it is imperative that the agent understand
> what data is
> > in the community or the context. It is the implementation of the
> > managed entity that determines just what distinct communities or
> > contexts exist within the managed entity, and an agent
> knows about the
> > data subsets, even if there are dynamic hardware changes
> that affect
> > the subsets. The manager can learn what managed objects are in a
> > community or context by querying the agent. I think the same
> > agent-centric determination of named data partitions will
> be required
> > if the partial locking will apply to multiple NM interfaces
> that use
> > different data modeling interfaces.
> >
> > In SNMP and/or Netconf, the manager/operatorcan also dynamically
> > specify subtrees of data or "view families" or XPath expressions. I
> > think we need to identify whether and how this type of
> dynamic subset
> > of data might be locked by partial locking, whether such
> > dynamically-specified locks apply across multiple NM
> interfaces, and
> > how the managed entity knows which non-Netconf data to
> partially lock.
> >
>
> I'm not sure there is any use case to share write access to
> the configuration database between SNMP and NETCONF.
> Is anybody doing this already?
>
> Is anybody implementing SNMP context or community string
> based 'partitions'
> within the NETCONF protocol?
>
> There is no non-NETCONF data to lock.
> There are non-NETCONF locks on NETCONF data, and global locks
> of this type are probably good enough.
>
I am not sure that I understand the concepts of NETCONF data and
non-NETCONF data. We deal with network devices that are being configured
nowadays using different protocols - I know for example uses of CLI and
SNMP and some forms of secure file transfer and telephony provisioning
protocols in any combination - and now we want to add NETCONF as another
configuration protocol. Unless we assume that what is being configured
by NETCONF is something completely new or that we introduce a
requirement that I was not aware about that what is configured by
NETCONF is not configured by other protocols it seems to me that there
the use case of NETCONF sharing write access with other protocols is
obvious. Am I missing something?
Dan
(speaking as contributor)
--
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/>