Subject: RE: [Disman] Re: alarm MIB question...

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Tue, 14 Oct 2003 20:47:11 +0200

> You're quite right, and we went through the same discussion during the
> IESG review of the Log MIB.  Consequently, I agree that a note to the
> effect of "we know and here's why" would save us some grief.  I
> suggest the following words be added to the end of the DESCRIPTION
> text for alarmActiveVariableOpaqueVal:
> 
> Note: although the SMI [RFC2578] forbids the use of Opaque in

I'd use (RFC 2578) to avoid a citation in the MIB module itself.
Once the MIB gets extracted it points to nowhere.

Bert
> 'standard' MIB modules, this particular usage is driven by the
> need to be able to accurately represent any well-formed notification,
> and justified by the need for backward compatibility.
> 
> Randy
> 
> 
>

---

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Tue, 14 Oct 2003 20:47:11 +0200

Bert

---

From: "Sharon Chisholm" <[email-masked]>
Date: Sat, 18 Oct 2003 19:36:24 -0400

Hi

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

In the description of alarmActiveVariableOpaqueVal replace

          "The value when alarmActiveVariableType is 'opaque'."

With

          "The value when alarmActiveVariableType is 'opaque'.

          Note that although RFC2578 [RFC2578] forbids the use 
          of Opaque in 'standard' MIB modules, this particular 
          usage is driven by the need to be able to accurately 
          represent any well-formed notification, and justified 
          by the need for backward compatibility."

Sharon

-----Original Message-----
From: Randy Presuhn [mailto:[email-masked]] 
Sent: Tuesday, October 14, 2003 12:22 PM
To: Disman (E-mail)
Cc: [email-masked]
Subject: [Disman] Re: alarm MIB question...

Hi -

> From: "David Partain (LM/EAB)" <[email-masked]>
> To: <[email-masked]>; <[email-masked]>
> Cc: <[email-masked]>
> Sent: Tuesday, October 14, 2003 4:10 AM
> Subject: alarm MIB question...
>

> Hi,
>
> Can you remind me of the reasoning behind including 
> alarmActiveVariableOpaqueVal with a syntax of Opaque? Its inclusion 
> violates RFC 2578: on page 24, section 7.1.9, it states: "The Opaque 
> type is provided solely for backward-compatibility, and shall not be 
> used for newly-defined object types."  Seems pretty clear to me.  
> Perhaps you're doing so in the name of backward-compatibility? Or are 
> you just choosing to ignore this for the possibility there are 
> enterprise MIBs that use Opaque for varbinds they sends in a 
> notification?
>
> I think the document should clearly state that it violates the 
> Standard but "we know and here's why".
>
> Cheers,
>
> David
>
> -- 
> Wireless Access Networks       E-mail:  [email-masked]
> Ericsson Research              Tel:  +46 13 28 41 44
> P.O. Box 1248                  Fax:  +46 13 28 75 67
> SE-581 12 Linköping, Sweden    http://linlab.ericsson.se/ietf

You're quite right, and we went through the same discussion during the IESG
review of the Log MIB.  Consequently, I agree that a note to the effect of
"we know and here's why" would save us some grief.  I suggest the following
words be added to the end of the DESCRIPTION text for
alarmActiveVariableOpaqueVal:

Note: although the SMI [RFC2578] forbids the use of Opaque in 'standard' MIB
modules, this particular usage is driven by the need to be able to
accurately represent any well-formed notification, and justified by the need
for backward compatibility.

Randy

---

From: "Sharon Chisholm" <[email-masked]>
Date: Sat, 18 Oct 2003 19:36:24 -0400

Hi

With

Sharon

-----Original Message-----
From: Randy Presuhn [mailto:[email-masked]] 
Sent: Tuesday, October 14, 2003 12:22 PM
To: Disman (E-mail)
Cc: [email-masked]
Subject: [Disman] Re: alarm MIB question...

Hi -

Randy