Re: [Idr] Draft IDR charter text

Jared Mauch <jared@puck.nether.net> Thu, 25 July 2019 23:15 UTC

Return-Path: <jared@puck.nether.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E30A12024E for <idr@ietfa.amsl.com>; Thu, 25 Jul 2019 16:15:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q2icdto2QABM for <idr@ietfa.amsl.com>; Thu, 25 Jul 2019 16:15:31 -0700 (PDT)
Received: from puck.nether.net (puck.nether.net [204.42.254.5]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7262712023B for <idr@ietf.org>; Thu, 25 Jul 2019 16:15:31 -0700 (PDT)
Received: from [IPv6:2600:380:7c4d:5694:bd6a:970:58c6:140f] (unknown [IPv6:2600:380:7c4d:5694:bd6a:970:58c6:140f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id 299DA540090; Thu, 25 Jul 2019 19:15:29 -0400 (EDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-83FE6824-E510-48CC-A49C-58A8CD39AEFA"
Mime-Version: 1.0 (1.0)
From: Jared Mauch <jared@puck.nether.net>
X-Mailer: iPhone Mail (16G77)
In-Reply-To: <CACWOCC_T_D9+4yG12w0aPpx74J3tm3osVSPEM0E-vwf-6k4YTg@mail.gmail.com>
Date: Thu, 25 Jul 2019 19:15:26 -0400
Cc: John Scudder <jgs=40juniper.net@dmarc.ietf.org>, idr wg <idr@ietf.org>
Content-Transfer-Encoding: 7bit
Message-Id: <8A0EEF33-CE23-4FB6-93E8-92B4CCDF6CAA@puck.nether.net>
References: <9CBFDB82-5965-4D76-A85F-3A8F5C89357F@juniper.net> <CACWOCC_T_D9+4yG12w0aPpx74J3tm3osVSPEM0E-vwf-6k4YTg@mail.gmail.com>
To: Job Snijders <job@instituut.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/u39-5XMwVaiKr8Xo22XEwlbzzXU>
Subject: Re: [Idr] Draft IDR charter text
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jul 2019 23:15:33 -0000

I have read this text and think it looks good as well. 

Sent from my iCar

> On Jul 25, 2019, at 6:58 PM, Job Snijders <job@instituut.net> wrote:
> 
> This looks great so far
> 
>> On Thu, Jul 25, 2019 at 18:44 John Scudder <jgs=40juniper.net@dmarc.ietf.org> wrote:
>> Hi All,
>> 
>> Here’s a draft of new charter text we came up with after consulting with the Routing ADs [*]:
>> 
>> —
>> The Inter-Domain Routing Working Group is chartered to standardize, develop, and support the Border Gateway Protocol Version 4 (BGP-4)  [RFC 4271] capable of supporting policy based routing for TCP/IP Internets.
>> 
>> The main objective of the working group is to support the use of BGP-4 by IP version 4 and IP version 6 networks. The working group will continue to work on improving the robustness, scalability, deployability, manageability, and security of BGP.
>> 
>> BGP is an enabling protocol or subject of interest for a number of other working groups, including BESS, LSVR, LSR, SIDROPS, and GROW. Those (and other) groups may develop standards that make use of BGP. IDR asks that when another working group proposes changes and additions to BGP, that IDR should be informed. In particular, if another working group requests allocation of a code point from a BGP protocol registry, IDR should be consulted as soon as possible. The Border Gateway Protocol (BGP) Parameters group is the most notable example of such registries. In general, protocol changes should be progressed through IDR, whereas uses of extensible mechanisms need only notification to IDR.
>> 
>> IDR desires to review extensions made to BGP in other working groups at least at WG document adoption and during working group last calls. The IDR working group will also provide advice and guidance on BGP to other working groups as requested.
>> 
>> IDR welcomes advice and requirements from other working groups, particularly from GROW which is chartered for this purpose. 
>> —
>> 
>> The main changes vs. the prior text are,
>> 
>> 1. Talks in more detail about what we expect from our peer WGs and what they can expect from us.
>> 2. Removes the “work items” section. This was largely redundant with the milestones and it just muddies the waters. 
>> 
>> Essentially the intent is to say “we do BGP” but a little more rigorously (or at least verbosely). :-)
>> 
>> If we adopt this charter, or one like it, the next step would be to do a pass of updating our milestones, fairly extensively. Many of the suggestions that have been made so far (thank you!) would fall into that discussion.
>> 
>> Regards,
>> 
>> —John
>> 
>> [*] Does not imply the Routing ADs have approved this text, they have not provided an opinion on it.
>> _______________________________________________
>> Idr mailing list
>> Idr@ietf.org
>> https://www.ietf.org/mailman/listinfo/idr
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr