Subject: Re: [Disman] [Errata Rejected] RFC3877 (1652)

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 11 May 2010 15:01:03 +0200

Brian,

(the distribution list slightly changes)

I think that we understand this. What you proposed is a change in the
mapping, which would not be backwards compatible with the current
deployment. What is suggested is that the text is changed to mention the
differences between the order in the two models - this text would
include your observation about the order of severity not being the same
as the one defined in the ITU-T document. 

Regards,

Dan

> -----Original Message-----
> From: Brian F. G. Bidulock [mailto:[email-masked]] 
> Sent: Tuesday, May 11, 2010 3:51 PM
> To: RFC Errata System
> Cc: [email-masked]; Romascanu, Dan (Dan); [email-masked]
> Subject: Re: [Errata Rejected] RFC3877 (1652)
> 
> Let me try one more time; read my lips:
> 
> It is not the enumerated value that need to change.
> 
> The document states that the alarm states are ordered from 
> least severe to most severe, but (without the correction) 
> they are not.
> 
> --brian
> 
> On Tue, 11 May 2010, RFC Errata System wrote:
> 
> > 
> > The following errata report has been rejected for RFC3877, "Alarm 
> > Management Information Base (MIB)".
> > 
> > --------------------------------------
> > You may review the report below and at:
> > http://www.rfc-editor.org/errata_search.php?rfc=3877&eid=1652
> > 
> > --------------------------------------
> > Status: Rejected
> > Type: Technical
> > 
> > Reported by: Brian Bidulock <[email-masked]> Date Reported: 
> > 2009-01-13 Rejected by: Dan Romascanu (IESG)
> > 
> > Section: 5.4
> > 
> > Original Text
> > -------------
> > alarmModelState -> ituAlarmPerceivedSeverity
> >        1        ->         clear (1)
> >        2        ->         indeterminate (2)
> >        3        ->         warning (6)
> >        4        ->         minor (5)
> >        5        ->         major (4)
> >        6        ->         critical (3)
> > 
> > Corrected Text
> > --------------
> > alarmModelState -> ituAlarmPerceivedSeverity
> >        1        ->         clear (1)
> >        2        ->         warning (6)
> >        3        ->         indeterminate (2)
> >        4        ->         minor (5)
> >        5        ->         major (4)
> >        6        ->         critical (3)
> > 
> > Notes
> > -----
> > alarmModelState requires that the states be defined from 
> less severe to more severe; however, under ITU-T 
> PerceivedSeverity from ITU-T Rec. X.721 | ISO/IEC 10165-2 
> "indeterminate" is more severe than "warning".  This change 
> corrects the order to match the requirement for order of 
> severity for alarmModelState.
> >  --VERIFIER NOTES--
> > While the discrepancy between the documents is unfortunate, 
> there is not a technical requirement for the enumeration 
> values to be identical, nor is there a technical requirement 
> for the labels to be identical, even though there is 
> obviously considerable documentation value in avoiding 
> gratuitous differences.
> > 
> > What *is* technically important is that the MIB be able to 
> uniquely represent all the cases from M.3100, and it 
> accomplishes that goal.
> > 
> > In a future version of the document we can add an 
> informative note alerting implementors to the discrepancies 
> in numbering and spelling, so their implementations can 
> include appropriate mapping functions to avoid losing information.
> >    
> > 
> > --------------------------------------
> > RFC3877 (draft-ietf-disman-alarm-mib-18)
> > --------------------------------------
> > Title               : Alarm Management Information Base (MIB)
> > Publication Date    : September 2004
> > Author(s)           : S. Chisholm, D. Romascanu
> > Category            : PROPOSED STANDARD
> > Source              : Distributed Management
> > Area                : Operations and Management
> > Stream              : IETF
> > Verifying Party     : IESG
> 
> -- 
> Brian F. G. Bidulock    | The reasonable man adapts himself to the |
> [email-masked]    | world; the unreasonable one persists in  |
> http://www.openss7.org/ | trying  to adapt the  world  to himself. |
>                         | Therefore  all  progress  depends on the |
>                         | unreasonable man. -- George Bernard Shaw |
>

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 11 May 2010 08:54:26 -0600

