Re: Multicast in draft version 5 comments

Fred Baker <> Wed, 03 January 1996 00:31 UTC

Received: from by IETF.CNRI.Reston.VA.US id aa18373; 2 Jan 96 19:31 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa18369; 2 Jan 96 19:31 EST
Received: from by CNRI.Reston.VA.US id aa16172; 2 Jan 96 19:31 EST
Received: from by IETF.CNRI.Reston.VA.US id aa18358; 2 Jan 96 19:31 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa18354; 2 Jan 96 19:30 EST
Received: from by CNRI.Reston.VA.US id aa15781; 2 Jan 96 19:30 EST
Received: from [] ( []) by (8.6.8+c/8.6.5) with SMTP id QAA28348; Tue, 2 Jan 1996 16:30:37 -0800
Message-Id: <v0213050bad0f74bb0cb7@[]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 2 Jan 1996 16:30:40 -0800
To: James Watt <>, Caralyn Brown <>
X-Orig-Sender: iplpdn-request@IETF.CNRI.Reston.VA.US
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Fred Baker <>
Subject: Re: Multicast in draft version 5 comments
Cc:, iplpdn@CNRI.Reston.VA.US

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.

This MIB was originally set up under the first set of rules; with the
change in consensus, yes, it sounds like [if this is the only change we are
making] this variable can/should be made read-write. I can point to plenty
of instances in MIB-II itself where this change has been made.

If you were removing a capability, we would have to deprecate and add; we
preserve the correctness of the existing implementation. If you are adding
capabilities in an updated version, I would argue that it is not necessary
to deprecate and add to get new capabilities in an updated draft, as the
existing implementation never claimed compliance to the update, and all the
capabilities it claims to offer are in fact defined.

An example: how many times have we added a value to ifType? And what was
the impact of taking MIB-II Row Status objects and giving them the
RowStatus TC?

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.

|> Also since multicast is optional we should allow an
|> implementation to only allow a write of unicast(1) as
|> a value and to allow other values to be optional.

An implementation is always permitted to reply "badValue" to things it
doesn't think make any sense. A unicast-only implementation would accept a
write of unicast, and replay badValue to any other.

Some ideas are so crazy that only an intellectual could believe them...
        George Orwell