Re: [sig-policy] Policy documentation feedback requested

* Sent by email to save paper. Print only if necessary. On 18/02/2014 12:26 am, Owen DeLong o...@delong.com wrote: I support option 2. It is hard enough trying to follow the regional policy differences as an international network. At least being able

Re: [sig-policy] Returned to SIG: prop-110: Designate 1.2.3.0/24 as Anycast to support DNS Infrastructure

On Mar 5, 2014, at 00:09 , Sanjeev Gupta sanj...@dcs1.biz wrote: On Wed, Mar 5, 2014 at 5:33 AM, Masato Yamanishi myama...@japan-telecom.com wrote: Is there anyone who want to continue this proposal? I read the Transcript, and saw the comment made on the inadvisability of 1.2.3.4/24

Re: [sig-policy] New version of prop-111: Request-based expansion of IPv6 default allocation size [SECURITY=UNCLASSIFIED]

On Sep 3, 2014, at 2:12 PM, Masato Yamanishi myama...@japan-telecom.com wrote: Hi Mike, Thank you for you comment and let me clarify your one point. On 2014/09/02 16:07, HENDERSON MICHAEL, MR michael.hender...@nzdf.mil.nz wrote: I do not favour IPv6 allocations on “non-nibble”

Re: [sig-policy] prop-111-v004: Request-based expansion of IPv6 default allocation size (SECURITY=UNCLASSIFIED)

, | elvis | | On 18/09/14 09:35, Owen DeLong wrote: | | Absolutely… That is current policy in the ARIN region and it is working | well. | | The reality is that the amount saved by doing non-nibble boundary | allocations is insignificant compared to the likely increase in human

Re: [sig-policy] [New Policy Proposal ] prop-112: On demand expansion of IPv6 address allocation size in legacy IPv6 space [SECURITY=UNCLASSIFIED]

] On Behalf Of Owen DeLong | Sent: Wednesday, 4 February 2015 4:05 p.m. | To: Masato Yamanishi | Cc: sig-policy@lists.apnic.net | Subject: Re: [sig-policy] [New Policy Proposal ] prop-112: On demand expansion of IPv6 address allocation size in legacy IPv6 space | | I will again oppose this as written

Re: [sig-policy] [New Policy Proposal ] prop-112: On demand expansion of IPv6 address allocation size in legacy IPv6 space [SECURITY=UNCLASSIFIED]

On Feb 3, 2015, at 8:12 PM, Robert Hudson hud...@gmail.com wrote: On 4 February 2015 at 14:54, Dean Pemberton d...@internetnz.net.nz mailto:d...@internetnz.net.nz wrote: There are a number of things that concern me about this proposal. 1) it doesn't appear to support needs based

Re: [sig-policy] [New Policy Proposal ] prop-112: On demand expansion of IPv6 address allocation size in legacy IPv6 space [SECURITY=UNCLASSIFIED]

On Feb 3, 2015, at 8:12 PM, Robert Hudson hud...@gmail.com mailto:hud...@gmail.com wrote: On 4 February 2015 at 14:54, Dean Pemberton d...@internetnz.net.nz mailto:d...@internetnz.net.nz wrote: There are a number of things that concern me about this proposal. 1) it doesn't appear to

Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria

I don't think your conclusion is supported by the statement from hostmaster... We don't know of anyone who hasn't reached out to us doesn't mean that nobody has reached out to them... It means that they are unaware. Asking the hostmasters about this issue in the way you did is akin to walking

Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria

On Fri, Feb 6, 2015 at 12:57 AM, Owen DeLong o...@delong.com wrote: I don't think your conclusion is supported by the statement from hostmaster... We don't know of anyone who hasn't reached out to us doesn't mean that nobody has reached out to them... It means that they are unaware. Asking

Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria

-policy-boun...@lists.apnic.net [mailto:sig-policy-boun...@lists.apnic.net] 代表 Owen DeLong 发送时间: 2015年2月27日 4:42 收件人: Mark Tinka 抄送: sig-policy@lists.apnic.net 主题: Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria In theory, this is why each RIR has

Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria

On Feb 27, 2015, at 01:43 , Izumi Okutani iz...@nic.ad.jp wrote: On 2015/02/27 17:58, Usman Latif wrote: I think organisations that have obtained portable address ranges from RIRs should have the liberty to use public ASNs from day one (if they want to) regardless of whether they are

Re: [sig-policy] New version of prop-114: Modification in the ASN eligibility criteria

