From narten at us.ibm.com Fri Apr 1 00:53:03 2016 From: narten at us.ibm.com (narten at us.ibm.com) Date: Fri, 01 Apr 2016 00:53:03 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201604010453.u314r3Uo006597@rotala.raleigh.ibm.com> Total of 1 messages in the last 7 days. script run at: Fri Apr 1 00:53:03 EDT 2016 Messages | Bytes | Who --------+------+--------+----------+------------------------ 100.00% | 1 |100.00% | 6828 | narten at us.ibm.com --------+------+--------+----------+------------------------ 100.00% | 1 |100.00% | 6828 | Total From andrew.dul at quark.net Sun Apr 3 13:59:37 2016 From: andrew.dul at quark.net (Andrew Dul) Date: Sun, 3 Apr 2016 10:59:37 -0700 Subject: [arin-ppml] 2-byte ASN policy Message-ID: <57015A09.2030901@quark.net> Hello, I am starting a new thread in PPML, as a follow up to the ARIN suggestion and consultation which recently started regarding creating a 2-byte ASN waiting list. The original suggestion is here: https://www.arin.net/participate/acsp/suggestions/2016-04.html ARIN opened a consultation on this suggestion on the arin-consult mailing-list. This thread starts here for those who are not subscribed to arin-consult. http://lists.arin.net/pipermail/arin-consult/2016-March/000713.html http://lists.arin.net/pipermail/arin-consult/2016-April/000722.html As the thread evolved it has been suggested that this issue should be resolved via the policy development process rather than through a suggestion. There are a number of questions that have been raised by this thread. I am copying them here to continue the discussion on PPML. === Working problem statement: ARIN will receive 2-byte ASNs as returns over time, and these ASNs have perceived or additional value to organizations compared to 4-byte ASNs. How should ARIN allocate these 2-byte ASNs? === Should they be given to the next requester, regardless of technical need for a 2-byte ASN? (What are the technical qualifications we should use if there is a specific technical need? e.g. provides transit to more than 1 ASN?) If there is really a technical need for 2-byte ASNs, shouldn't we attempt to build an inventory of 2-byte ASNs? Should returns be held in reserve? Should ARIN hold them for some period of time before reallocating them? Should they be put up for auction to qualified organizations? Should they be given to the 1st organization on a wait-list for 2-byte ASNs? Would an organization looking for a 2-byte ASN have the option to receive a 4-byte ASN in the interim? If they did would they have to return it? Should the waiting list be closed to organizations that already have a 2-byte ASNs? I and the AC would appreciate your comments on these questions so that we can start to build a draft policy that best matches with what the community would like to see implemented by ARIN. Thanks, Andrew From athompso at athompso.net Sun Apr 3 14:36:06 2016 From: athompso at athompso.net (Adam Thompson) Date: Sun, 03 Apr 2016 13:36:06 -0500 Subject: [arin-ppml] 2-byte ASN policy In-Reply-To: <57015A09.2030901@quark.net> References: <57015A09.2030901@quark.net> Message-ID: <4CFD1C3E-CAA7-45A1-9784-CBC9A1E29800@athompso.net> IMO, 2-byte ASNs should simply be retired and not reallocated. "Solving the technical problem", as described in your email, is actually ensuring the perpetuation of a different technical problem. It's the same sort of thing as the IPv4 vs IPv6 --transition, but this time ARIN has an opportunity to at least avoid being part of the problem, even if it can't really be part of the "solution". Let's please not prolong this problem, too... even in central Canada, known for a paucity of upstream carriers, it's now commercially feasible to work around the 2-byte technical limitations. -Adam On April 3, 2016 12:59:37 PM CDT, Andrew Dul wrote: >Hello, > >I am starting a new thread in PPML, as a follow up to the ARIN >suggestion and consultation which recently started regarding creating a > >2-byte ASN waiting list. > >The original suggestion is here: > >https://www.arin.net/participate/acsp/suggestions/2016-04.html > >ARIN opened a consultation on this suggestion on the arin-consult >mailing-list. This thread starts here for those who are not subscribed > >to arin-consult. > >http://lists.arin.net/pipermail/arin-consult/2016-March/000713.html > >http://lists.arin.net/pipermail/arin-consult/2016-April/000722.html > >As the thread evolved it has been suggested that this issue should be >resolved via the policy development process rather than through a >suggestion. > >There are a number of questions that have been raised by this thread. >I >am copying them here to continue the discussion on PPML. > >=== > >Working problem statement: ARIN will receive 2-byte ASNs as returns >over time, and these ASNs have perceived or additional value to >organizations compared to 4-byte ASNs. How should ARIN allocate these >2-byte ASNs? > >=== > >Should they be given to the next requester, regardless of technical >need >for a 2-byte ASN? (What are the technical qualifications we should use >if there is a specific technical need? e.g. provides transit to more >than 1 ASN?) > >If there is really a technical need for 2-byte ASNs, shouldn't we >attempt to build an inventory of 2-byte ASNs? > >Should returns be held in reserve? > >Should ARIN hold them for some period of time before reallocating >them? > >Should they be put up for auction to qualified organizations? > >Should they be given to the 1st organization on a wait-list for 2-byte > >ASNs? > >Would an organization looking for a 2-byte ASN have the option to >receive a 4-byte ASN in the interim? If they did would they have to >return it? > >Should the waiting list be closed to organizations that already have a >2-byte ASNs? > >I and the AC would appreciate your comments on these questions so that >we can start to build a draft policy that best matches with what the >community would like to see implemented by ARIN. > >Thanks, >Andrew > > > >_______________________________________________ >PPML >You are receiving this message because you are subscribed to >the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >Unsubscribe or manage your mailing list subscription at: >http://lists.arin.net/mailman/listinfo/arin-ppml >Please contact info at arin.net if you experience any issues. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rgrant at skywaywest.com Sun Apr 3 14:52:23 2016 From: rgrant at skywaywest.com (Ron Grant) Date: Sun, 3 Apr 2016 11:52:23 -0700 Subject: [arin-ppml] 2-byte ASN policy In-Reply-To: <4CFD1C3E-CAA7-45A1-9784-CBC9A1E29800@athompso.net> References: <57015A09.2030901@quark.net> <4CFD1C3E-CAA7-45A1-9784-CBC9A1E29800@athompso.net> Message-ID: <57016667.8050300@skywaywest.com> The biggest technical problem with 4-byte ASNs that I'm aware of comes when propagating BGP communities - AFAIK even with extended communities, you can't specify two 4-byte ASNs in a single community. This can be worked around when using communities for direct peering arrangements, as one side of the equation is static - but at a Public Exchange point, it can be problematic, because who knows who might want to connect or not connect to whom. Recently we ran into this problem when requesting an ASN for the Vancouver Internet Exchange (VANIX) - we were told there were no 2-byte ASNs left, so we went back to the drawing board to see how we could run our Route Server with a 4-byte ASN, and after wrestling with the problem for a few weeks, went back to ARIN and...joy!...someone had returned a 2-byte, which we obtained for the RS. IMO any future returned 2-byte ASNs should be reserved for critical infrastructure or special need, but I'd love to find a solution to the communities issue that made 2-byte ASNs "not special" anymore. On 2016-04-03 11:36 AM, Adam Thompson wrote: > IMO, 2-byte ASNs should simply be retired and not reallocated. > "Solving the technical problem", as described in your email, is > actually ensuring the perpetuation of a different technical problem. > It's the same sort of thing as the IPv4 vs IPv6 --transition, but this > time ARIN has an opportunity to at least avoid being part of the > problem, even if it can't really be part of the "solution". > Let's please not prolong this problem, too... even in central Canada, > known for a paucity of upstream carriers, it's now commercially > feasible to work around the 2-byte technical limitations. > > -Adam > > > On April 3, 2016 12:59:37 PM CDT, Andrew Dul > wrote: > > Hello, > > I am starting a new thread in PPML, as a follow up to the ARIN > suggestion and consultation which recently started regarding creating a > 2-byte ASN waiting list. > > The original suggestion is here: > > https://www.arin.net/participate/acsp/suggestions/2016-04.html > > ARIN opened a consultation on this suggestion on the arin-consult > mailing-list. This thread starts here for those who are not subscribed > to arin-consult. > > http://lists.arin.net/pipermail/arin-consult/2016-March/000713.html > > http://lists.arin.net/pipermail/arin-consult/2016-April/000722.html > > As the thread evolved it has been suggested that this issue should be > resolved via the policy development process rather than through a > suggestion. > > There are a number of questions that have been raised by this thread. I > am copying them here to continue the discussion on PPML. > > === > > Working problem statement: ARIN will receive 2-byte ASNs as returns > over time, and these ASNs have perceived or additional value to > organizations compared to 4-byte ASNs. How should ARIN allocate these > 2-byte ASNs? > > === > > Should they be given to the next requester, regardless of technical need > for a 2-byte ASN? (What are the technical qualifications we should use > if there is a specific technical need? e.g. provides transit to more > than 1 ASN?) > > If there is really a technical need for 2-byte ASNs, shouldn't we > attempt to build an inventory of 2-byte ASNs? > > Should returns be held in reserve? > > Should ARIN hold them for some period of > time > before reallocating them? > > Should they be put up for auction to qualified organizations? > > Should they be given to the 1st organization on a wait-list for 2-byte > ASNs? > > Would an organization looking for a 2-byte ASN have the option to > receive a 4-byte ASN in the interim? If they did would they have to > return it? > > Should the waiting list be closed to organizations that already have a > 2-byte ASNs? > > I and the AC would appreciate your comments on these questions so that > we can start to build a draft policy that best matches with what the > community would like to see implemented by ARIN. > > Thanks, > Andrew > > > > ------------------------------------------------------------------------ > > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > -- Sent from my Android device with K-9 Mail. Please excuse my brevity. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -- Ron Grant Managed DSL/Cable/Wireless/Fibre Skyway West Business Internet Internet and Private Networking rgrant at skywaywest.com Bonding and Fail Over Solutions cell: 604-737-2113 Virtual Data Centre and Private Clouds direct: 604-484-5263 http://www.skywaywest.com Sales, Support and Billing http://www.skywaywest.com/contact-us.htm ca.linkedin.com/in/obiron -------------- next part -------------- An HTML attachment was scrubbed... URL: From athompso at athompso.net Sun Apr 3 20:15:22 2016 From: athompso at athompso.net (Adam Thompson) Date: Sun, 3 Apr 2016 19:15:22 -0500 Subject: [arin-ppml] 2-byte ASN policy In-Reply-To: <57016667.8050300@skywaywest.com> References: <57015A09.2030901@quark.net> <4CFD1C3E-CAA7-45A1-9784-CBC9A1E29800@athompso.net> <57016667.8050300@skywaywest.com> Message-ID: <5701B21A.3030202@athompso.net> (IMHO, and I know this is highly debatable but this isn't the place, BGP communities are a mis-feature anyway.) Regardless, reserving 2-byte ASNs for "critical infrastructure" is a good compromise if the restrictions mirror those for the IPv4 block also reserved for "critical infrastructure". -Adam On 2016-04-03 13:52, Ron Grant wrote: > The biggest technical problem with 4-byte ASNs that I'm aware of comes > when propagating BGP communities - AFAIK even with extended > communities, you can't specify two 4-byte ASNs in a single community. > > This can be worked around when using communities for direct peering > arrangements, as one side of the equation is static - but at a Public > Exchange point, it can be problematic, because who knows who might > want to connect or not connect to whom. > > Recently we ran into this problem when requesting an ASN for the > Vancouver Internet Exchange (VANIX) - we were told there were no > 2-byte ASNs left, so we went back to the drawing board to see how we > could run our Route Server with a 4-byte ASN, and after wrestling with > the problem for a few weeks, went back to ARIN and...joy!...someone > had returned a 2-byte, which we obtained for the RS. > > IMO any future returned 2-byte ASNs should be reserved for critical > infrastructure or special need, but I'd love to find a solution to the > communities issue that made 2-byte ASNs "not special" anymore. > > > > > On 2016-04-03 11:36 AM, Adam Thompson wrote: >> IMO, 2-byte ASNs should simply be retired and not reallocated. >> "Solving the technical problem", as described in your email, is >> actually ensuring the perpetuation of a different technical problem. >> It's the same sort of thing as the IPv4 vs IPv6 --transition, but >> this time ARIN has an opportunity to at least avoid being part of the >> problem, even if it can't really be part of the "solution". >> Let's please not prolong this problem, too... even in central Canada, >> known for a paucity of upstream carriers, it's now commercially >> feasible to work around the 2-byte technical limitations. >> >> -Adam >> >> >> On April 3, 2016 12:59:37 PM CDT, Andrew Dul >> wrote: >> >> Hello, >> >> I am starting a new thread in PPML, as a follow up to the ARIN >> suggestion and consultation which recently started regarding creating a >> 2-byte ASN waiting list. >> >> The original suggestion is here: >> >> https://www.arin.net/participate/acsp/suggestions/2016-04.html >> >> ARIN opened a consultation on this suggestion on the arin-consult >> mailing-list. This thread starts here for those who are not subscribed >> to arin-consult. >> >> http://lists.arin.net/pipermail/arin-consult/2016-March/000713.html >> >> http://lists.arin.net/pipermail/arin-consult/2016-April/000722.html >> >> As the thread evolved it has been suggested that this issue should be >> resolved via the policy development process rather than through a >> suggestion. >> >> There are a number of questions that have been raised by this thread. I >> am copying them here to continue the discussion on PPML. >> >> === >> >> Working problem statement: ARIN will receive 2-byte ASNs as returns >> over time, and these ASNs have perceived or additional value to >> organizations compared to 4-byte ASNs. How should ARIN allocate these >> 2-byte ASNs? >> >> === >> >> Should they be given to the next requester, regardless of technical need >> for a 2-byte ASN? (What are the technical qualifications we should use >> if there is a specific technical need? e.g. provides transit to more >> than 1 ASN?) >> >> If there is really a technical need for 2-byte ASNs, shouldn't we >> attempt to build an inventory of 2-byte ASNs? >> >> Should returns be held in reserve? >> >> Should ARIN hold them for some period of >> time >> before reallocating them? >> >> Should they be put up for auction to qualified organizations? >> >> Should they be given to the 1st organization on a wait-list for 2-byte >> ASNs? >> >> Would an organization looking for a 2-byte ASN have the option to >> receive a 4-byte ASN in the interim? If they did would they have to >> return it? >> >> Should the waiting list be closed to organizations that already have a >> 2-byte ASNs? >> >> I and the AC would appreciate your comments on these questions so that >> we can start to build a draft policy that best matches with what the >> community would like to see implemented by ARIN. >> >> Thanks, >> Andrew >> >> >> >> ------------------------------------------------------------------------ >> >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contactinfo at arin.net if you experience any issues. >> >> -- Sent from my Android device with K-9 Mail. Please excuse my brevity. >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contactinfo at arin.net if you experience any issues. > -- > Ron Grant Managed DSL/Cable/Wireless/Fibre > Skyway West Business Internet Internet and Private Networking > rgrant at skywaywest.com Bonding and Fail Over Solutions > cell: 604-737-2113 Virtual Data Centre and Private Clouds > direct: 604-484-5263http://www.skywaywest.com > > Sales, Support and Billinghttp://www.skywaywest.com/contact-us.htm > > ca.linkedin.com/in/obiron -------------- next part -------------- An HTML attachment was scrubbed... URL: From michel at arneill-py.sacramento.ca.us Sun Apr 3 20:34:09 2016 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Mon, 4 Apr 2016 00:34:09 +0000 Subject: [arin-ppml] 2-byte ASN policy In-Reply-To: <57016667.8050300@skywaywest.com> References: <57015A09.2030901@quark.net> <4CFD1C3E-CAA7-45A1-9784-CBC9A1E29800@athompso.net> <57016667.8050300@skywaywest.com> Message-ID: > Ron Grant wrote : > The biggest technical problem with 4-byte ASNs that I'm aware of comes when propagating BGP communities > - AFAIK even with extended communities, you can't specify two 4-byte ASNs in a single community. Indeed. I am perverting RT:ASN:Comm (that part does accept and propagate multiple 4-byte ASNs) instead of ROO:ASN:Comm; I wanted to propagate a community that said something about the source of the prefix, not the target. I'm evil. Michel. ip extcommunity-list standard COMM-EX-CBBC permit rt 4200065532:666 rt 4200065532:667 route-map RM-EXABGP permit 10 set extcommunity rt 4200065532:666 4200065532:667 cisco2821#sh ip bgp x.x.x.x BGP routing table entry for x.x.x.x/32, version 19852973 Paths: (1 available, best #1, table default) Not advertised to any peer 65532 192.0.2.1 from 50.1.8.254 (50.1.8.254) Origin IGP, localpref 100, valid, external, best Community: 65532:666 65532:667 Extended Community: RT:4200065532:666 RT:4200065532:667 From rgrant at skywaywest.com Sun Apr 3 20:41:59 2016 From: rgrant at skywaywest.com (Ron Grant) Date: Sun, 3 Apr 2016 17:41:59 -0700 Subject: [arin-ppml] 2-byte ASN policy In-Reply-To: References: <57015A09.2030901@quark.net> <4CFD1C3E-CAA7-45A1-9784-CBC9A1E29800@athompso.net> <57016667.8050300@skywaywest.com> Message-ID: <5701B857.2060702@skywaywest.com> Sorry, your humour is completely evading me tonight. Can you explain? BTW, this comment is not intended to be an obtuse rejoinder, I'm sincerely interested in what you're trying to say. On 2016-04-03 5:34 PM, Michel Py wrote: >> Ron Grant wrote : >> The biggest technical problem with 4-byte ASNs that I'm aware of comes when propagating BGP communities >> - AFAIK even with extended communities, you can't specify two 4-byte ASNs in a single community. > Indeed. I am perverting RT:ASN:Comm (that part does accept and propagate multiple 4-byte ASNs) instead of ROO:ASN:Comm; I wanted to propagate a community that said something about the source of the prefix, not the target. I'm evil. > > Michel. > > ip extcommunity-list standard COMM-EX-CBBC permit rt 4200065532:666 rt 4200065532:667 > > route-map RM-EXABGP permit 10 > set extcommunity rt 4200065532:666 4200065532:667 > > cisco2821#sh ip bgp x.x.x.x > BGP routing table entry for x.x.x.x/32, version 19852973 > Paths: (1 available, best #1, table default) > Not advertised to any peer > 65532 > 192.0.2.1 from 50.1.8.254 (50.1.8.254) > Origin IGP, localpref 100, valid, external, best > Community: 65532:666 65532:667 > Extended Community: RT:4200065532:666 RT:4200065532:667 > -- Ron Grant Managed DSL/Cable/Wireless/Fibre Skyway West Business Internet Internet and Private Networking rgrant at skywaywest.com Bonding and Fail Over Solutions cell: 604-737-2113 Virtual Data Centre and Private Clouds direct: 604-484-5263 http://www.skywaywest.com Sales, Support and Billing http://www.skywaywest.com/contact-us.htm ca.linkedin.com/in/obiron From michel at arneill-py.sacramento.ca.us Sun Apr 3 23:18:31 2016 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Mon, 4 Apr 2016 03:18:31 +0000 Subject: [arin-ppml] 2-byte ASN policy In-Reply-To: <5701B857.2060702@skywaywest.com> References: <57015A09.2030901@quark.net> <4CFD1C3E-CAA7-45A1-9784-CBC9A1E29800@athompso.net> <57016667.8050300@skywaywest.com> <5701B857.2060702@skywaywest.com> Message-ID: Hi Ron, > Ron Grant wrote : > Sorry, your humour is completely evading me tonight. Can you explain? No worries, I understand it's hard to get sometimes. Long story made short : - I'm running an experimental BGP blacklist: http://arneill-py.sacramento.ca.us/cbbc/ - Basically, it's a route server; the next-hop I announce is 192.0.2.1, which struck me to be the most widely used blackhole route. - The sources are multiple and diverse. - Not unlike other BGP blacklists, I will (conditions) accept prefixes with the correct BGP community, which happens to be ASN:666. - I have nothing to do with the meaning some will see in the 666 part; I was not the one who invented it. - For reference : to my knowledge, the first public reference in using 666 as the BGP blacklist community dates back to September 2004 : https://tools.ietf.org/rfc/rfc3882.txt - Not trying to pretend I am innocent, I was in the room in the IETF meeting when we voted that the 6bone deprecation date would be 6/6/6. - This is not an April fool's joke. - Back to BGP : it has been suggested earlier on that the CBBC should announce various communities, instead of the original 65532:666; that would allow subscribers to ignore potentially undesirable/incompatible/controversial sources. I agreed. - Some of the potential sources and actual CBBC subscribers have a 4-byte ASN number, possibly because they could not obtain a 2-byte one. - The propagation mechanism should allow for 4-byte-ASN:666 as well as 2-byte-ASN:666. The comments below are Cisco-oriented, YMMV. - Therefore, the need for a 4-byte ASN equivalent to the good old "ip bgp-community new-format" arose. - That would be 2-byte-ASN:666 - Since there is no such thing as 4-byte-ASN:666, the logic suggested that the proper way to do it would be something along the lines of SoO:4-byte-ASN:666, does not accept multiple entries. - Here we go : instead of trying to use SoO:ASN:Comm which is very stubborn animal and refuses multiple entries as well as the "additive" thing, instead I use RT:ASN:Comm which solves the problem you are having : give me the multiple-ASN version of BGP the 2-byte-ASN flavor communities we used for ages for 4-byte-ASNs. - It configures AND propagates. See below. > sincerely interested in what you're trying to say. I am a Sith Lord known as Darth Numerous. Being the devil himself on top of it does not hurt me :P Are you, uh, looking for a job as an apprentice to the Dark Side ? Michel. route-map RM-EXABGP permit 10 description IPv4 filter learned from iBGP peer set extcommunity rt 4200000000:1111 4200065532:666 4200065532:667 set ip next-hop 192.0.2.1 cisco1841-michel#sh ip bgp 1.9.79.191 BGP routing table entry for 1.9.79.191/32, version 4 Paths: (1 available, best #1, table default) Advertised to update-groups: 40 Local 192.0.2.1 from 192.168.222.3 (192.168.222.3) Origin IGP, localpref 100, weight 1, valid, internal, best Community: 65532:666 65532:667 Extended Community: RT:4200000000:1111 RT:4200065532:666 RT:4200065532:667 From info at arin.net Mon Apr 4 12:00:15 2016 From: info at arin.net (ARIN) Date: Mon, 04 Apr 2016 12:00:15 -0400 Subject: [arin-ppml] Advisory Council Meeting Results - March 2016 In-Reply-To: <56F178D8.6050505@arin.net> References: <56F178D8.6050505@arin.net> Message-ID: <57028F8F.1010706@arin.net> > The AC abandoned 2015-6. Anyone dissatisfied with this decision may > initiate a petition. The deadline to begin a petition will be five > business days after the AC's draft meeting minutes are published. The minutes from the ARIN Advisory Council's 17 March 2016 meeting have been published: https://www.arin.net/about_us/ac/ac2016_0317.html The petition deadline is 11 April 2016. For more information on starting and participating in petitions, see PDP Petitions at: https://www.arin.net/policy/pdp_petitions.html The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Draft Policy and Proposal texts are available at: https://www.arin.net/policy/proposals/index.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) On 3/22/16 12:54 PM, ARIN wrote: > In accordance with the ARIN Policy Development Process (PDP), the ARIN > Advisory Council (AC) met on 17 March 2016. > > The AC recommended the following to the ARIN Board of Trustees for > adoption: > > Recommended Draft Policy ARIN-2015-5: Out of region use > Recommended Draft Policy ARIN-2015-11: Remove transfer language which > only applied pre-exhaustion of IPv4 pool > > The AC accepted the following Proposal as a Draft Policy (it will be > posted for discussion): > > Draft Policy 2016-1 Reserved Pool Transfer Policy > > The AC abandoned the following: > > Draft Policy ARIN-2015-6: Transfers and Multi-national Networks > > The AC stated, "The ARIN Advisory Council based on input from the > community has voted to abandon ARIN 2015-6 Transfers and Multi-National > Networks. The proposal was similar to ARIN 2015-5 Out of Region Use, > which has completed last call and been recommended for Adoption. The > community feedback was to maintain the proposal as a secondary option, > with 2015-5 as the preferred course of action." > > The AC is continuing to work on: > > Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to > Specified Recipients) > Recommended Draft Policy ARIN-2015-3: Remove 30 day utilization > requirement in end-user IPv4 policy > Draft Policy ARIN-2015-7: Simplified requirements for demonstrated > need for IPv4 transfers > Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for > Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks > > The AC abandoned 2015-6. Anyone dissatisfied with this decision may > initiate a petition. The deadline to begin a petition will be five > business days after the AC's draft meeting minutes are published. For > more information on starting and participating in petitions, see PDP > Petitions at: > https://www.arin.net/policy/pdp_petitions.html > > Draft Policy and Proposal texts are available at: > https://www.arin.net/policy/proposals/index.html > > The ARIN Policy Development Process can be found at: > https://www.arin.net/policy/pdp.html > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) From owen at delong.com Mon Apr 4 16:08:54 2016 From: owen at delong.com (Owen DeLong) Date: Mon, 4 Apr 2016 13:08:54 -0700 Subject: [arin-ppml] 2-byte ASN policy In-Reply-To: <57016667.8050300@skywaywest.com> References: <57015A09.2030901@quark.net> <4CFD1C3E-CAA7-45A1-9784-CBC9A1E29800@athompso.net> <57016667.8050300@skywaywest.com> Message-ID: <63AA9FBE-4737-4538-BE23-5D54A6C3C98B@delong.com> > On Apr 3, 2016, at 11:52 , Ron Grant wrote: > > The biggest technical problem with 4-byte ASNs that I'm aware of comes when propagating BGP communities - AFAIK even with extended communities, you can't specify two 4-byte ASNs in a single community. > > This can be worked around when using communities for direct peering arrangements, as one side of the equation is static - but at a Public Exchange point, it can be problematic, because who knows who might want to connect or not connect to whom. This can be worked around in extended communities using a pair of communities (one type 0x42 and one type 0x02). > Recently we ran into this problem when requesting an ASN for the Vancouver Internet Exchange (VANIX) - we were told there were no 2-byte ASNs left, so we went back to the drawing board to see how we could run our Route Server with a 4-byte ASN, and after wrestling with the problem for a few weeks, went back to ARIN and...joy!...someone had returned a 2-byte, which we obtained for the RS. So you?ve perpetuated the problem rather than finding a solution. I suppose that?s one way to go. Really, for an RS, you don?t need two ASNs in the community as you already have one of them in the peer-as route property, so all you care about is the advertise-to ASNs. This could be handled with an extended community of type ?Destination AS specific? where the ?Global Administrator? field is set to the destination AS. If you care about tagging the AS that fed the route to the route server, that can be done with an additional extended community of type ?Origin AS Specific? where the ?Global Administrator? field is set to the advertising AS. You would then have 16 bits with which other information could also be encoded into each of those communities if you so choose. > IMO any future returned 2-byte ASNs should be reserved for critical infrastructure or special need, but I'd love to find a solution to the communities issue that made 2-byte ASNs "not special" anymore. This is already a solved problem IMHO. Owen > > > > > On 2016-04-03 11:36 AM, Adam Thompson wrote: >> IMO, 2-byte ASNs should simply be retired and not reallocated. "Solving the technical problem", as described in your email, is actually ensuring the perpetuation of a different technical problem. >> It's the same sort of thing as the IPv4 vs IPv6 --transition, but this time ARIN has an opportunity to at least avoid being part of the problem, even if it can't really be part of the "solution". >> Let's please not prolong this problem, too... even in central Canada, known for a paucity of upstream carriers, it's now commercially feasible to work around the 2-byte technical limitations. >> >> -Adam >> >> >> On April 3, 2016 12:59:37 PM CDT, Andrew Dul wrote: >> Hello, >> >> I am starting a new thread in PPML, as a follow up to the ARIN >> suggestion and consultation which recently started regarding creating a >> 2-byte ASN waiting list. >> >> The original suggestion is here: >> >> https://www.arin.net/participate/acsp/suggestions/2016-04.html >> >> ARIN opened a consultation on this suggestion on the arin-consult >> mailing-list. This thread starts here for those who are not subscribed >> to arin-consult. >> >> http://lists.arin.net/pipermail/arin-consult/2016-March/000713.html >> >> http://lists.arin.net/pipermail/arin-consult/2016-April/000722.html >> >> As the thread evolved it has been suggested that this issue should be >> resolved via the policy development process rather than through a >> suggestion. >> >> There are a number of questions that have been raised by this thread. I >> am copying them here to continue the discussion on PPML. >> >> === >> >> Working problem statement: ARIN will receive 2-byte ASNs as returns >> over time, and these ASNs have perceived or additional value to >> organizations compared to 4-byte ASNs. How should ARIN allocate these >> 2-byte ASNs? >> >> === >> >> Should they be given to the next requester, regardless of technical need >> for a 2-byte ASN? (What are the technical qualifications we should use >> if there is a specific technical need? e.g. provides transit to more >> than 1 ASN?) >> >> If there is really a technical need for 2-byte ASNs, shouldn't we >> attempt to build an inventory of 2-byte ASNs? >> >> Should returns be held in reserve? >> >> Should ARIN hold them for some period of >> time >> before reallocating them? >> >> Should they be put up for auction to qualified organizations? >> >> Should they be given to the 1st organization on a wait-list for 2-byte >> ASNs? >> >> Would an organization looking for a 2-byte ASN have the option to >> receive a 4-byte ASN in the interim? If they did would they have to >> return it? >> >> Should the waiting list be closed to organizations that already have a >> 2-byte ASNs? >> >> I and the AC would appreciate your comments on these questions so that >> we can start to build a draft policy that best matches with what the >> community would like to see implemented by ARIN. >> >> Thanks, >> Andrew >> >> >> >> >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> -- Sent from my Android device with K-9 Mail. Please excuse my brevity. >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > -- > Ron Grant Managed DSL/Cable/Wireless/Fibre > Skyway West Business Internet Internet and Private Networking > rgrant at skywaywest.com Bonding and Fail Over Solutions > cell: 604-737-2113 Virtual Data Centre and Private Clouds > direct: 604-484-5263 http://www.skywaywest.com > > Sales, Support and Billing http://www.skywaywest.com/contact-us.htm > > ca.linkedin.com/in/obiron > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at semihuman.com Mon Apr 4 16:30:40 2016 From: chris at semihuman.com (Chris Woodfield) Date: Mon, 4 Apr 2016 13:30:40 -0700 Subject: [arin-ppml] 2-byte ASN policy In-Reply-To: <4CFD1C3E-CAA7-45A1-9784-CBC9A1E29800@athompso.net> References: <57015A09.2030901@quark.net> <4CFD1C3E-CAA7-45A1-9784-CBC9A1E29800@athompso.net> Message-ID: Do we have information on how many 2-byte ASNs get returned, compared to the rate of requests for them? Is there a surplus? > On Apr 3, 2016, at 11:36 AM, Adam Thompson wrote: > > IMO, 2-byte ASNs should simply be retired and not reallocated. "Solving the technical problem", as described in your email, is actually ensuring the perpetuation of a different technical problem. > It's the same sort of thing as the IPv4 vs IPv6 --transition, but this time ARIN has an opportunity to at least avoid being part of the problem, even if it can't really be part of the "solution". > Let's please not prolong this problem, too... even in central Canada, known for a paucity of upstream carriers, it's now commercially feasible to work around the 2-byte technical limitations. > > -Adam > > > On April 3, 2016 12:59:37 PM CDT, Andrew Dul wrote: > Hello, > > I am starting a new thread in PPML, as a follow up to the ARIN > suggestion and consultation which recently started regarding creating a > 2-byte ASN waiting list. > > The original suggestion is here: > > https://www.arin.net/participate/acsp/suggestions/2016-04.html > > ARIN opened a consultation on this suggestion on the arin-consult > mailing-list. This thread starts here for those who are not subscribed > to arin-consult. > > http://lists.arin.net/pipermail/arin-consult/2016-March/000713.html > > http://lists.arin.net/pipermail/arin-consult/2016-April/000722.html > > As the thread evolved it has been suggested that this issue should be > resolved via the policy development process rather than through a > suggestion. > > There are a number of questions that have been raised by this thread. I > am copying them here to continue the discussion on PPML. > > === > > Working problem statement: ARIN will receive 2-byte ASNs as returns > over time, and these ASNs have perceived or additional value to > organizations compared to 4-byte ASNs. How should ARIN allocate these > 2-byte ASNs? > > === > > Should they be given to the next requester, regardless of technical need > for a 2-byte ASN? (What are the technical qualifications we should use > if there is a specific technical need? e.g. provides transit to more > than 1 ASN?) > > If there is really a technical need for 2-byte ASNs, shouldn't we > attempt to build an inventory of 2-byte ASNs? > > Should returns be held in reserve? > > Should ARIN hold them for some period of > time > before reallocating them? > > Should they be put up for auction to qualified organizations? > > Should they be given to the 1st organization on a wait-list for 2-byte > ASNs? > > Would an organization looking for a 2-byte ASN have the option to > receive a 4-byte ASN in the interim? If they did would they have to > return it? > > Should the waiting list be closed to organizations that already have a > 2-byte ASNs? > > I and the AC would appreciate your comments on these questions so that > we can start to build a draft policy that best matches with what the > community would like to see implemented by ARIN. > > Thanks, > Andrew > > > > > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From David_Huberman at outlook.com Mon Apr 4 16:56:34 2016 From: David_Huberman at outlook.com (David Huberman) Date: Mon, 4 Apr 2016 20:56:34 +0000 Subject: [arin-ppml] 2-byte ASN policy In-Reply-To: References: <57015A09.2030901@quark.net> <4CFD1C3E-CAA7-45A1-9784-CBC9A1E29800@athompso.net>, Message-ID: Chris's excellent question jogs my brain to ask a related-but-different question: ARIN has traditionally had a large number of AS numbers (almost all 2-byte) in the "hold" bucket. These are ASNs which have been revoked for years due to non-payment and separation from the RSA. But they're still found in the DFZ. Can't ARIN ask requestors who say they need 2-bytes if they'd be willing to accept a 2-byte ASN that may have route announcements present in the DFZ, and due to circumstances blah blah blah? It boils down to "we have 2-byte ASNs, but they're not quite as clean as one might expect - is that ok?", because I'm pretty sure the answer will always be "HECK YEAH!" ASNs aren't quite like IP addresses in this context. There's no conflict I know of unless the new registrants tries to directly exchange routes with the old registrant, which is mathematically highly improbable. ________________________________ From: arin-ppml-bounces at arin.net on behalf of Chris Woodfield Sent: Monday, April 4, 2016 4:30 PM To: Adam Thompson Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] 2-byte ASN policy Do we have information on how many 2-byte ASNs get returned, compared to the rate of requests for them? Is there a surplus? On Apr 3, 2016, at 11:36 AM, Adam Thompson > wrote: IMO, 2-byte ASNs should simply be retired and not reallocated. "Solving the technical problem", as described in your email, is actually ensuring the perpetuation of a different technical problem. It's the same sort of thing as the IPv4 vs IPv6 --transition, but this time ARIN has an opportunity to at least avoid being part of the problem, even if it can't really be part of the "solution". Let's please not prolong this problem, too... even in central Canada, known for a paucity of upstream carriers, it's now commercially feasible to work around the 2-byte technical limitations. -Adam On April 3, 2016 12:59:37 PM CDT, Andrew Dul > wrote: Hello, I am starting a new thread in PPML, as a follow up to the ARIN suggestion and consultation which recently started regarding creating a 2-byte ASN waiting list. The original suggestion is here: https://www.arin.net/participate/acsp/suggestions/2016-04.html ARIN opened a consultation on this suggestion on the arin-consult mailing-list. This thread starts here for those who are not subscribed to arin-consult. http://lists.arin.net/pipermail/arin-consult/2016-March/000713.html http://lists.arin.net/pipermail/arin-consult/2016-April/000722.html As the thread evolved it has been suggested that this issue should be resolved via the policy development process rather than through a suggestion. There are a number of questions that have been raised by this thread. I am copying them here to continue the discussion on PPML. === Working problem statement: ARIN will receive 2-byte ASNs as returns over time, and these ASNs have perceived or additional value to organizations compared to 4-byte ASNs. How should ARIN allocate these 2-byte ASNs? === Should they be given to the next requester, regardless of technical need for a 2-byte ASN? (What are the technical qualifications we should use if there is a specific technical need? e.g. provides transit to more than 1 ASN?) If there is really a technical need for 2-byte ASNs, shouldn't we attempt to build an inventory of 2-byte ASNs? Should returns be held in reserve? Should ARIN hold them for some period of time before reallocating them? Should they be put up for auction to qualified organizations? Should they be given to the 1st organization on a wait-list for 2-byte ASNs? Would an organization looking for a 2-byte ASN have the option to receive a 4-byte ASN in the interim? If they did would they have to return it? Should the waiting list be closed to organizations that already have a 2-byte ASNs? I and the AC would appreciate your comments on these questions so that we can start to build a draft policy that best matches with what the community would like to see implemented by ARIN. Thanks, Andrew ________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From job at ntt.net Mon Apr 4 17:17:11 2016 From: job at ntt.net (Job Snijders) Date: Mon, 4 Apr 2016 23:17:11 +0200 Subject: [arin-ppml] 2-byte ASN policy In-Reply-To: References: <57015A09.2030901@quark.net> <4CFD1C3E-CAA7-45A1-9784-CBC9A1E29800@athompso.net> Message-ID: <20160404211711.GB901@22.rev.meerval.net> On Mon, Apr 04, 2016 at 08:56:34PM +0000, David Huberman wrote: > ARIN has traditionally had a large number of AS numbers (almost all > 2-byte) in the "hold" bucket. These are ASNs which have been revoked > for years due to non-payment and separation from the RSA. But they're > still found in the DFZ. > > Can't ARIN ask requestors who say they need 2-bytes if they'd be > willing to accept a 2-byte ASN that may have route announcements > present in the DFZ, and due to circumstances blah blah blah? It boils > down to "we have 2-byte ASNs, but they're not quite as clean as one > might expect - is that ok?", because I'm pretty sure the answer will > always be "HECK YEAH!" > ASNs aren't quite like IP addresses in this context. There's no > conflict I know of unless the new registrants tries to directly > exchange routes with the old registrant, which is mathematically > highly improbable. (Assuming at least one of two parties is running their network with default settings..) Indrect route exchange will also fail due to AS_PATH loop prevention. ("Phase 2: Route Selection" RFC4271). The idea is interesting, but I wonder if there will be cases where the new ASN holder just can't get the old ASN holder's peers & upstreams to disconnect the illegitimately user of the ASN, causing operational issues. Kind regards, Job From David_Huberman at outlook.com Mon Apr 4 17:38:43 2016 From: David_Huberman at outlook.com (David Huberman) Date: Mon, 4 Apr 2016 21:38:43 +0000 Subject: [arin-ppml] 2-byte ASN policy In-Reply-To: <20160404211711.GB901@22.rev.meerval.net> References: <57015A09.2030901@quark.net> <4CFD1C3E-CAA7-45A1-9784-CBC9A1E29800@athompso.net> , <20160404211711.GB901@22.rev.meerval.net> Message-ID: Thanks for the good reply, Job. So two things. 1) It's a trade-off, right? A network operator who absolutely must have a 2-byte either has equipment that hasn't been updated in 6+ years, or is having an issue like BGP communities where the solution they want to implement requires a 2-byte (rather than what Owen is talking about). Their network, their rules. So if they want a 2-byte, and ARIN has inventory of 2-bytes -- but they're found in the DFZ -- that requires the network operator to make a decision. ARIN's lawyers can surely indemnify ARIN from any fault. So in this scenario (which Im just proposing as a thought experiment) the network operator should be allowed to determine for herself what's best for her network. 2) ARIN staff (me!) spent many years trying to get upstreams to help us deal with the backlog of ASNs which were (from a Registry perspective) being squatted on. And these arent published in Whois btw. But it was simply too much volume to handle. The upstreams are primarily concerned with profit, and customer relations, and this was very much a low priority. Then add in high volume for 7018 or someone like that, and it became completely untenable. In your scenario, it's less volume. But success in this path is not an expectation I would want to set for anyone who is fine taking a routed ASN. Thanks /david ________________________________________ From: Job Snijders Sent: Monday, April 4, 2016 5:17 PM To: David Huberman Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] 2-byte ASN policy On Mon, Apr 04, 2016 at 08:56:34PM +0000, David Huberman wrote: > ARIN has traditionally had a large number of AS numbers (almost all > 2-byte) in the "hold" bucket. These are ASNs which have been revoked > for years due to non-payment and separation from the RSA. But they're > still found in the DFZ. > > Can't ARIN ask requestors who say they need 2-bytes if they'd be > willing to accept a 2-byte ASN that may have route announcements > present in the DFZ, and due to circumstances blah blah blah? It boils > down to "we have 2-byte ASNs, but they're not quite as clean as one > might expect - is that ok?", because I'm pretty sure the answer will > always be "HECK YEAH!" > ASNs aren't quite like IP addresses in this context. There's no > conflict I know of unless the new registrants tries to directly > exchange routes with the old registrant, which is mathematically > highly improbable. (Assuming at least one of two parties is running their network with default settings..) Indrect route exchange will also fail due to AS_PATH loop prevention. ("Phase 2: Route Selection" RFC4271). The idea is interesting, but I wonder if there will be cases where the new ASN holder just can't get the old ASN holder's peers & upstreams to disconnect the illegitimately user of the ASN, causing operational issues. Kind regards, Job From farmer at umn.edu Mon Apr 4 18:08:19 2016 From: farmer at umn.edu (David Farmer) Date: Mon, 4 Apr 2016 17:08:19 -0500 Subject: [arin-ppml] 2-byte ASN policy In-Reply-To: <5701B21A.3030202@athompso.net> References: <57015A09.2030901@quark.net> <4CFD1C3E-CAA7-45A1-9784-CBC9A1E29800@athompso.net> <57016667.8050300@skywaywest.com> <5701B21A.3030202@athompso.net> Message-ID: 6.10.1 and 4.4 speak to critical infrastructure. 6.10.1 has the more concise definition and is quoted below. 4.4 has been edited, but includes the same components, just more spread out. ARIN will make micro-allocations to critical infrastructure providers of the Internet, including public exchange points, core DNS service providers (e.g. ICANN-sanctioned root, gTLD, and ccTLD operators) as well as the RIRs and IANA. So, I think understand the issue as they relate to internet exchanges, they have been and are being discussed. However, I'm not certain these issues are as pressing for core DNS service providers, or at least any more than any other internet edge ASN. Could someone with experience with core DNS comment on that issue? So, maybe we should reserve any returned 2-byte ASN for internet exchanges and not include core DNS. Unless someone has a convincing argument why this is an issue for core DNS. Allow transfers, but any 2-byte ASNs returned to the free pool would be reserved for internet exchanges. Everyone else would get 4-byte ASNs out of the free pool. If there aren't any 2-byte ASNs available, or if they request request one, internet exchanges would receive a 4-byte ASN. Just an idea that I thought I would put out there. On Sun, Apr 3, 2016 at 7:15 PM, Adam Thompson wrote: > (IMHO, and I know this is highly debatable but this isn't the place, BGP > communities are a mis-feature anyway.) > > Regardless, reserving 2-byte ASNs for "critical infrastructure" is a good > compromise if the restrictions mirror those for the IPv4 block also > reserved for "critical infrastructure". > > -Adam > > > On 2016-04-03 13:52, Ron Grant wrote: > > The biggest technical problem with 4-byte ASNs that I'm aware of comes > when propagating BGP communities - AFAIK even with extended communities, > you can't specify two 4-byte ASNs in a single community. > > This can be worked around when using communities for direct peering > arrangements, as one side of the equation is static - but at a Public > Exchange point, it can be problematic, because who knows who might want to > connect or not connect to whom. > > Recently we ran into this problem when requesting an ASN for the Vancouver > Internet Exchange (VANIX) - we were told there were no 2-byte ASNs left, so > we went back to the drawing board to see how we could run our Route Server > with a 4-byte ASN, and after wrestling with the problem for a few weeks, > went back to ARIN and...joy!...someone had returned a 2-byte, which we > obtained for the RS. > > IMO any future returned 2-byte ASNs should be reserved for critical > infrastructure or special need, but I'd love to find a solution to the > communities issue that made 2-byte ASNs "not special" anymore. > > > > > On 2016-04-03 11:36 AM, Adam Thompson wrote: > > IMO, 2-byte ASNs should simply be retired and not reallocated. "Solving > the technical problem", as described in your email, is actually ensuring > the perpetuation of a different technical problem. > It's the same sort of thing as the IPv4 vs IPv6 --transition, but this > time ARIN has an opportunity to at least avoid being part of the problem, > even if it can't really be part of the "solution". > Let's please not prolong this problem, too... even in central Canada, > known for a paucity of upstream carriers, it's now commercially feasible to > work around the 2-byte technical limitations. > > -Adam > > > On April 3, 2016 12:59:37 PM CDT, Andrew Dul > wrote: >> >> Hello, >> >> I am starting a new thread in PPML, as a follow up to the ARIN >> suggestion and consultation which recently started regarding creating a >> 2-byte ASN waiting list. >> >> The original suggestion is here: >> https://www.arin.net/participate/acsp/suggestions/2016-04.html >> >> ARIN opened a consultation on this suggestion on the arin-consult >> mailing-list. This thread starts here for those who are not subscribed >> to arin-consult. >> http://lists.arin.net/pipermail/arin-consult/2016-March/000713.html >> http://lists.arin.net/pipermail/arin-consult/2016-April/000722.html >> >> As the thread evolved it has been suggested that this issue should be >> resolved via the policy development process rather than through a >> suggestion. >> >> There are a number of questions that have been raised by this thread. I >> am copying them here to continue the discussion on PPML. >> >> === >> >> Working problem statement: ARIN will receive 2-byte ASNs as returns >> over time, and these ASNs have perceived or additional value to >> organizations compared to 4-byte ASNs. How should ARIN allocate these >> 2-byte ASNs? >> >> === >> >> Should they be given to the next requester, regardless of technical need >> for a 2-byte ASN? (What are the technical qualifications we should use >> if there is a specific technical need? e.g. provides transit to more >> than 1 ASN?) >> >> If there is really a technical need for 2-byte ASNs, shouldn't we >> attempt to build an inventory of 2-byte ASNs? >> >> Should returns be held in reserve? >> >> Should ARIN hold them for some period of >> time >> before reallocating them? >> >> Should they be put up for auction to qualified organizations? >> >> Should they be given to the 1st organization on a wait-list for 2-byte >> ASNs? >> >> Would an organization looking for a 2-byte ASN have the option to >> receive a 4-byte ASN in the interim? If they did would they have to >> return it? >> >> Should the waiting list be closed to organizations that already have a >> 2-byte ASNs? >> >> I and the AC would appreciate your comments on these questions so that >> we can start to build a draft policy that best matches with what the >> community would like to see implemented by ARIN. >> >> Thanks, >> Andrew >> >> >> >> ------------------------------ >> >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at:http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> >> -- Sent from my Android device with K-9 Mail. Please excuse my brevity. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at:http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > -- > Ron Grant Managed DSL/Cable/Wireless/Fibre > Skyway West Business Internet Internet and Private Networkingrgrant at skywaywest.com Bonding and Fail Over Solutions > cell: 604-737-2113 Virtual Data Centre and Private Clouds > direct: 604-484-5263 http://www.skywaywest.com > > Sales, Support and Billing http://www.skywaywest.com/contact-us.htm > ca.linkedin.com/in/obiron > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmer at umn.edu Mon Apr 4 18:50:02 2016 From: farmer at umn.edu (David Farmer) Date: Mon, 4 Apr 2016 17:50:02 -0500 Subject: [arin-ppml] 2-byte ASN policy In-Reply-To: References: <57015A09.2030901@quark.net> <4CFD1C3E-CAA7-45A1-9784-CBC9A1E29800@athompso.net> Message-ID: On Mon, Apr 4, 2016 at 3:56 PM, David Huberman wrote: > .... > > ARIN has traditionally had a large number of AS numbers (almost all > 2-byte) in the "hold" bucket. These are ASNs which have been revoked for > years due to non-payment and separation from the RSA. But they're still > found in the DFZ. > Interesting. In the quick searching I just did, most BOGON lists focus on things from an address perspective ()IPv4 or IPv6). The only thing I found was a list of unallocated ASN announcing prefixes at, which is still kind of from an address perspective. http://thyme.rand.apnic.net/current/data-badAS Do you know of a list of BOGON ASNs? Thanks. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From job at ntt.net Mon Apr 4 18:56:04 2016 From: job at ntt.net (Job Snijders) Date: Tue, 5 Apr 2016 00:56:04 +0200 Subject: [arin-ppml] 2-byte ASN policy In-Reply-To: References: <57015A09.2030901@quark.net> <4CFD1C3E-CAA7-45A1-9784-CBC9A1E29800@athompso.net> Message-ID: <20160404225604.GG901@22.rev.meerval.net> On Mon, Apr 04, 2016 at 05:50:02PM -0500, David Farmer wrote: > On Mon, Apr 4, 2016 at 3:56 PM, David Huberman wrote: > > > .... > > > > Do you know of a list of BOGON ASNs? Go to http://www.cidr-report.org/as2.0/ and look under the "Possible Bogus ASs" section. A more detailed report can be found here: http://www.cidr-report.org/as2.0/bogus-as-advertisements.html Kind regards, Job From David_Huberman at outlook.com Mon Apr 4 19:02:03 2016 From: David_Huberman at outlook.com (David Huberman) Date: Mon, 4 Apr 2016 23:02:03 +0000 Subject: [arin-ppml] 2-byte ASN policy In-Reply-To: <20160404225604.GG901@22.rev.meerval.net> References: <57015A09.2030901@quark.net> <4CFD1C3E-CAA7-45A1-9784-CBC9A1E29800@athompso.net> , <20160404225604.GG901@22.rev.meerval.net> Message-ID: Richard Jimmerson: may we please know how many two-byte ASNs are currently in the hold bucket? ________________________________________ From: Job Snijders Sent: Monday, April 4, 2016 6:56 PM To: David Farmer Cc: David Huberman; arin-ppml at arin.net Subject: Re: [arin-ppml] 2-byte ASN policy On Mon, Apr 04, 2016 at 05:50:02PM -0500, David Farmer wrote: > On Mon, Apr 4, 2016 at 3:56 PM, David Huberman wrote: > > > .... > > > > Do you know of a list of BOGON ASNs? Go to http://www.cidr-report.org/as2.0/ and look under the "Possible Bogus ASs" section. A more detailed report can be found here: http://www.cidr-report.org/as2.0/bogus-as-advertisements.html Kind regards, Job From jlewis at lewis.org Mon Apr 4 20:17:09 2016 From: jlewis at lewis.org (Jon Lewis) Date: Mon, 4 Apr 2016 20:17:09 -0400 (EDT) Subject: [arin-ppml] 2-byte ASN policy In-Reply-To: References: <57015A09.2030901@quark.net> <4CFD1C3E-CAA7-45A1-9784-CBC9A1E29800@athompso.net> , <20160404211711.GB901@22.rev.meerval.net> Message-ID: On Mon, 4 Apr 2016, David Huberman wrote: > 1) It's a trade-off, right? A network operator who absolutely must have > a 2-byte either has equipment that hasn't been updated in 6+ years, or > is having an issue like BGP communities where the solution they want to > implement requires a 2-byte (rather than what Owen is talking about). > Their network, their rules. So if they want a 2-byte, and ARIN has > inventory of 2-bytes -- but they're found in the DFZ -- that requires > the network operator to make a decision. If both networks point default at a transit provider, traffic exchange can still work...but as Job said, they will (by default) ignore each other's routes regardless of how many AS-hops separate them. > 2) ARIN staff (me!) spent many years trying to get upstreams to help us > deal with the backlog of ASNs which were (from a Registry perspective) > being squatted on. And these arent published in Whois btw. But it was > simply too much volume to handle. The upstreams are primarily concerned > with profit, and customer relations, and this was very much a low > priority. Then add in high volume for 7018 or someone like that, and it > became completely untenable. In your scenario, it's less volume. But > success in this path is not an expectation I would want to set for > anyone who is fine taking a routed ASN. If ARIN has a large pool of ASNs which it believes ARIN is responsible for, and are not being paid for, i.e. ASN squatters, then WTH are these ASN's not published in whois as Unused/Reserved/Reclaimed/whatever term/language ARIN comes up with that clearly identifies the ASN as not belonging to whoever might be trying to use it? That just might help deter transit providers from allowing customers to use them. An automated periodic email to peeringdb/whois contacts for the immediate upstream ASNs would at least notify/remind networks that they're providing transit to an org squatting on an ASN. ---------------------------------------------------------------------- Jon Lewis, MCP :) | I route | therefore you are _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ From jcurran at arin.net Mon Apr 4 21:50:56 2016 From: jcurran at arin.net (John Curran) Date: Tue, 5 Apr 2016 01:50:56 +0000 Subject: [arin-ppml] 2-byte ASN policy In-Reply-To: References: <57015A09.2030901@quark.net> <4CFD1C3E-CAA7-45A1-9784-CBC9A1E29800@athompso.net> <20160404211711.GB901@22.rev.meerval.net> Message-ID: <89A13A71-52B3-4114-A2B4-B1C801D63C93@corp.arin.net> On Apr 4, 2016, at 8:17 PM, Jon Lewis > wrote: If ARIN has a large pool of ASNs which it believes ARIN is responsible for, and are not being paid for, i.e. ASN squatters, then WTH are these ASN's not published in whois as Unused/Reserved/Reclaimed/whatever term/language ARIN comes up with that clearly identifies the ASN as not belonging to whoever might be trying to use it? That just might help deter transit providers from allowing customers to use them. An automated periodic email to peeringdb/whois contacts for the immediate upstream ASNs would at least notify/remind networks that they're providing transit to an org squatting on an ASN. Jon - ARIN could undertake automation to monitor the appearance of ASN?s (or address blocks, for that matter) in the global routing tables and then send (unrequested) email to the contacts for the appropriate network. (I will note that much of this information is already being monitored, and reported on, at http://www.cidr-report.org , but those ISPs who really care about such and would act on the results are precisely the ones who least likely to be the problem?) If you wish us to proceed as suggested, please writeup a brief suggestion at and we will review it and post for discussion on aria-consult (as it is quite distinct from the current thread here on PPML regarding whether any policy change for 2-Byte ASN?s is desirable.) Thanks! /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From arin at ics-il.net Mon Apr 4 21:53:30 2016 From: arin at ics-il.net (Mike Hammett) Date: Mon, 4 Apr 2016 20:53:30 -0500 (CDT) Subject: [arin-ppml] 2-byte ASN policy In-Reply-To: Message-ID: <1152879685.3161.1459821207700.JavaMail.mhammett@ThunderFuck> Would operators take hijacking an ASN issued to someone more seriously than squatting on an ASN issued to no one? I'd assume no one cares about the risk to the squatter. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "David Huberman" To: arin-ppml at arin.net Sent: Monday, April 4, 2016 3:56:34 PM Subject: Re: [arin-ppml] 2-byte ASN policy Chris's excellent question jogs my brain to ask a related-but-different question: ARIN has traditionally had a large number of AS numbers (almost all 2-byte) in the "hold" bucket. These are ASNs which have been revoked for years due to non-payment and separation from the RSA. But they're still found in the DFZ. Can't ARIN ask requestors who say they need 2-bytes if they'd be willing to accept a 2-byte ASN that may have route announcements present in the DFZ, and due to circumstances blah blah blah? It boils down to "we have 2-byte ASNs, but they're not quite as clean as one might expect - is that ok?", because I'm pretty sure the answer will always be "HECK YEAH!" ASNs aren't quite like IP addresses in this context. There's no conflict I know of unless the new registrants tries to directly exchange routes with the old registrant, which is mathematically highly improbable. From: arin-ppml-bounces at arin.net on behalf of Chris Woodfield Sent: Monday, April 4, 2016 4:30 PM To: Adam Thompson Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] 2-byte ASN policy Do we have information on how many 2-byte ASNs get returned, compared to the rate of requests for them? Is there a surplus? On Apr 3, 2016, at 11:36 AM, Adam Thompson < athompso at athompso.net > wrote: IMO, 2-byte ASNs should simply be retired and not reallocated. "Solving the technical problem", as described in your email, is actually ensuring the perpetuation of a different technical problem. It's the same sort of thing as the IPv4 vs IPv6 --transition, but this time ARIN has an opportunity to at least avoid being part of the problem, even if it can't really be part of the "solution". Let's please not prolong this problem, too... even in central Canada, known for a paucity of upstream carriers, it's now commercially feasible to work around the 2-byte technical limitations. -Adam On April 3, 2016 12:59:37 PM CDT, Andrew Dul < andrew.dul at quark.net > wrote:
Hello, I am starting a new thread in PPML, as a follow up to the ARIN suggestion and consultation which recently started regarding creating a 2-byte ASN waiting list. The original suggestion is here: https://www.arin.net/participate/acsp/suggestions/2016-04.html ARIN opened a consultation on this suggestion on the arin-consult mailing-list. This thread starts here for those who are not subscribed to arin-consult. http://lists.arin.net/pipermail/arin-consult/2016-March/000713.html http://lists.arin.net/pipermail/arin-consult/2016-April/000722.html As the thread evolved it has been suggested that this issue should be resolved via the policy development process rather than through a suggestion. There are a number of questions that have been raised by this thread. I am copying them here to continue the discussion on PPML. === Working problem statement: ARIN will receive 2-byte ASNs as returns over time, and these ASNs have perceived or additional value to organizations compared to 4-byte ASNs. How should ARIN allocate these 2-byte ASNs? === Should they be given to the next requester, regardless of technical need for a 2-byte ASN? (What are the technical qualifications we should use if there is a specific technical need? e.g. provides transit to more than 1 ASN?) If there is really a technical need for 2-byte ASNs, shouldn't we attempt to build an inventory of 2-byte ASNs? Should returns be held in reserve? Should ARIN hold them for some period of time before reallocating them? Should they be put up for auction to qualified organizations? Should they be given to the 1st organization on a wait-list for 2-byte ASNs? Would an organization looking for a 2-byte ASN have the option to receive a 4-byte ASN in the interim? If they did would they have to return it? Should the waiting list be closed to organizations that already have a 2-byte ASNs? I and the AC would appreciate your comments on these questions so that we can start to build a draft policy that best matches with what the community would like to see implemented by ARIN. Thanks, Andrew PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ( ARIN-PPML at arin.net ). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ( ARIN-PPML at arin.net ). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues.
_______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From David_Huberman at outlook.com Tue Apr 5 00:50:18 2016 From: David_Huberman at outlook.com (David Huberman) Date: Tue, 5 Apr 2016 04:50:18 +0000 Subject: [arin-ppml] 2-byte ASN policy In-Reply-To: <1152879685.3161.1459821207700.JavaMail.mhammett@ThunderFuck> References: , <1152879685.3161.1459821207700.JavaMail.mhammett@ThunderFuck> Message-ID: Operators generally want to do the right thing. But at the same time, there's no real leverage over a paying customer who is breaking no laws and just never paid ARIN's bills and has out-of-date contact info. You can tell them to go talk to ARIN. But you can't disco them or turn off your BGP session. So whether it's an unregistered ASN or an ASN clearly marked "BAD! NO!", we generally find the ISP is unproductively stuck in the middle. ________________________________ From: arin-ppml-bounces at arin.net on behalf of Mike Hammett Sent: Monday, April 4, 2016 9:53 PM Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] 2-byte ASN policy Would operators take hijacking an ASN issued to someone more seriously than squatting on an ASN issued to no one? I'd assume no one cares about the risk to the squatter. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com [http://www.ics-il.com/images/fbicon.png][http://www.ics-il.com/images/googleicon.png][http://www.ics-il.com/images/linkedinicon.png][http://www.ics-il.com/images/twittericon.png] Midwest Internet Exchange http://www.midwest-ix.com [http://www.ics-il.com/images/fbicon.png][http://www.ics-il.com/images/linkedinicon.png][http://www.ics-il.com/images/twittericon.png] ________________________________ From: "David Huberman" To: arin-ppml at arin.net Sent: Monday, April 4, 2016 3:56:34 PM Subject: Re: [arin-ppml] 2-byte ASN policy Chris's excellent question jogs my brain to ask a related-but-different question: ARIN has traditionally had a large number of AS numbers (almost all 2-byte) in the "hold" bucket. These are ASNs which have been revoked for years due to non-payment and separation from the RSA. But they're still found in the DFZ. Can't ARIN ask requestors who say they need 2-bytes if they'd be willing to accept a 2-byte ASN that may have route announcements present in the DFZ, and due to circumstances blah blah blah? It boils down to "we have 2-byte ASNs, but they're not quite as clean as one might expect - is that ok?", because I'm pretty sure the answer will always be "HECK YEAH!" ASNs aren't quite like IP addresses in this context. There's no conflict I know of unless the new registrants tries to directly exchange routes with the old registrant, which is mathematically highly improbable. ________________________________ From: arin-ppml-bounces at arin.net on behalf of Chris Woodfield Sent: Monday, April 4, 2016 4:30 PM To: Adam Thompson Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] 2-byte ASN policy Do we have information on how many 2-byte ASNs get returned, compared to the rate of requests for them? Is there a surplus? On Apr 3, 2016, at 11:36 AM, Adam Thompson > wrote: IMO, 2-byte ASNs should simply be retired and not reallocated. "Solving the technical problem", as described in your email, is actually ensuring the perpetuation of a different technical problem. It's the same sort of thing as the IPv4 vs IPv6 --transition, but this time ARIN has an opportunity to at least avoid being part of the problem, even if it can't really be part of the "solution". Let's please not prolong this problem, too... even in central Canada, known for a paucity of upstream carriers, it's now commercially feasible to work around the 2-byte technical limitations. -Adam On April 3, 2016 12:59:37 PM CDT, Andrew Dul > wrote: Hello, I am starting a new thread in PPML, as a follow up to the ARIN suggestion and consultation which recently started regarding creating a 2-byte ASN waiting list. The original suggestion is here: https://www.arin.net/participate/acsp/suggestions/2016-04.html ARIN opened a consultation on this suggestion on the arin-consult mailing-list. This thread starts here for those who are not subscribed to arin-consult. http://lists.arin.net/pipermail/arin-consult/2016-March/000713.html http://lists.arin.net/pipermail/arin-consult/2016-April/000722.html As the thread evolved it has been suggested that this issue should be resolved via the policy development process rather than through a suggestion. There are a number of questions that have been raised by this thread. I am copying them here to continue the discussion on PPML. === Working problem statement: ARIN will receive 2-byte ASNs as returns over time, and these ASNs have perceived or additional value to organizations compared to 4-byte ASNs. How should ARIN allocate these 2-byte ASNs? === Should they be given to the next requester, regardless of technical need for a 2-byte ASN? (What are the technical qualifications we should use if there is a specific technical need? e.g. provides transit to more than 1 ASN?) If there is really a technical need for 2-byte ASNs, shouldn't we attempt to build an inventory of 2-byte ASNs? Should returns be held in reserve? Should ARIN hold them for some period of time before reallocating them? Should they be put up for auction to qualified organizations? Should they be given to the 1st organization on a wait-list for 2-byte ASNs? Would an organization looking for a 2-byte ASN have the option to receive a 4-byte ASN in the interim? If they did would they have to return it? Should the waiting list be closed to organizations that already have a 2-byte ASNs? I and the AC would appreciate your comments on these questions so that we can start to build a draft policy that best matches with what the community would like to see implemented by ARIN. Thanks, Andrew ________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sethm at rollernet.us Tue Apr 5 00:56:19 2016 From: sethm at rollernet.us (Seth Mattinen) Date: Mon, 4 Apr 2016 21:56:19 -0700 Subject: [arin-ppml] 2-byte ASN policy In-Reply-To: References: <1152879685.3161.1459821207700.JavaMail.mhammett@ThunderFuck> Message-ID: <57034573.707@rollernet.us> On 4/4/16 9:50 PM, David Huberman wrote: > > Operators generally want to do the right thing. But at the same time, > there's no real leverage over a paying customer who is breaking no laws > and just never paid ARIN's bills and has out-of-date contact info. You > can tell them to go talk to ARIN. But you can't disco them or turn off > your BGP session. So whether it's an unregistered ASN or an ASN clearly > marked "BAD! NO!", we generally find the ISP is unproductively stuck in > the middle. > If the ASN gets legitimately issued to someone else and the squatter proceeds to hijack it from the legitimate registrant they should be turned off if the ISP is going to do the right thing according to whois. ~Seth From farmer at umn.edu Tue Apr 5 01:43:30 2016 From: farmer at umn.edu (David Farmer) Date: Tue, 5 Apr 2016 00:43:30 -0500 Subject: [arin-ppml] 2-byte ASN policy In-Reply-To: <57034573.707@rollernet.us> References: <1152879685.3161.1459821207700.JavaMail.mhammett@ThunderFuck> <57034573.707@rollernet.us> Message-ID: On Mon, Apr 4, 2016 at 11:56 PM, Seth Mattinen wrote: > > If the ASN gets legitimately issued to someone else and the squatter > proceeds to hijack it from the legitimate registrant they should be turned > off if the ISP is going to do the right thing according to whois. > > ~Seth > If you forgot to pay your bill and ARIN reissues your ASN, it's a matter of perspective who the hijacker is. I'm not saying it's OK to not pay your bill, but how punitive should we be asking ARIN staff to be? Especially, if ARIN staff has every reason to believe the organization using the ASN is the original registrant? And if we the internet routing community are not will to be the bad guys and stop routing it after ARIN staff signals us by removing it from the registry. When what are we really expecting? We're not being very forthright, if we ask ARIN staff to break things that we the internet routing community are not will to break ourselves. Do we really need to recycle these ASN bad enough to cause intentional breakage? Then we need to stop using them in the internet routing system! -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Tue Apr 5 08:14:13 2016 From: jcurran at arin.net (John Curran) Date: Tue, 5 Apr 2016 12:14:13 +0000 Subject: [arin-ppml] 2-byte ASN policy In-Reply-To: References: <1152879685.3161.1459821207700.JavaMail.mhammett@ThunderFuck> <57034573.707@rollernet.us> Message-ID: <345976B4-DCB6-4F78-940D-2B835F544E79@corp.arin.net> On Apr 5, 2016, at 1:43 AM, David Farmer > wrote: On Mon, Apr 4, 2016 at 11:56 PM, Seth Mattinen > wrote: If the ASN gets legitimately issued to someone else and the squatter proceeds to hijack it from the legitimate registrant they should be turned off if the ISP is going to do the right thing according to whois. ~Seth If you forgot to pay your bill and ARIN reissues your ASN, it's a matter of perspective who the hijacker is. David - You may hold an interesting perspective in this area, but I must note that any misappropriation of rights (of the new resource holder) would actually be a simple matter of law. I'm not saying it's OK to not pay your bill, but how punitive should we be asking ARIN staff to be? Especially, if ARIN staff has every reason to believe the organization using the ASN is the original registrant? We already allow for recovery by the previous registrant (via reinstatement) if the resources have not yet been reissued. This is allowed even after multiple emails, calls, and formal notice that the resources are going to be revoked. (See https://www.arin.net/fees/reinstatement.html for specifics.) As someone who gets involved in panicked reinstatement situations, I highly recommend that folks maintain accurate contact information and pay their invoices. Ironically, consistent annual billing is one of the few effective mechanisms for maintaining accurate contact information in Whois, and folks should carefully consider the implications to long-term accuracy of the registry in any policy proposals that would alter the revocation portion of this process. And if we the internet routing community are not will to be the bad guys and stop routing it after ARIN staff signals us by removing it from the registry. When what are we really expecting? We're not being very forthright, if we ask ARIN staff to break things that we the internet routing community are not will to break ourselves. The difference may lie in the fact that ARIN will consistently follow community guidance (for better or worse ;-), whereas the operator community is not likely to be as consistent in its application of even commonly accepted norms and standards. Thanks, /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Tue Apr 5 18:23:41 2016 From: owen at delong.com (Owen DeLong) Date: Tue, 5 Apr 2016 15:23:41 -0700 Subject: [arin-ppml] 2-byte ASN policy In-Reply-To: References: <1152879685.3161.1459821207700.JavaMail.mhammett@ThunderFuck> <57034573.707@rollernet.us> Message-ID: <5E8801AE-D504-4539-A139-C8EDCC9F5478@delong.com> > On Apr 4, 2016, at 22:43 , David Farmer wrote: > > > On Mon, Apr 4, 2016 at 11:56 PM, Seth Mattinen > wrote: > > If the ASN gets legitimately issued to someone else and the squatter proceeds to hijack it from the legitimate registrant they should be turned off if the ISP is going to do the right thing according to whois. > > ~Seth > > If you forgot to pay your bill and ARIN reissues your ASN, it's a matter of perspective who the hijacker is. If you forgot to pay your bill _AND_ forgot to update your contact info _AND_ let that state of affairs remain so long that ARIN re-issued your resources to someone else, then I have little sympathy for you. I did, in fact, encounter a situation where an employer (actually a company acquired by said employer) had done just that and while I did my best to resolve it with ARIN we ultimately ended up ceding the space. (This was for IP Addresses, not an ASN, but still seems similar to me). > I'm not saying it's OK to not pay your bill, but how punitive should we be asking ARIN staff to be? Especially, if ARIN staff has every reason to believe the organization using the ASN is the original registrant? And if we the internet routing community are not will to be the bad guys and stop routing it after ARIN staff signals us by removing it from the registry. When what are we really expecting? If ARIN has reason to believe they are the original registrant, we should make an effort to contact and warn them. If their contacts are out of date, then I think we have no real basis for believing it to be the original organization and even if it is, they kind of made their own bed. I?ve found ARIN to be very helpful if you respond when they contact you or if you contact them while they still can do something about it. > We're not being very forthright, if we ask ARIN staff to break things that we the internet routing community are not will to break ourselves. We went through this with IPv4 addresses and it was made quite clear ahead of time that the timeframe for IPv4 hold-down was going to be reduced. Perhaps we should publish ASN hold-down times and then move forward accordingly? > Do we really need to recycle these ASN bad enough to cause intentional breakage? Then we need to stop using them in the internet routing system! Yes. I suspect there?s more of them being used for mischief than there are people who merely forgot to pay their bills. I am not necessarily in favor of continuing the 2-byte ASN mythos, but I am in favor of cleaning up the internet. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at tknow.com Wed Apr 6 10:48:56 2016 From: bill at tknow.com (Bill Buhler) Date: Wed, 6 Apr 2016 14:48:56 +0000 Subject: [arin-ppml] 2-byte ASN policy In-Reply-To: References: <1152879685.3161.1459821207700.JavaMail.mhammett@ThunderFuck> <57034573.707@rollernet.us> Message-ID: What about a policy including a grace period before reissue? For instance the FCC will not reissue a call sign for two years after validation. This allows the original licensee to correct the issue and come back into good grace. What if ARIN started handling resources in that manner? They could start by posting in arrears notice on the records when the bill is unreasonably past due. At one year they could list the record as revoked, and at two years reissue if the offending party hasn?t dealt with it? --Bill From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of David Farmer Sent: Monday, April 4, 2016 11:44 PM To: Seth Mattinen Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] 2-byte ASN policy On Mon, Apr 4, 2016 at 11:56 PM, Seth Mattinen > wrote: If the ASN gets legitimately issued to someone else and the squatter proceeds to hijack it from the legitimate registrant they should be turned off if the ISP is going to do the right thing according to whois. ~Seth If you forgot to pay your bill and ARIN reissues your ASN, it's a matter of perspective who the hijacker is. I'm not saying it's OK to not pay your bill, but how punitive should we be asking ARIN staff to be? Especially, if ARIN staff has every reason to believe the organization using the ASN is the original registrant? And if we the internet routing community are not will to be the bad guys and stop routing it after ARIN staff signals us by removing it from the registry. When what are we really expecting? We're not being very forthright, if we ask ARIN staff to break things that we the internet routing community are not will to break ourselves. Do we really need to recycle these ASN bad enough to cause intentional breakage? Then we need to stop using them in the internet routing system! -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Wed Apr 6 11:34:23 2016 From: jcurran at arin.net (John Curran) Date: Wed, 6 Apr 2016 15:34:23 +0000 Subject: [arin-ppml] 2-byte ASN policy In-Reply-To: References: <1152879685.3161.1459821207700.JavaMail.mhammett@ThunderFuck> <57034573.707@rollernet.us> Message-ID: <03ADDE02-4C9E-49AD-BD08-C30768543097@corp.arin.net> On Apr 6, 2016, at 10:48 AM, Bill Buhler > wrote: What about a policy including a grace period before reissue? For instance the FCC will not reissue a call sign for two years after validation. This allows the original licensee to correct the issue and come back into good grace. What if ARIN started handling resources in that manner? They could start by posting in arrears notice on the records when the bill is unreasonably past due. At one year they could list the record as revoked, and at two years reissue if the offending party hasn?t dealt with it? Bill - We present provide a grace period of 30 days even after revocation. Note that this period was shortened incrementally down to 30 days as IPv4 free pool depleted, and this allows for reasonably timely reuse of recovered address space for those who are on the waiting list. For IP address blocks, parties will often notice even before revocation because we suspend services (e.g. reverse DNS) at 120 days from past due (note that this is done after two collection emails, a certified collection letter, a final collection notice, direct calls to listed contacts, and letter of pending revocation have all already been sent at 30, 60, 75, 90, and 100 days past due?) The resources are then quarantined for 60 more days before actually initiating revocation. Once the quarantine expires (approximately 187 days from past due), the resources are finally revoked and placed into hold status for 30 days. Reinstatement during this 30 day hold ?grace? period is possible. If the community wishes to change the grace period, that can be suggested via the ARIN Consultation and Suggestion process . Alternatively, if there exists consensus in the community, then the grace period for each specific type of resource (IPv4, IPv6, and ASN32, ASN64) could be established by number resource policy. (We try to avoid creating number resource policy for operational matters, but it can be argued that the grace period has a direct affect on availability of number resources in some cases.) Thanks! /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From jrdelacruz at acm.org Wed Apr 6 13:36:17 2016 From: jrdelacruz at acm.org (Jose R. de la Cruz III) Date: Wed, 6 Apr 2016 13:36:17 -0400 Subject: [arin-ppml] 2-byte ASN policy In-Reply-To: <5E8801AE-D504-4539-A139-C8EDCC9F5478@delong.com> References: <1152879685.3161.1459821207700.JavaMail.mhammett@ThunderFuck> <57034573.707@rollernet.us> <5E8801AE-D504-4539-A139-C8EDCC9F5478@delong.com> Message-ID: I do agree with Owen in that every holder of resources is responsible for their timely bookkeeping. About the 2-byte ASN's, should they be recycled? Or should they just be retired? Jos? On Tue, Apr 5, 2016 at 6:23 PM, Owen DeLong wrote: > > On Apr 4, 2016, at 22:43 , David Farmer wrote: > > > On Mon, Apr 4, 2016 at 11:56 PM, Seth Mattinen wrote: > >> >> If the ASN gets legitimately issued to someone else and the squatter >> proceeds to hijack it from the legitimate registrant they should be turned >> off if the ISP is going to do the right thing according to whois. >> >> ~Seth >> > > If you forgot to pay your bill and ARIN reissues your ASN, it's a matter > of perspective who the hijacker is. > > > If you forgot to pay your bill _AND_ forgot to update your contact info > _AND_ let that state of affairs remain so long that ARIN re-issued your > resources to someone else, then I have little sympathy for you. > > I did, in fact, encounter a situation where an employer (actually a > company acquired by said employer) had done just that and while I did my > best to resolve it with ARIN we ultimately ended up ceding the space. (This > was for IP Addresses, not an ASN, but still seems similar to me). > > I'm not saying it's OK to not pay your bill, but how punitive should we be > asking ARIN staff to be? Especially, if ARIN staff has every reason to > believe the organization using the ASN is the original registrant? And if > we the internet routing community are not will to be the bad guys and stop > routing it after ARIN staff signals us by removing it from the registry. > When what are we really expecting? > > > If ARIN has reason to believe they are the original registrant, we should > make an effort to contact and warn them. If their contacts are out of date, > then I think we have no real basis for believing it to be the original > organization and even if it is, they kind of made their own bed. > > I?ve found ARIN to be very helpful if you respond when they contact you or > if you contact them while they still can do something about it. > > We're not being very forthright, if we ask ARIN staff to break things that > we the internet routing community are not will to break ourselves. > > > We went through this with IPv4 addresses and it was made quite clear ahead > of time that the timeframe for IPv4 hold-down was going to be reduced. > Perhaps we should publish ASN hold-down times and then move forward > accordingly? > > Do we really need to recycle these ASN bad enough to cause intentional > breakage? Then we need to stop using them in the internet routing system! > > > Yes. I suspect there?s more of them being used for mischief than there are > people who merely forgot to pay their bills. > > I am not necessarily in favor of continuing the 2-byte ASN mythos, but I > am in favor of cleaning up the internet. > > Owen > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at tknow.com Wed Apr 6 16:17:57 2016 From: bill at tknow.com (Bill Buhler) Date: Wed, 6 Apr 2016 20:17:57 +0000 Subject: [arin-ppml] 2-byte ASN policy In-Reply-To: <03ADDE02-4C9E-49AD-BD08-C30768543097@corp.arin.net> References: <1152879685.3161.1459821207700.JavaMail.mhammett@ThunderFuck> <57034573.707@rollernet.us> <03ADDE02-4C9E-49AD-BD08-C30768543097@corp.arin.net> Message-ID: <27644b16ede8441795352480ce27abb7@TK-Ex13.ad.tknow.com> Thanks for the clarification John, So I understand you, regarding IPv4 you are recycling the deadbeat resources already. My impression though is that you aren?t doing the same with 2-byte ASN? I think it would be good policy to begin reclamation of those resources. I was very grateful a few years ago to be able to get a 2-byte ASN because one of my two upstreams stated they weren?t able to handle a 4 byte ASN, I hope they have corrected that by now. But I understand being stuck between the old and new and it?s nice if there are resources for those edge cases. Best regards, Bill From: John Curran [mailto:jcurran at arin.net] Sent: Wednesday, April 6, 2016 9:34 AM To: Bill Buhler Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] 2-byte ASN policy On Apr 6, 2016, at 10:48 AM, Bill Buhler > wrote: What about a policy including a grace period before reissue? For instance the FCC will not reissue a call sign for two years after validation. This allows the original licensee to correct the issue and come back into good grace. What if ARIN started handling resources in that manner? They could start by posting in arrears notice on the records when the bill is unreasonably past due. At one year they could list the record as revoked, and at two years reissue if the offending party hasn?t dealt with it? Bill - We present provide a grace period of 30 days even after revocation. Note that this period was shortened incrementally down to 30 days as IPv4 free pool depleted, and this allows for reasonably timely reuse of recovered address space for those who are on the waiting list. For IP address blocks, parties will often notice even before revocation because we suspend services (e.g. reverse DNS) at 120 days from past due (note that this is done after two collection emails, a certified collection letter, a final collection notice, direct calls to listed contacts, and letter of pending revocation have all already been sent at 30, 60, 75, 90, and 100 days past due?) The resources are then quarantined for 60 more days before actually initiating revocation. Once the quarantine expires (approximately 187 days from past due), the resources are finally revoked and placed into hold status for 30 days. Reinstatement during this 30 day hold ?grace? period is possible. If the community wishes to change the grace period, that can be suggested via the ARIN Consultation and Suggestion process . Alternatively, if there exists consensus in the community, then the grace period for each specific type of resource (IPv4, IPv6, and ASN32, ASN64) could be established by number resource policy. (We try to avoid creating number resource policy for operational matters, but it can be argued that the grace period has a direct affect on availability of number resources in some cases.) Thanks! /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Wed Apr 6 19:24:19 2016 From: jcurran at arin.net (John Curran) Date: Wed, 6 Apr 2016 23:24:19 +0000 Subject: [arin-ppml] 2-byte ASN policy In-Reply-To: <27644b16ede8441795352480ce27abb7@TK-Ex13.ad.tknow.com> References: <1152879685.3161.1459821207700.JavaMail.mhammett@ThunderFuck> <57034573.707@rollernet.us> <03ADDE02-4C9E-49AD-BD08-C30768543097@corp.arin.net> <27644b16ede8441795352480ce27abb7@TK-Ex13.ad.tknow.com> Message-ID: <6C85C405-C68D-40A2-BAF5-82A9FF293C64@arin.net> On Apr 6, 2016, at 4:17 PM, Bill Buhler wrote: > > Thanks for the clarification John, > > So I understand you, regarding IPv4 you are recycling the deadbeat resources already. > > My impression though is that you aren?t doing the same with 2-byte ASN? I think it would be good policy to begin reclamation of those resources. We are recycling ASN?s that are returned - after the hold period we confirm that they?re not in active routing and then will reissue if someone makes an explicit request for a 2-byte ASN. > I was very grateful a few years ago to be able to get a 2-byte ASN because one of my two upstreams stated they weren?t able to handle a 4 byte ASN, I hope they have corrected that by now. But I understand being stuck between the old and new and it?s nice if there are resources for those edge cases. Understood. Thanks! /John John Curran President and CEO ARIN From chris at semihuman.com Wed Apr 6 19:47:15 2016 From: chris at semihuman.com (Chris Woodfield) Date: Wed, 6 Apr 2016 16:47:15 -0700 Subject: [arin-ppml] 2-byte ASN policy In-Reply-To: <6C85C405-C68D-40A2-BAF5-82A9FF293C64@arin.net> References: <1152879685.3161.1459821207700.JavaMail.mhammett@ThunderFuck> <57034573.707@rollernet.us> <03ADDE02-4C9E-49AD-BD08-C30768543097@corp.arin.net> <27644b16ede8441795352480ce27abb7@TK-Ex13.ad.tknow.com> <6C85C405-C68D-40A2-BAF5-82A9FF293C64@arin.net> Message-ID: <46A9C830-552E-4EDE-8A17-3FFA556C81E7@semihuman.com> To an earlier question is the rate of returns higher/lower than the rate of requests? Do we anticipate a backlog/waiting list here? -C > On Apr 6, 2016, at 4:24 PM, John Curran wrote: > > On Apr 6, 2016, at 4:17 PM, Bill Buhler wrote: >> >> Thanks for the clarification John, >> >> So I understand you, regarding IPv4 you are recycling the deadbeat resources already. >> >> My impression though is that you aren?t doing the same with 2-byte ASN? I think it would be good policy to begin reclamation of those resources. > > We are recycling ASN?s that are returned - after the hold period we confirm that > they?re not in active routing and then will reissue if someone makes an explicit > request for a 2-byte ASN. > >> I was very grateful a few years ago to be able to get a 2-byte ASN because one of my two upstreams stated they weren?t able to handle a 4 byte ASN, I hope they have corrected that by now. But I understand being stuck between the old and new and it?s nice if there are resources for those edge cases. > > Understood. > > Thanks! > /John > > John Curran > President and CEO > ARIN > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From andrew.dul at quark.net Wed Apr 6 20:26:40 2016 From: andrew.dul at quark.net (Andrew Dul) Date: Wed, 6 Apr 2016 17:26:40 -0700 Subject: [arin-ppml] Draft Policy ARIN-2016-1: Reserved Pool Transfer Policy In-Reply-To: <56F178F9.7020608@arin.net> References: <56F178F9.7020608@arin.net> Message-ID: <5705A940.2070209@quark.net> Hello, The AC would appreciate your feedback on this new draft policy. This draft grew out of a conversation at the San Diego NANOG meeting where it was noted that current policy allows the transfer of IPv4 addresses which are issued to critical infrastructure or as IPv6 transition space. It was suggested by the authors that this was not intended and that there are negative consequences of allowing these transfers to occur. Do you support this draft policy? If not, are there changes that could be made that would allow you to support it. Thanks, Andrew On 3/22/2016 9:55 AM, ARIN wrote: > > > ## * ## > > > Draft Policy ARIN-2016-1 > Reserved Pool Transfer Policy > > Date: 22 March 2016 > > Problem Statement: > > Section 8 of the current NRPM does not distinguish between the > transfer of blocks from addresses that have been reserved for specific > uses and other addresses that can be transferred. In sections 4.4 and > 4.10 there are specific address blocks set aside, based on the need > for critical infrastructure and IPv6 transitions. Two issues arise if > transfers of reserved address space occur under the current language > of section 8. First, if transfers of 4.4 or 4.10 space occur under the > current policy requirements set forth in sections 8.3 and 8.4, the > recipients will be able to acquire space that was originally reserved > for a specific purpose without ever providing evidence that they will > be using the space for either critical infrastructure or IPv6 > transition. Second, if we allow an allocation or assignment from the > block reserved in section 4.10 to be transferred out of the region, it > would complicate the single aggregate from which providers are being > asked to allow in block sizes smaller than a /24. This policy would > limit the transfer of addresses from reserved pools. > > Policy statement: > > Add to Section 8.3 and Section 8.4 under the "Conditions on source of > the transfer:" > > Address resources from a reserved pool (including those designated in > Section 4.4 and 4.10) are not eligible for transfer. > > Timetable for implementation: Immediate > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From scottleibrand at gmail.com Wed Apr 6 20:46:54 2016 From: scottleibrand at gmail.com (Scott Leibrand) Date: Wed, 6 Apr 2016 17:46:54 -0700 Subject: [arin-ppml] 2-byte ASN policy In-Reply-To: <6C85C405-C68D-40A2-BAF5-82A9FF293C64@arin.net> References: <1152879685.3161.1459821207700.JavaMail.mhammett@ThunderFuck> <57034573.707@rollernet.us> <03ADDE02-4C9E-49AD-BD08-C30768543097@corp.arin.net> <27644b16ede8441795352480ce27abb7@TK-Ex13.ad.tknow.com> <6C85C405-C68D-40A2-BAF5-82A9FF293C64@arin.net> Message-ID: On Wed, Apr 6, 2016 at 4:24 PM, John Curran wrote: > On Apr 6, 2016, at 4:17 PM, Bill Buhler wrote: > > > > Thanks for the clarification John, > > > > So I understand you, regarding IPv4 you are recycling the deadbeat > resources already. > > > > My impression though is that you aren?t doing the same with 2-byte ASN? > I think it would be good policy to begin reclamation of those resources. > > We are recycling ASN?s that are returned - after the hold period we > confirm that > they?re not in active routing and then will reissue if someone makes an > explicit > request for a 2-byte ASN. > If a 2-byte ASN comes available and no one immediately requests an explicit 2-byte ASN, will you reissue the 2-byte ASN to the next non-explicit ASN requester (who presumably would be just as happy with a 4-byte ASN), or do you keep the 2-byte ASN in inventory until the next explicit 2-byte ASN request? -Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From sethm at rollernet.us Wed Apr 6 22:06:16 2016 From: sethm at rollernet.us (Seth Mattinen) Date: Wed, 6 Apr 2016 19:06:16 -0700 Subject: [arin-ppml] Draft Policy ARIN-2016-1: Reserved Pool Transfer Policy In-Reply-To: <56F178F9.7020608@arin.net> References: <56F178F9.7020608@arin.net> Message-ID: <5705C098.6030500@rollernet.us> On 3/22/16 09:55, ARIN wrote: > Problem Statement: > > Section 8 of the current NRPM does not distinguish between the transfer > of blocks from addresses that have been reserved for specific uses and > other addresses that can be transferred. In sections 4.4 and 4.10 there > are specific address blocks set aside, based on the need for critical > infrastructure and IPv6 transitions. Two issues arise if transfers of > reserved address space occur under the current language of section 8. > First, if transfers of 4.4 or 4.10 space occur under the current policy > requirements set forth in sections 8.3 and 8.4, the recipients will be > able to acquire space that was originally reserved for a specific > purpose without ever providing evidence that they will be using the > space for either critical infrastructure or IPv6 transition. Second, if > we allow an allocation or assignment from the block reserved in section > 4.10 to be transferred out of the region, it would complicate the single > aggregate from which providers are being asked to allow in block sizes > smaller than a /24. This policy would limit the transfer of addresses > from reserved pools. > > Policy statement: > > Add to Section 8.3 and Section 8.4 under the "Conditions on source of > the transfer:" > > Address resources from a reserved pool (including those designated in > Section 4.4 and 4.10) are not eligible for transfer. I support this policy. ~Seth From gary.buhrmaster at gmail.com Wed Apr 6 23:11:14 2016 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Thu, 7 Apr 2016 03:11:14 +0000 Subject: [arin-ppml] Draft Policy ARIN-2016-1: Reserved Pool Transfer Policy In-Reply-To: <56F178F9.7020608@arin.net> References: <56F178F9.7020608@arin.net> Message-ID: On Tue, Mar 22, 2016 at 4:55 PM, ARIN wrote: .... > Policy statement: > > Add to Section 8.3 and Section 8.4 under the "Conditions on source of the > transfer:" > > Address resources from a reserved pool (including those designated in > Section 4.4 and 4.10) are not eligible for transfer. I am in favor of the intent, although I would have (at first thought) expected that the "resources transferred will be subject to ARIN policies" would have resulted in a review of the recipients planned usage. However, given the possible interpretations (which historically any ambiguity goes in favor of the requester), I can see that some improvements might be valuable. However, I would suggest that the proposed language be modified to allow for a transfer if the recipient would otherwise meet the requirements that could be used to approve the resources from the reserved block. What about something like: "Recipients of resources from a reserved pool .... must demonstrate that the recipient would qualify for those resources under existing policy, and the resources may not be transferred out of region". From scottleibrand at gmail.com Thu Apr 7 01:06:25 2016 From: scottleibrand at gmail.com (Scott Leibrand) Date: Wed, 6 Apr 2016 22:06:25 -0700 Subject: [arin-ppml] Draft Policy ARIN-2016-1: Reserved Pool Transfer Policy In-Reply-To: References: <56F178F9.7020608@arin.net> Message-ID: > On Apr 6, 2016, at 8:11 PM, Gary Buhrmaster wrote: > >> On Tue, Mar 22, 2016 at 4:55 PM, ARIN wrote: >> .... >> Policy statement: >> >> Add to Section 8.3 and Section 8.4 under the "Conditions on source of the >> transfer:" >> >> Address resources from a reserved pool (including those designated in >> Section 4.4 and 4.10) are not eligible for transfer. > > I am in favor of the intent, although I would have > (at first thought) expected that the "resources > transferred will be subject to ARIN policies" > would have resulted in a review of the recipients > planned usage. However, given the possible > interpretations (which historically any ambiguity > goes in favor of the requester), I can see that > some improvements might be valuable. However, > I would suggest that the proposed language be > modified to allow for a transfer if the recipient > would otherwise meet the requirements that could > be used to approve the resources from the reserved > block. > > What about something like: > > "Recipients of resources from a reserved pool .... > must demonstrate that the recipient would > qualify for those resources under existing policy, > and the resources may not be transferred out > of region". I like this approach better than the originally proposed text. To prevent ambiguity around which existing policy applies, perhaps: > "Recipients of resources from a reserved pool .... > must demonstrate that the recipient would > qualify for those resources under the policy criteria for that reserved pool. Resources from such reserved pools are not eligible for inter-RIR transfer." -Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From arin at ics-il.net Thu Apr 7 08:36:54 2016 From: arin at ics-il.net (Mike Hammett) Date: Thu, 7 Apr 2016 07:36:54 -0500 (CDT) Subject: [arin-ppml] 2-byte ASN policy In-Reply-To: Message-ID: <1116956735.6304.1460032613832.JavaMail.mhammett@ThunderFuck> I believe both times I requested an ASN last year (my IX and my ISP) they asked if I wanted a 2 byte or a 4 byte. For the IX, I chose 2 and for my ISP I chose 4. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest Internet Exchange http://www.midwest-ix.com ----- Original Message ----- From: "Scott Leibrand" To: "John Curran" Cc: arin-ppml at arin.net Sent: Wednesday, April 6, 2016 7:46:54 PM Subject: Re: [arin-ppml] 2-byte ASN policy On Wed, Apr 6, 2016 at 4:24 PM, John Curran < jcurran at arin.net > wrote: On Apr 6, 2016, at 4:17 PM, Bill Buhler < bill at tknow.com > wrote: > > Thanks for the clarification John, > > So I understand you, regarding IPv4 you are recycling the deadbeat resources already. > > My impression though is that you aren?t doing the same with 2-byte ASN? I think it would be good policy to begin reclamation of those resources. We are recycling ASN?s that are returned - after the hold period we confirm that they?re not in active routing and then will reissue if someone makes an explicit request for a 2-byte ASN. If a 2-byte ASN comes available and no one immediately requests an explicit 2-byte ASN, will you reissue the 2-byte ASN to the next non-explicit ASN requester (who presumably would be just as happy with a 4-byte ASN), or do you keep the 2-byte ASN in inventory until the next explicit 2-byte ASN request? -Scott _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Thu Apr 7 14:44:05 2016 From: jcurran at arin.net (John Curran) Date: Thu, 7 Apr 2016 18:44:05 +0000 Subject: [arin-ppml] ARIN 2-Byte ASN inventory and issuance (was: Re: 2-byte ASN policy) In-Reply-To: <57015A09.2030901@quark.net> References: <57015A09.2030901@quark.net> Message-ID: Folks - Please forgive this omnibus email of information, but we've had sufficient individual questions for 2-byte ASN data that it simply made more sense to provide one full summary rather than reply to each question individually... ARIN continues to have classic, 2-byte, AS numbers in inventory. Over the last few years, we have received small blocks of them in our new delegations from the IANA, obtained them from customer returns of AS numbers, or through revocations of AS numbers due to non-payment of registration fees. Our last AS block delegation from IANA was on 29 April 2015. We received 99 2-byte ASNs and 925 4-byte ASNs at that time, and do not expect to receive any additional 2-byte ASNs from the IANA in future delegations. The 2-byte ASNs received from the IANA in 2015 were added to the inventory and placed on hold. The reason that the 2-byte ASNs were put on hold is that was not responsible to issue from the dwindling quantity of these resources to parties that did not specifically request such while we were still receiving AS number requests specifically asking for 2-byte AS numbers. As of today, we currently have the following 2-byte ASNs in ARIN inventory: 387 2-byte AS numbers on hold (most were routed at some point) 535 2-byte AS numbers revoked 133 2-byte AS numbers returned = 1,055 2-byte AS numbers returned/revoked/held (Total) Customers requesting ASNs receive a 4-byte ASN by default. If a request comes in that specifically requests a 2-byte ASN, we inform the customer that we have noted their special request and that we will accommodate it at the issuance phase of the ticket process if we have 2-byte ASN available at that time. Rate of issuance for 2-byte ASNs per month - 1/2015: 68 2/2015: 77 3/2015: 74 4/2015: 60 5/2015: 7 6/2015: 12 7/2015: 16 8/2015: 4 9/2015: 7 10/2015: 11 11/2015: 7 12/2015: 11 1/2016: 5 2/2016: 6 3/2016: 13 A waiting list will only be applicable after depletion of the present 2-byte ASN inventory, hence the following general run-out estimates are provided for consideration: - If we release all of the 2-byte ASNs from hold and issue ASNs strictly from smallest to largest, i.e. the practice prior to May 2015, it is likely that the current inventory of 2-byte ASN?s would last somewhere between 6 to 12 months. - If we continue the current approach (wherein 4-byte ASNs are issued by default and 2-byte ASNs are only issued upon special request), the current inventory of 2-byte ASNs would appear to last for many years (5+ years at present rate). I hope the above information helps in your policy development efforts! Thank you, /John John Curran President and CEO American Registry for Internet Numbers (ARIN) From scottleibrand at gmail.com Thu Apr 7 15:24:38 2016 From: scottleibrand at gmail.com (Scott Leibrand) Date: Thu, 7 Apr 2016 12:24:38 -0700 Subject: [arin-ppml] ARIN 2-Byte ASN inventory and issuance (was: Re: 2-byte ASN policy) In-Reply-To: References: <57015A09.2030901@quark.net> Message-ID: Thanks, John. It sounds to me like ARIN is already doing the right thing (saving 2-byte ASNs for people who specifically want them), and that is sufficient for the time being. It does not appear that additional restrictions on who may request a 2-byte ASN are necessary at this time. If at some point 5+ years down the road the rate of 2-byte ASN demand starts to exceed the recovered supply and the 2-byte ASN inventory is depleted, we can consider a waiting list and/or technical requirements for requesting a 2-byte ASN at that time. Is there any other reason we need to consider taking action sooner? Was there something else I'm missing that prompted ARIN staff to start the consultation process around a 2-byte ASN waiting list? -Scott On Thu, Apr 7, 2016 at 11:44 AM, John Curran wrote: > Folks - > > Please forgive this omnibus email of information, but we've had sufficient > individual > questions for 2-byte ASN data that it simply made more sense to provide > one full > summary rather than reply to each question individually... > > ARIN continues to have classic, 2-byte, AS numbers in inventory. Over the > last few > years, we have received small blocks of them in our new delegations from > the IANA, > obtained them from customer returns of AS numbers, or through revocations > of AS > numbers due to non-payment of registration fees. > > Our last AS block delegation from IANA was on 29 April 2015. We received > 99 2-byte > ASNs and 925 4-byte ASNs at that time, and do not expect to receive any > additional > 2-byte ASNs from the IANA in future delegations. The 2-byte ASNs received > from the > IANA in 2015 were added to the inventory and placed on hold. The reason > that the > 2-byte ASNs were put on hold is that was not responsible to issue from the > dwindling > quantity of these resources to parties that did not specifically request > such while we > were still receiving AS number requests specifically asking for 2-byte AS > numbers. > > As of today, we currently have the following 2-byte ASNs in ARIN inventory: > > 387 2-byte AS numbers on hold (most were routed at some point) > 535 2-byte AS numbers revoked > 133 2-byte AS numbers returned > > = 1,055 2-byte AS numbers returned/revoked/held (Total) > > Customers requesting ASNs receive a 4-byte ASN by default. If a request > comes in > that specifically requests a 2-byte ASN, we inform the customer that we > have noted > their special request and that we will accommodate it at the issuance > phase of the > ticket process if we have 2-byte ASN available at that time. > > Rate of issuance for 2-byte ASNs per month - > > 1/2015: 68 > 2/2015: 77 > 3/2015: 74 > 4/2015: 60 > 5/2015: 7 > 6/2015: 12 > 7/2015: 16 > 8/2015: 4 > 9/2015: 7 > 10/2015: 11 > 11/2015: 7 > 12/2015: 11 > 1/2016: 5 > 2/2016: 6 > 3/2016: 13 > > A waiting list will only be applicable after depletion of the present > 2-byte ASN inventory, > hence the following general run-out estimates are provided for > consideration: > > - If we release all of the 2-byte ASNs from hold and issue ASNs > strictly from smallest > to largest, i.e. the practice prior to May 2015, it is likely that > the current inventory of > 2-byte ASN?s would last somewhere between 6 to 12 months. > > - If we continue the current approach (wherein 4-byte ASNs are issued > by default and > 2-byte ASNs are only issued upon special request), the current > inventory of 2-byte > ASNs would appear to last for many years (5+ years at present rate). > > I hope the above information helps in your policy development efforts! > > Thank you, > /John > > John Curran > President and CEO > American Registry for Internet Numbers (ARIN) > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Thu Apr 7 15:36:27 2016 From: jcurran at arin.net (John Curran) Date: Thu, 7 Apr 2016 19:36:27 +0000 Subject: [arin-ppml] ARIN 2-Byte ASN inventory and issuance (was: Re: 2-byte ASN policy) In-Reply-To: References: <57015A09.2030901@quark.net> Message-ID: > On Apr 7, 2016, at 3:24 PM, Scott Leibrand wrote: > > Thanks, John. > > It sounds to me like ARIN is already doing the right thing (saving 2-byte ASNs for people who specifically want them), and that is sufficient for the time being. It does not appear that additional restrictions on who may request a 2-byte ASN are necessary at this time. If at some point 5+ years down the road the rate of 2-byte ASN demand starts to exceed the recovered supply and the 2-byte ASN inventory is depleted, we can consider a waiting list and/or technical requirements for requesting a 2-byte ASN at that time. > > Is there any other reason we need to consider taking action sooner? Was there something else I'm missing that prompted ARIN staff to start the consultation process around a 2-byte ASN waiting list? It was unclear if the present 2-byte AS number inventory would last sufficiently long (i.e. past the point of operational impact) to avoid the need for a wait-list. Having now reviewed the data, the need for wait-list is at present trajectory is likely 5 years out. It is up to the community whether it is worth working now to address the potential situation that may occur at that time. Thanks! /John From narten at us.ibm.com Fri Apr 8 00:53:03 2016 From: narten at us.ibm.com (narten at us.ibm.com) Date: Fri, 08 Apr 2016 00:53:03 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201604080453.u384r3nI024816@rotala.raleigh.ibm.com> Total of 41 messages in the last 7 days. script run at: Fri Apr 8 00:53:02 EDT 2016 Messages | Bytes | Who --------+------+--------+----------+------------------------ 14.63% | 6 | 11.83% | 63433 | jcurran at arin.net 9.76% | 4 | 13.91% | 74612 | david_huberman at outlook.com 7.32% | 3 | 9.19% | 49293 | farmer at umn.edu 7.32% | 3 | 7.11% | 38159 | scottleibrand at gmail.com 4.88% | 2 | 9.26% | 49663 | arin at ics-il.net 4.88% | 2 | 7.77% | 41650 | bill at tknow.com 4.88% | 2 | 6.85% | 36740 | owen at delong.com 4.88% | 2 | 6.06% | 32487 | athompso at athompso.net 4.88% | 2 | 4.82% | 25873 | rgrant at skywaywest.com 4.88% | 2 | 4.38% | 23494 | chris at semihuman.com 4.88% | 2 | 3.09% | 16590 | andrew.dul at quark.net 4.88% | 2 | 2.70% | 14486 | michel at arneill-py.sacramento.ca.us 4.88% | 2 | 2.43% | 13008 | sethm at rollernet.us 4.88% | 2 | 2.23% | 11934 | job at ntt.net 2.44% | 1 | 2.93% | 15706 | jrdelacruz at acm.org 2.44% | 1 | 1.43% | 7657 | jlewis at lewis.org 2.44% | 1 | 1.43% | 7646 | info at arin.net 2.44% | 1 | 1.36% | 7319 | gary.buhrmaster at gmail.com 2.44% | 1 | 1.23% | 6593 | narten at us.ibm.com --------+------+--------+----------+------------------------ 100.00% | 41 |100.00% | 536343 | Total From andrew.dul at quark.net Fri Apr 8 12:06:37 2016 From: andrew.dul at quark.net (Andrew Dul) Date: Fri, 8 Apr 2016 09:06:37 -0700 Subject: [arin-ppml] ARIN 2-Byte ASN inventory and issuance In-Reply-To: References: <57015A09.2030901@quark.net> Message-ID: <5707D70D.2040805@quark.net> Do other members of the ARIN community believe that the current policy and operational practice is sufficient for now, or are there policy changes needed at this time? Thanks, Andrew On 4/7/2016 12:24 PM, Scott Leibrand wrote: > Thanks, John. > > It sounds to me like ARIN is already doing the right thing (saving > 2-byte ASNs for people who specifically want them), and that is > sufficient for the time being. It does not appear that additional > restrictions on who may request a 2-byte ASN are necessary at this > time. If at some point 5+ years down the road the rate of 2-byte ASN > demand starts to exceed the recovered supply and the 2-byte ASN > inventory is depleted, we can consider a waiting list and/or technical > requirements for requesting a 2-byte ASN at that time. > > Is there any other reason we need to consider taking action sooner? > Was there something else I'm missing that prompted ARIN staff to start > the consultation process around a 2-byte ASN waiting list? > > -Scott > > On Thu, Apr 7, 2016 at 11:44 AM, John Curran > wrote: > > Folks - > > Please forgive this omnibus email of information, but we've had > sufficient individual > questions for 2-byte ASN data that it simply made more sense to > provide one full > summary rather than reply to each question individually... > > ARIN continues to have classic, 2-byte, AS numbers in inventory. > Over the last few > years, we have received small blocks of them in our new > delegations from the IANA, > obtained them from customer returns of AS numbers, or through > revocations of AS > numbers due to non-payment of registration fees. > > Our last AS block delegation from IANA was on 29 April 2015. We > received 99 2-byte > ASNs and 925 4-byte ASNs at that time, and do not expect to > receive any additional > 2-byte ASNs from the IANA in future delegations. The 2-byte ASNs > received from the > IANA in 2015 were added to the inventory and placed on hold. The > reason that the > 2-byte ASNs were put on hold is that was not responsible to issue > from the dwindling > quantity of these resources to parties that did not specifically > request such while we > were still receiving AS number requests specifically asking for > 2-byte AS numbers. > > As of today, we currently have the following 2-byte ASNs in ARIN > inventory: > > 387 2-byte AS numbers on hold (most were routed at some point) > 535 2-byte AS numbers revoked > 133 2-byte AS numbers returned > > = 1,055 2-byte AS numbers returned/revoked/held (Total) > > Customers requesting ASNs receive a 4-byte ASN by default. If a > request comes in > that specifically requests a 2-byte ASN, we inform the customer > that we have noted > their special request and that we will accommodate it at the > issuance phase of the > ticket process if we have 2-byte ASN available at that time. > > Rate of issuance for 2-byte ASNs per month - > > 1/2015: 68 > 2/2015: 77 > 3/2015: 74 > 4/2015: 60 > 5/2015: 7 > 6/2015: 12 > 7/2015: 16 > 8/2015: 4 > 9/2015: 7 > 10/2015: 11 > 11/2015: 7 > 12/2015: 11 > 1/2016: 5 > 2/2016: 6 > 3/2016: 13 > > A waiting list will only be applicable after depletion of the > present 2-byte ASN inventory, > hence the following general run-out estimates are provided for > consideration: > > - If we release all of the 2-byte ASNs from hold and issue ASNs > strictly from smallest > to largest, i.e. the practice prior to May 2015, it is likely > that the current inventory of > 2-byte ASN?s would last somewhere between 6 to 12 months. > > - If we continue the current approach (wherein 4-byte ASNs are > issued by default and > 2-byte ASNs are only issued upon special request), the > current inventory of 2-byte > ASNs would appear to last for many years (5+ years at present > rate). > > I hope the above information helps in your policy development efforts! > > Thank you, > /John > > John Curran > President and CEO > American Registry for Internet Numbers (ARIN) > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net > ). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you > experience any issues. > > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From milton at gatech.edu Fri Apr 8 16:02:38 2016 From: milton at gatech.edu (Mueller, Milton L) Date: Fri, 8 Apr 2016 20:02:38 +0000 Subject: [arin-ppml] ARIN 2-Byte ASN inventory and issuance In-Reply-To: <5707D70D.2040805@quark.net> References: <57015A09.2030901@quark.net> <5707D70D.2040805@quark.net> Message-ID: Andrew: I lean toward sticking with the status quo until there is more evidence of a problem. 5 years is a reasonably comfortable time frame. If there's an inflection that alters John's projected trajectory I think we can act then. I was especially concerned about the potential subjectivity or variability of the definitions of "technical need" that were flying about, although the definitions focused on critical infrastructure seemed more solid and possibly acceptable. --MM From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Andrew Dul Sent: Friday, April 8, 2016 12:07 PM To: arin-ppml at arin.net Subject: Re: [arin-ppml] ARIN 2-Byte ASN inventory and issuance Do other members of the ARIN community believe that the current policy and operational practice is sufficient for now, or are there policy changes needed at this time? Thanks, Andrew On 4/7/2016 12:24 PM, Scott Leibrand wrote: Thanks, John. It sounds to me like ARIN is already doing the right thing (saving 2-byte ASNs for people who specifically want them), and that is sufficient for the time being. It does not appear that additional restrictions on who may request a 2-byte ASN are necessary at this time. If at some point 5+ years down the road the rate of 2-byte ASN demand starts to exceed the recovered supply and the 2-byte ASN inventory is depleted, we can consider a waiting list and/or technical requirements for requesting a 2-byte ASN at that time. Is there any other reason we need to consider taking action sooner? Was there something else I'm missing that prompted ARIN staff to start the consultation process around a 2-byte ASN waiting list? -Scott On Thu, Apr 7, 2016 at 11:44 AM, John Curran > wrote: Folks - Please forgive this omnibus email of information, but we've had sufficient individual questions for 2-byte ASN data that it simply made more sense to provide one full summary rather than reply to each question individually... ARIN continues to have classic, 2-byte, AS numbers in inventory. Over the last few years, we have received small blocks of them in our new delegations from the IANA, obtained them from customer returns of AS numbers, or through revocations of AS numbers due to non-payment of registration fees. Our last AS block delegation from IANA was on 29 April 2015. We received 99 2-byte ASNs and 925 4-byte ASNs at that time, and do not expect to receive any additional 2-byte ASNs from the IANA in future delegations. The 2-byte ASNs received from the IANA in 2015 were added to the inventory and placed on hold. The reason that the 2-byte ASNs were put on hold is that was not responsible to issue from the dwindling quantity of these resources to parties that did not specifically request such while we were still receiving AS number requests specifically asking for 2-byte AS numbers. As of today, we currently have the following 2-byte ASNs in ARIN inventory: 387 2-byte AS numbers on hold (most were routed at some point) 535 2-byte AS numbers revoked 133 2-byte AS numbers returned = 1,055 2-byte AS numbers returned/revoked/held (Total) Customers requesting ASNs receive a 4-byte ASN by default. If a request comes in that specifically requests a 2-byte ASN, we inform the customer that we have noted their special request and that we will accommodate it at the issuance phase of the ticket process if we have 2-byte ASN available at that time. Rate of issuance for 2-byte ASNs per month - 1/2015: 68 2/2015: 77 3/2015: 74 4/2015: 60 5/2015: 7 6/2015: 12 7/2015: 16 8/2015: 4 9/2015: 7 10/2015: 11 11/2015: 7 12/2015: 11 1/2016: 5 2/2016: 6 3/2016: 13 A waiting list will only be applicable after depletion of the present 2-byte ASN inventory, hence the following general run-out estimates are provided for consideration: - If we release all of the 2-byte ASNs from hold and issue ASNs strictly from smallest to largest, i.e. the practice prior to May 2015, it is likely that the current inventory of 2-byte ASN's would last somewhere between 6 to 12 months. - If we continue the current approach (wherein 4-byte ASNs are issued by default and 2-byte ASNs are only issued upon special request), the current inventory of 2-byte ASNs would appear to last for many years (5+ years at present rate). I hope the above information helps in your policy development efforts! Thank you, /John John Curran President and CEO American Registry for Internet Numbers (ARIN) _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From david_huberman at outlook.com Fri Apr 8 16:13:30 2016 From: david_huberman at outlook.com (David Huberman) Date: Fri, 8 Apr 2016 20:13:30 +0000 Subject: [arin-ppml] ARIN 2-Byte ASN inventory and issuance In-Reply-To: References: <57015A09.2030901@quark.net> <5707D70D.2040805@quark.net>, Message-ID: I am strongly in favor of leaving things be. 900+ 2-byte ASNs in inventory means anyone who truly needs one can get one - for quite a long time. On Apr 8, 2016, at 4:03 PM, Mueller, Milton L > wrote: Andrew: I lean toward sticking with the status quo until there is more evidence of a problem. 5 years is a reasonably comfortable time frame. If there's an inflection that alters John's projected trajectory I think we can act then. I was especially concerned about the potential subjectivity or variability of the definitions of "technical need" that were flying about, although the definitions focused on critical infrastructure seemed more solid and possibly acceptable. --MM From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Andrew Dul Sent: Friday, April 8, 2016 12:07 PM To: arin-ppml at arin.net Subject: Re: [arin-ppml] ARIN 2-Byte ASN inventory and issuance Do other members of the ARIN community believe that the current policy and operational practice is sufficient for now, or are there policy changes needed at this time? Thanks, Andrew On 4/7/2016 12:24 PM, Scott Leibrand wrote: Thanks, John. It sounds to me like ARIN is already doing the right thing (saving 2-byte ASNs for people who specifically want them), and that is sufficient for the time being. It does not appear that additional restrictions on who may request a 2-byte ASN are necessary at this time. If at some point 5+ years down the road the rate of 2-byte ASN demand starts to exceed the recovered supply and the 2-byte ASN inventory is depleted, we can consider a waiting list and/or technical requirements for requesting a 2-byte ASN at that time. Is there any other reason we need to consider taking action sooner? Was there something else I'm missing that prompted ARIN staff to start the consultation process around a 2-byte ASN waiting list? -Scott On Thu, Apr 7, 2016 at 11:44 AM, John Curran > wrote: Folks - Please forgive this omnibus email of information, but we've had sufficient individual questions for 2-byte ASN data that it simply made more sense to provide one full summary rather than reply to each question individually... ARIN continues to have classic, 2-byte, AS numbers in inventory. Over the last few years, we have received small blocks of them in our new delegations from the IANA, obtained them from customer returns of AS numbers, or through revocations of AS numbers due to non-payment of registration fees. Our last AS block delegation from IANA was on 29 April 2015. We received 99 2-byte ASNs and 925 4-byte ASNs at that time, and do not expect to receive any additional 2-byte ASNs from the IANA in future delegations. The 2-byte ASNs received from the IANA in 2015 were added to the inventory and placed on hold. The reason that the 2-byte ASNs were put on hold is that was not responsible to issue from the dwindling quantity of these resources to parties that did not specifically request such while we were still receiving AS number requests specifically asking for 2-byte AS numbers. As of today, we currently have the following 2-byte ASNs in ARIN inventory: 387 2-byte AS numbers on hold (most were routed at some point) 535 2-byte AS numbers revoked 133 2-byte AS numbers returned = 1,055 2-byte AS numbers returned/revoked/held (Total) Customers requesting ASNs receive a 4-byte ASN by default. If a request comes in that specifically requests a 2-byte ASN, we inform the customer that we have noted their special request and that we will accommodate it at the issuance phase of the ticket process if we have 2-byte ASN available at that time. Rate of issuance for 2-byte ASNs per month - 1/2015: 68 2/2015: 77 3/2015: 74 4/2015: 60 5/2015: 7 6/2015: 12 7/2015: 16 8/2015: 4 9/2015: 7 10/2015: 11 11/2015: 7 12/2015: 11 1/2016: 5 2/2016: 6 3/2016: 13 A waiting list will only be applicable after depletion of the present 2-byte ASN inventory, hence the following general run-out estimates are provided for consideration: - If we release all of the 2-byte ASNs from hold and issue ASNs strictly from smallest to largest, i.e. the practice prior to May 2015, it is likely that the current inventory of 2-byte ASN's would last somewhere between 6 to 12 months. - If we continue the current approach (wherein 4-byte ASNs are issued by default and 2-byte ASNs are only issued upon special request), the current inventory of 2-byte ASNs would appear to last for many years (5+ years at present rate). I hope the above information helps in your policy development efforts! Thank you, /John John Curran President and CEO American Registry for Internet Numbers (ARIN) _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjones at vt.edu Fri Apr 8 16:39:35 2016 From: bjones at vt.edu (Brian Jones) Date: Fri, 8 Apr 2016 16:39:35 -0400 Subject: [arin-ppml] ARIN 2-Byte ASN inventory and issuance In-Reply-To: <5707D70D.2040805@quark.net> References: <57015A09.2030901@quark.net> <5707D70D.2040805@quark.net> Message-ID: I believe the current practice is sufficient for now. If a sudden run on 2-byte ASN's occurs this issue should be resurrected at that time. -- Brian ? E Jones? -- Brian On Fri, Apr 8, 2016 at 12:06 PM, Andrew Dul wrote: > Do other members of the ARIN community believe that the current policy and > operational practice is sufficient for now, or are there policy changes > needed at this time? > > Thanks, > Andrew > > On 4/7/2016 12:24 PM, Scott Leibrand wrote: > > Thanks, John. > > It sounds to me like ARIN is already doing the right thing (saving 2-byte > ASNs for people who specifically want them), and that is sufficient for the > time being. It does not appear that additional restrictions on who may > request a 2-byte ASN are necessary at this time. If at some point 5+ years > down the road the rate of 2-byte ASN demand starts to exceed the recovered > supply and the 2-byte ASN inventory is depleted, we can consider a waiting > list and/or technical requirements for requesting a 2-byte ASN at that time. > > Is there any other reason we need to consider taking action sooner? Was > there something else I'm missing that prompted ARIN staff to start the > consultation process around a 2-byte ASN waiting list? > > -Scott > > On Thu, Apr 7, 2016 at 11:44 AM, John Curran wrote: > >> Folks - >> >> Please forgive this omnibus email of information, but we've had >> sufficient individual >> questions for 2-byte ASN data that it simply made more sense to provide >> one full >> summary rather than reply to each question individually... >> >> ARIN continues to have classic, 2-byte, AS numbers in inventory. Over the >> last few >> years, we have received small blocks of them in our new delegations from >> the IANA, >> obtained them from customer returns of AS numbers, or through revocations >> of AS >> numbers due to non-payment of registration fees. >> >> Our last AS block delegation from IANA was on 29 April 2015. We received >> 99 2-byte >> ASNs and 925 4-byte ASNs at that time, and do not expect to receive any >> additional >> 2-byte ASNs from the IANA in future delegations. The 2-byte ASNs >> received from the >> IANA in 2015 were added to the inventory and placed on hold. The reason >> that the >> 2-byte ASNs were put on hold is that was not responsible to issue from >> the dwindling >> quantity of these resources to parties that did not specifically request >> such while we >> were still receiving AS number requests specifically asking for 2-byte AS >> numbers. >> >> As of today, we currently have the following 2-byte ASNs in ARIN >> inventory: >> >> 387 2-byte AS numbers on hold (most were routed at some point) >> 535 2-byte AS numbers revoked >> 133 2-byte AS numbers returned >> >> = 1,055 2-byte AS numbers returned/revoked/held (Total) >> >> Customers requesting ASNs receive a 4-byte ASN by default. If a request >> comes in >> that specifically requests a 2-byte ASN, we inform the customer that we >> have noted >> their special request and that we will accommodate it at the issuance >> phase of the >> ticket process if we have 2-byte ASN available at that time. >> >> Rate of issuance for 2-byte ASNs per month - >> >> 1/2015: 68 >> 2/2015: 77 >> 3/2015: 74 >> 4/2015: 60 >> 5/2015: 7 >> 6/2015: 12 >> 7/2015: 16 >> 8/2015: 4 >> 9/2015: 7 >> 10/2015: 11 >> 11/2015: 7 >> 12/2015: 11 >> 1/2016: 5 >> 2/2016: 6 >> 3/2016: 13 >> >> A waiting list will only be applicable after depletion of the present >> 2-byte ASN inventory, >> hence the following general run-out estimates are provided for >> consideration: >> >> - If we release all of the 2-byte ASNs from hold and issue ASNs >> strictly from smallest >> to largest, i.e. the practice prior to May 2015, it is likely that >> the current inventory of >> 2-byte ASN?s would last somewhere between 6 to 12 months. >> >> - If we continue the current approach (wherein 4-byte ASNs are issued >> by default and >> 2-byte ASNs are only issued upon special request), the current >> inventory of 2-byte >> ASNs would appear to last for many years (5+ years at present rate). >> >> I hope the above information helps in your policy development efforts! >> >> Thank you, >> /John >> >> John Curran >> President and CEO >> American Registry for Internet Numbers (ARIN) >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List ( >> ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at:http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at semihuman.com Fri Apr 8 16:41:59 2016 From: chris at semihuman.com (Chris Woodfield) Date: Fri, 8 Apr 2016 13:41:59 -0700 Subject: [arin-ppml] ARIN 2-Byte ASN inventory and issuance In-Reply-To: References: <57015A09.2030901@quark.net> <5707D70D.2040805@quark.net> Message-ID: Agreed that we can park this for now, provided we can come up with a measurable turning point (let?s say, where the trend points to 1-2 years from exhaustion) where we should revive the discussion. -C > On Apr 8, 2016, at 1:39 PM, Brian Jones wrote: > > I believe the current practice is sufficient for now. If a sudden run on 2-byte ASN's occurs this issue should be resurrected at that time. > > -- > Brian? E Jones? > > -- > Brian > > On Fri, Apr 8, 2016 at 12:06 PM, Andrew Dul > wrote: > Do other members of the ARIN community believe that the current policy and operational practice is sufficient for now, or are there policy changes needed at this time? > > Thanks, > Andrew > > On 4/7/2016 12:24 PM, Scott Leibrand wrote: >> Thanks, John. >> >> It sounds to me like ARIN is already doing the right thing (saving 2-byte ASNs for people who specifically want them), and that is sufficient for the time being. It does not appear that additional restrictions on who may request a 2-byte ASN are necessary at this time. If at some point 5+ years down the road the rate of 2-byte ASN demand starts to exceed the recovered supply and the 2-byte ASN inventory is depleted, we can consider a waiting list and/or technical requirements for requesting a 2-byte ASN at that time. >> >> Is there any other reason we need to consider taking action sooner? Was there something else I'm missing that prompted ARIN staff to start the consultation process around a 2-byte ASN waiting list? >> >> -Scott >> >> On Thu, Apr 7, 2016 at 11:44 AM, John Curran > wrote: >> Folks - >> >> Please forgive this omnibus email of information, but we've had sufficient individual >> questions for 2-byte ASN data that it simply made more sense to provide one full >> summary rather than reply to each question individually... >> >> ARIN continues to have classic, 2-byte, AS numbers in inventory. Over the last few >> years, we have received small blocks of them in our new delegations from the IANA, >> obtained them from customer returns of AS numbers, or through revocations of AS >> numbers due to non-payment of registration fees. >> >> Our last AS block delegation from IANA was on 29 April 2015. We received 99 2-byte >> ASNs and 925 4-byte ASNs at that time, and do not expect to receive any additional >> 2-byte ASNs from the IANA in future delegations. The 2-byte ASNs received from the >> IANA in 2015 were added to the inventory and placed on hold. The reason that the >> 2-byte ASNs were put on hold is that was not responsible to issue from the dwindling >> quantity of these resources to parties that did not specifically request such while we >> were still receiving AS number requests specifically asking for 2-byte AS numbers. >> >> As of today, we currently have the following 2-byte ASNs in ARIN inventory: >> >> 387 2-byte AS numbers on hold (most were routed at some point) >> 535 2-byte AS numbers revoked >> 133 2-byte AS numbers returned >> >> = 1,055 2-byte AS numbers returned/revoked/held (Total) >> >> Customers requesting ASNs receive a 4-byte ASN by default. If a request comes in >> that specifically requests a 2-byte ASN, we inform the customer that we have noted >> their special request and that we will accommodate it at the issuance phase of the >> ticket process if we have 2-byte ASN available at that time. >> >> Rate of issuance for 2-byte ASNs per month - >> >> 1/2015: 68 >> 2/2015: 77 >> 3/2015: 74 >> 4/2015: 60 >> 5/2015: 7 >> 6/2015: 12 >> 7/2015: 16 >> 8/2015: 4 >> 9/2015: 7 >> 10/2015: 11 >> 11/2015: 7 >> 12/2015: 11 >> 1/2016: 5 >> 2/2016: 6 >> 3/2016: 13 >> >> A waiting list will only be applicable after depletion of the present 2-byte ASN inventory, >> hence the following general run-out estimates are provided for consideration: >> >> - If we release all of the 2-byte ASNs from hold and issue ASNs strictly from smallest >> to largest, i.e. the practice prior to May 2015, it is likely that the current inventory of >> 2-byte ASN?s would last somewhere between 6 to 12 months. >> >> - If we continue the current approach (wherein 4-byte ASNs are issued by default and >> 2-byte ASNs are only issued upon special request), the current inventory of 2-byte >> ASNs would appear to last for many years (5+ years at present rate). >> >> I hope the above information helps in your policy development efforts! >> >> Thank you, >> /John >> >> John Curran >> President and CEO >> American Registry for Internet Numbers (ARIN) >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List ( ARIN-PPML at arin.net ). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> >> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjletts at uw.edu Fri Apr 8 18:51:47 2016 From: rjletts at uw.edu (Richard J. Letts) Date: Fri, 8 Apr 2016 22:51:47 +0000 Subject: [arin-ppml] ARIN 2-Byte ASN inventory and issuance In-Reply-To: References: <57015A09.2030901@quark.net> <5707D70D.2040805@quark.net> Message-ID: Agreed; Though I would also point out that charging less than $500 for a 4-byte ASN (say $100) would act as an economic incentive to use one of those if it would work in your situation, and it probably does for most locations. Thank you Richard Letts From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Chris Woodfield Sent: Friday, April 8, 2016 1:42 PM To: bjones at vt.edu Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] ARIN 2-Byte ASN inventory and issuance Agreed that we can park this for now, provided we can come up with a measurable turning point (let?s say, where the trend points to 1-2 years from exhaustion) where we should revive the discussion. -C On Apr 8, 2016, at 1:39 PM, Brian Jones > wrote: I believe the current practice is sufficient for now. If a sudden run on 2-byte ASN's occurs this issue should be resurrected at that time. -- Brian ? E Jones? -- Brian On Fri, Apr 8, 2016 at 12:06 PM, Andrew Dul > wrote: Do other members of the ARIN community believe that the current policy and operational practice is sufficient for now, or are there policy changes needed at this time? Thanks, Andrew On 4/7/2016 12:24 PM, Scott Leibrand wrote: Thanks, John. It sounds to me like ARIN is already doing the right thing (saving 2-byte ASNs for people who specifically want them), and that is sufficient for the time being. It does not appear that additional restrictions on who may request a 2-byte ASN are necessary at this time. If at some point 5+ years down the road the rate of 2-byte ASN demand starts to exceed the recovered supply and the 2-byte ASN inventory is depleted, we can consider a waiting list and/or technical requirements for requesting a 2-byte ASN at that time. Is there any other reason we need to consider taking action sooner? Was there something else I'm missing that prompted ARIN staff to start the consultation process around a 2-byte ASN waiting list? -Scott On Thu, Apr 7, 2016 at 11:44 AM, John Curran > wrote: Folks - Please forgive this omnibus email of information, but we've had sufficient individual questions for 2-byte ASN data that it simply made more sense to provide one full summary rather than reply to each question individually... ARIN continues to have classic, 2-byte, AS numbers in inventory. Over the last few years, we have received small blocks of them in our new delegations from the IANA, obtained them from customer returns of AS numbers, or through revocations of AS numbers due to non-payment of registration fees. Our last AS block delegation from IANA was on 29 April 2015. We received 99 2-byte ASNs and 925 4-byte ASNs at that time, and do not expect to receive any additional 2-byte ASNs from the IANA in future delegations. The 2-byte ASNs received from the IANA in 2015 were added to the inventory and placed on hold. The reason that the 2-byte ASNs were put on hold is that was not responsible to issue from the dwindling quantity of these resources to parties that did not specifically request such while we were still receiving AS number requests specifically asking for 2-byte AS numbers. As of today, we currently have the following 2-byte ASNs in ARIN inventory: 387 2-byte AS numbers on hold (most were routed at some point) 535 2-byte AS numbers revoked 133 2-byte AS numbers returned = 1,055 2-byte AS numbers returned/revoked/held (Total) Customers requesting ASNs receive a 4-byte ASN by default. If a request comes in that specifically requests a 2-byte ASN, we inform the customer that we have noted their special request and that we will accommodate it at the issuance phase of the ticket process if we have 2-byte ASN available at that time. Rate of issuance for 2-byte ASNs per month - 1/2015: 68 2/2015: 77 3/2015: 74 4/2015: 60 5/2015: 7 6/2015: 12 7/2015: 16 8/2015: 4 9/2015: 7 10/2015: 11 11/2015: 7 12/2015: 11 1/2016: 5 2/2016: 6 3/2016: 13 A waiting list will only be applicable after depletion of the present 2-byte ASN inventory, hence the following general run-out estimates are provided for consideration: - If we release all of the 2-byte ASNs from hold and issue ASNs strictly from smallest to largest, i.e. the practice prior to May 2015, it is likely that the current inventory of 2-byte ASN?s would last somewhere between 6 to 12 months. - If we continue the current approach (wherein 4-byte ASNs are issued by default and 2-byte ASNs are only issued upon special request), the current inventory of 2-byte ASNs would appear to last for many years (5+ years at present rate). I hope the above information helps in your policy development efforts! Thank you, /John John Curran President and CEO American Registry for Internet Numbers (ARIN) _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmer at umn.edu Fri Apr 8 19:26:30 2016 From: farmer at umn.edu (David Farmer) Date: Fri, 8 Apr 2016 18:26:30 -0500 Subject: [arin-ppml] ARIN 2-Byte ASN inventory and issuance (was: Re: 2-byte ASN policy) In-Reply-To: References: <57015A09.2030901@quark.net> Message-ID: On Thu, Apr 7, 2016 at 2:24 PM, Scott Leibrand wrote: > Thanks, John. > > It sounds to me like ARIN is already doing the right thing (saving 2-byte > ASNs for people who specifically want them), and that is sufficient for the > time being. It does not appear that additional restrictions on who may > request a 2-byte ASN are necessary at this time. If at some point 5+ years > down the road the rate of 2-byte ASN demand starts to exceed the recovered > supply and the 2-byte ASN inventory is depleted, we can consider a waiting > list and/or technical requirements for requesting a 2-byte ASN at that time. > > Is there any other reason we need to consider taking action sooner? > I agree the current procedures are meeting our needs and see no need for immediate changes. However, I would suggest the community get regular reports on the inventory levels for 2-byte ASNs. Adding a slide to one of the many reports at the PPMs seems logical, but I'd leave it up to staff to determine the best mechanism for such reporting. Assuming we stay on the current trajectory, I think we should look at this again in about two years. Hopefully, by then the rate of use for 2-byte ASNs will have slowed even more and any real operational threat from running out of 2-byte ASNs will be greatly diminished if not non-existent. If not we should still have sufficient time to plan for a soft landing. Was there something else I'm missing that prompted ARIN staff to start the > consultation process around a 2-byte ASN waiting list? > > -Scott > One side issue that came up in this discussion that I think could be worthy of follow up and/or further discussion. The number of ASNs in the routing table that are not properly registered, surprised me a little; 350+ unregistered ASNs and 900+ prefixes associated with them, were the easy numbers for me to find. What I don't know, does that represent a constant churn of short-term issues, where most of them come and go over a few months. Or, are most those chronic long-term issues that are not getting cleaned up even after several years. If it's the later, then maybe we need to do something about that. Thanks -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjones at vt.edu Fri Apr 8 21:34:15 2016 From: bjones at vt.edu (Brian Jones) Date: Fri, 8 Apr 2016 21:34:15 -0400 Subject: [arin-ppml] ARIN 2-Byte ASN inventory and issuance (was: Re: 2-byte ASN policy) In-Reply-To: References: <57015A09.2030901@quark.net> Message-ID: On Apr 8, 2016 7:26 PM, "David Farmer" wrote: > > On Thu, Apr 7, 2016 at 2:24 PM, Scott Leibrand wrote: >> >> Thanks, John. >> >> It sounds to me like ARIN is already doing the right thing (saving 2-byte ASNs for people who specifically want them), and that is sufficient for the time being. It does not appear that additional restrictions on who may request a 2-byte ASN are necessary at this time. If at some point 5+ years down the road the rate of 2-byte ASN demand starts to exceed the recovered supply and the 2-byte ASN inventory is depleted, we can consider a waiting list and/or technical requirements for requesting a 2-byte ASN at that time. >> >> Is there any other reason we need to consider taking action sooner? > > > I agree the current procedures are meeting our needs and see no need for immediate changes. However, I would suggest the community get regular reports on the inventory levels for 2-byte ASNs. Adding a slide to one of the many reports at the PPMs seems logical, but I'd leave it up to staff to determine the best mechanism for such reporting. > > Assuming we stay on the current trajectory, I think we should look at this again in about two years. Hopefully, by then the rate of use for 2-byte ASNs will have slowed even more and any real operational threat from running out of 2-byte ASNs will be greatly diminished if not non-existent. If not we should still have sufficient time to plan for a soft landing. > >> Was there something else I'm missing that prompted ARIN staff to start the consultation process around a 2-byte ASN waiting list? >> >> -Scott > > > One side issue that came up in this discussion that I think could be worthy of follow up and/or further discussion. The number of ASNs in the routing table that are not properly registered, surprised me a little; 350+ unregistered ASNs and 900+ prefixes associated with them, were the easy numbers for me to find. What I don't know, does that represent a constant churn of short-term issues, where most of them come and go over a few months. Or, are most those chronic long-term issues that are not getting cleaned up even after several years. If it's the later, then maybe we need to do something about that. +1 - I agree if this is a long term issue we really should be doing something about it. Good information Thanks David. > > Thanks > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =============================================== > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michel at arneill-py.sacramento.ca.us Fri Apr 8 23:34:46 2016 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Sat, 9 Apr 2016 03:34:46 +0000 Subject: [arin-ppml] 4-byte ASNs and BGP communities was:policy 2-byte ASN policy In-Reply-To: <57016667.8050300@skywaywest.com> References: <57015A09.2030901@quark.net> <4CFD1C3E-CAA7-45A1-9784-CBC9A1E29800@athompso.net> <57016667.8050300@skywaywest.com> Message-ID: Ron, > Ron Grant wrote : > The biggest technical problem with 4-byte ASNs that I'm aware of comes when propagating BGP communities > - AFAIK even with extended communities, you can't specify two 4-byte ASNs in a single community. [..] > Recently we ran into this problem when requesting an ASN for the Vancouver Internet Exchange (VANIX) > - we were told there were no 2-byte ASNs left, so we went back to the drawing board to see how we could > run our Route Server with a 4-byte ASN, and after wrestling with the problem for a few weeks, went back > to ARIN and...joy!...someone had returned a 2-byte, which we obtained for the RS. Would you have technical specifics about the problems you ran into using a 4-byte-ASN ? Such as the OS / platform / software used for the Route Server and which configurations items / scripts did not work ? I acknowledge that 4-byte-ASN support is not what I expected it to be; it is clear / justified that people will prefer 2-byte ASNs for a while as they require no change to what they are used to. That being said, I think it would be of interest to the ARIN community to have a clear view of the technical issues using 4-byte-ASNs WRT BGP communities. I am in the process of deprecating 65532:666 in favor of RT:4200065532:666. It is a LOT of work. Below is my personal view using Cisco IOS 15.x and the cheat-sheet I use. I would like the cheat-sheet for other platforms. Michel. (config)#ip bgp-community new-format Nothing new about that, we used it on a 2500. What it means is that the format is AS16:value, (16 bits each) instead of being a 32-bit integer. Example : AS 65532, value 666 : the community is 65532:666; one can assign more than one community to a prefix. (config-route-map)#set community 65532:666 65532:667 -> OK (config-route-map)#set community 65532:666 additive -> OK Problem : 4-byte ASNs are 32-bit not 16, duh. Solution, (on paper) : extended communities. Cisco-specific issue : if the desired community is related to the originating AS, one can have only one community per prefix, which possibly is the issue you mentioned in the first place. (config-route-map)#set extcommunity soo 4200065532:666 4200065532:667 ^ % Invalid input detected at '^' marker. (config-route-map)#set extcommunity soo 4200065532:666 additive ^ % Invalid input detected at '^' marker. Way around it : use RT (target AS) instead of SoO. (config-route-map)#set extcommunity rt 4200065532:666 4200065532:667 -> OK (config-route-map)#set extcommunity rt 4200065532:666 additive -> OK #sh ip bgp x.x.x.x BGP routing table entry for x.x.x.x/32, version 4 Paths: (1 available, best #1, table default) Advertised to update-groups: zz Local 192.0.2.1 from y.y.y.y (y.y.y.y) Origin IGP, localpref 100, weight 1, valid, internal, best Community: 65532:666 65532:667 Extended Community: RT:4200065532:666 RT:4200065532:667 It works, and propagates correctly (shows the same on peers). Cheat-sheet for Cisco : +-----------------------------------------+-----------------------------------------------+ | AS 16 bit | AS 32 bit | +-----------------------------------------+-----------------------------------------------+ | set community ASN16:value1 ASN16:value2 | set extcommunity RT ASN32:value1 ASN32:value2 | | set community ASN16:value1 additive | set extcommunity RT ASN32:value1 additive | | match community | match extcommunity | | ip community-list standard | ip extcommunity-list standard | +-----------------------------------------+-----------------------------------------------+ From ctacit at tacitlaw.com Mon Apr 11 10:50:32 2016 From: ctacit at tacitlaw.com (Christian Tacit) Date: Mon, 11 Apr 2016 14:50:32 +0000 Subject: [arin-ppml] Revision to Text of Draft Policy ARIN-2015-2 Message-ID: <9851d5ee8a334febaf54742028e5bb1b@S05-MBX03-12.S05.local> Dear Community Members: I am writing to advise of additional changes made today to the text of Draft Policy ARIN-2015-2. In the Staff and Legal analysis obtained, General Counsel expressed concerns about the proposed definitions of "affiliated" and "control". In light of these concerns and other efforts to simplify the text further, I have amended the text once again. The new amendments achieve the same intent as the previous language using much simpler and more concise language. The revised draft proposal is: "Problem Statement: Organizations that obtain a 24 month supply of IP addresses via the transfer market and then have an unexpected change in business plan are unable to move IP addresses to the proper RIR within the first 12 months of receipt. Policy statement: Replace 8.4, bullet 4, to read: "Source entities within the ARIN region must not have received a transfer, allocation, or assignment of IPv4 number resources from ARIN for the 12 months prior to the approval of a transfer request, unless either the source and recipient entities own or control each other or are under common ownership or control. This restriction does not include M&A transfers." Comments: Organizations that obtain a 24 month supply of IP addresses via the transfer market and then have an unexpected change in business plan are unable to move IP addresses to the proper RIR within the first 12 months of receipt. The need to move the resources does not flow from ARIN policy, but rather from the requirement of certain registries outside the ARIN region to have the resources moved in order to be used there. The intention of this change is to allow organizations to perform inter-RIR transfers of space received via an 8.3 transfer regardless of the date transferred to ARIN. A common example is that an organization acquires a block located in the ARIN region, transfers it to ARIN, then 3 months later, the organization announces that it wants to launch new services out of region. Under current policy, the organization is prohibited from moving some or all of those addresses to that region's Whois if there is a need to move them to satisfy the rules of the other region requiring the movement of the resources to that region in order for them to be used there. Instead, the numbers are locked in ARIN's Whois. It's important to note that 8.3 transfers are approved for a 24 month supply, and it would not be unheard of for a business model to change within the first 12 months after approval. The proposal also introduces a requirement for an affiliation relationship between the source and recipient entity, based on established corporate law principles, so as to make it reasonably likely that eliminating the 12 month anti-flip period in that situation will meet the needs of organizations that operate networks in more than one region without encouraging abuse. a. Timetable for implementation: Immediate b. Anything else: N/A" Chris Tacit -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Mon Apr 11 13:43:21 2016 From: owen at delong.com (Owen DeLong) Date: Mon, 11 Apr 2016 10:43:21 -0700 Subject: [arin-ppml] Draft Policy ARIN-2016-1: Reserved Pool Transfer Policy In-Reply-To: References: <56F178F9.7020608@arin.net> Message-ID: <26041E0D-0DDD-4395-AEDA-1B5D2FCEB37B@delong.com> > On Apr 6, 2016, at 20:11 , Gary Buhrmaster wrote: > > On Tue, Mar 22, 2016 at 4:55 PM, ARIN wrote: > .... >> Policy statement: >> >> Add to Section 8.3 and Section 8.4 under the "Conditions on source of the >> transfer:" >> >> Address resources from a reserved pool (including those designated in >> Section 4.4 and 4.10) are not eligible for transfer. > > I am in favor of the intent, although I would have > (at first thought) expected that the "resources > transferred will be subject to ARIN policies" > would have resulted in a review of the recipients > planned usage. However, given the possible > interpretations (which historically any ambiguity > goes in favor of the requester), I can see that > some improvements might be valuable. However, > I would suggest that the proposed language be > modified to allow for a transfer if the recipient > would otherwise meet the requirements that could > be used to approve the resources from the reserved > block. > > What about something like: > > "Recipients of resources from a reserved pool .... > must demonstrate that the recipient would > qualify for those resources under existing policy, > and the resources may not be transferred out > of region?. I?d be OK with this, but given that there is remaining free pool for these resources, I?m not sure that it isn?t better to have a clear policy that when the resources in these categories are no longer needed, voluntary return to ARIN is expected. Unlike the normal case where freeing up resources may require extraordinary effort and thus some level of incentive, these are micro-allocations made for a specific purpose which is relatively binary? Either that purpose continues to exist or it does not. In case of the latter, the resources should be returned. There is no possibility of legacy issues in these pools, so each of the resources in question is attached to an annual billing. As such, non-renewal should address any abandonment issues. Owen From owen at delong.com Mon Apr 11 15:18:51 2016 From: owen at delong.com (Owen DeLong) Date: Mon, 11 Apr 2016 12:18:51 -0700 Subject: [arin-ppml] ARIN 2-Byte ASN inventory and issuance In-Reply-To: <5707D70D.2040805@quark.net> References: <57015A09.2030901@quark.net> <5707D70D.2040805@quark.net> Message-ID: Pesonally, I believe we have a terminology problem more than anything else. At this time, we should no longer be even considering ?2-byte? ASNs. There are two classes of 4-byte ASNs. The idea of 2-byte ASNs should be considered anachronistic. The classes of 4-byte ASNs are those that are ?65535 and those that are ?65536. The former class can be used as a 2-byte ASN in the rare case of a technological limitation (obsolete routing equipment or equipment with inadequate support for extended communities). The latter class cannot be used as a 2-byte ASN in such cases. In all cases, continuing to talk about 2-byte ASNs IMHO contributes to the misperception that the internet has not yet moved on. I believe that current policy is sufficient. I would prefer that operational practice actually revert to what is in policy and that we no longer treat 4-byte ASNs ?65535 as being in any way special. Owen > On Apr 8, 2016, at 09:06 , Andrew Dul wrote: > > Do other members of the ARIN community believe that the current policy and operational practice is sufficient for now, or are there policy changes needed at this time? > > Thanks, > Andrew > > On 4/7/2016 12:24 PM, Scott Leibrand wrote: >> Thanks, John. >> >> It sounds to me like ARIN is already doing the right thing (saving 2-byte ASNs for people who specifically want them), and that is sufficient for the time being. It does not appear that additional restrictions on who may request a 2-byte ASN are necessary at this time. If at some point 5+ years down the road the rate of 2-byte ASN demand starts to exceed the recovered supply and the 2-byte ASN inventory is depleted, we can consider a waiting list and/or technical requirements for requesting a 2-byte ASN at that time. >> >> Is there any other reason we need to consider taking action sooner? Was there something else I'm missing that prompted ARIN staff to start the consultation process around a 2-byte ASN waiting list? >> >> -Scott >> >> On Thu, Apr 7, 2016 at 11:44 AM, John Curran > wrote: >> Folks - >> >> Please forgive this omnibus email of information, but we've had sufficient individual >> questions for 2-byte ASN data that it simply made more sense to provide one full >> summary rather than reply to each question individually... >> >> ARIN continues to have classic, 2-byte, AS numbers in inventory. Over the last few >> years, we have received small blocks of them in our new delegations from the IANA, >> obtained them from customer returns of AS numbers, or through revocations of AS >> numbers due to non-payment of registration fees. >> >> Our last AS block delegation from IANA was on 29 April 2015. We received 99 2-byte >> ASNs and 925 4-byte ASNs at that time, and do not expect to receive any additional >> 2-byte ASNs from the IANA in future delegations. The 2-byte ASNs received from the >> IANA in 2015 were added to the inventory and placed on hold. The reason that the >> 2-byte ASNs were put on hold is that was not responsible to issue from the dwindling >> quantity of these resources to parties that did not specifically request such while we >> were still receiving AS number requests specifically asking for 2-byte AS numbers. >> >> As of today, we currently have the following 2-byte ASNs in ARIN inventory: >> >> 387 2-byte AS numbers on hold (most were routed at some point) >> 535 2-byte AS numbers revoked >> 133 2-byte AS numbers returned >> >> = 1,055 2-byte AS numbers returned/revoked/held (Total) >> >> Customers requesting ASNs receive a 4-byte ASN by default. If a request comes in >> that specifically requests a 2-byte ASN, we inform the customer that we have noted >> their special request and that we will accommodate it at the issuance phase of the >> ticket process if we have 2-byte ASN available at that time. >> >> Rate of issuance for 2-byte ASNs per month - >> >> 1/2015: 68 >> 2/2015: 77 >> 3/2015: 74 >> 4/2015: 60 >> 5/2015: 7 >> 6/2015: 12 >> 7/2015: 16 >> 8/2015: 4 >> 9/2015: 7 >> 10/2015: 11 >> 11/2015: 7 >> 12/2015: 11 >> 1/2016: 5 >> 2/2016: 6 >> 3/2016: 13 >> >> A waiting list will only be applicable after depletion of the present 2-byte ASN inventory, >> hence the following general run-out estimates are provided for consideration: >> >> - If we release all of the 2-byte ASNs from hold and issue ASNs strictly from smallest >> to largest, i.e. the practice prior to May 2015, it is likely that the current inventory of >> 2-byte ASN?s would last somewhere between 6 to 12 months. >> >> - If we continue the current approach (wherein 4-byte ASNs are issued by default and >> 2-byte ASNs are only issued upon special request), the current inventory of 2-byte >> ASNs would appear to last for many years (5+ years at present rate). >> >> I hope the above information helps in your policy development efforts! >> >> Thank you, >> /John >> >> John Curran >> President and CEO >> American Registry for Internet Numbers (ARIN) >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List ( ARIN-PPML at arin.net ). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> >> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Mon Apr 11 15:24:30 2016 From: jcurran at arin.net (John Curran) Date: Mon, 11 Apr 2016 19:24:30 +0000 Subject: [arin-ppml] ARIN 2-Byte ASN inventory and issuance In-Reply-To: References: <57015A09.2030901@quark.net> <5707D70D.2040805@quark.net> Message-ID: > On Apr 11, 2016, at 3:18 PM, Owen DeLong wrote: > > Pesonally, I believe we have a terminology problem more than anything else. > > At this time, we should no longer be even considering ?2-byte? ASNs. > > There are two classes of 4-byte ASNs. The idea of 2-byte ASNs should be considered anachronistic. > > The classes of 4-byte ASNs are those that are ?65535 and those that are ?65536. > > The former class can be used as a 2-byte ASN in the rare case of a technological limitation (obsolete routing equipment or equipment with inadequate support for extended communities). > > The latter class cannot be used as a 2-byte ASN in such cases. > > In all cases, continuing to talk about 2-byte ASNs IMHO contributes to the misperception that the internet has not yet moved on. > > I believe that current policy is sufficient. I would prefer that operational practice actually revert to what is in policy and that we no longer treat 4-byte ASNs ?65535 as being in any way special. Since parties coming to ARIN are distinguishing between these classes of 4-byte ASNs and come back explicitly asking for one ?65535, are you suggesting that ARIN not hold these lower ones to be able to satisfy such requests? Thanks, /John John Curran President and CEO ARIN From scottleibrand at gmail.com Mon Apr 11 15:31:36 2016 From: scottleibrand at gmail.com (Scott Leibrand) Date: Mon, 11 Apr 2016 12:31:36 -0700 Subject: [arin-ppml] ARIN 2-Byte ASN inventory and issuance In-Reply-To: References: <57015A09.2030901@quark.net> <5707D70D.2040805@quark.net> Message-ID: On Mon, Apr 11, 2016 at 12:24 PM, John Curran wrote: > > > On Apr 11, 2016, at 3:18 PM, Owen DeLong wrote: > > > > Pesonally, I believe we have a terminology problem more than anything > else. > > > > At this time, we should no longer be even considering ?2-byte? ASNs. > > > > There are two classes of 4-byte ASNs. The idea of 2-byte ASNs should be > considered anachronistic. > > > > The classes of 4-byte ASNs are those that are ?65535 and those that are > ?65536. > > > > The former class can be used as a 2-byte ASN in the rare case of a > technological limitation (obsolete routing equipment or equipment with > inadequate support for extended communities). > > > > The latter class cannot be used as a 2-byte ASN in such cases. > > > > In all cases, continuing to talk about 2-byte ASNs IMHO contributes to > the misperception that the internet has not yet moved on. > > > > I believe that current policy is sufficient. I would prefer that > operational practice actually revert to what is in policy and that we no > longer treat 4-byte ASNs ?65535 as being in any way special. > > Since parties coming to ARIN are distinguishing between these classes of > 4-byte ASNs > and come back explicitly asking for one ?65535, are you suggesting that > ARIN not hold > these lower ones to be able to satisfy such requests? > I would vehemently oppose such a punitive and pointless change. If an applicant has no reason to prefer a low-numbered ASN, they should get a 6-digit one by default. -Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Mon Apr 11 17:06:36 2016 From: owen at delong.com (Owen DeLong) Date: Mon, 11 Apr 2016 14:06:36 -0700 Subject: [arin-ppml] ARIN 2-Byte ASN inventory and issuance In-Reply-To: References: <57015A09.2030901@quark.net> <5707D70D.2040805@quark.net> Message-ID: > On Apr 11, 2016, at 12:24 , John Curran wrote: > >> >> On Apr 11, 2016, at 3:18 PM, Owen DeLong wrote: >> >> Pesonally, I believe we have a terminology problem more than anything else. >> >> At this time, we should no longer be even considering ?2-byte? ASNs. >> >> There are two classes of 4-byte ASNs. The idea of 2-byte ASNs should be considered anachronistic. >> >> The classes of 4-byte ASNs are those that are ?65535 and those that are ?65536. >> >> The former class can be used as a 2-byte ASN in the rare case of a technological limitation (obsolete routing equipment or equipment with inadequate support for extended communities). >> >> The latter class cannot be used as a 2-byte ASN in such cases. >> >> In all cases, continuing to talk about 2-byte ASNs IMHO contributes to the misperception that the internet has not yet moved on. >> >> I believe that current policy is sufficient. I would prefer that operational practice actually revert to what is in policy and that we no longer treat 4-byte ASNs ?65535 as being in any way special. > > Since parties coming to ARIN are distinguishing between these classes of 4-byte ASNs > and come back explicitly asking for one ?65535, are you suggesting that ARIN not hold > these lower ones to be able to satisfy such requests? Yes. I believe that we, more than any other region, have been lazy in our adoption of current internet technologies to the detriment of the internet at large. I believe that continuing to facilitate this is not providing a useful service to the internet as a whole. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Mon Apr 11 17:38:26 2016 From: jcurran at arin.net (John Curran) Date: Mon, 11 Apr 2016 21:38:26 +0000 Subject: [arin-ppml] ARIN 2-Byte ASN inventory and issuance In-Reply-To: References: <57015A09.2030901@quark.net> <5707D70D.2040805@quark.net> Message-ID: On Apr 11, 2016, at 5:06 PM, Owen DeLong > wrote: On Apr 11, 2016, at 12:24 , John Curran > wrote: Since parties coming to ARIN are distinguishing between these classes of 4-byte ASNs and come back explicitly asking for one ?65535, are you suggesting that ARIN not hold these lower ones to be able to satisfy such requests? Yes. I believe that we, more than any other region, have been lazy in our adoption of current internet technologies to the detriment of the internet at large. I believe that continuing to facilitate this is not providing a useful service to the internet as a whole. Just to be clear, you feel that ARIN registry policy which rapidly depletes the lower range of 4-byte ASNs would be technically sound and facilitate fair and impartial number resource administration? It would be helpful if you could explain how in some detail, given that there appears to be sufficient number of lower range 4-byte ASNs for those who require such for their operations, and further that the supply appears to be sufficient for quite some time (potentially till there is greater acceptance and far fewer hurdles with the use of higher range 4-byte ASNs...) Thanks! /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Mon Apr 11 17:53:56 2016 From: owen at delong.com (Owen DeLong) Date: Mon, 11 Apr 2016 14:53:56 -0700 Subject: [arin-ppml] ARIN 2-Byte ASN inventory and issuance In-Reply-To: References: <57015A09.2030901@quark.net> <5707D70D.2040805@quark.net> Message-ID: <767503C3-7237-44C8-89DE-C03B6E4EFA3B@delong.com> > On Apr 11, 2016, at 14:38 , John Curran wrote: > > On Apr 11, 2016, at 5:06 PM, Owen DeLong > wrote: >> >> On Apr 11, 2016, at 12:24 , John Curran > wrote: >>> Since parties coming to ARIN are distinguishing between these classes of 4-byte ASNs >>> and come back explicitly asking for one ?65535, are you suggesting that ARIN not hold >>> these lower ones to be able to satisfy such requests? >> >> Yes. >> >> I believe that we, more than any other region, have been lazy in our adoption of current internet technologies to the detriment of the internet at large. >> >> I believe that continuing to facilitate this is not providing a useful service to the internet as a whole. > > Just to be clear, you feel that ARIN registry policy which rapidly depletes the > lower range of 4-byte ASNs would be technically sound and facilitate fair and > impartial number resource administration? No. I believe that ARIN registry policy which ignores any previous distinction between ASNs ?65535 and ASNs ?65536 is harmful. I believe that a policy which makes no distinction and hands them out as if they were a single pool of 32-bit numbers is in the best interests of the community. At some point there will no longer be available ASNs ?65535. So be it. That date should neither be accelerated nor decelerated by ARIN policy. > It would be helpful if you could explain how in some detail, given that there > appears to be sufficient number of lower range 4-byte ASNs for those who > require such for their operations, and further that the supply appears to be > sufficient for quite some time (potentially till there is greater acceptance > and far fewer hurdles with the use of higher range 4-byte ASNs?) So far, I haven?t seen so much a requirement as a convenience request for those lower numbers. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at semihuman.com Mon Apr 11 18:05:19 2016 From: chris at semihuman.com (Chris Woodfield) Date: Mon, 11 Apr 2016 15:05:19 -0700 Subject: [arin-ppml] ARIN 2-Byte ASN inventory and issuance In-Reply-To: <767503C3-7237-44C8-89DE-C03B6E4EFA3B@delong.com> References: <57015A09.2030901@quark.net> <5707D70D.2040805@quark.net> <767503C3-7237-44C8-89DE-C03B6E4EFA3B@delong.com> Message-ID: <44A08FD2-D764-4D45-8C3A-FE0DE2827A0E@semihuman.com> I?d argue that doing so ignores the fact that 2-byte vs 4-byte AS numbers (yes, I?m still using that terminology, so sue me) are handled fundamentally differently by the BGP protocol. As such, this isn?t a place where we can effectively boil the ocean and force providers to update their hardware via policy. As such, I?d far prefer that *as available* we continue to keep 2-byte ASNs in reserve for providers who can document their reasons for not being able to support having a 4-byte ASNs. Obviously there will be a day where those are all gone and then we?ll have no choice but to force operators to run compliant hardware/software. Note I?m making it clear that this isn?t just a matter of software; there?s quite a bit of gear out there on the internet that doesn?t have available software at all that supports 4-byte ASNs. And there are definitely operators that don?t have the budget to swap it out. This isn?t a case of inefficiency, it?s simply the fact that many providers are stuck using old hardware. Given negligible cost to accommodate, I have no problem doing so. Thanks, -C > On Apr 11, 2016, at 2:53 PM, Owen DeLong wrote: > >> >> On Apr 11, 2016, at 14:38 , John Curran > wrote: >> >> On Apr 11, 2016, at 5:06 PM, Owen DeLong > wrote: >>> >>> On Apr 11, 2016, at 12:24 , John Curran > wrote: >>>> Since parties coming to ARIN are distinguishing between these classes of 4-byte ASNs >>>> and come back explicitly asking for one ?65535, are you suggesting that ARIN not hold >>>> these lower ones to be able to satisfy such requests? >>> >>> Yes. >>> >>> I believe that we, more than any other region, have been lazy in our adoption of current internet technologies to the detriment of the internet at large. >>> >>> I believe that continuing to facilitate this is not providing a useful service to the internet as a whole. >> >> Just to be clear, you feel that ARIN registry policy which rapidly depletes the >> lower range of 4-byte ASNs would be technically sound and facilitate fair and >> impartial number resource administration? > > No. I believe that ARIN registry policy which ignores any previous distinction > between ASNs ?65535 and ASNs ?65536 is harmful. I believe that a policy which > makes no distinction and hands them out as if they were a single pool of 32-bit > numbers is in the best interests of the community. > > At some point there will no longer be available ASNs ?65535. So be it. That > date should neither be accelerated nor decelerated by ARIN policy. > >> It would be helpful if you could explain how in some detail, given that there >> appears to be sufficient number of lower range 4-byte ASNs for those who >> require such for their operations, and further that the supply appears to be >> sufficient for quite some time (potentially till there is greater acceptance >> and far fewer hurdles with the use of higher range 4-byte ASNs?) > > So far, I haven?t seen so much a requirement as a convenience request for those > lower numbers. > > Owen > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Mon Apr 11 18:08:57 2016 From: owen at delong.com (Owen DeLong) Date: Mon, 11 Apr 2016 15:08:57 -0700 Subject: [arin-ppml] ARIN 2-Byte ASN inventory and issuance In-Reply-To: <44A08FD2-D764-4D45-8C3A-FE0DE2827A0E@semihuman.com> References: <57015A09.2030901@quark.net> <5707D70D.2040805@quark.net> <767503C3-7237-44C8-89DE-C03B6E4EFA3B@delong.com> <44A08FD2-D764-4D45-8C3A-FE0DE2827A0E@semihuman.com> Message-ID: <5746CA86-58A5-4FAB-8A38-C45AD3B297D3@delong.com> > On Apr 11, 2016, at 15:05 , Chris Woodfield wrote: > > I?d argue that doing so ignores the fact that 2-byte vs 4-byte AS numbers (yes, I?m still using that terminology, so sue me) are handled fundamentally differently by the BGP protocol. As such, this isn?t a place where we can effectively boil the ocean and force providers to update their hardware via policy. Actually, they aren?t treated at all differently if you are using the modern configuration options. Sure, if you are continuing to use traditional communities, you are limited to low-order ASNs in the ASN portion of the community string. Sure, there?s a certain amount of backwards-compatible handling of ASPATH management in modern routers and that code still gets occasionally exercised in interacting with ancient equipment still in operation. However, if you have a configuration using extended communities and full support of modern ASNs enabled on your router, then all ASNs are treated as 32-bit ASNs and there is no fundamental difference remaining. There?s no attempt to boil the ocean and force providers. Merely an attempt to recognize that the days of treating them differently have, in fact, passed in most of the world and we shouldn?t be further enabling the harmful behavior of pretending otherwise. If this is such a huge issue, why isn?t it coming up in the other RIRs? Owen > > As such, I?d far prefer that *as available* we continue to keep 2-byte ASNs in reserve for providers who can document their reasons for not being able to support having a 4-byte ASNs. Obviously there will be a day where those are all gone and then we?ll have no choice but to force operators to run compliant hardware/software. > > Note I?m making it clear that this isn?t just a matter of software; there?s quite a bit of gear out there on the internet that doesn?t have available software at all that supports 4-byte ASNs. And there are definitely operators that don?t have the budget to swap it out. > > This isn?t a case of inefficiency, it?s simply the fact that many providers are stuck using old hardware. Given negligible cost to accommodate, I have no problem doing so. > > Thanks, > > -C > >> On Apr 11, 2016, at 2:53 PM, Owen DeLong > wrote: >> >>> >>> On Apr 11, 2016, at 14:38 , John Curran > wrote: >>> >>> On Apr 11, 2016, at 5:06 PM, Owen DeLong > wrote: >>>> >>>> On Apr 11, 2016, at 12:24 , John Curran > wrote: >>>>> Since parties coming to ARIN are distinguishing between these classes of 4-byte ASNs >>>>> and come back explicitly asking for one ?65535, are you suggesting that ARIN not hold >>>>> these lower ones to be able to satisfy such requests? >>>> >>>> Yes. >>>> >>>> I believe that we, more than any other region, have been lazy in our adoption of current internet technologies to the detriment of the internet at large. >>>> >>>> I believe that continuing to facilitate this is not providing a useful service to the internet as a whole. >>> >>> Just to be clear, you feel that ARIN registry policy which rapidly depletes the >>> lower range of 4-byte ASNs would be technically sound and facilitate fair and >>> impartial number resource administration? >> >> No. I believe that ARIN registry policy which ignores any previous distinction >> between ASNs ?65535 and ASNs ?65536 is harmful. I believe that a policy which >> makes no distinction and hands them out as if they were a single pool of 32-bit >> numbers is in the best interests of the community. >> >> At some point there will no longer be available ASNs ?65535. So be it. That >> date should neither be accelerated nor decelerated by ARIN policy. >> >>> It would be helpful if you could explain how in some detail, given that there >>> appears to be sufficient number of lower range 4-byte ASNs for those who >>> require such for their operations, and further that the supply appears to be >>> sufficient for quite some time (potentially till there is greater acceptance >>> and far fewer hurdles with the use of higher range 4-byte ASNs?) >> >> So far, I haven?t seen so much a requirement as a convenience request for those >> lower numbers. >> >> Owen >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at semihuman.com Mon Apr 11 18:25:27 2016 From: chris at semihuman.com (Chris Woodfield) Date: Mon, 11 Apr 2016 15:25:27 -0700 Subject: [arin-ppml] ARIN 2-Byte ASN inventory and issuance In-Reply-To: <5746CA86-58A5-4FAB-8A38-C45AD3B297D3@delong.com> References: <57015A09.2030901@quark.net> <5707D70D.2040805@quark.net> <767503C3-7237-44C8-89DE-C03B6E4EFA3B@delong.com> <44A08FD2-D764-4D45-8C3A-FE0DE2827A0E@semihuman.com> <5746CA86-58A5-4FAB-8A38-C45AD3B297D3@delong.com> Message-ID: <8DBB340C-2D96-41F2-A9A8-DD17BEC2AC80@semihuman.com> I?ll note that there are some pretty substantial ?ifs? in your statement there. Not all operators are in a position to satisfy those ?ifs?. Also, how is this behavior harmful? What operational issues arise from use of the backward-compatible mode here? Is it just a matter of not being able to see other ASNs with 23456 in path if you?re running in compatibility mode? If so, that?s not going to impact anyone but the operator itself (which IMO should be motivation enough to upgrade, but I don?t control those operator?s budgets). -C > On Apr 11, 2016, at 3:08 PM, Owen DeLong wrote: > > >> On Apr 11, 2016, at 15:05 , Chris Woodfield > wrote: >> >> I?d argue that doing so ignores the fact that 2-byte vs 4-byte AS numbers (yes, I?m still using that terminology, so sue me) are handled fundamentally differently by the BGP protocol. As such, this isn?t a place where we can effectively boil the ocean and force providers to update their hardware via policy. > > Actually, they aren?t treated at all differently if you are using the modern configuration options. > > Sure, if you are continuing to use traditional communities, you are limited to low-order ASNs in the ASN portion of the community string. > > Sure, there?s a certain amount of backwards-compatible handling of ASPATH management in modern routers and that code still gets occasionally exercised in interacting with ancient equipment still in operation. > > However, if you have a configuration using extended communities and full support of modern ASNs enabled on your router, then all ASNs are treated as 32-bit ASNs and there is no fundamental difference remaining. > > There?s no attempt to boil the ocean and force providers. Merely an attempt to recognize that the days of treating them differently have, in fact, passed in most of the world and we shouldn?t be further enabling the harmful behavior of pretending otherwise. > > If this is such a huge issue, why isn?t it coming up in the other RIRs? > > Owen > >> >> As such, I?d far prefer that *as available* we continue to keep 2-byte ASNs in reserve for providers who can document their reasons for not being able to support having a 4-byte ASNs. Obviously there will be a day where those are all gone and then we?ll have no choice but to force operators to run compliant hardware/software. >> >> Note I?m making it clear that this isn?t just a matter of software; there?s quite a bit of gear out there on the internet that doesn?t have available software at all that supports 4-byte ASNs. And there are definitely operators that don?t have the budget to swap it out. >> >> This isn?t a case of inefficiency, it?s simply the fact that many providers are stuck using old hardware. Given negligible cost to accommodate, I have no problem doing so. >> >> Thanks, >> >> -C >> >>> On Apr 11, 2016, at 2:53 PM, Owen DeLong > wrote: >>> >>>> >>>> On Apr 11, 2016, at 14:38 , John Curran > wrote: >>>> >>>> On Apr 11, 2016, at 5:06 PM, Owen DeLong > wrote: >>>>> >>>>> On Apr 11, 2016, at 12:24 , John Curran > wrote: >>>>>> Since parties coming to ARIN are distinguishing between these classes of 4-byte ASNs >>>>>> and come back explicitly asking for one ?65535, are you suggesting that ARIN not hold >>>>>> these lower ones to be able to satisfy such requests? >>>>> >>>>> Yes. >>>>> >>>>> I believe that we, more than any other region, have been lazy in our adoption of current internet technologies to the detriment of the internet at large. >>>>> >>>>> I believe that continuing to facilitate this is not providing a useful service to the internet as a whole. >>>> >>>> Just to be clear, you feel that ARIN registry policy which rapidly depletes the >>>> lower range of 4-byte ASNs would be technically sound and facilitate fair and >>>> impartial number resource administration? >>> >>> No. I believe that ARIN registry policy which ignores any previous distinction >>> between ASNs ?65535 and ASNs ?65536 is harmful. I believe that a policy which >>> makes no distinction and hands them out as if they were a single pool of 32-bit >>> numbers is in the best interests of the community. >>> >>> At some point there will no longer be available ASNs ?65535. So be it. That >>> date should neither be accelerated nor decelerated by ARIN policy. >>> >>>> It would be helpful if you could explain how in some detail, given that there >>>> appears to be sufficient number of lower range 4-byte ASNs for those who >>>> require such for their operations, and further that the supply appears to be >>>> sufficient for quite some time (potentially till there is greater acceptance >>>> and far fewer hurdles with the use of higher range 4-byte ASNs?) >>> >>> So far, I haven?t seen so much a requirement as a convenience request for those >>> lower numbers. >>> >>> Owen >>> >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to >>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at arin.net if you experience any issues. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Mon Apr 11 18:24:06 2016 From: jcurran at arin.net (John Curran) Date: Mon, 11 Apr 2016 22:24:06 +0000 Subject: [arin-ppml] ARIN 2-Byte ASN inventory and issuance In-Reply-To: <767503C3-7237-44C8-89DE-C03B6E4EFA3B@delong.com> References: <57015A09.2030901@quark.net> <5707D70D.2040805@quark.net> <767503C3-7237-44C8-89DE-C03B6E4EFA3B@delong.com> Message-ID: <9C5608C2-8BE2-4322-8D66-66A8CCFC3CE9@arin.net> On Apr 11, 2016, at 5:53 PM, Owen DeLong > wrote: Just to be clear, you feel that ARIN registry policy which rapidly depletes the lower range of 4-byte ASNs would be technically sound and facilitate fair and impartial number resource administration? No. I believe that ARIN registry policy which ignores any previous distinction between ASNs ?65535 and ASNs ?65536 is harmful. I believe that a policy which makes no distinction and hands them out as if they were a single pool of 32-bit numbers is in the best interests of the community. Alas, within the scope of ARIN?s mission, the best interests of the community are met by registry policy which is technically sound and facilitates fair and impartial number resource administration (hence the reason I asked you to elaborate on those aspects, if any were applicable to your position.) At some point there will no longer be available ASNs ?65535. So be it. That date should neither be accelerated nor decelerated by ARIN policy. It would be helpful if you could explain how in some detail, given that there appears to be sufficient number of lower range 4-byte ASNs for those who require such for their operations, and further that the supply appears to be sufficient for quite some time (potentially till there is greater acceptance and far fewer hurdles with the use of higher range 4-byte ASNs?) So far, I haven?t seen so much a requirement as a convenience request for those lower numbers. Understood, however, we have folks who have expressed that higher-range 4-byte ASN?s pose additional technical challenges to their operations, so that remains an active point of discussion. If ARIN were to issue AS numbers strictly from smallest to largest, is it your belief that those who feel they need lower-range AS numbers should engage in an NRPM 8.3 transfer to obtain such? (or would you also want policy change to prohibit that as an option?) Thanks! /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From michel at arneill-py.sacramento.ca.us Mon Apr 11 18:59:47 2016 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Mon, 11 Apr 2016 22:59:47 +0000 Subject: [arin-ppml] ARIN 2-Byte ASN inventory and issuance In-Reply-To: <5746CA86-58A5-4FAB-8A38-C45AD3B297D3@delong.com> References: <57015A09.2030901@quark.net> <5707D70D.2040805@quark.net> <767503C3-7237-44C8-89DE-C03B6E4EFA3B@delong.com> <44A08FD2-D764-4D45-8C3A-FE0DE2827A0E@semihuman.com> <5746CA86-58A5-4FAB-8A38-C45AD3B297D3@delong.com> Message-ID: > Owen DeLong wrote : > However, if you have a configuration using extended communities and full support of modern ASNs enabled on > your router, then all ASNs are treated as 32-bit ASNs and there is no fundamental difference remaining. Big if, and in reality this is simply untrue. For large and /or heterogeneous networks, there will be a need to deal with both for quite a number of years. Event with compliant gear, there is always some legacy stuff somewhere else that has not been upgraded yet. Using extended communities is just the same as operating dual-stack : twice the number of things to manage, and a bridge to build between the old ones and the new ones. Two different configuration lines. Two sets of regexp to match. Limitations in extended communities that did not exist with the old ones. I gave examples recently. Show me in the real-world where old-style BGP communities have been completely deprecated. Moving to extended communities is time consuming, prone to mistakes, and not simple. Trying to argue that you can treat all AS numbers the same way is the same as trying to pretend that operating an IPv6-only network is simple. Let's not make with extended communities and 4-byte ASNs the same mistake we made with IPv6 : for the foreseeable future, we will have to deal with 2-byte ASNs, non-extended communities, and IPv4. Here is the real question : do we want a grey market for 2-byte ASNs ? because as long as they are easier to use than 4-byte ones, there will be a value attached to them. Michel. From owen at delong.com Mon Apr 11 20:03:13 2016 From: owen at delong.com (Owen DeLong) Date: Mon, 11 Apr 2016 17:03:13 -0700 Subject: [arin-ppml] ARIN 2-Byte ASN inventory and issuance In-Reply-To: <8DBB340C-2D96-41F2-A9A8-DD17BEC2AC80@semihuman.com> References: <57015A09.2030901@quark.net> <5707D70D.2040805@quark.net> <767503C3-7237-44C8-89DE-C03B6E4EFA3B@delong.com> <44A08FD2-D764-4D45-8C3A-FE0DE2827A0E@semihuman.com> <5746CA86-58A5-4FAB-8A38-C45AD3B297D3@delong.com> <8DBB340C-2D96-41F2-A9A8-DD17BEC2AC80@semihuman.com> Message-ID: <2AD2F874-E3FB-4D8A-8C9D-159455B3F64E@delong.com> The harm is that this continued practice is hampering deployment of exchange point RS with artificial imposition of requirements for ASNs ?65535 for no reason other than the convenience of operators who come to the exchange(s) with obsolete equipment or antiquated policies. Owen > On Apr 11, 2016, at 15:25 , Chris Woodfield wrote: > > I?ll note that there are some pretty substantial ?ifs? in your statement there. Not all operators are in a position to satisfy those ?ifs?. > > Also, how is this behavior harmful? What operational issues arise from use of the backward-compatible mode here? Is it just a matter of not being able to see other ASNs with 23456 in path if you?re running in compatibility mode? If so, that?s not going to impact anyone but the operator itself (which IMO should be motivation enough to upgrade, but I don?t control those operator?s budgets). > > -C > >> On Apr 11, 2016, at 3:08 PM, Owen DeLong > wrote: >> >> >>> On Apr 11, 2016, at 15:05 , Chris Woodfield > wrote: >>> >>> I?d argue that doing so ignores the fact that 2-byte vs 4-byte AS numbers (yes, I?m still using that terminology, so sue me) are handled fundamentally differently by the BGP protocol. As such, this isn?t a place where we can effectively boil the ocean and force providers to update their hardware via policy. >> >> Actually, they aren?t treated at all differently if you are using the modern configuration options. >> >> Sure, if you are continuing to use traditional communities, you are limited to low-order ASNs in the ASN portion of the community string. >> >> Sure, there?s a certain amount of backwards-compatible handling of ASPATH management in modern routers and that code still gets occasionally exercised in interacting with ancient equipment still in operation. >> >> However, if you have a configuration using extended communities and full support of modern ASNs enabled on your router, then all ASNs are treated as 32-bit ASNs and there is no fundamental difference remaining. >> >> There?s no attempt to boil the ocean and force providers. Merely an attempt to recognize that the days of treating them differently have, in fact, passed in most of the world and we shouldn?t be further enabling the harmful behavior of pretending otherwise. >> >> If this is such a huge issue, why isn?t it coming up in the other RIRs? >> >> Owen >> >>> >>> As such, I?d far prefer that *as available* we continue to keep 2-byte ASNs in reserve for providers who can document their reasons for not being able to support having a 4-byte ASNs. Obviously there will be a day where those are all gone and then we?ll have no choice but to force operators to run compliant hardware/software. >>> >>> Note I?m making it clear that this isn?t just a matter of software; there?s quite a bit of gear out there on the internet that doesn?t have available software at all that supports 4-byte ASNs. And there are definitely operators that don?t have the budget to swap it out. >>> >>> This isn?t a case of inefficiency, it?s simply the fact that many providers are stuck using old hardware. Given negligible cost to accommodate, I have no problem doing so. >>> >>> Thanks, >>> >>> -C >>> >>>> On Apr 11, 2016, at 2:53 PM, Owen DeLong > wrote: >>>> >>>>> >>>>> On Apr 11, 2016, at 14:38 , John Curran > wrote: >>>>> >>>>> On Apr 11, 2016, at 5:06 PM, Owen DeLong > wrote: >>>>>> >>>>>> On Apr 11, 2016, at 12:24 , John Curran > wrote: >>>>>>> Since parties coming to ARIN are distinguishing between these classes of 4-byte ASNs >>>>>>> and come back explicitly asking for one ?65535, are you suggesting that ARIN not hold >>>>>>> these lower ones to be able to satisfy such requests? >>>>>> >>>>>> Yes. >>>>>> >>>>>> I believe that we, more than any other region, have been lazy in our adoption of current internet technologies to the detriment of the internet at large. >>>>>> >>>>>> I believe that continuing to facilitate this is not providing a useful service to the internet as a whole. >>>>> >>>>> Just to be clear, you feel that ARIN registry policy which rapidly depletes the >>>>> lower range of 4-byte ASNs would be technically sound and facilitate fair and >>>>> impartial number resource administration? >>>> >>>> No. I believe that ARIN registry policy which ignores any previous distinction >>>> between ASNs ?65535 and ASNs ?65536 is harmful. I believe that a policy which >>>> makes no distinction and hands them out as if they were a single pool of 32-bit >>>> numbers is in the best interests of the community. >>>> >>>> At some point there will no longer be available ASNs ?65535. So be it. That >>>> date should neither be accelerated nor decelerated by ARIN policy. >>>> >>>>> It would be helpful if you could explain how in some detail, given that there >>>>> appears to be sufficient number of lower range 4-byte ASNs for those who >>>>> require such for their operations, and further that the supply appears to be >>>>> sufficient for quite some time (potentially till there is greater acceptance >>>>> and far fewer hurdles with the use of higher range 4-byte ASNs?) >>>> >>>> So far, I haven?t seen so much a requirement as a convenience request for those >>>> lower numbers. >>>> >>>> Owen >>>> >>>> _______________________________________________ >>>> PPML >>>> You are receiving this message because you are subscribed to >>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). >>>> Unsubscribe or manage your mailing list subscription at: >>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>> Please contact info at arin.net if you experience any issues. >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Mon Apr 11 20:05:17 2016 From: owen at delong.com (Owen DeLong) Date: Mon, 11 Apr 2016 17:05:17 -0700 Subject: [arin-ppml] ARIN 2-Byte ASN inventory and issuance In-Reply-To: <9C5608C2-8BE2-4322-8D66-66A8CCFC3CE9@arin.net> References: <57015A09.2030901@quark.net> <5707D70D.2040805@quark.net> <767503C3-7237-44C8-89DE-C03B6E4EFA3B@delong.com> <9C5608C2-8BE2-4322-8D66-66A8CCFC3CE9@arin.net> Message-ID: > On Apr 11, 2016, at 15:24 , John Curran wrote: > > On Apr 11, 2016, at 5:53 PM, Owen DeLong > wrote: >>> Just to be clear, you feel that ARIN registry policy which rapidly depletes the >>> lower range of 4-byte ASNs would be technically sound and facilitate fair and >>> impartial number resource administration? >> >> No. I believe that ARIN registry policy which ignores any previous distinction >> between ASNs ?65535 and ASNs ?65536 is harmful. I believe that a policy which >> makes no distinction and hands them out as if they were a single pool of 32-bit >> numbers is in the best interests of the community. > > Alas, within the scope of ARIN?s mission, the best interests of the community are > met by registry policy which is technically sound and facilitates fair and impartial > number resource administration (hence the reason I asked you to elaborate on > those aspects, if any were applicable to your position.) > >> At some point there will no longer be available ASNs ?65535. So be it. That >> date should neither be accelerated nor decelerated by ARIN policy. >> >>> It would be helpful if you could explain how in some detail, given that there >>> appears to be sufficient number of lower range 4-byte ASNs for those who >>> require such for their operations, and further that the supply appears to be >>> sufficient for quite some time (potentially till there is greater acceptance >>> and far fewer hurdles with the use of higher range 4-byte ASNs?) >> >> So far, I haven?t seen so much a requirement as a convenience request for those >> lower numbers. > > Understood, however, we have folks who have expressed that higher-range > 4-byte ASN?s pose additional technical challenges to their operations, so that > remains an active point of discussion. > > If ARIN were to issue AS numbers strictly from smallest to largest, is it your > belief that those who feel they need lower-range AS numbers should engage > in an NRPM 8.3 transfer to obtain such? (or would you also want policy change > to prohibit that as an option?) I?m not making any suggestions about the order in which ARIN issues AS Numbers. I?m simply suggesting that we stop treating AS Numbers as anything other than a single collective pool of 32 bit integers from which ARIN issues them. High to low, low to high, or random order is fine with me. However, the community adopted a policy that said ARIN is to treat them as a single pool of 32-bit identifiers and so long as we continue to ask questions like this in the application process, it?s pretty clear that policy isn?t being followed. Owen -------------- next part -------------- An HTML attachment was scrubbed... URL: From michel at arneill-py.sacramento.ca.us Mon Apr 11 20:09:46 2016 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Tue, 12 Apr 2016 00:09:46 +0000 Subject: [arin-ppml] ARIN 2-Byte ASN inventory and issuance In-Reply-To: <2AD2F874-E3FB-4D8A-8C9D-159455B3F64E@delong.com> References: <57015A09.2030901@quark.net> <5707D70D.2040805@quark.net> <767503C3-7237-44C8-89DE-C03B6E4EFA3B@delong.com> <44A08FD2-D764-4D45-8C3A-FE0DE2827A0E@semihuman.com> <5746CA86-58A5-4FAB-8A38-C45AD3B297D3@delong.com> <8DBB340C-2D96-41F2-A9A8-DD17BEC2AC80@semihuman.com> <2AD2F874-E3FB-4D8A-8C9D-159455B3F64E@delong.com> Message-ID: > Owen DeLong wrote : > The harm is that this continued practice is hampering deployment of exchange point RS with artificial imposition of requirements for ASNs > ?65535 for no reason other than the convenience of operators who come to the exchange(s) with obsolete equipment or antiquated policies. And if said operator can't get it their way, they go somewhere else and the only one hurt is the new IX tying to impose a new world order. The ones who already have a 2-byte ASN are going to like the depletion : no new competitors. It's not a shortage, it's a feature. Michel. From owen at delong.com Mon Apr 11 20:09:03 2016 From: owen at delong.com (Owen DeLong) Date: Mon, 11 Apr 2016 17:09:03 -0700 Subject: [arin-ppml] ARIN 2-Byte ASN inventory and issuance In-Reply-To: References: <57015A09.2030901@quark.net> <5707D70D.2040805@quark.net> <767503C3-7237-44C8-89DE-C03B6E4EFA3B@delong.com> <44A08FD2-D764-4D45-8C3A-FE0DE2827A0E@semihuman.com> <5746CA86-58A5-4FAB-8A38-C45AD3B297D3@delong.com> Message-ID: <4C801582-A4DC-410F-960B-85DBD7380B11@delong.com> > On Apr 11, 2016, at 15:59 , Michel Py wrote: > >> Owen DeLong wrote : >> However, if you have a configuration using extended communities and full support of modern ASNs enabled on >> your router, then all ASNs are treated as 32-bit ASNs and there is no fundamental difference remaining. > > Big if, and in reality this is simply untrue. For large and /or heterogeneous networks, there will be a need to deal with both for quite a number of years. Event with compliant gear, there is always some legacy stuff somewhere else that has not been upgraded yet. Using extended communities is just the same as operating dual-stack : twice the number of things to manage, and a bridge to build between the old ones and the new ones. > Two different configuration lines. Two sets of regexp to match. Limitations in extended communities that did not exist with the old ones. > > I gave examples recently. Show me in the real-world where old-style BGP communities have been completely deprecated. > > Moving to extended communities is time consuming, prone to mistakes, and not simple. Trying to argue that you can treat all AS numbers the same way is the same as trying to pretend that operating an IPv6-only network is simple. Let's not make with extended communities and 4-byte ASNs the same mistake we made with IPv6 : for the foreseeable future, we will have to deal with 2-byte ASNs, non-extended communities, and IPv4. Operating an IPv6-only network is actually a lot simpler than operating an IPv4-capable network. The only draw-back being the inability to reach the fraction of the internet that has not yet deployed working IPv6. I admit that today, that is a huge limitation for an IPv6-only network rendering doing so quite impractical, but as to the simplicity of doing so, that?s quite well established. However, there?s a lot less of an issue with communities as there isn?t really an inability to reach providers that don?t support extended communities if you start using them. > Here is the real question : do we want a grey market for 2-byte ASNs ? because as long as they are easier to use than 4-byte ones, there will be a value attached to them. I?m simply not going to dignify another bogey-man argument. Owen From owen at delong.com Mon Apr 11 20:27:03 2016 From: owen at delong.com (Owen DeLong) Date: Mon, 11 Apr 2016 17:27:03 -0700 Subject: [arin-ppml] ARIN 2-Byte ASN inventory and issuance In-Reply-To: References: <57015A09.2030901@quark.net> <5707D70D.2040805@quark.net> <767503C3-7237-44C8-89DE-C03B6E4EFA3B@delong.com> <44A08FD2-D764-4D45-8C3A-FE0DE2827A0E@semihuman.com> <5746CA86-58A5-4FAB-8A38-C45AD3B297D3@delong.com> <8DBB340C-2D96-41F2-A9A8-DD17BEC2AC80@semihuman.com> <2AD2F874-E3FB-4D8A-8C9D-159455B3F64E@delong.com> Message-ID: > On Apr 11, 2016, at 17:09 , Michel Py wrote: > >> Owen DeLong wrote : >> The harm is that this continued practice is hampering deployment of exchange point RS with artificial imposition of requirements for ASNs >> ?65535 for no reason other than the convenience of operators who come to the exchange(s) with obsolete equipment or antiquated policies. > > And if said operator can't get it their way, they go somewhere else and the only one hurt is the new IX tying to impose a new world order. The ones who already have a 2-byte ASN are going to like the depletion : no new competitors. It's not a shortage, it's a feature. > > Michel. > In my experience, there is rarely significant competition among exchange points anywhere other than primary cities. In fact, in most secondary and smaller cities, competing exchange points usually turn out to be harmful to the community and consolidation ends up happening relatively quickly anyway. Owen From michel at arneill-py.sacramento.ca.us Mon Apr 11 20:44:51 2016 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Tue, 12 Apr 2016 00:44:51 +0000 Subject: [arin-ppml] ARIN 2-Byte ASN inventory and issuance In-Reply-To: <4C801582-A4DC-410F-960B-85DBD7380B11@delong.com> References: <57015A09.2030901@quark.net> <5707D70D.2040805@quark.net> <767503C3-7237-44C8-89DE-C03B6E4EFA3B@delong.com> <44A08FD2-D764-4D45-8C3A-FE0DE2827A0E@semihuman.com> <5746CA86-58A5-4FAB-8A38-C45AD3B297D3@delong.com> <4C801582-A4DC-410F-960B-85DBD7380B11@delong.com> Message-ID: > Owen DeLong wrote : > Operating an IPv6-only network is actually a lot simpler than operating an IPv4-capable network. The only draw-back > being the inability to reach the fraction of the internet that has not yet deployed working IPv6. Which, after 15 years, still is 90%. There was a lot of FUD about IPv4 shortage, and all that FUD has done is to accelerate people hoarding IPv4 addresses to have them available now. If we accelerate the shortage of 2-byte ASNs, everyone is going to find a good reason to hoard them and deny access to the new players in 5 years. This is the exact situation we have with IPv4. Got some when it was easy ? Good, now there is a new market as renting PA space and newcomers are left with that. It did not help IPv6 being deployed, just made the organizations who had extra IPv4 happy. Do you want to do the same with 2-byte ASNs ? I support keeping things as they are : give a 4-byte ASN by default, give a 2-byte ASN to those who have a good reason to need one. Let's not make more FUD, let's look at reality. Can one operate a new IX with a 4-byte ASN ? So far nobody but me has posted a single line of config for any platform detailing why or why not. Michel. From rudi.daniel at gmail.com Tue Apr 12 06:35:47 2016 From: rudi.daniel at gmail.com (Rudolph Daniel) Date: Tue, 12 Apr 2016 06:35:47 -0400 Subject: [arin-ppml] ARIN-PPML 2015-2 Message-ID: Question: how often does Arin staff encounter this anomaly if I can call it that? RD On Apr 11, 2016 12:00 PM, wrote: > Send ARIN-PPML mailing list submissions to > arin-ppml at arin.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.arin.net/mailman/listinfo/arin-ppml > or, via email, send a message with subject or body 'help' to > arin-ppml-request at arin.net > > You can reach the person managing the list at > arin-ppml-owner at arin.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of ARIN-PPML digest..." > > > Today's Topics: > > 1. Revision to Text of Draft Policy ARIN-2015-2 (Christian Tacit) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 11 Apr 2016 14:50:32 +0000 > From: Christian Tacit > To: "arin-ppml at arin.net" > Subject: [arin-ppml] Revision to Text of Draft Policy ARIN-2015-2 > Message-ID: <9851d5ee8a334febaf54742028e5bb1b at S05-MBX03-12.S05.local> > Content-Type: text/plain; charset="us-ascii" > > Dear Community Members: > I am writing to advise of additional changes made today to the text of > Draft Policy ARIN-2015-2. > In the Staff and Legal analysis obtained, General Counsel expressed > concerns about the proposed definitions of "affiliated" and "control". In > light of these concerns and other efforts to simplify the text further, I > have amended the text once again. The new amendments achieve the same > intent as the previous language using much simpler and more concise > language. The revised draft proposal is: > > "Problem Statement: > > Organizations that obtain a 24 month supply of IP addresses via the > transfer market and then have an unexpected change in business plan are > unable to move IP addresses to the proper RIR within the first 12 months of > receipt. > > Policy statement: > Replace 8.4, bullet 4, to read: > "Source entities within the ARIN region must not have received a transfer, > allocation, or assignment of IPv4 number resources from ARIN for the 12 > months prior to the approval of a transfer request, unless either the > source and recipient entities own or control each other or are under common > ownership or control. This restriction does not include M&A transfers." > Comments: Organizations that obtain a 24 month supply of IP addresses via > the transfer market and then have an unexpected change in business plan are > unable to move IP addresses to the proper RIR within the first 12 months of > receipt. The need to move the resources does not flow from ARIN policy, but > rather from the requirement of certain registries outside the ARIN region > to have the resources moved in order to be used there. > The intention of this change is to allow organizations to perform > inter-RIR transfers of space received via an 8.3 transfer regardless of the > date transferred to ARIN. A common example is that an organization acquires > a block located in the ARIN region, transfers it to ARIN, then 3 months > later, the organization announces that it wants to launch new services out > of region. Under current policy, the organization is prohibited from moving > some or all of those addresses to that region's Whois if there is a need to > move them to satisfy the rules of the other region requiring the movement > of the resources to that region in order for them to be used there. > Instead, the numbers are locked in ARIN's Whois. It's important to note > that 8.3 transfers are approved for a 24 month supply, and it would not be > unheard of for a business model to change within the first 12 months after > approval. The proposal also introduces a requirement for an affiliation > relationship between the source and r > ecipient entity, based on established corporate law principles, so as to > make it reasonably likely that eliminating the 12 month anti-flip period in > that situation will meet the needs of organizations that operate networks > in more than one region without encouraging abuse. > a. Timetable for implementation: Immediate > b. Anything else: N/A" > Chris Tacit > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://lists.arin.net/pipermail/arin-ppml/attachments/20160411/d3ecf3f6/attachment-0001.html > > > > ------------------------------ > > _______________________________________________ > ARIN-PPML mailing list > ARIN-PPML at arin.net > http://lists.arin.net/mailman/listinfo/arin-ppml > > End of ARIN-PPML Digest, Vol 130, Issue 18 > ****************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Tue Apr 12 06:38:21 2016 From: jcurran at arin.net (John Curran) Date: Tue, 12 Apr 2016 10:38:21 +0000 Subject: [arin-ppml] ARIN-PPML 2015-2 In-Reply-To: References: Message-ID: <3DAAC4EA-60EC-4837-A1FC-D1D0FFD58308@corp.arin.net> > On Apr 12, 2016, at 6:35 AM, Rudolph Daniel wrote: > > Question: how often does Arin staff encounter this anomaly if I can call it that? > Rudi - If by ?anomaly?, you mean an 'unexpected change in business plans? , it is infrequent but does occur. We will see if we can better characterize the frequency and report back. Thanks! /John John Curran President and CEO ARIN From rjletts at uw.edu Tue Apr 12 10:46:22 2016 From: rjletts at uw.edu (Richard J. Letts) Date: Tue, 12 Apr 2016 14:46:22 +0000 Subject: [arin-ppml] ARIN 2-Byte ASN inventory and issuance In-Reply-To: <2AD2F874-E3FB-4D8A-8C9D-159455B3F64E@delong.com> References: <57015A09.2030901@quark.net> <5707D70D.2040805@quark.net> <767503C3-7237-44C8-89DE-C03B6E4EFA3B@delong.com> <44A08FD2-D764-4D45-8C3A-FE0DE2827A0E@semihuman.com> <5746CA86-58A5-4FAB-8A38-C45AD3B297D3@delong.com> <8DBB340C-2D96-41F2-A9A8-DD17BEC2AC80@semihuman.com> <2AD2F874-E3FB-4D8A-8C9D-159455B3F64E@delong.com> Message-ID: This is a commercial view of the world; Part of the network here is a SDN network where we build layer-1 optical or layer-2 VPN with research organizations spread from Chicago and El Paso to Tokyo. I have no control over the equipment at the remote end; I don?t want to have to argue with a research team about how they ought to upgrade or run their equipment, I need the easiest way I can to setup BGP peering for a fragment of our address space without breaking the whole of routing for campus. Yes, obtaining a 2-byte ASN was for the convenience of me not arguing with a network engineer in Tokyo, Qatar, or West, Texas about them upgrading their equipment because frankly, for my users, it?s all about the research and moving train-loads of data as quickly as possible. Thank you Richard Letts From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong Sent: Monday, April 11, 2016 5:03 PM To: Chris Woodfield Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] ARIN 2-Byte ASN inventory and issuance The harm is that this continued practice is hampering deployment of exchange point RS with artificial imposition of requirements for ASNs ?65535 for no reason other than the convenience of operators who come to the exchange(s) with obsolete equipment or antiquated policies. Owen On Apr 11, 2016, at 15:25 , Chris Woodfield > wrote: I?ll note that there are some pretty substantial ?ifs? in your statement there. Not all operators are in a position to satisfy those ?ifs?. Also, how is this behavior harmful? What operational issues arise from use of the backward-compatible mode here? Is it just a matter of not being able to see other ASNs with 23456 in path if you?re running in compatibility mode? If so, that?s not going to impact anyone but the operator itself (which IMO should be motivation enough to upgrade, but I don?t control those operator?s budgets). -C On Apr 11, 2016, at 3:08 PM, Owen DeLong > wrote: On Apr 11, 2016, at 15:05 , Chris Woodfield > wrote: I?d argue that doing so ignores the fact that 2-byte vs 4-byte AS numbers (yes, I?m still using that terminology, so sue me) are handled fundamentally differently by the BGP protocol. As such, this isn?t a place where we can effectively boil the ocean and force providers to update their hardware via policy. Actually, they aren?t treated at all differently if you are using the modern configuration options. Sure, if you are continuing to use traditional communities, you are limited to low-order ASNs in the ASN portion of the community string. Sure, there?s a certain amount of backwards-compatible handling of ASPATH management in modern routers and that code still gets occasionally exercised in interacting with ancient equipment still in operation. However, if you have a configuration using extended communities and full support of modern ASNs enabled on your router, then all ASNs are treated as 32-bit ASNs and there is no fundamental difference remaining. There?s no attempt to boil the ocean and force providers. Merely an attempt to recognize that the days of treating them differently have, in fact, passed in most of the world and we shouldn?t be further enabling the harmful behavior of pretending otherwise. If this is such a huge issue, why isn?t it coming up in the other RIRs? Owen As such, I?d far prefer that *as available* we continue to keep 2-byte ASNs in reserve for providers who can document their reasons for not being able to support having a 4-byte ASNs. Obviously there will be a day where those are all gone and then we?ll have no choice but to force operators to run compliant hardware/software. Note I?m making it clear that this isn?t just a matter of software; there?s quite a bit of gear out there on the internet that doesn?t have available software at all that supports 4-byte ASNs. And there are definitely operators that don?t have the budget to swap it out. This isn?t a case of inefficiency, it?s simply the fact that many providers are stuck using old hardware. Given negligible cost to accommodate, I have no problem doing so. Thanks, -C On Apr 11, 2016, at 2:53 PM, Owen DeLong > wrote: On Apr 11, 2016, at 14:38 , John Curran > wrote: On Apr 11, 2016, at 5:06 PM, Owen DeLong > wrote: On Apr 11, 2016, at 12:24 , John Curran > wrote: Since parties coming to ARIN are distinguishing between these classes of 4-byte ASNs and come back explicitly asking for one ?65535, are you suggesting that ARIN not hold these lower ones to be able to satisfy such requests? Yes. I believe that we, more than any other region, have been lazy in our adoption of current internet technologies to the detriment of the internet at large. I believe that continuing to facilitate this is not providing a useful service to the internet as a whole. Just to be clear, you feel that ARIN registry policy which rapidly depletes the lower range of 4-byte ASNs would be technically sound and facilitate fair and impartial number resource administration? No. I believe that ARIN registry policy which ignores any previous distinction between ASNs ?65535 and ASNs ?65536 is harmful. I believe that a policy which makes no distinction and hands them out as if they were a single pool of 32-bit numbers is in the best interests of the community. At some point there will no longer be available ASNs ?65535. So be it. That date should neither be accelerated nor decelerated by ARIN policy. It would be helpful if you could explain how in some detail, given that there appears to be sufficient number of lower range 4-byte ASNs for those who require such for their operations, and further that the supply appears to be sufficient for quite some time (potentially till there is greater acceptance and far fewer hurdles with the use of higher range 4-byte ASNs?) So far, I haven?t seen so much a requirement as a convenience request for those lower numbers. Owen _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From narten at us.ibm.com Fri Apr 15 00:53:03 2016 From: narten at us.ibm.com (narten at us.ibm.com) Date: Fri, 15 Apr 2016 00:53:03 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201604150453.u3F4r3QU014151@rotala.raleigh.ibm.com> Total of 32 messages in the last 7 days. script run at: Fri Apr 15 00:53:02 EDT 2016 Messages | Bytes | Who --------+------+--------+----------+------------------------ 28.12% | 9 | 27.91% | 167615 | owen at delong.com 9.38% | 3 | 15.62% | 93787 | chris at semihuman.com 12.50% | 4 | 8.34% | 50058 | jcurran at arin.net 6.25% | 2 | 14.32% | 86002 | rjletts at uw.edu 12.50% | 4 | 4.94% | 29633 | michel at arneill-py.sacramento.ca.us 6.25% | 2 | 6.04% | 36248 | bjones at vt.edu 3.12% | 1 | 4.48% | 26917 | david_huberman at outlook.com 3.12% | 1 | 4.15% | 24894 | milton at gatech.edu 3.12% | 1 | 3.36% | 20158 | andrew.dul at quark.net 3.12% | 1 | 2.85% | 17123 | rudi.daniel at gmail.com 3.12% | 1 | 2.63% | 15767 | ctacit at tacitlaw.com 3.12% | 1 | 2.32% | 13931 | farmer at umn.edu 3.12% | 1 | 1.79% | 10733 | scottleibrand at gmail.com 3.12% | 1 | 1.26% | 7585 | narten at us.ibm.com --------+------+--------+----------+------------------------ 100.00% | 32 |100.00% | 600451 | Total From gary.buhrmaster at gmail.com Tue Apr 19 21:18:40 2016 From: gary.buhrmaster at gmail.com (Gary Buhrmaster) Date: Wed, 20 Apr 2016 01:18:40 +0000 Subject: [arin-ppml] Draft Policy ARIN-2016-1: Reserved Pool Transfer Policy In-Reply-To: <26041E0D-0DDD-4395-AEDA-1B5D2FCEB37B@delong.com> References: <56F178F9.7020608@arin.net> <26041E0D-0DDD-4395-AEDA-1B5D2FCEB37B@delong.com> Message-ID: On Mon, Apr 11, 2016 at 5:43 PM, Owen DeLong wrote: .... > I?d be OK with this, but given that there is remaining free pool for these resources, I?m not sure that it isn?t better to have a clear policy that when the resources in these categories are no longer needed, voluntary return to ARIN is expected. On Monday, there was discussion (during policy experience report) about ARIN not being able to provide "theoretical" pre-qualifications in the case where (in the example) you transfer a /16 to someone, and would want to get a /24 from somewhere else. And while most steeped in the ARIN process understand that qualifying is an almost certainty, that does not take it to the level some seem to need to feel entirely comfortable. As far as this proposal, I can imagine there to be cases were a transfer may only make sense if the receiving org can be assured that they will be able to get the IP numbers from a reserved pool which ARIN cannot make assurance on in advance. And while (as before) everyone may be (almost) 100% sure that the recipient will qualify, that does not always make everyone sufficiently comfortable. It would seem to be nice for a 8.3 transfer which happens to include reserved pool space not turn into another policy experience report bullet for not being able to successfully transfer (worst case?) "CI" space if indeed the recipient would otherwise qualify (and potentially force a renumber of such resources for no particular policy reason). I do agree with Owen that these cases are unlikely. And regardless of whether the (what I think is) better language as proposed by Scott is included, I would support the policy moving forward to address the problem statement. From jay at impulse.net Wed Apr 20 19:47:35 2016 From: jay at impulse.net (Jay Hennigan) Date: Wed, 20 Apr 2016 16:47:35 -0700 Subject: [arin-ppml] Spam from ipv4seller.com AKA ipv4salvation.com aka slashnineteen.com Message-ID: <57181517.5090403@impulse.net> I am getting numerous unsolicited emails at ARIN contact addresses from the above outfit wanting to buy our IPv4 netblocks. Included in the body of the email is the ARIN "Facilitator" logo as well as the other RIRs. Is this in any way sanctioned or authorized by ARIN? If not could we get cease-and-desist please? If so, please reconsider! And, to the entities responsible for [74.91.86.114] (mail origin IP) and [97.74.42.79] (spamvertized website), could we get a LART, please? I'm happy to send spam samples with headers off-list on request. -- Jay Hennigan | jay at impulse.net | CCIE #7880 | WB6RDV Chief Network Architect | Impulse Advanced Communications direct 805.884.6323 | fax 805.880.1523 | www.impulse.net From jcurran at arin.net Thu Apr 21 08:46:33 2016 From: jcurran at arin.net (John Curran) Date: Thu, 21 Apr 2016 12:46:33 +0000 Subject: [arin-ppml] Spam from ipv4seller.com AKA ipv4salvation.com aka slashnineteen.com In-Reply-To: <57181517.5090403@impulse.net> References: <57181517.5090403@impulse.net> Message-ID: <026486FB-ED6B-40B6-A443-F0A123D3BF6A@corp.arin.net> Jay - Thanks for the report. Please forward me the messages with the full headers and we will pursue. (We?ve had some other reports in the last day which may be related) /John John Curran President and CEO ARIN > On Apr 20, 2016, at 6:47 PM, Jay Hennigan wrote: > > I am getting numerous unsolicited emails at ARIN contact addresses from the above outfit wanting to buy our IPv4 netblocks. Included in the body of the email is the ARIN "Facilitator" logo as well as the other RIRs. > > Is this in any way sanctioned or authorized by ARIN? If not could we get cease-and-desist please? If so, please reconsider! > > And, to the entities responsible for [74.91.86.114] (mail origin IP) and [97.74.42.79] (spamvertized website), could we get a LART, please? > > I'm happy to send spam samples with headers off-list on request. > > -- > Jay Hennigan | jay at impulse.net | CCIE #7880 | WB6RDV > Chief Network Architect | Impulse Advanced Communications > direct 805.884.6323 | fax 805.880.1523 | www.impulse.net > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From narten at us.ibm.com Fri Apr 22 00:53:02 2016 From: narten at us.ibm.com (narten at us.ibm.com) Date: Fri, 22 Apr 2016 00:53:02 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201604220453.u3M4r2JG004558@rotala.raleigh.ibm.com> Total of 4 messages in the last 7 days. script run at: Fri Apr 22 00:53:01 EDT 2016 Messages | Bytes | Who --------+------+--------+----------+------------------------ 25.00% | 1 | 29.14% | 8266 | gary.buhrmaster at gmail.com 25.00% | 1 | 25.72% | 7296 | narten at us.ibm.com 25.00% | 1 | 24.93% | 7072 | jcurran at arin.net 25.00% | 1 | 20.21% | 5733 | jay at impulse.net --------+------+--------+----------+------------------------ 100.00% | 4 |100.00% | 28367 | Total From ctacit at tacitlaw.com Sun Apr 24 12:26:37 2016 From: ctacit at tacitlaw.com (Christian Tacit) Date: Sun, 24 Apr 2016 16:26:37 +0000 Subject: [arin-ppml] Proposed Editorial Revision to Current Text of Draft Policy ARIN-2015-2 Message-ID: Dear Community Members: I am writing to advise of some minor suggested editorial changes to the current text of Draft Policy ARIN-2015-2. The intent is to make ensure that the relationship between the source and recipient in the fourth bullet of section 8.4 of the NRPM is clearer. No substantive change is contemplated, and none has been requested following the previous text change, either on PPML or at ARIN 37. Please provide any comments you may have regarding these additional proposed changes as soon as possible. If no material objection is raised, I will modify the text of the proposal formally to reflect the wording below. "Problem Statement: Organizations that obtain a 24 month supply of IP addresses via the transfer market and then have an unexpected change in business plan are unable to move IP addresses to the proper RIR within the first 12 months of receipt. Policy statement: Replace 8.4, bullet 4, to read: "Source entities within the ARIN region must not have received a transfer, allocation, or assignment of IPv4 number resources from ARIN for the 12 months prior to the approval of a transfer request, unless either the source or recipient entity owns or controls the other, or both are under common ownership or control. This restriction does not include M&A transfers." Comments: Organizations that obtain a 24 month supply of IP addresses via the transfer market and then have an unexpected change in business plan are unable to move IP addresses to the proper RIR within the first 12 months of receipt. The need to move the resources does not flow from ARIN policy, but rather from the requirement of certain registries outside the ARIN region to have the resources moved in order to be used there. The intention of this change is to allow organizations to perform inter-RIR transfers of space received via an 8.3 transfer regardless of the date transferred to ARIN. A common example is that an organization acquires a block located in the ARIN region, transfers it to ARIN, then 3 months later, the organization announces that it wants to launch new services out of region. Under current policy, the organization is prohibited from moving some or all of those addresses to that region's Whois if there is a need to move them to satisfy the rules of the other region requiring the movement of the resources to that region in order for them to be used there. Instead, the numbers are locked in ARIN's Whois. It's important to note that 8.3 transfers are approved for a 24 month supply, and it would not be unheard of for a business model to change within the first 12 months after approval. The proposal also introduces a requirement for an affiliation relationship between the source and recipient entity, based on established corporate law principles, so as to make it reasonably likely that eliminating the 12 month anti-flip period in that situation will meet the needs of organizations that operate networks in more than one region without encouraging abuse. a. Timetable for implementation: Immediate b. Anything else: N/A" Thank you. Chris Tacit -------------- next part -------------- An HTML attachment was scrubbed... URL: From jschiller at google.com Mon Apr 25 10:40:43 2016 From: jschiller at google.com (Jason Schiller) Date: Mon, 25 Apr 2016 10:40:43 -0400 Subject: [arin-ppml] ARIN-2015-3: Staff interpretation needed Message-ID: After the topic of 2015-3 closed I was discussing the policy with some folks and there seems to be some confusion. If 2015-3 was current ARIN policy what would staff accept as an acceptable justification. It was my assumption that an ARIN ticket that said "We might have 9 million new customers in the next two years. We would like transfer approval for a /8. We are currently holding a /21 which we intend to keep." And an officer of the company attests to this. Then ARIN would accept this justification as sufficient. Others postulated that the amount of documentation required would be unchanged from what it previously was. For a two year transfer approval that is not based on a doubling of the previous 1 year run rate, a requester would still have to submit a business case supporting the two year growth need, and the officer would have to attest to that business case. The only difference here is that ARIN would not review the business case except that the project count of things in two years is more that 50% of what is requested plus what is held. This means ARIN would not review the supporting documentation of the business case, and leave that up to the officer of the requesting company to do. Is that correct? Additionally, can staff provide some statistics on the following: 1. over the last year how many end user transfer (pre-)approvals were justified based on past growth? 2. over the last year how many end user transfer (pre-)approvals were justified based on a future looking growth projection that was not based an past growth? 3. Of the requests in type 2 above, how many were: - Approved with no additional questions asked about the growth projection (not including the request for attestation)? - How many with one additional question about the growth projection? - How many with two or more additional questions about the growth projection? - How many were closed with no (pre-)approval during additional questions about the growth projection? - How many were left unresolved for 30 days or more (or abandoned) during additional questions about the growth projection I realize that some or all of the stats questions may take some time to answer. Please feel free to answer the first question about what documentation is required to be in the ticket and attested to, and any stats that are easily found, and follow up with the more time consuming stats later. Thanks, __Jason On Wed, Feb 17, 2016 at 1:19 PM, Jason Schiller wrote: > Just in case it wasn't clear, I oppose as written as it has no teeth and > can easily be an end user end-run around justified need. > > I support the change with some teeth so it is not likely to be an end-run > around justified need. > > __Jason > > > > On Tue, Feb 16, 2016 at 4:52 PM, Brian Jones wrote: > >> >> >> >> >> On Tue, Feb 16, 2016 at 3:51 PM, Richard J. Letts wrote: >> >>> My preference is to apply the policy change as written (with the minor >>> editorial change substituting "criterion" for "criteria".) >>> >> >> ?+1? >> -- >> Brian >> >> >>> >>> Thank you >>> Richard Letts >>> >>> > -----Original Message----- >>> > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] >>> On >>> > Behalf Of David Farmer >>> > Sent: Monday, February 15, 2016 9:23 PM >>> > To: ARIN PPML >>> > Subject: Re: [arin-ppml] ARIN-2015-3: Remove 30-Day Utilization >>> > Requirement in End-User IPv4 Policy >>> > >>> > As shepherd, I need additional feedback on this, I need a better sense >>> of >>> > what the community wants here. >>> > >>> > Should we move forward more or less as-is, with a minor editorial >>> change, >>> > substituting "criterion" for "criteria"? >>> > >>> > Or, does the community want to work on a way to address the concerns >>> > raised but Jason? >>> > >>> > Your input please. >>> > >>> > Thanks >>> > >>> > On 1/29/16 10:00 , Jason Schiller wrote: >>> > > McTim, >>> > > >>> > > WRT some other tangible and verifiable claim to show there was a real >>> > > commitment to use half the address space within one year... >>> > > >>> > > I think there are 3 choices: >>> > > >>> > > 1. Very vague >>> > > >>> > > Something like "there must be some tangible and verifiable claim to >>> > > show there was a real commitment to use half the address space within >>> > > one year and not just a future projection or business case" >>> > > >>> > > >>> > > 2. Open ended with some guidance for ARIN staff: >>> > > >>> > > Something like "there must be some tangible and verifiable claim to >>> > > show there was a real commitment to use half the address space within >>> > > one year and not just a future projection or business case. Some >>> > > examples include: >>> > > - list of equipment in hand to be numbered counting at least 25% of >>> > > requested IP size >>> > > - invoices showing equipment purchases demonstrating a commitment to >>> > > buy equipment to be numbered counting at least 25% of requested IP >>> > > size >>> > > - invoices showing equipment purchases demonstrating a commitment to >>> > > buy equipment to be numbered counting at least 50% of requested IP >>> > > size within one year >>> > > - lease agreements for real estate supporting equipment that is >>> > > appropratly sized to support equipment to be numbered counting at >>> > > least 50% of requested IP size >>> > > >>> > > 3. specific criterion >>> > > >>> > > ---- >>> > > >>> > > I don't know what it the right answer here, and suspect it has more >>> to >>> > > do with what the community is comfortable with. >>> > > >>> > > On one end of the spectrum is choice 1. This allows ARIN to do the >>> > > right thing. But this also is not clear about what the community >>> > > expects, and ARIN may act in a way that is counter to what is >>> > > anticipated, and may seem like ARIN is being arbitrary or has too >>> much >>> > > leeway to screw with requestors. >>> > > >>> > > The opposite end of the spectrum is choice 3. This sets a very clear >>> > > list of what qualifies. Hammering out that list may be very >>> > > difficult, and it is unlikely to be complete. This will leave little >>> > > or no room for ARIN to do the right thing and approve a request that >>> > > is justified, but not one of the criterion listed. >>> > > >>> > > Choice 2 is the middle ground. Where we have a not necessarily >>> > > complete list of criterion (so somewhat less difficulty in drawing up >>> > > the list) that creates a very clear expectation of what ARIN should >>> > > accept (and reduces the possibility that ARIN may act in a way that >>> is >>> > > counter to what is anticipated, and may seem like ARIN is being >>> > > arbitrary or has too much leeway to screw with requestors) with >>> > > respect to criterion clearly defined, while also allowing ARIN to do >>> > > the right thing with similar types of proof that are not explicitly >>> > > listed as criterion (this has somewhat higher risk that ARIN may act >>> > > in a way that is counter to what is anticipated, and may seem like >>> > > ARIN is being arbitrary or has too much leeway to screw with >>> > > requestors, but less risk than option 1 as the criterion should serve >>> > > as good guidance) >>> > > >>> > > >>> > > So two open questions to the community? >>> > > >>> > > 1. Is the community most comfortable with: >>> > > A. totally vague and open-ended such as "there must be some >>> > > tangible and verifiable claim to show there was a real commitment >>> to >>> > > use half the address space within one year and not just a future >>> > > projection or business case" >>> > > >>> > > B. A vague statement with some guidance as to some acceptable >>> > > forms of tangible verifiable proof of a real commitment to use half >>> > > the IP address within one year. >>> > > >>> > > C. A very clear list of what proof is considered acceptable >>> > > >>> > > >>> > > 2. If the community prefers B. guidance or C. a very clear list then >>> > > what sort of things would the community like to see on that list? >>> > > >>> > > >>> > > On Fri, Jan 29, 2016 at 8:27 AM, McTim >> > > > wrote: >>> > > >>> > > >>> > > >>> > > On Thu, Jan 28, 2016 at 4:52 PM, Jason Schiller >>> > > > wrote: >>> > > >>> > > I support the removal of the 30 day utilization as it is >>> > > unreasonable for any larger end-site, who may have a real >>> need >>> > > for say a /16, with 65,000 desktops arriving on a loading doc >>> > > next week, but an inability to unbox, configure and deploy >>> > > 16,384 to the various office locations in 30 days. >>> > > >>> > > >>> > > agreed. >>> > > >>> > > However, this is the only provision that has a real, >>> tangible, >>> > > and verifiable claim. Without this check justified need for >>> end >>> > > users simply becomes a 1 year future looking projection, and >>> > > with sufficient arm waving an easy end run around justified >>> need >>> > > for any end user with no IP space or if they are efficiently >>> > > using what they currently hold. >>> > > >>> > > >>> > > good point! >>> > > >>> > > I could get on board if the maximum sized block permitted on >>> a >>> > > purely future looking projection was a /24 and you had to >>> use it >>> > > prior to getting more. >>> > > >>> > > >>> > > +1 >>> > > >>> > > I could certainly get on board if there were some other >>> tangible >>> > > and verifiable claim to show there was a real commitment to >>> use >>> > > half the address space within one year. >>> > > >>> > > >>> > > Would this language suffice, or would we need a metric of some >>> sort? >>> > > >>> > > >>> > > Regards, >>> > > >>> > > McTim >>> > > >>> > > __Jason >>> > > >>> > > On Thu, Jan 28, 2016 at 8:55 AM, Brian Jones >> > > > wrote: >>> > > >>> > > Looks good to me Dave. I am okay with using criteria or >>> > > criterion, however using the strict definition it looks >>> as >>> > > though criterion is the proper singular form. >>> > > >>> > > -- >>> > > Brian >>> > > >>> > > On Wed, Jan 27, 2016 at 5:54 PM, David Farmer >>> > > > wrote: >>> > > >>> > > The following is the proposed update for ARIN-2015-3: >>> > > Remove 30-Day Utilization Requirement in End-User >>> IPv4 >>> > > Policy based on strong support in Montreal. >>> > > >>> > > Beyond deleting the 25% bullet as the policy says, >>> their >>> > > are editorial changes as follows to the remaining >>> > > text; >>> > > >>> > > - It looks weird to have single item bullet list, so >>> > > merge the two remaining sentence fragments into a >>> single >>> > > sentence. >>> > > - Change "are" to "is", since there is only one >>> > > remaining criteria >>> > > - Use of "criteria" as a singular is common usage, >>> even >>> > > though technically it's plural. >>> > > - Resulting in "The basic criteria that must be met >>> is a >>> > > 50% utilization rate within one year." >>> > > >>> > > The remaining and resulting text for 4.3.3 is now >>> > > included in the policy text, for editorial clarity. >>> The >>> > > original staff and legal suggested removing the >>> RFC2050 >>> > > reference and also pointed out that >>> > > 4.2.3.6 also has a 25% immediate use clause and a >>> > > RFC2050 reference. >>> > > >>> > > Feedback in Montreal was that deleting the 25% >>> immediate >>> > > use was a nice bite-sized change, and we shouldn't >>> try >>> > > to do more than that with this change, so those >>> changes >>> > > are not included at this time. >>> > > >>> > > Any additional feedback or comments are appreciated. >>> > > >>> > > Thanks >>> > > >>> > > --------- >>> > > >>> > > Draft Policy ARIN-2015-3: Remove 30 day utilization >>> > > requirement in end-user IPv4 policy >>> > > >>> > > Date: 27 January 2015 >>> > > >>> > > Problem Statement: >>> > > >>> > > End-user policy is intended to provide end-users >>> with a >>> > > one year supply of IP addresses. Qualification for a >>> > > one-year supply requires the network operator to >>> utilize >>> > > at least 25% of the requested addresses within 30 >>> days. >>> > > This text is unrealistic and should be removed. >>> > > >>> > > First, it often takes longer than 30 days to stage >>> > > equipment and start actually using the addresses. >>> > > >>> > > Second, growth is often not that regimented; the >>> > > forecast is to use X addresses over the course of a >>> > > year, not to use 25% of X within 30 days. >>> > > >>> > > Third, this policy text applies to additional address >>> > > space requests. It is incompatible with the >>> requirements >>> > > of other additional address space request >>> justification >>> > > which indicates that 80% utilization of existing >>> space >>> > > is sufficient to justify new space. If a block is at >>> > > 80%, then often (almost always?) the remaining 80% >>> will >>> > > be used over the next 30 days and longer. Therefore >>> the >>> > > operator cannot honestly state they will use 25% of >>> the >>> > > ADDITIONAL space within 30 days of receiving it; >>> they're >>> > > still trying to use their older block efficiently. >>> > > >>> > > Fourth, in the face of ARIN exhaustion, some ISPs are >>> > > starting to not give out /24 (or larger) blocks. So >>> the >>> > > justification for the 25% rule that previously >>> existed >>> > > (and in fact, applied for many years) is no longer >>> germane. >>> > > >>> > > Policy statement: >>> > > >>> > > Remove the 25% utilization criteria bullet point from >>> > > NRPM 4.3.3. >>> > > >>> > > Resulting text: >>> > > >>> > > 4.3.3. Utilization rate >>> > > >>> > > Utilization rate of address space is a key factor in >>> > > justifying a new >>> > > assignment of IP address space. Requesters must show >>> > > exactly how >>> > > previous address assignments have been utilized and >>> must >>> > > provide >>> > > appropriate details to verify their one-year growth >>> > > projection. >>> > > >>> > > The basic criteria that must be met is a 50% >>> utilization >>> > > rate within one year. >>> > > >>> > > A greater utilization rate may be required based on >>> > > individual network >>> > > requirements. Please refer to RFC 2050 for more >>> > > information on >>> > > utilization guidelines. >>> > > >>> > > Comments: >>> > > a.Timetable for implementation: Immediate >>> > > b.Anything else >>> > > >>> > > -- >>> > > ================================================ >>> > > David Farmer Email: farmer at 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 >>> > > >>> > > ================================================ >>> > > _______________________________________________ >>> > > PPML >>> > > You are receiving this message because you are >>> subscribed to >>> > > the ARIN Public Policy Mailing List ( >>> ARIN-PPML at arin.net >>> > > ). >>> > > Unsubscribe or manage your mailing list subscription >>> at: >>> > > http://lists.arin.net/mailman/listinfo/arin-ppml >>> > > Please contact info at arin.net >>> if >>> > > you experience any issues. >>> > > >>> > > >>> > > >>> > > _______________________________________________ >>> > > PPML >>> > > You are receiving this message because you are >>> subscribed to >>> > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net >>> > > ). >>> > > Unsubscribe or manage your mailing list subscription at: >>> > > http://lists.arin.net/mailman/listinfo/arin-ppml >>> > > Please contact info at arin.net if >>> you >>> > > experience any issues. >>> > > >>> > > >>> > > >>> > > >>> > > -- >>> > > >>> > _______________________________________________________ >>> > > Jason Schiller|NetOps|jschiller at google.com >>> > > |571-266-0006 >> > >>> > > >>> > > >>> > > _______________________________________________ >>> > > PPML >>> > > You are receiving this message because you are subscribed to >>> > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net >>> > > ). >>> > > Unsubscribe or manage your mailing list subscription at: >>> > > http://lists.arin.net/mailman/listinfo/arin-ppml >>> > > Please contact info at arin.net if you >>> > > experience any issues. >>> > > >>> > > >>> > > >>> > > >>> > > -- >>> > > Cheers, >>> > > >>> > > McTim >>> > > "A name indicates what we seek. An address indicates where it >>> is. A >>> > > route indicates how we get there." Jon Postel >>> > > >>> > > >>> > > >>> > > >>> > > -- >>> > > _______________________________________________________ >>> > > Jason Schiller|NetOps|jschiller at google.com >>> > > |571-266-0006 >>> > > >>> > > >>> > > >>> > > _______________________________________________ >>> > > PPML >>> > > You are receiving this message because you are subscribed to the ARIN >>> > > Public Policy Mailing List (ARIN-PPML at arin.net). >>> > > Unsubscribe or manage your mailing list subscription at: >>> > > http://lists.arin.net/mailman/listinfo/arin-ppml >>> > > Please contact info at arin.net if you experience any issues. >>> > > >>> > >>> > >>> > -- >>> > ================================================ >>> > David Farmer Email: farmer at 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 >>> > ================================================ >>> > _______________________________________________ >>> > PPML >>> > You are receiving this message because you are subscribed to the ARIN >>> > Public Policy Mailing List (ARIN-PPML at arin.net). >>> > Unsubscribe or manage your mailing list subscription at: >>> > http://lists.arin.net/mailman/listinfo/arin-ppml >>> > Please contact info at arin.net if you experience any issues. >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to >>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at arin.net if you experience any issues. >>> >> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> > > > > -- > _______________________________________________________ > Jason Schiller|NetOps|jschiller at google.com|571-266-0006 > > -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmer at umn.edu Mon Apr 25 10:53:33 2016 From: farmer at umn.edu (David Farmer) Date: Mon, 25 Apr 2016 09:53:33 -0500 Subject: [arin-ppml] ARIN-2015-3:(remove 30-day...) Staff interpretation needed Message-ID: I'm worried that people are confusing policy proposals; ARIN 2015-3:Remove 30 day utilization requirement in end-user IPv4 policy, simply removes the 25% immediate need (30-day) clause, it shouldn't really change anything else. On Mon, Apr 25, 2016 at 9:40 AM, Jason Schiller wrote: > After the topic of 2015-3 closed I was discussing the policy with some folks > and there seems to be some confusion. > > If 2015-3 was current ARIN policy what would staff accept as an acceptable > justification. > > It was my assumption that an ARIN ticket that said "We might have 9 million > new customers in the next two years. We would like transfer approval for a > /8. We are currently holding a /21 which we intend to keep." And an > officer of the company attests to this. Then ARIN would accept this > justification as sufficient. > > Others postulated that the amount of documentation required would be > unchanged from what it previously was. For a two year transfer approval > that is not based on a doubling of the previous 1 year run rate, a requester > would still have to submit a business case supporting the two year growth > need, and the officer would have to attest to that business case. The only > difference here is that ARIN would not review the business case except that > the project count of things in two years is more that 50% of what is > requested plus what is held. This means ARIN would not review the > supporting documentation of the business case, and leave that up to the > officer of the requesting company to do. Is that correct? > > > Additionally, can staff provide some statistics on the following: > > 1. over the last year how many end user transfer (pre-)approvals were > justified based on past growth? > > 2. over the last year how many end user transfer (pre-)approvals were > justified based on > a future looking growth projection that was not based an past growth? > > 3. Of the requests in type 2 above, how many were: > - Approved with no additional questions asked about the growth projection > (not including the request for attestation)? > - How many with one additional question about the growth projection? > - How many with two or more additional questions about the growth > projection? > - How many were closed with no (pre-)approval during additional questions > about the growth projection? > - How many were left unresolved for 30 days or more (or abandoned) during > additional questions about the growth projection > > > I realize that some or all of the stats questions may take some time to > answer. Please feel free to answer the first question about what > documentation is required to be in the ticket and attested to, and any stats > that are easily found, and follow up with the more time consuming stats > later. > > Thanks, > > __Jason > > > > On Wed, Feb 17, 2016 at 1:19 PM, Jason Schiller > wrote: >> >> Just in case it wasn't clear, I oppose as written as it has no teeth and >> can easily be an end user end-run around justified need. >> >> I support the change with some teeth so it is not likely to be an end-run >> around justified need. >> >> __Jason >> >> >> >> On Tue, Feb 16, 2016 at 4:52 PM, Brian Jones wrote: >>> >>> >>> >>> >>> >>> On Tue, Feb 16, 2016 at 3:51 PM, Richard J. Letts wrote: >>>> >>>> My preference is to apply the policy change as written (with the minor >>>> editorial change substituting "criterion" for "criteria".) >>> >>> >>> +1 >>> -- >>> Brian >>> >>>> >>>> >>>> Thank you >>>> Richard Letts >>>> >>>> > -----Original Message----- >>>> > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] >>>> > On >>>> > Behalf Of David Farmer >>>> > Sent: Monday, February 15, 2016 9:23 PM >>>> > To: ARIN PPML >>>> > Subject: Re: [arin-ppml] ARIN-2015-3: Remove 30-Day Utilization >>>> > Requirement in End-User IPv4 Policy >>>> > >>>> > As shepherd, I need additional feedback on this, I need a better sense >>>> > of >>>> > what the community wants here. >>>> > >>>> > Should we move forward more or less as-is, with a minor editorial >>>> > change, >>>> > substituting "criterion" for "criteria"? >>>> > >>>> > Or, does the community want to work on a way to address the concerns >>>> > raised but Jason? >>>> > >>>> > Your input please. >>>> > >>>> > Thanks >>>> > >>>> > On 1/29/16 10:00 , Jason Schiller wrote: >>>> > > McTim, >>>> > > >>>> > > WRT some other tangible and verifiable claim to show there was a >>>> > > real >>>> > > commitment to use half the address space within one year... >>>> > > >>>> > > I think there are 3 choices: >>>> > > >>>> > > 1. Very vague >>>> > > >>>> > > Something like "there must be some tangible and verifiable claim to >>>> > > show there was a real commitment to use half the address space >>>> > > within >>>> > > one year and not just a future projection or business case" >>>> > > >>>> > > >>>> > > 2. Open ended with some guidance for ARIN staff: >>>> > > >>>> > > Something like "there must be some tangible and verifiable claim to >>>> > > show there was a real commitment to use half the address space >>>> > > within >>>> > > one year and not just a future projection or business case. Some >>>> > > examples include: >>>> > > - list of equipment in hand to be numbered counting at least 25% of >>>> > > requested IP size >>>> > > - invoices showing equipment purchases demonstrating a commitment to >>>> > > buy equipment to be numbered counting at least 25% of requested IP >>>> > > size >>>> > > - invoices showing equipment purchases demonstrating a commitment to >>>> > > buy equipment to be numbered counting at least 50% of requested IP >>>> > > size within one year >>>> > > - lease agreements for real estate supporting equipment that is >>>> > > appropratly sized to support equipment to be numbered counting at >>>> > > least 50% of requested IP size >>>> > > >>>> > > 3. specific criterion >>>> > > >>>> > > ---- >>>> > > >>>> > > I don't know what it the right answer here, and suspect it has more >>>> > > to >>>> > > do with what the community is comfortable with. >>>> > > >>>> > > On one end of the spectrum is choice 1. This allows ARIN to do the >>>> > > right thing. But this also is not clear about what the community >>>> > > expects, and ARIN may act in a way that is counter to what is >>>> > > anticipated, and may seem like ARIN is being arbitrary or has too >>>> > > much >>>> > > leeway to screw with requestors. >>>> > > >>>> > > The opposite end of the spectrum is choice 3. This sets a very >>>> > > clear >>>> > > list of what qualifies. Hammering out that list may be very >>>> > > difficult, and it is unlikely to be complete. This will leave >>>> > > little >>>> > > or no room for ARIN to do the right thing and approve a request that >>>> > > is justified, but not one of the criterion listed. >>>> > > >>>> > > Choice 2 is the middle ground. Where we have a not necessarily >>>> > > complete list of criterion (so somewhat less difficulty in drawing >>>> > > up >>>> > > the list) that creates a very clear expectation of what ARIN should >>>> > > accept (and reduces the possibility that ARIN may act in a way that >>>> > > is >>>> > > counter to what is anticipated, and may seem like ARIN is being >>>> > > arbitrary or has too much leeway to screw with requestors) with >>>> > > respect to criterion clearly defined, while also allowing ARIN to do >>>> > > the right thing with similar types of proof that are not explicitly >>>> > > listed as criterion (this has somewhat higher risk that ARIN may act >>>> > > in a way that is counter to what is anticipated, and may seem like >>>> > > ARIN is being arbitrary or has too much leeway to screw with >>>> > > requestors, but less risk than option 1 as the criterion should >>>> > > serve >>>> > > as good guidance) >>>> > > >>>> > > >>>> > > So two open questions to the community? >>>> > > >>>> > > 1. Is the community most comfortable with: >>>> > > A. totally vague and open-ended such as "there must be some >>>> > > tangible and verifiable claim to show there was a real commitment >>>> > > to >>>> > > use half the address space within one year and not just a future >>>> > > projection or business case" >>>> > > >>>> > > B. A vague statement with some guidance as to some acceptable >>>> > > forms of tangible verifiable proof of a real commitment to use half >>>> > > the IP address within one year. >>>> > > >>>> > > C. A very clear list of what proof is considered acceptable >>>> > > >>>> > > >>>> > > 2. If the community prefers B. guidance or C. a very clear list then >>>> > > what sort of things would the community like to see on that list? >>>> > > >>>> > > >>>> > > On Fri, Jan 29, 2016 at 8:27 AM, McTim >>> > > > wrote: >>>> > > >>>> > > >>>> > > >>>> > > On Thu, Jan 28, 2016 at 4:52 PM, Jason Schiller >>>> > > > wrote: >>>> > > >>>> > > I support the removal of the 30 day utilization as it is >>>> > > unreasonable for any larger end-site, who may have a real >>>> > > need >>>> > > for say a /16, with 65,000 desktops arriving on a loading >>>> > > doc >>>> > > next week, but an inability to unbox, configure and deploy >>>> > > 16,384 to the various office locations in 30 days. >>>> > > >>>> > > >>>> > > agreed. >>>> > > >>>> > > However, this is the only provision that has a real, >>>> > > tangible, >>>> > > and verifiable claim. Without this check justified need for >>>> > > end >>>> > > users simply becomes a 1 year future looking projection, and >>>> > > with sufficient arm waving an easy end run around justified >>>> > > need >>>> > > for any end user with no IP space or if they are efficiently >>>> > > using what they currently hold. >>>> > > >>>> > > >>>> > > good point! >>>> > > >>>> > > I could get on board if the maximum sized block permitted on >>>> > > a >>>> > > purely future looking projection was a /24 and you had to >>>> > > use it >>>> > > prior to getting more. >>>> > > >>>> > > >>>> > > +1 >>>> > > >>>> > > I could certainly get on board if there were some other >>>> > > tangible >>>> > > and verifiable claim to show there was a real commitment to >>>> > > use >>>> > > half the address space within one year. >>>> > > >>>> > > >>>> > > Would this language suffice, or would we need a metric of some >>>> > > sort? >>>> > > >>>> > > >>>> > > Regards, >>>> > > >>>> > > McTim >>>> > > >>>> > > __Jason >>>> > > >>>> > > On Thu, Jan 28, 2016 at 8:55 AM, Brian Jones >>> > > > wrote: >>>> > > >>>> > > Looks good to me Dave. I am okay with using criteria or >>>> > > criterion, however using the strict definition it looks >>>> > > as >>>> > > though criterion is the proper singular form. >>>> > > >>>> > > -- >>>> > > Brian >>>> > > >>>> > > On Wed, Jan 27, 2016 at 5:54 PM, David Farmer >>>> > > > wrote: >>>> > > >>>> > > The following is the proposed update for >>>> > > ARIN-2015-3: >>>> > > Remove 30-Day Utilization Requirement in End-User >>>> > > IPv4 >>>> > > Policy based on strong support in Montreal. >>>> > > >>>> > > Beyond deleting the 25% bullet as the policy says, >>>> > > their >>>> > > are editorial changes as follows to the remaining >>>> > > text; >>>> > > >>>> > > - It looks weird to have single item bullet list, so >>>> > > merge the two remaining sentence fragments into a >>>> > > single >>>> > > sentence. >>>> > > - Change "are" to "is", since there is only one >>>> > > remaining criteria >>>> > > - Use of "criteria" as a singular is common usage, >>>> > > even >>>> > > though technically it's plural. >>>> > > - Resulting in "The basic criteria that must be met >>>> > > is a >>>> > > 50% utilization rate within one year." >>>> > > >>>> > > The remaining and resulting text for 4.3.3 is now >>>> > > included in the policy text, for editorial clarity. >>>> > > The >>>> > > original staff and legal suggested removing the >>>> > > RFC2050 >>>> > > reference and also pointed out that >>>> > > 4.2.3.6 also has a 25% immediate use clause and a >>>> > > RFC2050 reference. >>>> > > >>>> > > Feedback in Montreal was that deleting the 25% >>>> > > immediate >>>> > > use was a nice bite-sized change, and we shouldn't >>>> > > try >>>> > > to do more than that with this change, so those >>>> > > changes >>>> > > are not included at this time. >>>> > > >>>> > > Any additional feedback or comments are appreciated. >>>> > > >>>> > > Thanks >>>> > > >>>> > > --------- >>>> > > >>>> > > Draft Policy ARIN-2015-3: Remove 30 day utilization >>>> > > requirement in end-user IPv4 policy >>>> > > >>>> > > Date: 27 January 2015 >>>> > > >>>> > > Problem Statement: >>>> > > >>>> > > End-user policy is intended to provide end-users >>>> > > with a >>>> > > one year supply of IP addresses. Qualification for a >>>> > > one-year supply requires the network operator to >>>> > > utilize >>>> > > at least 25% of the requested addresses within 30 >>>> > > days. >>>> > > This text is unrealistic and should be removed. >>>> > > >>>> > > First, it often takes longer than 30 days to stage >>>> > > equipment and start actually using the addresses. >>>> > > >>>> > > Second, growth is often not that regimented; the >>>> > > forecast is to use X addresses over the course of a >>>> > > year, not to use 25% of X within 30 days. >>>> > > >>>> > > Third, this policy text applies to additional >>>> > > address >>>> > > space requests. It is incompatible with the >>>> > > requirements >>>> > > of other additional address space request >>>> > > justification >>>> > > which indicates that 80% utilization of existing >>>> > > space >>>> > > is sufficient to justify new space. If a block is at >>>> > > 80%, then often (almost always?) the remaining 80% >>>> > > will >>>> > > be used over the next 30 days and longer. Therefore >>>> > > the >>>> > > operator cannot honestly state they will use 25% of >>>> > > the >>>> > > ADDITIONAL space within 30 days of receiving it; >>>> > > they're >>>> > > still trying to use their older block efficiently. >>>> > > >>>> > > Fourth, in the face of ARIN exhaustion, some ISPs >>>> > > are >>>> > > starting to not give out /24 (or larger) blocks. So >>>> > > the >>>> > > justification for the 25% rule that previously >>>> > > existed >>>> > > (and in fact, applied for many years) is no longer >>>> > > germane. >>>> > > >>>> > > Policy statement: >>>> > > >>>> > > Remove the 25% utilization criteria bullet point >>>> > > from >>>> > > NRPM 4.3.3. >>>> > > >>>> > > Resulting text: >>>> > > >>>> > > 4.3.3. Utilization rate >>>> > > >>>> > > Utilization rate of address space is a key factor in >>>> > > justifying a new >>>> > > assignment of IP address space. Requesters must show >>>> > > exactly how >>>> > > previous address assignments have been utilized and >>>> > > must >>>> > > provide >>>> > > appropriate details to verify their one-year growth >>>> > > projection. >>>> > > >>>> > > The basic criteria that must be met is a 50% >>>> > > utilization >>>> > > rate within one year. >>>> > > >>>> > > A greater utilization rate may be required based on >>>> > > individual network >>>> > > requirements. Please refer to RFC 2050 for more >>>> > > information on >>>> > > utilization guidelines. >>>> > > >>>> > > Comments: >>>> > > a.Timetable for implementation: Immediate >>>> > > b.Anything else >>>> > > >>>> > > -- >>>> > > ================================================ >>>> > > David Farmer Email: farmer at 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 >>>> > > >>>> > > ================================================ >>>> > > _______________________________________________ >>>> > > PPML >>>> > > You are receiving this message because you are >>>> > > subscribed to >>>> > > the ARIN Public Policy Mailing List >>>> > > (ARIN-PPML at arin.net >>>> > > ). >>>> > > Unsubscribe or manage your mailing list subscription >>>> > > at: >>>> > > http://lists.arin.net/mailman/listinfo/arin-ppml >>>> > > Please contact info at arin.net >>>> > > if >>>> > > you experience any issues. >>>> > > >>>> > > >>>> > > >>>> > > _______________________________________________ >>>> > > PPML >>>> > > You are receiving this message because you are >>>> > > subscribed to >>>> > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net >>>> > > ). >>>> > > Unsubscribe or manage your mailing list subscription at: >>>> > > http://lists.arin.net/mailman/listinfo/arin-ppml >>>> > > Please contact info at arin.net if >>>> > > you >>>> > > experience any issues. >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > -- >>>> > > >>>> > _______________________________________________________ >>>> > > Jason Schiller|NetOps|jschiller at google.com >>>> > > |571-266-0006 >>>> > > >>>> > > >>>> > > >>>> > > _______________________________________________ >>>> > > PPML >>>> > > You are receiving this message because you are subscribed to >>>> > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net >>>> > > ). >>>> > > Unsubscribe or manage your mailing list subscription at: >>>> > > http://lists.arin.net/mailman/listinfo/arin-ppml >>>> > > Please contact info at arin.net if you >>>> > > experience any issues. >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > -- >>>> > > Cheers, >>>> > > >>>> > > McTim >>>> > > "A name indicates what we seek. An address indicates where it >>>> > > is. A >>>> > > route indicates how we get there." Jon Postel >>>> > > >>>> > > >>>> > > >>>> > > >>>> > > -- >>>> > > _______________________________________________________ >>>> > > Jason Schiller|NetOps|jschiller at google.com >>>> > > |571-266-0006 >>>> > > >>>> > > >>>> > > >>>> > > _______________________________________________ >>>> > > PPML >>>> > > You are receiving this message because you are subscribed to the >>>> > > ARIN >>>> > > Public Policy Mailing List (ARIN-PPML at arin.net). >>>> > > Unsubscribe or manage your mailing list subscription at: >>>> > > http://lists.arin.net/mailman/listinfo/arin-ppml >>>> > > Please contact info at arin.net if you experience any issues. >>>> > > >>>> > >>>> > >>>> > -- >>>> > ================================================ >>>> > David Farmer Email: farmer at 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 >>>> > ================================================ >>>> > _______________________________________________ >>>> > PPML >>>> > You are receiving this message because you are subscribed to the ARIN >>>> > Public Policy Mailing List (ARIN-PPML at arin.net). >>>> > Unsubscribe or manage your mailing list subscription at: >>>> > http://lists.arin.net/mailman/listinfo/arin-ppml >>>> > Please contact info at arin.net if you experience any issues. >>>> _______________________________________________ >>>> PPML >>>> You are receiving this message because you are subscribed to >>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>>> Unsubscribe or manage your mailing list subscription at: >>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>> Please contact info at arin.net if you experience any issues. >>> >>> >>> >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to >>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at arin.net if you experience any issues. >> >> >> >> >> -- >> _______________________________________________________ >> Jason Schiller|NetOps|jschiller at google.com|571-266-0006 >> > > > > -- > _______________________________________________________ > Jason Schiller|NetOps|jschiller at google.com|571-266-0006 > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== From jschiller at google.com Mon Apr 25 12:47:00 2016 From: jschiller at google.com (Jason Schiller) Date: Mon, 25 Apr 2016 12:47:00 -0400 Subject: [arin-ppml] ARIN-2015-3:(remove 30-day...) Staff interpretation needed In-Reply-To: References: Message-ID: As discussed at the mic by David Huberman, this policy will be used wrt specified transfers. I am personally confused as to the impact of this change, and my understanding of the impact seems to be at odds with a few community members I discussed it with. I suspect requests fall into two buckets. The first bucket is based on past growth. The second bucket is based on a future looking 2 year projection for Specified transfers (or a one year future looking projection for ARIN IP space / waiting list). I suspect the 30 days part does (to some extent) regulate outrageously large claims, as this is a real short term verifiable commitment. Without a possibility of a 30 day check you simply fall back to an officer attestation of a two year projected need claim. I am trying to figure out what is the likely impact of only requiring a two year projected need claim. So my questions are regarding to what level of push back ARIN provides against two year projected need in general, and will that be sufficient to prevent outlandishly large claims. Maybe another way to get at this is to compare end user transfer stats to ISP transfer stats. - what percentage of ISP specified transfers are justified by past growth? by a two year projection? - what percentage of end user specified transfers are justified by past growth? by a two year projection? - what is the average size of ISP specified transfers that are justified by past growth? by a two year projection? - what is the average size of end user specified transfers that are justified by past growth? by a two year projection? - do we see a greater gap between average ISP size between specified transfers that are justified by past growth vs. by a two year projection? - do we see a greater percentage of ISP transfers justified by a 2 year projection than end users? David, I hear a lot of people such as yourself, supposing that removal of the 30 day need check will not change anything else. But I believe it makes (pre-)approval for transfer solely based on the 2 year need projection, which I am concerned could be wildly optimistic. I am not confusing it with 2015-7: Simplified requirements for demonstrated need for IPv4 transfers. I believe 2015-7 would result in two changes, 1. lowering the bar for ISP to match what end users need in 2015-3, and 2. removing any demonstration of current utilization (and by extension demonstration that you can and are properly managing the space you have) for both ISPs and end users. I can see where there could be some confusion as I have the same concern for both proposals, that there needs to be some tangible verifiable claim. I think some people are narrowly looking at the 30 day removal as a positive thing, and I agree it is a positive thing, but it is not clear to me that people are looking at what is left in the policy. What is left is the same as 2015-7 minus the lack of demonstration of current utilization. To me it seemed that the community was less supportive of 2015-7 than 2015-3. When I probed after the fact (as I did not get a good sense from the conversation at the more or the questions asked) it became clear to me people had concerns about changing the needs measurement to simply a non-verifiable two year need claim in 2015-7, but felt removing the 30 day assessment was good. When I suggested to them that without the 30 day assessment, they only had to meet the non-verifiable two year need claim, they explained to me that only the 30 day assessment was being removed, and did not seem to think justification could be based solely on a 2 year projected need. It seems to me if you take current end user policy and remove the 30 day assessment, you have backed yourself into only needing a non-verifiable two year need claim. Am I mistaken about this? If I am not mistaken, then I am concerned that the community may have not considered the impact of these changes. If I am mistaken, then I need a better understanding of this policy proposal. __Jason On Mon, Apr 25, 2016 at 10:53 AM, David Farmer wrote: > I'm worried that people are confusing policy proposals; ARIN > 2015-3:Remove 30 day utilization requirement in end-user IPv4 policy, > simply removes the 25% immediate need (30-day) clause, it shouldn't > really change anything else. > > On Mon, Apr 25, 2016 at 9:40 AM, Jason Schiller > wrote: > > After the topic of 2015-3 closed I was discussing the policy with some > folks > > and there seems to be some confusion. > > > > If 2015-3 was current ARIN policy what would staff accept as an > acceptable > > justification. > > > > It was my assumption that an ARIN ticket that said "We might have 9 > million > > new customers in the next two years. We would like transfer approval > for a > > /8. We are currently holding a /21 which we intend to keep." And an > > officer of the company attests to this. Then ARIN would accept this > > justification as sufficient. > > > > Others postulated that the amount of documentation required would be > > unchanged from what it previously was. For a two year transfer approval > > that is not based on a doubling of the previous 1 year run rate, a > requester > > would still have to submit a business case supporting the two year growth > > need, and the officer would have to attest to that business case. The > only > > difference here is that ARIN would not review the business case except > that > > the project count of things in two years is more that 50% of what is > > requested plus what is held. This means ARIN would not review the > > supporting documentation of the business case, and leave that up to the > > officer of the requesting company to do. Is that correct? > > > > > > Additionally, can staff provide some statistics on the following: > > > > 1. over the last year how many end user transfer (pre-)approvals were > > justified based on past growth? > > > > 2. over the last year how many end user transfer (pre-)approvals were > > justified based on > > a future looking growth projection that was not based an past growth? > > > > 3. Of the requests in type 2 above, how many were: > > - Approved with no additional questions asked about the growth projection > > (not including the request for attestation)? > > - How many with one additional question about the growth projection? > > - How many with two or more additional questions about the growth > > projection? > > - How many were closed with no (pre-)approval during additional questions > > about the growth projection? > > - How many were left unresolved for 30 days or more (or abandoned) during > > additional questions about the growth projection > > > > > > I realize that some or all of the stats questions may take some time to > > answer. Please feel free to answer the first question about what > > documentation is required to be in the ticket and attested to, and any > stats > > that are easily found, and follow up with the more time consuming stats > > later. > > > > Thanks, > > > > __Jason > > > > > > > > On Wed, Feb 17, 2016 at 1:19 PM, Jason Schiller > > wrote: > >> > >> Just in case it wasn't clear, I oppose as written as it has no teeth and > >> can easily be an end user end-run around justified need. > >> > >> I support the change with some teeth so it is not likely to be an > end-run > >> around justified need. > >> > >> __Jason > >> > >> > >> > >> On Tue, Feb 16, 2016 at 4:52 PM, Brian Jones wrote: > >>> > >>> > >>> > >>> > >>> > >>> On Tue, Feb 16, 2016 at 3:51 PM, Richard J. Letts > wrote: > >>>> > >>>> My preference is to apply the policy change as written (with the minor > >>>> editorial change substituting "criterion" for "criteria".) > >>> > >>> > >>> +1 > >>> -- > >>> Brian > >>> > >>>> > >>>> > >>>> Thank you > >>>> Richard Letts > >>>> > >>>> > -----Original Message----- > >>>> > From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net > ] > >>>> > On > >>>> > Behalf Of David Farmer > >>>> > Sent: Monday, February 15, 2016 9:23 PM > >>>> > To: ARIN PPML > >>>> > Subject: Re: [arin-ppml] ARIN-2015-3: Remove 30-Day Utilization > >>>> > Requirement in End-User IPv4 Policy > >>>> > > >>>> > As shepherd, I need additional feedback on this, I need a better > sense > >>>> > of > >>>> > what the community wants here. > >>>> > > >>>> > Should we move forward more or less as-is, with a minor editorial > >>>> > change, > >>>> > substituting "criterion" for "criteria"? > >>>> > > >>>> > Or, does the community want to work on a way to address the concerns > >>>> > raised but Jason? > >>>> > > >>>> > Your input please. > >>>> > > >>>> > Thanks > >>>> > > >>>> > On 1/29/16 10:00 , Jason Schiller wrote: > >>>> > > McTim, > >>>> > > > >>>> > > WRT some other tangible and verifiable claim to show there was a > >>>> > > real > >>>> > > commitment to use half the address space within one year... > >>>> > > > >>>> > > I think there are 3 choices: > >>>> > > > >>>> > > 1. Very vague > >>>> > > > >>>> > > Something like "there must be some tangible and verifiable claim > to > >>>> > > show there was a real commitment to use half the address space > >>>> > > within > >>>> > > one year and not just a future projection or business case" > >>>> > > > >>>> > > > >>>> > > 2. Open ended with some guidance for ARIN staff: > >>>> > > > >>>> > > Something like "there must be some tangible and verifiable claim > to > >>>> > > show there was a real commitment to use half the address space > >>>> > > within > >>>> > > one year and not just a future projection or business case. Some > >>>> > > examples include: > >>>> > > - list of equipment in hand to be numbered counting at least 25% > of > >>>> > > requested IP size > >>>> > > - invoices showing equipment purchases demonstrating a commitment > to > >>>> > > buy equipment to be numbered counting at least 25% of requested IP > >>>> > > size > >>>> > > - invoices showing equipment purchases demonstrating a commitment > to > >>>> > > buy equipment to be numbered counting at least 50% of requested IP > >>>> > > size within one year > >>>> > > - lease agreements for real estate supporting equipment that is > >>>> > > appropratly sized to support equipment to be numbered counting at > >>>> > > least 50% of requested IP size > >>>> > > > >>>> > > 3. specific criterion > >>>> > > > >>>> > > ---- > >>>> > > > >>>> > > I don't know what it the right answer here, and suspect it has > more > >>>> > > to > >>>> > > do with what the community is comfortable with. > >>>> > > > >>>> > > On one end of the spectrum is choice 1. This allows ARIN to do > the > >>>> > > right thing. But this also is not clear about what the community > >>>> > > expects, and ARIN may act in a way that is counter to what is > >>>> > > anticipated, and may seem like ARIN is being arbitrary or has too > >>>> > > much > >>>> > > leeway to screw with requestors. > >>>> > > > >>>> > > The opposite end of the spectrum is choice 3. This sets a very > >>>> > > clear > >>>> > > list of what qualifies. Hammering out that list may be very > >>>> > > difficult, and it is unlikely to be complete. This will leave > >>>> > > little > >>>> > > or no room for ARIN to do the right thing and approve a request > that > >>>> > > is justified, but not one of the criterion listed. > >>>> > > > >>>> > > Choice 2 is the middle ground. Where we have a not necessarily > >>>> > > complete list of criterion (so somewhat less difficulty in drawing > >>>> > > up > >>>> > > the list) that creates a very clear expectation of what ARIN > should > >>>> > > accept (and reduces the possibility that ARIN may act in a way > that > >>>> > > is > >>>> > > counter to what is anticipated, and may seem like ARIN is being > >>>> > > arbitrary or has too much leeway to screw with requestors) with > >>>> > > respect to criterion clearly defined, while also allowing ARIN to > do > >>>> > > the right thing with similar types of proof that are not > explicitly > >>>> > > listed as criterion (this has somewhat higher risk that ARIN may > act > >>>> > > in a way that is counter to what is anticipated, and may seem like > >>>> > > ARIN is being arbitrary or has too much leeway to screw with > >>>> > > requestors, but less risk than option 1 as the criterion should > >>>> > > serve > >>>> > > as good guidance) > >>>> > > > >>>> > > > >>>> > > So two open questions to the community? > >>>> > > > >>>> > > 1. Is the community most comfortable with: > >>>> > > A. totally vague and open-ended such as "there must be some > >>>> > > tangible and verifiable claim to show there was a real > commitment > >>>> > > to > >>>> > > use half the address space within one year and not just a future > >>>> > > projection or business case" > >>>> > > > >>>> > > B. A vague statement with some guidance as to some acceptable > >>>> > > forms of tangible verifiable proof of a real commitment to use > half > >>>> > > the IP address within one year. > >>>> > > > >>>> > > C. A very clear list of what proof is considered acceptable > >>>> > > > >>>> > > > >>>> > > 2. If the community prefers B. guidance or C. a very clear list > then > >>>> > > what sort of things would the community like to see on that list? > >>>> > > > >>>> > > > >>>> > > On Fri, Jan 29, 2016 at 8:27 AM, McTim >>>> > > > wrote: > >>>> > > > >>>> > > > >>>> > > > >>>> > > On Thu, Jan 28, 2016 at 4:52 PM, Jason Schiller > >>>> > > > wrote: > >>>> > > > >>>> > > I support the removal of the 30 day utilization as it is > >>>> > > unreasonable for any larger end-site, who may have a real > >>>> > > need > >>>> > > for say a /16, with 65,000 desktops arriving on a loading > >>>> > > doc > >>>> > > next week, but an inability to unbox, configure and deploy > >>>> > > 16,384 to the various office locations in 30 days. > >>>> > > > >>>> > > > >>>> > > agreed. > >>>> > > > >>>> > > However, this is the only provision that has a real, > >>>> > > tangible, > >>>> > > and verifiable claim. Without this check justified need > for > >>>> > > end > >>>> > > users simply becomes a 1 year future looking projection, > and > >>>> > > with sufficient arm waving an easy end run around > justified > >>>> > > need > >>>> > > for any end user with no IP space or if they are > efficiently > >>>> > > using what they currently hold. > >>>> > > > >>>> > > > >>>> > > good point! > >>>> > > > >>>> > > I could get on board if the maximum sized block permitted > on > >>>> > > a > >>>> > > purely future looking projection was a /24 and you had to > >>>> > > use it > >>>> > > prior to getting more. > >>>> > > > >>>> > > > >>>> > > +1 > >>>> > > > >>>> > > I could certainly get on board if there were some other > >>>> > > tangible > >>>> > > and verifiable claim to show there was a real commitment > to > >>>> > > use > >>>> > > half the address space within one year. > >>>> > > > >>>> > > > >>>> > > Would this language suffice, or would we need a metric of some > >>>> > > sort? > >>>> > > > >>>> > > > >>>> > > Regards, > >>>> > > > >>>> > > McTim > >>>> > > > >>>> > > __Jason > >>>> > > > >>>> > > On Thu, Jan 28, 2016 at 8:55 AM, Brian Jones < > bjones at vt.edu > >>>> > > > wrote: > >>>> > > > >>>> > > Looks good to me Dave. I am okay with using criteria > or > >>>> > > criterion, however using the strict definition it > looks > >>>> > > as > >>>> > > though criterion is the proper singular form. > >>>> > > > >>>> > > -- > >>>> > > Brian > >>>> > > > >>>> > > On Wed, Jan 27, 2016 at 5:54 PM, David Farmer > >>>> > > > wrote: > >>>> > > > >>>> > > The following is the proposed update for > >>>> > > ARIN-2015-3: > >>>> > > Remove 30-Day Utilization Requirement in End-User > >>>> > > IPv4 > >>>> > > Policy based on strong support in Montreal. > >>>> > > > >>>> > > Beyond deleting the 25% bullet as the policy says, > >>>> > > their > >>>> > > are editorial changes as follows to the remaining > >>>> > > text; > >>>> > > > >>>> > > - It looks weird to have single item bullet list, > so > >>>> > > merge the two remaining sentence fragments into a > >>>> > > single > >>>> > > sentence. > >>>> > > - Change "are" to "is", since there is only one > >>>> > > remaining criteria > >>>> > > - Use of "criteria" as a singular is common usage, > >>>> > > even > >>>> > > though technically it's plural. > >>>> > > - Resulting in "The basic criteria that must be > met > >>>> > > is a > >>>> > > 50% utilization rate within one year." > >>>> > > > >>>> > > The remaining and resulting text for 4.3.3 is now > >>>> > > included in the policy text, for editorial > clarity. > >>>> > > The > >>>> > > original staff and legal suggested removing the > >>>> > > RFC2050 > >>>> > > reference and also pointed out that > >>>> > > 4.2.3.6 also has a 25% immediate use clause and a > >>>> > > RFC2050 reference. > >>>> > > > >>>> > > Feedback in Montreal was that deleting the 25% > >>>> > > immediate > >>>> > > use was a nice bite-sized change, and we shouldn't > >>>> > > try > >>>> > > to do more than that with this change, so those > >>>> > > changes > >>>> > > are not included at this time. > >>>> > > > >>>> > > Any additional feedback or comments are > appreciated. > >>>> > > > >>>> > > Thanks > >>>> > > > >>>> > > --------- > >>>> > > > >>>> > > Draft Policy ARIN-2015-3: Remove 30 day > utilization > >>>> > > requirement in end-user IPv4 policy > >>>> > > > >>>> > > Date: 27 January 2015 > >>>> > > > >>>> > > Problem Statement: > >>>> > > > >>>> > > End-user policy is intended to provide end-users > >>>> > > with a > >>>> > > one year supply of IP addresses. Qualification > for a > >>>> > > one-year supply requires the network operator to > >>>> > > utilize > >>>> > > at least 25% of the requested addresses within 30 > >>>> > > days. > >>>> > > This text is unrealistic and should be removed. > >>>> > > > >>>> > > First, it often takes longer than 30 days to stage > >>>> > > equipment and start actually using the addresses. > >>>> > > > >>>> > > Second, growth is often not that regimented; the > >>>> > > forecast is to use X addresses over the course of > a > >>>> > > year, not to use 25% of X within 30 days. > >>>> > > > >>>> > > Third, this policy text applies to additional > >>>> > > address > >>>> > > space requests. It is incompatible with the > >>>> > > requirements > >>>> > > of other additional address space request > >>>> > > justification > >>>> > > which indicates that 80% utilization of existing > >>>> > > space > >>>> > > is sufficient to justify new space. If a block is > at > >>>> > > 80%, then often (almost always?) the remaining 80% > >>>> > > will > >>>> > > be used over the next 30 days and longer. > Therefore > >>>> > > the > >>>> > > operator cannot honestly state they will use 25% > of > >>>> > > the > >>>> > > ADDITIONAL space within 30 days of receiving it; > >>>> > > they're > >>>> > > still trying to use their older block efficiently. > >>>> > > > >>>> > > Fourth, in the face of ARIN exhaustion, some ISPs > >>>> > > are > >>>> > > starting to not give out /24 (or larger) blocks. > So > >>>> > > the > >>>> > > justification for the 25% rule that previously > >>>> > > existed > >>>> > > (and in fact, applied for many years) is no longer > >>>> > > germane. > >>>> > > > >>>> > > Policy statement: > >>>> > > > >>>> > > Remove the 25% utilization criteria bullet point > >>>> > > from > >>>> > > NRPM 4.3.3. > >>>> > > > >>>> > > Resulting text: > >>>> > > > >>>> > > 4.3.3. Utilization rate > >>>> > > > >>>> > > Utilization rate of address space is a key factor > in > >>>> > > justifying a new > >>>> > > assignment of IP address space. Requesters must > show > >>>> > > exactly how > >>>> > > previous address assignments have been utilized > and > >>>> > > must > >>>> > > provide > >>>> > > appropriate details to verify their one-year > growth > >>>> > > projection. > >>>> > > > >>>> > > The basic criteria that must be met is a 50% > >>>> > > utilization > >>>> > > rate within one year. > >>>> > > > >>>> > > A greater utilization rate may be required based > on > >>>> > > individual network > >>>> > > requirements. Please refer to RFC 2050 for more > >>>> > > information on > >>>> > > utilization guidelines. > >>>> > > > >>>> > > Comments: > >>>> > > a.Timetable for implementation: Immediate > >>>> > > b.Anything else > >>>> > > > >>>> > > -- > >>>> > > ================================================ > >>>> > > David Farmer Email: farmer at 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 > >>>> > > > >>>> > > ================================================ > >>>> > > _______________________________________________ > >>>> > > PPML > >>>> > > You are receiving this message because you are > >>>> > > subscribed to > >>>> > > the ARIN Public Policy Mailing List > >>>> > > (ARIN-PPML at arin.net > >>>> > > ). > >>>> > > Unsubscribe or manage your mailing list > subscription > >>>> > > at: > >>>> > > http://lists.arin.net/mailman/listinfo/arin-ppml > >>>> > > Please contact info at arin.net info at arin.net> > >>>> > > if > >>>> > > you experience any issues. > >>>> > > > >>>> > > > >>>> > > > >>>> > > _______________________________________________ > >>>> > > PPML > >>>> > > You are receiving this message because you are > >>>> > > subscribed to > >>>> > > the ARIN Public Policy Mailing List ( > ARIN-PPML at arin.net > >>>> > > ). > >>>> > > Unsubscribe or manage your mailing list subscription > at: > >>>> > > http://lists.arin.net/mailman/listinfo/arin-ppml > >>>> > > Please contact info at arin.net > if > >>>> > > you > >>>> > > experience any issues. > >>>> > > > >>>> > > > >>>> > > > >>>> > > > >>>> > > -- > >>>> > > > >>>> > _______________________________________________________ > >>>> > > Jason Schiller|NetOps|jschiller at google.com > >>>> > > |571-266-0006 > >>>> > > > >>>> > > > >>>> > > > >>>> > > _______________________________________________ > >>>> > > PPML > >>>> > > You are receiving this message because you are subscribed > to > >>>> > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net > >>>> > > ). > >>>> > > Unsubscribe or manage your mailing list subscription at: > >>>> > > http://lists.arin.net/mailman/listinfo/arin-ppml > >>>> > > Please contact info at arin.net if > you > >>>> > > experience any issues. > >>>> > > > >>>> > > > >>>> > > > >>>> > > > >>>> > > -- > >>>> > > Cheers, > >>>> > > > >>>> > > McTim > >>>> > > "A name indicates what we seek. An address indicates where it > >>>> > > is. A > >>>> > > route indicates how we get there." Jon Postel > >>>> > > > >>>> > > > >>>> > > > >>>> > > > >>>> > > -- > >>>> > > _______________________________________________________ > >>>> > > Jason Schiller|NetOps|jschiller at google.com > >>>> > > |571-266-0006 > >>>> > > > >>>> > > > >>>> > > > >>>> > > _______________________________________________ > >>>> > > PPML > >>>> > > You are receiving this message because you are subscribed to the > >>>> > > ARIN > >>>> > > Public Policy Mailing List (ARIN-PPML at arin.net). > >>>> > > Unsubscribe or manage your mailing list subscription at: > >>>> > > http://lists.arin.net/mailman/listinfo/arin-ppml > >>>> > > Please contact info at arin.net if you experience any issues. > >>>> > > > >>>> > > >>>> > > >>>> > -- > >>>> > ================================================ > >>>> > David Farmer Email: farmer at 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 > >>>> > ================================================ > >>>> > _______________________________________________ > >>>> > PPML > >>>> > You are receiving this message because you are subscribed to the > ARIN > >>>> > Public Policy Mailing List (ARIN-PPML at arin.net). > >>>> > Unsubscribe or manage your mailing list subscription at: > >>>> > http://lists.arin.net/mailman/listinfo/arin-ppml > >>>> > Please contact info at arin.net if you experience any issues. > >>>> _______________________________________________ > >>>> PPML > >>>> You are receiving this message because you are subscribed to > >>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > >>>> Unsubscribe or manage your mailing list subscription at: > >>>> http://lists.arin.net/mailman/listinfo/arin-ppml > >>>> Please contact info at arin.net if you experience any issues. > >>> > >>> > >>> > >>> _______________________________________________ > >>> PPML > >>> You are receiving this message because you are subscribed to > >>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > >>> Unsubscribe or manage your mailing list subscription at: > >>> http://lists.arin.net/mailman/listinfo/arin-ppml > >>> Please contact info at arin.net if you experience any issues. > >> > >> > >> > >> > >> -- > >> _______________________________________________________ > >> Jason Schiller|NetOps|jschiller at google.com|571-266-0006 > >> > > > > > > > > -- > > _______________________________________________________ > > Jason Schiller|NetOps|jschiller at google.com|571-266-0006 > > > > > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > > > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =============================================== > -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at arin.net Mon Apr 25 14:38:35 2016 From: info at arin.net (ARIN) Date: Mon, 25 Apr 2016 14:38:35 -0400 Subject: [arin-ppml] Advisory Council Meeting Results - April 2016 Message-ID: <571E642B.5000101@arin.net> In accordance with the ARIN Policy Development Process (PDP), the ARIN Advisory Council (AC) met on 20 April 2016. The AC moved the following to last call (to be posted separately to last call): Draft Policy ARIN-2015-3: Remove 30 day utilization requirement in end-user IPv4 policy The AC abandoned the following: Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks The AC provided the following statement. "The ARIN AC abandoned 2015-9 because there was insufficient community support to bring the proposal forward and there did not appear to be any potential changes to the proposal that were likely to significantly improve the level of support." The AC is continuing to work on: Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) Draft Policy ARIN-2015-7: Simplified requirements for demonstrated need for IPv4 transfers Draft Policy ARIN-2016-1: Reserved Pool Transfer Policy The AC abandoned 2015-9. Anyone dissatisfied with this decision may initiate a petition. The deadline to begin a petition will be five business days after the AC's draft meeting minutes are published. For more information on starting and participating in petitions, see PDP Petitions at: https://www.arin.net/policy/pdp_petitions.html Draft Policy and Proposal texts are available at: https://www.arin.net/policy/proposals/index.html The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) From info at arin.net Mon Apr 25 14:38:49 2016 From: info at arin.net (ARIN) Date: Mon, 25 Apr 2016 14:38:49 -0400 Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2015-3: Remove 30 day utilization requirement in end-user IPv4 policy Message-ID: <571E6439.7010801@arin.net> The ARIN Advisory Council (AC) met on 20 April 2016 and decided to send the following to last call: Recommended Draft Policy ARIN-2015-3: Remove 30 day utilization requirement in end-user IPv4 policy Feedback is encouraged during the last call period. All comments should be provided to the Public Policy Mailing List. This last call will expire on 9 May 2016. After last call the AC will conduct their last call review. The draft policy text is below and available at: https://www.arin.net/policy/proposals/ The ARIN Policy Development Process is available at: https://www.arin.net/policy/pdp.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) ## * ## Recommended Draft Policy ARIN-2015-3 Remove 30 day utilization requirement in end-user IPv4 policy AC's assessment of conformance with the Principles of Internet Number Resource Policy: ARIN 2015-3 contributes to fair and impartial number resource administration by removing from the NRPM text that is operationally unrealistic for the reasons discussed in the problem statement. This proposal is technically sound, in that the removal of the text will more closely align with the way staff applies the existing policy in relation to 8.3 transfers. There was strong community support for the policy on PPML and at ARIN 36, which was confirmed at ARIN 37. There was a suggestion to replace this text with an alternate requirement. However, the community consensus was to move forward with the removal alone. The staff and legal review also suggested removing RFC2050 references and pointed out that 4.2.3.6 has an additional 25% immediate use clause, community feedback was to deal with those issues separately. Problem Statement: End-user policy is intended to provide end-users with a one year supply of IP addresses. Qualification for a one-year supply requires the network operator to utilize at least 25% of the requested addresses within 30 days. This text is unrealistic and should be removed. First, it often takes longer than 30 days to stage equipment and start actually using the addresses. Second, growth is often not that regimented; the forecast is to use X addresses over the course of a year, not to use 25% of X within 30 days. Third, this policy text applies to additional address space requests. It is incompatible with the requirements of other additional address space request justification which indicates that 80% utilization of existing space is sufficient to justify new space. If a block is at 80%, then often (almost always?) the remaining 80% will be used over the next 30 days and longer. Therefore the operator cannot honestly state they will use 25% of the ADDITIONAL space within 30 days of receiving it; they're still trying to use their older block efficiently. Fourth, in the face of ARIN exhaustion, some ISPs are starting to not give out /24 (or larger) blocks. So the justification for the 25% rule that previously existed (and in fact, applied for many years) is no longer germane. Policy statement: Remove the 25% utilization criteria bullet point from NRPM 4.3.3. Resulting text: 4.3.3. Utilization rate Utilization rate of address space is a key factor in justifying a new assignment of IP address space. Requesters must show exactly how previous address assignments have been utilized and must provide appropriate details to verify their one-year growth projection. The basic criterion that must be met is a 50% utilization rate within one year. A greater utilization rate may be required based on individual network requirements. Please refer to RFC 2050 for more information on utilization guidelines. Comments: a.Timetable for implementation: Immediate b.Anything else ##### ARIN STAFF ASSESSMENT Draft Policy ARIN-2015-3 Remove 30 day utilization requirement in end-user IPv4 policy Date of Assessment: 16 February 2016 ___ 1. Summary (Staff Understanding) This proposal would remove the 25% utilization (within 30 days of issuance) criteria bullet point from NRPM 4.3.3. ___ 2. Comments A. ARIN Staff Comments This policy would more closely align with the way staff applies the existing policy in relation to 8.3 transfers. Because there is no longer an IPv4 free pool and many IPv4 requests are likely to be satisfied by 8.3 transfers, the adoption of this policy should have no major impact on operations and could be implemented as written. Note that both NRPM 4.3.3 and NRPM 4.2.3.6 contain references to obsolete RFC 2050. Additionally, 4.2.3.6 references the 25% immediate use (within 30 days of issuance) requirement. Staff suggests removing the first two sentences of 4.2.3.6 to remove the references to RFC 2050 and the 25% requirement. Additionally, staff suggests removing the reference to the obsolete RFC 2050 in section 4.3.3. B. ARIN General Counsel ? Legal Assessment No material legal risk in this policy. ___ 3. Resource Impact This policy would have minimal resource impact from an implementation aspect. It is estimated that implementation would occur immediately after ratification by the ARIN Board of Trustees. The following would be needed in order to implement: * Updated guidelines and internal procedures * Staff training From rudi.daniel at gmail.com Wed Apr 27 07:10:48 2016 From: rudi.daniel at gmail.com (Rudolph Daniel) Date: Wed, 27 Apr 2016 07:10:48 -0400 Subject: [arin-ppml] Last call 2015-3 Message-ID: I am in support of this draft: Remove 30 day utilization requirement in end-user IPv4 policy. RD On Apr 26, 2016 11:48 PM, wrote: > Send ARIN-PPML mailing list submissions to > arin-ppml at arin.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.arin.net/mailman/listinfo/arin-ppml > or, via email, send a message with subject or body 'help' to > arin-ppml-request at arin.net > > You can reach the person managing the list at > arin-ppml-owner at arin.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of ARIN-PPML digest..." > > > Today's Topics: > > 1. Advisory Council Meeting Results - April 2016 (ARIN) > 2. LAST CALL for Recommended Draft Policy ARIN-2015-3: Remove 30 > day utilization requirement in end-user IPv4 policy (ARIN) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 25 Apr 2016 14:38:35 -0400 > From: ARIN > To: arin-ppml at arin.net > Subject: [arin-ppml] Advisory Council Meeting Results - April 2016 > Message-ID: <571E642B.5000101 at arin.net> > Content-Type: text/plain; charset=utf-8; format=flowed > > In accordance with the ARIN Policy Development Process (PDP), the ARIN > Advisory Council (AC) met on 20 April 2016. > > The AC moved the following to last call (to be posted separately to last > call): > > Draft Policy ARIN-2015-3: Remove 30 day utilization requirement in > end-user IPv4 policy > > The AC abandoned the following: > > Draft Policy ARIN-2015-9: Eliminating needs-based evaluation for > Section 8.2, 8.3, and 8.4 transfers of IPv4 netblocks > > The AC provided the following statement. "The ARIN AC abandoned 2015-9 > because there was insufficient community support to bring the proposal > forward and there did not appear to be any potential changes to the > proposal that were likely to significantly improve the level of support." > > The AC is continuing to work on: > > Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to > Specified Recipients) > Draft Policy ARIN-2015-7: Simplified requirements for demonstrated > need for IPv4 transfers > Draft Policy ARIN-2016-1: Reserved Pool Transfer Policy > > The AC abandoned 2015-9. Anyone dissatisfied with this decision may > initiate a petition. The deadline to begin a petition will be five > business days after the AC's draft meeting minutes are published. For > more information on starting and participating in petitions, see PDP > Petitions at: > https://www.arin.net/policy/pdp_petitions.html > > Draft Policy and Proposal texts are available at: > https://www.arin.net/policy/proposals/index.html > > The ARIN Policy Development Process can be found at: > https://www.arin.net/policy/pdp.html > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ------------------------------ > > Message: 2 > Date: Mon, 25 Apr 2016 14:38:49 -0400 > From: ARIN > To: arin-ppml at arin.net > Subject: [arin-ppml] LAST CALL for Recommended Draft Policy > ARIN-2015-3: Remove 30 day utilization requirement in end-user IPv4 > policy > Message-ID: <571E6439.7010801 at arin.net> > Content-Type: text/plain; charset=utf-8; format=flowed > > The ARIN Advisory Council (AC) met on 20 April 2016 and decided to > send the following to last call: > > Recommended Draft Policy ARIN-2015-3: Remove 30 day utilization > requirement in end-user IPv4 policy > > Feedback is encouraged during the last call period. All comments should > be provided to the Public Policy Mailing List. This last call will > expire on 9 May 2016. After last call the AC will conduct their > last call review. > > The draft policy text is below and available at: > https://www.arin.net/policy/proposals/ > > The ARIN Policy Development Process is available at: > https://www.arin.net/policy/pdp.html > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > ## * ## > > > Recommended Draft Policy ARIN-2015-3 > Remove 30 day utilization requirement in end-user IPv4 policy > > AC's assessment of conformance with the Principles of Internet Number > Resource Policy: > > ARIN 2015-3 contributes to fair and impartial number resource > administration by removing from the NRPM text that is operationally > unrealistic for the reasons discussed in the problem statement. This > proposal is technically sound, in that the removal of the text will more > closely align with the way staff applies the existing policy in relation > to 8.3 transfers. There was strong community support for the policy on > PPML and at ARIN 36, which was confirmed at ARIN 37. There was a > suggestion to replace this text with an alternate requirement. However, > the community consensus was to move forward with the removal alone. > > The staff and legal review also suggested removing RFC2050 references > and pointed out that 4.2.3.6 has an additional 25% immediate use clause, > community feedback was to deal with those issues separately. > > Problem Statement: > > End-user policy is intended to provide end-users with a one year supply > of IP addresses. Qualification for a one-year supply requires the > network operator to utilize at least 25% of the requested addresses > within 30 days. This text is unrealistic and should be removed. > > First, it often takes longer than 30 days to stage equipment and start > actually using the addresses. > > Second, growth is often not that regimented; the forecast is to use X > addresses over the course of a year, not to use 25% of X within 30 days. > > Third, this policy text applies to additional address space requests. It > is incompatible with the requirements of other additional address space > request justification which indicates that 80% utilization of existing > space is sufficient to justify new space. If a block is at 80%, then > often (almost always?) the remaining 80% will be used over the next 30 > days and longer. Therefore the operator cannot honestly state they will > use 25% of the ADDITIONAL space within 30 days of receiving it; they're > still trying to use their older block efficiently. > > Fourth, in the face of ARIN exhaustion, some ISPs are starting to not > give out /24 (or larger) blocks. So the justification for the 25% rule > that previously existed (and in fact, applied for many years) is no > longer germane. > > Policy statement: > > Remove the 25% utilization criteria bullet point from NRPM 4.3.3. > > Resulting text: > > 4.3.3. Utilization rate > > Utilization rate of address space is a key factor in justifying a new > assignment of IP address space. Requesters must show exactly how > previous address assignments have been utilized and must provide > appropriate details to verify their one-year growth projection. > > The basic criterion that must be met is a 50% utilization rate within > one year. > > A greater utilization rate may be required based on individual network > requirements. Please refer to RFC 2050 for more information on > utilization guidelines. > > Comments: > > a.Timetable for implementation: Immediate > > b.Anything else > > ##### > > ARIN STAFF ASSESSMENT > > Draft Policy ARIN-2015-3 > Remove 30 day utilization requirement in end-user IPv4 policy > Date of Assessment: 16 February 2016 > > ___ > 1. Summary (Staff Understanding) > > This proposal would remove the 25% utilization (within 30 days of > issuance) criteria bullet point from NRPM 4.3.3. > > ___ > 2. Comments > > A. ARIN Staff Comments > This policy would more closely align with the way staff applies the > existing policy in relation to 8.3 transfers. Because there is no longer > an IPv4 free pool and many IPv4 requests are likely to be satisfied by > 8.3 transfers, the adoption of this policy should have no major impact > on operations and could be implemented as written. > > Note that both NRPM 4.3.3 and NRPM 4.2.3.6 contain references to > obsolete RFC 2050. Additionally, 4.2.3.6 references the 25% immediate > use (within 30 days of issuance) requirement. > > Staff suggests removing the first two sentences of 4.2.3.6 to remove the > references to RFC 2050 and the 25% requirement. Additionally, staff > suggests removing the reference to the obsolete RFC 2050 in section 4.3.3. > > B. ARIN General Counsel ? Legal Assessment > No material legal risk in this policy. > > ___ > 3. Resource Impact > > This policy would have minimal resource impact from an implementation > aspect. It is estimated that implementation would occur immediately > after ratification by the ARIN Board of Trustees. The following would be > needed in order to implement: > * Updated guidelines and internal procedures > * Staff training > > > ------------------------------ > > _______________________________________________ > ARIN-PPML mailing list > ARIN-PPML at arin.net > http://lists.arin.net/mailman/listinfo/arin-ppml > > End of ARIN-PPML Digest, Vol 130, Issue 34 > ****************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: From narten at us.ibm.com Fri Apr 29 00:53:03 2016 From: narten at us.ibm.com (narten at us.ibm.com) Date: Fri, 29 Apr 2016 00:53:03 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201604290453.u3T4r3Wf023790@rotala.raleigh.ibm.com> Total of 8 messages in the last 7 days. script run at: Fri Apr 29 00:53:02 EDT 2016 Messages | Bytes | Who --------+------+--------+----------+------------------------ 25.00% | 2 | 61.08% | 151328 | jschiller at google.com 25.00% | 2 | 6.57% | 16271 | info at arin.net 12.50% | 1 | 12.11% | 30012 | farmer at umn.edu 12.50% | 1 | 10.94% | 27100 | rudi.daniel at gmail.com 12.50% | 1 | 6.55% | 16238 | ctacit at tacitlaw.com 12.50% | 1 | 2.75% | 6818 | narten at us.ibm.com --------+------+--------+----------+------------------------ 100.00% | 8 |100.00% | 247767 | Total