Distributed Management (disman)

Romascanu, Dan (Dan | 11 May 2010 15:01

Re: [Errata Rejected] RFC3877 (1652)

 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:bidulock <at> openss7.org] 
> Sent: Tuesday, May 11, 2010 3:51 PM
> To: RFC Errata System
> Cc: schishol <at> nortelnetworks.com; Romascanu, Dan (Dan); iesg <at> iesg.org
> 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.
>

(Continue reading)

Brian F. G. Bidulock | 11 May 2010 16:54

Re: [Errata Rejected] RFC3877 (1652)

Romascanu,,

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

--brian

On Tue, 11 May 2010, Romascanu, Dan (Dan) wrote:

>  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:bidulock <at> openss7.org] 
> > Sent: Tuesday, May 11, 2010 3:51 PM
> > To: RFC Errata System
> > Cc: schishol <at> nortelnetworks.com; Romascanu, Dan (Dan); iesg <at> iesg.org

(Continue reading)

Romascanu, Dan (Dan | 12 May 2010 12:11

Re: [Errata Rejected] RFC3877 (1652)

Brian,

Please use my first name and not the family name. 

Thanks and Regards,

Dan

> -----Original Message-----
> From: disman-bounces <at> ietf.org 
> [mailto:disman-bounces <at> ietf.org] On Behalf Of Brian F. G. Bidulock
> Sent: Tuesday, May 11, 2010 5:54 PM
> To: Romascanu, Dan (Dan)
> Cc: Disman; schishol <at> nortelnetworks.com
> Subject: Re: [Disman] [Errata Rejected] RFC3877 (1652)
> 
> Romascanu,,
> 
> Perhaps the errata should add a statement then, that the 
> order is, and will remain, in error.
> 
> --brian
> 
> On Tue, 11 May 2010, Romascanu, Dan (Dan) wrote:
> 
> >  Brian,
> > 
> > (the distribution list slightly changes)
> > 
> > I think that we understand this. What you proposed is a

(Continue reading)

Randy Presuhn | 11 May 2010 19:40

Picon

Re: [Errata Rejected] RFC3877 (1652)

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)" <dromasca <at> avaya.com>
To: <bidulock <at> openss7.org>
Cc: "Disman" <disman <at> ietf.org>; <schishol <at> nortelnetworks.com>
Sent: Tuesday, May 11, 2010 6:01 AM
Subject: Re: [Disman] [Errata Rejected] RFC3877 (1652)

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,

(Continue reading)

Brian F. G. Bidulock | 12 May 2010 01:44

Re: [Errata Rejected] RFC3877 (1652)

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

On Tue, 11 May 2010, Randy Presuhn wrote:

> 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

(Continue reading)

Randy Presuhn | 12 May 2010 07:38

Picon

Re: [Errata Rejected] RFC3877 (1652)

Hi -

> From: "Brian F. G. Bidulock" <bidulock <at> openss7.org>
> To: "Randy Presuhn" <randy_presuhn <at> mindspring.com>
> Cc: "Romascanu, Dan (Dan)" <dromasca <at> avaya.com>; "Disman" <disman <at> ietf.org>; <schishol <at> nortelnetworks.com>
> Sent: Tuesday, May 11, 2010 4:44 PM
> Subject: Re: [Disman] [Errata Rejected] RFC3877 (1652)
>
> 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).

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.)

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

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

(Continue reading)

Brian F. G. Bidulock | 12 May 2010 13:45

Re: [Errata Rejected] RFC3877 (1652)

Randy,

On Tue, 11 May 2010, Randy Presuhn wrote:

> Hi -
> 
> > From: "Brian F. G. Bidulock" <bidulock <at> openss7.org>
> > To: "Randy Presuhn" <randy_presuhn <at> mindspring.com>
> > Cc: "Romascanu, Dan (Dan)" <dromasca <at> avaya.com>; "Disman" <disman <at> ietf.org>; <schishol <at> nortelnetworks.com>
> > Sent: Tuesday, May 11, 2010 4:44 PM
> > Subject: Re: [Disman] [Errata Rejected] RFC3877 (1652)
> >
> > 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).
> 
> 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.)

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

(Continue reading)

Brian F. G. Bidulock | 12 May 2010 14:01

Re: [Errata Rejected] RFC3877 (1652)

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

On Wed, 12 May 2010, Brian F. G. Bidulock wrote:

> Randy,
> 
> On Tue, 11 May 2010, Randy Presuhn wrote:
> 
> > Hi -
> > 
> > > From: "Brian F. G. Bidulock" <bidulock <at> openss7.org>
> > > To: "Randy Presuhn" <randy_presuhn <at> mindspring.com>
> > > Cc: "Romascanu, Dan (Dan)" <dromasca <at> avaya.com>; "Disman" <disman <at> ietf.org>; <schishol <at> nortelnetworks.com>
> > > Sent: Tuesday, May 11, 2010 4:44 PM
> > > Subject: Re: [Disman] [Errata Rejected] RFC3877 (1652)
> > >
> > > Randy,
> > > 
> > > Actually, the severity levels from M.3100 are completely different.

(Continue reading)

Randy Presuhn | 12 May 2010 20:23

Picon

Re: [Errata Rejected] RFC3877 (1652)

Hi -

> From: "Brian F. G. Bidulock" <bidulock <at> openss7.org>
> To: "Randy Presuhn" <randy_presuhn <at> mindspring.com>
> Cc: "Romascanu, Dan (Dan)" <dromasca <at> avaya.com>; "Disman" <disman <at> ietf.org>; <schishol <at> nortelnetworks.com>
> Sent: Wednesday, May 12, 2010 5:01 AM
> Subject: Re: [Disman] [Errata Rejected] RFC3877 (1652)
>
> 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.
...

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

(Continue reading)

Romascanu, Dan (Dan | 13 May 2010 09:14

Re: [Errata Rejected] RFC3877 (1652)

(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

> -----Original Message-----
> From: Randy Presuhn [mailto:randy_presuhn <at> mindspring.com] 
> Sent: Wednesday, May 12, 2010 9:23 PM
> To: bidulock <at> openss7.org
> Cc: Romascanu, Dan (Dan); Disman; schishol <at> nortelnetworks.com
> Subject: Re: [Disman] [Errata Rejected] RFC3877 (1652)
> 
> Hi -
>

(Continue reading)

Romascanu, Dan (Dan | 12 May 2010 12:24

Re: [Errata Rejected] RFC3877 (1652)

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

> -----Original Message-----
> From: Randy Presuhn [mailto:randy_presuhn <at> mindspring.com] 
> Sent: Tuesday, May 11, 2010 8:41 PM
> To: Romascanu, Dan (Dan); bidulock <at> openss7.org
> Cc: Disman; schishol <at> nortelnetworks.com
> Subject: Re: [Disman] [Errata Rejected] RFC3877 (1652)
> 
> 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

(Continue reading)

Return

Return to gmane.ietf.disman.

Advertisement

Search Archive

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane