Thank you, Christopher, Q, for your messages! As authors, we would be happy with a call for adoption.
There are some minor revisions to the draft that we would like to post in the next week or two, but if those can happen in parallel with the adoption, then we are very happy to go ahead. I believe the outstanding revisions are: * Add a reference to Q’s RPKI discovery draft * Add an additional field to the section on route servers. We will try to post the new version next week. If that could happen in parallel with adoption, we’d be delighted. Thanks, Jenny (and co-authors Tom, Carlos, Matt, Arturo) From: Q Misell <[email protected]> Date: Friday, October 11, 2024 at 7:26 AM To: Christopher Morrow <[email protected]> Cc: [email protected] <[email protected]>, [email protected] <[email protected]> Subject: [GROW] Re: [Sidrops] Re: Peering API Discovery Moin Christopher! My reading of the room in Vancouver was that there was broad support for the peering API draft, and I think it's probably time we adopt it. As for the RPKI discovery draft I'd like to hear other people's opinions, Moin Christopher! My reading of the room in Vancouver was that there was broad support for the peering API draft, and I think it's probably time we adopt it. As for the RPKI discovery draft I'd like to hear other people's opinions, but I think it was agreed that we need some form of standardised discovery - and that RPKI is the way to go about it. @chairs: what are your thoughts, and if you feel it appropriate can you arrange an adoption call? Q ________________________________ Any statements contained in this email are personal to the author and are not necessarily the statements of the company unless specifically stated. AS207960 Cyfyngedig, having a registered office at 13 Pen-y-lan Terrace, Caerdydd, Cymru, CF23 9EU, trading as Glauca Digital, is a company registered in Wales under № 12417574<https://urldefense.com/v3/__https:/find-and-update.company-information.service.gov.uk/company/12417574__;!!Bt8RZUm9aw!4mkiQRBZ6nufrrmO1jivgz7coIQjqo0-IzkC8j-SQUJ8scQqOqJTvaq9NfdU5KfZhpYRB-bgv6zv4-NKshGbUMA-Ep_D$>, LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876<https://urldefense.com/v3/__https:/ico.org.uk/ESDWebPages/Entry/ZA782876__;!!Bt8RZUm9aw!4mkiQRBZ6nufrrmO1jivgz7coIQjqo0-IzkC8j-SQUJ8scQqOqJTvaq9NfdU5KfZhpYRB-bgv6zv4-NKshGbUJfuHzKf$>. UK VAT №: GB378323867. EU VAT №: EU372013983. Turkish VAT №: 0861333524. South Korean VAT №: 522-80-03080. AS207960 Ewrop OÜ, having a registered office at Lääne-Viru maakond, Tapa vald, Porkuni küla, Lossi tn 1, 46001, trading as Glauca Digital, is a company registered in Estonia under № 16755226. Estonian VAT №: EE102625532. Glauca Digital and the Glauca logo are registered trademarks in the UK, under № UK00003718474 and № UK00003718468, respectively. On Wed, 9 Oct 2024 at 10:10, Christopher Morrow <[email protected]<mailto:[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?) On Fri, Aug 23, 2024 at 10:46 AM Tim Bruijnzeels <[email protected]<mailto:[email protected]>> wrote: > > Hi Q, all, > > > On 16 Aug 2024, at 11:11, Q Misell > > <[email protected]<mailto:[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]<mailto:[email protected]> > To unsubscribe send an email to > [email protected]<mailto:[email protected]>
_______________________________________________ GROW mailing list -- [email protected] To unsubscribe send an email to [email protected]
