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?) 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]
