[Idr] Charter text from IETF 105 - WG LC (11/18 to 12/2/2019)
"Susan Hares" <shares@ndzh.com> Mon, 18 November 2019 01:54 UTC
Return-Path: <shares@ndzh.com>
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 7EC49120288 for <idr@ietfa.amsl.com>; Sun, 17 Nov 2019 17:54:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.348
X-Spam-Level: *
X-Spam-Status: No, score=1.348 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.4, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no 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 tLoEvA7CnAE5 for <idr@ietfa.amsl.com>; Sun, 17 Nov 2019 17:54:10 -0800 (PST)
Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86187120048 for <idr@ietf.org>; Sun, 17 Nov 2019 17:54:10 -0800 (PST)
X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=31.133.148.129;
From: Susan Hares <shares@ndzh.com>
To: idr@ietf.org
Date: Sun, 17 Nov 2019 20:54:03 -0500
Message-ID: <009001d59db3$0f4d03f0$2de70bd0$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0091_01D59D89.26779830"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdWdseIkp3GNSm24TfOaAwUzTS0QrA==
Content-Language: en-us
X-Antivirus: AVG (VPS 191117-0, 11/17/2019), Outbound message
X-Antivirus-Status: Not-Tested
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/MPYullgFP350VyciaJ4_WM0-c34>
Subject: [Idr] Charter text from IETF 105 - WG LC (11/18 to 12/2/2019)
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: Mon, 18 Nov 2019 01:54:13 -0000
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 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. --------------- This is the text from IETF 105 on the IDR charter. I received feedback at the meeting on the asking that if the words "consulted" and "informed' implied approval. The words consulted and informed mean the English definition of those words. The charter WG LC only refers to the text above. The IDR chairs will set milestone for the IDR WG based on feedback from the IDR WG. These milestones can change as rapidly as the WG gives concrete feedback (3-4 weeks to months). No additional feedback on the milestones have been given since IETF 105. The BGP status reports have been sent every 2-3 weeks, and seem to have been useful. Please continue to send priorities on documents to the WG chairs. Please continue to send feedback on the mail list. Cheerily, Susan Hares
- [Idr] Charter text from IETF 105 - WG LC (11/18 t… Susan Hares
- Re: [Idr] Charter text from IETF 105 - WG LC (11/… John Scudder