Re: [Idr] Draft IDR charter text

"UTTARO, JAMES" <> Fri, 26 July 2019 07:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7E1A21202C2 for <>; Fri, 26 Jul 2019 00:31:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.498
X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RrFpG3WV6Zwj for <>; Fri, 26 Jul 2019 00:31:36 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9E03D1202C0 for <>; Fri, 26 Jul 2019 00:31:36 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id x6Q7PMMc012055; Fri, 26 Jul 2019 03:31:32 -0400
Received: from ( []) by with ESMTP id 2tyq23yc3n-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 26 Jul 2019 03:31:32 -0400
Received: from (localhost []) by (8.14.5/8.14.5) with ESMTP id x6Q7VV9K011760; Fri, 26 Jul 2019 03:31:31 -0400
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id x6Q7VLEQ011691 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 26 Jul 2019 03:31:21 -0400
Received: from ( []) by (Service) with ESMTP id 06E7140002D8; Fri, 26 Jul 2019 07:31:21 +0000 (GMT)
Received: from (unknown []) by (Service) with ESMTPS id E47F040002D2; Fri, 26 Jul 2019 07:31:20 +0000 (GMT)
Received: from ([]) by ([]) with mapi id 14.03.0439.000; Fri, 26 Jul 2019 03:31:20 -0400
From: "UTTARO, JAMES" <>
To: Job Snijders <>, John Scudder <>
CC: idr wg <>
Thread-Topic: [Idr] Draft IDR charter text
Thread-Index: AQHVQzp8jJykHDeCGE+hycpMUkTEPabcNYoAgABMMjA=
Date: Fri, 26 Jul 2019 07:31:19 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_B17A6910EEDD1F45980687268941550F4D891927MISOUT7MSGUSRCD_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-26_04:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1907260097
Archived-At: <>
Subject: Re: [Idr] Draft IDR charter text
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 26 Jul 2019 07:31:39 -0000


Jim Uttaro

From: Idr <> On Behalf Of Job Snijders
Sent: Thursday, July 25, 2019 6:58 PM
To: John Scudder <>
Cc: idr wg <>
Subject: Re: [Idr] Draft IDR charter text

This looks great so far

On Thu, Jul 25, 2019 at 18:44 John Scudder <<>> 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.



[*] Does not imply the Routing ADs have approved this text, they have not provided an opinion on it.
Idr mailing list<><>