Subject: Re: Updated Alarm MIB Issues

From: Randy Presuhn <[email-masked]>
Date: Mon, 6 May 2002 11:36:18 -0700 (PDT)

Hi -

> Message-ID: <[email-masked]>
> From: "Sharon Chisholm" <[email-masked]>
> To: [email-masked]
> Subject: Updated Alarm MIB Issues
> Date: Sat, 4 May 2002 13:05:55 -0400 
...
> Here's an update on the issues list:
...

I urge you all to review the issues list.

For those items where solutions have been proposed (e.g., #26,
27, 31, 33, 37, 39, 41, 46, 47, 48) if you disagree with the
proposed solution, please speak up now, preferably with an
alternate proposal.

For those items where there are multiple proposed solutions,
(e.g., #36, 38, 40) please indicate your preference or offer
an alternative.

For those items which do not offer a proposed solution, please
offer proposals or a rationale for not addressing the item. (#35,
42, 43, 44, 45)

If you think any significant issues have been omitted from
the list, please speak up now.  We're running late and need
to finish this thing!

 ------------------------------------------------------
 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: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 8 May 2002 13:31:26 +0300

> In terms of your question for #43, I am not sure I clearly 
> understand the impact
> of not having sysUptime and trapOID in the 
> alarmActiveVariableTable.  Could
> these be added via extensability as needed?
> 
Tammy, 

The question is about SNMPv1. V1 traps do not carry this information. I am not sure that I understand what you mean by 'added via extensibility', but trying to emulate these objects in V1 would lead to inconsistency.  There is no way an entity receiving v1 traps can re-build the information similarly to what a v2/v3 Notification would have carried.

Regards,

Dan

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Wed, 8 May 2002 17:04:41 +0300

Looks like we are in violent agreement ;-)

> -----Original Message-----
> From: Dale Francisco [mailto:[email-masked]]
> Sent: Wednesday, May 08, 2002 5:07 PM
> To: Romascanu, Dan (Dan); [email-masked]
> Subject: RE: Updated Alarm MIB Issues
> 
> 
> Dan,
> 
> What I intended to do was comment on the logic
> of the prose--nothing more.  If you were to remove
> the phrase "if available", then logically you should
> remove the following sentence as well, since you would
> be mandating implementations only where the UTC
> offset is available.
> 
> If it's the sense of the WG that implementations are
> allowed even where the UTC offset isn't available, then
> I agree that the paragraph in question should stand exactly
> as written.
> 
> Best regards,
> Dale
> 
> > -----Original Message-----
> > From: Romascanu, Dan (Dan) [mailto:[email-masked]]
> > Sent: Wednesday, May 08, 2002 3:31 AM
> > To: [email-masked]; Randy Presuhn; [email-masked]
> > Subject: RE: Updated Alarm MIB Issues
> > 
> > 
> > I am not sure that I agree with any of you!
> > 
> > Randy, I thought that we agree that we do not mandate the 
> > awareness of the UTC. So the MUST refers to the case when UTC is 
> > available, and is not defeated by anything in the next phrase 
> > which refers at the opposite case.
> > 
> > Francisco, we like using the UTC offset, thus the second phrase. 
> > Life being stronger than our stronger desires, this case is 
> > possible but NOT RECOMMENDED.
> > 
> > Regards,
> > 
> > Dan
> 
>

---

From: Randy Presuhn <[email-masked]>
Date: Thu, 9 May 2002 18:26:29 -0700 (PDT)

Hi -

WG chair says:

Stefan Wallin's posting dated January 2, 2002 led to the
"MUST" language.

Based on our previous discussions of this issue, I believe we
had a rough consensus that, based on operational experience
with systems with these kinds of capabilities, this MIB
only makes sense on systems capable of recording times
unambiguously.

I haven't seen anything to suggest that this is not a valid
position for the WG to take, though of course I'm keen to hear
from those planning to implement or to make use of this MIB.

...