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