Subject: RE: Alarm MIB WG last call

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 3 Apr 2002 18:10:30 +0300

I find this argument in-sufficient. It includes a reference to a non-chartered work (AFAIK) and a conditional ('could result in the I-D being broken').  RFC 3014 is a standards track document at PS. Answering in same conditional mode, IF a replacement work will be chartered, and IF this will indeed replace RFC 3014, the next versions of the Alarm MIB COULD refer this replacement. Until then my opinion is that the references in the I-D are valid.

Regards,

Dan

> -----Original Message-----
> From: David T. Perkins [mailto:[email-masked]]
> Sent: Wednesday, April 03, 2002 4:57 AM
> To: Randy Presuhn; [email-masked]
> Subject: Re: Alarm MIB WG last call
> 
> 
> HI,
> 
> The I-D still depends of RFC 3014. Steve Mouton and I plus RamK and
> implementor at cisco and implementor at Riverstone are looking into
> RFC 3014 and have found problems. Steve Mouton and I are working on
> a replacement MIB module to 3014. This replacement MIB module could
> result in the I-D being broken in its usage of RFC 3014. Note the
> reference in the I-D to RFC 3014 is not simply as an example.
> Hint: see the definition of object alarmListName.
> 
> So, until the I-D is purged of references to RFC 3014, I find it
> inappropriate for it to be forwarded by the WG to the IESG for
> consideration as publication as an RFC.
> 
> Regards,
> /david t. perkins
> 
> At 05:35 PM 4/2/2002 -0800, Randy Presuhn wrote:
> >Hi -
> >
> >Private email has made it clear that some folks didn't read the
> >attached message.  Make no mistake:  disman WG last call on the
> >alarm MIB began March 28 when the draft appeared.  The WG last
> >call will end 5 p.m. Pacific Daylight Time on April 11, 2002.
> >
> > ------------------------------------------------------
> > Randy Presuhn          BMC Software, Inc.  1-3141
> > [email-masked]  2141 North First Street
> > Tel: +1 408 546-1006   San José, California 95131  USA
> > ------------------------------------------------------
> > My opinions and BMC's are independent variables.
> > ------------------------------------------------------
> >
> >> From [email-masked] Mon Mar 18 13:08:39 PST 2002
> >> Date: Mon, 18 Mar 2002 13:08:17 -0800 (PST)
> >> From: Randy Presuhn <rpresuhn>
> >> Message-Id: <[email-masked]>
> >> To: [email-masked]
> >> Subject: Alarm MIB WG last call
> >> List-Id: IETF disman Working Group mailing list 
> <disman.dorothy.bmc.com>
> >> 
> >> Hi -
> >> 
> >> We finished a first WG last call on the alarm MIB, and,
> >> *surprise* found that some revisions were needed.  I've talked
> >> to some of the folks active in the discussion, and as disman
> >> WG chair have decided that, when the revision appears, another
> >> two-week WG last call on the document would be appropriate.
> >> This last call will begin when the revised I-D becomes available.
> >> 
> >> As with the previous last call, I would appreciate a (personal)
> >> note from those who have read the document but not felt the
> >> need to comment on the WG mailing list, so that I might better
> >> assess how much review it has actually received.
> >> 
> >>  ------------------------------------------------------
> >>  Randy Presuhn          BMC Software, Inc.  1-3141
> >>  [email-masked]  2141 North First Street
> >>  Tel: +1 408 546-1006   San José, California 95131  USA
> >>  ------------------------------------------------------
> >>  My opinions and BMC's are independent variables.
> >>  ------------------------------------------------------
> >> 
> 
>

---

From: Randy Presuhn <[email-masked]>
Date: Thu, 11 Apr 2002 14:24:35 -0700 (PDT)

Hi -

> Date: Tue, 2 Apr 2002 17:35:14 -0800 (PST)
> Message-Id: <[email-masked]>
...
> call will end 5 p.m. Pacific Daylight Time on April 11, 2002.
...

I'm glad to see we've gotten some substantive comments.
We will need to discuss those comments (and any others that
might appear) on the mailing list, and revise the draft
accordingly.  Before issue another WG last call.  Please,
let's make this the last iteration!

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 14 Apr 2002 18:48:03 +0300

Tammy,
 
