[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Proposed Update to Netconf Charter
HI,
In SNMP, the identification of an instance of management information
can only be extended in a backwards compatable way through use of
contexts. In other management systems, such as CMIP and netconf,
identification of an instance is simply extended by adding a new
container object. In SNMP operations, a "context" applies to
all items in the request, response, and notification. However,
in other management protocols, the added container is needed
only for those items for which it applies.
Since Netconf can do a better job than SNMP in coping with
not correctly predicting the future, I do not see a need
for "contexts" (like those found in SNMP) in Netconf.
Regards,
/david t. perkins
On Mon, 11 Jul 2005, Sharon Chisholm wrote:
> 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/>
>
--
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/>