Disman – IETF 56 Alarm MIB Sharon Chisholm Dan Romascanu March 2003

Alarm MIB - 1 Disman IETF 56 Alarm MIB Overview Current Status ITU-T Study Group 4 Liaison –Statement –Translation –Proposed Response Area Director Review Comments Next Steps

Alarm MIB - 2 Disman IETF 56 Status

Alarm MIB - 3 Disman IETF 56 Status Passed Working Group Last Call Currently in Area Director Review Making edits that are –Gating –Simply editorial Looking to progress to IESG

Alarm MIB - 4 Disman IETF 56 ITU-T Study Group 4 Liaison “We thank you very much for having sent us information about the IETF disman WG alarm MIB and appreciate very much the work done in this specification, as well as the presentations which were done during the SG4 meeting, February, We're encouraging consistency between all alarm management specification work. We've seen that the IETF alarm MIB has addressed concerns previously sent by ITU-T, and encourage any further cooperation. We've noted several points for further consideration and where future cooperation would be beneficial - Additional fields such as recommended actions, qualifiers - Alarm model methodology definition via a generic and multi-purpose definition instead of the current explanations based only on examples. We're looking forward for further collaboration aiming at consistency between alarm management standards, with respect to the goal of producing alarm management standards of value to all network technologies.”

Alarm MIB - 5 Disman IETF 56 ITU-T Study Group 4 Liaison Translation –Pleased their concerns have been addressed –Should we do an Alarm MIB, version 2, they’d like us to consider their suggestions. Proposed Response –Thank you for the interest –Our WG hopes to advance the current I-D to Proposed Standard, with minimal editorial changes –In the future, if the WG is chartered with an Alarm MIB2 we will be interested to cooperate with you –Translate this to nice English

Alarm MIB - 6 Disman IETF 56 Area Director Review Comments Summary of 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 * See Backup Slides

Alarm MIB - 7 Disman IETF 56 Area Director Review Comments 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 desription 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

Alarm MIB - 8 Disman IETF 56 Area Director Review Comments 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

Alarm MIB - 9 Disman IETF 56 Area Director Review Comments 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

Alarm MIB - 10 Disman IETF 56 Area Director Review Comments 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

Alarm MIB - 11 Disman IETF 56 Next Step Make necessary edits and progress Alarm MIB to IESG Send Liaison to ITU-T –Address ITU-T SG 4’s issue in later version at some point in the future.

Disman – IETF 56 Backup Slides

Alarm MIB - 13 Disman IETF 56 Area Director Review Comments AD #1 – Boilerplate –1.1 New MIB boilerplate is now preferred see 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

Alarm MIB - 14 Disman IETF 56 Area Director Review Comments 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

Alarm MIB - 15 Disman IETF 56 Area Director Review Comments 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.

Alarm MIB - 16 Disman IETF 56 Issues 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

Alarm MIB - 17 Disman IETF 56 Area Director Review Comments 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

Alarm MIB - 18 Disman IETF 56 Area Director Review Comments 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

Alarm MIB - 19 Disman IETF 56 Area Director Review Comments 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