Romascanu,,

Perhaps the errata should add a statement then, that
the order is, and will remain, in error.

--brian

-- 
Brian F. G. Bidulock    ¦ The reasonable man adapts himself to the ¦
[email-masked]    ¦ world; the unreasonable one persists in  ¦
http://www.openss7.org/ ¦ trying  to adapt the  world  to himself. ¦
                        ¦ Therefore  all  progress  depends on the ¦
                        ¦ unreasonable man. -- George Bernard Shaw ¦

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 11 May 2010 10:40:33 -0700

Hi -

The "verifier notes" look strangely familiar to me.  My recollection
is that they were written in response to a DIFFERENT erratum,
namely number 1819, NOT number 1652, and thus do not address
Brian's comment.  Did the "verifier notes" for *this* erratum get lost
somewhere along the way?

Randy

----- Original Message ----- 
From: "Romascanu, Dan (Dan)" <[email-masked]>
To: <[email-masked]>
Cc: "Disman" <[email-masked]>; <[email-masked]>
Sent: Tuesday, May 11, 2010 6:01 AM
Subject: Re: [Disman] [Errata Rejected] RFC3877 (1652)

Brian,

Regards,

Dan

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Tue, 11 May 2010 17:44:01 -0600

Randy,

Actually, the severity levels from M.3100 are completely different.
This MIB models the ITU-T Rec. X.721 ISO/EIC 10165-2 severities (OSI
severities, not telco severities).

Nevertheless, if one follows the alarm states in the document, a
more severe alarm (indeterminate(2)) will be masked by a less
severe alarm (warning(6)), making it largely unusable for the
purpose for which it was intended.

I submitted this errata over a year ago.  In the meantime I have
found this MIB so lacking that I implemented alarms management
completely in private MIBs.

So, do what you want with it: it is useless to me.

--brian

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 11 May 2010 22:38:48 -0700

Hi -

> From: "Brian F. G. Bidulock" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>
> Cc: "Romascanu, Dan (Dan)" <[email-masked]>; "Disman" <[email-masked]>; <[email-masked]>
> Sent: Tuesday, May 11, 2010 4:44 PM

They're the same thing.  M.3100 IMPORTS PerceivedSeverity from X.721  
The tables in M.3100 for handling PerceivedSeverity appear to
be consistent with X.721 and X.733  (Which is not surprising,
since some of the same people were involved in writing all three.)

> purpose for which it was intended.

X.721 specifically comments (page 41) that "indeterminate" is
only used when it is not possible to assign one of the other values.
The semantics nailed down in X.733, in clause 8.1.2.3, only
specify the relative severity of the other values, not for "indeterminate".
Likewise, 8.1.2.6, "Trend Indication", also does not include
"indeterminate" in the ordering.  Consequently, I do not see how
either the current ordering, nor the proposed change, could be
supported by citing M.3100 or X.733.

> So, do what you want with it: it is useless to me.
...

I'm not arguing your point.  I'm just saying that the "verifier notes"
that accompanied the rejection appear to belong to a DIFFERENT
erratum, and did not address the point of your comments.  I'm
AGREEING with you that there is (at least) a documentation problem,
in that the mapping does not fit X.721 /  X.733.  M.3100 merely imports
the definition from X.721, and does NOT, as far as I can see, do anything
to "indeterminate" to justify the proposed change in order.  However, it
also makes it clear that the existing order, while perhaps sensible for
some application, is not justified by the base standards.

Randy

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 12 May 2010 12:11:13 +0200

Brian,

Please use my first name and not the family name. 

Thanks and Regards,

