Hi grow, Matthias, About your second point. We wrote that specific part with the goal of providing a mini threat model that substantiates the gradual addition of security features we have received inputs on and that mitigate the different levels of risk organizations are willing to support. That section aims to address the need for arbitrary identity providers beyond PeeringDB, and the tie back to RPKI via RSC among others. I would appreciate it if you could please clarify how we can make it easier to parse. Do you expect more or less context on use cases? More or less implementation detail?
Best, Carlos On Wed, 12 Jun 2024 at 09:39, Matthias Wichtlhuber <matthias.wichtlhuber= [email protected]> wrote: > Hi grow, Job, > > I am in support of this draft. However I have two concerns I would like to > raise because I am unsure whether they should be clarified before adoption: > > (1) The draft bakes in PeeringDB as an identity and information provider. > PeeringDB is a great project, but tying a standard to the existence of a > specific organization like PeeringDB might be a general concern. > (2) I have a hard time parsing the new additions to the security concept > in the current revision. The authors might consider clarifying this part > before going into an extended discussion (this is more a recommendation > than a real concern). > > If both can be solved after adoption, I am happy to do so on the grow list. > > Kind regards, > Matthias > > On 07.06.24, 20:13, "Job Snijders" <[email protected] > <mailto:[email protected]>> wrote: > > > 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/> > > > 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]> > > > _______________________________________________ > 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]
