I read over this and in general I don't think I can provide any additional input that isn't already covered - a lot of great discussion above here. It seems like a smart idea that would benefit the community after input and iteration, so I support adoption to further refine and define it.
nb On Tue, Jul 2, 2024 at 10:50 AM Arturo Servin <[email protected]> wrote: > Hi > > Apologies, I found out that I just replied to Matthias when I wanted to > reply to the group (also the co-authors discussed the topic and we are > aligned with my initial/unicast response to Matthias that I am adding here.) > > Mathias > > >I find the idea of relying on unspecified information outside the session > descriptor at least worth a discussion > > Yes, it is understandable. > > I personally come from the position of the current practice that we follow > (at Google) by using a canonical source of info (PeeringDB for us) to > configure sessions. > > >Reading this remark I would like to ask the following question: is it you > and your co-authors official position that route servers are in scope of > this draft? > > I do not see why a RS would be out of scope. It is a bgp peer and the > draft is about automating the creation of BGP sessions. > > Do I think (now) that they require special considerations? > > No, I personally think (and also consulted with the other co-authors) that > Route-servers do not require any special considerations as everything that > is needed to set up a session with them or as them is already there. But if > we find (as grow group, not just the authors) that we need to add some > support and something is missing, we are open to it. > > Regards > as > > > On Fri, 28 Jun 2024 at 19:06, Matthias Wichtlhuber < > [email protected]> wrote: > >> Hi Arturo, >> >> > One assumption that we have is that the Peering Database (in this case >> PeeringDB but it could be any) is the canonical source of most of the >> information that you need to set up a peering session. >> >> While I understand the general direction of your remarks, I find the idea >> of relying on unspecified information outside the session descriptor at >> least worth a discussion. But I don't think we need to go down that road >> now. >> >> > I hope this helps to clarify our position and why we are hesitant to >> add the fields that you request. It has nothing to do with Route-servers, >> it is about not adding information (that could be conflicting) that is >> already there. >> >> Reading this remark I would like to ask the following question: is it you >> and your co-authors official position that route servers are in scope of >> this draft? >> >> Regards >> Matthias >> >> >> On 28.06.24, 14:13, "Arturo Servin" <[email protected] <mailto: >> [email protected]>> wrote: >> >> >> Matthias >> >> >> One assumption that we have is that the Peering Database (in this case >> PeeringDB but it could be any) is the canonical source of most of the >> information that you need to set up a peering session. >> >> >> >> >> In the case of RS, all that information is already there and there is no >> need to add it again. Furthermore, adding it might generates >> inconsistencies, for example saying that my AS-SET is 'AS-EXAMPLE1' but in >> the Peering Database it is 'AS-EXAMPLE-2' >> >> >> >> >> * Extend peer_type from [public, private] to [public, private, >> route_server] (if private means PNI, not clear from draft) >> >> >> >> >> Peering DB has/should have the Network Type that has 'Route Server', so >> no need to include this >> >> >> * Add an optional Enum [passive, active] mode, if set to passive, the >> requestor must open the connection, if missing defaults to active >> >> >> >> >> TBH, I am not sure what this is, but open to discuss >> >> >> * Add an optional Enum [public, collector] mode, if set to collector, the >> peer must not redistribute routes, if missing defaults to public >> >> >> >> >> Peering DB has/should have the Network Type that has 'Route Collector' >> >> >> >> >> * Add an optional String as_set_v4/v6, format is AS-SET@IRR; field is >> required if peer_type==route_server >> >> >> >> >> Peering DB has/should have IRR as-set/route-set >> >> >> * Add an optional int max_prefix_v4/v6, session will be dropped if >> max_prefix is violated, if missing no limit >> >> >> >> >> >> >> Peering DB has/should have IPv4 Prefixes and IPv6 Prefixes >> >> >> >> >> So, because we assume the peering DB already has this info, and both >> parties requesting the peering agree to use and that the info is there is >> canonical source, we think that it is unnecessary to add those in the API. >> >> >> >> >> I hope this helps to clarify our position and why we are hesitant to add >> the fields that you request. It has nothing to do with Route-servers, it is >> about not adding information (that could be conflicting) that is already >> there. >> >> >> >> >> Regards >> as >> >> >> >> >> On Fri, 28 Jun 2024 at 11:44, Matthias Wichtlhuber <matthias.wichtlhuber= >> [email protected] <mailto:[email protected]> <mailto: >> [email protected] <mailto:[email protected]>>> wrote: >> >> >> Hi Jenny, all, >> >> >> while I understand the theoretical reasoning behind your answer, I would >> like to discuss a few practical issues to clarify the way forward for route >> server support before adoption. >> >> >> (1) Integrating route server support requires minimal effort and the >> changes are not specific to route servers >> >> >> Honestly, I was quite amused by the huge number of changes and added >> complexity in the current revision of the draft [1], while small changes >> for route server support are deemed out of scope :-) Especially since the >> additional fields can be copied from the IX-API route server endpoint >> definition [2] and are already agreed upon by several relevant IXPs, so >> extensive discussions are unlikely. >> >> >> The only changes I see are for the session descriptor in 5.1: >> >> >> * Extend peer_type from [public, private] to [public, private, >> route_server] (if private means PNI, not clear from draft) >> * Add an optional Enum [passive, active] mode, if set to passive, the >> requestor must open the connection, if missing defaults to active >> * Add an optional Enum [public, collector] mode, if set to collector, the >> peer must not redistribute routes, if missing defaults to public >> * Add an optional String as_set_v4/v6, format is AS-SET@IRR; field is >> required if peer_type==route_server >> * Add an optional int max_prefix_v4/v6, session will be dropped if >> max_prefix is violated, if missing no limit >> >> >> That's all. Notably, these fields are not specific to route servers; they >> are also useful in other contexts (e.g., transit across peering LANs). If >> you do not want to file these additions under route server support, you can >> simply file them under general BGP support, which is within the scope of >> the proposal. >> >> >> (2) How a separate draft proposal for RSes would likely play out in >> practice >> >> >> Let's assume we submit our own draft proposal. Doing so would require you >> to integrate exchangeable or extendable definitions of session descriptors >> in your draft (which is a reasonable change if you want to support >> follow-up work). At this point, the effort is already higher than adding >> the fields mentioned above. But let's assume we ignore that: it would >> result in a minimal draft proposal for an RS extension, half of which would >> probably be general preamble. There is nothing wrong with small and concise >> proposals, but I think at some point in the process, the question will >> arise whether the two proposals should be merged to avoid wasting valuable >> resources for reviews and discussions. >> >> >> (3) Having private peering in a separate draft is a better cut than RSes, >> as private peering is a much larger topic >> >> >> Except the description of the session, everything in this draft is in >> place for provisioning route server sessions. As opposed to that, private >> peering is a much larger topic with a lot more unknowns that are hard to >> solve: involving data centers, establishing fiber connections, LOAs, cost, >> common identifiers to name just a few. >> >> >> That being said, the IETF is not political and shouldn't be, but >> integrating route servers would certainly help with the acceptance of this >> draft in the IXP community. My offer to assist with an integration into the >> draft and the OpenAPI definition still stands. >> >> >> Best regards, >> Matthias >> >> >> >> >> >> >> [1] >> https://author-tools.ietf.org/iddiff?url1=draft-ramseyer-grow-peering-api-04&url2=draft-ramseyer-grow-peering-api-05&difftype=--html >> < >> https://author-tools.ietf.org/iddiff?url1=draft-ramseyer-grow-peering-api-04&url2=draft-ramseyer-grow-peering-api-05&difftype=--html> >> <_blank> < >> https://author-tools.ietf.org/iddiff?url1=draft-ramseyer-grow-peering-api-04&url2=draft-ramseyer-grow-peering-api-05&difftype=--html >> < >> https://author-tools.ietf.org/iddiff?url1=draft-ramseyer-grow-peering-api-04&amp;url2=draft-ramseyer-grow-peering-api-05&amp;difftype=--html> >> <_blank>> >> [2] >> https://docs.ix-api.net/latest/#operation/network_feature_configs_create >> <https://docs.ix-api.net/latest/#operation/network_feature_configs_create> >> <_blank> < >> https://docs.ix-api.net/latest/#operation/network_feature_configs_create >> <https://docs.ix-api.net/latest/#operation/network_feature_configs_create> >> <_blank>> >> >> >> -- >> >> >> >> >> Dr.-Ing. Matthias Wichtlhuber >> Team Lead Research and Development >> ------------------------------ >> DE-CIX Management GmbH >> Lindleystr. 12, 60314 Frankfurt (Germany) >> phone: +49 69 1730902 141 >> mobile: +49 171 3836036 >> fax: +49 69 4056 2716 >> e-mail: [email protected] <mailto: >> [email protected]> <_blank> <mailto: >> [email protected] <mailto:[email protected]> >> <_blank>> <mailto:[email protected] <mailto: >> [email protected]> <_blank> <mailto: >> [email protected] <mailto:[email protected]> >> <_blank>>> >> web: www.de-cix.net <_blank> <http://www.de-cix.net/ < >> http://www.de-cix.net/> <_blank>> <http://www.de-cix.net/> < >> http://www.de-cix.net/&gt> <_blank>;> >> ------------------------------ >> DE-CIX Management GmbH >> Executive Directors: Ivaylo Ivanov and Sebastian Seifert Trade registry: >> District court (Amtsgericht) Cologne, HRB 51135 Registered office: >> Lichtstr. >> 43i, 50825 Cologne >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On 26.06.24, 16:39, "Jenny Ramseyer" <[email protected] >> <mailto:[email protected]> <_blank> <mailto: >> [email protected] <mailto:[email protected]> <_blank>> >> <mailto:[email protected] <mailto:[email protected]> >> <_blank> <mailto:[email protected] <mailto: >> [email protected]> <_blank>>>> wrote: >> >> >> >> >> >> >> >> >> Hi Matthias, Stavros, GROW, >> >> >> >> >> >> >> >> >> Thanks for your comments. As we discussed offline, while this API could >> be extended to be used for route servers, we are keeping this draft focused >> to public peering requests. >> >> >> >> >> >> >> >> >> As this is the first draft for the network peering API, we decided to >> keep the first draft scoped only to the security considerations and >> peer-to-peer public peering configuration. Private peering and route server >> peering are both reasonable extensions to consider, but would expand the >> complexity of the draft. As a result, we decided to leave them out for the >> original proposal. >> >> >> >> >> >> >> >> >> We hope to add additional features in a subsequent proposal (private >> peering being the next one of interest), and would encourage you to submit >> a separate proposal for route server support. Hopefully, by building off of >> the same standard, we will be able to extend the features of the API, while >> still keeping each individual proposal well-scoped. >> >> >> >> >> >> >> >> >> Thank you again for the feedback on the draft, and we look forward to >> collaborating on further versions with everyone. >> >> >> >> >> >> >> >> >> Jenny >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> From: Matthias Wichtlhuber <matthias.wichtlhuber= >> [email protected] <mailto:[email protected]> >> <_blank> <mailto:[email protected] <mailto: >> [email protected]> <_blank>> <mailto: >> [email protected] <mailto:[email protected]> >> <_blank> <mailto:[email protected] <mailto: >> [email protected]> <_blank>>>> >> Date: Wednesday, June 26, 2024 at 4:01 AM >> To: Stavros Konstantaras <[email protected] <mailto: >> [email protected]> <_blank> <mailto: >> [email protected] <mailto:[email protected]> >> <_blank>> <mailto:[email protected] <mailto: >> [email protected]> <_blank> <mailto: >> [email protected] <mailto:[email protected]> >> <_blank>>>>, [email protected] <mailto:[email protected]> <_blank> <mailto: >> [email protected] <mailto:[email protected]> <_blank>> <mailto:[email protected] >> <mailto:[email protected]> <_blank> <mailto:[email protected] <mailto: >> [email protected]> <_blank>>> <[email protected] <mailto:[email protected]> <_blank> >> <mailto:[email protected] <mailto:[email protected]> <_blank>> <mailto: >> [email protected] <mailto:[email protected]> <_blank> <mailto:[email protected] >> <mailto:[email protected]> <_blank>>>> >> Subject: [GROW]Re: Working Group Call for Adoption for >> draft-ramseyer-grow-peering-api (start 07/Jun/2024 end 21/Jun/2024) >> >> >> >> >> >> >> >> >> Hi Stavros, >> >> >> >> >> >> >> >> >> thanks for pointing out the lack of route server support. I had some >> private conversations with the authors on this. Maybe they want to comment >> on this specific issue themselves? >> >> >> >> >> >> >> >> >> I agree the draft is only missing a few additional fields in the session >> description that can be added as optional fields (mainly the ones mentioned >> by Stavros + AS-SET and preferred IRR). >> >> >> >> >> >> >> >> >> Regards, >> Matthias >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On 21.06.24, 22:18, "Stavros Konstantaras" < >> [email protected] <mailto:[email protected]> >> <_blank> <mailto:[email protected] <mailto: >> [email protected]> <_blank>> <mailto: >> [email protected] <mailto:[email protected]> >> <_blank> <mailto:[email protected] <mailto: >> [email protected]> <_blank>>> <mailto: >> [email protected] <mailto:[email protected]> >> <_blank> <mailto:[email protected] <mailto: >> [email protected]> <_blank>> <mailto: >> [email protected] <mailto:[email protected]> >> <_blank> <mailto:[email protected] <mailto: >> [email protected]> <_blank>>> <mailto: >> [email protected] <mailto:[email protected]> >> <_blank> <mailto:[email protected] <mailto: >> [email protected]> <_blank>> <mailto: >> [email protected] <mailto:[email protected]> >> <_blank> <mailto:[email protected] <mailto: >> [email protected]> <_blank>>>>>> wrote: >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Hi all, >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> This has been done already but for the sake of the discussion, I thought >> it might be useful to post some general comments over here as well. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> * It seems the standard does not include the Route Servers option and >> authors noted it down in section 10. That’s very unfortunate and I am >> really sorry to read this, we would love to learn more why this happens and >> what are the complications. However, could be possible to make the standard >> a bit more ready for such a scenario so in the future we would not need to >> go into an extensive restructuring? >> * In section 4.4 perhaps the following fields could be included as well >> in the struct??? >> * TTL (optional) >> * Address family (mandatory) >> * BGP Role from RFC9234 (optional) >> * I would like to echo Rayhaan’s comment that publishing the URL in WHOIS >> is a neat way to distribute the API endpoints. >> * I would like to echo Matthias’ comment that section 9 regarding >> security considerations needs some extra clarity as it is a bit hard to >> digest in the current status. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Thank you in advance for your work and looking forward for your feedback. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Kind Regards >> Stavros >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> From: Stavros Konstantaras <[email protected] <mailto: >> [email protected]> <_blank> <mailto: >> [email protected] <mailto:[email protected]> >> <_blank>> <mailto:[email protected] <mailto: >> [email protected]> <_blank> <mailto: >> [email protected] <mailto:[email protected]> >> <_blank>>> <mailto:[email protected] <mailto: >> [email protected]> <_blank> <mailto: >> [email protected] <mailto:[email protected]> >> <_blank>> <mailto:[email protected] <mailto: >> [email protected]> <_blank> <mailto: >> [email protected] <mailto:[email protected]> >> <_blank>>> <mailto:[email protected] <mailto: >> [email protected]> <_blank> <mailto: >> [email protected] <mailto:[email protected]> >> <_blank>> <mailto:[email protected] <mailto: >> [email protected]> <_blank> <mailto: >> [email protected] <mailto:[email protected]> >> <_blank>>>>>> >> >> >> >> >> Date: Wednesday, 12 June 2024 at 22:37 >> To: Job Snijders <[email protected] <mailto: >> [email protected]> <_blank> <mailto:[email protected] >> <mailto:[email protected]> <_blank>> <mailto: >> [email protected] <mailto:[email protected]> >> <_blank> <mailto:[email protected] <mailto: >> [email protected]> <_blank>>> <mailto: >> [email protected] <mailto:[email protected]> >> <_blank> <mailto:[email protected] <mailto: >> [email protected]> <_blank>> <mailto: >> [email protected] <mailto:[email protected]> >> <_blank> <mailto:[email protected] <mailto: >> [email protected]> <_blank>>> <mailto: >> [email protected] <mailto:[email protected]> >> <_blank> <mailto:[email protected] <mailto: >> [email protected]> <_blank>> <mailto: >> [email protected] <mailto:[email protected]> >> <_blank> <mailto:[email protected] <mailto: >> [email protected]> <_blank>>>>>>, [email protected] <mailto: >> [email protected]> <_blank> <mailto:[email protected] <mailto:[email protected]> >> <_blank>> <mailto:[email protected] <mailto:[email protected]> <_blank> <mailto: >> [email protected] <mailto:[email protected]> <_blank>>> <mailto:[email protected] >> <mailto:[email protected]> <_blank> <mailto:[email protected] <mailto: >> [email protected]> <_blank>> <mailto:[email protected] <mailto:[email protected]> >> <_blank> <mailto:[email protected] <mailto:[email protected]> <_blank>>> <mailto: >> [email protected] <mailto:[email protected]> <_blank> <mailto:[email protected] >> <mailto:[email protected]> <_blank>> <mailto:[email protected] <mailto: >> [email protected]> <_blank> <mailto:[email protected] <mailto:[email protected]> >> <_blank>>>>> <[email protected] <mailto:[email protected]> <_blank> <mailto: >> [email protected] <mailto:[email protected]> <_blank>> <mailto:[email protected] >> <mailto:[email protected]> <_blank> <mailto:[email protected] <mailto: >> [email protected]> <_blank>>> <mailto:[email protected] <mailto:[email protected]> >> <_blank> <mailto:[email protected] <mailto:[email protected]> <_blank>> <mailto: >> [email protected] <mailto:[email protected]> <_blank> <mailto:[email protected] >> <mailto:[email protected]> <_blank>>> <mailto:[email protected] <mailto: >> [email protected]> <_blank> <mailto:[email protected] <mailto:[email protected]> >> <_blank>> <mailto:[email protected] <mailto:[email protected]> <_blank> <mailto: >> [email protected] <mailto:[email protected]> <_blank>>>>>> >> Subject: [GROW]Re: Working Group Call for Adoption for >> draft-ramseyer-grow-peering-api (start 07/Jun/2024 end 21/Jun/2024) >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Hi Job and GROW-WG >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> I like the idea of having a Peering API that sets the path for more >> automation in service-level. Is a good idea in general. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> However, I have some second thoughts that make me a bit hesitant and for >> the time being, I can only echo Mohamed’s and Matthias’ concerns. I will >> contact the authors and provide them feedback in a separate e-mail thread >> to see what can be addressed. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Kind Regards >> Stavros >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> From: Job Snijders <[email protected] <mailto: >> [email protected]> <_blank> <mailto:[email protected] >> <mailto:[email protected]> <_blank>> <mailto: >> [email protected] <mailto:[email protected]> >> <_blank> <mailto:[email protected] <mailto: >> [email protected]> <_blank>>> <mailto: >> [email protected] <mailto:[email protected]> >> <_blank> <mailto:[email protected] <mailto: >> [email protected]> <_blank>> <mailto: >> [email protected] <mailto:[email protected]> >> <_blank> <mailto:[email protected] <mailto: >> [email protected]> <_blank>>> <mailto: >> [email protected] <mailto:[email protected]> >> <_blank> <mailto:[email protected] <mailto: >> [email protected]> <_blank>> <mailto: >> [email protected] <mailto:[email protected]> >> <_blank> <mailto:[email protected] <mailto: >> [email protected]> <_blank>>>>>> >> Date: Friday, 7 June 2024 at 20:13 >> To: [email protected] <mailto:[email protected]> <_blank> <mailto:[email protected] >> <mailto:[email protected]> <_blank>> <mailto:[email protected] <mailto: >> [email protected]> <_blank> <mailto:[email protected] <mailto:[email protected]> >> <_blank>>> <mailto:[email protected] <mailto:[email protected]> <_blank> <mailto: >> [email protected] <mailto:[email protected]> <_blank>> <mailto:[email protected] >> <mailto:[email protected]> <_blank> <mailto:[email protected] <mailto: >> [email protected]> <_blank>>> <mailto:[email protected] <mailto:[email protected]> >> <_blank> <mailto:[email protected] <mailto:[email protected]> <_blank>> <mailto: >> [email protected] <mailto:[email protected]> <_blank> <mailto:[email protected] >> <mailto:[email protected]> <_blank>>>>> <[email protected] <mailto:[email protected]> >> <_blank> <mailto:[email protected] <mailto:[email protected]> <_blank>> <mailto: >> [email protected] <mailto:[email protected]> <_blank> <mailto:[email protected] >> <mailto:[email protected]> <_blank>>> <mailto:[email protected] <mailto: >> [email protected]> <_blank> <mailto:[email protected] <mailto:[email protected]> >> <_blank>> <mailto:[email protected] <mailto:[email protected]> <_blank> <mailto: >> [email protected] <mailto:[email protected]> <_blank>>> <mailto:[email protected] >> <mailto:[email protected]> <_blank> <mailto:[email protected] <mailto: >> [email protected]> <_blank>> <mailto:[email protected] <mailto:[email protected]> >> <_blank> <mailto:[email protected] <mailto:[email protected]> <_blank>>>>>> >> Subject: [GROW]Working Group Call for Adoption for >> draft-ramseyer-grow-peering-api (start 07/Jun/2024 end 21/Jun/2024) >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Dear GROW, >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> The author of draft-ramseyer-grow-peering-api asked whether the >> GROW working group could consider adoption of their internet-draft. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> This message is a request to the group for feedback on whether this >> internet-draft should be adopted. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Title: Peering API >> Abstract: >> We propose an API standard for BGP Peering, also known as interdomain >> interconnection through global Internet Routing. This API offers a >> standard way to request public (settlement-free) peering, verify the >> status of a request or BGP session, and list potential connection >> locations. The API is backed by PeeringDB OIDC, the industry >> standard for peering authentication. We also propose future work to >> cover private peering, and alternative authentication methods. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> The Internet-Draft can be found here: >> https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/ < >> https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/> >> <_blank> < >> https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/ < >> https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/> >> <_blank>> < >> https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/ < >> https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/> >> <_blank>> < >> https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/> < >> https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/&gt> >> <_blank>;> < >> https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/ < >> https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/> >> <_blank>> < >> https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/> < >> https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/&gt> >> <_blank>;> < >> https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/> < >> https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/&gt> >> <_blank>;> < >> https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/&gt;> >> < >> https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/&amp;gt;&gt> >> <_blank>;> < >> https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/ < >> https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/> >> <_blank> < >> https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/ < >> https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/> >> <_blank>> < >> https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/ < >> https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/> >> <_blank>> < >> https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/> < >> https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/&gt> >> <_blank>;> < >> https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/ < >> https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/> >> <_blank>>> < >> https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/>> >> < >> https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/&gt;&gt> >> <_blank>;> < >> https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/>> >> < >> https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/&gt;&gt> >> <_blank>;> < >> https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/&gt;&gt;> >> < >> https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/&amp;gt;&amp;gt;&gt> >> <_blank>;> < >> https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/ < >> https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/> >> <_blank> < >> https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/ < >> https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/> >> <_blank>> < >> https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/ < >> https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/> >> <_blank>> < >> https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/> < >> https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/&gt> >> <_blank>;> < >> https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/ < >> https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/> >> <_blank>>> < >> https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/>> >> < >> https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/&gt;&gt> >> <_blank>;> < >> https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/>> >> < >> https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/&gt;&gt> >> <_blank>;> < >> https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/&gt;&gt;> >> < >> https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/&amp;gt;&amp;gt;&gt> >> <_blank>;> < >> https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/> < >> https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/&gt> >> <_blank>; < >> https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/&gt >> < >> https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/&amp;gt> >> <_blank>;> < >> https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/&gt >> < >> https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/&amp;gt> >> <_blank>;> < >> https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/&amp;gt;> >> < >> https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/&amp;amp;gt;&gt> >> <_blank>;> < >> https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/&gt >> < >> https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/&amp;gt> >> <_blank>;>> < >> https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/&amp;gt;>> >> < >> https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/&amp;amp;gt;&gt;&gt> >> <_blank>;> < >> https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/&amp;gt;>> >> < >> https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/&amp;amp;gt;&gt;&gt> >> <_blank>;> < >> https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/&amp;amp;gt;&gt;&gt;> >> < >> https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/&amp;amp;amp;gt;&amp;gt;&amp;gt;&gt> >> <_blank>;> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Please share with the mailing list if you would like this work to be >> adopted by GROW, are willing to review and/or otherwise contribute to >> this draft! >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> WG Adoption call ends June 21st, 2024. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Kind regards, >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Job / Chris >> GROW co-chairs >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> GROW mailing list -- [email protected] <mailto:[email protected]> <_blank> >> <mailto:[email protected] <mailto:[email protected]> <_blank>> <mailto: >> [email protected] <mailto:[email protected]> <_blank> <mailto:[email protected] >> <mailto:[email protected]> <_blank>>> <mailto:[email protected] <mailto: >> [email protected]> <_blank> <mailto:[email protected] <mailto:[email protected]> >> <_blank>> <mailto:[email protected] <mailto:[email protected]> <_blank> <mailto: >> [email protected] <mailto:[email protected]> <_blank>>> <mailto:[email protected] >> <mailto:[email protected]> <_blank> <mailto:[email protected] <mailto: >> [email protected]> <_blank>> <mailto:[email protected] <mailto:[email protected]> >> <_blank> <mailto:[email protected] <mailto:[email protected]> <_blank>>>>> >> To unsubscribe send an email to [email protected] <mailto: >> [email protected]> <_blank> <mailto:[email protected] <mailto: >> [email protected]> <_blank>> <mailto:[email protected] <mailto: >> [email protected]> <_blank> <mailto:[email protected] <mailto: >> [email protected]> <_blank>>> <mailto:[email protected] <mailto: >> [email protected]> <_blank> <mailto:[email protected] <mailto: >> [email protected]> <_blank>> <mailto:[email protected] <mailto: >> [email protected]> <_blank> <mailto:[email protected] <mailto: >> [email protected]> <_blank>>> <mailto:[email protected] <mailto: >> [email protected]> <_blank> <mailto:[email protected] <mailto: >> [email protected]> <_blank>> <mailto:[email protected] <mailto: >> [email protected]> <_blank> <mailto:[email protected] <mailto: >> [email protected]> <_blank>>>>> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> GROW mailing list -- [email protected] <mailto:[email protected]> <_blank> >> To unsubscribe send an email to [email protected] <mailto: >> [email protected]> <_blank> >> >> >> >> >> >> >> _______________________________________________ > GROW mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
