Subject: [NGO] FW: I-D ACTION:draft-li-ngo-access-mib-00.txt

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Fri, 5 Jan 2007 08:19:45 +0200

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Friday, January 05, 2007 1:50 AM
To: [email-masked]
Subject: I-D ACTION:draft-li-ngo-access-mib-00.txt 

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: Accessing MIBs using NETCONF
	Author(s)	: Y. Li, D. Harrington
	Filename	: draft-li-ngo-access-mib-00.txt
	Pages		: 21
	Date		: 2006-1-4
	
   This memo describes a simple mechanism for accessing the Management
   Information Base (MIB), using the existing NETCONF RPC
   infrastructure.  It defines a set of specific operations for
   accessing the MIB as a capability of NETCONF.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-li-ngo-access-mib-00.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of 
the message. 
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the 
username "anonymous" and a password of your e-mail address. After 
logging in, type "cd internet-drafts" and then 
"get draft-li-ngo-access-mib-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-li-ngo-access-mib-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail
readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

---

From: Andy Bierman <[email-masked]>
Date: Fri, 05 Jan 2007 09:51:41 -0800

Hi,

> 	Title		: Accessing MIBs using NETCONF

Although I agree with the intentions of this document (as I understand them),
I do not see any additional value in the special RPCs <mib-get> and <mib-set>.
They seem to be the same as the <get> and <edit-config> operations.
All of the value seems to be in the <snmp-data> data model element,
and actual MIB-to-XSD conversion algorithms, which are not documented here.

Section 3 describes some requirements for SNMP, but it doesn't
actually map those requirements into the NETCONF protocol in any way.
I was expecting to see how all these requirements are mapped to
the RPC methods, or maybe the <snmp-data> data model wrapper element.

The examples have a lot of XML attributes and underlying data model
assumptions that are not explained.  These are the missing details
that implementors need to support this proposal in running code.

Isn't 'max-repetitions' used in SNMP to deal with UDP limitations?
Introducing it in NETCONF as a new control in subtree filtering,
and embellishing subtree filtering instead of using Xpath,
does not seem like a good idea to me.

Andy

---

From: "David Harrington" <[email-masked]>
Date: Mon, 8 Jan 2007 21:32:06 -0500

Hi, 

> and actual MIB-to-XSD conversion algorithms, which are not 

As currently written, that is true. As described, the current document
only deals with the data addressing issue of accessing MIB data, by
using the smidump output.

> the RPC methods, or maybe the <snmp-data> data model wrapper
element.

The main issue is how to map from netconf parameters to SNMP access
control. Netconf does not provide the necessary parameters to do this,
and the document points out that these parameters are necessary if the
operator-defined MIB access control rules will be honored by netconf.

In ISMS, as in netconf, we are depending on a secure transport layer
to provide user authentication and message security. The difference
between ISMS (SNMPv3) and netconf is that netconf provides no mapping
from its transport-specific SSH/BEEP/SOAP security parameters to
transport-independent parameters (securityname/level/model) that can
then be passed in an RPC for purposes of access control.

Is there additional value in <mib-get> and <mib-set> over <get> and
<edit-config>? Yes. They provide a specialized RPC interface that is
specially designed to use an XSD-to-MIB data mapping, and can be
extended to support the SNMP-specific access control interface,
without forcing <get> and <edit-config> and other netconf operations
to use the same XSD data models or the same access control interface. 

Of course, if the netconf community wants to redefine <get> and
<edit-config> to take securityName/level/model parameters for access
control for <get> and <edit-config>, then there would be no additional
value in the <mib-get>/<mib-set> specialized RPCs. I have not seen
much indication that the netconf community wants to do this, so we
have suggested the use of specialized RPCs to "contain" this extra
functionality.

If the netconf community is interested in seeing mappings from the
transport-security-specific authentication mechanisms to
transport-security-independent parameters (which for consistency with
SNMP I would call securityName, securityLevel, and securityModel), I
can certainly help specify those mappings, working with the
netconf-transport document authors, and then work with Yan to extend
the <mib-get> and <mib-set> RPCs (or <get> and <edit-config>) to
include them.

> that implementors need to support this proposal in running code.

Agreed. Hopefully, the SMI-to-XSD translation will be documented by
Thorsten and Frank, and we can clean up any text with other
assumptions.

> does not seem like a good idea to me.

Eliminating max-repetitions from the proposal has been under
discussion, but has not been removed yet.

David Harrington
[email-masked] 
[email-masked]
[email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Mon, 08 Jan 2007 18:59:23 -0800

> to use the same XSD data models or the same access control interface. 

As Martin pointed out, the regular <get> can be used
because the <snmp-data> element is in a specific namespace,
and it doesn't interfere with anything else.  This element
is just another data model root, like the <top> element
we've seen in many examples.

The NETCONF interface to the SNMP Set PDU (mib-set RPC in your draft)
is problematic, since RowStatus and the operation attribute do not mix.
It might be possible to use edit-config by treating 'merge' and 'replace'
operations as just a 'write' operation in SNMP, and leaving out RowStatus
completely.  Either that, or use RowStatus and leave the operation attribute
out completely (i.e., use a special RPC, not <edit-config>).

> discussion, but has not been removed yet.

How is get-next accomplished?
This is the data model discovery mechanism in SNMP.
Is a <get> on the entire agent (or subtree) the only mechanism needed?

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 9 Jan 2007 09:24:50 +0100

> out completely (i.e., use a special RPC, not <edit-config>).

Tweaking semantics is broken and I guess this is why the ID suggests
new operations (<mib-get> and <mib-set>). Some CLIs of some of our
devices has similar primitives...
 
> Is a <get> on the entire agent (or subtree) the only mechanism needed?

The question is whether it is really needed since we have more
powerful filtering mechanisms in netconf. If someone insists in using
SNMP primitives, he/she should probably best talk SNMP. (And hence I
am also not convinced of keeping the max-repetitions idea.)

/js

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

---

From: Li Yan <[email-masked]>
Date: Tue, 09 Jan 2007 20:54:15 +0800

Hi Andy,
There are multiple data model roots in both NETCONF data model and
XML-formatted MIBs. If I need to retrieve entire NETCONF data or entire MIB
data from a device, I have to enumerate all root elements of data model that
are supported by the device in the <filter> parameter. It is a trouble. So
the separation of NETCONF data and MIB data is meaningful.

Yan

> From: Andy Bierman [mailto:[email-masked]]
> Sent: Tuesday, January 09, 2007 10:59 AM
> To: David Harrington
> Cc: 'NETCONF Goes On'
> Subject: Re: [NGO] FW: I-D ACTION:draft-li-ngo-access-mib-00.txt
> 
> [...]
> [...]

---

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

> the separation of NETCONF data and MIB data is meaningful.

I don't think it is a long-term useful feature.
If I have a NETCONF application that manages bandwidth
rate limiting, what do I care if the "number of bytes
received on the interface" came from "ifInOctets" or some other
variable that does not have an origin in MIBs?  What if the
data model had an object called "bytes-received"?
Why is it useful to have this MIB data filter,
so I can receive "ifInOctets" but not the "bytes-received" element?
IMO, this is not an important distinction to maintain in the NETCONF API.

Andy