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 _______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
