Hello all, Med, About pending questions, we are trying to navigate the IETF process to gather the consensus on the right use case. Please let me shed light on what's been discussed privately.
I shared that the main business use case expressed at the top of the document is to describe intent of interconnection via a RESTful API and the behaviors each party can expect. This declarative intent behavior is to help both sides to programmatically reach a business decision automatically before proceeding with the organizations' internal processes. In my opinion, the YANG model proposed is very extensive and flexible as one would expect to configure features of a control plane. I am concerned that such flexibility makes it very ambiguous to programmatically cover the expectations from the combination of options in an API, without defaulting to human escalation. I do agree that alignment to YANG data types can help with the device configuration, but in this draft we are trying to reduce ambiguity and not expose device configuration but a model of what semantics, API verbs, and the associated data types go together. If the request is to use the YANG model to influence those data types I'd think it is a reasonable next step to hear more of this wider audience as to what the expectation of doing with them is. We have also iterated over the doc to make the document self contained and describe the API artifacts without resorting to a github repo. >From the IETF submission guidelines we were under the impression that this disambiguation is expected to happen during adoption but please let us know whether we should have further iterations on a specific topic before that or whether iterating on the document from wider inputs in this list is the correct step at this stage. Best, Carlos On Wed, 12 Jun 2024 at 08:11, <[email protected]> wrote: > Hi Job, all, > > As an editor of [1], I'm supportive of work that enables more automation, > not only for provisioning but also for service negotiation. I'm > specifically supportive of mechanisms to automate interconnection. > > However, I think we need to clarify the scope here, avoid overlapping, and > leverage existing specifications before considering adoption. > > When checking the archives I was surprised that there was no technical > discussion on the list. There was no follow-up to the very few technical > comments raised on the list: > > * Tom asked on [2] to clarify the use of existing tools such YANG. > * Qin raised [3] a question whether Attachment Circuit as Service API > defined in draft-ietf-opsawg-teas-attachment-circuit be reused, but no > follow-up. > * I raised a similar point in [4], and also privately to the authors. > > Very detailed walk trough examples are provided in > https://datatracker.ietf.org/doc/html/draft-ietf-opsawg-teas-attachment-circuit-13#name-interconnection-via-interne > to cover the target use cases in draft-ramseyer (and even more). The module > includes a rich set of reusable groupings to cover other workflow needs, > etc. There are also tools out there for YANG/OpenAPI transforms. > > So, the first question we need to assess is what are the missing pieces? > > Thank you. > > Cheers, > Med > > [1] https://datatracker.ietf.org/doc/html/rfc8921 > [1] > https://mailarchive.ietf.org/arch/msg/grow/0TkURmDuTSv4KNsZ8K9URjHAPs0/ > [2] > https://mailarchive.ietf.org/arch/msg/grow/HZ36NsnyKA6aN7OSOI4XpNGfYkc/ > [3] > https://mailarchive.ietf.org/arch/msg/grow/jHut32YWE5zceUifo5pO3MAtxnc/ > > > -----Message d'origine----- > > De : Job Snijders <[email protected]> > > Envoyé : vendredi 7 juin 2024 20:13 > > À : [email protected] > > Objet : [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%2 > > Fdatatracker.ietf.org%2Fdoc%2Fdraft-ramseyer-grow-peering- > > api%2F&data=05%7C02%7Cmohamed.boucadair%40orange.com%7Cd9a91862bb > > 794544104708dc871d81ca%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0 > > %7C638533807998852919%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDA > > iLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdat > > a=KK16qnk7B278E1eDMSv%2FlhGOkwhI4m%2BbQLRlnTY6iCk%3D&reserved=0 > > > > 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] > > ____________________________________________________________________________________________________________ > 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 -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