Dan

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Brian F. G. Bidulock
> Sent: Tuesday, May 11, 2010 5:54 PM
> To: Romascanu, Dan (Dan)
> Cc: Disman; [email-masked]
> Perhaps the errata should add a statement then, that the 
> order is, and will remain, in error.
> 
> --brian
> 
> > deployment. What is suggested is that the text is changed 
> to mention 
> > the differences between the order in the two models - this 
> text would 
> > include your observation about the order of severity not being the 
> > same as the one defined in the ITU-T document.
> > 
> > Regards,
> > 
> > Dan
> > 
> > 
> > > The document states that the alarm states are ordered from least 
> > > severe to most severe, but (without the correction) they are not.
> > > 
> > > --brian
> > > 
> PerceivedSeverity 
> > > from ITU-T Rec. X.721 | ISO/IEC 10165-2 "indeterminate" is more 
> > > severe than "warning".  This change corrects the order to 
> match the 
> > > requirement for order of severity for alarmModelState.
> > > >  --VERIFIER NOTES--
> values to 
> > > be identical, nor is there a technical requirement for 
> the labels to 
> > > be identical, even though there is obviously considerable 
> > > documentation value in avoiding gratuitous differences.
> > > > 
> > > uniquely represent all the cases from M.3100, and it accomplishes 
> > > that goal.
> > > > 
> > > informative note alerting implementors to the discrepancies in 
> > > numbering and spelling, so their implementations can include 
> > > appropriate mapping functions to avoid losing information.
> > > >    
> > > >

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 12 May 2010 12:24:27 +0200

Indeed - the confusion is mine and I apologize. 

Did the WG reach a recommendation for Errata #1652? I cannot find it in
my archives.

My opinion as a contributor is that we still better reject the errata
but the comment should prompt on the discrepancy between the different
standards, and show that it is not clear from the ITU-T standards the
value 'indeterminate' should be used in ordering relative to the other
levels and in masking. 

Brian, please submit again your errata - so that we can append the
appropriate comment and resolution. 

Thanks and Regards,

Dan

> From: Randy Presuhn [mailto:[email-masked]] 
> Sent: Tuesday, May 11, 2010 8:41 PM
> To: Romascanu, Dan (Dan); [email-masked]
> The "verifier notes" look strangely familiar to me.  My 
> recollection is that they were written in response to a 
> DIFFERENT erratum, namely number 1819, NOT number 1652, and 
> thus do not address Brian's comment.  Did the "verifier 
> notes" for *this* erratum get lost somewhere along the way?
> 
> Randy
>

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 12 May 2010 05:45:30 -0600

Randy,

> since some of the same people were involved in writing all three.)

You still don't get it: I am not talking about enumerations of
perceivedSeverity.  I am talking about the severity levels of
alarmStatus:

This from the M.3100 GDMOs: (alarmStatus ATTRIBUTE DEFINED AS)

    "The Alarm Status attribute type indicates the occurrence of an
     abnormal condition relating to an object. This attribute may also
     function as a summary indicator of alarm conditions associated with
     a specific resource. It is used to indicate the existence of an
     alarm condition, a pending alarm condition such as threshold
     situations, or (when used as a summary indicator) the highest
     severity of active alarm conditions. When used as a summary
     indicator, the order of severity (from highest to lowest) is:

	activeReportable-Critical
	activeReportable-Major
	activeReportable-Minor
	activeReportable-Indeterminate
	activeReportable-Warning
	activePending
	cleared."

And from the M.3100 ASN:

AlarmStatus ::= ENUMERATED {
	cleared(0),
	activeReportable-Indeterminate(1),
	activeReportable-Warning(2),
	activeReportable-Minor(3),
	activeReportable-Major(4),
	activeReportable-Critical(5),
	activePending(6) }

Now, just in the MIB:

    "Entries appear in this table whenever an entry is created
     in the alarmModelTable with a value of alarmModelState in
     the range from 1 to 6.  Entries disappear from this table
     whenever the corresponding entries are deleted from the
     alarmModelTable, including in cases where those entries
     have been deleted due to local system action.  The value of
     alarmModelSpecificPointer has no effect on the creation
     or deletion of entries in this table.  Values of
     alarmModelState map to values of ituAlarmPerceivedSeverity
     as follows:

     All other values of alarmModelState MUST NOT appear
     in this table.

