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://find-and-update.company-information.service.gov.uk/company/12417574>, LEI 875500FXNCJPAPF3PD10. ICO register №: ZA782876 <https://ico.org.uk/ESDWebPages/Entry/ZA782876>. 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]> 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]> > 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]
