Hi all,
In this second email, I will take most of the questions I identified in
the directionz thread and we can take it from here:
1- Whether the RIRs are willing to "back up on this"
--
Depending on what is meant by 'this'. If 'this' refers to 'back up on
the whole 0/0 idea', I of course cannot provide an absolute answer, but
I don't think the RIRs are willing to do that just now.
However, we don't necessarily see 0/0 as a permanent state, just as the
previous one wasn't.
If 'this' refers to WG adoption, definitely. If the WG doesn't want the
document, then we are fine with that. We will probably pursue an
independent submission since we believe that it’s important that this
gets documented within the IETF.
2. Regarding how the top levels of the cert tree will look like (Roque)
--
Roque asks whether there will be a 2nd level certificate that will list
the resources each RIR has, in the same way as today's top level
certificates do.
Short answer: it will be RIR-dependent.
A bit longish answer:
In our case (LACNIC), we will probably do what you've described, but
just because that is the simplest thing for us to do. However, bear in
mind we don't have inter-RIR transfer policies that apply to us, and if
such a policy gets approved we will probably review this decision.
If there is a need to have a way to list what an RIR's holdings are,
there are ways to do that which do not involve RPKI. In fact, RPKI certs
are not authoritative as of today. They are fed from other systems that
are authoritative; systems that also feed the logic that generates the
'delegated-extended-stats' files. Regarding listing resources, these
files are just as authoritative as the RPKI certs are.
An RIR's holdings can be easily aggregated up by looping through the
delegated-extended files. If there is a community need that the RIRs
publish a file stating which our holdings are, we are open to talk about
it.
Again, thanks for all your feedback.
-Carlos
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
