From rbf+arin-ppml at panix.com Wed Nov 2 13:26:57 2016 From: rbf+arin-ppml at panix.com (Brett Frankenberger) Date: Wed, 2 Nov 2016 12:26:57 -0500 Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2016-6: Eliminate HD-Ratio from NRPM In-Reply-To: <58111C5F.7060206@arin.net> References: <58111C5F.7060206@arin.net> Message-ID: <20161102172657.GA28919@panix.com> Support. On Wed, Oct 26, 2016 at 05:13:03PM -0400, ARIN wrote: > The ARIN Advisory Council (AC) met on 21 October 2016 and decided to send > Recommended Draft Policy ARIN-2016-6: Eliminate HD-Ratio from NRPM to Last > Call: > > The AC provided the following statement to the community: > > This proposal is technically sound and enables fair and impartial number > policy by reducing any confusion caused by HD-Ratio remaining in the NRPM. > According to the staff and legal assessment, these changes align with > current practice of ARIN staff. There is support and no concerns have been > raised by the community regarding this proposal on PPML. During the Public > Policy Meeting at ARIN 38 in Dallas, a concern was raised regarding the > inclusion of comments on the fee structure in the policy statement. To > address this issue an editorial change has been made while sending the > policy to Last Call, removing the following unnecessary text from the > proposed section 6.5.9.2, "(both policy and fee structure) unless or until > the board adopts a specific more favorable fee structure for community > networks." > > Feedback is encouraged during the Last Call period. All comments should be > provided to the Public Policy Mailing List. This Last Call will expire on 9 > November 2016. After Last Call, the AC will conduct their Last Call review. > > The full text is below and available at: > https://www.arin.net/policy/proposals/ > > The ARIN Policy Development Process is available at: > https://www.arin.net/policy/pdp.html > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > > Recommended Draft Policy ARIN-2016-6: Eliminate HD-Ratio from NRPM > > AC's assessment of conformance with the Principles of Internet Number > Resource Policy: > > This proposal is technically sound and enables fair and impartial number > policy by reducing any confusion caused by HD-Ratio remaining in the NRPM. > According to the staff and legal assessment, these changes align with > current practice of ARIN staff. There is support and no concerns have been > raised by the community regarding this proposal on PPML. > > Problem Statement: > > The HD-Ratio has become an anachronism in the NRPM and some of the vestigial > references to it create confusion about recommended prefix sizes for IPv6 > resulting in a belief in the community that ARIN endorses the idea of /56s > as a unit of measure in IPv6 assignments. While there are members of the > community that believe a /56 is a reasonable choice, ARIN policy has always > allowed and still supports /48 prefixes for any and all end-sites without > need for further justification. More restrictive choices are still permitted > under policy as well. This proposal does not change that, but it attempts to > eliminate some possible confusion. > > The last remaining vestigial references to HD-Ratio are contained in the > community networks policy (Section 6.5.9). This policy seeks to replace > 6.5.9 with new text incorporating end user policy by reference (roughly > equivalent to the original intent of 6.5.9 prior to the more recent changes > to end-user policy). While this contains a substantial rewrite to the > Community Networks policy, it will not have any negative impact on community > networks. It may increase the amount of IPv6 space a community network could > receive due to the change from HD-Ratio, but not more than any other similar > sized end-user would receive under existing policy. > > Policy statement: > > Replace section 6.5.9 in its entirety as follows: > > 6.5.9 Community Network Assignments > > 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 them > to use end-user criteria. > > 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. > > 6.5.9.2 Receiving Resources > > Once qualified under this section, a community network shall be treated as > an end-user assignment for all ARIN purposes. > > Community networks shall be eligible under this section only for IPv6 > resources and the application process and use of those resources shall be > governed by the existing end-user policy contained in section 6.5.8 et. seq. > > Community networks seeking other resources shall remain subject to the > policies governing those resources independent of their election to use this > policy for IPv6 resources. > > Delete section 2.8 ? This section is non-operative and conflicts with the > definitions of utilization contained in current policies. > > Delete section 2.9 ? This section is no longer operative. > > Delete section 6.7 ? This section is no longer applicable. > > Comments: > > Timetable for implementation: Immediate > > Anything else > > Originally, I thought this would be an editorial change as the HD-Ratio has > been unused for several years. > > However, further research revealed that it is still referenced in the > Community Networks policy which has also gone unused since its inception. As > a result, I am going to attempt to simultaneously simplify the Community > Networks policy while preserving its intent and eliminate the HD-Ratio from > the NRPM. > > I realize that fees are out of scope for policy, however, in this case, we > are not setting fees. We are addressing in policy which fee structure the > given policy should operate under in a manner which does not constrain board > action on actual fees. > > This is an attempt to preserve the original intent of the Community networks > policy in a way that may make it less vestigial. > > Alternatively, we could simply delete Section 6.5.9 if that is preferred. > The primary goal here is to get rid of vestigial reference to HD-Ratio > rather than to get wrapped around the axle on community networks. > _______________________________________________ > 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 rbf+arin-ppml at panix.com Wed Nov 2 13:27:39 2016 From: rbf+arin-ppml at panix.com (Brett Frankenberger) Date: Wed, 2 Nov 2016 12:27:39 -0500 Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2016-4: Transfers for new entrants In-Reply-To: <58111D82.2040301@arin.net> References: <58111D82.2040301@arin.net> Message-ID: <20161102172739.GB28919@panix.com> Support. On Wed, Oct 26, 2016 at 05:17:54PM -0400, ARIN wrote: > The ARIN Advisory Council (AC) met on 21 October 2016 and decided to send > Recommended Draft Policy ARIN-2016-4: Transfers for new entrants to Last > Call: > > The AC provided the following statement to the community: > > This proposal is technically sound and enables fair and impartial number > policy. There is support for this policy in the ARIN community as expressed > at ARIN 38 and on PPML. There has been no opposition stated to 2016-4. At > the ARIN AC meeting held on 10/21/2016, it was agreed that in the "Anything > else" section of Recommended Draft Policy 2016-4 stating that 'The text in > 4.2.2 ?for specified transfers, or three months otherwise? and the text in > 4.3.3 ?for specified transfers, or 12 months otherwise? should be stricken > if ARIN-prop-227 is adopted' should be followed by ARIN staff as an > instruction from the AC, presuming that 2016-2 (which is what ARIN-prop-227 > has become) continues to move forward after last call. > > Feedback is encouraged during the Last Call period. All comments should be > provided to the Public Policy Mailing List. This Last Call will expire on 9 > November 2016. After Last Call, the AC will conduct their Last Call review. > > The full text is below and available at: > https://www.arin.net/policy/proposals/ > > The ARIN Policy Development Process is available at: > https://www.arin.net/policy/pdp.html > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > > > ARIN-2016-4: Transfers for new entrants > > AC assessment of conformance with the Principles of Internet Number Resource > Policy: > > The proposal is technically sound and enables fair and impartial number > policy by ensuring that new organizations have a mechanism to access at > least a minimum amount of resources from the transfer market. The staff and > legal review (as updated 8/19/2016) is non-controversial. There is support > and no concerns have been raised by the community regarding the proposal on > PPML or elsewhere. > > 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. Now that ARIN?s > free pool is exhausted, 4.2.1.6. Immediate need states that ?These cases are > exceptional?, but that is no longer correct. End user organizations > requiring less a /24 of address space may also be unable to acquire space > from their upstream ISP, and may instead need to receive a /24 from ARIN via > transfer. > > Policy statement: > > 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. > > Replace Section 4.3.2 to read: > > 4.3.2 Minimum assignment > > ARIN?s minimum assignment for end-user organizations is a /24. > > End-user organizations without direct assignments or allocations from ARIN > qualify for an initial assignment of ARIN?s minimum assignment size. > > Replace the first two sentences of Section 4.3.3. Utilization rate to read: > > Organizations may qualify for a larger initial allocation by providing > appropriate details to verify their 24-month growth projection for specified > transfers, or 12 months otherwise. > > Resulting new section 4.3.3 will be: > > Organizations may qualify for a larger initial allocation, by providing > appropriate details to verify their 24-month growth projection for specified > transfers, or 12 months otherwise. > > The basic criterion that must be met is a 50% utilization rate within one > year. > > A greater utilization rate may be required based on individual network > requirements. > > Comments: > > Timetable for implementation: Immediate > > Anything else > > The text in 4.2.2 ?for specified transfers, or three months otherwise? and > the text in 4.3.3 ?for specified transfers, or 12 months otherwise? should > be stricken if ARIN-prop-227 is adopted. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From chris at semihuman.com Wed Nov 2 13:57:05 2016 From: chris at semihuman.com (Chris Woodfield) Date: Wed, 2 Nov 2016 10:57:05 -0700 Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2016-4: Transfers for new entrants In-Reply-To: <58111D82.2040301@arin.net> References: <58111D82.2040301@arin.net> Message-ID: Support as proposed. -C > On Oct 26, 2016, at 2:17 PM, ARIN wrote: > > The ARIN Advisory Council (AC) met on 21 October 2016 and decided to send Recommended Draft Policy ARIN-2016-4: Transfers for new entrants to Last Call: > > The AC provided the following statement to the community: > > This proposal is technically sound and enables fair and impartial number policy. There is support for this policy in the ARIN community as expressed at ARIN 38 and on PPML. There has been no opposition stated to 2016-4. At the ARIN AC meeting held on 10/21/2016, it was agreed that in the "Anything else" section of Recommended Draft Policy 2016-4 stating that 'The text in 4.2.2 ?for specified transfers, or three months otherwise? and the text in 4.3.3 ?for specified transfers, or 12 months otherwise? should be stricken if ARIN-prop-227 is adopted' should be followed by ARIN staff as an instruction from the AC, presuming that 2016-2 (which is what ARIN-prop-227 has become) continues to move forward after last call. > > Feedback is encouraged during the Last Call period. All comments should be provided to the Public Policy Mailing List. This Last Call will expire on 9 November 2016. After Last Call, the AC will conduct their Last Call review. > > The full text is below and available at: > https://www.arin.net/policy/proposals/ > > The ARIN Policy Development Process is available at: > https://www.arin.net/policy/pdp.html > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > > > ARIN-2016-4: Transfers for new entrants > > AC assessment of conformance with the Principles of Internet Number Resource Policy: > > The proposal is technically sound and enables fair and impartial number policy by ensuring that new organizations have a mechanism to access at least a minimum amount of resources from the transfer market. The staff and legal review (as updated 8/19/2016) is non-controversial. There is support and no concerns have been raised by the community regarding the proposal on PPML or elsewhere. > > 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. Now that ARIN?s free pool is exhausted, 4.2.1.6. Immediate need states that ?These cases are exceptional?, but that is no longer correct. End user organizations requiring less a /24 of address space may also be unable to acquire space from their upstream ISP, and may instead need to receive a /24 from ARIN via transfer. > > Policy statement: > > 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. > > Replace Section 4.3.2 to read: > > 4.3.2 Minimum assignment > > ARIN?s minimum assignment for end-user organizations is a /24. > > End-user organizations without direct assignments or allocations from ARIN qualify for an initial assignment of ARIN?s minimum assignment size. > > Replace the first two sentences of Section 4.3.3. Utilization rate to read: > > Organizations may qualify for a larger initial allocation by providing appropriate details to verify their 24-month growth projection for specified transfers, or 12 months otherwise. > > Resulting new section 4.3.3 will be: > > Organizations may qualify for a larger initial allocation, by providing appropriate details to verify their 24-month growth projection for specified transfers, or 12 months otherwise. > > The basic criterion that must be met is a 50% utilization rate within one year. > > A greater utilization rate may be required based on individual network requirements. > > Comments: > > Timetable for implementation: Immediate > > Anything else > > The text in 4.2.2 ?for specified transfers, or three months otherwise? and the text in 4.3.3 ?for specified transfers, or 12 months otherwise? should be stricken if ARIN-prop-227 is adopted. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From bjones at vt.edu Wed Nov 2 14:19:20 2016 From: bjones at vt.edu (Brian Jones) Date: Wed, 02 Nov 2016 18:19:20 +0000 Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2016-4: Transfers for new entrants In-Reply-To: References: <58111D82.2040301@arin.net> Message-ID: Support. On Wed, Nov 2, 2016 at 1:57 PM Chris Woodfield wrote: > Support as proposed. > > -C > > > On Oct 26, 2016, at 2:17 PM, ARIN wrote: > > > > The ARIN Advisory Council (AC) met on 21 October 2016 and decided to > send Recommended Draft Policy ARIN-2016-4: Transfers for new entrants to > Last Call: > > > > The AC provided the following statement to the community: > > > > This proposal is technically sound and enables fair and impartial number > policy. There is support for this policy in the ARIN community as expressed > at ARIN 38 and on PPML. There has been no opposition stated to 2016-4. At > the ARIN AC meeting held on 10/21/2016, it was agreed that in the "Anything > else" section of Recommended Draft Policy 2016-4 stating that 'The text in > 4.2.2 ?for specified transfers, or three months otherwise? and the text in > 4.3.3 ?for specified transfers, or 12 months otherwise? should be stricken > if ARIN-prop-227 is adopted' should be followed by ARIN staff as an > instruction from the AC, presuming that 2016-2 (which is what ARIN-prop-227 > has become) continues to move forward after last call. > > > > Feedback is encouraged during the Last Call period. All comments should > be provided to the Public Policy Mailing List. This Last Call will expire > on 9 November 2016. After Last Call, the AC will conduct their Last Call > review. > > > > The full text is below and available at: > > https://www.arin.net/policy/proposals/ > > > > The ARIN Policy Development Process is available at: > > https://www.arin.net/policy/pdp.html > > > > Regards, > > > > Communications and Member Services > > American Registry for Internet Numbers (ARIN) > > > > > > > > > > ARIN-2016-4: Transfers for new entrants > > > > AC assessment of conformance with the Principles of Internet Number > Resource Policy: > > > > The proposal is technically sound and enables fair and impartial number > policy by ensuring that new organizations have a mechanism to access at > least a minimum amount of resources from the transfer market. The staff and > legal review (as updated 8/19/2016) is non-controversial. There is support > and no concerns have been raised by the community regarding the proposal on > PPML or elsewhere. > > > > 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. Now that ARIN?s > free pool is exhausted, 4.2.1.6. Immediate need states that ?These cases > are exceptional?, but that is no longer correct. End user organizations > requiring less a /24 of address space may also be unable to acquire space > from their upstream ISP, and may instead need to receive a /24 from ARIN > via transfer. > > > > Policy statement: > > > > 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. > > > > Replace Section 4.3.2 to read: > > > > 4.3.2 Minimum assignment > > > > ARIN?s minimum assignment for end-user organizations is a /24. > > > > End-user organizations without direct assignments or allocations from > ARIN qualify for an initial assignment of ARIN?s minimum assignment size. > > > > Replace the first two sentences of Section 4.3.3. Utilization rate to > read: > > > > Organizations may qualify for a larger initial allocation by providing > appropriate details to verify their 24-month growth projection for > specified transfers, or 12 months otherwise. > > > > Resulting new section 4.3.3 will be: > > > > Organizations may qualify for a larger initial allocation, by providing > appropriate details to verify their 24-month growth projection for > specified transfers, or 12 months otherwise. > > > > The basic criterion that must be met is a 50% utilization rate within > one year. > > > > A greater utilization rate may be required based on individual network > requirements. > > > > Comments: > > > > Timetable for implementation: Immediate > > > > Anything else > > > > The text in 4.2.2 ?for specified transfers, or three months otherwise? > and the text in 4.3.3 ?for specified transfers, or 12 months otherwise? > should be stricken if ARIN-prop-227 is adopted. > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjones at vt.edu Wed Nov 2 14:21:42 2016 From: bjones at vt.edu (Brian Jones) Date: Wed, 02 Nov 2016 18:21:42 +0000 Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2016-6: Eliminate HD-Ratio from NRPM In-Reply-To: <20161102172657.GA28919@panix.com> References: <58111C5F.7060206@arin.net> <20161102172657.GA28919@panix.com> Message-ID: Support. > > On Wed, Oct 26, 2016 at 05:13:03PM -0400, ARIN wrote: > > The ARIN Advisory Council (AC) met on 21 October 2016 and decided to send > > Recommended Draft Policy ARIN-2016-6: Eliminate HD-Ratio from NRPM to > Last > > Call: > > > > The AC provided the following statement to the community: > > > > This proposal is technically sound and enables fair and impartial number > > policy by reducing any confusion caused by HD-Ratio remaining in the > NRPM. > > According to the staff and legal assessment, these changes align with > > current practice of ARIN staff. There is support and no concerns have > been > > raised by the community regarding this proposal on PPML. During the > Public > > Policy Meeting at ARIN 38 in Dallas, a concern was raised regarding the > > inclusion of comments on the fee structure in the policy statement. To > > address this issue an editorial change has been made while sending the > > policy to Last Call, removing the following unnecessary text from the > > proposed section 6.5.9.2, "(both policy and fee structure) unless or > until > > the board adopts a specific more favorable fee structure for community > > networks." > > > > Feedback is encouraged during the Last Call period. All comments should > be > > provided to the Public Policy Mailing List. This Last Call will expire > on 9 > > November 2016. After Last Call, the AC will conduct their Last Call > review. > > > > The full text is below and available at: > > https://www.arin.net/policy/proposals/ > > > > The ARIN Policy Development Process is available at: > > https://www.arin.net/policy/pdp.html > > > > Regards, > > > > Communications and Member Services > > American Registry for Internet Numbers (ARIN) > > > > > > > > Recommended Draft Policy ARIN-2016-6: Eliminate HD-Ratio from NRPM > > > > AC's assessment of conformance with the Principles of Internet Number > > Resource Policy: > > > > This proposal is technically sound and enables fair and impartial number > > policy by reducing any confusion caused by HD-Ratio remaining in the > NRPM. > > According to the staff and legal assessment, these changes align with > > current practice of ARIN staff. There is support and no concerns have > been > > raised by the community regarding this proposal on PPML. > > > > Problem Statement: > > > > The HD-Ratio has become an anachronism in the NRPM and some of the > vestigial > > references to it create confusion about recommended prefix sizes for IPv6 > > resulting in a belief in the community that ARIN endorses the idea of > /56s > > as a unit of measure in IPv6 assignments. While there are members of the > > community that believe a /56 is a reasonable choice, ARIN policy has > always > > allowed and still supports /48 prefixes for any and all end-sites without > > need for further justification. More restrictive choices are still > permitted > > under policy as well. This proposal does not change that, but it > attempts to > > eliminate some possible confusion. > > > > The last remaining vestigial references to HD-Ratio are contained in the > > community networks policy (Section 6.5.9). This policy seeks to replace > > 6.5.9 with new text incorporating end user policy by reference (roughly > > equivalent to the original intent of 6.5.9 prior to the more recent > changes > > to end-user policy). While this contains a substantial rewrite to the > > Community Networks policy, it will not have any negative impact on > community > > networks. It may increase the amount of IPv6 space a community network > could > > receive due to the change from HD-Ratio, but not more than any other > similar > > sized end-user would receive under existing policy. > > > > Policy statement: > > > > Replace section 6.5.9 in its entirety as follows: > > > > 6.5.9 Community Network Assignments > > > > 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 > them > > to use end-user criteria. > > > > 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. > > > > 6.5.9.2 Receiving Resources > > > > Once qualified under this section, a community network shall be treated > as > > an end-user assignment for all ARIN purposes. > > > > Community networks shall be eligible under this section only for IPv6 > > resources and the application process and use of those resources shall be > > governed by the existing end-user policy contained in section 6.5.8 et. > seq. > > > > Community networks seeking other resources shall remain subject to the > > policies governing those resources independent of their election to use > this > > policy for IPv6 resources. > > > > Delete section 2.8 ? This section is non-operative and conflicts with the > > definitions of utilization contained in current policies. > > > > Delete section 2.9 ? This section is no longer operative. > > > > Delete section 6.7 ? This section is no longer applicable. > > > > Comments: > > > > Timetable for implementation: Immediate > > > > Anything else > > > > Originally, I thought this would be an editorial change as the HD-Ratio > has > > been unused for several years. > > > > However, further research revealed that it is still referenced in the > > Community Networks policy which has also gone unused since its > inception. As > > a result, I am going to attempt to simultaneously simplify the Community > > Networks policy while preserving its intent and eliminate the HD-Ratio > from > > the NRPM. > > > > I realize that fees are out of scope for policy, however, in this case, > we > > are not setting fees. We are addressing in policy which fee structure the > > given policy should operate under in a manner which does not constrain > board > > action on actual fees. > > > > This is an attempt to preserve the original intent of the Community > networks > > policy in a way that may make it less vestigial. > > > > Alternatively, we could simply delete Section 6.5.9 if that is preferred. > > The primary goal here is to get rid of vestigial reference to HD-Ratio > > rather than to get wrapped around the axle on community networks. > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjones at vt.edu Wed Nov 2 14:26:33 2016 From: bjones at vt.edu (Brian Jones) Date: Wed, 02 Nov 2016 18:26:33 +0000 Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2016-1: Reserved Pool Transfer Policy In-Reply-To: <58111DAF.9070706@arin.net> References: <58111DAF.9070706@arin.net> Message-ID: Support with the changes concerning the reserved pool. On Wed, Oct 26, 2016 at 5:18 PM ARIN wrote: > The ARIN Advisory Council (AC) met on 21 October 2016 and decided to > send Recommended Draft Policy ARIN-2016-1: Reserved Pool Transfer Policy > to Last Call: > > The AC provided the following statement to the community: > > This proposal is technically sound and enables fair and impartial number > policy by ensuring that the number resources are used in accordance with > the terms under which they were granted. There is significant support > for this change within the Internet community. Re: Merge into 2016-5. > The new text "Address resources from a reserved pool (including those > designated in Section 4.4 and 4.10) are not eligible for transfer." > should be added to the revised 2016-5 sections 8.3 & 8.4 "Conditions on > source of the transfer:?. > > Feedback is encouraged during the Last Call period. All comments should > be provided to the Public Policy Mailing List. This Last Call will > expire on 9 November 2016. After Last Call, the AC will conduct their > Last Call review. > > The full text is below and available at: > https://www.arin.net/policy/proposals/ > > The ARIN Policy Development Process is available at: > https://www.arin.net/policy/pdp.html > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > > Recommended Draft Policy ARIN-2016-1: Reserved Pool Transfer Policy > > AC assessment of conformance with the Principles of Internet Number > Resource Policy: > > This proposal enables fair and impartial number resource administration > by ensuring that IPv4 resources, which are specially designated for > critical infrastructure and IPv6 transition, are readily available for > many years into the future. This is done by ensuring the resources > remain in their originally designated pool rather than being moved into > the general IPv4 address pool via a transfer. This proposal is > technically sound and is supported by the community. > > Problem Statement: > > Section 8 of the current NRPM does not distinguish between the transfer > of blocks from addresses that have been reserved for specific uses and > other addresses that can be transferred. In sections 4.4 and 4.10 there > are specific address blocks set aside, based on the need for critical > infrastructure and IPv6 transitions. Two issues arise if transfers of > reserved address space occur under the current language of section 8. > First, if transfers of 4.4 or 4.10 space occur under the current policy > requirements set forth in sections 8.3 and 8.4, the recipients will be > able to acquire space that was originally reserved for a specific > purpose without ever providing evidence that they will be using the > space for either critical infrastructure or IPv6 transition. Second, if > we allow an allocation or assignment from the block reserved in section > 4.10 to be transferred out of the region, it would complicate the single > aggregate from which providers are being asked to allow in block sizes > smaller than a /24. This policy would limit the transfer of addresses > from reserved pools. > > Policy statement: > > Add to Section 8.3 and Section 8.4 under the "Conditions on source of > the transfer:" > > Address resources from a reserved pool (including those designated in > Section 4.4 and 4.10) are not eligible for transfer. > > Timetable for implementation: Immediate > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjones at vt.edu Wed Nov 2 14:27:55 2016 From: bjones at vt.edu (Brian Jones) Date: Wed, 02 Nov 2016 18:27:55 +0000 Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2016-2: Change timeframes for IPv4 requests to 24 months In-Reply-To: <58111CD1.5070207@arin.net> References: <58111CD1.5070207@arin.net> Message-ID: Support. On Wed, Oct 26, 2016 at 5:15 PM ARIN wrote: > The ARIN Advisory Council (AC) met on 21 October 2016 and decided to > send Recommended Draft Policy ARIN-2016-2: Change timeframes for IPv4 > requests to 24 months to Last Call: > > The AC provided the following statement to the community: > > ARIN 2016-2: "Change timeframes for IPv4 requests to 24 months" > contributes to fair and impartial number resource administration by > standardizing time frames for requests throughout the NRPM. This will > streamline procedures for all new requests. The proposal has received a > favorable community response on PPML, and at ARIN38 it was well > supported and did not generate any opposition. > > Feedback is encouraged during the Last Call period. All comments should > be provided to the Public Policy Mailing List. This Last Call will > expire on 9 November 2016. After Last Call, the AC will conduct their > Last Call review. > > The full text is below and available at: > https://www.arin.net/policy/proposals/ > > The ARIN Policy Development Process is available at: > https://www.arin.net/policy/pdp.html > > Regards, > > Communications and Member Services > American Registry for Internet Numbers (ARIN) > > > > Recommended Draft Policy ARIN-2016-2: Change timeframes for IPv4 > requests to 24 months > > AC's assessment of conformance with the Principles of Internet Number > Resource Policy: > > 2016-2 is one of a set of overlapping policies involving simplification > of section 8 specified transfer policy. Each takes a somewhat different > approach, and all have a degree of community support. Based on community > feedback at the upcoming ARIN 38 meeting in Dallas, we hope to advance > whichever of those proposals is best-supported by the community, or > craft and advance a unified proposal that incorporates the best > attributes of the proposals currently on the docket. Moving 2016-2 to > Recommended Draft will facilitate moving the best policy forward in a > timely manner. > > Problem Statement: > > Disparity in timeframes between pre-approvals for waiting list and > pre-approval for transfers is creating difficulties for organizations > that initially apply to be on the waiting list and subsequently elect to > satisfy their needs through transfers. Therefore, this proposal seeks to > set all timeframes for IPv4 request approvals to 24 months. Prior to > runout, such a change could have created great disparity in resource > distribution just because of coincidence of request timing. With the > free pool gone, this is no longer an issue. > > Policy statement: > > The following changes would be made in the NRPM: > > 1. Retitle section 4.2.2.1.3 ?Three months? to ?Time Horizon?. > > 2. Section 4.2.2.1.3 body, replace ?three months? with ?24 months?. > > 3. Section 4.2.3.8, replace the term ?three months? with ?24 months?. > > 4. Section 4.3.3, replace both instances of ?one year? with ?24 months?. > > 5. Section 4.2.4.3, replace the entire paragraph which currently reads: > "ISPs may request up to a 3-month supply of IPv4 addresses from ARIN, or > a 24-month supply via 8.3 or 8.4 transfer. Determination of the > appropriate allocation to be issued is based on efficient utilization of > space within this time frame, consistent with the principles in 4.2.1.? > > with: > > ?ISPs may request up to a 24-month supply of IPv4 addresses.? > > Comments: > > a. Timetable for implementation: Immediate > > b. Clarification of intent - This policy would not affect the existing > waiting list in any way. This policy would simply change the > qualification period to 24 months, so new entrants can go to either the > bottom of the waiting list or to the transfer market to seek their > 24-month supply. If an existing entity on the waiting list wants to > re-qualify and expand their request to a 24-month supply, they would go > to the end of the list. Otherwise, they would remain on the waiting list > with the original approved block size unchanged. If the organization's > needs have changed by the time IPv4 space becomes available to fill > waiting list requests, the organization will be re-qualified under the > new more lenient 24-month standard, but regardless of re-qualification, > the organization will not be eligible to receive a larger block than > they originally qualified for when they were placed on the waiting list. > > > _______________________________________________ > 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 bcornett at servlet.com Wed Nov 2 14:49:24 2016 From: bcornett at servlet.com (Bruce Cornett) Date: Wed, 02 Nov 2016 14:49:24 -0400 Subject: [arin-ppml] LAST CALL for Recommended Draft Policy ARIN-2016-4: Transfers for new entrants In-Reply-To: References: <58111D82.2040301@arin.net> Message-ID: <581A3534.9050805@servlet.com> Support as proposed. Bruce C On 11/02/2016 02:19 PM, Brian Jones wrote: > Support. > > On Wed, Nov 2, 2016 at 1:57 PM Chris Woodfield > wrote: > > Support as proposed. > > -C > > > On Oct 26, 2016, at 2:17 PM, ARIN > wrote: > > > > The ARIN Advisory Council (AC) met on 21 October 2016 and decided > to send Recommended Draft Policy ARIN-2016-4: Transfers for new > entrants to Last Call: > > > > The AC provided the following statement to the community: > > > > This proposal is technically sound and enables fair and impartial > number policy. There is support for this policy in the ARIN > community as expressed at ARIN 38 and on PPML. There has been no > opposition stated to 2016-4. At the ARIN AC meeting held on > 10/21/2016, it was agreed that in the "Anything else" section of > Recommended Draft Policy 2016-4 stating that 'The text in 4.2.2 ?for > specified transfers, or three months otherwise? and the text in > 4.3.3 ?for specified transfers, or 12 months otherwise? should be > stricken if ARIN-prop-227 is adopted' should be followed by ARIN > staff as an instruction from the AC, presuming that 2016-2 (which is > what ARIN-prop-227 has become) continues to move forward after last > call. > > > > Feedback is encouraged during the Last Call period. All comments > should be provided to the Public Policy Mailing List. This Last Call > will expire on 9 November 2016. After Last Call, the AC will conduct > their Last Call review. > > > > The full text is below and available at: > > https://www.arin.net/policy/proposals/ > > > > The ARIN Policy Development Process is available at: > > https://www.arin.net/policy/pdp.html > > > > Regards, > > > > Communications and Member Services > > American Registry for Internet Numbers (ARIN) > > > > > > > > > > ARIN-2016-4: Transfers for new entrants > > > > AC assessment of conformance with the Principles of Internet > Number Resource Policy: > > > > The proposal is technically sound and enables fair and impartial > number policy by ensuring that new organizations have a mechanism to > access at least a minimum amount of resources from the transfer > market. The staff and legal review (as updated 8/19/2016) is > non-controversial. There is support and no concerns have been raised > by the community regarding the proposal on PPML or elsewhere. > > > > 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. Now that ARIN?s free pool is exhausted, > 4.2.1.6. Immediate need states that ?These cases are exceptional?, > but that is no longer correct. End user organizations requiring less > a /24 of address space may also be unable to acquire space from > their upstream ISP, and may instead need to receive a /24 from ARIN > via transfer. > > > > Policy statement: > > > > 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. > > > > Replace Section 4.3.2 to read: > > > > 4.3.2 Minimum assignment > > > > ARIN?s minimum assignment for end-user organizations is a /24. > > > > End-user organizations without direct assignments or allocations > from ARIN qualify for an initial assignment of ARIN?s minimum > assignment size. > > > > Replace the first two sentences of Section 4.3.3. Utilization > rate to read: > > > > Organizations may qualify for a larger initial allocation by > providing appropriate details to verify their 24-month growth > projection for specified transfers, or 12 months otherwise. > > > > Resulting new section 4.3.3 will be: > > > > Organizations may qualify for a larger initial allocation, by > providing appropriate details to verify their 24-month growth > projection for specified transfers, or 12 months otherwise. > > > > The basic criterion that must be met is a 50% utilization rate > within one year. > > > > A greater utilization rate may be required based on individual > network requirements. > > > > Comments: > > > > Timetable for implementation: Immediate > > > > Anything else > > > > The text in 4.2.2 ?for specified transfers, or three months > otherwise? and the text in 4.3.3 ?for specified transfers, or 12 > months otherwise? should be stricken if ARIN-prop-227 is adopted. > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net > ). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you > experience any issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net > ). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you > experience any issues. > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From narten at us.ibm.com Fri Nov 4 00:53:03 2016 From: narten at us.ibm.com (narten at us.ibm.com) Date: Fri, 04 Nov 2016 00:53:03 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201611040453.uA44r355007873@rotala.raleigh.ibm.com> Total of 11 messages in the last 7 days. script run at: Fri Nov 4 00:53:03 EDT 2016 Messages | Bytes | Who --------+------+--------+----------+------------------------ 36.36% | 4 | 47.80% | 87127 | bjones at vt.edu 18.18% | 2 | 12.54% | 22862 | rbf+arin-ppml at panix.com 9.09% | 1 | 11.46% | 20892 | rjletts at uw.edu 9.09% | 1 | 10.76% | 19611 | sryerse at eclipse-networks.com 9.09% | 1 | 6.93% | 12636 | bcornett at servlet.com 9.09% | 1 | 5.77% | 10525 | chris at semihuman.com 9.09% | 1 | 4.73% | 8624 | narten at us.ibm.com --------+------+--------+----------+------------------------ 100.00% | 11 |100.00% | 182277 | Total From bill at herrin.us Fri Nov 4 18:50:04 2016 From: bill at herrin.us (William Herrin) Date: Fri, 4 Nov 2016 18:50:04 -0400 Subject: [arin-ppml] re-org question Message-ID: Hi Folks, I have an NRPM 8.2 question for you. One of the orgs I work with is contemplating a reorganization in which the IT support group and all of its assets will be split off in to a wholly owned subsidiary. One of these assets is a legacy /16. As I read the last paragraph in NRPM section 8.2, in order for the /16 to be recorded under the new subsidiary's name, the subsidiary would have to sign an RSA, renumber the otherwise unchanging network infrastructure to meet ARIN's current efficiency standards and return or sell the excess IP addresses. Am I actually reading that right? Semi-related question: Does ARIN publish anywhere which RIRs it deems to "share reciprocal, compatible, needs-based policies" under section 8.4? Thanks, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From daveid at panix.com Fri Nov 4 21:17:50 2016 From: daveid at panix.com (David R Huberman) Date: Fri, 4 Nov 2016 21:17:50 -0400 (EDT) Subject: [arin-ppml] re-org question In-Reply-To: References: Message-ID: > As I read the last paragraph in NRPM section 8.2, in order for the /16 > to be recorded under the new subsidiary's name, the subsidiary would > have to sign an RSA, renumber the otherwise unchanging network > infrastructure to meet ARIN's current efficiency standards and return > or sell the excess IP addresses. > > Am I actually reading that right? No. You are drawing a conclusion not supported by either the text or by many years of practice. The /16 can be transferred as-is. ARIN has been given no power in the NRPM to coerce a renumbering, return, exchange, or anything else. From bill at herrin.us Fri Nov 4 21:28:20 2016 From: bill at herrin.us (William Herrin) Date: Fri, 4 Nov 2016 21:28:20 -0400 Subject: [arin-ppml] re-org question In-Reply-To: References: Message-ID: On Fri, Nov 4, 2016 at 9:17 PM, David R Huberman wrote: > >> As I read the last paragraph in NRPM section 8.2, in order for the /16 >> to be recorded under the new subsidiary's name, the subsidiary would >> have to sign an RSA, renumber the otherwise unchanging network >> infrastructure to meet ARIN's current efficiency standards and return >> or sell the excess IP addresses. >> >> Am I actually reading that right? > > > No. You are drawing a conclusion not supported by either the text or by many > years of practice. The /16 can be transferred as-is. ARIN has been given no > power in the NRPM to coerce a renumbering, return, exchange, or anything > else. Hi David, For clarity's sake, here's the text, emphasis mine: https://www.arin.net/policy/nrpm.html#eight2 "ARIN will proceed with processing transfer requests even if the number resources of the combined organizations EXCEED WHAT CAN BE JUSTIFIED UNDER CURRENT ARIN POLICY. IN THAT EVENT, ARIN will work with the resource holder(s) to transfer the extra number resources to other organization(s) or accept a voluntary return of the extra number resources to ARIN." I don't see an "or let you keep the extra number resources' in there. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From daveid at panix.com Fri Nov 4 21:35:53 2016 From: daveid at panix.com (David R Huberman) Date: Fri, 4 Nov 2016 21:35:53 -0400 (EDT) Subject: [arin-ppml] re-org question In-Reply-To: References: Message-ID: > "ARIN will proceed with processing transfer requests even if the > number resources of the combined organizations EXCEED WHAT CAN BE > JUSTIFIED UNDER CURRENT ARIN POLICY. IN THAT EVENT, ARIN will work > with the resource holder(s) to transfer the extra number resources to > other organization(s) or accept a voluntary return of the extra number > resources to ARIN." > > I don't see an "or let you keep the extra number resources' in there. Correct. You also don't see a MUST in the context of MUST transfer or MUST return. The RSA forbids it, and the community has never given ARIN such power in policy. The AC has tried to fix this text a few times, and perhaps we haven't done a good enough job. From bill at herrin.us Fri Nov 4 21:53:52 2016 From: bill at herrin.us (William Herrin) Date: Fri, 4 Nov 2016 21:53:52 -0400 Subject: [arin-ppml] re-org question In-Reply-To: References: Message-ID: On Fri, Nov 4, 2016 at 9:35 PM, David R Huberman wrote: >> "ARIN will proceed with processing transfer requests even if the >> number resources of the combined organizations EXCEED WHAT CAN BE >> JUSTIFIED UNDER CURRENT ARIN POLICY. IN THAT EVENT, ARIN will work >> with the resource holder(s) to transfer the extra number resources to >> other organization(s) or accept a voluntary return of the extra number >> resources to ARIN." >> >> I don't see an "or let you keep the extra number resources' in there. > > Correct. You also don't see a MUST in the context of MUST transfer or MUST > return. The RSA forbids it, and the community has never given ARIN such > power in policy. David, It's a public policy document. In the absence of language to the contrary, the MUST is implied. And if it's not a MUST then it's operational guidance that doesn't belong in a POLICY document at all. > The AC has tried to fix this text a few times, and perhaps we haven't done a > good enough job. You think? Regards, Bill -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From daveid at panix.com Fri Nov 4 22:01:40 2016 From: daveid at panix.com (David R Huberman) Date: Fri, 4 Nov 2016 22:01:40 -0400 (EDT) Subject: [arin-ppml] re-org question In-Reply-To: References: Message-ID: > It's a public policy document. In the absence of language to the > contrary, the MUST is implied. And if it's not a MUST then it's > operational guidance that doesn't belong in a POLICY document at all. Probably, yes. Nevertheless, the MUST is not there and is not implied. And I fully agree on the sentence not belonging there, because a reasonable reading includes the implication. From owen at delong.com Fri Nov 4 22:01:59 2016 From: owen at delong.com (Owen DeLong) Date: Fri, 4 Nov 2016 19:01:59 -0700 Subject: [arin-ppml] re-org question In-Reply-To: References: Message-ID: <452BE3ED-0C95-4D1D-BA40-DE8CDE6AB47E@delong.com> > On Nov 4, 2016, at 18:35 , David R Huberman wrote: > > >> "ARIN will proceed with processing transfer requests even if the >> number resources of the combined organizations EXCEED WHAT CAN BE >> JUSTIFIED UNDER CURRENT ARIN POLICY. IN THAT EVENT, ARIN will work >> with the resource holder(s) to transfer the extra number resources to >> other organization(s) or accept a voluntary return of the extra number >> resources to ARIN." >> >> I don't see an "or let you keep the extra number resources' in there. > > Correct. You also don't see a MUST in the context of MUST transfer or MUST return. The RSA forbids it, and the community has never given ARIN such power in policy. > > The AC has tried to fix this text a few times, and perhaps we haven't done a good enough job. Perhaps, in part, because some of us think that the RSA is what is broken rather than the language in the policy. The intent of the community, despite the board?s and staff?s future actions to the contrary was that an 8.2 transfer would force signing an RSA. Owen From bill at herrin.us Fri Nov 4 22:11:29 2016 From: bill at herrin.us (William Herrin) Date: Fri, 4 Nov 2016 22:11:29 -0400 Subject: [arin-ppml] re-org question In-Reply-To: <452BE3ED-0C95-4D1D-BA40-DE8CDE6AB47E@delong.com> References: <452BE3ED-0C95-4D1D-BA40-DE8CDE6AB47E@delong.com> Message-ID: On Fri, Nov 4, 2016 at 10:01 PM, Owen DeLong wrote: > Perhaps, in part, because some of us think that the RSA is what is broken rather than the language in the policy. Owen, Really? You think ARIN policy should be that folks are required to renumber just because of a business transaction involving the owner of the physical network using them? 'Cause if you don't think that then maybe let's get that stray sentence the heck out of there. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From owen at delong.com Fri Nov 4 22:28:19 2016 From: owen at delong.com (Owen DeLong) Date: Fri, 4 Nov 2016 19:28:19 -0700 Subject: [arin-ppml] re-org question In-Reply-To: References: <452BE3ED-0C95-4D1D-BA40-DE8CDE6AB47E@delong.com> Message-ID: <59083B6E-A081-4F8C-BD40-D1C1DA92A1E9@delong.com> > On Nov 4, 2016, at 19:11 , William Herrin wrote: > > On Fri, Nov 4, 2016 at 10:01 PM, Owen DeLong wrote: >> Perhaps, in part, because some of us think that the RSA is what is broken rather than the language in the policy. > > Owen, > > Really? You think ARIN policy should be that folks are required to > renumber just because of a business transaction involving the owner of > the physical network using them? Nowhere does it say you are required to renumber. You?re reading that into things. It says that if the combined organization can not justify the combined resources, that ARIN will work with them on appropriate transfers, and/or returns. Renumbering is entirely optional, though may often be the simplest course. > 'Cause if you don't think that then maybe let's get that stray > sentence the heck out of there. Please point me to the stray sentence about renumbering first. I?m just not seeing it in the policy. Owen From bill at herrin.us Fri Nov 4 22:33:45 2016 From: bill at herrin.us (William Herrin) Date: Fri, 4 Nov 2016 22:33:45 -0400 Subject: [arin-ppml] re-org question In-Reply-To: <59083B6E-A081-4F8C-BD40-D1C1DA92A1E9@delong.com> References: <452BE3ED-0C95-4D1D-BA40-DE8CDE6AB47E@delong.com> <59083B6E-A081-4F8C-BD40-D1C1DA92A1E9@delong.com> Message-ID: On Fri, Nov 4, 2016 at 10:28 PM, Owen DeLong wrote: >> On Nov 4, 2016, at 19:11 , William Herrin wrote: >> On Fri, Nov 4, 2016 at 10:01 PM, Owen DeLong wrote: >>> Perhaps, in part, because some of us think that the RSA is what is broken rather than the language in the policy. >> >> Owen, >> Really? You think ARIN policy should be that folks are required to >> renumber just because of a business transaction involving the owner of >> the physical network using them? > > Nowhere does it say you are required to renumber. You?re reading that into things. > > It says that if the combined organization can not justify the combined resources, that ARIN will work with them on appropriate transfers, and/or returns. Owen, You're going to have to explain that particular magic to me because I haven't heard of any way to free up netblocks for return other than renumbering out of them. Sure, an org might possibly have vast amounts of unrouted address space they're just not using with all the addresses they are using carefully crammed into an efficient /24 but what's your plan for everybody else? Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From bill at herrin.us Fri Nov 4 22:37:24 2016 From: bill at herrin.us (William Herrin) Date: Fri, 4 Nov 2016 22:37:24 -0400 Subject: [arin-ppml] re-org question In-Reply-To: References: Message-ID: On Fri, Nov 4, 2016 at 10:01 PM, David R Huberman wrote: > >> It's a public policy document. In the absence of language to the >> contrary, the MUST is implied. And if it's not a MUST then it's >> operational guidance that doesn't belong in a POLICY document at all. > > Nevertheless, the MUST is not there and is not implied. Hi David, The language was introduced in draft policy 2010-6 whose rationale stated: "This policy also should dramatically increase the completion rate for transfer requests, as the evaluation of whether space is efficiently utilized after the transfer can occur in parallel, completely independently of the transfer request, and can continue even if the transfer request is abandoned." Still think renumbering to achieve efficient utilization as a consequence of the 8.2 transfer wasn't intended to be a requirement? Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From daveid at panix.com Fri Nov 4 22:42:40 2016 From: daveid at panix.com (David R Huberman) Date: Fri, 4 Nov 2016 22:42:40 -0400 (EDT) Subject: [arin-ppml] re-org question In-Reply-To: References: Message-ID: > The language was introduced in draft policy 2010-6 whose rationale stated: > > "This policy also should dramatically increase the completion rate for > transfer requests, as the evaluation of whether space is efficiently > utilized after the transfer can occur in parallel, completely > independently of the transfer request, and can continue even if the > transfer request is abandoned." > > Still think renumbering to achieve efficient utilization as a > consequence of the 8.2 transfer wasn't intended to be a requirement? I don't know for sure. I was answering your question with objective fact, to help you help your client make an informed decision. From owen at delong.com Fri Nov 4 22:45:50 2016 From: owen at delong.com (Owen DeLong) Date: Fri, 4 Nov 2016 19:45:50 -0700 Subject: [arin-ppml] re-org question In-Reply-To: References: <452BE3ED-0C95-4D1D-BA40-DE8CDE6AB47E@delong.com> <59083B6E-A081-4F8C-BD40-D1C1DA92A1E9@delong.com> Message-ID: > On Nov 4, 2016, at 19:33 , William Herrin wrote: > > On Fri, Nov 4, 2016 at 10:28 PM, Owen DeLong wrote: >>> On Nov 4, 2016, at 19:11 , William Herrin wrote: >>> On Fri, Nov 4, 2016 at 10:01 PM, Owen DeLong wrote: >>>> Perhaps, in part, because some of us think that the RSA is what is broken rather than the language in the policy. >>> >>> Owen, >>> Really? You think ARIN policy should be that folks are required to >>> renumber just because of a business transaction involving the owner of >>> the physical network using them? >> >> Nowhere does it say you are required to renumber. You?re reading that into things. >> >> It says that if the combined organization can not justify the combined resources, that ARIN will work with them on appropriate transfers, and/or returns. > > Owen, > > You're going to have to explain that particular magic to me because I > haven't heard of any way to free up netblocks for return other than > renumbering out of them. If you?re using 50%, you pretty much meet current guidelines, so really very little problem. If you?ve got a /16 and you?ve got /28s all over it, yeah, you?ll probably have to do some consolidation (renumbering) of some of the networks. If you?ve got a /16 and you?re using most of the first /18, then no problem with returning the last /17 and (if needed) the second /18. > Sure, an org might possibly have vast amounts of unrouted address > space they're just not using with all the addresses they are using > carefully crammed into an efficient /24 but what's your plan for > everybody else? There?s a lot of ground in between those two extremes. In the vast majority of cases I?ve encountered, minimal renumbering can free up more than enough space to return to satisfy policy. Owen From bill at herrin.us Fri Nov 4 22:52:03 2016 From: bill at herrin.us (William Herrin) Date: Fri, 4 Nov 2016 22:52:03 -0400 Subject: [arin-ppml] re-org question In-Reply-To: References: <452BE3ED-0C95-4D1D-BA40-DE8CDE6AB47E@delong.com> <59083B6E-A081-4F8C-BD40-D1C1DA92A1E9@delong.com> Message-ID: On Fri, Nov 4, 2016 at 10:45 PM, Owen DeLong wrote: >>> Nowhere does it say you are required to renumber. You?re reading that into things. > In the vast majority of cases I?ve encountered, minimal renumbering can free up more than > enough space to return to satisfy policy. Owen, Minimal renumbering is still renumbering. Especially if there's some minority where the renumbering isn't minimal. The policy's renumbering requirement was there all along; I didn't insert it or "read it into things." Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From owen at delong.com Fri Nov 4 22:55:12 2016 From: owen at delong.com (Owen DeLong) Date: Fri, 4 Nov 2016 19:55:12 -0700 Subject: [arin-ppml] re-org question In-Reply-To: References: <452BE3ED-0C95-4D1D-BA40-DE8CDE6AB47E@delong.com> <59083B6E-A081-4F8C-BD40-D1C1DA92A1E9@delong.com> Message-ID: <32251EA0-0991-4979-A117-25B9FF6CC14E@delong.com> You can return as small as a /24. If you?re using half, then you can keep it. So, at most, you have to renumber 126 hosts out of each of half of your /25s. How is this not minimal again? Owen > On Nov 4, 2016, at 19:52 , William Herrin wrote: > > On Fri, Nov 4, 2016 at 10:45 PM, Owen DeLong wrote: >>>> Nowhere does it say you are required to renumber. You?re reading that into things. > >> In the vast majority of cases I?ve encountered, minimal renumbering can free up more than >> enough space to return to satisfy policy. > > Owen, > > Minimal renumbering is still renumbering. Especially if there's some > minority where the renumbering isn't minimal. The policy's renumbering > requirement was there all along; I didn't insert it or "read it into > things." > > Regards, > Bill Herrin > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Owner, Dirtside Systems ......... Web: From bill at herrin.us Fri Nov 4 22:55:45 2016 From: bill at herrin.us (William Herrin) Date: Fri, 4 Nov 2016 22:55:45 -0400 Subject: [arin-ppml] re-org question In-Reply-To: References: Message-ID: On Fri, Nov 4, 2016 at 10:42 PM, David R Huberman wrote: >> The language was introduced in draft policy 2010-6 whose rationale stated: >> "This policy also should dramatically increase the completion rate for >> transfer requests, as the evaluation of whether space is efficiently >> utilized after the transfer can occur in parallel, completely >> independently of the transfer request, and can continue even if the >> transfer request is abandoned." >> >> Still think renumbering to achieve efficient utilization as a >> consequence of the 8.2 transfer wasn't intended to be a requirement? > > I don't know for sure. I was answering your question with objective fact, > to help you help your client make an informed decision. Hi David, I'm sure it will come as a great relief to my client that ARIN probably won't follow its policy as written because no one knows for know for sure whether they really meant it that way. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From bill at herrin.us Fri Nov 4 23:06:22 2016 From: bill at herrin.us (William Herrin) Date: Fri, 4 Nov 2016 23:06:22 -0400 Subject: [arin-ppml] re-org question In-Reply-To: <32251EA0-0991-4979-A117-25B9FF6CC14E@delong.com> References: <452BE3ED-0C95-4D1D-BA40-DE8CDE6AB47E@delong.com> <59083B6E-A081-4F8C-BD40-D1C1DA92A1E9@delong.com> <32251EA0-0991-4979-A117-25B9FF6CC14E@delong.com> Message-ID: On Fri, Nov 4, 2016 at 10:55 PM, Owen DeLong wrote: > You can return as small as a /24. > > If you?re using half, then you can keep it. > > So, at most, you have to renumber 126 hosts out of each of half of your /25s. > > How is this not minimal again? Sorry Owen, I won't engage you with the relocated goal post. If you are correct, the 8.2 transfer language requires a registrant whose addresses are assigned and in use but not efficiently used per ARIN standards to engage some degree of renumbering as consequence of the transfer. -Bill -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From rfg at tristatelogic.com Fri Nov 4 23:54:23 2016 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Fri, 04 Nov 2016 20:54:23 -0700 Subject: [arin-ppml] re-org question In-Reply-To: Message-ID: <62129.1478318063@segfault.tristatelogic.com> In message William Herrin wrote: >Sorry Owen, I won't engage you with the relocated goal post. If you >are correct, the 8.2 transfer language requires a registrant whose >addresses are assigned and in use but not efficiently used per ARIN >standards to engage some degree of renumbering as consequence of the >transfer. You say that like it's a bad thing. https://en.wikipedia.org/wiki/Manspreading See also: Social courtesy, Limited resources From bill at herrin.us Sat Nov 5 00:23:55 2016 From: bill at herrin.us (William Herrin) Date: Sat, 5 Nov 2016 00:23:55 -0400 Subject: [arin-ppml] re-org question In-Reply-To: <62129.1478318063@segfault.tristatelogic.com> References: <62129.1478318063@segfault.tristatelogic.com> Message-ID: On Fri, Nov 4, 2016 at 11:54 PM, Ronald F. Guilmette wrote: > In message > William Herrin wrote: >>Sorry Owen, I won't engage you with the relocated goal post. If you >>are correct, the 8.2 transfer language requires a registrant whose >>addresses are assigned and in use but not efficiently used per ARIN >>standards to engage some degree of renumbering as consequence of the >>transfer. > > You say that like it's a bad thing. Hi Ronald, I say that like I think Owen's diversion to, 'Nowhere does it say you are required to renumber," reeked of cognitive dissonance. Whether I think it's a bad thing for ARIN to dictate that corporate restructuring requires renumbering, as NRPM 8.2 seems to say, returns us to the original conversion. My thoughts on that can be boiled down to three words which start W.T.F. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From michel at arneill-py.sacramento.ca.us Sat Nov 5 17:49:25 2016 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Sat, 5 Nov 2016 21:49:25 +0000 Subject: [arin-ppml] re-org question In-Reply-To: <32251EA0-0991-4979-A117-25B9FF6CC14E@delong.com> References: <452BE3ED-0C95-4D1D-BA40-DE8CDE6AB47E@delong.com> <59083B6E-A081-4F8C-BD40-D1C1DA92A1E9@delong.com> <32251EA0-0991-4979-A117-25B9FF6CC14E@delong.com> Message-ID: I have been reading this thread with the greatest interest because I recently switched jobs and I am facing a similar situation than Bill, except that it has already happenned, we are not even a subsidiary anymore. Long story made short : after decades of merger and acquisitions, my org is operating un-announced address space that has never been transferred. We use eleven contiguous /24s scatterred un the middle of a /16. Re-numbering is NOT an option regardless of the incentive. The org who is assigned the /16 does not reply no my messages. Besides getting these adresses assigned to us by the former parent org, what are my options here ? I do not need the entire /16, so it will have to be broken down into a /21, a /23 and a /24. I don't need the entire /16, what should I do ? Thanks, Michel. From rfg at tristatelogic.com Sat Nov 5 19:51:03 2016 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Sat, 05 Nov 2016 16:51:03 -0700 Subject: [arin-ppml] re-org question In-Reply-To: Message-ID: <66891.1478389863@segfault.tristatelogic.com> In message Michel Py wrote: >Re-numbering is NOT an option regardless of the incentive. I don't want to distract from the point you were making, but I wonder if you might be so kind as to elaborate on the above assertion, e.g. for the benefit of those few poor ignorant sods on this list, such as myself, who might be largely or entirely ignorant of the issues and related difficulties. Regards, rfg From michel at arneill-py.sacramento.ca.us Sat Nov 5 20:47:10 2016 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Sun, 6 Nov 2016 00:47:10 +0000 Subject: [arin-ppml] re-org question In-Reply-To: <66891.1478389863@segfault.tristatelogic.com> References: <66891.1478389863@segfault.tristatelogic.com> Message-ID: >> Michel Py wrote : >> Re-numbering is NOT an option regardless of the incentive. > Ronald F. Guilmette wrote : > I don't want to distract from the point you were making, but I wonder if you might be so kind as to elaborate on the above assertion, e.g. > for the benefit of those few poor ignorant sods on this list, such as myself, who might be largely or entirely ignorant of the issues and related difficulties. I run the network for a foundry. Most of it is configured with static IPs, no DNS, and the hosts they talk to hard-coded in proprietary software. On top of it, half is inside a ISO class I cleanroom and runs 24/7/365. It's a common situation with large infrastructures that are 20 or 30 years old. In the same room, I have 30 different gases and 30 different operating systems. Even if I wanted, I could not renumber. Michel. From dave at connetrix.com Sat Nov 5 20:53:26 2016 From: dave at connetrix.com (Dave Feuer) Date: Sat, 5 Nov 2016 20:53:26 -0400 Subject: [arin-ppml] re-org question In-Reply-To: <66891.1478389863@segfault.tristatelogic.com> References: <66891.1478389863@segfault.tristatelogic.com> Message-ID: <007101d237c8$2ea11060$8be33120$@connetrix.com> Although I don't want to put words in people mouths. Off the top of my head 1) Equipment that is spread far and wide that needs to talk to other equipment that is spread far and wide. If every time you change an IP in 1 router you have to manually hit another dozen it gets to be a disaster very quickly. 2) Legacy apps that have addresses hard coded in them. 3) Legacy hardware that has routes and addresses hard coded in them. -Dave -----Original Message----- From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of Ronald F. Guilmette Sent: Saturday, November 05, 2016 7:51 PM To: arin-ppml at arin.net Subject: Re: [arin-ppml] re-org question In message Michel Py wrote: >Re-numbering is NOT an option regardless of the incentive. I don't want to distract from the point you were making, but I wonder if you might be so kind as to elaborate on the above assertion, e.g. for the benefit of those few poor ignorant sods on this list, such as myself, who might be largely or entirely ignorant of the issues and related difficulties. Regards, rfg _______________________________________________ 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 rfg at tristatelogic.com Sun Nov 6 15:22:56 2016 From: rfg at tristatelogic.com (Ronald F. Guilmette) Date: Sun, 06 Nov 2016 12:22:56 -0800 Subject: [arin-ppml] re-org question In-Reply-To: Message-ID: <71337.1478463776@segfault.tristatelogic.com> In message Michel Py wrote: >>> Michel Py wrote : >>> Re-numbering is NOT an option regardless of the incentive. > >> Ronald F. Guilmette wrote : >> I don't want to distract from the point you were making, but I wonder if >you might be so kind as to elaborate on the above assertion, e.g. >> for the benefit of those few poor ignorant sods on this list, such as mys= >elf, who might be largely or entirely ignorant of the issues and related di= >fficulties. > >I run the network for a foundry. Most of it is configured with static IPs, >no DNS, and the hosts they talk to hard-coded in proprietary software. On >top of it, half is inside a ISO class I cleanroom and runs 24/7/365. >It's a common situation with large infrastructures that are 20 or 30 years >old. In the same room, I have 30 different gases and 30 different operating > systems. Even if I wanted, I could not renumber. Thanks you for providing this answer. It is indeed enlightening. Obviously, I am not at all familiar with any other particulars of your situation. Nor, I should say, am I by any stretch of the imagination a serious or deep networking guy. Nontheless, your elaboration of the problem does cause me to wonder if there isn't any solution to the problem, as you have described it, which would allow all of the equipment within your foundary to continue to use the existing range IP addresses, but to do so behind some sort of a firewall and/or address translation device/mechanism which would hide and isolate all such ``internal'' IPv4 addresses from direct exposure to the public Internet. On my own admittedly tiny network... and also, I suspect, on millions of others like it elsewhere... I route RFC1918 addresses around, you know, internally. But given that none of these internal IPv4 addresses ever interact directly with the public Internet, my internal-only use of these addresses quite obviously causes no problems for anyone, least of all me. In fact I sleep better at night knowing that, as a practical matter, regardless of the numbers or kinds of software bugs in my internal devices, random outsiders cannot directly access or exploit these devices. (And since some of my devices are running older and unmaintained software this seems to be a rather big plus as far as I am concerned.) Regards, rfg From mpetach at netflight.com Sun Nov 6 15:47:13 2016 From: mpetach at netflight.com (Matthew Petach) Date: Sun, 6 Nov 2016 12:47:13 -0800 Subject: [arin-ppml] re-org question In-Reply-To: <32251EA0-0991-4979-A117-25B9FF6CC14E@delong.com> References: <452BE3ED-0C95-4D1D-BA40-DE8CDE6AB47E@delong.com> <59083B6E-A081-4F8C-BD40-D1C1DA92A1E9@delong.com> <32251EA0-0991-4979-A117-25B9FF6CC14E@delong.com> Message-ID: On Fri, Nov 4, 2016 at 7:55 PM, Owen DeLong wrote: > You can return as small as a /24. > > If you?re using half, then you can keep it. > > So, at most, you have to renumber 126 hosts out of each of half of your /25s. > > How is this not minimal again? > > Owen I suspect Owen is trolling for effect here. Renumbering 126 hosts out of 255 is only slightly less than half. I'm guessing Owen would be unhappy, were he to be told by his doctor that he needed a surgical operation in which a minimal amount of his body mass would be removed; but upon delving deeper, found that the doctor would be removing slightly less than half his body. Using the term "minimal" to apply to renumbering nearly half a block strays well past the realm of 'stretching the definition' into the neighborhood of 'trolling'. If the community does indeed think the language should stay, and that renumbering should be required, we should perhaps put some clarity around what is expected. If an organization is using 40% of each /24, would the ARIN community be happy if the organization renumbered such that alternating /24s were now 80% filled, and returned every other /24 to ARIN, as individual /24 subnets? That would meet the letter of the law, so to speak, but would ensure those blocks could never be aggregated into a larger allocation. (As a side note, this could be a good way to ensure a steady supply of /24s for small entrants, while ensuring no larger entity can ever make use of them.) For the record, I think the sentence is confusing, and should have the "will" replaced with "may", to read as follows: "ARIN will proceed with processing transfer requests even if the number resources of the combined organizations exceed what can be justified under current ARIN policy. In that event, ARIN *may* work with the resource holder(s) to transfer the extra number resources to other organization(s) or accept a voluntary return of the extra number resources to ARIN." emphasis on *may* included only to make it clear which word was changed; emphasis need not stay in the resulting NRPM text. That should clear up confusion about it being a requirement, and instead make it clear this is an optional exercise. Thanks! Matt From owen at delong.com Sun Nov 6 16:08:07 2016 From: owen at delong.com (Owen DeLong) Date: Sun, 6 Nov 2016 13:08:07 -0800 Subject: [arin-ppml] re-org question In-Reply-To: References: <452BE3ED-0C95-4D1D-BA40-DE8CDE6AB47E@delong.com> <59083B6E-A081-4F8C-BD40-D1C1DA92A1E9@delong.com> <32251EA0-0991-4979-A117-25B9FF6CC14E@delong.com> Message-ID: <23D2F23E-98FC-4E1A-B7E2-3CE98BB5C4AF@delong.com> > On Nov 6, 2016, at 12:47 , Matthew Petach wrote: > > On Fri, Nov 4, 2016 at 7:55 PM, Owen DeLong wrote: >> You can return as small as a /24. >> >> If you?re using half, then you can keep it. >> >> So, at most, you have to renumber 126 hosts out of each of half of your /25s. >> >> How is this not minimal again? >> >> Owen > > > I suspect Owen is trolling for effect here. No, not really. > > Renumbering 126 hosts out of 255 is only > slightly less than half. Sure, but that?s the absolute worst case and it only remains true if he has managed to inefficiently use every single /24 in his entire address block. > I'm guessing Owen would be unhappy, were he to be > told by his doctor that he needed a surgical operation > in which a minimal amount of his body mass would be > removed; but upon delving deeper, found that the > doctor would be removing slightly less than half his > body. It would probably depend on which pieces, but Owen is unusually obese and so probably has more tissue than the average person he would be willing to part with. Nonetheless, your point is made. However, see above? Using the absolute worst possible case of the worst possible choices made in the past is probably similarly atypical as an exemplar. > Using the term "minimal" to apply to renumbering > nearly half a block strays well past the realm of > 'stretching the definition' into the neighborhood of > 'trolling?. But that?s also not likely to be the case. > If the community does indeed think the language > should stay, and that renumbering should be required, > we should perhaps put some clarity around what is > expected. If an organization is using 40% of each /24, > would the ARIN community be happy if the organization > renumbered such that alternating /24s were now 80% > filled, and returned every other /24 to ARIN, as individual > /24 subnets? That would meet the letter of the law, so > to speak, but would ensure those blocks could never > be aggregated into a larger allocation. (As a side note, > this could be a good way to ensure a steady supply of /24s > for small entrants, while ensuring no larger entity can ever > make use of them.) I suspect that at this time, the community is unlikely to come to a sufficient consensus in either direction and thus the existing language remains despite multiple attempts to change it in either direction. > For the record, I think the sentence is confusing, and > should have the "will" replaced with "may", to read as > follows: > > "ARIN will proceed with processing transfer requests even if the > number resources of the combined organizations exceed what > can be justified under current ARIN policy. In that event, ARIN *may* work > with the resource holder(s) to transfer the extra number resources to > other organization(s) or accept a voluntary return of the extra number > resources to ARIN.? So you want it to be optional for ARIN to work with the resource holder, but the resource holder is still required to return the space under section 12 and other parts of section 4? I am confused by this desire. > emphasis on *may* included only to make it clear which word > was changed; emphasis need not stay in the resulting NRPM > text. That should clear up confusion about it being a requirement, > and instead make it clear this is an optional exercise. Not the way you worded it, but at least now I understand your actual intent. You?ll need to hack up a lot more of the NRPM than 8.2 to achieve that desired result. Owen From michel at arneill-py.sacramento.ca.us Sun Nov 6 17:23:40 2016 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Sun, 6 Nov 2016 22:23:40 +0000 Subject: [arin-ppml] re-org question In-Reply-To: References: Message-ID: > William Herrin wrote : > As I read the last paragraph in NRPM section 8.2, in order for the /16 to be recorded under the new subsidiary's name, the subsidiary would have to sign > an RSA, renumber the otherwise unchanging network infrastructure to meet ARIN's current efficiency standards and return or sell the excess IP addresses. Bill, If I may say so, the subsidiary has no choice but to sign the RSA and I say so as inherited one that was split from the parent org the alternative way. Here's the typical path : the parent org does not want to sign the RSA because it costs time, money, paperwork, and generates some additional annoyances. A verbal agreement is made between the parent org and the newly created subsidiary that the subsidiary gets whatever subset of the /16 they were using for their operations, and everyone is happy especially senior management who sees all this complications about IP addresses an obstruction to the reasons they want to split. The /16 remains legacy and everyone is happy. All is fine for a little bit, but then the subsidiary changes plans, people move, retire, go work for the competition, boths sides go through other corporate mergers and acquisitions, and the subsidiary is left with nothing. If you are seeking a fair deal for both parties, do it the ARIN way. Now, if the parent org spins the subsidiary with the idea of giving them all the liabilities and keep the assets with the untold intention of bankrupting it later, don't do anything. Michel. From Daniel_Alexander at comcast.com Mon Nov 7 10:53:36 2016 From: Daniel_Alexander at comcast.com (Alexander, Daniel) Date: Mon, 7 Nov 2016 15:53:36 +0000 Subject: [arin-ppml] re-org question In-Reply-To: References: <452BE3ED-0C95-4D1D-BA40-DE8CDE6AB47E@delong.com> <59083B6E-A081-4F8C-BD40-D1C1DA92A1E9@delong.com> <32251EA0-0991-4979-A117-25B9FF6CC14E@delong.com> Message-ID: Morning Bill, One item that may help clarify intent is an editorial change that the AC requested in April, and was adopted by the BoT at their May 2016 meeting. https://www.arin.net/about_us/bot/20160520/exhibit_d.pdf But as you and David suggested, more work may be required in this area. Hope this helps. -Dan On 11/4/16, 11:06 PM, "arin-ppml-bounces at arin.net on behalf of William Herrin" wrote: >On Fri, Nov 4, 2016 at 10:55 PM, Owen DeLong wrote: >> You can return as small as a /24. >> >> If you?re using half, then you can keep it. >> >> So, at most, you have to renumber 126 hosts out of each of half of your >>/25s. >> >> How is this not minimal again? > >Sorry Owen, I won't engage you with the relocated goal post. If you >are correct, the 8.2 transfer language requires a registrant whose >addresses are assigned and in use but not efficiently used per ARIN >standards to engage some degree of renumbering as consequence of the >transfer. > >-Bill > > > >-- >William Herrin ................ herrin at dirtside.com bill at herrin.us >Owner, Dirtside Systems ......... Web: >_______________________________________________ >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 farmer at umn.edu Mon Nov 7 11:59:38 2016 From: farmer at umn.edu (David Farmer) Date: Mon, 7 Nov 2016 10:59:38 -0600 Subject: [arin-ppml] re-org question In-Reply-To: References: Message-ID: On Fri, Nov 4, 2016 at 8:53 PM, William Herrin wrote: > On Fri, Nov 4, 2016 at 9:35 PM, David R Huberman wrote: > >> "ARIN will proceed with processing transfer requests even if the > >> number resources of the combined organizations EXCEED WHAT CAN BE > >> JUSTIFIED UNDER CURRENT ARIN POLICY. IN THAT EVENT, ARIN will work > >> with the resource holder(s) to transfer the extra number resources to > >> other organization(s) or accept a voluntary return of the extra number > >> resources to ARIN." > >> > >> I don't see an "or let you keep the extra number resources' in there. > > > > Correct. You also don't see a MUST in the context of MUST transfer or > MUST > > return. The RSA forbids it, and the community has never given ARIN such > > power in policy. > > David, > > It's a public policy document. In the absence of language to the > contrary, the MUST is implied. And if it's not a MUST then it's > operational guidance that doesn't belong in a POLICY document at all. > Its debatable whether the transfer part of that clause is implied to be mandatory or not. However, at least for the return part of the clause, the use of the word "voluntary" rebuts that idea. Something can't both be explicitly voluntary and implied to be mandatory at the same time. I say it's debatable because I not sure how ARIN could go about forcing such a transaction to occur between two other parties in practice. I see how ARIN could go about forcing a return in practice, but that is not allowed both by policy and the RSA in the situation being discussed. > The AC has tried to fix this text a few times, and perhaps we haven't > done a > > good enough job. > > You think? > What if the transfer part was made explicitly voluntary as well? Would that solve your worry? Personally, I'd like to remove that clause all together, I do not see where it is reasonable to re-justify your resources just because of a business reorganization. It should be sufficient to submit proper legal documentation and demonstrate that the number resources are not the primary thing of value being transferred or otherwise reorganized in the transaction. If the number resources are the primary thing of real value, then its not really a business reorganization transaction, its number resources transaction and the other policies should apply. Regards, > Bill -- =============================================== 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 daveid at panix.com Mon Nov 7 12:43:50 2016 From: daveid at panix.com (David R Huberman) Date: Mon, 7 Nov 2016 12:43:50 -0500 (EST) Subject: [arin-ppml] re-org question In-Reply-To: References: Message-ID: On Mon, 7 Nov 2016, David Farmer wrote: > Personally, I'd like to remove that clause all together, I do not see > where it is reasonable to re-justify your resources just because of a > business reorganization. It should be sufficient to submit proper legal > documentation and demonstrate that the number resources are not the > primary thing of value being transferred or otherwise reorganized in the > transaction. If the number resources are the primary thing of real > value, then its not really a business reorganization transaction, its > number resources transaction and the other policies should apply. I agree with you 100%. Are you willing to submit a policy template to that effect please? David From bill at herrin.us Mon Nov 7 12:45:23 2016 From: bill at herrin.us (William Herrin) Date: Mon, 7 Nov 2016 12:45:23 -0500 Subject: [arin-ppml] re-org question In-Reply-To: References: Message-ID: On Mon, Nov 7, 2016 at 11:59 AM, David Farmer wrote: > What if the transfer part was made explicitly voluntary as well? Would that > solve your worry? > > Personally, I'd like to remove that clause all together, I do not see where > it is reasonable to re-justify your resources just because of a business > reorganization. Hi David, I think the appropriate solution is to remove the offending language. The NRPM should concisely specify the requirements we place on both ARIN and its registrants. Anything more wishy-washy belongs in accompanying Guidance documents that offer best practices for compliance. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From farmer at umn.edu Mon Nov 7 13:32:31 2016 From: farmer at umn.edu (David Farmer) Date: Mon, 7 Nov 2016 12:32:31 -0600 Subject: [arin-ppml] re-org question In-Reply-To: References: Message-ID: <3AC21C79-DA04-4DBD-BA1A-F2C9926CD687@umn.edu> Sent from my iPhone > On Nov 7, 2016, at 11:45, William Herrin wrote: > >> On Mon, Nov 7, 2016 at 11:59 AM, David Farmer wrote: >> What if the transfer part was made explicitly voluntary as well? Would that >> solve your worry? >> >> Personally, I'd like to remove that clause all together, I do not see where >> it is reasonable to re-justify your resources just because of a business >> reorganization. > > Hi David, > > I think the appropriate solution is to remove the offending language. > The NRPM should concisely specify the requirements we place on both > ARIN and its registrants. Anything more wishy-washy belongs in > accompanying Guidance documents that offer best practices for > compliance. > > Regards, > Bill Herrin After the current round of last calls get worked through, I'm willing to take another run at removing this issue. I'll work on some text over the next few weeks or so. However, I still need to know what you think of making the transfer part explicitly voluntarily, would that eliminate your worry about the current language? Even if we can't find consensus to eliminate that language, I want to at make sure people aren't getting hung up on it. Thanks From bill at herrin.us Mon Nov 7 13:54:32 2016 From: bill at herrin.us (William Herrin) Date: Mon, 7 Nov 2016 13:54:32 -0500 Subject: [arin-ppml] re-org question In-Reply-To: <3AC21C79-DA04-4DBD-BA1A-F2C9926CD687@umn.edu> References: <3AC21C79-DA04-4DBD-BA1A-F2C9926CD687@umn.edu> Message-ID: On Mon, Nov 7, 2016 at 1:32 PM, David Farmer wrote: > However, I still need to know what you think of making the > transfer part explicitly voluntarily, would that eliminate your > worry about the current language? Hi David, I think "voluntary" in that context sounds a lot like "voluntold." So no, it does not resolve my concern. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From scott at dlvr.com Mon Nov 7 14:07:36 2016 From: scott at dlvr.com (Scott Leibrand) Date: Mon, 7 Nov 2016 11:07:36 -0800 Subject: [arin-ppml] re-org question In-Reply-To: References: <3AC21C79-DA04-4DBD-BA1A-F2C9926CD687@umn.edu> Message-ID: Bill, The intent of this policy text was that an organization receiving a sparsely used /16 would transfer the unused bits to other organization(s) that could use them. In your case, if you transferred all the /24s that are currently unused (without any renumbering), would the blocks you're keeping meet a 50% utilization threshold, if you include planned 24 month growth? -Scott On Mon, Nov 7, 2016 at 10:54 AM, William Herrin wrote: > On Mon, Nov 7, 2016 at 1:32 PM, David Farmer wrote: > > However, I still need to know what you think of making the > > transfer part explicitly voluntarily, would that eliminate your > > worry about the current language? > > Hi David, > > I think "voluntary" in that context sounds a lot like "voluntold." So > no, it does not resolve my concern. > > Regards, > Bill Herrin > > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Owner, Dirtside Systems ......... Web: > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Wed Nov 9 15:36:11 2016 From: bill at herrin.us (William Herrin) Date: Wed, 9 Nov 2016 15:36:11 -0500 Subject: [arin-ppml] re-org question In-Reply-To: References: <3AC21C79-DA04-4DBD-BA1A-F2C9926CD687@umn.edu> Message-ID: On Mon, Nov 7, 2016 at 2:07 PM, Scott Leibrand wrote: > The intent of this policy text was that an organization receiving a sparsely > used /16 would transfer the unused bits to other organization(s) that could > use them. For those who've not dug deep, Scott was the author of PP105 which became draft 2010-6. This was the draft policy which first introduced the language to the NRPM. He is thus uniquely well qualified to explain its intent. > In your case, if you transferred all the /24s that are currently > unused (without any renumbering), would the blocks you're keeping meet a 50% > utilization threshold, if you include planned 24 month growth? Hi Scott, In my case the question is moot. I'd advise my client to update POCs at ARIN and place a carefully crafted contract effecting transfer of control into a locked safe. I can't think of a single sane reason I'd advise them to consider renumbering, changing BGP advertisements, dealing with IP brokers, evaluating the ARIN RSA contract, etc. in the midst of an already complicated re-organization. The policies structured as they are, I'd have to be out of my mind to actually tell ARIN the addresses had been transferred to a new organization. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From scott at dlvr.com Wed Nov 9 15:41:44 2016 From: scott at dlvr.com (Scott Leibrand) Date: Wed, 9 Nov 2016 12:41:44 -0800 Subject: [arin-ppml] re-org question In-Reply-To: References: <3AC21C79-DA04-4DBD-BA1A-F2C9926CD687@umn.edu> Message-ID: Fair enough. If the 2010-6 language were removed, would that change your approach? Or is signing the RSA the main stumbling block for you? -Scott On Wed, Nov 9, 2016 at 12:36 PM, William Herrin wrote: > On Mon, Nov 7, 2016 at 2:07 PM, Scott Leibrand wrote: > > The intent of this policy text was that an organization receiving a > sparsely > > used /16 would transfer the unused bits to other organization(s) that > could > > use them. > > For those who've not dug deep, Scott was the author of PP105 which > became draft 2010-6. This was the draft policy which first introduced > the language to the NRPM. He is thus uniquely well qualified to > explain its intent. > > > > In your case, if you transferred all the /24s that are currently > > unused (without any renumbering), would the blocks you're keeping meet a > 50% > > utilization threshold, if you include planned 24 month growth? > > Hi Scott, > > In my case the question is moot. I'd advise my client to update POCs > at ARIN and place a carefully crafted contract effecting transfer of > control into a locked safe. I can't think of a single sane reason I'd > advise them to consider renumbering, changing BGP advertisements, > dealing with IP brokers, evaluating the ARIN RSA contract, etc. in the > midst of an already complicated re-organization. > > The policies structured as they are, I'd have to be out of my mind to > actually tell ARIN the addresses had been transferred to a new > organization. > > Regards, > Bill Herrin > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Owner, Dirtside Systems ......... Web: > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Wed Nov 9 17:10:51 2016 From: bill at herrin.us (William Herrin) Date: Wed, 9 Nov 2016 17:10:51 -0500 Subject: [arin-ppml] re-org question In-Reply-To: References: <3AC21C79-DA04-4DBD-BA1A-F2C9926CD687@umn.edu> Message-ID: On Wed, Nov 9, 2016 at 3:41 PM, Scott Leibrand wrote: > If the 2010-6 language were removed, would that change your approach? Or is > signing the RSA the main stumbling block for you? Hi Scott, The RSA standing alone, I'd at least put on the table. The lawyers will be vetting lots of documents; one more that requires no action beyond a signature and a token payment is no big deal. If the lawyers choked on it, I'd probably go back to plan-A but it would at least get past me to the lawyers. Regards, Bill -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From scott at dlvr.com Wed Nov 9 17:25:15 2016 From: scott at dlvr.com (Scott Leibrand) Date: Wed, 9 Nov 2016 14:25:15 -0800 Subject: [arin-ppml] re-org question In-Reply-To: References: <3AC21C79-DA04-4DBD-BA1A-F2C9926CD687@umn.edu> Message-ID: Ok. I'm not sure if the timing would work for this particular transaction, but it sounds like we have a real-world problem that would be fixed by removing the last paragraph of NRPM 8.2, so we should probably write up the problem statement and submit it as a policy proposal. Would you be interested in putting that into the process? It sounds like David might be interested in assisting if you need any help writing it up, or I would also be happy to do so. I personally believe that the "work with the resource holder" language has now outlived its usefulness, and can be safely removed, particularly in light of the RSA constraints that prevent ARIN from reclaiming resources due to lack of utilization. -Scott On Wed, Nov 9, 2016 at 2:10 PM, William Herrin wrote: > On Wed, Nov 9, 2016 at 3:41 PM, Scott Leibrand wrote: > > If the 2010-6 language were removed, would that change your approach? > Or is > > signing the RSA the main stumbling block for you? > > Hi Scott, > > The RSA standing alone, I'd at least put on the table. The lawyers > will be vetting lots of documents; one more that requires no action > beyond a signature and a token payment is no big deal. If the lawyers > choked on it, I'd probably go back to plan-A but it would at least get > past me to the lawyers. > > Regards, > Bill > > > -- > William Herrin ................ herrin at dirtside.com bill at herrin.us > Owner, Dirtside Systems ......... Web: > -------------- next part -------------- An HTML attachment was scrubbed... URL: From narten at us.ibm.com Fri Nov 11 00:53:03 2016 From: narten at us.ibm.com (narten at us.ibm.com) Date: Fri, 11 Nov 2016 00:53:03 -0500 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201611110553.uAB5r3GA012307@rotala.raleigh.ibm.com> Total of 39 messages in the last 7 days. script run at: Fri Nov 11 00:53:03 EST 2016 Messages | Bytes | Who --------+------+--------+----------+------------------------ 35.90% | 14 | 33.41% | 104943 | bill at herrin.us 12.82% | 5 | 12.44% | 39075 | owen at delong.com 12.82% | 5 | 10.40% | 32654 | daveid at panix.com 7.69% | 3 | 11.50% | 36135 | scott at dlvr.com 7.69% | 3 | 6.69% | 21029 | michel at arneill-py.sacramento.ca.us 7.69% | 3 | 6.13% | 19246 | rfg at tristatelogic.com 5.13% | 2 | 8.15% | 25587 | farmer at umn.edu 2.56% | 1 | 3.17% | 9967 | mpetach at netflight.com 2.56% | 1 | 3.08% | 9688 | daniel_alexander at comcast.com 2.56% | 1 | 2.77% | 8714 | narten at us.ibm.com 2.56% | 1 | 2.25% | 7065 | dave at connetrix.com --------+------+--------+----------+------------------------ 100.00% | 39 |100.00% | 314103 | Total From info at arin.net Thu Nov 17 14:23:02 2016 From: info at arin.net (ARIN) Date: Thu, 17 Nov 2016 14:23:02 -0500 Subject: [arin-ppml] Fwd: Advisory Council Meeting Results - October 2016 In-Reply-To: <581119E4.4070005@arin.net> References: <581119E4.4070005@arin.net> Message-ID: <582E0396.1030709@arin.net> > The AC abandoned the following: > > Recommended Draft Policy ARIN-2015-7: Simplified requirements for > demonstrated need for IPv4 transfers > > The AC provided the following statement regarding ARIN-2015-7: > > The Advisory Council decided to abandon ARIN-2015-7: Simplified > requirements for demonstrated need for IPv4 transfers due to a lack of > support, when compared to other alternative proposals at the Public > Policy Meeting at ARIN 38 in Dallas. > > Anyone dissatisfied with this decision may initiate a petition. The > deadline to begin a petition will be five business days after the AC's > draft meeting minutes are published. The minutes from the ARIN Advisory Council's 21 October 2016 meeting have been published at: https://www.arin.net/about_us/ac/ac2016_1021.html The petition deadline for the AC's abandonment of Recommended Draft Policy ARIN-2015-7 is 22 November 2016. For more information on starting and participating in petitions, see PDP Petitions at: https://www.arin.net/policy/pdp_petitions.html The ARIN Policy Development Process can be found at: https://www.arin.net/policy/pdp.html Draft Policy and Proposal texts are available at: https://www.arin.net/policy/proposals/index.html Regards, Communications and Member Services American Registry for Internet Numbers (ARIN) -------- Forwarded Message -------- Subject: Advisory Council Meeting Results - October 2016 Date: Wed, 26 Oct 2016 17:02:28 -0400 From: ARIN To: arin-ppml at arin.net The Advisory Council met on 21 October in accordance with the Policy Development Process (PDP), and moved the following to Last Call (each will be posted separately): Recommended Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) Recommended Draft Policy ARIN-2016-1: Reserved Pool Transfer Policy Recommended Draft Policy ARIN-2016-2: Change timeframes for IPv4 requests to 24 months Recommended Draft Policy ARIN-2016-4: Transfers for new entrants Recommended Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer Policy Recommended Draft Policy ARIN-2016-6: Eliminate HD-Ratio from NRPM The AC abandoned the following: Recommended Draft Policy ARIN-2015-7: Simplified requirements for demonstrated need for IPv4 transfers The AC provided the following statement regarding ARIN-2015-7: The Advisory Council decided to abandon ARIN-2015-7: Simplified requirements for demonstrated need for IPv4 transfers due to a lack of support, when compared to other alternative proposals at the Public Policy Meeting at ARIN 38 in Dallas. Anyone dissatisfied with this decision may initiate a petition. The deadline to begin a petition will be five business days after the AC's draft meeting minutes are published. The AC accepted the following Proposal as a Draft Policy (to be posted separately for discussion): ARIN-prop-232: Integration of Community Networks into existing ISP policy 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 number resource policy text. The AC is continuing to work on: Draft Policy ARIN-2016-3: Alternative simplified criteria for justifying small IPv4 transfers The AC provided the following statement regarding ARIN-2016-3: With regard to merging with other Recommended Draft Policies, 2016-3 includes a change to NRPM Section 8.4, bullet 3. Recommended Draft Policy ARIN-2016-5 includes the movement of bullet 3 to bullet 2. Recommended Draft Policy ARIN-2016-1: Reserved Pool Transfer Policy includes the addition of a bullet to Section 8.4 Should 2016-5 be implemented, the aforementioned changes from 2016-3 and 2016-1 should be incorporated into Section 4 as appropriate. 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, Communications and Member Services American Registry for Internet Numbers (ARIN) From narten at us.ibm.com Fri Nov 18 00:53:03 2016 From: narten at us.ibm.com (narten at us.ibm.com) Date: Fri, 18 Nov 2016 00:53:03 -0500 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201611180553.uAI5r3Nx021146@rotala.raleigh.ibm.com> Total of 2 messages in the last 7 days. script run at: Fri Nov 18 00:53:03 EST 2016 Messages | Bytes | Who --------+------+--------+----------+------------------------ 50.00% | 1 | 51.21% | 9390 | info at arin.net 50.00% | 1 | 48.79% | 8947 | narten at us.ibm.com --------+------+--------+----------+------------------------ 100.00% | 2 |100.00% | 18337 | Total From jcurran at arin.net Fri Nov 18 08:32:25 2016 From: jcurran at arin.net (John Curran) Date: Fri, 18 Nov 2016 13:32:25 +0000 Subject: [arin-ppml] re-org question In-Reply-To: References: <452BE3ED-0C95-4D1D-BA40-DE8CDE6AB47E@delong.com> <59083B6E-A081-4F8C-BD40-D1C1DA92A1E9@delong.com> <32251EA0-0991-4979-A117-25B9FF6CC14E@delong.com> Message-ID: <0F67A81C-8452-4D79-8B53-7A1B68896653@arin.net> On 7 Nov 2016, at 10:53 AM, Alexander, Daniel > wrote: Morning Bill, One item that may help clarify intent is an editorial change that the AC requested in April, and was adopted by the BoT at their May 2016 meeting. https://www.arin.net/about_us/bot/20160520/exhibit_d.pdf Daniel - You are correct. ARIN will process NRPM 8.2 transfer requests even if the number resources of the combined organizations exceed what can be justified under current ARIN policy. ARIN works with the organization to encourage timely resolution with regard to excess resources (via either voluntary return or subsequent transfer. However, as has been noted on this list, ARIN cannot require either of these actions, and the language in NRPM 8.2 in this regard solely serves to direct ARIN to remind recipients of community expectation in this regard. If this policy text were to be removed, then ARIN staff would no longer remind NRPM 8.2 recipients with excess resources of the community expectations in this regard. Thanks! /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill at herrin.us Fri Nov 18 09:10:39 2016 From: bill at herrin.us (William Herrin) Date: Fri, 18 Nov 2016 09:10:39 -0500 Subject: [arin-ppml] re-org question In-Reply-To: <0F67A81C-8452-4D79-8B53-7A1B68896653@arin.net> References: <452BE3ED-0C95-4D1D-BA40-DE8CDE6AB47E@delong.com> <59083B6E-A081-4F8C-BD40-D1C1DA92A1E9@delong.com> <32251EA0-0991-4979-A117-25B9FF6CC14E@delong.com> <0F67A81C-8452-4D79-8B53-7A1B68896653@arin.net> Message-ID: On Fri, Nov 18, 2016 at 8:32 AM, John Curran wrote: > ARIN works with the organization to encourage timely resolution with > regard > to excess resources (via either voluntary return or subsequent transfer. > However, as has been noted on this list, ARIN cannot require either of > these > actions, and the language in NRPM 8.2 in this regard solely serves to > direct > ARIN to remind recipients of community expectation in this regard. Thanks John, I appreciate the clarification. Please pardon my rhetoric, but does the NRPM have any more instances of non-binding "community expectations" that we can all safely ignore? It seems to me like this sort of thing is undesirable in an otherwise-binding policy document. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Owner, Dirtside Systems ......... Web: From farmer at umn.edu Fri Nov 18 12:05:33 2016 From: farmer at umn.edu (David Farmer) Date: Fri, 18 Nov 2016 11:05:33 -0600 Subject: [arin-ppml] re-org question In-Reply-To: References: <452BE3ED-0C95-4D1D-BA40-DE8CDE6AB47E@delong.com> <59083B6E-A081-4F8C-BD40-D1C1DA92A1E9@delong.com> <32251EA0-0991-4979-A117-25B9FF6CC14E@delong.com> <0F67A81C-8452-4D79-8B53-7A1B68896653@arin.net> Message-ID: On Fri, Nov 18, 2016 at 8:10 AM, William Herrin wrote: > > Thanks John, I appreciate the clarification. > > Please pardon my rhetoric, but does the NRPM have any more instances > of non-binding "community expectations" that we can all safely ignore? > It seems to me like this sort of thing is undesirable in an > otherwise-binding policy document. > > Regards, > Bill Herrin > Bill, While I may not be happy with the way this particular "community expectation" is instantiated in policy, I feel the policy in question is too onerous. That said, I think it is extremely important for "community expectations" to be communicated through policy. Further, I would suggest that an attitude that non-binding "community expectations" can be safely ignored is dangerous, because it only invites the community to create policies that are binding and likely to be inflexible and even more onerous. If fact I feel the reason we have the policy in question is because too many people are ignoring "community expectations" to begin with. Voluntary compliance with "community expectations" is a much preferred model for most policy in my opinion and is key to the industry self-regulatory model. 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 jcurran at arin.net Fri Nov 18 19:01:40 2016 From: jcurran at arin.net (John Curran) Date: Sat, 19 Nov 2016 00:01:40 +0000 Subject: [arin-ppml] re-org question In-Reply-To: References: <452BE3ED-0C95-4D1D-BA40-DE8CDE6AB47E@delong.com> <59083B6E-A081-4F8C-BD40-D1C1DA92A1E9@delong.com> <32251EA0-0991-4979-A117-25B9FF6CC14E@delong.com> <0F67A81C-8452-4D79-8B53-7A1B68896653@arin.net> Message-ID: <8D2761C3-A39D-460F-9C64-696DDDB163E1@arin.net> On 18 Nov 2016, at 12:05 PM, David Farmer wrote: > > While I may not be happy with the way this particular "community expectation" is instantiated in policy, I feel the policy in question is too onerous. That said, I think it is extremely important for "community expectations" to be communicated through policy. Bill David is quite correct - community expectations are just that; the fact that ARIN does not have an enforcement role does not mean that these expectations are invalid. > Further, I would suggest that an attitude that non-binding "community expectations" can be safely ignored is dangerous, because it only invites the community to create policies that are binding and likely to be inflexible and even more onerous. If fact I feel the reason we have the policy in question is because too many people are ignoring "community expectations" to begin with. > > Voluntary compliance with "community expectations" is a much preferred model for most policy in my opinion and is key to the industry self-regulatory model. For example, NRPM 4.2.3.7. (Reassignment Information) sets expectations with regard to customer reassignments. Historically, the enforcement of this requirement has been via indirect enforcement ? specifically, when an organization requested their next IP address block, ARIN performed detailed reviews of their previous assignment information. This level of review is less likely with transfers, given the more generous criteria that applies. To my knowledge, we have no reclaimed address blocks due to lack of reassignment information, but the community expectation remains that such information will put in the Whois per NRPM 4.2.3.7. If the community feels that no reassignment info is necessary, then this section could be removed; but currently, its presence provides important guidance despite no direct enforcement by ARIN. Thanks, /John John Curran President and CEO ARIN From michel at arneill-py.sacramento.ca.us Sun Nov 20 14:29:40 2016 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Sun, 20 Nov 2016 19:29:40 +0000 Subject: [arin-ppml] ARIN procedures for disputes Message-ID: Hi John, > John Curran wrote : > the fact that ARIN does not have an enforcement role I understand that you wrote this sentence in a differenct context, which is why I changed the subject line. I was communicating with ARIN staff recently about a dispute related to org split, and was told "there aren't any actions you can take with ARIN to dispute having any of this IP range transferred to your Organization". I am a bit surprised; I was trying to avoid a legal procedure. I do understand that ARIN would not want to be involved with this kind of issue, but ARIN is going to be in the middle of it no matter how; isn't there a better way than a full blown lawsuit ? Thanks, Michel. From jcurran at arin.net Sun Nov 20 22:30:26 2016 From: jcurran at arin.net (John Curran) Date: Mon, 21 Nov 2016 03:30:26 +0000 Subject: [arin-ppml] ARIN procedures for disputes In-Reply-To: References: Message-ID: On 20 Nov 2016, at 2:29 PM, Michel Py > wrote: ... I was communicating with ARIN staff recently about a dispute related to org split, and was told "there aren't any actions you can take with ARIN to dispute having any of this IP range transferred to your Organization". I am a bit surprised; I was trying to avoid a legal procedure. I do understand that ARIN would not want to be involved with this kind of issue, but ARIN is going to be in the middle of it no matter how; isn't there a better way than a full blown lawsuit ? Michel - Depending on the circumstances and parties involved, arbitration or litigation might be the only option, but I do hope that is not necessary (we usually only end up there when there are multiple parties asserting rights to the same number resource?) However, before it gets to that, you do want to make the resource request, and supply the information necessary (that you have available) and pursue to the end result. If the result is that the request is denied, then you should review this page: which outlines the ARIN Appeal Process. In short - 1) First, ask to have the request reviewed by RSD Director and ARIN COO - (this will determine if there has bene any error in processing the request per our procedures which implement the number resource policy.) 2) If the determination stands after review, and you believe that ARIN is not properly implementing number resource policy, then send me a letter indicating that you are appealing the determination, including the ARIN ticket number. I?ll review whether ARIN?s implementation of the policy is correct, including reviewing our implementation procedures for the policy. If I find that they are in error, then we will correct them so that your request (and any similar ones) will be processed correctly. If we are correctly processing these requests per number resource policy, then I?ll inform you of that; you do have the arbitration mechanisms provided in the RSA if you wish to pursue further (and may have other legal options as you noted.) Thanks! /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From michel at arneill-py.sacramento.ca.us Mon Nov 21 16:02:23 2016 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Mon, 21 Nov 2016 21:02:23 +0000 Subject: [arin-ppml] ARIN procedures for disputes In-Reply-To: References: Message-ID: From: John Curran [mailto:jcurran at arin.net] Sent: Sunday, November 20, 2016 7:30 PM To: Michel Py Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] ARIN procedures for disputes On 20 Nov 2016, at 2:29 PM, Michel Py wrote: ... I was communicating with ARIN staff recently about a dispute related to org split, and was told "there aren't any actions you can take with ARIN to dispute having any of this IP range transferred to your Organization". I am a bit surprised; I was trying to avoid a legal procedure. I do understand that ARIN would not want to be involved with this kind of issue, but ARIN is going to be in the middle of it no matter how; isn't there a better way than a full blown lawsuit ? Michel -? Depending on the circumstances and parties involved, arbitration or litigation? might be the only option, but I do hope that is not necessary (we usually only end up there when there are multiple parties asserting rights to the same? number resource?) However, before it gets to that, you do want to make the resource request,? and supply the information necessary (that you have available) and pursue? to the end result. ? If the result is that the request is denied, then you should review this page: ? which outlines the ARIN Appeal Process. ? In short -? 1) First, ask to have the request reviewed by RSD Director and ARIN COO - ? ? (this will determine if there has bene any error in processing the request? ? ? per our procedures which implement the number resource policy.)? ? ? ? 2) If the determination stands after review, and you believe that ARIN is not? ? ? properly implementing number resource policy, then send me a letter? ? ? indicating that you are appealing the determination, including the ARIN? ? ? ticket number. ?I?ll review whether ARIN?s implementation of the policy is? ? ? correct, including reviewing our implementation procedures for the policy. ? ? If I find that they are in error, then we will correct them so that your request? ? ? (and any similar ones) will be processed correctly. ? If we are correctly ? ? processing these requests per number resource policy, then I?ll inform you? ? ? of that; you do have the arbitration mechanisms provided in the RSA if you? ? ? wish to pursue further (and may have other legal options as you noted.) Thanks! /John John Curran President and CEO ARIN ? ?? From michel at arneill-py.sacramento.ca.us Mon Nov 21 16:15:38 2016 From: michel at arneill-py.sacramento.ca.us (Michel Py) Date: Mon, 21 Nov 2016 21:15:38 +0000 Subject: [arin-ppml] ARIN procedures for disputes In-Reply-To: References: Message-ID: [Oops, sorry for the fast fingers] > John Curran wrote : > However, before it gets to that, you do want to make the resource request Thanks, I just made a transfer request, we'll see how it goes. I have an additional question, for you and/or the community : Bases on previous experience, in a multi-billion merger such as the one below, is it common/expected that the IP blocks registered with ARIN are specifically mentioned in the legal documents ? https://www.renesas.com/en-us/about/press-center/news/2010/news20100401a.html Thanks, Michel. From jcurran at arin.net Mon Nov 21 17:23:30 2016 From: jcurran at arin.net (John Curran) Date: Mon, 21 Nov 2016 22:23:30 +0000 Subject: [arin-ppml] ARIN procedures for disputes In-Reply-To: References: Message-ID: <98135E24-D7EF-4F5C-91CC-4D51A6820658@corp.arin.net> On 21 Nov 2016, at 4:15 PM, Michel Py wrote: > I have an additional question, for you and/or the community : > Bases on previous experience, in a multi-billion merger such as the one below, is it common/expected that the IP blocks registered with ARIN are specifically mentioned in the legal documents ? it is not common to see IP number resources included in legal documents in the case of mergers or acquisitions, but it is common in the case of the sale or divestiture of business units. As you might imagine, things can get quite colorful when a company breaks into multiple pieces, particularly if there is no guidance in the legal contracts and overlapping use of number resources? Thanks! /John John Curran President and CEO ARIN From info at arin.net Tue Nov 22 15:46:17 2016 From: info at arin.net (ARIN) Date: Tue, 22 Nov 2016 15:46:17 -0500 Subject: [arin-ppml] Advisory Council Meeting Results - November 2016 Message-ID: The Advisory Council met on 17 November in accordance with the Policy Development Process (PDP), and recommended the following to the Board of Trustees for adoption: Recommended Draft Policy ARIN-2015-2: Modify 8.4 (Inter-RIR Transfers to Specified Recipients) Recommended Draft Policy ARIN-2016-1: Reserved Pool Transfer Policy Recommended Draft Policy ARIN-2016-2: Change timeframes for IPv4 requests to 24 months Recommended Draft Policy ARIN-2016-4: Transfers for new entrants Recommended Draft Policy ARIN-2016-5: Post-IPv4-Free-Pool-Depletion Transfer Policy Recommended Draft Policy ARIN-2016-6: Eliminate HD-Ratio from NRPM The AC is continuing to work on: Draft Policy ARIN-2016-3: Alternative simplified criteria for justifying small IPv4 transfers Draft Policy ARIN-2016-7: Integration of Community Networks into existing ISP policy 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, Communications and Member Services American Registry for Internet Numbers (ARIN) From narten at us.ibm.com Fri Nov 25 00:53:33 2016 From: narten at us.ibm.com (narten at us.ibm.com) Date: Fri, 25 Nov 2016 00:53:33 -0500 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201611250553.uAP5rXeb026141@rotala.raleigh.ibm.com> Total of 11 messages in the last 7 days. script run at: Fri Nov 25 00:53:28 EST 2016 Messages | Bytes | Who --------+------+--------+----------+------------------------ 36.36% | 4 | 43.15% | 43201 | jcurran at arin.net 27.27% | 3 | 20.93% | 20951 | michel at arneill-py.sacramento.ca.us 9.09% | 1 | 13.36% | 13377 | farmer at umn.edu 9.09% | 1 | 8.39% | 8396 | narten at us.ibm.com 9.09% | 1 | 7.80% | 7814 | bill at herrin.us 9.09% | 1 | 6.37% | 6381 | info at arin.net --------+------+--------+----------+------------------------ 100.00% | 11 |100.00% | 100120 | Total