Hi Chris and GROW, I wanted to follow up on the Peering API (draft-ramseyer-grow-peering-api) Adoption. My co-author, Arturo, presented the draft updates at the GROW meeting in Dublin last week. Out of that meeting, we would like to request adoption of the draft, and continue the discussion under the auspices of the working group. Would it be possible to call for adoption on our draft?
We have posted a new version last week with the changes around route servers. The latest version of our draft is here: https://datatracker.ietf.org/doc/draft-ramseyer-grow-peering-api/ API discovery through RSC is in discussion now: https://github.com/bgp/draft-ietf-peering-api/pull/30 Thank you, Jenny (with Arturo, Carlos, Matt, and Tom) From: Christopher Morrow <[email protected]> Date: Saturday, October 12, 2024 at 12:41 PM To: Tim Bruijnzeels <[email protected]> Cc: Q Misell <[email protected]>, [email protected] <[email protected]>, [email protected] <[email protected]> Subject: [GROW] Re: [Sidrops] Peering API Discovery On Sat, Oct 12, 2024 at 10:06 AM Tim Bruijnzeels <[email protected]> wrote: > > Hi Chris, > > > On 9 Oct 2024, at 10:10, Christopher Morrow <[email protected]> > > wrote: > > > > howdy authors/readers/suggesters/improvers! > > I happened to run into Arturo and he asked what was the WG side status > > for this document/work... > > > > It looks like some churn happened here on authen methods and possibly > > progress :) > > Should we WG Adopt this draft soon? (like call now, end prior to > > Face-2-Face in Dublin?) > > Which draft and which working group (since you are co-chair for both)? HAHAAH :( ouch, I mean the Peering automation draft actually. (apologies for my imprecision!) I think if the related RPKI draft gets into shape we should probably ALSO (in sidrops) ask for adoption there. I suppose the actual process here is: "Grow has this great draft: <peering automation draft link> which appears to need some 'better' authentication capabilities. Those 'better authentication capabilities' could be RPKI? it could be validated human-to-human handshakes... GROW folk believe the RPKI path is useful he SIDROPS does this pass the sniff test? can we talk about this in <draft q rpki draft> ?" Some of this discussion happened in this thread, but a bit more formally seems fine too. > To be clear I think: > draft-ramseyer-grow-peering-api > draft-misell-grow-rpki-peering-api-discovery > > Should both be adopted and discussed further. ok thanks! > > Based on the "author-wg” names both seem to target grow. I think that makes > perfect sense for the first. The api-discovery document has a lot more > "hard-core” RPKI content: i.e. new object type that would have to be > published in the RPKI repository, etc. So, it might make more sense to > discuss that one in sidrops with input from grow (is the right holder signing > the right information needed?), rather than the other way around. > seems good. I think this is part of the: "Hey we want this other new auth thingy, SIDROPS can we do that?" > Tim > > > > > > > > On Fri, Aug 23, 2024 at 10:46 AM Tim Bruijnzeels <[email protected]> > > wrote: > >> > >> Hi Q, all, > >> > >>> On 16 Aug 2024, at 11:11, Q Misell <[email protected]> wrote: > >>> > >>>> But it’s still not clear to me what the challenge would look like. > >>> > >>> It might help to look over my attempt at defining this in my PR: > >>> https://github.com/bgp/draft-ietf-peering-api/pull/30 > >>> > >> > >> At a glance… yes something like this would help to make it more clear. > >> > >> As for the proposed mechanism - I don’t get the full picture yet, and have > >> not had the time to really dive into it. Generally speaking I think it may > >> also > >> need an RSC signed by the server to prove its holdership of its ASN. And > >> you probably need to allow for some time to get an RSC signed by an RPKI > >> CA (i.e. perhaps don’t expect synchronous signing). Furthermore, you > >> likely want to use RSCs for an initial handshake only but use some other > >> token later (but I think this is what OAuth2 will do anyway). > >> > >> More importantly though, rather than wanting to express a strong opinion > >> at this point about *how* this should work, I think it’s important *that* > >> this > >> is specified clearly. Yes, I can wait for a future version of the document > >> :) > >> > >> Tim > >> > >> _______________________________________________ > >> Sidrops 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]
_______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
