Re: Multicast in draft version 5 comments

Keith McCloghrie <kzm@cisco.com> Wed, 03 January 1996 06:50 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06266; 3 Jan 96 1:50 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06262; 3 Jan 96 1:50 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa19108; 3 Jan 96 1:50 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa06244; 3 Jan 96 1:50 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa06240; 3 Jan 96 1:47 EST
Received: from foxhound.cisco.com by CNRI.Reston.VA.US id aa17984; 3 Jan 96 1:47 EST
Received: (kzm@localhost) by foxhound.cisco.com (8.6.8+c/8.6.5) id WAA06394; Tue, 2 Jan 1996 22:47:48 -0800
X-Orig-Sender: iplpdn-request@IETF.CNRI.Reston.VA.US
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Keith McCloghrie <kzm@cisco.com>
Message-Id: <199601030647.WAA06394@foxhound.cisco.com>
Subject: Re: Multicast in draft version 5 comments
To: Fred Baker <fred@cisco.com>
Date: Tue, 2 Jan 96 22:47:48 PST
Cc: james@ca.newbridge.com, cbrown@baynetworks.com, alan@xylan.com, iplpdn@CNRI.Reston.VA.US
In-Reply-To: <v0213050bad0f74bb0cb7@[171.69.128.114]>; from "Fred Baker" at Jan 2, 96 4:30 pm
X-Mailer: ELM [version 2.3 PL11]

> From: Fred Baker <fred@cisco.com>
> 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.