From narten at us.ibm.com Fri Dec 1 00:53:05 2017 From: narten at us.ibm.com (narten at us.ibm.com) Date: Fri, 01 Dec 2017 00:53:05 -0500 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201712010553.vB15r5s5008498@rotala.raleigh.ibm.com> Total of 34 messages in the last 7 days. script run at: Fri Dec 1 00:53:04 EST 2017 Messages | Bytes | Who --------+------+--------+----------+------------------------ 20.59% | 7 | 23.37% | 157664 | owen at delong.com 11.76% | 4 | 12.77% | 86179 | abagrin at omninet.io 11.76% | 4 | 10.12% | 68274 | hostmaster at uneedus.com 5.88% | 2 | 7.91% | 53403 | oroberts at bell.ca 5.88% | 2 | 5.38% | 36283 | austin.murkland at qscend.com 5.88% | 2 | 4.82% | 32526 | farmer at umn.edu 5.88% | 2 | 3.98% | 26889 | tedm at ipinc.net 5.88% | 2 | 3.33% | 22475 | lar at mwtcorp.net 2.94% | 1 | 5.28% | 35619 | sryerse at eclipse-networks.com 2.94% | 1 | 4.86% | 32797 | ahadenfeldt at allophone.net 2.94% | 1 | 3.39% | 22843 | jcurran at arin.net 2.94% | 1 | 3.32% | 22375 | mike at iptrading.com 2.94% | 1 | 3.24% | 21880 | scottleibrand at gmail.com 2.94% | 1 | 3.04% | 20490 | bjones at vt.edu 2.94% | 1 | 1.83% | 12357 | chris at semihuman.com 2.94% | 1 | 1.77% | 11976 | adalle at ncf.ca 2.94% | 1 | 1.59% | 10729 | narten at us.ibm.com --------+------+--------+----------+------------------------ 100.00% | 34 |100.00% | 674759 | Total From tedm at ipinc.net Sat Dec 2 11:46:12 2017 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Sat, 02 Dec 2017 08:46:12 -0800 Subject: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment In-Reply-To: <1FBD1C3B-543C-4F91-BC7D-E0017E79E9B9@delong.com> References: <20171122160159.GA41025@gweep.net> <1965618547.183023.1511392822657.JavaMail.zimbra@ncf.ca> <0d4075293a247645e6bf46b7343b767c@mail.gmail.com> <5A1FA060.7090609@ipinc.net> <1FBD1C3B-543C-4F91-BC7D-E0017E79E9B9@delong.com> Message-ID: <5A22D8D4.5030600@ipinc.net> On 11/30/2017 10:36 AM, Owen DeLong wrote: > >> On Nov 29, 2017, at 22:08 , Ted Mittelstaedt wrote: >> >> >> And I will point out that the entire point of validating POCs is to discover things like /16's that haven't been used for 15 years. > > I?m not convinced this is true. > As the originator of the policy I assure you that was the intent for IPv4. It has gathered other very good reasons along the way but that's what it's entire point really was. For IPv6 the goal was completely different - it was expressing the hope that we might be able to help admins to contact abusers of IP addressing - even though I knew that was tilting at windmills since people with malevolent intentions can always find a way to abuse IP addressing and hide behind a fake name. But as long as I had support from the lets-find-IPv4 crowd I was going to take advantage of the base craven desires to get something altruistic in as well. > I think the entire point of validating POCs is to make sure that all resources have valid POCs. > > I think that if the entire point were discovering /16s that haven?t been used for 15 years, then POC validation would be tied > to some process for liberating those resources for reissue. > And what makes you think there isn't some process Owen? The POC requirement was put in there to allow ARIN to force the issue on these bogus POCs to do what is needed to free up the space. They can go through a reasonable attempt to contact the former owners and if they get nowhere, then they can invalidate all of the POCS. Once that's done if a legacy block has all invalid POCs then it's effectively owned by nobody. There is no legal concept of ownership by a non-existent entity, except perhaps in a religion. ARIN can legally take control of those and redistribute them. This is all internal operations in ARIN not covered in NRPM. So YOU aren't going to necessarily know if there's a process or not. As I recall YOU were arguing against further process being put into the validation when the policy was going through discussion precisely on the grounds that such a process wasn't policy. Pretty disingenuous - argue against something then later criticize that thing for not having what you argued against? The reporting requirement was put into the validation to insure that ARIN was actually doing this as well as giving the community the idea of how much unused IPv4 was being tied up by abandoned assignments. Yes we know they are hell-bent on getting IPv6 out there but IMHO that effort has always been dependent on pushing it out to the last mile and it certainly seems to me that, that effort has completely stalled at this point. ARIN needs to be apply pressure to CPE device makers like Cisco for this but that's not happening. And for orgs that DO exist and want to keep their unused legacy space because they don't know any better, perhaps, well getting the correct contact identified allows brokers to know who to pitch to. I don't think most people have any clue how difficult it is to free up an unused legacy block of IPv4 from an org that is not using it but is just sitting on it because they don't know what the hell it is. The broker has to find a buyer with a lot of money, then go make a personal visit to the block holder and start waving the money around otherwise there will be zero interest. And it's going to have to be in a significant amount that it will attract and retain that interest and that amount is going to force the issue all the way up the chain to the CEO, and the broker is going to have to be educating every one along that chain as to what the legacy space is, and why they don't need it anymore. To add to this task the idea the broker is going to have to research and dig up owners of old blocks - that is just impossible. So the main source of IPv4 from Legacy blocks are going to be abandoned blocks, where the owners are all gone, where ARIN invalidates the POCs on them, and takes them back. Whether or not ARIN has taken this any further is really an internal issue within ARIN but at least they now have the foundation to be able to do it. Not being a broker I don't know where the brokers today are getting their IPv4 addressing from but I would assume they are also using POCs to do this. I mean, it doesn't take much effort to run Looking Glass and get a BGP listing then compare that to the IPv4 assignments to find addressing that is owned by orgs and not being used. Ted From tedm at ipinc.net Sat Dec 2 11:56:28 2017 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Sat, 02 Dec 2017 08:56:28 -0800 Subject: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment In-Reply-To: References: <238D16DF-59FF-4A98-91D7-A073F87CD228@delong.com> Message-ID: <5A22DB3C.5090407@ipinc.net> On 11/30/2017 10:44 AM, hostmaster at uneedus.com wrote: > Because of the massive (compared to IPv4) blocks given out with IPv6, > the need for SWIP except for multihome and downstream ISP's may go away. This is why RFC 1714 was written and why the RWhois project was created. It is understood that SWIP submission might be a pain. It's also understood that any ISP or network has to track assignments to their customers for billing purposes. Thus the need for a database of assignments even down to the customer level still exists. Enter RWhois to fill that need. > My experence is that many ISP's with v6 blocks have SWIP'ed nothing, and > since they are not going back to ARIN for more space, and having to > justify their current use, it is unlikely that SWIP in IPv6 will ever be > used to the extent it is in IPv4, since they are not seeking another > bite of the apple. > I just connected a customer to a brand new Internet connection with static IPs yesterday. They are still handing out IPv4. The ISP is still growing so they will still need IPv4 in the future. Ted From andrew.dul at quark.net Mon Dec 4 16:30:09 2017 From: andrew.dul at quark.net (Andrew Dul) Date: Mon, 4 Dec 2017 13:30:09 -0800 Subject: [arin-ppml] Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers In-Reply-To: <053B38B3-B8BD-43A8-9328-B4DDFE1F7E7B@gmail.com> References: <652abd11-68d7-900e-7776-b97b2311ea05@arin.net> <846F1403-01F5-4DA1-A241-3B58108E111C@quark.net> <053B38B3-B8BD-43A8-9328-B4DDFE1F7E7B@gmail.com> Message-ID: <7a704972-c75b-2423-9212-30a65c3605b1@quark.net> Scott,? how would you feel about this proposed updated problem statement which focuses on the current issue rather than the past. Andrew *Problem Statement:?* It was noted at the ARIN 40 Policy Experience Report, that there is an inconsistency in the initial block size for ISPs. Section 4.2.2 notes that the initial ISP block size should be /21 whereas the initial block size in 8.5.4 is noted as "minimum transfer size" which is effectively a /24. This causes ISP organizations to be approved for different initial block size depending on if they first apply apply for a transfer directly under section 8 or if they apply for a block under section 4.? This policy is intended to clarify this issue, by setting a consistent ISP initial IPv4 block size. It was noted that ARIN staff current operational practice is to allow all ISPs an initial /21 for Section 8 transfers. On 11/21/2017 9:19 PM, Scott Leibrand wrote: > I?d be ok with a /21, but there?s nothing magical about that size in a > post-exhaustion world. I?d rather base a loosening on actual transfer > statistics, and consider doing so for both allocations and assignments.? > > Scott > > On Nov 21, 2017, at 7:28 PM, Andrew Dul > wrote: > >> It sounds like our recollections of what we intended for ISP initial >> allocations have diverged. I will admit when I drafted the problem >> statement I did not go back through email to see if there was >> anything about this issue. >> >> Assuming we harmonize the problem statement, would you prefer the /24 >> as initial no questions asked size or a /21? >> >> What do others prefer? >> >> .Andrew >> >> On Nov 21, 2017, at 2:52 PM, Scott Leibrand > > wrote: >> >>> I believe this problem statement is incorrect, and therefore oppose >>> the policy proposal as-is. >>> >>> 8.5.4 was intended (by me, as one of the authors, and in PPML >>> discussions I just pulled up) to allow ISPs to transfer a /24 >>> without justification.? It was *not* intended to "match the previous >>> policy" in 4.2.2. >>> >>> 8.5.5 reads "8.5.5. Block size >>> Organizations may qualify for the transfer of a larger initial >>> block, or an additional block, by providing documentation to ARIN >>> which details the use of at least 50% of the requested IPv4 block >>> size within 24 months. An officer of the organization shall attest >>> to the documentation provided to ARIN." >>> >>> The intention was that any ISP needing a /21 would need to "provide >>> documentation to ARIN which details the use of at least 50% of the >>> requested IPv4 block size within 24 months", with officer >>> attestation to same. >>> >>> If that policy is deemed insufficient, and we believe it's better to >>> allow transfers of up to /21 without providing documentation to ARIN >>> and officer attestation of such, then this proposal would need to be >>> re-written with a new problem statement justifying that. >>> >>> -Scott >>> >>> On Tue, Nov 21, 2017 at 2:40 PM, ARIN >> > wrote: >>> >>> On 16 November 2017, the ARIN Advisory Council (AC) advanced >>> "ARIN-prop-244: Clarification of Initial Block Size for IPv4 ISP >>> Transfers" to Draft Policy status. >>> >>> Draft Policy ARIN-2017-9 is below and can be found at: >>> https://www.arin.net/policy/proposals/2017_9.html >>> >>> >>> You are encouraged to discuss all Draft Policies on PPML. The AC >>> will evaluate the discussion in order to assess the conformance >>> of this draft policy with ARIN's Principles of Internet number >>> resource policy as stated in the Policy Development Process >>> (PDP). Specifically, these principles are: >>> >>> * Enabling Fair and Impartial Number Resource Administration >>> * Technically Sound >>> * Supported by the Community >>> >>> The PDP can be found at: >>> https://www.arin.net/policy/pdp.html >>> >>> >>> Draft Policies and Proposals under discussion can be found at: >>> https://www.arin.net/policy/proposals/index.html >>> >>> >>> Regards, >>> >>> Sean Hopkins >>> Policy Analyst >>> American Registry for Internet Numbers (ARIN) >>> >>> >>> >>> Draft Policy ARIN-2017-9: Clarification of Initial Block Size >>> for IPv4 ISP Transfers >>> >>> Problem Statement: >>> >>> It was noted at the ARIN 40 Policy Experience Report, that there >>> is an inconsistency in the initial block size for ISPs. Section >>> 4.2.2 notes that the initial ISP block size should be /21 >>> whereas the initial block size in 8.5.4 is noted as "minimum >>> transfer size" which is effectively a /24. The intent of the new >>> 8.5.4 was to match the previous policy. This policy is intended >>> to clarify this issue. It was noted that ARIN staff current >>> operational practice is to allow ISPs an initial /21 for Section >>> 8 transfers. >>> >>> Policy statement: >>> >>> Add the following to 8.5.4 >>> >>> ISP organizations without direct assignments or allocations from >>> ARIN qualify for an initial allocation of up to a /21. >>> >>> Comments: >>> >>> a. 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. >>> >>> >>> _______________________________________________ >>> 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 daveid at panix.com Mon Dec 4 17:47:46 2017 From: daveid at panix.com (David Huberman) Date: Mon, 4 Dec 2017 17:47:46 -0500 Subject: [arin-ppml] Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers In-Reply-To: <7a704972-c75b-2423-9212-30a65c3605b1@quark.net> References: <652abd11-68d7-900e-7776-b97b2311ea05@arin.net> <846F1403-01F5-4DA1-A241-3B58108E111C@quark.net> <053B38B3-B8BD-43A8-9328-B4DDFE1F7E7B@gmail.com> <7a704972-c75b-2423-9212-30a65c3605b1@quark.net> Message-ID: Andrew, It?s unclear to me that /21 is the correct boundary, especially (as Scott Leibrand asked for) absent statistics from the staff (if any such stats make sense). With section 8 policy now wholly separated from section 4 policy, I sort of think that it?s the staff who should change their practices, and follow section 8 policy as written. Further to your problem statement, ISPs should NOT be applying under section 4 anymore. We know, however, from staff reports at the recent ARIN meeting that they still are applying. That?s a definite problem, but it feels to me to be a different problem than what you are tackling in this draft policy proposal. Happy to hear and be swayed by data or other arguments. David Sent from my iPhone > On Dec 4, 2017, at 4:30 PM, Andrew Dul wrote: > > Scott, how would you feel about this proposed updated problem statement which focuses on the current issue rather than the past. > > Andrew > > Problem Statement: > > It was noted at the ARIN 40 Policy Experience Report, that there is an inconsistency in the initial block size for ISPs. Section 4.2.2 notes that the initial ISP block size should be /21 whereas the initial block size in 8.5.4 is noted as "minimum transfer size" which is effectively a /24. This causes ISP organizations to be approved for different initial block size depending on if they first apply apply for a transfer directly under section 8 or if they apply for a block under section 4. This policy is intended to clarify this issue, by setting a consistent ISP initial IPv4 block size. It was noted that ARIN staff current operational practice is to allow all ISPs an initial /21 for Section 8 transfers. > > >> On 11/21/2017 9:19 PM, Scott Leibrand wrote: >> I?d be ok with a /21, but there?s nothing magical about that size in a post-exhaustion world. I?d rather base a loosening on actual transfer statistics, and consider doing so for both allocations and assignments. >> >> Scott >> >> On Nov 21, 2017, at 7:28 PM, Andrew Dul wrote: >> >>> It sounds like our recollections of what we intended for ISP initial allocations have diverged. I will admit when I drafted the problem statement I did not go back through email to see if there was anything about this issue. >>> >>> Assuming we harmonize the problem statement, would you prefer the /24 as initial no questions asked size or a /21? >>> >>> What do others prefer? >>> >>> .Andrew >>> >>> On Nov 21, 2017, at 2:52 PM, Scott Leibrand wrote: >>> >>>> I believe this problem statement is incorrect, and therefore oppose the policy proposal as-is. >>>> >>>> 8.5.4 was intended (by me, as one of the authors, and in PPML discussions I just pulled up) to allow ISPs to transfer a /24 without justification. It was *not* intended to "match the previous policy" in 4.2.2. >>>> >>>> 8.5.5 reads "8.5.5. Block size >>>> Organizations may qualify for the transfer of a larger initial block, or an additional block, by providing documentation to ARIN which details the use of at least 50% of the requested IPv4 block size within 24 months. An officer of the organization shall attest to the documentation provided to ARIN." >>>> >>>> The intention was that any ISP needing a /21 would need to "provide documentation to ARIN which details the use of at least 50% of the requested IPv4 block size within 24 months", with officer attestation to same. >>>> >>>> If that policy is deemed insufficient, and we believe it's better to allow transfers of up to /21 without providing documentation to ARIN and officer attestation of such, then this proposal would need to be re-written with a new problem statement justifying that. >>>> >>>> -Scott >>>> >>>>> On Tue, Nov 21, 2017 at 2:40 PM, ARIN wrote: >>>>> On 16 November 2017, the ARIN Advisory Council (AC) advanced "ARIN-prop-244: Clarification of Initial Block Size for IPv4 ISP Transfers" to Draft Policy status. >>>>> >>>>> Draft Policy ARIN-2017-9 is below and can be found at: >>>>> https://www.arin.net/policy/proposals/2017_9.html >>>>> >>>>> You are encouraged to discuss all Draft Policies on PPML. The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet number resource policy as stated in the Policy Development Process (PDP). Specifically, these principles are: >>>>> >>>>> * Enabling Fair and Impartial Number Resource Administration >>>>> * Technically Sound >>>>> * Supported by the Community >>>>> >>>>> The PDP can be found at: >>>>> https://www.arin.net/policy/pdp.html >>>>> >>>>> Draft Policies and Proposals under discussion can be found at: >>>>> https://www.arin.net/policy/proposals/index.html >>>>> >>>>> Regards, >>>>> >>>>> Sean Hopkins >>>>> Policy Analyst >>>>> American Registry for Internet Numbers (ARIN) >>>>> >>>>> >>>>> >>>>> Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers >>>>> >>>>> Problem Statement: >>>>> >>>>> It was noted at the ARIN 40 Policy Experience Report, that there is an inconsistency in the initial block size for ISPs. Section 4.2.2 notes that the initial ISP block size should be /21 whereas the initial block size in 8.5.4 is noted as "minimum transfer size" which is effectively a /24. The intent of the new 8.5.4 was to match the previous policy. This policy is intended to clarify this issue. It was noted that ARIN staff current operational practice is to allow ISPs an initial /21 for Section 8 transfers. >>>>> >>>>> Policy statement: >>>>> >>>>> Add the following to 8.5.4 >>>>> >>>>> ISP organizations without direct assignments or allocations from ARIN qualify for an initial allocation of up to a /21. >>>>> >>>>> Comments: >>>>> >>>>> a. 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. >>>> >>>> _______________________________________________ >>>> 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 andrew.dul at quark.net Mon Dec 4 23:40:27 2017 From: andrew.dul at quark.net (Andrew Dul) Date: Mon, 4 Dec 2017 20:40:27 -0800 Subject: [arin-ppml] Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers In-Reply-To: References: <652abd11-68d7-900e-7776-b97b2311ea05@arin.net> <846F1403-01F5-4DA1-A241-3B58108E111C@quark.net> <053B38B3-B8BD-43A8-9328-B4DDFE1F7E7B@gmail.com> <7a704972-c75b-2423-9212-30a65c3605b1@quark.net> Message-ID: <374a5979-7946-84f1-3086-d8bed9c021e0@quark.net> I would agree there is nothing special about /21, that is just where we ended up at exhaustion.? It is possible this draft policy doesn't do what the community wants us to do.? I wrote this draft as a followup to the policy experience report to continue the conversation about the issue and to correct the inconsistency.? (Normally, I think of inconsistencies as a "bad" thing in policy)? Perhaps what we really do want is a more strict interpretation of the new section 8 transfer policy?? If so we need a way to signal that to staff.? I'd think that could happen here on this list or at a meeting and thus no policy change is needed.? Andrew On 12/4/2017 2:47 PM, David Huberman wrote: > Andrew, > > It?s unclear to me that /21 is the correct boundary, especially (as > Scott Leibrand asked for) absent statistics from the staff (if any > such stats make sense). ?With section 8 policy now wholly separated > from section 4 policy, I sort of think that it?s the staff who should > change their practices, and follow section 8 policy as written. ? > > Further to your problem statement, ISPs should NOT be applying under > section 4 anymore. We know, however, from staff reports at the recent > ARIN meeting that they still are applying. ?That?s a definite problem, > but it feels to me to be a different problem than what you are > tackling in this draft policy proposal.? > > Happy to hear and be swayed by data or other arguments. > > David? > > Sent from my iPhone > > On Dec 4, 2017, at 4:30 PM, Andrew Dul > wrote: > >> Scott,? how would you feel about this proposed updated problem >> statement which focuses on the current issue rather than the past. >> >> Andrew >> >> *Problem Statement:?* >> >> It was noted at the ARIN 40 Policy Experience Report, that there is >> an inconsistency in the initial block size for ISPs. Section 4.2.2 >> notes that the initial ISP block size should be /21 whereas the >> initial block size in 8.5.4 is noted as "minimum transfer size" which >> is effectively a /24. This causes ISP organizations to be approved >> for different initial block size depending on if they first apply >> apply for a transfer directly under section 8 or if they apply for a >> block under section 4.? This policy is intended to clarify this >> issue, by setting a consistent ISP initial IPv4 block size. It was >> noted that ARIN staff current operational practice is to allow all >> ISPs an initial /21 for Section 8 transfers. >> >> >> >> On 11/21/2017 9:19 PM, Scott Leibrand wrote: >>> I?d be ok with a /21, but there?s nothing magical about that size in >>> a post-exhaustion world. I?d rather base a loosening on actual >>> transfer statistics, and consider doing so for both allocations and >>> assignments.? >>> >>> Scott >>> >>> On Nov 21, 2017, at 7:28 PM, Andrew Dul >> > wrote: >>> >>>> It sounds like our recollections of what we intended for ISP >>>> initial allocations have diverged. I will admit when I drafted the >>>> problem statement I did not go back through email to see if there >>>> was anything about this issue. >>>> >>>> Assuming we harmonize the problem statement, would you prefer the >>>> /24 as initial no questions asked size or a /21? >>>> >>>> What do others prefer? >>>> >>>> .Andrew >>>> >>>> On Nov 21, 2017, at 2:52 PM, Scott Leibrand >>>> > wrote: >>>> >>>>> I believe this problem statement is incorrect, and therefore >>>>> oppose the policy proposal as-is. >>>>> >>>>> 8.5.4 was intended (by me, as one of the authors, and in PPML >>>>> discussions I just pulled up) to allow ISPs to transfer a /24 >>>>> without justification.? It was *not* intended to "match the >>>>> previous policy" in 4.2.2. >>>>> >>>>> 8.5.5 reads "8.5.5. Block size >>>>> Organizations may qualify for the transfer of a larger initial >>>>> block, or an additional block, by providing documentation to ARIN >>>>> which details the use of at least 50% of the requested IPv4 block >>>>> size within 24 months. An officer of the organization shall attest >>>>> to the documentation provided to ARIN." >>>>> >>>>> The intention was that any ISP needing a /21 would need to >>>>> "provide documentation to ARIN which details the use of at least >>>>> 50% of the requested IPv4 block size within 24 months", with >>>>> officer attestation to same. >>>>> >>>>> If that policy is deemed insufficient, and we believe it's better >>>>> to allow transfers of up to /21 without providing documentation to >>>>> ARIN and officer attestation of such, then this proposal would >>>>> need to be re-written with a new problem statement justifying that. >>>>> >>>>> -Scott >>>>> >>>>> On Tue, Nov 21, 2017 at 2:40 PM, ARIN >>>> > wrote: >>>>> >>>>> On 16 November 2017, the ARIN Advisory Council (AC) advanced >>>>> "ARIN-prop-244: Clarification of Initial Block Size for IPv4 >>>>> ISP Transfers" to Draft Policy status. >>>>> >>>>> Draft Policy ARIN-2017-9 is below and can be found at: >>>>> https://www.arin.net/policy/proposals/2017_9.html >>>>> >>>>> >>>>> You are encouraged to discuss all Draft Policies on PPML. The >>>>> AC will evaluate the discussion in order to assess the >>>>> conformance of this draft policy with ARIN's Principles of >>>>> Internet number resource policy as stated in the Policy >>>>> Development Process (PDP). Specifically, these principles are: >>>>> >>>>> * Enabling Fair and Impartial Number Resource Administration >>>>> * Technically Sound >>>>> * Supported by the Community >>>>> >>>>> The PDP can be found at: >>>>> https://www.arin.net/policy/pdp.html >>>>> >>>>> >>>>> Draft Policies and Proposals under discussion can be found at: >>>>> https://www.arin.net/policy/proposals/index.html >>>>> >>>>> >>>>> Regards, >>>>> >>>>> Sean Hopkins >>>>> Policy Analyst >>>>> American Registry for Internet Numbers (ARIN) >>>>> >>>>> >>>>> >>>>> Draft Policy ARIN-2017-9: Clarification of Initial Block Size >>>>> for IPv4 ISP Transfers >>>>> >>>>> Problem Statement: >>>>> >>>>> It was noted at the ARIN 40 Policy Experience Report, that >>>>> there is an inconsistency in the initial block size for ISPs. >>>>> Section 4.2.2 notes that the initial ISP block size should be >>>>> /21 whereas the initial block size in 8.5.4 is noted as >>>>> "minimum transfer size" which is effectively a /24. The intent >>>>> of the new 8.5.4 was to match the previous policy. This policy >>>>> is intended to clarify this issue. It was noted that ARIN >>>>> staff current operational practice is to allow ISPs an initial >>>>> /21 for Section 8 transfers. >>>>> >>>>> Policy statement: >>>>> >>>>> Add the following to 8.5.4 >>>>> >>>>> ISP organizations without direct assignments or allocations >>>>> from ARIN qualify for an initial allocation of up to a /21. >>>>> >>>>> Comments: >>>>> >>>>> a. 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. >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 scottleibrand at gmail.com Mon Dec 4 23:49:52 2017 From: scottleibrand at gmail.com (Scott Leibrand) Date: Tue, 5 Dec 2017 08:49:52 +0400 Subject: [arin-ppml] Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers In-Reply-To: <374a5979-7946-84f1-3086-d8bed9c021e0@quark.net> References: <652abd11-68d7-900e-7776-b97b2311ea05@arin.net> <846F1403-01F5-4DA1-A241-3B58108E111C@quark.net> <053B38B3-B8BD-43A8-9328-B4DDFE1F7E7B@gmail.com> <7a704972-c75b-2423-9212-30a65c3605b1@quark.net> <374a5979-7946-84f1-3086-d8bed9c021e0@quark.net> Message-ID: Section 8 as discussed on PPML and as written gives anyone the ability to transfer a /24 without justification and requires officer-attested justification for anything larger. If there are organizations transferring blocks larger than a /24 for whom officer-attested justification is burdensome (to them or to ARIN) I?d like to understand what is burdensome, so we can figure out how to reduce that burden. If not, then implementing section 8 as written seems appropriate until we identify a reason to change it. Scott > On Dec 5, 2017, at 8:40 AM, Andrew Dul wrote: > > I would agree there is nothing special about /21, that is just where we ended up at exhaustion. > > It is possible this draft policy doesn't do what the community wants us to do. I wrote this draft as a followup to the policy experience report to continue the conversation about the issue and to correct the inconsistency. (Normally, I think of inconsistencies as a "bad" thing in policy) > > Perhaps what we really do want is a more strict interpretation of the new section 8 transfer policy? If so we need a way to signal that to staff. I'd think that could happen here on this list or at a meeting and thus no policy change is needed. > > Andrew > >> On 12/4/2017 2:47 PM, David Huberman wrote: >> Andrew, >> >> It?s unclear to me that /21 is the correct boundary, especially (as Scott Leibrand asked for) absent statistics from the staff (if any such stats make sense). With section 8 policy now wholly separated from section 4 policy, I sort of think that it?s the staff who should change their practices, and follow section 8 policy as written. >> >> Further to your problem statement, ISPs should NOT be applying under section 4 anymore. We know, however, from staff reports at the recent ARIN meeting that they still are applying. That?s a definite problem, but it feels to me to be a different problem than what you are tackling in this draft policy proposal. >> >> Happy to hear and be swayed by data or other arguments. >> >> David >> >> Sent from my iPhone >> >> On Dec 4, 2017, at 4:30 PM, Andrew Dul wrote: >> >>> Scott, how would you feel about this proposed updated problem statement which focuses on the current issue rather than the past. >>> >>> Andrew >>> >>> Problem Statement: >>> >>> It was noted at the ARIN 40 Policy Experience Report, that there is an inconsistency in the initial block size for ISPs. Section 4.2.2 notes that the initial ISP block size should be /21 whereas the initial block size in 8.5.4 is noted as "minimum transfer size" which is effectively a /24. This causes ISP organizations to be approved for different initial block size depending on if they first apply apply for a transfer directly under section 8 or if they apply for a block under section 4. This policy is intended to clarify this issue, by setting a consistent ISP initial IPv4 block size. It was noted that ARIN staff current operational practice is to allow all ISPs an initial /21 for Section 8 transfers. >>> >>> >>>> On 11/21/2017 9:19 PM, Scott Leibrand wrote: >>>> I?d be ok with a /21, but there?s nothing magical about that size in a post-exhaustion world. I?d rather base a loosening on actual transfer statistics, and consider doing so for both allocations and assignments. >>>> >>>> Scott >>>> >>>> On Nov 21, 2017, at 7:28 PM, Andrew Dul wrote: >>>> >>>>> It sounds like our recollections of what we intended for ISP initial allocations have diverged. I will admit when I drafted the problem statement I did not go back through email to see if there was anything about this issue. >>>>> >>>>> Assuming we harmonize the problem statement, would you prefer the /24 as initial no questions asked size or a /21? >>>>> >>>>> What do others prefer? >>>>> >>>>> .Andrew >>>>> >>>>> On Nov 21, 2017, at 2:52 PM, Scott Leibrand wrote: >>>>> >>>>>> I believe this problem statement is incorrect, and therefore oppose the policy proposal as-is. >>>>>> >>>>>> 8.5.4 was intended (by me, as one of the authors, and in PPML discussions I just pulled up) to allow ISPs to transfer a /24 without justification. It was *not* intended to "match the previous policy" in 4.2.2. >>>>>> >>>>>> 8.5.5 reads "8.5.5. Block size >>>>>> Organizations may qualify for the transfer of a larger initial block, or an additional block, by providing documentation to ARIN which details the use of at least 50% of the requested IPv4 block size within 24 months. An officer of the organization shall attest to the documentation provided to ARIN." >>>>>> >>>>>> The intention was that any ISP needing a /21 would need to "provide documentation to ARIN which details the use of at least 50% of the requested IPv4 block size within 24 months", with officer attestation to same. >>>>>> >>>>>> If that policy is deemed insufficient, and we believe it's better to allow transfers of up to /21 without providing documentation to ARIN and officer attestation of such, then this proposal would need to be re-written with a new problem statement justifying that. >>>>>> >>>>>> -Scott >>>>>> >>>>>>> On Tue, Nov 21, 2017 at 2:40 PM, ARIN wrote: >>>>>>> On 16 November 2017, the ARIN Advisory Council (AC) advanced "ARIN-prop-244: Clarification of Initial Block Size for IPv4 ISP Transfers" to Draft Policy status. >>>>>>> >>>>>>> Draft Policy ARIN-2017-9 is below and can be found at: >>>>>>> https://www.arin.net/policy/proposals/2017_9.html >>>>>>> >>>>>>> You are encouraged to discuss all Draft Policies on PPML. The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet number resource policy as stated in the Policy Development Process (PDP). Specifically, these principles are: >>>>>>> >>>>>>> * Enabling Fair and Impartial Number Resource Administration >>>>>>> * Technically Sound >>>>>>> * Supported by the Community >>>>>>> >>>>>>> The PDP can be found at: >>>>>>> https://www.arin.net/policy/pdp.html >>>>>>> >>>>>>> Draft Policies and Proposals under discussion can be found at: >>>>>>> https://www.arin.net/policy/proposals/index.html >>>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Sean Hopkins >>>>>>> Policy Analyst >>>>>>> American Registry for Internet Numbers (ARIN) >>>>>>> >>>>>>> >>>>>>> >>>>>>> Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers >>>>>>> >>>>>>> Problem Statement: >>>>>>> >>>>>>> It was noted at the ARIN 40 Policy Experience Report, that there is an inconsistency in the initial block size for ISPs. Section 4.2.2 notes that the initial ISP block size should be /21 whereas the initial block size in 8.5.4 is noted as "minimum transfer size" which is effectively a /24. The intent of the new 8.5.4 was to match the previous policy. This policy is intended to clarify this issue. It was noted that ARIN staff current operational practice is to allow ISPs an initial /21 for Section 8 transfers. >>>>>>> >>>>>>> Policy statement: >>>>>>> >>>>>>> Add the following to 8.5.4 >>>>>>> >>>>>>> ISP organizations without direct assignments or allocations from ARIN qualify for an initial allocation of up to a /21. >>>>>>> >>>>>>> Comments: >>>>>>> >>>>>>> a. 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. >>>>>> >>>>>> _______________________________________________ >>>>>> 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 hostmaster at uneedus.com Tue Dec 5 07:22:30 2017 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Tue, 5 Dec 2017 07:22:30 -0500 (EST) Subject: [arin-ppml] Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers In-Reply-To: References: <652abd11-68d7-900e-7776-b97b2311ea05@arin.net> <846F1403-01F5-4DA1-A241-3B58108E111C@quark.net> <053B38B3-B8BD-43A8-9328-B4DDFE1F7E7B@gmail.com> <7a704972-c75b-2423-9212-30a65c3605b1@quark.net> <374a5979-7946-84f1-3086-d8bed9c021e0@quark.net> Message-ID: In NRPM, I see 3 different IPv4 sizes mentioned. They are the /27 mentioned in section 4, the /24 mentioned in section 8, and the /22 mentioned for the block still available and reserved for IPv6 trans tech. I say that we set the section 4 standard to /24 same as section 8, as this allows us to serve more people on the wait list, than if each can ask for a /21. I strongly think we are not serving very many people via the wait list anyway, as much of the space that would otherwise be returned, is ending up in the section 8 transfer process instead. If they need more, they either need a section 8 transfer, or consider what doing what we all need to do, which is to move to IPv6 and apply for a /22 for trans tech for short term IPv4 need until we all move. Under section 8, I really do not see what is burdensome in having an officer attest to the need. ARIN needs this policy to prevent speculation in number resources. Albert Erdmann Network Administrator Paradise On Line Inc. On Tue, 5 Dec 2017, Scott Leibrand wrote: > Section 8 as discussed on PPML and as written gives anyone the ability to transfer a /24 without justification and requires officer-attested justification for anything larger. > > If there are organizations transferring blocks larger than a /24 for > whom officer-attested justification is burdensome (to them or to ARIN) > I???d like to understand what is burdensome, so we can figure out how to > reduce that burden. If not, then implementing section 8 as written seems > appropriate until we identify a reason to change it. > > Scott > >> On Dec 5, 2017, at 8:40 AM, Andrew Dul wrote: >> >> I would agree there is nothing special about /21, that is just where we >> ended up at exhaustion. >> >> It is possible this draft policy doesn't do what the community wants us >> to do. I wrote this draft as a followup to the policy experience >> report to continue the conversation about the issue and to correct the >> inconsistency. (Normally, I think of inconsistencies as a "bad" thing >> in policy) >> >> Perhaps what we really do want is a more strict interpretation of the >> new section 8 transfer policy? If so we need a way to signal that to >> staff. I'd think that could happen here on this list or at a meeting >> and thus no policy change is needed. >> >> Andrew >> >>> On 12/4/2017 2:47 PM, David Huberman wrote: >>> Andrew, >>> >>> It???s unclear to me that /21 is the correct boundary, especially (as Scott Leibrand asked for) absent statistics from the staff (if any such stats make sense). With section 8 policy now wholly separated from section 4 policy, I sort of think that it???s the staff who should change their practices, and follow section 8 policy as written. >>> >>> Further to your problem statement, ISPs should NOT be applying under section 4 anymore. We know, however, from staff reports at the recent ARIN meeting that they still are applying. That???s a definite problem, but it feels to me to be a different problem than what you are tackling in this draft policy proposal. >>> >>> Happy to hear and be swayed by data or other arguments. >>> >>> David >>> >>> Sent from my iPhone >>> >>> On Dec 4, 2017, at 4:30 PM, Andrew Dul wrote: >>> >>>> Scott, how would you feel about this proposed updated problem statement which focuses on the current issue rather than the past. >>>> >>>> Andrew >>>> >>>> Problem Statement: >>>> >>>> It was noted at the ARIN 40 Policy Experience Report, that there is an inconsistency in the initial block size for ISPs. Section 4.2.2 notes that the initial ISP block size should be /21 whereas the initial block size in 8.5.4 is noted as "minimum transfer size" which is effectively a /24. This causes ISP organizations to be approved for different initial block size depending on if they first apply apply for a transfer directly under section 8 or if they apply for a block under section 4. This policy is intended to clarify this issue, by setting a consistent ISP initial IPv4 block size. It was noted that ARIN staff current operational practice is to allow all ISPs an initial /21 for Section 8 transfers. >>>> >>>> >>>>> On 11/21/2017 9:19 PM, Scott Leibrand wrote: >>>>> I???d be ok with a /21, but there???s nothing magical about that size in a post-exhaustion world. I???d rather base a loosening on actual transfer statistics, and consider doing so for both allocations and assignments. >>>>> >>>>> Scott >>>>> >>>>> On Nov 21, 2017, at 7:28 PM, Andrew Dul wrote: >>>>> >>>>>> It sounds like our recollections of what we intended for ISP initial allocations have diverged. I will admit when I drafted the problem statement I did not go back through email to see if there was anything about this issue. >>>>>> >>>>>> Assuming we harmonize the problem statement, would you prefer the /24 as initial no questions asked size or a /21? >>>>>> >>>>>> What do others prefer? >>>>>> >>>>>> .Andrew >>>>>> >>>>>> On Nov 21, 2017, at 2:52 PM, Scott Leibrand wrote: >>>>>> >>>>>>> I believe this problem statement is incorrect, and therefore oppose the policy proposal as-is. >>>>>>> >>>>>>> 8.5.4 was intended (by me, as one of the authors, and in PPML discussions I just pulled up) to allow ISPs to transfer a /24 without justification. It was *not* intended to "match the previous policy" in 4.2.2. >>>>>>> >>>>>>> 8.5.5 reads "8.5.5. Block size >>>>>>> Organizations may qualify for the transfer of a larger initial block, or an additional block, by providing documentation to ARIN which details the use of at least 50% of the requested IPv4 block size within 24 months. An officer of the organization shall attest to the documentation provided to ARIN." >>>>>>> >>>>>>> The intention was that any ISP needing a /21 would need to "provide documentation to ARIN which details the use of at least 50% of the requested IPv4 block size within 24 months", with officer attestation to same. >>>>>>> >>>>>>> If that policy is deemed insufficient, and we believe it's better to allow transfers of up to /21 without providing documentation to ARIN and officer attestation of such, then this proposal would need to be re-written with a new problem statement justifying that. >>>>>>> >>>>>>> -Scott >>>>>>> >>>>>>>> On Tue, Nov 21, 2017 at 2:40 PM, ARIN wrote: >>>>>>>> On 16 November 2017, the ARIN Advisory Council (AC) advanced "ARIN-prop-244: Clarification of Initial Block Size for IPv4 ISP Transfers" to Draft Policy status. >>>>>>>> >>>>>>>> Draft Policy ARIN-2017-9 is below and can be found at: >>>>>>>> https://www.arin.net/policy/proposals/2017_9.html >>>>>>>> >>>>>>>> You are encouraged to discuss all Draft Policies on PPML. The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet number resource policy as stated in the Policy Development Process (PDP). Specifically, these principles are: >>>>>>>> >>>>>>>> * Enabling Fair and Impartial Number Resource Administration >>>>>>>> * Technically Sound >>>>>>>> * Supported by the Community >>>>>>>> >>>>>>>> The PDP can be found at: >>>>>>>> https://www.arin.net/policy/pdp.html >>>>>>>> >>>>>>>> Draft Policies and Proposals under discussion can be found at: >>>>>>>> https://www.arin.net/policy/proposals/index.html >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Sean Hopkins >>>>>>>> Policy Analyst >>>>>>>> American Registry for Internet Numbers (ARIN) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers >>>>>>>> >>>>>>>> Problem Statement: >>>>>>>> >>>>>>>> It was noted at the ARIN 40 Policy Experience Report, that there is an inconsistency in the initial block size for ISPs. Section 4.2.2 notes that the initial ISP block size should be /21 whereas the initial block size in 8.5.4 is noted as "minimum transfer size" which is effectively a /24. The intent of the new 8.5.4 was to match the previous policy. This policy is intended to clarify this issue. It was noted that ARIN staff current operational practice is to allow ISPs an initial /21 for Section 8 transfers. >>>>>>>> >>>>>>>> Policy statement: >>>>>>>> >>>>>>>> Add the following to 8.5.4 >>>>>>>> >>>>>>>> ISP organizations without direct assignments or allocations from ARIN qualify for an initial allocation of up to a /21. >>>>>>>> >>>>>>>> Comments: >>>>>>>> >>>>>>>> a. 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. >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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. >> > From owen at delong.com Wed Dec 6 13:34:47 2017 From: owen at delong.com (Owen DeLong) Date: Wed, 6 Dec 2017 10:34:47 -0800 Subject: [arin-ppml] Draft Policy ARIN-2017-11: Reallocation and Reassignment Language Cleanup In-Reply-To: References: <98d17d2f-c3f8-f395-77a2-6493f7d36452@arin.net> Message-ID: <31F2F002-5EA2-4BCB-9609-C9FB062195E6@delong.com> The proposed editorial changes do not conflict with the current language, nor do they present a conflict with the revised language that will occur if the board ratifies 2017-5. Staff can intelligently apply this update to the NRPM in either state without conflict or loss of fidelity in either case. Owen > On Nov 21, 2017, at 15:48 , theone at uneedus.com wrote: > > For the same reason as stated in comments to ARIN-2017-10, this proposal changes language in 6.5.5.1 which is before the ARIN Board regarding a change of the standard from /64 or more to /47 or more, or any size individually announced. > > I suggest the author take into consideration the change of this section in ARIN-2017-5 before the ARIN Board, before any changes to this section are made. > > Albert Erdmann > Network Administrator > Paradise On Line Inc. > > On Tue, 21 Nov 2017, ARIN wrote: > >> On 16 November 2017, the ARIN Advisory Council (AC) advanced "ARIN-prop-246: Reallocation and Reassignment Language Cleanup" to Draft Policy status. >> >> Draft Policy ARIN-2017-11 is below and can be found at: >> https://www.arin.net/policy/proposals/2017_11.html >> >> You are encouraged to discuss all Draft Policies on PPML. The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet number resource policy as stated in the Policy Development Process (PDP). Specifically, these principles are: >> >> * Enabling Fair and Impartial Number Resource Administration >> * Technically Sound >> * Supported by the Community >> >> The PDP can be found at: >> https://www.arin.net/policy/pdp.html >> >> Draft Policies and Proposals under discussion can be found at: >> https://www.arin.net/policy/proposals/index.html >> >> Regards, >> >> Sean Hopkins >> Policy Analyst >> American Registry for Internet Numbers (ARIN) >> >> >> >> Draft Policy ARIN-2017-11: Reallocation and Reassignment Language Cleanup >> >> Problem Statement: >> >> The current text of NRPM uses the terms ?reallocate? and ?reassign? in ways that are both internally inconsistent within NRPM and inconsistent with the definitions of Reassignments and Reallocations as fields within the ARIN database. Frequently the term ?reassignment? or ?reassign? is used in NRPM as an umbrella term for both reallocations and reassignments. As a result, someone familiar with the ARIN Whois database, but unfamiliar with history of particular portions of NRPM and their intended meaning may interpret certain NRPM requirements as applying only to reassignments and not to reallocations. This is particularly problematic when it comes to SWIP requirements and the requirement to record reallocations and reassignments with ARIN, which under current text could be read to only apply to reassignments. >> >> Policy Statement: >> >> Make the following changes to the definitions in Section 2.5 >> >> Current text: >> >> 2.5. Allocate and Assign >> >> A distinction is made between address allocation and address assignment, i.e., ISPs are "allocated" address space as described herein, while end-users are "assigned" address space. >> >> Allocate - To allocate means to distribute address space to IRs for the purpose of subsequent distribution by them. >> >> Assign - To assign means to delegate address space to an ISP or end-user, for specific use within the Internet infrastructure they operate. Assignments must only be made for specific purposes documented by specific organizations and are not to be sub-assigned to other parties. >> >> Proposed Editorial Change: >> >> 2.5 Allocation, Assignment, Reallocation, Reassignment >> >> Allocation - Address space delegated to an organization directly by ARIN for the purpose of subsequent distribution by the recipient organization to other parties. >> >> Assignment - Address space delegated to an organization directly by ARIN for the exclusive use of the recipient organization. >> >> Reallocation - Address space sub-delegated to an organization by an upstream provider for the purpose of subsequent distribution by the recipient organization to other parties. >> >> Reassignment - Address space sub-delegated to an organization by an upstream provider for the exclusive use of the recipient organization. >> >> Make the following editorial changes to section 4.2: >> >> Current text: >> >> 4.2.1.1. Purpose >> >> ARIN allocates blocks of IP addresses to ISPs for the purpose of reassigning that space to their customers. >> >> Proposed Editorial Change: >> >> 4.2.1.1. Purpose >> >> ARIN allocates blocks of IP addresses to ISPs for the purpose of reassigning and reallocating that space to their customers. >> >> Current text: >> >> 4.2.3. Reassigning Address Space to Customers >> >> Proposed Editorial Change: >> >> 4.2.3. Reassigning and Reallocating Address Space to Customers >> >> Current Text: >> >> 4.2.3.1. Efficient utilization >> >> ISPs are required to apply a utilization efficiency criterion in providing address space to their customers. To this end, ISPs should have documented justification available for each reassignment. ARIN may request this justification at any time. If justification is not provided, future receipt of allocations may be impacted. >> >> Proposed Editorial Change: >> >> 4.2.3.1. Efficient utilization >> >> ISPs are required to apply a utilization efficiency criterion in providing address space to their customers. To this end, ISPs should have documented justification available for each reassignment and reallocation. ARIN may request this justification at any time. If justification is not provided, future receipt of allocations may be impacted. >> >> Current text: >> >> 4.2.3.4. Downstream customer adherence >> >> ISPs must require their downstream customers to adhere to the following criteria: >> >> 4.2.3.4.1. Utilization >> >> Reassignment information for prior allocations must show that each customer meets the 80% utilization criteria and must be available via SWIP / RWhois prior to your issuing them additional space. >> >> Proposed Editorial Changes: >> >> 4.2.3.4. Downstream customer adherence >> >> ISPs must require their downstream customers to adhere to the following criteria: >> >> 4.2.3.4.1. Utilization >> >> Reassignment and reallocation information for prior allocations must show that each customer meets the 80% utilization criteria and must be available via SWIP / RWhois prior to your issuing them additional space. >> >> Current text: >> >> 4.2.3.5. ARIN approval of reassignments/reallocations >> >> 4.2.3.5.1. /18 >> >> All extra-large ISPs making reassignments of a /18 or larger to a customer must first have these reassignments reviewed and approved by ARIN. >> >> 4.2.3.5.2. /19 >> >> Small to large ISPs making customer reassignments of a /19 or larger must first seek ARIN's approval. >> >> Proposed Editorial Changes: >> >> 4.2.3.5. ARIN approval of reassignments/reallocations >> >> 4.2.3.5.1. /18 >> >> All extra-large ISPs making reassignments or reallocations of a /18 or larger to a customer must first have these reassignments or reallocations reviewed and approved by ARIN. >> >> 4.2.3.5.2. /19 >> >> Small to large ISPs making customer reassignments or reallocations of a /19 or larger must first seek ARIN's approval. >> >> Current text: >> >> 4.2.3.7.1. Reassignment Information >> >> Each IPv4 assignment containing a /29 or more addresses shall be registered in the WHOIS directory via SWIP or a distributed service which meets the standards set forth in section 3.2. Reassignment registrations shall include each client's organizational information, except where specifically exempted by this policy. >> >> Proposed Editorial Changes: >> >> 4.2.3.7.1. Reassignment and Reallocation Information >> >> Each IPv4 reassignment or reallocation containing a /29 or more addresses shall be registered in the WHOIS directory via SWIP or a distributed service which meets the standards set forth in section 3.2. Reassignment and reallocation registrations shall include each client's organizational information, except where specifically exempted by this policy. >> >> Current text: >> >> 4.2.3.7.2.Assignments visible within 7 days >> >> All assignments shall be made visible as required in section 4.2.3.7.1 within seven calendar days of assignment. >> >> Proposed Editorial Changes: >> >> 4.2.3.7.2.Reassignments and Reallocations visible within 7 days >> >> All reassignments and reallocations shall be made visible as required in section 4.2.3.7.1 within seven calendar days of reassignment or reallocation. >> >> Current text: >> >> 4.2.4. ISP Additional Requests >> >> 4.2.4.1. Utilization percentage (80%) >> >> ISPs must have efficiently utilized all allocations, in aggregate, to at least 80% and at least 50% of every allocation in order to receive additional space. This includes all space reassigned to their customers. >> >> Proposed Editorial Changes: >> >> 4.2.4. ISP Additional Requests >> >> 4.2.4.1. Utilization percentage (80%) >> >> ISPs must have efficiently utilized all allocations, in aggregate, to at least 80% and at least 50% of every allocation in order to receive additional space. This includes all space reassigned or reallocated to their customers. >> >> Make the following editorial changes to section 6 to clarify language regarding current practices and requirements for reallocations and reassignments, and specifically to clarify that recording reallocation information is required where current language is ambiguous: >> >> Current text: >> >> 6.5.2.1(e) Initial Allocations to LIRs, Size >> >> For purposes of the calculation in (c), an LIR which has subordinate LIRs shall make such allocations according to the same policies and criteria as ARIN. In such a case, the prefixes necessary for such an allocation should be treated as fully utilized in determining the block sizing for the parent LIR. LIRs which do not receive resources directly from ARIN will not be able to make such allocations to subordinate LIRs and subordinate LIRs which need more than a /32 shall apply directly to ARIN. >> >> Proposed Editorial Changes: >> >> 6.5.2.1(e) Initial Allocations to LIRs, Size >> >> For purposes of the calculation in (c), an LIR which has subordinate LIRs shall make such reallocations according to the same policies and criteria as ARIN. In such a case, the prefixes necessary for such a reallocation should be treated as fully utilized in determining the block sizing for the parent LIR. LIRs which do not receive resources directly from ARIN will not be able to make such reallocations to subordinate LIRs and subordinate LIRs which need more than a /32 shall apply directly to ARIN. >> >> Current text: >> >> 6.5.2.2. Qualifications >> >> An organization qualifies for an allocation under this policy if they meet any of the following criteria: >> >> a. Have a previously justified IPv4 ISP allocation from ARIN or one of its predecessor registries or can qualify for an IPv4 ISP allocation under current criteria. >> >> b. Are currently multihomed for IPv6 or will immediately become multihomed for IPv6 using a valid assigned global AS number. >> >> In either case, they will be making reassignments from allocation(s) under this policy to other organizations. >> >> Provide ARIN a reasonable technical justification indicating why an allocation is necessary. Justification must include the intended purposes for the allocation and describe the network infrastructure the allocation will be used to support. Justification must also include a plan detailing anticipated assignments to other organizations or customers for one, two and five year periods, with a minimum of 50 assignments within 5 years. >> >> Proposed Editorial Changes: >> >> 6.5.2.2. Qualifications >> >> An organization qualifies for an allocation under this policy if they meet any of the following criteria: >> >> a. Have a previously justified IPv4 ISP allocation from ARIN or one of its predecessor registries or can qualify for an IPv4 ISP allocation under current criteria. >> >> b. Are currently multihomed for IPv6 or will immediately become multihomed for IPv6 using a valid assigned global AS number. >> >> In either case, they will be making reassignments or reallocations from allocation(s) under this policy to other organizations. >> >> Provide ARIN a reasonable technical justification indicating why an allocation is necessary. Justification must include the intended purposes for the allocation and describe the network infrastructure the allocation will be used to support. Justification must also include a plan detailing anticipated reassignments and reallocations to other organizations or customers for one, two and five year periods, with a minimum of 50 assignments within 5 years. >> >> Current text: >> >> 6.5.4. Assignments from LIRs/ISPs >> >> Assignments to end users shall be governed by the same practices adopted by the community in section 6.5.8 except that the requirements in 6.5.8.1 do not apply. >> >> Proposed Editorial Changes: >> >> 6.5.4. Reassignments from LIRs/ISPs >> >> Reassignments to end users shall be governed by the same practices adopted by the community in section 6.5.8 except that the requirements in 6.5.8.1 do not apply. >> >> Current text: >> >> 6.5.4.1. Assignment to operator's infrastructure >> >> An LIR may assign up to a /48 per PoP as well as up to an additional /48 globally for its own infrastructure. >> >> Proposed Editorial Changes: >> >> 6.5.4.1. Reassignment to operator's infrastructure >> >> An LIR may reassign up to a /48 per PoP as well as up to an additional /48 globally for its own infrastructure. >> >> Current text: >> >> 6.5.5. Registration >> >> ISPs are required to demonstrate efficient use of IP address space allocations by providing appropriate documentation, including but not limited to assignment histories, showing their efficient use. >> >> Proposed Editorial Changes: >> >> 6.5.5. Registration >> >> ISPs are required to demonstrate efficient use of IP address space allocations by providing appropriate documentation, including but not limited to reassignment and reallocation histories, showing their efficient use. >> >> Current text: >> >> 6.5.5.1. Reassignment information >> >> Each static IPv6 assignment containing a /64 or more addresses shall be registered in the WHOIS directory via SWIP or a distributed service which meets the standards set forth in section 3.2. Reassignment registrations shall include each client's organizational information, except where specifically exempted by this policy. >> >> Proposed Editorial Changes: >> >> 6.5.5.1. Reassignment information >> >> Each static IPv6 reassignment or reallocation containing a /64 or more addresses shall be registered in the WHOIS directory via SWIP or a distributed service which meets the standards set forth in section 3.2. Reassignment and reallocation registrations shall include each client's organizational information, except where specifically exempted by this policy. >> >> Current text: >> >> 6.5.5.2. Assignments visible within 7 days >> >> All assignments shall be made visible as required in section 4.2.3.7.1 within seven calendar days of assignment >> >> Proposed Editorial Changes: >> >> 6.5.5.2. Reassignments and Reallocations visible within 7 days >> >> All reassignments and reallocations shall be made visible as required in section 4.2.3.7.1 within seven calendar days of reassignment or reallocation. >> _______________________________________________ >> 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. From bjones at vt.edu Wed Dec 6 13:57:26 2017 From: bjones at vt.edu (Brian Jones) Date: Wed, 06 Dec 2017 18:57:26 +0000 Subject: [arin-ppml] Draft Policy ARIN-2017-11: Reallocation and Reassignment Language Cleanup In-Reply-To: <31F2F002-5EA2-4BCB-9609-C9FB062195E6@delong.com> References: <98d17d2f-c3f8-f395-77a2-6493f7d36452@arin.net> <31F2F002-5EA2-4BCB-9609-C9FB062195E6@delong.com> Message-ID: On Wed, Dec 6, 2017 at 1:36 PM Owen DeLong wrote: > The proposed editorial changes do not conflict with the current language, > nor do they present a conflict with the revised language that will occur if > the board ratifies 2017-5. Staff can intelligently apply this update to the > NRPM in either state without conflict or loss of fidelity in either case. > > Owen > > I +1 Owen's comments. It seems these changes could be made with or without ratification of 2015-5. -- Brian > > On Nov 21, 2017, at 15:48 , theone at uneedus.com wrote: > > > > For the same reason as stated in comments to ARIN-2017-10, this proposal > changes language in 6.5.5.1 which is before the ARIN Board regarding a > change of the standard from /64 or more to /47 or more, or any size > individually announced. > > > > I suggest the author take into consideration the change of this section > in ARIN-2017-5 before the ARIN Board, before any changes to this section > are made. > > > > Albert Erdmann > > Network Administrator > > Paradise On Line Inc. > > > > On Tue, 21 Nov 2017, ARIN wrote: > > > >> On 16 November 2017, the ARIN Advisory Council (AC) advanced > "ARIN-prop-246: Reallocation and Reassignment Language Cleanup" to Draft > Policy status. > >> > >> Draft Policy ARIN-2017-11 is below and can be found at: > >> https://www.arin.net/policy/proposals/2017_11.html > >> > >> You are encouraged to discuss all Draft Policies on PPML. The AC will > evaluate the discussion in order to assess the conformance of this draft > policy with ARIN's Principles of Internet number resource policy as stated > in the Policy Development Process (PDP). Specifically, these principles are: > >> > >> * Enabling Fair and Impartial Number Resource Administration > >> * Technically Sound > >> * Supported by the Community > >> > >> The PDP can be found at: > >> https://www.arin.net/policy/pdp.html > >> > >> Draft Policies and Proposals under discussion can be found at: > >> https://www.arin.net/policy/proposals/index.html > >> > >> Regards, > >> > >> Sean Hopkins > >> Policy Analyst > >> American Registry for Internet Numbers (ARIN) > >> > >> > >> > >> Draft Policy ARIN-2017-11: Reallocation and Reassignment Language > Cleanup > >> > >> Problem Statement: > >> > >> The current text of NRPM uses the terms ?reallocate? and ?reassign? in > ways that are both internally inconsistent within NRPM and inconsistent > with the definitions of Reassignments and Reallocations as fields within > the ARIN database. Frequently the term ?reassignment? or ?reassign? is used > in NRPM as an umbrella term for both reallocations and reassignments. As a > result, someone familiar with the ARIN Whois database, but unfamiliar with > history of particular portions of NRPM and their intended meaning may > interpret certain NRPM requirements as applying only to reassignments and > not to reallocations. This is particularly problematic when it comes to > SWIP requirements and the requirement to record reallocations and > reassignments with ARIN, which under current text could be read to only > apply to reassignments. > >> > >> Policy Statement: > >> > >> Make the following changes to the definitions in Section 2.5 > >> > >> Current text: > >> > >> 2.5. Allocate and Assign > >> > >> A distinction is made between address allocation and address > assignment, i.e., ISPs are "allocated" address space as described herein, > while end-users are "assigned" address space. > >> > >> Allocate - To allocate means to distribute address space to IRs for the > purpose of subsequent distribution by them. > >> > >> Assign - To assign means to delegate address space to an ISP or > end-user, for specific use within the Internet infrastructure they operate. > Assignments must only be made for specific purposes documented by specific > organizations and are not to be sub-assigned to other parties. > >> > >> Proposed Editorial Change: > >> > >> 2.5 Allocation, Assignment, Reallocation, Reassignment > >> > >> Allocation - Address space delegated to an organization directly by > ARIN for the purpose of subsequent distribution by the recipient > organization to other parties. > >> > >> Assignment - Address space delegated to an organization directly by > ARIN for the exclusive use of the recipient organization. > >> > >> Reallocation - Address space sub-delegated to an organization by an > upstream provider for the purpose of subsequent distribution by the > recipient organization to other parties. > >> > >> Reassignment - Address space sub-delegated to an organization by an > upstream provider for the exclusive use of the recipient organization. > >> > >> Make the following editorial changes to section 4.2: > >> > >> Current text: > >> > >> 4.2.1.1. Purpose > >> > >> ARIN allocates blocks of IP addresses to ISPs for the purpose of > reassigning that space to their customers. > >> > >> Proposed Editorial Change: > >> > >> 4.2.1.1. Purpose > >> > >> ARIN allocates blocks of IP addresses to ISPs for the purpose of > reassigning and reallocating that space to their customers. > >> > >> Current text: > >> > >> 4.2.3. Reassigning Address Space to Customers > >> > >> Proposed Editorial Change: > >> > >> 4.2.3. Reassigning and Reallocating Address Space to Customers > >> > >> Current Text: > >> > >> 4.2.3.1. Efficient utilization > >> > >> ISPs are required to apply a utilization efficiency criterion in > providing address space to their customers. To this end, ISPs should have > documented justification available for each reassignment. ARIN may request > this justification at any time. If justification is not provided, future > receipt of allocations may be impacted. > >> > >> Proposed Editorial Change: > >> > >> 4.2.3.1. Efficient utilization > >> > >> ISPs are required to apply a utilization efficiency criterion in > providing address space to their customers. To this end, ISPs should have > documented justification available for each reassignment and reallocation. > ARIN may request this justification at any time. If justification is not > provided, future receipt of allocations may be impacted. > >> > >> Current text: > >> > >> 4.2.3.4. Downstream customer adherence > >> > >> ISPs must require their downstream customers to adhere to the following > criteria: > >> > >> 4.2.3.4.1. Utilization > >> > >> Reassignment information for prior allocations must show that each > customer meets the 80% utilization criteria and must be available via SWIP > / RWhois prior to your issuing them additional space. > >> > >> Proposed Editorial Changes: > >> > >> 4.2.3.4. Downstream customer adherence > >> > >> ISPs must require their downstream customers to adhere to the following > criteria: > >> > >> 4.2.3.4.1. Utilization > >> > >> Reassignment and reallocation information for prior allocations must > show that each customer meets the 80% utilization criteria and must be > available via SWIP / RWhois prior to your issuing them additional space. > >> > >> Current text: > >> > >> 4.2.3.5. ARIN approval of reassignments/reallocations > >> > >> 4.2.3.5.1. /18 > >> > >> All extra-large ISPs making reassignments of a /18 or larger to a > customer must first have these reassignments reviewed and approved by ARIN. > >> > >> 4.2.3.5.2. /19 > >> > >> Small to large ISPs making customer reassignments of a /19 or larger > must first seek ARIN's approval. > >> > >> Proposed Editorial Changes: > >> > >> 4.2.3.5. ARIN approval of reassignments/reallocations > >> > >> 4.2.3.5.1. /18 > >> > >> All extra-large ISPs making reassignments or reallocations of a /18 or > larger to a customer must first have these reassignments or reallocations > reviewed and approved by ARIN. > >> > >> 4.2.3.5.2. /19 > >> > >> Small to large ISPs making customer reassignments or reallocations of a > /19 or larger must first seek ARIN's approval. > >> > >> Current text: > >> > >> 4.2.3.7.1. Reassignment Information > >> > >> Each IPv4 assignment containing a /29 or more addresses shall be > registered in the WHOIS directory via SWIP or a distributed service which > meets the standards set forth in section 3.2. Reassignment registrations > shall include each client's organizational information, except where > specifically exempted by this policy. > >> > >> Proposed Editorial Changes: > >> > >> 4.2.3.7.1. Reassignment and Reallocation Information > >> > >> Each IPv4 reassignment or reallocation containing a /29 or more > addresses shall be registered in the WHOIS directory via SWIP or a > distributed service which meets the standards set forth in section 3.2. > Reassignment and reallocation registrations shall include each client's > organizational information, except where specifically exempted by this > policy. > >> > >> Current text: > >> > >> 4.2.3.7.2.Assignments visible within 7 days > >> > >> All assignments shall be made visible as required in section 4.2.3.7.1 > within seven calendar days of assignment. > >> > >> Proposed Editorial Changes: > >> > >> 4.2.3.7.2.Reassignments and Reallocations visible within 7 days > >> > >> All reassignments and reallocations shall be made visible as required > in section 4.2.3.7.1 within seven calendar days of reassignment or > reallocation. > >> > >> Current text: > >> > >> 4.2.4. ISP Additional Requests > >> > >> 4.2.4.1. Utilization percentage (80%) > >> > >> ISPs must have efficiently utilized all allocations, in aggregate, to > at least 80% and at least 50% of every allocation in order to receive > additional space. This includes all space reassigned to their customers. > >> > >> Proposed Editorial Changes: > >> > >> 4.2.4. ISP Additional Requests > >> > >> 4.2.4.1. Utilization percentage (80%) > >> > >> ISPs must have efficiently utilized all allocations, in aggregate, to > at least 80% and at least 50% of every allocation in order to receive > additional space. This includes all space reassigned or reallocated to > their customers. > >> > >> Make the following editorial changes to section 6 to clarify language > regarding current practices and requirements for reallocations and > reassignments, and specifically to clarify that recording reallocation > information is required where current language is ambiguous: > >> > >> Current text: > >> > >> 6.5.2.1(e) Initial Allocations to LIRs, Size > >> > >> For purposes of the calculation in (c), an LIR which has subordinate > LIRs shall make such allocations according to the same policies and > criteria as ARIN. In such a case, the prefixes necessary for such an > allocation should be treated as fully utilized in determining the block > sizing for the parent LIR. LIRs which do not receive resources directly > from ARIN will not be able to make such allocations to subordinate LIRs and > subordinate LIRs which need more than a /32 shall apply directly to ARIN. > >> > >> Proposed Editorial Changes: > >> > >> 6.5.2.1(e) Initial Allocations to LIRs, Size > >> > >> For purposes of the calculation in (c), an LIR which has subordinate > LIRs shall make such reallocations according to the same policies and > criteria as ARIN. In such a case, the prefixes necessary for such a > reallocation should be treated as fully utilized in determining the block > sizing for the parent LIR. LIRs which do not receive resources directly > from ARIN will not be able to make such reallocations to subordinate LIRs > and subordinate LIRs which need more than a /32 shall apply directly to > ARIN. > >> > >> Current text: > >> > >> 6.5.2.2. Qualifications > >> > >> An organization qualifies for an allocation under this policy if they > meet any of the following criteria: > >> > >> a. Have a previously justified IPv4 ISP allocation from ARIN or one of > its predecessor registries or can qualify for an IPv4 ISP allocation under > current criteria. > >> > >> b. Are currently multihomed for IPv6 or will immediately become > multihomed for IPv6 using a valid assigned global AS number. > >> > >> In either case, they will be making reassignments from allocation(s) > under this policy to other organizations. > >> > >> Provide ARIN a reasonable technical justification indicating why an > allocation is necessary. Justification must include the intended purposes > for the allocation and describe the network infrastructure the allocation > will be used to support. Justification must also include a plan detailing > anticipated assignments to other organizations or customers for one, two > and five year periods, with a minimum of 50 assignments within 5 years. > >> > >> Proposed Editorial Changes: > >> > >> 6.5.2.2. Qualifications > >> > >> An organization qualifies for an allocation under this policy if they > meet any of the following criteria: > >> > >> a. Have a previously justified IPv4 ISP allocation from ARIN or one of > its predecessor registries or can qualify for an IPv4 ISP allocation under > current criteria. > >> > >> b. Are currently multihomed for IPv6 or will immediately become > multihomed for IPv6 using a valid assigned global AS number. > >> > >> In either case, they will be making reassignments or reallocations from > allocation(s) under this policy to other organizations. > >> > >> Provide ARIN a reasonable technical justification indicating why an > allocation is necessary. Justification must include the intended purposes > for the allocation and describe the network infrastructure the allocation > will be used to support. Justification must also include a plan detailing > anticipated reassignments and reallocations to other organizations or > customers for one, two and five year periods, with a minimum of 50 > assignments within 5 years. > >> > >> Current text: > >> > >> 6.5.4. Assignments from LIRs/ISPs > >> > >> Assignments to end users shall be governed by the same practices > adopted by the community in section 6.5.8 except that the requirements in > 6.5.8.1 do not apply. > >> > >> Proposed Editorial Changes: > >> > >> 6.5.4. Reassignments from LIRs/ISPs > >> > >> Reassignments to end users shall be governed by the same practices > adopted by the community in section 6.5.8 except that the requirements in > 6.5.8.1 do not apply. > >> > >> Current text: > >> > >> 6.5.4.1. Assignment to operator's infrastructure > >> > >> An LIR may assign up to a /48 per PoP as well as up to an additional > /48 globally for its own infrastructure. > >> > >> Proposed Editorial Changes: > >> > >> 6.5.4.1. Reassignment to operator's infrastructure > >> > >> An LIR may reassign up to a /48 per PoP as well as up to an additional > /48 globally for its own infrastructure. > >> > >> Current text: > >> > >> 6.5.5. Registration > >> > >> ISPs are required to demonstrate efficient use of IP address space > allocations by providing appropriate documentation, including but not > limited to assignment histories, showing their efficient use. > >> > >> Proposed Editorial Changes: > >> > >> 6.5.5. Registration > >> > >> ISPs are required to demonstrate efficient use of IP address space > allocations by providing appropriate documentation, including but not > limited to reassignment and reallocation histories, showing their efficient > use. > >> > >> Current text: > >> > >> 6.5.5.1. Reassignment information > >> > >> Each static IPv6 assignment containing a /64 or more addresses shall be > registered in the WHOIS directory via SWIP or a distributed service which > meets the standards set forth in section 3.2. Reassignment registrations > shall include each client's organizational information, except where > specifically exempted by this policy. > >> > >> Proposed Editorial Changes: > >> > >> 6.5.5.1. Reassignment information > >> > >> Each static IPv6 reassignment or reallocation containing a /64 or more > addresses shall be registered in the WHOIS directory via SWIP or a > distributed service which meets the standards set forth in section 3.2. > Reassignment and reallocation registrations shall include each client's > organizational information, except where specifically exempted by this > policy. > >> > >> Current text: > >> > >> 6.5.5.2. Assignments visible within 7 days > >> > >> All assignments shall be made visible as required in section 4.2.3.7.1 > within seven calendar days of assignment > >> > >> Proposed Editorial Changes: > >> > >> 6.5.5.2. Reassignments and Reallocations visible within 7 days > >> > >> All reassignments and reallocations shall be made visible as required > in section 4.2.3.7.1 within seven calendar days of reassignment or > reallocation. > >> _______________________________________________ > >> 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 andrew.dul at quark.net Thu Dec 7 23:47:44 2017 From: andrew.dul at quark.net (Andrew Dul) Date: Thu, 7 Dec 2017 20:47:44 -0800 Subject: [arin-ppml] Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers In-Reply-To: <7a704972-c75b-2423-9212-30a65c3605b1@quark.net> References: <652abd11-68d7-900e-7776-b97b2311ea05@arin.net> <846F1403-01F5-4DA1-A241-3B58108E111C@quark.net> <053B38B3-B8BD-43A8-9328-B4DDFE1F7E7B@gmail.com> <7a704972-c75b-2423-9212-30a65c3605b1@quark.net> Message-ID: It was noted to me by ARIN staff, that this updated problem statement doesn't accurately reflect ARIN's current practice.? Below I suggest another updated problem statement. *Problem Statement:?* It was noted at the ARIN 40 Policy Experience Report, that there is an inconsistency in the initial block size for ISPs. Section 4.2.2 notes that the initial ISP block size should be /21 whereas the initial block size in 8.5.4 is noted as "minimum transfer size" which is effectively a /24. This causes ISP organizations to be approved for different initial block size depending on if they first apply apply for a transfer directly under section 8 or if they apply for a block under section 4.? This policy is intended to clarify this issue, by setting a consistent ISP initial IPv4 block size. It was noted that ARIN staff current operational practice is to allow qualified ISPs an initial /21 for Section 8 transfers when they first apply and are approved under section 4.? If an organization applies under section 8 first they are initially qualified for a /24, larger allocations require additional documentation as noted in 8.5.5. On 12/4/2017 1:30 PM, Andrew Dul wrote: > Scott,? how would you feel about this proposed updated problem > statement which focuses on the current issue rather than the past. > > Andrew > > *Problem Statement:?* > > It was noted at the ARIN 40 Policy Experience Report, that there is an > inconsistency in the initial block size for ISPs. Section 4.2.2 notes > that the initial ISP block size should be /21 whereas the initial > block size in 8.5.4 is noted as "minimum transfer size" which is > effectively a /24. This causes ISP organizations to be approved for > different initial block size depending on if they first apply apply > for a transfer directly under section 8 or if they apply for a block > under section 4.? This policy is intended to clarify this issue, by > setting a consistent ISP initial IPv4 block size. It was noted that > ARIN staff current operational practice is to allow all ISPs an > initial /21 for Section 8 transfers. > > > > On 11/21/2017 9:19 PM, Scott Leibrand wrote: >> I?d be ok with a /21, but there?s nothing magical about that size in >> a post-exhaustion world. I?d rather base a loosening on actual >> transfer statistics, and consider doing so for both allocations and >> assignments.? >> >> Scott >> >> On Nov 21, 2017, at 7:28 PM, Andrew Dul > > wrote: >> >>> It sounds like our recollections of what we intended for ISP initial >>> allocations have diverged. I will admit when I drafted the problem >>> statement I did not go back through email to see if there was >>> anything about this issue. >>> >>> Assuming we harmonize the problem statement, would you prefer the >>> /24 as initial no questions asked size or a /21? >>> >>> What do others prefer? >>> >>> .Andrew >>> >>> On Nov 21, 2017, at 2:52 PM, Scott Leibrand >> > wrote: >>> >>>> I believe this problem statement is incorrect, and therefore oppose >>>> the policy proposal as-is. >>>> >>>> 8.5.4 was intended (by me, as one of the authors, and in PPML >>>> discussions I just pulled up) to allow ISPs to transfer a /24 >>>> without justification.? It was *not* intended to "match the >>>> previous policy" in 4.2.2. >>>> >>>> 8.5.5 reads "8.5.5. Block size >>>> Organizations may qualify for the transfer of a larger initial >>>> block, or an additional block, by providing documentation to ARIN >>>> which details the use of at least 50% of the requested IPv4 block >>>> size within 24 months. An officer of the organization shall attest >>>> to the documentation provided to ARIN." >>>> >>>> The intention was that any ISP needing a /21 would need to "provide >>>> documentation to ARIN which details the use of at least 50% of the >>>> requested IPv4 block size within 24 months", with officer >>>> attestation to same. >>>> >>>> If that policy is deemed insufficient, and we believe it's better >>>> to allow transfers of up to /21 without providing documentation to >>>> ARIN and officer attestation of such, then this proposal would need >>>> to be re-written with a new problem statement justifying that. >>>> >>>> -Scott >>>> >>>> On Tue, Nov 21, 2017 at 2:40 PM, ARIN >>> > wrote: >>>> >>>> On 16 November 2017, the ARIN Advisory Council (AC) advanced >>>> "ARIN-prop-244: Clarification of Initial Block Size for IPv4 >>>> ISP Transfers" to Draft Policy status. >>>> >>>> Draft Policy ARIN-2017-9 is below and can be found at: >>>> https://www.arin.net/policy/proposals/2017_9.html >>>> >>>> >>>> You are encouraged to discuss all Draft Policies on PPML. The >>>> AC will evaluate the discussion in order to assess the >>>> conformance of this draft policy with ARIN's Principles of >>>> Internet number resource policy as stated in the Policy >>>> Development Process (PDP). Specifically, these principles are: >>>> >>>> * Enabling Fair and Impartial Number Resource Administration >>>> * Technically Sound >>>> * Supported by the Community >>>> >>>> The PDP can be found at: >>>> https://www.arin.net/policy/pdp.html >>>> >>>> >>>> Draft Policies and Proposals under discussion can be found at: >>>> https://www.arin.net/policy/proposals/index.html >>>> >>>> >>>> Regards, >>>> >>>> Sean Hopkins >>>> Policy Analyst >>>> American Registry for Internet Numbers (ARIN) >>>> >>>> >>>> >>>> Draft Policy ARIN-2017-9: Clarification of Initial Block Size >>>> for IPv4 ISP Transfers >>>> >>>> Problem Statement: >>>> >>>> It was noted at the ARIN 40 Policy Experience Report, that >>>> there is an inconsistency in the initial block size for ISPs. >>>> Section 4.2.2 notes that the initial ISP block size should be >>>> /21 whereas the initial block size in 8.5.4 is noted as >>>> "minimum transfer size" which is effectively a /24. The intent >>>> of the new 8.5.4 was to match the previous policy. This policy >>>> is intended to clarify this issue. It was noted that ARIN staff >>>> current operational practice is to allow ISPs an initial /21 >>>> for Section 8 transfers. >>>> >>>> Policy statement: >>>> >>>> Add the following to 8.5.4 >>>> >>>> ISP organizations without direct assignments or allocations >>>> from ARIN qualify for an initial allocation of up to a /21. >>>> >>>> Comments: >>>> >>>> a. 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. >>>> >>>> >>>> _______________________________________________ >>>> 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 daveid at panix.com Fri Dec 8 00:37:47 2017 From: daveid at panix.com (David Huberman) Date: Fri, 8 Dec 2017 00:37:47 -0500 Subject: [arin-ppml] Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers In-Reply-To: References: <652abd11-68d7-900e-7776-b97b2311ea05@arin.net> <846F1403-01F5-4DA1-A241-3B58108E111C@quark.net> <053B38B3-B8BD-43A8-9328-B4DDFE1F7E7B@gmail.com> <7a704972-c75b-2423-9212-30a65c3605b1@quark.net> Message-ID: <37CBFACF-23E2-4F69-9519-1E022900CA2F@panix.com> Thank you for the clarification. I think the staff practice is a reasonable approach and I don?t think change is needed in policy for this. The updated Problem Statement reveals the real issue here - the one we need to figure out as a community. What to do about all the requests each month for IPv4 addresses under section 4? Is it time to pass a policy to direct staff to no longer accept section 4 requests (except the ones they still fill like critical infrastructure)? I wonder what the downside of such a policy would be - anyone know? > On Dec 7, 2017, at 11:47 PM, Andrew Dul wrote: > > It was noted to me by ARIN staff, that this updated problem statement doesn't accurately reflect ARIN's current practice. Below I suggest another updated problem statement. > > Problem Statement: > > It was noted at the ARIN 40 Policy Experience Report, that there is an inconsistency in the initial block size for ISPs. Section 4.2.2 notes that the initial ISP block size should be /21 whereas the initial block size in 8.5.4 is noted as "minimum transfer size" which is effectively a /24. This causes ISP organizations to be approved for different initial block size depending on if they first apply apply for a transfer directly under section 8 or if they apply for a block under section 4. This policy is intended to clarify this issue, by setting a consistent ISP initial IPv4 block size. It was noted that ARIN staff current operational practice is to allow qualified ISPs an initial /21 for Section 8 transfers when they first apply and are approved under section 4. If an organization applies under section 8 first they are initially qualified for a /24, larger allocations require additional documentation as noted in 8.5.5. > > > >> On 12/4/2017 1:30 PM, Andrew Dul wrote: >> Scott, how would you feel about this proposed updated problem statement which focuses on the current issue rather than the past. >> >> Andrew >> >> Problem Statement: >> >> It was noted at the ARIN 40 Policy Experience Report, that there is an inconsistency in the initial block size for ISPs. Section 4.2.2 notes that the initial ISP block size should be /21 whereas the initial block size in 8.5.4 is noted as "minimum transfer size" which is effectively a /24. This causes ISP organizations to be approved for different initial block size depending on if they first apply apply for a transfer directly under section 8 or if they apply for a block under section 4. This policy is intended to clarify this issue, by setting a consistent ISP initial IPv4 block size. It was noted that ARIN staff current operational practice is to allow all ISPs an initial /21 for Section 8 transfers. >> >> >>> On 11/21/2017 9:19 PM, Scott Leibrand wrote: >>> I?d be ok with a /21, but there?s nothing magical about that size in a post-exhaustion world. I?d rather base a loosening on actual transfer statistics, and consider doing so for both allocations and assignments. >>> >>> Scott >>> >>> On Nov 21, 2017, at 7:28 PM, Andrew Dul wrote: >>> >>>> It sounds like our recollections of what we intended for ISP initial allocations have diverged. I will admit when I drafted the problem statement I did not go back through email to see if there was anything about this issue. >>>> >>>> Assuming we harmonize the problem statement, would you prefer the /24 as initial no questions asked size or a /21? >>>> >>>> What do others prefer? >>>> >>>> .Andrew >>>> >>>> On Nov 21, 2017, at 2:52 PM, Scott Leibrand wrote: >>>> >>>>> I believe this problem statement is incorrect, and therefore oppose the policy proposal as-is. >>>>> >>>>> 8.5.4 was intended (by me, as one of the authors, and in PPML discussions I just pulled up) to allow ISPs to transfer a /24 without justification. It was *not* intended to "match the previous policy" in 4.2.2. >>>>> >>>>> 8.5.5 reads "8.5.5. Block size >>>>> Organizations may qualify for the transfer of a larger initial block, or an additional block, by providing documentation to ARIN which details the use of at least 50% of the requested IPv4 block size within 24 months. An officer of the organization shall attest to the documentation provided to ARIN." >>>>> >>>>> The intention was that any ISP needing a /21 would need to "provide documentation to ARIN which details the use of at least 50% of the requested IPv4 block size within 24 months", with officer attestation to same. >>>>> >>>>> If that policy is deemed insufficient, and we believe it's better to allow transfers of up to /21 without providing documentation to ARIN and officer attestation of such, then this proposal would need to be re-written with a new problem statement justifying that. >>>>> >>>>> -Scott >>>>> >>>>>> On Tue, Nov 21, 2017 at 2:40 PM, ARIN wrote: >>>>>> On 16 November 2017, the ARIN Advisory Council (AC) advanced "ARIN-prop-244: Clarification of Initial Block Size for IPv4 ISP Transfers" to Draft Policy status. >>>>>> >>>>>> Draft Policy ARIN-2017-9 is below and can be found at: >>>>>> https://www.arin.net/policy/proposals/2017_9.html >>>>>> >>>>>> You are encouraged to discuss all Draft Policies on PPML. The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet number resource policy as stated in the Policy Development Process (PDP). Specifically, these principles are: >>>>>> >>>>>> * Enabling Fair and Impartial Number Resource Administration >>>>>> * Technically Sound >>>>>> * Supported by the Community >>>>>> >>>>>> The PDP can be found at: >>>>>> https://www.arin.net/policy/pdp.html >>>>>> >>>>>> Draft Policies and Proposals under discussion can be found at: >>>>>> https://www.arin.net/policy/proposals/index.html >>>>>> >>>>>> Regards, >>>>>> >>>>>> Sean Hopkins >>>>>> Policy Analyst >>>>>> American Registry for Internet Numbers (ARIN) >>>>>> >>>>>> >>>>>> >>>>>> Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers >>>>>> >>>>>> Problem Statement: >>>>>> >>>>>> It was noted at the ARIN 40 Policy Experience Report, that there is an inconsistency in the initial block size for ISPs. Section 4.2.2 notes that the initial ISP block size should be /21 whereas the initial block size in 8.5.4 is noted as "minimum transfer size" which is effectively a /24. The intent of the new 8.5.4 was to match the previous policy. This policy is intended to clarify this issue. It was noted that ARIN staff current operational practice is to allow ISPs an initial /21 for Section 8 transfers. >>>>>> >>>>>> Policy statement: >>>>>> >>>>>> Add the following to 8.5.4 >>>>>> >>>>>> ISP organizations without direct assignments or allocations from ARIN qualify for an initial allocation of up to a /21. >>>>>> >>>>>> Comments: >>>>>> >>>>>> a. 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. >>>>> >>>>> _______________________________________________ >>>>> 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 narten at us.ibm.com Fri Dec 8 00:53:03 2017 From: narten at us.ibm.com (narten at us.ibm.com) Date: Fri, 08 Dec 2017 00:53:03 -0500 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201712080553.vB85r3QW030154@rotala.raleigh.ibm.com> Total of 11 messages in the last 7 days. script run at: Fri Dec 8 00:53:03 EST 2017 Messages | Bytes | Who --------+------+--------+----------+------------------------ 27.27% | 3 | 35.17% | 107086 | andrew.dul at quark.net 9.09% | 1 | 16.85% | 51318 | bjones at vt.edu 18.18% | 2 | 6.66% | 20279 | tedm at ipinc.net 9.09% | 1 | 12.93% | 39362 | scottleibrand at gmail.com 9.09% | 1 | 10.32% | 31417 | daveid at panix.com 9.09% | 1 | 8.15% | 24832 | owen at delong.com 9.09% | 1 | 6.38% | 19415 | hostmaster at uneedus.com 9.09% | 1 | 3.55% | 10813 | narten at us.ibm.com --------+------+--------+----------+------------------------ 100.00% | 11 |100.00% | 304522 | Total From narten at us.ibm.com Fri Dec 15 00:53:03 2017 From: narten at us.ibm.com (narten at us.ibm.com) Date: Fri, 15 Dec 2017 00:53:03 -0500 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201712150553.vBF5r3P7006326@rotala.raleigh.ibm.com> Total of 2 messages in the last 7 days. script run at: Fri Dec 15 00:53:03 EST 2017 Messages | Bytes | Who --------+------+--------+----------+------------------------ 50.00% | 1 | 77.23% | 34335 | daveid at panix.com 50.00% | 1 | 22.77% | 10124 | narten at us.ibm.com --------+------+--------+----------+------------------------ 100.00% | 2 |100.00% | 44459 | Total From mike at iptrading.com Mon Dec 18 14:20:13 2017 From: mike at iptrading.com (Mike Burns) Date: Mon, 18 Dec 2017 14:20:13 -0500 Subject: [arin-ppml] Inter-regional ASN transfers? Message-ID: <000701d37835$3afc4f10$b0f4ed30$@iptrading.com> Hello list, I am debating a proposal to allow inter-regional ASN transfers. Short ASNs have value. We have brokered inter-regional ASN transfers between RIPE and APNIC. We have been asked about an ASN transfer from ARIN to APNIC but ARIN policy forbids this. The last time this was considered, the proposal was abandoned due to a cost/benefit analysis, and I am wondering the same objections pertain. Here are the reasons for the last abandonment: > Regarding 2014-15: > > "The following substantive issues were noted by the AC in considering > this draft policy. > > -There is outstanding technical work which must be done prior to > implementation which would allow RPKI functionality for inter-RIR ASN > transfers > -There would be a significant time delay on the full implementation of > this policy > -The implementation of 2014-15 requires agreement from all 5 RIRs on a > method to implement inter-RIR ASN transfers > -Cleanup of the 2-byte ASN registry at IANA is required before this > policy could be fully implemented > -There is significant work which must be done to implement this policy > amongst all 5 RIRs with limited perceived overall benefit to the > community, especially when weighed against other competing priorities > > While the AC believes that the limited corner case illuminated during > discussion of this draft policy is valid, it was noted that a valid > workaround, obtaining a new ASN in an appropriate RIR, is available for > all members of the community." > Input from staff or community on the current status of these objections is appreciated. Considering how it works between RIPE and APNIC, maybe the work mentioned has been completed? Regards, Mike Burns -------------- next part -------------- An HTML attachment was scrubbed... URL: From elvis at velea.eu Wed Dec 20 20:31:24 2017 From: elvis at velea.eu (Elvis Daniel Velea) Date: Wed, 20 Dec 2017 17:31:24 -0800 Subject: [arin-ppml] Inter-regional ASN transfers? In-Reply-To: <000701d37835$3afc4f10$b0f4ed30$@iptrading.com> References: <000701d37835$3afc4f10$b0f4ed30$@iptrading.com> Message-ID: <658ff155-6182-8246-e9ea-8163ecc3b991@velea.eu> I think this proposal will benefit the community. You have my +1 (and my offer to assist if you need a co-author) elvis On 12/18/17 11:20 AM, Mike Burns wrote: > > Hello list, > > I am debating a proposal to allow inter-regional ASN transfers. > > Short ASNs have value. > > We have brokered inter-regional ASN transfers between RIPE and APNIC. > > We have been asked about an ASN transfer from ARIN to APNIC but ARIN > policy forbids this. > > The last time this was considered, the proposal was abandoned due to a > cost/benefit analysis, and I am wondering the same objections pertain. > > Here are the reasons for the last abandonment: > > >/Regarding 2014-15:/ > > >// > > >/"The following substantive issues were noted by the AC in considering/ > > >/this draft policy./ > > >// > > >/-There is outstanding technical work which must be done prior to/ > > >/implementation which would allow RPKI functionality for inter-RIR ASN/ > > >/transfers/ > > >/-There would be a significant time delay on the full implementation of/ > > >/this policy/ > > >/-The implementation of 2014-15 requires agreement from all 5 RIRs on a/ > > >/method to implement inter-RIR ASN transfers/ > > >/-Cleanup of the 2-byte ASN registry at IANA is required before this/ > > >/policy could be fully implemented/ > > >/-There is significant work which must be done to implement this policy/ > > >/amongst all 5 RIRs with limited perceived overall benefit to the/ > > >/community, especially when weighed against other competing priorities/ > > >// > > >/While the AC believes that the limited corner case illuminated during/ > > >/discussion of this draft policy is valid, it was noted that a valid/ > > >/workaround, obtaining a new ASN in an appropriate RIR, is available for/ > > >/all members of the community."/ > > > > > Input from staff or community on the current status of these > objections is appreciated. > > Considering how it works between RIPE and APNIC, maybe the work > mentioned has been completed? > > Regards, > Mike Burns > > > > _______________________________________________ > 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 daveid at panix.com Wed Dec 20 20:41:54 2017 From: daveid at panix.com (David R Huberman) Date: Wed, 20 Dec 2017 20:41:54 -0500 (EST) Subject: [arin-ppml] Inter-regional ASN transfers? In-Reply-To: <000701d37835$3afc4f10$b0f4ed30$@iptrading.com> References: <000701d37835$3afc4f10$b0f4ed30$@iptrading.com> Message-ID: Mike Burns wrote: > I am debating a proposal to allow inter-regional ASN transfers. > > Short ASNs have value. Indeed. Though RFC 8092 solves the overarching problem (BGP community strings not supporting integers above 65536), it will take a long time (years) for widespread adoption of 8092-compliant code. In the meanwhile, there's a real technical deficiency here. Number resources should go where they're needed, when they're needed. Operators who use ARIN for a Registry should not have any more or less access to numbers they need than those who use another Registry. Let's be part of the solution and support inter-RIR ASN transfers. From hostmaster at uneedus.com Thu Dec 21 07:13:47 2017 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Thu, 21 Dec 2017 07:13:47 -0500 (EST) Subject: [arin-ppml] Inter-regional ASN transfers? In-Reply-To: References: <000701d37835$3afc4f10$b0f4ed30$@iptrading.com> Message-ID: Are there any technical issues related to DNSSEC or otherwise that bind ASN ranges to specific RIR's. If so, we need to talk about required measures to deal with this issue. Other than this, I see no other showstopper to portable ASN's, and would support. Albert Erdmann Network Administrator Paradise On Line Inc. On Wed, 20 Dec 2017, David R Huberman wrote: > > Mike Burns wrote: > >> I am debating a proposal to allow inter-regional ASN transfers. >> >> Short ASNs have value. > > Indeed. Though RFC 8092 solves the overarching problem (BGP community > strings not supporting integers above 65536), it will take a long time > (years) for widespread adoption of 8092-compliant code. In the meanwhile, > there's a real technical deficiency here. > > Number resources should go where they're needed, when they're needed. > > Operators who use ARIN for a Registry should not have any more or less access > to numbers they need than those who use another Registry. > > Let's be part of the solution and support inter-RIR ASN transfers. > > _______________________________________________ > 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 chris at semihuman.com Thu Dec 21 11:00:39 2017 From: chris at semihuman.com (Chris Woodfield) Date: Thu, 21 Dec 2017 08:00:39 -0800 Subject: [arin-ppml] Inter-regional ASN transfers? In-Reply-To: <000701d37835$3afc4f10$b0f4ed30$@iptrading.com> References: <000701d37835$3afc4f10$b0f4ed30$@iptrading.com> Message-ID: <95E1824A-C2A0-4DDB-8DA9-719C8D618240@semihuman.com> I personally don?t have much visibility into the resale market for short ASNs, so I?m curious - is there currently a relative supply/demand imbalance that could be alleviated by opening up the ARIN supply to other regions? Or is this meant to address future anticipated imbalances? -C > On Dec 18, 2017, at 11:20 AM, Mike Burns wrote: > > Hello list, > > I am debating a proposal to allow inter-regional ASN transfers. > Short ASNs have value. > We have brokered inter-regional ASN transfers between RIPE and APNIC. > We have been asked about an ASN transfer from ARIN to APNIC but ARIN policy forbids this. > The last time this was considered, the proposal was abandoned due to a cost/benefit analysis, and I am wondering the same objections pertain. > > Here are the reasons for the last abandonment: > > > Regarding 2014-15: > > > > "The following substantive issues were noted by the AC in considering > > this draft policy. > > > > -There is outstanding technical work which must be done prior to > > implementation which would allow RPKI functionality for inter-RIR ASN > > transfers > > -There would be a significant time delay on the full implementation of > > this policy > > -The implementation of 2014-15 requires agreement from all 5 RIRs on a > > method to implement inter-RIR ASN transfers > > -Cleanup of the 2-byte ASN registry at IANA is required before this > > policy could be fully implemented > > -There is significant work which must be done to implement this policy > > amongst all 5 RIRs with limited perceived overall benefit to the > > community, especially when weighed against other competing priorities > > > > While the AC believes that the limited corner case illuminated during > > discussion of this draft policy is valid, it was noted that a valid > > workaround, obtaining a new ASN in an appropriate RIR, is available for > > all members of the community." > > > > Input from staff or community on the current status of these objections is appreciated. > Considering how it works between RIPE and APNIC, maybe the work mentioned has been completed? > > Regards, > Mike Burns > > _______________________________________________ > 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 mike at iptrading.com Thu Dec 21 11:04:08 2017 From: mike at iptrading.com (Mike Burns) Date: Thu, 21 Dec 2017 11:04:08 -0500 Subject: [arin-ppml] Inter-regional ASN transfers? In-Reply-To: <95E1824A-C2A0-4DDB-8DA9-719C8D618240@semihuman.com> References: <000701d37835$3afc4f10$b0f4ed30$@iptrading.com> <95E1824A-C2A0-4DDB-8DA9-719C8D618240@semihuman.com> Message-ID: <008001d37a75$55ab5350$0101f9f0$@iptrading.com> Hi Chris, We find demand for short ASNs, particularly in the APNIC region. The top part of the APNIC transfer list shows a lot of ASN transfers. https://www.apnic.net/manage-ip/manage-resources/transfer-resources/transfer-logs/ They cost roughly $1K. Regards, Mike Burns From: Chris Woodfield [mailto:chris at semihuman.com] Sent: Thursday, December 21, 2017 11:01 AM To: Mike Burns Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Inter-regional ASN transfers? I personally don?t have much visibility into the resale market for short ASNs, so I?m curious - is there currently a relative supply/demand imbalance that could be alleviated by opening up the ARIN supply to other regions? Or is this meant to address future anticipated imbalances? -C On Dec 18, 2017, at 11:20 AM, Mike Burns > wrote: Hello list, I am debating a proposal to allow inter-regional ASN transfers. Short ASNs have value. We have brokered inter-regional ASN transfers between RIPE and APNIC. We have been asked about an ASN transfer from ARIN to APNIC but ARIN policy forbids this. The last time this was considered, the proposal was abandoned due to a cost/benefit analysis, and I am wondering the same objections pertain. Here are the reasons for the last abandonment: > Regarding 2014-15: > > "The following substantive issues were noted by the AC in considering > this draft policy. > > -There is outstanding technical work which must be done prior to > implementation which would allow RPKI functionality for inter-RIR ASN > transfers > -There would be a significant time delay on the full implementation of > this policy > -The implementation of 2014-15 requires agreement from all 5 RIRs on a > method to implement inter-RIR ASN transfers > -Cleanup of the 2-byte ASN registry at IANA is required before this > policy could be fully implemented > -There is significant work which must be done to implement this policy > amongst all 5 RIRs with limited perceived overall benefit to the > community, especially when weighed against other competing priorities > > While the AC believes that the limited corner case illuminated during > discussion of this draft policy is valid, it was noted that a valid > workaround, obtaining a new ASN in an appropriate RIR, is available for > all members of the community." > Input from staff or community on the current status of these objections is appreciated. Considering how it works between RIPE and APNIC, maybe the work mentioned has been completed? Regards, Mike Burns _______________________________________________ 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 Thu Dec 21 11:11:54 2017 From: job at ntt.net (Job Snijders) Date: Thu, 21 Dec 2017 16:11:54 +0000 Subject: [arin-ppml] Inter-regional ASN transfers? In-Reply-To: <000701d37835$3afc4f10$b0f4ed30$@iptrading.com> References: <000701d37835$3afc4f10$b0f4ed30$@iptrading.com> Message-ID: <20171221161154.GW4435@vurt.meerval.net> On Mon, Dec 18, 2017 at 02:20:13PM -0500, Mike Burns wrote: > I am debating a proposal to allow inter-regional ASN transfers. A degree of 'feature' parity between IP blocks and ASNs in terms of transferability makes perfect sense to me. Kind regards, Job From mike at iptrading.com Thu Dec 21 11:12:25 2017 From: mike at iptrading.com (Mike Burns) Date: Thu, 21 Dec 2017 11:12:25 -0500 Subject: [arin-ppml] Inter-regional ASN transfers? In-Reply-To: <95E1824A-C2A0-4DDB-8DA9-719C8D618240@semihuman.com> References: <000701d37835$3afc4f10$b0f4ed30$@iptrading.com> <95E1824A-C2A0-4DDB-8DA9-719C8D618240@semihuman.com> Message-ID: <009a01d37a76$7dc505b0$794f1110$@iptrading.com> Hi Chris, Sorry I didn?t address the regional imbalance issue. It does seem to me that the demand for ASN transfers is larger in other regions than in ARIN, and there is no reason to believe that ARIN couldn?t be the source for ASN transfers since the same reasons cause ARIN to be a primary source for IPv4 transfers. That is a longer history of allocations and more short numbers in ARIN. Regards, Mike From: Chris Woodfield [mailto:chris at semihuman.com] Sent: Thursday, December 21, 2017 11:01 AM To: Mike Burns Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Inter-regional ASN transfers? I personally don?t have much visibility into the resale market for short ASNs, so I?m curious - is there currently a relative supply/demand imbalance that could be alleviated by opening up the ARIN supply to other regions? Or is this meant to address future anticipated imbalances? -C On Dec 18, 2017, at 11:20 AM, Mike Burns > wrote: Hello list, I am debating a proposal to allow inter-regional ASN transfers. Short ASNs have value. We have brokered inter-regional ASN transfers between RIPE and APNIC. We have been asked about an ASN transfer from ARIN to APNIC but ARIN policy forbids this. The last time this was considered, the proposal was abandoned due to a cost/benefit analysis, and I am wondering the same objections pertain. Here are the reasons for the last abandonment: > Regarding 2014-15: > > "The following substantive issues were noted by the AC in considering > this draft policy. > > -There is outstanding technical work which must be done prior to > implementation which would allow RPKI functionality for inter-RIR ASN > transfers > -There would be a significant time delay on the full implementation of > this policy > -The implementation of 2014-15 requires agreement from all 5 RIRs on a > method to implement inter-RIR ASN transfers > -Cleanup of the 2-byte ASN registry at IANA is required before this > policy could be fully implemented > -There is significant work which must be done to implement this policy > amongst all 5 RIRs with limited perceived overall benefit to the > community, especially when weighed against other competing priorities > > While the AC believes that the limited corner case illuminated during > discussion of this draft policy is valid, it was noted that a valid > workaround, obtaining a new ASN in an appropriate RIR, is available for > all members of the community." > Input from staff or community on the current status of these objections is appreciated. Considering how it works between RIPE and APNIC, maybe the work mentioned has been completed? Regards, Mike Burns _______________________________________________ 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 Dec 21 12:06:19 2017 From: jcurran at arin.net (John Curran) Date: Thu, 21 Dec 2017 17:06:19 +0000 Subject: [arin-ppml] Inter-regional ASN transfers? In-Reply-To: References: <000701d37835$3afc4f10$b0f4ed30$@iptrading.com> Message-ID: On 21 Dec 2017, at 7:13 AM, hostmaster at uneedus.com wrote: > > Are there any technical issues related to DNSSEC or otherwise that bind ASN ranges to specific RIR's. If so, we need to talk about required measures to deal with this issue. Albert - There?s not a DNCSEC issue, but it does mean that we need to implement some form inter-RIR coordination (similar to what occurs for early ERX IPv4 blocks today) for ASNs. It is not a huge hurdle, but would represent a longer implementation period and agreement among the RIRs regarding how this gets tracked. /John John Curran President and CEO ARIN From mike at iptrading.com Thu Dec 21 12:18:02 2017 From: mike at iptrading.com (Mike Burns) Date: Thu, 21 Dec 2017 12:18:02 -0500 Subject: [arin-ppml] Inter-regional ASN transfers? In-Reply-To: References: <000701d37835$3afc4f10$b0f4ed30$@iptrading.com> Message-ID: <010101d37a7f$a83e3240$f8ba96c0$@iptrading.com> Hi John APNIC and RIPE are doing it today. Surely the agreement you reference between RIRs about tracking has been achieved between those two registries. Can you provide any guidance on the timeline of the implementation period? Or the costs involved, so we can see if it's worth the effort? Regards, Mike -----Original Message----- From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of John Curran Sent: Thursday, December 21, 2017 12:06 PM To: hostmaster at uneedus.com Cc: arin-ppml at arin.net List Subject: Re: [arin-ppml] Inter-regional ASN transfers? On 21 Dec 2017, at 7:13 AM, hostmaster at uneedus.com wrote: > > Are there any technical issues related to DNSSEC or otherwise that bind ASN ranges to specific RIR's. If so, we need to talk about required measures to deal with this issue. Albert - There?s not a DNCSEC issue, but it does mean that we need to implement some form inter-RIR coordination (similar to what occurs for early ERX IPv4 blocks today) for ASNs. It is not a huge hurdle, but would represent a longer implementation period and agreement among the RIRs regarding how this gets tracked. /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 owen at delong.com Thu Dec 21 12:30:12 2017 From: owen at delong.com (Owen DeLong) Date: Thu, 21 Dec 2017 09:30:12 -0800 Subject: [arin-ppml] Inter-regional ASN transfers? In-Reply-To: References: <000701d37835$3afc4f10$b0f4ed30$@iptrading.com> Message-ID: It potentially creates some RPKI and whois software questions IIRC. No DNSSEC implications that I can think of. Owen > On Dec 21, 2017, at 04:13 , hostmaster at uneedus.com wrote: > > Are there any technical issues related to DNSSEC or otherwise that bind ASN ranges to specific RIR's. If so, we need to talk about required measures to deal with this issue. > > Other than this, I see no other showstopper to portable ASN's, and would support. > > Albert Erdmann > Network Administrator > Paradise On Line Inc. > > > On Wed, 20 Dec 2017, David R Huberman wrote: > >> >> Mike Burns wrote: >> >>> I am debating a proposal to allow inter-regional ASN transfers. >>> Short ASNs have value. >> >> Indeed. Though RFC 8092 solves the overarching problem (BGP community strings not supporting integers above 65536), it will take a long time (years) for widespread adoption of 8092-compliant code. In the meanwhile, there's a real technical deficiency here. >> >> Number resources should go where they're needed, when they're needed. >> >> Operators who use ARIN for a Registry should not have any more or less access to numbers they need than those who use another Registry. >> >> Let's be part of the solution and support inter-RIR ASN transfers. >> >> _______________________________________________ >> 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. From jcurran at arin.net Thu Dec 21 13:37:46 2017 From: jcurran at arin.net (John Curran) Date: Thu, 21 Dec 2017 18:37:46 +0000 Subject: [arin-ppml] Inter-regional ASN transfers? In-Reply-To: <010101d37a7f$a83e3240$f8ba96c0$@iptrading.com> References: <000701d37835$3afc4f10$b0f4ed30$@iptrading.com> <010101d37a7f$a83e3240$f8ba96c0$@iptrading.com> Message-ID: On 21 Dec 2017, at 12:18 PM, Mike Burns > wrote: Hi John APNIC and RIPE are doing it today. Surely the agreement you reference between RIRs about tracking has been achieved between those two registries. Can you provide any guidance on the timeline of the implementation period? From the last inter-RIR ASN transfer proposal?s staff and legal review: "This policy would have minimal to moderate resource impact from an implementation aspect. It is estimated that implementation would occur within 3 - 9 months after ratification by the ARIN Board of Trustees. Future impact from RPKI implementation could involve either some kind of RIR<->IANA<->RIR coordination system or ERX for ASNs." FYI, /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at iptrading.com Thu Dec 21 18:02:57 2017 From: mike at iptrading.com (Mike Burns) Date: Thu, 21 Dec 2017 18:02:57 -0500 Subject: [arin-ppml] Inter-regional ASN transfers? In-Reply-To: References: <000701d37835$3afc4f10$b0f4ed30$@iptrading.com> <010101d37a7f$a83e3240$f8ba96c0$@iptrading.com> Message-ID: <01d601d37aaf$d73979d0$85ac6d70$@iptrading.com> Hi John, Thanks and Happy Holidays. I submitted a proposal so we can continue the discussion. Regards, Mike From: John Curran [mailto:jcurran at arin.net] Sent: Thursday, December 21, 2017 1:38 PM To: Mike Burns Cc: arin-ppml at arin.net List Subject: Re: [arin-ppml] Inter-regional ASN transfers? On 21 Dec 2017, at 12:18 PM, Mike Burns > wrote: Hi John APNIC and RIPE are doing it today. Surely the agreement you reference between RIRs about tracking has been achieved between those two registries. Can you provide any guidance on the timeline of the implementation period? >From the last inter-RIR ASN transfer proposal?s staff and legal review: "This policy would have minimal to moderate resource impact from an implementation aspect. It is estimated that implementation would occur within 3 - 9 months after ratification by the ARIN Board of Trustees. Future impact from RPKI implementation could involve either some kind of RIR<->IANA<->RIR coordination system or ERX for ASNs." FYI, /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From narten at us.ibm.com Fri Dec 22 00:53:03 2017 From: narten at us.ibm.com (narten at us.ibm.com) Date: Fri, 22 Dec 2017 00:53:03 -0500 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201712220553.vBM5r3bH018925@rotala.raleigh.ibm.com> Total of 14 messages in the last 7 days. script run at: Fri Dec 22 00:53:03 EST 2017 Messages | Bytes | Who --------+------+--------+----------+------------------------ 35.71% | 5 | 44.55% | 102261 | mike at iptrading.com 14.29% | 2 | 9.51% | 21833 | jcurran at arin.net 7.14% | 1 | 14.76% | 33875 | chris at semihuman.com 7.14% | 1 | 12.03% | 27605 | elvis at velea.eu 7.14% | 1 | 4.30% | 9863 | owen at delong.com 7.14% | 1 | 4.18% | 9601 | narten at us.ibm.com 7.14% | 1 | 3.72% | 8541 | hostmaster at uneedus.com 7.14% | 1 | 3.65% | 8384 | job at ntt.net 7.14% | 1 | 3.31% | 7599 | daveid at panix.com --------+------+--------+----------+------------------------ 100.00% | 14 |100.00% | 229562 | Total From info at arin.net Wed Dec 27 09:26:54 2017 From: info at arin.net (ARIN) Date: Wed, 27 Dec 2017 09:26:54 -0500 Subject: [arin-ppml] Advisory Council Meeting Results - December 2017 Message-ID: <7bd8fe74-f537-3f71-d3e9-7a0483458fc1@arin.net> In accordance with the Policy Development Process (PDP), the Advisory Council (AC) met on 21 December 2017. The AC is continuing to work on: * ARIN-2017-3: Update to NPRM 3.6: Annual Whois POC Validation * ARIN-2017-4: Remove Bidirectional Requirement for Inter-RIR Transfers * ARIN-2017-8: Amend the Definition of Community Network * ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers * ARIN-2017-10: Repeal of Immediate Need for IPv4 Address Space (NRPM Section 4.2.1.6) * ARIN-2017-11: Reallocation and Reassignment Language Cleanup * ARIN-2017-12: Require New POC Validation Upon Reassignment * ARIN-2017-13: Remove ARIN Review Requirements for Large IPv4 Reassignments/ Reallocations The PDP can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Sean Hopkins Policy Analyst American Registry for Internet Numbers (ARIN) From narten at us.ibm.com Fri Dec 29 00:53:03 2017 From: narten at us.ibm.com (narten at us.ibm.com) Date: Fri, 29 Dec 2017 00:53:03 -0500 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201712290553.vBT5r3wO028568@rotala.raleigh.ibm.com> Total of 2 messages in the last 7 days. script run at: Fri Dec 29 00:53:03 EST 2017 Messages | Bytes | Who --------+------+--------+----------+------------------------ 50.00% | 1 | 55.82% | 10161 | narten at us.ibm.com 50.00% | 1 | 44.18% | 8041 | info at arin.net --------+------+--------+----------+------------------------ 100.00% | 2 |100.00% | 18202 | Total