IETF Logo Mail Archive

Re: Last Call: Definitions of Managed Objects for the Fourth Version

Paul Traina <pst@cisco.com> Wed, 06 December 1995 19:25 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16205; 6 Dec 95 14:25 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa16201; 6 Dec 95 14:25 EST
Received: from ietf.cnri.reston.va.us by CNRI.Reston.VA.US id aa14203; 6 Dec 95 14:25 EST
Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16176; 6 Dec 95 14:25 EST
Received: from puli.cisco.com by IETF.CNRI.Reston.VA.US id aa16171; 6 Dec 95 14:25 EST
Received: from localhost.cisco.com (localhost.cisco.com [127.0.0.1]) by puli.cisco.com (8.6.8+c/8.6.5) with SMTP id LAA29883; Wed, 6 Dec 1995 11:25:17 -0800
Message-Id: <199512061925.LAA29883@puli.cisco.com>
To: ietf@CNRI.Reston.VA.US
Cc: "Jeffrey T. Johnson" <jjohnson@cisco.com>, iesg@IETF.CNRI.Reston.VA.US, bgp@ans.net
Subject: Re: Last Call: Definitions of Managed Objects for the Fourth Version
In-Reply-To: Your message of "Wed, 06 Dec 1995 09:54:10 CST." <16734.818265250@dbc.mtview.ca.us>
Date: Wed, 06 Dec 1995 11:25:17 -0800
X-Orig-Sender: iesg-request@IETF.CNRI.Reston.VA.US
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Paul Traina <pst@cisco.com>

  From: Marshall Rose <mrose@dbc.mtview.ca.us>
  Subject: Re: Last Call: Definitions of Managed Objects for the Fourth Version
>> 
  > Given the current state of affairs in that area, it seems like we need to
  > do seems to be to eliminate the SNMPv2 boilerplate and framework entirely
  > and replace the MIB notification section with one that is based upon native
  > SNMPv1 identifiers.  All of this is basicly mechanical translation of text.
  
  alternatively, one could show up at the thursday night plenary to hear a
  discussion of "the current state of affairs" in SNMPv2... (there are, of
  course, other solutions than simply throwing everything out; further,
  bgp is not the only working group with a mib effected...)
  
  /mtr

If progress on the SNMPv2 issue can be made in the time frame necessary
to accomodate standardizing the BGP4 MIB, then taking a step backwards is
foolhardy.  There is no "judgement" call here at all,  if SNMPv2 is moved
forward and accepted before the BGP4 MIB, then the MIB will reference SNMPv2,
otherwise it cannot.  (Simple answer to difficult problem.)

v2.8.7 | Report a Bug | By Email