[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