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)? To be clear I think: draft-ramseyer-grow-peering-api draft-misell-grow-rpki-peering-api-discovery Should both be adopted and discussed further. 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. 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]
