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

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

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa16443; 6 Dec 95 14:41 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa16439; 6 Dec 95 14:41 EST
Received: from interlock.ans.net by CNRI.Reston.VA.US id aa14477; 6 Dec 95 14:41 EST
Received: by interlock.ans.net id AA09920 (InterLock SMTP Gateway 3.0 for iwg-out@ans.net); Wed, 6 Dec 1995 14:25:26 -0500
Message-Id: <199512061925.AA09920@interlock.ans.net>
Received: by interlock.ans.net (Protected-side Proxy Mail Agent-2); Wed, 6 Dec 1995 14:25:26 -0500
Received: by interlock.ans.net (Protected-side Proxy Mail Agent-1); Wed, 6 Dec 1995 14:25:26 -0500
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
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.)