Subject: RE: [Disman] alarmListName implications

From: "Sharon Chisholm" <[email-masked]>
Date: Sat, 18 Oct 2003 17:45:12 -0400

Hi

The following is the proposed resolution to Randy-56  Assuming no objection,
this item will be considered closed conditional on the proposed edit being
done.

In the description of alarmListName replace

"      The name of the list of alarms.  This SHOULD be the same as
       nlmLogName if the Notification Log MIB [RFC3014] is supported.

       An implementation may allow multiple named alarm lists, up to
       some implementation-specific limit (which may be none).  A
       zero-length list name is reserved for creation and deletion
       by the managed system, and MUST be used as the default log
       name by systems that do not support named alarm lists."

With

"      The name of the list of alarms.  This SHOULD be the same as
       nlmLogName if the Notification Log MIB [RFC3014] is supported.
       This SHOULD be the same as, or contain as a prefix, the 
       applicable snmpNotifyFilterProfileName if the 
       SNMP-NOTIFICATION-MIB DEFINITIONS [RFC3413] is supported.         

       An implementation may allow multiple named alarm lists, up to
       some implementation-specific limit (which may be none).  A
       zero-length list name is reserved for creation and deletion
       by the managed system, and MUST be used as the default log
       name by systems that do not support named alarm lists."

Sharon

-----Original Message-----
From: Randy Presuhn [mailto:[email-masked]] 
Sent: Wednesday, October 08, 2003 3:06 PM
To: Disman (E-mail)
Subject: [Disman] alarmListName implications

Hi -

> From: "Sharon Chisholm" <[email-masked]>
> To: "Disman (E-mail)" <[email-masked]>
> Cc: <[email-masked]>; "Randy Presuhn" 
> <[email-masked]>; "Romascanu, Dan (Dan)"
<[email-masked]>
> Sent: Monday, September 29, 2003 7:34 AM
> Subject: [Disman] RE: Comments on draft-ietf-disman-alarm-mib-14.txt
...

> 56) alarmListName's DESCRIPTION should spell how this object's
>     value hooks into the SNMP-NOTIFICATION-MIB.  Without out this
>     bit of explanation, the whole thing is magic.

It's good that it explains the non-normative relationship to nlmLogName.
However, it's more important that it also be explicit about the fact that
the notification got here by matching an RFC 3413
snmpNotifyFilterProfileName, since that's the mechanism for selecting the
notifications in the first place, as sketched out in the diagram in section
3.2
<clip>

Randy

---

From: "Sharon Chisholm" <[email-masked]>
Date: Sat, 18 Oct 2003 17:45:12 -0400

Hi

With

Sharon

-----Original Message-----
From: Randy Presuhn [mailto:[email-masked]] 
Sent: Wednesday, October 08, 2003 3:06 PM
To: Disman (E-mail)
Subject: [Disman] alarmListName implications

Hi -

<[email-masked]>
...

Randy

---

From: "Sharon Chisholm" <[email-masked]>
Date: Sat, 18 Oct 2003 18:20:11 -0400

Hi

The following is the proposed resolution to Randy-60. Assuming no objection,
this item will is closed with no changes to the draft.

Sharon

-----Original Message-----
From: Randy Presuhn [mailto:[email-masked]] 
Sent: Wednesday, October 08, 2003 3:06 PM
To: Disman (E-mail)
Subject: [Disman] alarmListName implications

Hi -

<[email-masked]>
...
<clip>

> 60) alarmActiveLogPointer: should spell out that the log's name
>     would be the same as alarmListName for this instance.
>     ditto alarmClearLogIndex

I'll relent on this one, since adequate text for (56) would make this
redundant.

<clip>

Randy

---

From: "Sharon Chisholm" <[email-masked]>
Date: Sat, 18 Oct 2003 18:20:11 -0400

Hi

Sharon

-----Original Message-----
From: Randy Presuhn [mailto:[email-masked]] 
Sent: Wednesday, October 08, 2003 3:06 PM
To: Disman (E-mail)
Subject: [Disman] alarmListName implications

Hi -

<[email-masked]>
...
<clip>

<clip>

Randy

---

From: "Sharon Chisholm" <[email-masked]>
Date: Sat, 18 Oct 2003 19:10:13 -0400

Hi

