Subject: RE: Proposed Update to Netconf Charter

From: "Sharon Chisholm" <[email-masked]>
Date: Mon, 11 Jul 2005 08:13:59 -0400

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:[email-masked]] 
Sent: Tuesday, July 05, 2005 4:54 PM
To: David B Harrington
Cc: 'Andy Bierman'; Chisholm, Sharon [CAR:5K50:EXCH];
[email-masked]
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
> [email-masked]
> 
> 
> 
> 
> 
> 
> 
> --
> to unsubscribe send a message to [email-masked] 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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: "David T. Perkins" <[email-masked]>
Date: Mon, 11 Jul 2005 07:51:44 -0700 (PDT)

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 11 Jul 2005 17:58:41 +0200

> only for those items for which it applies.

Adding a container might be as difficult as adding an index to
a table once a data model has been deployed.

<soap>
Note that CMIP really tried to tackle parts of this problem by
introducing allomorphism. There are a few articles in CMIP Run!
<www.simpleweb.org/standard/iso/cmip-run/> which deal with this
topic in case someone is interested. I am sure Randy knows the
details well and whether this was a success story. In modern 
programming languages such as Java, the concept of interfaces 
became popular and this allows on object to actually support 
multiple interfaces, which can be exploited for backwards
compatibility if you want. But to be honest, I do not see any 
of these fancy concepts applying to XML encoded documents. 
</soap>

I am not advocating to add something like contexts - if you have 
screwed something up in your XML hierarchy, fix it by fixing the 
data model and use name spaces and version numbers to deal with 
backwards compatibility issues. The hope is that the costs of doing 
this and adopting to such changes will be reasonably cheap in XML 
land.  If netconf is successful, we will know in say 5 years whether 
this is actually true. ;-)

/js

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