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

["David Harrington" <ietfdbh at comcast.net>]

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.

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.

> 
> 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 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.

> 
> 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.

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

> 
> 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.

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

David Harrington
dharrington at huawei.com 
dbharrington at comcast.net
ietfdbh at comcast.net



_______________________________________________
NGO mailing list
NGO at ietf.org
https://www1.ietf.org/mailman/listinfo/ngo