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

[Robert Hudson]

On behalf of SAGE-AU, I support this proposal.
On 13 Sep 2015 1:28 am, "Masato Yamanishi"  wrote:

> Dear colleagues
>
> Version 3 of prop-114: Modification in the ASN eligibility criteria,
> reached consensus at the APNIC 40 Open Policy Meeting and later at the
> APNIC Member Meeting (AMM).
>
> This proposal will now move to the next step in the APNIC Policy
> Development Process and is being returned to the Policy SIG mailing list
> for the final Comment Period.
>
> At the end of this period the Policy SIG Chairs will evaluate comments
> made and determine if the consensus reached at APNIC 40 still holds. The
> Chairs may extend the Comment Period to a maximum of eight (8) weeks to
> allow further discussion.
>
> If consensus holds, the Chair of the Policy SIG will ask the Executive
> Council to endorse the proposal for implementation.
>
>- Send all comments and questions to: 
>- Deadline for comments:  23:59 (UTC +10) Sunday, 11 October 2015
>
>
>
> Proposal details
> 
>
> This is a proposal changes the criteria for AS number requests from
> end-user organizations considering multihoming.
>
> Proposal details, including the full text of the proposal, history, and
> links to the APNIC 40 meeting archive, are available at:
>
>  http://www.apnic.net/policy/proposals/prop-114
>
> Regards
>
> Masato and Sumon
>
> ---
>
> prop-114-v003: Modification in the ASN eligibility criteria
>
> ---
>
> Proposer:  Aftab Siddiqui
>aftab.siddi...@gmail.com
>
>Skeeve Stevens
>ske...@eintellegonetworks.com
>
>
> 1. Problem statement
> 
>
>The current ASN assignment policy states two eligibility criteria and
>that both criteria should be fulfilled in order to obtain an ASN. The
>policy seems to imply that both requirements i.e. multi-homing and
>clearly defined single routing policy must be met simultaneously,
>this has created much confusion in interpreting the policy.
>
>As a result organizations have either provided incorrect information
>to get the ASN or barred themselves from applying where they still
>have a valid justification for obtaining an ASN.
>
>
> 2. Objective of policy change
> -
>
>In order to make the policy guidelines simpler we are proposing to
>modify the text describing the eligibility criteria for ASN
>assignment by providing alternate criteria to obtaining an ASN.
>
>
> 3. Situation in other regions
> -
>
> ARIN:
> It is not mandatory but optional to be multi-homed in order get ASN
>
> RIPE:
> Policy to remove multi-homing requirement is currently in discussion
> and the current phase ends 12 February 2015 (awaiting Chair decision)
> Policy - https://www.ripe.net/ripe/policies/proposals/2014-03
>
> LACNIC:
> Only inter-connect is mandatory not multi-homing
>
> AFRINIC:
> It is mandatory to be multi-homed in order to get ASN.
>
>
> 4. Proposed policy solution
> ---
>
> An organisation is eligible for an ASN assignment if:
>
> - they are currently multi-homed, OR
>
> - have previous allocated provider independent address space by
>   APNIC, AND intend to multi-home in the future
>
>
> 5. Advantages / Disadvantages
> -
>
> Advantages:
>
> By adding the additional criteria of Guidelines managed by APNIC
> Secretariat, this would enable the Secretariat to make decisions
> based on common or rare use cases, but that may still be a valid
> request.
>
> Disadvantages:
>
> It may be perceived that this policy would enable members to obtain
> ASN’s more easily, and in return cause faster consumption of ASN’s
> in the region.  Given the relative ease of obtaining an ASN with
> ‘work around’ methods, we do not perceive this will actually have
> any effect.
>
>
> 6. Impact on resource holders
> -
>
> No impact on existing resource holders.
>
>
> *  sig-policy:  APNIC SIG on resource management policy
>*
> ___
> sig-policy mailing list
> sig-policy@lists.apnic.net
> http://mailman.apnic.net/mailman/listinfo/sig-policy
>
>
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

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

[Robert Hudson]

On behalf of SAGE-AU, I support this proposal.
On 13 Sep 2015 1:24 am, "Masato Yamanishi"  wrote:

