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

[Masato Yamanishi]

Dear SIG members

The proposal "prop-114: Modification in the ASN eligibility criteria"
has been sent to the Policy SIG for review.

It  will be presented at the Open Policy Meeting at APNIC 39 in Fukuoka,
Japan on Thursday, 5 March 2015.

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?


Information about this proposal is available at:

http://www.apnic.net/policy/proposals/prop-114


Regards,

Masato





---
prop-114-v001: 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 dictates two eligibility criteria
and both should be fulfilled in order to get 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.


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 removing multi-homing requirement for the organization.


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
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 organization is eligible for an ASN assignment if it:
 - Is planning to use it within next 6 months


5. Advantages / Disadvantages
-

Advantages:

Removing the mandatory multi-homing requirement from the policy will
make sure that organizations are not tempted to provide wrong
information in order to fulfil the criteria of eligibility.

Disadvantages:

No disadvantage.


6. Impact on resource holders
-

No impact on existing resource holders.


7. References
-
*  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-114: Modification in the ASN eligibility criteria

[Dean Pemberton]

Could I ask that the APNIC hostmasters to comment on the following:

Have you ever been made aware of a situation where due of the current
wording of the relevant clauses in the policy, a member or potential member
has not made a resource application where they would otherwise have been
able to?

In other words has the current policy in the eyes of the host masters ever
been a barrier to entry?




On Wednesday, 4 February 2015, Masato Yamanishi  wrote:

> Dear SIG members
>
> The proposal "prop-114: Modification in the ASN eligibility criteria"
> has been sent to the Policy SIG for review.
>
> It  will be presented at the Open Policy Meeting at APNIC 39 in Fukuoka,
> Japan on Thursday, 5 March 2015.
>
> 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?
>
>
> Information about this proposal is available at:
>
> http://www.apnic.net/policy/proposals/prop-114
>
>
> Regards,
>
> Masato
>
>
>
>
>
> ---
> prop-114-v001: 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 dictates two eligibility criteria
> and both should be fulfilled in order to get 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.
>
>
> 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 removing multi-homing requirement for the organization.
>
>
> 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
> 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 organization is eligible for an ASN assignment if it:
>  - Is planning to use it within next 6 months
>
>
> 5. Advantages / Disadvantages
> -
>
> Advantages:
>
> Removing the mandatory multi-homing requirement from the policy will
> make sure that organizations are not tempted to provide wrong
> information in order to fulfil the criteria of eligibility.
>
> Disadvantages:
>
> No disadvantage.
>
>
> 6. Impact on resource holders
> -
>
> No impact on existing resource holders.
>
>
> 7. References
> -
>
>

-- 
--
Dean Pemberton

Technical Policy Advisor
InternetNZ
+64 21 920 363 (mob)
d...@internetnz.net.nz

To promote the Internet's benefits and uses, and protect its potential.
*  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-114: Modification in the ASN eligibility criteria

[Job Snijders]

On Tue, Feb 03, 2015 at 11:57:38AM -0600, Masato Yamanishi wrote:
> 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?

I support this proposal. I appreciate its simplicity.

Kind regards,

Job
*  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-114: Modification in the ASN eligibility criteria

[Randy Bush]

> In order to make the policy guidelines simpler we are proposing to
> modify the text describing the eligibility criteria for ASN
> assignment by removing multi-homing requirement for the organization.
> 
> An organization is eligible for an ASN assignment if it:
>  - Is planning to use it within next 6 months

planning to use it as what?  a guess in the lucky numbers draw?

on the global net, as numbers are for autonomous systems, i.e. those
whose routing policies differ from their neighbor, see rfc1930.  unless
you are multi-homed, your policy can not differ from that of your
neighbor (== upstream).

so the little hack above should be

>  - Is planning to use it within next 6 months
   ^ for multi-homing

randy
*  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-114: Modification in the ASN eligibility criteria

[Gaurab Raj Upadhaya]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2/3/15 9:19 PM, Randy Bush wrote:

> so the little hack above should be
> 
>> - Is planning to use it within next 6 months
> ^ for multi-homing


make it applicable only for 32 bits ASNs.

(duck)

- -gaurab


-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)

iEYEARECAAYFAlTRgkAACgkQSo7fU26F3X3BnACaA/cWeaPosz/0m4Oh9rCkS8Qc
PHkAn1QaM551nYWJojMBVjNpeR/LyRET
=Ad7X
-END PGP SIGNATURE-
*  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-114: Modification in the ASN eligibility criteria

[Randy Bush]

i liked dean's question.  is there actually a problem?  have folk who
really needed asns not been able to get one under current policy?

randy, thinking of reintroducing the no more policies policy 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-114: Modification in the ASN eligibility criteria

[Skeeve Stevens]

I did actually think that... but Aftab rightly pointed out that there are
people who still can use them, due to their own equipment or due to their
upstreams.


...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 Wed, Feb 4, 2015 at 1:21 PM, Gaurab Raj Upadhaya 
wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 2/3/15 9:19 PM, Randy Bush wrote:
>
> > so the little hack above should be
> >
> >> - Is planning to use it within next 6 months
> > ^ for multi-homing
>
>
> make it applicable only for 32 bits ASNs.
>
> (duck)
>
> - -gaurab
>
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
>
> iEYEARECAAYFAlTRgkAACgkQSo7fU26F3X3BnACaA/cWeaPosz/0m4Oh9rCkS8Qc
> PHkAn1QaM551nYWJojMBVjNpeR/LyRET
> =Ad7X
> -END PGP SIGNATURE-
> *  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 Policy Proposal] prop-114: Modification in the ASN eligibility criteria

[Owen DeLong]

> 
> 3. Situation in other regions
> -
> 
> ARIN:
> It is not mandatory but optional to be multi-homed in order get ASN

For clarity, ARIN requires either Multihoming _OR_ a Unique Routing Policy.

> 4. Proposed policy solution
> ---
> 
> An organization is eligible for an ASN assignment if it:
>  - Is planning to use it within next 6 months

I’d like to see something more stringent than this. This amounts to a Pez 
dispenser for ASNs.

I can claim I plan to do just about anything within 6 months.

Is there a problem with preserving the existing policy and simply clarifying 
that either of the two requirements being satisfied is sufficient?

That is, match the ARIN policy of Multihoming _OR_ a Unique Routing Policy?

> 
> 
> 5. Advantages / Disadvantages
> -
> 
> Advantages:
> 
> Removing the mandatory multi-homing requirement from the policy will
> make sure that organizations are not tempted to provide wrong
> information in order to fulfil the criteria of eligibility.
> 
> Disadvantages:
> 
> No disadvantage.

I disagree. I think putting ASNs into a Pez dispenser has numerous 
disadvantages.

While there are 4 billion ASNs, as we have seen demonstrated before, 4 billion 
is still a finite number.

Owen


*  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-114: Modification in the ASN eligibility criteria

[沈志]

I support this proposal. This can solve the problem in some situations that 
companies

are able to make BGP connections with operators only when they have their own 
ASN.

 

 ---

Jessica Shen

CNNIC



-原始邮件-
发件人:"Masato Yamanishi" 
发送时间:2015-02-04 01:57:38 (星期三)
收件人: sig-policy@lists.apnic.net
抄送:
主题: [sig-policy] [New Policy Proposal] prop-114: Modification in the ASN 
eligibility criteria


Dear SIG members

The proposal "prop-114: Modification in the ASN eligibility criteria"
has been sent to the Policy SIG for review.

It  will be presented at the Open Policy Meeting at APNIC 39 in Fukuoka,
Japan on Thursday, 5 March 2015.

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?


Information about this proposal is available at:

http://www.apnic.net/policy/proposals/prop-114


Regards,

Masato





---
prop-114-v001: 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 dictates two eligibility criteria
and both should be fulfilled in order to get 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.


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 removing multi-homing requirement for the organization.


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
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 organization is eligible for an ASN assignment if it:
 - Is planning to use it within next 6 months


5. Advantages / Disadvantages
-

Advantages:

Removing the mandatory multi-homing requirement from the policy will
make sure that organizations are not tempted to provide wrong
information in order to fulfil the criteria of eligibility.

Disadvantages:

No disadvantage.


6. Impact on resource holders
-

No impact on existing resource holders.


7. References
-


*  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-114: Modification in the ASN eligibility criteria

[Aftab Siddiqui]

Hi Randy,

i liked dean's question.  is there actually a problem?  have folk who
> really needed asns not been able to get one under current policy?
>

Even, I liked Dean's question and would like to see what data hostmasters
have on this.


> randy, thinking of reintroducing the no more policies policy proposal.
>

I would love to see prop-108 again :)
*  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-114: Modification in the ASN eligibility criteria

[Aftab Siddiqui]

Hi Dean,
Thanks for raising the question.

Could I ask that the APNIC hostmasters to comment on the following:
>
> Have you ever been made aware of a situation where due of the current
> wording of the relevant clauses in the policy, a member or potential member
> has not made a resource application where they would otherwise have been
> able to?
>

Would like to add something here to the question, "have you even been made
aware of a situation where applicant provided wrong or fake multi-homing
information just to meet the criteria?"


> In other words has the current policy in the eyes of the host masters
> ever been a barrier to entry?
>
> Very valid point.


Regards,

Aftab A. Siddiqui
*  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-114: Modification in the ASN eligibility criteria

[Dean Pemberton]

Changing or removing the rules is not the way to address people submitting
invalid or misleading information.

Also I doubt that the hostmasters would be 'aware' of a case. If they were
then the question would be why did they approve the resource application.



On Wednesday, 4 February 2015, Aftab Siddiqui 
wrote:

> Hi Dean,
> Thanks for raising the question.
>
> Could I ask that the APNIC hostmasters to comment on the following:
>>
>> Have you ever been made aware of a situation where due of the current
>> wording of the relevant clauses in the policy, a member or potential member
>> has not made a resource application where they would otherwise have been
>> able to?
>>
>
> Would like to add something here to the question, "have you even been made
> aware of a situation where applicant provided wrong or fake multi-homing
> information just to meet the criteria?"
>
>
>> In other words has the current policy in the eyes of the host masters
>> ever been a barrier to entry?
>>
>> Very valid point.
>
>
> Regards,
>
> Aftab A. Siddiqui
>
>
>


-- 
--
Dean Pemberton

Technical Policy Advisor
InternetNZ
+64 21 920 363 (mob)
d...@internetnz.net.nz

To promote the Internet's benefits and uses, and protect its potential.
*  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-114: Modification in the ASN eligibility criteria

[George Kuo]

Hello Dean,

We are not aware of any potential members who may have decided not to 
apply for IPv4 addresses or AS numbers based on how they have 
interpreted the policy wording.


However, we explain the policy criteria to any potential members who do 
contact APNIC, and those who are not multihoming do not qualify for An 
IPv4 or ASN assignment based on the current policy.


Currently, we don't keep a record of these unsuccessful requests, but
we can begin to keep records in the future if this information is
required.

George K

On 4/02/2015 5:13 am, Dean Pemberton wrote:

Could I ask that the APNIC hostmasters to comment on the following:

Have you ever been made aware of a situation where due of the current
wording of the relevant clauses in the policy, a member or potential
member has not made a resource application where they would otherwise
have been able to?

In other words has the current policy in the eyes of the host masters
ever been a barrier to entry?




On Wednesday, 4 February 2015, Masato Yamanishi mailto:myama...@gmail.com>> wrote:

Dear SIG members

The proposal "prop-114: Modification in the ASN eligibility criteria"
has been sent to the Policy SIG for review.

It  will be presented at the Open Policy Meeting at APNIC 39 in Fukuoka,
Japan on Thursday, 5 March 2015.

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?


Information about this proposal is available at:

http://www.apnic.net/policy/proposals/prop-114


Regards,

Masato





---
prop-114-v001: 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 dictates two eligibility criteria
 and both should be fulfilled in order to get 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.


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 removing multi-homing requirement for the
organization.


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
 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 organization is eligible for an ASN assignment if it:
  - Is planning to use it within next 6 months


5. Advantages / Disadvantages
-

Advantages:

 Removing the mandatory multi-homing requirement from the policy
will
 make sure that organizations are not tempted to provide wrong
 information in order to fulfil the criteria of eligibility.

Disadvantages:

 No disadvantage.


6. Impact on resource holders
-

 No impact on existing resource holders.


7. References
-



--
--
Dean Pemberton

Technical Policy Advisor
InternetNZ
+64 21 920 363 (mob)
d...@internetnz.net.nz 

To promote the Internet's benefits and uses, and protect its potential.


*  sig-policy:  APNIC SIG on resource management policy   *
___
sig-policy mailing list
sig-policy@lists.apnic.net
http://mailman.apnic.net/mailman/list

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

[Dean Pemberton]

So it doesn't look like there is a problem here.

The hostmasters are clear about the current policy, they explain it to
people who contact them.

Am I missing something?  I'm not at all in favour of policy for policy
sake.

What's the problem statement here?

On Thursday, 5 February 2015, George Kuo  wrote:

> Hello Dean,
>
> We are not aware of any potential members who may have decided not to
> apply for IPv4 addresses or AS numbers based on how they have interpreted
> the policy wording.
>
> However, we explain the policy criteria to any potential members who do
> contact APNIC, and those who are not multihoming do not qualify for An IPv4
> or ASN assignment based on the current policy.
>
> Currently, we don't keep a record of these unsuccessful requests, but
> we can begin to keep records in the future if this information is
> required.
>
> George K
>
> On 4/02/2015 5:13 am, Dean Pemberton wrote:
>
>> Could I ask that the APNIC hostmasters to comment on the following:
>>
>> Have you ever been made aware of a situation where due of the current
>> wording of the relevant clauses in the policy, a member or potential
>> member has not made a resource application where they would otherwise
>> have been able to?
>>
>> In other words has the current policy in the eyes of the host masters
>> ever been a barrier to entry?
>>
>>
>>
>>
>> On Wednesday, 4 February 2015, Masato Yamanishi > > wrote:
>>
>> Dear SIG members
>>
>> The proposal "prop-114: Modification in the ASN eligibility criteria"
>> has been sent to the Policy SIG for review.
>>
>> It  will be presented at the Open Policy Meeting at APNIC 39 in
>> Fukuoka,
>> Japan on Thursday, 5 March 2015.
>>
>> 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?
>>
>>
>> Information about this proposal is available at:
>>
>> http://www.apnic.net/policy/proposals/prop-114
>>
>>
>> Regards,
>>
>> Masato
>>
>>
>>
>>
>>
>> ---
>> prop-114-v001: 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 dictates two eligibility
>> criteria
>>  and both should be fulfilled in order to get 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.
>>
>>
>> 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 removing multi-homing requirement for the
>> organization.
>>
>>
>> 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
>>  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 organization is eligible for an ASN assignment if it:
>>   - Is planning to use it within next 6 months
>>
>>
>> 5. Advantages / Disadvantages
>> -
>>
>> Advantages:
>>
>>  Removing the mandatory multi-homing requirement from the policy
>> will
>>  make sure that organizations are not tempted to provide wrong
>>  info

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

[Owen DeLong]

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 
into a room full of people and saying "Everyone who is not here, please raise 
your hand" and concluding from the lack of raised hands that everyone is 
present.

Owen




> On Feb 4, 2015, at 8:09 PM, Dean Pemberton  wrote:
> 
> So it doesn't look like there is a problem here. 
> 
> The hostmasters are clear about the current policy, they explain it to people 
> who contact them. 
> 
> Am I missing something?  I'm not at all in favour of policy for policy sake. 
> 
> What's the problem statement here?
> 
> On Thursday, 5 February 2015, George Kuo  wrote:
>> Hello Dean,
>> 
>> We are not aware of any potential members who may have decided not to apply 
>> for IPv4 addresses or AS numbers based on how they have interpreted the 
>> policy wording.
>> 
>> However, we explain the policy criteria to any potential members who do 
>> contact APNIC, and those who are not multihoming do not qualify for An IPv4 
>> or ASN assignment based on the current policy.
>> 
>> Currently, we don't keep a record of these unsuccessful requests, but
>> we can begin to keep records in the future if this information is
>> required.
>> 
>> George K
>> 
>>> On 4/02/2015 5:13 am, Dean Pemberton wrote:
>>> Could I ask that the APNIC hostmasters to comment on the following:
>>> 
>>> Have you ever been made aware of a situation where due of the current
>>> wording of the relevant clauses in the policy, a member or potential
>>> member has not made a resource application where they would otherwise
>>> have been able to?
>>> 
>>> In other words has the current policy in the eyes of the host masters
>>> ever been a barrier to entry?
>>> 
>>> 
>>> 
>>> 
>>> On Wednesday, 4 February 2015, Masato Yamanishi >> > wrote:
>>> 
>>> Dear SIG members
>>> 
>>> The proposal "prop-114: Modification in the ASN eligibility criteria"
>>> has been sent to the Policy SIG for review.
>>> 
>>> It  will be presented at the Open Policy Meeting at APNIC 39 in Fukuoka,
>>> Japan on Thursday, 5 March 2015.
>>> 
>>> 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?
>>> 
>>> 
>>> Information about this proposal is available at:
>>> 
>>> http://www.apnic.net/policy/proposals/prop-114
>>> 
>>> 
>>> Regards,
>>> 
>>> Masato
>>> 
>>> 
>>> 
>>> 
>>> 
>>> ---
>>> prop-114-v001: 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 dictates two eligibility criteria
>>>  and both should be fulfilled in order to get 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.
>>> 
>>> 
>>> 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 removing multi-homing requirement for the
>>> organization.
>>> 
>>> 
>>> 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
>>>  Policy - https://www.ripe.net/rip

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

[Dean Pemberton]

You're right that it's just one data point.
I'd encourage anyone with any further information to present it.

At the moment I'm not seeing the requirement here.

On Friday, 6 February 2015, Owen DeLong  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 the hostmasters about this issue in the way you did is akin to
> walking into a room full of people and saying "Everyone who is not here,
> please raise your hand" and concluding from the lack of raised hands that
> everyone is present.
>
> Owen
>
>
>
>
> On Feb 4, 2015, at 8:09 PM, Dean Pemberton  > wrote:
>
> So it doesn't look like there is a problem here.
>
> The hostmasters are clear about the current policy, they explain it to
> people who contact them.
>
> Am I missing something?  I'm not at all in favour of policy for policy
> sake.
>
> What's the problem statement here?
>
> On Thursday, 5 February 2015, George Kuo  > wrote:
>
>> Hello Dean,
>>
>> We are not aware of any potential members who may have decided not to
>> apply for IPv4 addresses or AS numbers based on how they have interpreted
>> the policy wording.
>>
>> However, we explain the policy criteria to any potential members who do
>> contact APNIC, and those who are not multihoming do not qualify for An IPv4
>> or ASN assignment based on the current policy.
>>
>> Currently, we don't keep a record of these unsuccessful requests, but
>> we can begin to keep records in the future if this information is
>> required.
>>
>> George K
>>
>> On 4/02/2015 5:13 am, Dean Pemberton wrote:
>>
>>> Could I ask that the APNIC hostmasters to comment on the following:
>>>
>>> Have you ever been made aware of a situation where due of the current
>>> wording of the relevant clauses in the policy, a member or potential
>>> member has not made a resource application where they would otherwise
>>> have been able to?
>>>
>>> In other words has the current policy in the eyes of the host masters
>>> ever been a barrier to entry?
>>>
>>>
>>>
>>>
>>> On Wednesday, 4 February 2015, Masato Yamanishi >> > wrote:
>>>
>>> Dear SIG members
>>>
>>> The proposal "prop-114: Modification in the ASN eligibility criteria"
>>> has been sent to the Policy SIG for review.
>>>
>>> It  will be presented at the Open Policy Meeting at APNIC 39 in
>>> Fukuoka,
>>> Japan on Thursday, 5 March 2015.
>>>
>>> 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?
>>>
>>>
>>> Information about this proposal is available at:
>>>
>>> http://www.apnic.net/policy/proposals/prop-114
>>>
>>>
>>> Regards,
>>>
>>> Masato
>>>
>>>
>>>
>>>
>>>
>>> ---
>>> prop-114-v001: 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 dictates two eligibility
>>> criteria
>>>  and both should be fulfilled in order to get 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.
>>>
>>>
>>> 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 removing multi-homing requirement for the
>>> organization.
>>>
>>>
>>> 3. Situation in other regions
>>> -
>>>
>>> ARIN:
>>>  It is not mandatory but optional to be multi-homed in order get
>>>

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

[Usman Latif]

I support this proposal as well.

Regards,
Usman

  From: Job Snijders 
 To: Masato Yamanishi  
Cc: sig-policy@lists.apnic.net 
 Sent: Wednesday, 4 February 2015, 7:19
 Subject: Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the 
ASN eligibility criteria
   
On Tue, Feb 03, 2015 at 11:57:38AM -0600, Masato Yamanishi wrote:
> 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?

I support this proposal. I appreciate its simplicity.

Kind regards,

Job
*              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 Policy Proposal] prop-114: Modification in the ASN eligibility criteria

[Skeeve Stevens]

hahahahahahahahahah

"...to walking into a room full of people and saying "Everyone who is not
here, please raise your hand" and concluding from the lack of raised hands
that everyone is present."

This made my morning.


...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 Fri, Feb 6, 2015 at 12:57 AM, Owen DeLong  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 the hostmasters about this issue in the way you did is akin to
> walking into a room full of people and saying "Everyone who is not here,
> please raise your hand" and concluding from the lack of raised hands that
> everyone is present.
>
> Owen
>
>
>
>
> On Feb 4, 2015, at 8:09 PM, Dean Pemberton  wrote:
>
> So it doesn't look like there is a problem here.
>
> The hostmasters are clear about the current policy, they explain it to
> people who contact them.
>
> Am I missing something?  I'm not at all in favour of policy for policy
> sake.
>
> What's the problem statement here?
>
> On Thursday, 5 February 2015, George Kuo  wrote:
>
>> Hello Dean,
>>
>> We are not aware of any potential members who may have decided not to
>> apply for IPv4 addresses or AS numbers based on how they have interpreted
>> the policy wording.
>>
>> However, we explain the policy criteria to any potential members who do
>> contact APNIC, and those who are not multihoming do not qualify for An IPv4
>> or ASN assignment based on the current policy.
>>
>> Currently, we don't keep a record of these unsuccessful requests, but
>> we can begin to keep records in the future if this information is
>> required.
>>
>> George K
>>
>> On 4/02/2015 5:13 am, Dean Pemberton wrote:
>>
>>> Could I ask that the APNIC hostmasters to comment on the following:
>>>
>>> Have you ever been made aware of a situation where due of the current
>>> wording of the relevant clauses in the policy, a member or potential
>>> member has not made a resource application where they would otherwise
>>> have been able to?
>>>
>>> In other words has the current policy in the eyes of the host masters
>>> ever been a barrier to entry?
>>>
>>>
>>>
>>>
>>> On Wednesday, 4 February 2015, Masato Yamanishi >> > wrote:
>>>
>>> Dear SIG members
>>>
>>> The proposal "prop-114: Modification in the ASN eligibility criteria"
>>> has been sent to the Policy SIG for review.
>>>
>>> It  will be presented at the Open Policy Meeting at APNIC 39 in
>>> Fukuoka,
>>> Japan on Thursday, 5 March 2015.
>>>
>>> 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?
>>>
>>>
>>> Information about this proposal is available at:
>>>
>>> http://www.apnic.net/policy/proposals/prop-114
>>>
>>>
>>> Regards,
>>>
>>> Masato
>>>
>>>
>>>
>>>
>>>
>>> ---
>>> prop-114-v001: 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 dictates two eligibility
>>> criteria
>>>  and both should be fulfilled in order to get 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.
>>>
>>>
>>> 2. Objective of policy change
>>> -
>>>

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

[Dean Pemberton]

Rather than being a laughing matter this proposal seeks to hand out ASNs
with no more  justification than "I want one".

Can the authors explain why they feel radical change to existing policy is
required?

On Friday, 6 February 2015, Skeeve Stevens  wrote:

> hahahahahahahahahah
>
> "...to walking into a room full of people and saying "Everyone who is not
> here, please raise your hand" and concluding from the lack of raised hands
> that everyone is present."
>
> This made my morning.
>
>
> ...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 Fri, Feb 6, 2015 at 12:57 AM, Owen DeLong  > 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 the hostmasters about this issue in the way you did is akin to
>> walking into a room full of people and saying "Everyone who is not here,
>> please raise your hand" and concluding from the lack of raised hands that
>> everyone is present.
>>
>> Owen
>>
>>
>>
>>
>> On Feb 4, 2015, at 8:09 PM, Dean Pemberton > > wrote:
>>
>> So it doesn't look like there is a problem here.
>>
>> The hostmasters are clear about the current policy, they explain it to
>> people who contact them.
>>
>> Am I missing something?  I'm not at all in favour of policy for policy
>> sake.
>>
>> What's the problem statement here?
>>
>> On Thursday, 5 February 2015, George Kuo > > wrote:
>>
>>> Hello Dean,
>>>
>>> We are not aware of any potential members who may have decided not to
>>> apply for IPv4 addresses or AS numbers based on how they have interpreted
>>> the policy wording.
>>>
>>> However, we explain the policy criteria to any potential members who do
>>> contact APNIC, and those who are not multihoming do not qualify for An IPv4
>>> or ASN assignment based on the current policy.
>>>
>>> Currently, we don't keep a record of these unsuccessful requests, but
>>> we can begin to keep records in the future if this information is
>>> required.
>>>
>>> George K
>>>
>>> On 4/02/2015 5:13 am, Dean Pemberton wrote:
>>>
 Could I ask that the APNIC hostmasters to comment on the following:

 Have you ever been made aware of a situation where due of the current
 wording of the relevant clauses in the policy, a member or potential
 member has not made a resource application where they would otherwise
 have been able to?

 In other words has the current policy in the eyes of the host masters
 ever been a barrier to entry?




 On Wednesday, 4 February 2015, Masato Yamanishi >>> > wrote:

 Dear SIG members

 The proposal "prop-114: Modification in the ASN eligibility
 criteria"
 has been sent to the Policy SIG for review.

 It  will be presented at the Open Policy Meeting at APNIC 39 in
 Fukuoka,
 Japan on Thursday, 5 March 2015.

 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?


 Information about this proposal is available at:

 http://www.apnic.net/policy/proposals/prop-114


 Regards,

 Masato





 ---
 prop-114-v001: 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 dictates two eligibility
 criteria
  and both should be fulfilled in order to get an ASN. The policy
  seems to imply that

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

[Owen DeLong]

I do agree with Dean that this proposal in its current state is too radical, 
but I do support relaxing the requirements to multi home _or_ unique routing 
policy would be an improvement that addresses the issue raised in the problem 
statement. 

Owen




