[sig-policy] Re: prop-154-v001: Resizing of IPv4 assignment for the IXPs

> On Dec 20, 2023, at 17:03, Luke Thompson wrote: > > The logic on both sides seems valid to me. I think ultimately it's about > supporting the demise of v4 (in that, the rise of efficient smaller > operators). > I’ll slightly disagree here… The demise of v4 is best resolved by v6, not by

[sig-policy] Re: New proposal: prop-158-v001: IPv6 auto-allocation for each IPv4 request

This proposal is yet another gift from the bad idea fairy… Wait… It’s actually a regift from someone else who got it from the bad idea fairy on its last go-around. While I’m all for reuse and recycling, this one needs to go to the landfill. It was a bad idea the first several times it was

[sig-policy] Re: New proposal - prop-157-v001: Temporary IPv4 Transfers

I would think that in any case where there is a (valid and verified) request which cannot be fulfilled otherwise, but could be fulfilled by early termination of the quarantine period that APNIC should contact the requestor and offer them the option of accepting the space in that condition. Once

[sig-policy] Re: prop-154-v001: Resizing of IPv4 assignment for the IXPs

> On Dec 20, 2023, at 16:33, Christopher Hawker wrote: > >> Longer prefixes are misguided for a number of reasons, but I was’t referring >> to that. >> I was calling the idea of deluding ourselves into believing that the useful >> lifetime of IPv4 can be extended by these ever increasing

[sig-policy] Re: prop-154-v001: Resizing of IPv4 assignment for the IXPs

> On Dec 20, 2023, at 03:40, Christopher Hawker wrote: > >>> My problem still lies with the community not accepting prefixes longer than >>> a /24 for global routability. We can't prevent IXPs with prefixes longer >>> than a /24 from routing their prefixes, when those with shorter than or

[sig-policy] Re: prop-154-v001: Resizing of IPv4 assignment for the IXPs

>> RIRs should not be in the business of dictating routing policy to anyone. > > Well yes, that is commonly said and sometimes too generically, but as the > entity responsible for setting the rules for IP assignment there may be any > necessary usage restriction for that type of assignment if

[sig-policy] Re: prop-154-v001: Resizing of IPv4 assignment for the IXPs

> My problem still lies with the community not accepting prefixes longer than a > /24 for global routability. We can't prevent IXPs with prefixes longer than a > /24 from routing their prefixes, when those with shorter than or equal to a > /24 can. It's either all can, or none can. My problem

[sig-policy] Re: prop-154-v001: Resizing of IPv4 assignment for the IXPs

> On Dec 18, 2023, at 11:06, Fernando Frediani wrote: > > Hello > > On 11/12/2023 09:38, Christopher Hawker wrote: >> >> >> 1. If a current IXP applies for space under this policy, they should be >> restricted from transferring new or existing delegations under any transfer >> conditions

[sig-policy] Re: New version: prop-154: Resizing of IPv4 assignment for the IXPs

I remain opposed to this proposal. It is an unnecessary and pointless rearranging of deck chairs with zero benefit to the community. When we run out of /24s to give to new IXs, It is utterly harmless for IXs to become IPv6 only fabrics. IPv4 NRLI can be exchanged over IPv6 peering sessions with

[sig-policy] Re: New version: prop-148 - Clarification: Leasing of Resources is not Acceptable

> 3. Situation in other regions > - > In other RIRs, the leasing of addresses is not authorized either and > since it is not explicit in their policy manuals either, this proposal > will be presented as well. This simply isn’t the fact. In ARIN, Leasing is not

[sig-policy] Re: New version: prop-148 Clarification - Leasing of Resources is not Acceptable

The vast majority of representatives in various countries are not actually elected by majorities… Usually they are elected by mere pluralities. Owen > On Sep 2, 2023, at 03:38, jordi.palet--- via SIG-policy > wrote: > > Laws aren’t ONLY made by means of elected representatives of majority

[sig-policy] Re: New version: prop-148 Clarification - Leasing of Resources is not Acceptable

> On Sep 2, 2023, at 03:36, Lu Heng wrote: > > When PDP have such vast impact on the internet, such model will not work > well, a good example here is you being a good person, but hugely disconnected > from the real will of the community. > > And I understand how things started, it make

[sig-policy] Re: New version: prop-148 Clarification - Leasing of Resources is not Acceptable

First of all, RIRs don’t convey usage rights. They convey unique registrations. Now the vast majority of (virtually all) ISPs (fortunately) choose to cooperate with the existing registry system, so that the unique registrations in that registry system are roughly equivalent to a right to use,

[sig-policy] Re: New version: prop-148 Clarification - Leasing of Resources is not Acceptable

> On Aug 31, 2023, at 22:26, Noah wrote: > > > > On Thu, 31 Aug 2023, 07:29 Sanjeev Gupta, > wrote: >> >> >> > If the leasing of addresses is authorized, contrary to the original >> spirit of the policies and the very existence of the RIRs, the link >> between

