From info at arin.net Thu Jan 4 10:19:22 2018 From: info at arin.net (ARIN) Date: Thu, 4 Jan 2018 10:19:22 -0500 Subject: [arin-ppml] ARIN Board Adopts New Policy Message-ID: <9da7ee5a-c203-d53f-f4eb-0bf62f66a8ad@arin.net> On 14 December 2017, the Board of Trustees adopted Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements. This policy will be implemented no later than 14 March 2018 in accordance with its Staff and Legal Review, which rated the policy's resource impacts as minimal. Board of Trustees Meeting Minutes are available at: https://www.arin.net/about_us/bot/index.html Draft Policy and Policy Proposal texts are available at: https://www.arin.net/policy/proposals/index.html The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Regards, Sean Hopkins Policy Analyst American Registry for Internet Numbers (ARIN) From narten at us.ibm.com Fri Jan 5 00:53:02 2018 From: narten at us.ibm.com (narten at us.ibm.com) Date: Fri, 05 Jan 2018 00:53:02 -0500 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201801050553.w055r2Us008199@rotala.raleigh.ibm.com> Total of 2 messages in the last 7 days. script run at: Fri Jan 5 00:53:02 EST 2018 Messages | Bytes | Who --------+------+--------+----------+------------------------ 50.00% | 1 | 54.56% | 9552 | narten at us.ibm.com 50.00% | 1 | 45.44% | 7954 | info at arin.net --------+------+--------+----------+------------------------ 100.00% | 2 |100.00% | 17506 | Total From narten at us.ibm.com Fri Jan 12 00:53:03 2018 From: narten at us.ibm.com (narten at us.ibm.com) Date: Fri, 12 Jan 2018 00:53:03 -0500 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201801120553.w0C5r37T019754@rotala.raleigh.ibm.com> Total of 1 messages in the last 7 days. script run at: Fri Jan 12 00:53:03 EST 2018 Messages | Bytes | Who --------+------+--------+----------+------------------------ 100.00% | 1 |100.00% | 9521 | narten at us.ibm.com --------+------+--------+----------+------------------------ 100.00% | 1 |100.00% | 9521 | Total From farmer at umn.edu Sat Jan 13 14:14:25 2018 From: farmer at umn.edu (David Farmer) Date: Sat, 13 Jan 2018 13:14:25 -0600 Subject: [arin-ppml] Draft Policy ARIN-2017-8: Amend Community Networks Message-ID: After taking into account the discussion of ARIN-2017-8 preceding and during ARIN 40, here are the proposed revisions for the Problem and Policy Statements for ARIN-2017-8: Amend Community Networks. Note the name of the policy is being changed to account for the expansion of the scope of policy changes beyond just the definition of a Community Network. Following any initial comments or suggestion I will move this forward as an official update to the Draft Policy in a week or so. Thanks. ----- Problem Statement: The Community Networks section of the NRPM has only been used once since implementation in January 2010. Proposal ARIN-2016-7, to increase the number of use cases, was abandoned by the Advisory Council due to lack of feedback. Proposal ARIN 2017-2, to remove all mention of community networks from NRPM was met with opposition by the community. Many responded that the definition of "community network" was too narrow, which could be the reason for lack of uptake. In the discussion at ARIN 40, it was clear that more than just the definition of a community network needs to be revised and that community networks need to have allocations and not assignments made to them. Policy statement: Replace section 2.11 with the following; 2.11 Community Network *A community network is deployed, operated, and governed by its users, for the purpose of providing free or low-cost connectivity to the community it services. Users of the network or other volunteers must play a primary role in governance of the organization, other functions may be handled by either paid staff or volunteers.* Rename section 6.5.9 and revise the last sentence as follows; 6.5.9. Community Network *Allocations* While community networks would normally be considered to be ISP type organizations under existing ARIN criteria, they tend to operate on much tighter budgets and often depend on volunteer labor. As a result, they tend to be much smaller and more communal in their organization rather than provider/customer relationships of commercial ISPs. This section seeks to provide policy that is more friendly to those environments by allowing *community network to receive a smaller allocation than other LIRs or commercial ISPs.* Replace section 6.5.9.2 and 6.5.9.3 with the following; *6.5.9.2. Allocation Size* *Community Networks are eligible only to receive an allocation of /40 of IPv6 resources under this section. Community Networks that wish to receive a larger initial allocation or any subsequent allocations must qualify as a regular LIR, see sections 6.5.2 or 6.5.3 respectively. * *6.5.9.3. Reassignments by Community Networks* *Similar to other LIRs, Community Networks shall make reassignments to end-users in accordance with applicable policies, in particular but not limited to sections 6.5.4 and 6.5.5. However, they shall not reallocate resources to other organizations.* Comments: Timetable for implementation: Immediate -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From hostmaster at uneedus.com Sun Jan 14 12:23:46 2018 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Sun, 14 Jan 2018 12:23:46 -0500 (EST) Subject: [arin-ppml] Draft Policy ARIN-2017-8: Amend Community Networks In-Reply-To: References: Message-ID: I support the changes you have made. This language looks like it could support most types of community networks, from the smallest neighbor-to-neighbor links, to larger more formal networks like the Southeast Florida Library Information Network. The fact that the Community network definition only technically covers IPv6 resources should not be a problem. If one were establishing a community network today, it is clear the backbone would be IPv6 based. With the costs involved in todays market of obtaining IPv4 resources, it is very likely that any IPv4 connections would end up being routed thru some kind of NAT, with the public addresses provided by the upstream(s) being used. For Florida, one of the largest is SEFLIN. They are still IPv4 only, obtaining many of its resources from Florida Atlantic University. They might simply get a block of IPv6 from FAU when they take the plunge into dual stack. However, even a larger network like theirs could benefit from this policy, as even a /40 would still provide growth for new users. Albert Erdmann Network Administrator Paradise On Line Inc. On Sat, 13 Jan 2018, David Farmer wrote: > After taking into account the discussion of ARIN-2017-8 preceding and > during ARIN 40, here are the proposed revisions for the Problem and Policy > Statements for ARIN-2017-8: Amend Community Networks. > > Note the name of the policy is being changed to account for the expansion > of the scope of policy changes beyond just the definition of a Community > Network. > > Following any initial comments or suggestion I will move this forward as an > official update to the Draft Policy in a week or so. > > Thanks. > > ----- > > Problem Statement: > > The Community Networks section of the NRPM has only been used once since > implementation in January 2010. Proposal ARIN-2016-7, to increase the > number of use cases, was abandoned by the Advisory Council due to lack of > feedback. Proposal ARIN 2017-2, to remove all mention of community networks > from NRPM was met with opposition by the community. Many responded that the > definition of "community network" was too narrow, which could be the reason > for lack of uptake. > > In the discussion at ARIN 40, it was clear that more than just the > definition of a community network needs to be revised and that community > networks need to have allocations and not assignments made to them. > > Policy statement: > > Replace section 2.11 with the following; > > 2.11 Community Network > > *A community network is deployed, operated, and governed by its users, for > the purpose of providing free or low-cost connectivity to the community it > services. Users of the network or other volunteers must play a primary role > in governance of the organization, other functions may be handled by either > paid staff or volunteers.* > > Rename section 6.5.9 and revise the last sentence as follows; > > 6.5.9. Community Network *Allocations* > > While community networks would normally be considered to be ISP type > organizations under existing ARIN criteria, they tend to operate on much > tighter budgets and often depend on volunteer labor. As a result, they tend > to be much smaller and more communal in their organization rather than > provider/customer relationships of commercial ISPs. This section seeks to > provide policy that is more friendly to those environments by allowing > *community > network to receive a smaller allocation than other LIRs or commercial ISPs.* > > Replace section 6.5.9.2 and 6.5.9.3 with the following; > > *6.5.9.2. Allocation Size* > > *Community Networks are eligible only to receive an allocation of /40 of > IPv6 resources under this section. Community Networks that wish to receive > a larger initial allocation or any subsequent allocations must qualify as a > regular LIR, see sections 6.5.2 or 6.5.3 respectively. * > > *6.5.9.3. Reassignments by Community Networks* > > *Similar to other LIRs, Community Networks shall make reassignments to > end-users in accordance with applicable policies, in particular but not > limited to sections 6.5.4 and 6.5.5. However, they shall not reallocate > resources to other organizations.* > > Comments: > > Timetable for implementation: Immediate > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> > Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> > =============================================== > From carlton.samuels at gmail.com Sun Jan 14 21:49:51 2018 From: carlton.samuels at gmail.com (Carlton Samuels) Date: Sun, 14 Jan 2018 21:49:51 -0500 Subject: [arin-ppml] Draft Policy ARIN-2017-8: Amend Community Networks In-Reply-To: References: Message-ID: I would support this reformulation. Best, -Carlton ============================== *Carlton A Samuels* *Mobile: 876-818-1799Strategy, Planning, Governance, Assessment & Turnaround* ============================= On Sat, Jan 13, 2018 at 2:14 PM, David Farmer wrote: > After taking into account the discussion of ARIN-2017-8 preceding and > during ARIN 40, here are the proposed revisions for the Problem and Policy > Statements for ARIN-2017-8: Amend Community Networks. > > Note the name of the policy is being changed to account for the expansion > of the scope of policy changes beyond just the definition of a Community > Network. > > Following any initial comments or suggestion I will move this forward as > an official update to the Draft Policy in a week or so. > > Thanks. > > ----- > > Problem Statement: > > The Community Networks section of the NRPM has only been used once since > implementation in January 2010. Proposal ARIN-2016-7, to increase the > number of use cases, was abandoned by the Advisory Council due to lack of > feedback. Proposal ARIN 2017-2, to remove all mention of community networks > from NRPM was met with opposition by the community. Many responded that the > definition of "community network" was too narrow, which could be the reason > for lack of uptake. > > In the discussion at ARIN 40, it was clear that more than just the > definition of a community network needs to be revised and that community > networks need to have allocations and not assignments made to them. > > Policy statement: > > Replace section 2.11 with the following; > > 2.11 Community Network > > *A community network is deployed, operated, and governed by its users, for > the purpose of providing free or low-cost connectivity to the community it > services. Users of the network or other volunteers must play a primary role > in governance of the organization, other functions may be handled by either > paid staff or volunteers.* > > Rename section 6.5.9 and revise the last sentence as follows; > > 6.5.9. Community Network *Allocations* > > While community networks would normally be considered to be ISP type > organizations under existing ARIN criteria, they tend to operate on much > tighter budgets and often depend on volunteer labor. As a result, they tend > to be much smaller and more communal in their organization rather than > provider/customer relationships of commercial ISPs. This section seeks to > provide policy that is more friendly to those environments by allowing *community > network to receive a smaller allocation than other LIRs or commercial ISPs.* > > Replace section 6.5.9.2 and 6.5.9.3 with the following; > > *6.5.9.2. Allocation Size* > > *Community Networks are eligible only to receive an allocation of /40 of > IPv6 resources under this section. Community Networks that wish to receive > a larger initial allocation or any subsequent allocations must qualify as a > regular LIR, see sections 6.5.2 or 6.5.3 respectively. * > > *6.5.9.3. Reassignments by Community Networks* > > *Similar to other LIRs, Community Networks shall make reassignments to > end-users in accordance with applicable policies, in particular but not > limited to sections 6.5.4 and 6.5.5. However, they shall not reallocate > resources to other organizations.* > > Comments: > > Timetable for implementation: Immediate > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> > Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> > =============================================== > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmer at umn.edu Tue Jan 16 10:37:17 2018 From: farmer at umn.edu (David Farmer) Date: Tue, 16 Jan 2018 09:37:17 -0600 Subject: [arin-ppml] Draft Policy ARIN-2017-8: Amend Community Networks In-Reply-To: References: Message-ID: Based on private feedback I have made some grammatical correction, primarily in section 2.11; Additional feedback is appreciated. ----- After taking into account the discussion of ARIN-2017-8 preceding and during ARIN 40, here are the proposed revisions to the Problem and Policy Statements for ARIN-2017-8: Amend Community Networks. Note the name of the policy is being changed to account for the expansion of the scope of policy changes beyond just the definition of a Community Network. Following initial comments or suggestions, I will move this forward as an official update to the Draft Policy in a week or so. Thanks. ----- Problem Statement: The Community Networks section of the NRPM has only been used once since implementation in January 2010. Proposal ARIN-2016-7, to increase the number of use cases, was abandoned by the Advisory Council due to lack of feedback. Proposal ARIN 2017-2, to remove all mention of community networks from NRPM was met with opposition by the community. Many responded that the definition of "community network" was too narrow, which could be the reason for lack of uptake. In the discussion at ARIN 40, it was clear that more than just the definition of a community network needs to be revised and that community networks need to have allocations and not assignments made to them. Policy statement: Replace section 2.11 with the following; 2.11 Community Network *A community network is deployed, operated, and governed by its users, for the purpose of providing free or low-cost connectivity to the community it services. Users of the network or other volunteers must play a primary role in the governance of the organization, whereas other functions may be handled by either paid staff or volunteers.* Rename section 6.5.9 and revise the last sentence as follows; 6.5.9. Community Network *Allocations* While community networks would normally be considered to be ISP type organizations under existing ARIN criteria, they tend to operate on much tighter budgets and often depend on volunteer labor. As a result, they tend to be much smaller and more communal in their organization rather than provider/customer relationships of commercial ISPs. This section seeks to provide *a* policy that is more friendly to those environments by allowing *community network to receive a smaller allocation than other LIRs or commercial ISPs.* Replace section 6.5.9.2 and 6.5.9.3 with the following; *6.5.9.2. Allocation SizeCommunity Networks are eligible only to receive an allocation of /40 of IPv6 resources under this section. Community Networks that wish to receive a larger initial allocation or any subsequent allocations must qualify as a regular LIR, see sections 6.5.2 or 6.5.3 respectively. 6.5.9.3. Reassignments by Community NetworksSimilar to other LIRs, Community Networks shall make reassignments to end-users in accordance with applicable policies, in particular, but not limited to sections 6.5.4 and 6.5.5. However, they shall not reallocate resources to other organizations.* Comments: Timetable for implementation: Immediate -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From jschiller at google.com Tue Jan 16 12:04:01 2018 From: jschiller at google.com (Jason Schiller) Date: Tue, 16 Jan 2018 12:04:01 -0500 Subject: [arin-ppml] Draft Policy ARIN-2017-8: Amend Community Networks In-Reply-To: References: Message-ID: I support the proposal with the exclusion of section 6.5.9.3. I support the proposal with the inclusion of section 6.5.9.3. I ask what is the purpose of section 6.5.9.3? Is section 6.5.9.3 needed? Is section 6.5.9.3 restricting the right thing? Without section 6.5.9.3 the policy clearly defines a community network, and allows what would otherwise be an LIR getting a /32 (or /36 upon request) get instead a /40. This would reduce there fees from X-small $1,000 annunally (or upon request 2X-small $500 annually) to 3X-small $250 annually. Sounds well and good. Section 6.5.9.3 adds a further restriction of there shall be no no re-allocations, suggesting they cannot have a user of their space which in turn has its own users. (for the record I think you can drop the text "to other organizations." and just have "However, they shall not reallocate resources.") What behavior are you intending to prevent? Doesn't the definition already have the required limits on behavior in the form of: "A community network is deployed, operated, and governed by its users, for the purpose of providing free or low-cost connectivity to the community it services." It appears what you are preventing are the cases below. I ask is this what you intend to prevent? and if so why? Should the Colorado IPv6 cooperative be prevented from providing transit to the Rocky Mountain Spotted IPv6 community network because they in turn assign IPv6 addresses to community members? What if this is all within one community network? What if the Rocky Mountain Spotted IPv6 community network has a part of the network that is managed by a group in Ball Mountain community and another part is managed by a group in Mount Lincoln. Wouldn't it make sense to re-allocate some of the Rocky Mountain Spotted IPv6 community network's /40 to Ball Mountain community and let them handle the assignments to users in their locale? ___Jason On Sat, Jan 13, 2018 at 2:14 PM, David Farmer wrote: > After taking into account the discussion of ARIN-2017-8 preceding and > during ARIN 40, here are the proposed revisions for the Problem and Policy > Statements for ARIN-2017-8: Amend Community Networks. > > Note the name of the policy is being changed to account for the expansion > of the scope of policy changes beyond just the definition of a Community > Network. > > Following any initial comments or suggestion I will move this forward as > an official update to the Draft Policy in a week or so. > > Thanks. > > ----- > > Problem Statement: > > The Community Networks section of the NRPM has only been used once since > implementation in January 2010. Proposal ARIN-2016-7, to increase the > number of use cases, was abandoned by the Advisory Council due to lack of > feedback. Proposal ARIN 2017-2, to remove all mention of community networks > from NRPM was met with opposition by the community. Many responded that the > definition of "community network" was too narrow, which could be the reason > for lack of uptake. > > In the discussion at ARIN 40, it was clear that more than just the > definition of a community network needs to be revised and that community > networks need to have allocations and not assignments made to them. > > Policy statement: > > Replace section 2.11 with the following; > > 2.11 Community Network > > *A community network is deployed, operated, and governed by its users, for > the purpose of providing free or low-cost connectivity to the community it > services. Users of the network or other volunteers must play a primary role > in governance of the organization, other functions may be handled by either > paid staff or volunteers.* > > Rename section 6.5.9 and revise the last sentence as follows; > > 6.5.9. Community Network *Allocations* > > While community networks would normally be considered to be ISP type > organizations under existing ARIN criteria, they tend to operate on much > tighter budgets and often depend on volunteer labor. As a result, they tend > to be much smaller and more communal in their organization rather than > provider/customer relationships of commercial ISPs. This section seeks to > provide policy that is more friendly to those environments by allowing *community > network to receive a smaller allocation than other LIRs or commercial ISPs.* > > Replace section 6.5.9.2 and 6.5.9.3 with the following; > > *6.5.9.2. Allocation Size* > > *Community Networks are eligible only to receive an allocation of /40 of > IPv6 resources under this section. Community Networks that wish to receive > a larger initial allocation or any subsequent allocations must qualify as a > regular LIR, see sections 6.5.2 or 6.5.3 respectively. * > > *6.5.9.3. Reassignments by Community Networks* > > *Similar to other LIRs, Community Networks shall make reassignments to > end-users in accordance with applicable policies, in particular but not > limited to sections 6.5.4 and 6.5.5. However, they shall not reallocate > resources to other organizations.* > > Comments: > > Timetable for implementation: Immediate > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> > Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> > =============================================== > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmer at umn.edu Tue Jan 16 15:57:28 2018 From: farmer at umn.edu (David Farmer) Date: Tue, 16 Jan 2018 14:57:28 -0600 Subject: [arin-ppml] Draft Policy ARIN-2017-8: Amend Community Networks In-Reply-To: References: Message-ID: On Tue, Jan 16, 2018 at 11:04 AM, Jason Schiller wrote: > I support the proposal with the exclusion of section 6.5.9.3. > I support the proposal with the inclusion of section 6.5.9.3. > I ask what is the purpose of section 6.5.9.3? > Is section 6.5.9.3 needed? > Is section 6.5.9.3 restricting the right thing? > > Without section 6.5.9.3 the policy clearly defines a community network, > and allows what would otherwise be an LIR getting a /32 (or /36 upon > request) > get instead a /40. > > This would reduce there fees from X-small $1,000 annunally > (or upon request 2X-small $500 annually) > to 3X-small $250 annually. > > Sounds well and good. > > > Section 6.5.9.3 adds a further restriction of there shall be no no > re-allocations, > suggesting they cannot have a user of their space which in turn has its > own users. > > (for the record I think you can drop the text "to other organizations." > and just have "However, they shall not reallocate resources.") > > > What behavior are you intending to prevent? > Section 6.5.9.3 has two parts. The first part says community networks are like other LIRs, they make reassignments to end-users and makes it abundantly clear that section 6.5.4 and 6.5.5 apply to community networks. I don't want anyone arguing that those sections don't apply to community networks. The second part is the restriction on making reallocations. This comes back to a couple of arguments; (A.) If community networks can make reallocations, then there is no difference between them and a regular ISP/LIR, and some participants in earlier discussions were adamant there needed to be a difference between community networks and regular ISPs/LIRs. (B.) From the debate on ARIN-2013-3: Tiny IPv6 Allocations for ISPs, some participants in that discussion were adamant that a /40 was too small of an allocation for an ISP, especially if that ISP was to make any reallocations. Doesn't the definition already have the required limits on behavior in the > form of: > > "A community network is deployed, operated, and governed by its users, > for the purpose of providing free or low-cost connectivity to the > community it services." > > It appears what you are preventing are the cases below. I ask is this > what you > intend to prevent? and if so why? > > Should the Colorado IPv6 cooperative be prevented from providing transit > to the > Rocky Mountain Spotted IPv6 community network because they in turn assign > IPv6 addresses to community members? > > > What if this is all within one community network? What if the Rocky > Mountain > Spotted IPv6 community network has a part of the network that is managed by > a group in Ball Mountain community and another part is managed by a group > in > Mount Lincoln. Wouldn't it make sense to re-allocate some of the Rocky > Mountain > Spotted IPv6 community network's /40 to Ball Mountain community and let > them > handle the assignments to users in their locale? > Personly, I'd be fine with removing the restriction on community networks making reallocations, but I'd still want to have section 6.5.9.3 I'd rewrite is as follows; *6.5.9.3. Reassignments by Community Networks* *Similar to other LIRs, Community Networks shall make reassignments and reallocations in accordance with applicable policies, in particular, but not limited to sections 6.5.4 and 6.5.5. * What do others think should community networks be allowed to make both reassignments and reallocations, or just reassignments? Thanks. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From admin at wsfnet.org Tue Jan 16 16:04:33 2018 From: admin at wsfnet.org (Whitestone IT) Date: Tue, 16 Jan 2018 21:04:33 +0000 Subject: [arin-ppml] Draft Policy ARIN-2017-8: Amend Community Networks In-Reply-To: References: Message-ID: I would prefer for community networks to be able to make reallocations; it could enhance commercial opportunities that could help elevate the network up to traditional ISP status. My $.02 On Tue, Jan 16, 2018 at 11:57 AM David Farmer wrote: > On Tue, Jan 16, 2018 at 11:04 AM, Jason Schiller > wrote: > >> I support the proposal with the exclusion of section 6.5.9.3. >> I support the proposal with the inclusion of section 6.5.9.3. >> I ask what is the purpose of section 6.5.9.3? >> Is section 6.5.9.3 needed? >> Is section 6.5.9.3 restricting the right thing? >> >> Without section 6.5.9.3 the policy clearly defines a community network, >> and allows what would otherwise be an LIR getting a /32 (or /36 upon >> request) >> get instead a /40. >> >> This would reduce there fees from X-small $1,000 annunally >> (or upon request 2X-small $500 annually) >> to 3X-small $250 annually. >> >> Sounds well and good. >> >> >> Section 6.5.9.3 adds a further restriction of there shall be no no >> re-allocations, >> suggesting they cannot have a user of their space which in turn has its >> own users. >> >> (for the record I think you can drop the text "to other organizations." >> and just have "However, they shall not reallocate resources.") >> >> >> What behavior are you intending to prevent? >> > > Section 6.5.9.3 has two parts. > > The first part says community networks are like other LIRs, they make > reassignments to end-users and makes it abundantly clear that section 6.5.4 > and 6.5.5 apply to community networks. I don't want anyone arguing that > those sections don't apply to community networks. > > The second part is the restriction on making reallocations. This comes > back to a couple of arguments; (A.) If community networks can make > reallocations, then there is no difference between them and a regular > ISP/LIR, and some participants in earlier discussions were adamant there > needed to be a difference between community networks and regular ISPs/LIRs. > (B.) From the debate on ARIN-2013-3: Tiny IPv6 Allocations for ISPs, some > participants in that discussion were adamant that a /40 was too small of an > allocation for an ISP, especially if that ISP was to make any > reallocations. > > Doesn't the definition already have the required limits on behavior in the >> form of: >> > >> "A community network is deployed, operated, and governed by its users, >> for the purpose of providing free or low-cost connectivity to the >> community it services." >> >> It appears what you are preventing are the cases below. I ask is this >> what you >> intend to prevent? and if so why? >> >> Should the Colorado IPv6 cooperative be prevented from providing transit >> to the >> Rocky Mountain Spotted IPv6 community network because they in turn assign >> IPv6 addresses to community members? >> >> >> What if this is all within one community network? What if the Rocky >> Mountain >> Spotted IPv6 community network has a part of the network that is managed >> by >> a group in Ball Mountain community and another part is managed by a group >> in >> Mount Lincoln. Wouldn't it make sense to re-allocate some of the Rocky >> Mountain >> Spotted IPv6 community network's /40 to Ball Mountain community and let >> them >> handle the assignments to users in their locale? >> > > Personly, I'd be fine with removing the restriction on community networks > making reallocations, but I'd still want to have section 6.5.9.3 I'd > rewrite is as follows; > > *6.5.9.3. Reassignments by Community Networks* > > *Similar to other LIRs, Community Networks shall make reassignments and > reallocations in accordance with applicable policies, in particular, but > not limited to sections 6.5.4 and 6.5.5. * > > What do others think should community networks be allowed to make > both reassignments and reallocations, or just reassignments? > > Thanks. > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =============================================== > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Tue Jan 16 16:09:09 2018 From: owen at delong.com (Owen DeLong) Date: Tue, 16 Jan 2018 13:09:09 -0800 Subject: [arin-ppml] Draft Policy ARIN-2017-8: Amend Community Networks In-Reply-To: References: Message-ID: <1A0E5953-E77D-4A0F-A580-0B6B877EB1AF@delong.com> David summarized my views on the matter rather well. I am adamantly opposed to trying to make reallocations out of /40 (or longer) prefixes. Really, a /40 is 256 /48s. Any rational reallocation would be at least a /44. Is anyone really in need of running an ISP with only 16 /48s? I?d rather see any such ISP that is subordinate to a community network (if such a construct exists) get their space directly from ARIN under this same policy than see us daisy chaining community networks through micro-allocations in IPv6. I?m operating under the assumption that any ISP that has a subordinate ISP that isn?t a community network isn?t really a community network, though I suppose it might be possible under the proposed rules to engineer such a thing if one tried hard enough. Nonetheless, I would argue that such a construct is a clear violation of the spirit of the policy even if you found a way to do it within the proverbial letter of the law. Owen > On Jan 16, 2018, at 12:57 , David Farmer wrote: > > On Tue, Jan 16, 2018 at 11:04 AM, Jason Schiller > wrote: > I support the proposal with the exclusion of section 6.5.9.3. > I support the proposal with the inclusion of section 6.5.9.3. > I ask what is the purpose of section 6.5.9.3? > Is section 6.5.9.3 needed? > Is section 6.5.9.3 restricting the right thing? > > Without section 6.5.9.3 the policy clearly defines a community network, > and allows what would otherwise be an LIR getting a /32 (or /36 upon request) > get instead a /40. > > This would reduce there fees from X-small $1,000 annunally > (or upon request 2X-small $500 annually) > to 3X-small $250 annually. > > Sounds well and good. > > > Section 6.5.9.3 adds a further restriction of there shall be no no re-allocations, > suggesting they cannot have a user of their space which in turn has its own users. > > (for the record I think you can drop the text "to other organizations." > and just have "However, they shall not reallocate resources.") > > > What behavior are you intending to prevent? > > Section 6.5.9.3 has two parts. > > The first part says community networks are like other LIRs, they make reassignments to end-users and makes it abundantly clear that section 6.5.4 and 6.5.5 apply to community networks. I don't want anyone arguing that those sections don't apply to community networks. > > The second part is the restriction on making reallocations. This comes back to a couple of arguments; (A.) If community networks can make reallocations, then there is no difference between them and a regular ISP/LIR, and some participants in earlier discussions were adamant there needed to be a difference between community networks and regular ISPs/LIRs. (B.) From the debate on ARIN-2013-3: Tiny IPv6 Allocations for ISPs, some participants in that discussion were adamant that a /40 was too small of an allocation for an ISP, especially if that ISP was to make any reallocations. > > Doesn't the definition already have the required limits on behavior in the form of: > > "A community network is deployed, operated, and governed by its users, > for the purpose of providing free or low-cost connectivity to the community it services." > > It appears what you are preventing are the cases below. I ask is this what you > intend to prevent? and if so why? > > Should the Colorado IPv6 cooperative be prevented from providing transit to the > Rocky Mountain Spotted IPv6 community network because they in turn assign > IPv6 addresses to community members? > > > What if this is all within one community network? What if the Rocky Mountain > Spotted IPv6 community network has a part of the network that is managed by > a group in Ball Mountain community and another part is managed by a group in > Mount Lincoln. Wouldn't it make sense to re-allocate some of the Rocky Mountain > Spotted IPv6 community network's /40 to Ball Mountain community and let them > handle the assignments to users in their locale? > > Personly, I'd be fine with removing the restriction on community networks making reallocations, but I'd still want to have section 6.5.9.3 I'd rewrite is as follows; > > 6.5.9.3. Reassignments by Community Networks > > Similar to other LIRs, Community Networks shall make reassignments and reallocations in accordance with applicable policies, in particular, but not limited to sections 6.5.4 and 6.5.5. > > What do others think should community networks be allowed to make both reassignments and reallocations, or just reassignments? > > Thanks. > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =============================================== > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmer at umn.edu Tue Jan 16 16:27:54 2018 From: farmer at umn.edu (David Farmer) Date: Tue, 16 Jan 2018 15:27:54 -0600 Subject: [arin-ppml] Draft Policy ARIN-2017-8: Amend Community Networks In-Reply-To: References: Message-ID: Playing a little bit of a devil's advocate here, but why shouldn't traditional ISP's be able to start off with a /40 too? What makes community networks special that they should get to start out with a /40 and be able to do all the same things that a traditional ISP can do? Note: under the current proposal a community network can make reallocations if it applies as a regular LIR under section 6.5.2 and gets a /36, /32, or larger if it can justify such. The intent is that the restriction applies only to community networks that elect to receive a /40. If they grow, they then need to qualify as regular LIR and get a /36, or larger, and then they qualify to make reallocations. Thanks. On Tue, Jan 16, 2018 at 3:04 PM, Whitestone IT wrote: > I would prefer for community networks to be able to make reallocations; it > could enhance commercial opportunities that could help elevate the network > up to traditional ISP status. > > My $.02 > On Tue, Jan 16, 2018 at 11:57 AM David Farmer wrote: > >> On Tue, Jan 16, 2018 at 11:04 AM, Jason Schiller >> wrote: >> >>> I support the proposal with the exclusion of section 6.5.9.3. >>> I support the proposal with the inclusion of section 6.5.9.3. >>> I ask what is the purpose of section 6.5.9.3? >>> Is section 6.5.9.3 needed? >>> Is section 6.5.9.3 restricting the right thing? >>> >>> Without section 6.5.9.3 the policy clearly defines a community network, >>> and allows what would otherwise be an LIR getting a /32 (or /36 upon >>> request) >>> get instead a /40. >>> >>> This would reduce there fees from X-small $1,000 annunally >>> (or upon request 2X-small $500 annually) >>> to 3X-small $250 annually. >>> >>> Sounds well and good. >>> >>> >>> Section 6.5.9.3 adds a further restriction of there shall be no no >>> re-allocations, >>> suggesting they cannot have a user of their space which in turn has its >>> own users. >>> >>> (for the record I think you can drop the text "to other organizations." >>> and just have "However, they shall not reallocate resources.") >>> >>> >>> What behavior are you intending to prevent? >>> >> >> Section 6.5.9.3 has two parts. >> >> The first part says community networks are like other LIRs, they make >> reassignments to end-users and makes it abundantly clear that section 6.5.4 >> and 6.5.5 apply to community networks. I don't want anyone arguing that >> those sections don't apply to community networks. >> >> The second part is the restriction on making reallocations. This comes >> back to a couple of arguments; (A.) If community networks can make >> reallocations, then there is no difference between them and a regular >> ISP/LIR, and some participants in earlier discussions were adamant there >> needed to be a difference between community networks and regular ISPs/LIRs. >> (B.) From the debate on ARIN-2013-3: Tiny IPv6 Allocations for ISPs, some >> participants in that discussion were adamant that a /40 was too small of an >> allocation for an ISP, especially if that ISP was to make any >> reallocations. >> >> Doesn't the definition already have the required limits on behavior in >>> the form of: >>> >> >>> "A community network is deployed, operated, and governed by its users, >>> for the purpose of providing free or low-cost connectivity to the >>> community it services." >>> >>> It appears what you are preventing are the cases below. I ask is this >>> what you >>> intend to prevent? and if so why? >>> >>> Should the Colorado IPv6 cooperative be prevented from providing transit >>> to the >>> Rocky Mountain Spotted IPv6 community network because they in turn >>> assign >>> IPv6 addresses to community members? >>> >>> >>> What if this is all within one community network? What if the Rocky >>> Mountain >>> Spotted IPv6 community network has a part of the network that is managed >>> by >>> a group in Ball Mountain community and another part is managed by a >>> group in >>> Mount Lincoln. Wouldn't it make sense to re-allocate some of the Rocky >>> Mountain >>> Spotted IPv6 community network's /40 to Ball Mountain community and let >>> them >>> handle the assignments to users in their locale? >>> >> >> Personly, I'd be fine with removing the restriction on community networks >> making reallocations, but I'd still want to have section 6.5.9.3 I'd >> rewrite is as follows; >> >> *6.5.9.3. Reassignments by Community Networks* >> >> *Similar to other LIRs, Community Networks shall make reassignments and >> reallocations in accordance with applicable policies, in particular, but >> not limited to sections 6.5.4 and 6.5.5. * >> >> What do others think should community networks be allowed to make >> both reassignments and reallocations, or just reassignments? >> >> Thanks. >> >> -- >> =============================================== >> David Farmer Email:farmer at umn.edu >> Networking & Telecommunication Services >> Office of Information Technology >> University of Minnesota >> 2218 University Ave SE >> >> Phone: 612-626-0815 <(612)%20626-0815> >> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> >> =============================================== >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > > -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From hostmaster at uneedus.com Tue Jan 16 19:41:08 2018 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Tue, 16 Jan 2018 19:41:08 -0500 (EST) Subject: [arin-ppml] Draft Policy ARIN-2017-8: Amend Community Networks In-Reply-To: References: Message-ID: I really never considered until this was brought up that community networks might want to band together to provide backbone connectivity or otherwise associate with each other. I do not think the Community network provisions of policy should forbid this. Based on the discussion around 2017-5, it appears that the most important thing for accountability is the registration of blocks routed differently or assigned to others, which in this example are other community networks for specific areas unless the Community Network holding the space manages abuse for the smaller Community Networks below it. Since the end users would have a /48 or less, there is no need to register the end users. under the adopted 2017-5, unless they have requested registration. In the example, Rocky Mountain Spotted IPv6 community network might apply for a /40 from ARIN for $250/year. It could do this, or obtain an allocation from Colorado IPv6 cooperative to use. Instead of operating this entire network itself, it might choose to allow other existing smaller groups to operate parts of the network such as the Ball Mountain community and Mount Lincoln. I have no heartburn with these delegations as long as they are SWIP'ed, so we know who is managing each segment of the overall network. While some might argue that it is no big deal to become a full LIR and get more space, that space comes at a greater cost which may not be affordable. Many of these groups just manage the network, with the end users providing their own access nodes at their own expense, often using some sort of point to point wireless connectivity. The amount of "cash" for things such as ARIN fees may in fact be quite limited. While it is not the "recommended" way to do it, some of these community networks may "find" more space for end users by assigning less than a /48 to most of its end users, assigning that smaller value by default, and only giving a /48 to end users upon a specific request. This allows more users, without more cost for annual fees. I therefore go along with the proposed rewrite of 6.5.9.3. I do not see a valid reason to prevent community networks from banding together. Albert Erdmann Network Administrator Paradise On Line Inc. On Tue, 16 Jan 2018, David Farmer wrote: > On Tue, Jan 16, 2018 at 11:04 AM, Jason Schiller > wrote: > >> I support the proposal with the exclusion of section 6.5.9.3. >> I support the proposal with the inclusion of section 6.5.9.3. >> I ask what is the purpose of section 6.5.9.3? >> Is section 6.5.9.3 needed? >> Is section 6.5.9.3 restricting the right thing? >> >> Without section 6.5.9.3 the policy clearly defines a community network, >> and allows what would otherwise be an LIR getting a /32 (or /36 upon >> request) >> get instead a /40. >> >> This would reduce there fees from X-small $1,000 annunally >> (or upon request 2X-small $500 annually) >> to 3X-small $250 annually. >> >> Sounds well and good. >> >> >> Section 6.5.9.3 adds a further restriction of there shall be no no >> re-allocations, >> suggesting they cannot have a user of their space which in turn has its >> own users. >> >> (for the record I think you can drop the text "to other organizations." >> and just have "However, they shall not reallocate resources.") >> >> >> What behavior are you intending to prevent? >> > > Section 6.5.9.3 has two parts. > > The first part says community networks are like other LIRs, they make > reassignments to end-users and makes it abundantly clear that section 6.5.4 > and 6.5.5 apply to community networks. I don't want anyone arguing that > those sections don't apply to community networks. > > The second part is the restriction on making reallocations. This comes back > to a couple of arguments; (A.) If community networks can make > reallocations, then there is no difference between them and a regular > ISP/LIR, and some participants in earlier discussions were adamant there > needed to be a difference between community networks and regular ISPs/LIRs. > (B.) From the debate on ARIN-2013-3: Tiny IPv6 Allocations for ISPs, some > participants in that discussion were adamant that a /40 was too small of an > allocation for an ISP, especially if that ISP was to make any > reallocations. > > Doesn't the definition already have the required limits on behavior in the >> form of: >> >> "A community network is deployed, operated, and governed by its users, >> for the purpose of providing free or low-cost connectivity to the >> community it services." >> >> It appears what you are preventing are the cases below. I ask is this >> what you >> intend to prevent? and if so why? >> >> Should the Colorado IPv6 cooperative be prevented from providing transit >> to the >> Rocky Mountain Spotted IPv6 community network because they in turn assign >> IPv6 addresses to community members? >> >> >> What if this is all within one community network? What if the Rocky >> Mountain >> Spotted IPv6 community network has a part of the network that is managed by >> a group in Ball Mountain community and another part is managed by a group >> in >> Mount Lincoln. Wouldn't it make sense to re-allocate some of the Rocky >> Mountain >> Spotted IPv6 community network's /40 to Ball Mountain community and let >> them >> handle the assignments to users in their locale? >> > > Personly, I'd be fine with removing the restriction on community networks > making reallocations, but I'd still want to have section 6.5.9.3 I'd > rewrite is as follows; > > *6.5.9.3. Reassignments by Community Networks* > > *Similar to other LIRs, Community Networks shall make reassignments and > reallocations in accordance with applicable policies, in particular, but > not limited to sections 6.5.4 and 6.5.5. * > > What do others think should community networks be allowed to make > both reassignments and reallocations, or just reassignments? > > Thanks. > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =============================================== > From owen at delong.com Wed Jan 17 00:19:24 2018 From: owen at delong.com (Owen DeLong) Date: Tue, 16 Jan 2018 21:19:24 -0800 Subject: [arin-ppml] Draft Policy ARIN-2017-8: Amend Community Networks In-Reply-To: References: Message-ID: > On Jan 16, 2018, at 16:41 , hostmaster at uneedus.com wrote: > > I really never considered until this was brought up that community networks might want to band together to provide backbone connectivity or otherwise associate with each other. I do not think the Community network provisions of policy should forbid this. Agreed. It doesn?t. However, it does not (currently) lend itself to them doing so with a single IPv6 aggregate prefix. Is there a need or desire to do so? > Based on the discussion around 2017-5, it appears that the most important thing for accountability is the registration of blocks routed differently or assigned to others, which in this example are other community networks for specific areas unless the Community Network holding the space manages abuse for the smaller Community Networks below it. Since the end users would have a /48 or less, there is no need to register the end users. under the adopted 2017-5, unless they have requested registration. Really, once they get to the point of providing this level of service, I see no reason (or advantage to them) of not being a regular LIR. > In the example, Rocky Mountain Spotted IPv6 community network might apply for a /40 from ARIN for $250/year. It could do this, or obtain an allocation from Colorado IPv6 cooperative to use. Instead of operating this entire network itself, it might choose to allow other existing smaller groups to operate parts of the network such as the Ball Mountain community and Mount Lincoln. I have no heartburn with these delegations as long as they are SWIP'ed, so we know who is managing each segment of the overall network. Sure, but you?ve now got 4 networks crammed into a /40 meaning that each can be no bigger than a /42 and with rational allocation policy, no bigger than a /44, ignoring the fact that one of the networks is named after a disease. > While some might argue that it is no big deal to become a full LIR and get more space, that space comes at a greater cost which may not be affordable. Many of these groups just manage the network, with the end users providing their own access nodes at their own expense, often using some sort of point to point wireless connectivity. The amount of "cash" for things such as ARIN fees may in fact be quite limited. You?re talking about a cooperative of 4 networks having to pay $500 instead of a single network paying $250 (or $100) per year. Under older fee structures, it was a significant hurdle. Under the current fee structure, it?s a lot less of an issue. > While it is not the "recommended" way to do it, some of these community networks may "find" more space for end users by assigning less than a /48 to most of its end users, assigning that smaller value by default, and only giving a /48 to end users upon a specific request. This allows more users, without more cost for annual fees. Here I have real heartburn. I really want to avoid writing policy that provides any incentive to do this if at all possible. Part of ARIN?s mission is to promote the development of the internet. Encouraging ISPs to give out less than a /48 to end users is contrary to that mission IMHO. > I therefore go along with the proposed rewrite of 6.5.9.3. I do not see a valid reason to prevent community networks from banding together. I don?t think we are preventing any such thing. Owen > > Albert Erdmann > Network Administrator > Paradise On Line Inc. > > > On Tue, 16 Jan 2018, David Farmer wrote: > >> On Tue, Jan 16, 2018 at 11:04 AM, Jason Schiller >> wrote: >> >>> I support the proposal with the exclusion of section 6.5.9.3. >>> I support the proposal with the inclusion of section 6.5.9.3. >>> I ask what is the purpose of section 6.5.9.3? >>> Is section 6.5.9.3 needed? >>> Is section 6.5.9.3 restricting the right thing? >>> >>> Without section 6.5.9.3 the policy clearly defines a community network, >>> and allows what would otherwise be an LIR getting a /32 (or /36 upon >>> request) >>> get instead a /40. >>> >>> This would reduce there fees from X-small $1,000 annunally >>> (or upon request 2X-small $500 annually) >>> to 3X-small $250 annually. >>> >>> Sounds well and good. >>> >>> >>> Section 6.5.9.3 adds a further restriction of there shall be no no >>> re-allocations, >>> suggesting they cannot have a user of their space which in turn has its >>> own users. >>> >>> (for the record I think you can drop the text "to other organizations." >>> and just have "However, they shall not reallocate resources.") >>> >>> >>> What behavior are you intending to prevent? >>> >> >> Section 6.5.9.3 has two parts. >> >> The first part says community networks are like other LIRs, they make >> reassignments to end-users and makes it abundantly clear that section 6.5.4 >> and 6.5.5 apply to community networks. I don't want anyone arguing that >> those sections don't apply to community networks. >> >> The second part is the restriction on making reallocations. This comes back >> to a couple of arguments; (A.) If community networks can make >> reallocations, then there is no difference between them and a regular >> ISP/LIR, and some participants in earlier discussions were adamant there >> needed to be a difference between community networks and regular ISPs/LIRs. >> (B.) From the debate on ARIN-2013-3: Tiny IPv6 Allocations for ISPs, some >> participants in that discussion were adamant that a /40 was too small of an >> allocation for an ISP, especially if that ISP was to make any >> reallocations. >> >> Doesn't the definition already have the required limits on behavior in the >>> form of: >>> >>> "A community network is deployed, operated, and governed by its users, >>> for the purpose of providing free or low-cost connectivity to the >>> community it services." >>> >>> It appears what you are preventing are the cases below. I ask is this >>> what you >>> intend to prevent? and if so why? >>> >>> Should the Colorado IPv6 cooperative be prevented from providing transit >>> to the >>> Rocky Mountain Spotted IPv6 community network because they in turn assign >>> IPv6 addresses to community members? >>> >>> >>> What if this is all within one community network? What if the Rocky >>> Mountain >>> Spotted IPv6 community network has a part of the network that is managed by >>> a group in Ball Mountain community and another part is managed by a group >>> in >>> Mount Lincoln. Wouldn't it make sense to re-allocate some of the Rocky >>> Mountain >>> Spotted IPv6 community network's /40 to Ball Mountain community and let >>> them >>> handle the assignments to users in their locale? >>> >> >> Personly, I'd be fine with removing the restriction on community networks >> making reallocations, but I'd still want to have section 6.5.9.3 I'd >> rewrite is as follows; >> >> *6.5.9.3. Reassignments by Community Networks* >> >> *Similar to other LIRs, Community Networks shall make reassignments and >> reallocations in accordance with applicable policies, in particular, but >> not limited to sections 6.5.4 and 6.5.5. * >> >> What do others think should community networks be allowed to make >> both reassignments and reallocations, or just reassignments? >> >> Thanks. >> >> -- >> =============================================== >> David Farmer Email:farmer at umn.edu >> Networking & Telecommunication Services >> Office of Information Technology >> University of Minnesota >> 2218 University Ave SE Phone: 612-626-0815 >> Minneapolis, MN 55414-3029 Cell: 612-812-9952 >> =============================================== >> > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From hostmaster at uneedus.com Wed Jan 17 09:25:25 2018 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Wed, 17 Jan 2018 09:25:25 -0500 (EST) Subject: [arin-ppml] Draft Policy ARIN-2017-8: Amend Community Networks Message-ID: ---------- Forwarded message ---------- Date: Wed, 17 Jan 2018 07:31:05 As for the disease reference, I assume the networks are not real, and only for the purposes of this discussion. There are good technical reasons for the example networks to share address space, if they are not multihomed and share an upstream. The routing tables and hardware are often simpler for more non technical volunteers to set up and maintain. Often the network upstream points are chosen to be points within the territory where the upstream connections are available, often in/near a nearby town, and may be the location of a home or business of one or more members of the Community network. Every Community network should have the option to use its own backbone, or link up with another community network that can provide access to a backbone and numbering resources, especially if is highly remote. Policy should not put a roadblock in the way of doing this. I would guess such arrangements might happen because the larger community network does not provide access to more remote locations, and another group gets together to link one or more of the served sites of the larger network with the remaining locations which are unserved, effectively extending the reach of the larger network to the more remote points. While the goal of a /48 for each end user site is a good goal, network operators are free to make a different choice if that meets their needs. Do be aware that the larger network may not even be aware of the extension of their network to additional users. Ball Mountain might be a group of people living on the other side of the mountain from Rocky Mountain Spotted IPv6 Community Network who are blocked from direct connection. To get around this problem, they may recruit one of the Rocky Mountain members that are line of sight to both Rocky Mountain, and the Ball Mountain to set up a "backbone" there. At some future date, another community network may become available, or a commercial circuit becomes available at one of the Ball Mountain sites, and they change the routing to match. Since they are effectively sharing the /48 from the original Rocky Mountain user, this group might divide that /48 into individual /56's for each of the Ball Mountain users. A good Community Network Policy should help people, especially in remote areas with many options to obtain Internet access. Chaining connections via more than one such network should not be forbidden by ARIN policy. Albert Erdmann Network Administrator Paradise On Line Inc. On Tue, 16 Jan 2018, Owen DeLong wrote: > >> On Jan 16, 2018, at 16:41 , hostmaster at uneedus.com wrote: >> >> I really never considered until this was brought up that community networks >> might want to band together to provide backbone connectivity or otherwise >> associate with each other. I do not think the Community network provisions >> of policy should forbid this. > > Agreed. It doesn?t. However, it does not (currently) lend itself to them > doing so with a single IPv6 aggregate prefix. Is there a need or desire to do > so? > >> Based on the discussion around 2017-5, it appears that the most important >> thing for accountability is the registration of blocks routed differently or >> assigned to others, which in this example are other community networks for >> specific areas unless the Community Network holding the space manages abuse >> for the smaller Community Networks below it. Since the end users would have >> a /48 or less, there is no need to register the end users. under the adopted >> 2017-5, unless they have requested registration. > > Really, once they get to the point of providing this level of service, I see > no reason (or advantage to them) of not being a regular LIR. > >> In the example, Rocky Mountain Spotted IPv6 community network might apply >> for a /40 from ARIN for $250/year. It could do this, or obtain an allocation >> from Colorado IPv6 cooperative to use. Instead of operating this entire >> network itself, it might choose to allow other existing smaller groups to >> operate parts of the network such as the Ball Mountain community and Mount >> Lincoln. I have no heartburn with these delegations as long as they are >> SWIP'ed, so we know who is managing each segment of the overall network. > > Sure, but you?ve now got 4 networks crammed into a /40 meaning that each > can be no bigger than a /42 and with rational allocation policy, no bigger > than a /44, ignoring the fact that one of the networks is named after a > disease. > >> While some might argue that it is no big deal to become a full LIR and get >> more space, that space comes at a greater cost which may not be affordable. >> Many of these groups just manage the network, with the end users providing >> their own access nodes at their own expense, often using some sort of point >> to point wireless connectivity. The amount of "cash" for things such as >> ARIN fees may in fact be quite limited. > > You?re talking about a cooperative of 4 networks having to pay $500 instead > of a single network paying $250 (or $100) per year. Under older fee > structures, it was a significant hurdle. Under the current fee structure, > it?s a lot less of an issue. > >> While it is not the "recommended" way to do it, some of these community >> networks may "find" more space for end users by assigning less than a /48 to >> most of its end users, assigning that smaller value by default, and only >> giving a /48 to end users upon a specific request. This allows more users, >> without more cost for annual fees. > > Here I have real heartburn. I really want to avoid writing policy that > provides any incentive to do this if at all possible. Part of ARIN?s > mission is to promote the development of the internet. Encouraging ISPs to > give out less than a /48 to end users is contrary to that mission IMHO. > >> I therefore go along with the proposed rewrite of 6.5.9.3. I do not see a >> valid reason to prevent community networks from banding together. > > I don?t think we are preventing any such thing. > > Owen > >> >> Albert Erdmann >> Network Administrator >> Paradise On Line Inc. >> >> >> On Tue, 16 Jan 2018, David Farmer wrote: >> >>> On Tue, Jan 16, 2018 at 11:04 AM, Jason Schiller >>> wrote: >>> >>>> I support the proposal with the exclusion of section 6.5.9.3. >>>> I support the proposal with the inclusion of section 6.5.9.3. >>>> I ask what is the purpose of section 6.5.9.3? >>>> Is section 6.5.9.3 needed? >>>> Is section 6.5.9.3 restricting the right thing? >>>> >>>> Without section 6.5.9.3 the policy clearly defines a community network, >>>> and allows what would otherwise be an LIR getting a /32 (or /36 upon >>>> request) >>>> get instead a /40. >>>> >>>> This would reduce there fees from X-small $1,000 annunally >>>> (or upon request 2X-small $500 annually) >>>> to 3X-small $250 annually. >>>> >>>> Sounds well and good. >>>> >>>> >>>> Section 6.5.9.3 adds a further restriction of there shall be no no >>>> re-allocations, >>>> suggesting they cannot have a user of their space which in turn has its >>>> own users. >>>> >>>> (for the record I think you can drop the text "to other organizations." >>>> and just have "However, they shall not reallocate resources.") >>>> >>>> >>>> What behavior are you intending to prevent? >>>> >>> >>> Section 6.5.9.3 has two parts. >>> >>> The first part says community networks are like other LIRs, they make >>> reassignments to end-users and makes it abundantly clear that section 6.5.4 >>> and 6.5.5 apply to community networks. I don't want anyone arguing that >>> those sections don't apply to community networks. >>> >>> The second part is the restriction on making reallocations. This comes back >>> to a couple of arguments; (A.) If community networks can make >>> reallocations, then there is no difference between them and a regular >>> ISP/LIR, and some participants in earlier discussions were adamant there >>> needed to be a difference between community networks and regular ISPs/LIRs. >>> (B.) From the debate on ARIN-2013-3: Tiny IPv6 Allocations for ISPs, some >>> participants in that discussion were adamant that a /40 was too small of an >>> allocation for an ISP, especially if that ISP was to make any >>> reallocations. >>> >>> Doesn't the definition already have the required limits on behavior in the >>>> form of: >>>> >>>> "A community network is deployed, operated, and governed by its users, >>>> for the purpose of providing free or low-cost connectivity to the >>>> community it services." >>>> >>>> It appears what you are preventing are the cases below. I ask is this >>>> what you >>>> intend to prevent? and if so why? >>>> >>>> Should the Colorado IPv6 cooperative be prevented from providing transit >>>> to the >>>> Rocky Mountain Spotted IPv6 community network because they in turn assign >>>> IPv6 addresses to community members? >>>> >>>> >>>> What if this is all within one community network? What if the Rocky >>>> Mountain >>>> Spotted IPv6 community network has a part of the network that is managed >>>> by >>>> a group in Ball Mountain community and another part is managed by a group >>>> in >>>> Mount Lincoln. Wouldn't it make sense to re-allocate some of the Rocky >>>> Mountain >>>> Spotted IPv6 community network's /40 to Ball Mountain community and let >>>> them >>>> handle the assignments to users in their locale? >>>> >>> >>> Personly, I'd be fine with removing the restriction on community networks >>> making reallocations, but I'd still want to have section 6.5.9.3 I'd >>> rewrite is as follows; >>> >>> *6.5.9.3. Reassignments by Community Networks* >>> >>> *Similar to other LIRs, Community Networks shall make reassignments and >>> reallocations in accordance with applicable policies, in particular, but >>> not limited to sections 6.5.4 and 6.5.5. * >>> >>> What do others think should community networks be allowed to make >>> both reassignments and reallocations, or just reassignments? >>> >>> Thanks. >>> >>> -- >>> =============================================== >>> David Farmer Email:farmer at umn.edu >>> Networking & Telecommunication Services >>> Office of Information Technology >>> University of Minnesota >>> 2218 University Ave SE Phone: 612-626-0815 >>> Minneapolis, MN 55414-3029 Cell: 612-812-9952 >>> =============================================== >>> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > From jschiller at google.com Wed Jan 17 14:51:11 2018 From: jschiller at google.com (Jason Schiller) Date: Wed, 17 Jan 2018 14:51:11 -0500 Subject: [arin-ppml] Draft Policy ARIN-2017-8: Amend Community Networks In-Reply-To: <1A0E5953-E77D-4A0F-A580-0B6B877EB1AF@delong.com> References: <1A0E5953-E77D-4A0F-A580-0B6B877EB1AF@delong.com> Message-ID: Owen makes a good point here. a /40 is quite small, and doesn't leave much room for subnetting. We should not encourage the practice of giving out less than a /48 per "site" or less than a /64 per user. 1 administration domain with 256 locations 2 administration domains with 128 locations each 4 administration domains with 64 locations each 8 administration domains with 32 locations each 16 administration domains with 16 locations each You would have to correctly guess at the number of administration domains, and how many location each might have. And it leaves a lot of IPv6 space on the table when the allocation size is quite small. It is a reasonable trade-off that if you want to link up community networks to a central network you ether need each community network to fork over $250 for their own /40 (two networks = $500) or get a /36 at $500 and split the cost. A /36 split two ways it is a wash. A /32 at $1,000, split 4 ways is a wash. I am comfortable with that approach, if we can document it somewhere. I'd recommend the comments for this policy (in case anyone looks back) and in some ARIN FAQ once this policy is adopted. Lets not confuse the community networks in to thinking that can't just be an ISP and get ISP space and ISP pricing. __Jason On Tue, Jan 16, 2018 at 4:09 PM, Owen DeLong wrote: > David summarized my views on the matter rather well. I am adamantly > opposed to trying to make reallocations out of /40 (or longer) prefixes. > > Really, a /40 is 256 /48s. Any rational reallocation would be at least a > /44. Is anyone really in need of running an ISP with only 16 /48s? > > I?d rather see any such ISP that is subordinate to a community network (if > such a construct exists) get their space directly from ARIN under this same > policy than see us daisy chaining community networks through > micro-allocations in IPv6. > > I?m operating under the assumption that any ISP that has a subordinate ISP > that isn?t a community network isn?t really a community network, though I > suppose it might be possible under the proposed rules to engineer such a > thing if one tried hard enough. Nonetheless, I would argue that such a > construct is a clear violation of the spirit of the policy even if you > found a way to do it within the proverbial letter of the law. > > Owen > > On Jan 16, 2018, at 12:57 , David Farmer wrote: > > On Tue, Jan 16, 2018 at 11:04 AM, Jason Schiller > wrote: > >> I support the proposal with the exclusion of section 6.5.9.3. >> I support the proposal with the inclusion of section 6.5.9.3. >> I ask what is the purpose of section 6.5.9.3? >> Is section 6.5.9.3 needed? >> Is section 6.5.9.3 restricting the right thing? >> >> Without section 6.5.9.3 the policy clearly defines a community network, >> and allows what would otherwise be an LIR getting a /32 (or /36 upon >> request) >> get instead a /40. >> >> This would reduce there fees from X-small $1,000 annunally >> (or upon request 2X-small $500 annually) >> to 3X-small $250 annually. >> >> Sounds well and good. >> >> >> Section 6.5.9.3 adds a further restriction of there shall be no no >> re-allocations, >> suggesting they cannot have a user of their space which in turn has its >> own users. >> >> (for the record I think you can drop the text "to other organizations." >> and just have "However, they shall not reallocate resources.") >> >> >> What behavior are you intending to prevent? >> > > Section 6.5.9.3 has two parts. > > The first part says community networks are like other LIRs, they make > reassignments to end-users and makes it abundantly clear that section 6.5.4 > and 6.5.5 apply to community networks. I don't want anyone arguing that > those sections don't apply to community networks. > > The second part is the restriction on making reallocations. This comes > back to a couple of arguments; (A.) If community networks can make > reallocations, then there is no difference between them and a regular > ISP/LIR, and some participants in earlier discussions were adamant there > needed to be a difference between community networks and regular ISPs/LIRs. > (B.) From the debate on ARIN-2013-3: Tiny IPv6 Allocations for ISPs, some > participants in that discussion were adamant that a /40 was too small of an > allocation for an ISP, especially if that ISP was to make any > reallocations. > > Doesn't the definition already have the required limits on behavior in the >> form of: >> >> "A community network is deployed, operated, and governed by its users, >> for the purpose of providing free or low-cost connectivity to the >> community it services." >> >> It appears what you are preventing are the cases below. I ask is this >> what you >> intend to prevent? and if so why? >> >> Should the Colorado IPv6 cooperative be prevented from providing transit >> to the >> Rocky Mountain Spotted IPv6 community network because they in turn assign >> IPv6 addresses to community members? >> >> >> What if this is all within one community network? What if the Rocky >> Mountain >> Spotted IPv6 community network has a part of the network that is managed >> by >> a group in Ball Mountain community and another part is managed by a group >> in >> Mount Lincoln. Wouldn't it make sense to re-allocate some of the Rocky >> Mountain >> Spotted IPv6 community network's /40 to Ball Mountain community and let >> them >> handle the assignments to users in their locale? >> > > Personly, I'd be fine with removing the restriction on community networks > making reallocations, but I'd still want to have section 6.5.9.3 I'd > rewrite is as follows; > > *6.5.9.3. Reassignments by Community Networks* > > *Similar to other LIRs, Community Networks shall make reassignments and > reallocations in accordance with applicable policies, in particular, but > not limited to sections 6.5.4 and 6.5.5. * > > What do others think should community networks be allowed to make > both reassignments and reallocations, or just reassignments? > > Thanks. > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE > > Phone: 612-626-0815 <(612)%20626-0815> > Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> > =============================================== > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > > -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmer at umn.edu Thu Jan 18 14:21:23 2018 From: farmer at umn.edu (David Farmer) Date: Thu, 18 Jan 2018 13:21:23 -0600 Subject: [arin-ppml] Draft Policy ARIN-2017-8: Amend Community Networks In-Reply-To: References: Message-ID: Based on additional feedback on PPML and in private exchanges, I have made several changes, included adding a rationale for restricting reallocations in the comments section. Additional feedback is appreciated. I'm especially interested if you think reallocations should be allowed or not, including why or why not. Thanks. ----- Problem Statement: The Community Networks section of the NRPM has only been used once since implementation in January 2010. Proposal ARIN-2016-7, to increase the number of use cases, was abandoned by the Advisory Council due to lack of feedback. Proposal ARIN 2017-2, to remove all mention of community networks from NRPM met with opposition by the community. Many responded that the definition of "community network" was too narrow, which could be the reason for lack of uptake. In the discussion at ARIN 40, it was clear that more than just the definition of a community network needed revision and that community networks need to have allocations, not assignments. Additionally, community networks need to make reassignments to end-users in accordance with applicable policies. Policy statement: Replace section 2.11 with the following; 2.11 Community Network *A community network is deployed, operated, and governed by its users, for the purpose of providing free or low-cost connectivity to the community it services. Users of the network or other volunteers must play a primary role in the governance of the organization, whereas other functions may be handled by either paid staff or volunteers.* Rename section 6.5.9 and revise as follows; 6.5.9. Community Network *Allocations* While community networks would normally be considered to be ISP type organizations under existing ARIN criteria, they tend to operate on much tighter budgets and often depend on volunteer labor. As a result, they tend to be much smaller and more communal in their organization rather than provider/customer relationships of commercial ISPs. This section seeks to provide *a* policy that is more friendly to those environments by allowing *community network to receive a smaller allocation than other LIRs or commercial ISPs.* *Community networks may also qualify under section 6.5.2 as a regular LIR.* Section 6.5.9.1 is not changing, but is included here for completeness; 6.5.9.1. Qualification Criteria To qualify under this section, a community network must demonstrate to ARIN's satisfaction that it meets the definition of a community network under section 2.11 of the NRPM. Replace section 6.5.9.2 and 6.5.9.3 with the following; *6.5.9.2. Allocation SizeCommunity networks are eligible only to receive an allocation of /40 of IPv6 resources under this section. Community networks that wish to receive a larger initial allocation or any subsequent allocations must qualify as a regular LIR, see sections 6.5.2 or 6.5.3 respectively. 6.5.9.3. Reassignments by Community NetworksSimilar to other LIRs, community networks shall make reassignments to end-users in accordance with applicable policies, in particular, but not limited to sections 6.5.4 and 6.5.5. However, they shall not reallocate resources under this section.* Comments: Timetable for implementation: Immediate The rationale for restricting community networks that receive resources through this policy from making reallocations is that a /40 is a tiny IPv6 allocation and it does not seem reasonable to subdivide such a small allocation into even smaller reallocations. Also, the recommended size for reassignment is /48, to even the smallest end-users, and therefore a /40 only provides 256 such reassignments. If a community network needs to make reallocations, maybe to other cooperating community networks in their area, they should apply as, or become, a regular LIR. As the smallest regular LIR, they would get a /36, allowing more than sufficient room to subdivide the allocation into several reasonable sized reallocations as necessary. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmer at umn.edu Thu Jan 18 17:21:15 2018 From: farmer at umn.edu (David Farmer) Date: Thu, 18 Jan 2018 16:21:15 -0600 Subject: [arin-ppml] Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers Message-ID: David, The resolution you suggest below seems like a different policy proposal to me, one with a significantly broader scope than this draft policy has. But I think it is a valid question for the community to consider, it's just not really the problem statement in question for this Draft Policy. So, back within the scope of this Draft Policy as the shepherd, I plan to push forward Andrew's updated Problem Statement with a Policy Statement that harmonizes and simplifies the text in section 4.2.2 as an official update to this Draft Policy to get the conversation moving again. The current text of 4.2.2 is; 4.2.2. Initial allocation to ISPs All ISP organizations without direct assignments or allocations from ARIN qualify for an initial allocation of up to a /21, subject to ARIN's minimum allocation size. Organizations may qualify for a larger initial allocation by documenting how the requested allocation will be utilized within 24 months. ISPs renumbering out of their previous address space will be given a reasonable amount of time to do so, and any blocks they are returning will not count against their utilization. The text "subject to ARIN's minimum allocation size" seems extraneous. And, post runout renumbering and returning any address space seems unlikely, so let's just eliminate that whole sentence. I propose we simplify that to the following; 4.2.2. Initial allocation to ISPs All ISP organizations without direct assignments or allocations from ARIN qualify for an initial allocation of up to a /24. Organizations may qualify for a larger initial allocation by documenting how the requested allocation will be utilized within 24 months. Below is the policy update that results; Thanks -------- Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers Problem Statement: It was noted in 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 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. Policy Statement: Change section 4.2.2 as follows; 4.2.2. Initial allocation to ISPs All ISP organizations without direct assignments or allocations from ARIN qualify for an initial allocation of up to a /24. Organizations may qualify for a larger initial allocation by documenting how the requested allocation will be utilized within 24 months. Comments: Timetable for implementation: Immediate On Thu, Dec 7, 2017 at 11:37 PM, David Huberman wrote: > 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. > > -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Thu Jan 18 17:26:06 2018 From: owen at delong.com (Owen DeLong) Date: Thu, 18 Jan 2018 14:26:06 -0800 Subject: [arin-ppml] Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers In-Reply-To: References: Message-ID: I see no reason to move the boundary for an ISP initial allocation from /21 to /24. I certainly see no reason for ?up to a /24? as there?s nothing smaller available and even if it were, it wouldn?t be useful in any foreseeable environment. Owen > On Jan 18, 2018, at 2:21 PM, David Farmer wrote: > > David, > > The resolution you suggest below seems like a different policy proposal to me, one with a significantly broader scope than this draft policy has. But I think it is a valid question for the community to consider, it's just not really the problem statement in question for this Draft Policy. > > So, back within the scope of this Draft Policy as the shepherd, I plan to push forward Andrew's updated Problem Statement with a Policy Statement that harmonizes and simplifies the text in section 4.2.2 as an official update to this Draft Policy to get the conversation moving again. > > The current text of 4.2.2 is; > > 4.2.2. Initial allocation to ISPs > > All ISP organizations without direct assignments or allocations from ARIN qualify for an initial allocation of up to a /21, subject to ARIN's minimum allocation size. Organizations may qualify for a larger initial allocation by documenting how the requested allocation will be utilized within 24 months. ISPs renumbering out of their previous address space will be given a reasonable amount of time to do so, and any blocks they are returning will not count against their utilization. > > The text "subject to ARIN's minimum allocation size" seems extraneous. And, post runout renumbering and returning any address space seems unlikely, so let's just eliminate that whole sentence. > > I propose we simplify that to the following; > > 4.2.2. Initial allocation to ISPs > > All ISP organizations without direct assignments or allocations from ARIN qualify for an initial allocation of up to a /24. Organizations may qualify for a larger initial allocation by documenting how the requested allocation will be utilized within 24 months. > > Below is the policy update that results; > > Thanks > > -------- > > Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers > > Problem Statement: > > It was noted in 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 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. > > Policy Statement: > > Change section 4.2.2 as follows; > > 4.2.2. Initial allocation to ISPs > > All ISP organizations without direct assignments or allocations from ARIN qualify for an initial allocation of up to a /24. Organizations may qualify for a larger initial allocation by documenting how the requested allocation will be utilized within 24 months. > > Comments: > > Timetable for implementation: Immediate > > > On Thu, Dec 7, 2017 at 11:37 PM, David Huberman > wrote: > 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. >> > > > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =============================================== > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmer at umn.edu Thu Jan 18 17:37:07 2018 From: farmer at umn.edu (David Farmer) Date: Thu, 18 Jan 2018 16:37:07 -0600 Subject: [arin-ppml] Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers In-Reply-To: References: Message-ID: Owen, Yep, that was an editing error, it should have been; 4.2.2. Initial allocation to ISPs All ISP organizations without direct assignments or allocations from ARIN qualify for an initial allocation of a /24. Organizations may qualify for a larger initial allocation by documenting how the requested allocation will be utilized within 24 months. On Thu, Jan 18, 2018 at 4:26 PM, Owen DeLong wrote: > I see no reason to move the boundary for an ISP initial allocation from > /21 to /24. > Well that seems to be staff intrupretation if you are getting an initial allocation via a transfer, how would you reslove this then? Thanks. > I certainly see no reason for ?up to a /24? as there?s nothing smaller > available and even if it were, it wouldn?t be useful in any foreseeable > environment. > > Owen > > On Jan 18, 2018, at 2:21 PM, David Farmer wrote: > > David, > > The resolution you suggest below seems like a different policy proposal to > me, one with a significantly broader scope than this draft policy has. But > I think it is a valid question for the community to consider, it's just not > really the problem statement in question for this Draft Policy. > > So, back within the scope of this Draft Policy as the shepherd, I plan to > push forward Andrew's updated Problem Statement with a Policy Statement > that harmonizes and simplifies the text in section 4.2.2 as an official > update to this Draft Policy to get the conversation moving again. > > The current text of 4.2.2 is; > > 4.2.2. Initial allocation to ISPs > > All ISP organizations without direct assignments or allocations from ARIN > qualify for an initial allocation of up to a /21, subject to ARIN's minimum > allocation size. Organizations may qualify for a larger initial allocation > by documenting how the requested allocation will be utilized within 24 > months. ISPs renumbering out of their previous address space will be given > a reasonable amount of time to do so, and any blocks they are returning > will not count against their utilization. > > The text "subject to ARIN's minimum allocation size" seems extraneous. > And, post runout renumbering and returning any address space > seems unlikely, so let's just eliminate that whole sentence. > > I propose we simplify that to the following; > > 4.2.2. Initial allocation to ISPs > > All ISP organizations without direct assignments or allocations from ARIN > qualify for an initial allocation of up to a /24. Organizations may qualify > for a larger initial allocation by documenting how the requested allocation > will be utilized within 24 months. > > Below is the policy update that results; > > Thanks > > -------- > > Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP > Transfers > > Problem Statement: > > It was noted in 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 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. > > Policy Statement: > > Change section 4.2.2 as follows; > > 4.2.2. Initial allocation to ISPs > > All ISP organizations without direct assignments or allocations from ARIN > qualify for an initial allocation of up to a /24. Organizations may qualify > for a larger initial allocation by documenting how the requested allocation > will be utilized within 24 months. > > Comments: > > Timetable for implementation: Immediate > > > On Thu, Dec 7, 2017 at 11:37 PM, David Huberman wrote: > >> 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. >> >> > > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE > > Phone: 612-626-0815 <(612)%20626-0815> > Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> > =============================================== > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > > -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Thu Jan 18 17:38:42 2018 From: owen at delong.com (Owen DeLong) Date: Thu, 18 Jan 2018 14:38:42 -0800 Subject: [arin-ppml] Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers In-Reply-To: References: Message-ID: <37CC78F2-D908-44A6-A75F-22B84CAD9E76@delong.com> The existing language ?up to a /21? is consistent with staff allowing you to obtain a /24 via transfer. Are you telling me that staff is refusing /21 transfers, but allowing /24 transfers to new ISPs without further justification? If so, I would argue that current staff practice is in error vs. policy language. Owen > On Jan 18, 2018, at 2:37 PM, David Farmer wrote: > > Owen, > > Yep, that was an editing error, it should have been; > > 4.2.2. Initial allocation to ISPs > > All ISP organizations without direct assignments or allocations from ARIN qualify for an initial allocation of a /24. Organizations may qualify for a larger initial allocation by documenting how the requested allocation will be utilized within 24 months. > > On Thu, Jan 18, 2018 at 4:26 PM, Owen DeLong > wrote: > I see no reason to move the boundary for an ISP initial allocation from /21 to /24. > > Well that seems to be staff intrupretation if you are getting an initial allocation via a transfer, how would you reslove this then? > > Thanks. > > I certainly see no reason for ?up to a /24? as there?s nothing smaller available and even if it were, it wouldn?t be useful in any foreseeable environment. > > Owen > >> On Jan 18, 2018, at 2:21 PM, David Farmer > wrote: >> >> David, >> >> The resolution you suggest below seems like a different policy proposal to me, one with a significantly broader scope than this draft policy has. But I think it is a valid question for the community to consider, it's just not really the problem statement in question for this Draft Policy. >> >> So, back within the scope of this Draft Policy as the shepherd, I plan to push forward Andrew's updated Problem Statement with a Policy Statement that harmonizes and simplifies the text in section 4.2.2 as an official update to this Draft Policy to get the conversation moving again. >> >> The current text of 4.2.2 is; >> >> 4.2.2. Initial allocation to ISPs >> >> All ISP organizations without direct assignments or allocations from ARIN qualify for an initial allocation of up to a /21, subject to ARIN's minimum allocation size. Organizations may qualify for a larger initial allocation by documenting how the requested allocation will be utilized within 24 months. ISPs renumbering out of their previous address space will be given a reasonable amount of time to do so, and any blocks they are returning will not count against their utilization. >> >> The text "subject to ARIN's minimum allocation size" seems extraneous. And, post runout renumbering and returning any address space seems unlikely, so let's just eliminate that whole sentence. >> >> I propose we simplify that to the following; >> >> 4.2.2. Initial allocation to ISPs >> >> All ISP organizations without direct assignments or allocations from ARIN qualify for an initial allocation of up to a /24. Organizations may qualify for a larger initial allocation by documenting how the requested allocation will be utilized within 24 months. >> >> Below is the policy update that results; >> >> Thanks >> >> -------- >> >> Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers >> >> Problem Statement: >> >> It was noted in 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 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. >> >> Policy Statement: >> >> Change section 4.2.2 as follows; >> >> 4.2.2. Initial allocation to ISPs >> >> All ISP organizations without direct assignments or allocations from ARIN qualify for an initial allocation of up to a /24. Organizations may qualify for a larger initial allocation by documenting how the requested allocation will be utilized within 24 months. >> >> Comments: >> >> Timetable for implementation: Immediate >> >> >> On Thu, Dec 7, 2017 at 11:37 PM, David Huberman > wrote: >> 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. >>> >> >> >> >> -- >> =============================================== >> David Farmer Email:farmer at umn.edu >> Networking & Telecommunication Services >> Office of Information Technology >> University of Minnesota >> 2218 University Ave SE Phone: 612-626-0815 >> Minneapolis, MN 55414-3029 Cell: 612-812-9952 >> =============================================== >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > > > > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmer at umn.edu Thu Jan 18 18:03:15 2018 From: farmer at umn.edu (David Farmer) Date: Thu, 18 Jan 2018 17:03:15 -0600 Subject: [arin-ppml] Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers In-Reply-To: <37CC78F2-D908-44A6-A75F-22B84CAD9E76@delong.com> References: <37CC78F2-D908-44A6-A75F-22B84CAD9E76@delong.com> Message-ID: >From the updated problem statement: 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. Again, whether a change in policy or staff practice, what do we want to happen? On Thu, Jan 18, 2018 at 4:38 PM, Owen DeLong wrote: > The existing language ?up to a /21? is consistent with staff allowing you > to obtain a /24 via transfer. > > Are you telling me that staff is refusing /21 transfers, but allowing /24 > transfers to new ISPs without further justification? If so, I would argue > that current staff practice is in error vs. policy language. > > Owen > > On Jan 18, 2018, at 2:37 PM, David Farmer wrote: > > Owen, > > Yep, that was an editing error, it should have been; > > 4.2.2. Initial allocation to ISPs > > All ISP organizations without direct assignments or allocations from ARIN > qualify for an initial allocation of a /24. Organizations may qualify for a > larger initial allocation by documenting how the requested allocation will > be utilized within 24 months. > > On Thu, Jan 18, 2018 at 4:26 PM, Owen DeLong wrote: > >> I see no reason to move the boundary for an ISP initial allocation from >> /21 to /24. >> > > Well that seems to be staff intrupretation if you are getting an initial > allocation via a transfer, how would you reslove this then? > > Thanks. > > >> I certainly see no reason for ?up to a /24? as there?s nothing smaller >> available and even if it were, it wouldn?t be useful in any foreseeable >> environment. >> >> Owen >> >> On Jan 18, 2018, at 2:21 PM, David Farmer wrote: >> >> David, >> >> The resolution you suggest below seems like a different policy proposal >> to me, one with a significantly broader scope than this draft policy has. >> But I think it is a valid question for the community to consider, it's just >> not really the problem statement in question for this Draft Policy. >> >> So, back within the scope of this Draft Policy as the shepherd, I plan to >> push forward Andrew's updated Problem Statement with a Policy Statement >> that harmonizes and simplifies the text in section 4.2.2 as an official >> update to this Draft Policy to get the conversation moving again. >> >> The current text of 4.2.2 is; >> >> 4.2.2. Initial allocation to ISPs >> >> All ISP organizations without direct assignments or allocations from ARIN >> qualify for an initial allocation of up to a /21, subject to ARIN's minimum >> allocation size. Organizations may qualify for a larger initial allocation >> by documenting how the requested allocation will be utilized within 24 >> months. ISPs renumbering out of their previous address space will be given >> a reasonable amount of time to do so, and any blocks they are returning >> will not count against their utilization. >> >> The text "subject to ARIN's minimum allocation size" seems extraneous. >> And, post runout renumbering and returning any address space >> seems unlikely, so let's just eliminate that whole sentence. >> >> I propose we simplify that to the following; >> >> 4.2.2. Initial allocation to ISPs >> >> All ISP organizations without direct assignments or allocations from ARIN >> qualify for an initial allocation of up to a /24. Organizations may qualify >> for a larger initial allocation by documenting how the requested allocation >> will be utilized within 24 months. >> >> Below is the policy update that results; >> >> Thanks >> >> -------- >> >> Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 >> ISP Transfers >> >> Problem Statement: >> >> It was noted in 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 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. >> >> Policy Statement: >> >> Change section 4.2.2 as follows; >> >> 4.2.2. Initial allocation to ISPs >> >> All ISP organizations without direct assignments or allocations from ARIN >> qualify for an initial allocation of up to a /24. Organizations may qualify >> for a larger initial allocation by documenting how the requested allocation >> will be utilized within 24 months. >> >> Comments: >> >> Timetable for implementation: Immediate >> >> >> On Thu, Dec 7, 2017 at 11:37 PM, David Huberman wrote: >> >>> 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. >>> >>> >> >> >> -- >> =============================================== >> David Farmer Email:farmer at umn.edu >> Networking & Telecommunication Services >> Office of Information Technology >> University of Minnesota >> 2218 University Ave SE >> >> Phone: 612-626-0815 <(612)%20626-0815> >> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> >> =============================================== >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> >> >> > > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE > > Phone: 612-626-0815 <(612)%20626-0815> > Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> > =============================================== > > > -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Thu Jan 18 18:17:28 2018 From: owen at delong.com (Owen DeLong) Date: Thu, 18 Jan 2018 15:17:28 -0800 Subject: [arin-ppml] Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers In-Reply-To: References: <37CC78F2-D908-44A6-A75F-22B84CAD9E76@delong.com> Message-ID: Well, section 4 doesn?t govern transfers since we decoupled it anyway, so I?m not sure if we want to make staff behavior consistent or not. I would argue that moving the transfer boundary to /21 would make more sense than moving the section 4 boundary to /24, if we are going to synchronize them. However, as you point out, transfers are governed by 8.5.5 and only free pool is governed by section 4 unless section 4 is referenced by section 8. As you may recall, I opposed this decoupling because of the confusion and disparity in protocol I expected to result. Now we?re exactly where I predicted we?d be. Owen > On Jan 18, 2018, at 3:03 PM, David Farmer wrote: > > From the updated problem statement: 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. > > Again, whether a change in policy or staff practice, what do we want to happen? > > On Thu, Jan 18, 2018 at 4:38 PM, Owen DeLong > wrote: > The existing language ?up to a /21? is consistent with staff allowing you to obtain a /24 via transfer. > > Are you telling me that staff is refusing /21 transfers, but allowing /24 transfers to new ISPs without further justification? If so, I would argue that current staff practice is in error vs. policy language. > > Owen > >> On Jan 18, 2018, at 2:37 PM, David Farmer > wrote: >> >> Owen, >> >> Yep, that was an editing error, it should have been; >> >> 4.2.2. Initial allocation to ISPs >> >> All ISP organizations without direct assignments or allocations from ARIN qualify for an initial allocation of a /24. Organizations may qualify for a larger initial allocation by documenting how the requested allocation will be utilized within 24 months. >> >> On Thu, Jan 18, 2018 at 4:26 PM, Owen DeLong > wrote: >> I see no reason to move the boundary for an ISP initial allocation from /21 to /24. >> >> Well that seems to be staff intrupretation if you are getting an initial allocation via a transfer, how would you reslove this then? >> >> Thanks. >> >> I certainly see no reason for ?up to a /24? as there?s nothing smaller available and even if it were, it wouldn?t be useful in any foreseeable environment. >> >> Owen >> >>> On Jan 18, 2018, at 2:21 PM, David Farmer > wrote: >>> >>> David, >>> >>> The resolution you suggest below seems like a different policy proposal to me, one with a significantly broader scope than this draft policy has. But I think it is a valid question for the community to consider, it's just not really the problem statement in question for this Draft Policy. >>> >>> So, back within the scope of this Draft Policy as the shepherd, I plan to push forward Andrew's updated Problem Statement with a Policy Statement that harmonizes and simplifies the text in section 4.2.2 as an official update to this Draft Policy to get the conversation moving again. >>> >>> The current text of 4.2.2 is; >>> >>> 4.2.2. Initial allocation to ISPs >>> >>> All ISP organizations without direct assignments or allocations from ARIN qualify for an initial allocation of up to a /21, subject to ARIN's minimum allocation size. Organizations may qualify for a larger initial allocation by documenting how the requested allocation will be utilized within 24 months. ISPs renumbering out of their previous address space will be given a reasonable amount of time to do so, and any blocks they are returning will not count against their utilization. >>> >>> The text "subject to ARIN's minimum allocation size" seems extraneous. And, post runout renumbering and returning any address space seems unlikely, so let's just eliminate that whole sentence. >>> >>> I propose we simplify that to the following; >>> >>> 4.2.2. Initial allocation to ISPs >>> >>> All ISP organizations without direct assignments or allocations from ARIN qualify for an initial allocation of up to a /24. Organizations may qualify for a larger initial allocation by documenting how the requested allocation will be utilized within 24 months. >>> >>> Below is the policy update that results; >>> >>> Thanks >>> >>> -------- >>> >>> Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers >>> >>> Problem Statement: >>> >>> It was noted in 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 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. >>> >>> Policy Statement: >>> >>> Change section 4.2.2 as follows; >>> >>> 4.2.2. Initial allocation to ISPs >>> >>> All ISP organizations without direct assignments or allocations from ARIN qualify for an initial allocation of up to a /24. Organizations may qualify for a larger initial allocation by documenting how the requested allocation will be utilized within 24 months. >>> >>> Comments: >>> >>> Timetable for implementation: Immediate >>> >>> >>> On Thu, Dec 7, 2017 at 11:37 PM, David Huberman > wrote: >>> 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. >>>> >>> >>> >>> >>> -- >>> =============================================== >>> David Farmer Email:farmer at umn.edu >>> Networking & Telecommunication Services >>> Office of Information Technology >>> University of Minnesota >>> 2218 University Ave SE Phone: 612-626-0815 >>> Minneapolis, MN 55414-3029 Cell: 612-812-9952 >>> =============================================== >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to >>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at arin.net if you experience any issues. >> >> >> >> >> -- >> =============================================== >> David Farmer Email:farmer at umn.edu >> Networking & Telecommunication Services >> Office of Information Technology >> University of Minnesota >> 2218 University Ave SE Phone: 612-626-0815 >> Minneapolis, MN 55414-3029 Cell: 612-812-9952 >> =============================================== > > > > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at semihuman.com Thu Jan 18 18:26:05 2018 From: chris at semihuman.com (Chris Woodfield) Date: Thu, 18 Jan 2018 15:26:05 -0800 Subject: [arin-ppml] Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers In-Reply-To: <37CBFACF-23E2-4F69-9519-1E022900CA2F@panix.com> 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> <37CBFACF-23E2-4F69-9519-1E022900CA2F@panix.com> Message-ID: Hi David, Section 4 requests are still relevant for the waiting list and critical infrastructure, but little else. That said, there have been efforts in the past to obliterate Section 4 wholesale and replace it with a much more concise text, but those never had much support. I?d be happy to try again in the name of simplification, but that would be an entirely separate proposal. -C > On Dec 7, 2017, at 9:37 PM, David Huberman wrote: > > 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. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmer at umn.edu Thu Jan 18 18:35:28 2018 From: farmer at umn.edu (David Farmer) Date: Thu, 18 Jan 2018 17:35:28 -0600 Subject: [arin-ppml] Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers In-Reply-To: References: <37CC78F2-D908-44A6-A75F-22B84CAD9E76@delong.com> Message-ID: Owen, I think you are justified in taking an "I told you so!" But, here are the two options as I see them to harmonize things; 1. Change 4.2.2 to /24 2. Change 8.5.3 to /21 I think Owen is saying #2, and the best I could glean from the previous comments most we leaning toward #1. So, which way do people think we should go, #1 or #2? Thanks. On Thu, Jan 18, 2018 at 5:17 PM, Owen DeLong wrote: > Well, section 4 doesn?t govern transfers since we decoupled it anyway, so > I?m not sure if we want to make staff behavior consistent or not. I would > argue that moving the transfer boundary to /21 would make more sense than > moving the section 4 boundary to /24, if we are going to synchronize them. > > However, as you point out, transfers are governed by 8.5.5 and only free > pool is governed by section 4 unless section 4 is referenced by section 8. > > As you may recall, I opposed this decoupling because of the confusion and > disparity in protocol I expected to result. Now we?re exactly where I > predicted we?d be. > > Owen > > On Jan 18, 2018, at 3:03 PM, David Farmer wrote: > > From the updated problem statement: 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. > > Again, whether a change in policy or staff practice, what do we want to > happen? > > On Thu, Jan 18, 2018 at 4:38 PM, Owen DeLong wrote: > >> The existing language ?up to a /21? is consistent with staff allowing you >> to obtain a /24 via transfer. >> >> Are you telling me that staff is refusing /21 transfers, but allowing /24 >> transfers to new ISPs without further justification? If so, I would argue >> that current staff practice is in error vs. policy language. >> >> Owen >> >> On Jan 18, 2018, at 2:37 PM, David Farmer wrote: >> >> Owen, >> >> Yep, that was an editing error, it should have been; >> >> 4.2.2. Initial allocation to ISPs >> >> All ISP organizations without direct assignments or allocations from ARIN >> qualify for an initial allocation of a /24. Organizations may qualify for a >> larger initial allocation by documenting how the requested allocation will >> be utilized within 24 months. >> >> On Thu, Jan 18, 2018 at 4:26 PM, Owen DeLong wrote: >> >>> I see no reason to move the boundary for an ISP initial allocation from >>> /21 to /24. >>> >> >> Well that seems to be staff intrupretation if you are getting an initial >> allocation via a transfer, how would you reslove this then? >> >> Thanks. >> >> >>> I certainly see no reason for ?up to a /24? as there?s nothing smaller >>> available and even if it were, it wouldn?t be useful in any foreseeable >>> environment. >>> >>> Owen >>> >>> On Jan 18, 2018, at 2:21 PM, David Farmer wrote: >>> >>> David, >>> >>> The resolution you suggest below seems like a different policy proposal >>> to me, one with a significantly broader scope than this draft policy has. >>> But I think it is a valid question for the community to consider, it's just >>> not really the problem statement in question for this Draft Policy. >>> >>> So, back within the scope of this Draft Policy as the shepherd, I plan >>> to push forward Andrew's updated Problem Statement with a Policy Statement >>> that harmonizes and simplifies the text in section 4.2.2 as an official >>> update to this Draft Policy to get the conversation moving again. >>> >>> The current text of 4.2.2 is; >>> >>> 4.2.2. Initial allocation to ISPs >>> >>> All ISP organizations without direct assignments or allocations from >>> ARIN qualify for an initial allocation of up to a /21, subject to ARIN's >>> minimum allocation size. Organizations may qualify for a larger initial >>> allocation by documenting how the requested allocation will be utilized >>> within 24 months. ISPs renumbering out of their previous address space will >>> be given a reasonable amount of time to do so, and any blocks they are >>> returning will not count against their utilization. >>> >>> The text "subject to ARIN's minimum allocation size" seems extraneous. >>> And, post runout renumbering and returning any address space >>> seems unlikely, so let's just eliminate that whole sentence. >>> >>> I propose we simplify that to the following; >>> >>> 4.2.2. Initial allocation to ISPs >>> >>> All ISP organizations without direct assignments or allocations from >>> ARIN qualify for an initial allocation of up to a /24. Organizations may >>> qualify for a larger initial allocation by documenting how the requested >>> allocation will be utilized within 24 months. >>> >>> Below is the policy update that results; >>> >>> Thanks >>> >>> -------- >>> >>> Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 >>> ISP Transfers >>> >>> Problem Statement: >>> >>> It was noted in 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 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. >>> >>> Policy Statement: >>> >>> Change section 4.2.2 as follows; >>> >>> 4.2.2. Initial allocation to ISPs >>> >>> All ISP organizations without direct assignments or allocations from >>> ARIN qualify for an initial allocation of up to a /24. Organizations may >>> qualify for a larger initial allocation by documenting how the requested >>> allocation will be utilized within 24 months. >>> >>> Comments: >>> >>> Timetable for implementation: Immediate >>> >>> >>> On Thu, Dec 7, 2017 at 11:37 PM, David Huberman wr >>> ote: >>> >>>> 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. >>>> >>>> >>> >>> >>> -- >>> =============================================== >>> David Farmer Email:farmer at umn.edu >>> Networking & Telecommunication Services >>> Office of Information Technology >>> University of Minnesota >>> 2218 University Ave SE >>> >>> Phone: 612-626-0815 <(612)%20626-0815> >>> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> >>> =============================================== >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to >>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at arin.net if you experience any issues. >>> >>> >>> >> >> >> -- >> =============================================== >> David Farmer Email:farmer at umn.edu >> Networking & Telecommunication Services >> Office of Information Technology >> University of Minnesota >> 2218 University Ave SE >> >> Phone: 612-626-0815 <(612)%20626-0815> >> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> >> =============================================== >> >> >> > > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE > > Phone: 612-626-0815 <(612)%20626-0815> > Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> > =============================================== > > > -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From scottleibrand at gmail.com Thu Jan 18 19:07:59 2018 From: scottleibrand at gmail.com (Scott Leibrand) Date: Fri, 19 Jan 2018 01:07:59 +0100 Subject: [arin-ppml] Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers In-Reply-To: References: <37CC78F2-D908-44A6-A75F-22B84CAD9E76@delong.com> Message-ID: <7AB0967C-2CE4-4878-A76C-85A3D5E50CCC@gmail.com> Quoting myself: > 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. Do you know of any organizations transferring blocks larger than a /24 for whom officer-attested justification is burdensome (to them or to ARIN)? Scott > On Jan 19, 2018, at 12:35 AM, David Farmer wrote: > > Owen, I think you are justified in taking an "I told you so!" > > But, here are the two options as I see them to harmonize things; > > 1. Change 4.2.2 to /24 > > 2. Change 8.5.3 to /21 > > I think Owen is saying #2, and the best I could glean from the previous comments most we leaning toward #1. > > So, which way do people think we should go, #1 or #2? > > Thanks. > >> On Thu, Jan 18, 2018 at 5:17 PM, Owen DeLong wrote: >> Well, section 4 doesn?t govern transfers since we decoupled it anyway, so I?m not sure if we want to make staff behavior consistent or not. I would argue that moving the transfer boundary to /21 would make more sense than moving the section 4 boundary to /24, if we are going to synchronize them. >> >> However, as you point out, transfers are governed by 8.5.5 and only free pool is governed by section 4 unless section 4 is referenced by section 8. >> >> As you may recall, I opposed this decoupling because of the confusion and disparity in protocol I expected to result. Now we?re exactly where I predicted we?d be. >> >> Owen >> >>> On Jan 18, 2018, at 3:03 PM, David Farmer wrote: >>> >>> From the updated problem statement: 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. >>> >>> Again, whether a change in policy or staff practice, what do we want to happen? >>> >>>> On Thu, Jan 18, 2018 at 4:38 PM, Owen DeLong wrote: >>>> The existing language ?up to a /21? is consistent with staff allowing you to obtain a /24 via transfer. >>>> >>>> Are you telling me that staff is refusing /21 transfers, but allowing /24 transfers to new ISPs without further justification? If so, I would argue that current staff practice is in error vs. policy language. >>>> >>>> Owen >>>> >>>>> On Jan 18, 2018, at 2:37 PM, David Farmer wrote: >>>>> >>>>> Owen, >>>>> >>>>> Yep, that was an editing error, it should have been; >>>>> >>>>> 4.2.2. Initial allocation to ISPs >>>>> >>>>> All ISP organizations without direct assignments or allocations from ARIN qualify for an initial allocation of a /24. Organizations may qualify for a larger initial allocation by documenting how the requested allocation will be utilized within 24 months. >>>>> >>>>>> On Thu, Jan 18, 2018 at 4:26 PM, Owen DeLong wrote: >>>>>> I see no reason to move the boundary for an ISP initial allocation from /21 to /24. >>>>> >>>>> Well that seems to be staff intrupretation if you are getting an initial allocation via a transfer, how would you reslove this then? >>>>> >>>>> Thanks. >>>>> >>>>>> I certainly see no reason for ?up to a /24? as there?s nothing smaller available and even if it were, it wouldn?t be useful in any foreseeable environment. >>>>>> >>>>>> Owen >>>>>> >>>>>>> On Jan 18, 2018, at 2:21 PM, David Farmer wrote: >>>>>>> >>>>>>> David, >>>>>>> >>>>>>> The resolution you suggest below seems like a different policy proposal to me, one with a significantly broader scope than this draft policy has. But I think it is a valid question for the community to consider, it's just not really the problem statement in question for this Draft Policy. >>>>>>> >>>>>>> So, back within the scope of this Draft Policy as the shepherd, I plan to push forward Andrew's updated Problem Statement with a Policy Statement that harmonizes and simplifies the text in section 4.2.2 as an official update to this Draft Policy to get the conversation moving again. >>>>>>> >>>>>>> The current text of 4.2.2 is; >>>>>>> >>>>>>> 4.2.2. Initial allocation to ISPs >>>>>>> >>>>>>> All ISP organizations without direct assignments or allocations from ARIN qualify for an initial allocation of up to a /21, subject to ARIN's minimum allocation size. Organizations may qualify for a larger initial allocation by documenting how the requested allocation will be utilized within 24 months. ISPs renumbering out of their previous address space will be given a reasonable amount of time to do so, and any blocks they are returning will not count against their utilization. >>>>>>> >>>>>>> The text "subject to ARIN's minimum allocation size" seems extraneous. And, post runout renumbering and returning any address space seems unlikely, so let's just eliminate that whole sentence. >>>>>>> >>>>>>> I propose we simplify that to the following; >>>>>>> >>>>>>> 4.2.2. Initial allocation to ISPs >>>>>>> >>>>>>> All ISP organizations without direct assignments or allocations from ARIN qualify for an initial allocation of up to a /24. Organizations may qualify for a larger initial allocation by documenting how the requested allocation will be utilized within 24 months. >>>>>>> >>>>>>> Below is the policy update that results; >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> -------- >>>>>>> >>>>>>> Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers >>>>>>> >>>>>>> Problem Statement: >>>>>>> >>>>>>> It was noted in 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 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. >>>>>>> >>>>>>> Policy Statement: >>>>>>> >>>>>>> Change section 4.2.2 as follows; >>>>>>> >>>>>>> 4.2.2. Initial allocation to ISPs >>>>>>> >>>>>>> All ISP organizations without direct assignments or allocations from ARIN qualify for an initial allocation of up to a /24. Organizations may qualify for a larger initial allocation by documenting how the requested allocation will be utilized within 24 months. >>>>>>> >>>>>>> Comments: >>>>>>> >>>>>>> Timetable for implementation: Immediate >>>>>>> >>>>>>> >>>>>>>> On Thu, Dec 7, 2017 at 11:37 PM, David Huberman wrote: >>>>>>>> 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. >>>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> =============================================== >>>>>>> David Farmer Email:farmer at umn.edu >>>>>>> Networking & Telecommunication Services >>>>>>> Office of Information Technology >>>>>>> University of Minnesota >>>>>>> 2218 University Ave SE Phone: 612-626-0815 >>>>>>> Minneapolis, MN 55414-3029 Cell: 612-812-9952 >>>>>>> =============================================== >>>>>>> _______________________________________________ >>>>>>> PPML >>>>>>> You are receiving this message because you are subscribed to >>>>>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>>>>>> Unsubscribe or manage your mailing list subscription at: >>>>>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>>>>> Please contact info at arin.net if you experience any issues. >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> =============================================== >>>>> David Farmer Email:farmer at umn.edu >>>>> Networking & Telecommunication Services >>>>> Office of Information Technology >>>>> University of Minnesota >>>>> 2218 University Ave SE Phone: 612-626-0815 >>>>> Minneapolis, MN 55414-3029 Cell: 612-812-9952 >>>>> =============================================== >>>> >>> >>> >>> >>> -- >>> =============================================== >>> David Farmer Email:farmer at umn.edu >>> Networking & Telecommunication Services >>> Office of Information Technology >>> University of Minnesota >>> 2218 University Ave SE Phone: 612-626-0815 >>> Minneapolis, MN 55414-3029 Cell: 612-812-9952 >>> =============================================== >> > > > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =============================================== > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Thu Jan 18 19:26:29 2018 From: owen at delong.com (Owen DeLong) Date: Thu, 18 Jan 2018 16:26:29 -0800 Subject: [arin-ppml] Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers In-Reply-To: <7AB0967C-2CE4-4878-A76C-85A3D5E50CCC@gmail.com> References: <37CC78F2-D908-44A6-A75F-22B84CAD9E76@delong.com> <7AB0967C-2CE4-4878-A76C-85A3D5E50CCC@gmail.com> Message-ID: <923C9197-0014-4442-84D9-02D83586898F@delong.com> However, since we?re talking about making changes here anyway (2017-9 is proposing changes), I would still argue that the more logical change to make if we care about harmonization is to change section 8 rather than section 4. If we don?t care about harmonization, then let?s not change either one. Owen > On Jan 18, 2018, at 4:07 PM, Scott Leibrand wrote: > > Quoting myself: > >> 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. > > > Do you know of any organizations transferring blocks larger than a /24 for whom officer-attested justification is burdensome (to them or to ARIN)? > > Scott > > On Jan 19, 2018, at 12:35 AM, David Farmer > wrote: > >> Owen, I think you are justified in taking an "I told you so!" >> >> But, here are the two options as I see them to harmonize things; >> >> 1. Change 4.2.2 to /24 >> >> 2. Change 8.5.3 to /21 >> >> I think Owen is saying #2, and the best I could glean from the previous comments most we leaning toward #1. >> >> So, which way do people think we should go, #1 or #2? >> >> Thanks. >> >> On Thu, Jan 18, 2018 at 5:17 PM, Owen DeLong > wrote: >> Well, section 4 doesn?t govern transfers since we decoupled it anyway, so I?m not sure if we want to make staff behavior consistent or not. I would argue that moving the transfer boundary to /21 would make more sense than moving the section 4 boundary to /24, if we are going to synchronize them. >> >> However, as you point out, transfers are governed by 8.5.5 and only free pool is governed by section 4 unless section 4 is referenced by section 8. >> >> As you may recall, I opposed this decoupling because of the confusion and disparity in protocol I expected to result. Now we?re exactly where I predicted we?d be. >> >> Owen >> >>> On Jan 18, 2018, at 3:03 PM, David Farmer > wrote: >>> >>> From the updated problem statement: 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. >>> >>> Again, whether a change in policy or staff practice, what do we want to happen? >>> >>> On Thu, Jan 18, 2018 at 4:38 PM, Owen DeLong > wrote: >>> The existing language ?up to a /21? is consistent with staff allowing you to obtain a /24 via transfer. >>> >>> Are you telling me that staff is refusing /21 transfers, but allowing /24 transfers to new ISPs without further justification? If so, I would argue that current staff practice is in error vs. policy language. >>> >>> Owen >>> >>>> On Jan 18, 2018, at 2:37 PM, David Farmer > wrote: >>>> >>>> Owen, >>>> >>>> Yep, that was an editing error, it should have been; >>>> >>>> 4.2.2. Initial allocation to ISPs >>>> >>>> All ISP organizations without direct assignments or allocations from ARIN qualify for an initial allocation of a /24. Organizations may qualify for a larger initial allocation by documenting how the requested allocation will be utilized within 24 months. >>>> >>>> On Thu, Jan 18, 2018 at 4:26 PM, Owen DeLong > wrote: >>>> I see no reason to move the boundary for an ISP initial allocation from /21 to /24. >>>> >>>> Well that seems to be staff intrupretation if you are getting an initial allocation via a transfer, how would you reslove this then? >>>> >>>> Thanks. >>>> >>>> I certainly see no reason for ?up to a /24? as there?s nothing smaller available and even if it were, it wouldn?t be useful in any foreseeable environment. >>>> >>>> Owen >>>> >>>>> On Jan 18, 2018, at 2:21 PM, David Farmer > wrote: >>>>> >>>>> David, >>>>> >>>>> The resolution you suggest below seems like a different policy proposal to me, one with a significantly broader scope than this draft policy has. But I think it is a valid question for the community to consider, it's just not really the problem statement in question for this Draft Policy. >>>>> >>>>> So, back within the scope of this Draft Policy as the shepherd, I plan to push forward Andrew's updated Problem Statement with a Policy Statement that harmonizes and simplifies the text in section 4.2.2 as an official update to this Draft Policy to get the conversation moving again. >>>>> >>>>> The current text of 4.2.2 is; >>>>> >>>>> 4.2.2. Initial allocation to ISPs >>>>> >>>>> All ISP organizations without direct assignments or allocations from ARIN qualify for an initial allocation of up to a /21, subject to ARIN's minimum allocation size. Organizations may qualify for a larger initial allocation by documenting how the requested allocation will be utilized within 24 months. ISPs renumbering out of their previous address space will be given a reasonable amount of time to do so, and any blocks they are returning will not count against their utilization. >>>>> >>>>> The text "subject to ARIN's minimum allocation size" seems extraneous. And, post runout renumbering and returning any address space seems unlikely, so let's just eliminate that whole sentence. >>>>> >>>>> I propose we simplify that to the following; >>>>> >>>>> 4.2.2. Initial allocation to ISPs >>>>> >>>>> All ISP organizations without direct assignments or allocations from ARIN qualify for an initial allocation of up to a /24. Organizations may qualify for a larger initial allocation by documenting how the requested allocation will be utilized within 24 months. >>>>> >>>>> Below is the policy update that results; >>>>> >>>>> Thanks >>>>> >>>>> -------- >>>>> >>>>> Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers >>>>> >>>>> Problem Statement: >>>>> >>>>> It was noted in 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 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. >>>>> >>>>> Policy Statement: >>>>> >>>>> Change section 4.2.2 as follows; >>>>> >>>>> 4.2.2. Initial allocation to ISPs >>>>> >>>>> All ISP organizations without direct assignments or allocations from ARIN qualify for an initial allocation of up to a /24. Organizations may qualify for a larger initial allocation by documenting how the requested allocation will be utilized within 24 months. >>>>> >>>>> Comments: >>>>> >>>>> Timetable for implementation: Immediate >>>>> >>>>> >>>>> On Thu, Dec 7, 2017 at 11:37 PM, David Huberman > wrote: >>>>> 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. >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> =============================================== >>>>> David Farmer Email:farmer at umn.edu >>>>> Networking & Telecommunication Services >>>>> Office of Information Technology >>>>> University of Minnesota >>>>> 2218 University Ave SE Phone: 612-626-0815 >>>>> Minneapolis, MN 55414-3029 Cell: 612-812-9952 >>>>> =============================================== >>>>> _______________________________________________ >>>>> PPML >>>>> You are receiving this message because you are subscribed to >>>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). >>>>> Unsubscribe or manage your mailing list subscription at: >>>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>>> Please contact info at arin.net if you experience any issues. >>>> >>>> >>>> >>>> >>>> -- >>>> =============================================== >>>> David Farmer Email:farmer at umn.edu >>>> Networking & Telecommunication Services >>>> Office of Information Technology >>>> University of Minnesota >>>> 2218 University Ave SE Phone: 612-626-0815 >>>> Minneapolis, MN 55414-3029 Cell: 612-812-9952 >>>> =============================================== >>> >>> >>> >>> >>> -- >>> =============================================== >>> David Farmer Email:farmer at umn.edu >>> Networking & Telecommunication Services >>> Office of Information Technology >>> University of Minnesota >>> 2218 University Ave SE Phone: 612-626-0815 >>> Minneapolis, MN 55414-3029 Cell: 612-812-9952 >>> =============================================== >> >> >> >> >> -- >> =============================================== >> David Farmer Email:farmer at umn.edu >> Networking & Telecommunication Services >> Office of Information Technology >> University of Minnesota >> 2218 University Ave SE Phone: 612-626-0815 >> Minneapolis, MN 55414-3029 Cell: 612-812-9952 >> =============================================== >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmer at umn.edu Thu Jan 18 19:32:14 2018 From: farmer at umn.edu (David Farmer) Date: Thu, 18 Jan 2018 18:32:14 -0600 Subject: [arin-ppml] Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers In-Reply-To: References: <37CC78F2-D908-44A6-A75F-22B84CAD9E76@delong.com> Message-ID: Looking at this a little more closely; Section 8.5.4 has a common size for both initial allocations and assignments or in other words an initial transfer size of /24. Whereas in section 4 the initial allocations and assignments sizes differ; with section 4.2.2 having an initial ISP allocation size of /21 and section 4.3.2 having an initial end-user assignment size of /24. So, I believe the easiest way to harmonize section 4 and 8 is to harmonize section 4.2.2 with section 4.3.2 at /24. Otherwise, we need to make section 8 more complicated and distinguishing between initial allocations and assignments sizes. So which way should we go? Thanks. On Thu, Jan 18, 2018 at 5:17 PM, Owen DeLong wrote: > Well, section 4 doesn?t govern transfers since we decoupled it anyway, so > I?m not sure if we want to make staff behavior consistent or not. I would > argue that moving the transfer boundary to /21 would make more sense than > moving the section 4 boundary to /24, if we are going to synchronize them. > > However, as you point out, transfers are governed by 8.5.5 and only free > pool is governed by section 4 unless section 4 is referenced by section 8. > > As you may recall, I opposed this decoupling because of the confusion and > disparity in protocol I expected to result. Now we?re exactly where I > predicted we?d be. > > Owen > > On Jan 18, 2018, at 3:03 PM, David Farmer wrote: > > From the updated problem statement: 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. > > Again, whether a change in policy or staff practice, what do we want to > happen? > > On Thu, Jan 18, 2018 at 4:38 PM, Owen DeLong wrote: > >> The existing language ?up to a /21? is consistent with staff allowing you >> to obtain a /24 via transfer. >> >> Are you telling me that staff is refusing /21 transfers, but allowing /24 >> transfers to new ISPs without further justification? If so, I would argue >> that current staff practice is in error vs. policy language. >> >> Owen >> >> On Jan 18, 2018, at 2:37 PM, David Farmer wrote: >> >> Owen, >> >> Yep, that was an editing error, it should have been; >> >> 4.2.2. Initial allocation to ISPs >> >> All ISP organizations without direct assignments or allocations from ARIN >> qualify for an initial allocation of a /24. Organizations may qualify for a >> larger initial allocation by documenting how the requested allocation will >> be utilized within 24 months. >> >> On Thu, Jan 18, 2018 at 4:26 PM, Owen DeLong wrote: >> >>> I see no reason to move the boundary for an ISP initial allocation from >>> /21 to /24. >>> >> >> Well that seems to be staff intrupretation if you are getting an initial >> allocation via a transfer, how would you reslove this then? >> >> Thanks. >> >> >>> I certainly see no reason for ?up to a /24? as there?s nothing smaller >>> available and even if it were, it wouldn?t be useful in any foreseeable >>> environment. >>> >>> Owen >>> >>> On Jan 18, 2018, at 2:21 PM, David Farmer wrote: >>> >>> David, >>> >>> The resolution you suggest below seems like a different policy proposal >>> to me, one with a significantly broader scope than this draft policy has. >>> But I think it is a valid question for the community to consider, it's just >>> not really the problem statement in question for this Draft Policy. >>> >>> So, back within the scope of this Draft Policy as the shepherd, I plan >>> to push forward Andrew's updated Problem Statement with a Policy Statement >>> that harmonizes and simplifies the text in section 4.2.2 as an official >>> update to this Draft Policy to get the conversation moving again. >>> >>> The current text of 4.2.2 is; >>> >>> 4.2.2. Initial allocation to ISPs >>> >>> All ISP organizations without direct assignments or allocations from >>> ARIN qualify for an initial allocation of up to a /21, subject to ARIN's >>> minimum allocation size. Organizations may qualify for a larger initial >>> allocation by documenting how the requested allocation will be utilized >>> within 24 months. ISPs renumbering out of their previous address space will >>> be given a reasonable amount of time to do so, and any blocks they are >>> returning will not count against their utilization. >>> >>> The text "subject to ARIN's minimum allocation size" seems extraneous. >>> And, post runout renumbering and returning any address space >>> seems unlikely, so let's just eliminate that whole sentence. >>> >>> I propose we simplify that to the following; >>> >>> 4.2.2. Initial allocation to ISPs >>> >>> All ISP organizations without direct assignments or allocations from >>> ARIN qualify for an initial allocation of up to a /24. Organizations may >>> qualify for a larger initial allocation by documenting how the requested >>> allocation will be utilized within 24 months. >>> >>> Below is the policy update that results; >>> >>> Thanks >>> >>> -------- >>> >>> Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 >>> ISP Transfers >>> >>> Problem Statement: >>> >>> It was noted in 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 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. >>> >>> Policy Statement: >>> >>> Change section 4.2.2 as follows; >>> >>> 4.2.2. Initial allocation to ISPs >>> >>> All ISP organizations without direct assignments or allocations from >>> ARIN qualify for an initial allocation of up to a /24. Organizations may >>> qualify for a larger initial allocation by documenting how the requested >>> allocation will be utilized within 24 months. >>> >>> Comments: >>> >>> Timetable for implementation: Immediate >>> >>> >>> On Thu, Dec 7, 2017 at 11:37 PM, David Huberman wr >>> ote: >>> >>>> 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. >>>> >>>> >>> >>> >>> -- >>> =============================================== >>> David Farmer Email:farmer at umn.edu >>> Networking & Telecommunication Services >>> Office of Information Technology >>> University of Minnesota >>> 2218 University Ave SE >>> >>> Phone: 612-626-0815 <(612)%20626-0815> >>> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> >>> =============================================== >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to >>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at arin.net if you experience any issues. >>> >>> >>> >> >> >> -- >> =============================================== >> David Farmer Email:farmer at umn.edu >> Networking & Telecommunication Services >> Office of Information Technology >> University of Minnesota >> 2218 University Ave SE >> >> Phone: 612-626-0815 <(612)%20626-0815> >> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> >> =============================================== >> >> >> > > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE > > Phone: 612-626-0815 <(612)%20626-0815> > Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> > =============================================== > > > -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Thu Jan 18 19:33:57 2018 From: owen at delong.com (Owen DeLong) Date: Thu, 18 Jan 2018 16:33:57 -0800 Subject: [arin-ppml] Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers In-Reply-To: References: <37CC78F2-D908-44A6-A75F-22B84CAD9E76@delong.com> Message-ID: We could also simplify section 8 to state that the minimum transfer size is /24 and that initial requests for transfer are governed by officer attestation limits unless a larger size is needed. Owen > On Jan 18, 2018, at 4:32 PM, David Farmer wrote: > > > Looking at this a little more closely; > > Section 8.5.4 has a common size for both initial allocations and assignments or in other words an initial transfer size of /24. > > Whereas in section 4 the initial allocations and assignments sizes differ; with section 4.2.2 having an initial ISP allocation size of /21 and section 4.3.2 having an initial end-user assignment size of /24. > > So, I believe the easiest way to harmonize section 4 and 8 is to harmonize section 4.2.2 with section 4.3.2 at /24. > > Otherwise, we need to make section 8 more complicated and distinguishing between initial allocations and assignments sizes. > > So which way should we go? > > Thanks. > > On Thu, Jan 18, 2018 at 5:17 PM, Owen DeLong > wrote: > Well, section 4 doesn?t govern transfers since we decoupled it anyway, so I?m not sure if we want to make staff behavior consistent or not. I would argue that moving the transfer boundary to /21 would make more sense than moving the section 4 boundary to /24, if we are going to synchronize them. > > However, as you point out, transfers are governed by 8.5.5 and only free pool is governed by section 4 unless section 4 is referenced by section 8. > > As you may recall, I opposed this decoupling because of the confusion and disparity in protocol I expected to result. Now we?re exactly where I predicted we?d be. > > Owen > >> On Jan 18, 2018, at 3:03 PM, David Farmer > wrote: >> >> From the updated problem statement: 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. >> >> Again, whether a change in policy or staff practice, what do we want to happen? >> >> On Thu, Jan 18, 2018 at 4:38 PM, Owen DeLong > wrote: >> The existing language ?up to a /21? is consistent with staff allowing you to obtain a /24 via transfer. >> >> Are you telling me that staff is refusing /21 transfers, but allowing /24 transfers to new ISPs without further justification? If so, I would argue that current staff practice is in error vs. policy language. >> >> Owen >> >>> On Jan 18, 2018, at 2:37 PM, David Farmer > wrote: >>> >>> Owen, >>> >>> Yep, that was an editing error, it should have been; >>> >>> 4.2.2. Initial allocation to ISPs >>> >>> All ISP organizations without direct assignments or allocations from ARIN qualify for an initial allocation of a /24. Organizations may qualify for a larger initial allocation by documenting how the requested allocation will be utilized within 24 months. >>> >>> On Thu, Jan 18, 2018 at 4:26 PM, Owen DeLong > wrote: >>> I see no reason to move the boundary for an ISP initial allocation from /21 to /24. >>> >>> Well that seems to be staff intrupretation if you are getting an initial allocation via a transfer, how would you reslove this then? >>> >>> Thanks. >>> >>> I certainly see no reason for ?up to a /24? as there?s nothing smaller available and even if it were, it wouldn?t be useful in any foreseeable environment. >>> >>> Owen >>> >>>> On Jan 18, 2018, at 2:21 PM, David Farmer > wrote: >>>> >>>> David, >>>> >>>> The resolution you suggest below seems like a different policy proposal to me, one with a significantly broader scope than this draft policy has. But I think it is a valid question for the community to consider, it's just not really the problem statement in question for this Draft Policy. >>>> >>>> So, back within the scope of this Draft Policy as the shepherd, I plan to push forward Andrew's updated Problem Statement with a Policy Statement that harmonizes and simplifies the text in section 4.2.2 as an official update to this Draft Policy to get the conversation moving again. >>>> >>>> The current text of 4.2.2 is; >>>> >>>> 4.2.2. Initial allocation to ISPs >>>> >>>> All ISP organizations without direct assignments or allocations from ARIN qualify for an initial allocation of up to a /21, subject to ARIN's minimum allocation size. Organizations may qualify for a larger initial allocation by documenting how the requested allocation will be utilized within 24 months. ISPs renumbering out of their previous address space will be given a reasonable amount of time to do so, and any blocks they are returning will not count against their utilization. >>>> >>>> The text "subject to ARIN's minimum allocation size" seems extraneous. And, post runout renumbering and returning any address space seems unlikely, so let's just eliminate that whole sentence. >>>> >>>> I propose we simplify that to the following; >>>> >>>> 4.2.2. Initial allocation to ISPs >>>> >>>> All ISP organizations without direct assignments or allocations from ARIN qualify for an initial allocation of up to a /24. Organizations may qualify for a larger initial allocation by documenting how the requested allocation will be utilized within 24 months. >>>> >>>> Below is the policy update that results; >>>> >>>> Thanks >>>> >>>> -------- >>>> >>>> Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers >>>> >>>> Problem Statement: >>>> >>>> It was noted in 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 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. >>>> >>>> Policy Statement: >>>> >>>> Change section 4.2.2 as follows; >>>> >>>> 4.2.2. Initial allocation to ISPs >>>> >>>> All ISP organizations without direct assignments or allocations from ARIN qualify for an initial allocation of up to a /24. Organizations may qualify for a larger initial allocation by documenting how the requested allocation will be utilized within 24 months. >>>> >>>> Comments: >>>> >>>> Timetable for implementation: Immediate >>>> >>>> >>>> On Thu, Dec 7, 2017 at 11:37 PM, David Huberman > wrote: >>>> 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. >>>>> >>>> >>>> >>>> >>>> -- >>>> =============================================== >>>> David Farmer Email:farmer at umn.edu >>>> Networking & Telecommunication Services >>>> Office of Information Technology >>>> University of Minnesota >>>> 2218 University Ave SE Phone: 612-626-0815 >>>> Minneapolis, MN 55414-3029 Cell: 612-812-9952 >>>> =============================================== >>>> _______________________________________________ >>>> PPML >>>> You are receiving this message because you are subscribed to >>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). >>>> Unsubscribe or manage your mailing list subscription at: >>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>> Please contact info at arin.net if you experience any issues. >>> >>> >>> >>> >>> -- >>> =============================================== >>> David Farmer Email:farmer at umn.edu >>> Networking & Telecommunication Services >>> Office of Information Technology >>> University of Minnesota >>> 2218 University Ave SE Phone: 612-626-0815 >>> Minneapolis, MN 55414-3029 Cell: 612-812-9952 >>> =============================================== >> >> >> >> >> -- >> =============================================== >> David Farmer Email:farmer at umn.edu >> Networking & Telecommunication Services >> Office of Information Technology >> University of Minnesota >> 2218 University Ave SE Phone: 612-626-0815 >> Minneapolis, MN 55414-3029 Cell: 612-812-9952 >> =============================================== > > > > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From narten at us.ibm.com Fri Jan 19 00:53:02 2018 From: narten at us.ibm.com (narten at us.ibm.com) Date: Fri, 19 Jan 2018 00:53:02 -0500 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201801190553.w0J5r3v7031799@rotala.raleigh.ibm.com> Total of 27 messages in the last 7 days. script run at: Fri Jan 19 00:53:02 EST 2018 Messages | Bytes | Who --------+------+--------+----------+------------------------ 37.04% | 10 | 36.85% | 279594 | farmer at umn.edu 25.93% | 7 | 31.73% | 240732 | owen at delong.com 11.11% | 3 | 5.82% | 44123 | hostmaster at uneedus.com 7.41% | 2 | 7.17% | 54392 | jschiller at google.com 3.70% | 1 | 6.10% | 46256 | scottleibrand at gmail.com 3.70% | 1 | 5.48% | 41602 | chris at semihuman.com 3.70% | 1 | 2.89% | 21899 | admin at wsfnet.org 3.70% | 1 | 2.73% | 20712 | carlton.samuels at gmail.com 3.70% | 1 | 1.25% | 9453 | narten at us.ibm.com --------+------+--------+----------+------------------------ 100.00% | 27 |100.00% | 758763 | Total From jschiller at google.com Fri Jan 19 12:11:32 2018 From: jschiller at google.com (Jason Schiller) Date: Fri, 19 Jan 2018 12:11:32 -0500 Subject: [arin-ppml] Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers In-Reply-To: References: <37CC78F2-D908-44A6-A75F-22B84CAD9E76@delong.com> Message-ID: Can you clarify the problem (I'm confused). What I expect to happen and an ISP under 4.2.2 can get an initial allocation of between a /24 and a /21 inclusive. They will be slow started because they have no history. They can get a 2 year supply, and will need to make it 80% utilized before they can come back for more.. Utilized means: - If an IP block is allocated/assigned to a customer and one of the following is true: - the customer can show justification for 25% utilization in 30 days 50% in 1 year - the customer can show a discreet multi-homing requirement each /24 - the residential market area IP block is at least 50% utilized - the residential market area is TPIA and - initial assignments to each piece of hardware is the smallest possible - additional assignments to each piece of hardware only made after 80% utilization - additional assignments to each piece of hardware is not more than a 2 year supply Then that space is considered 100% utilized IP space in use by the ISP is counted as utilized. This includes network and broadcast addresses for subsets in use. Under 8.5.4 They can transfer pre-approval for a /24 no questions asked if they have no direct IPv4. If they have a direct IPv4, or want pre-approval for more than a /24 then they need to show how they will use 50% of the requested space in 24 months. What is weird is post last /8, ISP could only get a 90 day supply on slow start and then had to come back. So request for ARIN space were 1/8 the size (90 days) of what could be request on the transfer market (2 years). We adjusted this back to a two year supply to mirror the transfer window of time and simplify things (which I opposed at the time, but now that it is changed standby it). ___Jason On Thu, Jan 18, 2018 at 7:33 PM, Owen DeLong wrote: > We could also simplify section 8 to state that the minimum transfer size > is /24 and that initial requests for transfer are governed by officer > attestation limits unless a larger size is needed. > > Owen > > On Jan 18, 2018, at 4:32 PM, David Farmer wrote: > > > Looking at this a little more closely; > > Section 8.5.4 has a common size for both initial allocations and > assignments or in other words an initial transfer size of /24. > > Whereas in section 4 the initial allocations and assignments sizes differ; > with section 4.2.2 having an initial ISP allocation size of /21 and section > 4.3.2 having an initial end-user assignment size of /24. > > So, I believe the easiest way to harmonize section 4 and 8 is to harmonize > section 4.2.2 with section 4.3.2 at /24. > > Otherwise, we need to make section 8 more complicated and distinguishing > between initial allocations and assignments sizes. > > So which way should we go? > > Thanks. > > On Thu, Jan 18, 2018 at 5:17 PM, Owen DeLong wrote: > >> Well, section 4 doesn?t govern transfers since we decoupled it anyway, so >> I?m not sure if we want to make staff behavior consistent or not. I would >> argue that moving the transfer boundary to /21 would make more sense than >> moving the section 4 boundary to /24, if we are going to synchronize them. >> >> However, as you point out, transfers are governed by 8.5.5 and only free >> pool is governed by section 4 unless section 4 is referenced by section 8. >> >> As you may recall, I opposed this decoupling because of the confusion and >> disparity in protocol I expected to result. Now we?re exactly where I >> predicted we?d be. >> >> Owen >> >> On Jan 18, 2018, at 3:03 PM, David Farmer wrote: >> >> From the updated problem statement: 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. >> >> Again, whether a change in policy or staff practice, what do we want to >> happen? >> >> On Thu, Jan 18, 2018 at 4:38 PM, Owen DeLong wrote: >> >>> The existing language ?up to a /21? is consistent with staff allowing >>> you to obtain a /24 via transfer. >>> >>> Are you telling me that staff is refusing /21 transfers, but allowing >>> /24 transfers to new ISPs without further justification? If so, I would >>> argue that current staff practice is in error vs. policy language. >>> >>> Owen >>> >>> On Jan 18, 2018, at 2:37 PM, David Farmer wrote: >>> >>> Owen, >>> >>> Yep, that was an editing error, it should have been; >>> >>> 4.2.2. Initial allocation to ISPs >>> >>> All ISP organizations without direct assignments or allocations from >>> ARIN qualify for an initial allocation of a /24. Organizations may qualify >>> for a larger initial allocation by documenting how the requested allocation >>> will be utilized within 24 months. >>> >>> On Thu, Jan 18, 2018 at 4:26 PM, Owen DeLong wrote: >>> >>>> I see no reason to move the boundary for an ISP initial allocation from >>>> /21 to /24. >>>> >>> >>> Well that seems to be staff intrupretation if you are getting an initial >>> allocation via a transfer, how would you reslove this then? >>> >>> Thanks. >>> >>> >>>> I certainly see no reason for ?up to a /24? as there?s nothing smaller >>>> available and even if it were, it wouldn?t be useful in any foreseeable >>>> environment. >>>> >>>> Owen >>>> >>>> On Jan 18, 2018, at 2:21 PM, David Farmer wrote: >>>> >>>> David, >>>> >>>> The resolution you suggest below seems like a different policy proposal >>>> to me, one with a significantly broader scope than this draft policy has. >>>> But I think it is a valid question for the community to consider, it's just >>>> not really the problem statement in question for this Draft Policy. >>>> >>>> So, back within the scope of this Draft Policy as the shepherd, I plan >>>> to push forward Andrew's updated Problem Statement with a Policy Statement >>>> that harmonizes and simplifies the text in section 4.2.2 as an official >>>> update to this Draft Policy to get the conversation moving again. >>>> >>>> The current text of 4.2.2 is; >>>> >>>> 4.2.2. Initial allocation to ISPs >>>> >>>> All ISP organizations without direct assignments or allocations from >>>> ARIN qualify for an initial allocation of up to a /21, subject to ARIN's >>>> minimum allocation size. Organizations may qualify for a larger initial >>>> allocation by documenting how the requested allocation will be utilized >>>> within 24 months. ISPs renumbering out of their previous address space will >>>> be given a reasonable amount of time to do so, and any blocks they are >>>> returning will not count against their utilization. >>>> >>>> The text "subject to ARIN's minimum allocation size" seems extraneous. >>>> And, post runout renumbering and returning any address space >>>> seems unlikely, so let's just eliminate that whole sentence. >>>> >>>> I propose we simplify that to the following; >>>> >>>> 4.2.2. Initial allocation to ISPs >>>> >>>> All ISP organizations without direct assignments or allocations from >>>> ARIN qualify for an initial allocation of up to a /24. Organizations may >>>> qualify for a larger initial allocation by documenting how the requested >>>> allocation will be utilized within 24 months. >>>> >>>> Below is the policy update that results; >>>> >>>> Thanks >>>> >>>> -------- >>>> >>>> Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 >>>> ISP Transfers >>>> >>>> Problem Statement: >>>> >>>> It was noted in 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 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. >>>> >>>> Policy Statement: >>>> >>>> Change section 4.2.2 as follows; >>>> >>>> 4.2.2. Initial allocation to ISPs >>>> >>>> All ISP organizations without direct assignments or allocations from >>>> ARIN qualify for an initial allocation of up to a /24. Organizations may >>>> qualify for a larger initial allocation by documenting how the requested >>>> allocation will be utilized within 24 months. >>>> >>>> Comments: >>>> >>>> Timetable for implementation: Immediate >>>> >>>> >>>> On Thu, Dec 7, 2017 at 11:37 PM, David Huberman wr >>>> ote: >>>> >>>>> 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. >>>>> >>>>> >>>> >>>> >>>> -- >>>> =============================================== >>>> David Farmer Email:farmer at umn.edu >>>> Networking & Telecommunication Services >>>> Office of Information Technology >>>> University of Minnesota >>>> 2218 University Ave SE >>>> >>>> Phone: 612-626-0815 <(612)%20626-0815> >>>> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> >>>> =============================================== >>>> _______________________________________________ >>>> PPML >>>> You are receiving this message because you are subscribed to >>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>>> Unsubscribe or manage your mailing list subscription at: >>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>> Please contact info at arin.net if you experience any issues. >>>> >>>> >>>> >>> >>> >>> -- >>> =============================================== >>> David Farmer Email:farmer at umn.edu >>> Networking & Telecommunication Services >>> Office of Information Technology >>> University of Minnesota >>> 2218 University Ave SE >>> >>> Phone: 612-626-0815 <(612)%20626-0815> >>> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> >>> =============================================== >>> >>> >>> >> >> >> -- >> =============================================== >> David Farmer Email:farmer at umn.edu >> Networking & Telecommunication Services >> Office of Information Technology >> University of Minnesota >> 2218 University Ave SE >> >> Phone: 612-626-0815 <(612)%20626-0815> >> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> >> =============================================== >> >> >> > > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> > Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> > =============================================== > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmer at umn.edu Fri Jan 19 15:23:11 2018 From: farmer at umn.edu (David Farmer) Date: Fri, 19 Jan 2018 14:23:11 -0600 Subject: [arin-ppml] Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers In-Reply-To: References: <37CC78F2-D908-44A6-A75F-22B84CAD9E76@delong.com> Message-ID: For additional background, see the ARIN 40 Policy Experience Report; Slides 10 - 13, and on the video from 6:30 to 8:30, questions follow. Slides: https://www.arin.net/vault/participate/meetings/reports/ARIN _40/PDF/PPM/sweeting-policy-experience.pdf Transcript: https://www.arin.net/vault/participate/meetings/ reports/ARIN_40/ppm1_transcript.html#anchor_5 Video: https://www.youtube.com/watch?v=QVsfVMG_6fA On Fri, Jan 19, 2018 at 11:11 AM, Jason Schiller wrote: > Can you clarify the problem (I'm confused). > I think you summrized it well, there is a inconsistency between 4.2.2 and 8.5.4 for ISPs, but 4.3.2 and 8.5.4 are consistent for end-users. What do we want to do about it? > What I expect to happen and an ISP under 4.2.2 can get an initial > allocation of between a /24 and a /21 inclusive. > They will be slow started because they have no history. They can get a 2 > year supply, and will need to make it > 80% utilized before they can come back for more.. > > Utilized means: > > - If an IP block is allocated/assigned to a customer and one of the > following is true: > - the customer can show justification for 25% utilization in 30 days > 50% in 1 year > - the customer can show a discreet multi-homing requirement each /24 > - the residential market area IP block is at least 50% utilized > - the residential market area is TPIA and > - initial assignments to each piece of hardware is the smallest > possible > - additional assignments to each piece of hardware only made after > 80% utilization > - additional assignments to each piece of hardware is not more than > a 2 year supply > > Then that space is considered 100% utilized > > IP space in use by the ISP is counted as utilized. > This includes network and broadcast addresses for subsets in use. > > > Under 8.5.4 > They can transfer pre-approval for a /24 no questions asked if they have > no direct IPv4. > > If they have a direct IPv4, or want pre-approval for more than a /24 then > they > need to show how they will use 50% of the requested space in 24 months. > > > > What is weird is post last /8, ISP could only get a 90 day supply on slow > start and then > had to come back. So request for ARIN space were 1/8 the size (90 days) > of what could > be request on the transfer market (2 years). We adjusted this back to a > two year supply to > mirror the transfer window of time and simplify things (which I opposed at > the time, > but now that it is changed standby it). > > ___Jason > > > > > > > On Thu, Jan 18, 2018 at 7:33 PM, Owen DeLong wrote: > >> We could also simplify section 8 to state that the minimum transfer size >> is /24 and that initial requests for transfer are governed by officer >> attestation limits unless a larger size is needed. >> >> Owen >> >> On Jan 18, 2018, at 4:32 PM, David Farmer wrote: >> >> >> Looking at this a little more closely; >> >> Section 8.5.4 has a common size for both initial allocations and >> assignments or in other words an initial transfer size of /24. >> >> Whereas in section 4 the initial allocations and assignments sizes >> differ; with section 4.2.2 having an initial ISP allocation size of /21 and >> section 4.3.2 having an initial end-user assignment size of /24. >> >> So, I believe the easiest way to harmonize section 4 and 8 is to >> harmonize section 4.2.2 with section 4.3.2 at /24. >> >> Otherwise, we need to make section 8 more complicated and distinguishing >> between initial allocations and assignments sizes. >> >> So which way should we go? >> >> Thanks. >> >> On Thu, Jan 18, 2018 at 5:17 PM, Owen DeLong wrote: >> >>> Well, section 4 doesn?t govern transfers since we decoupled it anyway, >>> so I?m not sure if we want to make staff behavior consistent or not. I >>> would argue that moving the transfer boundary to /21 would make more sense >>> than moving the section 4 boundary to /24, if we are going to synchronize >>> them. >>> >>> However, as you point out, transfers are governed by 8.5.5 and only free >>> pool is governed by section 4 unless section 4 is referenced by section 8. >>> >>> As you may recall, I opposed this decoupling because of the confusion >>> and disparity in protocol I expected to result. Now we?re exactly where I >>> predicted we?d be. >>> >>> Owen >>> >>> On Jan 18, 2018, at 3:03 PM, David Farmer wrote: >>> >>> From the updated problem statement: 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. >>> >>> Again, whether a change in policy or staff practice, what do we want to >>> happen? >>> >>> On Thu, Jan 18, 2018 at 4:38 PM, Owen DeLong wrote: >>> >>>> The existing language ?up to a /21? is consistent with staff allowing >>>> you to obtain a /24 via transfer. >>>> >>>> Are you telling me that staff is refusing /21 transfers, but allowing >>>> /24 transfers to new ISPs without further justification? If so, I would >>>> argue that current staff practice is in error vs. policy language. >>>> >>>> Owen >>>> >>>> On Jan 18, 2018, at 2:37 PM, David Farmer wrote: >>>> >>>> Owen, >>>> >>>> Yep, that was an editing error, it should have been; >>>> >>>> 4.2.2. Initial allocation to ISPs >>>> >>>> All ISP organizations without direct assignments or allocations from >>>> ARIN qualify for an initial allocation of a /24. Organizations may qualify >>>> for a larger initial allocation by documenting how the requested allocation >>>> will be utilized within 24 months. >>>> >>>> On Thu, Jan 18, 2018 at 4:26 PM, Owen DeLong wrote: >>>> >>>>> I see no reason to move the boundary for an ISP initial allocation >>>>> from /21 to /24. >>>>> >>>> >>>> Well that seems to be staff intrupretation if you are getting an >>>> initial allocation via a transfer, how would you reslove this then? >>>> >>>> Thanks. >>>> >>>> >>>>> I certainly see no reason for ?up to a /24? as there?s nothing smaller >>>>> available and even if it were, it wouldn?t be useful in any foreseeable >>>>> environment. >>>>> >>>>> Owen >>>>> >>>>> On Jan 18, 2018, at 2:21 PM, David Farmer wrote: >>>>> >>>>> David, >>>>> >>>>> The resolution you suggest below seems like a different policy >>>>> proposal to me, one with a significantly broader scope than this draft >>>>> policy has. But I think it is a valid question for the community to >>>>> consider, it's just not really the problem statement in question for this >>>>> Draft Policy. >>>>> >>>>> So, back within the scope of this Draft Policy as the shepherd, I plan >>>>> to push forward Andrew's updated Problem Statement with a Policy Statement >>>>> that harmonizes and simplifies the text in section 4.2.2 as an official >>>>> update to this Draft Policy to get the conversation moving again. >>>>> >>>>> The current text of 4.2.2 is; >>>>> >>>>> 4.2.2. Initial allocation to ISPs >>>>> >>>>> All ISP organizations without direct assignments or allocations from >>>>> ARIN qualify for an initial allocation of up to a /21, subject to ARIN's >>>>> minimum allocation size. Organizations may qualify for a larger initial >>>>> allocation by documenting how the requested allocation will be utilized >>>>> within 24 months. ISPs renumbering out of their previous address space will >>>>> be given a reasonable amount of time to do so, and any blocks they are >>>>> returning will not count against their utilization. >>>>> >>>>> The text "subject to ARIN's minimum allocation size" seems >>>>> extraneous. And, post runout renumbering and returning any address space >>>>> seems unlikely, so let's just eliminate that whole sentence. >>>>> >>>>> I propose we simplify that to the following; >>>>> >>>>> 4.2.2. Initial allocation to ISPs >>>>> >>>>> All ISP organizations without direct assignments or allocations from >>>>> ARIN qualify for an initial allocation of up to a /24. Organizations may >>>>> qualify for a larger initial allocation by documenting how the requested >>>>> allocation will be utilized within 24 months. >>>>> >>>>> Below is the policy update that results; >>>>> >>>>> Thanks >>>>> >>>>> -------- >>>>> >>>>> Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 >>>>> ISP Transfers >>>>> >>>>> Problem Statement: >>>>> >>>>> It was noted in 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 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. >>>>> >>>>> Policy Statement: >>>>> >>>>> Change section 4.2.2 as follows; >>>>> >>>>> 4.2.2. Initial allocation to ISPs >>>>> >>>>> All ISP organizations without direct assignments or allocations from >>>>> ARIN qualify for an initial allocation of up to a /24. Organizations may >>>>> qualify for a larger initial allocation by documenting how the requested >>>>> allocation will be utilized within 24 months. >>>>> >>>>> Comments: >>>>> >>>>> Timetable for implementation: Immediate >>>>> >>>>> >>>>> On Thu, Dec 7, 2017 at 11:37 PM, David Huberman wr >>>>> ote: >>>>> >>>>>> 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. >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> =============================================== >>>>> David Farmer Email:farmer at umn.edu >>>>> Networking & Telecommunication Services >>>>> Office of Information Technology >>>>> University of Minnesota >>>>> 2218 University Ave SE >>>>> >>>>> Phone: 612-626-0815 <(612)%20626-0815> >>>>> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> >>>>> =============================================== >>>>> _______________________________________________ >>>>> PPML >>>>> You are receiving this message because you are subscribed to >>>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>>>> Unsubscribe or manage your mailing list subscription at: >>>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>>> Please contact info at arin.net if you experience any issues. >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> =============================================== >>>> David Farmer Email:farmer at umn.edu >>>> Networking & Telecommunication Services >>>> Office of Information Technology >>>> University of Minnesota >>>> 2218 University Ave SE >>>> >>>> Phone: 612-626-0815 <(612)%20626-0815> >>>> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> >>>> =============================================== >>>> >>>> >>>> >>> >>> >>> -- >>> =============================================== >>> David Farmer Email:farmer at umn.edu >>> Networking & Telecommunication Services >>> Office of Information Technology >>> University of Minnesota >>> 2218 University Ave SE >>> >>> Phone: 612-626-0815 <(612)%20626-0815> >>> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> >>> =============================================== >>> >>> >>> >> >> >> -- >> =============================================== >> David Farmer Email:farmer at umn.edu >> Networking & Telecommunication Services >> Office of Information Technology >> University of Minnesota >> 2218 University Ave SE >> >> Phone: 612-626-0815 <(612)%20626-0815> >> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> >> =============================================== >> >> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> > > > > -- > _______________________________________________________ > Jason Schiller|NetOps|jschiller at google.com|571-266-0006 <(571)%20266-0006> > > -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmer at umn.edu Sat Jan 20 12:15:34 2018 From: farmer at umn.edu (David Farmer) Date: Sat, 20 Jan 2018 11:15:34 -0600 Subject: [arin-ppml] Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers In-Reply-To: References: Message-ID: I did a completely fresh review of the ARIN 40 Policy Experience Report and the ARIN-2017-9 PPML thread so far. From that, I concluded the best way to present the question to the community is to use Andrew's updated Problem Statement with a Policy Statement that modifies section 8.5.4 Initial Block by providing a /24 for assignments and a /24 up to a /21 for allocations. Please provide any feedback you might have on the following; Thanks ------ Problem Statement: It was noted in 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 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. Policy statement: Replace section 8.5.4 as follows; 8.5.4. Initial block Organizations without direct assignments or allocations from ARIN qualify for the transfer of an initial IPv4 block, a /24 for assignments, or a /24 up to a /21 for allocations. Comments: Timetable for implementation: Immediate The ARIN 40 Policy Experience Report is available at; Slides: https://www.arin.net/vault/participate/meetings/reports/ARIN _40/PDF/PPM/sweeting-policy-experience.pdf Transcript: https://www.arin.net/vault/participate/meetings/reports/ARIN _40/ppm1_transcript.html#anchor_5 Video: https://www.youtube.com/watch?v=QVsfVMG_6fA Slides 10 - 13, located in the video from 6:30 to 8:30, are the relevant portion of the report, questions from the audience follow. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmer at umn.edu Sat Jan 20 12:16:52 2018 From: farmer at umn.edu (David Farmer) Date: Sat, 20 Jan 2018 11:16:52 -0600 Subject: [arin-ppml] Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers In-Reply-To: <7AB0967C-2CE4-4878-A76C-85A3D5E50CCC@gmail.com> References: <37CC78F2-D908-44A6-A75F-22B84CAD9E76@delong.com> <7AB0967C-2CE4-4878-A76C-85A3D5E50CCC@gmail.com> Message-ID: I think the burden is the potential to have to rejustify an ISP's initial allocation when being fulfilled by transfer. The inconsistency seems inefficient and creates confusion; there appears to be support for eliminating the inconsistency. With slightly more support for changing section 8 to be consistent with section 4, rather than the other way around. On Thu, Jan 18, 2018 at 6:07 PM, Scott Leibrand wrote: > Quoting myself: > > 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. > > > Do you know of any organizations transferring blocks larger than a /24 > for whom officer-attested justification is burdensome (to them or to ARIN)? > > Scott > -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From abagrin at mydigitalshield.com Sat Jan 20 12:38:46 2018 From: abagrin at mydigitalshield.com (Andrew Bagrin) Date: Sat, 20 Jan 2018 12:38:46 -0500 Subject: [arin-ppml] Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers In-Reply-To: References: <37CC78F2-D908-44A6-A75F-22B84CAD9E76@delong.com> <7AB0967C-2CE4-4878-A76C-85A3D5E50CCC@gmail.com> Message-ID: Justification seemed reasonably simple. If they are burdensome, we could look at making justification easier. I would vote for #1 but either is fine. I'm all for the prevention of IP blocks hoarding. On Jan 20, 2018 12:17 PM, "David Farmer" wrote: I think the burden is the potential to have to rejustify an ISP's initial allocation when being fulfilled by transfer. The inconsistency seems inefficient and creates confusion; there appears to be support for eliminating the inconsistency. With slightly more support for changing section 8 to be consistent with section 4, rather than the other way around. On Thu, Jan 18, 2018 at 6:07 PM, Scott Leibrand wrote: > Quoting myself: > > 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. > > > Do you know of any organizations transferring blocks larger than a /24 > for whom officer-attested justification is burdensome (to them or to ARIN)? > > Scott > -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> =============================================== _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Mon Jan 22 18:27:23 2018 From: owen at delong.com (Owen DeLong) Date: Mon, 22 Jan 2018 15:27:23 -0800 Subject: [arin-ppml] Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers In-Reply-To: References: <37CC78F2-D908-44A6-A75F-22B84CAD9E76@delong.com> <7AB0967C-2CE4-4878-A76C-85A3D5E50CCC@gmail.com> Message-ID: I hardly think that an ISP getting a /21 as their first allocation via transfer can support much hoarding. Really, we?re talking about trying to issue addresses to customers _AND_ manage your own infrastructure out of a total of 8 /24s. Just a barebones ISP infrastructure strikes me as quickly approaching a pair of /24s leaving only 6 /24s to issue to customers. If you?re a 100% residential provider, you?re going to need a lot more customers than that just to be profitable. If you?re a 100% business provider, even if we assume only a /29 per customer, that?s still only 192 customers before you?re at 100% utilization. If you?ve got some mix, then you have a smaller number of business customers who might be subsidizing your residential customers, but it?s still not a large customer count. Any ISP smaller than that isn?t going to want to pay the acquisition costs of the extra space in the transfer market to begin with. If we?re worried about hoarding, that?s going to be something very large organizations with large budgets will do if it?s going to matter at all. Owen > On Jan 20, 2018, at 9:38 AM, Andrew Bagrin wrote: > > Justification seemed reasonably simple. If they are burdensome, we could look at making justification easier. > I would vote for #1 but either is fine. I'm all for the prevention of IP blocks hoarding. > > On Jan 20, 2018 12:17 PM, "David Farmer" > wrote: > I think the burden is the potential to have to rejustify an ISP's initial allocation when being fulfilled by transfer. The inconsistency seems inefficient and creates confusion; there appears to be support for eliminating the inconsistency. With slightly more support for changing section 8 to be consistent with section 4, rather than the other way around. > > On Thu, Jan 18, 2018 at 6:07 PM, Scott Leibrand > wrote: > Quoting myself: > >> 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. > > > Do you know of any organizations transferring blocks larger than a /24 for whom officer-attested justification is burdensome (to them or to ARIN)? > > Scott > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =============================================== > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Mon Jan 22 18:35:50 2018 From: owen at delong.com (Owen DeLong) Date: Mon, 22 Jan 2018 15:35:50 -0800 Subject: [arin-ppml] Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers In-Reply-To: References: <37CC78F2-D908-44A6-A75F-22B84CAD9E76@delong.com> <7AB0967C-2CE4-4878-A76C-85A3D5E50CCC@gmail.com> Message-ID: <683F1314-A7E2-4E4B-9CB4-8CA4195BA964@delong.com> Fully support the direction you are now taking this. Owen > On Jan 20, 2018, at 9:16 AM, David Farmer wrote: > > I think the burden is the potential to have to rejustify an ISP's initial allocation when being fulfilled by transfer. The inconsistency seems inefficient and creates confusion; there appears to be support for eliminating the inconsistency. With slightly more support for changing section 8 to be consistent with section 4, rather than the other way around. > > On Thu, Jan 18, 2018 at 6:07 PM, Scott Leibrand > wrote: > Quoting myself: > >> 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. > > > Do you know of any organizations transferring blocks larger than a /24 for whom officer-attested justification is burdensome (to them or to ARIN)? > > Scott > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at arin.net Wed Jan 24 08:42:28 2018 From: info at arin.net (ARIN) Date: Wed, 24 Jan 2018 08:42:28 -0500 Subject: [arin-ppml] Revised - Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers Message-ID: The following has been revised: * Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers Revised text 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 in 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 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. Policy statement: Replace section 8.5.4; 8.5.4. Initial block Organizations without direct assignments or allocations from ARIN qualify for the transfer of an initial IPv4 block, a /24 for assignments or a /24 up to a /21 for allocations. Comments: Timetable for implementation: Immediate Anything Else: The ARIN 40 Policy Experience Report is available at; Slides: https://www.arin.net/vault/participate/meetings/reports/ARIN_40/PDF/PPM/sweeting-policy-experience.pdf Transcript: https://www.arin.net/vault/participate/meetings/reports/ARIN_40/ppm1_transcript.html#anchor_5 Video: https://www.youtube.com/watch?v=QVsfVMG_6fA Slides 10 - 13, located in the video from 6:30 to 8:30, are the relevant portion of the report, questions from the audience follow. From info at arin.net Wed Jan 24 08:46:11 2018 From: info at arin.net (ARIN) Date: Wed, 24 Jan 2018 08:46:11 -0500 Subject: [arin-ppml] Revised/Re-titled - Draft Policy ARIN-2017-8: Amend Community Networks Message-ID: <73e07de6-7271-2c1b-c1d6-0788c5d96c74@arin.net> The following has been revised and re-titled: * Draft Policy ARIN-2017-8: Amend Community Networks Revised text is below and can be found at: https://www.arin.net/policy/proposals/2017_8.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-8: Amend Community Networks Problem Statement: The Community Networks section of the NRPM has only been used once since implementation in January 2010. Proposal ARIN-2016-7, to increase the number of use cases, was abandoned by the Advisory Council due to lack of feedback. Proposal ARIN 2017-2, to remove all mention of community networks from NRPM met with opposition by the community. Many responded that the definition of "community network" was too narrow, which could be the reason for lack of uptake. In the discussion at ARIN 40, it was clear that more than just the definition of a community network needed revision and that community networks need to have allocations, not assignments. Additionally, community networks need to make reassignments to end-users in accordance with applicable policies. ?????? Policy statement: Replace section 2.11 with the following; 2.11 Community Network A community network is deployed, operated, and governed by its users, for the purpose of providing free or low-cost connectivity to the community it services. Users of the network or other volunteers must play a primary role in the governance of the organization, whereas other functions may be handled by either paid staff or volunteers. Rename section 6.5.9 and revise the last sentence as follows; 6.5.9. Community Network Allocations While community networks would normally be considered to be ISP type organizations under existing ARIN criteria, they tend to operate on much tighter budgets and often depend on volunteer labor. As a result, they tend to be much smaller and more communal in their organization rather than provider/customer relationships of commercial ISPs. This section seeks to provide a policy that is more friendly to those environments by allowing community network to receive a smaller allocation than other LIRs or commercial ISPs. Community networks may also qualify under section 6.5.2 as a regular LIR. Section 6.5.9.1 is not changing, but is included here for completeness; 6.5.9.1. Qualification Criteria To qualify under this section, a community network must demonstrate to ARIN's satisfaction that it meets the definition of a community network under section 2.11 of the NRPM. Replace section 6.5.9.2 and 6.5.9.3 with the following; 6.5.9.2. Allocation Size Community networks are eligible only to receive an allocation of /40 of IPv6 resources under this section. Community networks that wish to receive a larger initial allocation or any subsequent allocations must qualify as a regular LIR, see sections 6.5.2 or 6.5.3 respectively. 6.5.9.3. Reassignments by Community Networks Similar to other LIRs, Community networks shall make reassignments to end-users in accordance with applicable policies, in particular, but not limited to sections 6.5.4 and 6.5.5. However, they shall not reallocate resources under this section. Comments: Timetable for implementation: Immediate Anything Else: The rationale for restricting community networks that receive resources through this policy from making reallocations is that a /40 is a tiny IPv6 allocation and it does not seem reasonable to subdivide such a small allocation into even smaller reallocations. Also, the recommended size for reassignment is /48, to even the smallest end-users, and therefore a /40 only provides 256 such reassignments. If a community network needs to make reallocations, maybe to other cooperating community networks in their area, they should apply as, or become, a regular LIR. As the smallest regular LIR, they would get a /36, allowing more than sufficient room to subdivide the allocation into several reasonable sized reallocations as necessary. From jschiller at google.com Wed Jan 24 10:17:36 2018 From: jschiller at google.com (Jason Schiller) Date: Wed, 24 Jan 2018 10:17:36 -0500 Subject: [arin-ppml] Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers In-Reply-To: <683F1314-A7E2-4E4B-9CB4-8CA4195BA964@delong.com> References: <37CC78F2-D908-44A6-A75F-22B84CAD9E76@delong.com> <7AB0967C-2CE4-4878-A76C-85A3D5E50CCC@gmail.com> <683F1314-A7E2-4E4B-9CB4-8CA4195BA964@delong.com> Message-ID: I oppose. 2016-4 was an attempt to replace the slow-start boot strap of get a /24 (or more) from your upstream, put it into use, then use that to qualify to get your own IP space from ARIN. The transfer slow-start boot strapping is to give the first /24 with no justification, put it to use, then double (just as you did under slow start). Essentially changing this to a /21 allows roughly 80% of ARIN members to be able to get all the IPv4 address space they could even need with no justification if they are willing to call themselves an ISP, and pay the appropriate fees. I oppose a non-needs based (or simply put a money based) justification system on the grounds that does not provide IP addresses to those who need them, but rather to those who are more willing to spend, favoring services that generate the most revenue per IP. I even more strongly oppose a non-needs based justification that only benifits some small portion of the community. This proposal is essentially a non-needs based justification for anyone who needs a /21 or less and is willing to pay an extra $400 annually for up to a /22 or, and extra $900 annually for up to a /21. Under NRPM version 2016.2 - 13 July 2016 https://www.arin.net/vault/policy/archive/nrpm_20160713.pdf For an ISP request for ARIN IP space, 4.2.2.1.1 required them to show utilization of currently held IPv4 space. 1. They could use the utilization of their provider's /24 along with the promise of renumbering to justify getting their own /24 An ISP could meet the 4.2.2.1.1 demonstration of utilization and get additional space by showing the 3 month growth projection under 4.2.2.1.3. (replacing their provider supplied addressing can be included in the ask if they promose to return under 4.2.2.1.4) Or doubling under slow start 4.2.1.4. 2016-4 came along to remove the need to get IPs from your upstream. https://www.arin.net/policy/proposals/2016_4.html Replace Section 4.2.2 with: 4.2.2. Initial allocation to ISPs "All ISP organizations without direct assignments or allocations from ARIN qualify for an initial allocation of up to a /21, subject to ARIN's minimum allocation size. Organizations may qualify for a larger initial allocation by documenting how the requested allocation will be utilized within 24 months for specified transfers, or three months otherwise. ISPs renumbering out of their previous address space will be given a reasonable amount of time to do so, and any blocks they are returning will not count against their utilization." At that time the difference between ARIN IP space was a 90 day supply versus a two tear supply on the transfer market. It also seemingly removed the following sections: 4.2.2.1. ISP Requirements 4.2.2.1.1. Use of /24 4.2.2.1.2. Efficient Utilization 4.2.2.1.3. Three Months 4.2.2.1.4. Renumber and Return It was my impression that ARIN would not issue a /21 if it was more than a 90 day supply. 2016-2 came along and changes the time frame to sync pre-approval for transfers and approval for the waiting list. It seeming updates the non-existant section 4.2.2.1.3 from 3 months to 24. and 4.2.4.3 to 24 months. This is what creates the problem where now an initial ISP can request a /21 without requiring I do not believe the intent was to give ISPs a /21 even if it is larger than a, then 90 day, or now two year supply. I suggest that if more than a /24 is desired, they can get up to a /21 if it is less than a 2 year supply, and subsequently need to show utilization. That means a /21 is not entirely justification free like the /24 is. __Jason On Mon, Jan 22, 2018 at 6:35 PM, Owen DeLong wrote: > Fully support the direction you are now taking this. > > Owen > > On Jan 20, 2018, at 9:16 AM, David Farmer wrote: > > I think the burden is the potential to have to rejustify an ISP's initial > allocation when being fulfilled by transfer. The > inconsistency seems inefficient and creates confusion; there appears to > be support for eliminating the inconsistency. With slightly more support > for changing section 8 to be consistent with section 4, rather than the > other way around. > > On Thu, Jan 18, 2018 at 6:07 PM, Scott Leibrand > wrote: > >> Quoting myself: >> >> 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. >> >> >> Do you know of any organizations transferring blocks larger than a /24 >> for whom officer-attested justification is burdensome (to them or to ARIN)? >> >> Scott >> > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> > Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> > =============================================== > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Wed Jan 24 10:38:33 2018 From: owen at delong.com (Owen DeLong) Date: Wed, 24 Jan 2018 07:38:33 -0800 Subject: [arin-ppml] Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers In-Reply-To: References: <37CC78F2-D908-44A6-A75F-22B84CAD9E76@delong.com> <7AB0967C-2CE4-4878-A76C-85A3D5E50CCC@gmail.com> <683F1314-A7E2-4E4B-9CB4-8CA4195BA964@delong.com> Message-ID: <44111583-2D5A-4B9B-AEE8-2E8521B7C0DC@delong.com> While there?s some truth to that, it was also the reality under which we operated when that /21 was coming from the free pool rather than from the transfer market. Admittedly, the price penalty was a bit higher because that was under an older fee structure which had higher prices for ISPs, but, as the old Churchill joke ends? ?Madam, the first question established what you are, now we are merely haggling over price.? So, given that, do you really believe we need to place additional limits on transfers that didn?t exist on the free pool? Also, even with the /24 limit, under current policy, they can immediately turn around, claim they?ve used that /24 and with officer attestation get an additional /23, then turn around again and get an additional /22 which would leave them only 1 /24 short of a /21 (which they could turn around and immediately obtain unto an additional /21 under the same policy). So we essentially already allow this transaction, but the question is how many hoops do we want to add to the process. I?m usually the one on the other side of this argument, but under the current circumstances, even I think it?s kind of silly. Owen > On Jan 24, 2018, at 7:17 AM, Jason Schiller wrote: > > I oppose. > > 2016-4 was an attempt to replace the slow-start boot strap of get a /24 (or more) > from your upstream, put it into use, then use that to qualify to get your own IP space from ARIN. > > The transfer slow-start boot strapping is to give the first /24 with no justification, > put it to use, then double (just as you did under slow start). > > Essentially changing this to a /21 allows roughly 80% of ARIN members > to be able to get all the IPv4 address space they could even need with > no justification if they are willing to call themselves an ISP, and pay the > appropriate fees. > > I oppose a non-needs based (or simply put a money based) justification > system on the grounds that does not provide IP addresses to those who need > them, but rather to those who are more willing to spend, favoring services that > generate the most revenue per IP. > > I even more strongly oppose a non-needs based justification that only benifits > some small portion of the community. This proposal is essentially a non-needs > based justification for anyone who needs a /21 or less and is willing to pay an > extra $400 annually for up to a /22 or, and extra $900 annually for up to a /21. > > > Under NRPM version 2016.2 - 13 July 2016 > https://www.arin.net/vault/policy/archive/nrpm_20160713.pdf > > For an ISP request for ARIN IP space, 4.2.2.1.1 required them to > show utilization of currently held IPv4 space. > > 1. They could use the utilization of their provider's /24 along with > the promise of renumbering to justify getting their own /24 > > An ISP could meet the 4.2.2.1.1 demonstration of utilization and > get additional space by showing the 3 month growth projection under > 4.2.2.1.3. > > (replacing their provider supplied addressing can be > included in the ask if they promose to return under 4.2.2.1.4) > > Or doubling under slow start 4.2.1.4. > > > 2016-4 came along to remove the need to get IPs from your upstream. > > https://www.arin.net/policy/proposals/2016_4.html > > > Replace Section 4.2.2 with: > > 4.2.2. Initial allocation to ISPs > > "All ISP organizations without direct assignments or allocations from ARIN > qualify for an initial allocation of up to a /21, subject to ARIN's > minimum allocation size. Organizations may qualify for a larger initial > allocation by documenting how the requested allocation will be utilized > within 24 months for specified transfers, or three months otherwise. > ISPs renumbering out of their previous address space will be given a > reasonable amount of time to do so, and any blocks they are returning > will not count against their utilization." > > At that time the difference between ARIN IP space was a 90 day supply > versus a two tear supply on the transfer market. > > It also seemingly removed the following sections: > 4.2.2.1. ISP Requirements > 4.2.2.1.1. Use of /24 > 4.2.2.1.2. Efficient Utilization > 4.2.2.1.3. Three Months > 4.2.2.1.4. Renumber and Return > > It was my impression that ARIN would not issue a /21 if it was more than a 90 day > supply. > > 2016-2 came along and changes the time frame to sync pre-approval for transfers > and approval for the waiting list. > > It seeming updates the non-existant section 4.2.2.1.3 from 3 months to 24. > and 4.2.4.3 to 24 months. > > This is what creates the problem where now an initial ISP can request a /21 > without requiring > > I do not believe the intent was to give ISPs a /21 even if it is larger than a, then > 90 day, or now two year supply. I suggest that if more than a /24 is desired, they can get up > to a /21 if it is less than a 2 year supply, and subsequently need to show utilization. > That means a /21 is not entirely justification free like the /24 is. > > __Jason > > > > > > > On Mon, Jan 22, 2018 at 6:35 PM, Owen DeLong > wrote: > Fully support the direction you are now taking this. > > Owen > >> On Jan 20, 2018, at 9:16 AM, David Farmer > wrote: >> >> I think the burden is the potential to have to rejustify an ISP's initial allocation when being fulfilled by transfer. The inconsistency seems inefficient and creates confusion; there appears to be support for eliminating the inconsistency. With slightly more support for changing section 8 to be consistent with section 4, rather than the other way around. >> >> On Thu, Jan 18, 2018 at 6:07 PM, Scott Leibrand > wrote: >> Quoting myself: >> >>> 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. >> >> >> Do you know of any organizations transferring blocks larger than a /24 for whom officer-attested justification is burdensome (to them or to ARIN)? >> >> Scott >> >> -- >> =============================================== >> David Farmer Email:farmer at umn.edu >> Networking & Telecommunication Services >> Office of Information Technology >> University of Minnesota >> 2218 University Ave SE Phone: 612-626-0815 >> Minneapolis, MN 55414-3029 Cell: 612-812-9952 >> =============================================== > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > > > -- > _______________________________________________________ > Jason Schiller|NetOps|jschiller at google.com |571-266-0006 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jschiller at google.com Wed Jan 24 13:06:12 2018 From: jschiller at google.com (Jason Schiller) Date: Wed, 24 Jan 2018 13:06:12 -0500 Subject: [arin-ppml] Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers In-Reply-To: <44111583-2D5A-4B9B-AEE8-2E8521B7C0DC@delong.com> References: <37CC78F2-D908-44A6-A75F-22B84CAD9E76@delong.com> <7AB0967C-2CE4-4878-A76C-85A3D5E50CCC@gmail.com> <683F1314-A7E2-4E4B-9CB4-8CA4195BA964@delong.com> <44111583-2D5A-4B9B-AEE8-2E8521B7C0DC@delong.com> Message-ID: ARIN staff, After the implementation of 2009-8 and post IANA IPv4 depletion (say 02/03/2011) If an ISP wanted more than a 90 day supply would that have been limited to only a 90 day supply? Is that because of both: 4.2.4.3. Subscriber Members Less Than One Year 4.2.4.4. Subscriber Members After One Year ? Does that also apply to an ISP asking for IP space 4.2.1.6. Immediate Need? Does that also apply to an ISP asking for IP space 4.2.1.4. Slow start? Does this also apply to ISP asking for IP space under 4.2.2. Initial allocation to ISPs? After the implementation of 2013-7 (say September 2014) Did any of this change? Did 4.2.4.3 Request size simply replace 4.2.4.3 and 4.2.4.4 and do essentially the same limit? After the implementation of 2016-4 (say March 2017) Did any of this change? Is that because of 4.2.4.3 Request size still limits the maximum an ISP can get? Then after 2016-2 (say April 20, 2017) Would all of the above change to a 2 year supply? Owen, responses in line __Jason On Wed, Jan 24, 2018 at 10:38 AM, Owen DeLong wrote: > While there?s some truth to that, it was also the reality under which we > operated when that /21 was coming from the free pool rather than from the > transfer market. > > Admittedly, the price penalty was a bit higher because that was under an > older fee structure which had higher prices for ISPs, but, as the old > Churchill joke ends? ?Madam, the first question established what you are, > now we are merely haggling over price.? > > So, given that, do you really believe we need to place additional limits > on transfers that didn?t exist on the free pool? > I don't believe this limit is new or additional... My understanding of the policy that existed between 09/18/2012 and 04/20/2017 was that an ISP could only get a 3 month supply of addresses. This was established under 2009-8 (01/13/2010 and triggered 02/03/2011) and modified by 2016-2 (04/20/2017) https://www.arin.net/vault/announcements/2011/20110203.html https://www.arin.net/resources/request/ipv4_countdown_plan.html Post 04/20/2017, and ISP can only get a 2 year supply. I believe you need to show that the initial /21 you are asking for is a 90 day supply or less during the 09/2010-04/2012 time period, which subsequently reverted to a two year window. Hopefully staff questions above will clarify this. At the very least it was never my expectation that passing 2016-4 would exclude the initial /21 from needing to meet the requirement of 4.2.2.1.3. Three Months. > > Also, even with the /24 limit, under current policy, they can immediately > turn around, claim they?ve used that /24 and with officer attestation get > an additional /23, then turn around again and get an additional /22 which > would leave them only 1 /24 short of a /21 (which they could turn around > and immediately obtain unto an additional /21 under the same policy). So we > essentially already allow this transaction, but the question is how many > hoops do we want to add to the process. > > Assuming there is no fraud in the transaction you describe, then they would essentially be doing slow start. Get a block press it into service, show it is being used, and double. That is exactly how it is supposed to work. That is exactly what we did under slow start with no history of use: 1. get a /24 (or more up to a /21 from an upstream) show it is being used, 2. trade it out for ARIN space that replaces, and doubles the size 3. re number into the new space 4. press the unused new space into service 5. double you previous allocation if you do it in less than half the 90 day window 6. get the same size as your previous allocation if you do it in less that 90 days 7. fall back to a smaller next allocation if you do it in more than 90 days. The transfer version is more liberal in that it allows a straight doubling of all your holdings as opposed to only your last allocation doubling, and there is no time horizon, you can double even if it take you 3 years to press your address space into service. So, less silly than slow start with a 1 year window, and much less silly than slow start with a 3 month window. > I?m usually the one on the other side of this argument, but under the > current circumstances, even I think it?s kind of silly. > > What am I missing? What is so silly with this approach? > Owen > > On Jan 24, 2018, at 7:17 AM, Jason Schiller wrote: > > I oppose. > > 2016-4 was an attempt to replace the slow-start boot strap of get a /24 > (or more) > from your upstream, put it into use, then use that to qualify to get your > own IP space from ARIN. > > The transfer slow-start boot strapping is to give the first /24 with no > justification, > put it to use, then double (just as you did under slow start). > > Essentially changing this to a /21 allows roughly 80% of ARIN members > to be able to get all the IPv4 address space they could even need with > no justification if they are willing to call themselves an ISP, and pay > the > appropriate fees. > > I oppose a non-needs based (or simply put a money based) justification > system on the grounds that does not provide IP addresses to those who need > them, but rather to those who are more willing to spend, favoring services > that > generate the most revenue per IP. > > I even more strongly oppose a non-needs based justification that only > benifits > some small portion of the community. This proposal is essentially a > non-needs > based justification for anyone who needs a /21 or less and is willing to > pay an > extra $400 annually for up to a /22 or, and extra $900 annually for up to > a /21. > > > Under NRPM version 2016.2 - 13 July 2016 > https://www.arin.net/vault/policy/archive/nrpm_20160713.pdf > > For an ISP request for ARIN IP space, 4.2.2.1.1 required them to > show utilization of currently held IPv4 space. > > 1. They could use the utilization of their provider's /24 along with > the promise of renumbering to justify getting their own /24 > > An ISP could meet the 4.2.2.1.1 demonstration of utilization and > get additional space by showing the 3 month growth projection under > 4.2.2.1.3. > > (replacing their provider supplied addressing can be > included in the ask if they promose to return under 4.2.2.1.4) > > Or doubling under slow start 4.2.1.4. > > > 2016-4 came along to remove the need to get IPs from your upstream. > > https://www.arin.net/policy/proposals/2016_4.html > > > Replace Section 4.2.2 with: > > 4.2.2. Initial allocation to ISPs > > "All ISP organizations without direct assignments or allocations from ARIN > qualify for an initial allocation of up to a /21, subject to ARIN's > minimum allocation size. Organizations may qualify for a larger initial > allocation by documenting how the requested allocation will be utilized > within 24 months for specified transfers, or three months otherwise. > ISPs renumbering out of their previous address space will be given a > reasonable amount of time to do so, and any blocks they are returning > will not count against their utilization." > > At that time the difference between ARIN IP space was a 90 day supply > versus a two tear supply on the transfer market. > > It also seemingly removed the following sections: > 4.2.2.1. ISP Requirements > 4.2.2.1.1. Use of /24 > 4.2.2.1.2. Efficient Utilization > 4.2.2.1.3. Three Months > 4.2.2.1.4. Renumber and Return > > It was my impression that ARIN would not issue a /21 if it was more than a > 90 day > supply. > > 2016-2 came along and changes the time frame to sync pre-approval for > transfers > and approval for the waiting list. > > It seeming updates the non-existant section 4.2.2.1.3 from 3 months to 24. > and 4.2.4.3 to 24 months. > > This is what creates the problem where now an initial ISP can request a /21 > without requiring > > I do not believe the intent was to give ISPs a /21 even if it is larger > than a, then > 90 day, or now two year supply. I suggest that if more than a /24 is > desired, they can get up > to a /21 if it is less than a 2 year supply, and subsequently need to show > utilization. > That means a /21 is not entirely justification free like the /24 is. > > __Jason > > > > > > > On Mon, Jan 22, 2018 at 6:35 PM, Owen DeLong wrote: > >> Fully support the direction you are now taking this. >> >> Owen >> >> On Jan 20, 2018, at 9:16 AM, David Farmer wrote: >> >> I think the burden is the potential to have to rejustify an ISP's initial >> allocation when being fulfilled by transfer. The >> inconsistency seems inefficient and creates confusion; there appears to >> be support for eliminating the inconsistency. With slightly more support >> for changing section 8 to be consistent with section 4, rather than the >> other way around. >> >> On Thu, Jan 18, 2018 at 6:07 PM, Scott Leibrand >> wrote: >> >>> Quoting myself: >>> >>> 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. >>> >>> >>> Do you know of any organizations transferring blocks larger than a /24 >>> for whom officer-attested justification is burdensome (to them or to ARIN)? >>> >>> Scott >>> >> >> -- >> =============================================== >> David Farmer Email:farmer at umn.edu >> Networking & Telecommunication Services >> Office of Information Technology >> University of Minnesota >> 2218 University Ave SE >> >> Phone: 612-626-0815 <(612)%20626-0815> >> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> >> =============================================== >> >> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> > > > > -- > _______________________________________________________ > Jason Schiller|NetOps|jschiller at google.com|571-266-0006 <(571)%20266-0006> > > > -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Wed Jan 24 13:14:01 2018 From: jcurran at arin.net (John Curran) Date: Wed, 24 Jan 2018 18:14:01 +0000 Subject: [arin-ppml] Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers In-Reply-To: References: <37CC78F2-D908-44A6-A75F-22B84CAD9E76@delong.com> <7AB0967C-2CE4-4878-A76C-85A3D5E50CCC@gmail.com> <683F1314-A7E2-4E4B-9CB4-8CA4195BA964@delong.com> Message-ID: <4A9C5998-DBF8-495E-8590-26088F41A646@arin.net> On 24 Jan 2018, at 5:17 AM, Jason Schiller wrote: > ... > Essentially changing this to a /21 allows roughly 80% of ARIN members > to be able to get all the IPv4 address space they could even need with > no justification if they are willing to call themselves an ISP, and pay the > appropriate fees. > > I oppose a non-needs based (or simply put a money based) justification > system on the grounds that does not provide IP addresses to those who need > them, but rather to those who are more willing to spend, favoring services that > generate the most revenue per IP. Jason - The ability to obtain IPv4 address space from the transfer market will always be inherently biased towards those willing to pay more ? i.e. the condition you object to exists and will remain regardless of the initial block size. To the extent that the initial block size is limited, it is also likely that smaller entities will be prevented from obtaining an initial block sufficient to carry them through to the industry IPv6 transition, and instead require they risk unknown market conditions several years out to receive one or more additional blocks. It might be helpful to hear from some smaller entities about how they feel about this particular tradeoff, as each organization has its own perspective on future risk tolerance; i.e. it could be material or a non-issue, and hence important to hear from the community on this aspect. Thanks, /John John Curran President and CEO ARIN From jcurran at arin.net Wed Jan 24 13:17:24 2018 From: jcurran at arin.net (John Curran) Date: Wed, 24 Jan 2018 18:17:24 +0000 Subject: [arin-ppml] Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers In-Reply-To: References: <37CC78F2-D908-44A6-A75F-22B84CAD9E76@delong.com> <7AB0967C-2CE4-4878-A76C-85A3D5E50CCC@gmail.com> <683F1314-A7E2-4E4B-9CB4-8CA4195BA964@delong.com> <44111583-2D5A-4B9B-AEE8-2E8521B7C0DC@delong.com> Message-ID: <1E8D9EA9-FE50-48A5-B0DD-C86C7B73F44C@arin.net> Jason - Your query below is with regard to ARIN allocations from the free pool, or with regard to approval of the transfer of IPv4 number resources? /John On 24 Jan 2018, at 8:06 AM, Jason Schiller > wrote: ARIN staff, After the implementation of 2009-8 and post IANA IPv4 depletion (say 02/03/2011) If an ISP wanted more than a 90 day supply would that have been limited to only a 90 day supply? Is that because of both: 4.2.4.3. Subscriber Members Less Than One Year 4.2.4.4. Subscriber Members After One Year ? Does that also apply to an ISP asking for IP space 4.2.1.6. Immediate Need? Does that also apply to an ISP asking for IP space 4.2.1.4. Slow start? Does this also apply to ISP asking for IP space under 4.2.2. Initial allocation to ISPs? After the implementation of 2013-7 (say September 2014) Did any of this change? Did 4.2.4.3 Request size simply replace 4.2.4.3 and 4.2.4.4 and do essentially the same limit? After the implementation of 2016-4 (say March 2017) Did any of this change? Is that because of 4.2.4.3 Request size still limits the maximum an ISP can get? Then after 2016-2 (say April 20, 2017) Would all of the above change to a 2 year supply? Owen, responses in line __Jason On Wed, Jan 24, 2018 at 10:38 AM, Owen DeLong > wrote: While there?s some truth to that, it was also the reality under which we operated when that /21 was coming from the free pool rather than from the transfer market. Admittedly, the price penalty was a bit higher because that was under an older fee structure which had higher prices for ISPs, but, as the old Churchill joke ends? ?Madam, the first question established what you are, now we are merely haggling over price.? So, given that, do you really believe we need to place additional limits on transfers that didn?t exist on the free pool? I don't believe this limit is new or additional... My understanding of the policy that existed between 09/18/2012 and 04/20/2017 was that an ISP could only get a 3 month supply of addresses. This was established under 2009-8 (01/13/2010 and triggered 02/03/2011) and modified by 2016-2 (04/20/2017) https://www.arin.net/vault/announcements/2011/20110203.html https://www.arin.net/resources/request/ipv4_countdown_plan.html Post 04/20/2017, and ISP can only get a 2 year supply. I believe you need to show that the initial /21 you are asking for is a 90 day supply or less during the 09/2010-04/2012 time period, which subsequently reverted to a two year window. Hopefully staff questions above will clarify this. At the very least it was never my expectation that passing 2016-4 would exclude the initial /21 from needing to meet the requirement of 4.2.2.1.3. Three Months. Also, even with the /24 limit, under current policy, they can immediately turn around, claim they?ve used that /24 and with officer attestation get an additional /23, then turn around again and get an additional /22 which would leave them only 1 /24 short of a /21 (which they could turn around and immediately obtain unto an additional /21 under the same policy). So we essentially already allow this transaction, but the question is how many hoops do we want to add to the process. Assuming there is no fraud in the transaction you describe, then they would essentially be doing slow start. Get a block press it into service, show it is being used, and double. That is exactly how it is supposed to work. That is exactly what we did under slow start with no history of use: 1. get a /24 (or more up to a /21 from an upstream) show it is being used, 2. trade it out for ARIN space that replaces, and doubles the size 3. re number into the new space 4. press the unused new space into service 5. double you previous allocation if you do it in less than half the 90 day window 6. get the same size as your previous allocation if you do it in less that 90 days 7. fall back to a smaller next allocation if you do it in more than 90 days. The transfer version is more liberal in that it allows a straight doubling of all your holdings as opposed to only your last allocation doubling, and there is no time horizon, you can double even if it take you 3 years to press your address space into service. So, less silly than slow start with a 1 year window, and much less silly than slow start with a 3 month window. I?m usually the one on the other side of this argument, but under the current circumstances, even I think it?s kind of silly. What am I missing? What is so silly with this approach? Owen On Jan 24, 2018, at 7:17 AM, Jason Schiller > wrote: I oppose. 2016-4 was an attempt to replace the slow-start boot strap of get a /24 (or more) from your upstream, put it into use, then use that to qualify to get your own IP space from ARIN. The transfer slow-start boot strapping is to give the first /24 with no justification, put it to use, then double (just as you did under slow start). Essentially changing this to a /21 allows roughly 80% of ARIN members to be able to get all the IPv4 address space they could even need with no justification if they are willing to call themselves an ISP, and pay the appropriate fees. I oppose a non-needs based (or simply put a money based) justification system on the grounds that does not provide IP addresses to those who need them, but rather to those who are more willing to spend, favoring services that generate the most revenue per IP. I even more strongly oppose a non-needs based justification that only benifits some small portion of the community. This proposal is essentially a non-needs based justification for anyone who needs a /21 or less and is willing to pay an extra $400 annually for up to a /22 or, and extra $900 annually for up to a /21. Under NRPM version 2016.2 - 13 July 2016 https://www.arin.net/vault/policy/archive/nrpm_20160713.pdf For an ISP request for ARIN IP space, 4.2.2.1.1 required them to show utilization of currently held IPv4 space. 1. They could use the utilization of their provider's /24 along with the promise of renumbering to justify getting their own /24 An ISP could meet the 4.2.2.1.1 demonstration of utilization and get additional space by showing the 3 month growth projection under 4.2.2.1.3. (replacing their provider supplied addressing can be included in the ask if they promose to return under 4.2.2.1.4) Or doubling under slow start 4.2.1.4. 2016-4 came along to remove the need to get IPs from your upstream. https://www.arin.net/policy/proposals/2016_4.html Replace Section 4.2.2 with: 4.2.2. Initial allocation to ISPs "All ISP organizations without direct assignments or allocations from ARIN qualify for an initial allocation of up to a /21, subject to ARIN's minimum allocation size. Organizations may qualify for a larger initial allocation by documenting how the requested allocation will be utilized within 24 months for specified transfers, or three months otherwise. ISPs renumbering out of their previous address space will be given a reasonable amount of time to do so, and any blocks they are returning will not count against their utilization." At that time the difference between ARIN IP space was a 90 day supply versus a two tear supply on the transfer market. It also seemingly removed the following sections: 4.2.2.1. ISP Requirements 4.2.2.1.1. Use of /24 4.2.2.1.2. Efficient Utilization 4.2.2.1.3. Three Months 4.2.2.1.4. Renumber and Return It was my impression that ARIN would not issue a /21 if it was more than a 90 day supply. 2016-2 came along and changes the time frame to sync pre-approval for transfers and approval for the waiting list. It seeming updates the non-existant section 4.2.2.1.3 from 3 months to 24. and 4.2.4.3 to 24 months. This is what creates the problem where now an initial ISP can request a /21 without requiring I do not believe the intent was to give ISPs a /21 even if it is larger than a, then 90 day, or now two year supply. I suggest that if more than a /24 is desired, they can get up to a /21 if it is less than a 2 year supply, and subsequently need to show utilization. That means a /21 is not entirely justification free like the /24 is. __Jason On Mon, Jan 22, 2018 at 6:35 PM, Owen DeLong > wrote: Fully support the direction you are now taking this. Owen On Jan 20, 2018, at 9:16 AM, David Farmer > wrote: I think the burden is the potential to have to rejustify an ISP's initial allocation when being fulfilled by transfer. The inconsistency seems inefficient and creates confusion; there appears to be support for eliminating the inconsistency. With slightly more support for changing section 8 to be consistent with section 4, rather than the other way around. On Thu, Jan 18, 2018 at 6:07 PM, Scott Leibrand > wrote: Quoting myself: 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. Do you know of any organizations transferring blocks larger than a /24 for whom officer-attested justification is burdensome (to them or to ARIN)? Scott -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jschiller at google.com Wed Jan 24 14:38:36 2018 From: jschiller at google.com (Jason Schiller) Date: Wed, 24 Jan 2018 14:38:36 -0500 Subject: [arin-ppml] Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers In-Reply-To: <1E8D9EA9-FE50-48A5-B0DD-C86C7B73F44C@arin.net> References: <37CC78F2-D908-44A6-A75F-22B84CAD9E76@delong.com> <7AB0967C-2CE4-4878-A76C-85A3D5E50CCC@gmail.com> <683F1314-A7E2-4E4B-9CB4-8CA4195BA964@delong.com> <44111583-2D5A-4B9B-AEE8-2E8521B7C0DC@delong.com> <1E8D9EA9-FE50-48A5-B0DD-C86C7B73F44C@arin.net> Message-ID: >From the free pool (assuming we had one or the waitlist) ___Jason On Wed, Jan 24, 2018 at 1:17 PM, John Curran wrote: > Jason - > > Your query below is with regard to ARIN allocations from the free pool, > or with regard to approval of the transfer of IPv4 number resources? > > /John > > > On 24 Jan 2018, at 8:06 AM, Jason Schiller wrote: > > ARIN staff, > > After the implementation of 2009-8 > and post IANA IPv4 depletion > (say 02/03/2011) > > If an ISP wanted more than a 90 day supply would > that have been limited to only a 90 day supply? > Is that because of both: > 4.2.4.3. Subscriber Members Less Than One Year > 4.2.4.4. Subscriber Members After One Year ? > > > Does that also apply to an ISP asking for IP space > 4.2.1.6. Immediate Need? > > Does that also apply to an ISP asking for IP space > 4.2.1.4. Slow start? > > Does this also apply to ISP asking for IP space > under 4.2.2. Initial allocation to ISPs? > > > After the implementation of 2013-7 > (say September 2014) > > Did any of this change? > > Did 4.2.4.3 Request size simply > replace 4.2.4.3 and 4.2.4.4 and > do essentially the same limit? > > After the implementation of 2016-4 > (say March 2017) > > Did any of this change? > Is that because of 4.2.4.3 Request size > still limits the maximum an ISP can get? > > Then after 2016-2 > (say April 20, 2017) > > Would all of the above change to a 2 year supply? > > > Owen, > > responses in line > > __Jason > > On Wed, Jan 24, 2018 at 10:38 AM, Owen DeLong wrote: > >> While there?s some truth to that, it was also the reality under which we >> operated when that /21 was coming from the free pool rather than from the >> transfer market. >> >> Admittedly, the price penalty was a bit higher because that was under an >> older fee structure which had higher prices for ISPs, but, as the old >> Churchill joke ends? ?Madam, the first question established what you are, >> now we are merely haggling over price.? >> >> So, given that, do you really believe we need to place additional limits >> on transfers that didn?t exist on the free pool? >> > > I don't believe this limit is new or additional... > My understanding of the policy that existed between 09/18/2012 and > 04/20/2017 > was that an ISP could only get a 3 month supply of addresses. > > This was established under 2009-8 (01/13/2010 and triggered 02/03/2011) > and modified by 2016-2 (04/20/2017) > > https://www.arin.net/vault/announcements/2011/20110203.html > https://www.arin.net/resources/request/ipv4_countdown_plan.html > > Post 04/20/2017, and ISP can only get a 2 year supply. > > I believe you need to show that the initial /21 you are asking for is a > 90 day supply or less during the 09/2010-04/2012 time period, which > subsequently reverted to a two year window. > > Hopefully staff questions above will clarify this. > > At the very least it was never my expectation that passing 2016-4 > would exclude the initial /21 from needing to meet the requirement > of 4.2.2.1.3. Three Months. > > >> >> Also, even with the /24 limit, under current policy, they can immediately >> turn around, claim they?ve used that /24 and with officer attestation get >> an additional /23, then turn around again and get an additional /22 which >> would leave them only 1 /24 short of a /21 (which they could turn around >> and immediately obtain unto an additional /21 under the same policy). So we >> essentially already allow this transaction, but the question is how many >> hoops do we want to add to the process. >> >> > Assuming there is no fraud in the transaction you describe, then > they would essentially be doing slow start. > Get a block press it into service, show it is being used, and double. > > That is exactly how it is supposed to work. > That is exactly what we did under slow start with no history of use: > 1. get a /24 (or more up to a /21 from an upstream) show it is being used, > 2. trade it out for ARIN space that replaces, and doubles the size > 3. re number into the new space > 4. press the unused new space into service > 5. double you previous allocation if you do it in less than half the 90 > day window > 6. get the same size as your previous allocation if you do it in less that > 90 days > 7. fall back to a smaller next allocation if you do it in more than 90 > days. > > The transfer version is more liberal in that it allows a straight doubling > of all > your holdings as opposed to only your last allocation doubling, and there > is > no time horizon, you can double even if it take you 3 years to press your > address space into service. > > So, less silly than slow start with a 1 year window, and much less silly > than > slow start with a 3 month window. > > > >> I?m usually the one on the other side of this argument, but under the >> current circumstances, even I think it?s kind of silly. >> >> > What am I missing? What is so silly with this approach? > > >> Owen >> >> On Jan 24, 2018, at 7:17 AM, Jason Schiller wrote: >> >> I oppose. >> >> 2016-4 was an attempt to replace the slow-start boot strap of get a /24 >> (or more) >> from your upstream, put it into use, then use that to qualify to get your >> own IP space from ARIN. >> >> The transfer slow-start boot strapping is to give the first /24 with no >> justification, >> put it to use, then double (just as you did under slow start). >> >> Essentially changing this to a /21 allows roughly 80% of ARIN members >> to be able to get all the IPv4 address space they could even need with >> no justification if they are willing to call themselves an ISP, and pay >> the >> appropriate fees. >> >> I oppose a non-needs based (or simply put a money based) justification >> system on the grounds that does not provide IP addresses to those who need >> them, but rather to those who are more willing to spend, favoring >> services that >> generate the most revenue per IP. >> >> I even more strongly oppose a non-needs based justification that only >> benifits >> some small portion of the community. This proposal is essentially a >> non-needs >> based justification for anyone who needs a /21 or less and is willing to >> pay an >> extra $400 annually for up to a /22 or, and extra $900 annually for up to >> a /21. >> >> >> Under NRPM version 2016.2 - 13 July 2016 >> https://www.arin.net/vault/policy/archive/nrpm_20160713.pdf >> >> For an ISP request for ARIN IP space, 4.2.2.1.1 required them to >> show utilization of currently held IPv4 space. >> >> 1. They could use the utilization of their provider's /24 along with >> the promise of renumbering to justify getting their own /24 >> >> An ISP could meet the 4.2.2.1.1 demonstration of utilization and >> get additional space by showing the 3 month growth projection under >> 4.2.2.1.3. >> >> (replacing their provider supplied addressing can be >> included in the ask if they promose to return under 4.2.2.1.4) >> >> Or doubling under slow start 4.2.1.4. >> >> >> 2016-4 came along to remove the need to get IPs from your upstream. >> >> https://www.arin.net/policy/proposals/2016_4.html >> >> >> Replace Section 4.2.2 with: >> >> 4.2.2. Initial allocation to ISPs >> >> "All ISP organizations without direct assignments or allocations from >> ARIN >> qualify for an initial allocation of up to a /21, subject to ARIN's >> minimum allocation size. Organizations may qualify for a larger initial >> allocation by documenting how the requested allocation will be utilized >> within 24 months for specified transfers, or three months otherwise. >> ISPs renumbering out of their previous address space will be given a >> reasonable amount of time to do so, and any blocks they are returning >> will not count against their utilization." >> >> At that time the difference between ARIN IP space was a 90 day supply >> versus a two tear supply on the transfer market. >> >> It also seemingly removed the following sections: >> 4.2.2.1. ISP Requirements >> 4.2.2.1.1. Use of /24 >> 4.2.2.1.2. Efficient Utilization >> 4.2.2.1.3. Three Months >> 4.2.2.1.4. Renumber and Return >> >> It was my impression that ARIN would not issue a /21 if it was more than >> a 90 day >> supply. >> >> 2016-2 came along and changes the time frame to sync pre-approval for >> transfers >> and approval for the waiting list. >> >> It seeming updates the non-existant section 4.2.2.1.3 from 3 months to 24. >> and 4.2.4.3 to 24 months. >> >> This is what creates the problem where now an initial ISP can request a >> /21 >> without requiring >> >> I do not believe the intent was to give ISPs a /21 even if it is larger >> than a, then >> 90 day, or now two year supply. I suggest that if more than a /24 is >> desired, they can get up >> to a /21 if it is less than a 2 year supply, and subsequently need to >> show utilization. >> That means a /21 is not entirely justification free like the /24 is. >> >> __Jason >> >> >> >> >> >> >> On Mon, Jan 22, 2018 at 6:35 PM, Owen DeLong wrote: >> >>> Fully support the direction you are now taking this. >>> >>> Owen >>> >>> On Jan 20, 2018, at 9:16 AM, David Farmer wrote: >>> >>> I think the burden is the potential to have to rejustify an ISP's >>> initial allocation when being fulfilled by transfer. The >>> inconsistency seems inefficient and creates confusion; there appears to >>> be support for eliminating the inconsistency. With slightly more support >>> for changing section 8 to be consistent with section 4, rather than the >>> other way around. >>> >>> On Thu, Jan 18, 2018 at 6:07 PM, Scott Leibrand >> > wrote: >>> >>>> Quoting myself: >>>> >>>> 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. >>>> >>>> >>>> Do you know of any organizations transferring blocks larger than a /24 >>>> for whom officer-attested justification is burdensome (to them or to ARIN)? >>>> >>>> Scott >>>> >>> >>> -- >>> =============================================== >>> David Farmer Email:farmer at umn.edu >>> Networking & Telecommunication Services >>> Office of Information Technology >>> University of Minnesota >>> 2218 University Ave SE >>> >>> Phone: 612-626-0815 <(612)%20626-0815> >>> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> >>> =============================================== >>> >>> >>> >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to >>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at arin.net if you experience any issues. >>> >> >> >> >> -- >> _______________________________________________________ >> Jason Schiller|NetOps|jschiller at google.com|571-266-0006 >> <(571)%20266-0006> >> >> >> > > > -- > _______________________________________________________ > Jason Schiller|NetOps|jschiller at google.com|571-266-0006 <(571)%20266-0006> > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > > -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Wed Jan 24 23:51:09 2018 From: jcurran at arin.net (John Curran) Date: Thu, 25 Jan 2018 04:51:09 +0000 Subject: [arin-ppml] Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers In-Reply-To: References: <37CC78F2-D908-44A6-A75F-22B84CAD9E76@delong.com> <7AB0967C-2CE4-4878-A76C-85A3D5E50CCC@gmail.com> <683F1314-A7E2-4E4B-9CB4-8CA4195BA964@delong.com> <44111583-2D5A-4B9B-AEE8-2E8521B7C0DC@delong.com> <1E8D9EA9-FE50-48A5-B0DD-C86C7B73F44C@arin.net> Message-ID: <25E9F785-ABD2-4CCC-9285-029798BCB884@arin.net> Jason - The policy in question is with regard to transfers, but the limitations that you are asking about are with regard to allocations from the free pool? Could you explain how the information sought is germane to the policy discussion regarding this proposed change to IPv4 transfer policy? Thanks! /John On 24 Jan 2018, at 9:38 AM, Jason Schiller > wrote: From the free pool (assuming we had one or the waitlist) ___Jason On Wed, Jan 24, 2018 at 1:17 PM, John Curran > wrote: Jason - Your query below is with regard to ARIN allocations from the free pool, or with regard to approval of the transfer of IPv4 number resources? /John On 24 Jan 2018, at 8:06 AM, Jason Schiller > wrote: ARIN staff, After the implementation of 2009-8 and post IANA IPv4 depletion (say 02/03/2011) If an ISP wanted more than a 90 day supply would that have been limited to only a 90 day supply? Is that because of both: 4.2.4.3. Subscriber Members Less Than One Year 4.2.4.4. Subscriber Members After One Year ? Does that also apply to an ISP asking for IP space 4.2.1.6. Immediate Need? Does that also apply to an ISP asking for IP space 4.2.1.4. Slow start? Does this also apply to ISP asking for IP space under 4.2.2. Initial allocation to ISPs? After the implementation of 2013-7 (say September 2014) Did any of this change? Did 4.2.4.3 Request size simply replace 4.2.4.3 and 4.2.4.4 and do essentially the same limit? After the implementation of 2016-4 (say March 2017) Did any of this change? Is that because of 4.2.4.3 Request size still limits the maximum an ISP can get? Then after 2016-2 (say April 20, 2017) Would all of the above change to a 2 year supply? Owen, responses in line __Jason On Wed, Jan 24, 2018 at 10:38 AM, Owen DeLong > wrote: While there?s some truth to that, it was also the reality under which we operated when that /21 was coming from the free pool rather than from the transfer market. Admittedly, the price penalty was a bit higher because that was under an older fee structure which had higher prices for ISPs, but, as the old Churchill joke ends? ?Madam, the first question established what you are, now we are merely haggling over price.? So, given that, do you really believe we need to place additional limits on transfers that didn?t exist on the free pool? I don't believe this limit is new or additional... My understanding of the policy that existed between 09/18/2012 and 04/20/2017 was that an ISP could only get a 3 month supply of addresses. This was established under 2009-8 (01/13/2010 and triggered 02/03/2011) and modified by 2016-2 (04/20/2017) https://www.arin.net/vault/announcements/2011/20110203.html https://www.arin.net/resources/request/ipv4_countdown_plan.html Post 04/20/2017, and ISP can only get a 2 year supply. I believe you need to show that the initial /21 you are asking for is a 90 day supply or less during the 09/2010-04/2012 time period, which subsequently reverted to a two year window. Hopefully staff questions above will clarify this. At the very least it was never my expectation that passing 2016-4 would exclude the initial /21 from needing to meet the requirement of 4.2.2.1.3. Three Months. Also, even with the /24 limit, under current policy, they can immediately turn around, claim they?ve used that /24 and with officer attestation get an additional /23, then turn around again and get an additional /22 which would leave them only 1 /24 short of a /21 (which they could turn around and immediately obtain unto an additional /21 under the same policy). So we essentially already allow this transaction, but the question is how many hoops do we want to add to the process. Assuming there is no fraud in the transaction you describe, then they would essentially be doing slow start. Get a block press it into service, show it is being used, and double. That is exactly how it is supposed to work. That is exactly what we did under slow start with no history of use: 1. get a /24 (or more up to a /21 from an upstream) show it is being used, 2. trade it out for ARIN space that replaces, and doubles the size 3. re number into the new space 4. press the unused new space into service 5. double you previous allocation if you do it in less than half the 90 day window 6. get the same size as your previous allocation if you do it in less that 90 days 7. fall back to a smaller next allocation if you do it in more than 90 days. The transfer version is more liberal in that it allows a straight doubling of all your holdings as opposed to only your last allocation doubling, and there is no time horizon, you can double even if it take you 3 years to press your address space into service. So, less silly than slow start with a 1 year window, and much less silly than slow start with a 3 month window. I?m usually the one on the other side of this argument, but under the current circumstances, even I think it?s kind of silly. What am I missing? What is so silly with this approach? Owen On Jan 24, 2018, at 7:17 AM, Jason Schiller > wrote: I oppose. 2016-4 was an attempt to replace the slow-start boot strap of get a /24 (or more) from your upstream, put it into use, then use that to qualify to get your own IP space from ARIN. The transfer slow-start boot strapping is to give the first /24 with no justification, put it to use, then double (just as you did under slow start). Essentially changing this to a /21 allows roughly 80% of ARIN members to be able to get all the IPv4 address space they could even need with no justification if they are willing to call themselves an ISP, and pay the appropriate fees. I oppose a non-needs based (or simply put a money based) justification system on the grounds that does not provide IP addresses to those who need them, but rather to those who are more willing to spend, favoring services that generate the most revenue per IP. I even more strongly oppose a non-needs based justification that only benifits some small portion of the community. This proposal is essentially a non-needs based justification for anyone who needs a /21 or less and is willing to pay an extra $400 annually for up to a /22 or, and extra $900 annually for up to a /21. Under NRPM version 2016.2 - 13 July 2016 https://www.arin.net/vault/policy/archive/nrpm_20160713.pdf For an ISP request for ARIN IP space, 4.2.2.1.1 required them to show utilization of currently held IPv4 space. 1. They could use the utilization of their provider's /24 along with the promise of renumbering to justify getting their own /24 An ISP could meet the 4.2.2.1.1 demonstration of utilization and get additional space by showing the 3 month growth projection under 4.2.2.1.3. (replacing their provider supplied addressing can be included in the ask if they promose to return under 4.2.2.1.4) Or doubling under slow start 4.2.1.4. 2016-4 came along to remove the need to get IPs from your upstream. https://www.arin.net/policy/proposals/2016_4.html Replace Section 4.2.2 with: 4.2.2. Initial allocation to ISPs "All ISP organizations without direct assignments or allocations from ARIN qualify for an initial allocation of up to a /21, subject to ARIN's minimum allocation size. Organizations may qualify for a larger initial allocation by documenting how the requested allocation will be utilized within 24 months for specified transfers, or three months otherwise. ISPs renumbering out of their previous address space will be given a reasonable amount of time to do so, and any blocks they are returning will not count against their utilization." At that time the difference between ARIN IP space was a 90 day supply versus a two tear supply on the transfer market. It also seemingly removed the following sections: 4.2.2.1. ISP Requirements 4.2.2.1.1. Use of /24 4.2.2.1.2. Efficient Utilization 4.2.2.1.3. Three Months 4.2.2.1.4. Renumber and Return It was my impression that ARIN would not issue a /21 if it was more than a 90 day supply. 2016-2 came along and changes the time frame to sync pre-approval for transfers and approval for the waiting list. It seeming updates the non-existant section 4.2.2.1.3 from 3 months to 24. and 4.2.4.3 to 24 months. This is what creates the problem where now an initial ISP can request a /21 without requiring I do not believe the intent was to give ISPs a /21 even if it is larger than a, then 90 day, or now two year supply. I suggest that if more than a /24 is desired, they can get up to a /21 if it is less than a 2 year supply, and subsequently need to show utilization. That means a /21 is not entirely justification free like the /24 is. __Jason On Mon, Jan 22, 2018 at 6:35 PM, Owen DeLong > wrote: Fully support the direction you are now taking this. Owen On Jan 20, 2018, at 9:16 AM, David Farmer > wrote: I think the burden is the potential to have to rejustify an ISP's initial allocation when being fulfilled by transfer. The inconsistency seems inefficient and creates confusion; there appears to be support for eliminating the inconsistency. With slightly more support for changing section 8 to be consistent with section 4, rather than the other way around. On Thu, Jan 18, 2018 at 6:07 PM, Scott Leibrand > wrote: Quoting myself: 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. Do you know of any organizations transferring blocks larger than a /24 for whom officer-attested justification is burdensome (to them or to ARIN)? Scott -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jschiller at google.com Thu Jan 25 10:17:56 2018 From: jschiller at google.com (Jason Schiller) Date: Thu, 25 Jan 2018 10:17:56 -0500 Subject: [arin-ppml] Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers In-Reply-To: <25E9F785-ABD2-4CCC-9285-029798BCB884@arin.net> References: <37CC78F2-D908-44A6-A75F-22B84CAD9E76@delong.com> <7AB0967C-2CE4-4878-A76C-85A3D5E50CCC@gmail.com> <683F1314-A7E2-4E4B-9CB4-8CA4195BA964@delong.com> <44111583-2D5A-4B9B-AEE8-2E8521B7C0DC@delong.com> <1E8D9EA9-FE50-48A5-B0DD-C86C7B73F44C@arin.net> <25E9F785-ABD2-4CCC-9285-029798BCB884@arin.net> Message-ID: The argument (as I understand it) is comparing justification required for a transfer vs for ARIN free pool. If ARIN does not permit a "no justification" approval for a transfer of a /21 under ISP initial allocation if they have no direct resources then, There are extra requirements on transfers that did not exist on getting that same approval for a /21 from the free pool. My understanding is that there is a restriction on the ISP initial allocation from the free pool. It was show that this is not more than a 90 day supply. We changed that to two years. My understanding is that ISPs with no direct IPv4 didn't get a free pass on the (then) 90 day restriction when asking for their initial /21. They got a free pass on demonstrating past utilization. They got a free pass on starting with slow start at larger than a /24 if they had some justification that something larger (up to a /21) was less than a 90 day supply. ___Jason On Wed, Jan 24, 2018 at 11:51 PM, John Curran wrote: > Jason - > > The policy in question is with regard to transfers, but the > limitations that you are asking about are with regard to allocations from > the free pool? > > Could you explain how the information sought is germane to the policy > discussion regarding this proposed change to IPv4 transfer policy? > > Thanks! > /John > > On 24 Jan 2018, at 9:38 AM, Jason Schiller wrote: > > From the free pool (assuming we had one or the waitlist) > > ___Jason > > On Wed, Jan 24, 2018 at 1:17 PM, John Curran wrote: > >> Jason - >> >> Your query below is with regard to ARIN allocations from the free >> pool, or with regard to approval of the transfer of IPv4 number resources? >> >> /John >> >> >> On 24 Jan 2018, at 8:06 AM, Jason Schiller wrote: >> >> ARIN staff, >> >> After the implementation of 2009-8 >> and post IANA IPv4 depletion >> (say 02/03/2011) >> >> If an ISP wanted more than a 90 day supply would >> that have been limited to only a 90 day supply? >> Is that because of both: >> 4.2.4.3. Subscriber Members Less Than One Year >> 4.2.4.4. Subscriber Members After One Year ? >> >> >> Does that also apply to an ISP asking for IP space >> 4.2.1.6. Immediate Need? >> >> Does that also apply to an ISP asking for IP space >> 4.2.1.4. Slow start? >> >> Does this also apply to ISP asking for IP space >> under 4.2.2. Initial allocation to ISPs? >> >> >> After the implementation of 2013-7 >> (say September 2014) >> >> Did any of this change? >> >> Did 4.2.4.3 Request size simply >> replace 4.2.4.3 and 4.2.4.4 and >> do essentially the same limit? >> >> After the implementation of 2016-4 >> (say March 2017) >> >> Did any of this change? >> Is that because of 4.2.4.3 Request size >> still limits the maximum an ISP can get? >> >> Then after 2016-2 >> (say April 20, 2017) >> >> Would all of the above change to a 2 year supply? >> >> >> Owen, >> >> responses in line >> >> __Jason >> >> On Wed, Jan 24, 2018 at 10:38 AM, Owen DeLong wrote: >> >>> While there?s some truth to that, it was also the reality under which we >>> operated when that /21 was coming from the free pool rather than from the >>> transfer market. >>> >>> Admittedly, the price penalty was a bit higher because that was under an >>> older fee structure which had higher prices for ISPs, but, as the old >>> Churchill joke ends? ?Madam, the first question established what you are, >>> now we are merely haggling over price.? >>> >>> So, given that, do you really believe we need to place additional limits >>> on transfers that didn?t exist on the free pool? >>> >> >> I don't believe this limit is new or additional... >> My understanding of the policy that existed between 09/18/2012 and >> 04/20/2017 >> was that an ISP could only get a 3 month supply of addresses. >> >> This was established under 2009-8 (01/13/2010 and triggered 02/03/2011) >> and modified by 2016-2 (04/20/2017) >> >> https://www.arin.net/vault/announcements/2011/20110203.html >> https://www.arin.net/resources/request/ipv4_countdown_plan.html >> >> Post 04/20/2017, and ISP can only get a 2 year supply. >> >> I believe you need to show that the initial /21 you are asking for is a >> 90 day supply or less during the 09/2010-04/2012 time period, which >> subsequently reverted to a two year window. >> >> Hopefully staff questions above will clarify this. >> >> At the very least it was never my expectation that passing 2016-4 >> would exclude the initial /21 from needing to meet the requirement >> of 4.2.2.1.3. Three Months. >> >> >>> >>> Also, even with the /24 limit, under current policy, they can >>> immediately turn around, claim they?ve used that /24 and with officer >>> attestation get an additional /23, then turn around again and get an >>> additional /22 which would leave them only 1 /24 short of a /21 (which they >>> could turn around and immediately obtain unto an additional /21 under the >>> same policy). So we essentially already allow this transaction, but the >>> question is how many hoops do we want to add to the process. >>> >>> >> Assuming there is no fraud in the transaction you describe, then >> they would essentially be doing slow start. >> Get a block press it into service, show it is being used, and double. >> >> That is exactly how it is supposed to work. >> That is exactly what we did under slow start with no history of use: >> 1. get a /24 (or more up to a /21 from an upstream) show it is being used, >> 2. trade it out for ARIN space that replaces, and doubles the size >> 3. re number into the new space >> 4. press the unused new space into service >> 5. double you previous allocation if you do it in less than half the 90 >> day window >> 6. get the same size as your previous allocation if you do it in less >> that 90 days >> 7. fall back to a smaller next allocation if you do it in more than 90 >> days. >> >> The transfer version is more liberal in that it allows a straight >> doubling of all >> your holdings as opposed to only your last allocation doubling, and there >> is >> no time horizon, you can double even if it take you 3 years to press your >> address space into service. >> >> So, less silly than slow start with a 1 year window, and much less silly >> than >> slow start with a 3 month window. >> >> >> >>> I?m usually the one on the other side of this argument, but under the >>> current circumstances, even I think it?s kind of silly. >>> >>> >> What am I missing? What is so silly with this approach? >> >> >>> Owen >>> >>> On Jan 24, 2018, at 7:17 AM, Jason Schiller >>> wrote: >>> >>> I oppose. >>> >>> 2016-4 was an attempt to replace the slow-start boot strap of get a /24 >>> (or more) >>> from your upstream, put it into use, then use that to qualify to get >>> your own IP space from ARIN. >>> >>> The transfer slow-start boot strapping is to give the first /24 with no >>> justification, >>> put it to use, then double (just as you did under slow start). >>> >>> Essentially changing this to a /21 allows roughly 80% of ARIN members >>> to be able to get all the IPv4 address space they could even need with >>> no justification if they are willing to call themselves an ISP, and pay >>> the >>> appropriate fees. >>> >>> I oppose a non-needs based (or simply put a money based) justification >>> system on the grounds that does not provide IP addresses to those who >>> need >>> them, but rather to those who are more willing to spend, favoring >>> services that >>> generate the most revenue per IP. >>> >>> I even more strongly oppose a non-needs based justification that only >>> benifits >>> some small portion of the community. This proposal is essentially a >>> non-needs >>> based justification for anyone who needs a /21 or less and is willing to >>> pay an >>> extra $400 annually for up to a /22 or, and extra $900 annually for up >>> to a /21. >>> >>> >>> Under NRPM version 2016.2 - 13 July 2016 >>> https://www.arin.net/vault/policy/archive/nrpm_20160713.pdf >>> >>> For an ISP request for ARIN IP space, 4.2.2.1.1 required them to >>> show utilization of currently held IPv4 space. >>> >>> 1. They could use the utilization of their provider's /24 along with >>> the promise of renumbering to justify getting their own /24 >>> >>> An ISP could meet the 4.2.2.1.1 demonstration of utilization and >>> get additional space by showing the 3 month growth projection under >>> 4.2.2.1.3. >>> >>> (replacing their provider supplied addressing can be >>> included in the ask if they promose to return under 4.2.2.1.4) >>> >>> Or doubling under slow start 4.2.1.4. >>> >>> >>> 2016-4 came along to remove the need to get IPs from your upstream. >>> >>> https://www.arin.net/policy/proposals/2016_4.html >>> >>> >>> Replace Section 4.2.2 with: >>> >>> 4.2.2. Initial allocation to ISPs >>> >>> "All ISP organizations without direct assignments or allocations from >>> ARIN >>> qualify for an initial allocation of up to a /21, subject to ARIN's >>> minimum allocation size. Organizations may qualify for a larger initial >>> allocation by documenting how the requested allocation will be utilized >>> within 24 months for specified transfers, or three months otherwise. >>> ISPs renumbering out of their previous address space will be given a >>> reasonable amount of time to do so, and any blocks they are returning >>> will not count against their utilization." >>> >>> At that time the difference between ARIN IP space was a 90 day supply >>> versus a two tear supply on the transfer market. >>> >>> It also seemingly removed the following sections: >>> 4.2.2.1. ISP Requirements >>> 4.2.2.1.1. Use of /24 >>> 4.2.2.1.2. Efficient Utilization >>> 4.2.2.1.3. Three Months >>> 4.2.2.1.4. Renumber and Return >>> >>> It was my impression that ARIN would not issue a /21 if it was more than >>> a 90 day >>> supply. >>> >>> 2016-2 came along and changes the time frame to sync pre-approval for >>> transfers >>> and approval for the waiting list. >>> >>> It seeming updates the non-existant section 4.2.2.1.3 from 3 months to >>> 24. >>> and 4.2.4.3 to 24 months. >>> >>> This is what creates the problem where now an initial ISP can request a >>> /21 >>> without requiring >>> >>> I do not believe the intent was to give ISPs a /21 even if it is larger >>> than a, then >>> 90 day, or now two year supply. I suggest that if more than a /24 is >>> desired, they can get up >>> to a /21 if it is less than a 2 year supply, and subsequently need to >>> show utilization. >>> That means a /21 is not entirely justification free like the /24 is. >>> >>> __Jason >>> >>> >>> >>> >>> >>> >>> On Mon, Jan 22, 2018 at 6:35 PM, Owen DeLong wrote: >>> >>>> Fully support the direction you are now taking this. >>>> >>>> Owen >>>> >>>> On Jan 20, 2018, at 9:16 AM, David Farmer wrote: >>>> >>>> I think the burden is the potential to have to rejustify an ISP's >>>> initial allocation when being fulfilled by transfer. The >>>> inconsistency seems inefficient and creates confusion; there appears >>>> to be support for eliminating the inconsistency. With slightly more >>>> support for changing section 8 to be consistent with section 4, rather than >>>> the other way around. >>>> >>>> On Thu, Jan 18, 2018 at 6:07 PM, Scott Leibrand >>> com> wrote: >>>> >>>>> Quoting myself: >>>>> >>>>> 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. >>>>> >>>>> >>>>> Do you know of any organizations transferring blocks larger than a >>>>> /24 for whom officer-attested justification is burdensome (to them or to >>>>> ARIN)? >>>>> >>>>> Scott >>>>> >>>> >>>> -- >>>> =============================================== >>>> David Farmer Email:farmer at umn.edu >>>> Networking & Telecommunication Services >>>> Office of Information Technology >>>> University of Minnesota >>>> 2218 University Ave SE >>>> >>>> Phone: 612-626-0815 <(612)%20626-0815> >>>> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> >>>> =============================================== >>>> >>>> >>>> >>>> _______________________________________________ >>>> PPML >>>> You are receiving this message because you are subscribed to >>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>>> Unsubscribe or manage your mailing list subscription at: >>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>> Please contact info at arin.net if you experience any issues. >>>> >>> >>> >>> >>> -- >>> _______________________________________________________ >>> Jason Schiller|NetOps|jschiller at google.com|571-266-0006 >>> <(571)%20266-0006> >>> >>> >>> >> >> >> -- >> _______________________________________________________ >> Jason Schiller|NetOps|jschiller at google.com|571-266-0006 >> <(571)%20266-0006> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> >> >> > > > -- > _______________________________________________________ > Jason Schiller|NetOps|jschiller at google.com|571-266-0006 <(571)%20266-0006> > > > -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at iptrading.com Thu Jan 25 12:03:44 2018 From: mike at iptrading.com (Mike Burns) Date: Thu, 25 Jan 2018 12:03:44 -0500 Subject: [arin-ppml] Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers In-Reply-To: References: <37CC78F2-D908-44A6-A75F-22B84CAD9E76@delong.com> <7AB0967C-2CE4-4878-A76C-85A3D5E50CCC@gmail.com> <683F1314-A7E2-4E4B-9CB4-8CA4195BA964@delong.com> Message-ID: <009b01d395fe$7554f450$5ffedcf0$@iptrading.com> I support the policy. What Jason misses below when he says ?if they are willing to call themselves an ISP, and pay the appropriate fees.? And ?for anyone who needs a /21 or less and is willing to pay an extra $400 annually for up to a /22 or, and extra $900 annually for up to a /21.? is of course the far larger expense which is the actual purchase price of the addresses. At today?s rates, to go from a /24 to a /21 would cost almost $30k, or 30 years of fees! That, in a nutshell, is why needs-tests are an irrelevance in terms of who gets addresses. The high-bidder always gets them. Virtually all buyers can all justify their needs, or in a pinch, register at RIPE or permanently lease the addresses and don?t tell the RIR(s). The ARIN needs-test is almost never a concern among buyers we talk to. The price of the addresses is ALWAYS a concern. What is wrong with ?favoring services that generate the most revenue per IP? anyway? Whom should we ?favor?? It always bears repeating here that RIPE has no needs-tests for transfers and the most vital transfer market. And that there are no indications of hoarding, speculation, or market manipulation in RIPE that I can discern. Fears of these potential problems have always been the reasons proffered for the continued requirement for a needs-test, but I never hear any voices who dispassionately regard the RIPE transfer market and then question their prior beliefs that these maladies would come to pass. I mean these are the same people, generally, who feel IPv6 is in the offing and growing closer. Will there never come a time that the coming of IPv6 will convince people that nobody will speculate on IPv4? The needs-test is a completely irrelevant artifact from a prior era, and address pricing provides better conservation than any needs-test ever did. So anything we can do to remove this irrelevant burden from market participants is a step towards reducing uncertainty in the IPv4 transfer market and a step towards reconciliation with the other trading registries which have removed needs tests, as RIPE has and APNIC has done in the past before being pressured by ARIN to rescind. Regards, Mike From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Jason Schiller Sent: Wednesday, January 24, 2018 10:18 AM To: Owen DeLong Cc: ARIN-PPML List Subject: Re: [arin-ppml] Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers I oppose. 2016-4 was an attempt to replace the slow-start boot strap of get a /24 (or more) from your upstream, put it into use, then use that to qualify to get your own IP space from ARIN. The transfer slow-start boot strapping is to give the first /24 with no justification, put it to use, then double (just as you did under slow start). Essentially changing this to a /21 allows roughly 80% of ARIN members to be able to get all the IPv4 address space they could even need with no justification if they are willing to call themselves an ISP, and pay the appropriate fees. I oppose a non-needs based (or simply put a money based) justification system on the grounds that does not provide IP addresses to those who need them, but rather to those who are more willing to spend, favoring services that generate the most revenue per IP. I even more strongly oppose a non-needs based justification that only benifits some small portion of the community. This proposal is essentially a non-needs based justification for anyone who needs a /21 or less and is willing to pay an extra $400 annually for up to a /22 or, and extra $900 annually for up to a /21. Under NRPM version 2016.2 - 13 July 2016 https://www.arin.net/vault/policy/archive/nrpm_20160713.pdf For an ISP request for ARIN IP space, 4.2.2.1.1 required them to show utilization of currently held IPv4 space. 1. They could use the utilization of their provider's /24 along with the promise of renumbering to justify getting their own /24 An ISP could meet the 4.2.2.1.1 demonstration of utilization and get additional space by showing the 3 month growth projection under 4.2.2.1.3. (replacing their provider supplied addressing can be included in the ask if they promose to return under 4.2.2.1.4) Or doubling under slow start 4.2.1.4. 2016-4 came along to remove the need to get IPs from your upstream. https://www.arin.net/policy/proposals/2016_4.html Replace Section 4.2.2 with: 4.2.2. Initial allocation to ISPs "All ISP organizations without direct assignments or allocations from ARIN qualify for an initial allocation of up to a /21, subject to ARIN's minimum allocation size. Organizations may qualify for a larger initial allocation by documenting how the requested allocation will be utilized within 24 months for specified transfers, or three months otherwise. ISPs renumbering out of their previous address space will be given a reasonable amount of time to do so, and any blocks they are returning will not count against their utilization." At that time the difference between ARIN IP space was a 90 day supply versus a two tear supply on the transfer market. It also seemingly removed the following sections: 4.2.2.1. ISP Requirements 4.2.2.1.1. Use of /24 4.2.2.1.2. Efficient Utilization 4.2.2.1.3. Three Months 4.2.2.1.4. Renumber and Return It was my impression that ARIN would not issue a /21 if it was more than a 90 day supply. 2016-2 came along and changes the time frame to sync pre-approval for transfers and approval for the waiting list. It seeming updates the non-existant section 4.2.2.1.3 from 3 months to 24. and 4.2.4.3 to 24 months. This is what creates the problem where now an initial ISP can request a /21 without requiring I do not believe the intent was to give ISPs a /21 even if it is larger than a, then 90 day, or now two year supply. I suggest that if more than a /24 is desired, they can get up to a /21 if it is less than a 2 year supply, and subsequently need to show utilization. That means a /21 is not entirely justification free like the /24 is. __Jason On Mon, Jan 22, 2018 at 6:35 PM, Owen DeLong > wrote: Fully support the direction you are now taking this. Owen On Jan 20, 2018, at 9:16 AM, David Farmer > wrote: I think the burden is the potential to have to rejustify an ISP's initial allocation when being fulfilled by transfer. The inconsistency seems inefficient and creates confusion; there appears to be support for eliminating the inconsistency. With slightly more support for changing section 8 to be consistent with section 4, rather than the other way around. On Thu, Jan 18, 2018 at 6:07 PM, Scott Leibrand > wrote: Quoting myself: 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. Do you know of any organizations transferring blocks larger than a /24 for whom officer-attested justification is burdensome (to them or to ARIN)? Scott -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -- _______________________________________________________ Jason Schiller|NetOps| jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Thu Jan 25 13:53:26 2018 From: jcurran at arin.net (John Curran) Date: Thu, 25 Jan 2018 18:53:26 +0000 Subject: [arin-ppml] Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers In-Reply-To: References: <37CC78F2-D908-44A6-A75F-22B84CAD9E76@delong.com> <7AB0967C-2CE4-4878-A76C-85A3D5E50CCC@gmail.com> <683F1314-A7E2-4E4B-9CB4-8CA4195BA964@delong.com> <44111583-2D5A-4B9B-AEE8-2E8521B7C0DC@delong.com> <1E8D9EA9-FE50-48A5-B0DD-C86C7B73F44C@arin.net> <25E9F785-ABD2-4CCC-9285-029798BCB884@arin.net> Message-ID: On 25 Jan 2018, at 5:17 AM, Jason Schiller wrote: > > The argument (as I understand it) is comparing justification > required for a transfer vs for ARIN free pool. > > If ARIN does not permit a "no justification" approval > for a transfer of a /21 under ISP initial allocation > if they have no direct resources then, > > There are extra requirements on transfers that > did not exist on getting that same approval for a /21 > from the free pool. > > My understanding is that there is a restriction > on the ISP initial allocation from the free pool. > It was show that this is not more than a 90 day > supply. We changed that to two years. > > My understanding is that ISPs with no direct IPv4 > didn't get a free pass on the (then) 90 day restriction > when asking for their initial /21. 2009-8 (which added the 90 restriction on ISP initial allocations) indicated "This reduction does not apply to resources received via section 8.3.?, and therefore it is inappropriate to take it into consideration when comparing allocation policy against transfer policy as it was never indicated to apply with respect to transfers. Thanks, /John John Curran President and CEO ARIN From jschiller at google.com Thu Jan 25 17:20:07 2018 From: jschiller at google.com (Jason Schiller) Date: Thu, 25 Jan 2018 17:20:07 -0500 Subject: [arin-ppml] Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers In-Reply-To: References: <37CC78F2-D908-44A6-A75F-22B84CAD9E76@delong.com> <7AB0967C-2CE4-4878-A76C-85A3D5E50CCC@gmail.com> <683F1314-A7E2-4E4B-9CB4-8CA4195BA964@delong.com> <44111583-2D5A-4B9B-AEE8-2E8521B7C0DC@delong.com> <1E8D9EA9-FE50-48A5-B0DD-C86C7B73F44C@arin.net> <25E9F785-ABD2-4CCC-9285-029798BCB884@arin.net> Message-ID: John, So an ISP with no resources who wanted an initial /21 from ARIN would be asked for some additional data to ensure that the /21 was not more than an 90 day supply? __Jason On Thu, Jan 25, 2018 at 1:53 PM, John Curran wrote: > On 25 Jan 2018, at 5:17 AM, Jason Schiller wrote: > > > > The argument (as I understand it) is comparing justification > > required for a transfer vs for ARIN free pool. > > > > If ARIN does not permit a "no justification" approval > > for a transfer of a /21 under ISP initial allocation > > if they have no direct resources then, > > > > There are extra requirements on transfers that > > did not exist on getting that same approval for a /21 > > from the free pool. > > > > My understanding is that there is a restriction > > on the ISP initial allocation from the free pool. > > It was show that this is not more than a 90 day > > supply. We changed that to two years. > > > > My understanding is that ISPs with no direct IPv4 > > didn't get a free pass on the (then) 90 day restriction > > when asking for their initial /21. > > 2009-8 (which added the 90 restriction on ISP initial allocations) > indicated "This reduction does not apply to resources received via section > 8.3.?, and therefore it is inappropriate to take it into consideration when > comparing allocation policy against transfer policy as it was never > indicated to apply with respect to transfers. > > Thanks, > /John > > John Curran > President and CEO > ARIN > > > -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Fri Jan 26 00:34:21 2018 From: jcurran at arin.net (John Curran) Date: Fri, 26 Jan 2018 05:34:21 +0000 Subject: [arin-ppml] Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers In-Reply-To: References: <37CC78F2-D908-44A6-A75F-22B84CAD9E76@delong.com> <7AB0967C-2CE4-4878-A76C-85A3D5E50CCC@gmail.com> <683F1314-A7E2-4E4B-9CB4-8CA4195BA964@delong.com> <44111583-2D5A-4B9B-AEE8-2E8521B7C0DC@delong.com> <1E8D9EA9-FE50-48A5-B0DD-C86C7B73F44C@arin.net> <25E9F785-ABD2-4CCC-9285-029798BCB884@arin.net> Message-ID: On 25 Jan 2018, at 2:20 PM, Jason Schiller > wrote: John, So an ISP with no resources who wanted an initial /21 from ARIN would be asked for some additional data to ensure that the /21 was not more than an 90 day supply? Jason - No, an ISP receiving its initial assignment would have to meet the criteria in NRPM 4.2.2, and that does not specify any requirement regarding 90 day supply. Note that as a practical matter the ISP would no IPv4 space from ARIN, but instead go to the waiting list for an uncertain chance at receiving some resources in the future. Thanks, /John 4.2.2. Initial allocation to ISPs All ISP organizations without direct assignments or allocations from ARIN qualify for an initial allocation of up to a /21, subject to ARIN's minimum allocation size. Organizations may qualify for a larger initial allocation by documenting how the requested allocation will be utilized within 24 months -------------- next part -------------- An HTML attachment was scrubbed... URL: From narten at us.ibm.com Fri Jan 26 00:53:03 2018 From: narten at us.ibm.com (narten at us.ibm.com) Date: Fri, 26 Jan 2018 00:53:03 -0500 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201801260553.w0Q5r3Uc011509@rotala.raleigh.ibm.com> Total of 21 messages in the last 7 days. script run at: Fri Jan 26 00:53:02 EST 2018 Messages | Bytes | Who --------+------+--------+----------+------------------------ 28.57% | 6 | 38.55% | 241260 | jschiller at google.com 19.05% | 4 | 20.72% | 129672 | jcurran at arin.net 14.29% | 3 | 15.47% | 96808 | farmer at umn.edu 14.29% | 3 | 11.08% | 69346 | owen at delong.com 9.52% | 2 | 3.65% | 22871 | info at arin.net 4.76% | 1 | 6.29% | 39371 | mike at iptrading.com 4.76% | 1 | 2.63% | 16478 | abagrin at mydigitalshield.com 4.76% | 1 | 1.60% | 10034 | narten at us.ibm.com --------+------+--------+----------+------------------------ 100.00% | 21 |100.00% | 625840 | Total From jcurran at arin.net Fri Jan 26 00:54:56 2018 From: jcurran at arin.net (John Curran) Date: Fri, 26 Jan 2018 05:54:56 +0000 Subject: [arin-ppml] Free-pool allocation policy (Re: Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers) In-Reply-To: References: <37CC78F2-D908-44A6-A75F-22B84CAD9E76@delong.com> <7AB0967C-2CE4-4878-A76C-85A3D5E50CCC@gmail.com> <683F1314-A7E2-4E4B-9CB4-8CA4195BA964@delong.com> <44111583-2D5A-4B9B-AEE8-2E8521B7C0DC@delong.com> <1E8D9EA9-FE50-48A5-B0DD-C86C7B73F44C@arin.net> <25E9F785-ABD2-4CCC-9285-029798BCB884@arin.net> Message-ID: <32DE9744-5AF6-40DF-A15C-5215F2158071@arin.net> On 25 Jan 2018, at 8:34 PM, John Curran wrote: > ?. > Note that as a practical matter the ISP would no IPv4 space from ARIN, but instead go to the waiting list for an uncertain chance at receiving some resources in the future. Note as a follow-on for thought - The discussion of free-pool allocation policy also raises an important issue: specifically, in light of free-pool depletion, what is the policy purpose of IPv4 free-pool allocation policy given an active and functional transfer market? While a waiting list policy that allows for receiving allocations similar to historical practice has obviously been an important transitional mechanism (providing a functional alternative at runout while the market got established and for those who were caught unaware), its goals at this point are less clear. If the goal is to help those who lack financial resources with an opportunity to receive resources, then one would expect entry to the waiting list (and issuance when available) to be conditioned on same. If the goal is help as many parties as possible, then allocation of anything other than the minimum allocation size (/24) would seem ill-advised, as would supporting additional allocation requests. It might be worth the community spending some time discussing the underlying goals of the post-depletion IPv4 allocation policy, as it is unclear whether its goals meaningfully overlap that of the transfer policy. Thanks! /John John Curran President and CEO ARIN From hostmaster at uneedus.com Fri Jan 26 07:26:57 2018 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Fri, 26 Jan 2018 07:26:57 -0500 (EST) Subject: [arin-ppml] Free-pool allocation policy (Re: Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers) In-Reply-To: <32DE9744-5AF6-40DF-A15C-5215F2158071@arin.net> References: <7AB0967C-2CE4-4878-A76C-85A3D5E50CCC@gmail.com> <683F1314-A7E2-4E4B-9CB4-8CA4195BA964@delong.com> <44111583-2D5A-4B9B-AEE8-2E8521B7C0DC@delong.com> <1E8D9EA9-FE50-48A5-B0DD-C86C7B73F44C@arin.net> <25E9F785-ABD2-4CCC-9285-029798BCB884@arin.net> <32DE9744-5AF6-40DF-A15C-5215F2158071@arin.net> Message-ID: I kinda agree that we should work toward a post free pool world. Right now, other than the few lucky people who have obtained resources from the free pool, microallocations under 4.4 or IPv6 deployment under 4.10 are the only IPv4 resources being allocated under section 4 policy. The majority of total activity of late is clearly section 8 transfers. I think our work here should be toward a single policy for all, which would include the few section 4 allocations, along with the section 8 transfers. Section 4.10's limit is a /28 to a /24, whereas 4.4's limit is /24 or /23 and the remaining section 8 transfers under discussion can be from a /27 to a /24. I would like to see us work toward a single policy used for all of these cases, with the exact limits used in each case dependent on which section of the NRPM the person is applying for number resources. Albert Erdmann Network Administrator Paradise On Line Inc. On Fri, 26 Jan 2018, John Curran wrote: > On 25 Jan 2018, at 8:34 PM, John Curran wrote: >> ?. >> Note that as a practical matter the ISP would no IPv4 space from >> ARIN, but instead go to the waiting list for an uncertain chance at >> receiving some resources in the future. > > Note as a follow-on for thought - The discussion of free-pool allocation > policy also raises an important issue: specifically, in light of > free-pool depletion, what is the policy purpose of IPv4 free-pool > allocation policy given an active and functional transfer market? > > While a waiting list policy that allows for receiving allocations > similar to historical practice has obviously been an important > transitional mechanism (providing a functional alternative at runout > while the market got established and for those who were caught unaware), > its goals at this point are less clear. If the goal is to help those > who lack financial resources with an opportunity to receive resources, > then one would expect entry to the waiting list (and issuance when > available) to be conditioned on same. If the goal is help as many > parties as possible, then allocation of anything other than the minimum > allocation size (/24) would seem ill-advised, as would supporting > additional allocation requests. > > It might be worth the community spending some time discussing the > underlying goals of the post-depletion IPv4 allocation policy, as it is > unclear whether its goals meaningfully overlap that of the transfer > policy. > > Thanks! > /John > > John Curran > President and CEO > ARIN > > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From jschiller at google.com Fri Jan 26 11:26:35 2018 From: jschiller at google.com (Jason Schiller) Date: Fri, 26 Jan 2018 11:26:35 -0500 Subject: [arin-ppml] Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers In-Reply-To: References: <37CC78F2-D908-44A6-A75F-22B84CAD9E76@delong.com> <7AB0967C-2CE4-4878-A76C-85A3D5E50CCC@gmail.com> <683F1314-A7E2-4E4B-9CB4-8CA4195BA964@delong.com> <44111583-2D5A-4B9B-AEE8-2E8521B7C0DC@delong.com> <1E8D9EA9-FE50-48A5-B0DD-C86C7B73F44C@arin.net> <25E9F785-ABD2-4CCC-9285-029798BCB884@arin.net> Message-ID: John, Looking back, I note that I have not made an ISP initial IPv4 request after 02/21/2017 when the policy was changed. My previous ISP initial IPv4 requests asked for a 3 month, 12 month, and 18 month projection. I assumed this was to comply with "4.2.2.1.3. Three Months" that existed until 02/21/2017. Was this information used prior to 02/21/2017? Is this information used since 02/21/2017? Or is it ignored and collected only because the initial ISP IPv4 request uses the same form as the subsequent requests? "4.2.2.1.3. Three Months" disappeared on 02/21/2017 That version was modified by: 2015-2 2016-1 2016-4 2016-5 2016-6 2016-4 replaces section 4.2.2 text. It does not clearly state that it replaces, removes, or modifies any of the sub sections. 4.2.2.1. ISP Requirements 4.2.2.1.1. Use of /24 4.2.2.1.2. Efficient Utilization 4.2.2.1.3. Three Months 4.2.2.1.4. Renumber and Return 4.2.2.2. [Section Number Retired] I never noticed that the sub-section disappeared and assumed 2016-4 only changed the 4.2.2 text. When I voiced my support for the 2016-4 it was with the understanding that (at that time): An ISP without a direct IPv4 block would automatically qualify for a /24, (without needing to go to an upstream and get IPv4 space and pressing it into service). Furthermore an ISP without a direct IPv4 block could get more than a /24 so long as it was did not exceed a 90 day supply (for non-transfers) or a 2 year supply (for transfers). Staff understanding at the time, suggested the same conclusions. __Jason On Fri, Jan 26, 2018 at 12:34 AM, John Curran wrote: > On 25 Jan 2018, at 2:20 PM, Jason Schiller wrote: > > > John, > > So an ISP with no resources who wanted an initial /21 from ARIN > would be asked for some additional data to ensure that the /21 > was not more than an 90 day supply? > > > Jason - > > No, an ISP receiving its initial assignment would have to meet the > criteria in NRPM 4.2.2, and that does not specify any requirement regarding > 90 day supply. > > Note that as a practical matter the ISP would no IPv4 space from ARIN, > but instead go to the waiting list for an uncertain chance at receiving > some resources in the future. > > Thanks, > /John > > 4.2.2. Initial allocation to ISPs > All ISP organizations without direct assignments or allocations from ARIN > qualify for an initial allocation of up to a /21, subject to ARIN's minimum > allocation size. Organizations may qualify for a larger initial allocation > by documenting how the requested allocation will be utilized within 24 > months > > > > > -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Fri Jan 26 12:40:58 2018 From: jcurran at arin.net (John Curran) Date: Fri, 26 Jan 2018 17:40:58 +0000 Subject: [arin-ppml] Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers In-Reply-To: References: <37CC78F2-D908-44A6-A75F-22B84CAD9E76@delong.com> <7AB0967C-2CE4-4878-A76C-85A3D5E50CCC@gmail.com> <683F1314-A7E2-4E4B-9CB4-8CA4195BA964@delong.com> <44111583-2D5A-4B9B-AEE8-2E8521B7C0DC@delong.com> <1E8D9EA9-FE50-48A5-B0DD-C86C7B73F44C@arin.net> <25E9F785-ABD2-4CCC-9285-029798BCB884@arin.net> Message-ID: <077A1A43-A76E-4BE6-98B9-C635AFA2B0F1@arin.net> On 26 Jan 2018, at 8:26 AM, Jason Schiller > wrote: John, Looking back, I note that I have not made an ISP initial IPv4 request after 02/21/2017 when the policy was changed. My previous ISP initial IPv4 requests asked for a 3 month, 12 month, and 18 month projection. I assumed this was to comply with "4.2.2.1.3. Three Months" that existed until 02/21/2017. Was this information used prior to 02/21/2017? Is this information used since 02/21/2017? Documentation requirements for parties requesting IPv4 resources under various policies may be found here: https://www.arin.net/resources/request_ipv4.html We are happy to research past request forms and processing to support the policy development process, but need to understand the relevance so that we can prioritize the effort. 2016-4 replaces section 4.2.2 text. It does not clearly state that it replaces, removes, or modifies any of the sub sections. 4.2.2.1. ISP Requirements 4.2.2.1.1. Use of /24 4.2.2.1.2. Efficient Utilization 4.2.2.1.3. Three Months 4.2.2.1.4. Renumber and Return 4.2.2.2. [Section Number Retired] I never noticed that the sub-section disappeared and assumed 2016-4 only changed the 4.2.2 text. Replacement of 4.2.2.1.1 (et al) was inherent to the policy proposal, as per the problem statement - "Problem Statement: New organizations without existing IPv4 space may not always be able to qualify for an initial allocation under NRPM 4.2, particularly if they are categorized as ISPs and subject to 4.2.2.1.1. Use of /24. " If 4.2.2.1.1 and other subsections were retained, the policy change would be moot. When I voiced my support for the 2016-4 it was with the understanding that (at that time): Ah, that?s unfortunate, but does somewhat explain your interesting perspective in this regard. If you believe that a change to number resource policy is warranted, you can submit a policy proposal as documented here: https://www.arin.net/participate/how_to_participate.html Thanks! /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmer at umn.edu Tue Jan 30 10:51:17 2018 From: farmer at umn.edu (David Farmer) Date: Tue, 30 Jan 2018 09:51:17 -0600 Subject: [arin-ppml] Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers In-Reply-To: References: <37CC78F2-D908-44A6-A75F-22B84CAD9E76@delong.com> <7AB0967C-2CE4-4878-A76C-85A3D5E50CCC@gmail.com> <683F1314-A7E2-4E4B-9CB4-8CA4195BA964@delong.com> <44111583-2D5A-4B9B-AEE8-2E8521B7C0DC@delong.com> <1E8D9EA9-FE50-48A5-B0DD-C86C7B73F44C@arin.net> <25E9F785-ABD2-4CCC-9285-029798BCB884@arin.net> Message-ID: Jason, I've been reviewing the record for ARIN-2016-2 and ARIN-2016-4; https://www.arin.net/policy/proposals/2016_2.html https://www.arin.net/policy/proposals/2016_4.html Please remember that 2016-2 and 2016-4 have overlapping changes, this was noted in the comments of 2016-4, prop-227 is 2016-2. See my comments inline; On Fri, Jan 26, 2018 at 10:26 AM, Jason Schiller wrote: > John, > > Looking back, I note that I have not made an ISP initial IPv4 > request after 02/21/2017 when the policy was changed. > > My previous ISP initial IPv4 requests asked for a > 3 month, 12 month, and 18 month projection. > > I assumed this was to comply with "4.2.2.1.3. Three Months" > that existed until 02/21/2017. > > Was this information used prior to 02/21/2017? > Is this information used since 02/21/2017? > > Or is it ignored and collected only because the > initial ISP IPv4 request uses the same form as the > subsequent requests? > > > "4.2.2.1.3. Three Months" disappeared on 02/21/2017 > > That version was modified by: > 2015-2 > 2016-1 > 2016-4 > 2016-5 > 2016-6 > 2016-2 had a slightly delayed implementation, it was impemented on 04/20/217, from the other policys approved at the same time. > 2016-4 replaces section 4.2.2 text. > > It does not clearly state that it > replaces, removes, or modifies > any of the sub sections. > While it is unfortunate we didn't explicitly say that the sub-sections were to be deleted, it however seems clear to me that was the intent. The Problem Statement makes it clear 4.2.2.1.1 is no longer valid, further several of the sub-sections are obviously incoporated in the new text of 4.2.2 including 4.2.2.1.3, which based on the coment within 2016-4 was removed because 2016-2 was also adopted. > 4.2.2.1. ISP Requirements > 4.2.2.1.1. Use of /24 > 4.2.2.1.2. Efficient Utilization > 4.2.2.1.3. Three Months > Even if 4.2.2.1.3 wasn't removed ARIN-2016-2 would have clearlly changed it to 24 months. > 4.2.2.1.4. Renumber and Return > 4.2.2.2. [Section Number Retired] > > > I never noticed that the sub-section disappeared > and assumed 2016-4 only changed the 4.2.2 > text. > > > When I voiced my support for the 2016-4 it was > with the understanding that (at that time): > > An ISP without a direct IPv4 block would > automatically qualify for a /24, (without needing > to go to an upstream and get IPv4 space and > pressing it into service). > > Furthermore an ISP without a direct IPv4 block > could get more than a /24 so long as it was did > not exceed a 90 day supply (for non-transfers) > or a 2 year supply (for transfers). > I don't know if you also support 2016-2, but it quite cleary changes the 90 day supply (for non-transfers) to a 2 year supply (for both transfers and non-transfers), in fact this is conditionally noted in the comments for 2016-4. > Staff understanding at the time, suggested > the same conclusions. > I believe the overlapping changes were propperly implemneted, infact staff and the AC work closely to ensure this happened correctly. > __Jason > Thanks. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at arin.net Wed Jan 31 14:15:18 2018 From: info at arin.net (ARIN) Date: Wed, 31 Jan 2018 14:15:18 -0500 Subject: [arin-ppml] Advisory Council Meeting Results - January 2018 Message-ID: <0c5a122d-9364-9a9c-3532-d658b9d4f77a@arin.net> In accordance with the Policy Development Process (PDP), the Advisory Council (AC) met on 26 January 2018. The AC has advanced the following Proposal to Draft Policy status (will be posted separately for discussion): * ARIN-prop-250: Allow Inter-regional ASN Transfers The AC advances Proposals to Draft Policy status once they are found to be within the scope of the PDP, and contain a clear problem statement and suggested changes to Internet number resource policy text. The AC has abandoned the following: * ARIN-2017-4: Remove Bidirectional Requirement for Inter-RIR Transfers The AC provided the following statement: "At its annual face-to-face meeting on January 26th 2018, the ARIN AC voted to abandon Draft Policy ARIN-2017-4. Support/opposition among members of the AC mirrors that in the community - which has remained more or less evenly split over the life of the policy proposal. One of the ongoing objections has been that under current policies at other RIRs, 2017-4 would not have any effect on current address transfer practices. We would welcome the submission of a new policy proposal with the same unidirectional transfer goals as 2017-4 once there is a compatible one-way transfer policy in another RIR to inform discussion." Anyone dissatisfied with this decision may initiate a petition. The deadline to begin a petition will be five business days after the AC's draft meeting minutes have been published. The AC has classified the following Proposal as an editorial update: * ARIN-prop-251: Correct references to rwhois Per Part One, Section 3.1 of the PDP: "Changes to policy that are purely editorial and non-substantial in nature are outside the scope of the full Policy Development Process and may only be made with 30 days public notice followed by the concurrence of both the ARIN Advisory Council and ARIN Board of Trustees that the changes are non-substantial in nature." The editorial update review window is forthcoming and will be posted separately for discussion. The AC is continuing to work on: * ARIN-2017-3: Update to NPRM 3.6: Annual Whois POC Validation * ARIN-2017-8: Amend Community Networks * 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 info at arin.net Wed Jan 31 14:20:38 2018 From: info at arin.net (ARIN) Date: Wed, 31 Jan 2018 14:20:38 -0500 Subject: [arin-ppml] Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers Message-ID: <5b901b94-f0b8-276b-2c9d-1b27bcb54442@arin.net> On 26 January 2018, the ARIN Advisory Council (AC) advanced "ARIN-prop-250: Allow Inter-regional ASN Transfers" to Draft Policy status. Draft Policy ARIN-2018-1 is below and can be found at: https://www.arin.net/policy/proposals/2018_1.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-2018-1: Allow Inter-regional ASN Transfers Problem Statement: There is a need to allow RIR transfers of ASNs with RIRs with an equivalent transfer policy. Policy Statement: Change the first sentence in section 8.4 from: "Inter-regional transfers may take place only via RIRs who agree to the transfer and share reciprocal, compatible, needs-based policies." To: "Inter-regional transfers of IPv4 number resources and ASNs may take place only via RIRs who agree to the transfer and share reciprocal, compatible needs-based policies." Comments: Timetable for Implementation: Immediate From hvgeekwtrvl at gmail.com Wed Jan 31 14:53:52 2018 From: hvgeekwtrvl at gmail.com (james machado) Date: Wed, 31 Jan 2018 11:53:52 -0800 Subject: [arin-ppml] Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers In-Reply-To: <5b901b94-f0b8-276b-2c9d-1b27bcb54442@arin.net> References: <5b901b94-f0b8-276b-2c9d-1b27bcb54442@arin.net> Message-ID: Could someone please expand upon the problem statment? Maybe include some examples of why AS's need to be transferable between RIR's and versus requsting an AS number from the appropriate RIR and utilizing it. James On Wed, Jan 31, 2018 at 11:20 AM, ARIN wrote: > On 26 January 2018, the ARIN Advisory Council (AC) advanced > "ARIN-prop-250: Allow Inter-regional ASN Transfers" to Draft Policy status. > > Draft Policy ARIN-2018-1 is below and can be found at: > > https://www.arin.net/policy/proposals/2018_1.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-2018-1: Allow Inter-regional ASN Transfers > > Problem Statement: > > There is a need to allow RIR transfers of ASNs with RIRs with an > equivalent transfer policy. > > Policy Statement: > > Change the first sentence in section 8.4 from: > > "Inter-regional transfers may take place only via RIRs who agree to the > transfer and share reciprocal, compatible, needs-based policies." > > To: > > "Inter-regional transfers of IPv4 number resources and ASNs may take place > only via RIRs who agree to the transfer and share reciprocal, compatible > needs-based policies." > > Comments: > > 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at semihuman.com Wed Jan 31 15:01:44 2018 From: chris at semihuman.com (Chris Woodfield) Date: Wed, 31 Jan 2018 12:01:44 -0800 Subject: [arin-ppml] Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers In-Reply-To: References: <5b901b94-f0b8-276b-2c9d-1b27bcb54442@arin.net> Message-ID: <10670B62-314D-469F-B43F-292C9D49E95C@semihuman.com> The thread that precipitated this proposal is here: http://lists.arin.net/pipermail/arin-ppml/2017-December/032112.html The main motivator appears to be differences in supply/demand ratios for 16-bit ASNs in different regions. I agree that the problem statement should capture this need. -C > On Jan 31, 2018, at 11:53 AM, james machado wrote: > > Could someone please expand upon the problem statment? Maybe include some examples of why AS's need to be transferable between RIR's and versus requsting an AS number from the appropriate RIR and utilizing it. > > James > > On Wed, Jan 31, 2018 at 11:20 AM, ARIN > wrote: > On 26 January 2018, the ARIN Advisory Council (AC) advanced > "ARIN-prop-250: Allow Inter-regional ASN Transfers" to Draft Policy status. > > Draft Policy ARIN-2018-1 is below and can be found at: > > https://www.arin.net/policy/proposals/2018_1.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-2018-1: Allow Inter-regional ASN Transfers > > Problem Statement: > > There is a need to allow RIR transfers of ASNs with RIRs with an equivalent transfer policy. > > Policy Statement: > > Change the first sentence in section 8.4 from: > > "Inter-regional transfers may take place only via RIRs who agree to the transfer and share reciprocal, compatible, needs-based policies." > > To: > > "Inter-regional transfers of IPv4 number resources and ASNs may take place only via RIRs who agree to the transfer and share reciprocal, compatible needs-based policies." > > Comments: > > 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 job at ntt.net Wed Jan 31 15:07:22 2018 From: job at ntt.net (Job Snijders) Date: Wed, 31 Jan 2018 20:07:22 +0000 Subject: [arin-ppml] Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers In-Reply-To: <10670B62-314D-469F-B43F-292C9D49E95C@semihuman.com> References: <5b901b94-f0b8-276b-2c9d-1b27bcb54442@arin.net> <10670B62-314D-469F-B43F-292C9D49E95C@semihuman.com> Message-ID: <20180131200722.GB87376@vurt.meerval.net> On Wed, Jan 31, 2018 at 12:01:44PM -0800, Chris Woodfield wrote: > The thread that precipitated this proposal is here: > > http://lists.arin.net/pipermail/arin-ppml/2017-December/032112.html > > > The main motivator appears to be differences in supply/demand ratios > for 16-bit ASNs in different regions. I agree that the problem > statement should capture this need. There is also the matter of consistency: when an organisation ends up moving a portion or all of their resources to another RIR, it would be strange if the ASNs have to be left behind. Renumbering ASNs can be a very expensive and involved process, so simply 'requesting a new one' in the other region may not be feasible. - Job From scottleibrand at gmail.com Wed Jan 31 15:32:57 2018 From: scottleibrand at gmail.com (Scott Leibrand) Date: Wed, 31 Jan 2018 12:32:57 -0800 Subject: [arin-ppml] Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers In-Reply-To: <20180131200722.GB87376@vurt.meerval.net> References: <5b901b94-f0b8-276b-2c9d-1b27bcb54442@arin.net> <10670B62-314D-469F-B43F-292C9D49E95C@semihuman.com> <20180131200722.GB87376@vurt.meerval.net> Message-ID: On Wed, Jan 31, 2018 at 12:07 PM, Job Snijders wrote: > On Wed, Jan 31, 2018 at 12:01:44PM -0800, Chris Woodfield wrote: > > The thread that precipitated this proposal is here: > > > > http://lists.arin.net/pipermail/arin-ppml/2017-December/032112.html > > > > > > The main motivator appears to be differences in supply/demand ratios > > for 16-bit ASNs in different regions. I agree that the problem > > statement should capture this need. > > There is also the matter of consistency: when an organisation ends up > moving a portion or all of their resources to another RIR, it would be > strange if the ASNs have to be left behind. Renumbering ASNs can be a > very expensive and involved process, so simply 'requesting a new one' in > the other region may not be feasible. > Personally I'd rather not go down the "ASNs that can be represented as a 16-bit integer" rabbit hole again. I think the better problem statement here is Job's one here. Maybe add something like this to the problem statement in the proposal? "When an organisation ends up moving a portion or all of their IPv4 resources to another RIR, it is often most efficient to transfer the ASN used with them. Renumbering ASNs can be a very expensive and involved process, so simply 'requesting a new one' in the other region may not be feasible." -Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmer at umn.edu Wed Jan 31 15:33:16 2018 From: farmer at umn.edu (David Farmer) Date: Wed, 31 Jan 2018 14:33:16 -0600 Subject: [arin-ppml] Revised/Re-titled - Draft Policy ARIN-2017-8: Amend Community Networks In-Reply-To: <73e07de6-7271-2c1b-c1d6-0788c5d96c74@arin.net> References: <73e07de6-7271-2c1b-c1d6-0788c5d96c74@arin.net> Message-ID: Unless there are additional comments or suggestions, I plan to propose this Policy is advanced to Recommended Draft Policy at the AC's February meeting. Thanks On Wed, Jan 24, 2018 at 7:46 AM, ARIN wrote: > The following has been revised and re-titled: > > * Draft Policy ARIN-2017-8: Amend Community Networks > > Revised text is below and can be found at: > https://www.arin.net/policy/proposals/2017_8.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-8: Amend Community Networks > > Problem Statement: > > The Community Networks section of the NRPM has only been used once since > implementation in January 2010. Proposal ARIN-2016-7, to increase the > number of use cases, was abandoned by the Advisory Council due to lack of > feedback. Proposal ARIN 2017-2, to remove all mention of community networks > from NRPM met with opposition by the community. Many responded that the > definition of "community network" was too narrow, which could be the reason > for lack of uptake. > > In the discussion at ARIN 40, it was clear that more than just the > definition of a community network needed revision and that community > networks need to have allocations, not assignments. Additionally, community > networks need to make reassignments to end-users in accordance with > applicable policies. > ?????? > Policy statement: > > Replace section 2.11 with the following; > > 2.11 Community Network > > A community network is deployed, operated, and governed by its users, for > the purpose of providing free or low-cost connectivity to the community it > services. Users of the network or other volunteers must play a primary role > in the governance of the organization, whereas other functions may be > handled by either paid staff or volunteers. > > Rename section 6.5.9 and revise the last sentence as follows; > > 6.5.9. Community Network Allocations > > While community networks would normally be considered to be ISP type > organizations under existing ARIN criteria, they tend to operate on much > tighter budgets and often depend on volunteer labor. As a result, they tend > to be much smaller and more communal in their organization rather than > provider/customer relationships of commercial ISPs. This section seeks to > provide a policy that is more friendly to those environments by allowing > community network to receive a smaller allocation than other LIRs or > commercial ISPs. > > Community networks may also qualify under section 6.5.2 as a regular LIR. > > Section 6.5.9.1 is not changing, but is included here for completeness; > > 6.5.9.1. Qualification Criteria > > To qualify under this section, a community network must demonstrate to > ARIN's satisfaction that it meets the definition of a community network > under section 2.11 of the NRPM. > > Replace section 6.5.9.2 and 6.5.9.3 with the following; > > 6.5.9.2. Allocation Size > > Community networks are eligible only to receive an allocation of /40 of > IPv6 resources under this section. Community networks that wish to receive > a larger initial allocation or any subsequent allocations must qualify as a > regular LIR, see sections 6.5.2 or 6.5.3 respectively. > > 6.5.9.3. Reassignments by Community Networks > > Similar to other LIRs, Community networks shall make reassignments to > end-users in accordance with applicable policies, in particular, but not > limited to sections 6.5.4 and 6.5.5. However, they shall not reallocate > resources under this section. > > Comments: > > Timetable for implementation: Immediate > > Anything Else: > > The rationale for restricting community networks that receive resources > through this policy from making reallocations is that a /40 is a tiny IPv6 > allocation and it does not seem reasonable to subdivide such a small > allocation into even smaller reallocations. > > Also, the recommended size for reassignment is /48, to even the smallest > end-users, and therefore a /40 only provides 256 such reassignments. > > If a community network needs to make reallocations, maybe to other > cooperating community networks in their area, they should apply as, or > become, a regular LIR. As the smallest regular LIR, they would get a /36, > allowing more than sufficient room to subdivide the allocation into several > reasonable sized reallocations as necessary. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvgeekwtrvl at gmail.com Wed Jan 31 15:47:01 2018 From: hvgeekwtrvl at gmail.com (james machado) Date: Wed, 31 Jan 2018 12:47:01 -0800 Subject: [arin-ppml] Draft Policy ARIN-2018-1: Allow Inter-regional ASN Transfers In-Reply-To: References: <5b901b94-f0b8-276b-2c9d-1b27bcb54442@arin.net> <10670B62-314D-469F-B43F-292C9D49E95C@semihuman.com> <20180131200722.GB87376@vurt.meerval.net> Message-ID: So we seem to have 2 "problems" for this draft if I am reading correctly. A) An Entity wishes to buy/sell/transfer one or more ASN(s) to another Entity without regard of the destination RIR. B) Entity with one or more ASN(s) wishes to move one or more ASN(s) to a new RIR, possibly complementing an IP move, to begin/continue operations in the destination RIR. James -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmer at umn.edu Wed Jan 31 16:18:57 2018 From: farmer at umn.edu (David Farmer) Date: Wed, 31 Jan 2018 15:18:57 -0600 Subject: [arin-ppml] Revised - Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers In-Reply-To: References: Message-ID: There seems to be a bit of controversy on the direction to take this policy. Therefore as the shepherd, it would be helpful to hear from additional community members regarding this policy. Do you support or oppose the policy as written? Do you think the inconsistency described in the Problem Statement should be corrected? If yes, should it be corrected by revising by section 8.5.4 to be consistent with section 4.2.2, as proposed by the current text? Or, as an alternative by revising section 4.2.2 to be consistent with section 8.5.4? Are there other alternatives to correct the inconsistency to be considered? Other suggestions or comments? Your additional feedback and participation are appreciated, thank you. On Wed, Jan 24, 2018 at 7:42 AM, ARIN wrote: > The following has been revised: > > * Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 > ISP Transfers > > Revised text 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 in 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 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. > > Policy statement: > > Replace section 8.5.4; > > 8.5.4. Initial block > > Organizations without direct assignments or allocations from ARIN qualify > for the transfer of an initial IPv4 block, a /24 for assignments or a /24 > up to a /21 for allocations. > > Comments: > > Timetable for implementation: Immediate > > Anything Else: > > The ARIN 40 Policy Experience Report is available at; > > Slides: https://www.arin.net/vault/participate/meetings/reports/ARIN > _40/PDF/PPM/sweeting-policy-experience.pdf > > Transcript: https://www.arin.net/vault/participate/meetings/reports/ARIN > _40/ppm1_transcript.html#anchor_5 > > Video: https://www.youtube.com/watch?v=QVsfVMG_6fA > > Slides 10 - 13, located in the video from 6:30 to 8:30, are the relevant > portion of the report, questions from the audience follow. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: