Re: [sig-policy] prop-072: Reapplication limits when transferring addres
entitled to get it?
Why would they need to transfer that /24 instead of assign it in this
situation? The transfer process deals with transfer of the allocation to
another APNIC member. If the address space is unused it should be handed
back to the registry. If they are selling address space for money then there
is an assumption that the free pool is already exhausted and there is no
more space to apply for anyway.
McDonald Richards
CTO
Vocus Communications
-----Original Message-----
From: sig-policy-bounces at lists dot apnic dot net
[mailto:sig-policy-bounces at lists dot apnic dot net] On Behalf Of Skeeve Stevens
Sent: Wednesday, 11 March 2009 11:05 AM
To: sig-policy at apnic dot net
Subject: Re: [sig-policy] prop-072: Reapplication limits when transferring
address space
Report for correct Policy to be commented on:
I VERY much do NOT support this proposal.
A timeframe which stops you getting any address space from APNIC is
unacceptable.
In this day and age of business things can change very very quickly.
A business might have some address space available, business is slow and not
looking great or some such, they sell/transfer off some address space to
another party. A few months (arbitrary amount of time) later, the mother of
all deals falls into their laps and they can justify a lot of address space.
So someone could transfer a /24 and then suddenly need a /18 and not be
entitled to get it? You have to be kidding me.
No-one can predict the flow of business next month, much less 2 years into
the future.
Legally 'restraint of trade' comes to mind in Australia.
This proposal, which I understand is the original wording, is unacceptable
and should not be brought in.
Perhaps if it were worded in some way (don't know how) that they were not
able to get the SAME AMOUNT of address space they gave away - for a shorter
time... but I still think this is fraught with dangers.
...Skeeve
--
Skeeve Stevens, CEO/Technical Director
eintellego Pty Ltd - The Networking Specialists
skeeve at eintellego dot net / www.eintellego.net
Phone: 1300 753 383, Fax: (+612) 8572 9954
Cell +61 (0)414 753 383 / skype://skeeve
--
NOC, NOC, who's there?
Disclaimer: Limits of Liability and Disclaimer: This message is for the
named person's use only. It may contain sensitive and private proprietary or
legally privileged information. You must not, directly or indirectly, use,
disclose, distribute, print, or copy any part of this message if you are not
the intended recipient. eintellego Pty Ltd and each legal entity in the
Tefilah Pty Ltd group of companies reserve the right to monitor all e-mail
communications through its networks. Any views expressed in this message
are those of the individual sender, except where the message states
otherwise and the sender is authorised to state them to be the views of any
such entity. Any reference to costs, fee quotations, contractual
transactions and variations to contract terms is subject to separate
confirmation in writing signed by an authorised representative of
eintellego. Whilst all efforts are made to safeguard inbound and outbound
e-mails, we cannot guarantee that attachments are
virus-free or compatible with your systems and do not accept any liability
in respect of viruses or computer problems experienced.
> -----Original Message-----
> From: sig-policy-bounces at lists dot apnic dot net [mailto:sig-policy-
> bounces at lists dot apnic dot net] On Behalf Of Randy Bush
> Sent: Tuesday, 10 March 2009 8:18 PM
> To: sig-policy at apnic dot net
> Subject: [sig-policy] prop-072: Reapplication limits when transferring
> address space
>
> Dear SIG members
>
> The policy proposal 'Reapplication limits when transferring address
> space' has been sent to the Policy SIG for review. It will be presented
> at the Policy SIG at APNIC 28 in Beijing, China, 24-28 August 2009. The
> proposal's history can be found at:
>
> http://www.apnic.net/policy/proposals/prop-072-v001.html
>
> We invite you to review and comment on the proposal on the mailing
> list before the meeting.
>
> The comment period on the mailing list before an APNIC meeting is
> an important part of the policy development process. We encourage
> you to express your views on the proposal:
>
> - Do you support or oppose this proposal?
> - Does this proposal solve a problem you are experiencing? If
> so, tell the community about your situation.
> - Do you see any disadvantages in this proposal?
> - Is there anything in the proposal that is not clear?
> - What changes could be made to this proposal to make it more
> effective?
>
> Randy, Jian, and Ching-Heng
>
> _______________________________________________________________________
> _
>
> prop-072: Reapplication limits when transferring address space
> _______________________________________________________________________
> _
>
>
> Author: Philip Smith
> pfs at cisco dot com
>
> Version: 1
>
> Date: 10 March 2009
>
> 1. Introduction
> ----------------
>
> This policy proposal seeks to supplement prop-050, "IPv4 address
> transfers", by not permitting organisations who have transferred IPv4
> address from obtaining more address space from APNIC for a period of 24
> months after the transfer.
>
>
> 2. Summary of current problem
> ------------------------------
>
> Prop-050, "IPv4 address transfers", as it stands at time of writing,
> places no restriction on the organisation transferring IPv4 address
> space to return to APNIC for additional IPv4 address space.
>
> This gives organisations the opportunity to transfer their IPv4 address
> space to another organisation, and return to APNIC almost immediately
> with a fully justified application for additional resources. This means
> that organisations could rapidly deplete the remaining IPv4 pool, to
> the
> detriment of the entire industry during the IPv4 runout period.
>
>
> 3. Situation in other RIRs
> ---------------------------
>
> RIPE NCC
>
> The transfer policy adopted by RIPE only places no limits on any
> organisation transferring address space to a third party from going
> back to the RIPE NCC for further IPv4 address space. See:
>
> http://www.ripe.net/ripe/policies/proposals/2007-08.html
>
> ARIN
>
> The transfer policy notes that transfers of address space between
> organisations are only considered if the originating organisation
> has
> made a complete transfer of assets to the recipient (such as a
> liquidation of the originating organisation). See:
>
> http://www.arin.net/policy/proposals/2007_8.html
>
> LACNIC
>
> LACNIC is currently discussing a transfer proposal:
>
> LAC-2009-04 Transfer of IPv4 Blocks within the LACNIC Region
> http://www.lacnic.net/documentos/politicas/LAC-2009-04-propuesta-
> en.pdf
>
> AfriNIC has no transfer policy.
>
>
> 4. Details of the proposal
> ---------------------------
>
> It is proposed that organisations disposing of their space using the
> transfer policy described in prop-050, "IPv4 address transfers", are
> not
> eligible for APNIC IPv4 assignments and/or allocations for two years.
>
>
> 5. Advantages and disadvantages of the proposal
> ------------------------------------------------
>
> 5.1 Advantages
>
> - Organisations transferring address space to third parties can
> not
> go back to APNIC and request additional IPv4 address space for a
> period of 24 months. This prevents organisations from making
> frequent and repeated requests to APNIC, and then transferring
> the address space elsewhere.
>
> 5.2 Disadvantages
>
> - None.
>
>
> 6. Effect on APNIC Members
> ---------------------------
>
> The proposal impacts all APNIC members in that they now cannot receive
> more address space from the APNIC free pool for a full 24 months after
> they have made a transfer to another organisation.
>
>
> 7. Effect on NIRs
> ------------------
>
> The proposal has no direct impact on NIRs, but impacts members of NIRs
> in the same way it impacts APNIC members.
> * sig-policy: APNIC SIG on resource management policy
> *
> _______________________________________________
> sig-policy mailing list
> sig-policy at lists dot apnic dot net
> http://mailman.apnic.net/mailman/listinfo/sig-policy
* sig-policy: APNIC SIG on resource management policy
*
_______________________________________________
sig-policy mailing list
sig-policy at lists dot apnic dot net
http://mailman.apnic.net/mailman/listinfo/sig-policy