[sig-policy] Re: Prop-152-v001: Reduce the IPv4 delegation from /23 to /24

That makes little to no sense. All that will accomplish is increasing the unused addresses held by those that don’t need them while limiting the ability of those that need addresses to acquire them from those that have them available. I’m not one for abandoning needs-basis, nor am I in favor of

[sig-policy] Re: prop-155-v001: IPv6 PI assignment for associate members

In my opinion, any special restrictions on transfers should be removed from the proposal. Transfer or not of IPv6 space is an independent policy matter and there is no need for any special provisions in this proposal. Owen > On Aug 22, 2023, at 05:04, Srinivas (Sunny) Chendi wrote: > >

[sig-policy] Re: New version: prop-148 Clarification - Leasing of Resources is not Acceptable

and their providers.Owen, it's not leasing. Its assignment since an LIR is mandated to do so to end users.Cheers,./noahOn Sun, Aug 13, 2023 at 8:10 AM Owen DeLong via SIG-policy <sig-policy@lists.apnic.net> wrote:There are many customers that have a /24 or more leased from their provider. Cl

[sig-policy] Re: New version: prop-148 Clarification - Leasing of Resources is not Acceptable

There are many customers that have a /24 or more leased from their provider. Claiming that anyone needing a /24 or shorter prefix must go to an RIR or the market is current reality, but not historically true. Lots of older provider assignments of /24 and shorter prefixes exist in the wild and

[sig-policy] Re: prop-154-v001: Resizing of IPv4 assignment for the IXPs

Renumbering an enterprise is hard. Renumbering an IXP even a large one is relatively simple and has been done multiple times. I still don’t support the proposal, but I think that the “renumbering is hard” argument rings a bit hollow when it comes to IXPs. The process boils down to: 1.

[sig-policy] Re: prop-154-v001: Resizing of IPv4 assignment for the IXPs

> >> The providers on the exchange points can still exchange IPv4 NLRI via IPv6 >> peering sessions and forward IPv4 data grams to the correct MAC next-hop >> learned via IPv6 ND. >> >> This is already in widespread use. It’s a bit hacking, but it works and >> doesn’t require additional

[sig-policy] Re: prop-154-v001: Resizing of IPv4 assignment for the IXPs

Oppose. Rearranging deck chairs to smaller ixp prefixes is a step away from goodness. I do support removing the /23 cap for IXPs that demonstrate need for shorter prefixes. I do not support RIR assignments or allocations longer than /24 in IPv4 or /48 in IPv6. When we run out, IXPs can move to

[sig-policy] Re: New version: prop-148 Clarification - Leasing of Resources is not Acceptable

As written, this policy is absurd. Virtually all internet numbers in use are leased by the providers that they are registered to. The question here is whether or not to require that connectivity services be provided as part of the lease arrangement. I’m OK with whatever the community decides

[sig-policy] Re: prop-147-v003: Historical Resources Management

In use != Announced. There are many uses for IP addresses (including legitimate uses of GUA) that don’t make their way into any routing table you can see. Owen > On Jan 26, 2023, at 22:06, Rajesh Panwala wrote: > > Hello Sunny and Team, > > Is there any routing table analysis available,

[sig-policy] Re: New version: prop-150: ROA/whois object with Private,,Reserved and Unallocated (reserved/available) Origin ASN

I think the problem is overstated in that a ROA authorizing origination from an unallocated ASN is not necessarily a security risk. Personally, I don’t see significant benefit to this proposal. I think guidelines are sufficient. People who wish to violate the guidelines, well, to quote Mr.

[sig-policy] Re: SIG elections changes proposal

Correct me if I’m wrong, but doesn’t conference registration usually open some time prior to the start of the conference? Suggest amending 3.4.3(1) to read as follows: 1. Registered and attending the current conference in person. The attendee must be checked-in at the on-site registration desk

[sig-policy] Re: prop-147-v003: Historical Resources Management

RIPE does have specified processes for dealing with Legacy resources without contract. So neither the first half nor the second half holds true. Also, AFRINIC preserves legacy status across transfers IIRC. Owen > On Jan 20, 2023, at 15:40, Owen DeLong via sig-policy > wrote: >

[sig-policy] Re: prop-147-v003: Historical Resources Management

> > 3. Situation in other regions > - > In other RIRs legacy resources lose their legacy status when the RSA is > signed (upon receiving other resources), so they become under the regular > monitoring. In other cases, there is nothing specified by policies. This

[sig-policy] Re: Sec 4.2.1 - Recovery of Unused Historical Resources

I will point out that unannounced != unused. There are plenty of legitimate cases for needing globally unique addresses that are not necessarily announced in the global routing table. Exchange points are one example. Private networks that interact with multiple internet-connected networks is