Re: More on draft-ietf-ospf-mib-update-04

[John Flick <johnf@rose.hp.com>]

Ken,

I implemented these as read-only objects that return the values sent
in the most recent notification.  I agree that they make more sense as
accessible-for-notify, but I don't think that the SMI has any
provision for changing the MAX-ACCESS of an existing object.  RFC 2578
Section 10.2 is pretty explicit about listing what is allowed to change
when revising an object definition, and the MAX-ACCESS clause is not
listed.

Defining these objects as MIN-ACCESS accessible-for-notify in the
MODULE-COMPLIANCE may make sense though.

John

"Chapman, Ken" wrote:
> 
> Folks,
> I have one more issue with the OSPF-MIB.
> I think it is appropriate to change MAX-ACCESS for ospfConfigErrorType,
> ospfPacketType and ospfPacketSrc from "read-only" to
> "accessible-for-notify".
> The reason I think it is justified is that when RFC1850 was published, it
> was based on SMIv2 as defined by RFC1442 which did not have
> "accessible-for-notify" as an option (wasn't introduced until RFC1902).
> Therefore, this is only a "refinement", since I don't believe that any of
> these attributes should/can be implemented to be accessed via a
> Get/GetNext/GetBulk request.  If these are not changed then most/all
> implementations will need to put something like the following in their
> AGENT-CAPABILITIES statements:
> 
>     SUPPORTS        OSPF-TRAP-MIB
>         INCLUDES  { ospfTrapControlGroup,
>                     ospfTraps } -- group tbd
>         VARIATION   ospfConfigErrorType
>             SYNTAX      accessible-for-notify
>             DESCRIPTION
>                 "Only provided within a notification."
>         VARIATION   ospfPacketType
>             SYNTAX      accessible-for-notify
>             DESCRIPTION
>                 "Only provided within a notification."
>         VARIATION   ospfPacketSrc
>             SYNTAX      accessible-for-notify
>             DESCRIPTION
>                 "Only provided within a notification."
> 
> Is this an acceptable change, since I don't think it will result in any
> interoperability problems?
> 
>         Ken
> 
> ++++++++++++++++++++++++++++++++++++++++++++++
> Ken Chapman           Unisphere Networks, Inc.
> Tel: +1-978-614-5322  5 Carlisle Drive
> Fax: +1-978-692-9992  Westford, MA 01886
> Email: KChapman@UnisphereNetworks.com
> ++++++++++++++++++++++++++++++++++++++++++++++