Subject: RE: [Disman] Section 5.1 in draft-ietf-disman-alarm-mib-15.txt

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 22 Oct 2003 10:38:31 +0200

> >    In the case of the ITU Alarm MIB, for each row in the
> >    alarm model table there is one row in the ITU alarm model table.
> 
> If a system supports both the ITU alarm MIB and some
> other alarm extension MIB, then for a given entry in the 
> alarmModelTable
> there will be:
>     (a) an entry in the ITU alarm MIB, and no entry in the 
> other extension MIB
>     (b) an entry in both MIBs' tables
> 
> I believe the proposed text preclude the third possibility
>     (c) an entry in the other extension MIB, but not in the 
> ITU alarm MIB.
> 

I do not believe this is the case. The text refers to the ITU Alarm MIB, but does not preclude the third possibility.

> The upshot of this, I believe, is that only extension models 
> corresponding
> to the ITU alarm model could be defined.  I don't think that 
> this was quite what
> we meant to do.
> 

See below - Alarm Table can be AUGMETED!

> >    Additional extensions can be defined by defining an 
> AUGEMENTATION of
> >    either the Alarm or ITU Alarm tables. As the alarm model 
> table only
> >    provides a mechanism to point at one specific alarm model,
> >    additional specific models SHOULD define another mechanism to map
> >    from the generic alarm model to the additional model."
> ...
> 
> I think that the the semantics of augmenting the Alarm table 
> would be different
> from the semantics of augmenting the ITU alarm table, and 
> that we shouldn't
> confuse the two cases.

I fail to see where is the confusion.

> Randy

Regards,

Dan

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 22 Oct 2003 09:00:25 -0700

Hi -

> From: "Romascanu, Dan (Dan)" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>; "Disman (E-mail)" <[email-masked]>
> Sent: Wednesday, October 22, 2003 1:38 AM
> Subject: RE: [Disman] Section 5.1 in draft-ietf-disman-alarm-mib-15.txt
>
...
> I do not believe this is the case. The text refers to the ITU Alarm MIB, but does not preclude the third possibility.

???  Sharon's proposed text says that for each row in the alarm model table there
will be one row in the ITU alarm model table.  (See quote above.)  This cannot
be true if it is possible for there to be an entry without a corresponding entry
in the ITU alarm MIB.

> > The upshot of this, I believe, is that only extension models  corresponding
> > this was quite what we meant to do.
>

The point is that if the proposed text is true when it says that an ITU alarm model entry
must exist for each generic alarm model entry, then all alarm models will by definition
map to ITU models.

> > >    Additional extensions can be defined by defining an  AUGEMENTATION of
> > >    either the Alarm or ITU Alarm tables. As the alarm model  table only
...

The proposed text treats augmentations of the Alarm and ITU alarm tables as
equivalent.  This is true if all models are required to map to the ITU model if
a system implements it.  If one doesn't require 1:1 relationship between ITU and
generic alarm model entries, i.e., one permits definition of alarm models that
do not map to ITU alarm models in a system that supports ITU models, then
there is a *big* difference between augmenting the generic tables and
augmenting the ITU tables.

Example:
take a system that supports 3 models: generic, ITU, and AcmeCorp.
the system needs to support two kinds of alarms: an ITU-defined one,
and an AcmeCorp one.
The current proposal requires that we have model table entries like this:

           acmeentryA1..n  -------------- genericentryA1..n --------------- ituentryA1..n
           acmeentryB1..n --------------- genericentryB1..n --------------- ituentryB1..n

           or perhaps

           acmeentryA1..n  -------------- genericentryA1..n --------------- ituentryA1..n
                                          genericentryB1..n --------------- ituentryB1..n

If the AcmeCorp model doesn't map well to ITU model, both of these seem undesirable.
Much more reasonable would be:

           acmeentryA1..n  -------------- genericentryA1..n
                                          genericentryB1..n --------------- ituentryB1..n

which is precluded by the text saying that there must be an ituentry for every generic entry.

Randy

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 22 Oct 2003 09:00:25 -0700

Hi -

...

...

Example:

           or perhaps

Randy