RE: Proposed Update to Netconf Charter

["David B Harrington" <dbharrington@comcast.net>]

Hi Andy,

> Access control is also critical to get in place early on.
> I prefer to start simple and evolve the complexity over time.
> IMO, a mapping to ISMS should be a separate work effort,
> and probably in that WG.
> 
> NETCONF AC is unique because it is both "RPC method" and 
> document oriented.
> IMO, old approaches like VACM will be clumsy and/or bloated if
applied
> to NETCONF.  Some new innovation is required  here.
> 

I'm interested in your views about the uniqueness of netconf AC. 

In SNMPv3, as you know, we found that all operations could be
abstracted into read/write/notify types of operations for purposes of
AC. There was not a real need to distinguish between GET, GETBULK, and
other proposed GET-XXXX operations. Do you see a real need to
distinguish between the various <get-xxx> RPC methods, etc., that
would be initiated by an operator? 

In the SNMPv3 isAccessAllowed() ASI, variableName names the instance
of the managed object. Would netconf use a similar (XML-based)
variablename to identify the instance of the managed object? 

Do you expect that "documents" will be aggregations of objects that
are not necessarily from the same XML subtree? I can see this if the
document is an HTML web page; but if it is built from data elements
defined as an XML instance, then would AC based on the underlying XML
suffice? Cf: a varbind list with an aggregation of various managed
objects. Do you have something different in mind for documents?

In SNMPv3, we have contexts to differentiate MIB instances. I assume
such a concept would also be needed for netconf. Do you agree? Is
"running" and "candidate" about as deep as you need to go for netconf
contexts, or do you need the greater depth found in the SNMP contexts?
Do you anticipate a future need to be able to configure, for example,
the XML instance for a specific blade in a server?

I'm interested in your thoughts on this because VACM has not gained
very wide acceptance, and a simpler AC model that could be used with
both netconf's XML hierarchical naming scheme and SNMP's OID
hierarchical naming scheme (or an XML-based SNMP naming scheme) could
help both protocols. I'm also interested in probing how the
requirements for netconf AC and SNMP AC might differ, since this could
also have an impact on whether ISMS design should even try to be
future-compatible with netconf. 

David Harrington
dbharrington@comcast.net







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