Re: Multicast in draft version 5 comments

James Watt <james@ca.newbridge.com> Wed, 03 January 1996 15:46 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12758; 3 Jan 96 10:46 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12754; 3 Jan 96 10:46 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa12084; 3 Jan 96 10:46 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa12722; 3 Jan 96 10:46 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa12716; 3 Jan 96 10:43 EST
Received: from ns.newbridge.com by CNRI.Reston.VA.US id aa10552; 3 Jan 96 10:43 EST
Received: (from adm@localhost) by ns.newbridge.com (8.6.12/8.6.12) id KAA07571; Wed, 3 Jan 1996 10:42:35 -0500
Received: from portero(192.75.23.66) by ns via smap (V1.3) id sma007541; Wed Jan 3 10:42:08 1996
Received: from thor.ca.newbridge.com (thor121.ca.newbridge.com [138.120.121.43]) by kanmaster.ca.newbridge.com (8.6.12/8.6.12) with ESMTP id KAA23408; Wed, 3 Jan 1996 10:42:08 -0500
Received: from fields.newbridge ([138.120.144.160]) by thor.ca.newbridge.com (8.6.12/8.6.12) with SMTP id KAA22621; Wed, 3 Jan 1996 10:42:07 -0500
X-Orig-Sender: iplpdn-request@IETF.CNRI.Reston.VA.US
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: James Watt <james@ca.newbridge.com>
Message-Id: <199601031542.KAA22621@thor.ca.newbridge.com>
Subject: Re: Multicast in draft version 5 comments
To: Keith McCloghrie <kzm@cisco.com>
Date: Wed, 3 Jan 1996 10:42:05 -0500 (EST)
Cc: fred@cisco.com, james@ca.newbridge.com, cbrown@baynetworks.com, alan@xylan.com, iplpdn@CNRI.Reston.VA.US
In-Reply-To: <199601030647.WAA06394@foxhound.cisco.com> from "Keith McCloghrie" at Jan 2, 96 10:47:48 pm
X-Mailer: ELM [version 2.4 PL22]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 1632

Keith McCloghrie writes:
+---------
|> 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.
+---------
Hmmm... Perhaps this should get pointed out in the SMI or co-existence
document, i.e. when converting a MIB from V1->V2 SMI you are allowed
certain latitude in mapping from the ACCESS to the MAX-ACCESS clause...

Or perhaps a one page informational from the NM Directorate ?

Regards,
-james
____________________________________________________________________________
James W. Watt,     james@newbridge.com                   Ph: +1 613 591-3600
Newbridge Networks 600 March Rd Kanata ON Canada K2K 2E6 FAX:+1 613 591-3680