Hello Tore, Radu and all,
Tore’s understanding of the two scenarios is correct.
The main difference is that in the first scenario, organisation A
submits a single request, allowing us to perform the entire evaluation,
including all necessary due diligence checks, in one go.
In the second scenario, organisation B would send us three separate
requests, requiring us to perform due diligence and evaluations three
times. While your hypothetical scenario suggests the requests might
arrive on three consecutive days, in reality, they typically come in
more sporadically. But regardless of the time between submissions, all
checks will need to be performed for each request.
Additionally, in the first scenario, the request might initially be for
a /46. After our evaluation, we would need to explain why several /48
assignments will be issued instead, which is one of the issues this
policy proposal aims to address.
As for your comments on the yearly recurring fee, I believe this topic
is less related to this policy proposal and more relevant to the ongoing
work of the Charging Scheme Task Force, which aims to define the
principles of a future Charging Scheme. The discussions on this proposal
have been brought to the attention of the task force, and their work
will be communicated to the membership as it progresses.
Regarding Radu’s questions about the numbers, I can clarify that all
requests for multiple /48s are for different end sites of the same
organisation. If a request would justify the need for more /64 subnets
at a single end site than could fit in one /48, the RIPE NCC would issue
a single prefix that provides sufficient space for that end site.
I hope this answers your questions.
Kind regards,
Marco Schmidt
Manager Registration Services
RIPE NCC
On 02/09/2024 09:28, Tore Anderson wrote:
* Marco Schmidt
The RIPE NCC has always charged an assignment for any that is made in
a single day. The idea here is not to negatively affect anyone for a
decision made by the RIPE NCC or for other factors that might result
in them receiving multiple prefixes based on a single request.
For example, if somebody asks for a /44 IPv6 PI (equals 16x /48) but
only qualifies for 5 /48's - it wouldn't be fair to charge them five
times more than for one single block. Similarly, if somebody
transfers part of their IPv4 PI, maybe a /24 out of a /22, this will
leave them with two prefixes (/23 and /24) and potentially a double
charge. Of course, guidance on how we interpret policy is always
welcome from the community.
Hi Marco,
So let me see if I understand correctly:
Assume organisation A requested and received, say, three separate /48
assignments to be used in three different sites on the same day / in
the same ticket, then they will only pay a single PI fee annually in
perpetuity?
At the same time, assume organisation B also requested and received
three separate /48s to be used in three different sites, but did so in
three different tickets submitted over three consecutive days, then
they will need to pay three PI fees annually in perpetuity?
To be clear I am not talking about a single /46 assignment for a
single gigantic site (or collection of sites with uniform routing
requirements) here, but three distinct /48s given to be used in
different sites with different routing requirements.
It is also worth noting that handling End Users for PI assignments
and ASNs is an ongoing workload when it comes to keeping the Registry
up to date and also with regards to sanctions.
Certainly, and I bet that is one of the reasons for having an annual
fee in the first place. However I do not see how this could explain
the different treatment between organisation A and B above.
I could see the rationale for giving A a one-time discount on the act
of issuing the PI prefixes themselves (assuming there is a one-time
charge for that), but I don't think I can see any reason to give
organisation A a discount on the yearly recurring fees in perpetuity.
The on-going maintenance for A and B's prefixes in the years following
their issuance should after all be identical, and both A and B ought
to have the same economic incentives to return any prefixes that fall
into disuse.
Tore
-----
To unsubscribe from this mailing list or change your subscription options,
please visit:
https://mailman.ripe.net/mailman3/lists/address-policy-wg.ripe.net/
As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings.
More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
