Hi Tobias, Some responses below, in-line. Saludos, Jordi @jordipalet
El 7 abr 2026, a las 14:05, Tobias Fiebig <tobias@fiebig.nl> escribió:
Hello Jordi,
Thank you for reaching out. Please let me respond to individual points below.
1) Length of the assignment. Why, again we want to restrict it? If I get a PI, it may be perfectly valid that I sub-assign /52 instead of /56. It is an operational decision/need what is the size of the prefix sub-assigned.
As you may have noticed, 2024-01 has been going on for a bit, and there were a lot of discussions on the text. An earlier revision of the proposal actually limited this to /49 and more specific, i.e., anything that is not announcable. The current state is a /64. However, this drags the tail of the end-site definition with it, which was removed from 2024-01 to make the proposal more digestible.
Hence, to make the actual change in this revision smaller, the idea was to only expand to a /56, as this is another common size in PD.
The point to understand is that this community is not making standards at IETF, which is the right place. The IETF did a standard that doesn’t put a limit like /56. Consequently if anyone in this community wants to change that, must address it at the right venue: the IETF. Note also that this limitation places RIPE “below" what other RIRs already had (allowing prefixes without any limit of size, not just addresses). In other words, our work here must be coherent and fully respecting the IETF standards. In the end, we are several organizations working together: RIRs, IETF, other standard bodies, ICANN, etc. and each one has its own limits and must not step in the job of others or alter or limit that. Otherwise, we can have weird several situations: 1) Tomorrow, at Routing WG or DNS WG, or others, we can alter the IETF standards by limiting them artificially. Clearly, not right. 2) IETF could approve an RFC that step in the work that we do by means of policies.
So my proposal is:
Actual:
Providing connectivity to another entity inside the assignment holder’s network, at the same geographical End Site, with a prefix size of /56 or longer from the assignment, is not considered a sub- assignment.
Proposal: Providing connectivity to another entity inside the assignment holder’s network, at the same geographical End Site, *regardless of the prefix length*, is not considered a sub-assignment.
With the proposal passing, though, it would be up to the community, to propose further relaxing this requirement, e.g., as you proposed. I would suggest submitting the change you are suggesting there as a dedicated proposal after 2024-01 has been implemented.
We have been there already. One proposal after other after other, changing the same, doesn’t work, and even chairs reject them (which I think is beyond their authority/PDP, but that’s a different discussion). As said, this community can’t limit what standards don’t limit.
2) Reasons for the assignment. Why we want to make it, again, restrictive? Any operational need must be valid. Removing the wording “for example” limits whatever is not specifically worded out. Also we are making, in my opinion, the text longer, without adding extra value. Also instead of static (to avoid confusion with dynamic - DHCP), I will suggest to use persistent, as described in BCOP690.
Actual:
This includes letting visitors connect to the assignment holder's network, providing static addresses when connecting a server or appliance to the assignment holder's network, providing a single service with multiple addresses, or using a /64 or longer when setting up point-to-point links with other ISPs for the purpose of exchanging traffic and Internet routing information
Proposal:
This includes *for example* letting visitors connect to the assignment holder's network, providing *persistent* addresses *or prefixes* for *devices, applications, services or point-to-point links* or other operational needs.
First of all, I believe that the use of persistent vs. static is an editorial issue, and I am very much open to align with BCOP690 there.
Yes, this is editorial, we can change it without a big discussion, hopefully.
Beyond that, the section carries the implications of using PI for PA reserved purposes, which is a major concern from the NCC side, as well as several members of the community. Again, as the end-site revisions were removed from the text, this part is also kept more slim. As before, I would suggest implementing the proposed change in a dedicated policy proposal.
As said before, a proposal after another after another, doesn’t work. We must fix it in a single step. Not wait years for it.
3) Why we want to limit the planning of an organization to 24 months? Several years ago already decided that the address planning depends on each organization, each business plan. Some organizations may plan for just 1 year, others for 5 years. We have this very clear text in 5.1.2 “… the segmentation of infrastructure for security and the planned longevity of the allocation.” PI must allow the same, no difference. By the way, I’m not sure about the “–“ must be finished with another “–“ at some point in the sentence (I think so), as it is not clear to me if the sentence should be read as “everything is part of the example” or the "within the next 24 months" is not part of the example.
Actual: … – for example, by documenting each End Site’s current and/or planned routing policies, or expected utilisation (see 2.7) within the next 24 months
Proposal: … – for example, by documenting each End Site’s current and/or planned routing policies, or expected utilisation (see 2.7) *– for the planned longevity of the allocation*.
The 24 months are, to the best of my knowledge, aligned with current procedures. Again, as before, a larger change should be implemented in a follow-up proposal, instead of expanding the scope of this document.
I’m not proposing to change the current practice, but to stick to the actual *existing* text.
4) Again, not sure if this is restrictive. If we allow an assignment /32, why not?, we may have an organization that prefers a PI instead of PA and is perfectly valid.
Actual:
To aid aggregation and reduce the need for renumbering in case of growth, justified assignments are to be made in nibble boundary steps (i.e. starting with /48, followed by /44, /40, and /36, in steps of 4 bits).
Proposal:
To aid aggregation and reduce the need for renumbering in case of growth, justified assignments are to be made in nibble boundary steps (i.e. starting with /48, followed by /44, /40, /36 *and so on*, in steps of 4 bits).
Again, this is the larger discussion about the purpose of PI/PA, and some members feeling that there should be a qualitative difference between PI and PA.
Unless I’m wrong, there is no text in the actual policy that limits a PI size. So why we want to limit it now?
Again, in the spirit of more restrictive changes in a single intervention, this point is being kept consciously restrained.
Also, again, as before, I would suggest bringing in this further change in a follow-up proposal, ensuring that the specific intent voiced can receive the necessary focus and attention from the community.
Repeating myself … proposal after a proposal …. doesn’t work.
5) Last, but not least, I think that if renumbering is needed as per 7.1.2,, 6 months may be too short, according to many previous discussions about that. I will suggest 12 or 24 months, or a text that allows an extension of the 6-months if justified.
Actual:
If the requested extension to the next nibble boundary cannot be made, the assignment holder may request a new Assignment as per "7.1.1. PI Assignment at the Nibble Boundary" and must return the previous assignment(s) within a six-month renumbering period.
Proposal:
If the requested extension to the next nibble boundary cannot be made, the assignment holder may request a new Assignment as per "7.1.1. PI Assignment at the Nibble Boundary" and must return the previous assignment(s) within a *twelve-month* renumbering period. *If justified to the RIPE NCC, this period could be extended.*
The six month renumbering period is a commonly used time-frame for renumbering within NCC policy documents. Again, as before, opening that box was considered outside the scope of the document. If there is a strong push to deviate from these numbers in either direction as highlighted by several members voicing it, that change could be easily considered, I believe.
Will not repeat myself, why we want to leave it for the future … doesn’t work.
Someone could say “let’s move on and later on we submit another proposal”, but this doesn’t work, specially if we can agree in small modifications now.
Your argument is circular. Either the modifications are small now, so it should not be an issue to have the, hence small, follow up proposal pass. Or the follow-up proposal would not work, because the changes are not that small. However, then it also would not make sense to now quickly slip them through here.
I’ve been there. Some years ago, when we had a policy proposal for “assign” and I said it was restrictive and no sense to allow only addresses, not prefixes, and look now is clear I was right. Also I was told “you send too many proposals, we already discussed this a few months ago with a previous proposal”, etc., etc. Let’s do the things as perfect as we can once!
I hear your concerns and appreciate you sharing your personal experiences with other policy proposals. I would, however, prefer to keep this discussion focused on 2024-01; And, in best engineering practice, I would deeply prefer following the small-badge-principle instead of trying to submit something--eventually, but likely never reaching the state--perfect once.
With best regards, Tobias
-- Univ.Prof. Dr.-Ing. Tobias Fiebig T +31 616 80 98 99 M tobias@fiebig.at
********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or confidential. The information is intended to be for the exclusive use of the individual(s) named above and further non-explicilty authorized disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited and will be considered a criminal offense. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, even if partially, including attached files, is strictly prohibited, will be considered a criminal offense, so you must reply to the original sender to inform about this communication and delete it.