> Dear colleagues
>
> Version 3 of prop-113: Modification in the IPv4 eligibility criteria,
> reached consensus at the APNIC 40 Open Policy Meeting and later at the
> APNIC Member Meeting (AMM).
>
> This proposal will now move to the next step in the APNIC Policy
> Development Process and is being returned to the Policy SIG mailing list
> for the final Comment Period.
>
> At the end of this period the Policy SIG Chairs will evaluate comments
> made and determine if the consensus reached at APNIC 40 still holds. The
> Chairs may extend the Comment Period to a maximum of eight (8) weeks to
> allow further discussion.
>
> If consensus holds, the Chair of the Policy SIG will ask the Executive
> Council to endorse the proposal for implementation.
>
>- Send all comments and questions to: 
>- Deadline for comments:  23:59 (UTC +10) Sunday, 11 October 2015
>
>
>
> Proposal details
> 
>
> This is a proposal changes the criteria for IPv4 address requests from
> end-user organizations considering multihoming.
>
> Proposal details, including the full text of the proposal, history, and
> links to the APNIC 40 meeting archive, are available at:
>
>  http://www.apnic.net/policy/proposals/prop-113
>
> Regards
>
> Masato and Sumon
>
>
> 
>
> prop-113-v003: Modification in the IPv4 eligibility criteria
>
> 
>
> Proposer:  Aftab Siddiqui
>aftab.siddi...@gmail.com
>
>Skeeve Stevens
>ske...@eintellegonetworks.com
>
>
> 1. Problem statement
> 
>
> The current APNIC IPv4 delegation policy defines multiple
> eligibility criteria and applicants must meet one criteria to be
> eligible to receive IPv4 resources. One of the criteria dictates
> that “an organization is eligible if it is currently multi-homed
> with provider-based addresses, or demonstrates a plan to multi-home
> within one month” (section 3.3).
>
> The policy seems to imply that multi-homing is mandatory even if
> there is no use case for the applicant to be multi-homed or even
> when there is only one upstream provider available, this has created
> much confusion in interpreting this policy.
>
> As a result organizations have either tempted to provide incorrect
> or fabricated multi-homing information to get the IPv4 resources or
> barred themselves from applying.
>
>
> 2. Objective of policy change
> -
>
> In order to make the policy guidelines simpler we are proposing to
> modify the text of section 3.3.
>
>
> 3. Situation in other regions
> -
>
> ARIN:
> There is no multi-homing requirement
>
> RIPE:
> There is no multi-homing requirement.
>
> LACNIC:
> Applicant can either have multi-homing requirement or interconnect.
>
> AFRINIC:
> There is no multi-homing requirement.
>
>
> 4. Proposed policy solution
> ---
>
> Section 3.3: Criteria for small delegations
>
> An organization is eligible if:
>
> - it is currently multi-homed, OR
>
> - currently utilising provider (ISP) assignment of at least a /24,
>   AND intends to be multi-homed, OR
>
> - intends to be multi-homed, AND advertise the prefixes within
>   6 months
>
> Organizations requesting a delegation under these terms must
> demonstrate that they are able to use 25% of the requested addresses
> immediately and 50% within one year.
>
>
> 5. Advantages / Disadvantages
> -
>
> Advantages:
>
> Simplifies the process of applying for IPv4 address space for small
> delegations and delays the immediate requirement for multi-homing as
> determined to be appropriate within the timeframe as detailed in
> Section 3.3.
>
>
> Disadvantages:
>
> There is no known disadvantage of this proposal.
>
>
> 6. Impact on resource holders
> -
>
> No impact on existing resource holders.
>
>
> *  sig-policy:  APNIC SIG on resource management policy
>*
> ___
> sig-policy mailing list
> sig-policy@lists.apnic.net
> http://mailman.apnic.net/mailman/listinfo/sig-policy
>
>
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

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

[Robert Hudson]

In addition to Owen's point, I also wonder about this:

"AND

- advertise the prefixes within 6 months"

Is there a process in place which actually checks this?

If so, will APNIC actually pull back /24 allocations which aren't
advertised within 6 months?
If not - why even include it?

Regards,

Robert

On 5 March 2015 at 12:10, Owen DeLong  wrote:

> Simply advertising a network doesn’t mean you need the addresses or that
> you’re actually using them in an operational network.
>
> It just means you typed in a BGP anchor statement.
>
> Owen
>
> On Mar 4, 2015, at 16:44 , Skeeve Stevens  wrote:
>
> How do you see needs basis going away in this wording?
>
>
> ...Skeeve
>
> *Skeeve Stevens - Senior IP Broker*
> *v4Now - *an eintellego Networks service
> ske...@v4now.com ; www.v4now.com
> Phone: 1300 239 038; Cell +61 (0)414 753 383 ; skype://skeeve
> facebook.com/v4now ;  
> linkedin.com/in/skeeve
> twitter.com/theispguy ; blog: www.theispguy.com
>
> IP Address Brokering - Introducing sellers and buyers
>
> On Thu, Mar 5, 2015 at 9:31 AM, Owen DeLong  wrote:
>
>> +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.
>>
>> This still looks to remove needs based allocation and shift that to an
>> "ability to advertise".
>>
>> Am I missing something here?
>>
>> On Thursday, 5 March 2015, Masato Yamanishi  wrote:
>>
>>> Dear SIG members
>>>
>>> A new version of the proposal “prop-113: Modification in the IPv4
>>> eligibility criteria" has been sent to the Policy SIG for review.
>>>
>>> Information about earlier versions is available from:
>>>
>>> http://www.apnic.net/policy/proposals/prop-113
>>>
>>> You are encouraged to express your views on the proposal:
>>>
>>>  - Do you support or oppose the proposal?
>>>  - Is there anything in the proposal that is not clear?
>>>  - What changes could be made to this proposal to make it more effective?
>>>
>>> Please find the text of the proposal below.
>>>
>>> Kind Regards,
>>>
>>> Masato
>>>
>>>
>>>
>>>
>>>
>>> --
>>> prop-113-v002: Modification in the IPv4 eligibility criteria
>>> -
>>>
>>> Proposer:   Aftab Siddiqui
>>>   aftab.siddi...@gmail.com
>>>
>>>   Skeeve Stevens
>>>   ske...@eintellegonetworks.com
>>>
>>>
>>> 1. Problem statement
>>> -
>>>
>>> The current APNIC IPv4 delegation policy defines multiple
>>> eligibility criteria and applicants must meet one criteria to be
>>> eligible to receive IPv4 resources. One of the criteria dictates
>>> that “an organization is eligible if it is currently multi-homed
>>> with provider-based addresses, or demonstrates a plan to multi-home
>>> within one month” (section 3.3).
>>>
>>> The policy seems to imply that multi-homing is mandatory even if
>>> there is no use case for the applicant to be multi-homed or even
>>> when there is only one upstream provider available, this has created
>>> much confusion in interpreting this policy.
>>>
>>> As a result organizations have either tempted to provide incorrect
>>> or fabricated multi-homing information to get the IPv4 resources or
>>> barred themselves from applying.
>>>
>>>
>>> 2. Objective of policy change
>>> --
>>>
>>> In order to make the policy guidelines simpler we are proposing to
>>> modify the text of section 3.3.
>>>
>>>
>>> 3. Situation in other regions
>>> 
>>>
>>> ARIN:
>>> There is no multi-homing requirement
>>>
>>> RIPE:
>>> There is no multi-homing requirement.
>>>
>>> LACNIC:
>>> Applicant can either have multi-homing requirement or interconnect.
>>>
>>> AFRINIC:
>>> There is no multi-homing requirement.
>>>
>>>
>>> 4. Proposed policy solution
>>> 
>>>
>>> Section 3.3: Criteria for small delegations
>>>
>>> An organization is eligible if:
>>>
>>> - it is currently multi-homed
>>>
>>> OR,
>>>
>>> - currently utilising provider (ISP) assignment of at least a /24,
>>>
>>> AND
>>>
>>> - intends to be multi-homed
>>>
>>> OR,
>>>
>>> - intends to be multi-homed
>>>
>>> AND
>>>
>>> - advertise the prefixes within 6 months
>>>
>>>
>>>
>>> 5. Advantages / Disadvantages
>>> --
>>>
>>> Advantages:
>>>
>>> Simplifies the process of applying for IPv4 address space for small
>>> delegations and delays the immediate requirement for multi-homing as
>>> determined to be appropriate w

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

[Robert Hudson]

On 25 February 2015 at 17:06, Dean Pemberton  wrote:

> Great - Thanks for that.
>
> As far as I can tell this covers all possible use cases I can see.
> I do not believe that there is a need for prop-114.
>
> I do not support the proposal
>

I concur with Dean - I don't see a requirement for this proposal, given the
clarification of existing policy which has been provided, and thus do not
support the proposal.
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

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

[Robert Hudson]

