Re: 2842 to Draft Standard
Yakov Rekhter <yakov@juniper.net> Mon, 14 January 2002 18:49 UTC
Received: from trapdoor.merit.edu (postfix@trapdoor.merit.edu [198.108.1.26]) by nic.merit.edu (8.9.3/8.9.1) with ESMTP id NAA22409 for <idr-archive@nic.merit.edu>; Mon, 14 Jan 2002 13:49:16 -0500 (EST)
Received: by trapdoor.merit.edu (Postfix) id EBC599121A; Mon, 14 Jan 2002 13:48:54 -0500 (EST)
Delivered-To: idr-outgoing@trapdoor.merit.edu
Received: by trapdoor.merit.edu (Postfix, from userid 56) id B7C4D9121B; Mon, 14 Jan 2002 13:48:53 -0500 (EST)
Delivered-To: idr@trapdoor.merit.edu
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41]) by trapdoor.merit.edu (Postfix) with ESMTP id 7EB409121A for <idr@trapdoor.merit.edu>; Mon, 14 Jan 2002 13:48:52 -0500 (EST)
Received: by segue.merit.edu (Postfix) id 59CDA5DE19; Mon, 14 Jan 2002 13:48:52 -0500 (EST)
Delivered-To: idr@merit.edu
Received: from merlot.juniper.net (natint.juniper.net [207.17.136.129]) by segue.merit.edu (Postfix) with ESMTP id C8F185DE0A for <idr@merit.edu>; Mon, 14 Jan 2002 13:48:51 -0500 (EST)
Received: from juniper.net (garnet.juniper.net [172.17.28.17]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id g0EImo638481; Mon, 14 Jan 2002 10:48:50 -0800 (PST) (envelope-from yakov@juniper.net)
Message-Id: <200201141848.g0EImo638481@merlot.juniper.net>
To: Bill Fenner <fenner@research.att.com>
Cc: idr@merit.edu
Subject: Re: 2842 to Draft Standard
In-Reply-To: Your message of "Tue, 08 Jan 2002 12:01:37 PST." <200201082001.MAA06767@windsor.research.att.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <72198.1011034130.1@juniper.net>
Date: Mon, 14 Jan 2002 10:48:50 -0800
From: Yakov Rekhter <yakov@juniper.net>
Sender: owner-idr@merit.edu
Precedence: bulk
Bill > IDR WG, > > In order to progress to Draft Standard, an implementation report > is required (see section 4.1.2 of RFC 2026). In particular: > > The requirement for at least two independent and interoperable > implementations applies to all of the options and features of the > specification. > > RFC 2842 has several optional portions (e.g. sending Notifications > and whether to include the capability in question in the Notification), > which the implementation report that you included in the original > request did not mention. > > I'd like to see a more complete implementation report. For > example, if vendors don't mind being named: > http://www.ietf.org/IESG/Implementations/IPCOMP-Implementation.txt > or if they don't want to be named: > http://www.ietf.org/IESG/Implementations/AGENTX-IMPLEMENTATION See below. > Also, the process would go much more smoothly if there was an > Internet-Draft containing the revision, even though it's so small. > The RFC-Editor can supply the nroff of RFC 2842 if the authors > don't still have their source. Done (see draft-ietf-idr-rfc2842bis-00.txt) Yakov. ---------------------------------------------------------------------- The following is the list of some of the implementations of rfc2842: Ericsson: Interoperates with: Cisco, Juniper Juniper Networks Interoperates with: Cisco Laurel Networks: Interoperates with: Cisco, Juniper NetPlane Systems Inc. Interoperates with: Cisco, Juniper Redback Interoperates with: Cisco, Juniper Riverstone: Interoperates with: Cisco, Juniper, Zebra, Foundry Unisphere Networks: Interoperates with: Cisco, Juniper If a BGP speaker that supports a certain capability determines that its peer doesn't support this capability, 2 implementations never send a NOTIFICATION message to the peer, and 4 implementations sometimes send a NOTIFICATION message to the peer. Out of the 4 implementations that send the NOTIFICATION message (when the peer doesn't support a particular capability), 2 implementations never include the Capability in question in the message, and 2 implementations always include the Capability in question in the message.
- 2842 to Draft Standard Yakov Rekhter
- Re: 2842 to Draft Standard Yakov Rekhter
- Re: 2842 to Draft Standard Yakov Rekhter
- Re: 2842 to Draft Standard Yakov Rekhter