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

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

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

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

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

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

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

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

[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, bu

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

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

eed and it is > considered as a policy violation. > > This proposal just want to make that more evident, because today, you need to > find it in pieces of text across the policy manual. > > Regards, > Jordi > > @jordipalet > > >> El 4 ago 2023, a las 21:18, O

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

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

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

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

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

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

[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, whi

[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. Bush

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

[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 isn’

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

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 (/23+

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

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 feed

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

I took the liberty of reformatting the message into a consistent font and size. > On Sep 9, 2019, at 02:41 , JORDI PALET MARTINEZ > wrote: > > Hi Owen, > > > El 27/8/19 8:15, "Owen DeLong" mailto:o...@delong.com>> > escribió: > > &g

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 suspens

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 c

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-132-v002: AS0 for Bogons

customers. > > > 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 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 conce

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 communi

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 thei

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 specifi

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, I

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-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-v001 AS0 for Bogons

AS0 ROAs for 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 su

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

bogons. Owen > On Aug 15, 2019, at 15:12, Andrew Dul wrote: > > >> On 8/15/2019 12:19 AM, Aftab Siddiqui wrote: >> Hi Owen, >> >>> On Thu, Aug 15, 2019 at 5:10 PM Owen DeLong wrote: >>> Looks like IETF wants the global BOGONs to be attested by

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

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 pro

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

Aftab, I think you misread the proposed language. First, neither the current version nor the proposed version refer to members at all, but to the actions of the APNIC, NIRs, and ISPs. The one change I think should be made there is to replace ISPs with LIRs since not all LIRs are technically ISP

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

t think we should do either). Owen > > Regards, > Jordi > > > > > > De: Owen DeLong mailto:o...@delong.com>> > Fecha: viernes, 22 de febrero de 2019, 19:00 > Para: JORDI PALET MARTINEZ <mailto:jordi.pa...@consulintel.es>> > CC: Satoru

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, or

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 abl

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] 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] prop-123-v001: Modify 103/8 IPv4 transfer policy

d concur with your 24 month period as > being more reasonable. As I stated previously in reply to Skeeve. The statistics don’t bear out the problem I thought would exist, so I’m no longer objecting to this proposal. However, I don’t grant the premise of your argument above. Owen > > Regar

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

. It is 1% of > the total membership (includes members under NIRs). Out of that, 123 members > received one range, 16 members received two ranges and 13 members received > more two ranges. > > > > Kind regards, > > Guangliang > > == > >

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

We can agree to disagree. This is, IMHO, the kind of speculation in 103/8 blocks that the policy (original 2 year limit) was intended to target. The expansion of this to a 5 year limit, while excessive IMHO, seems to likely be community reaction to just this sort of behavior, so I have no probl

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

ase: 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 <mailto:o...@delong.com>> wrote: > I would argue that 257 probably represent

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&A transfers since issuance. I’d be especially interested in the numbe

Re: [sig-policy] sig-policy Digest, Vol 160, Issue 27--- apply in the address allocated after the policy officially issued

IIRC, it’s part of the contract that you agree to accept policy changes adopted by the community, so I see no reason to grandfather. Owen > On Oct 13, 2017, at 02:36 , Brown Kevin wrote: > > There is a big problem what is the range of the transfer prohibition, > all the allocated 103/8 or new

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 space, and they disappear soon

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 to

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 not

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 o

Re: [sig-policy] An interesting policy question

warning, 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 <mailto:o...@delong.com>> wrote: > >> Fair warning, Lu

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

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

> On Sep 15, 2015, at 17:58 , Paul Wilson 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 say we pass &

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

e.io/skeeve> > > IP Address Brokering - Introducing sellers and buyers > > On Wed, Sep 16, 2015 at 8:07 AM, George Kuo <mailto:geo...@apnic.net>> wrote: > Hi Owen, > > > On 15/09/2015 3:36 am, Owen DeLong wrote: > > On Sep 14, 2015, at 01:59 , Masato Yama

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

> > In 2010, I was told that the transition would be end in 5 years. > In 2000…… Where are we right now? > I bet my 5 cents that we just started long long way. > > Regards, > Masato Yamanishi > > > 2015-09-15 2:36 GMT+09:00 Owen DeLong <mailto:o...@delong.com>

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

> On Sep 14, 2015, at 01:59 , Masato Yamanishi wrote: > > Dear Colleagues, > > In Jakarta, Geoff Huston presented the status of our IPv4 resources, in > particular about exhaustion and transfer, > and some participants asked to summarize and post it to the list for further > discussion. > >

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 > should share their f

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 interne

Re: [sig-policy] prop-114: Modification in the ASN eligibility criteria to be discussed at APNIC 40

> On Aug 7, 2015, at 02:34 , Masato Yamanishi wrote: > > Dear SIG members > > ## It is NOT new version, just a reminder that this proposal will be > discussed at APNIC 40 > > Version 3 of this proposal was posted to the mailing list during > APNIC 39. The proposal did not reach consensus and

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

> On May 22, 2015, at 20:42 , Michel Py > wrote: > >> David Conrad wrote : >> In my (early) experience at APNIC, there was significant interest in >> "vanity" IP addresses, >> to the point where folks created multiple companies in order to get >> particular addresses >> when APNIC was allocat

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

. Owen > On May 22, 2015, at 10:21 , Paul Wilson wrote: > > > > On 23 May 2015, at 2:13 am, Owen DeLong wrote: > >> Paul, >> >> I find it interesting amid calls for “don’t rearrange the deck chairs” that >> you single out my message as the one at

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

pace, rather than trying to shut them down. > > Paul > > > > Paul Wilson, Director-General, APNICd...@apnic.net > http://www.apnic.net @ap

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

We’re talking about a single /24. Use it for whatever research value it has and then put it out to pasture along with the rest of this antiquated addressing. My $0.02. Owen > On May 21, 2015, at 12:45 , David Huberman > wrote: > > Dean, <> > > Thank you for your excellent reply. > > I a

Re: [sig-policy] Updated Text - Prop-114v003

I think this is an improvement, but I can support either way. Owen > On Mar 4, 2015, at 21:54 , Sanjeev Gupta wrote: > > > On Thu, Mar 5, 2015 at 12:50 PM, Skeeve Stevens > wrote: > 4. Proposed policy solution > --- > > An organisation is elig

Re: [sig-policy] Updated Text - Prop-114v003

That’s text I can support. Owen > On Mar 4, 2015, at 21:27 , Gaurab Raj Upadhaya wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > I support this. > > - -gaurab > > > On 3/5/15 4:50 AM, Skeeve Stevens wrote: >> In this text, the suggested guidelines have been removed to be >> r

Re: [sig-policy] Updated Text - Prop-113v003

I support this as written. Owen > On Mar 4, 2015, at 20:50 , Skeeve Stevens wrote: > > The only addition to this text was the clarification of demonstrated need. > It is not being removed and will remain in place as below. > > "Organizations requesting a delegation under these terms must dem

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

> On Mar 4, 2015, at 18:31 , Gaurab Raj Upadhaya wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 3/5/15 2:13 AM, Skeeve Stevens wrote: > >> So, if I wanted to put a connection online in Singapore, and only >> connected to one upstream, but also connect to Megaport, or >> Pac

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

; facebook.com/v4now <http://facebook.com/v4now> ; > <http://twitter.com/networkceoau>linkedin.com/in/skeeve > <http://linkedin.com/in/skeeve> > twitter.com/theispguy <http://twitter.com/theispguy> ; blog: > www.theispguy.com <http://www.theispguy.com/> >

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

y.com/> > > IP Address Brokering - Introducing sellers and buyers > > On Thu, Mar 5, 2015 at 9:31 AM, Owen DeLong <mailto:o...@delong.com>> wrote: > +1… I’m with Dean… Still opposed. > > Let’s keep needs basis in place, please. I’m all for removing the requiremen

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 wrote: > > Just to clarify. > >

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

ntellego Networks service >> ske...@v4now.com <mailto:ske...@v4now.com> ; www.v4now.com >> <http://www.v4now.com/> >> Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve <> >> facebook.com/v4now <http://facebook.com/v4now> ; >>

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

lt;http://facebook.com/v4now> ; > <http://twitter.com/networkceoau>linkedin.com/in/skeeve > <http://linkedin.com/in/skeeve> > twitter.com/theispguy <http://twitter.com/theispguy> ; blog: > www.theispguy.com <http://www.theispguy.com/> > > IP Addre

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 wrote: > > Dear SIG member

Re: [sig-policy] New Version of prop-115-v001: Registration of detailed assignment information in whois DB

gt; But in order to start discussing about what is good solution where we > can get detailed information about assignment of address, I thought > whois DB is possible one to choose. > > Regards, > > On 2015/02/25 2:11, Owen DeLong wrote: >> I don’t believe the proposal

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

> On Feb 27, 2015, at 01:43 , Izumi Okutani 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 single hom

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

; > Cheers, > Jessica Shen > > > >> -邮件原件- >> 发件人: sig-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] Requirements for Subsequent ASN Requests

t may qualify some > usecases 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 mailto:o...@delong.com>> > のメッセージ: > >> Yes

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

ato Yamanishi wrote: > > Owen and Usman, > > In following comments, did you consider we are discussing "public" AS numbers? > Since we are discussing "public" AS, we should have some kind of > justifications why it should be globally unique. > > Regards, &

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, I

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 rout

  1   2   >