Hi Q, I have some comments, orthogonal to Job’s comments, so let me reply to the thread root…
1. One object, one ASN, one URI? The object defines a single ASN and a single URI. However, there is no way to prevent that CAs publish multiple PAD objects for the same ASN, or that a parent CA publishes such an object for an ASN that is delegated to a child CA. Some text to RECOMMEND that only one object is created may help, but there is no way to prevent this, and these objects would all be equally valid, so a validator can’t really choose between them. In other words, you should probably be prepared to deal with having >1 URIs per ASN and you may want to have text to deal with this. Just try them all? 2. Other people’s URIs? Question, after only glancing at draft-ramseyer-grow-peering-api. Is there a risk or danger when the wrong URI is listed, maliciously or not? I expect that this isn’t an issue, but it may be worth saying so explicitly. 3. Peering-API proof of holdership - dedicated RPKI object type? Out-of-scope for discovery, but since I stumbled upon this here I wanted to ask about this here. It is unclear to me how section 9.3 of draft-ramseyer-grow-peering-api intends to use RPKI Signed Checklists (RSC) to prove authority for an ASN. I think it would be beneficial to have a dedicated RPKI object for this instead of using RSC (even if the object is exchanged directly rather than published in the RPKI repository). It would remove the uncertainty around how this authorization works. Furthermore, while RSC signing is easy to implement on a technical level, there are possible legal concerns around allowing any authorized user to make statements for resources outside of the context of routing (liability, terms and conditions, user authorization). Speaking as Principal Engineer / Product Owner RPKI at RIPE NCC I feel that dedicated objects with a clearly defined routing related context are much easier to understand and support in that regard. Kind regards Tim > On 31 Jul 2024, at 13:08, Q Misell <q=40as207960....@dmarc.ietf.org> wrote: > > Moin, > > Following on from a discussion I had with Jenny and Job on discovery for > peering APIs using the RPKI I've posted > draft-misell-grow-rpki-peering-api-discovery as a first attempt at defining > how this would be done within the RPKI. I'm unsure if this document fits > better in the grow or sidrops (CCed) WG, but I've tentatively associated it > with grow as that's where the peering API draft is. > > Looking forward to hearing all your comments! > 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, LEI 875500FXNCJPAPF3PD10. ICO register №: > 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. > _______________________________________________ > Sidrops mailing list -- sidr...@ietf.org > To unsubscribe send an email to sidrops-le...@ietf.org _______________________________________________ GROW mailing list -- grow@ietf.org To unsubscribe send an email to grow-le...@ietf.org
