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]>
Date: Wednesday, 12 June 2024 at 22:37
To: Job Snijders <[email protected]>, [email protected]
<[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]>
Date: Friday, 7 June 2024 at 20:13
To: [email protected] <[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://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]
To unsubscribe send an email to [email protected]
_______________________________________________
GROW mailing list -- [email protected]
To unsubscribe send an email to [email protected]
