[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

referential integrity across reboots (Was: DISMAN Meeting minutes - 0716/02)



[ post by non-subscriber.  with the massive amount of spam, it is easy to
  miss and therefore delete mis-posts.  so fix subscription addresses! ]

Hi -

> Message-Id: <4.3.2.7.2.20020721145557.016e0690@mira-linc3-1.cisco.com>
> Date: Sun, 21 Jul 2002 14:59:29 +0900
> To: "'Randy Presuhn'" <rpresuhn@dorothy.bmc.com>, disman@dorothy.bmc.com
> From: Niraj Gopal <niraj@cisco.com>
> Subject: DISMAN Meeting minutes - 0716/02
> List-Id: IETF disman Working Group mailing list <disman.dorothy.bmc.com>
...
> It was asked if it would be adequate to say in the Security Considerations
> section that resources with unstable indices (non-persistent) can
> have problems. Bert pointed out that we need a separate doc as this
> a generic problem. Randy pointed out that ADSL profiles handle it
> thru description and that it is a known limitation of VACM.
> 
> Action Item - A BCP might be needed for this general referential
> integrity problem.
...

There were specific people assigned to all the other the
action items in the minutes.  You know who you are!

I think further discussion will be necessary to figure out
what, if anything, to do about this.

An example of the basic problem is that VACM is based on the
assumption that the name of an object instance to which access
is to be controlled will remain the same across reboots.
For objects whose names change, fine-grained access control
is problematic.

However, it's not just a problem with VACM.  It shows up
anywhere where we can have things like row or instance pointers
as configuration data that needs to survive a reboot, and
those pointers can reference objects whose names might change.
So, for example, the event mib, the alarm mib, the arc mib,
the expression mib, the notification filtering in RFC 2573,
rmon's thresholding, and nmpconf pm mib scripts are just a
few examples of things that could run afoul of this.

To the extent that this isn't specifically a distributed
management problem, let's move the followup discussion to
the ops-area@ops.ietf.org mailing list.  No need to CC the
disman list in followup postings.

 ------------------------------------------------------
 Randy Presuhn          BMC Software, Inc.  1-3141
 randy_presuhn@bmc.com  2141 North First Street
 Tel: +1 408 546-1006   San José, California 95131  USA
 ------------------------------------------------------
 My opinions and BMC's are independent variables.
 ------------------------------------------------------