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 <ske...@v4now.com> のメッセージ:
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 <d...@internetnz.net.nz> wrote:
On Thu, Feb 26, 2015 at 12:50 PM, Skeeve Stevens <ske...@v4now.com> 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
