Disman – IETF 56

Alarm MIB

Sharon Chisholm schishol@nortelnetworks.com

Dan Romascanu dromasca@avaya.com

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