> On Feb 5, 2015, at 12:07, Skeeve Stevens  wrote:
> 
> hahahahahahahahahah
> 
> "...to walking into a room full of people and saying "Everyone who is not 
> here, please raise your hand" and concluding from the lack of raised hands 
> that everyone is present."
> 
> This made my morning.
> 
> 
> ...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 Fri, Feb 6, 2015 at 12:57 AM, Owen DeLong  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 the hostmasters about this issue in the way you did is akin to 
>> walking into a room full of people and saying "Everyone who is not here, 
>> please raise your hand" and concluding from the lack of raised hands that 
>> everyone is present.
>> 
>> Owen
>> 
>> 
>> 
>> 
>>> On Feb 4, 2015, at 8:09 PM, Dean Pemberton  wrote:
>>> 
>>> So it doesn't look like there is a problem here. 
>>> 
>>> The hostmasters are clear about the current policy, they explain it to 
>>> people who contact them. 
>>> 
>>> Am I missing something?  I'm not at all in favour of policy for policy 
>>> sake. 
>>> 
>>> What's the problem statement here?
>>> 
>>> On Thursday, 5 February 2015, George Kuo  wrote:
 Hello Dean,
 
 We are not aware of any potential members who may have decided not to 
 apply for IPv4 addresses or AS numbers based on how they have interpreted 
 the policy wording.
 
 However, we explain the policy criteria to any potential members who do 
 contact APNIC, and those who are not multihoming do not qualify for An 
 IPv4 or ASN assignment based on the current policy.
 
 Currently, we don't keep a record of these unsuccessful requests, but
 we can begin to keep records in the future if this information is
 required.
 
 George K
 
> On 4/02/2015 5:13 am, Dean Pemberton wrote:
> Could I ask that the APNIC hostmasters to comment on the following:
> 
> Have you ever been made aware of a situation where due of the current
> wording of the relevant clauses in the policy, a member or potential
> member has not made a resource application where they would otherwise
> have been able to?
> 
> In other words has the current policy in the eyes of the host masters
> ever been a barrier to entry?
> 
> 
> 
> 
> On Wednesday, 4 February 2015, Masato Yamanishi  > wrote:
> 
> Dear SIG members
> 
> The proposal "prop-114: Modification in the ASN eligibility criteria"
> has been sent to the Policy SIG for review.
> 
> It  will be presented at the Open Policy Meeting at APNIC 39 in 
> Fukuoka,
> Japan on Thursday, 5 March 2015.
> 
> 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?
> 
> 
> Information about this proposal is available at:
> 
> http://www.apnic.net/policy/proposals/prop-114
> 
> 
> Regards,
> 
> Masato
> 
> 
> 
> 
> 
> ---
> prop-114-v001: 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 d

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

[Dean Pemberton]

There is a version of this that I would support, this isn't it.



On Sunday, 8 February 2015, Owen DeLong  wrote:

> I do agree with Dean that this proposal in its current state is too
> radical, but I do support relaxing the requirements to multi home _or_
> unique routing policy would be an improvement that addresses the issue
> raised in the problem statement.
>
> Owen
>
>
>
>
> On Feb 5, 2015, at 12:07, Skeeve Stevens  > wrote:
>
> hahahahahahahahahah
>
> "...to walking into a room full of people and saying "Everyone who is not
> here, please raise your hand" and concluding from the lack of raised hands
> that everyone is present."
>
> This made my morning.
>
>
> ...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 Fri, Feb 6, 2015 at 12:57 AM, Owen DeLong  > 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 the hostmasters about this issue in the way you did is akin to
>> walking into a room full of people and saying "Everyone who is not here,
>> please raise your hand" and concluding from the lack of raised hands that
>> everyone is present.
>>
>> Owen
>>
>>
>>
>>
>> On Feb 4, 2015, at 8:09 PM, Dean Pemberton > > wrote:
>>
>> So it doesn't look like there is a problem here.
>>
>> The hostmasters are clear about the current policy, they explain it to
>> people who contact them.
>>
>> Am I missing something?  I'm not at all in favour of policy for policy
>> sake.
>>
>> What's the problem statement here?
>>
>> On Thursday, 5 February 2015, George Kuo > > wrote:
>>
>>> Hello Dean,
>>>
>>> We are not aware of any potential members who may have decided not to
>>> apply for IPv4 addresses or AS numbers based on how they have interpreted
>>> the policy wording.
>>>
>>> However, we explain the policy criteria to any potential members who do
>>> contact APNIC, and those who are not multihoming do not qualify for An IPv4
>>> or ASN assignment based on the current policy.
>>>
>>> Currently, we don't keep a record of these unsuccessful requests, but
>>> we can begin to keep records in the future if this information is
>>> required.
>>>
>>> George K
>>>
>>> On 4/02/2015 5:13 am, Dean Pemberton wrote:
>>>
 Could I ask that the APNIC hostmasters to comment on the following:

 Have you ever been made aware of a situation where due of the current
 wording of the relevant clauses in the policy, a member or potential
 member has not made a resource application where they would otherwise
 have been able to?

 In other words has the current policy in the eyes of the host masters
 ever been a barrier to entry?




 On Wednesday, 4 February 2015, Masato Yamanishi >>> > wrote:

 Dear SIG members

 The proposal "prop-114: Modification in the ASN eligibility
 criteria"
 has been sent to the Policy SIG for review.

 It  will be presented at the Open Policy Meeting at APNIC 39 in
 Fukuoka,
 Japan on Thursday, 5 March 2015.

 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?


 Information about this proposal is available at:

 http://www.apnic.net/policy/proposals/prop-114


 Regards,

 Masato





 ---
 prop-114-v001: Modification in the ASN eligibility criteria
 ---

 Proposer: Aftab Siddiqui
 aftab.siddi...@gmail.com
 

Skeeve Stevens
 ske...@eintellegonetworks.com
 


 1. Problem statement
 

  The 

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

[Skeeve Stevens]

Dean,

Pleas enlighten us on what version you would support.


...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 Sun, Feb 8, 2015 at 11:49 AM, Dean Pemberton 
wrote:

> There is a version of this that I would support, this isn't it.
>
>
>
> On Sunday, 8 February 2015, Owen DeLong  wrote:
>
>> I do agree with Dean that this proposal in its current state is too
>> radical, but I do support relaxing the requirements to multi home _or_
>> unique routing policy would be an improvement that addresses the issue
>> raised in the problem statement.
>>
>> Owen
>>
>>
>>
>>
>> On Feb 5, 2015, at 12:07, Skeeve Stevens  wrote:
>>
>> hahahahahahahahahah
>>
>> "...to walking into a room full of people and saying "Everyone who is not
>> here, please raise your hand" and concluding from the lack of raised hands
>> that everyone is present."
>>
>> This made my morning.
>>
>>
>> ...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 Fri, Feb 6, 2015 at 12:57 AM, Owen DeLong  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 the hostmasters about this issue in the way you did is akin to
>>> walking into a room full of people and saying "Everyone who is not here,
>>> please raise your hand" and concluding from the lack of raised hands that
>>> everyone is present.
>>>
>>> Owen
>>>
>>>
>>>
>>>
>>> On Feb 4, 2015, at 8:09 PM, Dean Pemberton 
>>> wrote:
>>>
>>> So it doesn't look like there is a problem here.
>>>
>>> The hostmasters are clear about the current policy, they explain it to
>>> people who contact them.
>>>
>>> Am I missing something?  I'm not at all in favour of policy for policy
>>> sake.
>>>
>>> What's the problem statement here?
>>>
>>> On Thursday, 5 February 2015, George Kuo  wrote:
>>>
 Hello Dean,

 We are not aware of any potential members who may have decided not to
 apply for IPv4 addresses or AS numbers based on how they have interpreted
 the policy wording.

 However, we explain the policy criteria to any potential members who do
 contact APNIC, and those who are not multihoming do not qualify for An IPv4
 or ASN assignment based on the current policy.

 Currently, we don't keep a record of these unsuccessful requests, but
 we can begin to keep records in the future if this information is
 required.

 George K

 On 4/02/2015 5:13 am, Dean Pemberton wrote:

> Could I ask that the APNIC hostmasters to comment on the following:
>
> Have you ever been made aware of a situation where due of the current
> wording of the relevant clauses in the policy, a member or potential
> member has not made a resource application where they would otherwise
> have been able to?
>
> In other words has the current policy in the eyes of the host masters
> ever been a barrier to entry?
>
>
>
>
> On Wednesday, 4 February 2015, Masato Yamanishi  > wrote:
>
> Dear SIG members
>
> The proposal "prop-114: Modification in the ASN eligibility
> criteria"
> has been sent to the Policy SIG for review.
>
> It  will be presented at the Open Policy Meeting at APNIC 39 in
> Fukuoka,
> Japan on Thursday, 5 March 2015.
>
> 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?
>
>
> Information about this proposal is a

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

[Dean Pemberton]

Firstly I agree with Randy here.  If you're not multi-homed then your
routing policy can not be 'unique' from your single upstream.  You may wish
it was, but you have no way to enforce this.

Secondly, In considering this policy proposal in conjunction with prop-113,
I am increasingly doubtful that there is anything for me to support here.

I suspect what is happening here is that these proposals (113 and 114) are
conjoined and rather than significantly lowering the bar with regard to
allocation of IPv4 resources, they seek removal of the bar altogether.

There are players within the community who will significantly benefit from
a policy framework with a reduced multi-homing and demonstrated needs
requirement, but those entities are not necessarily the end LIRs.

What these two proposals seek to do is remove all barriers to obtaining
IPv4 addresses and ASNs.
One of the major problems here is that the authors seek to do this one
'cut' at a time.  Almost in an attempt to avoid waking the tiger which is
ARIN's requirement for needs based allocation, or having the APNIC
community discussion around 'needs based' allocation for IPv4 resources.

I would like to see us stop the subterfuge here.

I would like to see both of these policies withdrawn and prop-116 "Removal
of all barriers to allocation of IPv4 and ASN resources" put forward for
debate.  It is only in that way that the true ramifications/impacts of
these smaller policies can be realised and discussed by the community.

Forcing us to debate this clause by clause is a waste of community time and
effort.

I strongly oppose this policy as it is currently written.


Dean


--
Dean Pemberton

Technical Policy Advisor
InternetNZ
+64 21 920 363 (mob)
d...@internetnz.net.nz

To promote the Internet's benefits and uses, and protect its potential.

On Tue, Feb 24, 2015 at 7:38 AM, Masato Yamanishi 
wrote:

> Dear Colleagues,
>
> Regarding prop-114, discussion points are;
>
> 1. Whether completely taking away multi-home requirement or relaxing it by
> adding "or unique routing policy"
> as Owen proposed and ARIN doing.
>
> http://mailman.apnic.net/mailing-lists/sig-policy/archive/2015/02/msg00015.html
>
> http://mailman.apnic.net/mailing-lists/sig-policy/archive/2015/02/msg00044.html
>
> 2. Whether we will relax it for only 4-byte AS or 2-byte also.
> (Please note that we are running out 2-byte AS and it might speed it
> up)
>
> It is very appreciated if you will express your views for these points,
> and also show another points if you have.
>
> Regards,
> Masato
>
>
> 2015-02-07 19:25 GMT-06:00 Skeeve Stevens :
>
> Dean,
>>
>> Pleas enlighten us on what version you would support.
>>
>>
>> ...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 Sun, Feb 8, 2015 at 11:49 AM, Dean Pemberton 
>> wrote:
>>
>>> There is a version of this that I would support, this isn't it.
>>>
>>>
>>>
>>> On Sunday, 8 February 2015, Owen DeLong  wrote:
>>>
 I do agree with Dean that this proposal in its current state is too
 radical, but I do support relaxing the requirements to multi home _or_
 unique routing policy would be an improvement that addresses the issue
 raised in the problem statement.

 Owen




 On Feb 5, 2015, at 12:07, Skeeve Stevens  wrote:

 hahahahahahahahahah

 "...to walking into a room full of people and saying "Everyone who is
 not here, please raise your hand" and concluding from the lack of raised
 hands that everyone is present."

 This made my morning.


 ...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 Fri, Feb 6, 2015 at 12:57 AM, Owen DeLong  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 the hostmasters about this issue in the way you did is akin to
> walking into a room full of people and saying "Everyone who is not here,
> please raise your hand" and concluding from the lack of raised hands that
> everyone is present.
>
> Owen
>
>
>
>
> On Feb 4, 20

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

[Owen DeLong]

> On Feb 23, 2015, at 13:34 , Dean Pemberton  wrote:
> 
> Firstly I agree with Randy here.  If you're not multi-homed then your routing 
> policy can not be 'unique' from your single upstream.  You may wish it was, 
> but you have no way to enforce this.

This is not true.

You can be single homed to a single upstream, but, have other peering 
relationships with other non-upstream ASNs which are also not down-stream. 
These relationships may not be sufficiently visible to convince APNIC that one 
is multihomed, even though technically it is a multihomed situation.

For example, two or more ASNs that exchange peering on a private basis, but do 
not provide transit for each other.

There are other possible situations as well, this is just the simplest example.

> There are players within the community who will significantly benefit from a 
> policy framework with a reduced multi-homing and demonstrated needs 
> requirement, but those entities are not necessarily the end LIRs.

More likely, they are end-user organizations rather than LIRs, but so what? Is 
there a reason not to serve end-user organizations or make their lives easier?

> What these two proposals seek to do is remove all barriers to obtaining IPv4 
> addresses and ASNs.

While I oppose that (and thus completely oppose the other proposal), as stated 
above, I think there are legitimate reasons to allow ASN issuance in some cases 
for organizations that may not meet the multi-homing requirement from an APNIC 
perspective.


> One of the major problems here is that the authors seek to do this one 'cut' 
> at a time.  Almost in an attempt to avoid waking the tiger which is ARIN's 
> requirement for needs based allocation, or having the APNIC community 
> discussion around 'needs based' allocation for IPv4 resources.

I don’t agree here. I think it is more a case that smaller and simpler policy 
proposals that seek to change a single aspect of policy are more likely to 
succeed or fail on their merits, where large complex omnibus proposals have a 
substantial history of failing on community misunderstanding or general 
avoidance of complexity.

> 
> I would like to see us stop the subterfuge here.  
> 

I think that is an unfair accusation, even though I am not a supporter of the 
proposals as written.

I would support the ASN proposal if it were modified as I previously stated, to 
require either multihoming or a unique routing policy.

I will strongly report the removal of all conditions for the issuance of 
resources in any case. I would argue that if you’re going to make that claim 
and insist on discussing this under the terms of your proposed policy, that it 
is arguably equally dishonest not to include IPv6 in the list as well.

Owen


*  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-114: Modification in the ASN eligibility criteria

[Dean Pemberton]

On Wed, Feb 25, 2015 at 6:20 AM, Owen DeLong  wrote:
>> Firstly I agree with Randy here.  If you're not multi-homed then your 
>> routing policy can not be 'unique' from your single upstream.  You may wish 
>> it was, but you have no way to enforce this.
>
> This is not true.
>
> You can be single homed to a single upstream, but, have other peering 
> relationships with other non-upstream ASNs which are also not down-stream. 
> These relationships may not be sufficiently visible to convince APNIC that 
> one is multihomed, even though technically it is a multihomed situation.
>

I don't agree (Damn and we were getting on so well this year  =) ).

I would argue that the situation you describe above DOES constitute multihoming.
If an LIR were connected to an upstream ISP but also wanted to
participate at an IXP I would consider them to be multihomed and
covered under existing APNIC policy.

I couldn't find the strict definition on the APNIC pages as to what
the hostmasters considered multihoming to be, but if one of them can
point us to it then it might help.


> While I oppose that (and thus completely oppose the other proposal), as 
> stated above, I think there are legitimate reasons to allow ASN issuance in 
> some cases for organizations that may not meet the multi-homing requirement 
> from an APNIC perspective.

I really want to find out what those multi-homing requirements are.  I
suspect that they amount to "BGP connections to two or more other
ASNs"
In which case I think we can go back to agreeing.


> I think it is more a case that smaller and simpler policy proposals that seek 
> to change a single aspect of policy are more likely to succeed or fail on 
> their merits, where large complex omnibus proposals have a substantial 
> history of failing on community misunderstanding or general avoidance of 
> complexity.

I can see your point, but taking a smaller simpler approach is only
valid once you have agreed on the larger more strategic direction.  I
don't believe that we have had those conversations.

We are seeing small proposals purporting to talk about multihoming,
but what they are in essence talking about is the much larger topic of
the removal of demonstrated need (as Aftab's clarification in the
other thread confirms beyond doubt.)

There is danger in the death by a thousand cuts.  Many times you can't
see the unintended consequences until you are already down the track
of smaller simpler policy changes.

As we are in Japan I offer a haiku:

A frog in water
doesn’t feel it boil in time.
Do not be that frog.