I agree with the proposed change in the DESCRIPTION clause, which is consistent with the definition of an alarm.
 
Wrt. the SYNTAX, this was debated in SLC (if I remember well), and the decision was to go with DateAndTime.
 
Thanks,
 
Dan

-----Original Message-----
From: Tammy Ferris [mailto:[email-masked]]
Sent: Saturday, April 13, 2002 12:00 AM
Cc: [email-masked]
Subject: Re: Alarm MIB WG last call

All, 
Found another item.  For clarity, I think the following definition: 
   alarmActiveDateAndTime OBJECT-TYPE 
      SYNTAX      DateAndTime 
      MAX-ACCESS  not-accessible 
      STATUS      current 
      DESCRIPTION 
          "The local date and time when the alarm occurred. 

          Implementations MUST include the offset from UTC, 
          if available.  Implementation in environments in which 
          the UTC offset is not available is NOT RECOMMENDED." 
      ::= { alarmActiveEntry 2 } 

Should be modified to: 
   alarmActiveDateAndTime OBJECT-TYPE 
      SYNTAX      DateAndTime 
      MAX-ACCESS  not-accessible 
      STATUS      current 
      DESCRIPTION 
          "The local date and time when the error occurred. 

          Implementations MUST include the offset from UTC, 
          if available.  Implementation in environments in which 
          the UTC offset is not available is NOT RECOMMENDED." 
      ::= { alarmActiveEntry 2 } 

Of course, I would not object to two time stamps.  One for the time the error occurred and another for the time an alarm was reported. 
Cheers, 
Tammy 

Tammy Lehtinen Ferris 
[email-masked] 
+1 (763)577-5946 
Merkita Incorporated 
www.merkita.com 

> > List-Id: IETF disman Working Group mailing list <disman.dorothy.bmc.com> 
> > 
> > Hi - 
> >

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 21 Apr 2002 08:32:29 +0300

I also think that 1) is the better way. In the case that you describe it is the subagent that might have a better (or the only) clue about when the condition occurred. On the other hand, reporting time capability seems to be a characteristic of the main agent, similarly as in the case of a monolithic agent that polls some HW registers.

Regards,

Dan

> From: Randy Presuhn [mailto:[email-masked]]
> Sent: Saturday, April 20, 2002 4:07 AM
> > Message-ID: <[email-masked]>
> > Date: Thu, 18 Apr 2002 18:36:36 -0500
> > From: Tammy Ferris <[email-masked]>
> > To: "Romascanu, Dan (Dan)" <[email-masked]>, 
> [email-masked]
> > References: 
> <[email-masked].
> avaya.com>
> ...
> > > I proposed a fix of having 2 timestamps in the active alarm
> > > table rather than one :  One time stamp (the time the alarm
> > > was reported) be the one to use for indexing and a second
> > > time stamp (the time the error occurred).
> ...
> (much discussion / elaboration deleted)
> 
> I'm thinking about this problem from an implementation
> perspective, specifically with an AgentX bias.  Now I
> know that we don't want to *require* the use of agentx,
> but the pervasiveness of subagent technologies requires
> us to at least give some thought to its implications.
> 
> If we would like to have both timestamps in the active
> alarm table, where would the values come from?  If we rely
> on "in-band" information in AgentX, we are left with few
> reasonable choices:
> 
>     1) the subagent could supply a sysUpTime.0 varbind
>        reflecting the time the condition occurred, and
>        the Active Alarm MIB implementation could use its
>        local time to populate the "reported" field.
> 
>     2) the subagent could supply a sysUpTime.0 varbind
>        reflecting the time the condition was reported, and
>        add another variable binding to reflect when the
>        condition occurred.
> 
> Though I personally prefer (1) (and would like to see
> appropriate language in the condition mib), both of these
> alternatives have a really interesting property: the
> information recording when the condition was detected ends
> up in the alarmActiveVariableTable, though perhaps not in
> the most convenient form imaginable.
> 
> Am I missing something here?
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 21 Apr 2002 08:32:29 +0300

> Maybe it would be worth restating the goal of 
> the Alarm MIB.  What do you think is the goal of the Alarm 
> MIB?  

Oh, no, please. Even an IETF work item must be completed at some point. WG Last Call is not the phase where goals are discussed. This work is at draft -06, and is lasting for two years or so. Goals were discussed for another bunch of time even before this. Let us complete the Last Call, fix what needs to be fixed, and deliver. Believe or not, there might be people there expecting for this work to be completed and waiting to use it.

