Alarm Management Information Base (MIB)
RFC 3877
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2020-01-21 |
18 | (System) | Received changes through RFC Editor sync (added Verified Errata tag) |
2015-10-14 |
18 | (System) | Notify list changed from <randy_presuhn@mindspring.com>, <schishol@nortelnetworks.com>,<dromasca@avaya.com> to (None) |
2012-08-22 |
18 | (System) | post-migration administrative database adjustment to the No Objection position for Bert Wijnen |
2005-06-10 |
(System) | Posted related IPR disclosure: Nortel Networks Updated Patent Statement pertaining to draft-chisholm-disman-active-alarm about IPR claimed in RFC 3877 | |
2004-09-28 |
18 | Amy Vezza | State Changes to RFC Published from RFC Ed Queue by Amy Vezza |
2004-09-28 |
18 | Amy Vezza | [Note]: 'RFC 3877' added by Amy Vezza |
2004-09-21 |
18 | (System) | RFC published |
2004-03-17 |
18 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
2004-03-16 |
18 | Amy Vezza | IESG state changed to Approved-announcement sent |
2004-03-16 |
18 | Amy Vezza | IESG has approved the document |
2004-03-16 |
18 | Amy Vezza | Closed "Approve" ballot |
2004-03-16 |
18 | Bert Wijnen | State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Bert Wijnen |
2004-03-16 |
18 | Bert Wijnen | [Ballot Position Update] Position for Bert Wijnen has been changed to No Objection from Discuss by Bert Wijnen |
2004-03-16 |
18 | Bert Wijnen | Revision 18 addresses IANA Considerations clarifications. |
2004-03-16 |
18 | Bert Wijnen | State Change Notice email list have been change to <randy_presuhn@mindspring.com>, <schishol@nortelnetworks.com>,<dromasca@avaya.com> from <randy_presuhn@mindspring.com> |
2004-03-16 |
18 | Bert Wijnen | Status date has been changed to 2004-03-16 from 2004-01-02 |
2004-03-16 |
18 | Bert Wijnen | [Note]: 'The revision 17 has been submitted, but is not yet at internet-drafts repository. FOr now, it can be accessed at http://www.psg.com/~bwijnen/draft-ietf-disman-alarm-mib-17.txt' has been cleared … [Note]: 'The revision 17 has been submitted, but is not yet at internet-drafts repository. FOr now, it can be accessed at http://www.psg.com/~bwijnen/draft-ietf-disman-alarm-mib-17.txt' has been cleared by Bert Wijnen |
2004-02-11 |
18 | (System) | New version available: draft-ietf-disman-alarm-mib-18.txt |
2004-01-08 |
18 | Amy Vezza | Removed from agenda for telechat - 2004-01-08 by Amy Vezza |
2004-01-08 |
18 | Amy Vezza | State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza |
2004-01-08 |
18 | Amy Vezza | [Ballot Position Update] New position, No Objection, has been recorded for Harald Alvestrand by Amy Vezza |
2004-01-08 |
18 | Bert Wijnen | [Ballot discuss] On behalf of IANA: how are values under 1024 being assigned... |
2004-01-08 |
18 | Bert Wijnen | [Ballot discuss] On behalf of IANA |
2004-01-08 |
18 | Bert Wijnen | [Ballot Position Update] Position for Bert Wijnen has been changed to Discuss from Yes by Bert Wijnen |
2004-01-08 |
18 | Alex Zinin | [Ballot Position Update] New position, No Objection, has been recorded for Alex Zinin by Alex Zinin |
2004-01-08 |
18 | Bill Fenner | [Ballot Position Update] New position, No Objection, has been recorded for Bill Fenner by Bill Fenner |
2004-01-08 |
18 | Thomas Narten | [Ballot Position Update] New position, No Objection, has been recorded for Thomas Narten by Thomas Narten |
2004-01-08 |
18 | Margaret Cullen | [Ballot comment] This document is exceptionally clear and well-written. |
2004-01-08 |
18 | Margaret Cullen | [Ballot Position Update] New position, Yes, has been recorded for Margaret Wasserman by Margaret Wasserman |
2004-01-08 |
18 | Jon Peterson | [Ballot Position Update] New position, No Objection, has been recorded for Jon Peterson by Jon Peterson |
2004-01-07 |
18 | Allison Mankin | [Ballot Position Update] Position for Allison Mankin has been changed to No Objection from Undefined by Allison Mankin |
2004-01-07 |
18 | Allison Mankin | [Ballot comment] Typo in the IANA Considerations -- "Values of IANAProbableCause greater than 1024" should be IANAItuProbableCause As far as allowing the ones over 1024 … [Ballot comment] Typo in the IANA Considerations -- "Values of IANAProbableCause greater than 1024" should be IANAItuProbableCause 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? |
2004-01-07 |
18 | Allison Mankin | [Ballot Position Update] New position, Undefined, has been recorded for Allison Mankin by Allison Mankin |
2004-01-06 |
18 | Ted Hardie | [Ballot Position Update] Position for Ted Hardie has been changed to No Objection from Undefined by Ted Hardie |
2004-01-06 |
18 | Ted Hardie | [Ballot comment] In the Terminology section, the draft says: Alarm Clear The detection that the fault indicated by an alarm no longer … [Ballot comment] 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? 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". |
2004-01-06 |
18 | Ted Hardie | [Ballot Position Update] New position, Undefined, has been recorded for Ted Hardie by Ted Hardie |
2004-01-06 |
18 | Steven Bellovin | [Ballot Position Update] New position, No Objection, has been recorded for Steve Bellovin by Steve Bellovin |
2004-01-06 |
17 | (System) | New version available: draft-ietf-disman-alarm-mib-17.txt |
2004-01-05 |
18 | Russ Housley | [Ballot Position Update] New position, No Objection, has been recorded for by Russ Housley |
2004-01-03 |
18 | Ned Freed | [Ballot Position Update] New position, No Objection, has been recorded for by Ned Freed |
2004-01-02 |
18 | Bert Wijnen | [Ballot Position Update] New position, Yes, has been recorded for Bert Wijnen |
2004-01-02 |
18 | Bert Wijnen | Ballot has been issued by Bert Wijnen |
2004-01-02 |
18 | Bert Wijnen | Created "Approve" ballot |
2004-01-02 |
18 | Bert Wijnen | Placed on agenda for telechat - 2004-01-08 by Bert Wijnen |
2004-01-02 |
18 | Bert Wijnen | State Changes to IESG Evaluation from Waiting for AD Go-Ahead::Revised ID Needed by Bert Wijnen |
2004-01-02 |
18 | Bert Wijnen | [Note]: 'The revision 17 has been submitted, but is not yet at internet-drafts repository. FOr now, it can be accessed at http://www.psg.com/~bwijnen/draft-ietf-disman-alarm-mib-17.txt' added by Bert … [Note]: 'The revision 17 has been submitted, but is not yet at internet-drafts repository. FOr now, it can be accessed at http://www.psg.com/~bwijnen/draft-ietf-disman-alarm-mib-17.txt' added by Bert Wijnen |
2004-01-02 |
18 | Bert Wijnen | State Changes to Waiting for AD Go-Ahead::Revised ID Needed from Waiting for Writeup by Bert Wijnen |
2004-01-02 |
18 | Bert Wijnen | Status date has been changed to 2004-01-02 from 2003-12-11 |
2004-01-02 |
18 | Bert Wijnen | [Note]: 'New revision expected to address SYNTAX checking issues' added by Bert Wijnen |
2003-12-25 |
18 | (System) | State has been changed to Waiting for Writeup from In Last Call by system |
2003-12-11 |
18 | Amy Vezza | Last call sent |
2003-12-11 |
18 | Amy Vezza | State Changes to In Last Call from Last Call Requested by Amy Vezza |
2003-12-11 |
18 | Bert Wijnen | Last Call was requested by Bert Wijnen |
2003-12-11 |
18 | Bert Wijnen | State Changes to Last Call Requested from AD Evaluation::Revised ID Needed by Bert Wijnen |
2003-12-11 |
18 | (System) | Ballot writeup text was added |
2003-12-11 |
18 | (System) | Last call text was added |
2003-12-11 |
18 | (System) | Ballot approval text was added |
2003-12-11 |
18 | Bert Wijnen | [Note]: 'IETF Last Call requested' added by Bert Wijnen |
2003-12-11 |
18 | Bert Wijnen | Status date has been changed to 2003-12-11 from 2003-09-03 |
2003-11-21 |
16 | (System) | New version available: draft-ietf-disman-alarm-mib-16.txt |
2003-10-01 |
15 | (System) | New version available: draft-ietf-disman-alarm-mib-15.txt |
2003-09-03 |
18 | Bert Wijnen | Athors (Sharon) answered we can expect a new rev soon |
2003-09-03 |
18 | Bert Wijnen | Status date has been changed to 2003-09-03 from 2003-08-07 |
2003-08-28 |
18 | Bert Wijnen | checking with authors and WG chairs on what the status is and when to expect new rev., |
2003-08-07 |
18 | Bert Wijnen | WG chairs posted a list of 75 items to be addressed to WG mailing list today (Aug 7th) |
2003-08-07 |
18 | Bert Wijnen | Status date has been changed to 2003-08-07 from 2003-06-06 |
2003-06-10 |
14 | (System) | New version available: draft-ietf-disman-alarm-mib-14.txt |
2003-06-06 |
18 | Bert Wijnen | Revision 13 still has some issues: -----Original Message----- From: Wijnen, Bert (Bert) Sent: donderdag 5 juni 2003 15:22 To: Dan Romascanu (E-mail); Sharon Chisholm (E-mail) … Revision 13 still has some issues: -----Original Message----- From: Wijnen, Bert (Bert) Sent: donderdag 5 juni 2003 15:22 To: Dan Romascanu (E-mail); Sharon Chisholm (E-mail) Cc: Randy Presuhn (E-mail); Wijnen, Bert (Bert) Subject: RE: I-D ACTION:draft-ietf-disman-alarm-mib-13.txt You guys keep confusing me... I now checked revision 13 I see: - citations to RFC1905, while you have (correctly) changed the entry in the references section to RFC3416. Of course the citation should be in sync - I now see: LocalSnmpEngineOrZeroLenStr ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An SNMP Engine ID or a zero length string. The instantiation of this object will provide guidance on when this will be an SNMP Engine ID and when it will be a zero lengths string" SYNTAX OCTET STRING (SIZE(1..32)) Which is an improvement over the earlier OBJECT-IDENTIFIER, but you exlude zero as a possible size and yet the description clause indocates that zero length string sis OK. I had suggested that the best SYNTAX would be: SYNTAX OCTET STRING (SIZE (0 | 5..32)) Since lengths of 1,2,3,4 are not valid EngineIDs either - You have citations to RFC2576, but it is not in the References section. By the way, I expect the follow up of coex to be approved by IEESG this coming Thursday. New things I saw: - RFC2037 has been obsoleted by RFC2737... would it be better to refrence newer RFC? - PrinterMib has just been approved to obsolete RFC1759 draft-ietf-printmib-mib-info-15.txt. You may want to consider to reference new RFC-to-be (it is in RFC-Editor queue) instead. If so, pls check, cause object definitions have changed a bit. Thanks, Bert |
2003-06-06 |
18 | Bert Wijnen | Status date has been changed to 2003-06-06 from 2003-05-06 |
2003-06-02 |
13 | (System) | New version available: draft-ietf-disman-alarm-mib-13.txt |
2003-05-07 |
18 | Bert Wijnen | Revision 12 still has several nits. And at least 2 things that are trouble: It has quite a few non-ASCII characters. See below output of … Revision 12 still has several nits. And at least 2 things that are trouble: It has quite a few non-ASCII characters. See below output of checkpage. Most are at page breaks (which also I think) cuases the 73 char lines A few of them are in the alarm MIB: alarmGroups OBJECT IDENTIFIER ::= { alarmConformance 2 }xE1 alarmActiveVariableOpaqueValxE1 xE1 So cause syntax errors I am also surprised by (a fix that you made on my request): LocalSnmpEngineOrZeroLenStr ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An SNMP Engine ID or a zero length string. The instantiation of this object will provide guidance on when this will be an SNMP Engine ID and when it will be a zero lengths string" SYNTAX OBJECT IDENTIFIER Should that not be a OCTET STRING ?? And to be precize: SYNTAX OCTET STRING (SIZE (0 | 5..32)) Full set of comments below. -----Original Message----- From: Wijnen, Bert (Bert) Sent: dinsdag 6 mei 2003 16:44 To: Dan Romascanu (E-mail); Sharon Chisholm (E-mail) Cc: Randy Presuhn (E-mail) Subject: FW: I-D ACTION:draft-ietf-disman-alarm-mib-12.txt So I checked this new revision.... Mmm.... sending to you first instead of disman list. It has quite a few non-ASCII characters. See below output of checkpage. Most are at page breaks (which also I think) cuases the 73 char lines A few of them are in the alarm MIB: alarmGroups OBJECT IDENTIFIER ::= { alarmConformance 2 }xE1 alarmActiveVariableOpaqueValxE1 xE1 So cause syntax errors I am also surprised by (a fix that you made on my request): LocalSnmpEngineOrZeroLenStr ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "An SNMP Engine ID or a zero length string. The instantiation of this object will provide guidance on when this will be an SNMP Engine ID and when it will be a zero lengths string" SYNTAX OBJECT IDENTIFIER Should that not be a OCTET STRING ?? And to be precize: SYNTAX OCTET STRING (SIZE (0 | 5..32)) I still see (useless) references to old MIB-boilerplate docuemnts in the (normative) references section. Namely... do we need: [RFC1155], [RFC1157], [RFC1212], [RFC1215], [RFC1901], [RFC1906] I also still see refrences to [RFC1905], which I think should be to [RFC3416]. In the Informative references I see a ref to [RFC2233]. Should that not be [RFC2863] ?? The copyright statement on Page35 now reeads: Copyright (C) The Internet Society 2003." I had posted to the mibs@ops.ietf.org (4th of april, so after you posted your revision I suspect, but given the other comments I have I might as well add this) that it should be: Copyright (C) The Internet Society (year). The initial version of this MIB module was published in RFC xxxx. For full legal notices see the RFC itself or see: http://www.ietf.org/copyrights/ianamib.html Also, Dan had suggested to add some explanatory text which I do not yet see, see his email below. Did I not also question the fact that you have [RFCxxxx] and [MMMM.3100] and [X.733] references in DESCRIPTION clauses of objects? The problem (minor) I see is that if they MIB module gets extracted from the doc, then those references/citations are no longer valid. I tend to suggest to people to use (RFCxxxx) instead of [RFCxxxx]. A nit I guess. In many cases however, such thing probably warrant a REFERENCE clause, no? My SMICng run still says: C:?wijnensmicngwork>smicng alarm.inc W: f(alarm.mi2), (620,19) Item "alarmActiveVariableOctetStringVal" should have SIZE specified Would it be too much to add a SIZE (0..65535) ?? W: f(alarm.mi2), (651,4) SMIv2 discourages used of Opaque for SYNTAX value of "alarmActiveVariableOpaqueVal" We can ignore that W: f(alarm.mi2), (652,19) Item "alarmActiveVariableOpaqueVal" should have SIZE specified Would it be too much to add a SIZE (0..65535) ?? W: f(alarm.mi2), (530,33) Row "alarmActiveVariableEntry" does not have a consistent indexing scheme - index items must be in same order as used in INDEX clause for "base row" alarmActiveEntry Even with Dan's explanatory text, it looks weird. But if the others think it is OK, I will accept. I am surprised that Perkins did not jump on it earlier. W: f(alarm.mi2), (983,8) OBJECT-GROUP "alarmActiveStatsGroup" is not used in a MODULE-COMPLIANCE in current module W: f(alarm.mi2), (995,4) OBJECT-GROUP "alarmClearGroup" is not used in a MODULE-COMPLIANCE in current module W: f(alarm.mi2), (1012,4) NOTIFICATION-GROUP "alarmNotificationsGroup" is not used in a MODULE-COMPLIANCE in current module I think our MIB Doctor Review Guidelines RECOMMEND to list them and explain in the DESCRIPTION clause that they are optional, see sect 4.8 of draft-ietf-ops-mib-review-guidelines-01.txt *** 0 errors and 7 warnings in parsing W: f(itualarm.mi2), (360,4) OBJECT-GROUP "ituAlarmServiceUserGroup" is not used in a MODULE-COMPLIANCE in current module W: f(itualarm.mi2), (370,4) OBJECT-GROUP "ituAlarmSecurityGroup" is not used in a MODULE-COMPLIANCE in current module W: f(itualarm.mi2), (381,4) OBJECT-GROUP "ituAlarmStatisticsGroup" is not used in a MODULE-COMPLIANCE in current module I think our MIB Doctor Review Guidelines RECOMMEND to list them and explain in the DESCRIPTION clause that they are optional, see sect 4.8 of draft-ietf-ops-mib-review-guidelines-01.txt Thanks, Bert -----Original Message----- From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] Sent: maandag 28 april 2003 18:24 To: Wijnen, Bert (Bert); Sharon Chisholm; Randy Presuhn Subject: RE: [Disman] Re: draft-ietf-disman-alarm-mib-11.txt Sure. In the DESCRIPTION clause of alarmActiveDateAndTime I suggest that we add: 'This index serves the purpose of helping applications retrieve active entries entered after a certain moment in time.' In the DESCRIPTION clause of alarmActiveVariableEntry, add after the first phrase: 'Entries in the alarmActiveTable are uniquely identified by alarmListname and alarmActiveIndex.' Sharon, if you are OK with this, please add to your revision. Dan ------------ Bert Wijnen ran: checkpage.awk and it tells us: Long page at 59 Bad chars at 60 Long line at 60 with 73 chars Bad chars at 118 Long line at 118 with 73 chars Bad chars at 176 Long line at 176 with 73 chars Bad chars at 234 Long line at 234 with 73 chars Bad chars at 292 Long line at 292 with 73 chars Bad chars at 350 Long line at 350 with 73 chars Bad chars at 408 Long line at 408 with 73 chars Bad chars at 466 Long line at 466 with 73 chars Bad chars at 524 Long line at 524 with 73 chars Bad chars at 582 Long line at 582 with 73 chars Bad chars at 640 Long line at 640 with 73 chars Bad chars at 698 Long line at 698 with 73 chars Bad chars at 756 Long line at 756 with 73 chars Bad chars at 814 Long line at 814 with 73 chars Bad chars at 872 Long line at 872 with 73 chars Bad chars at 930 Long line at 930 with 73 chars Bad chars at 988 Long line at 988 with 73 chars Bad chars at 1046 Long line at 1046 with 73 chars Bad chars at 1104 Long line at 1104 with 73 chars Bad chars at 1162 Long line at 1162 with 73 chars Bad chars at 1220 Long line at 1220 with 73 chars Bad chars at 1278 Long line at 1278 with 73 chars Bad chars at 1336 Long line at 1336 with 73 chars Bad chars at 1394 Long line at 1394 with 73 chars Bad chars at 1452 Long line at 1452 with 73 chars Bad chars at 1510 Long line at 1510 with 73 chars Bad chars at 1568 Long line at 1568 with 73 chars Bad chars at 1626 Long line at 1626 with 73 chars Bad chars at 1684 Long line at 1684 with 73 chars Bad chars at 1742 Long line at 1742 with 73 chars Bad chars at 1800 Long line at 1800 with 73 chars Bad chars at 1815 Bad chars at 1858 Long line at 1858 with 73 chars Bad chars at 1865 Bad chars at 1916 Long line at 1916 with 73 chars Bad chars at 1974 Long line at 1974 with 73 chars Bad chars at 2032 Long line at 2032 with 73 chars Bad chars at 2090 Long line at 2090 with 73 chars Bad chars at 2148 Long line at 2148 with 73 chars Bad chars at 2206 Long line at 2206 with 73 chars Bad chars at 2264 Long line at 2264 with 73 chars Bad chars at 2322 Long line at 2322 with 73 chars Bad chars at 2380 Long line at 2380 with 73 chars Bad chars at 2438 Long line at 2438 with 73 chars Bad chars at 2496 Long line at 2496 with 73 chars Bad chars at 2554 Long line at 2554 with 73 chars Bad chars at 2612 Long line at 2612 with 73 chars Bad chars at 2670 Long line at 2670 with 73 chars Bad chars at 2728 Long line at 2728 with 73 chars Bad chars at 2786 Long line at 2786 with 73 chars Bad chars at 2844 Long line at 2844 with 73 chars Bad chars at 2902 Long line at 2902 with 73 chars Bad chars at 2960 Long line at 2960 with 73 chars Bad chars at 3018 Long line at 3018 with 73 chars Bad chars at 3076 Long line at 3076 with 73 chars Bad chars at 3134 Long line at 3134 with 73 chars Bad chars at 3192 Long line at 3192 with 73 chars Bad chars at 3250 Long line at 3250 with 73 chars Bad chars at 3308 Long line at 3308 with 73 chars Bad chars at 3366 Long line at 3366 with 73 chars Bad chars at 3424 Long line at 3424 with 73 chars Bad chars at 3482 Long line at 3482 with 73 chars Bad chars at 3540 Long line at 3540 with 73 chars Bad chars at 3598 Long line at 3598 with 73 chars Bad chars at 3656 Long line at 3656 with 73 chars Bad chars at 3714 Long line at 3714 with 73 chars -: 66 lines containing non-US-ASCII characters -: 64 lines longer than 72 characters, max 73 -: 1 pages longer than 58 lines, max 3771 lines |
2003-05-07 |
18 | Bert Wijnen | Status date has been changed to 2003-05-06 from 2003-04-08 |
2003-05-07 |
18 | Bert Wijnen | State Changes to AD Evaluation :: Revised ID Needed from AD Evaluation by Wijnen, Bert |
2003-04-29 |
12 | (System) | New version available: draft-ietf-disman-alarm-mib-12.txt |
2003-04-17 |
11 | (System) | New version available: draft-ietf-disman-alarm-mib-11.txt |
2003-04-08 |
18 | Bert Wijnen | WG chairs asked WG for possible comment on the new revision before putting it back on AD plate. The WG needs to respond by April … WG chairs asked WG for possible comment on the new revision before putting it back on AD plate. The WG needs to respond by April 14th |
2003-04-08 |
18 | Bert Wijnen | Status date has been changed to 2003-04-08 from 2003-03-15 |
2003-04-08 |
18 | Bert Wijnen | State Changes to AD Evaluation from AD Evaluation :: Revised ID Needed by Wijnen, Bert |
2003-04-04 |
10 | (System) | New version available: draft-ietf-disman-alarm-mib-10.txt |
2003-03-24 |
18 | Bert Wijnen | AD review comments posted to the WG list: -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: zaterdag 15 maart 2003 21:38 To: Disman … AD review comments posted to the WG list: -----Original Message----- From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com] Sent: zaterdag 15 maart 2003 21:38 To: Disman (E-mail) (E-mail) Subject: [Disman] AD review of: draft-ietf-disman-alarm-mib-09.txt Sorry that it took so long. - New MIB boilerplate is now prefered see www.ops.ietf.org Nice thing is that it is much shorter and has far less references. - New MIB security guidelines to be followed see www.ops.ietf.org This one is a bit more elaborate than what you currently have - 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 - Page 4, you may want to add [RFC2119] refernece to the text - In the IANA maintained IANA-ITU-ALARM-TC mib, pls add in DESCRIPTION clause the rules/guidelines for IANA on how to add/change stuff in this MIB module. Pls also add (or instruct RFC-editor to add) a (normative reference) to the iana web site where this IANA maintained MIB module will be placed. Also, add text to make it clear that this is only the initial module and that the authoritative copy to be referenced in any future document must be the one at iana web site. Not sure if this was posted anywhere yet (it should show up in our IESG minutes), but 20 Feb, IESG discussed this in their bi-weekly telechat. Here is the result: The IESG discussed if new IANA-maintained MIB modules should be published as (part of) an RFC. The consensus is that the initial version indeed is to be in an RFC. The version in that RFC MUST make sure that some statement is made that the authoritative version of the IANA-maintained MIB module is at the IANA web pages. I guess 2nd para in sect 5.2 does that. May want to add the ref to the iana web page to be - ianaItuAlarmNumbers MODULE-IDENTITY needs a REVISION clause - I prefer to see ::= { mib-2 xx} -- to be assigned by IANA That is, add the comment that IANA needs to assign a value So that IANA can clearly see where they need to do things This holds for all MIB modules. In fact, 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 - 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? - I see: alarmModelVarbindIndex OBJECT-TYPE SYNTAX Integer32 Does a negative value ever make sense? Is an Unsigned32 SYNTAX better? - I cannot find a StorageType object or any text in a DESCRIPTION clause that explains the persistency behavioru for alarmModelTable I believe this is so for more tables in this(these) MIB module(s) - I see: alarmActiveEngineID OBJECT-TYPE SYNTAX SnmpEngineID MAX-ACCESS read-only STATUS current DESCRIPTION "The identification of the SNMP engine at which the alarm originated. If the alarm list can contain alarms from only one engine or the alarm is from an SNMPv1 system, this object is a zero length string." But... the SnmpEngineID as specified in RFC3411 has a SIZE(5..32). So it cannot be a zero length string. What you need is a LocalSnmpEngineOrSnmpEngineID or some such. The PM-MIB in SNMPCONF WG had same problem. In rev 13, they now have: pmRoleContextEngineID OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0 | 5..32)) Maybe this calls for a common TC ?? If not, then you can solve it in a similar way - 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 mdoules we have created sofar. Occurs in alarmClearTable also - I see: alarmClearMaximum OBJECT-TYPE SYNTAX Integer32 Would a negative value ever make sense? - I see Underscores in the IANA-ITU-ALARM-TC mib. Formally they are not allowed. So why are we doing this? I do not see a good reason. Can we not just leave the underscore out? Maybe this was discussed on WG .. pls refresh my memory if so. - SMIlint tells me about ITU-ALARM-MIB: .ITU-ALARM-MIB:359: warning: current group `ituAlarmServiceUserGroup' is not referenced in this module .ITU-ALARM-MIB:369: warning: current group `ituAlarmSecurityGroup' is not referenced in this module .ITU-ALARM-MIB:380: warning: current group `ituAlarmStatisticsGroup' is not referenced in this module 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 - SMIlint tells me about ALARM-MIB: .ALARM-MIB:967: warning: current group `alarmActiveStatsGroup' is not referenced in this module .ALARM-MIB:980: warning: current group `alarmClearGroup' is not referenced in this module .ALARM-MIB:997: warning: current group `alarmNotificationsGroup' is not referenced in this module Same comments as above. - I am missing an IPR statement. - when you do an update, pls update the year for the copyrigth statements in various places. - same for dates in MIB modules. - Pls realize that RFCs that contain MIB modules from which you IMPORT anything must be referenced in a normative way. I say this, cause for example the new boilerplate no longer refrences RFC3411, but since you IMPORT from the MIB module in that doc, it should still be listed as noramative reference. - I believe that the WG mailing list has moved to IETF site, so pls update that information as well (in the MIB modules). - I wonder if alarmItuTc MODULE-IDENTITY would not be better (and more in line with the rest of the naming) ituAlarmTc MODULE-IDENTITY - In the ITU-ALARM-TC module, I see references in the TC DESCRIPTION clauses. Would it not be better to use a REFERENCE clause? - In the ITU-ALARM-MIB I see references in the various DESCRIPTION clauses. Would it not be better to use a REFERENCE clause? Thanks, Bert |
2003-03-24 |
18 | Bert Wijnen | Status date has been changed to 2003-03-15 from |
2003-03-24 |
18 | Bert Wijnen | State Changes to AD Evaluation :: Revised ID Needed from AD Evaluation by Wijnen, Bert |
2002-11-13 |
18 | Jacqueline Hargest | Draft Added by Hargest, Jacqueline |
2002-09-30 |
09 | (System) | New version available: draft-ietf-disman-alarm-mib-09.txt |
2002-08-29 |
08 | (System) | New version available: draft-ietf-disman-alarm-mib-08.txt |
2002-07-03 |
07 | (System) | New version available: draft-ietf-disman-alarm-mib-07.txt |
2002-03-27 |
06 | (System) | New version available: draft-ietf-disman-alarm-mib-06.txt |
2002-02-06 |
05 | (System) | New version available: draft-ietf-disman-alarm-mib-05.txt |
2002-01-08 |
04 | (System) | New version available: draft-ietf-disman-alarm-mib-04.txt |
2001-10-16 |
03 | (System) | New version available: draft-ietf-disman-alarm-mib-03.txt |
2001-04-30 |
02 | (System) | New version available: draft-ietf-disman-alarm-mib-02.txt |
2001-03-05 |
01 | (System) | New version available: draft-ietf-disman-alarm-mib-01.txt |
2001-01-30 |
00 | (System) | New version available: draft-ietf-disman-alarm-mib-00.txt |