This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[routing-wg] Publish in Parent - input requested
- Previous message (by thread): [routing-wg] Publish in Parent - input requested
- Next message (by thread): [routing-wg] [EXTERNAL] Publish in Parent - input requested
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Jay Borkenhagen
jayb at braeburn.org
Fri Sep 30 03:14:19 CEST 2022
Erik Bais writes: > We worked for years with irrdb’s like radb that would accept everything from everywhere .. I hoped we learned something from that mess at the design table .. > > So again, not excluding anyone .. just push the stuff where it belongs … > Again, RPKI != IRR. In RPKI, if one publishes records that do not have in place the requisite chains of certificates, etc., from the root(s) to the INR, the records will not validate, and the rest of the world will know not to use them. RPKI achieves this by virtue of the contents of the records themselves -- it does not rely at all on knowing who operates the publication point where the records were found. The term "Publish in Parent" is an inexact term, so let's not read too much into it. I doubt any RIR would extend such a service to a party having no INRs from that RIR, so in that regard it _is_ "Publish in Parent", but extrapolating that the name requires that INRs from only this RIR are eligible is a taking things too far. Think of it this way: as part of performing their RPKI duties, RIRs must (a) produce RPKI objects, and (b) make those RPKI objects available at any time to relying parties all around the world. RIRs can delegate the generation of certain objects to their children, but they can also offer to publish the RPKI objects generated by those children using the RIR's maximally-available publication infrastructure -- regardless of the contents of those records. It would actually be more work for an RIR to filter out any records provided by their children having to do with INRs coming from other RIRs, than it would be to accept all records the child provides. There need not be a direct relationship between the INRs issued by an RIR and the RPKI records found at their "Publish in Parent" repository. Please do not impose one. Thanks. Jay B. PS: Watch RP logs for a while, and you'll soon grow disappointed by the number of delegated CAs -- those who attempt to publish their own records -- that are not as reachable as they should be. It would be far better for most folks to publish their records using a professionally-operated publication service. Let's not make things any more difficult for delegated CAs to use well-run publication points being offered by folks like the RIPE NCC.
- Previous message (by thread): [routing-wg] Publish in Parent - input requested
- Next message (by thread): [routing-wg] [EXTERNAL] Publish in Parent - input requested
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]