RE: Proposed Update to Netconf Charter

["Sharon Chisholm" <schishol@nortel.com>]

hi

Some comments on Contexts. I think this concept may well still be needed
because 

1. People are always going to have trouble predicting the future
2. Over-optimizing your schema for 'what ifs' can make the thing
complicated.

For example, in order to support virtual routers, do you really extend
all of your traditional things like routing tables so you can have more
than one of them? Perhaps the answer is yes, since this also means
allows supports for distributed management, but is this worth it for the
simple case of a single router with a single routing table?

Sharon

-----Original Message-----
From: David T. Perkins [mailto:dperkins@dsperkins.com] 
Sent: Tuesday, July 05, 2005 4:54 PM
To: David B Harrington
Cc: 'Andy Bierman'; Chisholm, Sharon [CAR:5K50:EXCH];
netconf@ops.ietf.org
Subject: RE: Proposed Update to Netconf Charter


HI,

Two specific items...
1) I don't see the need for contexts in NETCONF data modeling,
   since contexts are simply "a mechanism to add extra
   indexing when the MIB designer failed to predict the future
   evolution of technology" (or bandaid for poor MIB design).
   With XML, I don't really believe this limitation is
   present, and, thus, a "context" will not be needed.

2) SNMP VACM access control is based on
    1) the identication of the management information
        (the variable name)
    2) the operation type (read/write/notify)
    3) the security model
    4) the security level
    5) the context
    6) the group
   It doesn't depend on the value of object instance. This
   has resulted in MIB design patterns where objects are
   made (unnaturally) into index object(s). The usual
   case is where the security name (or group name)
   is made into an index. Many other systems, especially
   data base systems have access control based on
   data values.

   In the work that I have done explaining VACM, the
   concept that what security level is used can affect
   what can be accessed is always a very big surprise.

   So far, there is a single security model. If several
   were present, then the number of entries in the VACM
   table could increase by a factor of the number.

   In general, the SNMP acess model is unlike anything
   that most users are use to. Thus, they can not
   understand it, and its richness is typically never 
   used. It is also typically not used because the
   objects used by management apps are not typically
   characterized. Thus, most systems that I've seen
   provide no restriction to management platforms, and
   any restriction is done by a management platform
   as to which management applications any specific
   user can run.

   Thus, I would characterize VACM as completely missing
   the target. It is too complex for typical usage,
   and not rich enough for realworld usage.

Regards,
/david t. perkins

On Tue, 5 Jul 2005, David B Harrington wrote:

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



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