Oleg,
No. You broke the line in the wrong place. I meant "many (NIRs or LIRs)".
In your text the "many" is distributed over both terms, NIRs and LIRs.
You should have just omitted NIRs,
since there are not "many" of them .
Not necessarily. The LIR could create a ROA for client's assignment,
using LIR's allocation certificate. I'm not saying they should do it
like this, but they could. And I have a feeling that might become a
common case. But I think LIRs could say for themselves. For example,
how many their clients maintain Whois objects themselves, and for how
many LIRs doing it?
I agree that an LIR could behave the way you indicated, but in so doing
it needs to track which
other LIRs provide service to the customer in question, in order to
generate ROAs for each of them. If
it fails to do so, any connections to other LIRs may be ignored, as the
NLRI in question will be
represented by a valid ROA pointing to another AS#. That might create a
liability for the LIR. That's why
Section 7.3.2 of RFC 6480 cites this as the least desirable option.
The question is who runs that CA, and whether the CA's pub point lives in a
different repository.
I find it difficult to estimate how many LIRs will do this, and for how many of
their clients. But for RIPE NCC I could see that
the number of organisation objects in RIPE DB is 70746, and that should be the
upper bound of the number of CAs in our region. I
don't have that number for other regions, and don't know if it's applicable in
the same way, especially where NIRs are present.
NIRs are probably not relevant in this counting approach.
My point was that it's quite difficult to estimate the upper bound of possible
CAs. NIR or LIR does not matter, I agree.
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
