Re: partial locking

[Andy Bierman <ietf@andybierman.com>]

David B Harrington wrote:
> Hi Andy,
>
> Please get past your SNMP hangup and concentrate on what people are
> actually saying. My concerns remain concerns on systems that do not
> even have an SNMP agent on them.
>
> You are assuming I am talking about SNMP and about MIB access. I am
> not. 
> I am not talking about <get-mib> or <set-mib>.
>
> I am talking about locks. And locks go beyond one protocol-specific
> approach to accessing the configuration data on a device. 

I am trying to understand your concerns.
Are you suggesting a NETCONF agent is responsible for locking
device data it has no knowledge of and does not manage at all?
Are you suggesting half of one sentence in RFC 4741 means
that all NETCONF implementations are non-compliant because
they contain some data on the device that has nothing to do with
NETCONF, and is not affected by the <lock> operation?

I don't see why the existence of non-NETCONF related data on the device
is of any concern here.  Internal agent instrumentation is an
implementation detail, outside the scope of standardization.

I doubt any NETCONF implementations exist in which the <lock> operation
prevents other protocols from accessing device data not known to
the NETCONF agent.  I'm not sure how or even why somebody would code that.



> dbh

Andy

> > -----Original Message-----
> > From: Andy Bierman [mailto:ietf@andybierman.com] 
> > Sent: Friday, August 31, 2007 12:38 PM
> > To: David B Harrington
> > Cc: 'Balazs Lengyel'; 'Romascanu, Dan (Dan)'; 'Eliot Lear'; 
> > 'David Harrington'; 'Netconf (E-mail)'
> > Subject: Re: partial locking
> >
> > David B Harrington wrote:
> > > Hi,
> > >
> > > I agree. 
> > > I think there is one virtual shared configuration database that
> > > contains all configuration regardless of the protocol(s) used to
> > > access it.  
> > yes -- this is what we have now with internal agent instrumentation
> > allowing various protocols to access various internal data
> structures.
> > SNMP has an tree populated with OIDs and NETCONF has a conceptual
> > XML instance document.  How they overlap within internal agent
> > instrumentation is not relevant to the NETCONF WG.
> >
> > > And then there are protocol-specific representations (views) of
> this
> > > shared configuration database.
> > yes -- this is what we have now.  Different protocols with
> > different data model architectures accessing various subsets
> > of internal data structures on the agent.
> >
> > This does not mean the NETCONF protocol needs to access the database
> > with special RPCs like <get-mib> and <set-mib>.
> > Each protocol has its own consistent view of the data, and the
> > agent handles any translation for multi-protocol access as
> > an implementation detail.
> >
> > > dbh
> > Andy
> >
> >
> > > > -----Original Message-----
> > > > From: Balazs Lengyel [mailto:balazs.lengyel@ericsson.com] 
> > > > Sent: Friday, August 31, 2007 12:04 PM
> > > > To: Andy Bierman
> > > > Cc: David B Harrington; 'Romascanu, Dan (Dan)'; 'Eliot Lear'; 
> > > > 'David Harrington'; 'Netconf (E-mail)'
> > > > Subject: Re: partial locking
> > > >
> > > > Hello Andy,
> > > > I have a problem with the terminology used in this mail-thread.
> > > >
> > > > People are speaking about SNMP database, Netconf database 
> > > > etc. IMHO we should speak about the 
> > > > device's management database as the only database. Different 
> > > > protocols, interfaces might 
> > > > provide a complete or partial view to this database, but the 
> > > > data is not owned by this or that 
> > > > protocol as I understand.
> > > >
> > > > Balazs
>
>
>
> --
> 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/>