That's actually getting closer to something I could support On Thursday, 5 March 2015, Owen DeLong <o...@delong.com> wrote:
> I don’t feel the need for every use case to be set in stone, but I do > think that there are better ways to address this. > > Is there any reason that adding the following to the existing policy would > be unacceptable to you? > > … > or an organization which has received an assignment or allocation from > APNIC and has not previously obtained an ASN may obtain one ASN upon > request for purposes of setting up peering for their network with one or > more other other autonomous systems. > > > Why would that not suffice? > > Owen > > On Mar 4, 2015, at 15:47 , Skeeve Stevens <ske...@v4now.com > <javascript:_e(%7B%7D,'cvml','ske...@v4now.com');>> wrote: > > Owen, > > It just feels like nitpicking and moving chairs around. I actually trust > the Secretariat to do the right thing when allocating resources. We're > also talking about a resource where there are over 4.1 billion ASN's still > available... not that it should be a justification to wastage, but it is > useful for context. > > The APNIC stats are: > > How many ASN - % of Membership > no ASN > 34.06% > 1 > 56.59% > 2 > 5.55% > 3 > 1.78% > 4 > 0.77% > 5 > 0.35% > 6 > 0.28% > 7 > 0.15% > 8 > 0.04% > 10 > 0.13% > more than 10 > 0.31% > > I'm unsure why you guys want to see each and every use-case set in stone. > I don't want to have to come back and do amendments picking on a word here > or there because there has been an innovation in the way networks are > operated. > > > I fully support the idea that this isn't a free-for-all.. but we need some > flexibility in the community. > > > ...Skeeve > > *Skeeve Stevens - Senior IP Broker* > *v4Now - *an eintellego Networks service > ske...@v4now.com <javascript:_e(%7B%7D,'cvml','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 Thu, Mar 5, 2015 at 8:33 AM, Owen DeLong <o...@delong.com > <javascript:_e(%7B%7D,'cvml','o...@delong.com');>> wrote: > >> If said standard pre-existing procedure were subject to the PDP, I’d be >> fine with that. >> >> However, that’s not what the wording implies. In the case of the IPv6 >> policy, I think this is less than desirable, but it’s not on the table in >> this discussion. >> >> Certainly if someone proposed removing that wording from the IPv6 policy, >> I would support such a proposal. >> >> Owen >> >> On Mar 4, 2015, at 14:58 , Skeeve Stevens <ske...@v4now.com >> <javascript:_e(%7B%7D,'cvml','ske...@v4now.com');>> wrote: >> >> Do we just move the 'proposed draft guidelines' to cases under 3.3? >> >> We were trying to be flexible for future use cases without going through >> this painful process for every future valid use case that comes up in >> future. >> >> This is an established process where for subsequent IPv6 allocations: >> >> === http://www.apnic.net/policy/ipv6-address-policy#5.3.2 ==== >> >> 5.3.2 Alternative allocation criteria >> >> Alternatively, a subsequent allocation may be provided where an >> organization (ISP/LIR) can demonstrate a valid reason for requiring the >> subsequent allocation. For guidelines on what will be considered a valid >> technical or other reason, see “APNIC guidelines for IPv6 allocation and >> assignment requests”. >> >> http://www.apnic.net/ipv6-guidelines >> === >> >> Why isn't a standard pre-existing procedure acceptable to you? >> >> >> ...Skeeve >> >> *Skeeve Stevens - Senior IP Broker* >> *v4Now - *an eintellego Networks service >> ske...@v4now.com <javascript:_e(%7B%7D,'cvml','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 Thu, Mar 5, 2015 at 3:11 AM, Owen DeLong <o...@delong.com >> <javascript:_e(%7B%7D,'cvml','o...@delong.com');>> wrote: >> >>> Opposed as written. >>> >>> Vague wording which basically says that the secretariat can decide >>> policy on a case-by-case >>> basis is antithetical to an informed multi-stakeholder community >>> consensus policy development >>> process. >>> >>> Owen >>> >>> On Mar 4, 2015, at 00:02 , Masato Yamanishi <myama...@gmail.com >>> <javascript:_e(%7B%7D,'cvml','myama...@gmail.com');>> wrote: >>> >>> Dear SIG members >>> >>> A new version of the proposal “prop-114: Modification in the ASN >>> eligibility criteria" has been sent to the Policy SIG for review. >>> >>> Information about earlier versions is available from: >>> >>> http://www.apnic.net/policy/proposals/prop-114 >>> >>> You are encouraged to express your views on the proposal: >>> >>> - Do you support or oppose the proposal? >>> - Is there anything in the proposal that is not clear? >>> - What changes could be made to this proposal to make it more effective? >>> >>> Please find the text of the proposal below. >>> >>> Kind Regards, >>> >>> Masato >>> >>> >>> >>> >>> -------------------------------------------------------------------------- >>> prop-114-v002: Modification in the ASN eligibility criteria >>> >>> -------------------------------------------------------------------------- >>> >>> Proposer: Aftab Siddiqui >>> aftab.siddi...@gmail.com >>> <javascript:_e(%7B%7D,'cvml','aftab.siddi...@gmail.com');> >>> >>> Skeeve Stevens >>> ske...@eintellegonetworks.com >>> <javascript:_e(%7B%7D,'cvml','ske...@eintellegonetworks.com');> >>> >>> >>> 1. Problem statement >>> ----------------------------- >>> >>> The current ASN assignment policy states two eligibility criteria >>> and that both criteria should be fulfilled in order to obtain an >>> ASN. The policy seems to imply that both requirements i.e. >>> multi-homing and clearly defined single routing policy must be met >>> simultaneously, this has created much confusion in interpreting the >>> policy. >>> >>> As a result organizations have either provided incorrect information >>> to get the ASN or barred themselves from applying where they still >>> have a valid justification for obtaining an ASN. >>> >>> >>> 2. Objective of policy change >>> -------------------------------------- >>> >>> In order to make the policy guidelines simpler we are proposing to >>> modify the text describing the eligibility criteria for ASN >>> assignment by providing alternate criteria to obtaining an ASN. >>> >>> >>> 3. Situation in other regions >>> ------------------------------------ >>> >>> ARIN: >>> It is not mandatory but optional to be multi-homed in order get ASN >>> >>> RIPE: >>> Policy to remove multi-homing requirement is currently in discussion >>> and the current phase ends 12 February 2015 (awaiting Chair >>> decision) >>> >>> Policy - https://www.ripe.net/ripe/policies/proposals/2014-03 >>> >>> LACNIC: >>> Only inter-connect is mandatory not multi-homing >>> >>> AFRINIC: >>> It is mandatory to be multi-homed in order to get ASN. >>> >>> >>> 4. Proposed policy solution >>> ----------------------------------- >>> >>> An organization is eligible for an ASN assignment if: >>> >>> - they are currently multi-homed OR >>> >>> - meet one of the other criteria in the guidelines managed by the >>> APNIC Secretariat >>> >>> >>> 5. Advantages / Disadvantages >>> ----------------------------------------- >>> >>> Advantages: >>> >>> By adding the additional criteria of Guidelines managed by APNIC >>> Secretariat, this would enable the Secretariat to make decisions >>> based on common or rare use cases, but that may still be a valid >>> request. >>> >>> Disadvantages: >>> >>> It may be perceived that this policy would enable members to obtain >>> ASN’s more easily, and in return cause faster consumption of ASN’s >>> in the region. Given the relative ease of obtaining an ASN with >>> ‘work around’ methods, we do not perceive this will actually have >>> any effect. >>> >>> >>> >>> 6. Impact on resource holders >>> --------------------------------------- >>> >>> No impact on existing resource holders. >>> >>> >>> ------------------------------------------------------------------------ >>> Proposed Draft Guidelines >>> (to be created as a numbered document by APNIC) >>> ------------------------------------------------------------------------ >>> >>> The below are example of guidelines that could be considered for >>> alternate needs justification. >>> >>> The intention to multi-home in the future >>> >>> The applicant is participating in elastic fabrics where the >>> requirements to connect to ‘on demand’ service providers may require >>> ASN/BGP connectivity >>> >>> Regional limitation of obtaining multi-homing connectivity in the >>> ‘immediate’ term, but want to design their networks for this >>> capability >>> >>> Have a single unique routing policy different to their upstream, but >>> yet >>> are single-homed >>> >>> * sig-policy: APNIC SIG on resource management policy >>> * >>> _______________________________________________ >>> sig-policy mailing list >>> sig-policy@lists.apnic.net >>> <javascript:_e(%7B%7D,'cvml','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 >>> <javascript:_e(%7B%7D,'cvml','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
