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

From: "Sharon Chisholm" <[email-masked]>
Date: Wed, 8 Oct 2003 15:01:18 -0400

Hi

The following is the proposed resolution to Randy-65. Assuming no objection,
this item will is closed with no changes to the draft.

Section 4.1.1 says 

"The relationship between the Alarm MIB and the other alarm model MIB
   modules is expressed by the following: The alarmModelTable has a
   corresponding table in the specific MIB. For each row in the
   specific MIB alarm model table there is one row in the
   alarmModelTable."

Therefore the distinction that Randy is making is a moot point.

Sharon

-----Original Message-----
From: Randy Presuhn [mailto:[email-masked]] 
Sent: Thursday, October 02, 2003 6:32 PM
To: Disman (E-mail)
Subject: [Disman] Section 5.1 in draft-ietf-disman-alarm-mib-15.txt

Hi -

> From: "Sharon Chisholm" <[email-masked]>
> To: "Disman (E-mail)" <[email-masked]>
> Cc: <[email-masked]>; "Randy Presuhn" 
> <[email-masked]>; "Romascanu, Dan (Dan)"
<[email-masked]>
> Sent: Monday, September 29, 2003 7:34 AM
> Subject: [Disman] RE: Comments on draft-ietf-disman-alarm-mib-14.txt
...
> 65) 5.1: "about alarms" -> "about alarms modeled using the ituAlarmTable"
>     "total alarms" -> "total alarms modeled using the ituAlarmTable"
...

Though this item is identified as "changed", it looks like it only got half
done. As it stands, I think this sentence is still incorrect:

   The ituAlarmActiveStatsTable provides statistics on current and
   total alarms.

The number is the total for stuff modeled using the ituAlarmTable, not total
alarms in the system, right?

Randy

---

From: "Sharon Chisholm" <[email-masked]>
Date: Fri, 10 Oct 2003 14:59:18 -0400

Hi

For every A, there is a B. For every B there is an A. Therefore the # of A =
# of B. QED.

The number of itu active alarms is equal to the active alarms for the whole
system, if we define the whole system to be the whole alarm system.

Sharon

-----Original Message-----
From: Randy Presuhn [mailto:[email-masked]] 
Sent: Wednesday, October 08, 2003 3:23 PM
To: Disman (E-mail)
Subject: Re: [Disman] Section 5.1 in draft-ietf-disman-alarm-mib-15.txt

Hi -

> Cc: "Randy Presuhn" <[email-masked]>
> Sent: Wednesday, October 08, 2003 12:01 PM
> Subject: RE: [Disman] Section 5.1 in 
> draft-ietf-disman-alarm-mib-15.txt
>

> Hi
>
> The following is the proposed resolution to Randy-65. Assuming no 
> objection, this item will is closed with no changes to the draft.
>
> Section 4.1.1 says
>
...

I disagree.  The current text effectively says that for each entry in the
alarmModelTable there will be zero or one entries in any given specific MIB
alarm model table, though one might argue whether the limitations of
alarmModelSpecificPointer result in a total limit of
1:(0,1) or 1:(0,n) where n is the number of specific models possible.  So my
question still stands:

Are the numbers in ituAlarmActiveStatsTable for stuff modeled using the
ituAlarmTable, or for the whole system?

Randy

---

From: "Sharon Chisholm" <[email-masked]>
Date: Sat, 18 Oct 2003 18:32:50 -0400

Hi

The following is the proposed resolution to Randy-65  Assuming no objection,
this item will be considered closed conditional on the proposed edit being
done.

In section 4.1.1 replace

"  The relationship between the Alarm MIB and the other alarm model MIB
   modules is expressed by the following: The alarmModelTable has a
   corresponding table in the specific MIB. For each row in the
   specific MIB alarm model table there is one row in the
   alarmModelTable. The alarmActiveTable has a corresponding table in
   the specific MIBs. For each row in the specific MIB active alarm
   table, there is one row in the alarmActiveTable. The
   alarmModelSpecificPointer object in the alarmModelTable points to
   the specific model entry in an extended alarm model table
   corresponding to this particular alarm.  The
   alarmActiveSpecificPointer object in the alarmActiveTable points to
   the specific active alarm entry in an extended active alarm table
   corresponding to this particular alarm instance.

   Additional extensions can be defined by defining an AUGEMENTATION of
   either the Alarm or ITU Alarm tables."

