On Thu, Nov 14, 2024 at 1:29 PM Jenny Ramseyer <[email protected]> wrote: > > 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? > >
Thanks for calling! I think 'yes' :) > 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]