The following is the proposed resolution to Randy-75-1  Assuming no
objection, this item will be considered closed conditional on the proposed
edit being done.

Add the following text to the Security Considerations section:

"This MIB module can provide access to information that may also be accessed
through manipulation of the SNMP-NOTIFICATION-MIB and the
NOTIFICATION-LOG-MIB. This is expressed in part through the common indexing
structure of nlmLogName [RFC3014], snmpNotifyFilterProfileName [RFC3413],
and alarmListName.  Consequently, it is RECOMMENDED that security
administrators take care to configure a coherent VACM security policy. The
objects alarmActiveLogPointer, alarmActiveModelPointer,
alarmActiveSpecificPointer,  and alarmClearModelPointer are object
identifiers that reference information to which a particular user might not
be given direct access.  The structure of these object identifiers does not
permit the extraction of any sensitive information. Two other objects,
alarmClearResourceId, and alarmActiveResourceId, are also syntactically
object identifiers, but their structure could provide a user with
potentially useful information to which he or she might not otherwise be
granted access, such as the existence of a particular resource."

Sharon

-----Original Message-----
From: Randy Presuhn [mailto:[email-masked]] 
Sent: Wednesday, October 08, 2003 3:06 PM
To: Disman (E-mail)
Subject: [Disman] alarmListName implications

Hi -

<[email-masked]>
...
<clip>

> 75-1) Section 7 should describe the need for security administrators 
> to configure a coherent VACM policy for the configuration of the 
> SNMP-NOTIFICATION-MIB, the log MIB, and these MIBs based on log name.
>
> Sharon->We agreed back when everyone was complaining about the 
> Sharon->notification log MIB to not tie this document to it. The goal

agree we don't need a normative reference

> Sharon->was to be able to support it and any other log.
...

That wasn't the reasoning as I recall it.  The problem was that the initial
versions of this tied alarms to log entries, and the life-cycle of a log
entry may be different from that of an alarm.

Anway, that's not the issue.

This is *not* a question of making a normative reference to the log MIB.
Rather, it's about explaining how this MIB is meant to be used. We've seen
enough complaints that I'd prefer to err on the side of being overly clear.

The relationship between RFC 3014's nlmLogName and RFC 3413's
snmpNotifyFilterProfileName (particularly since 3014 calls it
snmpNotifyFilterName) is practically an FAQ, even though 3014 2.2.1 spells
it out.  The -15- i-d  only hints at the relationship in the diagram in
section 3.2

For item 75-1, the issues are similar to those we faced when we did the log
MIB: how to design the MIB and write the security considerations section so
that we didn't "leak" information.  To me, this means providing a modicum of
guidance to security administrators in the security considerations section
so that this MIB can be used with reasonable safety.  The relationship
between nlmLogName, snmpNotifyFilterProfileName, and alarmListName is
deliberately chosen to make life easier for the security administrator.

Proposed words to add to security considerations:  "This MIB module can
provide access to information that may also be accessed through manipulation
of the SNMP-NOTIFICATION-MIB and the NOTIFICATION-LOG-MIB. This is expressed
in part through the common indexing structure of nlmLogName [RFC3014],
snmpNotifyFilterProfileName [RFC3413], and alarmListName.  Consequently, it
is RECOMMENDED that security administrators take care to configure a
coherent VACM security policy. The objects alarmActiveLogPointer,
alarmActiveModelPointer, alarmActiveSpecificPointer,  and
alarmClearModelPointer are object identifiers that reference information to
which a particular user might not be given direct access.  The structure of
these object identifiers does not permit the extraction of any sensitive
information. Two other objects, alarmClearResourceId, and
alarmActiveResourceId, are also syntactically object identifiers, but their
structure could provide a user with potentially useful information to which
he or she might not otherwise be granted access, such as the existence of a
particular resource."

Whew.

Randy

---

From: "Sharon Chisholm" <[email-masked]>
Date: Sat, 18 Oct 2003 19:10:13 -0400

Hi

Sharon

-----Original Message-----
From: Randy Presuhn [mailto:[email-masked]] 
Sent: Wednesday, October 08, 2003 3:06 PM
To: Disman (E-mail)
Subject: [Disman] alarmListName implications

Hi -

<[email-masked]>
...
<clip>

...

Whew.

Randy