Hi Christopher, all I'm supportive of this work, overall.
However, I'm concerned that the authors didn't addressed comments raised in the past about leveraging/aligning this spec with existing IETF data models for managing interconnections. At least, we need to position this work vs. those (see the archives for the pointers). Also, how this interacts with existing RESTFUL specs such as RFC8040, which can consumes YANG data models without having to repeat details about verbs/methods/etc. There are some tools, e.g., https://github.com/Amartus/yang2swagger that allows to generate OpenAPI specs from YANG data models. I think some discussion is needed here on the methodology/approach. Thank you. Cheers, Med > -----Message d'origine----- > De : Christopher Morrow <christopher.mor...@gmail.com> > Envoyé : vendredi 15 novembre 2024 03:20 > À : grow-...@ietf.org; <grow-cha...@ietf.org> <grow- > cha...@ietf.org>; grow@ietf.org grow@ietf.org <grow@ietf.org> > Objet : [GROW] [WGADOPTION] draft-ramseyer-grow-peering-api - > ends 11/29/2024 (Nov 29, 2024) > > Howdy Grow Folks, > > Please consider this to be a WG Adoption Call for the subject > draft, available at this endpoint: > > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fdatatracker.ietf.org%2Fdoc%2Fdraft-ramseyer-grow-peering- > api%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Ce1c3f03c1c > e746316ba608dd051c1d7c%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0 > %7C638672340497170521%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnR > ydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoy > fQ%3D%3D%7C0%7C%7C%7C&sdata=lLNxugKCLxQ6Tr%2F%2FGgWEKoseFrFg1HJlz > FdyIsE11HU%3D&reserved=0 > > Abstract of same included for your reference: > "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." > > Please give this a read, a consideration and comment or three (no > more, sorry qos on comments is now in effect... unless signed > triplicate forms from the networker!) and let's attempt to close > out prior to the 2nd of December this very year 2 thousand and > twenty 4. > > -chris > CoChairHuman > > _______________________________________________ > GROW mailing list -- grow@ietf.org > To unsubscribe send an email to grow-le...@ietf.org ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. _______________________________________________ GROW mailing list -- grow@ietf.org To unsubscribe send an email to grow-le...@ietf.org
