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]>> 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]>> Date: Wednesday, 12 June 2024 at 22:37 To: Job Snijders <[email protected] <mailto:[email protected]>>, [email protected] <mailto:[email protected]> <[email protected] <mailto:[email protected]>> 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]>> Date: Friday, 7 June 2024 at 20:13 To: [email protected] <mailto:[email protected]> <[email protected] <mailto:[email protected]>> 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ramseyer-grow-peering-api%2F&data=05%7C02%7Cstavros.konstantaras%40ams-ix.net%7C86ac75f5f22946c553e408dc871d7cdd%7C09d28fc155624961a4848ce4932094ae%7C0%7C0%7C638533807950750327%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=UgLI6CYIDc%2BQwQWdE%2FBzGGAwup45Jcgsktqps38DyHk%3D&reserved=0 <https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ramseyer-grow-peering-api%2F&data=05%7C02%7Cstavros.konstantaras%40ams-ix.net%7C86ac75f5f22946c553e408dc871d7cdd%7C09d28fc155624961a4848ce4932094ae%7C0%7C0%7C638533807950750327%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=UgLI6CYIDc%2BQwQWdE%2FBzGGAwup45Jcgsktqps38DyHk%3D&reserved=0> <https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/> <https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/>> 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]> To unsubscribe send an email to [email protected] <mailto:[email protected]>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
