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]
