On Thu, Aug 15, 2024 at 02:28:46PM +0200, Tim Bruijnzeels wrote: > 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.
RSC can be used in a challenge/response process between two parties to verify authority over an internet resource. This is exactly what the Peering API needs. > 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. Do you think yet another OID and yet another object type will somehow resolve any self-imagined legal concerns? :-) I don't think that starting from scratch (rather than using existing & implemented technology) would help overcome potential future legal concerns. Kind regards, Job _______________________________________________ GROW mailing list -- grow@ietf.org To unsubscribe send an email to grow-le...@ietf.org