Regards,

Dan

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 23 Apr 2002 14:00:59 +0300

> Dan,
> See my comments below.
> Tammy
> 
> "Romascanu, Dan (Dan)" wrote:
> 
> > OK, I think that I got now your issue. Getting back to your 
> proposal:
> >
> > > > > time stamp (the time the error occured).
> >
> > Two things need to be clarified here:
> >
> > - instead of saying 'the alarm was reported' we need to say 
> 'the alarm was reported or retrieved', in order to 
> accommodate agent implementations that are based on a polling 
> model rather than asynchronous reports from an other subsystem
> > - need to define the behavior of an agent an agent that 
> cannot retrieve accurately the time the error occurred. I am 
> not sure how to do this. We might need to add another 
> variable that describes whether this capability exists in the 
> system, or invent another TC like DateAndTimeOrZero.
> 
> ***
> Does this reply indicate that you prefer two timestamps over 
> some other solution to fix this problem?
> 
> Instead of saying 'the alarm was reported' or 'the alarm was 
> reported or retrieved', how about 'the error information was 
> populated in the alarm table'?  I say this because I think 
> maybe the notion of time retrieved would be confusing in a 
> multi-manager environment.
> 
> For systems that cannot either produce and/or store error 
> occurance timestamps, how about setting the time the error 
> occurred equal to the time the alarm information was added to 
> the alarm table?
> Tammy
> 
> >

I am not convinced that there is a problem, or at least that this problem exists for all implementation models. However I would be ready to accomodate the solution that you are proposing, in  order to avoid blocking thw advancement of this work. 

I would like to hear more opinions. Randy seems to indicate that he does not think that the second object is necessary, though I am not dure that I completely digested his reference to agentx, which also hints to (another) specific way of implementing the distribution.

Regards,

Dan

---

From: Randy Presuhn <[email-masked]>
Date: Tue, 23 Apr 2002 08:20:03 -0700 (PDT)

Hi -

> Message-ID: <[email-masked]>
> Date: Tue, 23 Apr 2002 09:05:01 -0500
> To: Randy Presuhn <[email-masked]>
> References: <[email-masked]>
...
> > Just think about it from an AgentX perspective: the protocol is
> > specifically designed so that subagents will know their sysUpTime,
> > and the text on notifications specifically provides for the
> > communication of the time stamp.  If the subagent omits the
> > sysUpTime variable binding, the elements of procedure specifically
> > provide for the master agent to provide the appropriate one for
> > the context, which would be a perfectly reasonable fallback
> > for an active alarm MIB to use when the "real" time of the
> > failure isn't known.
> 
> ****
> What would be the appropriate one in this case?
> ****
...

If there is nothing in the payload from the subagent,
the AgentX specification requires the use of sysUpTime.0
from the named context.  I don't see why we'd want to
do anything else.

---

From: Randy Presuhn <[email-masked]>
Date: Tue, 23 Apr 2002 08:46:19 -0700 (PDT)

Hi -

> Subject: RE: Alarm MIB WG last call
> Date: Tue, 23 Apr 2002 14:00:59 +0300
> Message-ID: <[email-masked]>
> From: "Romascanu, Dan (Dan)" <[email-masked]>
> To: <[email-masked]>
> Cc: <[email-masked]>
...
> I would like to hear more opinions. Randy seems to indicate
> that he does not think that the second object is necessary,
> though I am not dure that I completely digested his reference
> to agentx, which also hints to (another) specific way of
> implementing the distribution.
...

The subagent protocols I am familiar with provide the ability
for the subagent to include event time information.  However,
this information would be lost if the sysUpTime varbind is
not retained in the varbind table.

Here are the alternatives I see:

    1) the distinction is not interesting.  we can
       omit the variable binding from the varbind table,
       and do not need an object to represent the event
       time.

    2) the distinction is interesting, but is not so
       important as to merit a special object.  we can
       cover this case simply by including the sysUpTime
       variable binding in the varbind table.

    3) the distinction is so interesting that it merits
       an object of its own.

I lean towards (2), but am willing to listen to reason,
particularly since (2) does have problems in the face of
sysUpTime discontinuities.