Re: Multicast in draft version 5 comments

[Keith McCloghrie <[e-mail]>]

> From: Fred Baker <[e-mail]>
> Date: Tue, 2 Jan 1996 16:30:40 -0800
> 
> At 6:05 PM 1/2/96, James Watt wrote:
> >|Those more MIB-literate than I am will have to help me decide whether it is
> >|legal or not to change a read-only to a read-write.
> 
> This is one of those things that gets lost in lore. As the SNMP MIB was
> originally developed, almost everything was read-only, under the assumption
> the MIB specified the minimum, and that a system that wanted to write stuff
> would do more than the minimum. Obvious examples are in the ipRouteTable,
> which is entirely read-only, but folks routinely install (write - or even
> worse, create) static routes.
> 
> That was by no means a universal position, though, and the other extreme
> was that the MIB specified the maximum set of things someone could do; a
> read-write variable might be implemented read-only. The statement was that
> the MIB should specify what makes "protocol sense" and a subsetting
> implementation might use a lower access class. This became the consensus
> over time, and is canonized in SNMP V2's MIN-ACCESS and MAX-ACCESS clauses.
 
Right, and note that SNMPv2's AGENT-CAPABILITIES and MODULE-CONFORMANCE
specify that implicitly referenced objects are implemented/to be
implemented according to the MAX-ACCESS clause.  Thus, modifying an
object's MAX-ACCESS clause would potentially invalidate AGENT-CAPABILITIES
and MODULE-CONFORMANCE macros referencing a group containing that object.
That's why 1442 disallows a change to the MAX-ACCESS value.

> We can make it read-write without deprecating and adding. As Alan points
> out, the change in values is also a change in the internet draft, not a
> change to RFC 1315, so there is nothing in 1315 to obsolete; yes, there are
> implementations to the draft, but we already did them in when we renumbered
> the MIB a couple of months ago.
 
I agree (especially since renumbering the MIB is equivalent to obsoleting and
adding everything in it).

Keith.