(http://en.wikipedia.org/wiki/Boiling_frog)


Dean
*  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-114: Modification in the ASN eligibility criteria

[Owen DeLong]

> On Feb 24, 2015, at 12:38 , Dean Pemberton  wrote:
> 
> On Wed, Feb 25, 2015 at 6:20 AM, Owen DeLong  wrote:
>>> Firstly I agree with Randy here.  If you're not multi-homed then your 
>>> routing policy can not be 'unique' from your single upstream.  You may wish 
>>> it was, but you have no way to enforce this.
>> 
>> This is not true.
>> 
>> You can be single homed to a single upstream, but, have other peering 
>> relationships with other non-upstream ASNs which are also not down-stream. 
>> These relationships may not be sufficiently visible to convince APNIC that 
>> one is multihomed, even though technically it is a multihomed situation.
>> 
> 
> I don't agree (Damn and we were getting on so well this year  =) ).
> 
> I would argue that the situation you describe above DOES constitute 
> multihoming.

I agree, but it may not necessarily constitute “multihoming” in a manner that 
is recognized or accepted by the RIR.

Clarification from APNIC staff on the exact behavior from APNIC could render 
this moot.

However, I have past experience where RIRs have rejected peerings with related 
entities and/or private ASNs of third parties as not constituting valid 
“multihoming” whereupon I had to resort to “a unique routing policy”.


> If an LIR were connected to an upstream ISP but also wanted to
> participate at an IXP I would consider them to be multihomed and
> covered under existing APNIC policy.

What if they only connected to the IXP with a single connection? I’ve also 
encountered situations where this is considered “not multihomed” and to be a 
“unique routing policy”.

> 
> I couldn't find the strict definition on the APNIC pages as to what
> the hostmasters considered multihoming to be, but if one of them can
> point us to it then it might help.

Agreed.

> 
> 
>> While I oppose that (and thus completely oppose the other proposal), as 
>> stated above, I think there are legitimate reasons to allow ASN issuance in 
>> some cases for organizations that may not meet the multi-homing requirement 
>> from an APNIC perspective.
> 
> I really want to find out what those multi-homing requirements are.  I
> suspect that they amount to "BGP connections to two or more other
> ASNs"
> In which case I think we can go back to agreeing.

As long as it’s not more specific than that (for example, two or more public 
ASNs or via distinct circuits, etc.).


> 
> 
>> I think it is more a case that smaller and simpler policy proposals that 
>> seek to change a single aspect of policy are more likely to succeed or fail 
>> on their merits, where large complex omnibus proposals have a substantial 
>> history of failing on community misunderstanding or general avoidance of 
>> complexity.
> 
> I can see your point, but taking a smaller simpler approach is only
> valid once you have agreed on the larger more strategic direction.  I
> don't believe that we have had those conversations.

I find that in general, the larger the group you are attempting to discuss 
strategy with, the smaller the chunks necessary for a useful outcome.

YMMV.

> We are seeing small proposals purporting to talk about multihoming,
> but what they are in essence talking about is the much larger topic of
> the removal of demonstrated need (as Aftab's clarification in the
> other thread confirms beyond doubt.)

Upon which clarification, you will notice that I switched to outright 
opposition to that policy. Frankly, you caught a subtlety in the language that 
I missed where I interpreted the proposal to still require justified need 
rather than mere announcement, but a careful re-read and the subsequent 
clarification of intent made it clear that I had erred.

Further, note that I have always opposed this proposal as written, but offered 
as an alternative a much smaller change which I felt met the intent stated by 
the proposer without the radical consequences you and I both seem to agree are 
undesirable.

> There is danger in the death by a thousand cuts.  Many times you can't
> see the unintended consequences until you are already down the track
> of smaller simpler policy changes.

I really don’t think that is a risk in this case.

> As we are in Japan I offer a haiku:
> 
> A frog in water
> doesn’t feel it boil in time.
> Do not be that frog.
> 
> (http://en.wikipedia.org/wiki/Boiling_frog)

I wish I could be at the meeting, but, alas, I’m here in the US looking on from 
afar.

Owen

*  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-114: Modification in the ASN eligibility criteria

[Dean Pemberton]

Looks like a clarification on the definition of multi-homing from the
secretariat is what we need before being able to proceed here.


--
Dean Pemberton

Technical Policy Advisor
InternetNZ
+64 21 920 363 (mob)
d...@internetnz.net.nz

To promote the Internet's benefits and uses, and protect its potential.


On Wed, Feb 25, 2015 at 9:53 AM, Owen DeLong  wrote:
>
>> On Feb 24, 2015, at 12:38 , Dean Pemberton  wrote:
>>
>> On Wed, Feb 25, 2015 at 6:20 AM, Owen DeLong  wrote:
 Firstly I agree with Randy here.  If you're not multi-homed then your 
 routing policy can not be 'unique' from your single upstream.  You may 
 wish it was, but you have no way to enforce this.
>>>
>>> This is not true.
>>>
>>> You can be single homed to a single upstream, but, have other peering 
>>> relationships with other non-upstream ASNs which are also not down-stream. 
>>> These relationships may not be sufficiently visible to convince APNIC that 
>>> one is multihomed, even though technically it is a multihomed situation.
>>>
>>
>> I don't agree (Damn and we were getting on so well this year  =) ).
>>
>> I would argue that the situation you describe above DOES constitute 
>> multihoming.
>
> I agree, but it may not necessarily constitute “multihoming” in a manner that 
> is recognized or accepted by the RIR.
>
> Clarification from APNIC staff on the exact behavior from APNIC could render 
> this moot.
>
> However, I have past experience where RIRs have rejected peerings with 
> related entities and/or private ASNs of third parties as not constituting 
> valid “multihoming” whereupon I had to resort to “a unique routing policy”.
>
>
>> If an LIR were connected to an upstream ISP but also wanted to
>> participate at an IXP I would consider them to be multihomed and
>> covered under existing APNIC policy.
>
> What if they only connected to the IXP with a single connection? I’ve also 
> encountered situations where this is considered “not multihomed” and to be a 
> “unique routing policy”.
>
>>
>> I couldn't find the strict definition on the APNIC pages as to what
>> the hostmasters considered multihoming to be, but if one of them can
>> point us to it then it might help.
>
> Agreed.
>
>>
>>
>>> While I oppose that (and thus completely oppose the other proposal), as 
>>> stated above, I think there are legitimate reasons to allow ASN issuance in 
>>> some cases for organizations that may not meet the multi-homing requirement 
>>> from an APNIC perspective.
>>
>> I really want to find out what those multi-homing requirements are.  I
>> suspect that they amount to "BGP connections to two or more other
>> ASNs"
>> In which case I think we can go back to agreeing.
>
> As long as it’s not more specific than that (for example, two or more public 
> ASNs or via distinct circuits, etc.).
>
>
>>
>>
>>> I think it is more a case that smaller and simpler policy proposals that 
>>> seek to change a single aspect of policy are more likely to succeed or fail 
>>> on their merits, where large complex omnibus proposals have a substantial 
>>> history of failing on community misunderstanding or general avoidance of 
>>> complexity.
>>
>> I can see your point, but taking a smaller simpler approach is only
>> valid once you have agreed on the larger more strategic direction.  I
>> don't believe that we have had those conversations.
>
> I find that in general, the larger the group you are attempting to discuss 
> strategy with, the smaller the chunks necessary for a useful outcome.
>
> YMMV.
>
>> We are seeing small proposals purporting to talk about multihoming,
>> but what they are in essence talking about is the much larger topic of
>> the removal of demonstrated need (as Aftab's clarification in the
>> other thread confirms beyond doubt.)
>
> Upon which clarification, you will notice that I switched to outright 
> opposition to that policy. Frankly, you caught a subtlety in the language 
> that I missed where I interpreted the proposal to still require justified 
> need rather than mere announcement, but a careful re-read and the subsequent 
> clarification of intent made it clear that I had erred.
>
> Further, note that I have always opposed this proposal as written, but 
> offered as an alternative a much smaller change which I felt met the intent 
> stated by the proposer without the radical consequences you and I both seem 
> to agree are undesirable.
>
>> There is danger in the death by a thousand cuts.  Many times you can't
>> see the unintended consequences until you are already down the track
>> of smaller simpler policy changes.
>
> I really don’t think that is a risk in this case.
>
>> As we are in Japan I offer a haiku:
>>
>> A frog in water
>> doesn’t feel it boil in time.
>> Do not be that frog.
>>
>> (http://en.wikipedia.org/wiki/Boiling_frog)
>
> I wish I could be at the meeting, but, alas, I’m here in the US looking on 
> from afar.
>
> Owen
>
*  sig-policy:  APNIC SIG on resource management policy   

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

[Raphael Ho]

I¹m with Dean on both counts.

My opinion is, if you are buying a single homed transit + peering, you are
multihoming.

However, if you are sub-allocated addresses from your upstream (non
portable) + peering, you are doing something undesirable (in my personal
opinion. Yours personal opinion may vary)

I think if you have a portable address block, and have demonstrated need
for an ASN (hint: just say peering), then you should be able to get one or
more (hint: just say discontiguous network) - which is not very different
from the current policy.

On 25/2/15 5:02 am, "Dean Pemberton"  wrote:

>Looks like a clarification on the definition of multi-homing from the
>secretariat is what we need before being able to proceed here.
>
>
>--
>Dean Pemberton
>
>Technical Policy Advisor
>InternetNZ
>+64 21 920 363 (mob)
>d...@internetnz.net.nz
>
>To promote the Internet's benefits and uses, and protect its potential.
>
>
>On Wed, Feb 25, 2015 at 9:53 AM, Owen DeLong  wrote:
>>
>>> On Feb 24, 2015, at 12:38 , Dean Pemberton 
>>>wrote:
>>>
>>> On Wed, Feb 25, 2015 at 6:20 AM, Owen DeLong  wrote:
> Firstly I agree with Randy here.  If you're not multi-homed then
>your routing policy can not be 'unique' from your single upstream.
>You may wish it was, but you have no way to enforce this.

 This is not true.

 You can be single homed to a single upstream, but, have other peering
relationships with other non-upstream ASNs which are also not
down-stream. These relationships may not be sufficiently visible to
convince APNIC that one is multihomed, even though technically it is a
multihomed situation.

>>>
>>> I don't agree (Damn and we were getting on so well this year  =) ).
>>>
>>> I would argue that the situation you describe above DOES constitute
>>>multihoming.
>>
>> I agree, but it may not necessarily constitute ³multihoming² in a
>>manner that is recognized or accepted by the RIR.
>>
>> Clarification from APNIC staff on the exact behavior from APNIC could
>>render this moot.
>>
>> However, I have past experience where RIRs have rejected peerings with
>>related entities and/or private ASNs of third parties as not
>>constituting valid ³multihoming² whereupon I had to resort to ³a unique
>>routing policy².
>>
>>
>>> If an LIR were connected to an upstream ISP but also wanted to
>>> participate at an IXP I would consider them to be multihomed and
>>> covered under existing APNIC policy.
>>
>> What if they only connected to the IXP with a single connection? I¹ve
>>also encountered situations where this is considered ³not multihomed²
>>and to be a ³unique routing policy².
>>
>>>
>>> I couldn't find the strict definition on the APNIC pages as to what
>>> the hostmasters considered multihoming to be, but if one of them can
>>> point us to it then it might help.
>>
>> Agreed.
>>
>>>
>>>
 While I oppose that (and thus completely oppose the other proposal),
as stated above, I think there are legitimate reasons to allow ASN
issuance in some cases for organizations that may not meet the
multi-homing requirement from an APNIC perspective.
>>>
>>> I really want to find out what those multi-homing requirements are.  I
>>> suspect that they amount to "BGP connections to two or more other
>>> ASNs"
>>> In which case I think we can go back to agreeing.
>>
>> As long as it¹s not more specific than that (for example, two or more
>>public ASNs or via distinct circuits, etc.).
>>
>>
>>>
>>>
 I think it is more a case that smaller and simpler policy proposals
that seek to change a single aspect of policy are more likely to
succeed or fail on their merits, where large complex omnibus proposals
have a substantial history of failing on community misunderstanding or
general avoidance of complexity.
>>>
>>> I can see your point, but taking a smaller simpler approach is only
>>> valid once you have agreed on the larger more strategic direction.  I
>>> don't believe that we have had those conversations.
>>
>> I find that in general, the larger the group you are attempting to
>>discuss strategy with, the smaller the chunks necessary for a useful
>>outcome.
>>
>> YMMV.
>>
>>> We are seeing small proposals purporting to talk about multihoming,
>>> but what they are in essence talking about is the much larger topic of
>>> the removal of demonstrated need (as Aftab's clarification in the
>>> other thread confirms beyond doubt.)
>>
>> Upon which clarification, you will notice that I switched to outright
>>opposition to that policy. Frankly, you caught a subtlety in the
>>language that I missed where I interpreted the proposal to still require
>>justified need rather than mere announcement, but a careful re-read and
>>the subsequent clarification of intent made it clear that I had erred.
>>
>> Further, note that I have always opposed this proposal as written, but
>>offered as an alternative a much smaller change which I felt met the
>>intent stated by the proposer without th

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

[Guangliang Pan]

Hi Dean and All,

According to the current APNIC ASN policy document, the definition of 
multihomed is as below.

http://www.apnic.net/policy/asn-policy#3.4

3.4 Multihomed

A multi-homed AS is one which is connected to more than one other AS. An AS 
also qualifies as multihomed if it is connected to a public Internet Exchange 
Point.

In the ASN request form, you will be asked to provide the estimate ASN 
implementation date, two peer AS numbers and their contact details. It is also 
acceptable if your network only connect to an IXP. 

Best regards,

Guangliang
=

-Original Message-
From: sig-policy-boun...@lists.apnic.net 
[mailto:sig-policy-boun...@lists.apnic.net] On Behalf Of Dean Pemberton
Sent: Wednesday, 25 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 to proceed here.


--
Dean Pemberton

Technical Policy Advisor
InternetNZ
+64 21 920 363 (mob)
d...@internetnz.net.nz

To promote the Internet's benefits and uses, and protect its potential.


On Wed, Feb 25, 2015 at 9:53 AM, Owen DeLong  wrote:
>
>> On Feb 24, 2015, at 12:38 , Dean Pemberton  wrote:
>>
>> On Wed, Feb 25, 2015 at 6:20 AM, Owen DeLong  wrote:
>>>> Firstly I agree with Randy here.  If you're not multi-homed then your 
>>>> routing policy can not be 'unique' from your single upstream.  You may 
>>>> wish it was, but you have no way to enforce this.
>>>
>>> This is not true.
>>>
>>> You can be single homed to a single upstream, but, have other peering 
>>> relationships with other non-upstream ASNs which are also not down-stream. 
>>> These relationships may not be sufficiently visible to convince APNIC that 
>>> one is multihomed, even though technically it is a multihomed situation.
>>>
>>
>> I don't agree (Damn and we were getting on so well this year  =) ).
>>
>> I would argue that the situation you describe above DOES constitute 
>> multihoming.
>
> I agree, but it may not necessarily constitute “multihoming” in a manner that 
> is recognized or accepted by the RIR.
>
> Clarification from APNIC staff on the exact behavior from APNIC could render 
> this moot.
>
> However, I have past experience where RIRs have rejected peerings with 
> related entities and/or private ASNs of third parties as not constituting 
> valid “multihoming” whereupon I had to resort to “a unique routing policy”.
>
>
>> If an LIR were connected to an upstream ISP but also wanted to 
>> participate at an IXP I would consider them to be multihomed and 
>> covered under existing APNIC policy.
>
> What if they only connected to the IXP with a single connection? I’ve also 
> encountered situations where this is considered “not multihomed” and to be a 
> “unique routing policy”.
>
>>
>> I couldn't find the strict definition on the APNIC pages as to what 
>> the hostmasters considered multihoming to be, but if one of them can 
>> point us to it then it might help.
>
> Agreed.
>
>>
>>
>>> While I oppose that (and thus completely oppose the other proposal), as 
>>> stated above, I think there are legitimate reasons to allow ASN issuance in 
>>> some cases for organizations that may not meet the multi-homing requirement 
>>> from an APNIC perspective.
>>
>> I really want to find out what those multi-homing requirements are.  
>> I suspect that they amount to "BGP connections to two or more other 
>> ASNs"
>> In which case I think we can go back to agreeing.
>
> As long as it’s not more specific than that (for example, two or more public 
> ASNs or via distinct circuits, etc.).
>
>
>>
>>
>>> I think it is more a case that smaller and simpler policy proposals that 
>>> seek to change a single aspect of policy are more likely to succeed or fail 
>>> on their merits, where large complex omnibus proposals have a substantial 
>>> history of failing on community misunderstanding or general avoidance of 
>>> complexity.
>>
>> I can see your point, but taking a smaller simpler approach is only 
>> valid once you have agreed on the larger more strategic direction.  I 
>> don't believe that we have had those conversations.
>
> I find that in general, the larger the group you are attempting to discuss 
> strategy with, the smaller the chunks necessary for a useful outcome.
>
> YMMV.
>
>> We are seeing small proposals purporting t

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

[Dean Pemberton]

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


--
Dean Pemberton

Technical Policy Advisor
InternetNZ
+64 21 920 363 (mob)
d...@internetnz.net.nz

To promote the Internet's benefits and uses, and protect its potential.


On Wed, Feb 25, 2015 at 5:05 PM, Guangliang Pan  wrote:
> Hi Dean and All,
>
> According to the current APNIC ASN policy document, the definition of 
> multihomed is as below.
>
> http://www.apnic.net/policy/asn-policy#3.4
>
> 3.4 Multihomed
>
> A multi-homed AS is one which is connected to more than one other AS. An AS 
> also qualifies as multihomed if it is connected to a public Internet Exchange 
> Point.
>
> In the ASN request form, you will be asked to provide the estimate ASN 
> implementation date, two peer AS numbers and their contact details. It is 
> also acceptable if your network only connect to an IXP.
>
> Best regards,
>
> Guangliang
> =
>
> -Original Message-
> From: sig-policy-boun...@lists.apnic.net 
> [mailto:sig-policy-boun...@lists.apnic.net] On Behalf Of Dean Pemberton
> Sent: Wednesday, 25 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 to proceed here.
>
>
> --
> Dean Pemberton
>
> Technical Policy Advisor
> InternetNZ
> +64 21 920 363 (mob)
> d...@internetnz.net.nz
>
> To promote the Internet's benefits and uses, and protect its potential.
>
>
> On Wed, Feb 25, 2015 at 9:53 AM, Owen DeLong  wrote:
>>
>>> On Feb 24, 2015, at 12:38 , Dean Pemberton  wrote:
>>>
>>> On Wed, Feb 25, 2015 at 6:20 AM, Owen DeLong  wrote:
>>>>> Firstly I agree with Randy here.  If you're not multi-homed then your 
>>>>> routing policy can not be 'unique' from your single upstream.  You may 
>>>>> wish it was, but you have no way to enforce this.
>>>>
>>>> This is not true.
>>>>
>>>> You can be single homed to a single upstream, but, have other peering 
>>>> relationships with other non-upstream ASNs which are also not down-stream. 
>>>> These relationships may not be sufficiently visible to convince APNIC that 
>>>> one is multihomed, even though technically it is a multihomed situation.
>>>>
>>>
>>> I don't agree (Damn and we were getting on so well this year  =) ).
>>>
>>> I would argue that the situation you describe above DOES constitute 
>>> multihoming.
>>
>> I agree, but it may not necessarily constitute “multihoming” in a manner 
>> that is recognized or accepted by the RIR.
>>
>> Clarification from APNIC staff on the exact behavior from APNIC could render 
>> this moot.
>>
>> However, I have past experience where RIRs have rejected peerings with 
>> related entities and/or private ASNs of third parties as not constituting 
>> valid “multihoming” whereupon I had to resort to “a unique routing policy”.
>>
>>
>>> If an LIR were connected to an upstream ISP but also wanted to
>>> participate at an IXP I would consider them to be multihomed and
>>> covered under existing APNIC policy.
>>
>> What if they only connected to the IXP with a single connection? I’ve also 
>> encountered situations where this is considered “not multihomed” and to be a 
>> “unique routing policy”.
>>
>>>
>>> I couldn't find the strict definition on the APNIC pages as to what
>>> the hostmasters considered multihoming to be, but if one of them can
>>> point us to it then it might help.
>>
>> Agreed.
>>
>>>
>>>
>>>> While I oppose that (and thus completely oppose the other proposal), as 
>>>> stated above, I think there are legitimate reasons to allow ASN issuance 
>>>> in some cases for organizations that may not meet the multi-homing 
>>>> requirement from an APNIC perspective.
>>>
>>> I really want to find out what those multi-homing requirements are.
>>> I suspect that they amount to "BGP connections to two or more other
>>> ASNs"
>>> In which case I think we can go back to agreeing.
>>
>> As long as it’s not more specific than that (for example, two or more public 
>> ASNs or via distinct circuits, 

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-114: Modification in the ASN eligibility criteria

[Aftab Siddiqui]

Thanks Guangliang for the update,


> According to the current APNIC ASN policy document, the definition of
> multihomed is as below.
>
> http://www.apnic.net/policy/asn-policy#3.4
>
> 3.4 Multihomed
>
> A multi-homed AS is one which is connected to more than one other AS. An
> AS also qualifies as multihomed if it is connected to a public Internet
> Exchange Point.
>
> In the ASN request form, you will be asked to provide the estimate ASN
> implementation date, two peer AS numbers and their contact details. It is
> also acceptable if your network only connect to an IXP.
>

So what if I only have one upstream provider and doesn't have a Public IX
in place? What If I just whois any member from my country and provide AS
numbers and contact details publicly available? Do you check back after 3
months that the AS you provided to the applicant is actually peering with
the ones they mentioned in the application? Do you send email notification
to those contacts provided in the application that XYZ has mentioned your
AS to be peer with in future?

Regards,

Aftab A. Siddiqui.
*  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-114: Modification in the ASN eligibility criteria

[Dean Pemberton]

Members potentially lying on their resource application forms is not
sufficient justification to remove all the rules entirely.
If someone lies on their a countries visa application about a previous
conviction for example, thats not justification for the entire country
to just give up issuing visas.

It sounds like you are accusing the hostmasters of doing an inadequate
job of checking policy compliance of member applications for
resources.  Perhaps this is something that you'd like to take up with
them directly rather than proposing that we remove all the rules in
the existing policies.


Regards,
Dean
--
Dean Pemberton

Technical Policy Advisor
InternetNZ
+64 21 920 363 (mob)
d...@internetnz.net.nz

To promote the Internet's benefits and uses, and protect its potential.


On Wed, Feb 25, 2015 at 7:25 PM, Aftab Siddiqui
 wrote:
> Thanks Guangliang for the update,
>
>>
>> According to the current APNIC ASN policy document, the definition of
>> multihomed is as below.
>>
>> http://www.apnic.net/policy/asn-policy#3.4
>>
>> 3.4 Multihomed
>>
>> A multi-homed AS is one which is connected to more than one other AS. An
>> AS also qualifies as multihomed if it is connected to a public Internet
>> Exchange Point.
>>
>> In the ASN request form, you will be asked to provide the estimate ASN
>> implementation date, two peer AS numbers and their contact details. It is
>> also acceptable if your network only connect to an IXP.
>
>
> So what if I only have one upstream provider and doesn't have a Public IX in
> place? What If I just whois any member from my country and provide AS
> numbers and contact details publicly available? Do you check back after 3
> months that the AS you provided to the applicant is actually peering with
> the ones they mentioned in the application? Do you send email notification
> to those contacts provided in the application that XYZ has mentioned your AS
> to be peer with in future?
>
> Regards,
>
> Aftab A. Siddiqui.
*  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-114: Modification in the ASN eligibility criteria

[Skeeve Stevens]

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 convenience of being able to add
these things easily.

Lets say I was a company with a /23 and upstream into Telstra Only.  If I
had my own ASN and was announcing to Telstra, then at any time I could add
another ISP, IXP, direct peering without having to go apply for an ASN,
reconfigure my network to bring the announcement in-house, etc.

I also might want to maintain a single provider, but be able to migrate
easily to another provider without having to rely on the providers to do
the "right thing" while changing announcements between them.

I think this policy has VERY valid applications for many smaller entities
to be able to have an ASN without having to be multi-homed either
initially, or maintain that multi-homing.

As Randy used to say - Why do you have the right to tell me how to manage
my network?  If I want to be multi-homed, or change my mind and not be, it
is none of your damn business.

I think this policy change reflects the changing way for businesses to get
online since APNIC has run out of IP's, and are often charging significant
amounts of money - so people are going to APNIC directly - which they are
entitled to do.  And being flexible and being able to change their
circumstances is a more common thing nowadays.

If you want, suggest charging for ASN's... but don't tell networks how they
should be connected at any time.

Btw... I am happy for this to apply ONLY to ASN4 and not ASN2.




...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 Wed, Feb 25, 2015 at 3:33 PM, Dean Pemberton 
wrote:

> Members potentially lying on their resource application forms is not
> sufficient justification to remove all the rules entirely.
> If someone lies on their a countries visa application about a previous
> conviction for example, thats not justification for the entire country
> to just give up issuing visas.
>
> It sounds like you are accusing the hostmasters of doing an inadequate
> job of checking policy compliance of member applications for
> resources.  Perhaps this is something that you'd like to take up with
> them directly rather than proposing that we remove all the rules in
> the existing policies.
>
>
> Regards,
> Dean
> --
> Dean Pemberton
>
> Technical Policy Advisor
> InternetNZ
> +64 21 920 363 (mob)
> d...@internetnz.net.nz
>
> To promote the Internet's benefits and uses, and protect its potential.
>
>
> On Wed, Feb 25, 2015 at 7:25 PM, Aftab Siddiqui
>  wrote:
> > Thanks Guangliang for the update,
> >
> >>
> >> According to the current APNIC ASN policy document, the definition of
> >> multihomed is as below.
> >>
> >> http://www.apnic.net/policy/asn-policy#3.4
> >>
> >> 3.4 Multihomed
> >>
> >> A multi-homed AS is one which is connected to more than one other AS. An
> >> AS also qualifies as multihomed if it is connected to a public Internet
> >> Exchange Point.
> >>
> >> In the ASN request form, you will be asked to provide the estimate ASN
> >> implementation date, two peer AS numbers and their contact details. It
> is
> >> also acceptable if your network only connect to an IXP.
> >
> >
> > So what if I only have one upstream provider and doesn't have a Public
> IX in
> > place? What If I just whois any member from my country and provide AS
> > numbers and contact details publicly available? Do you check back after 3
> > months that the AS you provided to the applicant is actually peering with
> > the ones they mentioned in the application? Do you send email
> notification
> > to those contacts provided in the application that XYZ has mentioned
> your AS
> > to be peer with in future?
> >
> > Regards,
> >
> > Aftab A. Siddiqui.
> *  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 Policy Proposal] prop-114: Modification in the ASN eligibility criteria

[Raphael Ho]

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 since
they will require an ASN to peer/multihome at some point in the future
(which I do agree)

Currently they all have to "commit fraud² in order to get an ASN, and I
guess some religion takes that more seriously than others.

Would we the proposal be acceptable if we reworded the proposal to say
something on the lines of

³Eligible LIRs with APNIC Assigned Portable addresses are also eligible
for as ASN²?

This would cover the use case without opening the floodgates.

Thoughts?

Raf


On 25/2/15 2:33 pm, "Dean Pemberton"  wrote:

>Members potentially lying on their resource application forms is not
>sufficient justification to remove all the rules entirely.
>If someone lies on their a countries visa application about a previous
>conviction for example, thats not justification for the entire country
>to just give up issuing visas.
>
>It sounds like you are accusing the hostmasters of doing an inadequate
>job of checking policy compliance of member applications for
>resources.  Perhaps this is something that you'd like to take up with
>them directly rather than proposing that we remove all the rules in
>the existing policies.
>
>
>Regards,
>Dean
>--
>Dean Pemberton
>
>Technical Policy Advisor
>InternetNZ
>+64 21 920 363 (mob)
>d...@internetnz.net.nz
>
>To promote the Internet's benefits and uses, and protect its potential.
>
>
>On Wed, Feb 25, 2015 at 7:25 PM, Aftab Siddiqui
> wrote:
>> Thanks Guangliang for the update,
>>
>>>
>>> According to the current APNIC ASN policy document, the definition of
>>> multihomed is as below.
>>>
>>> http://www.apnic.net/policy/asn-policy#3.4
>>>
>>> 3.4 Multihomed
>>>
>>> A multi-homed AS is one which is connected to more than one other AS.
>>>An
>>> AS also qualifies as multihomed if it is connected to a public Internet
>>> Exchange Point.
>>>
>>> In the ASN request form, you will be asked to provide the estimate ASN
>>> implementation date, two peer AS numbers and their contact details. It
>>>is
>>> also acceptable if your network only connect to an IXP.
>>
>>
>> So what if I only have one upstream provider and doesn't have a Public
>>IX in
>> place? What If I just whois any member from my country and provide AS
>> numbers and contact details publicly available? Do you check back after
>>3
>> months that the AS you provided to the applicant is actually peering
>>with
>> the ones they mentioned in the application? Do you send email
>>notification
>> to those contacts provided in the application that XYZ has mentioned
>>your AS
>> to be peer with in future?
>>
>> Regards,
>>
>> Aftab A. Siddiqui.
>*  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 Policy Proposal] prop-114: Modification in the ASN eligibility criteria

[Skeeve Stevens]

Agreed... Aftabs use case is one of many... the others I just posted about.


...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 Wed, Feb 25, 2015 at 3:47 PM, Raphael Ho 
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 since
> they will require an ASN to peer/multihome at some point in the future
> (which I do agree)
>
> Currently they all have to "commit fraud² in order to get an ASN, and I
> guess some religion takes that more seriously than others.
>
> Would we the proposal be acceptable if we reworded the proposal to say
> something on the lines of
>
> ³Eligible LIRs with APNIC Assigned Portable addresses are also eligible
> for as ASN²?
>
> This would cover the use case without opening the floodgates.
>
> Thoughts?
>
> Raf
>
>
> On 25/2/15 2:33 pm, "Dean Pemberton"  wrote:
>
> >Members potentially lying on their resource application forms is not
> >sufficient justification to remove all the rules entirely.
> >If someone lies on their a countries visa application about a previous
> >conviction for example, thats not justification for the entire country
> >to just give up issuing visas.
> >
> >It sounds like you are accusing the hostmasters of doing an inadequate
> >job of checking policy compliance of member applications for
> >resources.  Perhaps this is something that you'd like to take up with
> >them directly rather than proposing that we remove all the rules in
> >the existing policies.
> >
> >
> >Regards,
> >Dean
> >--
> >Dean Pemberton
> >
> >Technical Policy Advisor
> >InternetNZ
> >+64 21 920 363 (mob)
> >d...@internetnz.net.nz
> >
> >To promote the Internet's benefits and uses, and protect its potential.
> >
> >
> >On Wed, Feb 25, 2015 at 7:25 PM, Aftab Siddiqui
> > wrote:
> >> Thanks Guangliang for the update,
> >>
> >>>
> >>> According to the current APNIC ASN policy document, the definition of
> >>> multihomed is as below.
> >>>
> >>> http://www.apnic.net/policy/asn-policy#3.4
> >>>
> >>> 3.4 Multihomed
> >>>
> >>> A multi-homed AS is one which is connected to more than one other AS.
> >>>An
> >>> AS also qualifies as multihomed if it is connected to a public Internet
> >>> Exchange Point.
> >>>
> >>> In the ASN request form, you will be asked to provide the estimate ASN
> >>> implementation date, two peer AS numbers and their contact details. It
> >>>is
> >>> also acceptable if your network only connect to an IXP.
> >>
> >>
> >> So what if I only have one upstream provider and doesn't have a Public
> >>IX in
> >> place? What If I just whois any member from my country and provide AS
> >> numbers and contact details publicly available? Do you check back after
> >>3
> >> months that the AS you provided to the applicant is actually peering
> >>with
> >> the ones they mentioned in the application? Do you send email
> >>notification
> >> to those contacts provided in the application that XYZ has mentioned
> >>your AS
> >> to be peer with in future?
> >>
> >> Regards,
> >>
> >> Aftab A. Siddiqui.
> >*  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
>
*  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-114: Modification in the ASN eligibility criteria

[Philip Smith]

Dean Pemberton wrote on 25/02/2015 15:06 :
> 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.

Same, I simply don't understand what problem is trying to be solved here.

If an organisation is connected to only one other organisation, there is
no need for an ASN. If these two orgs want to use BGP, that's a private
matter, and is what private ASNs are for - and there are now around 1
billion of those.

If an organisation needs to connect to at least two other ASNs, then
they qualify under the APNIC definition which Guanliang shared.

philip
--

> 
> I do not support the proposal
> 
> 
> --
> Dean Pemberton
> 
> Technical Policy Advisor
> InternetNZ
> +64 21 920 363 (mob)
> d...@internetnz.net.nz
> 
> To promote the Internet's benefits and uses, and protect its potential.
> 
> 
> On Wed, Feb 25, 2015 at 5:05 PM, Guangliang Pan  wrote:
>> Hi Dean and All,
>>
>> According to the current APNIC ASN policy document, the definition of 
>> multihomed is as below.
>>
>> http://www.apnic.net/policy/asn-policy#3.4
>>
>> 3.4 Multihomed
>>
>> A multi-homed AS is one which is connected to more than one other AS. An AS 
>> also qualifies as multihomed if it is connected to a public Internet 
>> Exchange Point.
>>
>> In the ASN request form, you will be asked to provide the estimate ASN 
>> implementation date, two peer AS numbers and their contact details. It is 
>> also acceptable if your network only connect to an IXP.
>>
>> Best regards,
>>
>> Guangliang
>> =
>>
>> -Original Message-
>> From: sig-policy-boun...@lists.apnic.net 
>> [mailto:sig-policy-boun...@lists.apnic.net] On Behalf Of Dean Pemberton
>> Sent: Wednesday, 25 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 to proceed here.
>>
>>
>> --
>> Dean Pemberton
>>
>> Technical Policy Advisor
>> InternetNZ
>> +64 21 920 363 (mob)
>> d...@internetnz.net.nz
>>
>> To promote the Internet's benefits and uses, and protect its potential.
>>
>>
>> On Wed, Feb 25, 2015 at 9:53 AM, Owen DeLong  wrote:
>>>
>>>> On Feb 24, 2015, at 12:38 , Dean Pemberton  wrote:
>>>>
>>>> On Wed, Feb 25, 2015 at 6:20 AM, Owen DeLong  wrote:
>>>>>> Firstly I agree with Randy here.  If you're not multi-homed then your 
>>>>>> routing policy can not be 'unique' from your single upstream.  You may 
>>>>>> wish it was, but you have no way to enforce this.
>>>>>
>>>>> This is not true.
>>>>>
>>>>> You can be single homed to a single upstream, but, have other peering 
>>>>> relationships with other non-upstream ASNs which are also not 
>>>>> down-stream. These relationships may not be sufficiently visible to 
>>>>> convince APNIC that one is multihomed, even though technically it is a 
>>>>> multihomed situation.
>>>>>
>>>>
>>>> I don't agree (Damn and we were getting on so well this year  =) ).
>>>>
>>>> I would argue that the situation you describe above DOES constitute 
>>>> multihoming.
>>>
>>> I agree, but it may not necessarily constitute “multihoming” in a manner 
>>> that is recognized or accepted by the RIR.
>>>
>>> Clarification from APNIC staff on the exact behavior from APNIC could 
>>> render this moot.
>>>
>>> However, I have past experience where RIRs have rejected peerings with 
>>> related entities and/or private ASNs of third parties as not constituting 
>>> valid “multihoming” whereupon I had to resort to “a unique routing policy”.
>>>
>>>
>>>> If an LIR were connected to an upstream ISP but also wanted to
>>>> participate at an IXP I would consider them to be multihomed and
>>>> covered under existing APNIC policy.
>>>
>>> What if they only connected to the IXP with a single connection? I’ve also 
>>> encountered situations where this is considered “not multihomed” and to be 
>>> a “unique routing policy”.
>>>
>>>>
>>>> I couldn

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

[Gaurab Raj Upadhaya]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

A slight side tracking here - looking for some opinions.

how much of the cruft on IRR system is there because organizations
with allocated prefixes have to depend on their upstreams for the
creation of their route objects, which then doesn't get removed when
the relationship ends.

- -gaurab


-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)

iEYEARECAAYFAlTtgaUACgkQSo7fU26F3X1qPgCgp64/H56nfdbrXfyc6Q42yOqV
SE4AoMyXqwqjFYrfjLo7CTNywkTlAEGE
=d+RP
-END PGP SIGNATURE-
*  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-114: Modification in the ASN eligibility criteria

[Skeeve Stevens]

Please see my other email Phil.. there is very valid reasons for this
policy change.


...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 ;  <http://twitter.com/networkceoau>
linkedin.com/in/skeeve

twitter.com/theispguy ; blog: www.theispguy.com


IP Address Brokering - Introducing sellers and buyers

On Wed, Feb 25, 2015 at 4:25 PM, Philip Smith  wrote:

> Dean Pemberton wrote on 25/02/2015 15:06 :
> > 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.
>
> Same, I simply don't understand what problem is trying to be solved here.
>
> If an organisation is connected to only one other organisation, there is
> no need for an ASN. If these two orgs want to use BGP, that's a private
> matter, and is what private ASNs are for - and there are now around 1
> billion of those.
>
> If an organisation needs to connect to at least two other ASNs, then
> they qualify under the APNIC definition which Guanliang shared.
>
> philip
> --
>
> >
> > I do not support the proposal
> >
> >
> > --
> > Dean Pemberton
> >
> > Technical Policy Advisor
> > InternetNZ
> > +64 21 920 363 (mob)
> > d...@internetnz.net.nz
> >
> > To promote the Internet's benefits and uses, and protect its potential.
> >
> >
> > On Wed, Feb 25, 2015 at 5:05 PM, Guangliang Pan  wrote:
> >> Hi Dean and All,
> >>
> >> According to the current APNIC ASN policy document, the definition of
> multihomed is as below.
> >>
> >> http://www.apnic.net/policy/asn-policy#3.4
> >>
> >> 3.4 Multihomed
> >>
> >> A multi-homed AS is one which is connected to more than one other AS.
> An AS also qualifies as multihomed if it is connected to a public Internet
> Exchange Point.
> >>
> >> In the ASN request form, you will be asked to provide the estimate ASN
> implementation date, two peer AS numbers and their contact details. It is
> also acceptable if your network only connect to an IXP.
> >>
> >> Best regards,
> >>
> >> Guangliang
> >> =========
> >>
> >> -Original Message-
> >> From: sig-policy-boun...@lists.apnic.net [mailto:
> sig-policy-boun...@lists.apnic.net] On Behalf Of Dean Pemberton
> >> Sent: Wednesday, 25 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 to proceed here.
> >>
> >>
> >> --
> >> Dean Pemberton
> >>
> >> Technical Policy Advisor
> >> InternetNZ
> >> +64 21 920 363 (mob)
> >> d...@internetnz.net.nz
> >>
> >> To promote the Internet's benefits and uses, and protect its potential.
> >>
> >>
> >> On Wed, Feb 25, 2015 at 9:53 AM, Owen DeLong  wrote:
> >>>
> >>>> On Feb 24, 2015, at 12:38 , Dean Pemberton 
> wrote:
> >>>>
> >>>> On Wed, Feb 25, 2015 at 6:20 AM, Owen DeLong  wrote:
> >>>>>> Firstly I agree with Randy here.  If you're not multi-homed then
> your routing policy can not be 'unique' from your single upstream.  You may
> wish it was, but you have no way to enforce this.
> >>>>>
> >>>>> This is not true.
> >>>>>
> >>>>> You can be single homed to a single upstream, but, have other
> peering relationships with other non-upstream ASNs which are also not
> down-stream. These relationships may not be sufficiently visible to
> convince APNIC that one is multihomed, even though technically it is a
> multihomed situation.
> >>>>>
> >>>>
> >>>> I don't agree (Damn and we were getting on so well this year  =) ).
> >>>>
> >>>> I would argue that the situation you describe above DOES constitute
> multihoming.
> >>>
> >>> I agree, but it may not necessarily constitute “multihoming” in a
> manner that is recognized or accepted by the RIR.
> >>>
> >>> Clarification from APNIC staff on the exact behavior from APNIC could
> render this moot.
> >>&

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

[Gaurab Raj Upadhaya]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Guangliang,

can you clarify these questions for me.

If a provider connects to a v4 only transit provider over a physical
circuit, but does v6 transit from Hurricane Electric over a tunnel,
would that be considered multihoming ?


- -gaurab



On 2/25/15 4:05 AM, Guangliang Pan wrote:
> Hi Dean and All,
> 
> According to the current APNIC ASN policy document, the definition
> of multihomed is as below.
> 
> http://www.apnic.net/policy/asn-policy#3.4
> 
> 3.4 Multihomed
> 
> A multi-homed AS is one which is connected to more than one other
> AS. An AS also qualifies as multihomed if it is connected to a
> public Internet Exchange Point.
> 
> In the ASN request form, you will be asked to provide the estimate
> ASN implementation date, two peer AS numbers and their contact
> details. It is also acceptable if your network only connect to an
> IXP.
> 
> Best regards,
> 
> Guangliang =
> 
> -Original Message- From: sig-policy-boun...@lists.apnic.net
> [mailto:sig-policy-boun...@lists.apnic.net] On Behalf Of Dean
> Pemberton Sent: Wednesday, 25 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 to proceed here.
> 
> 
> -- Dean Pemberton
> 
> Technical Policy Advisor InternetNZ +64 21 920 363 (mob) 
> d...@internetnz.net.nz
> 
> To promote the Internet's benefits and uses, and protect its
> potential.
> 
> 
> On Wed, Feb 25, 2015 at 9:53 AM, Owen DeLong 
> wrote:
>> 
>>> On Feb 24, 2015, at 12:38 , Dean Pemberton
>>>  wrote:
>>> 
>>> On Wed, Feb 25, 2015 at 6:20 AM, Owen DeLong 
>>> wrote:
>>>>> Firstly I agree with Randy here.  If you're not multi-homed
>>>>> then your routing policy can not be 'unique' from your
>>>>> single upstream.  You may wish it was, but you have no way
>>>>> to enforce this.
>>>> 
>>>> This is not true.
>>>> 
>>>> You can be single homed to a single upstream, but, have other
>>>> peering relationships with other non-upstream ASNs which are
>>>> also not down-stream. These relationships may not be
>>>> sufficiently visible to convince APNIC that one is
>>>> multihomed, even though technically it is a multihomed
>>>> situation.
>>>> 
>>> 
>>> I don't agree (Damn and we were getting on so well this year
>>> =) ).
>>> 
>>> I would argue that the situation you describe above DOES
>>> constitute multihoming.
>> 
>> I agree, but it may not necessarily constitute “multihoming” in a
>> manner that is recognized or accepted by the RIR.
>> 
>> Clarification from APNIC staff on the exact behavior from APNIC
>> could render this moot.
>> 
>> However, I have past experience where RIRs have rejected peerings
>> with related entities and/or private ASNs of third parties as not
>> constituting valid “multihoming” whereupon I had to resort to “a
>> unique routing policy”.
>> 
>> 
>>> If an LIR were connected to an upstream ISP but also wanted to
>>>  participate at an IXP I would consider them to be multihomed
>>> and covered under existing APNIC policy.
>> 
>> What if they only connected to the IXP with a single connection?
>> I’ve also encountered situations where this is considered “not
>> multihomed” and to be a “unique routing policy”.
>> 
>>> 
>>> I couldn't find the strict definition on the APNIC pages as to
>>> what the hostmasters considered multihoming to be, but if one
>>> of them can point us to it then it might help.
>> 
>> Agreed.
>> 
>>> 
>>> 
>>>> While I oppose that (and thus completely oppose the other
>>>> proposal), as stated above, I think there are legitimate
>>>> reasons to allow ASN issuance in some cases for organizations
>>>> that may not meet the multi-homing requirement from an APNIC
>>>> perspective.
>>> 
>>> I really want to find out what those multi-homing requirements
>>> are. I suspect that they amount to "BGP connections to two or
>>> more other ASNs" In which case I think we can go back to
>>> agreeing.
>> 
>> As long as it’s not more specific than that (for example, two or
>> more public

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

[Skeeve Stevens]

I would think it would... why does it matter how you get to another peer?


...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 ;  <http://twitter.com/networkceoau>
linkedin.com/in/skeeve

twitter.com/theispguy ; blog: www.theispguy.com


IP Address Brokering - Introducing sellers and buyers

On Wed, Feb 25, 2015 at 5:09 PM, Gaurab Raj Upadhaya 
wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Guangliang,
>
> can you clarify these questions for me.
>
> If a provider connects to a v4 only transit provider over a physical
> circuit, but does v6 transit from Hurricane Electric over a tunnel,
> would that be considered multihoming ?
>
>
> - -gaurab
>
>
>
> On 2/25/15 4:05 AM, Guangliang Pan wrote:
> > Hi Dean and All,
> >
> > According to the current APNIC ASN policy document, the definition
> > of multihomed is as below.
> >
> > http://www.apnic.net/policy/asn-policy#3.4
> >
> > 3.4 Multihomed
> >
> > A multi-homed AS is one which is connected to more than one other
> > AS. An AS also qualifies as multihomed if it is connected to a
> > public Internet Exchange Point.
> >
> > In the ASN request form, you will be asked to provide the estimate
> > ASN implementation date, two peer AS numbers and their contact
> > details. It is also acceptable if your network only connect to an
> > IXP.
> >
> > Best regards,
> >
> > Guangliang =
> >
> > -Original Message- From: sig-policy-boun...@lists.apnic.net
> > [mailto:sig-policy-boun...@lists.apnic.net] On Behalf Of Dean
> > Pemberton Sent: Wednesday, 25 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 to proceed here.
> >
> >
> > -- Dean Pemberton
> >
> > Technical Policy Advisor InternetNZ +64 21 920 363 (mob)
> > d...@internetnz.net.nz
> >
> > To promote the Internet's benefits and uses, and protect its
> > potential.
> >
> >
> > On Wed, Feb 25, 2015 at 9:53 AM, Owen DeLong 
> > wrote:
> >>
> >>> On Feb 24, 2015, at 12:38 , Dean Pemberton
> >>>  wrote:
> >>>
> >>> On Wed, Feb 25, 2015 at 6:20 AM, Owen DeLong 
> >>> wrote:
> >>>>> Firstly I agree with Randy here.  If you're not multi-homed
> >>>>> then your routing policy can not be 'unique' from your
> >>>>> single upstream.  You may wish it was, but you have no way
> >>>>> to enforce this.
> >>>>
> >>>> This is not true.
> >>>>
> >>>> You can be single homed to a single upstream, but, have other
> >>>> peering relationships with other non-upstream ASNs which are
> >>>> also not down-stream. These relationships may not be
> >>>> sufficiently visible to convince APNIC that one is
> >>>> multihomed, even though technically it is a multihomed
> >>>> situation.
> >>>>
> >>>
> >>> I don't agree (Damn and we were getting on so well this year
> >>> =) ).
> >>>
> >>> I would argue that the situation you describe above DOES
> >>> constitute multihoming.
> >>
> >> I agree, but it may not necessarily constitute “multihoming” in a
> >> manner that is recognized or accepted by the RIR.
> >>
> >> Clarification from APNIC staff on the exact behavior from APNIC
> >> could render this moot.
> >>
> >> However, I have past experience where RIRs have rejected peerings
> >> with related entities and/or private ASNs of third parties as not
> >> constituting valid “multihoming” whereupon I had to resort to “a
> >> unique routing policy”.
> >>
> >>
> >>> If an LIR were connected to an upstream ISP but also wanted to
> >>>  participate at an IXP I would consider them to be multihomed
> >>> and covered under existing APNIC policy.
> >>
> >> What if they only connected to the IXP with a single connection?
> >> I’ve also encountered situations where this is considered “not
> >> multihomed” and to be

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

