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]
