Subject: [Disman] Alarm MIB Updates from Area Director Review

From: "Sharon Chisholm" <[email-masked]>
Date: Tue, 1 Apr 2003 12:14:53 -0500

hi

We are making good progress on the updated Alarm MIB to incorporate
the comments from Bert's area director review, and I just remembered
that it was suggested that the proposed edits be sent to the mailing
list for some pre-draft airing to ensure there were no issues with
them. These edits were previously discussed in the meeting in
San Francisco.

We had hoped to get the updated draft in today, but I guess we'll
wait until Thursdays now.

Summary of Area Director Review Comments
	1. Boilerplate 
	2. IANA Considerations 
	3. Time Passes ... Things Change 
	4. Data Types and Ranges
	5. SMI Nits 
	6. Resource ID
	7. Naming
	8. Storage Type

AD #1 - Boilerplate
  1.1 New MIB boilerplate is now preferred
    see www.ops.ietf.org 
    Nice thing is that it is much shorter and has far less references.
  1.2 New MIB security guidelines to be followed
    This one is a bit more elaborate than what you 
  1.3 We want MIB Copyright in the MODULE-IDENTITY in the DESCRIPTION
clause. 
     See recent    discussions on MIBS mailing list and in
           draft-ietf-ops-mib-review-guidelines-01.txt
  1.4 Page 4, you may want to add [RFC2119] reference to the text
Proposal: Make these changes

AD #1.5 - Boilerplate
  RFCs that contain MIB modules from which you IMPORT anything must be
referenced in 
  a normative way. I say this, because for example the new boilerplate no
longer
  references RFC3411, but since you IMPORT from the MIB module in that doc,
it should  
  still be listed as normative reference
Proposal: Make this change

AD #2.1 IANA Considerations
  In the IANA maintained IANA-ITU-ALARM-TC mib, need text in DESCRIPTION
clause the
  rules/guidelines for IANA on how to add/change stuff in this MIB module.
  Also need a (normative reference) to the IANA web site where this IANA
maintained 
  MIB module will be placed. 
Proposal: The IANA Considerations section contains some description, but
will add text
          specifically to DESCRIPTION Clause. Will also add reference to
IANA website.

AD #2.2 IANA Considerations
  I would change this:
         DESCRIPTION
          "Initial version, published as RFC XXXX."
         ::= { mib-2 xx }
  Into
         DESCRIPTION
          "Initial version, published as RFC XXXX."
           -- RFC-Editor assigns XXXX
         ::= { mib-2 xx } -- to be assigned by IANA
Proposal: Make this change

AD #3.1 - Time passes ... Things Change
  Copyrights need updating.
  same for dates in MIB modules.
Proposal: Update

AD #3.2 - Time passes ... Things Change
  Working group mailing list has moved
  Needs to be updated
Proposal: Update

AD #4.1 - Data Types and Ranges
  I see:
    alarmModelVarbindIndex and alarmClearMaximum are  Integer32
  Does a negative value ever make sense?
Proposal: Change to Unsigned 32

AD #4.2 - Data Types and Ranges 
  alarmActiveEngineID is SYNTAX SnmpEngineID with a description indicating
that 
  a zero length string is possible.   
  But SnmpEngineID, as specified in RFC3411 has a SIZE(5..32).
  So it cannot be a zero length string. 
  Need either A common TC of LocalSnmpEngineOrSnmpEngineID 
      SYNTAX      OCTET STRING (SIZE (0 | 5..32))
Proposal: Create this TC

AD #4.3 - Data Types and Ranges
  I see: 
    alarmActiveContextName OBJECT-TYPE
      SYNTAX      SnmpAdminString
  I wonder if it would not be (much) better to do:
    alarmActiveContextName OBJECT-TYPE
      SYNTAX      SnmpAdminString (SIZE (0..32))
  After all, a contextName can only have that size as far as I know. Or at
least, 
  we use that size in all the SNMP MIB modules we have created so far.
  Occurs in alarmClearTable also
Proposal: Add range to both

AD #5.1 - SMI Nits
  ianaItuAlarmNumbers MODULE-IDENTITY needs a REVISION clause
Proposal: Add one

AD #5.2 - SMI Nits
  I see Underscores in the IANA-ITU-ALARM-TC mib. Formally they are not
allowed.
Proposal: Remove them

AD #5.3 - SMI Nits
  In the ITU-ALARM-TC module, I see references in the TC DESCRIPTION
clauses. 
  Would it not be better to use a REFERENCE clause?
Proposal: Add REFERENCE clauses

AD #5.4 SMI Nits
  SMIlint complains about groups not referenced:
    `ituAlarmServiceUserGroup'
    `ituAlarmSecurityGroup'
    `ituAlarmStatisticsGroup'
    'alarmActiveStatsGroup'
    `alarmClearGroup'
    `alarmNotificationsGroup'
  Now... it is not mandatory to reference it. But see bottom of page 23 of 
  draft-ietf-ops-mib-review-guidelines-01.txt which recommends to actually
list them
Proposal: Still thinking about text in review guidelines; Keep as is for now

AD #6 - Resource ID
  When I see:     
    ResourceId ::= TEXTUAL-CONVENTION
  then I wonder... is this indeed a "resourceId" in the generic sense, or
have we 
  limited it here for the ALARM-MIB type of resources?
  In other words, would it maybe better to name it:
    AlarmResourceId ::= TEXTUAL-CONVENTION
  This to avoid conflict with other types of Resources?
Proposal: As the intention was to create a textual convention for general
use, 
          keep the name  but add some description to this effect

AD #7 - Naming
  Would      
    alarmItuTc MODULE-IDENTITY
  Be more consistent as
    ituAlarmTc MODULE-IDENTITY
Proposal: Change it

AD #8 - Storage Type
  I cannot find a StorageType object or any text in a DESCRIPTION clause 
  that explains the persistency behaviour for alarmModelTable
Proposal: Add description text indicating that he alarmModelTable is
persistent

Sharon Chisholm
Portfolio Integration
Nortel Networks
Ottawa, Canada