Opposed as written. Vague wording which basically says that the secretariat can decide policy on a case-by-case basis is antithetical to an informed multi-stakeholder community consensus policy development process. Owen On Mar 4, 2015, at 00:02 , Masato Yamanishi myama...@gmail.com wrote:

Re: [sig-policy] New version of prop-113: Modification in the IPv4 eligibility criteria

+1… I’m with Dean… Still opposed. Let’s keep needs basis in place, please. I’m all for removing the requirement to multihome, but not the requirement to actually need the addresses for an operational network. Owen On Mar 4, 2015, at 16:09 , Dean Pemberton d...@internetnz.net.nz wrote:

Re: [sig-policy] New version of prop-114: Modification in the ASN eligibility criteria

http://linkedin.com/in/skeeve twitter.com/theispguy http://twitter.com/theispguy ; blog: www.theispguy.com http://www.theispguy.com/ IP Address Brokering - Introducing sellers and buyers On Thu, Mar 5, 2015 at 8:33 AM, Owen DeLong o...@delong.com mailto:o...@delong.com wrote: If said

Re: [sig-policy] New version of prop-113: Modification in the IPv4 eligibility criteria

; http://twitter.com/networkceoaulinkedin.com/in/skeeve http://linkedin.com/in/skeeve twitter.com/theispguy http://twitter.com/theispguy ; blog: www.theispguy.com http://www.theispguy.com/ IP Address Brokering - Introducing sellers and buyers On Thu, Mar 5, 2015 at 9:31 AM, Owen DeLong o

Re: [sig-policy] [New Policy Proposal] prop-113: Modification in the IPv4 eligibility criteria

Actually, after seeing the clarifications provided to Dean, I now oppose this proposal as written. Owen On Feb 23, 2015, at 10:21 , Masato Yamanishi myama...@gmail.com wrote: Dear Colleagues, Regarding prop-113, I saw 3 very simple support and 1 clarification without any negative

Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria

In theory, this is why each RIR has a public policy process open to any who choose to participate. The fact that operator participation in the process is limited (voluntarily by the operators themselves) continues to cause problems for operators. This not only affects RIRs, but also the IETF,

Re: [sig-policy] Requirements for Subsequent ASN Requests

Owen DeLong o...@delong.com mailto:o...@delong.com: Usman, since an AS is defined as “A collection of prefixes with a common routing policy”, what would you use one for if not to connect to other autonomous systems? If you are connecting to a single other autonomous system, then, arguably

Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria

On Feb 25, 2015, at 00:32 , Skeeve Stevens ske...@v4now.com wrote: Sorry Dean, I don't agree with you. You guys are trying to tell people how to run their networks, and that they aren't allowed to pre-emptively design their connectivity to allow for changing to multi-homing, or away

Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria

On Feb 25, 2015, at 15:10 , David Farmer far...@umn.edu wrote: On 2/25/15 15:44 , Dean Pemberton wrote: ... There is essentially no barrier to entry here. If a site needs an ASN they are able to receive one. If they want one 'just in case', then that is against current policy and I'm ok

Re: [sig-policy] Requirements for Subsequent ASN Requests

Usman, since an AS is defined as “A collection of prefixes with a common routing policy”, what would you use one for if not to connect to other autonomous systems? If you are connecting to a single other autonomous system, then, arguably it is impossible for your prefixes to have a distinct

Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria

On Feb 24, 2015, at 22:46 , Skeeve Stevens ske...@v4now.com wrote: To me, relaxing these rules is less about lying - although is easy, but it is to do with flexibility. I understand the routing policy wont be different that an upstream without being multi-homed, but it does curtail the

Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria

://twitter.com/theispguy ; blog: www.theispguy.com http://www.theispguy.com/ IP Address Brokering - Introducing sellers and buyers On Thu, Feb 26, 2015 at 8:03 AM, Owen DeLong o...@delong.com mailto:o...@delong.com wrote: On Feb 24, 2015, at 22:47 , Raphael Ho raphael...@ap.equinix.com

Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria

February 2015 7:02 AM To: Owen DeLong Cc: sig-policy@lists.apnic.net Subject: Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria Looks like a clarification on the definition of multi-homing from the secretariat is what we need before being able

Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN eligibility criteria

On Feb 24, 2015, at 22:47 , Raphael Ho raphael...@ap.equinix.com wrote: All, I¹m having an offline discussion with Aftab, basically the issue he¹s trying to address is that new ISPs in small countries/cities may not meet the day 1 requirements for an ASN, but however should be eligible

Re: [sig-policy] Requirements for Subsequent ASN Requests