[Dean Pemberton]

Nope - Your other email didn't provide any reasons which weren't covered by
Philips answer.

If you have a peering session to two or more ASNs you are multihomed and
you qualify.
If you only peer with one ASN then you can do this with a private ASN.
If you want to make a change and move from a single peer to more than one
then you get quickly get an ASN.
You can even get them in advance of a planned network change as seen in the
current policy snippet below

"An organization will also be eligible if it can demonstrate that it will
meet the above criteria upon receiving an ASN (or within a reasonably short
time thereafter)."

No need to change policy.



--
Dean Pemberton

Technical Policy Advisor
InternetNZ
+64 21 920 363 (mob)
d...@internetnz.net.nz

To promote the Internet's benefits and uses, and protect its potential.

On Wed, Feb 25, 2015 at 9:09 PM, Skeeve Stevens  wrote:

> Please see my other email Phil.. there is very valid reasons for this
> policy change.
>
>
> ...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 ;  <http://twitter.com/networkceoau>
> linkedin.com/in/skeeve
>
> twitter.com/theispguy ; blog: www.theispguy.com
>
>
> IP Address Brokering - Introducing sellers and buyers
>
> On Wed, Feb 25, 2015 at 4:25 PM, Philip Smith  wrote:
>
>> Dean Pemberton wrote on 25/02/2015 15:06 :
>> > 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.
>>
>> Same, I simply don't understand what problem is trying to be solved here.
>>
>> If an organisation is connected to only one other organisation, there is
>> no need for an ASN. If these two orgs want to use BGP, that's a private
>> matter, and is what private ASNs are for - and there are now around 1
>> billion of those.
>>
>> If an organisation needs to connect to at least two other ASNs, then
>> they qualify under the APNIC definition which Guanliang shared.
>>
>> philip
>> --
>>
>> >
>> > I do not support the proposal
>> >
>> >
>> > --
>> > Dean Pemberton
>> >
>> > Technical Policy Advisor
>> > InternetNZ
>> > +64 21 920 363 (mob)
>> > d...@internetnz.net.nz
>> >
>> > To promote the Internet's benefits and uses, and protect its potential.
>> >
>> >
>> > On Wed, Feb 25, 2015 at 5:05 PM, Guangliang Pan  wrote:
>> >> Hi Dean and All,
>> >>
>> >> According to the current APNIC ASN policy document, the definition of
>> multihomed is as below.
>> >>
>> >> http://www.apnic.net/policy/asn-policy#3.4
>> >>
>> >> 3.4 Multihomed
>> >>
>> >> A multi-homed AS is one which is connected to more than one other AS.
>> An AS also qualifies as multihomed if it is connected to a public Internet
>> Exchange Point.
>> >>
>> >> In the ASN request form, you will be asked to provide the estimate ASN
>> implementation date, two peer AS numbers and their contact details. It is
>> also acceptable if your network only connect to an IXP.
>> >>
>> >> Best regards,
>> >>
>> >> Guangliang
>> >> =
>> >>
>> >> -Original Message-
>> >> From: sig-policy-boun...@lists.apnic.net [mailto:
>> sig-policy-boun...@lists.apnic.net] On Behalf Of Dean Pemberton
>> >> Sent: Wednesday, 25 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 to proceed here.
>> >>
>> >>
>> >> --
>> >> Dean Pemberton
>> >>
>> >> Technical Policy Advisor
>> >> InternetNZ
>> >> +64 21 920 363 (mob)
>> >> d...@internetnz.net.nz
>> >>
>> >> To promote the Internet's benefits and uses, and protect its potential.
>> >>
>> >>
>> >> On Wed, Feb 25, 2015 at 9:53 AM, Owen DeLong  wrote:
>> >>>
>> >>>> On Feb 24, 2015, at 12:38 , Dean Pemberton 
>> wrot

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

[Skeeve Stevens]

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 from it, without going through a change
in network configuration.

That might be easy for you, but that is simply your opinion on how things
should be done... not a reason why others shouldn't be allowed to do it the
way they want to.

If a member has a portable range, they should be entitled to - with no
restrictions - a ASN number to be able to BE as portable as they want to.




...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 ;  <http://twitter.com/networkceoau>
linkedin.com/in/skeeve

twitter.com/theispguy ; blog: www.theispguy.com


IP Address Brokering - Introducing sellers and buyers

On Wed, Feb 25, 2015 at 5:20 PM, Dean Pemberton 
wrote:

> Nope - Your other email didn't provide any reasons which weren't covered
> by Philips answer.
>
> If you have a peering session to two or more ASNs you are multihomed and
> you qualify.
> If you only peer with one ASN then you can do this with a private ASN.
> If you want to make a change and move from a single peer to more than one
> then you get quickly get an ASN.
> You can even get them in advance of a planned network change as seen in
> the current policy snippet below
>
> "An organization will also be eligible if it can demonstrate that it will
> meet the above criteria upon receiving an ASN (or within a reasonably short
> time thereafter)."
>
> No need to change policy.
>
>
>
> --
> Dean Pemberton
>
> Technical Policy Advisor
> InternetNZ
> +64 21 920 363 (mob)
> d...@internetnz.net.nz
>
> To promote the Internet's benefits and uses, and protect its potential.
>
> On Wed, Feb 25, 2015 at 9:09 PM, Skeeve Stevens  wrote:
>
>> Please see my other email Phil.. there is very valid reasons for this
>> policy change.
>>
>>
>> ...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 ;  <http://twitter.com/networkceoau>
>> linkedin.com/in/skeeve
>>
>> twitter.com/theispguy ; blog: www.theispguy.com
>>
>>
>> IP Address Brokering - Introducing sellers and buyers
>>
>> On Wed, Feb 25, 2015 at 4:25 PM, Philip Smith  wrote:
>>
>>> Dean Pemberton wrote on 25/02/2015 15:06 :
>>> > 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.
>>>
>>> Same, I simply don't understand what problem is trying to be solved here.
>>>
>>> If an organisation is connected to only one other organisation, there is
>>> no need for an ASN. If these two orgs want to use BGP, that's a private
>>> matter, and is what private ASNs are for - and there are now around 1
>>> billion of those.
>>>
>>> If an organisation needs to connect to at least two other ASNs, then
>>> they qualify under the APNIC definition which Guanliang shared.
>>>
>>> philip
>>> --
>>>
>>> >
>>> > I do not support the proposal
>>> >
>>> >
>>> > --
>>> > Dean Pemberton
>>> >
>>> > Technical Policy Advisor
>>> > InternetNZ
>>> > +64 21 920 363 (mob)
>>> > d...@internetnz.net.nz
>>> >
>>> > To promote the Internet's benefits and uses, and protect its potential.
>>> >
>>> >
>>> > On Wed, Feb 25, 2015 at 5:05 PM, Guangliang Pan 
>>> wrote:
>>> >> Hi Dean and All,
>>> >>
>>> >> According to the current APNIC ASN policy document, the definition of
>>> multihomed is as below.
>>> >>
>>> >> http://www.apnic.net/policy/asn-policy#3.4
>>> >>
>>> >> 3.4 Multihomed
>>> >>
>>> >> A multi-homed AS is one which is connected to more than one other AS.
>>> An AS also qualifies as multihomed if it is connected to a public Internet
>>> Exchange Point.
>>> >>
>>> >> In the ASN request form, you will be asked to provide the estimate
>>> ASN impleme

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

[Dean Pemberton]

Thanks for that Guangliang.  Thats really helped to clarify the position here.

Another question.
Whats the normal time lag between a member applying for an ASN
(assuming that all the information is present and correct) and it
being allocated?

1 day?
1 week?
1 month?

I'm trying to gauge if it really takes longer to apply for an ASN than
it does to arrange and configure a BGP peering session.

Thanks
Dean
--
Dean Pemberton

Technical Policy Advisor
InternetNZ
+64 21 920 363 (mob)
d...@internetnz.net.nz

To promote the Internet's benefits and uses, and protect its potential.


On Wed, Feb 25, 2015 at 5:05 PM, Guangliang Pan  wrote:
> Hi Dean and All,
>
> According to the current APNIC ASN policy document, the definition of 
> multihomed is as below.
>
> http://www.apnic.net/policy/asn-policy#3.4
>
> 3.4 Multihomed
>
> A multi-homed AS is one which is connected to more than one other AS. An AS 
> also qualifies as multihomed if it is connected to a public Internet Exchange 
> Point.
>
> In the ASN request form, you will be asked to provide the estimate ASN 
> implementation date, two peer AS numbers and their contact details. It is 
> also acceptable if your network only connect to an IXP.
>
> Best regards,
>
> Guangliang
> =
>
> -Original Message-
> From: sig-policy-boun...@lists.apnic.net 
> [mailto:sig-policy-boun...@lists.apnic.net] On Behalf Of Dean Pemberton
> Sent: Wednesday, 25 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 to proceed here.
>
>
> --
> Dean Pemberton
>
> Technical Policy Advisor
> InternetNZ
> +64 21 920 363 (mob)
> d...@internetnz.net.nz
>
> To promote the Internet's benefits and uses, and protect its potential.
>
>
> On Wed, Feb 25, 2015 at 9:53 AM, Owen DeLong  wrote:
>>
>>> On Feb 24, 2015, at 12:38 , Dean Pemberton  wrote:
>>>
>>> On Wed, Feb 25, 2015 at 6:20 AM, Owen DeLong  wrote:
>>>>> Firstly I agree with Randy here.  If you're not multi-homed then your 
>>>>> routing policy can not be 'unique' from your single upstream.  You may 
>>>>> wish it was, but you have no way to enforce this.
>>>>
>>>> This is not true.
>>>>
>>>> You can be single homed to a single upstream, but, have other peering 
>>>> relationships with other non-upstream ASNs which are also not down-stream. 
>>>> These relationships may not be sufficiently visible to convince APNIC that 
>>>> one is multihomed, even though technically it is a multihomed situation.
>>>>
>>>
>>> I don't agree (Damn and we were getting on so well this year  =) ).
>>>
>>> I would argue that the situation you describe above DOES constitute 
>>> multihoming.
>>
>> I agree, but it may not necessarily constitute “multihoming” in a manner 
>> that is recognized or accepted by the RIR.
>>
>> Clarification from APNIC staff on the exact behavior from APNIC could render 
>> this moot.
>>
>> However, I have past experience where RIRs have rejected peerings with 
>> related entities and/or private ASNs of third parties as not constituting 
>> valid “multihoming” whereupon I had to resort to “a unique routing policy”.
>>
>>
>>> If an LIR were connected to an upstream ISP but also wanted to
>>> participate at an IXP I would consider them to be multihomed and
>>> covered under existing APNIC policy.
>>
>> What if they only connected to the IXP with a single connection? I’ve also 
>> encountered situations where this is considered “not multihomed” and to be a 
>> “unique routing policy”.
>>
>>>
>>> I couldn't find the strict definition on the APNIC pages as to what
>>> the hostmasters considered multihoming to be, but if one of them can
>>> point us to it then it might help.
>>
>> Agreed.
>>
>>>
>>>
>>>> While I oppose that (and thus completely oppose the other proposal), as 
>>>> stated above, I think there are legitimate reasons to allow ASN issuance 
>>>> in some cases for organizations that may not meet the multi-homing 
>>>> requirement from an APNIC perspective.
>>>
>>> I really want to find out what those multi-homing requirements are.
>>> I suspect that they amount to "BGP connections to two or more 

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

[Skeeve Stevens]

Dean,

I'm not debating the time it takes to get an ASN allocated... I'm talking
about everything else around it... and changing your setup when you
shouldn't even have to... again, you're telling people how to run their
networks.

I'm simply saying that leave the running of the networks to them... let
them decide when, if they multi-home, if they choose to de-multi-home, etc.

We all know we can lie our way around this... but people shouldn't have
to... and if that is the only reason, then it is still a valid one.

A rule that isn't enforced, or has any repercussions for going around,
shouldn't even be there in the first place.  If the only reason it remains
is to annoy some small number of ethical people, it should be remediated.



...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 ;  <http://twitter.com/networkceoau>
linkedin.com/in/skeeve

twitter.com/theispguy ; blog: www.theispguy.com


IP Address Brokering - Introducing sellers and buyers

On Wed, Feb 25, 2015 at 5:35 PM, Dean Pemberton 
wrote:

> Thanks for that Guangliang.  Thats really helped to clarify the position
> here.
>
> Another question.
> Whats the normal time lag between a member applying for an ASN
> (assuming that all the information is present and correct) and it
> being allocated?
>
> 1 day?
> 1 week?
> 1 month?
>
> I'm trying to gauge if it really takes longer to apply for an ASN than
> it does to arrange and configure a BGP peering session.
>
> Thanks
> Dean
> --
> Dean Pemberton
>
> Technical Policy Advisor
> InternetNZ
> +64 21 920 363 (mob)
> d...@internetnz.net.nz
>
> To promote the Internet's benefits and uses, and protect its potential.
>
>
> On Wed, Feb 25, 2015 at 5:05 PM, Guangliang Pan  wrote:
> > Hi Dean and All,
> >
> > According to the current APNIC ASN policy document, the definition of
> multihomed is as below.
> >
> > http://www.apnic.net/policy/asn-policy#3.4
> >
> > 3.4 Multihomed
> >
> > A multi-homed AS is one which is connected to more than one other AS. An
> AS also qualifies as multihomed if it is connected to a public Internet
> Exchange Point.
> >
> > In the ASN request form, you will be asked to provide the estimate ASN
> implementation date, two peer AS numbers and their contact details. It is
> also acceptable if your network only connect to an IXP.
> >
> > Best regards,
> >
> > Guangliang
> > =
> >
> > -----Original Message-----
> > From: sig-policy-boun...@lists.apnic.net [mailto:
> sig-policy-boun...@lists.apnic.net] On Behalf Of Dean Pemberton
> > Sent: Wednesday, 25 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 to proceed here.
> >
> >
> > --
> > Dean Pemberton
> >
> > Technical Policy Advisor
> > InternetNZ
> > +64 21 920 363 (mob)
> > d...@internetnz.net.nz
> >
> > To promote the Internet's benefits and uses, and protect its potential.
> >
> >
> > On Wed, Feb 25, 2015 at 9:53 AM, Owen DeLong  wrote:
> >>
> >>> On Feb 24, 2015, at 12:38 , Dean Pemberton 
> wrote:
> >>>
> >>> On Wed, Feb 25, 2015 at 6:20 AM, Owen DeLong  wrote:
> >>>>> Firstly I agree with Randy here.  If you're not multi-homed then
> your routing policy can not be 'unique' from your single upstream.  You may
> wish it was, but you have no way to enforce this.
> >>>>
> >>>> This is not true.
> >>>>
> >>>> You can be single homed to a single upstream, but, have other peering
> relationships with other non-upstream ASNs which are also not down-stream.
> These relationships may not be sufficiently visible to convince APNIC that
> one is multihomed, even though technically it is a multihomed situation.
> >>>>
> >>>
> >>> I don't agree (Damn and we were getting on so well this year  =) ).
> >>>
> >>> I would argue that the situation you describe above DOES constitute
> multihoming.
> >>
> >> I agree, but it may not necessarily constitute “multihoming” in a
> manner that is recognized or accepted by the RIR.
> >>
> >> Clarification from APNIC staff on 

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

[Guangliang Pan]

Hi Dean,

If they meet the policy requirement and no payment requested, they normally 
will receive an ASN in the next working day. 

Thanks,
Guangliang 

