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.
--
To unsubscribe from this mailing list, get a password reminder, or change your
subscription options, please visit:
https://lists.ripe.net/mailman/listinfo/routing-wg
