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. > 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. > 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. 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. > 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. > 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. 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. > 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. > 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 [email protected] ----- 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/
