The ITU-ALARM-MIB and SpecificProblems.

"Gamet, Thomas" <[email protected]> Mon, 27 Nov 2006 10:51:04 -0500
Newsgroups gmane.ietf.disman
Message-ID <[email protected]>
This is a multi-part message in MIME format.

------_=_NextPart_001_01C7123B.D98FB80D
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

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...
  ituAlarmSpecificProblemsString	SnmpAdminString

And=20
ituAlarmSpecificProblemsString OBJECT-TYPE
  SYNTAX	SnmpAdminString
  MAX-ACCESS	read-write
  STATUS	current
  DESCRIPTION
	"String version of the ITU SET OF specificProblems using ASN.1
Value Notation."
  REFERENCES
	"ITU Recommendation X.733,"
  ::=3D { ituAlarmEntry 6 }

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,

Thomas Gamet
Interim Manager - Systems Engineering
Harris Corporation, Microwave Communications Division, NetBoss Business
Unit
Tel:  321-724-3260 (USA, Eastern Time, -05:00 GMT)
Fax: 321-724-3940
E-mail:  [email protected]

	*****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_01C7123B.D98FB80D
Content-Type: text/html;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
6.5.7650.28">
<TITLE>The ITU-ALARM-MIB and SpecificProblems.</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/rtf format -->

<P><FONT SIZE=3D2 FACE=3D"Arial">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.&nbsp; 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.&nbsp; </FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">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.&nbsp; 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.)&nbsp; May be the reason this item was omitted is that an =
accurate representation is difficult to achieve with SNMP?&nbsp; Or, was =
there some other mechanism in the minds of the original contributors for =
covering the purpose of specificProblems in the ITU standards?&nbsp; 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.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">If possible, I'd like to see the =
following added to the ITU-ALARM-MIB's ItuAlarmEntry&#8230;</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp; =
ituAlarmSpecificProblemsString&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
SnmpAdminString</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">And </FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">ituAlarmSpecificProblemsString =
OBJECT-TYPE</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp; =
SYNTAX&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; SnmpAdminString</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp; MAX-ACCESS&nbsp;&nbsp;&nbsp; =
read-write</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp; =
STATUS&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; current</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp; DESCRIPTION</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">&quot;String version of the ITU SET OF specificProblems =
using ASN.1 Value Notation.&quot;</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp; REFERENCES</FONT>

<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <FONT SIZE=3D2 =
FACE=3D"Arial">&quot;ITU Recommendation X.733,&quot;</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">&nbsp; ::=3D { ituAlarmEntry 6 =
}</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">This should keep the data type simple =
for SNMP to handle and still preserve the meaning of ITU specificProblem =
information.&nbsp; It should also be data that can be shared with CIM =
and TMF compliant systems.&nbsp; Comments, suggestions and corrections =
are welcome.</FONT></P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Regards,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">Thomas Gamet</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Interim Manager - Systems =
Engineering</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Harris Corporation, Microwave =
Communications Division, NetBoss Business Unit</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Tel:&nbsp; 321-724-3260 (USA, Eastern =
Time, -05:00 GMT)</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">Fax: 321-724-3940</FONT>

<BR><FONT SIZE=3D2 FACE=3D"Arial">E-mail:&nbsp; [email protected]</FONT>
</P>
<UL>
<P ALIGN=3DCENTER><FONT COLOR=3D"#000000" SIZE=3D1 =
FACE=3D"Tahoma">*****Confidentiality Notice*****</FONT></P>

<P><FONT COLOR=3D"#000000" SIZE=3D1 FACE=3D"Tahoma">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.</FONT></P>
<BR>
<BR>
<BR>
<BR>
</UL>
</BODY>
</HTML>
------_=_NextPart_001_01C7123B.D98FB80D--