Subject: [Disman] Issues from IESG Alarm MIB Review

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 13 Jan 2004 06:15:38 -0500

Hi

I will propose resolutions to these in separate emails.

IESG-1 

"Another issue that came up today (From IANA) is that it
is not clear to them how they assign new values:

   IANAItuProbableCause ::= TEXTUAL-CONVENTION
       STATUS current
       DESCRIPTION
           "ITU probable cause values. Duplicate values defined in X.733
           are appended with X733 to ensure uniqueness. Probable cause
           value 0 is reserved for special purposes.

           The Internet Assigned Number Authority (IANA) is responsible
           for the assignment of all Internet numbers, including
           various SNMP-related numbers, and specifically, new
           IANAItuProbableCause values. Values of
           IANAItuProbableCause less than 1024 are reserved for causes
           that correspond to ITU probable cause. IANAItuProbableCause
           of 0 is reserved for special purposes and therefore cannot
           be assigned. See http://www.iana.org"

To me it sounds that ITU defines new values, and then when they ask IANA,
then IANA will add them. Is that how we envision this? Should we mention
ITU-SG 4 as the one to ask for such values?

Can we add some text w.r.t. the FCFS assignments as to why we do not worry
about possible overlap and that this is OK? In otehr words, are we sure
nobody can screw us up one way or another. We have had some bad expericence
with large FCFS spaces in the recent past. That is why  it comes up."

IESG-2

"In the Terminology section, the draft says:

  Alarm Clear
    The detection that the fault indicated by an alarm no longer
    exists.  A Notification SHOULD be sent on alarm clear.

I'm a bit concerned about imposing a  requirement like this in the
terminology section.  Is a better place to impose this available?"

IESG-3

"In Section 3.4, the draft says:

  Security for alarms is awkward since access control for the objects
  in the underlying Notifications can be checked only where the
  Notification is created.  Thus such checking is possible only for
  locally generated Notifications, and even then only when security
  credentials are available.

This is very hard to parse, since it is difficult to understand whether the
kind of security we're talking about is access control for the alarms
themselves, access control to which Notifications refer, or something.  It
would help me, I think, if it said "for this $THREAT, there are the
following issues"."

IESG-4

"typo in the IANA Considerations --

"Values of IANAProbableCause greater than 1024" should be
IANAItuProbableCause""

IESG-5

"As far as allowing the ones over 1024 to be assigned FCFS, is this a good
idea?  What if ITU assigns them in a future document?"

In addition, there was an issue found that in the ITU Alarm MIB counter32 is
defined but not used. I will call that Other-1

Sharon Chisholm
Portfolio Integration
Nortel Networks
Ottawa, Canada