Re: New work items

Eric Rosen <erosen@cisco.com> Mon, 21 September 2009 15:48 UTC

Return-Path: <erosen@cisco.com>
X-Original-To: l3vpn@core3.amsl.com
Delivered-To: l3vpn@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5843E3A6901 for <l3vpn@core3.amsl.com>; Mon, 21 Sep 2009 08:48:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.179
X-Spam-Level:
X-Spam-Status: No, score=-6.179 tagged_above=-999 required=5 tests=[AWL=-0.180, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rkWm+-ARpjdt for <l3vpn@core3.amsl.com>; Mon, 21 Sep 2009 08:48:16 -0700 (PDT)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 205EC28C15C for <l3vpn@ietf.org>; Mon, 21 Sep 2009 08:48:16 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.44,425,1249257600"; d="scan'208";a="59158928"
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 21 Sep 2009 15:49:16 +0000
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n8LFnGaf030991; Mon, 21 Sep 2009 11:49:16 -0400
Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n8LFnGJQ001645; Mon, 21 Sep 2009 15:49:16 GMT
Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.1/8.13.1) with ESMTP id n8LFnGrn009670; Mon, 21 Sep 2009 11:49:16 -0400
To: Ross Callon <rcallon@juniper.net>
Subject: Re: New work items
In-reply-to: Your message of Wed, 16 Sep 2009 11:29:03 -0400. <DF7F294AF4153D498141CBEFADB177049A09C7ED6F@EMBX01-WF.jnpr.net>
Date: Mon, 21 Sep 2009 11:49:16 -0400
Message-ID: <9669.1253548156@erosen-linux>
From: Eric Rosen <erosen@cisco.com>
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1385; t=1253548156; x=1254412156; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=erosen@cisco.com; z=From:=20Eric=20Rosen=20<erosen@cisco.com> |Subject:=20Re=3A=20New=20work=20items=20 |Sender:=20 |To:=20Ross=20Callon=20<rcallon@juniper.net>; bh=NLhBiEvGs0ceTqeNxddWrvYZCDsp6b5Wu1CcHvMixLQ=; b=OyL18d3zZ2HzrJpAa1J5tNPiNehNqOeUXtRvG+UIC/FMHj331MWf0/5vUs pa5ma9kHUsqA+A9DUAq7zNsf3pMWWN0n0rEMHvUlQ8MR/CUBkRzFSiOah4K5 rDO1wM9Axb;
Authentication-Results: rtp-dkim-1; header.From=erosen@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; );
Cc: Yakov Rekhter <yakov@juniper.net>, "erosen@cisco.com" <erosen@cisco.com>, "l3vpn@ietf.org" <l3vpn@ietf.org>, Adrian Farrel <adrian@olddog.co.uk>
X-BeenThere: l3vpn@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: erosen@cisco.com
List-Id: <l3vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l3vpn>
List-Post: <mailto:l3vpn@ietf.org>
List-Help: <mailto:l3vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l3vpn>, <mailto:l3vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Sep 2009 15:48:17 -0000

Ross> The current 5+ year old charter is indeed rather vague regarding what
Ross> multicast work is needed (or was anticipated as needed 5 years
Ross> ago). This is something that would have been nice to have fixed long
Ross> ago. Given that the future work of L3VPN is likely to be largely on
Ross> multicast, it would be desirable to figure out what future work we can
Ross> currently anticipate is wanted and get the charter updated.

I don't think there is any need to change the rules in the middle of the
game.  The charter is fine the way it is.  In any event, until it is
changed, I see no justification for failing to accept "new" work items.

Ross> I suppose that the IDR charter could be re-written to say a very
Ross> simple "work on BGP enhancements forever". This would be a pretty
Ross> accurate top-level description of what IDR does, and might not be all
Ross> that different from the L3VPN WG's charter's current description of
Ross> multicast work

I think that's a fairly good model, as it allows for relatively quick
response to customer demands.  In many cases features are going to get
implemented anyway, and the IETF should encourage, not discourage, the
creation of public specifications for IETF review.  If the IESG had to
pre-approve the addition of every new BGP feature to the IDR charter, the
IDR WG would be a lot less useful.