Subject: [NGO] comments on draft-li-ngo-access-mib-00

From: Martin Bjorklund <[email-masked]>
Date: Mon, 08 Jan 2007 22:54:22 +0100 (CET)

Hi,

I don't understand why a new rpc method <mib-get> is needed.  Why can't
the normal <get> method be used?

<mib-set> I could possibly understand, but not the way it's defined.
Specifically, how is the operation attribute supposed to be used in
combination with RowStatus objects?

In general I think that these MIB request can be done using the normal
netconf operations, as long as the XML mapping is well-defined.
I.e. given a standard MIB, what will the XML look like (namespace URI,
element structure, attribute uses, datatype represention).  This part
isn't covered in the draft (just a reference to smidump).

/martin

_______________________________________________
NGO mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ngo

---

From: Li Yan <[email-masked]>
Date: Tue, 09 Jan 2007 17:44:40 +0800

Hi martin,
I consider that the MIB data and the NETCONF data should be separated.
Because MIBs and NETCONF data model are two different data models, they are
independent each other, their content may overlap. Therefore, <mib-get> can
only retrieve the MIB data，while <get> can only retrieve the true NETCONF
data. Otherwise, when a NETCONF client want to retrieve all NETCONF data by
a <get> operation, a <filter> parameter must be used to exclude all MIB
data.
>From the point of view of implementation, the mechanisms of retrieving the
MIB data and the NETCONF data are totally different. So I use operations
instead of the <filter> parameter to determine which mechanism of retrieving
data should be adopted.

RowStatus object should be ignored. The 'create' value of operation
attribute is treated as 'createAndGo', and the 'delete' value of operation
attribute is treated as 'destroy'.

Thanks for your comments.

Yan
> -----Original Message-----
> From: Martin Bjorklund [mailto:[email-masked]]
> Sent: Tuesday, January 09, 2007 5:54 AM
> To: [email-masked]
> Subject: [NGO] comments on draft-li-ngo-access-mib-00
> 
> Hi,
>

---

From: Andy Bierman <[email-masked]>
Date: Tue, 09 Jan 2007 05:17:10 -0800

> instead of the <filter> parameter to determine which mechanism of retrieving

I disagree with this POV.
We should not have SNMP data, SYSLOG data, and NETCONF data,
all with their own special access functions.  We just have
data, which happens to be traditionally delivered with a
particular protocol.

Juergen has pointed out in the past that our <get-config>
operation is just another filter, so we don't really need it.
We kept it because it is a very important filter to operators.
But the distinction between <get> and <get-config> is not
the same as <mib-get>.  The <get-config> filter applies
to all namespaces and all data.  It is a filter based
on the characteristics of the data being retrieved,
not the characteristics of a protocol that traditionally
carries the data.

Since the <snmp-data> element defines a namespace and data root
for "MIB data", the special <mib-get> RPC is totally redundant.

The real issue is "what problem are you trying to solve"?

Is this supposed to be a mechanism to manipulate XML/MIB data
(derived from SMI-based schema) with NETCONF operations,
or is it a mechanism to tunnel SNMP protocol operations
through the NETCONF protocol?

I think it is supposed to be the former, and therefore several
decisions have to be made (e.g., how to move RowStatus
and StorageType data to NETCONF operations, how to encode
INDEX clauses, how to deal with data in different contexts).
MaxRepetitions and even GetNext/GetBulk operations are not relevant
to NETCONF.

We need a standard which specifies the details
of "smidump --format=xsd", and not much else (ignoring VACM
for the moment ;-).  Ideally, there would not need to even
be an <snmp-data> wrapper, and <ifTable> could be just another
data model in just another namespace, and not be treated special.
This is probably not possible though, without moving the <snmp-data>
attributes to the RPC method as parameters.

> attribute is treated as 'destroy'.

Yes -- but a standard needs to detail how this is accomplished.

> Thanks for your comments.

Andy

---

From: Balazs Lengyel <[email-masked]>
Date: Tue, 09 Jan 2007 17:47:18 +0100

Hello Li,
Could you please explain somewhat why did you leave out merge and none from your draft.

In my experience network operators like to see the device as having just one configuration and
want to see all configuration data on all it's interfaces. If we start partitioning the
configuration data: this data can only be seen with method/protocol A that data can only be
manipulated with method B, they will hate us.
Due to this customer requirement on me I dream of a world where we have one data model and a
number of interfaces/methods that all see the same thing. Separating MIB data and Netconf data
doesn't go in this direction.
Balazs

---

From: Li Yan <[email-masked]>
Date: Wed, 10 Jan 2007 17:03:27 +0800

Hi Balazs,
I think that SNMP set operation has 3 senses:
1) Ordinarily set a value to a MIB object, it is equivalent to replace an
old value by a new value.
2) Set 'createAndGo' or 'createAndWait' to a RowStatus object, it is
equivalent to create an entry instance.
3) Set 'destroy' to a RowStatus object, it is equivalent to delete an entry
instance.
It seems 'merge' and 'replace' have the same meaning in SNMP world.
I constrain 'delete 'to be applied for an entry element only. It indicates
explicitly the entry element to be deleted. So unintentionally deleting the
parent hierarchy of the element will not happen.

Yan

> From: Lengyel [mailto:[email-masked]]
> Sent: Wednesday, January 10, 2007 12:47 AM
> To: Li Yan
> Cc: 'Martin Bjorklund'; [email-masked]
> Subject: Re: [NGO] comments on draft-li-ngo-access-mib-00
> 
> Hello Li,
> Could you please explain somewhat why did you leave out merge and none
from
> your draft.
> 
> In my experience network operators like to see the device as having just
one
> configuration and
> configuration data: this data can only be seen with method/protocol A that
data
> can only be
> Due to this customer requirement on me I dream of a world where we have
one
> data model and a
> number of interfaces/methods that all see the same thing. Separating MIB
data
> and Netconf data

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 10 Jan 2007 19:40:18 +0100

> MaxRepetitions and even GetNext/GetBulk operations are not relevant

Using <get> to access SNMP instrumentation might be made to work.

Using <edit-config> to write SNMP instrumentation is going to be a
nightmare since the semantics of SNMP sets and <edit-config> do not
align well. Even if one were to define an "snmp" data store which
allows for the special SNMP semantics (persistency, create/delete,
...), this special datastore will essentially change <edit-config> so
much that I believe a new operation would be a much cleaner way.

Since I believe we need a <mib-set> operation, I do not mind having a
<mib-get> operation as well to easily access _existing_ SNMP based
instrumentation via NETCONF.

In the future, we _may_ have a uniform data modeling approach (but we
know already this will be very difficult to achieve and perhaps this
is not worth the effort). Anyway, for the many existing MIBs out
there, we (a) either provide a mechanism to access them via NETCONF
(RPCs) or (b) we state that to access SNMP instrumentation, you better
use SNMP (with all its pros and cons) and use NETCONF for NETCONF data
models only (which still need to be defined), or (c) we leave this to
proprietary extensions (which I am sure will be developed).

It is a fundamental decision in which direction we want to go in terms
of coexistance with SNMP.

/js

-- 
Juergen Schoenwaelder		 {International|Jacobs} University Bremen
<http://www.eecs.iu-bremen.de/>	 P.O. Box 750 561, 28725 Bremen, Germany