RE: The ITU-ALARM-MIB and SpecificProblems.
"Romascanu, Dan \(Dan\)" <[email protected]> Mon, 27 Nov 2006 18:37:50 +0200
| Newsgroups | gmane.ietf.disman |
|---|---|
| Message-ID | <AAB4B3D3CF0F454F98272CBE187FDE2F0BD1A890@is0004avexu1.global.avaya.com> |
This is a multi-part message in MIME format. ------_=_NextPart_001_01C71242.60DA655C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We already have a free text field column - ituAlarmAdditionalText. Why do we need a second one?=20 =20 Dan =20 =20 =20 =20 _____ =20 From: Gamet, Thomas [mailto:[email protected]]=20 Sent: Monday, November 27, 2006 5:51 PM To: [email protected] Subject: [Disman] The ITU-ALARM-MIB and SpecificProblems. =09 =09 We are considering the use of the ituAlarmTable as an extension to the alarmMobelTable's rows that would give us the ability to report alarm data from an EMS function to an NMS using ITU standardized alarm information. The problem is that specificProblems, from X.721/X.733, is part of what makes an alarm unique but it is not provided in the definitions given in RFC 3877. =20 The TMF 814 (the probable cause qualifier), and CIM from the DMTF (the probable cause description), also provide mechanisms for extending a probable cause with more detailed or specific problem descriptions. Unlike the ITU, these other standards use only a string to provide the additional qualification/description on the probable cause (the ITU uses a SET OF construct.) May be the reason this item was omitted is that an accurate representation is difficult to achieve with SNMP? Or, was there some other mechanism in the minds of the original contributors for covering the purpose of specificProblems in the ITU standards? In either event, it needs to be available in the alarm model in order for the alarmActiveState and alarmClearState notification types to provide sufficient detail when sending notifications of alarm state changes. If possible, I'd like to see the following added to the ITU-ALARM-MIB's ItuAlarmEntry...=20 ituAlarmSpecificProblemsString SnmpAdminString=20 And=20 ituAlarmSpecificProblemsString OBJECT-TYPE=20 SYNTAX SnmpAdminString=20 MAX-ACCESS read-write=20 STATUS current=20 DESCRIPTION=20 "String version of the ITU SET OF specificProblems using ASN.1 Value Notation."=20 REFERENCES=20 "ITU Recommendation X.733,"=20 ::=3D { ituAlarmEntry 6 }=20 This should keep the data type simple for SNMP to handle and still preserve the meaning of ITU specificProblem information. It should also be data that can be shared with CIM and TMF compliant systems. Comments, suggestions and corrections are welcome. Regards,=20 Thomas Gamet=20 Interim Manager - Systems Engineering=20 Harris Corporation, Microwave Communications Division, NetBoss Business Unit=20 Tel: 321-724-3260 (USA, Eastern Time, -05:00 GMT)=20 Fax: 321-724-3940=20 E-mail: [email protected]=20 *****Confidentiality Notice***** This message is confidential. If you are not the intended recipient, you may not copy or otherwise disclose the contents of this message to any other person. If you have received this message in error, please contact the sender immediately by return e-mail. Thank you. ------_=_NextPart_001_01C71242.60DA655C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD><TITLE>The ITU-ALARM-MIB and SpecificProblems.</TITLE> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Dus-ascii"> <META content=3D"MSHTML 6.00.2900.2963" name=3DGENERATOR></HEAD> <BODY> <DIV><SPAN class=3D417213616-27112006><FONT face=3DArial color=3D#0000ff = size=3D2><STRONG><EM>We already have a free text field column -=20 </EM></STRONG><FONT color=3D#000000=20 size=3D3>ituAlarmAdditionalText</FONT><STRONG><EM>. Why do we need a = second one?=20 </EM></STRONG></FONT></SPAN></DIV> <DIV><SPAN class=3D417213616-27112006><STRONG><EM><FONT face=3DArial = color=3D#0000ff=20 size=3D2></FONT></EM></STRONG></SPAN> </DIV> <DIV><SPAN class=3D417213616-27112006><STRONG><EM><FONT face=3DArial = color=3D#0000ff=20 size=3D2>Dan</FONT></EM></STRONG></SPAN></DIV> <DIV><SPAN class=3D417213616-27112006><STRONG><EM><FONT face=3DArial = color=3D#0000ff=20 size=3D2></FONT></EM></STRONG></SPAN> </DIV> <DIV> </DIV> <DIV> </DIV> <DIV> </DIV><BR> <BLOCKQUOTE=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px = solid; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> Gamet, Thomas = [mailto:[email protected]]=20 <BR><B>Sent:</B> Monday, November 27, 2006 5:51 PM<BR><B>To:</B>=20 [email protected]<BR><B>Subject:</B> [Disman] The ITU-ALARM-MIB and=20 SpecificProblems.<BR></FONT><BR></DIV> <DIV></DIV><!-- Converted from text/rtf format --> <P><FONT face=3DArial size=3D2>We are considering the use of the = ituAlarmTable as=20 an extension to the alarmMobelTable's rows that would give us the = ability to=20 report alarm data from an EMS function to an NMS using ITU = standardized alarm=20 information. The problem is that specificProblems, from = X.721/X.733, is=20 part of what makes an alarm unique but it is not provided in the = definitions=20 given in RFC 3877. </FONT></P> <P><FONT face=3DArial size=3D2>The TMF 814 (the probable cause = qualifier), and CIM=20 from the DMTF (the probable cause description), also provide = mechanisms for=20 extending a probable cause with more detailed or specific problem=20 descriptions. Unlike the ITU, these other standards use only a = string to=20 provide the additional qualification/description on the probable cause = (the=20 ITU uses a SET OF construct.) May be the reason this item was = omitted is=20 that an accurate representation is difficult to achieve with = SNMP? Or,=20 was there some other mechanism in the minds of the original = contributors for=20 covering the purpose of specificProblems in the ITU standards? = In either=20 event, it needs to be available in the alarm model in order for the=20 alarmActiveState and alarmClearState notification types to provide = sufficient=20 detail when sending notifications of alarm state changes.</FONT></P> <P><FONT face=3DArial size=3D2>If possible, I'd like to see the = following added to=20 the ITU-ALARM-MIB's ItuAlarmEntry…</FONT> <BR><FONT face=3DArial = size=3D2> =20 = ituAlarmSpecificProblemsString = SnmpAdminString</FONT> </P> <P><FONT face=3DArial size=3D2>And </FONT><BR><FONT face=3DArial=20 size=3D2>ituAlarmSpecificProblemsString OBJECT-TYPE</FONT> <BR><FONT = face=3DArial=20 size=3D2> SYNTAX =20 SnmpAdminString</FONT> <BR><FONT face=3DArial size=3D2> =20 MAX-ACCESS read-write</FONT> <BR><FONT face=3DArial=20 size=3D2> STATUS = current</FONT>=20 <BR><FONT face=3DArial size=3D2> DESCRIPTION</FONT>=20 <BR> <FONT face=3DArial = size=3D2>"String=20 version of the ITU SET OF specificProblems using ASN.1 Value = Notation."</FONT>=20 <BR><FONT face=3DArial size=3D2> REFERENCES</FONT>=20 <BR> <FONT face=3DArial = size=3D2>"ITU=20 Recommendation X.733,"</FONT> <BR><FONT face=3DArial size=3D2> = ::=3D {=20 ituAlarmEntry 6 }</FONT> </P> <P><FONT face=3DArial size=3D2>This should keep the data type simple = for SNMP to=20 handle and still preserve the meaning of ITU specificProblem=20 information. It should also be data that can be shared with CIM = and TMF=20 compliant systems. Comments, suggestions and corrections are=20 welcome.</FONT></P> <P><FONT face=3DArial size=3D2>Regards,</FONT> </P> <P><FONT face=3DArial size=3D2>Thomas Gamet</FONT> <BR><FONT = face=3DArial=20 size=3D2>Interim Manager - Systems Engineering</FONT> <BR><FONT = face=3DArial=20 size=3D2>Harris Corporation, Microwave Communications Division, = NetBoss Business=20 Unit</FONT> <BR><FONT face=3DArial size=3D2>Tel: 321-724-3260 = (USA, Eastern=20 Time, -05:00 GMT)</FONT> <BR><FONT face=3DArial size=3D2>Fax: = 321-724-3940</FONT>=20 <BR><FONT face=3DArial size=3D2>E-mail: [email protected]</FONT> = </P> <UL> <P align=3Dcenter><FONT face=3DTahoma color=3D#000000 = size=3D1>*****Confidentiality=20 Notice*****</FONT></P> <P><FONT face=3DTahoma color=3D#000000 size=3D1>This message is = confidential. If=20 you are not the intended recipient, you may not copy or otherwise = disclose=20 the contents of this message to any other person. If you have = received this=20 message in error, please contact the sender immediately by return = e-mail.=20 Thank = you.</FONT></P><BR><BR><BR><BR></UL></BLOCKQUOTE></BODY></HTML> ------_=_NextPart_001_01C71242.60DA655C--