On 25 February 2015 at 07:13, Dean Pemberton  wrote:

> >
> > +1 to most of what Dean says.
> >
> > My point is that if you need more than a /32, then you should be able to
> get a /28 rather than having to make a /[29..31] work.
>
> It's my understanding that current policy allows just that.  If you
> need a /28 then APNIC will be able to allocate you one.  It might not
> be an extension of your existing allocation if you were one of the
> early adopters (limited to a /29 boundary), but this policy doesn't
> provide anything new.
>
> All it proposes is that anyone in the position of having an allocation
> from:
>   2001:0200::/23
>   2001:0c00::/23
>   2001:0e00::/23
>   2001:4400::/23
>
> Can request their allocation be extended to a /29 without any further
> justification needed.
>
> Owen opposes this as it wouldn't support allocation on a byte boundary
> (/28).  That is never going to be possible for allocations within this
> block as they were initially allocated too close together.
>
> I oppose this on the grounds that it violates needs based allocation
> guidelines AND non byte boundary allocation for IPv6.
>

So you would support it if it only violated one of those two concerns?


> A way forward that I would support is:
>
> 1.  Have the hostmasters confirm that a member with an allocation in
> this block could, if justified, receive an allocation up to a /29 by
> extending their current allocation.
> 2.  Have the hostmasters confirm that a member with an allocation in
> this block could, if justified, swap the allocation for one  allocated
> from a different block where the /29 restriction on growth did not
> apply.
> 3.  Withdraw this proposal.
>

My reading of the policy proposal is that it aims to allow people who
received allocations under the legacy allocation scheme to expand their
address space in a contiguous fashion without having to shift out of their
existing address space.

Given that the address space between the legacy /32s is completely wasted
at present, I don't see an issue with removing the justification
requirements in this specific case (it's been mentioned that we're setting
a dangerous precedent - I'd argue that leaving the space wasted if we have
a technically feasible way to make better utilisation of it is a more
dangerous precedent).  I do not see an issue with this, given the specific
limitations which are documented in the proposal.

We have to accept that (short of handing everyone with a legacy allocation
a new allocation based on today's allocation policy and forcing them to
move over to it, handing back their legacy allocation - and I believe that
the fact that this proposal is even being considered means we'd not go down
that path) we will never resolve the requirement for contiguous address
space within the legacy allocation ranges without allowing non-byte
allocations.

So, in my mind, the issue comes down to "Do we want to allow allocation on
non byte boundaries [in a limited sense, only within the legacy allocation
policy blocks] in order to allow us to better utilise what is currently
wasted space, and provide a non-disruptive allocation expansion capability
for those who's only crime was to ask for their allocation when the policy
was different to what it is now?"

In the end, I believe that we do want to do this.  And thus, in the absence
of an alternative policy proposal which resolves the issues this one does,
I support this proposal.
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy

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

[Robert Hudson]

On 4 February 2015 at 14:54, Dean Pemberton  wrote:

> There are a number of things that concern me about this proposal.
>
> 1) it doesn't appear to support needs based allocation
> 2) it doesn't support allocation on nibble boundaries which operators have
> said repeatedly is a major issue.
>

As I read it...

The proposal addresses only organisations who already have /32 allocations
in the legacy IPv6 block (the IP ranges this includes are defined in the
proposal).  The allocation policy in the legacy block was effectively to
carve out a /29, but then only provide the applicant with a /32 out of this
/29 - meaning the gap between the /29 and the /32 remains un-allocated.

Prop-112 simply proposes that the owner of one of these /32 allocations
can, if the require it, request to "fill out" the /29 which is allocated to
them in the back-end, so that they end up with a contiguous block of IP
address space.  It is not possible to stretch this to a nibble boundary
(/28), because the next allocation in the legacy IPv6 block could/would
overlap this.

The proposal does NOT impact /32 allocations that were made since the newer
policy of sparse allocation was introduced.  Those are left to be dealt
with under the existing rules.

If the proposal is not accepted, the gap between /32 and /29 is "wasted"
for every allocation within the legacy IPv6 block.  This "wastes"
30,064,771,072 /64 networks, unless a policy is proposed and approved to
somehow use this address space in another fashion.

I'm happy to be corrected on any of this.  But if my understanding is
correct, the benefits of this proposal vastly outweigh any negatives, and I
believe SAGE-AU will be supporting it.
*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/listinfo/sig-policy