> On 25 Feb 2015, at 6:36 pm, "Dean Pemberton"  wrote:
> 
> Thanks for that Guangliang.  Thats really helped to clarify the position here.
> 
> Another question.
> Whats the normal time lag between a member applying for an ASN
> (assuming that all the information is present and correct) and it
> being allocated?
> 
> 1 day?
> 1 week?
> 1 month?
> 
> I'm trying to gauge if it really takes longer to apply for an ASN than
> it does to arrange and configure a BGP peering session.
> 
> Thanks
> Dean
> --
> Dean Pemberton
> 
> Technical Policy Advisor
> InternetNZ
> +64 21 920 363 (mob)
> d...@internetnz.net.nz
> 
> To promote the Internet's benefits and uses, and protect its potential.
> 
> 
>> On Wed, Feb 25, 2015 at 5:05 PM, Guangliang Pan  wrote:
>> Hi Dean and All,
>> 
>> According to the current APNIC ASN policy document, the definition of 
>> multihomed is as below.
>> 
>> http://www.apnic.net/policy/asn-policy#3.4
>> 
>> 3.4 Multihomed
>> 
>> A multi-homed AS is one which is connected to more than one other AS. An AS 
>> also qualifies as multihomed if it is connected to a public Internet 
>> Exchange Point.
>> 
>> In the ASN request form, you will be asked to provide the estimate ASN 
>> implementation date, two peer AS numbers and their contact details. It is 
>> also acceptable if your network only connect to an IXP.
>> 
>> Best regards,
>> 
>> Guangliang
>> =
>> 
>> -Original Message-----
>> From: sig-policy-boun...@lists.apnic.net 
>> [mailto:sig-policy-boun...@lists.apnic.net] On Behalf Of Dean Pemberton
>> Sent: Wednesday, 25 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 to proceed here.
>> 
>> 
>> --
>> Dean Pemberton
>> 
>> Technical Policy Advisor
>> InternetNZ
>> +64 21 920 363 (mob)
>> d...@internetnz.net.nz
>> 
>> To promote the Internet's benefits and uses, and protect its potential.
>> 
>> 
>>> On Wed, Feb 25, 2015 at 9:53 AM, Owen DeLong  wrote:
>>> 
>>>> On Feb 24, 2015, at 12:38 , Dean Pemberton  wrote:
>>>> 
>>>> On Wed, Feb 25, 2015 at 6:20 AM, Owen DeLong  wrote:
>>>>>> Firstly I agree with Randy here.  If you're not multi-homed then your 
>>>>>> routing policy can not be 'unique' from your single upstream.  You may 
>>>>>> wish it was, but you have no way to enforce this.
>>>>> 
>>>>> This is not true.
>>>>> 
>>>>> You can be single homed to a single upstream, but, have other peering 
>>>>> relationships with other non-upstream ASNs which are also not 
>>>>> down-stream. These relationships may not be sufficiently visible to 
>>>>> convince APNIC that one is multihomed, even though technically it is a 
>>>>> multihomed situation.
>>>> 
>>>> I don't agree (Damn and we were getting on so well this year  =) ).
>>>> 
>>>> I would argue that the situation you describe above DOES constitute 
>>>> multihoming.
>>> 
>>> I agree, but it may not necessarily constitute “multihoming” in a manner 
>>> that is recognized or accepted by the RIR.
>>> 
>>> Clarification from APNIC staff on the exact behavior from APNIC could 
>>> render this moot.
>>> 
>>> However, I have past experience where RIRs have rejected peerings with 
>>> related entities and/or private ASNs of third parties as not constituting 
>>> valid “multihoming” whereupon I had to resort to “a unique routing policy”.
>>> 
>>> 
>>>> If an LIR were connected to an upstream ISP but also wanted to
>>>> participate at an IXP I would consider them to be multihomed and
>>>> covered under existing APNIC policy.
>>> 
>>> What if they only connected to the IXP with a single connection? I’ve also 
>>> encountered situations where this is considered “not multihomed” and to be 
>>> a “unique routing policy”.
>>> 
>>>> 
>>>&

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

[Guangliang Pan]

Hi Gaurab,

If they can provide 2 peer ASNs in their application, based on the policy they 
can receive an ASN assignment. 

Regards,
Guangliang 

> On 25 Feb 2015, at 6:10 pm, "Gaurab Raj Upadhaya"  wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Guangliang,
> 
> can you clarify these questions for me.
> 
> If a provider connects to a v4 only transit provider over a physical
> circuit, but does v6 transit from Hurricane Electric over a tunnel,
> would that be considered multihoming ?
> 
> 
> - -gaurab
> 
> 
> 
>> On 2/25/15 4:05 AM, Guangliang Pan wrote:
>> Hi Dean and All,
>> 
>> According to the current APNIC ASN policy document, the definition
>> of multihomed is as below.
>> 
>> http://www.apnic.net/policy/asn-policy#3.4
>> 
>> 3.4 Multihomed
>> 
>> A multi-homed AS is one which is connected to more than one other
>> AS. An AS also qualifies as multihomed if it is connected to a
>> public Internet Exchange Point.
>> 
>> In the ASN request form, you will be asked to provide the estimate
>> ASN implementation date, two peer AS numbers and their contact
>> details. It is also acceptable if your network only connect to an
>> IXP.
>> 
>> Best regards,
>> 
>> Guangliang =
>> 
>> -Original Message- From: sig-policy-boun...@lists.apnic.net
>> [mailto:sig-policy-boun...@lists.apnic.net] On Behalf Of Dean
>> Pemberton Sent: Wednesday, 25 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 to proceed here.
>> 
>> 
>> -- Dean Pemberton
>> 
>> Technical Policy Advisor InternetNZ +64 21 920 363 (mob) 
>> d...@internetnz.net.nz
>> 
>> To promote the Internet's benefits and uses, and protect its
>> potential.
>> 
>> 
>> On Wed, Feb 25, 2015 at 9:53 AM, Owen DeLong 
>> wrote:
>>> 
>>>> On Feb 24, 2015, at 12:38 , Dean Pemberton
>>>>  wrote:
>>>> 
>>>> On Wed, Feb 25, 2015 at 6:20 AM, Owen DeLong 
>>>> wrote:
>>>>>> Firstly I agree with Randy here.  If you're not multi-homed
>>>>>> then your routing policy can not be 'unique' from your
>>>>>> single upstream.  You may wish it was, but you have no way
>>>>>> to enforce this.
>>>>> 
>>>>> This is not true.
>>>>> 
>>>>> You can be single homed to a single upstream, but, have other
>>>>> peering relationships with other non-upstream ASNs which are
>>>>> also not down-stream. These relationships may not be
>>>>> sufficiently visible to convince APNIC that one is
>>>>> multihomed, even though technically it is a multihomed
>>>>> situation.
>>>> 
>>>> I don't agree (Damn and we were getting on so well this year
>>>> =) ).
>>>> 
>>>> I would argue that the situation you describe above DOES
>>>> constitute multihoming.
>>> 
>>> I agree, but it may not necessarily constitute “multihoming” in a
>>> manner that is recognized or accepted by the RIR.
>>> 
>>> Clarification from APNIC staff on the exact behavior from APNIC
>>> could render this moot.
>>> 
>>> However, I have past experience where RIRs have rejected peerings
>>> with related entities and/or private ASNs of third parties as not
>>> constituting valid “multihoming” whereupon I had to resort to “a
>>> unique routing policy”.
>>> 
>>> 
>>>> If an LIR were connected to an upstream ISP but also wanted to
>>>> participate at an IXP I would consider them to be multihomed
>>>> and covered under existing APNIC policy.
>>> 
>>> What if they only connected to the IXP with a single connection?
>>> I’ve also encountered situations where this is considered “not
>>> multihomed” and to be a “unique routing policy”.
>>> 
>>>> 
>>>> I couldn't find the strict definition on the APNIC pages as to
>>>> what the hostmasters considered multihoming to be, but if one
>>>> of them can point us to it then it might help.
>>> 
>>> Agreed.
>>> 
>>>> 
>>>> 
>>>>

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

[Skeeve Stevens]

Guangliang,

What are the rules about someone with a ASN, later de-multi-homing?


...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 ;  <http://twitter.com/networkceoau>
linkedin.com/in/skeeve

twitter.com/theispguy ; blog: www.theispguy.com


IP Address Brokering - Introducing sellers and buyers

On Wed, Feb 25, 2015 at 6:53 PM, Guangliang Pan  wrote:

> Hi Gaurab,
>
> If they can provide 2 peer ASNs in their application, based on the policy
> they can receive an ASN assignment.
>
> Regards,
> Guangliang
>
> > On 25 Feb 2015, at 6:10 pm, "Gaurab Raj Upadhaya" 
> wrote:
> >
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA1
> >
> > Guangliang,
> >
> > can you clarify these questions for me.
> >
> > If a provider connects to a v4 only transit provider over a physical
> > circuit, but does v6 transit from Hurricane Electric over a tunnel,
> > would that be considered multihoming ?
> >
> >
> > - -gaurab
> >
> >
> >
> >> On 2/25/15 4:05 AM, Guangliang Pan wrote:
> >> Hi Dean and All,
> >>
> >> According to the current APNIC ASN policy document, the definition
> >> of multihomed is as below.
> >>
> >> http://www.apnic.net/policy/asn-policy#3.4
> >>
> >> 3.4 Multihomed
> >>
> >> A multi-homed AS is one which is connected to more than one other
> >> AS. An AS also qualifies as multihomed if it is connected to a
> >> public Internet Exchange Point.
> >>
> >> In the ASN request form, you will be asked to provide the estimate
> >> ASN implementation date, two peer AS numbers and their contact
> >> details. It is also acceptable if your network only connect to an
> >> IXP.
> >>
> >> Best regards,
> >>
> >> Guangliang =====
> >>
> >> -Original Message- From: sig-policy-boun...@lists.apnic.net
> >> [mailto:sig-policy-boun...@lists.apnic.net] On Behalf Of Dean
> >> Pemberton Sent: Wednesday, 25 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 to proceed here.
> >>
> >>
> >> -- Dean Pemberton
> >>
> >> Technical Policy Advisor InternetNZ +64 21 920 363 (mob)
> >> d...@internetnz.net.nz
> >>
> >> To promote the Internet's benefits and uses, and protect its
> >> potential.
> >>
> >>
> >> On Wed, Feb 25, 2015 at 9:53 AM, Owen DeLong 
> >> wrote:
> >>>
> >>>> On Feb 24, 2015, at 12:38 , Dean Pemberton
> >>>>  wrote:
> >>>>
> >>>> On Wed, Feb 25, 2015 at 6:20 AM, Owen DeLong 
> >>>> wrote:
> >>>>>> Firstly I agree with Randy here.  If you're not multi-homed
> >>>>>> then your routing policy can not be 'unique' from your
> >>>>>> single upstream.  You may wish it was, but you have no way
> >>>>>> to enforce this.
> >>>>>
> >>>>> This is not true.
> >>>>>
> >>>>> You can be single homed to a single upstream, but, have other
> >>>>> peering relationships with other non-upstream ASNs which are
> >>>>> also not down-stream. These relationships may not be
> >>>>> sufficiently visible to convince APNIC that one is
> >>>>> multihomed, even though technically it is a multihomed
> >>>>> situation.
> >>>>
> >>>> I don't agree (Damn and we were getting on so well this year
> >>>> =) ).
> >>>>
> >>>> I would argue that the situation you describe above DOES
> >>>> constitute multihoming.
> >>>
> >>> I agree, but it may not necessarily constitute “multihoming” in a
> >>> manner that is recognized or accepted by the RIR.
> >>>
> >>> Clarification from APNIC staff on the exact behavior from APNIC
> >>> could render this moot.
> >>>
> >>> However, I have past experience where RIRs have rejected peerings
> >>> with related 

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

[Guangliang Pan]

Hi Skeeve,

I don't think we have a policy to reclaim those AS Numbers.

Regards,
Guangliang

On 25 Feb 2015, at 7:57 pm, "Skeeve Stevens" 
mailto:ske...@v4now.com>> wrote:

Guangliang,

What are the rules about someone with a ASN, later de-multi-homing?


...Skeeve

Skeeve Stevens - Senior IP Broker
v4Now - an eintellego 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> ; 
<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/>

[http://eintellegonetworks.com/logos/v4now-web05.png]

IP Address Brokering - Introducing sellers and buyers

On Wed, Feb 25, 2015 at 6:53 PM, Guangliang Pan 
mailto:g...@apnic.net>> wrote:
Hi Gaurab,

If they can provide 2 peer ASNs in their application, based on the policy they 
can receive an ASN assignment.

Regards,
Guangliang

> On 25 Feb 2015, at 6:10 pm, "Gaurab Raj Upadhaya" 
> mailto:gau...@lahai.com>> wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Guangliang,
>
> can you clarify these questions for me.
>
> If a provider connects to a v4 only transit provider over a physical
> circuit, but does v6 transit from Hurricane Electric over a tunnel,
> would that be considered multihoming ?
>
>
> - -gaurab
>
>
>
>> On 2/25/15 4:05 AM, Guangliang Pan wrote:
>> Hi Dean and All,
>>
>> According to the current APNIC ASN policy document, the definition
>> of multihomed is as below.
>>
>> http://www.apnic.net/policy/asn-policy#3.4
>>
>> 3.4 Multihomed
>>
>> A multi-homed AS is one which is connected to more than one other
>> AS. An AS also qualifies as multihomed if it is connected to a
>> public Internet Exchange Point.
>>
>> In the ASN request form, you will be asked to provide the estimate
>> ASN implementation date, two peer AS numbers and their contact
>> details. It is also acceptable if your network only connect to an
>> IXP.
>>
>> Best regards,
>>
>> Guangliang =
>>
>> -Original Message- From: 
>> sig-policy-boun...@lists.apnic.net<mailto:sig-policy-boun...@lists.apnic.net>
>> [mailto:sig-policy-boun...@lists.apnic.net<mailto:sig-policy-boun...@lists.apnic.net>]
>>  On Behalf Of Dean
>> Pemberton Sent: Wednesday, 25 February 2015 7:02 AM To: Owen
>> DeLong Cc: sig-policy@lists.apnic.net<mailto: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 to proceed here.
>>
>>
>> -- Dean Pemberton
>>
>> Technical Policy Advisor InternetNZ +64 21 920 363 (mob)
>> d...@internetnz.net.nz<mailto:d...@internetnz.net.nz>
>>
>> To promote the Internet's benefits and uses, and protect its
>> potential.
>>
>>
>> On Wed, Feb 25, 2015 at 9:53 AM, Owen DeLong 
>> mailto:o...@delong.com>>
>> wrote:
>>>
>>>> On Feb 24, 2015, at 12:38 , Dean Pemberton
>>>> mailto:d...@internetnz.net.nz>> wrote:
>>>>
>>>> On Wed, Feb 25, 2015 at 6:20 AM, Owen DeLong 
>>>> mailto:o...@delong.com>>
>>>> wrote:
>>>>>> Firstly I agree with Randy here.  If you're not multi-homed
>>>>>> then your routing policy can not be 'unique' from your
>>>>>> single upstream.  You may wish it was, but you have no way
>>>>>> to enforce this.
>>>>>
>>>>> This is not true.
>>>>>
>>>>> You can be single homed to a single upstream, but, have other
>>>>> peering relationships with other non-upstream ASNs which are
>>>>> also not down-stream. These relationships may not be
>>>>> sufficiently visible to convince APNIC that one is
>>>>> multihomed, even though technically it is a multihomed
>>>>> situation.
>>>>
>>>> I don't agree (Damn and we were getting on so well this year
>>>> =) ).
>>>>
>>>> I would argue that the situation you describe above DOES
>>>> constitute multihoming.
>>>
>>> I agree, but it may not necessarily constitute “mul

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

[Dean Pemberton]

Thanks Guangliang,

That's what I hoped the answer would be and it's great to see that the
hostmasters are able to turn these around so quickly.

My summary here after all we have discussed is that under the current
policy, if there is an operational need (connecting to more than one
ASN or to an IXP) for a member to have an ASN, they can apply a short
time in advance and generally receive an ASN the next working day.

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 with that.

Dean
--
Dean Pemberton

Technical Policy Advisor
InternetNZ
+64 21 920 363 (mob)
d...@internetnz.net.nz

To promote the Internet's benefits and uses, and protect its potential.


On Wed, Feb 25, 2015 at 10:36 PM, Guangliang Pan  wrote:
> Hi Dean,
>
> If they meet the policy requirement and no payment requested, they normally 
> will receive an ASN in the next working day.
>
> Thanks,
> Guangliang
>
>> On 25 Feb 2015, at 6:36 pm, "Dean Pemberton"  wrote:
>>
>> Thanks for that Guangliang.  Thats really helped to clarify the position 
>> here.
>>
>> Another question.
>> Whats the normal time lag between a member applying for an ASN
>> (assuming that all the information is present and correct) and it
>> being allocated?
>>
>> 1 day?
>> 1 week?
>> 1 month?
>>
>> I'm trying to gauge if it really takes longer to apply for an ASN than
>> it does to arrange and configure a BGP peering session.
>>
>> Thanks
>> Dean
>> --
>> Dean Pemberton
>>
>> Technical Policy Advisor
>> InternetNZ
>> +64 21 920 363 (mob)
>> d...@internetnz.net.nz
>>
>> To promote the Internet's benefits and uses, and protect its potential.
>>
>>
>>> On Wed, Feb 25, 2015 at 5:05 PM, Guangliang Pan  wrote:
>>> Hi Dean and All,
>>>
>>> According to the current APNIC ASN policy document, the definition of 
>>> multihomed is as below.
>>>
>>> http://www.apnic.net/policy/asn-policy#3.4
>>>
>>> 3.4 Multihomed
>>>
>>> A multi-homed AS is one which is connected to more than one other AS. An AS 
>>> also qualifies as multihomed if it is connected to a public Internet 
>>> Exchange Point.
>>>
>>> In the ASN request form, you will be asked to provide the estimate ASN 
>>> implementation date, two peer AS numbers and their contact details. It is 
>>> also acceptable if your network only connect to an IXP.
>>>
>>> Best regards,
>>>
>>> Guangliang
>>> =
>>>
>>> -Original Message-
>>> From: sig-policy-boun...@lists.apnic.net 
>>> [mailto:sig-policy-boun...@lists.apnic.net] On Behalf Of Dean Pemberton
>>> Sent: Wednesday, 25 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 to proceed here.
>>>
>>>
>>> --
>>> Dean Pemberton
>>>
>>> Technical Policy Advisor
>>> InternetNZ
>>> +64 21 920 363 (mob)
>>> d...@internetnz.net.nz
>>>
>>> To promote the Internet's benefits and uses, and protect its potential.
>>>
>>>
>>>> On Wed, Feb 25, 2015 at 9:53 AM, Owen DeLong  wrote:
>>>>
>>>>> On Feb 24, 2015, at 12:38 , Dean Pemberton  wrote:
>>>>>
>>>>> On Wed, Feb 25, 2015 at 6:20 AM, Owen DeLong  wrote:
>>>>>>> Firstly I agree with Randy here.  If you're not multi-homed then your 
>>>>>>> routing policy can not be 'unique' from your single upstream.  You may 
>>>>>>> wish it was, but you have no way to enforce this.
>>>>>>
>>>>>> This is not true.
>>>>>>
>>>>>> You can be single homed to a single upstream, but, have other peering 
>>>>>> relationships with other non-upstream ASNs which are also not 
>>>>>> down-stream. These relationships may not be sufficiently visible to 
>>>>>> convince APNIC that one is multihomed, even though technically it is a 
>>>>>> multihomed situation.
>>>>>
>>>>> I don't agree

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

[Owen DeLong]

> On Feb 24, 2015, at 22: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.
> 

Agreed… However, it does allow one to basically get ASNs no matter what, since 
all one needs to do is cobble up 3 distinct sites and ask for an ASN for each 
site and then peer the sites with each other.

Owen

> I do not support the proposal
> 
> 
> --
> Dean Pemberton
> 
> Technical Policy Advisor
> InternetNZ
> +64 21 920 363 (mob)
> d...@internetnz.net.nz
> 
> To promote the Internet's benefits and uses, and protect its potential.
> 
> 
> On Wed, Feb 25, 2015 at 5:05 PM, Guangliang Pan  wrote:
>> Hi Dean and All,
>> 
>> According to the current APNIC ASN policy document, the definition of 
>> multihomed is as below.
>> 
>> http://www.apnic.net/policy/asn-policy#3.4
>> 
>> 3.4 Multihomed
>> 
>> A multi-homed AS is one which is connected to more than one other AS. An AS 
>> also qualifies as multihomed if it is connected to a public Internet 
>> Exchange Point.
>> 
>> In the ASN request form, you will be asked to provide the estimate ASN 
>> implementation date, two peer AS numbers and their contact details. It is 
>> also acceptable if your network only connect to an IXP.
>> 
>> Best regards,
>> 
>> Guangliang
>> =
>> 
>> -Original Message-
>> From: sig-policy-boun...@lists.apnic.net 
>> [mailto:sig-policy-boun...@lists.apnic.net] On Behalf Of Dean Pemberton
>> Sent: Wednesday, 25 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 to proceed here.
>> 
>> 
>> --
>> Dean Pemberton
>> 
>> Technical Policy Advisor
>> InternetNZ
>> +64 21 920 363 (mob)
>> d...@internetnz.net.nz
>> 
>> To promote the Internet's benefits and uses, and protect its potential.
>> 
>> 
>> On Wed, Feb 25, 2015 at 9:53 AM, Owen DeLong  wrote:
>>> 
>>>> On Feb 24, 2015, at 12:38 , Dean Pemberton  wrote:
>>>> 
>>>> On Wed, Feb 25, 2015 at 6:20 AM, Owen DeLong  wrote:
>>>>>> Firstly I agree with Randy here.  If you're not multi-homed then your 
>>>>>> routing policy can not be 'unique' from your single upstream.  You may 
>>>>>> wish it was, but you have no way to enforce this.
>>>>> 
>>>>> This is not true.
>>>>> 
>>>>> You can be single homed to a single upstream, but, have other peering 
>>>>> relationships with other non-upstream ASNs which are also not 
>>>>> down-stream. These relationships may not be sufficiently visible to 
>>>>> convince APNIC that one is multihomed, even though technically it is a 
>>>>> multihomed situation.
>>>>> 
>>>> 
>>>> I don't agree (Damn and we were getting on so well this year  =) ).
>>>> 
>>>> I would argue that the situation you describe above DOES constitute 
>>>> multihoming.
>>> 
>>> I agree, but it may not necessarily constitute “multihoming” in a manner 
>>> that is recognized or accepted by the RIR.
>>> 
>>> Clarification from APNIC staff on the exact behavior from APNIC could 
>>> render this moot.
>>> 
>>> However, I have past experience where RIRs have rejected peerings with 
>>> related entities and/or private ASNs of third parties as not constituting 
>>> valid “multihoming” whereupon I had to resort to “a unique routing policy”.
>>> 
>>> 
>>>> If an LIR were connected to an upstream ISP but also wanted to
>>>> participate at an IXP I would consider them to be multihomed and
>>>> covered under existing APNIC policy.
>>> 
>>> What if they only connected to the IXP with a single connection? I’ve also 
>>> encountered situations where this is considered “not multihomed” and to be 
>>> a “unique routing policy”.
>>> 
>>>> 
>>>> I couldn't find the strict definition on the APNIC pages as to what
>>>> the hostmasters considered multihoming to be, but if one of them can
>>>> point us to it then it might hel

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

[Owen DeLong]

> On Feb 24, 2015, at 22:47 , Raphael Ho  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 since
> they will require an ASN to peer/multihome at some point in the future
> (which I do agree)

What is the disadvantage for them to get the ASN later, when they actually need 
it?

> Currently they all have to "commit fraud² in order to get an ASN, and I
> guess some religion takes that more seriously than others.

They only have to commit fraud if they are determined to get an ASN before they 
need one.

> Would we the proposal be acceptable if we reworded the proposal to say
> something on the lines of
> 
> ³Eligible LIRs with APNIC Assigned Portable addresses are also eligible
> for as ASN²?

I think “an ASN” rather than “as ASN”, but I’d need to better understand why 
they need one
ahead of time. What’s wrong with getting the ASN when you need it?

Owen


*  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-114: Modification in the ASN eligibility criteria

[David Farmer]

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 with that.

Dean


From a policy perspective there is no barrier to entry.

However, from an operational perspective, I see it a little differently; 
having deployed my network using a private ASN, I then need to migrate 
to a new unique registry assigned ASN.  Which you are saying I can't 
have until I've grown to the point were I need to multi-home or connect 
to an IX.  If I'm a small network, this may not be a big hardship.  But 
if you connect to a single provider in multiple cities you could build a 
fairly extensive network that would not qualify for a registry assigned 
ASN until you got a second provider or connected to an IX, at which 
point the transition to the new ASN could be rather complicated.


I'm not sure that justifies obliterating the current policy, but there 
is at least an operational barrier to entry in some situations.  I think 
maybe a compromise would be to allow a network of a certain size to 
obtain an ASN regardless of having a unique routing policy, being 
multi-homed, or connected to an IX.


A network of 1 or 2 routers probably doesn't justify an ASN unless it is 
multi-homed or connected to an IX.  A network of 100 routers probably 
justifies an ASN regardless.  Then the question becomes, where to draw 
the line.


--

David Farmer   Email: far...@umn.edu
Office of Information Technology
University of Minnesota
2218 University Ave SE Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952

*  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-114: Modification in the ASN eligibility criteria

[Skeeve Stevens]

Owen,

But who determines 'if they need one' ?  Them, or you (plural)?

I believe they should be able to determine that they need one and be able
to get one based on that decision - not told how they should be doing their
upstream connectivity at any particular time.


...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, Feb 26, 2015 at 8:03 AM, Owen DeLong  wrote:

>
> > On Feb 24, 2015, at 22:47 , Raphael Ho 
> 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 since
> > they will require an ASN to peer/multihome at some point in the future
> > (which I do agree)
>
> What is the disadvantage for them to get the ASN later, when they actually
> need it?
>
> > Currently they all have to "commit fraud² in order to get an ASN, and I
> > guess some religion takes that more seriously than others.
>
> They only have to commit fraud if they are determined to get an ASN before
> they need one.
>
> > Would we the proposal be acceptable if we reworded the proposal to say
> > something on the lines of
> >
> > ³Eligible LIRs with APNIC Assigned Portable addresses are also eligible
> > for as ASN²?
>
> I think “an ASN” rather than “as ASN”, but I’d need to better understand
> why they need one
> ahead of time. What’s wrong with getting the ASN when you need it?
>
> Owen
>
>
> *  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 Policy Proposal] prop-114: Modification in the ASN eligibility criteria

[Owen DeLong]