that private AS may also work. So, what is the definition or understanding for unique routing policy in ARIN? Masato Yamanishi Feb 26, 2015 3:14 PM、Owen DeLong o...@delong.com mailto:o...@delong.com のメッセージ: Yes, I was well aware of that. Is there anything you believe to be incorrect in my

Re: [sig-policy] Idea for 1.2.3.0/24

down. Paul Paul Wilson, Director-General, APNICd...@apnic.net http://www.apnic.net@apnicdg On 22 May 2015, at 8:48 am, Owen DeLong o

Re: [sig-policy] Prop-115 returned to author for further consideration

I do not support the proposal. Contorting policy around the abomination that is CGN instead of recognizing that no amount of policy or other contortion will preserve usability in IPv4 and just getting on with the business of making IPv6 deployment ubiquitous is counterproductive for the

Re: [sig-policy] Final Comment Period for prop-114: Modification in the ASN eligibility criteria

I still oppose the policy due to lack of inclusion of the possibility of a non-multi-homed need based on a unique routing policy. Owen > On Sep 12, 2015, at 23:33 , Jahangir Hossain wrote: > > I support this proposal by adding multi-homed to be optional but organization

Re: [sig-policy] The status of APNIC's IPv4 resources

> On Sep 15, 2015, at 17:58 , Paul Wilson <pwil...@apnic.net> wrote: > > Thanks Owen. > > On 16 Sep 2015, at 10:00, Owen DeLong wrote: >> I fully support the plan George described. >> >> If George states that policy is useful in pursuing that plan, I

Re: [sig-policy] An interesting policy question

arning, read to > Owen, do not speculate people's action on public space without ground.l, > especially such action was already explained publicly. > > On 6 Dec 2015, at 5:06 AM, Owen DeLong <o...@delong.com > <mailto:o...@delong.com>> wrote: > >> Fair warn

Re: [sig-policy] An interesting policy question

Fair warning, Lu asked the identical question on the ARIN list and (I presume the RIPE list since he left RIPE in all the key places in the one he posted to ARIN). It seems to me that he may be doing some form of registry policy shopping. Owen > On Dec 4, 2015, at 06:07 , Skeeve Stevens

Re: [sig-policy] Prop-115 revised.

Sanjaya, I think that’s a fine idea. I don’t think that this is “too operational” for the main policy document so much as it’s simply not a matter of policy. Policy and the existing database already fully enable the practice outlined in the proposal. Therefore, there is no need for policy in

Re: [sig-policy] prop-118-v001: No need policy in APNIC region

I disagree… I believe that needs testing still preserves the idea of distributing addresses to those with need even in a post-exhaustion world. This serves to discourage speculative transactions and other transfers to those not actually needing addresses which would only drive prices up and

Re: [sig-policy] prop-119: Temporary transfers, to be discussed at APNIC 44 Polic y SIG

I oppose this policy. Any legitimate case for a “temporary transfer” that I can envision would be supported through SWIP from an LIR providing services. Otherwise, this amounts to a lease-style transaction which is most popular when related to activities that are generally considered harmful

Re: [sig-policy] prop-119: Temporary transfers, to be discussed at APNIC 44 Polic y SIG

> On Aug 18, 2017, at 2:38 AM, Lu Heng wrote: > > Hi Aftab: > > I believe your understanding of spammer operation is not at all based on > reality. Aftab’s description of spammer operations is very much based in reality. > Spammers merely need one to two-month

Re: [sig-policy] prop-123-v001: Modify 103/8 IPv4 transfer policy [SECURITY=UNCLASSIFIED]

I would argue that 257 probably represents a significant fraction of the distributed portion of 103/8. I would be interested if staff can answer what percentage of the issued 103/8 resources have been subject to one or more M transfers since issuance. I’d be especially interested in the number

Re: [sig-policy] prop-123-v001: Modify 103/8 IPv4 transfer policy [SECURITY=UNCLASSIFIED]

.com/profile/d54a9> ; Keybase: https://keybase.io/skeeve > <https://keybase.io/skeeve> > > Elastic Fabrics - Elastic Engineers - Elastic ISPs - Elastic Enterprises > > On Thu, Feb 1, 2018 at 4:00 AM, Owen DeLong <o...@delong.com > <mailto:o...@delong.com>&g

Re: [sig-policy] Prop124 version 4

Aside from the question of examples or not examples, I offer the following suggestion… The wording is quite awkward and difficult to parse. So much so, I am not 100% certain of the intent. I offer the following suggestion for a rewrite hoping that I have captured the intent accurately:

Re: [sig-policy] Prop124 version 4