With

"  The relationship between the Alarm MIB and the other alarm model MIB
   modules is expressed by the following: The alarmModelTable has a
   corresponding table in the specific MIB. For each row in the
   specific MIB alarm model table there is one row in the
   alarmModelTable. The alarmActiveTable has a corresponding table in
   the specific MIBs. For each row in the specific MIB active alarm
   table, there is one row in the alarmActiveTable. The
   alarmModelSpecificPointer object in the alarmModelTable points to
   the specific model entry in an extended alarm model table
   corresponding to this particular alarm.  The
   alarmActiveSpecificPointer object in the alarmActiveTable points to
   the specific active alarm entry in an extended active alarm table
   corresponding to this particular alarm instance.

   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.

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

Sharon

-----Original Message-----
From: Randy Presuhn [mailto:[email-masked]] 
Sent: Friday, October 10, 2003 11:51 PM
To: Disman (E-mail)
Subject: Re: [Disman] Section 5.1 in draft-ietf-disman-alarm-mib-15.txt

Hi -

> Sent: Friday, October 10, 2003 11:59 AM

> Hi
>
> For every A, there is a B. For every B there is an A. Therefore the # 
> of A = # of B. QED.
...

Wrong.  The current language says for every B there is an A.  It does NOT
say that for every A there is a B.  Furthermore, if it did, then only ONE
extension MIB could exist in a system, due to the way
alarmModelSpecificPointer works.  If someone defined a DMTF-ALARM-MIB, it
could not under your reasoning exist in a system that also supported the ITU
alarm stuff.

Randy

---

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

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

> 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: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 22 Oct 2003 18:20:18 +0200

> Sent: 22 October, 2003 6:00 PM
> To: Disman (E-mail)
> > From: "Romascanu, Dan (Dan)" <[email-masked]>
> > To: "Randy Presuhn" <[email-masked]>; "Disman 
> (E-mail)" <[email-masked]>
> > Sent: Wednesday, October 22, 2003 1:38 AM
> > 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 quoted text starts with 'In the case of the ITU Alarm MIB' !

Would inserting the adjective 'relevant' between 'each' and 'row' help clarify?

Thanks,

Dan

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 22 Oct 2003 19:20:28 +0200

> Much more reasonable would be:
> 
>            acmeentryA1..n  -------------- genericentryA1..n
>                                           genericentryB1..n 
> --------------- ituentryB1..n
> 

and so it is! actually 

genericentry A1..n > ituEntry A1'...n'
genericentryB1..m > acmeEntryB1'...m'

The generic model is generic. Specific models build upon it. there is no conflict or interlocking. generic model numbers indicate just sorting, with value 1 being the sole entry with a semantic (clear)

Nothing in the text precludes it, but it may be just my poor English!

Regards,

Dan

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 22 Oct 2003 19:20:28 +0200

and so it is! actually 

Regards,

Dan

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 23 Oct 2003 09:34:19 +0200

> That doesn't affect the meaning.
> 
> Not really.  :-(  I think we agree what it's supposed to 
> mean, but the words that
> are there are say the wrong thing. In the interest of keeping 
> changes to the absolute
> minimum, I'd be OK with:
> 
> In the case of the ITU Alarm MIB, for each row in the ITU 
> alarm model table
> there would be a corresponding row in the alarm model table.
> 
> or perhaps
> 
> In the case of the ITU Alarm MIB, for each row in the alarm 
> model table there
> MAY be one row in the ITU alarm model table.

I am fine with any of the two texts that you are proposing. I thing that they say EXACTLY the same thing as the original text with 'relevant' inserted, but English is only my third language. 

> 
> I think we really do agree that the relationship between 
> usable generic and
> extension model entries isn't 1:1, but rather 1:(0,1), and 
> just need to make sure
> that the text is sufficiently clear.

Indeed.

> Randy

Case closed on this one?

Regards,

Dan

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Thu, 23 Oct 2003 09:34:19 +0200

Indeed.

Case closed on this one?

Regards,

Dan