And alarmModelState

        "A value of 1 MUST indicate a clear alarm state.
        The value of this object MUST be less than the
        alarmModelState of more severe alarm states for
        this alarm.  The value of this object MUST be more
        than the alarmModelState of less severe alarm states
        for this alarm."

So, the alarm model state values must be ordered in order of severity,
otherwise, masking occurs.  However, the alarmModelState value
mapping from perceivedSeverity do no match the M.3100 alarmStatus
severity levels.  INDETERMINATE AND WARNING ARE REVERSED.  Therefore
the mapping does not follow the MUST rules for alarmModelState per
M.3100 alarmStatus which is NOT the same as the X.721 alarmStatus.

> supported by citing M.3100 or X.733.

See M.3100 alarmStatus, per above.  Because the alarmModelState
rule (MUST) is violated, and alarm of activeReportable-Warning
will mask more severe alarms of activeReportable-Indeterminate.

> some application, is not justified by the base standards.

Again, read my lips: not perceivedSeverity enumerations, but
M.3100 alarmStatus to alarmModelState mapping.

--brian

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Wed, 12 May 2010 06:01:05 -0600

Randy,

I should have also given you the comment from the M.3100 GDMOS:

-- 7.3.13 alarmStatus
-- The semantics of alarmStatus defined in ITU-T Recommendation M.3100
-- are different from alarmStatus defined in ITU-T Recommendation X.721
-- and ITU-T Recommendation X.731.  This difference in semantics is
-- deliberate and reflects the requirement of Telecom Operators to have
-- an aggregated or consolidated alarm status for alarm management.

--brian

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 12 May 2010 11:23:11 -0700

Hi -

> Sent: Wednesday, May 12, 2010 5:01 AM
...

Two observations:
   (1)  The working group was specifically chartered:
   "The work on the Alarm MIB will take into consideration existing
   standards and practices, such as ITU-T X.733.  Whether any mappings to
   these other standards appear in the Alarm MIB or in separate documents
   will be decided by the WG.  The WG will actively seek participation
   from ITU participants to make ensure that the ITU work is correctly
   understood."   So, I wondered, why does section 3.1 in its definition
   of "Alarm State" (NOT "Status") give M.3100 as an example rather
   than X.733?  Turns out it was in response to my comment requesting
   that *a* reference be given  (October 7, 2003) but there was no
   discussion whether one or the other would have been a better example
   to cite.

  (2) RFC3877 never mentions alarmStatus.  Is your issue that you'd expect the
  ituAlarmTable in RFC 3877 to emulate the behaviour of an ITU (pick your
  standard) alarmStatus?  Sharon, Dan, was that the intent?

Randy

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 13 May 2010 09:14:22 +0200

(speaking as a contributor and co-author of RFC 3877)

Our intention with ituAlarmTable was stated in 4.1.3 

> Optionally, ituAlarmPerceivedSeverity models
   the states in terms of ITU perceived severity. 

and then in 5.1:

> The ituAlarmTable contains information from the ITU Alarm Model about
   possible alarms in the system.

My recollection is that we did not seek exact emulation, but a mapping
that makes sense for the severity levels. We looked at the ITU-T
standards because we did not want to reinvent the wheel. I personally
was not aware about the differences between M.3100 and X.733 on this
respect, but frankly I was relying on Sharon who was at that time
directly involved in the ITU-T work. 

Dan

> Sent: Wednesday, May 12, 2010 9:23 PM
> To: [email-masked]
> Cc: Romascanu, Dan (Dan); Disman; [email-masked]
> > Cc: "Romascanu, Dan (Dan)" <[email-masked]>; "Disman" 
> > <[email-masked]>; <[email-masked]>