ar policy that is understood by all who must live with and/or implement it. Owen > > Regards, > Jordi > > > > > > De: Owen DeLong mailto:o...@delong.com>> > Fecha: miércoles, 12 de septiembre de 2018, 4:17 > Para: JORDI PALET MARTINEZ

Re: [sig-policy] Prop124 version 4

h as broadband services, is still considered a sub-assignment.” > > We want to make sure that ISPs, typically offering broadband services, aren’t > end-users, as they should be LIRs. > > Regards, > Jordi > > > > > > De: Owen DeLong mailto:o...@delo

Re: [sig-policy] prop-124-version 5: Clarification on IPv6 Sub-Assignments

I express opposition to this policy change. There seems to me a misunderstanding of the term sub assignments in the proposal. A subassignment is an issuance of a portion of your prefix to an external third party recorded at the RIR level or provided in a public database (e.g. whois, rwhois,

Re: [sig-policy] prop-128-v001: Multihoming not required for ASN

> On Feb 21, 2019, at 22:20 , JORDI PALET MARTINEZ > wrote: > > Hi again Satoru, and once more many thanks for the inputs, > > If we keep “it holds previously-allocated provider independent address > space”, then it means an organization, for example, deploying only IPv6, will > not be

Re: [sig-policy] Amendment of SIG Charter

today are in-scope, to be left out. Agreed. However, in my view, your proposal is not less restrictive, just more verbose. Owen > > Regards, > Jordi > > > > > > El 11/5/19 1:27, "Owen DeLong" escribió: > > That’s not more generic, Jordi, i

Re: [sig-policy] Amendment of SIG Charter

apnic.net > http://www.apnic.net <http://www.apnic.net/> @apnicdg > > On 9 May 2019, at 19:53, Sumon Ahmed Sabir wrote: > >> >> Thank you very much Aftab and Owen for your constructive feedback. We will >> definitely consider those views. >>

Re: [sig-policy] Amendment of SIG Charter

perspective please jump in and share your > thoughts. > > Sincerely, > > Sumon > > > > On Mon, May 6, 2019 at 10:52 AM Owen DeLong <mailto:o...@delong.com>> wrote: > Aftab, I think you misread the proposed language. > > First, neither the current

Re: [sig-policy] Amendment of SIG Charter

derstanding. >> >> We have a recent experience of policies (resource hijacking is a policy >> violation) being declared out-of-scope in ARIN by the AC. I know the PDP >> is very different, but let’s make sure we don’t have this situation >> replicated in other AP

Re: [sig-policy] prop-132-v001 AS0 for Bogons

esources." > > Once allocated to RIRs then IANA can't issue any ROA (they are not doing it > to any resource anyway) but there is unallocated address space with RIRs, > they can issue AS0 ROAs. > > I hope this clarifies your point of IETF's involvement first. >

Re: [sig-policy] prop-132-v001 AS0 for Bogons

or all those unallocated addresses. > > Regards, > > Aftab A. Siddiqui > > > On Fri, Aug 16, 2019 at 9:03 AM Owen DeLong <mailto:o...@delong.com>> wrote: > Since we are talking about bigots, other than Unallocated space in RIR > inventory, I’m not sure how you

Re: [sig-policy] prop-132-v001 AS0 for Bogons

> On Aug 21, 2019, at 16:02 , Aftab Siddiqui wrote: > > Hi Owen, > > On Thu, Aug 22, 2019 at 7:10 AM Owen DeLong <mailto:o...@delong.com>> wrote: > I don’t tend to regard unallocated as “bogons”, > > Why is that? > RFC3871 <https://tools.ietf.org/h

Re: [sig-policy] prop-132-v002: AS0 for Bogons

Aftab, I don’t think you actually addressed his concern… > On Aug 26, 2019, at 17:17 , Aftab Siddiqui wrote: > > Hi Javed, > I understand your concern, let me try to explain. > > AS-0 ROA is an attestation by the holder of a prefix that the prefix > described in the ROA, and any more

Re: [sig-policy] Version 4 of prop-126 PDP Update

> On Aug 26, 2019, at 03:05 , JORDI PALET MARTINEZ > wrote: > > Hi Javed, > > I don’t agree, let me explain why. > > The current process only talks about the meeting and the chairs have clearly > indicated that they take in consideration the list and the confer. Anyone > from the

Re: [sig-policy] prop-124-v006: Clarification on Sub-Assignments

> On Aug 26, 2019, at 03:19 , JORDI PALET MARTINEZ > wrote: > > Hi Javed, > > I think you’re getting something wrong. > > Policies aren’t there so APNIC can verify “everything” to “every” member. > This will be impossible. > > Policies are there so everybody know the rules, and try

Re: [sig-policy] prop-132-v002: AS0 for Bogons

> On Aug 27, 2019, at 03:16 , Aftab Siddiqui wrote: > > Hi Owen, > > I don’t think you actually addressed his concern… > > Well, let me try again then :) > >> On Aug 26, 2019, at 17:17 , Aftab Siddiqui > > wrote: >> >> Hi Javed, >> I understand your

