Disman – IETF 56
Alarm MIB
Sharon Chisholm [email protected]
Dan Romascanu [email protected]
March 2003
Alarm MIB - 2Disman IETF 56
Alarm MIBOverview• Current Status
• ITU-T Study Group 4 Liaison– Statement– Translation– Proposed Response
• Area Director Review Comments
• Next Steps
Alarm MIB - 3Disman IETF 56
Status
Alarm MIB - 4Disman 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 - 5Disman 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, 2003.
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 - 6Disman 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 - 7Disman IETF 56
Area Director Review Comments
• Summary of Review Comments1. Boilerplate *2. IANA Considerations *3. Time Passes … Things Change *4. Data Types and Ranges5. SMI Nits *6. Resource ID7. Naming8. Storage Type
* See Backup Slides
Alarm MIB - 8Disman 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 - 9Disman 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 - 10Disman 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 - 11Disman 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 - 12Disman 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 - 14Disman IETF 56
Area Director Review Comments
• 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
Alarm MIB - 15Disman 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 - 16Disman 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 - 17Disman 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 - 18Disman 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 - 19Disman 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 - 20Disman 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