Re: [Idr] Charter text from IETF 105 - WG LC (11/18 to 12/2/2019)

[John Scudder <[e-mail]>]

Hi Sue and all,

My bad, I had this sitting in my edit buffer but forgot to send it. It reflects a few updates to the earlier text you quoted below, mainly it incorporates a few suggestions from Alvaro and from our earlier mailing list thread about the text.

Alvaro had raised one significant open point which isn’t covered in our current text, which is advancement of BGP to Internet Standard. This would be a significant work item for the group. It’s probably worth considering but I didn’t see it as a mere editorial change as the rest is.

Sorry for missing the boat on getting this out earlier.

—John


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 (including specification of YANG modules), and security of BGP.

With respect to security, IDR will be the primary group to work on further enhancements to the protocol to provide security features.

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. The IDR chairs will work with the chairs of related working groups to maintain open communications.

IDR welcomes advice and requirements from other working groups, particularly from GROW which is chartered for this purpose.


On Nov 18, 2019, at 9:54 AM, Susan Hares <[e-mail]<mailto:[e-mail]>> wrote:

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