Hi Steve, Stephen Kent wrote: > 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. If I understand correctly, you refer to multi-homed end-users here. In our region such users normally receive a provider-independent (PI) address space from RIPE NCC directly, so they will have their own CA and will have to maintain it.
However, there are also many end-users with provider-aggregatable address space that they received from LIRs. And this is where I find it quite difficult to continue with estimations, because - these end-users could still be multi-homed - or they might need to have own CAs for some other reason - their LIRs might prefer to give them responsibility for their CA - or prefer to not give them that responsibility >From my perspective I do not know any source of data to collect/guess the >number of end-users who will need their own CA, or the number of LIRs who would prefer to delegate CAs to their clients. I think LIRs / operators might know better. This is what I said in my previous email. -- Oleg Muravskiy RIPE NCC _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
