Hi all, While I support the intent of the proposal, I can’t support it in the current stage. Let me explain all the points:
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. 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. 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. 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*. 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). 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.* All those changes, will allow the IPv6 policy to be consistent *without artificial restrictions* with RFC9762. 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. 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! Regards, Jordi @jordipalet > El 3 abr 2026, a las 13:48, Tobias Fiebig via address-policy-wg > <[email protected]> escribió: > > Dear Colleagues, >> Version 2 of RIPE policy proposal 2024-01 "Revised IPv6 PI Assignment >> Policy" is now available for discussion again. >> >> The proposers and the APWG Chairs decided to open a new Discussion >> Phase because of the limited feedback received in the previous one. > > Thank you again for re-opening the discussion phase. > > I would like to use this opportunity to encourage those who already > voiced their support before the discussion phase to do so again, so it > is formally voiced during the discussion phase and in compliance with > the PDP. > > I am also reaching out to several people who already voiced their > support for an earlier revision, or who had strong opinions otherwise, > to do the same, i.e., read the new version of the document and share > their thoughts. > > (I am adding those colleagues into Bcc: to not clutter the headers.) > > With best regards, > Tobias > > -- > Dr.-Ing. Tobias Fiebig > T +31 616 80 98 99 > M [email protected] > Pronouns: he/him/his > ----- > 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/ ********************************************** 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.
----- 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/