Re: [sig-policy] prop-132-v002: AS0 for Bogons

Thanks, Sunny! This is very helpful. Given the potential for this to produce outages, I’d like to propose that APNIC consider an additional step in the process. I think there should be a way for a resource holder (or former resource holder) to log in to the APNIC web site and trigger a

Re: [sig-policy] prop-132-v002: AS0 for Bogons

Most, if not all RIRs have a process for address recycling with appropriate hold-down times and grace periods for the resource holder to act to preserve their claim on the resources. It seems to me that lining this up with those procedures can be left as an operational manner at the discretion

Re: [sig-policy] prop-132-v002: AS0 for Bogons

. > > > So I am not in favor of asking the RIR to create AS0 ROA. > > Thats absolutely fine we can agree to disagree but let’s have a clear > understanding of the policy. What makes you think he does not understand the policy? Owen > > > J Khan > >

Re: [sig-policy] prop-132-v002: AS0 for Bogons

> On Aug 28, 2019, at 20:37 , Aftab Siddiqui wrote: > > > Hi Owen, > cutting some stuff out, just to keep the thread small. > > Anyone can very quickly put just about anything in RADB if they want to. It’s > also relatively easy to put nearly anything in the current ARIN IRR (not to > be

Re: [sig-policy] prop-132-v002: AS0 for Bogons

> On Aug 28, 2019, at 16:40 , Aftab Siddiqui wrote: > > > > On Thu, 29 Aug 2019 at 9:04 am, Owen DeLong <mailto:o...@delong.com>> wrote: > > >> On Aug 28, 2019, at 13:44 , Aftab Siddiqui > <mailto:aftab.siddi...@gmail.com>> wrote: >&g

Re: [sig-policy] prop-124-v006: Clarification on Sub-Assignments

I think the current text isn’t really a problem because reasonable people apply a reasonable interpretation of intent rather than the literal meaning. The proposal brings literal meaning more in line with well understood intent. While I don’t believe there is an actual problem to solve here,

Re: [sig-policy] prop-132-v001 AS0 for Bogons

IMHO, while I’m perfectly fine with APNIC administering this and maintaining the ROAs, etc., I believe that the decision to allocate AS0 to this purpose and documentation of this intent should be done through the IETF and be documented in an STD or RFC. I support the idea, but I believe the

Re: [sig-policy] New version - prop-133-v002: Clarification on Sub-Assignments

I agree… I don’t think there is any benefit to this policy and I oppose adding IPv6 to inter-RIR transfers of any form. Owen > On Feb 16, 2020, at 20:20 , Tsurumaki, Satoru wrote: > > Dear Colleagues, > > I am Satoru Tsurumaki from Japan Open Policy Forum. > > I would like to share key

Re: [sig-policy] prop-133: Clarification on Sub-Assignments

Assigned address space isn’t generally delegated to LIRs,… It’s generally delegated to end-users. Address space delegated to LIRs may then be reassigned by the LIR to itself for internal purposes. Unless there’s a case where an LIR is receiving an assignment instead of an allocation, I think

Re: [sig-policy] prop-141-v002: Change maximum delegation, size of IPv4 address from 512 ( /23 ) to 768 (/23+/24) addresses

I have no strong opinion positive or negative towards the proposal overall. I do oppose going from /23 to 0.75 /22. If we’re going to do this, let’s just go from /23 to /22 and keep things on prefix boundaries. Owen > On Sep 7, 2021, at 15:02 , Bertrand Cherrier wrote: > > Dear SIG members,

Re: [sig-policy] prop-141-v003: Change maximum delegation, size of IPv4 address from 512 ( /23 ) to 768 (/23+/24) addresses

Opposed. Not in favor of moving to non-prefix aligned allocations from an RIR. Owen > On Sep 14, 2021, at 20:37 , Bertrand Cherrier > wrote: > > Dear SIG members, > > A new version of the proposal "prop-141-v003: Change maximum delegation > size of IPv4 address from 512 ( /23 ) to 768

[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

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

> 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-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: 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: 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-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: 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

[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: 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: 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: 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-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: 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: 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: 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: 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: 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

> 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: 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 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

> 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 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-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: 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