Hi Matthias, Our intent is to support alternate peering presence providers in the draft today, although we need to make it clearer.
In the /locations endpoint, we require the location id to be of the form [provider][type][id], the example being “pdb:ix:1”. (https://www.ietf.org/archive/id/draft-ramseyer-grow-peering-api-05.html#section-5.1-2) The idea there was to support multiple different provider types in the locations provider—an earlier version of the spec mentioned this explicitly, but it seems we removed that somewhere along the way. I will add it back in the next version, as our intent was to allow the API endpoint to support any and all location providers that might offer a database, and let the API server decide which ones to support. Thanks for pointing this out, I will make sure to update it in the next version. Jenny On 6/20/24, 9:05 AM, "Matthias Wichtlhuber" <matthias.wichtlhuber=40de-cix....@dmarc.ietf.org> wrote: Hi Jenny, Carlos, the proposal sounds good to me. However, I'm still concerned about point (1) from my original email. Do you have any plans to generalize the draft so it doesn't exclusively rely on Peering DB? You've already generalized the draft for identity management, and I think the same should be done for matching peering LAN presences. For example, you could allow multiple types of Peering LAN identifiers from various databases, including but not limited to Peering DB's ixlan id. This approach would give third parties, particularly RIRs, the opportunity to implement the draft if they choose to do so. Regards, Matthias On 14.06.24, 17:12, "Jenny Ramseyer" <ramseyer=40meta....@dmarc.ietf.org<mailto:40meta....@dmarc.ietf.org> <mailto:40meta....@dmarc.ietf.org<mailto:40meta....@dmarc.ietf.org>>> wrote: Hi Matthias, grow, Thank you for the feedback. We can look into adding a diagram to clarify the signing process, along with an overview section to explain the flow. We will try to add something in the next version. Thank you, Jenny Get Outlook for Android <https://aka.ms/AAb9ysg><https://aka.ms/AAb9ysg%3e> <https://aka.ms/AAb9ysg>><https://aka.ms/AAb9ysg>%3e> ________________________________________ From: Matthias Wichtlhuber <matthias.wichtlhuber=40de-cix....@dmarc.ietf.org<mailto:40de-cix....@dmarc.ietf.org> <mailto:40de-cix....@dmarc.ietf.org<mailto:40de-cix....@dmarc.ietf.org>>> Sent: Wednesday, June 12, 2024 5:54:05 AM To: Carlos Aguado <cagu...@infra.structur.es<mailto:cagu...@infra.structur.es> <mailto:cagu...@infra.structur.es<mailto:cagu...@infra.structur.es>>> Cc: grow@ietf.org<mailto:grow@ietf.org> <mailto:grow@ietf.org<mailto:grow@ietf.org>> <grow@ietf.org<mailto:grow@ietf.org> <mailto:grow@ietf.org<mailto:grow@ietf.org>>> Subject: [GROW]Re: Working Group Call for Adoption for draft-ramseyer-grow-peering-api (start 07/Jun/2024 end 21/Jun/2024) Hi Carlos, grow, IMHO you can improve the security considerations section by adding an introductory high-level overview on the flow between the entities involved, the information passed among them and who signs what before moving into the implementation details. This would probably help to structure the discussion. So more on the use case side. Kind regards, Matthias On 12.06.24, 12:20, "Carlos Aguado" <cagu...@infra.structur.es<mailto:cagu...@infra.structur.es> <mailto:cagu...@infra.structur.es<mailto:cagu...@infra.structur.es>> <mailto:cagu...@infra.structur.es<mailto:cagu...@infra.structur.es> <mailto:cagu...@infra.structur.es<mailto:cagu...@infra.structur.es>> <mailto:cagu...@infra.structur.es<mailto:cagu...@infra.structur.es> <mailto:cagu...@infra.structur.es<mailto:cagu...@infra.structur.es>>>>> wrote: 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=40de-cix....@dmarc.ietf.org<mailto:40de-cix....@dmarc.ietf.org> <mailto:40de-cix....@dmarc.ietf.org<mailto:40de-cix....@dmarc.ietf.org>> <mailto:40de-cix....@dmarc.ietf.org<mailto:40de-cix....@dmarc.ietf.org> <mailto:40de-cix....@dmarc.ietf.org<mailto:40de-cix....@dmarc.ietf.org>> <mailto:40de-cix....@dmarc.ietf.org<mailto:40de-cix....@dmarc.ietf.org> <mailto:40de-cix....@dmarc.ietf.org<mailto:40de-cix....@dmarc.ietf.org>>>> <mailto:40de-cix....@dmarc.ietf.org<mailto:40de-cix....@dmarc.ietf.org> <mailto:40de-cix....@dmarc.ietf.org<mailto:40de-cix....@dmarc.ietf.org>> <mailto:40de-cix....@dmarc.ietf.org<mailto:40de-cix....@dmarc.ietf.org> <mailto:40de-cix....@dmarc.ietf.org<mailto:40de-cix....@dmarc.ietf.org>> <mailto:40de-cix....@dmarc.ietf.org<mailto:40de-cix....@dmarc.ietf.org> <mailto:40de-cix....@dmarc.ietf.org<mailto:40de-cix....@dmarc.ietf.org>>>>>> 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" <job=40fastly....@dmarc.ietf.org<mailto:40fastly....@dmarc.ietf.org> <mailto:40fastly....@dmarc.ietf.org<mailto:40fastly....@dmarc.ietf.org>> <mailto:40fastly....@dmarc.ietf.org<mailto:40fastly....@dmarc.ietf.org> <mailto:40fastly....@dmarc.ietf.org<mailto:40fastly....@dmarc.ietf.org>> <mailto:40fastly....@dmarc.ietf.org<mailto:40fastly....@dmarc.ietf.org> <mailto:40fastly....@dmarc.ietf.org<mailto:40fastly....@dmarc.ietf.org>>>> <_blank> <mailto:40fastly....@dmarc.ietf.org<mailto:40fastly....@dmarc.ietf.org> <mailto:40fastly....@dmarc.ietf.org<mailto:40fastly....@dmarc.ietf.org>> <mailto:40fastly....@dmarc.ietf.org<mailto:40fastly....@dmarc.ietf.org> <mailto:40fastly....@dmarc.ietf.org<mailto:40fastly....@dmarc.ietf.org>> <mailto:40fastly....@dmarc.ietf.org<mailto:40fastly....@dmarc.ietf.org> <mailto:40fastly....@dmarc.ietf.org<mailto:40fastly....@dmarc.ietf.org>>>> <_blank>>> 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/><https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/%3e> <https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/><https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/%3e> <https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/>><https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/>%3e> <https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/ <https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/><https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/%3e> <https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/>><https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/%3e%3e> <https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/>>><https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/>>%3e> <_blank> <https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/ <https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/><https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/%3e> <https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/ <https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/><https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/%3e> <https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/>><https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/%3e%3e> <https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/>>><https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/>>%3e> <_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 -- grow@ietf.org<mailto:grow@ietf.org> <mailto:grow@ietf.org<mailto:grow@ietf.org>> <mailto:grow@ietf.org<mailto:grow@ietf.org> <mailto:grow@ietf.org<mailto:grow@ietf.org>> <mailto:grow@ietf.org<mailto:grow@ietf.org> <mailto:grow@ietf.org<mailto:grow@ietf.org>>>> <_blank> <mailto:grow@ietf.org<mailto:grow@ietf.org> <mailto:grow@ietf.org<mailto:grow@ietf.org>> <mailto:grow@ietf.org<mailto:grow@ietf.org> <mailto:grow@ietf.org<mailto:grow@ietf.org>> <mailto:grow@ietf.org<mailto:grow@ietf.org> <mailto:grow@ietf.org<mailto:grow@ietf.org>>>> <_blank>> To unsubscribe send an email to grow-le...@ietf.org<mailto:grow-le...@ietf.org> <mailto:grow-le...@ietf.org<mailto:grow-le...@ietf.org>> <mailto:grow-le...@ietf.org<mailto:grow-le...@ietf.org> <mailto:grow-le...@ietf.org<mailto:grow-le...@ietf.org>> <mailto:grow-le...@ietf.org<mailto:grow-le...@ietf.org> <mailto:grow-le...@ietf.org<mailto:grow-le...@ietf.org>>>> <_blank> <mailto:grow-le...@ietf.org<mailto:grow-le...@ietf.org> <mailto:grow-le...@ietf.org<mailto:grow-le...@ietf.org>> <mailto:grow-le...@ietf.org<mailto:grow-le...@ietf.org> <mailto:grow-le...@ietf.org<mailto:grow-le...@ietf.org>> <mailto:grow-le...@ietf.org<mailto:grow-le...@ietf.org> <mailto:grow-le...@ietf.org<mailto:grow-le...@ietf.org>>>> <_blank>> _______________________________________________ GROW mailing list -- grow@ietf.org<mailto:grow@ietf.org> <mailto:grow@ietf.org<mailto:grow@ietf.org>> <mailto:grow@ietf.org<mailto:grow@ietf.org> <mailto:grow@ietf.org<mailto:grow@ietf.org>> <mailto:grow@ietf.org<mailto:grow@ietf.org> <mailto:grow@ietf.org<mailto:grow@ietf.org>>>> <_blank> To unsubscribe send an email to grow-le...@ietf.org<mailto:grow-le...@ietf.org> <mailto:grow-le...@ietf.org<mailto:grow-le...@ietf.org>> <mailto:grow-le...@ietf.org<mailto:grow-le...@ietf.org> <mailto:grow-le...@ietf.org<mailto:grow-le...@ietf.org>> <mailto:grow-le...@ietf.org<mailto:grow-le...@ietf.org> <mailto:grow-le...@ietf.org<mailto:grow-le...@ietf.org>>>> <_blank>
_______________________________________________ GROW mailing list -- grow@ietf.org To unsubscribe send an email to grow-le...@ietf.org
