Re: [IETFMIBS] Extending InetAddress(Type) for BGP Multicast VPNs

"Romascanu, Dan (Dan)" <dromasca@avaya.com> Wed, 18 January 2012 11:33 UTC

Return-Path: <dromasca@avaya.com>
X-Original-To: ietfmibs@ietfa.amsl.com
Delivered-To: ietfmibs@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E3C721F87BF for <ietfmibs@ietfa.amsl.com>; Wed, 18 Jan 2012 03:33:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.31
X-Spam-Level:
X-Spam-Status: No, score=-103.31 tagged_above=-999 required=5 tests=[AWL=0.289, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j7LVgLZmzCbF for <ietfmibs@ietfa.amsl.com>; Wed, 18 Jan 2012 03:33:00 -0800 (PST)
Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id ABFA921F8794 for <ietfmibs@ietf.org>; Wed, 18 Jan 2012 03:33:00 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgEFAFKtFk+HCzI1/2dsb2JhbABErD6BAYEFgXIBAQEBAgEBAQEPHgo0CwUHBAIBCA0EBAEBAQoGDAsBBgEmHwkIAgQBEggah1gInHebdgSJMTYBBVYIAgcBAQIBAQgBAQEBAigOHAk3BQGBbTkeFgEBAQKCR2MEmwmMUA
X-IronPort-AV: E=Sophos;i="4.71,529,1320642000"; d="scan'208";a="325106316"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 18 Jan 2012 06:33:00 -0500
Received: from unknown (HELO 307622ANEX5.global.avaya.com) ([135.64.140.13]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 18 Jan 2012 06:19:34 -0500
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 18 Jan 2012 12:32:58 +0100
Message-ID: <EDC652A26FB23C4EB6384A4584434A0407023C2B@307622ANEX5.global.avaya.com>
In-Reply-To: <018101ccd548$a7a10110$f6e30330$@olddog.co.uk>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [IETFMIBS] Extending InetAddress(Type) for BGP Multicast VPNs
Thread-Index: AQGmo3JKdJR0MREEvSbSF1xLQ9WMKQD2v+OyARrYa/8BgKlECgG7KNukAgg97WkChTDVdwGj6zjXAnT7vXoCYikDSwHToJjLAV7as8iVwQZ5IIABGIMA
References: <CBFBAE7D-EFBC-4833-9DD5-C2659C00F419@juniper.net><20120109234012.GA93650@elstar.local><52539B15-9568-486D-9E04-5F753DA2BFAC@juniper.net><20120110105431.GC94367@elstar.local><4F0C35ED.8060705@innovationslab.net><28D0A91D-4C9B-4562-9495-639A38394194@juniper.net><20120110144109.GD95306@elstar.local><4DB4A319-8AA8-4510-B2A9-42A06513F1C0@juniper.net><EDC652A26FB23C4EB6384A4584434A0406F498A6@307622ANEX5.global.avaya.com> <03D47A26-2966-40BB-A372-B560DAE2A57C@juniper.net> <39eb01ccd529$0062c470$6601a8c0@JoanPC><4B6C3A87-D555-4E6F-B0A2-BA2E2BC13083@juniper.net> <018101ccd548$a7a10110$f6e30330$@olddog.co.uk>
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: adrian@olddog.co.uk, Jeff Haas <jhaas@juniper.net>, Joan Cucchiara <jcucchiara@mindspring.com>
Cc: ietfmibs@ietf.org
Subject: Re: [IETFMIBS] Extending InetAddress(Type) for BGP Multicast VPNs
X-BeenThere: ietfmibs@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF MIB Discussion list <ietfmibs.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietfmibs>, <mailto:ietfmibs-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietfmibs>
List-Post: <mailto:ietfmibs@ietf.org>
List-Help: <mailto:ietfmibs-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietfmibs>, <mailto:ietfmibs-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Jan 2012 11:33:01 -0000

> I am not sure what would be
> meant by
> "two interoperating independent implementations" of a MIB module).

Roughly - the method used by the WGs developing MIB modules was to test
(at least) two independent implementations of agents and two
implementations of manager applications, run (at least) a complete MIB
walk on the respective MIB module and make sure that the results
obtained by the two applications from the two agents are consistent. 

Regards,

Dan




> -----Original Message-----
> From: ietfmibs-bounces@ietf.org [mailto:ietfmibs-bounces@ietf.org] On
> Behalf Of Adrian Farrel
> Sent: Tuesday, January 17, 2012 8:49 PM
> To: 'Jeff Haas'; 'Joan Cucchiara'
> Cc: ietfmibs@ietf.org
> Subject: Re: [IETFMIBS] Extending InetAddress(Type) for BGP Multicast
> VPNs
> 
> Hi,
> 
> The "two implementations" rule is imposed on a case-by-case basis by
> the IDR WG
> chairs. It is usual for protocol modifications to BFD.  I am not aware
> of it
> being enforced for MIB modules (indeed, I am not sure what would be
> meant by
> "two interoperating independent implementations" of a MIB module).
> 
> Let's allow the WG chairs to decide what is needed in this case.
> 
> Cheers,
> Adrian
> 
> > -----Original Message-----
> > From: ietfmibs-bounces@ietf.org [mailto:ietfmibs-bounces@ietf.org]
On
> Behalf
> > Of Jeff Haas
> > Sent: 17 January 2012 15:46
> > To: Joan Cucchiara
> > Cc: ietfmibs@ietf.org
> > Subject: Re: [IETFMIBS] Extending InetAddress(Type) for BGP
Multicast
> VPNs
> >
> >
> > On Jan 17, 2012, at 10:02 AM, Joan Cucchiara wrote:
> > > Could you remind me again what the requirements are by the the IDR
> WG to
> > > have
> > > a document advance to RFC status?   As I recall, this is more
> involved than
> > > what is required by
> > > other WGs.
> >
> > Two independent implementations.
> >
> > > Could you also tell us what the status is of the BGPv2 MIBs with
> respect to
> > > the IDR WG requirements?
> >
> > Stable, but lacking implementation of the latest draft.  Juniper has
> an
> enterprise
> > MIB implementation of the older draft but I haven't had the
> opportunity to
> > update the implementation since joining.  (MIBs get poor attention
> from
> product
> > managers in general.)  Another large vendor is rumored to have an
> > implementation in progress.
> >
> > I also had most of an implementation in Quagga that I have yet to
> complete.
> The
> > majority of my problem was net-snmp issues with notifications,
> particularly
> with
> > sysUpTime timestamps.
> > I probably should complete that just to push the standard.
> >
> > -- Jeff
> >
> > _______________________________________________
> > IETFMIBS mailing list
> > IETFMIBS@ietf.org
> > https://www.ietf.org/mailman/listinfo/ietfmibs
> 
> _______________________________________________
> IETFMIBS mailing list
> IETFMIBS@ietf.org
> https://www.ietf.org/mailman/listinfo/ietfmibs