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

["Chapman, Ken" <KChapman@unispherenetworks.com>]

John,
Thanks for the clarification.  If you intended it to be readable, then
I would assume that you and perhaps others have implemented it that way.
Therefore, it is reasonable not to make a change to MAX_ACCESS.
I support your suggestion to make the change to the MODULE-COMPLIANCE
statement to define the MIN-ACCESS.
I would also suggest adding a line to each object's DESCRIPTION to state
that when the object is read, it will return the value of the most recent
notification AND specify a "default" value (or error) to return if no prior
notification has been sent.  
This would satisfy my concern for "interoperability".
	Ken


> -----Original Message-----
> From: John Flick [mailto:johnf@rose.hp.com]
> Sent: Monday, October 23, 2000 5:45 PM
> To: Chapman, Ken
> Cc: mibs@ops.ietf.org; ospf@discuss.microsoft.com
> Subject: Re: More on draft-ietf-ospf-mib-update-04
> 
> 
> 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
> > ++++++++++++++++++++++++++++++++++++++++++++++
>