Re: [Idr] Configuration objects in BGP MIB v2: Call for consenus

bill fumerola <> Mon, 14 July 2008 18:43 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 22FFC3A6B02; Mon, 14 Jul 2008 11:43:34 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5674F3A6AD5 for <>; Mon, 14 Jul 2008 11:43:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id plGikDfq9QC9 for <>; Mon, 14 Jul 2008 11:43:31 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7AA093A692F for <>; Mon, 14 Jul 2008 11:43:31 -0700 (PDT)
Received: by (Postfix, from userid 1098) id E21671A4D89; Mon, 14 Jul 2008 11:43:57 -0700 (PDT)
Date: Mon, 14 Jul 2008 11:43:57 -0700
From: bill fumerola <>
To: Simon Leinen <>
Message-ID: <>
References: <20080707015000.GB8722@slice> <>
Mime-Version: 1.0
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/
X-Operating-System: FreeBSD 6.3-MUORG-20080227 amd64
X-PGP-DEAD-Key: 1024D/7F868268
X-PGP-DEAD-Fingerprint: 5B2D 908E 4C2B F253 DAEB FC01 8436 B70B 7F86 8268
X-PGP-Key: 1024D/AE9EB579
X-PGP-Fingerprint: 2E51 E3DE 2C52 C84D 750F 8ADE 1F18 67FB AE9E B579
OpenPGP: id=AE9EB579
Subject: Re: [Idr] Configuration objects in BGP MIB v2: Call for consenus
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

On Sat, Jul 12, 2008 at 08:04:07PM +0200, Simon Leinen wrote:
> I strongly suggest dropping the configuration objects from BGP MIB v2.
> They wouldn't be used much anyway, and their presence will just slow
> down progress of the important (read-only) parts of the MIB.

i would agree, given the work going on in NETCONF. i believe anything
more complex than a one-variable change is going to become out of style
for SNMP configuration of devices that support NETCONF. BGP changes
rarely if ever would be so simple. the lack of an atomic method of change
in SNMP makes BGP configuration via SNMP risky.

also as Mr. McPherson alludes to, the security of snmp configurations
in many sites remains simple and underprotected. a NETCONF setup would
almost certainly be configured to secure the authentication and control
plane in ways that most snmp installations fail to do.

-- bill
Idr mailing list