> On Feb 24, 2015, at 22:46 , Skeeve Stevens  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 convenience of being able to add 
> these things easily.
> 
> Lets say I was a company with a /23 and upstream into Telstra Only.  If I had 
> my own ASN and was announcing to Telstra, then at any time I could add 
> another ISP, IXP, direct peering without having to go apply for an ASN, 
> reconfigure my network to bring the announcement in-house, etc. 

No you can’t… You just have already done it instead of doing it when you get 
ready to actually multihome.

It’s all the same effort, just a difference in when you have to apply said 
effort.

> I also might want to maintain a single provider, but be able to migrate 
> easily to another provider without having to rely on the providers to do the 
> "right thing" while changing announcements between them.

This has some validity, but if you have an overlap period, you’re multihomed 
during the overlap and eligible for an ASN as a result.

> I think this policy has VERY valid applications for many smaller entities to 
> be able to have an ASN without having to be multi-homed either initially, or 
> maintain that multi-homing.

I don’t believe you lose your ASN if you stop multihoming.

> As Randy used to say - Why do you have the right to tell me how to manage my 
> network?  If I want to be multi-homed, or change my mind and not be, it is 
> none of your damn business.

That’s true. But nobody is trying to tell you that. I don’t believe the APNIC 
policy calls for reclaiming ASNs from entities that are no longer multihomed. 
It merely prevents issuing ASNs to entities that are not multihomed.

The only possible case I can see where this might be useful would be the case 
of two uplinks to the same ASN that are sufficiently topologically diverse as 
to make it desirable to do route injection for better failover capabilities.

> I think this policy change reflects the changing way for businesses to get 
> online since APNIC has run out of IP's, and are often charging significant 
> amounts of money - so people are going to APNIC directly - which they are 
> entitled to do.  And being flexible and being able to change their 
> circumstances is a more common thing nowadays.

No, this policy change turns APNIC into an ASN pez dispenser which is an 
undesirable state.

You don’t need an ASN to use provider independent addresses, so the rest of the 
paragraph is a red herring.

The flexibility exists. It’s just a question of when one does the work to turn 
on BGP and get an ASN. I see no reason the community should hand out ASNs to 
anyone who thinks they might want one for some possible use at some possible 
time in some possible future.

> If you want, suggest charging for ASN's... but don't tell networks how they 
> should be connected at any time.

Nobody is telling anyone how they should be connected. This is about resource 
management of a community resource pool, not about dictating operational 
practice. You can do everything you have said you want to do with your network 
under the existing policy.  You just can’t get an ASN until you actually need 
one. Imagine where we’d be if we had handed out all the IPv4 space to anyone 
who thought they might need some someday?

> Btw... I am happy for this to apply ONLY to ASN4 and not ASN2.

There are no more ASN4s than there are IPv4 addresses.

Owen


*  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-114: Modification in the ASN eligibility criteria

[Skeeve Stevens]

David,

I agree very much with the operational perspective (obviously), but since
when in this day and age of infrastructure that size still matters?

Having to change your infrastructure (of any size), potentially with
outages and so on, is not acceptable if you are able to design around it
from day one.

I see it enough that a member should be able to proactively design their
connectivity (should they want to - no one is being forced here) to have
the potential for multi-homing.

The silly thing with the multi-homing barrier as Guangliang confirmed, you
could multi-home for 1 day and meet the criteria and then disconnect and
then you are still allowed to continue using it.  So why have the
restriction there in the first place?

Surely if someone thinks having an ASN is important in their design, they
should be allowed to have one.


...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, Feb 26, 2015 at 8:10 AM, David Farmer  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 with that.
>>
>> Dean
>>
>
> From a policy perspective there is no barrier to entry.
>
> However, from an operational perspective, I see it a little differently;
> having deployed my network using a private ASN, I then need to migrate to a
> new unique registry assigned ASN.  Which you are saying I can't have until
> I've grown to the point were I need to multi-home or connect to an IX.  If
> I'm a small network, this may not be a big hardship.  But if you connect to
> a single provider in multiple cities you could build a fairly extensive
> network that would not qualify for a registry assigned ASN until you got a
> second provider or connected to an IX, at which point the transition to the
> new ASN could be rather complicated.
>
> I'm not sure that justifies obliterating the current policy, but there is
> at least an operational barrier to entry in some situations.  I think maybe
> a compromise would be to allow a network of a certain size to obtain an ASN
> regardless of having a unique routing policy, being multi-homed, or
> connected to an IX.
>
> A network of 1 or 2 routers probably doesn't justify an ASN unless it is
> multi-homed or connected to an IX.  A network of 100 routers probably
> justifies an ASN regardless.  Then the question becomes, where to draw the
> line.
>
> --
> 
> David Farmer   Email: far...@umn.edu
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE Phone: 1-612-626-0815
> Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
> 
> *  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 Policy Proposal] prop-114: Modification in the ASN eligibility criteria

[Owen DeLong]

> On Feb 25, 2015, at 00:32 , Skeeve Stevens  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 from it, without going through a change in 
> network configuration.
> 
> That might be easy for you, but that is simply your opinion on how things 
> should be done... not a reason why others shouldn't be allowed to do it the 
> way they want to.
> 
> If a member has a portable range, they should be entitled to - with no 
> restrictions - a ASN number to be able to BE as portable as they want to.

Even if I agreed with what you have said above, and I do not, this last 
statement bears no resemblence to the policy you have proposed.

If you want to propose a policy that matches your last sentence, I would not 
oppose that, so long as any additional ASNs had to be issued under the current 
multihome requirement.

However, your proposal doesn’t say someone who has PI space is entitled to 1 
ASN. It says anyone who wants one is entitled to as many ASNs as they want.

That’s simply a bad idea.

Owen

*  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-114: Modification in the ASN eligibility criteria

[Guangliang Pan]

Hi Aftab,
If a network is single homed, according to the current policy, it does not 
qualify for a public ASN assignment. We would recommend requestors to use a 
private ASN instead. – I believe this is the main debate point of this policy 
discussion.

APNIC Members are bound by the membership agreement to not provide false or 
misleading information in their resource application. We work on the basis of 
trust when we do our evaluations. However, Hostmasters do contact other ASN 
peers if necessary to verify information provided in the request.
The ASN policy doesn’t request APNIC to monitor the ASN peering. APNIC Members 
are allowed to change their network peers at any time. The aut-num object in 
the whois database is maintained by the Member’s maintainer, and it is their 
responsibility to update their peer information in a timely manner.
Best regards,
Guangliang
=


From: Aftab Siddiqui [mailto:aftab.siddi...@gmail.com]
Sent: Wednesday, 25 February 2015 4:25 PM
To: Guangliang Pan
Cc: Dean Pemberton; Owen DeLong; sig-policy@lists.apnic.net
Subject: Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the 
ASN eligibility criteria

Thanks Guangliang for the update,


According to the current APNIC ASN policy document, the definition of 
multihomed is as below.

http://www.apnic.net/policy/asn-policy#3.4

3.4 Multihomed

A multi-homed AS is one which is connected to more than one other AS. An AS 
also qualifies as multihomed if it is connected to a public Internet Exchange 
Point.

In the ASN request form, you will be asked to provide the estimate ASN 
implementation date, two peer AS numbers and their contact details. It is also 
acceptable if your network only connect to an IXP.

So what if I only have one upstream provider and doesn't have a Public IX in 
place? What If I just whois any member from my country and provide AS numbers 
and contact details publicly available? Do you check back after 3 months that 
the AS you provided to the applicant is actually peering with the ones they 
mentioned in the application? Do you send email notification to those contacts 
provided in the application that XYZ has mentioned your AS to be peer with in 
future?

Regards,

Aftab A. Siddiqui.
*  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-114: Modification in the ASN eligibility criteria

[Skeeve Stevens]

Owen,

The intent is not to give people as many AS's as they want, and indeed few
businesses would ever need more than 1 AS.

What about if businesses did not have the multi-homing requirement for the
first ASN they were issued?


...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, Feb 26, 2015 at 8:15 AM, Owen DeLong  wrote:

>
> > On Feb 25, 2015, at 00:32 , Skeeve Stevens  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 from it, without going through a change
> in network configuration.
> >
> > That might be easy for you, but that is simply your opinion on how
> things should be done... not a reason why others shouldn't be allowed to do
> it the way they want to.
> >
> > If a member has a portable range, they should be entitled to - with no
> restrictions - a ASN number to be able to BE as portable as they want to.
>
> Even if I agreed with what you have said above, and I do not, this last
> statement bears no resemblence to the policy you have proposed.
>
> If you want to propose a policy that matches your last sentence, I would
> not oppose that, so long as any additional ASNs had to be issued under the
> current multihome requirement.
>
> However, your proposal doesn’t say someone who has PI space is entitled to
> 1 ASN. It says anyone who wants one is entitled to as many ASNs as they
> want.
>
> That’s simply a bad idea.
>
> Owen
>
>
*  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-114: Modification in the ASN eligibility criteria

[Owen DeLong]

> On Feb 25, 2015, at 15:10 , David Farmer  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 with that.
>> 
>> Dean
> 
> From a policy perspective there is no barrier to entry.
> 
> However, from an operational perspective, I see it a little differently; 
> having deployed my network using a private ASN, I then need to migrate to a 
> new unique registry assigned ASN.  Which you are saying I can't have until 
> I've grown to the point were I need to multi-home or connect to an IX.  If 
> I'm a small network, this may not be a big hardship.  But if you connect to a 
> single provider in multiple cities you could build a fairly extensive network 
> that would not qualify for a registry assigned ASN until you got a second 
> provider or connected to an IX, at which point the transition to the new ASN 
> could be rather complicated.

That’s actually not the case.

The case is until you choose to multihome or connect to an IX. You can choose 
to do that with a pretty small network. My home is multihomed, for example.

Any network with an IPv4 upstream can get an IPv6 tunnel from HE, turn on BGP, 
and poof, they are sufficiently multihomed for the APNIC definition. HE has 
several tunnel servers in the APNIC region to support this.

Changing ASNs on peering sessions actually isn’t very hard. There’s a brief 
period where you have inconsistent origin, but otherwise, it’s mostly one line 
of config change on each of your border routers. Even if you’ve got a hundred 
peering sessions, it’s something that can be done in a day or two with a 
cooperative provider. It might take a few weeks with some of the less 
responsive providers.

However, while I’m not trying to tell anyone how to run their network, I think 
we can agree that it is pretty foolhearty to get much beyond 2 or 3 peering 
sessions without mixing in some provider diversity. Further, if you want to 
plan ahead and deploy an ASN early, turning up an HE tunnel to do that is 
pretty easy. Unless HE is your only upstream for IPv4, you’re all set at that 
point.

> I'm not sure that justifies obliterating the current policy, but there is at 
> least an operational barrier to entry in some situations.  I think maybe a 
> compromise would be to allow a network of a certain size to obtain an ASN 
> regardless of having a unique routing policy, being multi-homed, or connected 
> to an IX.

I don’t think size is relevant. As I said, I wouldn’t oppose a policy 
modification that in addition to the current mechanisms, allowed for anyone 
with a PI allocation or assignment to obtain a single ASN without question.

> A network of 1 or 2 routers probably doesn't justify an ASN unless it is 
> multi-homed or connected to an IX.  A network of 100 routers probably 
> justifies an ASN regardless.  Then the question becomes, where to draw the 
> line.

I’m having trouble envisioning who would build a network with 100 border 
routers (only the border routers really count in this case) without connecting 
to more than one upstream. This smells like looking for a corner case to 
justify a solution looking for a problem statement.


Owen


*  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-114: Modification in the ASN eligibility criteria

[Skeeve Stevens]

Owen,

Can't you see the fault in your argument?  You are suggesting that a member
needlessly creates a tunnel to HE just to satisfy the needs of the current
policy... that seems wasteful and a stupid hoop which just gets around the
policy.

I might as well just offer free peering with a couple of routes to my ASN
for anyone who wants to satisfy the policy.

The point here is fixing a requirement that is so easily avoided, it needed
be there in the first place.

All you are doing is causing people to create route-object garbage so that
they are able to run their networks the way they want to.


...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, Feb 26, 2015 at 8:26 AM, Owen DeLong  wrote:

>
> > On Feb 25, 2015, at 15:10 , David Farmer  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 with that.
> >>
> >> Dean
> >
> > From a policy perspective there is no barrier to entry.
> >
> > However, from an operational perspective, I see it a little differently;
> having deployed my network using a private ASN, I then need to migrate to a
> new unique registry assigned ASN.  Which you are saying I can't have until
> I've grown to the point were I need to multi-home or connect to an IX.  If
> I'm a small network, this may not be a big hardship.  But if you connect to
> a single provider in multiple cities you could build a fairly extensive
> network that would not qualify for a registry assigned ASN until you got a
> second provider or connected to an IX, at which point the transition to the
> new ASN could be rather complicated.
>
> That’s actually not the case.
>
> The case is until you choose to multihome or connect to an IX. You can
> choose to do that with a pretty small network. My home is multihomed, for
> example.
>
> Any network with an IPv4 upstream can get an IPv6 tunnel from HE, turn on
> BGP, and poof, they are sufficiently multihomed for the APNIC definition.
> HE has several tunnel servers in the APNIC region to support this.
>
> Changing ASNs on peering sessions actually isn’t very hard. There’s a
> brief period where you have inconsistent origin, but otherwise, it’s mostly
> one line of config change on each of your border routers. Even if you’ve
> got a hundred peering sessions, it’s something that can be done in a day or
> two with a cooperative provider. It might take a few weeks with some of the
> less responsive providers.
>
> However, while I’m not trying to tell anyone how to run their network, I
> think we can agree that it is pretty foolhearty to get much beyond 2 or 3
> peering sessions without mixing in some provider diversity. Further, if you
> want to plan ahead and deploy an ASN early, turning up an HE tunnel to do
> that is pretty easy. Unless HE is your only upstream for IPv4, you’re all
> set at that point.
>
> > I'm not sure that justifies obliterating the current policy, but there
> is at least an operational barrier to entry in some situations.  I think
> maybe a compromise would be to allow a network of a certain size to obtain
> an ASN regardless of having a unique routing policy, being multi-homed, or
> connected to an IX.
>
> I don’t think size is relevant. As I said, I wouldn’t oppose a policy
> modification that in addition to the current mechanisms, allowed for anyone
> with a PI allocation or assignment to obtain a single ASN without question.
>
> > A network of 1 or 2 routers probably doesn't justify an ASN unless it is
> multi-homed or connected to an IX.  A network of 100 routers probably
> justifies an ASN regardless.  Then the question becomes, where to draw the
> line.
>
> I’m having trouble envisioning who would build a network with 100 border
> routers (only the border routers really count in this case) without
> connecting to more than one upstream. This smells like looking for a corner
> case to justify a solution looking for a problem statement.
>
>
> Owen
>
>
> *  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 Policy Proposal] prop-114: Modification in the ASN eligibility criteria

[Dean Pemberton]

Actually the RFC makes this clear.

There is clear guidance within RFC1930 for this which is marked as "BEST
CURRENT PRACTICE".  Please someone let me know if I've missed an
obsolescence here.

All of the situations you are talking about are described as "rare and
should almost never happen".  If you believe that the RFC is wrong and no
longer constitutes best practice, then engage in the IETF community and try
and fix this at the source rather than using RIR policy to justify a
departure from documented current best practice.



5.1 Sample Cases

   *Single-homed site, single prefix

A separate AS is not needed; the prefix should be placed in an
AS of the provider. The site's prefix has exactly the same rout-
ing policy as the other customers of the site's service
provider, and there is no need to make any distinction in rout-
ing information.

This idea may at first seem slightly alien to some, but it high-
lights the clear distinction in the use of the AS number as a
representation of routing policy as opposed to some form of
administrative use.

In some situations, a single site, or piece of a site, may find
it necessary to have a policy different from that of its
provider, or the rest of the site. In such an instance, a sepa-
rate AS must be created for the affected prefixes. This situa-
tion is rare and should almost never happen. Very few stub sites
require different routing policies than their parents. Because
the AS is the unit of policy, however, this sometimes occurs.

   *Single-homed site, multiple prefixes

Again, a separate AS is not needed; the prefixes should be
placed in an AS of the site's provider.

   *Multi-homed site

Here multi-homed is taken to mean a prefix or group of prefixes
which connects to more than one service provider (i.e. more than
one AS with its own routing policy). It does not mean a network
multi-homed running an IGP for the purposes of resilience.

An AS is required; the site's prefixes should be part of a
single AS, distinct from the ASes of its service providers.
This allows the customer the ability to have a different repre-
sentation of policy and preference among the different service
providers.

This is ALMOST THE ONLY case where a network operator should
create its own AS number. In this case, the site should ensure
that it has the necessary facilities to run appropriate routing
protocols, such as BGP4.

--
Dean Pemberton

Technical Policy Advisor
InternetNZ
+64 21 920 363 (mob)
d...@internetnz.net.nz

To promote the Internet's benefits and uses, and protect its potential.

On Thu, Feb 26, 2015 at 12:11 PM, Skeeve Stevens  wrote:

> Owen,
>
> But who determines 'if they need one' ?  Them, or you (plural)?
>
> I believe they should be able to determine that they need one and be able
> to get one based on that decision - not told how they should be doing their
> upstream connectivity at any particular time.
>
>
> ...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, Feb 26, 2015 at 8:03 AM, Owen DeLong  wrote:
>
>>
>> > On Feb 24, 2015, at 22:47 , Raphael Ho 
>> 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 since
>> > they will require an ASN to peer/multihome at some point in the future
>> > (which I do agree)
>>
>> What is the disadvantage for them to get the ASN later, when they
>> actually need it?
>>
>> > Currently they all have to "commit fraud² in order to get an ASN, and I
>> > guess some religion takes that more seriously than others.
>>
>> They only have to commit fraud if they are determined to get an ASN
>> before they need one.
>>
>> > Would we the proposal be acceptable if we reworded the proposal to say
>> > something on the lines of
>> >
>> > ³Eligible LIRs with APNIC Assigned Portable addresses are also eligible
>> > for as ASN²?
>>
>> I think “an ASN” rather than “as ASN”, but I’d need to better understand
>> why they need one
>> ahead of time. What’s wrong with getting the ASN when you need it?
>>
>> Owen
>>
>>
>> *  sig-policy:  APNIC SIG on resource management policy
>>  *
>> ___
>> sig-policy mailing list
>> sig-policy@lists.apnic.net
>> http://mailman.apnic.net/mailman/listinfo

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

[Skeeve Stevens]

Dean,

You are quoting an RFC from 1996 (19 years ago)?  What next, the Old
Testament? Thou shalt be multi-homed?

I don't think this RFC ever envisioned the IP runout and that networks
hosted by businesses themselves (of any size) would need multi-homing and
in the reading of this, you could make an argument that no-one needs an ASN
and that all their upstreams could host their portable space for them.

Please understand, that I am not suggesting giving an ASN to anyone who has
no intention of ever multi-homing.

I am wanting to policy to reflect that if a network operator wants to
design their network for multi-homing, that they should be able to, with no
requirement to immediately multi-home.  At no point did I say 'never'
multi-home, or no intention of multi-homing the intention should be
there.

I'm asking that the policy reflect an operators choice to decide how they
manage their networks should they choose to do it that way.



...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, Feb 26, 2015 at 8:36 AM, Dean Pemberton 
wrote:

> Actually the RFC makes this clear.
>
> There is clear guidance within RFC1930 for this which is marked as "BEST
> CURRENT PRACTICE".  Please someone let me know if I've missed an
> obsolescence here.
>
> All of the situations you are talking about are described as "rare and
> should almost never happen".  If you believe that the RFC is wrong and no
> longer constitutes best practice, then engage in the IETF community and try
> and fix this at the source rather than using RIR policy to justify a
> departure from documented current best practice.
>
>
>
> 5.1 Sample Cases
>
>*Single-homed site, single prefix
>
> A separate AS is not needed; the prefix should be placed in an
> AS of the provider. The site's prefix has exactly the same rout-
> ing policy as the other customers of the site's service
> provider, and there is no need to make any distinction in rout-
> ing information.
>
> This idea may at first seem slightly alien to some, but it high-
> lights the clear distinction in the use of the AS number as a
> representation of routing policy as opposed to some form of
> administrative use.
>
> In some situations, a single site, or piece of a site, may find
> it necessary to have a policy different from that of its
> provider, or the rest of the site. In such an instance, a sepa-
> rate AS must be created for the affected prefixes. This situa-
> tion is rare and should almost never happen. Very few stub sites
> require different routing policies than their parents. Because
> the AS is the unit of policy, however, this sometimes occurs.
>
>*Single-homed site, multiple prefixes
>
> Again, a separate AS is not needed; the prefixes should be
> placed in an AS of the site's provider.
>
>*Multi-homed site
>
> Here multi-homed is taken to mean a prefix or group of prefixes
> which connects to more than one service provider (i.e. more than
> one AS with its own routing policy). It does not mean a network
> multi-homed running an IGP for the purposes of resilience.
>
> An AS is required; the site's prefixes should be part of a
> single AS, distinct from the ASes of its service providers.
> This allows the customer the ability to have a different repre-
> sentation of policy and preference among the different service
> providers.
>
> This is ALMOST THE ONLY case where a network operator should
> create its own AS number. In this case, the site should ensure
> that it has the necessary facilities to run appropriate routing
> protocols, such as BGP4.
>
> --
> Dean Pemberton
>
> Technical Policy Advisor
> InternetNZ
> +64 21 920 363 (mob)
> d...@internetnz.net.nz
>
> To promote the Internet's benefits and uses, and protect its potential.
>
> On Thu, Feb 26, 2015 at 12:11 PM, Skeeve Stevens  wrote:
>
>> Owen,
>>
>> But who determines 'if they need one' ?  Them, or you (plural)?
>>
>> I believe they should be able to determine that they need one and be able
>> to get one based on that decision - not told how they should be doing their
>> upstream connectivity at any particular time.
>>
>>
>> ...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/theispgu

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

[Dean Pemberton]

On Thu, Feb 26, 2015 at 12:50 PM, Skeeve Stevens  wrote:

>
>
> I'm asking that the policy reflect an operators choice to decide how they
> manage their networks should they choose to do it that way.
>
>
>
I believe we've entered the point of diminishing returns here.

It has been shown multiple times in this thread that there is no barrier to
getting an ASN if one is required under the current policy.  This fact has
been supported by the current hostmasters.  Operators currently have the
freedom to choose how to manage their networks, they can choose to get an
ASN anytime they need one for operational purposes.

There is no change in policy required.

I strongly oppose this policy as written.
*  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-114: Modification in the ASN eligibility criteria

[Owen DeLong]

> On Feb 25, 2015, at 15:36 , Skeeve Stevens  wrote:
> 
> Owen,
> 
> Can't you see the fault in your argument?  You are suggesting that a member 
> needlessly creates a tunnel to HE just to satisfy the needs of the current 
> policy... that seems wasteful and a stupid hoop which just gets around the 
> policy.

Who said anything about needlessly… They probably need IPv6 and this gets them 
decent IPv6 connectivity.

> I might as well just offer free peering with a couple of routes to my ASN for 
> anyone who wants to satisfy the policy.

You’re certainly welcome to do that. After all, I’m not trying to tell you how 
to run your network.

> The point here is fixing a requirement that is so easily avoided, it needed 
> be there in the first place.

But you go so far beyond fixing the requirement that you break so much more. Go 
back and look at what I said about a policy I  would not object to.

> All you are doing is causing people to create route-object garbage so that 
> they are able to run their networks the way they want to.

I didn’t say anything about creating a single route object. There’s no 
requirement to create a route object or even use an IRR in anything I said, so 
you’re just wrong here.

Owen

> 
> 
> ...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, Feb 26, 2015 at 8:26 AM, Owen DeLong  > wrote:
> 
> > On Feb 25, 2015, at 15:10 , David Farmer  > > 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 with that.
> >>
> >> Dean
> >
> > From a policy perspective there is no barrier to entry.
> >
> > However, from an operational perspective, I see it a little differently; 
> > having deployed my network using a private ASN, I then need to migrate to a 
> > new unique registry assigned ASN.  Which you are saying I can't have until 
> > I've grown to the point were I need to multi-home or connect to an IX.  If 
> > I'm a small network, this may not be a big hardship.  But if you connect to 
> > a single provider in multiple cities you could build a fairly extensive 
> > network that would not qualify for a registry assigned ASN until you got a 
> > second provider or connected to an IX, at which point the transition to the 
> > new ASN could be rather complicated.
> 
> That’s actually not the case.
> 
> The case is until you choose to multihome or connect to an IX. You can choose 
> to do that with a pretty small network. My home is multihomed, for example.
> 
> Any network with an IPv4 upstream can get an IPv6 tunnel from HE, turn on 
> BGP, and poof, they are sufficiently multihomed for the APNIC definition. HE 
> has several tunnel servers in the APNIC region to support this.
> 
> Changing ASNs on peering sessions actually isn’t very hard. There’s a brief 
> period where you have inconsistent origin, but otherwise, it’s mostly one 
> line of config change on each of your border routers. Even if you’ve got a 
> hundred peering sessions, it’s something that can be done in a day or two 
> with a cooperative provider. It might take a few weeks with some of the less 
> responsive providers.
> 
> However, while I’m not trying to tell anyone how to run their network, I 
> think we can agree that it is pretty foolhearty to get much beyond 2 or 3 
> peering sessions without mixing in some provider diversity. Further, if you 
> want to plan ahead and deploy an ASN early, turning up an HE tunnel to do 
> that is pretty easy. Unless HE is your only upstream for IPv4, you’re all set 
> at that point.
> 
> > I'm not sure that justifies obliterating the current policy, but there is 
> > at least an operational barrier to entry in some situations.  I think maybe 
> > a compromise would be to allow a network of a certain size to obtain an ASN 
> > regardless of having a unique routing policy, being multi-homed, or 
> > connected to an IX.
> 
> I don’t think size is relevant. As I said, I wouldn’t oppose a policy 
> modification that in addition to the current mechanisms, allowed for anyone 
> with a PI allocation or assignment to obtain a single ASN without question.
> 
> > A network of 1 or 2 routers probably doesn't justify an ASN unless it is 
> > multi-homed or connected to an IX.  A network of 100 routers probably 
> > justifies an ASN reg

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

[Skeeve Stevens]

Dean,

What you are saying is your rose coloured view of this.

"You say they can get an ASN anytime they need one for operation
purposes".  I am saying that the case exists that operators will want to do
this - WITHOUT the requirement for being multi-homed.

The requirement for being multi-homed, 'as written' causes members to
either lie to provide false information or find a way around the
restriction (using HE or someone else) to choose how they wish to manage
their network.

You choosing to ignore this use case or situation doesn't make it go away
because you don't understand why they would want to manage their network in
that way.




...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, Feb 26, 2015 at 8:55 AM, Dean Pemberton 
wrote:

> On Thu, Feb 26, 2015 at 12:50 PM, Skeeve Stevens  wrote:
>
>>
>>
>> I'm asking that the policy reflect an operators choice to decide how they
>> manage their networks should they choose to do it that way.
>>
>>
>>
> I believe we've entered the point of diminishing returns here.
>
> It has been shown multiple times in this thread that there is no barrier
> to getting an ASN if one is required under the current policy.  This fact
> has been supported by the current hostmasters.  Operators currently have
> the freedom to choose how to manage their networks, they can choose to get
> an ASN anytime they need one for operational purposes.
>
> There is no change in policy required.
>
> I strongly oppose this policy as written.
>
>
>
*  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-114: Modification in the ASN eligibility criteria

[Owen DeLong]

> On Feb 25, 2015, at 15:50 , Skeeve Stevens  wrote:
> 
> Dean,
> 
> You are quoting an RFC from 1996 (19 years ago)?  What next, the Old 
> Testament? Thou shalt be multi-homed?
> 
> I don't think this RFC ever envisioned the IP runout and that networks hosted 
> by businesses themselves (of any size) would need multi-homing and in the 
> reading of this, you could make an argument that no-one needs an ASN and that 
> all their upstreams could host their portable space for them.

IP runout was well and truly known to be coming more than 20 years ago. That’s 
one of the reasons IPv6 was developed so long ago.

> 
> Please understand, that I am not suggesting giving an ASN to anyone who has 
> no intention of ever multi-homing.

Yes you are. You may not intend to suggest that, but your policy proposal 
wording certainly provides for it.

> 
> I am wanting to policy to reflect that if a network operator wants to design 
> their network for multi-homing, that they should be able to, with no 
> requirement to immediately multi-home.  At no point did I say 'never' 
> multi-home, or no intention of multi-homing the intention should be there.

Then propose a policy that does that. The current draft doesn’t. If it has 
sufficient safeguards against turning the ASN registry into a Pez dispenser, 
then I will support it.

> 
> I'm asking that the policy reflect an operators choice to decide how they 
> manage their networks should they choose to do it that way.

Nobody is objecting to that. However, that’s not a letter of the law 
interpretation of what you have proposed.

Owen

> 
> 
> 
> ...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, Feb 26, 2015 at 8:36 AM, Dean Pemberton  > wrote:
> Actually the RFC makes this clear.
> 
> There is clear guidance within RFC1930 for this which is marked as "BEST 
> CURRENT PRACTICE".  Please someone let me know if I've missed an obsolescence 
> here.
> 
> All of the situations you are talking about are described as "rare and should 
> almost never happen".  If you believe that the RFC is wrong and no longer 
> constitutes best practice, then engage in the IETF community and try and fix 
> this at the source rather than using RIR policy to justify a departure from 
> documented current best practice.  
> 
> 
> 
> 5.1 Sample Cases
> 
>*Single-homed site, single prefix
> 
> A separate AS is not needed; the prefix should be placed in an
> AS of the provider. The site's prefix has exactly the same rout-
> ing policy as the other customers of the site's service
> provider, and there is no need to make any distinction in rout-
> ing information.
> 
> This idea may at first seem slightly alien to some, but it high-
> lights the clear distinction in the use of the AS number as a
> representation of routing policy as opposed to some form of
> administrative use.
> 
> In some situations, a single site, or piece of a site, may find
> it necessary to have a policy different from that of its
> provider, or the rest of the site. In such an instance, a sepa-
> rate AS must be created for the affected prefixes. This situa-
> tion is rare and should almost never happen. Very few stub sites
> require different routing policies than their parents. Because
> the AS is the unit of policy, however, this sometimes occurs.
> 
>*Single-homed site, multiple prefixes
> 
> Again, a separate AS is not needed; the prefixes should be
> placed in an AS of the site's provider.
> 
>*Multi-homed site
> 
> Here multi-homed is taken to mean a prefix or group of prefixes
> which connects to more than one service provider (i.e. more than
> one AS with its own routing policy). It does not mean a network
> multi-homed running an IGP for the purposes of resilience.
> 
> An AS is required; the site's prefixes should be part of a
> single AS, distinct from the ASes of its service providers.
> This allows the customer the ability to have a different repre-
> sentation of policy and preference among the different service
> providers.
> 
> This is ALMOST THE ONLY case where a network operator should
> create its own AS number. In this case, the site should ensure
> that it has the necessary facilities to run appropr

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

[Mark Tinka]

While I tend to agree that the current draft policy in its form needs
more work, I empathize with the long-held concern of detachment between
the RIR and network operations. This is a well-documented issue that
affects several other policies within various RIR communities, and not
just this one nor APNIC. Take assigned prefix length and what operators
filter against as an example.

Globally, perhaps we would do well to find way to make RIR operations
and policy design reflect the practical day-to-day changes taking place
within operator networks, or at the very least, make a provision for
them that sufficiently covers what the future may throw up.

I don't think any of us have the answers now, but it starts from somewhere.

Mark.
*  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-114: Modification in the ASN eligibility criteria

[Gaurab Raj Upadhaya]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 2/25/15 11:10 PM, David Farmer wrote:

> A network of 1 or 2 routers probably doesn't justify an ASN unless
> it is multi-homed or connected to an IX.  A network of 100 routers
> probably justifies an ASN regardless.  Then the question becomes,
> where to draw the line.

even more slippery slope. eg. AS 29216 has a single upstream, with
just 2 prefixes (one v4, one v6).  and they have a legitimate need, so
size is irrelevant.

- -gaurab

-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)

iEYEARECAAYFAlTvNvoACgkQSo7fU26F3X10YACgtvvwLsn/IBjwM0hzZyw5gry9
tV0AoMjytMyN2Mgwm6Qr0m1DUE1GS5zo
=uwQr
-END PGP SIGNATURE-
*  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-114: Modification in the ASN eligibility criteria

[Job Snijders]

On Thu, Feb 26, 2015 at 03:08:42PM +, Gaurab Raj Upadhaya wrote:
> On 2/25/15 11:10 PM, David Farmer wrote:
> 
> > A network of 1 or 2 routers probably doesn't justify an ASN unless
> > it is multi-homed or connected to an IX.  A network of 100 routers
> > probably justifies an ASN regardless.  Then the question becomes,
> > where to draw the line.
> 
> even more slippery slope. eg. AS 29216 has a single upstream, with
> just 2 prefixes (one v4, one v6).  and they have a legitimate need, so
> size is irrelevant.

I agree with Gaurab, attempting to pinpoint where to draw the line in
this context is not worth the effort. Talking about 'size', assumes
networks can be classified by quantitative metrics.
*  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-114: Modification in the ASN eligibility criteria

[Owen DeLong]

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, ICANN, and other multi-stakeholder fora 
covering various aspects of internet governance and development.

If you have a suggestion for getting greater operator participation in these 
processes, I’m all ears.

Owen

> On Feb 25, 2015, at 5:27 PM, Mark Tinka  wrote:
> 
> While I tend to agree that the current draft policy in its form needs
> more work, I empathize with the long-held concern of detachment between
> the RIR and network operations. This is a well-documented issue that
> affects several other policies within various RIR communities, and not
> just this one nor APNIC. Take assigned prefix length and what operators
> filter against as an example.
> 
> Globally, perhaps we would do well to find way to make RIR operations
> and policy design reflect the practical day-to-day changes taking place
> within operator networks, or at the very least, make a provision for
> them that sufficiently covers what the future may throw up.
> 
> I don't think any of us have the answers now, but it starts from somewhere.
> 
> Mark.
> *  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 Policy Proposal] prop-114: Modification in the ASN eligibility criteria

[Masato Yamanishi]

Skeeve,

As acting chair, I'm neutral for each proposal, but even for me, proposed text 
sounds everybody can get AS by just saying "I need it within 6 months" without 
any explanation howto use it.
If your intension is covering more usecases, but not allowing for everyone, can 
you tweak proposed text?

> 4. Proposed policy solution
> ---
> 
> An organization is eligible for an ASN assignment if it:
>  - Is planning to use it within next 6 months

Masato Yamanishi


Feb 25, 2015 6:03 PM、Skeeve Stevens  のメッセージ:

> Dean,
> 
> What you are saying is your rose coloured view of this.
> 
> "You say they can get an ASN anytime they need one for operation purposes".  
> I am saying that the case exists that operators will want to do this - 
> WITHOUT the requirement for being multi-homed.
> 
> The requirement for being multi-homed, 'as written' causes members to either 
> lie to provide false information or find a way around the restriction (using 
> HE or someone else) to choose how they wish to manage their network.
> 
> You choosing to ignore this use case or situation doesn't make it go away 
> because you don't understand why they would want to manage their network in 
> that way.
> 
> 
> 
> 
> ...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, Feb 26, 2015 at 8:55 AM, Dean Pemberton  
>> wrote:
>>> On Thu, Feb 26, 2015 at 12:50 PM, Skeeve Stevens  wrote:
>>> 
>>> 
>>> I'm asking that the policy reflect an operators choice to decide how they 
>>> manage their networks should they choose to do it that way.
>> 
>> I believe we've entered the point of diminishing returns here.
>> 
>> It has been shown multiple times in this thread that there is no barrier to 
>> getting an ASN if one is required under the current policy.  This fact has 
>> been supported by the current hostmasters.  Operators currently have the 
>> freedom to choose how to manage their networks, they can choose to get an 
>> ASN anytime they need one for operational purposes.
>> 
>> There is no change in policy required.
>> 
>> I strongly oppose this policy as written.
> 
> *  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 Policy Proposal] prop-114: Modification in the ASN eligibility criteria

[Skeeve Stevens]

We will have new wording soon.


...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 Fri, Feb 27, 2015 at 7:03 AM, Masato Yamanishi 
wrote:

> Skeeve,
>
> As acting chair, I'm neutral for each proposal, but even for me, proposed
> text sounds everybody can get AS by just saying "I need it within 6 months"
> without any explanation howto use it.
> If your intension is covering more usecases, but not allowing for
> everyone, can you tweak proposed text?
>
> > 4. Proposed policy solution
> > ---
> >
> > An organization is eligible for an ASN assignment if it:
> >  - Is planning to use it within next 6 months
>
> Masato Yamanishi
>
>
> Feb 25, 2015 6:03 PM、Skeeve Stevens  のメッセージ:
>
> Dean,
>
> What you are saying is your rose coloured view of this.
>
> "You say they can get an ASN anytime they need one for operation
> purposes".  I am saying that the case exists that operators will want to do
> this - WITHOUT the requirement for being multi-homed.
>
> The requirement for being multi-homed, 'as written' causes members to
> either lie to provide false information or find a way around the
> restriction (using HE or someone else) to choose how they wish to manage
> their network.
>
> You choosing to ignore this use case or situation doesn't make it go away
> because you don't understand why they would want to manage their network in
> that way.
>
>
>
>
> ...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, Feb 26, 2015 at 8:55 AM, Dean Pemberton 
> wrote:
>
>> On Thu, Feb 26, 2015 at 12:50 PM, Skeeve Stevens 
>> wrote:
>>
>>>
>>>
>>> I'm asking that the policy reflect an operators choice to decide how
>>> they manage their networks should they choose to do it that way.
>>>
>>>
>>>
>> I believe we've entered the point of diminishing returns here.
>>
>> It has been shown multiple times in this thread that there is no barrier
>> to getting an ASN if one is required under the current policy.  This fact
>> has been supported by the current hostmasters.  Operators currently have
>> the freedom to choose how to manage their networks, they can choose to get
>> an ASN anytime they need one for operational purposes.
>>
>> There is no change in policy required.
>>
>> I strongly oppose this policy as written.
>>
>>
>>
>
> *  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 Policy Proposal] prop-114: Modification in the ASN eligibility criteria

[Izumi Okutani]

Hi all,


I agree with the suggested approach from the chair.

Raphael's earlier post was really helpful in understanding the 
situation. Thank you Raphael.



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 since
they will require an ASN to peer/multihome at some point in the future
(which I do agree)


I sympathize with this too.

I can see cases where an applicant plans to be multihomed but not 
multi-homed at the time of the application.



May I clarify with APNIC hosmaster whether :

 a. It is a must for an applicant to be multihomed at the time of
submitting the request

 b. If an applicant can demonstrate a plan to be multihomed in
immediate future, it is not a must they are physically multihomed
at the time of submitting a request

In case of JPNIC, it is b.

 - We approve the ASN assignments if an applicant can demonstrate the
   *plan* to be multihomed within three months.


I wonder taking approach b (accept a plan to be multihomed) addresses 
the problem described by Raphael (and Aftab) ?





Regards,
Izumi


On 2015/02/27 7:03, Masato Yamanishi wrote:

Skeeve,

As acting chair, I'm neutral for each proposal, but even for me, proposed text sounds 
everybody can get AS by just saying "I need it within 6 months" without any 
explanation howto use it.
If your intension is covering more usecases, but not allowing for everyone, can 
you tweak proposed text?


4. Proposed policy solution
---

 An organization is eligible for an ASN assignment if it:
  - Is planning to use it within next 6 months


Masato Yamanishi


Feb 25, 2015 6:03 PM、Skeeve Stevens  のメッセージ:


Dean,

What you are saying is your rose coloured view of this.

"You say they can get an ASN anytime they need one for operation purposes".  I 
am saying that the case exists that operators will want to do this - WITHOUT the 
requirement for being multi-homed.

The requirement for being multi-homed, 'as written' causes members to either 
lie to provide false information or find a way around the restriction (using HE 
or someone else) to choose how they wish to manage their network.

You choosing to ignore this use case or situation doesn't make it go away 
because you don't understand why they would want to manage their network in 
that way.




...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, Feb 26, 2015 at 8:55 AM, Dean Pemberton  wrote:

On Thu, Feb 26, 2015 at 12:50 PM, Skeeve Stevens  wrote:


I'm asking that the policy reflect an operators choice to decide how they 
manage their networks should they choose to do it that way.


I believe we've entered the point of diminishing returns here.

It has been shown multiple times in this thread that there is no barrier to 
getting an ASN if one is required under the current policy.  This fact has been 
supported by the current hostmasters.  Operators currently have the freedom to 
choose how to manage their networks, they can choose to get an ASN anytime they 
need one for operational purposes.

There is no change in policy required.

I strongly oppose this policy as written.


*  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



*  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-114: Modification in the ASN eligibility criteria

[Guangliang Pan]

Hi Izumi,

The option "b" is acceptable.

b. If an applicant can demonstrate a plan to be multihomed in
 immediate future, it is not a must they are physically multihomed
 at the time of submitting a request

Thanks,
Guangliang
=

-Original Message-
From: sig-policy-boun...@lists.apnic.net 
[mailto:sig-policy-boun...@lists.apnic.net] On Behalf Of Izumi Okutani
Sent: Friday, 27 February 2015 2:48 PM
To: sig-policy@lists.apnic.net
Subject: Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the 
ASN eligibility criteria

Hi all,


I agree with the suggested approach from the chair.

Raphael's earlier post was really helpful in understanding the situation. Thank 
you Raphael.

> 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 
> since they will require an ASN to peer/multihome at some point in the 
> future (which I do agree)

I sympathize with this too.

I can see cases where an applicant plans to be multihomed but not multi-homed 
at the time of the application.


May I clarify with APNIC hosmaster whether :

  a. It is a must for an applicant to be multihomed at the time of
 submitting the request

  b. If an applicant can demonstrate a plan to be multihomed in
 immediate future, it is not a must they are physically multihomed
 at the time of submitting a request

In case of JPNIC, it is b.

  - We approve the ASN assignments if an applicant can demonstrate the
*plan* to be multihomed within three months.


I wonder taking approach b (accept a plan to be multihomed) addresses 
the problem described by Raphael (and Aftab) ?




Regards,
Izumi


On 2015/02/27 7:03, Masato Yamanishi wrote:
> Skeeve,
>
> As acting chair, I'm neutral for each proposal, but even for me, proposed 
> text sounds everybody can get AS by just saying "I need it within 6 months" 
> without any explanation howto use it.
> If your intension is covering more usecases, but not allowing for everyone, 
> can you tweak proposed text?
>
>> 4. Proposed policy solution
>> ---
>>
>>  An organization is eligible for an ASN assignment if it:
>>   - Is planning to use it within next 6 months
>
> Masato Yamanishi
>
>
> Feb 25, 2015 6:03 PM、Skeeve Stevens  のメッセージ:
>
>> Dean,
>>
>> What you are saying is your rose coloured view of this.
>>
>> "You say they can get an ASN anytime they need one for operation purposes".  
>> I am saying that the case exists that operators will want to do this - 
>> WITHOUT the requirement for being multi-homed.
>>
>> The requirement for being multi-homed, 'as written' causes members to either 
>> lie to provide false information or find a way around the restriction (using 
>> HE or someone else) to choose how they wish to manage their network.
>>
>> You choosing to ignore this use case or situation doesn't make it go away 
>> because you don't understand why they would want to manage their network in 
>> that way.
>>
>>
>>
>>
>> ...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, Feb 26, 2015 at 8:55 AM, Dean Pemberton  
>>> wrote:
>>>> On Thu, Feb 26, 2015 at 12:50 PM, Skeeve Stevens  wrote:
>>>>
>>>>
>>>> I'm asking that the policy reflect an operators choice to decide how they 
>>>> manage their networks should they choose to do it that way.
>>>
>>> I believe we've entered the point of diminishing returns here.
>>>
>>> It has been shown multiple times in this thread that there is no barrier to 
>>> getting an ASN if one is required under the current policy.  This fact has 
>>> been supported by the current hostmasters.  Operators currently have the 
>>> freedom to choose how to manage their networks, they can choose to get an 
>>> ASN anytime they need one for operational purposes.
>>>
>>> There is no change in policy required.
>>>
>>> I strongly oppose this policy as written.
>>
>> *  sig-policy:  APNIC SIG on resource management policy  
>>  *
>> ___
>

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

[Aftab Siddiqui]

Hi Guangliang,


> The option "b" is acceptable.
>
> b. If an applicant can demonstrate a plan to be multihomed in
>  immediate future, it is not a must they are physically multihomed
>  at the time of submitting a request
>

But even then applicant has to provide the details of those ASN with whom
they may or may not multhome in future. right?

Regards,

Aftab A. Siddiqui
*  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-114: Modification in the ASN eligibility criteria

[Izumi Okutani]

Hi Guangliang,


> The option "b" is acceptable.
>
> b. If an applicant can demonstrate a plan to be multihomed in
>   immediate future, it is not a must they are physically multihomed
>   at the time of submitting a request


Thanks. Helpful to know and that's consistent with how we handle ASN 
requests in JPNIC.


If the issue is, some applicants misunderstand they must be multihomed 
at the time of submitting the ASN request (and plan to be multihomed is 
not acceptable), as described in an earlier post -


Perhaps it is a matter of stating this more clearly in the policy document?


Thanks,
Izumi


On 2015/02/27 13:54, Guangliang Pan wrote:

Hi Izumi,

The option "b" is acceptable.

b. If an applicant can demonstrate a plan to be multihomed in
  immediate future, it is not a must they are physically multihomed
  at the time of submitting a request

Thanks,
Guangliang
=

-Original Message-
From: sig-policy-boun...@lists.apnic.net 
[mailto:sig-policy-boun...@lists.apnic.net] On Behalf Of Izumi Okutani
Sent: Friday, 27 February 2015 2:48 PM
To: sig-policy@lists.apnic.net
Subject: Re: [sig-policy] [New Policy Proposal] prop-114: Modification in the 
ASN eligibility criteria

Hi all,


I agree with the suggested approach from the chair.

Raphael's earlier post was really helpful in understanding the situation. Thank 
you Raphael.


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
since they will require an ASN to peer/multihome at some point in the
future (which I do agree)


I sympathize with this too.

I can see cases where an applicant plans to be multihomed but not multi-homed 
at the time of the application.


May I clarify with APNIC hosmaster whether :

   a. It is a must for an applicant to be multihomed at the time of
  submitting the request

   b. If an applicant can demonstrate a plan to be multihomed in
  immediate future, it is not a must they are physically multihomed
  at the time of submitting a request

In case of JPNIC, it is b.

   - We approve the ASN assignments if an applicant can demonstrate the
 *plan* to be multihomed within three months.


I wonder taking approach b (accept a plan to be multihomed) addresses
the problem described by Raphael (and Aftab) ?




Regards,
Izumi


On 2015/02/27 7:03, Masato Yamanishi wrote:

Skeeve,

As acting chair, I'm neutral for each proposal, but even for me, proposed text sounds 
everybody can get AS by just saying "I need it within 6 months" without any 
explanation howto use it.
If your intension is covering more usecases, but not allowing for everyone, can 
you tweak proposed text?


4. Proposed policy solution
---

  An organization is eligible for an ASN assignment if it:
   - Is planning to use it within next 6 months


Masato Yamanishi


Feb 25, 2015 6:03 PM、Skeeve Stevens  のメッセージ:


Dean,

What you are saying is your rose coloured view of this.

"You say they can get an ASN anytime they need one for operation purposes".  I 
am saying that the case exists that operators will want to do this - WITHOUT the 
requirement for being multi-homed.

The requirement for being multi-homed, 'as written' causes members to either 
lie to provide false information or find a way around the restriction (using HE 
or someone else) to choose how they wish to manage their network.

You choosing to ignore this use case or situation doesn't make it go away 
because you don't understand why they would want to manage their network in 
that way.




...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, Feb 26, 2015 at 8:55 AM, Dean Pemberton  wrote:

On Thu, Feb 26, 2015 at 12:50 PM, Skeeve Stevens  wrote:


I'm asking that the policy reflect an operators choice to decide how they 
manage their networks should they choose to do it that way.


I believe we've entered the point of diminishing returns here.

It has been shown multiple times in this thread that there is no barrier to 
getting an ASN if one is required under the current policy.  This fact has been 
supported by the current hostmasters.  Operators currently have the freedom to 
choose how to manage their networks, they can choose to get an ASN anytime they 
need one for operational purposes.

There is no change in policy required.

I strongly oppose this policy as written.


*  sig-policy:  APNIC SIG on resource management policy   *
___

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

[Guangliang Pan]

Hi Aftab,

The option "b" is acceptable.

b. If an applicant can demonstrate a plan to be multihomed in
 immediate future, it is not a must they are physically multihomed
 at the time of submitting a request

But even then applicant has to provide the details of those ASN with whom they 
may or may not multhome in future. right?

Yes, they need to provide two ASNs which they planned to peer at the time of 
the application. They might peer to different ASNs after they received their 
own AS number.

Thanks,
Guangliang
=



*  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-114: Modification in the ASN eligibility criteria

[Izumi Okutani]

On 2015/02/27 14:00, Aftab Siddiqui wrote:
> Hi Guangliang,
> 
> 
>> The option "b" is acceptable.
>>
>> b. If an applicant can demonstrate a plan to be multihomed in
>>   immediate future, it is not a must they are physically multihomed
>>   at the time of submitting a request
>>
> 
> But even then applicant has to provide the details of those ASN with whom
> they may or may not multhome in future. right?
> 

I don't know whether it's adequate to do the same case in the APNIC
region but sharing our case as a reference -

JPNIC requests for contact information for those ASNs they plan to be
connected.

We sometimes we contact the upstreams and confirm the plan and this
seems to be working OK.


Regards,
Izumi

*  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-114: Modification in the ASN eligibility criteria

[Mark Tinka]

On 27/Feb/15 07:14, Izumi Okutani wrote:
> I don't know whether it's adequate to do the same case in the APNIC
> region but sharing our case as a reference -
>
> JPNIC requests for contact information for those ASNs they plan to be
> connected.
>
> We sometimes we contact the upstreams and confirm the plan and this
> seems to be working OK.

AFRINIC do the same thing.

They reach out to the ISP that the applicant has listed in their
application form to confirm whether, indeed, there are real plans for
the applicant to connect to to said ISP.

I'm not sure if they do the same for exchange points, as I'm not in that
space.

Mark.
*  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-114: Modification in the ASN eligibility criteria

[Aftab Siddiqui]

Hi Izumi,


> Thanks. Helpful to know and that's consistent with how we handle ASN
> requests in JPNIC.
>

w.r.t JPNIC, do they ask for the details of those ASN (along with contact
details) with whom applicant is planning to multi-home in future? Do they
have any mechanism to check the authenticity of those ASN and contact
details provided?

Regards,

Aftab A. Siddiqui
*  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-114: Modification in the ASN eligibility criteria

[Izumi Okutani]

Hi Aftab,


On 2015/02/27 14:19, Aftab Siddiqui wrote:
> Hi Izumi,
> 
> 
>> Thanks. Helpful to know and that's consistent with how we handle ASN
>> requests in JPNIC.
>>
> 
> w.r.t JPNIC, do they ask for the details of those ASN (along with contact
> details) with whom applicant is planning to multi-home in future? Do they
> have any mechanism to check the authenticity of those ASN and contact
> details provided?
> 

We would know which organization the ASNs are assigned to, as those
upstream ASNs are already used.

We don't have a formal mechanism to check the authenticity of the POCs
but usually check the e-mails provided are reachable. We would find it
suspicious if the domain name of the e-mail provided is different from
the domain used for the organization or free e-mail accounts.

It's not formal in the sense that we request upstream ASNs to register a
POC. I suppose therefore you can still forge domain name, etc, but it is
sufficient in our case to give credibility above a certain level.



Regards,
Izumi


*  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-114: Modification in the ASN eligibility criteria

[Mark Tinka]

On 27/Feb/15 07:34, Izumi Okutani wrote:
> We would know which organization the ASNs are assigned to, as those
> upstream ASNs are already used.
>
> We don't have a formal mechanism to check the authenticity of the POCs
> but usually check the e-mails provided are reachable. We would find it
> suspicious if the domain name of the e-mail provided is different from
> the domain used for the organization or free e-mail accounts.
>
> It's not formal in the sense that we request upstream ASNs to register a
> POC. I suppose therefore you can still forge domain name, etc, but it is
> sufficient in our case to give credibility above a certain level.

In the AFRINIC region, the membership have been mostly frustrated by
this added step by the AFRINIC hostmasters. But personally, I support if
they can always enforce it, as it adds some kind of "proof" that the
application information is reasonably genuine and the chances of faking
needs are somewhat reduced (which is better than not being reduced).

Of course, an applicant could collude with the ISP to let them claim the
applicant is, in fact, going to buy services that warrant the allocation
of resources. However, this comes back to the integrity of the ISP. Not
100% foolproof, but a step in some direction.

Mark.
*  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-114: Modification in the ASN eligibility criteria

[Dean Pemberton]

It did say "immediate future".
I would say that it seems reasonable that if you're claiming that
you're going to multihome in the "immediate future" that you would
know the ASNs with whom you were going to peer.

If it was more of a "Well at some point we might want to multihome",
then you might not know the ASN.  But in those situations RFC1930 says
that you should be using a private AS until such time as you are
closer to peering.

Dean
--
Dean Pemberton

Technical Policy Advisor
InternetNZ
+64 21 920 363 (mob)
d...@internetnz.net.nz

To promote the Internet's benefits and uses, and protect its potential.


On Fri, Feb 27, 2015 at 6:00 PM, Aftab Siddiqui
 wrote:
> Hi Guangliang,
>
>>
>> The option "b" is acceptable.
>>
>> b. If an applicant can demonstrate a plan to be multihomed in
>>  immediate future, it is not a must they are physically multihomed
>>  at the time of submitting a request
>
>
> But even then applicant has to provide the details of those ASN with whom
> they may or may not multhome in future. right?
>
> Regards,
>
> Aftab A. Siddiqui
>
> *  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 Policy Proposal] prop-114: Modification in the ASN eligibility criteria

[Seun Ojedeji]

Hi,

Just to mention that Izumi mentioned what is also largely requested and
done at the AfriNIC region as well. I don't think there is any policy
implication for member that peers with a different ASN other than the ones
provided during application.

Cheers!
sent from Google nexus 4
kindly excuse brevity and typos.
On 27 Feb 2015 06:14, "Izumi Okutani"  wrote:

> On 2015/02/27 14:00, Aftab Siddiqui wrote:
> > Hi Guangliang,
> >
> >
> >> The option "b" is acceptable.
> >>
> >> b. If an applicant can demonstrate a plan to be multihomed in
> >>   immediate future, it is not a must they are physically multihomed
> >>   at the time of submitting a request
> >>
> >
> > But even then applicant has to provide the details of those ASN with whom
> > they may or may not multhome in future. right?
> >
>
> I don't know whether it's adequate to do the same case in the APNIC
> region but sharing our case as a reference -
>
> JPNIC requests for contact information for those ASNs they plan to be
> connected.
>
> We sometimes we contact the upstreams and confirm the plan and this
> seems to be working OK.
>
>
> Regards,
> Izumi
>
> *  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 Policy Proposal] prop-114: Modification in the ASN eligibility criteria

[Skeeve Stevens]

This is where the big different in philosophy is.

I want to be able to choose to get an ASN and ready my network to be
multi-homed - 'at some point'

Dean says do it with private ASN and then reconfigure your network when you
are ready.

Frankly, I still think this is telling me how to plan the building of my
networks - and telling me when I should do the work.


...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 Fri, Feb 27, 2015 at 2:43 PM, Dean Pemberton 
wrote:

> It did say "immediate future".
> I would say that it seems reasonable that if you're claiming that
> you're going to multihome in the "immediate future" that you would
> know the ASNs with whom you were going to peer.
>
> If it was more of a "Well at some point we might want to multihome",
> then you might not know the ASN.  But in those situations RFC1930 says
> that you should be using a private AS until such time as you are
> closer to peering.
>
> Dean
> --
> Dean Pemberton
>
> Technical Policy Advisor
> InternetNZ
> +64 21 920 363 (mob)
> d...@internetnz.net.nz
>
> To promote the Internet's benefits and uses, and protect its potential.
>
>
> On Fri, Feb 27, 2015 at 6:00 PM, Aftab Siddiqui
>  wrote:
> > Hi Guangliang,
> >
> >>
> >> The option "b" is acceptable.
> >>
> >> b. If an applicant can demonstrate a plan to be multihomed in
> >>  immediate future, it is not a must they are physically multihomed
> >>  at the time of submitting a request
> >
> >
> > But even then applicant has to provide the details of those ASN with whom
> > they may or may not multhome in future. right?
> >
> > Regards,
> >
> > Aftab A. Siddiqui
> >
> > *  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
>
*  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-114: Modification in the ASN eligibility criteria

[Jahangir Hossain]

Personally, I also faced the same complexity about the "mandatory
multi-homing requirement" when i tried to apply for ASN of new ISP.

I support this by considering "organizations are not tempted to provide
wrong information " . Make simple and authenticate information .



On Fri, Feb 27, 2015 at 11:43 AM, Dean Pemberton 
wrote:

> It did say "immediate future".
> I would say that it seems reasonable that if you're claiming that
> you're going to multihome in the "immediate future" that you would
> know the ASNs with whom you were going to peer.
>
> If it was more of a "Well at some point we might want to multihome",
> then you might not know the ASN.  But in those situations RFC1930 says
> that you should be using a private AS until such time as you are
> closer to peering.
>
> Dean
> --
> Dean Pemberton
>
> Technical Policy Advisor
> InternetNZ
> +64 21 920 363 (mob)
> d...@internetnz.net.nz
>
> To promote the Internet's benefits and uses, and protect its potential.
>
>
> On Fri, Feb 27, 2015 at 6:00 PM, Aftab Siddiqui
>  wrote:
> > Hi Guangliang,
> >
> >>
> >> The option "b" is acceptable.
> >>
> >> b. If an applicant can demonstrate a plan to be multihomed in
> >>  immediate future, it is not a must they are physically multihomed
> >>  at the time of submitting a request
> >
> >
> > But even then applicant has to provide the details of those ASN with whom
> > they may or may not multhome in future. right?
> >
> > Regards,
> >
> > Aftab A. Siddiqui
> >
> > *  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
>



-- 
Regards  - Jahangir
*  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-114: Modification in the ASN eligibility criteria

[Aftab Siddiqui]

On a side note.. Since RFC1930 has already been quoted couple of times here
as the Best Current Practice even valid today..

an excerpt

"BGP (Border Gateway Protocol, the current de facto standard for inter-AS
routing; see [BGP-4]), and IDRP (The OSI Inter-Domain Routing Protocol,
which the Internet is expected to adopt when BGP becomes obsolete; see
[IDRP]). It should be noted that the IDRP equivalent of an AS is the RDI,
or Routing Domain Identifier."




Regards,

Aftab A. Siddiqui

On Fri, Feb 27, 2015 at 10:43 AM, Dean Pemberton 
wrote:

> It did say "immediate future".
> I would say that it seems reasonable that if you're claiming that
> you're going to multihome in the "immediate future" that you would
> know the ASNs with whom you were going to peer.
>
> If it was more of a "Well at some point we might want to multihome",
> then you might not know the ASN.  But in those situations RFC1930 says
> that you should be using a private AS until such time as you are
> closer to peering.
>
> Dean
> --
> Dean Pemberton
>
> Technical Policy Advisor
> InternetNZ
> +64 21 920 363 (mob)
> d...@internetnz.net.nz
>
> To promote the Internet's benefits and uses, and protect its potential.
>
>
> On Fri, Feb 27, 2015 at 6:00 PM, Aftab Siddiqui
>  wrote:
> > Hi Guangliang,
> >
> >>
> >> The option "b" is acceptable.
> >>
> >> b. If an applicant can demonstrate a plan to be multihomed in
> >>  immediate future, it is not a must they are physically multihomed
> >>  at the time of submitting a request
> >
> >
> > But even then applicant has to provide the details of those ASN with whom
> > they may or may not multhome in future. right?
> >
> > Regards,
> >
> > Aftab A. Siddiqui
> >
> > *  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 Policy Proposal] prop-114: Modification in the ASN eligibility criteria

[Dean Pemberton]

I'm sure Skeeve also thinks that organisations should be able to get all
the IP addresses they might ever need all on day one.
I'm sure he even knows a company who could arrange that for them.

Lets see where the community thinks this should go.
It still sounds like unlimited ASNs for anyone who thinks they might like
to have them.
Great business for anyone clipping the ticket on the transaction.



--
Dean Pemberton

Technical Policy Advisor
InternetNZ
+64 21 920 363 (mob)
d...@internetnz.net.nz

To promote the Internet's benefits and uses, and protect its potential.

On Fri, Feb 27, 2015 at 7:10 PM, Skeeve Stevens  wrote:

> This is where the big different in philosophy is.
>
> I want to be able to choose to get an ASN and ready my network to be
> multi-homed - 'at some point'
>
> Dean says do it with private ASN and then reconfigure your network when
> you are ready.
>
> Frankly, I still think this is telling me how to plan the building of my
> networks - and telling me when I should do the work.
>
>
> ...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 Fri, Feb 27, 2015 at 2:43 PM, Dean Pemberton 
> wrote:
>
>> It did say "immediate future".
>> I would say that it seems reasonable that if you're claiming that
>> you're going to multihome in the "immediate future" that you would
>> know the ASNs with whom you were going to peer.
>>
>> If it was more of a "Well at some point we might want to multihome",
>> then you might not know the ASN.  But in those situations RFC1930 says
>> that you should be using a private AS until such time as you are
>> closer to peering.
>>
>> Dean
>> --
>> Dean Pemberton
>>
>> Technical Policy Advisor
>> InternetNZ
>> +64 21 920 363 (mob)
>> d...@internetnz.net.nz
>>
>> To promote the Internet's benefits and uses, and protect its potential.
>>
>>
>> On Fri, Feb 27, 2015 at 6:00 PM, Aftab Siddiqui
>>  wrote:
>> > Hi Guangliang,
>> >
>> >>
>> >> The option "b" is acceptable.
>> >>
>> >> b. If an applicant can demonstrate a plan to be multihomed in
>> >>  immediate future, it is not a must they are physically multihomed
>> >>  at the time of submitting a request
>> >
>> >
>> > But even then applicant has to provide the details of those ASN with
>> whom
>> > they may or may not multhome in future. right?
>> >
>> > Regards,
>> >
>> > Aftab A. Siddiqui
>> >
>> > *  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
>>
>
>
*  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-114: Modification in the ASN eligibility criteria

[Dean Pemberton]

Here's a quote from an even OLDER RFC which hasn't stood the test of time.

 - Large organizations like banks and retail chains are
   switching to TCP/IP for their internal communication. Large
   numbers of local workstations like cash registers, money
   machines, and equipment at clerical positions rarely need
   to have such connectivity.

Thing is though that we haven't tossed out the rest of RFC1918 just
because some of it didn't age well.



--
Dean Pemberton

Technical Policy Advisor
InternetNZ
+64 21 920 363 (mob)
d...@internetnz.net.nz

To promote the Internet's benefits and uses, and protect its potential.


On Fri, Feb 27, 2015 at 7:19 PM, Aftab Siddiqui
 wrote:
> On a side note.. Since RFC1930 has already been quoted couple of times here
> as the Best Current Practice even valid today..
>
> an excerpt
>
> "BGP (Border Gateway Protocol, the current de facto standard for inter-AS
> routing; see [BGP-4]), and IDRP (The OSI Inter-Domain Routing Protocol,
> which the Internet is expected to adopt when BGP becomes obsolete; see
> [IDRP]). It should be noted that the IDRP equivalent of an AS is the RDI, or
> Routing Domain Identifier."
>
>
>
>
> Regards,
>
> Aftab A. Siddiqui
>
> On Fri, Feb 27, 2015 at 10:43 AM, Dean Pemberton 
> wrote:
>>
>> It did say "immediate future".
>> I would say that it seems reasonable that if you're claiming that
>> you're going to multihome in the "immediate future" that you would
>> know the ASNs with whom you were going to peer.
>>
>> If it was more of a "Well at some point we might want to multihome",
>> then you might not know the ASN.  But in those situations RFC1930 says
>> that you should be using a private AS until such time as you are
>> closer to peering.
>>
>> Dean
>> --
>> Dean Pemberton
>>
>> Technical Policy Advisor
>> InternetNZ
>> +64 21 920 363 (mob)
>> d...@internetnz.net.nz
>>
>> To promote the Internet's benefits and uses, and protect its potential.
>>
>>
>> On Fri, Feb 27, 2015 at 6:00 PM, Aftab Siddiqui
>>  wrote:
>> > Hi Guangliang,
>> >
>> >>
>> >> The option "b" is acceptable.
>> >>
>> >> b. If an applicant can demonstrate a plan to be multihomed in
>> >>  immediate future, it is not a must they are physically multihomed
>> >>  at the time of submitting a request
>> >
>> >
>> > But even then applicant has to provide the details of those ASN with
>> > whom
>> > they may or may not multhome in future. right?
>> >
>> > Regards,
>> >
>> > Aftab A. Siddiqui
>> >
>> > *  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 Policy Proposal] prop-114: Modification in the ASN eligibility criteria

[Skeeve Stevens]

Yes we did... Like when Cisco started rolling out 1.1.1.1 to Wireless
Controllers and other things.

...Skeeve

On Friday, February 27, 2015, Dean Pemberton  wrote:

> Here's a quote from an even OLDER RFC which hasn't stood the test of time.
>
>  - Large organizations like banks and retail chains are
>switching to TCP/IP for their internal communication. Large
>numbers of local workstations like cash registers, money
>machines, and equipment at clerical positions rarely need
>to have such connectivity.
>
> Thing is though that we haven't tossed out the rest of RFC1918 just
> because some of it didn't age well.
>
>
>
> --
> Dean Pemberton
>
> Technical Policy Advisor
> InternetNZ
> +64 21 920 363 (mob)
> d...@internetnz.net.nz 
>
> To promote the Internet's benefits and uses, and protect its potential.
>
>
> On Fri, Feb 27, 2015 at 7:19 PM, Aftab Siddiqui
> > wrote:
> > On a side note.. Since RFC1930 has already been quoted couple of times
> here
> > as the Best Current Practice even valid today..
> >
> > an excerpt
> >
> > "BGP (Border Gateway Protocol, the current de facto standard for inter-AS
> > routing; see [BGP-4]), and IDRP (The OSI Inter-Domain Routing Protocol,
> > which the Internet is expected to adopt when BGP becomes obsolete; see
> > [IDRP]). It should be noted that the IDRP equivalent of an AS is the
> RDI, or
> > Routing Domain Identifier."
> >
> >
> >
> >
> > Regards,
> >
> > Aftab A. Siddiqui
> >
> > On Fri, Feb 27, 2015 at 10:43 AM, Dean Pemberton  >
> > wrote:
> >>
> >> It did say "immediate future".
> >> I would say that it seems reasonable that if you're claiming that
> >> you're going to multihome in the "immediate future" that you would
> >> know the ASNs with whom you were going to peer.
> >>
> >> If it was more of a "Well at some point we might want to multihome",
> >> then you might not know the ASN.  But in those situations RFC1930 says
> >> that you should be using a private AS until such time as you are
> >> closer to peering.
> >>
> >> Dean
> >> --
> >> Dean Pemberton
> >>
> >> Technical Policy Advisor
> >> InternetNZ
> >> +64 21 920 363 (mob)
> >> d...@internetnz.net.nz 
> >>
> >> To promote the Internet's benefits and uses, and protect its potential.
> >>
> >>
> >> On Fri, Feb 27, 2015 at 6:00 PM, Aftab Siddiqui
> >> > wrote:
> >> > Hi Guangliang,
> >> >
> >> >>
> >> >> The option "b" is acceptable.
> >> >>
> >> >> b. If an applicant can demonstrate a plan to be multihomed in
> >> >>  immediate future, it is not a must they are physically
> multihomed
> >> >>  at the time of submitting a request
> >> >
> >> >
> >> > But even then applicant has to provide the details of those ASN with
> >> > whom
> >> > they may or may not multhome in future. right?
> >> >
> >> > Regards,
> >> >
> >> > Aftab A. Siddiqui
> >> >
> >> > *  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
>


-- 
...Skeeve (from an iPhone 6 Plus)
*  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-114: Modification in the ASN eligibility criteria

[Sanjeev Gupta]

On Fri, Feb 27, 2015 at 12:47 PM, Izumi Okutani  wrote:

> May I clarify with APNIC hosmaster whether :
>
>  a. It is a must for an applicant to be multihomed at the time of
> submitting the request
>
>  b. If an applicant can demonstrate a plan to be multihomed in
> immediate future, it is not a must they are physically multihomed
> at the time of submitting a request
>

When I became an APNIC member in 2005, and applied for an ASN, I clearly
stated that I was _planning_ to multihome.  At that time, I did not even
have PI address space.

I had discussed with two service providers, and provided the network
diagram in my application.


-- 
Sanjeev Gupta
+65 98551208   http://sg.linkedin.com/in/ghane
*  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-114: Modification in the ASN eligibility criteria

[Sanjeev Gupta]

On Fri, Feb 27, 2015 at 2:10 PM, Skeeve Stevens  wrote:

> Frankly, I still think this is telling me how to plan the building of my
> networks - and telling me when I should do the work.


Skeeve, I think you are stressing this point too far.

Dean has absolutely no right to tell you how you build your network.  I
wouldn't dream of having an opinon, either.  And I strongly oppose APNIC
getting involved in your network design at all.

But an ASN is not used for "your" network.  It is used to connect to
others.  If it was only your network you were concerned about, you can use
the ASN number I was allocated.  Or make up your own ASN.

If you do decide to connect to "the Internet", you have to listen to what
other players say.  I do not have a policy on how my customers at my DC
build their networks, but if they want to transit me, they MUST apply
BCP38, or else.  Some lie, forget to maintain it, turn it off later, etc.



-- 
Sanjeev Gupta
+65 98551208   http://sg.linkedin.com/in/ghane
*  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-114: Modification in the ASN eligibility criteria

[Usman Latif]

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 homed or multihomed.

Also, a lot of times organisations get more than one Internet link (for 
redundancy etc) from the same provider so theoretically they are "not 
multihomed" as they use the same provider.
I am not sure if the current proposal allows for assignment of a public ASN for 
the above situation?
If not, then this should be brought into scope because controlling traffic and 
AS-loops using private ASNs becomes challenging for organisations that have 
single-homed-but-multiple-links-to-same-provider-scenarios


Regards,
Usman


> On 27 Feb 2015, at 5:10 pm, Skeeve Stevens  wrote:
> 
> This is where the big different in philosophy is.
> 
> I want to be able to choose to get an ASN and ready my network to be 
> multi-homed - 'at some point'
> 
> Dean says do it with private ASN and then reconfigure your network when you 
> are ready.
> 
> Frankly, I still think this is telling me how to plan the building of my 
> networks - and telling me when I should do the work.
> 
> 
> ...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 Fri, Feb 27, 2015 at 2:43 PM, Dean Pemberton  
>> wrote:
>> It did say "immediate future".
>> I would say that it seems reasonable that if you're claiming that
>> you're going to multihome in the "immediate future" that you would
>> know the ASNs with whom you were going to peer.
>> 
>> If it was more of a "Well at some point we might want to multihome",
>> then you might not know the ASN.  But in those situations RFC1930 says
>> that you should be using a private AS until such time as you are
>> closer to peering.
>> 
>> Dean
>> --
>> Dean Pemberton
>> 
>> Technical Policy Advisor
>> InternetNZ
>> +64 21 920 363 (mob)
>> d...@internetnz.net.nz
>> 
>> To promote the Internet's benefits and uses, and protect its potential.
>> 
>> 
>> On Fri, Feb 27, 2015 at 6:00 PM, Aftab Siddiqui
>>  wrote:
>> > Hi Guangliang,
>> >
>> >>
>> >> The option "b" is acceptable.
>> >>
>> >> b. If an applicant can demonstrate a plan to be multihomed in
>> >>  immediate future, it is not a must they are physically multihomed
>> >>  at the time of submitting a request
>> >
>> >
>> > But even then applicant has to provide the details of those ASN with whom
>> > they may or may not multhome in future. right?
>> >
>> > Regards,
>> >
>> > Aftab A. Siddiqui
>> >
>> > *  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
> 
> *  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 Policy Proposal] prop-114: Modification in the ASN eligibility criteria

[Dean Pemberton]

How so?


If not, then this should be brought into scope because controlling traffic
> and AS-loops using private ASNs becomes challenging for organisations that
> have single-homed-but-multiple-links-to-same-provider-scenarios
>




>
>
> Regards,
> Usman
>
>
> On 27 Feb 2015, at 5:10 pm, Skeeve Stevens  > wrote:
>
> This is where the big different in philosophy is.
>
> I want to be able to choose to get an ASN and ready my network to be
> multi-homed - 'at some point'
>
> Dean says do it with private ASN and then reconfigure your network when
> you are ready.
>
> Frankly, I still think this is telling me how to plan the building of my
> networks - and telling me when I should do the work.
>
>
> ...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 Fri, Feb 27, 2015 at 2:43 PM, Dean Pemberton  > wrote:
>
>> It did say "immediate future".
>> I would say that it seems reasonable that if you're claiming that
>> you're going to multihome in the "immediate future" that you would
>> know the ASNs with whom you were going to peer.
>>
>> If it was more of a "Well at some point we might want to multihome",
>> then you might not know the ASN.  But in those situations RFC1930 says
>> that you should be using a private AS until such time as you are
>> closer to peering.
>>
>> Dean
>> --
>> Dean Pemberton
>>
>> Technical Policy Advisor
>> InternetNZ
>> +64 21 920 363 (mob)
>> d...@internetnz.net.nz
>> 
>>
>> To promote the Internet's benefits and uses, and protect its potential.
>>
>>
>> On Fri, Feb 27, 2015 at 6:00 PM, Aftab Siddiqui
>> > > wrote:
>> > Hi Guangliang,
>> >
>> >>
>> >> The option "b" is acceptable.
>> >>
>> >> b. If an applicant can demonstrate a plan to be multihomed in
>> >>  immediate future, it is not a must they are physically multihomed
>> >>  at the time of submitting a request
>> >
>> >
>> > But even then applicant has to provide the details of those ASN with
>> whom
>> > they may or may not multhome in future. right?
>> >
>> > Regards,
>> >
>> > Aftab A. Siddiqui
>> >
>> > *  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
>>
>
> *  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
>
>

-- 
--
Dean Pemberton

Technical Policy Advisor
InternetNZ
+64 21 920 363 (mob)
d...@internetnz.net.nz

To promote the Internet's benefits and uses, and protect its potential.
*  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-114: Modification in the ASN eligibility criteria

[Mark Tinka]

On 27/Feb/15 10: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 homed or multihomed.
>
> Also, a lot of times organisations get more than one Internet link
> (for redundancy etc) from the same provider so theoretically they are
> "not multihomed" as they use the same provider.

BGP does not concern itself with how many links it is running over.

Networks on the Internet have no idea how many links exist between you
and your service provider(s). All they see is the NLRI your network
purports to originate.

So really, being multi-homed has little bearing on how many links you
have to one or more providers, but rather with how many different
providers you share your routing policy with.

In BGP's mind (and in the classic definition of multi-homing as our
community understands it today), you could have 100x links to the same
ISP, but to the world, you still appear to be behind a single ISP, not
behind 100x links.

Mark.
*  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-114: Modification in the ASN eligibility criteria

[Izumi Okutani]

On 2015/02/27 18:16, Mark Tinka wrote:
> On 27/Feb/15 10: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 homed or multihomed.
>>
>> Also, a lot of times organisations get more than one Internet link
>> (for redundancy etc) from the same provider so theoretically they are
>> "not multihomed" as they use the same provider.
> 
> BGP does not concern itself with how many links it is running over.
> 
> Networks on the Internet have no idea how many links exist between you
> and your service provider(s). All they see is the NLRI your network
> purports to originate.
> 
> So really, being multi-homed has little bearing on how many links you
> have to one or more providers, but rather with how many different
> providers you share your routing policy with.
> 
> In BGP's mind (and in the classic definition of multi-homing as our
> community understands it today), you could have 100x links to the same
> ISP, but to the world, you still appear to be behind a single ISP, not
> behind 100x links.
> 

Indeed.

If we look at the definition of multihoming on APNIC Guangliang have
shared on this mailing list, it doesn't specify how many links and it
defines criteria based on ASNs.



http://www.apnic.net/policy/asn-policy#3.4

3.4 Multihomed

A multi-homed AS is one which is connected to more than one other AS. An
AS also qualifies as multihomed if it is connected to a public Internet
Exchange Point.

In the ASN request form, you will be asked to provide the estimate ASN
implementation date, two peer AS numbers and their contact details. It
is also acceptable if your network only connect to an IXP.


Izumi


*  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-114: Modification in the ASN eligibility criteria

[Izumi Okutani]

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 homed or multihomed.
> 

OK, that's an interesting approach.

What is the reason for this? Would be curious to hear from other
operators as well, on what issues it may cause if you are a single homed
portable assignment holder and cannot receive a global ASN.


Izumi

*  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-114: Modification in the ASN eligibility criteria

[Mark Tinka]

On 27/Feb/15 11:43, Izumi Okutani wrote:
> OK, that's an interesting approach.
>
> What is the reason for this? Would be curious to hear from other
> operators as well, on what issues it may cause if you are a single homed
> portable assignment holder and cannot receive a global ASN.

My experience with downstreams who have needed address space without the
need for an ASN is so they can have independence from their provider's
address space, but do not necessarily have the skill-set or budget to
run an autonomous system.

So I do not think that it is necessarily wise to tie IP address
resources to ASN resources in this way, by default. It is a valid
operational approach for networks that require the address space - but
not the autonomous system routing - to have their upstreams run their
address space behind the upstreams ASN. As an operator running network
across Africa, Europe and south Asia, we see and handle these use-cases
all the time. In my experience, most customers in this scenario are more
concerned with address space than routing.

Mark.

*  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-114: Modification in the ASN eligibility criteria

[David Farmer]

> On Feb 27, 2015, at 00:22, Dean Pemberton  wrote:
> 
> I'm sure Skeeve also thinks that organisations should be able to get all the 
> IP addresses they might ever need all on day one.
> I'm sure he even knows a company who could arrange that for them.

Well our IPv4 policies are explicitly designed to not provide all the IPv4 
addresses an organization needs.  Where as with IPv6 that is at least possible, 
maybe not forever, but there is a goal of 5 to 10 years or more for an initial 
allocation.

> Lets see where the community thinks this should go.  
> It still sounds like unlimited ASNs for anyone who thinks they might like to 
> have them.
> Great business for anyone clipping the ticket on the transaction.

Now that we that have 4 billion ASNs, maybe we should reexamine our policy 
goals for ASNs, at least compared to when we only had 65 thousand ASNs.  

If we are willing to give an organization a routing slot with IPv4 or IPv6 PA 
or PI address block, why wouldn't we be willing to give them a ASN too?  I 
would want them to provide additional justification why they need a second ASN, 
but the mere fact we gave then a PA or PI address block is probably sufficient 
justification for their first ASN.  

The reverse is also probably also true, if we are NOT willing to give them a 
routing slot, we probably should NOT be willing to give them an ASN either, at 
least without additional justification like multi-homing.

> --
> Dean Pemberton
> 
> Technical Policy Advisor
> InternetNZ
> +64 21 920 363 (mob)
> d...@internetnz.net.nz
> 
> To promote the Internet's benefits and uses, and protect its potential.

-- 
===
David Farmer  Email: far...@umn.edu
Office of Information Technology
University of Minnesota
2218 University Ave SE Phone: +1-612-626-0815
Minneapolis, MN 55414-3029   Cell: +1-612-812-9952
===

*  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