From narten at us.ibm.com Fri Sep 1 00:53:29 2017 From: narten at us.ibm.com (narten at us.ibm.com) Date: Fri, 01 Sep 2017 00:53:29 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201709010453.v814rT34012281@rotala.raleigh.ibm.com> Total of 21 messages in the last 7 days. script run at: Fri Sep 1 00:53:24 EDT 2017 Messages | Bytes | Who --------+------+--------+----------+------------------------ 19.05% | 4 | 19.50% | 130280 | jschiller at google.com 14.29% | 3 | 22.71% | 151742 | owen at delong.com 9.52% | 2 | 19.25% | 128629 | rudi.daniel at gmail.com 9.52% | 2 | 8.07% | 53887 | farmer at umn.edu 9.52% | 2 | 4.15% | 27734 | hostmaster at uneedus.com 4.76% | 1 | 6.13% | 40980 | lsawyer at gci.com 4.76% | 1 | 5.80% | 38779 | jrdelacruz at acm.org 4.76% | 1 | 5.26% | 35173 | kevinb at thewire.ca 4.76% | 1 | 3.08% | 20581 | carlton.samuels at gmail.com 4.76% | 1 | 1.83% | 12248 | mike at iptrading.com 4.76% | 1 | 1.71% | 11440 | info at arin.net 4.76% | 1 | 1.38% | 9213 | narten at us.ibm.com 4.76% | 1 | 1.12% | 7467 | ajs at anvilwalrusden.com --------+------+--------+----------+------------------------ 100.00% | 21 |100.00% | 668153 | Total From apotter at hilcoglobal.com Tue Sep 5 23:00:25 2017 From: apotter at hilcoglobal.com (Potter, Amy) Date: Wed, 6 Sep 2017 03:00:25 +0000 Subject: [arin-ppml] 2017-3 Message-ID: <62DD04C9CA033342B055D0C8BFE2A0FCD8713E99@NB-EXCH10.hgag.hilcotrading.com> Hi all, The text of 2017-3 that we presented at our last meeting attempts to address the problem of whois inaccuracy by removing reverse DNS entries for organizations that lack validated POC records as well as removing their resources from the public whois database. The feedback we've received for this option has been largely negative, so we are looking to get some feedback on alternative solutions. A revised draft is included below that proposes instead to remove access to ARIN Online for organizations that lack a validated tech or admin POC. Other options have also been proposed that we would like your feedback on. Those include: 1. Requiring organizations to validate their POCs at the time of creation. POCs for organizations that have received a reallocation from their upstream must validate both that the POC contact information is correct and that their organization information is correct. 2. Requiring POCs for reallocated space to validate their information prior to the reallocation being visible in public whois. 3. Removing ARIN Online access to upstream ISPs until every reallocation made from their direct allocation has validated POCs. Upstream ISPs would not be able to validate the POCs of their downstream recipients of reallocations. Only the actual recipients of the reallocation would be able to validate their own POCs (i.e. upstream ISPs would be dependent on the actions of their downstream customers, and would lose ARIN Online access if their customers did not validate the information the upstream provided for them in ARIN's whois). Some interesting stats were provided by staff to help us flesh out the feasibility of this idea. Those stats are included at the very bottom of this message. 4. Proposed revised text below. 5. Any other ideas? Proposed revised text Policy statement: Current text: 3.6 Annual Whois POC Validation 3.6.1 Method of Annual Verification During ARIN's annual Whois POC validation, an email will be sent to every POC in the Whois database. Each POC will have a maximum of 60 days to respond with an affirmative that their Whois contact information is correct and complete. Unresponsive POC email addresses shall be marked as such in the database. If ARIN staff deems a POC to be completely and permanently abandoned or otherwise illegitimate, the POC record shall be marked invalid. ARIN will maintain, and make readily available to the community, a current list of number resources with no valid POC; this data will be subject to the current bulk Whois policy. Proposed revised text: 3.6 Annual Validation of ARIN's Public Access WHOIS Point of Contact Data 3.6.1 Annual POC Verification ARIN will perform an annual verification of point of contact data each year on the date the POC was registered, beginning on January 1 each year using the procedure provided in 3.6.4. 3.6.2 Specified Public WHOIS Points of Contact for Verification Each of the following Points of Contact are to be verified annually and will be referred to as Points of Contact throughout this policy: - Admin - Tech - NOC - Abuse 3.6.3 Organizations Covered by this Policy This policy applies to every Organization that holds a direct assignment, direct allocation, AS number or reallocation from ARIN. This includes but is not limited to upstream ISPs and downstream ISP customers (as defined by NRPM 2.5 and 2.6), but not reassignments made to downstream customers or end user customers. 3.6.4 ARIN Staff Procedure for Verification Email notification will be sent to each of the Points of Contact in section 3.6.2 on an annual basis. Each Point of Contact will have up to sixty (60) days from the date of the notification in which to respond with confirmation as to the public WHOIS contact data or to submit data to correct and complete it. Validation can occur via the ARIN Online account, or, alternatively, by clicking the validation link in the email notification. After the sixty (60) day period, non-responsive Point of Contact records will be marked as "non-responsive" in the public WHOIS directory. 3.6.5 Non-Responsive Point of Contact Records After an additional ninety (90) days after the Point of Contact record has been marked as "non-responsive", ARIN's staff after through research and analysis, will mark those non validated, abandoned or otherwise illegitimate POC records "invalid". Organizations lacking a valid Tech or Admin POC will lose access to their ARIN Online account until a Tech or Admin POC has been validated. Comments: a. Timetable for implementation: to be based upon discussions with ARIN's staff. b. Anything else *** Reallocation stats provided by staff... 1) Could we get a breakdown of the number of nets in whois, how many are direct allocations, reallocations, and reassignments? # of nets in Whois: 3,161,723 # direct allocation: 23,661 # direct assignment: 35,751 # reallocations: 89,607 # detailed reassignments: 511,637 # simple reassignments: 2,502,016 (note: simple reassignments have no point of contact information) Note: This includes both legacy and non-legacy. 2) How many Org's have made reallocations? Not how many reallocations as the previous question, but how many org's with direct allocations have made reallocations. There are 5,590 Org IDs with one or more direct allocations. Of those, 648 (12%) have made one or more reallocations and 4,942 (88%) have no reallocations. Note that this excludes legacy direct allocations as well as self-reallocations (reallocations made to the same Org ID as the direct allocation). 3) Of the Direct Allocations, what is the average and median number of reallocations associated to the direct allocations? There are 2,205 direct allocations with one or more reallocations. The maximum number of reallocations under a single direct allocation is 31,500. (Note: This is a IPv6 Direct Allocation) The mean number of reallocations under a direct allocation (counting only direct allocations with one or more reallocations) is 37. The median number of reallocations under a direct allocation (counting only direct allocations with one or more reallocations) is 3. And, just for statistical completeness, the mode (# that occurs most frequently) is 1. As another datapoint: 1,648 direct allocations have 1-9 reallocations (Those nets have a total of 4,327 reallocations, 5% of the reallocations). 465 direct allocations have 10-99 reallocations (Those nets have a total of 13,322 reallocations, 16% of the reallocations) 92 have 100+ reallocations (Those nets have a total of 64,895 reallocations, 79% of the reallocations). 3b) As a companion to the above, we ran the numbers on a per-Org ID basis. There are 648 Org IDs with one or more reallocations. The maximum number of reallocations under a single Org ID is 31,504. The mean number of reallocations under a direct allocation (counting only direct allocations with one or more reallocations) is 127. The median number of reallocations under a direct allocation (counting only direct allocations with one or more reallocations) is 3. And, just for statistical completeness, the mode (# that occurs most frequently) is 1. As another datapoint: 454 Org IDs have 1-9 reallocations (1,256 total reallocations) 160 Org IDs have 10-99 reallocations (4,805 total reallocations) 34 Org IDs have 100+ reallocations (76,486 total reallocations) -------------- next part -------------- An HTML attachment was scrubbed... URL: From apotter at hilcoglobal.com Wed Sep 6 11:13:03 2017 From: apotter at hilcoglobal.com (Potter, Amy) Date: Wed, 6 Sep 2017 15:13:03 +0000 Subject: [arin-ppml] Draft Policy 2017-3: Update to NRPM 3.6: Annual Whois POC Validation Message-ID: <62DD04C9CA033342B055D0C8BFE2A0FCD871476D@NB-EXCH10.hgag.hilcotrading.com> Hi all, The text of 2017-3 that we presented at our last meeting attempts to address the problem of whois inaccuracy by removing reverse DNS entries for organizations that lack validated POC records as well as removing their resources from the public whois database. The feedback we've received for this option has been largely negative, so we are looking to get some feedback on alternative solutions. A revised draft is included below that proposes instead to remove access to ARIN Online for organizations that lack a validated tech or admin POC. Other options have also been proposed that we would like your feedback on. Those include: 1. Requiring organizations to validate their POCs at the time of creation. POCs for organizations that have received a reallocation from their upstream must validate both that the POC contact information is correct and that their organization information is correct. 2. Requiring POCs for reallocated space to validate their information prior to the reallocation being visible in public whois. 3. Removing ARIN Online access to upstream ISPs until every reallocation made from their direct allocation has validated POCs. Upstream ISPs would not be able to validate the POCs of their downstream recipients of reallocations. Only the actual recipients of the reallocation would be able to validate their own POCs (i.e. upstream ISPs would be dependent on the actions of their downstream customers, and would lose ARIN Online access if their customers did not validate the information the upstream provided for them in ARIN's whois). Some interesting stats were provided by staff to help us flesh out the feasibility of this idea. Those stats are included at the very bottom of this message. 4. Proposed revised text below. 5. Any other ideas? Proposed revised text Policy statement: Current text: 3.6 Annual Whois POC Validation 3.6.1 Method of Annual Verification During ARIN's annual Whois POC validation, an email will be sent to every POC in the Whois database. Each POC will have a maximum of 60 days to respond with an affirmative that their Whois contact information is correct and complete. Unresponsive POC email addresses shall be marked as such in the database. If ARIN staff deems a POC to be completely and permanently abandoned or otherwise illegitimate, the POC record shall be marked invalid. ARIN will maintain, and make readily available to the community, a current list of number resources with no valid POC; this data will be subject to the current bulk Whois policy. Proposed revised text: 3.6 Annual Validation of ARIN's Public Access WHOIS Point of Contact Data 3.6.1 Annual POC Verification ARIN will perform an annual verification of point of contact data each year on the date the POC was registered, beginning on January 1 each year using the procedure provided in 3.6.4. 3.6.2 Specified Public WHOIS Points of Contact for Verification Each of the following Points of Contact are to be verified annually and will be referred to as Points of Contact throughout this policy: - Admin - Tech - NOC - Abuse 3.6.3 Organizations Covered by this Policy This policy applies to every Organization that holds a direct assignment, direct allocation, AS number or reallocation from ARIN. This includes but is not limited to upstream ISPs and downstream ISP customers (as defined by NRPM 2.5 and 2.6), but not reassignments made to downstream customers or end user customers. 3.6.4 ARIN Staff Procedure for Verification Email notification will be sent to each of the Points of Contact in section 3.6.2 on an annual basis. Each Point of Contact will have up to sixty (60) days from the date of the notification in which to respond with confirmation as to the public WHOIS contact data or to submit data to correct and complete it. Validation can occur via the ARIN Online account, or, alternatively, by clicking the validation link in the email notification. After the sixty (60) day period, non-responsive Point of Contact records will be marked as "non-responsive" in the public WHOIS directory. 3.6.5 Non-Responsive Point of Contact Records After an additional ninety (90) days after the Point of Contact record has been marked as "non-responsive", ARIN's staff after through research and analysis, will mark those non validated, abandoned or otherwise illegitimate POC records "invalid". Organizations lacking a valid Tech or Admin POC will lose access to their ARIN Online account until a Tech or Admin POC has been validated. Comments: a. Timetable for implementation: to be based upon discussions with ARIN's staff. b. Anything else *** Reallocation stats provided by staff... 1) Could we get a breakdown of the number of nets in whois, how many are direct allocations, reallocations, and reassignments? # of nets in Whois: 3,161,723 # direct allocation: 23,661 # direct assignment: 35,751 # reallocations: 89,607 # detailed reassignments: 511,637 # simple reassignments: 2,502,016 (note: simple reassignments have no point of contact information) Note: This includes both legacy and non-legacy. 2) How many Org's have made reallocations? Not how many reallocations as the previous question, but how many org's with direct allocations have made reallocations. There are 5,590 Org IDs with one or more direct allocations. Of those, 648 (12%) have made one or more reallocations and 4,942 (88%) have no reallocations. Note that this excludes legacy direct allocations as well as self-reallocations (reallocations made to the same Org ID as the direct allocation). 3) Of the Direct Allocations, what is the average and median number of reallocations associated to the direct allocations? There are 2,205 direct allocations with one or more reallocations. The maximum number of reallocations under a single direct allocation is 31,500. (Note: This is a IPv6 Direct Allocation) The mean number of reallocations under a direct allocation (counting only direct allocations with one or more reallocations) is 37. The median number of reallocations under a direct allocation (counting only direct allocations with one or more reallocations) is 3. And, just for statistical completeness, the mode (# that occurs most frequently) is 1. As another datapoint: 1,648 direct allocations have 1-9 reallocations (Those nets have a total of 4,327 reallocations, 5% of the reallocations). 465 direct allocations have 10-99 reallocations (Those nets have a total of 13,322 reallocations, 16% of the reallocations) 92 have 100+ reallocations (Those nets have a total of 64,895 reallocations, 79% of the reallocations). 3b) As a companion to the above, we ran the numbers on a per-Org ID basis. There are 648 Org IDs with one or more reallocations. The maximum number of reallocations under a single Org ID is 31,504. The mean number of reallocations under a direct allocation (counting only direct allocations with one or more reallocations) is 127. The median number of reallocations under a direct allocation (counting only direct allocations with one or more reallocations) is 3. And, just for statistical completeness, the mode (# that occurs most frequently) is 1. As another datapoint: 454 Org IDs have 1-9 reallocations (1,256 total reallocations) 160 Org IDs have 10-99 reallocations (4,805 total reallocations) 34 Org IDs have 100+ reallocations (76,486 total reallocations) -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at arin.net Wed Sep 6 14:35:32 2017 From: info at arin.net (ARIN) Date: Wed, 6 Sep 2017 14:35:32 -0400 Subject: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers Message-ID: <2bc0e7f7-c3d1-c496-1d58-ccec181c6414@arin.net> The following has been revised: * Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers Revised text is below and can be found at: https://www.arin.net/policy/proposals/2017_4.html You are encouraged to discuss all Draft Policies on PPML. The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet number resource policy as stated in the Policy Development Process (PDP). Specifically, these principles are: * Enabling Fair and Impartial Number Resource Administration * Technically Sound * Supported by the Community The PDP can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Sean Hopkins Policy Analyst American Registry for Internet Numbers (ARIN) Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers Version Date: 6 September 2017 Problem Statement: AFRINIC and LACNIC are currently considering one-way inter-RIR transfer proposals. Those RIR communities feel a one-way policy a policy that allows network operators in their regions to obtain space from another region and transfer it into AFRINIC and LACNIC may best meet the needs of the operators in that region. ARIN staff, in reply to an inquiry from AFRINIC, have formally indicated that ARINs 8.4 policy language will not allow ARIN to participate in such one-way transfers. The staff formally indicate to AFRINIC that the word reciprocal in 8.4 prohibits ARIN from allowing ARIN-registered space to transfer directly to AFRINIC (in this context). ARIN as a community should recognize that other RIR operator communities have different needs than we do. We should recognize that: - network operators in AFRINIC in LACNIC have need to obtain space in the market; - have reasons they think are important to not allow two-way transfers; and - we should understand that the history of the RIR system has led to LACNIC and AFRINIC having multiple orders of magnitude less IPv4 address space than ARIN does. Policy statement: Add the following sentence after the first sentence of NRPM 8.4: Inter-RIR transfers may take place to an RIR with a non-reciprocal inter-RIR transfer policy only when the recipient RIR has an IPv4 total inventory less than the average (mean) of the IPv4 total inventory among all of the RIRs. Timetable for implementation: Upon the ratification of any inter-RIR transfer policy at another RIR that is one-way as described in the problem statement. From mike at iptrading.com Wed Sep 6 14:49:08 2017 From: mike at iptrading.com (Mike Burns) Date: Wed, 6 Sep 2017 14:49:08 -0400 Subject: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers In-Reply-To: <2bc0e7f7-c3d1-c496-1d58-ccec181c6414@arin.net> References: <2bc0e7f7-c3d1-c496-1d58-ccec181c6414@arin.net> Message-ID: <017d01d32740$d283a770$778af650$@iptrading.com> Policy statement: Add the following sentence after the first sentence of NRPM 8.4: Inter-RIR transfers may take place to an RIR with a non-reciprocal inter-RIR transfer policy only when the recipient RIR has an IPv4 total inventory less than the average (mean) of the IPv4 total inventory among all of the RIRs. Hi, Can we get a definition of "IPv4 total inventory"? Do reserves of all flavors count? Does ARIN staff whip out the calculators on the day the transfer request is received? Will they hold transfers in abeyance until the ratios work out, then quickly process them? Does this provide an incentive for LACNIC and AFRINIC to rid themselves of IPv4 reserves? Are all RIR inventories updated daily? The average could change throughout the day unless the RIRs publish at the same time. Imagine the situation of a buyer in AFRINIC, biting his nails to see whether a change in APNIC or RIPE will allow his transfer to go through today. I support the policy but it would be far better to lose that additional sentence. Just drop the world reciprocal and if problems arise they can be dealt with later. Regards, Mike Burns From daveid at panix.com Wed Sep 6 15:02:19 2017 From: daveid at panix.com (David Huberman) Date: Wed, 6 Sep 2017 15:02:19 -0400 Subject: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers In-Reply-To: <017d01d32740$d283a770$778af650$@iptrading.com> References: <2bc0e7f7-c3d1-c496-1d58-ccec181c6414@arin.net> <017d01d32740$d283a770$778af650$@iptrading.com> Message-ID: <05F27819-CEC9-4AE5-AECA-56A835CF08EF@panix.com> Mike, There was considerably more support if we left the qualifier in. It also has the operative effect of achieving the goal I believe you're interested in. David Sent from my iPhone > On Sep 6, 2017, at 2:49 PM, Mike Burns wrote: > > Policy statement: > > Add the following sentence after the first sentence of NRPM 8.4: > > Inter-RIR transfers may take place to an RIR with a non-reciprocal inter-RIR > transfer policy only when the recipient RIR has an IPv4 total inventory less > than the average (mean) of the IPv4 total inventory among all of the RIRs. > > > Hi, > > Can we get a definition of "IPv4 total inventory"? > Do reserves of all flavors count? > Does ARIN staff whip out the calculators on the day the transfer request is > received? > Will they hold transfers in abeyance until the ratios work out, then quickly > process them? > Does this provide an incentive for LACNIC and AFRINIC to rid themselves of > IPv4 reserves? > Are all RIR inventories updated daily? > > The average could change throughout the day unless the RIRs publish at the > same time. Imagine the situation of a buyer in AFRINIC, biting his nails to > see whether a change in APNIC or RIPE will allow his transfer to go through > today. > > I support the policy but it would be far better to lose that additional > sentence. Just drop the world reciprocal and if problems arise they can be > dealt with later. > > Regards, > Mike Burns > > > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From farmer at umn.edu Wed Sep 6 15:31:03 2017 From: farmer at umn.edu (David Farmer) Date: Wed, 6 Sep 2017 14:31:03 -0500 Subject: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers In-Reply-To: <017d01d32740$d283a770$778af650$@iptrading.com> References: <2bc0e7f7-c3d1-c496-1d58-ccec181c6414@arin.net> <017d01d32740$d283a770$778af650$@iptrading.com> Message-ID: On Wed, Sep 6, 2017 at 1:49 PM, Mike Burns wrote: > > Hi, > > Can we get a definition of "IPv4 total inventory"? > Is all IPv4 address space held by the RIR in any pools and that which has been allocated or assigned, legacy or otherwise. I think you are thinking of RIR free pools or available inventory, not total inventory. Look at the NRO slides; https://www.nro.net/wp-content/uploads/NRO_Q2_2017.pdf Slide #5 comes close, but I think it is missing legacy resources, so ARIN has even more than is shown there. The point here is that LACNIC and AFRINIC have way less total inventory and one could argue they don't have a fair share of the global IPv4 resource pool. Therefore requiring them to have a reciprocal transfer policies is some what insensitive to how the IPv4 resources are currently divided on a global level. More than 10 /8s would have to be transferred to LACNIC and AFRINIC each before the had any where near the average total IPv4 inventory of all the RIRs. > Do reserves of all flavors count? > Does ARIN staff whip out the calculators on the day the transfer request is > received? > Will they hold transfers in abeyance until the ratios work out, then > quickly > process them? > Does this provide an incentive for LACNIC and AFRINIC to rid themselves of > IPv4 reserves? > Are all RIR inventories updated daily? > > The average could change throughout the day unless the RIRs publish at the > same time. Imagine the situation of a buyer in AFRINIC, biting his nails to > see whether a change in APNIC or RIPE will allow his transfer to go through > today. > > I support the policy but it would be far better to lose that additional > sentence. Just drop the world reciprocal and if problems arise they can be > dealt with later. > > Regards, > Mike Burns > > > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- =============================================== 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 mike at iptrading.com Wed Sep 6 15:39:38 2017 From: mike at iptrading.com (Mike Burns) Date: Wed, 6 Sep 2017 15:39:38 -0400 Subject: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers In-Reply-To: References: <2bc0e7f7-c3d1-c496-1d58-ccec181c6414@arin.net> <017d01d32740$d283a770$778af650$@iptrading.com> Message-ID: <019701d32747$e062d0d0$a1287270$@iptrading.com> Ah! Thank you David! I though it meant available inventory. I am okay with the sentence in that case and I understand why it was placed there. I support the policy as written. Regards, Mike From: David Farmer [mailto:farmer at umn.edu] Sent: Wednesday, September 06, 2017 3:31 PM To: Mike Burns Cc: ARIN ; arin-ppml at arin.net Subject: Re: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers On Wed, Sep 6, 2017 at 1:49 PM, Mike Burns > wrote: Hi, Can we get a definition of "IPv4 total inventory"? Is all IPv4 address space held by the RIR in any pools and that which has been allocated or assigned, legacy or otherwise. I think you are thinking of RIR free pools or available inventory, not total inventory. Look at the NRO slides; https://www.nro.net/wp-content/uploads/NRO_Q2_2017.pdf Slide #5 comes close, but I think it is missing legacy resources, so ARIN has even more than is shown there. The point here is that LACNIC and AFRINIC have way less total inventory and one could argue they don't have a fair share of the global IPv4 resource pool. Therefore requiring them to have a reciprocal transfer policies is some what insensitive to how the IPv4 resources are currently divided on a global level. More than 10 /8s would have to be transferred to LACNIC and AFRINIC each before the had any where near the average total IPv4 inventory of all the RIRs. Do reserves of all flavors count? Does ARIN staff whip out the calculators on the day the transfer request is received? Will they hold transfers in abeyance until the ratios work out, then quickly process them? Does this provide an incentive for LACNIC and AFRINIC to rid themselves of IPv4 reserves? Are all RIR inventories updated daily? The average could change throughout the day unless the RIRs publish at the same time. Imagine the situation of a buyer in AFRINIC, biting his nails to see whether a change in APNIC or RIPE will allow his transfer to go through today. I support the policy but it would be far better to lose that additional sentence. Just drop the world reciprocal and if problems arise they can be dealt with later. Regards, Mike Burns _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -- =============================================== 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 scottleibrand at gmail.com Wed Sep 6 16:28:53 2017 From: scottleibrand at gmail.com (Scott Leibrand) Date: Wed, 6 Sep 2017 13:28:53 -0700 Subject: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers In-Reply-To: <019701d32747$e062d0d0$a1287270$@iptrading.com> References: <2bc0e7f7-c3d1-c496-1d58-ccec181c6414@arin.net> <017d01d32740$d283a770$778af650$@iptrading.com> <019701d32747$e062d0d0$a1287270$@iptrading.com> Message-ID: +1 (support as written) On Wed, Sep 6, 2017 at 12:39 PM, Mike Burns wrote: > Ah! Thank you David! > > I though it meant available inventory. > > > > I am okay with the sentence in that case and I understand why it was > placed there. > > I support the policy as written. > > > > Regards, > > Mike > > > > > > *From:* David Farmer [mailto:farmer at umn.edu] > *Sent:* Wednesday, September 06, 2017 3:31 PM > *To:* Mike Burns > *Cc:* ARIN ; arin-ppml at arin.net > *Subject:* Re: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity > Requirement for Inter-RIR Transfers > > > > > > > > On Wed, Sep 6, 2017 at 1:49 PM, Mike Burns wrote: > > > Hi, > > Can we get a definition of "IPv4 total inventory"? > > > > Is all IPv4 address space held by the RIR in any pools and that which has > been allocated or assigned, legacy or otherwise. > > > > I think you are thinking of RIR free pools or available inventory, not > total inventory. > > > > Look at the NRO slides; > > https://www.nro.net/wp-content/uploads/NRO_Q2_2017.pdf > > Slide #5 comes close, but I think it is missing legacy resources, so ARIN > has even more than is shown there. > > > > The point here is that LACNIC and AFRINIC have way less total inventory > and one could argue they don't have a fair share of the global IPv4 > resource pool. Therefore requiring them to have a reciprocal transfer > policies is some what insensitive to how the IPv4 resources are currently > divided on a global level. > > > > More than 10 /8s would have to be transferred to LACNIC and AFRINIC each > before the had any where near the average total IPv4 inventory of all the > RIRs. > > > > Do reserves of all flavors count? > Does ARIN staff whip out the calculators on the day the transfer request is > received? > Will they hold transfers in abeyance until the ratios work out, then > quickly > process them? > Does this provide an incentive for LACNIC and AFRINIC to rid themselves of > IPv4 reserves? > Are all RIR inventories updated daily? > > The average could change throughout the day unless the RIRs publish at the > same time. Imagine the situation of a buyer in AFRINIC, biting his nails to > see whether a change in APNIC or RIPE will allow his transfer to go through > today. > > I support the policy but it would be far better to lose that additional > sentence. Just drop the world reciprocal and if problems arise they can be > dealt with later. > > Regards, > Mike Burns > > > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > > > > > -- > > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> > Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> > =============================================== > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cja at daydream.com Wed Sep 6 17:10:09 2017 From: cja at daydream.com (Cj Aronson) Date: Wed, 6 Sep 2017 15:10:09 -0600 Subject: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers In-Reply-To: <2bc0e7f7-c3d1-c496-1d58-ccec181c6414@arin.net> References: <2bc0e7f7-c3d1-c496-1d58-ccec181c6414@arin.net> Message-ID: Okay so this formula.. does it just give us Afrinic and Lacnic right? So why don't we just say that? Since there are only 5 RIRs it seems that maybe a formula isn't needed? {?,?} (( )) ? ? On Wed, Sep 6, 2017 at 12:35 PM, ARIN wrote: > The following has been revised: > > * Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR > Transfers > > Revised text is below and can be found at: > https://www.arin.net/policy/proposals/2017_4.html > > You are encouraged to discuss all Draft Policies on PPML. The AC will > evaluate the discussion in order to assess the conformance of this draft > policy with ARIN's Principles of Internet number resource policy as stated > in the Policy Development Process (PDP). Specifically, these principles are: > > * Enabling Fair and Impartial Number Resource Administration > * Technically Sound > * Supported by the Community > > The PDP can be found at: > https://www.arin.net/policy/pdp.html > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > Regards, > > Sean Hopkins > Policy Analyst > American Registry for Internet Numbers (ARIN) > > > > Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR > Transfers > > Version Date: 6 September 2017 > > Problem Statement: > > AFRINIC and LACNIC are currently considering one-way inter-RIR transfer > proposals. Those RIR communities feel a one-way policy a policy that allows > network operators in their regions to obtain space from another region and > transfer it into AFRINIC and LACNIC may best meet the needs of the > operators in that region. > > ARIN staff, in reply to an inquiry from AFRINIC, have formally indicated > that ARINs 8.4 policy language will not allow ARIN to participate in such > one-way transfers. The staff formally indicate to AFRINIC that the word > reciprocal in 8.4 prohibits ARIN from allowing ARIN-registered space to > transfer directly to AFRINIC (in this context). > > ARIN as a community should recognize that other RIR operator communities > have different needs than we do. We should recognize that: > > - network operators in AFRINIC in LACNIC have need to obtain space in the > market; > > - have reasons they think are important to not allow two-way transfers; and > > - we should understand that the history of the RIR system has led to > LACNIC and AFRINIC having multiple orders of magnitude less IPv4 address > space than ARIN does. > > Policy statement: > > Add the following sentence after the first sentence of NRPM 8.4: > > Inter-RIR transfers may take place to an RIR with a non-reciprocal > inter-RIR transfer policy only when the recipient RIR has an IPv4 total > inventory less than the average (mean) of the IPv4 total inventory among > all of the RIRs. > > Timetable for implementation: Upon the ratification of any inter-RIR > transfer policy at another RIR that is one-way as described in the problem > statement. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at semihuman.com Wed Sep 6 17:19:18 2017 From: chris at semihuman.com (Chris Woodfield) Date: Wed, 6 Sep 2017 14:19:18 -0700 Subject: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers In-Reply-To: References: <2bc0e7f7-c3d1-c496-1d58-ccec181c6414@arin.net> Message-ID: <0D3D1354-0567-40F3-8770-37CA08AD85E7@semihuman.com> This policy proposal seems, to me, as an attempt to correct a historical imbalance in the distribution of IPv4 resources to various RIRs, since the vast majority of legacy space - which, to my eyes, it seems that much of the transfer supply is originating from - is in the ARIN region. Given that, this policy only makes sense up to the point that such imbalance still exists. If we simply named the target RIRs, we could result in a (arguably theoretical) situation where Afrinic and Lacnic wind up transferring enough space to push their totals over the average but are still permitted to transfer space. if that were to happen, it would require a subsequent policy change to keep that imbalance from growing worse. As such, I support as written and would argue against an approach that targets specific RIRs by name. -C > On Sep 6, 2017, at 2:10 PM, Cj Aronson wrote: > > Okay so this formula.. does it just give us Afrinic and Lacnic right? So why don't we just say that? Since there are only 5 RIRs it seems that maybe a formula isn't needed? > > > {?,?} > (( )) > ? ? > > On Wed, Sep 6, 2017 at 12:35 PM, ARIN > wrote: > The following has been revised: > > * Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers > > Revised text is below and can be found at: > https://www.arin.net/policy/proposals/2017_4.html > > You are encouraged to discuss all Draft Policies on PPML. The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet number resource policy as stated in the Policy Development Process (PDP). Specifically, these principles are: > > * Enabling Fair and Impartial Number Resource Administration > * Technically Sound > * Supported by the Community > > The PDP can be found at: > https://www.arin.net/policy/pdp.html > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > Regards, > > Sean Hopkins > Policy Analyst > American Registry for Internet Numbers (ARIN) > > > > Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers > > Version Date: 6 September 2017 > > Problem Statement: > > AFRINIC and LACNIC are currently considering one-way inter-RIR transfer proposals. Those RIR communities feel a one-way policy a policy that allows network operators in their regions to obtain space from another region and transfer it into AFRINIC and LACNIC may best meet the needs of the operators in that region. > > ARIN staff, in reply to an inquiry from AFRINIC, have formally indicated that ARINs 8.4 policy language will not allow ARIN to participate in such one-way transfers. The staff formally indicate to AFRINIC that the word reciprocal in 8.4 prohibits ARIN from allowing ARIN-registered space to transfer directly to AFRINIC (in this context). > > ARIN as a community should recognize that other RIR operator communities have different needs than we do. We should recognize that: > > - network operators in AFRINIC in LACNIC have need to obtain space in the market; > > - have reasons they think are important to not allow two-way transfers; and > > - we should understand that the history of the RIR system has led to LACNIC and AFRINIC having multiple orders of magnitude less IPv4 address space than ARIN does. > > Policy statement: > > Add the following sentence after the first sentence of NRPM 8.4: > > Inter-RIR transfers may take place to an RIR with a non-reciprocal inter-RIR transfer policy only when the recipient RIR has an IPv4 total inventory less than the average (mean) of the IPv4 total inventory among all of the RIRs. > > Timetable for implementation: Upon the ratification of any inter-RIR transfer policy at another RIR that is one-way as described in the problem statement. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Wed Sep 6 17:18:52 2017 From: owen at delong.com (Owen DeLong) Date: Wed, 6 Sep 2017 14:18:52 -0700 Subject: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers In-Reply-To: References: <2bc0e7f7-c3d1-c496-1d58-ccec181c6414@arin.net> <017d01d32740$d283a770$778af650$@iptrading.com> Message-ID: <12B95E6A-3D36-4D2D-9257-ADF599077A83@delong.com> If it includes all IPv4 whether allocated or not, then I am opposed to the policy once again. It completely defeats the purpose of the qualifier. Owen > On Sep 6, 2017, at 12:31 , David Farmer wrote: > > > > On Wed, Sep 6, 2017 at 1:49 PM, Mike Burns > wrote: > > Hi, > > Can we get a definition of "IPv4 total inventory"? > > Is all IPv4 address space held by the RIR in any pools and that which has been allocated or assigned, legacy or otherwise. > > I think you are thinking of RIR free pools or available inventory, not total inventory. > > Look at the NRO slides; > https://www.nro.net/wp-content/uploads/NRO_Q2_2017.pdf > Slide #5 comes close, but I think it is missing legacy resources, so ARIN has even more than is shown there. > > The point here is that LACNIC and AFRINIC have way less total inventory and one could argue they don't have a fair share of the global IPv4 resource pool. Therefore requiring them to have a reciprocal transfer policies is some what insensitive to how the IPv4 resources are currently divided on a global level. > > More than 10 /8s would have to be transferred to LACNIC and AFRINIC each before the had any where near the average total IPv4 inventory of all the RIRs. > > Do reserves of all flavors count? > Does ARIN staff whip out the calculators on the day the transfer request is > received? > Will they hold transfers in abeyance until the ratios work out, then quickly > process them? > Does this provide an incentive for LACNIC and AFRINIC to rid themselves of > IPv4 reserves? > Are all RIR inventories updated daily? > > The average could change throughout the day unless the RIRs publish at the > same time. Imagine the situation of a buyer in AFRINIC, biting his nails to > see whether a change in APNIC or RIPE will allow his transfer to go through > today. > > I support the policy but it would be far better to lose that additional > sentence. Just drop the world reciprocal and if problems arise they can be > dealt with later. > > Regards, > Mike Burns > > > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =============================================== > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cja at daydream.com Wed Sep 6 17:36:37 2017 From: cja at daydream.com (Cathy Aronson) Date: Wed, 6 Sep 2017 15:36:37 -0600 Subject: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers In-Reply-To: <0D3D1354-0567-40F3-8770-37CA08AD85E7@semihuman.com> References: <2bc0e7f7-c3d1-c496-1d58-ccec181c6414@arin.net> <0D3D1354-0567-40F3-8770-37CA08AD85E7@semihuman.com> Message-ID: <5CD7B623-6D80-4C13-8DB0-FCDA3509E80E@daydream.com> Has anyone looked at how long it would take for the formula to tell Lacnic or Afrinic based on current run rate? Thanks Cathy Ps. Against this prop as written Sent from a handheld device. > On Sep 6, 2017, at 3:19 PM, Chris Woodfield wrote: > > This policy proposal seems, to me, as an attempt to correct a historical imbalance in the distribution of IPv4 resources to various RIRs, since the vast majority of legacy space - which, to my eyes, it seems that much of the transfer supply is originating from - is in the ARIN region. > > Given that, this policy only makes sense up to the point that such imbalance still exists. If we simply named the target RIRs, we could result in a (arguably theoretical) situation where Afrinic and Lacnic wind up transferring enough space to push their totals over the average but are still permitted to transfer space. if that were to happen, it would require a subsequent policy change to keep that imbalance from growing worse. > > As such, I support as written and would argue against an approach that targets specific RIRs by name. > > -C > >> On Sep 6, 2017, at 2:10 PM, Cj Aronson wrote: >> >> Okay so this formula.. does it just give us Afrinic and Lacnic right? So why don't we just say that? Since there are only 5 RIRs it seems that maybe a formula isn't needed? >> >> >> {?,?} >> (( )) >> ? ? >> >>> On Wed, Sep 6, 2017 at 12:35 PM, ARIN wrote: >>> The following has been revised: >>> >>> * Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers >>> >>> Revised text is below and can be found at: >>> https://www.arin.net/policy/proposals/2017_4.html >>> >>> You are encouraged to discuss all Draft Policies on PPML. The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet number resource policy as stated in the Policy Development Process (PDP). Specifically, these principles are: >>> >>> * Enabling Fair and Impartial Number Resource Administration >>> * Technically Sound >>> * Supported by the Community >>> >>> The PDP can be found at: >>> https://www.arin.net/policy/pdp.html >>> >>> Draft Policies and Proposals under discussion can be found at: >>> https://www.arin.net/policy/proposals/index.html >>> >>> Regards, >>> >>> Sean Hopkins >>> Policy Analyst >>> American Registry for Internet Numbers (ARIN) >>> >>> >>> >>> Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers >>> >>> Version Date: 6 September 2017 >>> >>> Problem Statement: >>> >>> AFRINIC and LACNIC are currently considering one-way inter-RIR transfer proposals. Those RIR communities feel a one-way policy a policy that allows network operators in their regions to obtain space from another region and transfer it into AFRINIC and LACNIC may best meet the needs of the operators in that region. >>> >>> ARIN staff, in reply to an inquiry from AFRINIC, have formally indicated that ARINs 8.4 policy language will not allow ARIN to participate in such one-way transfers. The staff formally indicate to AFRINIC that the word reciprocal in 8.4 prohibits ARIN from allowing ARIN-registered space to transfer directly to AFRINIC (in this context). >>> >>> ARIN as a community should recognize that other RIR operator communities have different needs than we do. We should recognize that: >>> >>> - network operators in AFRINIC in LACNIC have need to obtain space in the market; >>> >>> - have reasons they think are important to not allow two-way transfers; and >>> >>> - we should understand that the history of the RIR system has led to LACNIC and AFRINIC having multiple orders of magnitude less IPv4 address space than ARIN does. >>> >>> Policy statement: >>> >>> Add the following sentence after the first sentence of NRPM 8.4: >>> >>> Inter-RIR transfers may take place to an RIR with a non-reciprocal inter-RIR transfer policy only when the recipient RIR has an IPv4 total inventory less than the average (mean) of the IPv4 total inventory among all of the RIRs. >>> >>> Timetable for implementation: Upon the ratification of any inter-RIR transfer policy at another RIR that is one-way as described in the problem statement. >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to >>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at arin.net if you experience any issues. >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmer at umn.edu Wed Sep 6 17:43:44 2017 From: farmer at umn.edu (David Farmer) Date: Wed, 6 Sep 2017 16:43:44 -0500 Subject: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers In-Reply-To: References: <2bc0e7f7-c3d1-c496-1d58-ccec181c6414@arin.net> <017d01d32740$d283a770$778af650$@iptrading.com> Message-ID: I just confirmed ARIN staff has the same interpretation as I said below, the following is from the Staff & Legal Assessment at; https://www.arin.net/policy/proposals/2017_4.html A snapshot of the current existing "total" RIR IPv4 inventories computed based on the extended stats file are: ARIN has 1.687 billion IPv4 addresses in its inventory. APNIC has 881 million IPv4 addresses in its inventory. RIPE has 822 million IPv4 addresses in its inventory. LACNIC has 191 million IPv4 addresses in its inventory. AFRINIC has 121 million IPv4 addresses in its inventory. Global average: 740 million IPv4 addresses. Thanks On Wed, Sep 6, 2017 at 2:31 PM, David Farmer wrote: > > > On Wed, Sep 6, 2017 at 1:49 PM, Mike Burns wrote: > >> >> Hi, >> >> Can we get a definition of "IPv4 total inventory"? >> > > Is all IPv4 address space held by the RIR in any pools and that which has > been allocated or assigned, legacy or otherwise. > > I think you are thinking of RIR free pools or available inventory, not > total inventory. > > Look at the NRO slides; > https://www.nro.net/wp-content/uploads/NRO_Q2_2017.pdf > Slide #5 comes close, but I think it is missing legacy resources, so ARIN > has even more than is shown there. > > The point here is that LACNIC and AFRINIC have way less total inventory > and one could argue they don't have a fair share of the global IPv4 > resource pool. Therefore requiring them to have a reciprocal transfer > policies is some what insensitive to how the IPv4 resources are currently > divided on a global level. > > More than 10 /8s would have to be transferred to LACNIC and AFRINIC each > before the had any where near the average total IPv4 inventory of all the > RIRs. > > >> Do reserves of all flavors count? >> Does ARIN staff whip out the calculators on the day the transfer request >> is >> received? >> Will they hold transfers in abeyance until the ratios work out, then >> quickly >> process them? >> Does this provide an incentive for LACNIC and AFRINIC to rid themselves of >> IPv4 reserves? >> Are all RIR inventories updated daily? >> >> The average could change throughout the day unless the RIRs publish at the >> same time. Imagine the situation of a buyer in AFRINIC, biting his nails >> to >> see whether a change in APNIC or RIPE will allow his transfer to go >> through >> today. >> >> I support the policy but it would be far better to lose that additional >> sentence. Just drop the world reciprocal and if problems arise they can be >> dealt with later. >> >> Regards, >> Mike Burns >> >> >> >> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> > > > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> > Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> > =============================================== > -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From ndavis at arin.net Wed Sep 6 17:46:59 2017 From: ndavis at arin.net (Nate Davis) Date: Wed, 6 Sep 2017 21:46:59 +0000 Subject: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers In-Reply-To: <017d01d32740$d283a770$778af650$@iptrading.com> References: <2bc0e7f7-c3d1-c496-1d58-ccec181c6414@arin.net> <017d01d32740$d283a770$778af650$@iptrading.com> Message-ID: Mike (et al.), Please see ARIN staff responses to your questions, inline below On 9/6/17, 2:49 PM, "ARIN-PPML on behalf of Mike Burns" wrote: >Policy statement: > >Add the following sentence after the first sentence of NRPM 8.4: > >Inter-RIR transfers may take place to an RIR with a non-reciprocal >inter-RIR >transfer policy only when the recipient RIR has an IPv4 total inventory >less >than the average (mean) of the IPv4 total inventory among all of the RIRs. > > >Hi, > >Can we get a definition of "IPv4 total inventory"? ARIN Staff interprets total inventory to include all IPv4 number resources held at each RIR in accordance to extended stats file which is published daily by each RIR. Here are the numbers that were pulled on May 19 and to contrast the numbers pulled today (110 days later) ARIN: 1,687,030,272 -> 1,686,159,104 (loss of 871,168) APNIC: 880,795,648 -> 881,734,912 (gain of 939,264) RIPE: 822,375,168 -> 822,316,800 (loss of 58,368) LACNIC: 190,775,552 -> 190,775,552 (no change) AFRINIC: 121,242,624 -> 121,242,624 (no change) Global average: 740,445,798 >Do reserves of all flavors count? The extended stats file includes all reserves.Does ARIN staff whip out the calculators on the day the transfer request is received? >Will they hold transfers in abeyance until the ratios work out, then >quickly >process them? To go below the global average, the RIR above the average and closest to it would need to lose 81,871,002 more addresses, which at the current rate (14,592 lost per month) would take 5,620 months (468 years). >Does this provide an incentive for LACNIC and AFRINIC to rid themselves of >IPv4 reserves? ARIN cannot speak to the intentions of other RIRs. Are all RIR inventories updated daily? Yes, current practice is for each RIR to update their extended stats on a daily basis. > >The average could change throughout the day unless the RIRs publish at the >same time. Imagine the situation of a buyer in AFRINIC, biting his nails >to >see whether a change in APNIC or RIPE will allow his transfer to go >through >today. For purposes of implementation of this draft policy ARIN would establish each RIR?s eligibility for transfers on a semi-annual basis. The magnitude of the numbers does not necessitate a more frequent review. I support the policy but it would be far better to lose that additional sentence. Just drop the world reciprocal and if problems arise they can be dealt with later. Regards, Mike Burns I hope this answers your questions. Regards, Nate Davis Chief Operating Officer American Registry for Internet Numbers _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From hostmaster at uneedus.com Wed Sep 6 14:59:46 2017 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Wed, 6 Sep 2017 14:59:46 -0400 (EDT) Subject: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers In-Reply-To: <2bc0e7f7-c3d1-c496-1d58-ccec181c6414@arin.net> References: <2bc0e7f7-c3d1-c496-1d58-ccec181c6414@arin.net> Message-ID: So based on this policy and the current numbers, which RIR's are covered by this statement? Is that LACNIC and AFRINIC only? Albert Erdmann Network Administrator Paradise On Line Inc. On Wed, 6 Sep 2017, ARIN wrote: > The following has been revised: > > * Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR > Transfers > > Revised text is below and can be found at: > https://www.arin.net/policy/proposals/2017_4.html > > You are encouraged to discuss all Draft Policies on PPML. The AC will > evaluate the discussion in order to assess the conformance of this draft > policy with ARIN's Principles of Internet number resource policy as stated in > the Policy Development Process (PDP). Specifically, these principles are: > > * Enabling Fair and Impartial Number Resource Administration > * Technically Sound > * Supported by the Community > > The PDP can be found at: > https://www.arin.net/policy/pdp.html > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > Regards, > > Sean Hopkins > Policy Analyst > American Registry for Internet Numbers (ARIN) > > > > Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR > Transfers > > Version Date: 6 September 2017 > > Problem Statement: > > AFRINIC and LACNIC are currently considering one-way inter-RIR transfer > proposals. Those RIR communities feel a one-way policy a policy that allows > network operators in their regions to obtain space from another region and > transfer it into AFRINIC and LACNIC may best meet the needs of the operators > in that region. > > ARIN staff, in reply to an inquiry from AFRINIC, have formally indicated that > ARINs 8.4 policy language will not allow ARIN to participate in such one-way > transfers. The staff formally indicate to AFRINIC that the word reciprocal in > 8.4 prohibits ARIN from allowing ARIN-registered space to transfer directly > to AFRINIC (in this context). > > ARIN as a community should recognize that other RIR operator communities have > different needs than we do. We should recognize that: > > - network operators in AFRINIC in LACNIC have need to obtain space in the > market; > > - have reasons they think are important to not allow two-way transfers; and > > - we should understand that the history of the RIR system has led to LACNIC > and AFRINIC having multiple orders of magnitude less IPv4 address space than > ARIN does. > > Policy statement: > > Add the following sentence after the first sentence of NRPM 8.4: > > Inter-RIR transfers may take place to an RIR with a non-reciprocal inter-RIR > transfer policy only when the recipient RIR has an IPv4 total inventory less > than the average (mean) of the IPv4 total inventory among all of the RIRs. > > Timetable for implementation: Upon the ratification of any inter-RIR transfer > policy at another RIR that is one-way as described in the problem statement. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From hostmaster at uneedus.com Wed Sep 6 18:10:41 2017 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Wed, 6 Sep 2017 18:10:41 -0400 (EDT) Subject: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers In-Reply-To: <2bc0e7f7-c3d1-c496-1d58-ccec181c6414@arin.net> References: <2bc0e7f7-c3d1-c496-1d58-ccec181c6414@arin.net> Message-ID: Now that discussion reveals that "IPv4 Inventory", refers to the total number of IPv4 addresses that a specific RIR has under its management, and not the amount of IPv4 addresses remaining for assignment, I will state the problems I see with the proposal. However, I remain open minded and am asking questions in order to make up my mind. If any of the history of numbering management that I state below is wrong, please let me know, as it might change my viewpoint. 1) Originally there was effectively only one RIR worldwide. 2) This original RIR's Resources were placed under control of ARIN. 3) When each of the RIR's other than ARIN were formed, all resources that were assigned to entities within the region of the new RIR, that were under management of ARIN, or the RIR which previously managed the space (RIPE to AFRINIC in that case) were transfered to the new RIR. 4) The Previous RIR's who controled resources before the formation of LACNIC or AFRINIC did not have a policy in place that discriminated against any portion of the world, and would if presented with a request for IPv4 resources, would process that request using the same policy that was used for resources assigned in the remaining portions of that RIR's Territory. With each of these things said, I now draw some conclusions. Specifically, it is not North America's or ARIN's fault that LACNIC and AFRINIC has less resources under management than ARIN or RIPE or APNIC. Had networks needing resources existed during this time, and all the way past their formation up until that date that IANA ran out of /8's, that RIR could have received IPv4 addresses from the free pool on an equal basis. While the original Class A networks were given out a lot more loosely than ARIN's standards, this did not change the fact that IANA had a free pool after these original Class A networks were assigned, and did provide additional /8's to any RIR who could show that they had exhausted their free pool below the standard that was applied to all 5 RIR's. In my opinion the only reason that LACNIC and AFRINIC did not have as many /8's, was the growth in the APNIC region compared to all other regions, which during that time exceeded every other RIR, including ARIN. In fact, it was APNIC's request for more space that triggered the exhaustion of the free pool. Technically, when LACNIC and AFRINIC received their final /8, it was not totally fair to the other RIR's with more addresses under management. In fact, this final non proportional oversupply at AFRINIC is likely the only reason that AFRINIC is the only RIR with a general free pool. Instead of a full /8 to each region, maybe this should have been done more proportional to each region's total address space under management. For a market based solution to IPv4 addresses, addresses need to be able to flow both ways. AFRINIC and LACNIC can argue that we are the small guys, and we need to be protected against transfers out. However, I can just as easily argue that ARIN is being used as a worldwide piggy bank of IPv4 addresses and should also adopt an anti-transfer out policy. As long as things move both ways, we can argue that the market effect is important, but for this to work, it must be bidirectional everywhere. While ARIN is the leader in supplying directed transfer addresses, market conditions could change worldwide, causing more transfers from another RIR. For an example, say if China were to require ALL internet to use IPv6, and forbid the use of IPv4 in their country, a large number of IPv4 addresses allocated to China would suddenly be available on the transfer market. Some similar event that is now unknown could drive the IPv4 addresses of the LACNIC and AFRINIC into the market, and if this policy were adopted would be unfair to the markets that would be forbidden from these addresses being in the market because of the lack of a bidirectional transfer rule. My gut tells me that noone should get a pass on bidirectional transfers, and I am leaning NO at this time, but could be convinced otherwise for the proper reason. I do not think "Past Discrimination" is that reason. The true past problem was lack of past network growth, vs other regions. Albert Erdmann Network Administrator Paradise On Line Inc. On Wed, 6 Sep 2017, ARIN wrote: > The following has been revised: > > * Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR > Transfers > > Revised text is below and can be found at: > https://www.arin.net/policy/proposals/2017_4.html > > You are encouraged to discuss all Draft Policies on PPML. The AC will > evaluate the discussion in order to assess the conformance of this draft > policy with ARIN's Principles of Internet number resource policy as stated in > the Policy Development Process (PDP). Specifically, these principles are: > > * Enabling Fair and Impartial Number Resource Administration > * Technically Sound > * Supported by the Community > > The PDP can be found at: > https://www.arin.net/policy/pdp.html > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > Regards, > > Sean Hopkins > Policy Analyst > American Registry for Internet Numbers (ARIN) > > > > Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR > Transfers > > Version Date: 6 September 2017 > > Problem Statement: > > AFRINIC and LACNIC are currently considering one-way inter-RIR transfer > proposals. Those RIR communities feel a one-way policy a policy that allows > network operators in their regions to obtain space from another region and > transfer it into AFRINIC and LACNIC may best meet the needs of the operators > in that region. > > ARIN staff, in reply to an inquiry from AFRINIC, have formally indicated that > ARINs 8.4 policy language will not allow ARIN to participate in such one-way > transfers. The staff formally indicate to AFRINIC that the word reciprocal in > 8.4 prohibits ARIN from allowing ARIN-registered space to transfer directly > to AFRINIC (in this context). > > ARIN as a community should recognize that other RIR operator communities have > different needs than we do. We should recognize that: > > - network operators in AFRINIC in LACNIC have need to obtain space in the > market; > > - have reasons they think are important to not allow two-way transfers; and > > - we should understand that the history of the RIR system has led to LACNIC > and AFRINIC having multiple orders of magnitude less IPv4 address space than > ARIN does. > > Policy statement: > > Add the following sentence after the first sentence of NRPM 8.4: > > Inter-RIR transfers may take place to an RIR with a non-reciprocal inter-RIR > transfer policy only when the recipient RIR has an IPv4 total inventory less > than the average (mean) of the IPv4 total inventory among all of the RIRs. > > Timetable for implementation: Upon the ratification of any inter-RIR transfer > policy at another RIR that is one-way as described in the problem statement. > _______________________________________________ > 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 mwinters at edwardrose.com Thu Sep 7 08:21:01 2017 From: mwinters at edwardrose.com (Michael Winters) Date: Thu, 7 Sep 2017 12:21:01 +0000 Subject: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers In-Reply-To: <0D3D1354-0567-40F3-8770-37CA08AD85E7@semihuman.com> References: <2bc0e7f7-c3d1-c496-1d58-ccec181c6414@arin.net> <0D3D1354-0567-40F3-8770-37CA08AD85E7@semihuman.com> Message-ID: <947590f72de642d690bb464342a2ea16@kz-mail01.manifold.edwardrosekzoo.com> I am opposed to this policy. From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Chris Woodfield Sent: Wednesday, September 6, 2017 5:19 PM To: Cj Aronson Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers This policy proposal seems, to me, as an attempt to correct a historical imbalance in the distribution of IPv4 resources to various RIRs, since the vast majority of legacy space - which, to my eyes, it seems that much of the transfer supply is originating from - is in the ARIN region. Given that, this policy only makes sense up to the point that such imbalance still exists. If we simply named the target RIRs, we could result in a (arguably theoretical) situation where Afrinic and Lacnic wind up transferring enough space to push their totals over the average but are still permitted to transfer space. if that were to happen, it would require a subsequent policy change to keep that imbalance from growing worse. As such, I support as written and would argue against an approach that targets specific RIRs by name. -C On Sep 6, 2017, at 2:10 PM, Cj Aronson > wrote: Okay so this formula.. does it just give us Afrinic and Lacnic right? So why don't we just say that? Since there are only 5 RIRs it seems that maybe a formula isn't needed? {?,?} (( )) ? ? On Wed, Sep 6, 2017 at 12:35 PM, ARIN > wrote: The following has been revised: * Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers Revised text is below and can be found at: https://www.arin.net/policy/proposals/2017_4.html You are encouraged to discuss all Draft Policies on PPML. The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet number resource policy as stated in the Policy Development Process (PDP). Specifically, these principles are: * Enabling Fair and Impartial Number Resource Administration * Technically Sound * Supported by the Community The PDP can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Sean Hopkins Policy Analyst American Registry for Internet Numbers (ARIN) Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers Version Date: 6 September 2017 Problem Statement: AFRINIC and LACNIC are currently considering one-way inter-RIR transfer proposals. Those RIR communities feel a one-way policy a policy that allows network operators in their regions to obtain space from another region and transfer it into AFRINIC and LACNIC may best meet the needs of the operators in that region. ARIN staff, in reply to an inquiry from AFRINIC, have formally indicated that ARINs 8.4 policy language will not allow ARIN to participate in such one-way transfers. The staff formally indicate to AFRINIC that the word reciprocal in 8.4 prohibits ARIN from allowing ARIN-registered space to transfer directly to AFRINIC (in this context). ARIN as a community should recognize that other RIR operator communities have different needs than we do. We should recognize that: - network operators in AFRINIC in LACNIC have need to obtain space in the market; - have reasons they think are important to not allow two-way transfers; and - we should understand that the history of the RIR system has led to LACNIC and AFRINIC having multiple orders of magnitude less IPv4 address space than ARIN does. Policy statement: Add the following sentence after the first sentence of NRPM 8.4: Inter-RIR transfers may take place to an RIR with a non-reciprocal inter-RIR transfer policy only when the recipient RIR has an IPv4 total inventory less than the average (mean) of the IPv4 total inventory among all of the RIRs. Timetable for implementation: Upon the ratification of any inter-RIR transfer policy at another RIR that is one-way as described in the problem statement. _______________________________________________ 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 kevinb at thewire.ca Thu Sep 7 08:30:22 2017 From: kevinb at thewire.ca (Kevin Blumberg) Date: Thu, 7 Sep 2017 12:30:22 +0000 Subject: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers In-Reply-To: <2bc0e7f7-c3d1-c496-1d58-ccec181c6414@arin.net> References: <2bc0e7f7-c3d1-c496-1d58-ccec181c6414@arin.net> Message-ID: <7E7773B523E82C478734E793E58F69E7A52773A8@SBS2011.thewireinc.local> Are there active polices in the other regions that rely on this policy? I understand there have been discussions, however I don't know what the status is/was. Thanks, Kevin Blumberg -----Original Message----- From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN Sent: Wednesday, September 6, 2017 2:36 PM To: arin-ppml at arin.net Subject: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers The following has been revised: * Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers Revised text is below and can be found at: https://www.arin.net/policy/proposals/2017_4.html You are encouraged to discuss all Draft Policies on PPML. The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet number resource policy as stated in the Policy Development Process (PDP). Specifically, these principles are: * Enabling Fair and Impartial Number Resource Administration * Technically Sound * Supported by the Community The PDP can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Sean Hopkins Policy Analyst American Registry for Internet Numbers (ARIN) Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers Version Date: 6 September 2017 Problem Statement: AFRINIC and LACNIC are currently considering one-way inter-RIR transfer proposals. Those RIR communities feel a one-way policy a policy that allows network operators in their regions to obtain space from another region and transfer it into AFRINIC and LACNIC may best meet the needs of the operators in that region. ARIN staff, in reply to an inquiry from AFRINIC, have formally indicated that ARINs 8.4 policy language will not allow ARIN to participate in such one-way transfers. The staff formally indicate to AFRINIC that the word reciprocal in 8.4 prohibits ARIN from allowing ARIN-registered space to transfer directly to AFRINIC (in this context). ARIN as a community should recognize that other RIR operator communities have different needs than we do. We should recognize that: - network operators in AFRINIC in LACNIC have need to obtain space in the market; - have reasons they think are important to not allow two-way transfers; and - we should understand that the history of the RIR system has led to LACNIC and AFRINIC having multiple orders of magnitude less IPv4 address space than ARIN does. Policy statement: Add the following sentence after the first sentence of NRPM 8.4: Inter-RIR transfers may take place to an RIR with a non-reciprocal inter-RIR transfer policy only when the recipient RIR has an IPv4 total inventory less than the average (mean) of the IPv4 total inventory among all of the RIRs. Timetable for implementation: Upon the ratification of any inter-RIR transfer policy at another RIR that is one-way as described in the problem statement. _______________________________________________ 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 mike at iptrading.com Thu Sep 7 09:39:02 2017 From: mike at iptrading.com (Mike Burns) Date: Thu, 7 Sep 2017 09:39:02 -0400 Subject: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers In-Reply-To: <7E7773B523E82C478734E793E58F69E7A52773A8@SBS2011.thewireinc.local> References: <2bc0e7f7-c3d1-c496-1d58-ccec181c6414@arin.net> <7E7773B523E82C478734E793E58F69E7A52773A8@SBS2011.thewireinc.local> Message-ID: <030f01d327de$ab148cb0$013da610$@iptrading.com> Hi Kevin, LACNIC will be presented with a one-way policy proposal in Montevideo in a few weeks. It has failed to reach consensus twice but was returned to the list, so it will be voted on again. https://politicas.lacnic.net/politicas/detail/id/LAC-2017-2 Regards, Mike -----Original Message----- From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Kevin Blumberg Sent: Thursday, September 07, 2017 8:30 AM To: arin-ppml at arin.net Subject: Re: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers Are there active polices in the other regions that rely on this policy? I understand there have been discussions, however I don't know what the status is/was. Thanks, Kevin Blumberg -----Original Message----- From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN Sent: Wednesday, September 6, 2017 2:36 PM To: arin-ppml at arin.net Subject: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers The following has been revised: * Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers Revised text is below and can be found at: https://www.arin.net/policy/proposals/2017_4.html You are encouraged to discuss all Draft Policies on PPML. The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet number resource policy as stated in the Policy Development Process (PDP). Specifically, these principles are: * Enabling Fair and Impartial Number Resource Administration * Technically Sound * Supported by the Community The PDP can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Sean Hopkins Policy Analyst American Registry for Internet Numbers (ARIN) Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers Version Date: 6 September 2017 Problem Statement: AFRINIC and LACNIC are currently considering one-way inter-RIR transfer proposals. Those RIR communities feel a one-way policy a policy that allows network operators in their regions to obtain space from another region and transfer it into AFRINIC and LACNIC may best meet the needs of the operators in that region. ARIN staff, in reply to an inquiry from AFRINIC, have formally indicated that ARINs 8.4 policy language will not allow ARIN to participate in such one-way transfers. The staff formally indicate to AFRINIC that the word reciprocal in 8.4 prohibits ARIN from allowing ARIN-registered space to transfer directly to AFRINIC (in this context). ARIN as a community should recognize that other RIR operator communities have different needs than we do. We should recognize that: - network operators in AFRINIC in LACNIC have need to obtain space in the market; - have reasons they think are important to not allow two-way transfers; and - we should understand that the history of the RIR system has led to LACNIC and AFRINIC having multiple orders of magnitude less IPv4 address space than ARIN does. Policy statement: Add the following sentence after the first sentence of NRPM 8.4: Inter-RIR transfers may take place to an RIR with a non-reciprocal inter-RIR transfer policy only when the recipient RIR has an IPv4 total inventory less than the average (mean) of the IPv4 total inventory among all of the RIRs. Timetable for implementation: Upon the ratification of any inter-RIR transfer policy at another RIR that is one-way as described in the problem statement. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From bjones at vt.edu Thu Sep 7 11:47:38 2017 From: bjones at vt.edu (Brian Jones) Date: Thu, 07 Sep 2017 15:47:38 +0000 Subject: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers In-Reply-To: <2bc0e7f7-c3d1-c496-1d58-ccec181c6414@arin.net> References: <2bc0e7f7-c3d1-c496-1d58-ccec181c6414@arin.net> Message-ID: I support this policy as revised. -- Brian On Wed, Sep 6, 2017 at 2:35 PM ARIN wrote: > The following has been revised: > > * Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR > Transfers > > Revised text is below and can be found at: > https://www.arin.net/policy/proposals/2017_4.html > > You are encouraged to discuss all Draft Policies on PPML. The AC will > evaluate the discussion in order to assess the conformance of this draft > policy with ARIN's Principles of Internet number resource policy as > stated in the Policy Development Process (PDP). Specifically, these > principles are: > > * Enabling Fair and Impartial Number Resource Administration > * Technically Sound > * Supported by the Community > > The PDP can be found at: > https://www.arin.net/policy/pdp.html > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > Regards, > > Sean Hopkins > Policy Analyst > American Registry for Internet Numbers (ARIN) > > > > Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR > Transfers > > Version Date: 6 September 2017 > > Problem Statement: > > AFRINIC and LACNIC are currently considering one-way inter-RIR transfer > proposals. Those RIR communities feel a one-way policy a policy that > allows network operators in their regions to obtain space from another > region and transfer it into AFRINIC and LACNIC may best meet the needs > of the operators in that region. > > ARIN staff, in reply to an inquiry from AFRINIC, have formally indicated > that ARINs 8.4 policy language will not allow ARIN to participate in > such one-way transfers. The staff formally indicate to AFRINIC that the > word reciprocal in 8.4 prohibits ARIN from allowing ARIN-registered > space to transfer directly to AFRINIC (in this context). > > ARIN as a community should recognize that other RIR operator communities > have different needs than we do. We should recognize that: > > - network operators in AFRINIC in LACNIC have need to obtain space in > the market; > > - have reasons they think are important to not allow two-way transfers; and > > - we should understand that the history of the RIR system has led to > LACNIC and AFRINIC having multiple orders of magnitude less IPv4 address > space than ARIN does. > > Policy statement: > > Add the following sentence after the first sentence of NRPM 8.4: > > Inter-RIR transfers may take place to an RIR with a non-reciprocal > inter-RIR transfer policy only when the recipient RIR has an IPv4 total > inventory less than the average (mean) of the IPv4 total inventory among > all of the RIRs. > > Timetable for implementation: Upon the ratification of any inter-RIR > transfer policy at another RIR that is one-way as described in the > problem statement. > _______________________________________________ > 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 Thu Sep 7 11:57:27 2017 From: bill at herrin.us (William Herrin) Date: Thu, 7 Sep 2017 11:57:27 -0400 Subject: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers In-Reply-To: <2bc0e7f7-c3d1-c496-1d58-ccec181c6414@arin.net> References: <2bc0e7f7-c3d1-c496-1d58-ccec181c6414@arin.net> Message-ID: On Wed, Sep 6, 2017 at 2:35 PM, ARIN wrote: > Policy statement: > > Add the following sentence after the first sentence of NRPM 8.4: > > Inter-RIR transfers may take place to an RIR with a non-reciprocal > inter-RIR transfer policy only when the recipient RIR has an IPv4 total > inventory less than the average (mean) of the IPv4 total inventory among > all of the RIRs. > Hello, I am violently OPPOSED to this proposal, as I am against any proposal which offers out-region registrants less restrictive access to ARIN-region addresses than is offered to ARIN-region registrants. Which the text of this proposal clearly does. Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: -------------- next part -------------- An HTML attachment was scrubbed... URL: From rudi.daniel at gmail.com Thu Sep 7 12:25:52 2017 From: rudi.daniel at gmail.com (Rudolph Daniel) Date: Thu, 7 Sep 2017 12:25:52 -0400 Subject: [arin-ppml] policy proposal 2017-4 removal of reciprocity requirements In-Reply-To: References: Message-ID: I oppose the proposed policy. Quoting Chris Woodfield (?) where Afrinic and Lacnic wind up transferring enough space to push their totals over the average but are still permitted to transfer space. if that were to happen, it would require a subsequent policy change to keep that imbalance from growing worse. end quote In addition, I am not convinced that it should be ARIN's role to correct perceived global RIR framework inbalances? We currently have a working policy strategy in this area, and I think we should stick with it for now. rd On Sep 7, 2017 9:39 AM, wrote: Send ARIN-PPML mailing list submissions to arin-ppml at arin.net To subscribe or unsubscribe via the World Wide Web, visit http://lists.arin.net/mailman/listinfo/arin-ppml or, via email, send a message with subject or body 'help' to arin-ppml-request at arin.net You can reach the person managing the list at arin-ppml-owner at arin.net When replying, please edit your Subject line so it is more specific than "Re: Contents of ARIN-PPML digest..." Today's Topics: 1. Re: Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers (Michael Winters) 2. Re: Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers (Kevin Blumberg) 3. Re: Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers (Mike Burns) ---------------------------------------------------------------------- Message: 1 Date: Thu, 7 Sep 2017 12:21:01 +0000 From: Michael Winters To: "arin-ppml at arin.net" Subject: Re: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers Message-ID: <947590f72de642d690bb464342a2ea16 at kz-mail01.manifold. edwardrosekzoo.com> Content-Type: text/plain; charset="utf-8" I am opposed to this policy. From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Chris Woodfield Sent: Wednesday, September 6, 2017 5:19 PM To: Cj Aronson Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers This policy proposal seems, to me, as an attempt to correct a historical imbalance in the distribution of IPv4 resources to various RIRs, since the vast majority of legacy space - which, to my eyes, it seems that much of the transfer supply is originating from - is in the ARIN region. Given that, this policy only makes sense up to the point that such imbalance still exists. If we simply named the target RIRs, we could result in a (arguably theoretical) situation where Afrinic and Lacnic wind up transferring enough space to push their totals over the average but are still permitted to transfer space. if that were to happen, it would require a subsequent policy change to keep that imbalance from growing worse. As such, I support as written and would argue against an approach that targets specific RIRs by name. -C On Sep 6, 2017, at 2:10 PM, Cj Aronson > wrote: Okay so this formula.. does it just give us Afrinic and Lacnic right? So why don't we just say that? Since there are only 5 RIRs it seems that maybe a formula isn't needed? {?,?} (( )) ? ? On Wed, Sep 6, 2017 at 12:35 PM, ARIN > wrote: The following has been revised: * Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers Revised text is below and can be found at: https://www.arin.net/policy/proposals/2017_4.html You are encouraged to discuss all Draft Policies on PPML. The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet number resource policy as stated in the Policy Development Process (PDP). Specifically, these principles are: * Enabling Fair and Impartial Number Resource Administration * Technically Sound * Supported by the Community The PDP can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Sean Hopkins Policy Analyst American Registry for Internet Numbers (ARIN) Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers Version Date: 6 September 2017 Problem Statement: AFRINIC and LACNIC are currently considering one-way inter-RIR transfer proposals. Those RIR communities feel a one-way policy a policy that allows network operators in their regions to obtain space from another region and transfer it into AFRINIC and LACNIC may best meet the needs of the operators in that region. ARIN staff, in reply to an inquiry from AFRINIC, have formally indicated that ARINs 8.4 policy language will not allow ARIN to participate in such one-way transfers. The staff formally indicate to AFRINIC that the word reciprocal in 8.4 prohibits ARIN from allowing ARIN-registered space to transfer directly to AFRINIC (in this context). ARIN as a community should recognize that other RIR operator communities have different needs than we do. We should recognize that: - network operators in AFRINIC in LACNIC have need to obtain space in the market; - have reasons they think are important to not allow two-way transfers; and - we should understand that the history of the RIR system has led to LACNIC and AFRINIC having multiple orders of magnitude less IPv4 address space than ARIN does. Policy statement: Add the following sentence after the first sentence of NRPM 8.4: Inter-RIR transfers may take place to an RIR with a non-reciprocal inter-RIR transfer policy only when the recipient RIR has an IPv4 total inventory less than the average (mean) of the IPv4 total inventory among all of the RIRs. Timetable for implementation: Upon the ratification of any inter-RIR transfer policy at another RIR that is one-way as described in the problem statement. _______________________________________________ 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: ------------------------------ Message: 2 Date: Thu, 7 Sep 2017 12:30:22 +0000 From: Kevin Blumberg To: "arin-ppml at arin.net" Subject: Re: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers Message-ID: <7E7773B523E82C478734E793E58F69E7A52773A8 at SBS2011.thewireinc.local> Content-Type: text/plain; charset="us-ascii" Are there active polices in the other regions that rely on this policy? I understand there have been discussions, however I don't know what the status is/was. Thanks, Kevin Blumberg -----Original Message----- From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN Sent: Wednesday, September 6, 2017 2:36 PM To: arin-ppml at arin.net Subject: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers The following has been revised: * Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers Revised text is below and can be found at: https://www.arin.net/policy/proposals/2017_4.html You are encouraged to discuss all Draft Policies on PPML. The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet number resource policy as stated in the Policy Development Process (PDP). Specifically, these principles are: * Enabling Fair and Impartial Number Resource Administration * Technically Sound * Supported by the Community The PDP can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Sean Hopkins Policy Analyst American Registry for Internet Numbers (ARIN) Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers Version Date: 6 September 2017 Problem Statement: AFRINIC and LACNIC are currently considering one-way inter-RIR transfer proposals. Those RIR communities feel a one-way policy a policy that allows network operators in their regions to obtain space from another region and transfer it into AFRINIC and LACNIC may best meet the needs of the operators in that region. ARIN staff, in reply to an inquiry from AFRINIC, have formally indicated that ARINs 8.4 policy language will not allow ARIN to participate in such one-way transfers. The staff formally indicate to AFRINIC that the word reciprocal in 8.4 prohibits ARIN from allowing ARIN-registered space to transfer directly to AFRINIC (in this context). ARIN as a community should recognize that other RIR operator communities have different needs than we do. We should recognize that: - network operators in AFRINIC in LACNIC have need to obtain space in the market; - have reasons they think are important to not allow two-way transfers; and - we should understand that the history of the RIR system has led to LACNIC and AFRINIC having multiple orders of magnitude less IPv4 address space than ARIN does. Policy statement: Add the following sentence after the first sentence of NRPM 8.4: Inter-RIR transfers may take place to an RIR with a non-reciprocal inter-RIR transfer policy only when the recipient RIR has an IPv4 total inventory less than the average (mean) of the IPv4 total inventory among all of the RIRs. Timetable for implementation: Upon the ratification of any inter-RIR transfer policy at another RIR that is one-way as described in the problem statement. _______________________________________________ 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. ------------------------------ Message: 3 Date: Thu, 7 Sep 2017 09:39:02 -0400 From: "Mike Burns" To: "'Kevin Blumberg'" , Subject: Re: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers Message-ID: <030f01d327de$ab148cb0$013da610$@iptrading.com> Content-Type: text/plain; charset="us-ascii" Hi Kevin, LACNIC will be presented with a one-way policy proposal in Montevideo in a few weeks. It has failed to reach consensus twice but was returned to the list, so it will be voted on again. https://politicas.lacnic.net/politicas/detail/id/LAC-2017-2 Regards, Mike -----Original Message----- From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Kevin Blumberg Sent: Thursday, September 07, 2017 8:30 AM To: arin-ppml at arin.net Subject: Re: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers Are there active polices in the other regions that rely on this policy? I understand there have been discussions, however I don't know what the status is/was. Thanks, Kevin Blumberg -----Original Message----- From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN Sent: Wednesday, September 6, 2017 2:36 PM To: arin-ppml at arin.net Subject: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers The following has been revised: * Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers Revised text is below and can be found at: https://www.arin.net/policy/proposals/2017_4.html You are encouraged to discuss all Draft Policies on PPML. The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet number resource policy as stated in the Policy Development Process (PDP). Specifically, these principles are: * Enabling Fair and Impartial Number Resource Administration * Technically Sound * Supported by the Community The PDP can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Sean Hopkins Policy Analyst American Registry for Internet Numbers (ARIN) Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers Version Date: 6 September 2017 Problem Statement: AFRINIC and LACNIC are currently considering one-way inter-RIR transfer proposals. Those RIR communities feel a one-way policy a policy that allows network operators in their regions to obtain space from another region and transfer it into AFRINIC and LACNIC may best meet the needs of the operators in that region. ARIN staff, in reply to an inquiry from AFRINIC, have formally indicated that ARINs 8.4 policy language will not allow ARIN to participate in such one-way transfers. The staff formally indicate to AFRINIC that the word reciprocal in 8.4 prohibits ARIN from allowing ARIN-registered space to transfer directly to AFRINIC (in this context). ARIN as a community should recognize that other RIR operator communities have different needs than we do. We should recognize that: - network operators in AFRINIC in LACNIC have need to obtain space in the market; - have reasons they think are important to not allow two-way transfers; and - we should understand that the history of the RIR system has led to LACNIC and AFRINIC having multiple orders of magnitude less IPv4 address space than ARIN does. Policy statement: Add the following sentence after the first sentence of NRPM 8.4: Inter-RIR transfers may take place to an RIR with a non-reciprocal inter-RIR transfer policy only when the recipient RIR has an IPv4 total inventory less than the average (mean) of the IPv4 total inventory among all of the RIRs. Timetable for implementation: Upon the ratification of any inter-RIR transfer policy at another RIR that is one-way as described in the problem statement. _______________________________________________ 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. ------------------------------ Subject: Digest Footer _______________________________________________ ARIN-PPML mailing list ARIN-PPML at arin.net http://lists.arin.net/mailman/listinfo/arin-ppml ------------------------------ End of ARIN-PPML Digest, Vol 147, Issue 7 ***************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: From oroberts at bell.ca Thu Sep 7 12:36:13 2017 From: oroberts at bell.ca (Roberts, Orin) Date: Thu, 7 Sep 2017 16:36:13 +0000 Subject: [arin-ppml] policy proposal 2017-4 removal of reciprocity requirements In-Reply-To: References: Message-ID: <8c6d95a46def4541b8457636b6ad13a9@DG2MBX04-DOR.bell.corp.bce.ca> These are my sentiments also>>> "I am not convinced that it should be ARIN's role to correct perceived global RIR framework imbalances. We currently have a working policy strategy in this area, and I think we should stick with it for now." Orin Roberts ------------------------------------------------------------------- From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Rudolph Daniel Sent: September-07-17 12:26 PM To: arin-ppml at arin.net Subject: Re: [arin-ppml] policy proposal 2017-4 removal of reciprocity requirements I oppose the proposed policy. Quoting Chris Woodfield (?) where Afrinic and Lacnic wind up transferring enough space to push their totals over the average but are still permitted to transfer space. if that were to happen, it would require a subsequent policy change to keep that imbalance from growing worse. end quote In addition, I am not convinced that it should be ARIN's role to correct perceived global RIR framework inbalances? We currently have a working policy strategy in this area, and I think we should stick with it for now. rd On Sep 7, 2017 9:39 AM, wrote: Send ARIN-PPML mailing list submissions to ? ? ? ? mailto:arin-ppml at arin.net To subscribe or unsubscribe via the World Wide Web, visit ? ? ? ? http://lists.arin.net/mailman/listinfo/arin-ppml or, via email, send a message with subject or body 'help' to ? ? ? ? mailto:arin-ppml-request at arin.net You can reach the person managing the list at ? ? ? ? mailto:arin-ppml-owner at arin.net When replying, please edit your Subject line so it is more specific than "Re: Contents of ARIN-PPML digest..." Today's Topics: ? ?1. Re: Revised: ARIN-2017-4: Remove Reciprocity Requirement for ? ? ? Inter-RIR Transfers (Michael Winters) ? ?2. Re: Revised: ARIN-2017-4: Remove Reciprocity Requirement for ? ? ? Inter-RIR Transfers (Kevin Blumberg) ? ?3. Re: Revised: ARIN-2017-4: Remove Reciprocity Requirement for ? ? ? Inter-RIR Transfers (Mike Burns) ---------------------------------------------------------------------- Message: 1 Date: Thu, 7 Sep 2017 12:21:01 +0000 From: Michael Winters To: "mailto:arin-ppml at arin.net" Subject: Re: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity ? ? ? ? Requirement for Inter-RIR Transfers Message-ID: ? ? ? ? Content-Type: text/plain; charset="utf-8" I am opposed to this policy. From: ARIN-PPML [mailto:mailto:arin-ppml-bounces at arin.net] On Behalf Of Chris Woodfield Sent: Wednesday, September 6, 2017 5:19 PM To: Cj Aronson Cc: mailto:arin-ppml at arin.net Subject: Re: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers This policy proposal seems, to me, as an attempt to correct a historical imbalance in the distribution of IPv4 resources to various RIRs, since the vast majority of legacy space - which, to my eyes, it seems that much of the transfer supply is originating from - is in the ARIN region. Given that, this policy only makes sense up to the point that such imbalance still exists. If we simply named the target RIRs, we could result in a (arguably theoretical) situation where Afrinic and Lacnic wind up transferring enough space to push their totals over the average but are still permitted to transfer space. if that were to happen, it would require a subsequent policy change to keep that imbalance from growing worse. As such, I support as written and would argue against an approach that targets specific RIRs by name. -C On Sep 6, 2017, at 2:10 PM, Cj Aronson > wrote: Okay so this formula.. does it just give us Afrinic and Lacnic right?? So why don't we just say that?? Since there are only 5 RIRs it seems that maybe a formula isn't needed? {?,?} ? (( )) ? ?? ? On Wed, Sep 6, 2017 at 12:35 PM, ARIN > wrote: The following has been revised: * Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers Revised text is below and can be found at: https://www.arin.net/policy/proposals/2017_4.html You are encouraged to discuss all Draft Policies on PPML. The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet number resource policy as stated in the Policy Development Process (PDP). Specifically, these principles are: * Enabling Fair and Impartial Number Resource Administration * Technically Sound * Supported by the Community The PDP can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Sean Hopkins Policy Analyst American Registry for Internet Numbers (ARIN) Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers Version Date: 6 September 2017 Problem Statement: AFRINIC and LACNIC are currently considering one-way inter-RIR transfer proposals. Those RIR communities feel a one-way policy a policy that allows network operators in their regions to obtain space from another region and transfer it into AFRINIC and LACNIC may best meet the needs of the operators in that region. ARIN staff, in reply to an inquiry from AFRINIC, have formally indicated that ARINs 8.4 policy language will not allow ARIN to participate in such one-way transfers. The staff formally indicate to AFRINIC that the word reciprocal in 8.4 prohibits ARIN from allowing ARIN-registered space to transfer directly to AFRINIC (in this context). ARIN as a community should recognize that other RIR operator communities have different needs than we do. We should recognize that: - network operators in AFRINIC in LACNIC have need to obtain space in the market; - have reasons they think are important to not allow two-way transfers; and - we should understand that the history of the RIR system has led to LACNIC and AFRINIC having multiple orders of magnitude less IPv4 address space than ARIN does. Policy statement: Add the following sentence after the first sentence of NRPM 8.4: Inter-RIR transfers may take place to an RIR with a non-reciprocal inter-RIR transfer policy only when the recipient RIR has an IPv4 total inventory less than the average (mean) of the IPv4 total inventory among all of the RIRs. Timetable for implementation: Upon the ratification of any inter-RIR transfer policy at another RIR that is one-way as described in the problem statement. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (mailto:ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact mailto: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 (mailto:ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact mailto:info at arin.net if you experience any issues. ________________________________ ________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 2 Date: Thu, 7 Sep 2017 12:30:22 +0000 From: Kevin Blumberg To: "mailto:arin-ppml at arin.net" Subject: Re: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity ? ? ? ? Requirement for Inter-RIR Transfers Message-ID: ? ? ? ? Content-Type: text/plain; charset="us-ascii" Are there active polices in the other regions that rely on this policy? I understand there have been discussions, however I don't know what the status is/was. Thanks, Kevin Blumberg -----Original Message----- From: ARIN-PPML [mailto:mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN Sent: Wednesday, September 6, 2017 2:36 PM To: mailto:arin-ppml at arin.net Subject: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers The following has been revised: * Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers Revised text is below and can be found at: https://www.arin.net/policy/proposals/2017_4.html You are encouraged to discuss all Draft Policies on PPML. The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet number resource policy as stated in the Policy Development Process (PDP). Specifically, these principles are: * Enabling Fair and Impartial Number Resource Administration * Technically Sound * Supported by the Community The PDP can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Sean Hopkins Policy Analyst American Registry for Internet Numbers (ARIN) Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers Version Date: 6 September 2017 Problem Statement: AFRINIC and LACNIC are currently considering one-way inter-RIR transfer proposals. Those RIR communities feel a one-way policy a policy that allows network operators in their regions to obtain space from another region and transfer it into AFRINIC and LACNIC may best meet the needs of the operators in that region. ARIN staff, in reply to an inquiry from AFRINIC, have formally indicated that ARINs 8.4 policy language will not allow ARIN to participate in such one-way transfers. The staff formally indicate to AFRINIC that the word reciprocal in 8.4 prohibits ARIN from allowing ARIN-registered space to transfer directly to AFRINIC (in this context). ARIN as a community should recognize that other RIR operator communities have different needs than we do. We should recognize that: - network operators in AFRINIC in LACNIC have need to obtain space in the market; - have reasons they think are important to not allow two-way transfers; and - we should understand that the history of the RIR system has led to LACNIC and AFRINIC having multiple orders of magnitude less IPv4 address space than ARIN does. Policy statement: Add the following sentence after the first sentence of NRPM 8.4: Inter-RIR transfers may take place to an RIR with a non-reciprocal inter-RIR transfer policy only when the recipient RIR has an IPv4 total inventory less than the average (mean) of the IPv4 total inventory among all of the RIRs. Timetable for implementation: Upon the ratification of any inter-RIR transfer policy at another RIR that is one-way as described in the problem statement. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (mailto:ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact mailto:info at arin.net if you experience any issues. ------------------------------ Message: 3 Date: Thu, 7 Sep 2017 09:39:02 -0400 From: "Mike Burns" To: "'Kevin Blumberg'" ,? ? ? Subject: Re: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity ? ? ? ? Requirement for Inter-RIR Transfers Message-ID: <030f01d327de$ab148cb0$013da610$@http://iptrading.com> Content-Type: text/plain;? ? ? ?charset="us-ascii" Hi Kevin, LACNIC will be presented with a one-way policy proposal in Montevideo in a few weeks. It has failed to reach consensus twice but was returned to the list, so it will be voted on again. https://politicas.lacnic.net/politicas/detail/id/LAC-2017-2 Regards, Mike -----Original Message----- From: ARIN-PPML [mailto:mailto:arin-ppml-bounces at arin.net] On Behalf Of Kevin Blumberg Sent: Thursday, September 07, 2017 8:30 AM To: mailto:arin-ppml at arin.net Subject: Re: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers Are there active polices in the other regions that rely on this policy? I understand there have been discussions, however I don't know what the status is/was. Thanks, Kevin Blumberg -----Original Message----- From: ARIN-PPML [mailto:mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN Sent: Wednesday, September 6, 2017 2:36 PM To: mailto:arin-ppml at arin.net Subject: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers The following has been revised: * Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers Revised text is below and can be found at: https://www.arin.net/policy/proposals/2017_4.html You are encouraged to discuss all Draft Policies on PPML. The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet number resource policy as stated in the Policy Development Process (PDP). Specifically, these principles are: * Enabling Fair and Impartial Number Resource Administration * Technically Sound * Supported by the Community The PDP can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Sean Hopkins Policy Analyst American Registry for Internet Numbers (ARIN) Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers Version Date: 6 September 2017 Problem Statement: AFRINIC and LACNIC are currently considering one-way inter-RIR transfer proposals. Those RIR communities feel a one-way policy a policy that allows network operators in their regions to obtain space from another region and transfer it into AFRINIC and LACNIC may best meet the needs of the operators in that region. ARIN staff, in reply to an inquiry from AFRINIC, have formally indicated that ARINs 8.4 policy language will not allow ARIN to participate in such one-way transfers. The staff formally indicate to AFRINIC that the word reciprocal in 8.4 prohibits ARIN from allowing ARIN-registered space to transfer directly to AFRINIC (in this context). ARIN as a community should recognize that other RIR operator communities have different needs than we do. We should recognize that: - network operators in AFRINIC in LACNIC have need to obtain space in the market; - have reasons they think are important to not allow two-way transfers; and - we should understand that the history of the RIR system has led to LACNIC and AFRINIC having multiple orders of magnitude less IPv4 address space than ARIN does. Policy statement: Add the following sentence after the first sentence of NRPM 8.4: Inter-RIR transfers may take place to an RIR with a non-reciprocal inter-RIR transfer policy only when the recipient RIR has an IPv4 total inventory less than the average (mean) of the IPv4 total inventory among all of the RIRs. Timetable for implementation: Upon the ratification of any inter-RIR transfer policy at another RIR that is one-way as described in the problem statement. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (mailto:ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact mailto: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 (mailto:ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact mailto:info at arin.net if you experience any issues. ------------------------------ Subject: Digest Footer _______________________________________________ ARIN-PPML mailing list mailto:ARIN-PPML at arin.net http://lists.arin.net/mailman/listinfo/arin-ppml ------------------------------ End of ARIN-PPML Digest, Vol 147, Issue 7 ***************************************** From kevinb at thewire.ca Thu Sep 7 12:42:55 2017 From: kevinb at thewire.ca (Kevin Blumberg) Date: Thu, 7 Sep 2017 16:42:55 +0000 Subject: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers In-Reply-To: <030f01d327de$ab148cb0$013da610$@iptrading.com> References: <2bc0e7f7-c3d1-c496-1d58-ccec181c6414@arin.net> <7E7773B523E82C478734E793E58F69E7A52773A8@SBS2011.thewireinc.local> <030f01d327de$ab148cb0$013da610$@iptrading.com> Message-ID: <7E7773B523E82C478734E793E58F69E7A5278612@SBS2011.thewireinc.local> In re-reading the problem statement the following information was given. "ARIN staff, in reply to an inquiry from AFRINIC, have formally indicated that ARINs 8.4 policy language will not allow ARIN to participate in such one-way transfers." The use of one-way transfers completely mitigates any loss on the one side, and opens concern from the other. A question for Staff. Would a policy in another region that allows transfers, if a ratio at or above 1:1 basis work? Would that be considered reciprocal? At this time, I'm neither in support or opposed to the problem statement, but I don't support the policy as written. I also have concerns with having policy in our region to support a policy in another region, that has not been approved in another region, and in fact has not reached consensus twice. I don't have a good handle of the issues that the other regions have and having a policy implemented with out that understanding will be problematic. Thanks, Kevin Blumberg -----Original Message----- From: Mike Burns [mailto:mike at iptrading.com] Sent: Thursday, September 7, 2017 9:39 AM To: Kevin Blumberg ; arin-ppml at arin.net Subject: RE: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers Hi Kevin, LACNIC will be presented with a one-way policy proposal in Montevideo in a few weeks. It has failed to reach consensus twice but was returned to the list, so it will be voted on again. https://politicas.lacnic.net/politicas/detail/id/LAC-2017-2 Regards, Mike -----Original Message----- From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Kevin Blumberg Sent: Thursday, September 07, 2017 8:30 AM To: arin-ppml at arin.net Subject: Re: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers Are there active polices in the other regions that rely on this policy? I understand there have been discussions, however I don't know what the status is/was. Thanks, Kevin Blumberg -----Original Message----- From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN Sent: Wednesday, September 6, 2017 2:36 PM To: arin-ppml at arin.net Subject: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers The following has been revised: * Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers Revised text is below and can be found at: https://www.arin.net/policy/proposals/2017_4.html You are encouraged to discuss all Draft Policies on PPML. The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet number resource policy as stated in the Policy Development Process (PDP). Specifically, these principles are: * Enabling Fair and Impartial Number Resource Administration * Technically Sound * Supported by the Community The PDP can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Sean Hopkins Policy Analyst American Registry for Internet Numbers (ARIN) Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers Version Date: 6 September 2017 Problem Statement: AFRINIC and LACNIC are currently considering one-way inter-RIR transfer proposals. Those RIR communities feel a one-way policy a policy that allows network operators in their regions to obtain space from another region and transfer it into AFRINIC and LACNIC may best meet the needs of the operators in that region. ARIN staff, in reply to an inquiry from AFRINIC, have formally indicated that ARINs 8.4 policy language will not allow ARIN to participate in such one-way transfers. The staff formally indicate to AFRINIC that the word reciprocal in 8.4 prohibits ARIN from allowing ARIN-registered space to transfer directly to AFRINIC (in this context). ARIN as a community should recognize that other RIR operator communities have different needs than we do. We should recognize that: - network operators in AFRINIC in LACNIC have need to obtain space in the market; - have reasons they think are important to not allow two-way transfers; and - we should understand that the history of the RIR system has led to LACNIC and AFRINIC having multiple orders of magnitude less IPv4 address space than ARIN does. Policy statement: Add the following sentence after the first sentence of NRPM 8.4: Inter-RIR transfers may take place to an RIR with a non-reciprocal inter-RIR transfer policy only when the recipient RIR has an IPv4 total inventory less than the average (mean) of the IPv4 total inventory among all of the RIRs. Timetable for implementation: Upon the ratification of any inter-RIR transfer policy at another RIR that is one-way as described in the problem statement. _______________________________________________ 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 milton at gatech.edu Thu Sep 7 13:27:12 2017 From: milton at gatech.edu (Mueller, Milton L) Date: Thu, 7 Sep 2017 17:27:12 +0000 Subject: [arin-ppml] policy proposal 2017-4 removal of reciprocity requirements In-Reply-To: References: Message-ID: I support this proposal. I am scratching my head at the apparent lack of logic in this claim: In addition, I am not convinced that it should be ARIN's role to correct perceived global RIR framework inbalances? The reciprocity requirement is the policy that makes it ARIN?s role to correct potential imbalances, not this policy. We need to remove those requirements. Dr. Milton L Mueller Professor, School of Public Policy Georgia Institute of Technology Internet Governance Project http://internetgovernance.org/ We currently have a working policy strategy in this area, and I think we should stick with it for now. rd On Sep 7, 2017 9:39 AM, > wrote: Send ARIN-PPML mailing list submissions to arin-ppml at arin.net To subscribe or unsubscribe via the World Wide Web, visit http://lists.arin.net/mailman/listinfo/arin-ppml or, via email, send a message with subject or body 'help' to arin-ppml-request at arin.net You can reach the person managing the list at arin-ppml-owner at arin.net When replying, please edit your Subject line so it is more specific than "Re: Contents of ARIN-PPML digest..." Today's Topics: 1. Re: Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers (Michael Winters) 2. Re: Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers (Kevin Blumberg) 3. Re: Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers (Mike Burns) ---------------------------------------------------------------------- Message: 1 Date: Thu, 7 Sep 2017 12:21:01 +0000 From: Michael Winters > To: "arin-ppml at arin.net" > Subject: Re: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers Message-ID: <947590f72de642d690bb464342a2ea16 at kz-mail01.manifold.edwardrosekzoo.com> Content-Type: text/plain; charset="utf-8" I am opposed to this policy. From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Chris Woodfield Sent: Wednesday, September 6, 2017 5:19 PM To: Cj Aronson > Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers This policy proposal seems, to me, as an attempt to correct a historical imbalance in the distribution of IPv4 resources to various RIRs, since the vast majority of legacy space - which, to my eyes, it seems that much of the transfer supply is originating from - is in the ARIN region. Given that, this policy only makes sense up to the point that such imbalance still exists. If we simply named the target RIRs, we could result in a (arguably theoretical) situation where Afrinic and Lacnic wind up transferring enough space to push their totals over the average but are still permitted to transfer space. if that were to happen, it would require a subsequent policy change to keep that imbalance from growing worse. As such, I support as written and would argue against an approach that targets specific RIRs by name. -C On Sep 6, 2017, at 2:10 PM, Cj Aronson >> wrote: Okay so this formula.. does it just give us Afrinic and Lacnic right? So why don't we just say that? Since there are only 5 RIRs it seems that maybe a formula isn't needed? {?,?} (( )) ? ? On Wed, Sep 6, 2017 at 12:35 PM, ARIN >> wrote: The following has been revised: * Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers Revised text is below and can be found at: https://www.arin.net/policy/proposals/2017_4.html You are encouraged to discuss all Draft Policies on PPML. The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet number resource policy as stated in the Policy Development Process (PDP). Specifically, these principles are: * Enabling Fair and Impartial Number Resource Administration * Technically Sound * Supported by the Community The PDP can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Sean Hopkins Policy Analyst American Registry for Internet Numbers (ARIN) Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers Version Date: 6 September 2017 Problem Statement: AFRINIC and LACNIC are currently considering one-way inter-RIR transfer proposals. Those RIR communities feel a one-way policy a policy that allows network operators in their regions to obtain space from another region and transfer it into AFRINIC and LACNIC may best meet the needs of the operators in that region. ARIN staff, in reply to an inquiry from AFRINIC, have formally indicated that ARINs 8.4 policy language will not allow ARIN to participate in such one-way transfers. The staff formally indicate to AFRINIC that the word reciprocal in 8.4 prohibits ARIN from allowing ARIN-registered space to transfer directly to AFRINIC (in this context). ARIN as a community should recognize that other RIR operator communities have different needs than we do. We should recognize that: - network operators in AFRINIC in LACNIC have need to obtain space in the market; - have reasons they think are important to not allow two-way transfers; and - we should understand that the history of the RIR system has led to LACNIC and AFRINIC having multiple orders of magnitude less IPv4 address space than ARIN does. Policy statement: Add the following sentence after the first sentence of NRPM 8.4: Inter-RIR transfers may take place to an RIR with a non-reciprocal inter-RIR transfer policy only when the recipient RIR has an IPv4 total inventory less than the average (mean) of the IPv4 total inventory among all of the RIRs. Timetable for implementation: Upon the ratification of any inter-RIR transfer policy at another RIR that is one-way as described in the problem statement. _______________________________________________ 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: ------------------------------ Message: 2 Date: Thu, 7 Sep 2017 12:30:22 +0000 From: Kevin Blumberg > To: "arin-ppml at arin.net" > Subject: Re: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers Message-ID: <7E7773B523E82C478734E793E58F69E7A52773A8 at SBS2011.thewireinc.local> Content-Type: text/plain; charset="us-ascii" Are there active polices in the other regions that rely on this policy? I understand there have been discussions, however I don't know what the status is/was. Thanks, Kevin Blumberg -----Original Message----- From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN Sent: Wednesday, September 6, 2017 2:36 PM To: arin-ppml at arin.net Subject: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers The following has been revised: * Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers Revised text is below and can be found at: https://www.arin.net/policy/proposals/2017_4.html You are encouraged to discuss all Draft Policies on PPML. The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet number resource policy as stated in the Policy Development Process (PDP). Specifically, these principles are: * Enabling Fair and Impartial Number Resource Administration * Technically Sound * Supported by the Community The PDP can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Sean Hopkins Policy Analyst American Registry for Internet Numbers (ARIN) Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers Version Date: 6 September 2017 Problem Statement: AFRINIC and LACNIC are currently considering one-way inter-RIR transfer proposals. Those RIR communities feel a one-way policy a policy that allows network operators in their regions to obtain space from another region and transfer it into AFRINIC and LACNIC may best meet the needs of the operators in that region. ARIN staff, in reply to an inquiry from AFRINIC, have formally indicated that ARINs 8.4 policy language will not allow ARIN to participate in such one-way transfers. The staff formally indicate to AFRINIC that the word reciprocal in 8.4 prohibits ARIN from allowing ARIN-registered space to transfer directly to AFRINIC (in this context). ARIN as a community should recognize that other RIR operator communities have different needs than we do. We should recognize that: - network operators in AFRINIC in LACNIC have need to obtain space in the market; - have reasons they think are important to not allow two-way transfers; and - we should understand that the history of the RIR system has led to LACNIC and AFRINIC having multiple orders of magnitude less IPv4 address space than ARIN does. Policy statement: Add the following sentence after the first sentence of NRPM 8.4: Inter-RIR transfers may take place to an RIR with a non-reciprocal inter-RIR transfer policy only when the recipient RIR has an IPv4 total inventory less than the average (mean) of the IPv4 total inventory among all of the RIRs. Timetable for implementation: Upon the ratification of any inter-RIR transfer policy at another RIR that is one-way as described in the problem statement. _______________________________________________ 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. ------------------------------ Message: 3 Date: Thu, 7 Sep 2017 09:39:02 -0400 From: "Mike Burns" > To: "'Kevin Blumberg'" >, > Subject: Re: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers Message-ID: <030f01d327de$ab148cb0$013da610$@iptrading.com> Content-Type: text/plain; charset="us-ascii" Hi Kevin, LACNIC will be presented with a one-way policy proposal in Montevideo in a few weeks. It has failed to reach consensus twice but was returned to the list, so it will be voted on again. https://politicas.lacnic.net/politicas/detail/id/LAC-2017-2 Regards, Mike -----Original Message----- From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Kevin Blumberg Sent: Thursday, September 07, 2017 8:30 AM To: arin-ppml at arin.net Subject: Re: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers Are there active polices in the other regions that rely on this policy? I understand there have been discussions, however I don't know what the status is/was. Thanks, Kevin Blumberg -----Original Message----- From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN Sent: Wednesday, September 6, 2017 2:36 PM To: arin-ppml at arin.net Subject: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers The following has been revised: * Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers Revised text is below and can be found at: https://www.arin.net/policy/proposals/2017_4.html You are encouraged to discuss all Draft Policies on PPML. The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet number resource policy as stated in the Policy Development Process (PDP). Specifically, these principles are: * Enabling Fair and Impartial Number Resource Administration * Technically Sound * Supported by the Community The PDP can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Sean Hopkins Policy Analyst American Registry for Internet Numbers (ARIN) Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers Version Date: 6 September 2017 Problem Statement: AFRINIC and LACNIC are currently considering one-way inter-RIR transfer proposals. Those RIR communities feel a one-way policy a policy that allows network operators in their regions to obtain space from another region and transfer it into AFRINIC and LACNIC may best meet the needs of the operators in that region. ARIN staff, in reply to an inquiry from AFRINIC, have formally indicated that ARINs 8.4 policy language will not allow ARIN to participate in such one-way transfers. The staff formally indicate to AFRINIC that the word reciprocal in 8.4 prohibits ARIN from allowing ARIN-registered space to transfer directly to AFRINIC (in this context). ARIN as a community should recognize that other RIR operator communities have different needs than we do. We should recognize that: - network operators in AFRINIC in LACNIC have need to obtain space in the market; - have reasons they think are important to not allow two-way transfers; and - we should understand that the history of the RIR system has led to LACNIC and AFRINIC having multiple orders of magnitude less IPv4 address space than ARIN does. Policy statement: Add the following sentence after the first sentence of NRPM 8.4: Inter-RIR transfers may take place to an RIR with a non-reciprocal inter-RIR transfer policy only when the recipient RIR has an IPv4 total inventory less than the average (mean) of the IPv4 total inventory among all of the RIRs. Timetable for implementation: Upon the ratification of any inter-RIR transfer policy at another RIR that is one-way as described in the problem statement. _______________________________________________ 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. ------------------------------ Subject: Digest Footer _______________________________________________ ARIN-PPML mailing list ARIN-PPML at arin.net http://lists.arin.net/mailman/listinfo/arin-ppml ------------------------------ End of ARIN-PPML Digest, Vol 147, Issue 7 ***************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Thu Sep 7 14:23:41 2017 From: owen at delong.com (Owen DeLong) Date: Thu, 7 Sep 2017 11:23:41 -0700 Subject: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers In-Reply-To: References: <2bc0e7f7-c3d1-c496-1d58-ccec181c6414@arin.net> Message-ID: <6AC63D0C-6E34-432C-B499-347F0A3895C4@delong.com> Timeline is a bit off? Originally there was Jon Postel?s notebook. That passed to SRI and later evolved into InterNIC. RIPE and APNIC were created and handed parts of the responsibility prior to the formation of ARIN. ARIN remained ?registry of last resort? until the formation of LACNIC and later AfriNIC. The ERX and other transfer processes were a bit more complicated, but essentially you have the right general idea. I think that statement 4 is likely not entirely historically accurate. Early distribution of IPv4 addresses was significantly more generous than later distribution (companies like Apple and HP, Universities like MIT, and others easily got /8s just for the asking, organizations of any significant size could easily request and receive /16s, etc.). Otherwise, I think you generally have it right. Owen > On Sep 6, 2017, at 15:10 , hostmaster at uneedus.com wrote: > > Now that discussion reveals that "IPv4 Inventory", refers to the total number of IPv4 addresses that a specific RIR has under its management, and not the amount of IPv4 addresses remaining for assignment, I will state the problems I see with the proposal. However, I remain open minded and am asking questions in order to make up my mind. > > If any of the history of numbering management that I state below is wrong, please let me know, as it might change my viewpoint. > > 1) Originally there was effectively only one RIR worldwide. > > 2) This original RIR's Resources were placed under control of ARIN. > > 3) When each of the RIR's other than ARIN were formed, all resources that were assigned to entities within the region of the new RIR, that were under management of ARIN, or the RIR which previously managed the space (RIPE to AFRINIC in that case) were transfered to the new RIR. > > 4) The Previous RIR's who controled resources before the formation of LACNIC or AFRINIC did not have a policy in place that discriminated against any portion of the world, and would if presented with a request for IPv4 resources, would process that request using the same policy that was used for resources assigned in the remaining portions of that RIR's Territory. > > With each of these things said, I now draw some conclusions. Specifically, it is not North America's or ARIN's fault that LACNIC and AFRINIC has less resources under management than ARIN or RIPE or APNIC. Had networks needing resources existed during this time, and all the way past their formation up until that date that IANA ran out of /8's, that RIR could have received IPv4 addresses from the free pool on an equal basis. While the original Class A networks were given out a lot more loosely than ARIN's standards, this did not change the fact that IANA had a free pool after these original Class A networks were assigned, and did provide additional /8's to any RIR who could show that they had exhausted their free pool below the standard that was applied to all 5 RIR's. > > In my opinion the only reason that LACNIC and AFRINIC did not have as many /8's, was the growth in the APNIC region compared to all other regions, which during that time exceeded every other RIR, including ARIN. In fact, it was APNIC's request for more space that triggered the exhaustion of the free pool. Technically, when LACNIC and AFRINIC received their final /8, it was not totally fair to the other RIR's with more addresses under management. In fact, this final non proportional oversupply at AFRINIC is likely the only reason that AFRINIC is the only RIR with a general free pool. Instead of a full /8 to each region, maybe this should have been done more proportional to each region's total address space under management. > > For a market based solution to IPv4 addresses, addresses need to be able to flow both ways. AFRINIC and LACNIC can argue that we are the small guys, and we need to be protected against transfers out. However, I can just as easily argue that ARIN is being used as a worldwide piggy bank of IPv4 addresses and should also adopt an anti-transfer out policy. As long as things move both ways, we can argue that the market effect is important, but for this to work, it must be bidirectional everywhere. While ARIN is the leader in supplying directed transfer addresses, market conditions could change worldwide, causing more transfers from another RIR. For an example, say if China were to require ALL internet to use IPv6, and forbid the use of IPv4 in their country, a large number of IPv4 addresses allocated to China would suddenly be available on the transfer market. > > Some similar event that is now unknown could drive the IPv4 addresses of the LACNIC and AFRINIC into the market, and if this policy were adopted would be unfair to the markets that would be forbidden from these addresses being in the market because of the lack of a bidirectional transfer rule. > > My gut tells me that noone should get a pass on bidirectional transfers, and I am leaning NO at this time, but could be convinced otherwise for the proper reason. I do not think "Past Discrimination" is that reason. The true past problem was lack of past network growth, vs other regions. > > Albert Erdmann > Network Administrator > Paradise On Line Inc. > > > > On Wed, 6 Sep 2017, ARIN wrote: > >> The following has been revised: >> >> * Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers >> >> Revised text is below and can be found at: >> https://www.arin.net/policy/proposals/2017_4.html >> >> You are encouraged to discuss all Draft Policies on PPML. The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet number resource policy as stated in the Policy Development Process (PDP). Specifically, these principles are: >> >> * Enabling Fair and Impartial Number Resource Administration >> * Technically Sound >> * Supported by the Community >> >> The PDP can be found at: >> https://www.arin.net/policy/pdp.html >> >> Draft Policies and Proposals under discussion can be found at: >> https://www.arin.net/policy/proposals/index.html >> >> Regards, >> >> Sean Hopkins >> Policy Analyst >> American Registry for Internet Numbers (ARIN) >> >> >> >> Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers >> >> Version Date: 6 September 2017 >> >> Problem Statement: >> >> AFRINIC and LACNIC are currently considering one-way inter-RIR transfer proposals. Those RIR communities feel a one-way policy a policy that allows network operators in their regions to obtain space from another region and transfer it into AFRINIC and LACNIC may best meet the needs of the operators in that region. >> >> ARIN staff, in reply to an inquiry from AFRINIC, have formally indicated that ARINs 8.4 policy language will not allow ARIN to participate in such one-way transfers. The staff formally indicate to AFRINIC that the word reciprocal in 8.4 prohibits ARIN from allowing ARIN-registered space to transfer directly to AFRINIC (in this context). >> >> ARIN as a community should recognize that other RIR operator communities have different needs than we do. We should recognize that: >> >> - network operators in AFRINIC in LACNIC have need to obtain space in the market; >> >> - have reasons they think are important to not allow two-way transfers; and >> >> - we should understand that the history of the RIR system has led to LACNIC and AFRINIC having multiple orders of magnitude less IPv4 address space than ARIN does. >> >> Policy statement: >> >> Add the following sentence after the first sentence of NRPM 8.4: >> >> Inter-RIR transfers may take place to an RIR with a non-reciprocal inter-RIR transfer policy only when the recipient RIR has an IPv4 total inventory less than the average (mean) of the IPv4 total inventory among all of the RIRs. >> >> Timetable for implementation: Upon the ratification of any inter-RIR transfer policy at another RIR that is one-way as described in the problem statement. >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From owen at delong.com Thu Sep 7 14:25:02 2017 From: owen at delong.com (Owen DeLong) Date: Thu, 7 Sep 2017 11:25:02 -0700 Subject: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers In-Reply-To: <7E7773B523E82C478734E793E58F69E7A52773A8@SBS2011.thewireinc.local> References: <2bc0e7f7-c3d1-c496-1d58-ccec181c6414@arin.net> <7E7773B523E82C478734E793E58F69E7A52773A8@SBS2011.thewireinc.local> Message-ID: <9D9CAE4C-0723-4F15-A543-AE368EFD8C97@delong.com> Neither LACNIC nor AfriNIC have currently passed or implemented an inter-RIR transfer policy. All Inter-RIR policies that have been considered in either region have been unilateral inbound-only to the best of my knowledge. Owen > On Sep 7, 2017, at 05:30 , Kevin Blumberg wrote: > > Are there active polices in the other regions that rely on this policy? I understand there have been discussions, however I don't know what the status is/was. > > Thanks, > > Kevin Blumberg > > > > -----Original Message----- > From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN > Sent: Wednesday, September 6, 2017 2:36 PM > To: arin-ppml at arin.net > Subject: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers > > The following has been revised: > > * Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers > > Revised text is below and can be found at: > https://www.arin.net/policy/proposals/2017_4.html > > You are encouraged to discuss all Draft Policies on PPML. The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet number resource policy as stated in the Policy Development Process (PDP). Specifically, these principles are: > > * Enabling Fair and Impartial Number Resource Administration > * Technically Sound > * Supported by the Community > > The PDP can be found at: > https://www.arin.net/policy/pdp.html > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > Regards, > > Sean Hopkins > Policy Analyst > American Registry for Internet Numbers (ARIN) > > > > Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers > > Version Date: 6 September 2017 > > Problem Statement: > > AFRINIC and LACNIC are currently considering one-way inter-RIR transfer proposals. Those RIR communities feel a one-way policy a policy that allows network operators in their regions to obtain space from another region and transfer it into AFRINIC and LACNIC may best meet the needs of the operators in that region. > > ARIN staff, in reply to an inquiry from AFRINIC, have formally indicated that ARINs 8.4 policy language will not allow ARIN to participate in such one-way transfers. The staff formally indicate to AFRINIC that the word reciprocal in 8.4 prohibits ARIN from allowing ARIN-registered space to transfer directly to AFRINIC (in this context). > > ARIN as a community should recognize that other RIR operator communities have different needs than we do. We should recognize that: > > - network operators in AFRINIC in LACNIC have need to obtain space in the market; > > - have reasons they think are important to not allow two-way transfers; and > > - we should understand that the history of the RIR system has led to LACNIC and AFRINIC having multiple orders of magnitude less IPv4 address space than ARIN does. > > Policy statement: > > Add the following sentence after the first sentence of NRPM 8.4: > > Inter-RIR transfers may take place to an RIR with a non-reciprocal inter-RIR transfer policy only when the recipient RIR has an IPv4 total inventory less than the average (mean) of the IPv4 total inventory among all of the RIRs. > > Timetable for implementation: Upon the ratification of any inter-RIR transfer policy at another RIR that is one-way as described in the problem statement. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From owen at delong.com Thu Sep 7 14:34:01 2017 From: owen at delong.com (Owen DeLong) Date: Thu, 7 Sep 2017 11:34:01 -0700 Subject: [arin-ppml] policy proposal 2017-4 removal of reciprocity requirements In-Reply-To: References: Message-ID: <6EF74EF8-A786-4FF1-9FF4-64D164EB3E44@delong.com> > On Sep 7, 2017, at 10:27 , Mueller, Milton L wrote: > > I support this proposal. > I am scratching my head at the apparent lack of logic in this claim: > In addition, I am not convinced that it should be ARIN's role to correct perceived global RIR framework inbalances? > > The reciprocity requirement is the policy that makes it ARIN?s role to correct potential imbalances, not this policy. We need to remove those requirements. No, we don?t. Those requirements are there because it is not ARIN?s responsibility to correct perceived global RIR framework imbalances and because the community came to consensus around the idea that any inter-RIR transfers that are to be allowed should be allowed mutually on an even footing as equals. Creating or permitting asymmetry in policy does not create an improvement in the situation IMHO. If the community comes to consensus that asymmetry is desirable, then I will accept that, but stating that the current policy which at least at the time it was sent to the board for ratification had community consensus somehow creates an obligation for ARIN to correct previous actions that predate that consensus policy is absurd at best and disingenuous at worst. Owen > > > Dr. Milton L Mueller > Professor, School of Public Policy > Georgia Institute of Technology > Internet Governance Project > http://internetgovernance.org/ > > > > > > We currently have a working policy strategy in this area, and I think we should stick with it for now. > rd > > > On Sep 7, 2017 9:39 AM, > wrote: > Send ARIN-PPML mailing list submissions to > arin-ppml at arin.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.arin.net/mailman/listinfo/arin-ppml > or, via email, send a message with subject or body 'help' to > arin-ppml-request at arin.net > > You can reach the person managing the list at > arin-ppml-owner at arin.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of ARIN-PPML digest..." > > > Today's Topics: > > 1. Re: Revised: ARIN-2017-4: Remove Reciprocity Requirement for > Inter-RIR Transfers (Michael Winters) > 2. Re: Revised: ARIN-2017-4: Remove Reciprocity Requirement for > Inter-RIR Transfers (Kevin Blumberg) > 3. Re: Revised: ARIN-2017-4: Remove Reciprocity Requirement for > Inter-RIR Transfers (Mike Burns) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 7 Sep 2017 12:21:01 +0000 > From: Michael Winters > > To: "arin-ppml at arin.net " > > Subject: Re: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity > Requirement for Inter-RIR Transfers > Message-ID: > <947590f72de642d690bb464342a2ea16 at kz-mail01.manifold.edwardrosekzoo.com > > > Content-Type: text/plain; charset="utf-8" > > I am opposed to this policy. > > From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net ] On Behalf Of Chris Woodfield > Sent: Wednesday, September 6, 2017 5:19 PM > To: Cj Aronson > > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers > > This policy proposal seems, to me, as an attempt to correct a historical imbalance in the distribution of IPv4 resources to various RIRs, since the vast majority of legacy space - which, to my eyes, it seems that much of the transfer supply is originating from - is in the ARIN region. > > Given that, this policy only makes sense up to the point that such imbalance still exists. If we simply named the target RIRs, we could result in a (arguably theoretical) situation where Afrinic and Lacnic wind up transferring enough space to push their totals over the average but are still permitted to transfer space. if that were to happen, it would require a subsequent policy change to keep that imbalance from growing worse. > > As such, I support as written and would argue against an approach that targets specific RIRs by name. > > -C > > On Sep 6, 2017, at 2:10 PM, Cj Aronson >> wrote: > > Okay so this formula.. does it just give us Afrinic and Lacnic right? So why don't we just say that? Since there are only 5 RIRs it seems that maybe a formula isn't needed? > > > {?,?} > (( )) > ? ? > > On Wed, Sep 6, 2017 at 12:35 PM, ARIN >> wrote: > The following has been revised: > > * Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers > > Revised text is below and can be found at: > https://www.arin.net/policy/proposals/2017_4.html > > You are encouraged to discuss all Draft Policies on PPML. The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet number resource policy as stated in the Policy Development Process (PDP). Specifically, these principles are: > > * Enabling Fair and Impartial Number Resource Administration > * Technically Sound > * Supported by the Community > > The PDP can be found at: > https://www.arin.net/policy/pdp.html > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > Regards, > > Sean Hopkins > Policy Analyst > American Registry for Internet Numbers (ARIN) > > > > Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers > > Version Date: 6 September 2017 > > Problem Statement: > > AFRINIC and LACNIC are currently considering one-way inter-RIR transfer proposals. Those RIR communities feel a one-way policy a policy that allows network operators in their regions to obtain space from another region and transfer it into AFRINIC and LACNIC may best meet the needs of the operators in that region. > > ARIN staff, in reply to an inquiry from AFRINIC, have formally indicated that ARINs 8.4 policy language will not allow ARIN to participate in such one-way transfers. The staff formally indicate to AFRINIC that the word reciprocal in 8.4 prohibits ARIN from allowing ARIN-registered space to transfer directly to AFRINIC (in this context). > > ARIN as a community should recognize that other RIR operator communities have different needs than we do. We should recognize that: > > - network operators in AFRINIC in LACNIC have need to obtain space in the market; > > - have reasons they think are important to not allow two-way transfers; and > > - we should understand that the history of the RIR system has led to LACNIC and AFRINIC having multiple orders of magnitude less IPv4 address space than ARIN does. > > Policy statement: > > Add the following sentence after the first sentence of NRPM 8.4: > > Inter-RIR transfers may take place to an RIR with a non-reciprocal inter-RIR transfer policy only when the recipient RIR has an IPv4 total inventory less than the average (mean) of the IPv4 total inventory among all of the RIRs. > > Timetable for implementation: Upon the ratification of any inter-RIR transfer policy at another RIR that is one-way as described in the problem statement. > _______________________________________________ > 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: > > > ------------------------------ > > Message: 2 > Date: Thu, 7 Sep 2017 12:30:22 +0000 > From: Kevin Blumberg > > To: "arin-ppml at arin.net " > > Subject: Re: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity > Requirement for Inter-RIR Transfers > Message-ID: > <7E7773B523E82C478734E793E58F69E7A52773A8 at SBS2011.thewireinc.local > > Content-Type: text/plain; charset="us-ascii" > > Are there active polices in the other regions that rely on this policy? I understand there have been discussions, however I don't know what the status is/was. > > Thanks, > > Kevin Blumberg > > > > -----Original Message----- > From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net ] On Behalf Of ARIN > Sent: Wednesday, September 6, 2017 2:36 PM > To: arin-ppml at arin.net > Subject: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers > > The following has been revised: > > * Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers > > Revised text is below and can be found at: > https://www.arin.net/policy/proposals/2017_4.html > > You are encouraged to discuss all Draft Policies on PPML. The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet number resource policy as stated in the Policy Development Process (PDP). Specifically, these principles are: > > * Enabling Fair and Impartial Number Resource Administration > * Technically Sound > * Supported by the Community > > The PDP can be found at: > https://www.arin.net/policy/pdp.html > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > Regards, > > Sean Hopkins > Policy Analyst > American Registry for Internet Numbers (ARIN) > > > > Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers > > Version Date: 6 September 2017 > > Problem Statement: > > AFRINIC and LACNIC are currently considering one-way inter-RIR transfer proposals. Those RIR communities feel a one-way policy a policy that allows network operators in their regions to obtain space from another region and transfer it into AFRINIC and LACNIC may best meet the needs of the operators in that region. > > ARIN staff, in reply to an inquiry from AFRINIC, have formally indicated that ARINs 8.4 policy language will not allow ARIN to participate in such one-way transfers. The staff formally indicate to AFRINIC that the word reciprocal in 8.4 prohibits ARIN from allowing ARIN-registered space to transfer directly to AFRINIC (in this context). > > ARIN as a community should recognize that other RIR operator communities have different needs than we do. We should recognize that: > > - network operators in AFRINIC in LACNIC have need to obtain space in the market; > > - have reasons they think are important to not allow two-way transfers; and > > - we should understand that the history of the RIR system has led to LACNIC and AFRINIC having multiple orders of magnitude less IPv4 address space than ARIN does. > > Policy statement: > > Add the following sentence after the first sentence of NRPM 8.4: > > Inter-RIR transfers may take place to an RIR with a non-reciprocal inter-RIR transfer policy only when the recipient RIR has an IPv4 total inventory less than the average (mean) of the IPv4 total inventory among all of the RIRs. > > Timetable for implementation: Upon the ratification of any inter-RIR transfer policy at another RIR that is one-way as described in the problem statement. > _______________________________________________ > 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. > > > ------------------------------ > > Message: 3 > Date: Thu, 7 Sep 2017 09:39:02 -0400 > From: "Mike Burns" > > To: "'Kevin Blumberg'" >, > > Subject: Re: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity > Requirement for Inter-RIR Transfers > Message-ID: <030f01d327de$ab148cb0$013da610$@iptrading.com > > Content-Type: text/plain; charset="us-ascii" > > Hi Kevin, > > LACNIC will be presented with a one-way policy proposal in Montevideo in a > few weeks. It has failed to reach consensus twice but was returned to the > list, so it will be voted on again. > > https://politicas.lacnic.net/politicas/detail/id/LAC-2017-2 > > Regards, > Mike > > > > > -----Original Message----- > From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net ] On Behalf Of Kevin > Blumberg > Sent: Thursday, September 07, 2017 8:30 AM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity > Requirement for Inter-RIR Transfers > > Are there active polices in the other regions that rely on this policy? I > understand there have been discussions, however I don't know what the status > is/was. > > Thanks, > > Kevin Blumberg > > > > -----Original Message----- > From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net ] On Behalf Of ARIN > Sent: Wednesday, September 6, 2017 2:36 PM > To: arin-ppml at arin.net > Subject: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement > for Inter-RIR Transfers > > The following has been revised: > > * Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR > Transfers > > Revised text is below and can be found at: > https://www.arin.net/policy/proposals/2017_4.html > > You are encouraged to discuss all Draft Policies on PPML. The AC will > evaluate the discussion in order to assess the conformance of this draft > policy with ARIN's Principles of Internet number resource policy as stated > in the Policy Development Process (PDP). Specifically, these principles are: > > * Enabling Fair and Impartial Number Resource Administration > * Technically Sound > * Supported by the Community > > The PDP can be found at: > https://www.arin.net/policy/pdp.html > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > Regards, > > Sean Hopkins > Policy Analyst > American Registry for Internet Numbers (ARIN) > > > > Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR > Transfers > > Version Date: 6 September 2017 > > Problem Statement: > > AFRINIC and LACNIC are currently considering one-way inter-RIR transfer > proposals. Those RIR communities feel a one-way policy a policy that allows > network operators in their regions to obtain space from another region and > transfer it into AFRINIC and LACNIC may best meet the needs of the operators > in that region. > > ARIN staff, in reply to an inquiry from AFRINIC, have formally indicated > that ARINs 8.4 policy language will not allow ARIN to participate in such > one-way transfers. The staff formally indicate to AFRINIC that the word > reciprocal in 8.4 prohibits ARIN from allowing ARIN-registered space to > transfer directly to AFRINIC (in this context). > > ARIN as a community should recognize that other RIR operator communities > have different needs than we do. We should recognize that: > > - network operators in AFRINIC in LACNIC have need to obtain space in the > market; > > - have reasons they think are important to not allow two-way transfers; and > > - we should understand that the history of the RIR system has led to LACNIC > and AFRINIC having multiple orders of magnitude less IPv4 address space than > ARIN does. > > Policy statement: > > Add the following sentence after the first sentence of NRPM 8.4: > > Inter-RIR transfers may take place to an RIR with a non-reciprocal inter-RIR > transfer policy only when the recipient RIR has an IPv4 total inventory less > than the average (mean) of the IPv4 total inventory among all of the RIRs. > > Timetable for implementation: Upon the ratification of any inter-RIR > transfer policy at another RIR that is one-way as described in the problem > statement. > _______________________________________________ > 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. > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > ARIN-PPML mailing list > ARIN-PPML at arin.net > http://lists.arin.net/mailman/listinfo/arin-ppml > > ------------------------------ > > End of ARIN-PPML Digest, Vol 147, Issue 7 > ***************************************** > > _______________________________________________ > 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 rudi.daniel at gmail.com Thu Sep 7 15:01:27 2017 From: rudi.daniel at gmail.com (Rudolph Daniel) Date: Thu, 7 Sep 2017 15:01:27 -0400 Subject: [arin-ppml] policy proposal 2017-4 removal of reciprocity requirements In-Reply-To: References: Message-ID: Re: Milton To correct potential imbalances of what Milton? Can't be address space surely...that Arin is correcting, you...but I'm happy to listen. rd On Sep 7, 2017 1:27 PM, "Mueller, Milton L" wrote: > I support this proposal. > > I am scratching my head at the apparent lack of logic in this claim: > > In addition, I am not convinced that it should be ARIN's role to correct > perceived global RIR framework inbalances? > > The reciprocity requirement is the policy that makes it ARIN?s role to > correct potential imbalances, not this policy. We need to remove those > requirements. > > > > > > Dr. Milton L Mueller > > Professor, School of Public Policy > > Georgia Institute of Technology > > Internet Governance Project > > http://internetgovernance.org/ > > > > > > > > We currently have a working policy strategy in this area, and I think we > should stick with it for now. > rd > > > > On Sep 7, 2017 9:39 AM, wrote: > > Send ARIN-PPML mailing list submissions to > arin-ppml at arin.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.arin.net/mailman/listinfo/arin-ppml > or, via email, send a message with subject or body 'help' to > arin-ppml-request at arin.net > > You can reach the person managing the list at > arin-ppml-owner at arin.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of ARIN-PPML digest..." > > > Today's Topics: > > 1. Re: Revised: ARIN-2017-4: Remove Reciprocity Requirement for > Inter-RIR Transfers (Michael Winters) > 2. Re: Revised: ARIN-2017-4: Remove Reciprocity Requirement for > Inter-RIR Transfers (Kevin Blumberg) > 3. Re: Revised: ARIN-2017-4: Remove Reciprocity Requirement for > Inter-RIR Transfers (Mike Burns) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 7 Sep 2017 12:21:01 +0000 > From: Michael Winters > To: "arin-ppml at arin.net" > Subject: Re: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity > Requirement for Inter-RIR Transfers > Message-ID: > <947590f72de642d690bb464342a2ea16 at kz-mail01.manifold. > edwardrosekzoo.com> > > Content-Type: text/plain; charset="utf-8" > > I am opposed to this policy. > > From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Chris > Woodfield > Sent: Wednesday, September 6, 2017 5:19 PM > To: Cj Aronson > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity > Requirement for Inter-RIR Transfers > > This policy proposal seems, to me, as an attempt to correct a historical > imbalance in the distribution of IPv4 resources to various RIRs, since the > vast majority of legacy space - which, to my eyes, it seems that much of > the transfer supply is originating from - is in the ARIN region. > > Given that, this policy only makes sense up to the point that such > imbalance still exists. If we simply named the target RIRs, we could result > in a (arguably theoretical) situation where Afrinic and Lacnic wind up > transferring enough space to push their totals over the average but are > still permitted to transfer space. if that were to happen, it would require > a subsequent policy change to keep that imbalance from growing worse. > > As such, I support as written and would argue against an approach that > targets specific RIRs by name. > > -C > > On Sep 6, 2017, at 2:10 PM, Cj Aronson daydream.com>> wrote: > > Okay so this formula.. does it just give us Afrinic and Lacnic right? So > why don't we just say that? Since there are only 5 RIRs it seems that > maybe a formula isn't needed? > > > {?,?} > (( )) > ? ? > > On Wed, Sep 6, 2017 at 12:35 PM, ARIN > > wrote: > The following has been revised: > > * Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR > Transfers > > Revised text is below and can be found at: > https://www.arin.net/policy/proposals/2017_4.html > > You are encouraged to discuss all Draft Policies on PPML. The AC will > evaluate the discussion in order to assess the conformance of this draft > policy with ARIN's Principles of Internet number resource policy as stated > in the Policy Development Process (PDP). Specifically, these principles are: > > * Enabling Fair and Impartial Number Resource Administration > * Technically Sound > * Supported by the Community > > The PDP can be found at: > https://www.arin.net/policy/pdp.html > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > Regards, > > Sean Hopkins > Policy Analyst > American Registry for Internet Numbers (ARIN) > > > > Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR > Transfers > > Version Date: 6 September 2017 > > Problem Statement: > > AFRINIC and LACNIC are currently considering one-way inter-RIR transfer > proposals. Those RIR communities feel a one-way policy a policy that allows > network operators in their regions to obtain space from another region and > transfer it into AFRINIC and LACNIC may best meet the needs of the > operators in that region. > > ARIN staff, in reply to an inquiry from AFRINIC, have formally indicated > that ARINs 8.4 policy language will not allow ARIN to participate in such > one-way transfers. The staff formally indicate to AFRINIC that the word > reciprocal in 8.4 prohibits ARIN from allowing ARIN-registered space to > transfer directly to AFRINIC (in this context). > > ARIN as a community should recognize that other RIR operator communities > have different needs than we do. We should recognize that: > > - network operators in AFRINIC in LACNIC have need to obtain space in the > market; > > - have reasons they think are important to not allow two-way transfers; and > > - we should understand that the history of the RIR system has led to > LACNIC and AFRINIC having multiple orders of magnitude less IPv4 address > space than ARIN does. > > Policy statement: > > Add the following sentence after the first sentence of NRPM 8.4: > > Inter-RIR transfers may take place to an RIR with a non-reciprocal > inter-RIR transfer policy only when the recipient RIR has an IPv4 total > inventory less than the average (mean) of the IPv4 total inventory among > all of the RIRs. > > Timetable for implementation: Upon the ratification of any inter-RIR > transfer policy at another RIR that is one-way as described in the problem > statement. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net N-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 N-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: attachments/20170907/ba57cf2e/attachment-0001.html> > > ------------------------------ > > Message: 2 > Date: Thu, 7 Sep 2017 12:30:22 +0000 > From: Kevin Blumberg > To: "arin-ppml at arin.net" > Subject: Re: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity > Requirement for Inter-RIR Transfers > Message-ID: > <7E7773B523E82C478734E793E58F69E7A52773A8 at SBS2011.thewireinc.local > > > Content-Type: text/plain; charset="us-ascii" > > Are there active polices in the other regions that rely on this policy? I > understand there have been discussions, however I don't know what the > status is/was. > > Thanks, > > Kevin Blumberg > > > > -----Original Message----- > From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN > Sent: Wednesday, September 6, 2017 2:36 PM > To: arin-ppml at arin.net > Subject: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement > for Inter-RIR Transfers > > The following has been revised: > > * Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR > Transfers > > Revised text is below and can be found at: > https://www.arin.net/policy/proposals/2017_4.html > > You are encouraged to discuss all Draft Policies on PPML. The AC will > evaluate the discussion in order to assess the conformance of this draft > policy with ARIN's Principles of Internet number resource policy as stated > in the Policy Development Process (PDP). Specifically, these principles are: > > * Enabling Fair and Impartial Number Resource Administration > * Technically Sound > * Supported by the Community > > The PDP can be found at: > https://www.arin.net/policy/pdp.html > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > Regards, > > Sean Hopkins > Policy Analyst > American Registry for Internet Numbers (ARIN) > > > > Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR > Transfers > > Version Date: 6 September 2017 > > Problem Statement: > > AFRINIC and LACNIC are currently considering one-way inter-RIR transfer > proposals. Those RIR communities feel a one-way policy a policy that allows > network operators in their regions to obtain space from another region and > transfer it into AFRINIC and LACNIC may best meet the needs of the > operators in that region. > > ARIN staff, in reply to an inquiry from AFRINIC, have formally indicated > that ARINs 8.4 policy language will not allow ARIN to participate in such > one-way transfers. The staff formally indicate to AFRINIC that the word > reciprocal in 8.4 prohibits ARIN from allowing ARIN-registered space to > transfer directly to AFRINIC (in this context). > > ARIN as a community should recognize that other RIR operator communities > have different needs than we do. We should recognize that: > > - network operators in AFRINIC in LACNIC have need to obtain space in the > market; > > - have reasons they think are important to not allow two-way transfers; and > > - we should understand that the history of the RIR system has led to > LACNIC and AFRINIC having multiple orders of magnitude less IPv4 address > space than ARIN does. > > Policy statement: > > Add the following sentence after the first sentence of NRPM 8.4: > > Inter-RIR transfers may take place to an RIR with a non-reciprocal > inter-RIR transfer policy only when the recipient RIR has an IPv4 total > inventory less than the average (mean) of the IPv4 total inventory among > all of the RIRs. > > Timetable for implementation: Upon the ratification of any inter-RIR > transfer policy at another RIR that is one-way as described in the problem > statement. > _______________________________________________ > 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. > > > ------------------------------ > > Message: 3 > Date: Thu, 7 Sep 2017 09:39:02 -0400 > From: "Mike Burns" > To: "'Kevin Blumberg'" , > Subject: Re: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity > Requirement for Inter-RIR Transfers > Message-ID: <030f01d327de$ab148cb0$013da610$@iptrading.com> > Content-Type: text/plain; charset="us-ascii" > > Hi Kevin, > > LACNIC will be presented with a one-way policy proposal in Montevideo in a > few weeks. It has failed to reach consensus twice but was returned to the > list, so it will be voted on again. > > https://politicas.lacnic.net/politicas/detail/id/LAC-2017-2 > > Regards, > Mike > > > > > -----Original Message----- > From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Kevin > Blumberg > Sent: Thursday, September 07, 2017 8:30 AM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity > Requirement for Inter-RIR Transfers > > Are there active polices in the other regions that rely on this policy? I > understand there have been discussions, however I don't know what the > status > is/was. > > Thanks, > > Kevin Blumberg > > > > -----Original Message----- > From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN > Sent: Wednesday, September 6, 2017 2:36 PM > To: arin-ppml at arin.net > Subject: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement > for Inter-RIR Transfers > > The following has been revised: > > * Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR > Transfers > > Revised text is below and can be found at: > https://www.arin.net/policy/proposals/2017_4.html > > You are encouraged to discuss all Draft Policies on PPML. The AC will > evaluate the discussion in order to assess the conformance of this draft > policy with ARIN's Principles of Internet number resource policy as stated > in the Policy Development Process (PDP). Specifically, these principles > are: > > * Enabling Fair and Impartial Number Resource Administration > * Technically Sound > * Supported by the Community > > The PDP can be found at: > https://www.arin.net/policy/pdp.html > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > Regards, > > Sean Hopkins > Policy Analyst > American Registry for Internet Numbers (ARIN) > > > > Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR > Transfers > > Version Date: 6 September 2017 > > Problem Statement: > > AFRINIC and LACNIC are currently considering one-way inter-RIR transfer > proposals. Those RIR communities feel a one-way policy a policy that allows > network operators in their regions to obtain space from another region and > transfer it into AFRINIC and LACNIC may best meet the needs of the > operators > in that region. > > ARIN staff, in reply to an inquiry from AFRINIC, have formally indicated > that ARINs 8.4 policy language will not allow ARIN to participate in such > one-way transfers. The staff formally indicate to AFRINIC that the word > reciprocal in 8.4 prohibits ARIN from allowing ARIN-registered space to > transfer directly to AFRINIC (in this context). > > ARIN as a community should recognize that other RIR operator communities > have different needs than we do. We should recognize that: > > - network operators in AFRINIC in LACNIC have need to obtain space in the > market; > > - have reasons they think are important to not allow two-way transfers; and > > - we should understand that the history of the RIR system has led to LACNIC > and AFRINIC having multiple orders of magnitude less IPv4 address space > than > ARIN does. > > Policy statement: > > Add the following sentence after the first sentence of NRPM 8.4: > > Inter-RIR transfers may take place to an RIR with a non-reciprocal > inter-RIR > transfer policy only when the recipient RIR has an IPv4 total inventory > less > than the average (mean) of the IPv4 total inventory among all of the RIRs. > > Timetable for implementation: Upon the ratification of any inter-RIR > transfer policy at another RIR that is one-way as described in the problem > statement. > _______________________________________________ > 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. > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > ARIN-PPML mailing list > ARIN-PPML at arin.net > http://lists.arin.net/mailman/listinfo/arin-ppml > > ------------------------------ > > End of ARIN-PPML Digest, Vol 147, Issue 7 > ***************************************** > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hostmaster at uneedus.com Thu Sep 7 15:23:36 2017 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Thu, 7 Sep 2017 15:23:36 -0400 (EDT) Subject: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers In-Reply-To: <6AC63D0C-6E34-432C-B499-347F0A3895C4@delong.com> References: <2bc0e7f7-c3d1-c496-1d58-ccec181c6414@arin.net> <6AC63D0C-6E34-432C-B499-347F0A3895C4@delong.com> Message-ID: The reason that those early class A holders received such a large block was simply the fact that CIDR did not exist at the time, and therefore there were only 3 possible values of address blocks you could receive, /8, /16 and /24. Clearly most of the original class A holders had plans to (and many still do) have more than 65536 devices, therefore being too large for a class B. In these days neither NAT or CIDR were a thing. You state that 4) is not entirely accurate, but I can find nothing that actually stated in policy that certain regions of the world were to receive less IPv4 resources than other portions. Of course since there were not large entities in Latin America or Africa requesting resources similar to MIT and others, we really do not know if resources would have been given out on the same basis. Had an actual request been made, and denied, that is a different story than we have here. In any case, had there been any large networks from these regions, they could have received address space they could justify from the free pool until it went away in 2011. However, like today these areas are clearly less served than other regions like ARIN and APNIC, and connectivity is often an issue as well. I believe that the only way the market of "highest and best use" for IPv4 addresses in a free market until everyone finally goes 100% to IPv6 is if all IPv4 addresses are subject to that market. I think that ARIN should not release addresses from this region to any region that has a one way policy, as it prevents the market of addresses from working. I also see a limit on how high address cost can go, as at some price point someone will simply say, "forget it, lets go v6". Albert Erdmann Network Administrator Paradise On Line Inc. On Thu, 7 Sep 2017, Owen DeLong wrote: > Timeline is a bit off??? > > Originally there was Jon Postel???s notebook. That passed to SRI and later evolved into InterNIC. > > RIPE and APNIC were created and handed parts of the responsibility prior to the formation of ARIN. > > ARIN remained ???registry of last resort??? until the formation of LACNIC and later AfriNIC. > > The ERX and other transfer processes were a bit more complicated, but essentially you have the right general idea. > > I think that statement 4 is likely not entirely historically accurate. > > Early distribution of IPv4 addresses was significantly more generous > than later distribution (companies like Apple and HP, Universities like > MIT, and others easily got /8s just for the asking, organizations of any > significant size could easily request and receive /16s, etc.). > > Otherwise, I think you generally have it right. > > Owen > >> On Sep 6, 2017, at 15:10 , hostmaster at uneedus.com wrote: >> >> Now that discussion reveals that "IPv4 Inventory", refers to the total number of IPv4 addresses that a specific RIR has under its management, and not the amount of IPv4 addresses remaining for assignment, I will state the problems I see with the proposal. However, I remain open minded and am asking questions in order to make up my mind. >> >> If any of the history of numbering management that I state below is wrong, please let me know, as it might change my viewpoint. >> >> 1) Originally there was effectively only one RIR worldwide. >> >> 2) This original RIR's Resources were placed under control of ARIN. >> >> 3) When each of the RIR's other than ARIN were formed, all resources >> that were assigned to entities within the region of the new RIR, that >> were under management of ARIN, or the RIR which previously managed the >> space (RIPE to AFRINIC in that case) were transfered to the new RIR. >> >> 4) The Previous RIR's who controled resources before the formation of >> LACNIC or AFRINIC did not have a policy in place that discriminated >> against any portion of the world, and would if presented with a request >> for IPv4 resources, would process that request using the same policy >> that was used for resources assigned in the remaining portions of that >> RIR's Territory. >> >> With each of these things said, I now draw some conclusions. Specifically, it is not North America's or ARIN's fault that LACNIC and AFRINIC has less resources under management than ARIN or RIPE or APNIC. Had networks needing resources existed during this time, and all the way past their formation up until that date that IANA ran out of /8's, that RIR could have received IPv4 addresses from the free pool on an equal basis. While the original Class A networks were given out a lot more loosely than ARIN's standards, this did not change the fact that IANA had a free pool after these original Class A networks were assigned, and did provide additional /8's to any RIR who could show that they had exhausted their free pool below the standard that was applied to all 5 RIR's. >> >> In my opinion the only reason that LACNIC and AFRINIC did not have as many /8's, was the growth in the APNIC region compared to all other regions, which during that time exceeded every other RIR, including ARIN. In fact, it was APNIC's request for more space that triggered the exhaustion of the free pool. Technically, when LACNIC and AFRINIC received their final /8, it was not totally fair to the other RIR's with more addresses under management. In fact, this final non proportional oversupply at AFRINIC is likely the only reason that AFRINIC is the only RIR with a general free pool. Instead of a full /8 to each region, maybe this should have been done more proportional to each region's total address space under management. >> >> For a market based solution to IPv4 addresses, addresses need to be able to flow both ways. AFRINIC and LACNIC can argue that we are the small guys, and we need to be protected against transfers out. However, I can just as easily argue that ARIN is being used as a worldwide piggy bank of IPv4 addresses and should also adopt an anti-transfer out policy. As long as things move both ways, we can argue that the market effect is important, but for this to work, it must be bidirectional everywhere. While ARIN is the leader in supplying directed transfer addresses, market conditions could change worldwide, causing more transfers from another RIR. For an example, say if China were to require ALL internet to use IPv6, and forbid the use of IPv4 in their country, a large number of IPv4 addresses allocated to China would suddenly be available on the transfer market. >> >> Some similar event that is now unknown could drive the IPv4 addresses of the LACNIC and AFRINIC into the market, and if this policy were adopted would be unfair to the markets that would be forbidden from these addresses being in the market because of the lack of a bidirectional transfer rule. >> >> My gut tells me that noone should get a pass on bidirectional transfers, and I am leaning NO at this time, but could be convinced otherwise for the proper reason. I do not think "Past Discrimination" is that reason. The true past problem was lack of past network growth, vs other regions. >> >> Albert Erdmann >> Network Administrator >> Paradise On Line Inc. >> >> >> >> On Wed, 6 Sep 2017, ARIN wrote: >> >>> The following has been revised: >>> >>> * Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers >>> >>> Revised text is below and can be found at: >>> https://www.arin.net/policy/proposals/2017_4.html >>> >>> You are encouraged to discuss all Draft Policies on PPML. The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet number resource policy as stated in the Policy Development Process (PDP). Specifically, these principles are: >>> >>> * Enabling Fair and Impartial Number Resource Administration >>> * Technically Sound >>> * Supported by the Community >>> >>> The PDP can be found at: >>> https://www.arin.net/policy/pdp.html >>> >>> Draft Policies and Proposals under discussion can be found at: >>> https://www.arin.net/policy/proposals/index.html >>> >>> Regards, >>> >>> Sean Hopkins >>> Policy Analyst >>> American Registry for Internet Numbers (ARIN) >>> >>> >>> >>> Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers >>> >>> Version Date: 6 September 2017 >>> >>> Problem Statement: >>> >>> AFRINIC and LACNIC are currently considering one-way inter-RIR transfer proposals. Those RIR communities feel a one-way policy a policy that allows network operators in their regions to obtain space from another region and transfer it into AFRINIC and LACNIC may best meet the needs of the operators in that region. >>> >>> ARIN staff, in reply to an inquiry from AFRINIC, have formally indicated that ARINs 8.4 policy language will not allow ARIN to participate in such one-way transfers. The staff formally indicate to AFRINIC that the word reciprocal in 8.4 prohibits ARIN from allowing ARIN-registered space to transfer directly to AFRINIC (in this context). >>> >>> ARIN as a community should recognize that other RIR operator communities have different needs than we do. We should recognize that: >>> >>> - network operators in AFRINIC in LACNIC have need to obtain space in the market; >>> >>> - have reasons they think are important to not allow two-way transfers; and >>> >>> - we should understand that the history of the RIR system has led to LACNIC and AFRINIC having multiple orders of magnitude less IPv4 address space than ARIN does. >>> >>> Policy statement: >>> >>> Add the following sentence after the first sentence of NRPM 8.4: >>> >>> Inter-RIR transfers may take place to an RIR with a non-reciprocal inter-RIR transfer policy only when the recipient RIR has an IPv4 total inventory less than the average (mean) of the IPv4 total inventory among all of the RIRs. >>> >>> Timetable for implementation: Upon the ratification of any inter-RIR transfer policy at another RIR that is one-way as described in the problem statement. >>> _______________________________________________ >>> 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 chris at semihuman.com Thu Sep 7 15:31:34 2017 From: chris at semihuman.com (Chris Woodfield) Date: Thu, 7 Sep 2017 12:31:34 -0700 Subject: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers In-Reply-To: <9D9CAE4C-0723-4F15-A543-AE368EFD8C97@delong.com> References: <2bc0e7f7-c3d1-c496-1d58-ccec181c6414@arin.net> <7E7773B523E82C478734E793E58F69E7A52773A8@SBS2011.thewireinc.local> <9D9CAE4C-0723-4F15-A543-AE368EFD8C97@delong.com> Message-ID: Which leads to the question as to why? a policy proposal to allow for outbound transfers as well as inbound in those regions would render this policy moot. Is there any sense of the appetite for such a proposal in either region, or would it be perceived as having the potential to result in even more IP space leaving those regions (due to deeper pockets in the transfer market in other regions)? -C > On Sep 7, 2017, at 11:25 AM, Owen DeLong wrote: > > Neither LACNIC nor AfriNIC have currently passed or implemented an inter-RIR transfer policy. > > All Inter-RIR policies that have been considered in either region have been unilateral inbound-only to the best of my knowledge. > > Owen > >> On Sep 7, 2017, at 05:30 , Kevin Blumberg wrote: >> >> Are there active polices in the other regions that rely on this policy? I understand there have been discussions, however I don't know what the status is/was. >> >> Thanks, >> >> Kevin Blumberg >> >> >> >> -----Original Message----- >> From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN >> Sent: Wednesday, September 6, 2017 2:36 PM >> To: arin-ppml at arin.net >> Subject: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers >> >> The following has been revised: >> >> * Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers >> >> Revised text is below and can be found at: >> https://www.arin.net/policy/proposals/2017_4.html >> >> You are encouraged to discuss all Draft Policies on PPML. The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet number resource policy as stated in the Policy Development Process (PDP). Specifically, these principles are: >> >> * Enabling Fair and Impartial Number Resource Administration >> * Technically Sound >> * Supported by the Community >> >> The PDP can be found at: >> https://www.arin.net/policy/pdp.html >> >> Draft Policies and Proposals under discussion can be found at: >> https://www.arin.net/policy/proposals/index.html >> >> Regards, >> >> Sean Hopkins >> Policy Analyst >> American Registry for Internet Numbers (ARIN) >> >> >> >> Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers >> >> Version Date: 6 September 2017 >> >> Problem Statement: >> >> AFRINIC and LACNIC are currently considering one-way inter-RIR transfer proposals. Those RIR communities feel a one-way policy a policy that allows network operators in their regions to obtain space from another region and transfer it into AFRINIC and LACNIC may best meet the needs of the operators in that region. >> >> ARIN staff, in reply to an inquiry from AFRINIC, have formally indicated that ARINs 8.4 policy language will not allow ARIN to participate in such one-way transfers. The staff formally indicate to AFRINIC that the word reciprocal in 8.4 prohibits ARIN from allowing ARIN-registered space to transfer directly to AFRINIC (in this context). >> >> ARIN as a community should recognize that other RIR operator communities have different needs than we do. We should recognize that: >> >> - network operators in AFRINIC in LACNIC have need to obtain space in the market; >> >> - have reasons they think are important to not allow two-way transfers; and >> >> - we should understand that the history of the RIR system has led to LACNIC and AFRINIC having multiple orders of magnitude less IPv4 address space than ARIN does. >> >> Policy statement: >> >> Add the following sentence after the first sentence of NRPM 8.4: >> >> Inter-RIR transfers may take place to an RIR with a non-reciprocal inter-RIR transfer policy only when the recipient RIR has an IPv4 total inventory less than the average (mean) of the IPv4 total inventory among all of the RIRs. >> >> Timetable for implementation: Upon the ratification of any inter-RIR transfer policy at another RIR that is one-way as described in the problem statement. >> _______________________________________________ >> 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 farmer at umn.edu Thu Sep 7 16:46:38 2017 From: farmer at umn.edu (David Farmer) Date: Thu, 7 Sep 2017 15:46:38 -0500 Subject: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers In-Reply-To: References: <2bc0e7f7-c3d1-c496-1d58-ccec181c6414@arin.net> Message-ID: Cathy, Yes, in some ways it would be more straight forward to just say LACNIC and AFRINIC are allowed an exception to the reciprocity requirement. However, that policy would contain only the facts of the situation. Whereas this policy contains quantifiable reasoning why LACNIC and AFRINIC are exempted from the reciprocity requirement and why APNIC and RIPE are not. To be honest, I didn't want the reciprocity requirement in the original transfer policy to being with, because of the optics of this very situation with LACNIC and AFRINIC. However, I didn't push the issue with the original transfer policy because I knew it would be several year before LACNIC and AFRINIC got to the point of approving a transfer policy of any kind. So, when this issue with LACNIC and AFRINIC came up I thought obvious thing to do was to eliminate the reciprocity requirement all together. However, I really like this compromise as well as the reasoning that comes with it. There is absolutely no reason for transfers with APNIC and RIPE to not be on a reciprocal basis. However, with LACNIC and AFRINIC I feel there should be room for some nuance. LACNIC and AFRINIC have received the short-end of the stick, so to speak. There was no conspiracy or wrongdoing that caused this result, but it is a stark fact when you look at the numbers. I therefore believe these facts should afford LACNIC and AFRINIC some latitude to decide for themselves how best to move forward. In the long-run I totally believe LACNIC and AFRINIC should approve reciprocal transfer policies. However, we need to give them room to decide this for themselves, it is arrogant and inconsiderate of the facts for us to dictate a reciprocal transfer policy to them. If they feel they need to start with a one-way transfer policy, there is logic to such a strategy, and the current facts seem to justify at least some caution on their part. Finally, the numbers show we have more than enough room to be magnanimous in this situation, I believe we should give LACNIC and AFRINIC room to maneuver, and choose their own way forward. Thanks. On Wed, Sep 6, 2017 at 4:10 PM, Cj Aronson wrote: > Okay so this formula.. does it just give us Afrinic and Lacnic right? So > why don't we just say that? Since there are only 5 RIRs it seems that > maybe a formula isn't needed? > > > {?,?} > (( )) > ? ? > > On Wed, Sep 6, 2017 at 12:35 PM, ARIN wrote: > >> The following has been revised: >> >> * Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR >> Transfers >> >> Revised text is below and can be found at: >> https://www.arin.net/policy/proposals/2017_4.html >> >> You are encouraged to discuss all Draft Policies on PPML. The AC will >> evaluate the discussion in order to assess the conformance of this draft >> policy with ARIN's Principles of Internet number resource policy as stated >> in the Policy Development Process (PDP). Specifically, these principles are: >> >> * Enabling Fair and Impartial Number Resource Administration >> * Technically Sound >> * Supported by the Community >> >> The PDP can be found at: >> https://www.arin.net/policy/pdp.html >> >> Draft Policies and Proposals under discussion can be found at: >> https://www.arin.net/policy/proposals/index.html >> >> Regards, >> >> Sean Hopkins >> Policy Analyst >> American Registry for Internet Numbers (ARIN) >> >> >> >> Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR >> Transfers >> >> Version Date: 6 September 2017 >> >> Problem Statement: >> >> AFRINIC and LACNIC are currently considering one-way inter-RIR transfer >> proposals. Those RIR communities feel a one-way policy a policy that allows >> network operators in their regions to obtain space from another region and >> transfer it into AFRINIC and LACNIC may best meet the needs of the >> operators in that region. >> >> ARIN staff, in reply to an inquiry from AFRINIC, have formally indicated >> that ARINs 8.4 policy language will not allow ARIN to participate in such >> one-way transfers. The staff formally indicate to AFRINIC that the word >> reciprocal in 8.4 prohibits ARIN from allowing ARIN-registered space to >> transfer directly to AFRINIC (in this context). >> >> ARIN as a community should recognize that other RIR operator communities >> have different needs than we do. We should recognize that: >> >> - network operators in AFRINIC in LACNIC have need to obtain space in the >> market; >> >> - have reasons they think are important to not allow two-way transfers; >> and >> >> - we should understand that the history of the RIR system has led to >> LACNIC and AFRINIC having multiple orders of magnitude less IPv4 address >> space than ARIN does. >> >> Policy statement: >> >> Add the following sentence after the first sentence of NRPM 8.4: >> >> Inter-RIR transfers may take place to an RIR with a non-reciprocal >> inter-RIR transfer policy only when the recipient RIR has an IPv4 total >> inventory less than the average (mean) of the IPv4 total inventory among >> all of the RIRs. >> >> Timetable for implementation: Upon the ratification of any inter-RIR >> transfer policy at another RIR that is one-way as described in the problem >> statement. >> _______________________________________________ >> 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. > -- =============================================== 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 Thu Sep 7 17:27:28 2017 From: jcurran at arin.net (John Curran) Date: Thu, 7 Sep 2017 21:27:28 +0000 Subject: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers In-Reply-To: <7E7773B523E82C478734E793E58F69E7A5278612@SBS2011.thewireinc.local> References: <2bc0e7f7-c3d1-c496-1d58-ccec181c6414@arin.net> <7E7773B523E82C478734E793E58F69E7A52773A8@SBS2011.thewireinc.local> <030f01d327de$ab148cb0$013da610$@iptrading.com> <7E7773B523E82C478734E793E58F69E7A5278612@SBS2011.thewireinc.local> Message-ID: <79D79834-C325-4373-B912-6B4419DCD9DA@arin.net> On 7 Sep 2017, at 12:42 PM, Kevin Blumberg wrote: > > In re-reading the problem statement the following information was given. > > "ARIN staff, in reply to an inquiry from AFRINIC, have formally indicated that ARINs 8.4 policy language will not allow ARIN to participate in such one-way transfers." > > The use of one-way transfers completely mitigates any loss on the one side, and opens concern from the other. > > A question for Staff. Would a policy in another region that allows transfers, if a ratio at or above 1:1 basis work? Would that be considered reciprocal? Kevin - Presently staff considers the reciprocal requirement to require that bidirectional transfers generally available under the other RIRs Inter-RIR transfer policy? i.e. if you meet the specific recipient criteria, then one should generally be able to be a recipient of resources coming from a source located with another RIR. Any requirement for an overall "ratio? would mean that the Inter-RIR transfers policy could no longer be generally relied upon; its applicability to any given transfer request would be based on factors not controlled by the source or recipient organizations. Such a constraint in another RIR?s inter-RIR transfer policy would create a circumstance not covered by our existing 8.4 Inter-RIR policy language, nor raised & addressed in the history of its development, so it is not 100% clear what the community wants ARIN staff to do under such circumstances. We likely would be conservative and notify the community that such a constraint for a 1:1 ratio makes a policy which is not clearly reciprocal, and given that reciprocal is a criteria under which transfers _only_ may occur, such a policy would prevent Inter-RIR transfers from with that RIR community, unless/until revised NRPM policy language is adopted by ARIN community making more clear the appropriate handling of this situation. Thanks! (and I do hope this helps your policy development efforts) /John John Curran President and CEO ARIN From cja at daydream.com Thu Sep 7 17:27:50 2017 From: cja at daydream.com (Cj Aronson) Date: Thu, 7 Sep 2017 15:27:50 -0600 Subject: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers In-Reply-To: References: <2bc0e7f7-c3d1-c496-1d58-ccec181c6414@arin.net> Message-ID: David.. I agree with your very well written summary. I just feel that the mathematical formula to determine when the transfers have to start being reciprocal is not needed. The reason why I feel that way is that we're computing something that was said earlier, "To go below the global average, the RIR above the average and closest to it would need to lose 81,871,002 more addresses, which at the current rate (14,592 lost per month) would take 5,620 months (468 years)." It seems like we're spending time computing something that is not likely to happen.. I would surely hope we are done with IPv4 within the next 468 years :-) Thanks! -----Cathy {?,?} (( )) ? ? On Thu, Sep 7, 2017 at 2:46 PM, David Farmer wrote: > Cathy, > > Yes, in some ways it would be more straight forward to just say LACNIC and > AFRINIC are allowed an exception to the reciprocity requirement. However, > that policy would contain only the facts of the situation. Whereas this > policy contains quantifiable reasoning why LACNIC and AFRINIC are exempted > from the reciprocity requirement and why APNIC and RIPE are not. > > To be honest, I didn't want the reciprocity requirement in the original > transfer policy to being with, because of the optics of this very situation > with LACNIC and AFRINIC. However, I didn't push the issue with the > original transfer policy because I knew it would be several year before > LACNIC and AFRINIC got to the point of approving a transfer policy of any > kind. So, when this issue with LACNIC and AFRINIC came up I thought obvious > thing to do was to eliminate the reciprocity requirement all together. > However, I really like this compromise as well as the reasoning that comes > with it. > > There is absolutely no reason for transfers with APNIC and RIPE to not be > on a reciprocal basis. However, with LACNIC and AFRINIC I feel there should > be room for some nuance. LACNIC and AFRINIC have received the short-end of > the stick, so to speak. There was no conspiracy or wrongdoing that caused > this result, but it is a stark fact when you look at the numbers. I > therefore believe these facts should afford LACNIC and AFRINIC some > latitude to decide for themselves how best to move forward. > > In the long-run I totally believe LACNIC and AFRINIC should approve > reciprocal transfer policies. However, we need to give them room to decide > this for themselves, it is arrogant and inconsiderate of the facts for us > to dictate a reciprocal transfer policy to them. If they feel they need to > start with a one-way transfer policy, there is logic to such a strategy, > and the current facts seem to justify at least some caution on their part. > > > Finally, the numbers show we have more than enough room to be magnanimous > in this situation, I believe we should give LACNIC and AFRINIC room to > maneuver, and choose their own way forward. > > Thanks. > > On Wed, Sep 6, 2017 at 4:10 PM, Cj Aronson wrote: > >> Okay so this formula.. does it just give us Afrinic and Lacnic right? So >> why don't we just say that? Since there are only 5 RIRs it seems that >> maybe a formula isn't needed? >> >> >> {?,?} >> (( )) >> ? ? >> >> On Wed, Sep 6, 2017 at 12:35 PM, ARIN wrote: >> >>> The following has been revised: >>> >>> * Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR >>> Transfers >>> >>> Revised text is below and can be found at: >>> https://www.arin.net/policy/proposals/2017_4.html >>> >>> You are encouraged to discuss all Draft Policies on PPML. The AC will >>> evaluate the discussion in order to assess the conformance of this draft >>> policy with ARIN's Principles of Internet number resource policy as stated >>> in the Policy Development Process (PDP). Specifically, these principles are: >>> >>> * Enabling Fair and Impartial Number Resource Administration >>> * Technically Sound >>> * Supported by the Community >>> >>> The PDP can be found at: >>> https://www.arin.net/policy/pdp.html >>> >>> Draft Policies and Proposals under discussion can be found at: >>> https://www.arin.net/policy/proposals/index.html >>> >>> Regards, >>> >>> Sean Hopkins >>> Policy Analyst >>> American Registry for Internet Numbers (ARIN) >>> >>> >>> >>> Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR >>> Transfers >>> >>> Version Date: 6 September 2017 >>> >>> Problem Statement: >>> >>> AFRINIC and LACNIC are currently considering one-way inter-RIR transfer >>> proposals. Those RIR communities feel a one-way policy a policy that allows >>> network operators in their regions to obtain space from another region and >>> transfer it into AFRINIC and LACNIC may best meet the needs of the >>> operators in that region. >>> >>> ARIN staff, in reply to an inquiry from AFRINIC, have formally indicated >>> that ARINs 8.4 policy language will not allow ARIN to participate in such >>> one-way transfers. The staff formally indicate to AFRINIC that the word >>> reciprocal in 8.4 prohibits ARIN from allowing ARIN-registered space to >>> transfer directly to AFRINIC (in this context). >>> >>> ARIN as a community should recognize that other RIR operator communities >>> have different needs than we do. We should recognize that: >>> >>> - network operators in AFRINIC in LACNIC have need to obtain space in >>> the market; >>> >>> - have reasons they think are important to not allow two-way transfers; >>> and >>> >>> - we should understand that the history of the RIR system has led to >>> LACNIC and AFRINIC having multiple orders of magnitude less IPv4 address >>> space than ARIN does. >>> >>> Policy statement: >>> >>> Add the following sentence after the first sentence of NRPM 8.4: >>> >>> Inter-RIR transfers may take place to an RIR with a non-reciprocal >>> inter-RIR transfer policy only when the recipient RIR has an IPv4 total >>> inventory less than the average (mean) of the IPv4 total inventory among >>> all of the RIRs. >>> >>> Timetable for implementation: Upon the ratification of any inter-RIR >>> transfer policy at another RIR that is one-way as described in the problem >>> statement. >>> _______________________________________________ >>> 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. >> > > > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> > Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> > =============================================== > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at semihuman.com Thu Sep 7 17:50:40 2017 From: chris at semihuman.com (Chris Woodfield) Date: Thu, 7 Sep 2017 14:50:40 -0700 Subject: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers In-Reply-To: References: <2bc0e7f7-c3d1-c496-1d58-ccec181c6414@arin.net> Message-ID: <0439B09D-AF93-4BC2-97EB-48A10BF753E8@semihuman.com> Thinking more about the use of an average distribution in the proposal, I?m wondering if this accurately reflects the issue. The distribution of IP addresses by IANA to the various RIRs is only inequitable if it results in a clear difference in the ability of an entity in different regions to acquire IP address space. We don?t need the same number of allocations in each region - if nothing else, the allocations should roughly reflect regional populations - but it should be no more difficult for a party in Africa or South America to acquire IPv4 resources than it is for a party in North America, Europe, or Asia to do so. To the extent that this is not the case, we owe the community action to correct. The question then becomes - does the lack of a transfer policy from ARIN to these regions make it substantially more difficult to acquire space on the transfer market today? I?d argue that to the extent that doing so requires transferring to the space to the local RIR, then the answer is YES, as from my point of view, the bulk of transfer market supply is from allocations in the ARIN region (resellers on the list who are in a position to comment, please keep me honest and speak up if that isn?t the case). This is somewhat mitigated by the current case that both LACNIC and AFRINIC still have space to allocate, while ARIN does not. But shower term point-in-time facts shouldn?t drive far-reaching policy decisions IMO. As such, I support the goal of the policy, but I believe that the calculation used to determine qualifying RIRs could be tweaked. Could we compare allocation percentages to world population, perhaps? -C > On Sep 7, 2017, at 2:27 PM, Cj Aronson wrote: > > David.. I agree with your very well written summary. I just feel that the mathematical formula to determine when the transfers have to start being reciprocal is not needed. > > The reason why I feel that way is that we're computing something that was said earlier, "To go below the global average, the RIR above the average and closest to > it would need to lose 81,871,002 more addresses, which at the current rate > (14,592 lost per month) would take 5,620 months (468 years)." > > It seems like we're spending time computing something that is not likely to happen.. I would surely hope we are done with IPv4 within the next 468 years :-) > > > Thanks! > -----Cathy > > > {?,?} > (( )) > ? ? > > On Thu, Sep 7, 2017 at 2:46 PM, David Farmer > wrote: > Cathy, > > Yes, in some ways it would be more straight forward to just say LACNIC and AFRINIC are allowed an exception to the reciprocity requirement. However, that policy would contain only the facts of the situation. Whereas this policy contains quantifiable reasoning why LACNIC and AFRINIC are exempted from the reciprocity requirement and why APNIC and RIPE are not. > > To be honest, I didn't want the reciprocity requirement in the original transfer policy to being with, because of the optics of this very situation with LACNIC and AFRINIC. However, I didn't push the issue with the original transfer policy because I knew it would be several year before LACNIC and AFRINIC got to the point of approving a transfer policy of any kind. So, when this issue with LACNIC and AFRINIC came up I thought obvious thing to do was to eliminate the reciprocity requirement all together. However, I really like this compromise as well as the reasoning that comes with it. > > There is absolutely no reason for transfers with APNIC and RIPE to not be on a reciprocal basis. However, with LACNIC and AFRINIC I feel there should be room for some nuance. LACNIC and AFRINIC have received the short-end of the stick, so to speak. There was no conspiracy or wrongdoing that caused this result, but it is a stark fact when you look at the numbers. I therefore believe these facts should afford LACNIC and AFRINIC some latitude to decide for themselves how best to move forward. > > In the long-run I totally believe LACNIC and AFRINIC should approve reciprocal transfer policies. However, we need to give them room to decide this for themselves, it is arrogant and inconsiderate of the facts for us to dictate a reciprocal transfer policy to them. If they feel they need to start with a one-way transfer policy, there is logic to such a strategy, and the current facts seem to justify at least some caution on their part. > > Finally, the numbers show we have more than enough room to be magnanimous in this situation, I believe we should give LACNIC and AFRINIC room to maneuver, and choose their own way forward. > > Thanks. > > On Wed, Sep 6, 2017 at 4:10 PM, Cj Aronson > wrote: > Okay so this formula.. does it just give us Afrinic and Lacnic right? So why don't we just say that? Since there are only 5 RIRs it seems that maybe a formula isn't needed? > > > {?,?} > (( )) > ? ? > > On Wed, Sep 6, 2017 at 12:35 PM, ARIN > wrote: > The following has been revised: > > * Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers > > Revised text is below and can be found at: > https://www.arin.net/policy/proposals/2017_4.html > > You are encouraged to discuss all Draft Policies on PPML. The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet number resource policy as stated in the Policy Development Process (PDP). Specifically, these principles are: > > * Enabling Fair and Impartial Number Resource Administration > * Technically Sound > * Supported by the Community > > The PDP can be found at: > https://www.arin.net/policy/pdp.html > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > Regards, > > Sean Hopkins > Policy Analyst > American Registry for Internet Numbers (ARIN) > > > > Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers > > Version Date: 6 September 2017 > > Problem Statement: > > AFRINIC and LACNIC are currently considering one-way inter-RIR transfer proposals. Those RIR communities feel a one-way policy a policy that allows network operators in their regions to obtain space from another region and transfer it into AFRINIC and LACNIC may best meet the needs of the operators in that region. > > ARIN staff, in reply to an inquiry from AFRINIC, have formally indicated that ARINs 8.4 policy language will not allow ARIN to participate in such one-way transfers. The staff formally indicate to AFRINIC that the word reciprocal in 8.4 prohibits ARIN from allowing ARIN-registered space to transfer directly to AFRINIC (in this context). > > ARIN as a community should recognize that other RIR operator communities have different needs than we do. We should recognize that: > > - network operators in AFRINIC in LACNIC have need to obtain space in the market; > > - have reasons they think are important to not allow two-way transfers; and > > - we should understand that the history of the RIR system has led to LACNIC and AFRINIC having multiple orders of magnitude less IPv4 address space than ARIN does. > > Policy statement: > > Add the following sentence after the first sentence of NRPM 8.4: > > Inter-RIR transfers may take place to an RIR with a non-reciprocal inter-RIR transfer policy only when the recipient RIR has an IPv4 total inventory less than the average (mean) of the IPv4 total inventory among all of the RIRs. > > Timetable for implementation: Upon the ratification of any inter-RIR transfer policy at another RIR that is one-way as described in the problem statement. > _______________________________________________ > 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. > > > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =============================================== > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at semihuman.com Thu Sep 7 18:19:35 2017 From: chris at semihuman.com (Chris Woodfield) Date: Thu, 7 Sep 2017 15:19:35 -0700 Subject: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers In-Reply-To: <0439B09D-AF93-4BC2-97EB-48A10BF753E8@semihuman.com> References: <2bc0e7f7-c3d1-c496-1d58-ccec181c6414@arin.net> <0439B09D-AF93-4BC2-97EB-48A10BF753E8@semihuman.com> Message-ID: <18F45FF2-7AC8-4891-B54F-9F135A09AFD4@semihuman.com> Replying to myself, I decided to look up the population proportions mentioned in my last email: North America - 7.79% South America - 5.68% Africa - 16.36% So if one were to use numbers similar to these - the average formula doesn?t make much of a difference for LACNIC, and actually qualifies AFRINIC for a far larger share of space than the straight average. I?m wondering what, if any, types of metrics might exist for measuring demand for resources instead of population? Or does that run afoul of the concept of Internet access as a worldwide human right? -C > On Sep 7, 2017, at 2:50 PM, Chris Woodfield wrote: > > Thinking more about the use of an average distribution in the proposal, I?m wondering if this accurately reflects the issue. > > The distribution of IP addresses by IANA to the various RIRs is only inequitable if it results in a clear difference in the ability of an entity in different regions to acquire IP address space. We don?t need the same number of allocations in each region - if nothing else, the allocations should roughly reflect regional populations - but it should be no more difficult for a party in Africa or South America to acquire IPv4 resources than it is for a party in North America, Europe, or Asia to do so. To the extent that this is not the case, we owe the community action to correct. > > The question then becomes - does the lack of a transfer policy from ARIN to these regions make it substantially more difficult to acquire space on the transfer market today? I?d argue that to the extent that doing so requires transferring to the space to the local RIR, then the answer is YES, as from my point of view, the bulk of transfer market supply is from allocations in the ARIN region (resellers on the list who are in a position to comment, please keep me honest and speak up if that isn?t the case). > > This is somewhat mitigated by the current case that both LACNIC and AFRINIC still have space to allocate, while ARIN does not. But shower term point-in-time facts shouldn?t drive far-reaching policy decisions IMO. > > As such, I support the goal of the policy, but I believe that the calculation used to determine qualifying RIRs could be tweaked. Could we compare allocation percentages to world population, perhaps? > > -C > >> On Sep 7, 2017, at 2:27 PM, Cj Aronson > wrote: >> >> David.. I agree with your very well written summary. I just feel that the mathematical formula to determine when the transfers have to start being reciprocal is not needed. >> >> The reason why I feel that way is that we're computing something that was said earlier, "To go below the global average, the RIR above the average and closest to >> it would need to lose 81,871,002 more addresses, which at the current rate >> (14,592 lost per month) would take 5,620 months (468 years)." >> >> It seems like we're spending time computing something that is not likely to happen.. I would surely hope we are done with IPv4 within the next 468 years :-) >> >> >> Thanks! >> -----Cathy >> >> >> {?,?} >> (( )) >> ? ? >> >> On Thu, Sep 7, 2017 at 2:46 PM, David Farmer > wrote: >> Cathy, >> >> Yes, in some ways it would be more straight forward to just say LACNIC and AFRINIC are allowed an exception to the reciprocity requirement. However, that policy would contain only the facts of the situation. Whereas this policy contains quantifiable reasoning why LACNIC and AFRINIC are exempted from the reciprocity requirement and why APNIC and RIPE are not. >> >> To be honest, I didn't want the reciprocity requirement in the original transfer policy to being with, because of the optics of this very situation with LACNIC and AFRINIC. However, I didn't push the issue with the original transfer policy because I knew it would be several year before LACNIC and AFRINIC got to the point of approving a transfer policy of any kind. So, when this issue with LACNIC and AFRINIC came up I thought obvious thing to do was to eliminate the reciprocity requirement all together. However, I really like this compromise as well as the reasoning that comes with it. >> >> There is absolutely no reason for transfers with APNIC and RIPE to not be on a reciprocal basis. However, with LACNIC and AFRINIC I feel there should be room for some nuance. LACNIC and AFRINIC have received the short-end of the stick, so to speak. There was no conspiracy or wrongdoing that caused this result, but it is a stark fact when you look at the numbers. I therefore believe these facts should afford LACNIC and AFRINIC some latitude to decide for themselves how best to move forward. >> >> In the long-run I totally believe LACNIC and AFRINIC should approve reciprocal transfer policies. However, we need to give them room to decide this for themselves, it is arrogant and inconsiderate of the facts for us to dictate a reciprocal transfer policy to them. If they feel they need to start with a one-way transfer policy, there is logic to such a strategy, and the current facts seem to justify at least some caution on their part. >> >> Finally, the numbers show we have more than enough room to be magnanimous in this situation, I believe we should give LACNIC and AFRINIC room to maneuver, and choose their own way forward. >> >> Thanks. >> >> On Wed, Sep 6, 2017 at 4:10 PM, Cj Aronson > wrote: >> Okay so this formula.. does it just give us Afrinic and Lacnic right? So why don't we just say that? Since there are only 5 RIRs it seems that maybe a formula isn't needed? >> >> >> {?,?} >> (( )) >> ? ? >> >> On Wed, Sep 6, 2017 at 12:35 PM, ARIN > wrote: >> The following has been revised: >> >> * Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers >> >> Revised text is below and can be found at: >> https://www.arin.net/policy/proposals/2017_4.html >> >> You are encouraged to discuss all Draft Policies on PPML. The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet number resource policy as stated in the Policy Development Process (PDP). Specifically, these principles are: >> >> * Enabling Fair and Impartial Number Resource Administration >> * Technically Sound >> * Supported by the Community >> >> The PDP can be found at: >> https://www.arin.net/policy/pdp.html >> >> Draft Policies and Proposals under discussion can be found at: >> https://www.arin.net/policy/proposals/index.html >> >> Regards, >> >> Sean Hopkins >> Policy Analyst >> American Registry for Internet Numbers (ARIN) >> >> >> >> Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers >> >> Version Date: 6 September 2017 >> >> Problem Statement: >> >> AFRINIC and LACNIC are currently considering one-way inter-RIR transfer proposals. Those RIR communities feel a one-way policy a policy that allows network operators in their regions to obtain space from another region and transfer it into AFRINIC and LACNIC may best meet the needs of the operators in that region. >> >> ARIN staff, in reply to an inquiry from AFRINIC, have formally indicated that ARINs 8.4 policy language will not allow ARIN to participate in such one-way transfers. The staff formally indicate to AFRINIC that the word reciprocal in 8.4 prohibits ARIN from allowing ARIN-registered space to transfer directly to AFRINIC (in this context). >> >> ARIN as a community should recognize that other RIR operator communities have different needs than we do. We should recognize that: >> >> - network operators in AFRINIC in LACNIC have need to obtain space in the market; >> >> - have reasons they think are important to not allow two-way transfers; and >> >> - we should understand that the history of the RIR system has led to LACNIC and AFRINIC having multiple orders of magnitude less IPv4 address space than ARIN does. >> >> Policy statement: >> >> Add the following sentence after the first sentence of NRPM 8.4: >> >> Inter-RIR transfers may take place to an RIR with a non-reciprocal inter-RIR transfer policy only when the recipient RIR has an IPv4 total inventory less than the average (mean) of the IPv4 total inventory among all of the RIRs. >> >> Timetable for implementation: Upon the ratification of any inter-RIR transfer policy at another RIR that is one-way as described in the problem statement. >> _______________________________________________ >> 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. >> >> >> >> -- >> =============================================== >> David Farmer Email:farmer at umn.edu >> Networking & Telecommunication Services >> Office of Information Technology >> University of Minnesota >> 2218 University Ave SE Phone: 612-626-0815 >> Minneapolis, MN 55414-3029 Cell: 612-812-9952 >> =============================================== >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From scottleibrand at gmail.com Thu Sep 7 20:06:40 2017 From: scottleibrand at gmail.com (Scott Leibrand) Date: Thu, 7 Sep 2017 17:06:40 -0700 Subject: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers In-Reply-To: <18F45FF2-7AC8-4891-B54F-9F135A09AFD4@semihuman.com> References: <2bc0e7f7-c3d1-c496-1d58-ccec181c6414@arin.net> <0439B09D-AF93-4BC2-97EB-48A10BF753E8@semihuman.com> <18F45FF2-7AC8-4891-B54F-9F135A09AFD4@semihuman.com> Message-ID: IMO we're overthinking this. The problem is simply that not all companies can get access to the IP addresses they need to run their businesses. The fix is to enable transfers from ARIN to all other regions, and between as many regions as are willing to participate. Only LACNIC and AfriNIC don't allow such transfers yet, and if we can make it easier for them to allow transfers at least in the important direction (to their regions) then the transfer market will take care of making sure everyone who needs addresses can get them. So any policy, including the draft policy as written, that allows unidirectional transfers to LACNIC and AfriNIC solves the problem. -Scott On Thu, Sep 7, 2017 at 3:19 PM, Chris Woodfield wrote: > Replying to myself, I decided to look up the population proportions > mentioned in my last email: > > North America - 7.79% > South America - 5.68% > Africa - 16.36% > > So if one were to use numbers similar to these - the average formula > doesn?t make much of a difference for LACNIC, and actually qualifies > AFRINIC for a far larger share of space than the straight average. > > I?m wondering what, if any, types of metrics might exist for measuring > demand for resources instead of population? Or does that run afoul of the > concept of Internet access as a worldwide human right? > > -C > > On Sep 7, 2017, at 2:50 PM, Chris Woodfield wrote: > > Thinking more about the use of an average distribution in the proposal, > I?m wondering if this accurately reflects the issue. > > The distribution of IP addresses by IANA to the various RIRs is only > inequitable if it results in a clear difference in the ability of an entity > in different regions to acquire IP address space. We don?t need the same > number of allocations in each region - if nothing else, the allocations > should roughly reflect regional populations - but it should be no more > difficult for a party in Africa or South America to acquire IPv4 resources > than it is for a party in North America, Europe, or Asia to do so. To the > extent that this is not the case, we owe the community action to correct. > > The question then becomes - does the lack of a transfer policy from ARIN > to these regions make it substantially more difficult to acquire space on > the transfer market today? I?d argue that to the extent that doing so > requires transferring to the space to the local RIR, then the answer is > YES, as from my point of view, the bulk of transfer market supply is from > allocations in the ARIN region (resellers on the list who are in a position > to comment, please keep me honest and speak up if that isn?t the case). > > This is somewhat mitigated by the current case that both LACNIC and > AFRINIC still have space to allocate, while ARIN does not. But shower term > point-in-time facts shouldn?t drive far-reaching policy decisions IMO. > > As such, I support the goal of the policy, but I believe that the > calculation used to determine qualifying RIRs could be tweaked. Could we > compare allocation percentages to world population, perhaps? > > -C > > On Sep 7, 2017, at 2:27 PM, Cj Aronson wrote: > > David.. I agree with your very well written summary. I just feel that the > mathematical formula to determine when the transfers have to start being > reciprocal is not needed. > > The reason why I feel that way is that we're computing something that was > said earlier, "To go below the global average, the RIR above the average > and closest to > it would need to lose 81,871,002 more addresses, which at the current rate > (14,592 lost per month) would take 5,620 months (468 years)." > > It seems like we're spending time computing something that is not likely > to happen.. I would surely hope we are done with IPv4 within the next 468 > years :-) > > > Thanks! > -----Cathy > > > {?,?} > (( )) > ? ? > > On Thu, Sep 7, 2017 at 2:46 PM, David Farmer wrote: > >> Cathy, >> >> Yes, in some ways it would be more straight forward to just say LACNIC >> and AFRINIC are allowed an exception to the reciprocity requirement. >> However, that policy would contain only the facts of the situation. >> Whereas this policy contains quantifiable reasoning why LACNIC and AFRINIC >> are exempted from the reciprocity requirement and why APNIC and RIPE are >> not. >> >> To be honest, I didn't want the reciprocity requirement in the original >> transfer policy to being with, because of the optics of this very situation >> with LACNIC and AFRINIC. However, I didn't push the issue with the >> original transfer policy because I knew it would be several year before >> LACNIC and AFRINIC got to the point of approving a transfer policy of any >> kind. So, when this issue with LACNIC and AFRINIC came up I thought obvious >> thing to do was to eliminate the reciprocity requirement all together. >> However, I really like this compromise as well as the reasoning that comes >> with it. >> >> There is absolutely no reason for transfers with APNIC and RIPE to not be >> on a reciprocal basis. However, with LACNIC and AFRINIC I feel there should >> be room for some nuance. LACNIC and AFRINIC have received the short-end of >> the stick, so to speak. There was no conspiracy or wrongdoing that caused >> this result, but it is a stark fact when you look at the numbers. I >> therefore believe these facts should afford LACNIC and AFRINIC some >> latitude to decide for themselves how best to move forward. >> >> In the long-run I totally believe LACNIC and AFRINIC should approve >> reciprocal transfer policies. However, we need to give them room to decide >> this for themselves, it is arrogant and inconsiderate of the facts for us >> to dictate a reciprocal transfer policy to them. If they feel they need to >> start with a one-way transfer policy, there is logic to such a strategy, >> and the current facts seem to justify at least some caution on their part. >> >> >> Finally, the numbers show we have more than enough room to be magnanimous >> in this situation, I believe we should give LACNIC and AFRINIC room to >> maneuver, and choose their own way forward. >> >> Thanks. >> >> On Wed, Sep 6, 2017 at 4:10 PM, Cj Aronson wrote: >> >>> Okay so this formula.. does it just give us Afrinic and Lacnic right? >>> So why don't we just say that? Since there are only 5 RIRs it seems that >>> maybe a formula isn't needed? >>> >>> >>> {?,?} >>> (( )) >>> ? ? >>> >>> On Wed, Sep 6, 2017 at 12:35 PM, ARIN wrote: >>> >>>> The following has been revised: >>>> >>>> * Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for >>>> Inter-RIR Transfers >>>> >>>> Revised text is below and can be found at: >>>> https://www.arin.net/policy/proposals/2017_4.html >>>> >>>> You are encouraged to discuss all Draft Policies on PPML. The AC will >>>> evaluate the discussion in order to assess the conformance of this draft >>>> policy with ARIN's Principles of Internet number resource policy as stated >>>> in the Policy Development Process (PDP). Specifically, these principles are: >>>> >>>> * Enabling Fair and Impartial Number Resource Administration >>>> * Technically Sound >>>> * Supported by the Community >>>> >>>> The PDP can be found at: >>>> https://www.arin.net/policy/pdp.html >>>> >>>> Draft Policies and Proposals under discussion can be found at: >>>> https://www.arin.net/policy/proposals/index.html >>>> >>>> Regards, >>>> >>>> Sean Hopkins >>>> Policy Analyst >>>> American Registry for Internet Numbers (ARIN) >>>> >>>> >>>> >>>> Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR >>>> Transfers >>>> >>>> Version Date: 6 September 2017 >>>> >>>> Problem Statement: >>>> >>>> AFRINIC and LACNIC are currently considering one-way inter-RIR transfer >>>> proposals. Those RIR communities feel a one-way policy a policy that allows >>>> network operators in their regions to obtain space from another region and >>>> transfer it into AFRINIC and LACNIC may best meet the needs of the >>>> operators in that region. >>>> >>>> ARIN staff, in reply to an inquiry from AFRINIC, have formally >>>> indicated that ARINs 8.4 policy language will not allow ARIN to participate >>>> in such one-way transfers. The staff formally indicate to AFRINIC that the >>>> word reciprocal in 8.4 prohibits ARIN from allowing ARIN-registered space >>>> to transfer directly to AFRINIC (in this context). >>>> >>>> ARIN as a community should recognize that other RIR operator >>>> communities have different needs than we do. We should recognize that: >>>> >>>> - network operators in AFRINIC in LACNIC have need to obtain space in >>>> the market; >>>> >>>> - have reasons they think are important to not allow two-way transfers; >>>> and >>>> >>>> - we should understand that the history of the RIR system has led to >>>> LACNIC and AFRINIC having multiple orders of magnitude less IPv4 address >>>> space than ARIN does. >>>> >>>> Policy statement: >>>> >>>> Add the following sentence after the first sentence of NRPM 8.4: >>>> >>>> Inter-RIR transfers may take place to an RIR with a non-reciprocal >>>> inter-RIR transfer policy only when the recipient RIR has an IPv4 total >>>> inventory less than the average (mean) of the IPv4 total inventory among >>>> all of the RIRs. >>>> >>>> Timetable for implementation: Upon the ratification of any inter-RIR >>>> transfer policy at another RIR that is one-way as described in the problem >>>> statement. >>>> _______________________________________________ >>>> 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. >>> >> >> >> >> -- >> =============================================== >> David Farmer Email:farmer at umn.edu >> Networking & Telecommunication Services >> Office of Information Technology >> University of Minnesota >> 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> >> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> >> =============================================== >> > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From narten at us.ibm.com Fri Sep 8 00:53:17 2017 From: narten at us.ibm.com (narten at us.ibm.com) Date: Fri, 08 Sep 2017 00:53:17 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201709080453.v884rHgv032462@rotala.raleigh.ibm.com> Total of 38 messages in the last 7 days. script run at: Fri Sep 8 00:53:12 EDT 2017 Messages | Bytes | Who --------+------+--------+----------+------------------------ 10.53% | 4 | 14.25% | 134606 | owen at delong.com 10.53% | 4 | 12.11% | 114356 | chris at semihuman.com 5.26% | 2 | 12.53% | 118307 | rudi.daniel at gmail.com 7.89% | 3 | 7.62% | 71983 | cja at daydream.com 7.89% | 3 | 6.86% | 64742 | farmer at umn.edu 5.26% | 2 | 7.85% | 74133 | apotter at hilcoglobal.com 7.89% | 3 | 4.60% | 43417 | hostmaster at uneedus.com 5.26% | 2 | 6.75% | 63789 | scottleibrand at gmail.com 7.89% | 3 | 4.08% | 38514 | mike at iptrading.com 2.63% | 1 | 7.21% | 68041 | milton at gatech.edu 5.26% | 2 | 2.49% | 23490 | kevinb at thewire.ca 2.63% | 1 | 3.25% | 30710 | oroberts at bell.ca 2.63% | 1 | 2.74% | 25907 | mwinters at edwardrose.com 2.63% | 1 | 1.82% | 17203 | bjones at vt.edu 2.63% | 1 | 1.06% | 10057 | ndavis at arin.net 2.63% | 1 | 1.06% | 10044 | bill at herrin.us 2.63% | 1 | 0.97% | 9136 | narten at us.ibm.com 2.63% | 1 | 0.96% | 9061 | jcurran at arin.net 2.63% | 1 | 0.94% | 8902 | info at arin.net 2.63% | 1 | 0.84% | 7928 | daveid at panix.com --------+------+--------+----------+------------------------ 100.00% | 38 |100.00% | 944326 | Total From mwinters at edwardrose.com Fri Sep 8 09:04:47 2017 From: mwinters at edwardrose.com (Michael Winters) Date: Fri, 8 Sep 2017 13:04:47 +0000 Subject: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers In-Reply-To: References: <2bc0e7f7-c3d1-c496-1d58-ccec181c6414@arin.net> <0439B09D-AF93-4BC2-97EB-48A10BF753E8@semihuman.com> <18F45FF2-7AC8-4891-B54F-9F135A09AFD4@semihuman.com> Message-ID: <9c99922f005c4545beb2f19f057b4032@kz-mail01.manifold.edwardrosekzoo.com> It seems to me that LACNIC and AfriNIC don?t want you there. If there is such a demand in those regions, then having a bidirectional transfer policy would not hurt them because very few would be transferring out and they would be able to easily get transfers in. The problem is not ARINs policy, it is small dying town thinking on behalf of the LACNIC and AfriNIC communities. Instead of playing the ?IP Privilege? card and relying on ?IP Guilt?, people and organizations that do business in those regions should push those communities to adopt policies that would allow others to transfer in and let the market fix itself. Mike From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Scott Leibrand Sent: Thursday, September 7, 2017 8:07 PM To: Chris Woodfield Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers IMO we're overthinking this. The problem is simply that not all companies can get access to the IP addresses they need to run their businesses. The fix is to enable transfers from ARIN to all other regions, and between as many regions as are willing to participate. Only LACNIC and AfriNIC don't allow such transfers yet, and if we can make it easier for them to allow transfers at least in the important direction (to their regions) then the transfer market will take care of making sure everyone who needs addresses can get them. So any policy, including the draft policy as written, that allows unidirectional transfers to LACNIC and AfriNIC solves the problem. -Scott On Thu, Sep 7, 2017 at 3:19 PM, Chris Woodfield > wrote: Replying to myself, I decided to look up the population proportions mentioned in my last email: North America - 7.79% South America - 5.68% Africa - 16.36% So if one were to use numbers similar to these - the average formula doesn?t make much of a difference for LACNIC, and actually qualifies AFRINIC for a far larger share of space than the straight average. I?m wondering what, if any, types of metrics might exist for measuring demand for resources instead of population? Or does that run afoul of the concept of Internet access as a worldwide human right? -C On Sep 7, 2017, at 2:50 PM, Chris Woodfield > wrote: Thinking more about the use of an average distribution in the proposal, I?m wondering if this accurately reflects the issue. The distribution of IP addresses by IANA to the various RIRs is only inequitable if it results in a clear difference in the ability of an entity in different regions to acquire IP address space. We don?t need the same number of allocations in each region - if nothing else, the allocations should roughly reflect regional populations - but it should be no more difficult for a party in Africa or South America to acquire IPv4 resources than it is for a party in North America, Europe, or Asia to do so. To the extent that this is not the case, we owe the community action to correct. The question then becomes - does the lack of a transfer policy from ARIN to these regions make it substantially more difficult to acquire space on the transfer market today? I?d argue that to the extent that doing so requires transferring to the space to the local RIR, then the answer is YES, as from my point of view, the bulk of transfer market supply is from allocations in the ARIN region (resellers on the list who are in a position to comment, please keep me honest and speak up if that isn?t the case). This is somewhat mitigated by the current case that both LACNIC and AFRINIC still have space to allocate, while ARIN does not. But shower term point-in-time facts shouldn?t drive far-reaching policy decisions IMO. As such, I support the goal of the policy, but I believe that the calculation used to determine qualifying RIRs could be tweaked. Could we compare allocation percentages to world population, perhaps? -C On Sep 7, 2017, at 2:27 PM, Cj Aronson > wrote: David.. I agree with your very well written summary. I just feel that the mathematical formula to determine when the transfers have to start being reciprocal is not needed. The reason why I feel that way is that we're computing something that was said earlier, "To go below the global average, the RIR above the average and closest to it would need to lose 81,871,002 more addresses, which at the current rate (14,592 lost per month) would take 5,620 months (468 years)." It seems like we're spending time computing something that is not likely to happen.. I would surely hope we are done with IPv4 within the next 468 years :-) Thanks! -----Cathy {?,?} (( )) ? ? On Thu, Sep 7, 2017 at 2:46 PM, David Farmer > wrote: Cathy, Yes, in some ways it would be more straight forward to just say LACNIC and AFRINIC are allowed an exception to the reciprocity requirement. However, that policy would contain only the facts of the situation. Whereas this policy contains quantifiable reasoning why LACNIC and AFRINIC are exempted from the reciprocity requirement and why APNIC and RIPE are not. To be honest, I didn't want the reciprocity requirement in the original transfer policy to being with, because of the optics of this very situation with LACNIC and AFRINIC. However, I didn't push the issue with the original transfer policy because I knew it would be several year before LACNIC and AFRINIC got to the point of approving a transfer policy of any kind. So, when this issue with LACNIC and AFRINIC came up I thought obvious thing to do was to eliminate the reciprocity requirement all together. However, I really like this compromise as well as the reasoning that comes with it. There is absolutely no reason for transfers with APNIC and RIPE to not be on a reciprocal basis. However, with LACNIC and AFRINIC I feel there should be room for some nuance. LACNIC and AFRINIC have received the short-end of the stick, so to speak. There was no conspiracy or wrongdoing that caused this result, but it is a stark fact when you look at the numbers. I therefore believe these facts should afford LACNIC and AFRINIC some latitude to decide for themselves how best to move forward. In the long-run I totally believe LACNIC and AFRINIC should approve reciprocal transfer policies. However, we need to give them room to decide this for themselves, it is arrogant and inconsiderate of the facts for us to dictate a reciprocal transfer policy to them. If they feel they need to start with a one-way transfer policy, there is logic to such a strategy, and the current facts seem to justify at least some caution on their part. Finally, the numbers show we have more than enough room to be magnanimous in this situation, I believe we should give LACNIC and AFRINIC room to maneuver, and choose their own way forward. Thanks. On Wed, Sep 6, 2017 at 4:10 PM, Cj Aronson > wrote: Okay so this formula.. does it just give us Afrinic and Lacnic right? So why don't we just say that? Since there are only 5 RIRs it seems that maybe a formula isn't needed? {?,?} (( )) ? ? On Wed, Sep 6, 2017 at 12:35 PM, ARIN > wrote: The following has been revised: * Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers Revised text is below and can be found at: https://www.arin.net/policy/proposals/2017_4.html You are encouraged to discuss all Draft Policies on PPML. The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet number resource policy as stated in the Policy Development Process (PDP). Specifically, these principles are: * Enabling Fair and Impartial Number Resource Administration * Technically Sound * Supported by the Community The PDP can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Sean Hopkins Policy Analyst American Registry for Internet Numbers (ARIN) Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers Version Date: 6 September 2017 Problem Statement: AFRINIC and LACNIC are currently considering one-way inter-RIR transfer proposals. Those RIR communities feel a one-way policy a policy that allows network operators in their regions to obtain space from another region and transfer it into AFRINIC and LACNIC may best meet the needs of the operators in that region. ARIN staff, in reply to an inquiry from AFRINIC, have formally indicated that ARINs 8.4 policy language will not allow ARIN to participate in such one-way transfers. The staff formally indicate to AFRINIC that the word reciprocal in 8.4 prohibits ARIN from allowing ARIN-registered space to transfer directly to AFRINIC (in this context). ARIN as a community should recognize that other RIR operator communities have different needs than we do. We should recognize that: - network operators in AFRINIC in LACNIC have need to obtain space in the market; - have reasons they think are important to not allow two-way transfers; and - we should understand that the history of the RIR system has led to LACNIC and AFRINIC having multiple orders of magnitude less IPv4 address space than ARIN does. Policy statement: Add the following sentence after the first sentence of NRPM 8.4: Inter-RIR transfers may take place to an RIR with a non-reciprocal inter-RIR transfer policy only when the recipient RIR has an IPv4 total inventory less than the average (mean) of the IPv4 total inventory among all of the RIRs. Timetable for implementation: Upon the ratification of any inter-RIR transfer policy at another RIR that is one-way as described in the problem statement. _______________________________________________ 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. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. ________________________________ ________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From daveid at panix.com Fri Sep 8 10:09:09 2017 From: daveid at panix.com (David R Huberman) Date: Fri, 8 Sep 2017 10:09:09 -0400 (EDT) Subject: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity In-Reply-To: <9c99922f005c4545beb2f19f057b4032@kz-mail01.manifold.edwardrosekzoo.com> References: <2bc0e7f7-c3d1-c496-1d58-ccec181c6414@arin.net> <0439B09D-AF93-4BC2-97EB-48A10BF753E8@semihuman.com> <18F45FF2-7AC8-4891-B54F-9F135A09AFD4@semihuman.com> <9c99922f005c4545beb2f19f057b4032@kz-mail01.manifold.edwardrosekzoo.com> Message-ID: ARIN-based network operators who are responsible for multi-continent IP networks need to be able to move ARIN-registered numbers from ARIN to LACNIC and AFRINIC for our datacenters in those regions. This need is to allow us to achieve legal compliance and network engineering goals. This draft policy meets that need, has safeguards against imbalance, and is respectful of the wishes of two RIR communities. Quoting David Farmer: "In the long-run I totally believe LACNIC and AFRINIC should approve reciprocal transfer policies. However, we need to give them room to decide this for themselves, it is arrogant and inconsiderate of the facts for us to dictate a reciprocal transfer policy to them. If they feel they need to start with a one-way transfer policy, there is logic to such a strategy, and the current facts seem to justify at least some caution on their part." From theone at uneedus.com Fri Sep 8 10:22:34 2017 From: theone at uneedus.com (theone at uneedus.com) Date: Fri, 8 Sep 2017 10:22:34 -0400 (EDT) Subject: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity In-Reply-To: References: <2bc0e7f7-c3d1-c496-1d58-ccec181c6414@arin.net> <0439B09D-AF93-4BC2-97EB-48A10BF753E8@semihuman.com> <18F45FF2-7AC8-4891-B54F-9F135A09AFD4@semihuman.com> <9c99922f005c4545beb2f19f057b4032@kz-mail01.manifold.edwardrosekzoo.com> Message-ID: Since AFRINIC still has a general free pool, why is not getting addresses directly from that RIR for use in that region not an option? With no current resources in that area, it should be easy to get an initial allocation, just like the old days.... Also, why cannot we consider a policy that allows the same operator to transfer between regions, without opening up the policy to the general transfer market? I see fewer problems with a transfer to another RIR, as long as the entity at each end of the transfer is the same. It is when we open up one way transfers between non related entities is where I see the issue for abuse. Albert Erdmann Network Administrator Paradise On Line Inc. On Fri, 8 Sep 2017, David R Huberman wrote: > > ARIN-based network operators who are responsible for multi-continent IP > networks need to be able to move ARIN-registered numbers from ARIN to LACNIC > and AFRINIC for our datacenters in those regions. This need is to allow us > to achieve legal compliance and network engineering goals. > > This draft policy meets that need, has safeguards against imbalance, and is > respectful of the wishes of two RIR communities. Quoting David Farmer: > > "In the long-run I totally believe LACNIC and AFRINIC should approve > reciprocal transfer policies. However, we need to give them room to decide > this for themselves, it is arrogant and inconsiderate of the facts for us to > dictate a reciprocal transfer policy to them. If they feel they need to > start with a one-way transfer policy, there is logic to such a strategy, and > the current facts seem to justify at least some caution on their part." > _______________________________________________ > 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 daveid at panix.com Fri Sep 8 10:52:33 2017 From: daveid at panix.com (David R Huberman) Date: Fri, 8 Sep 2017 10:52:33 -0400 (EDT) Subject: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity In-Reply-To: References: <2bc0e7f7-c3d1-c496-1d58-ccec181c6414@arin.net> <0439B09D-AF93-4BC2-97EB-48A10BF753E8@semihuman.com> <18F45FF2-7AC8-4891-B54F-9F135A09AFD4@semihuman.com> <9c99922f005c4545beb2f19f057b4032@kz-mail01.manifold.edwardrosekzoo.com> Message-ID: > Since AFRINIC still has a general free pool, why is not getting > addresses directly from that RIR for use in that region not an option? AFRINIC is in its last /8. By the time any ARIN policy makes it to implementation, your fact will be less true or possibly not true at all. Trying to plan for the future here :) > Also, why cannot we consider a policy that allows the same operator to > transfer between regions, without opening up the policy to the general > transfer market? > > I see fewer problems with a transfer to another RIR, as long as the > entity at each end of the transfer is the same. It is when we open up > one way transfers between non related entities is where I see the issue > for abuse. So I get what you're saying, but I have to ask: how is this idea better for network operations? As engineers, shouldn't we be striving to ensure that operators who need resources have access to those resources, and put political stuff secondary? From mwinters at edwardrose.com Fri Sep 8 11:54:22 2017 From: mwinters at edwardrose.com (Michael Winters) Date: Fri, 8 Sep 2017 15:54:22 +0000 Subject: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity In-Reply-To: References: <2bc0e7f7-c3d1-c496-1d58-ccec181c6414@arin.net> <0439B09D-AF93-4BC2-97EB-48A10BF753E8@semihuman.com> <18F45FF2-7AC8-4891-B54F-9F135A09AFD4@semihuman.com> <9c99922f005c4545beb2f19f057b4032@kz-mail01.manifold.edwardrosekzoo.com> Message-ID: <6f9106a54ace45a9a11a9202784acbe1@kz-mail01.manifold.edwardrosekzoo.com> Yes, so tell AfriNIC to stop being political and adopt an open policy and it will be able to get addresses transferred in. Trying to change ARIN's policy which supports an open market to accommodate there closed unilateral policy is being political. >So I get what you're saying, but I have to ask: how is this idea better for network operations? As engineers, shouldn't we be striving to ensure that operators who >need resources have access to those resources, and put political stuff secondary? ________________________ From daveid at panix.com Fri Sep 8 12:09:59 2017 From: daveid at panix.com (David R Huberman) Date: Fri, 8 Sep 2017 12:09:59 -0400 (EDT) Subject: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity In-Reply-To: <6f9106a54ace45a9a11a9202784acbe1@kz-mail01.manifold.edwardrosekzoo.com> References: <2bc0e7f7-c3d1-c496-1d58-ccec181c6414@arin.net> <0439B09D-AF93-4BC2-97EB-48A10BF753E8@semihuman.com> <18F45FF2-7AC8-4891-B54F-9F135A09AFD4@semihuman.com> <9c99922f005c4545beb2f19f057b4032@kz-mail01.manifold.edwardrosekzoo.com> <6f9106a54ace45a9a11a9202784acbe1@kz-mail01.manifold.edwardrosekzoo.com> Message-ID: > Yes, so tell AfriNIC to stop being political and adopt an open policy > and it will be able to get addresses transferred in. We have been trying for years. I presented a Inter-RIR transfer policy three times at LACNIC, in 2014 and 2015. Mike Burns in this thread presented an Inter-RIR transfer policy at the most recent LACNIC meeting. Many (quite a lot of us) participating in this thread have been involved in the AFRINIC discussions. "That dog don't hunt" is my response to what you're saying, and my response is borne of four years of first-hand policy development work at these RIRs. From bill at herrin.us Fri Sep 8 13:22:57 2017 From: bill at herrin.us (William Herrin) Date: Fri, 8 Sep 2017 13:22:57 -0400 Subject: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity In-Reply-To: References: <2bc0e7f7-c3d1-c496-1d58-ccec181c6414@arin.net> <0439B09D-AF93-4BC2-97EB-48A10BF753E8@semihuman.com> <18F45FF2-7AC8-4891-B54F-9F135A09AFD4@semihuman.com> <9c99922f005c4545beb2f19f057b4032@kz-mail01.manifold.edwardrosekzoo.com> <6f9106a54ace45a9a11a9202784acbe1@kz-mail01.manifold.edwardrosekzoo.com> Message-ID: On Fri, Sep 8, 2017 at 12:09 PM, David R Huberman wrote: > > Yes, so tell AfriNIC to stop being political and adopt an open policy and >> it will be able to get addresses transferred in. >> > > We have been trying for years. I presented a Inter-RIR transfer policy > three times at LACNIC, in 2014 and 2015. Mike Burns in this thread > presented an Inter-RIR transfer policy at the most recent LACNIC meeting. > Many (quite a lot of us) participating in this thread have been involved in > the AFRINIC discussions. > > "That dog don't hunt" is my response to what you're saying, and my > response is borne of four years of first-hand policy development work at > these RIRs. Hi David, Parts of Africa choose to starve rather than accept the import of GMO food products from the U.S. This is not the US's problem, nor should it be. I believe the correct proverb is, "beggars can't be choosers." Regards, Bill Herrin -- William Herrin ................ herrin at dirtside.com bill at herrin.us Dirtside Systems ......... Web: -------------- next part -------------- An HTML attachment was scrubbed... URL: From daveid at panix.com Fri Sep 8 13:27:10 2017 From: daveid at panix.com (David R Huberman) Date: Fri, 8 Sep 2017 13:27:10 -0400 (EDT) Subject: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity In-Reply-To: References: <2bc0e7f7-c3d1-c496-1d58-ccec181c6414@arin.net> <0439B09D-AF93-4BC2-97EB-48A10BF753E8@semihuman.com> <18F45FF2-7AC8-4891-B54F-9F135A09AFD4@semihuman.com> <9c99922f005c4545beb2f19f057b4032@kz-mail01.manifold.edwardrosekzoo.com> <6f9106a54ace45a9a11a9202784acbe1@kz-mail01.manifold.edwardrosekzoo.com> Message-ID: > Parts of Africa choose to starve rather than accept the import of GMO > food products from the U.S. This is not the US's problem, nor should it > be. I believe the correct proverb is, "beggars can't be choosers." Bill, I framed the root motivation of the draft policy as: "ARIN-based network operators who are responsible for multi-continent IP networks need to be able to move ARIN-registered numbers from ARIN to LACNIC and AFRINIC for our datacenters in those regions. This need is to allow us to achieve legal compliance and network engineering goals." From mwinters at edwardrose.com Fri Sep 8 15:45:19 2017 From: mwinters at edwardrose.com (Michael Winters) Date: Fri, 8 Sep 2017 19:45:19 +0000 Subject: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity In-Reply-To: References: <2bc0e7f7-c3d1-c496-1d58-ccec181c6414@arin.net> <0439B09D-AF93-4BC2-97EB-48A10BF753E8@semihuman.com> <18F45FF2-7AC8-4891-B54F-9F135A09AFD4@semihuman.com> <9c99922f005c4545beb2f19f057b4032@kz-mail01.manifold.edwardrosekzoo.com> <6f9106a54ace45a9a11a9202784acbe1@kz-mail01.manifold.edwardrosekzoo.com> Message-ID: <054284bb223d402f85434b4d8ae78765@kz-mail01.manifold.edwardrosekzoo.com> Serious question, what legal compliance requirements are there to use ARIN addresses in LACNIC or AfriNIC? -----Original Message----- From: David R Huberman [mailto:daveid at panix.com] Sent: Friday, September 8, 2017 1:27 PM To: William Herrin Cc: Michael Winters ; arin-ppml at arin.net Subject: Re: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity > Parts of Africa choose to starve rather than accept the import of GMO > food products from the U.S. This is not the US's problem, nor should > it be. I believe the correct proverb is, "beggars can't be choosers." Bill, I framed the root motivation of the draft policy as: "ARIN-based network operators who are responsible for multi-continent IP networks need to be able to move ARIN-registered numbers from ARIN to LACNIC and AFRINIC for our datacenters in those regions. This need is to allow us to achieve legal compliance and network engineering goals." ________________________ ________________________ From daveid at panix.com Fri Sep 8 16:04:22 2017 From: daveid at panix.com (David Huberman) Date: Fri, 8 Sep 2017 16:04:22 -0400 Subject: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity In-Reply-To: <054284bb223d402f85434b4d8ae78765@kz-mail01.manifold.edwardrosekzoo.com> References: <2bc0e7f7-c3d1-c496-1d58-ccec181c6414@arin.net> <0439B09D-AF93-4BC2-97EB-48A10BF753E8@semihuman.com> <18F45FF2-7AC8-4891-B54F-9F135A09AFD4@semihuman.com> <9c99922f005c4545beb2f19f057b4032@kz-mail01.manifold.edwardrosekzoo.com> <6f9106a54ace45a9a11a9202784acbe1@kz-mail01.manifold.edwardrosekzoo.com> <054284bb223d402f85434b4d8ae78765@kz-mail01.manifold.edwardrosekz oo.com> Message-ID: <0703529B-C2D8-4D5B-AC56-AF9D38F592FF@panix.com> In some countries, data sovereignty laws require all assets to be owned by an in country entity. A best practice for compliance is to register to the in country subsidiary and have that duly registered in the RIR. Doing it this way also gives you preferential treatment under data transport laws in some countries. In other countries, to obtain transit of your route announcements, the prefixes must be registered in the local RIR or NIR. Sent from my iPhone > On Sep 8, 2017, at 3:45 PM, Michael Winters wrote: > > Serious question, what legal compliance requirements are there to use ARIN addresses in LACNIC or AfriNIC? > > -----Original Message----- > From: David R Huberman [mailto:daveid at panix.com] > Sent: Friday, September 8, 2017 1:27 PM > To: William Herrin > Cc: Michael Winters ; arin-ppml at arin.net > Subject: Re: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity > >> Parts of Africa choose to starve rather than accept the import of GMO >> food products from the U.S. This is not the US's problem, nor should >> it be. I believe the correct proverb is, "beggars can't be choosers." > > Bill, I framed the root motivation of the draft policy as: > > "ARIN-based network operators who are responsible for multi-continent IP networks need to be able to move ARIN-registered numbers from ARIN to LACNIC and AFRINIC for our datacenters in those regions. This need is to allow us to achieve legal compliance and network engineering goals." > > > ________________________ > > > ________________________ > From owen at delong.com Fri Sep 8 23:17:57 2017 From: owen at delong.com (Owen DeLong) Date: Fri, 8 Sep 2017 20:17:57 -0700 Subject: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers In-Reply-To: References: <2bc0e7f7-c3d1-c496-1d58-ccec181c6414@arin.net> <6AC63D0C-6E34-432C-B499-347F0A3895C4@delong.com> Message-ID: <88EA0C94-D595-4FD7-86D2-22FC1290CB4F@delong.com> > On Sep 7, 2017, at 12:23 , hostmaster at uneedus.com wrote: > > The reason that those early class A holders received such a large block was simply the fact that CIDR did not exist at the time, and therefore there were only 3 possible values of address blocks you could receive, /8, /16 and /24. Clearly most of the original class A holders had plans to (and many still do) have more than 65536 devices, therefore being too large for a class B. In these days neither NAT or CIDR were a thing. I wasn?t making value judgments about the reasoning of the time, simply stating the historical fact of the matter. I lived much of this history and am not in any way condemning the choices of the time. Each and every one made sense at the time in the environment as it existed, including typing passwords into devices in clear text via telnet. Things are definitely different today in many ways. > You state that 4) is not entirely accurate, but I can find nothing that actually stated in policy that certain regions of the world were to receive less IPv4 resources than other portions. Of course since there were not large entities in Latin America or Africa requesting resources similar to MIT and others, we really do not know if resources would have been given out on the same basis. Had an actual request been made, and denied, that is a different story than we have here. I believe that ARIN and APNIC did, in fact, refer entities in the portions of the future LACNIC and/or AfriNIC regions that they didn?t serve at the time to the appropriate RIR at the time. While there was no policy to deny the requests, there were different territorial definitions and the policies for obtaining address space did vary from RIR to RIR. Some of the minima that existed for some time in ARIN made it quite difficult for entities in Africa and the Caribbean to qualify for address space from ARIN as an example. While it wasn?t geographical, there was size-based discrimination that had a stronger impact on some geographies than others. > In any case, had there been any large networks from these regions, they could have received address space they could justify from the free pool until it went away in 2011. However, like today these areas are clearly less served than other regions like ARIN and APNIC, and connectivity is often an issue as well. Should you have to be a large network to qualify for space from an RIR? Even if you are a network operating in a region where the economics of network operations and the region at the time precluded any such possibility? > I believe that the only way the market of "highest and best use" for IPv4 addresses in a free market until everyone finally goes 100% to IPv6 is if all IPv4 addresses are subject to that market. I think that ARIN should not release addresses from this region to any region that has a one way policy, as it prevents the market of addresses from working. I also see a limit on how high address cost can go, as at some price point someone will simply say, "forget it, lets go v6?. On this, we agree. If we can determine that price, then I vote we immediately make that the minimum RIR charge for a transfer and move on. ;-) Owen > > Albert Erdmann > Network Administrator > Paradise On Line Inc. > > > On Thu, 7 Sep 2017, Owen DeLong wrote: > >> Timeline is a bit off? >> >> Originally there was Jon Postel?s notebook. That passed to SRI and later evolved into InterNIC. >> >> RIPE and APNIC were created and handed parts of the responsibility prior to the formation of ARIN. >> >> ARIN remained ?registry of last resort? until the formation of LACNIC and later AfriNIC. >> >> The ERX and other transfer processes were a bit more complicated, but essentially you have the right general idea. >> >> I think that statement 4 is likely not entirely historically accurate. >> >> Early distribution of IPv4 addresses was significantly more generous than later distribution (companies like Apple and HP, Universities like MIT, and others easily got /8s just for the asking, organizations of any significant size could easily request and receive /16s, etc.). >> >> Otherwise, I think you generally have it right. >> >> Owen >> >>> On Sep 6, 2017, at 15:10 , hostmaster at uneedus.com wrote: >>> >>> Now that discussion reveals that "IPv4 Inventory", refers to the total number of IPv4 addresses that a specific RIR has under its management, and not the amount of IPv4 addresses remaining for assignment, I will state the problems I see with the proposal. However, I remain open minded and am asking questions in order to make up my mind. >>> >>> If any of the history of numbering management that I state below is wrong, please let me know, as it might change my viewpoint. >>> >>> 1) Originally there was effectively only one RIR worldwide. >>> >>> 2) This original RIR's Resources were placed under control of ARIN. >>> >>> 3) When each of the RIR's other than ARIN were formed, all resources that were assigned to entities within the region of the new RIR, that were under management of ARIN, or the RIR which previously managed the space (RIPE to AFRINIC in that case) were transfered to the new RIR. >>> >>> 4) The Previous RIR's who controled resources before the formation of LACNIC or AFRINIC did not have a policy in place that discriminated against any portion of the world, and would if presented with a request for IPv4 resources, would process that request using the same policy that was used for resources assigned in the remaining portions of that RIR's Territory. >>> >>> With each of these things said, I now draw some conclusions. Specifically, it is not North America's or ARIN's fault that LACNIC and AFRINIC has less resources under management than ARIN or RIPE or APNIC. Had networks needing resources existed during this time, and all the way past their formation up until that date that IANA ran out of /8's, that RIR could have received IPv4 addresses from the free pool on an equal basis. While the original Class A networks were given out a lot more loosely than ARIN's standards, this did not change the fact that IANA had a free pool after these original Class A networks were assigned, and did provide additional /8's to any RIR who could show that they had exhausted their free pool below the standard that was applied to all 5 RIR's. >>> >>> In my opinion the only reason that LACNIC and AFRINIC did not have as many /8's, was the growth in the APNIC region compared to all other regions, which during that time exceeded every other RIR, including ARIN. In fact, it was APNIC's request for more space that triggered the exhaustion of the free pool. Technically, when LACNIC and AFRINIC received their final /8, it was not totally fair to the other RIR's with more addresses under management. In fact, this final non proportional oversupply at AFRINIC is likely the only reason that AFRINIC is the only RIR with a general free pool. Instead of a full /8 to each region, maybe this should have been done more proportional to each region's total address space under management. >>> >>> For a market based solution to IPv4 addresses, addresses need to be able to flow both ways. AFRINIC and LACNIC can argue that we are the small guys, and we need to be protected against transfers out. However, I can just as easily argue that ARIN is being used as a worldwide piggy bank of IPv4 addresses and should also adopt an anti-transfer out policy. As long as things move both ways, we can argue that the market effect is important, but for this to work, it must be bidirectional everywhere. While ARIN is the leader in supplying directed transfer addresses, market conditions could change worldwide, causing more transfers from another RIR. For an example, say if China were to require ALL internet to use IPv6, and forbid the use of IPv4 in their country, a large number of IPv4 addresses allocated to China would suddenly be available on the transfer market. >>> >>> Some similar event that is now unknown could drive the IPv4 addresses of the LACNIC and AFRINIC into the market, and if this policy were adopted would be unfair to the markets that would be forbidden from these addresses being in the market because of the lack of a bidirectional transfer rule. >>> >>> My gut tells me that noone should get a pass on bidirectional transfers, and I am leaning NO at this time, but could be convinced otherwise for the proper reason. I do not think "Past Discrimination" is that reason. The true past problem was lack of past network growth, vs other regions. >>> >>> Albert Erdmann >>> Network Administrator >>> Paradise On Line Inc. >>> >>> >>> >>> On Wed, 6 Sep 2017, ARIN wrote: >>> >>>> The following has been revised: >>>> >>>> * Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers >>>> >>>> Revised text is below and can be found at: >>>> https://www.arin.net/policy/proposals/2017_4.html >>>> >>>> You are encouraged to discuss all Draft Policies on PPML. The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet number resource policy as stated in the Policy Development Process (PDP). Specifically, these principles are: >>>> >>>> * Enabling Fair and Impartial Number Resource Administration >>>> * Technically Sound >>>> * Supported by the Community >>>> >>>> The PDP can be found at: >>>> https://www.arin.net/policy/pdp.html >>>> >>>> Draft Policies and Proposals under discussion can be found at: >>>> https://www.arin.net/policy/proposals/index.html >>>> >>>> Regards, >>>> >>>> Sean Hopkins >>>> Policy Analyst >>>> American Registry for Internet Numbers (ARIN) >>>> >>>> >>>> >>>> Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers >>>> >>>> Version Date: 6 September 2017 >>>> >>>> Problem Statement: >>>> >>>> AFRINIC and LACNIC are currently considering one-way inter-RIR transfer proposals. Those RIR communities feel a one-way policy a policy that allows network operators in their regions to obtain space from another region and transfer it into AFRINIC and LACNIC may best meet the needs of the operators in that region. >>>> >>>> ARIN staff, in reply to an inquiry from AFRINIC, have formally indicated that ARINs 8.4 policy language will not allow ARIN to participate in such one-way transfers. The staff formally indicate to AFRINIC that the word reciprocal in 8.4 prohibits ARIN from allowing ARIN-registered space to transfer directly to AFRINIC (in this context). >>>> >>>> ARIN as a community should recognize that other RIR operator communities have different needs than we do. We should recognize that: >>>> >>>> - network operators in AFRINIC in LACNIC have need to obtain space in the market; >>>> >>>> - have reasons they think are important to not allow two-way transfers; and >>>> >>>> - we should understand that the history of the RIR system has led to LACNIC and AFRINIC having multiple orders of magnitude less IPv4 address space than ARIN does. >>>> >>>> Policy statement: >>>> >>>> Add the following sentence after the first sentence of NRPM 8.4: >>>> >>>> Inter-RIR transfers may take place to an RIR with a non-reciprocal inter-RIR transfer policy only when the recipient RIR has an IPv4 total inventory less than the average (mean) of the IPv4 total inventory among all of the RIRs. >>>> >>>> Timetable for implementation: Upon the ratification of any inter-RIR transfer policy at another RIR that is one-way as described in the problem statement. >>>> _______________________________________________ >>>> PPML >>>> You are receiving this message because you are subscribed to >>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>>> Unsubscribe or manage your mailing list subscription at: >>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>> Please contact info at arin.net if you experience any issues. >>>> >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to >>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at arin.net if you experience any issues. >> From owen at delong.com Fri Sep 8 23:19:41 2017 From: owen at delong.com (Owen DeLong) Date: Fri, 8 Sep 2017 20:19:41 -0700 Subject: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers In-Reply-To: References: <2bc0e7f7-c3d1-c496-1d58-ccec181c6414@arin.net> <7E7773B523E82C478734E793E58F69E7A52773A8@SBS2011.thewireinc.local> <9D9CAE4C-0723-4F15-A543-AE368EFD8C97@delong.com> Message-ID: <5E7CEE50-A832-477F-9E93-34BA779F66EF@delong.com> If they allow bidirectional transfers, then this would be moot because the reciprocity requirement would no longer block anything and this change would be a no-op. However, yes, within those regions, there is significant pandering to a vocal minority that is afraid of space leaving their region due to deeper pockets elsewhere. Owen > On Sep 7, 2017, at 12:31 , Chris Woodfield wrote: > > Which leads to the question as to why? a policy proposal to allow for outbound transfers as well as inbound in those regions would render this policy moot. Is there any sense of the appetite for such a proposal in either region, or would it be perceived as having the potential to result in even more IP space leaving those regions (due to deeper pockets in the transfer market in other regions)? > > -C > >> On Sep 7, 2017, at 11:25 AM, Owen DeLong wrote: >> >> Neither LACNIC nor AfriNIC have currently passed or implemented an inter-RIR transfer policy. >> >> All Inter-RIR policies that have been considered in either region have been unilateral inbound-only to the best of my knowledge. >> >> Owen >> >>> On Sep 7, 2017, at 05:30 , Kevin Blumberg wrote: >>> >>> Are there active polices in the other regions that rely on this policy? I understand there have been discussions, however I don't know what the status is/was. >>> >>> Thanks, >>> >>> Kevin Blumberg >>> >>> >>> >>> -----Original Message----- >>> From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN >>> Sent: Wednesday, September 6, 2017 2:36 PM >>> To: arin-ppml at arin.net >>> Subject: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers >>> >>> The following has been revised: >>> >>> * Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers >>> >>> Revised text is below and can be found at: >>> https://www.arin.net/policy/proposals/2017_4.html >>> >>> You are encouraged to discuss all Draft Policies on PPML. The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet number resource policy as stated in the Policy Development Process (PDP). Specifically, these principles are: >>> >>> * Enabling Fair and Impartial Number Resource Administration >>> * Technically Sound >>> * Supported by the Community >>> >>> The PDP can be found at: >>> https://www.arin.net/policy/pdp.html >>> >>> Draft Policies and Proposals under discussion can be found at: >>> https://www.arin.net/policy/proposals/index.html >>> >>> Regards, >>> >>> Sean Hopkins >>> Policy Analyst >>> American Registry for Internet Numbers (ARIN) >>> >>> >>> >>> Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers >>> >>> Version Date: 6 September 2017 >>> >>> Problem Statement: >>> >>> AFRINIC and LACNIC are currently considering one-way inter-RIR transfer proposals. Those RIR communities feel a one-way policy a policy that allows network operators in their regions to obtain space from another region and transfer it into AFRINIC and LACNIC may best meet the needs of the operators in that region. >>> >>> ARIN staff, in reply to an inquiry from AFRINIC, have formally indicated that ARINs 8.4 policy language will not allow ARIN to participate in such one-way transfers. The staff formally indicate to AFRINIC that the word reciprocal in 8.4 prohibits ARIN from allowing ARIN-registered space to transfer directly to AFRINIC (in this context). >>> >>> ARIN as a community should recognize that other RIR operator communities have different needs than we do. We should recognize that: >>> >>> - network operators in AFRINIC in LACNIC have need to obtain space in the market; >>> >>> - have reasons they think are important to not allow two-way transfers; and >>> >>> - we should understand that the history of the RIR system has led to LACNIC and AFRINIC having multiple orders of magnitude less IPv4 address space than ARIN does. >>> >>> Policy statement: >>> >>> Add the following sentence after the first sentence of NRPM 8.4: >>> >>> Inter-RIR transfers may take place to an RIR with a non-reciprocal inter-RIR transfer policy only when the recipient RIR has an IPv4 total inventory less than the average (mean) of the IPv4 total inventory among all of the RIRs. >>> >>> Timetable for implementation: Upon the ratification of any inter-RIR transfer policy at another RIR that is one-way as described in the problem statement. >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at arin.net if you experience any issues. >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to >>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at arin.net if you experience any issues. >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> > From owen at delong.com Fri Sep 8 23:46:28 2017 From: owen at delong.com (Owen DeLong) Date: Fri, 8 Sep 2017 20:46:28 -0700 Subject: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers In-Reply-To: References: <2bc0e7f7-c3d1-c496-1d58-ccec181c6414@arin.net> Message-ID: <58918650-9D59-406C-9E55-D601334EE558@delong.com> > On Sep 7, 2017, at 13:46 , David Farmer wrote: > > Cathy, > > Yes, in some ways it would be more straight forward to just say LACNIC and AFRINIC are allowed an exception to the reciprocity requirement. However, that policy would contain only the facts of the situation. Whereas this policy contains quantifiable reasoning why LACNIC and AFRINIC are exempted from the reciprocity requirement and why APNIC and RIPE are not. Actually, if you wanted to do that, I think you?d have somehow account for population differences between the various regions served as I think there is a radically different fraction of the population of earth in each of the RIR?s service regions. Since APNIC includes both China (1.37 bn) and India (1.28 bn) and in fact 18 of the top 100 countries by population, I?m pretty sure it is well ahead of most of the others. The number 3 nation on the list is the US at 328 Mil. By the time you get to 14, you?re looking at populations under 100 Mil. Of the top 15, we have: APNIC: 8 (CN, IN, ID, PK, BD, JP, PH, VN) , ARIN: 1 (US), AfriNIC: 3 (NG, ET, EG) , RIPE: 1 (RU), LACNIC: 2 (MX, BR). > To be honest, I didn't want the reciprocity requirement in the original transfer policy to being with, because of the optics of this very situation with LACNIC and AFRINIC. However, I didn't push the issue with the original transfer policy because I knew it would be several year before LACNIC and AFRINIC got to the point of approving a transfer policy of any kind. So, when this issue with LACNIC and AFRINIC came up I thought obvious thing to do was to eliminate the reciprocity requirement all together. However, I really like this compromise as well as the reasoning that comes with it. For many of the same reasons, I oppose this policy. That?s fine, men of good conscience can look at the same set of facts and draw different conclusions in good faith. > There is absolutely no reason for transfers with APNIC and RIPE to not be on a reciprocal basis. However, with LACNIC and AFRINIC I feel there should be room for some nuance. LACNIC and AFRINIC have received the short-end of the stick, so to speak. There was no conspiracy or wrongdoing that caused this result, but it is a stark fact when you look at the numbers. I therefore believe these facts should afford LACNIC and AFRINIC some latitude to decide for themselves how best to move forward. LACNIC and AfriNIC for a variety of reasons are late to the party for IPv4. I will venture to say that I have spent as much time working with and in the AfriNIC region as any other member of the AC, possibly more. I will also venture to say that I have a pretty good understanding of the network situation in the LACNIC region. The reality is that if we permit a unilateral transfer policy, we are, in fact, encouraging them to disable their networks with an even larger IPv4 legacy and greater IPv4 technical debt. > In the long-run I totally believe LACNIC and AFRINIC should approve reciprocal transfer policies. However, we need to give them room to decide this for themselves, it is arrogant and inconsiderate of the facts for us to dictate a reciprocal transfer policy to them. If they feel they need to start with a one-way transfer policy, there is logic to such a strategy, and the current facts seem to justify at least some caution on their part. We aren?t dictating anything to them. We are saying that if they want access to the addresses currently in this region, then it has to be on an equal footing with an equivalent bilateral policy. I see nothing arrogant or unfair about that and claiming that it is flies in the face of the facts of the matter. > Finally, the numbers show we have more than enough room to be magnanimous in this situation, I believe we should give LACNIC and AFRINIC room to maneuver, and choose their own way forward. They are perfectly free to choose whatever way forward they wish to choose without any changes in ARIN policy. Owen > > Thanks. > > On Wed, Sep 6, 2017 at 4:10 PM, Cj Aronson > wrote: > Okay so this formula.. does it just give us Afrinic and Lacnic right? So why don't we just say that? Since there are only 5 RIRs it seems that maybe a formula isn't needed? > > > {?,?} > (( )) > ? ? > > On Wed, Sep 6, 2017 at 12:35 PM, ARIN > wrote: > The following has been revised: > > * Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers > > Revised text is below and can be found at: > https://www.arin.net/policy/proposals/2017_4.html > > You are encouraged to discuss all Draft Policies on PPML. The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet number resource policy as stated in the Policy Development Process (PDP). Specifically, these principles are: > > * Enabling Fair and Impartial Number Resource Administration > * Technically Sound > * Supported by the Community > > The PDP can be found at: > https://www.arin.net/policy/pdp.html > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > Regards, > > Sean Hopkins > Policy Analyst > American Registry for Internet Numbers (ARIN) > > > > Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers > > Version Date: 6 September 2017 > > Problem Statement: > > AFRINIC and LACNIC are currently considering one-way inter-RIR transfer proposals. Those RIR communities feel a one-way policy a policy that allows network operators in their regions to obtain space from another region and transfer it into AFRINIC and LACNIC may best meet the needs of the operators in that region. > > ARIN staff, in reply to an inquiry from AFRINIC, have formally indicated that ARINs 8.4 policy language will not allow ARIN to participate in such one-way transfers. The staff formally indicate to AFRINIC that the word reciprocal in 8.4 prohibits ARIN from allowing ARIN-registered space to transfer directly to AFRINIC (in this context). > > ARIN as a community should recognize that other RIR operator communities have different needs than we do. We should recognize that: > > - network operators in AFRINIC in LACNIC have need to obtain space in the market; > > - have reasons they think are important to not allow two-way transfers; and > > - we should understand that the history of the RIR system has led to LACNIC and AFRINIC having multiple orders of magnitude less IPv4 address space than ARIN does. > > Policy statement: > > Add the following sentence after the first sentence of NRPM 8.4: > > Inter-RIR transfers may take place to an RIR with a non-reciprocal inter-RIR transfer policy only when the recipient RIR has an IPv4 total inventory less than the average (mean) of the IPv4 total inventory among all of the RIRs. > > Timetable for implementation: Upon the ratification of any inter-RIR transfer policy at another RIR that is one-way as described in the problem statement. > _______________________________________________ > 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. > > > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =============================================== > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Fri Sep 8 23:54:30 2017 From: owen at delong.com (Owen DeLong) Date: Fri, 8 Sep 2017 20:54:30 -0700 Subject: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers In-Reply-To: References: <2bc0e7f7-c3d1-c496-1d58-ccec181c6414@arin.net> <0439B09D-AF93-4BC2-97EB-48A10BF753E8@semihuman.com> <18F45FF2-7AC8-4891-B54F-9F135A09AFD4@semihuman.com> Message-ID: > On Sep 7, 2017, at 17:06 , Scott Leibrand wrote: > > IMO we're overthinking this. The problem is simply that not all companies can get access to the IP addresses they need to run their businesses. This simply isn?t true. The problem is limited only to IPv4 addresses. There is no shortage of IP addresses in any region. > The fix is to enable transfers from ARIN to all other regions, and between as many regions as are willing to participate. This is laughable. There are 7 billion people on the planet. There are a total of 3.2 billion unicast addresses in the total IPv4 space. No matter how you shift around the shell game here, you?re still short by half the world population of even being able to give each person a single IPv4 address. It doesn?t matter how you move things around, IPv4 simply doesn?t scale to a global internet. It was never intended to do so. The only fix is to go to a protocol (e.g. IPv6) that has a large enough address space to actually run a global network. > Only LACNIC and AfriNIC don't allow such transfers yet, and if we can make it easier for them to allow transfers at least in the important direction (to their regions) then the transfer market will take care of making sure everyone who needs addresses can get them. So any policy, including the draft policy as written, that allows unidirectional transfers to LACNIC and AfriNIC solves the problem. Why are transfers to their regions (the largest remaining free pools) the important direction? This seems utterly illogical to me in the face of current facts. No policy will solve the actual problem short of a policy that somehow gets everyone to IPv6 faster (and believe me, if I thought that were possible in policy, I?d have written it long ago). The shell game we are talking about doesn?t fix anything. It simply moves the shortages around in favor of those with the greatest economic resources. Owen > > -Scott > > On Thu, Sep 7, 2017 at 3:19 PM, Chris Woodfield > wrote: > Replying to myself, I decided to look up the population proportions mentioned in my last email: > > North America - 7.79% > South America - 5.68% > Africa - 16.36% > > So if one were to use numbers similar to these - the average formula doesn?t make much of a difference for LACNIC, and actually qualifies AFRINIC for a far larger share of space than the straight average. > > I?m wondering what, if any, types of metrics might exist for measuring demand for resources instead of population? Or does that run afoul of the concept of Internet access as a worldwide human right? > > -C > >> On Sep 7, 2017, at 2:50 PM, Chris Woodfield > wrote: >> >> Thinking more about the use of an average distribution in the proposal, I?m wondering if this accurately reflects the issue. >> >> The distribution of IP addresses by IANA to the various RIRs is only inequitable if it results in a clear difference in the ability of an entity in different regions to acquire IP address space. We don?t need the same number of allocations in each region - if nothing else, the allocations should roughly reflect regional populations - but it should be no more difficult for a party in Africa or South America to acquire IPv4 resources than it is for a party in North America, Europe, or Asia to do so. To the extent that this is not the case, we owe the community action to correct. >> >> The question then becomes - does the lack of a transfer policy from ARIN to these regions make it substantially more difficult to acquire space on the transfer market today? I?d argue that to the extent that doing so requires transferring to the space to the local RIR, then the answer is YES, as from my point of view, the bulk of transfer market supply is from allocations in the ARIN region (resellers on the list who are in a position to comment, please keep me honest and speak up if that isn?t the case). >> >> This is somewhat mitigated by the current case that both LACNIC and AFRINIC still have space to allocate, while ARIN does not. But shower term point-in-time facts shouldn?t drive far-reaching policy decisions IMO. >> >> As such, I support the goal of the policy, but I believe that the calculation used to determine qualifying RIRs could be tweaked. Could we compare allocation percentages to world population, perhaps? >> >> -C >> >>> On Sep 7, 2017, at 2:27 PM, Cj Aronson > wrote: >>> >>> David.. I agree with your very well written summary. I just feel that the mathematical formula to determine when the transfers have to start being reciprocal is not needed. >>> >>> The reason why I feel that way is that we're computing something that was said earlier, "To go below the global average, the RIR above the average and closest to >>> it would need to lose 81,871,002 more addresses, which at the current rate >>> (14,592 lost per month) would take 5,620 months (468 years)." >>> >>> It seems like we're spending time computing something that is not likely to happen.. I would surely hope we are done with IPv4 within the next 468 years :-) >>> >>> >>> Thanks! >>> -----Cathy >>> >>> >>> {?,?} >>> (( )) >>> ? ? >>> >>> On Thu, Sep 7, 2017 at 2:46 PM, David Farmer > wrote: >>> Cathy, >>> >>> Yes, in some ways it would be more straight forward to just say LACNIC and AFRINIC are allowed an exception to the reciprocity requirement. However, that policy would contain only the facts of the situation. Whereas this policy contains quantifiable reasoning why LACNIC and AFRINIC are exempted from the reciprocity requirement and why APNIC and RIPE are not. >>> >>> To be honest, I didn't want the reciprocity requirement in the original transfer policy to being with, because of the optics of this very situation with LACNIC and AFRINIC. However, I didn't push the issue with the original transfer policy because I knew it would be several year before LACNIC and AFRINIC got to the point of approving a transfer policy of any kind. So, when this issue with LACNIC and AFRINIC came up I thought obvious thing to do was to eliminate the reciprocity requirement all together. However, I really like this compromise as well as the reasoning that comes with it. >>> >>> There is absolutely no reason for transfers with APNIC and RIPE to not be on a reciprocal basis. However, with LACNIC and AFRINIC I feel there should be room for some nuance. LACNIC and AFRINIC have received the short-end of the stick, so to speak. There was no conspiracy or wrongdoing that caused this result, but it is a stark fact when you look at the numbers. I therefore believe these facts should afford LACNIC and AFRINIC some latitude to decide for themselves how best to move forward. >>> >>> In the long-run I totally believe LACNIC and AFRINIC should approve reciprocal transfer policies. However, we need to give them room to decide this for themselves, it is arrogant and inconsiderate of the facts for us to dictate a reciprocal transfer policy to them. If they feel they need to start with a one-way transfer policy, there is logic to such a strategy, and the current facts seem to justify at least some caution on their part. >>> >>> Finally, the numbers show we have more than enough room to be magnanimous in this situation, I believe we should give LACNIC and AFRINIC room to maneuver, and choose their own way forward. >>> >>> Thanks. >>> >>> On Wed, Sep 6, 2017 at 4:10 PM, Cj Aronson > wrote: >>> Okay so this formula.. does it just give us Afrinic and Lacnic right? So why don't we just say that? Since there are only 5 RIRs it seems that maybe a formula isn't needed? >>> >>> >>> {?,?} >>> (( )) >>> ? ? >>> >>> On Wed, Sep 6, 2017 at 12:35 PM, ARIN > wrote: >>> The following has been revised: >>> >>> * Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers >>> >>> Revised text is below and can be found at: >>> https://www.arin.net/policy/proposals/2017_4.html >>> >>> You are encouraged to discuss all Draft Policies on PPML. The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet number resource policy as stated in the Policy Development Process (PDP). Specifically, these principles are: >>> >>> * Enabling Fair and Impartial Number Resource Administration >>> * Technically Sound >>> * Supported by the Community >>> >>> The PDP can be found at: >>> https://www.arin.net/policy/pdp.html >>> >>> Draft Policies and Proposals under discussion can be found at: >>> https://www.arin.net/policy/proposals/index.html >>> >>> Regards, >>> >>> Sean Hopkins >>> Policy Analyst >>> American Registry for Internet Numbers (ARIN) >>> >>> >>> >>> Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers >>> >>> Version Date: 6 September 2017 >>> >>> Problem Statement: >>> >>> AFRINIC and LACNIC are currently considering one-way inter-RIR transfer proposals. Those RIR communities feel a one-way policy a policy that allows network operators in their regions to obtain space from another region and transfer it into AFRINIC and LACNIC may best meet the needs of the operators in that region. >>> >>> ARIN staff, in reply to an inquiry from AFRINIC, have formally indicated that ARINs 8.4 policy language will not allow ARIN to participate in such one-way transfers. The staff formally indicate to AFRINIC that the word reciprocal in 8.4 prohibits ARIN from allowing ARIN-registered space to transfer directly to AFRINIC (in this context). >>> >>> ARIN as a community should recognize that other RIR operator communities have different needs than we do. We should recognize that: >>> >>> - network operators in AFRINIC in LACNIC have need to obtain space in the market; >>> >>> - have reasons they think are important to not allow two-way transfers; and >>> >>> - we should understand that the history of the RIR system has led to LACNIC and AFRINIC having multiple orders of magnitude less IPv4 address space than ARIN does. >>> >>> Policy statement: >>> >>> Add the following sentence after the first sentence of NRPM 8.4: >>> >>> Inter-RIR transfers may take place to an RIR with a non-reciprocal inter-RIR transfer policy only when the recipient RIR has an IPv4 total inventory less than the average (mean) of the IPv4 total inventory among all of the RIRs. >>> >>> Timetable for implementation: Upon the ratification of any inter-RIR transfer policy at another RIR that is one-way as described in the problem statement. >>> _______________________________________________ >>> 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. >>> >>> >>> >>> -- >>> =============================================== >>> David Farmer Email:farmer at umn.edu >>> Networking & Telecommunication Services >>> Office of Information Technology >>> University of Minnesota >>> 2218 University Ave SE Phone: 612-626-0815 >>> Minneapolis, MN 55414-3029 Cell: 612-812-9952 >>> =============================================== >>> >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to >>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at arin.net if you experience any issues. >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Fri Sep 8 23:58:27 2017 From: owen at delong.com (Owen DeLong) Date: Fri, 8 Sep 2017 20:58:27 -0700 Subject: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity In-Reply-To: <0703529B-C2D8-4D5B-AC56-AF9D38F592FF@panix.com> References: <2bc0e7f7-c3d1-c496-1d58-ccec181c6414@arin.net> <0439B09D-AF93-4BC2-97EB-48A10BF753E8@semihuman.com> <18F45FF2-7AC8-4891-B54F-9F135A09AFD4@semihuman.com> <9c99922f005c4545beb2f19f057b4032@kz-mail01.manifold.edwardrosekzoo.com> <6f9106a54ace45a9a11a9202784acbe1@kz-mail01.manifold.edwardrosekzoo.com> <054284bb223d402f85434b4d8ae78765@kz-mail01.manifold.edwardrosekz oo.com> <0703529B-C2D8-4D5B-AC56-AF9D38F592FF@panix.com> Message-ID: <11AFD3D6-9DB5-4269-A299-D1B33AB19183@delong.com> If you have an in-country entity within the AfriNIC region, get your addresses from AfriNIC? Easy, problem solved. Owen > On Sep 8, 2017, at 13:04 , David Huberman wrote: > > In some countries, data sovereignty laws require all assets to be owned by an in country entity. A best practice for compliance is to register to the in country subsidiary and have that duly registered in the RIR. Doing it this way also gives you preferential treatment under data transport laws in some countries. > > In other countries, to obtain transit of your route announcements, the prefixes must be registered in the local RIR or NIR. > > Sent from my iPhone > >> On Sep 8, 2017, at 3:45 PM, Michael Winters wrote: >> >> Serious question, what legal compliance requirements are there to use ARIN addresses in LACNIC or AfriNIC? >> >> -----Original Message----- >> From: David R Huberman [mailto:daveid at panix.com] >> Sent: Friday, September 8, 2017 1:27 PM >> To: William Herrin >> Cc: Michael Winters ; arin-ppml at arin.net >> Subject: Re: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity >> >>> Parts of Africa choose to starve rather than accept the import of GMO >>> food products from the U.S. This is not the US's problem, nor should >>> it be. I believe the correct proverb is, "beggars can't be choosers." >> >> Bill, I framed the root motivation of the draft policy as: >> >> "ARIN-based network operators who are responsible for multi-continent IP networks need to be able to move ARIN-registered numbers from ARIN to LACNIC and AFRINIC for our datacenters in those regions. This need is to allow us to achieve legal compliance and network engineering goals." >> >> >> ________________________ >> >> >> ________________________ >> > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From owen at delong.com Sat Sep 9 00:03:05 2017 From: owen at delong.com (Owen DeLong) Date: Fri, 8 Sep 2017 21:03:05 -0700 Subject: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers In-Reply-To: <58918650-9D59-406C-9E55-D601334EE558@delong.com> References: <2bc0e7f7-c3d1-c496-1d58-ccec181c6414@arin.net> <58918650-9D59-406C-9E55-D601334EE558@delong.com> Message-ID: For those wondering: Source of my country ranks below: http://www.geoba.se/population.php?pc=world Owen > On Sep 8, 2017, at 20:46 , Owen DeLong wrote: > > >> On Sep 7, 2017, at 13:46 , David Farmer > wrote: >> >> Cathy, >> >> Yes, in some ways it would be more straight forward to just say LACNIC and AFRINIC are allowed an exception to the reciprocity requirement. However, that policy would contain only the facts of the situation. Whereas this policy contains quantifiable reasoning why LACNIC and AFRINIC are exempted from the reciprocity requirement and why APNIC and RIPE are not. > > Actually, if you wanted to do that, I think you?d have somehow account for population differences between the various regions served as I think there is a radically different fraction of the population of earth in each of the RIR?s service regions. Since APNIC includes both China (1.37 bn) and India (1.28 bn) and in fact 18 of the top 100 countries > by population, I?m pretty sure it is well ahead of most of the others. The number 3 nation on the list is the US at 328 Mil. By the time you get to 14, you?re looking at populations under 100 Mil. Of the top 15, we have: APNIC: 8 (CN, IN, ID, PK, BD, JP, PH, VN) , ARIN: 1 (US), AfriNIC: 3 (NG, ET, EG) , RIPE: 1 (RU), LACNIC: 2 (MX, BR). > >> To be honest, I didn't want the reciprocity requirement in the original transfer policy to being with, because of the optics of this very situation with LACNIC and AFRINIC. However, I didn't push the issue with the original transfer policy because I knew it would be several year before LACNIC and AFRINIC got to the point of approving a transfer policy of any kind. So, when this issue with LACNIC and AFRINIC came up I thought obvious thing to do was to eliminate the reciprocity requirement all together. However, I really like this compromise as well as the reasoning that comes with it. > > For many of the same reasons, I oppose this policy. That?s fine, men of good conscience can look at the same set of facts and draw different conclusions in good faith. > >> There is absolutely no reason for transfers with APNIC and RIPE to not be on a reciprocal basis. However, with LACNIC and AFRINIC I feel there should be room for some nuance. LACNIC and AFRINIC have received the short-end of the stick, so to speak. There was no conspiracy or wrongdoing that caused this result, but it is a stark fact when you look at the numbers. I therefore believe these facts should afford LACNIC and AFRINIC some latitude to decide for themselves how best to move forward. > > LACNIC and AfriNIC for a variety of reasons are late to the party for IPv4. I will venture to say that I have spent as much time working with and in the AfriNIC region as any other member of the AC, possibly more. I will also venture to say that I have a pretty good understanding of the network situation in the LACNIC region. > > The reality is that if we permit a unilateral transfer policy, we are, in fact, encouraging them to disable their networks with an even larger IPv4 legacy and greater IPv4 technical debt. > >> In the long-run I totally believe LACNIC and AFRINIC should approve reciprocal transfer policies. However, we need to give them room to decide this for themselves, it is arrogant and inconsiderate of the facts for us to dictate a reciprocal transfer policy to them. If they feel they need to start with a one-way transfer policy, there is logic to such a strategy, and the current facts seem to justify at least some caution on their part. > > We aren?t dictating anything to them. We are saying that if they want access to the addresses currently in this region, then it has to be on an equal footing with an equivalent bilateral policy. I see nothing arrogant or unfair about that and claiming that it is flies in the face of the facts of the matter. > >> Finally, the numbers show we have more than enough room to be magnanimous in this situation, I believe we should give LACNIC and AFRINIC room to maneuver, and choose their own way forward. > > They are perfectly free to choose whatever way forward they wish to choose without any changes in ARIN policy. > > Owen > >> >> Thanks. >> >> On Wed, Sep 6, 2017 at 4:10 PM, Cj Aronson > wrote: >> Okay so this formula.. does it just give us Afrinic and Lacnic right? So why don't we just say that? Since there are only 5 RIRs it seems that maybe a formula isn't needed? >> >> >> {?,?} >> (( )) >> ? ? >> >> On Wed, Sep 6, 2017 at 12:35 PM, ARIN > wrote: >> The following has been revised: >> >> * Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers >> >> Revised text is below and can be found at: >> https://www.arin.net/policy/proposals/2017_4.html >> >> You are encouraged to discuss all Draft Policies on PPML. The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet number resource policy as stated in the Policy Development Process (PDP). Specifically, these principles are: >> >> * Enabling Fair and Impartial Number Resource Administration >> * Technically Sound >> * Supported by the Community >> >> The PDP can be found at: >> https://www.arin.net/policy/pdp.html >> >> Draft Policies and Proposals under discussion can be found at: >> https://www.arin.net/policy/proposals/index.html >> >> Regards, >> >> Sean Hopkins >> Policy Analyst >> American Registry for Internet Numbers (ARIN) >> >> >> >> Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers >> >> Version Date: 6 September 2017 >> >> Problem Statement: >> >> AFRINIC and LACNIC are currently considering one-way inter-RIR transfer proposals. Those RIR communities feel a one-way policy a policy that allows network operators in their regions to obtain space from another region and transfer it into AFRINIC and LACNIC may best meet the needs of the operators in that region. >> >> ARIN staff, in reply to an inquiry from AFRINIC, have formally indicated that ARINs 8.4 policy language will not allow ARIN to participate in such one-way transfers. The staff formally indicate to AFRINIC that the word reciprocal in 8.4 prohibits ARIN from allowing ARIN-registered space to transfer directly to AFRINIC (in this context). >> >> ARIN as a community should recognize that other RIR operator communities have different needs than we do. We should recognize that: >> >> - network operators in AFRINIC in LACNIC have need to obtain space in the market; >> >> - have reasons they think are important to not allow two-way transfers; and >> >> - we should understand that the history of the RIR system has led to LACNIC and AFRINIC having multiple orders of magnitude less IPv4 address space than ARIN does. >> >> Policy statement: >> >> Add the following sentence after the first sentence of NRPM 8.4: >> >> Inter-RIR transfers may take place to an RIR with a non-reciprocal inter-RIR transfer policy only when the recipient RIR has an IPv4 total inventory less than the average (mean) of the IPv4 total inventory among all of the RIRs. >> >> Timetable for implementation: Upon the ratification of any inter-RIR transfer policy at another RIR that is one-way as described in the problem statement. >> _______________________________________________ >> 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. >> >> >> >> -- >> =============================================== >> David Farmer Email:farmer at umn.edu >> Networking & Telecommunication Services >> Office of Information Technology >> University of Minnesota >> 2218 University Ave SE Phone: 612-626-0815 >> Minneapolis, MN 55414-3029 Cell: 612-812-9952 >> =============================================== >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From milton at gatech.edu Mon Sep 11 12:39:02 2017 From: milton at gatech.edu (Mueller, Milton L) Date: Mon, 11 Sep 2017 16:39:02 +0000 Subject: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers In-Reply-To: References: <2bc0e7f7-c3d1-c496-1d58-ccec181c6414@arin.net> <0439B09D-AF93-4BC2-97EB-48A10BF753E8@semihuman.com> <18F45FF2-7AC8-4891-B54F-9F135A09AFD4@semihuman.com> Message-ID: Correct, Scott. ?The problem is simply that not all companies can get access to the IP addresses they need to run their businesses.? The current policy is a restriction on moving numbers to their most desired uses. The idea that we are protecting a market in IP addresses by NOT allowing trades to take place because of some imaginary ?imbalance? in the flow of IP addresses across imaginary RIR borders is indeed ?overthinking? ? or perhaps just not thinking. Perhaps you?ve all become Trumpian economic nationalists. Can anyone tell me how a so-called ?imbalance? in the flow of transferred addresses across regions negatively affects anyone on this list in a tangible way? Remember folks, there is no free pool. So what?s the harm? Party A transfers N IPv4 addresses to party B. If I am neither party A nor party B, tell me why I care whether party B is in Africa, Asia, Europe or wherever? How does it affect me in the slightest? You might say ?once the numbers go to Africa it might never come back.? Well, if the numbers go to Microsoft or Oracle in North America they almost never come back. At this stage of the game, almost all legitimate transfers are going to places where they will be used and not thrown back into the market any time soon. Why should I care where Party B is geographically? If you want to buy the addresses in competition with Party B, then outbid him/her. Are you saying that ARIN should subsidize your acquisition by eliminating certain buyers from the market? If I am Party A, then the current policy simply means that I have fewer options for selling my addresses. How does that benefit me? How does that benefit the Internet? How does that benefit anyone? Dr. Milton L. Mueller Professor, School of Public Policy Georgia Institute of Technology From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Scott Leibrand Sent: Thursday, September 7, 2017 8:07 PM To: Chris Woodfield Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers IMO we're overthinking this. The problem is simply that not all companies can get access to the IP addresses they need to run their businesses. The fix is to enable transfers from ARIN to all other regions, and between as many regions as are willing to participate. Only LACNIC and AfriNIC don't allow such transfers yet, and if we can make it easier for them to allow transfers at least in the important direction (to their regions) then the transfer market will take care of making sure everyone who needs addresses can get them. So any policy, including the draft policy as written, that allows unidirectional transfers to LACNIC and AfriNIC solves the problem. -Scott On Thu, Sep 7, 2017 at 3:19 PM, Chris Woodfield > wrote: Replying to myself, I decided to look up the population proportions mentioned in my last email: North America - 7.79% South America - 5.68% Africa - 16.36% So if one were to use numbers similar to these - the average formula doesn?t make much of a difference for LACNIC, and actually qualifies AFRINIC for a far larger share of space than the straight average. I?m wondering what, if any, types of metrics might exist for measuring demand for resources instead of population? Or does that run afoul of the concept of Internet access as a worldwide human right? -C On Sep 7, 2017, at 2:50 PM, Chris Woodfield > wrote: Thinking more about the use of an average distribution in the proposal, I?m wondering if this accurately reflects the issue. The distribution of IP addresses by IANA to the various RIRs is only inequitable if it results in a clear difference in the ability of an entity in different regions to acquire IP address space. We don?t need the same number of allocations in each region - if nothing else, the allocations should roughly reflect regional populations - but it should be no more difficult for a party in Africa or South America to acquire IPv4 resources than it is for a party in North America, Europe, or Asia to do so. To the extent that this is not the case, we owe the community action to correct. The question then becomes - does the lack of a transfer policy from ARIN to these regions make it substantially more difficult to acquire space on the transfer market today? I?d argue that to the extent that doing so requires transferring to the space to the local RIR, then the answer is YES, as from my point of view, the bulk of transfer market supply is from allocations in the ARIN region (resellers on the list who are in a position to comment, please keep me honest and speak up if that isn?t the case). This is somewhat mitigated by the current case that both LACNIC and AFRINIC still have space to allocate, while ARIN does not. But shower term point-in-time facts shouldn?t drive far-reaching policy decisions IMO. As such, I support the goal of the policy, but I believe that the calculation used to determine qualifying RIRs could be tweaked. Could we compare allocation percentages to world population, perhaps? -C On Sep 7, 2017, at 2:27 PM, Cj Aronson > wrote: David.. I agree with your very well written summary. I just feel that the mathematical formula to determine when the transfers have to start being reciprocal is not needed. The reason why I feel that way is that we're computing something that was said earlier, "To go below the global average, the RIR above the average and closest to it would need to lose 81,871,002 more addresses, which at the current rate (14,592 lost per month) would take 5,620 months (468 years)." It seems like we're spending time computing something that is not likely to happen.. I would surely hope we are done with IPv4 within the next 468 years :-) Thanks! -----Cathy {?,?} (( )) ? ? On Thu, Sep 7, 2017 at 2:46 PM, David Farmer > wrote: Cathy, Yes, in some ways it would be more straight forward to just say LACNIC and AFRINIC are allowed an exception to the reciprocity requirement. However, that policy would contain only the facts of the situation. Whereas this policy contains quantifiable reasoning why LACNIC and AFRINIC are exempted from the reciprocity requirement and why APNIC and RIPE are not. To be honest, I didn't want the reciprocity requirement in the original transfer policy to being with, because of the optics of this very situation with LACNIC and AFRINIC. However, I didn't push the issue with the original transfer policy because I knew it would be several year before LACNIC and AFRINIC got to the point of approving a transfer policy of any kind. So, when this issue with LACNIC and AFRINIC came up I thought obvious thing to do was to eliminate the reciprocity requirement all together. However, I really like this compromise as well as the reasoning that comes with it. There is absolutely no reason for transfers with APNIC and RIPE to not be on a reciprocal basis. However, with LACNIC and AFRINIC I feel there should be room for some nuance. LACNIC and AFRINIC have received the short-end of the stick, so to speak. There was no conspiracy or wrongdoing that caused this result, but it is a stark fact when you look at the numbers. I therefore believe these facts should afford LACNIC and AFRINIC some latitude to decide for themselves how best to move forward. In the long-run I totally believe LACNIC and AFRINIC should approve reciprocal transfer policies. However, we need to give them room to decide this for themselves, it is arrogant and inconsiderate of the facts for us to dictate a reciprocal transfer policy to them. If they feel they need to start with a one-way transfer policy, there is logic to such a strategy, and the current facts seem to justify at least some caution on their part. Finally, the numbers show we have more than enough room to be magnanimous in this situation, I believe we should give LACNIC and AFRINIC room to maneuver, and choose their own way forward. Thanks. On Wed, Sep 6, 2017 at 4:10 PM, Cj Aronson > wrote: Okay so this formula.. does it just give us Afrinic and Lacnic right? So why don't we just say that? Since there are only 5 RIRs it seems that maybe a formula isn't needed? {?,?} (( )) ? ? On Wed, Sep 6, 2017 at 12:35 PM, ARIN > wrote: The following has been revised: * Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers Revised text is below and can be found at: https://www.arin.net/policy/proposals/2017_4.html You are encouraged to discuss all Draft Policies on PPML. The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet number resource policy as stated in the Policy Development Process (PDP). Specifically, these principles are: * Enabling Fair and Impartial Number Resource Administration * Technically Sound * Supported by the Community The PDP can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Sean Hopkins Policy Analyst American Registry for Internet Numbers (ARIN) Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers Version Date: 6 September 2017 Problem Statement: AFRINIC and LACNIC are currently considering one-way inter-RIR transfer proposals. Those RIR communities feel a one-way policy a policy that allows network operators in their regions to obtain space from another region and transfer it into AFRINIC and LACNIC may best meet the needs of the operators in that region. ARIN staff, in reply to an inquiry from AFRINIC, have formally indicated that ARINs 8.4 policy language will not allow ARIN to participate in such one-way transfers. The staff formally indicate to AFRINIC that the word reciprocal in 8.4 prohibits ARIN from allowing ARIN-registered space to transfer directly to AFRINIC (in this context). ARIN as a community should recognize that other RIR operator communities have different needs than we do. We should recognize that: - network operators in AFRINIC in LACNIC have need to obtain space in the market; - have reasons they think are important to not allow two-way transfers; and - we should understand that the history of the RIR system has led to LACNIC and AFRINIC having multiple orders of magnitude less IPv4 address space than ARIN does. Policy statement: Add the following sentence after the first sentence of NRPM 8.4: Inter-RIR transfers may take place to an RIR with a non-reciprocal inter-RIR transfer policy only when the recipient RIR has an IPv4 total inventory less than the average (mean) of the IPv4 total inventory among all of the RIRs. Timetable for implementation: Upon the ratification of any inter-RIR transfer policy at another RIR that is one-way as described in the problem statement. _______________________________________________ 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. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ 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 abagrin at omninet.io Mon Sep 11 12:54:39 2017 From: abagrin at omninet.io (Andrew Bagrin) Date: Mon, 11 Sep 2017 12:54:39 -0400 Subject: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers In-Reply-To: References: <2bc0e7f7-c3d1-c496-1d58-ccec181c6414@arin.net> <0439B09D-AF93-4BC2-97EB-48A10BF753E8@semihuman.com> <18F45FF2-7AC8-4891-B54F-9F135A09AFD4@semihuman.com> Message-ID: <7295314bfb7e701d223bd7ffd5fc5aca@mail.gmail.com> As long as it is tracked that this block now belongs to a different country and can *easily *be updated in millions of companies geo-firewall policies based on IP. I?m okay with it being an ?occasional? thing, not a daily event. From a security perspective, there is benefit of having a solid ?non-fluid? mapping of IP blocks to geo. Tracking does not mean relying on company to fill in the country field properly in the who-is db. I would prefer a transfer of blocks between ARIN, RIPE etc.. On a side note, I?m still a big fan of $100/month per /24 IP block. ISP etc.. can easily charge their customer 25 cents or eat the cost, but those hoarding /16 blocks that aren?t being used, will be motivated to release them back to ARIN. *From:* ARIN-PPML [mailto:arin-ppml-bounces at arin.net] *On Behalf Of *Mueller, Milton L *Sent:* Monday, September 11, 2017 12:39 PM *To:* Scott Leibrand ; Chris Woodfield < chris at semihuman.com> *Cc:* arin-ppml at arin.net *Subject:* Re: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers Correct, Scott. ?The problem is simply that not all companies can get access to the IP addresses they need to run their businesses.? The current policy is a restriction on moving numbers to their most desired uses. The idea that we are protecting a market in IP addresses by NOT allowing trades to take place because of some imaginary ?imbalance? in the flow of IP addresses across imaginary RIR borders is indeed ?overthinking? ? or perhaps just not thinking. Perhaps you?ve all become Trumpian economic nationalists. Can anyone tell me how a so-called ?imbalance? in the flow of transferred addresses across regions negatively affects anyone on this list in a tangible way? Remember folks, there is no free pool. So what?s the harm? Party A transfers N IPv4 addresses to party B. If I am neither party A nor party B, tell me why I care whether party B is in Africa, Asia, Europe or wherever? How does it affect me in the slightest? You might say ?once the numbers go to Africa it might never come back.? Well, if the numbers go to Microsoft or Oracle in North America they almost never come back. At this stage of the game, almost all legitimate transfers are going to places where they will be used and not thrown back into the market any time soon. Why should I care where Party B is geographically? If you want to buy the addresses in competition with Party B, then outbid him/her. Are you saying that ARIN should subsidize your acquisition by eliminating certain buyers from the market? If I am Party A, then the current policy simply means that I have fewer options for selling my addresses. How does that benefit me? How does that benefit the Internet? How does that benefit anyone? Dr. Milton L. Mueller Professor, School of Public Policy Georgia Institute of Technology *From:* ARIN-PPML [mailto:arin-ppml-bounces at arin.net ] *On Behalf Of *Scott Leibrand *Sent:* Thursday, September 7, 2017 8:07 PM *To:* Chris Woodfield *Cc:* arin-ppml at arin.net *Subject:* Re: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers IMO we're overthinking this. The problem is simply that not all companies can get access to the IP addresses they need to run their businesses. The fix is to enable transfers from ARIN to all other regions, and between as many regions as are willing to participate. Only LACNIC and AfriNIC don't allow such transfers yet, and if we can make it easier for them to allow transfers at least in the important direction (to their regions) then the transfer market will take care of making sure everyone who needs addresses can get them. So any policy, including the draft policy as written, that allows unidirectional transfers to LACNIC and AfriNIC solves the problem. -Scott On Thu, Sep 7, 2017 at 3:19 PM, Chris Woodfield wrote: Replying to myself, I decided to look up the population proportions mentioned in my last email: North America - 7.79% South America - 5.68% Africa - 16.36% So if one were to use numbers similar to these - the average formula doesn?t make much of a difference for LACNIC, and actually qualifies AFRINIC for a far larger share of space than the straight average. I?m wondering what, if any, types of metrics might exist for measuring demand for resources instead of population? Or does that run afoul of the concept of Internet access as a worldwide human right? -C On Sep 7, 2017, at 2:50 PM, Chris Woodfield wrote: Thinking more about the use of an average distribution in the proposal, I?m wondering if this accurately reflects the issue. The distribution of IP addresses by IANA to the various RIRs is only inequitable if it results in a clear difference in the ability of an entity in different regions to acquire IP address space. We don?t need the same number of allocations in each region - if nothing else, the allocations should roughly reflect regional populations - but it should be no more difficult for a party in Africa or South America to acquire IPv4 resources than it is for a party in North America, Europe, or Asia to do so. To the extent that this is not the case, we owe the community action to correct. The question then becomes - does the lack of a transfer policy from ARIN to these regions make it substantially more difficult to acquire space on the transfer market today? I?d argue that to the extent that doing so requires transferring to the space to the local RIR, then the answer is YES, as from my point of view, the bulk of transfer market supply is from allocations in the ARIN region (resellers on the list who are in a position to comment, please keep me honest and speak up if that isn?t the case). This is somewhat mitigated by the current case that both LACNIC and AFRINIC still have space to allocate, while ARIN does not. But shower term point-in-time facts shouldn?t drive far-reaching policy decisions IMO. As such, I support the goal of the policy, but I believe that the calculation used to determine qualifying RIRs could be tweaked. Could we compare allocation percentages to world population, perhaps? -C On Sep 7, 2017, at 2:27 PM, Cj Aronson wrote: David.. I agree with your very well written summary. I just feel that the mathematical formula to determine when the transfers have to start being reciprocal is not needed. The reason why I feel that way is that we're computing something that was said earlier, "To go below the global average, the RIR above the average and closest to it would need to lose 81,871,002 more addresses, which at the current rate (14,592 lost per month) would take 5,620 months (468 years)." It seems like we're spending time computing something that is not likely to happen.. I would surely hope we are done with IPv4 within the next 468 years :-) Thanks! -----Cathy {?,?} (( )) ? ? On Thu, Sep 7, 2017 at 2:46 PM, David Farmer wrote: Cathy, Yes, in some ways it would be more straight forward to just say LACNIC and AFRINIC are allowed an exception to the reciprocity requirement. However, that policy would contain only the facts of the situation. Whereas this policy contains quantifiable reasoning why LACNIC and AFRINIC are exempted from the reciprocity requirement and why APNIC and RIPE are not. To be honest, I didn't want the reciprocity requirement in the original transfer policy to being with, because of the optics of this very situation with LACNIC and AFRINIC. However, I didn't push the issue with the original transfer policy because I knew it would be several year before LACNIC and AFRINIC got to the point of approving a transfer policy of any kind. So, when this issue with LACNIC and AFRINIC came up I thought obvious thing to do was to eliminate the reciprocity requirement all together. However, I really like this compromise as well as the reasoning that comes with it. There is absolutely no reason for transfers with APNIC and RIPE to not be on a reciprocal basis. However, with LACNIC and AFRINIC I feel there should be room for some nuance. LACNIC and AFRINIC have received the short-end of the stick, so to speak. There was no conspiracy or wrongdoing that caused this result, but it is a stark fact when you look at the numbers. I therefore believe these facts should afford LACNIC and AFRINIC some latitude to decide for themselves how best to move forward. In the long-run I totally believe LACNIC and AFRINIC should approve reciprocal transfer policies. However, we need to give them room to decide this for themselves, it is arrogant and inconsiderate of the facts for us to dictate a reciprocal transfer policy to them. If they feel they need to start with a one-way transfer policy, there is logic to such a strategy, and the current facts seem to justify at least some caution on their part. Finally, the numbers show we have more than enough room to be magnanimous in this situation, I believe we should give LACNIC and AFRINIC room to maneuver, and choose their own way forward. Thanks. On Wed, Sep 6, 2017 at 4:10 PM, Cj Aronson wrote: Okay so this formula.. does it just give us Afrinic and Lacnic right? So why don't we just say that? Since there are only 5 RIRs it seems that maybe a formula isn't needed? {?,?} (( )) ? ? On Wed, Sep 6, 2017 at 12:35 PM, ARIN wrote: The following has been revised: * Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers Revised text is below and can be found at: https://www.arin.net/policy/proposals/2017_4.html You are encouraged to discuss all Draft Policies on PPML. The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet number resource policy as stated in the Policy Development Process (PDP). Specifically, these principles are: * Enabling Fair and Impartial Number Resource Administration * Technically Sound * Supported by the Community The PDP can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Sean Hopkins Policy Analyst American Registry for Internet Numbers (ARIN) Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers Version Date: 6 September 2017 Problem Statement: AFRINIC and LACNIC are currently considering one-way inter-RIR transfer proposals. Those RIR communities feel a one-way policy a policy that allows network operators in their regions to obtain space from another region and transfer it into AFRINIC and LACNIC may best meet the needs of the operators in that region. ARIN staff, in reply to an inquiry from AFRINIC, have formally indicated that ARINs 8.4 policy language will not allow ARIN to participate in such one-way transfers. The staff formally indicate to AFRINIC that the word reciprocal in 8.4 prohibits ARIN from allowing ARIN-registered space to transfer directly to AFRINIC (in this context). ARIN as a community should recognize that other RIR operator communities have different needs than we do. We should recognize that: - network operators in AFRINIC in LACNIC have need to obtain space in the market; - have reasons they think are important to not allow two-way transfers; and - we should understand that the history of the RIR system has led to LACNIC and AFRINIC having multiple orders of magnitude less IPv4 address space than ARIN does. Policy statement: Add the following sentence after the first sentence of NRPM 8.4: Inter-RIR transfers may take place to an RIR with a non-reciprocal inter-RIR transfer policy only when the recipient RIR has an IPv4 total inventory less than the average (mean) of the IPv4 total inventory among all of the RIRs. Timetable for implementation: Upon the ratification of any inter-RIR transfer policy at another RIR that is one-way as described in the problem statement. _______________________________________________ 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. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> =============================================== _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Mon Sep 11 13:16:57 2017 From: owen at delong.com (Owen DeLong) Date: Mon, 11 Sep 2017 13:16:57 -0400 Subject: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers In-Reply-To: References: <2bc0e7f7-c3d1-c496-1d58-ccec181c6414@arin.net> <0439B09D-AF93-4BC2-97EB-48A10BF753E8@semihuman.com> <18F45FF2-7AC8-4891-B54F-9F135A09AFD4@semihuman.com> Message-ID: Milton, This isn't about a perceived imbalance of trade. At least not for me. For me it is about making sure that if we remove restrictions, they are removed bilaterally and on equal footing. The current policy does not prevent any transfers that would be enabled by this proposal. If LACNIC and/or AfriNIC were to pass bidirectional transfer policies, then the current policy would still allow all transfers permitted under this proposal. The only change this proposal makes is to allow those two RIRs to pass inbound-only transfer policies and still participate (one way) in inter-RIR transfers with ARIN. I would think that with your unrestricted trade arguments, you would be in favor of removing restrictions on both sides, rather than unilaterally. Owen > On Sep 11, 2017, at 12:39, Mueller, Milton L wrote: > > Correct, Scott. > > ?The problem is simply that not all companies can get access to the IP addresses they need to run their businesses.? The current policy is a restriction on moving numbers to their most desired uses. The idea that we are protecting a market in IP addresses by NOT allowing trades to take place because of some imaginary ?imbalance? in the flow of IP addresses across imaginary RIR borders is indeed ?overthinking? ? or perhaps just not thinking. Perhaps you?ve all become Trumpian economic nationalists. > > Can anyone tell me how a so-called ?imbalance? in the flow of transferred addresses across regions negatively affects anyone on this list in a tangible way? Remember folks, there is no free pool. So what?s the harm? > > Party A transfers N IPv4 addresses to party B. If I am neither party A nor party B, tell me why I care whether party B is in Africa, Asia, Europe or wherever? How does it affect me in the slightest? You might say ?once the numbers go to Africa it might never come back.? Well, if the numbers go to Microsoft or Oracle in North America they almost never come back. At this stage of the game, almost all legitimate transfers are going to places where they will be used and not thrown back into the market any time soon. Why should I care where Party B is geographically? > > If you want to buy the addresses in competition with Party B, then outbid him/her. Are you saying that ARIN should subsidize your acquisition by eliminating certain buyers from the market? > > If I am Party A, then the current policy simply means that I have fewer options for selling my addresses. How does that benefit me? How does that benefit the Internet? How does that benefit anyone? > > Dr. Milton L. Mueller > Professor, School of Public Policy > Georgia Institute of Technology > > > > > From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Scott Leibrand > Sent: Thursday, September 7, 2017 8:07 PM > To: Chris Woodfield > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Revised: ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers > > IMO we're overthinking this. The problem is simply that not all companies can get access to the IP addresses they need to run their businesses. The fix is to enable transfers from ARIN to all other regions, and between as many regions as are willing to participate. Only LACNIC and AfriNIC don't allow such transfers yet, and if we can make it easier for them to allow transfers at least in the important direction (to their regions) then the transfer market will take care of making sure everyone who needs addresses can get them. So any policy, including the draft policy as written, that allows unidirectional transfers to LACNIC and AfriNIC solves the problem. > > -Scott > > On Thu, Sep 7, 2017 at 3:19 PM, Chris Woodfield wrote: > Replying to myself, I decided to look up the population proportions mentioned in my last email: > > North America - 7.79% > South America - 5.68% > Africa - 16.36% > > So if one were to use numbers similar to these - the average formula doesn?t make much of a difference for LACNIC, and actually qualifies AFRINIC for a far larger share of space than the straight average. > > I?m wondering what, if any, types of metrics might exist for measuring demand for resources instead of population? Or does that run afoul of the concept of Internet access as a worldwide human right? > > -C > > On Sep 7, 2017, at 2:50 PM, Chris Woodfield wrote: > > Thinking more about the use of an average distribution in the proposal, I?m wondering if this accurately reflects the issue. > > The distribution of IP addresses by IANA to the various RIRs is only inequitable if it results in a clear difference in the ability of an entity in different regions to acquire IP address space. We don?t need the same number of allocations in each region - if nothing else, the allocations should roughly reflect regional populations - but it should be no more difficult for a party in Africa or South America to acquire IPv4 resources than it is for a party in North America, Europe, or Asia to do so. To the extent that this is not the case, we owe the community action to correct. > > The question then becomes - does the lack of a transfer policy from ARIN to these regions make it substantially more difficult to acquire space on the transfer market today? I?d argue that to the extent that doing so requires transferring to the space to the local RIR, then the answer is YES, as from my point of view, the bulk of transfer market supply is from allocations in the ARIN region (resellers on the list who are in a position to comment, please keep me honest and speak up if that isn?t the case). > > This is somewhat mitigated by the current case that both LACNIC and AFRINIC still have space to allocate, while ARIN does not. But shower term point-in-time facts shouldn?t drive far-reaching policy decisions IMO. > > As such, I support the goal of the policy, but I believe that the calculation used to determine qualifying RIRs could be tweaked. Could we compare allocation percentages to world population, perhaps? > > -C > > On Sep 7, 2017, at 2:27 PM, Cj Aronson wrote: > > David.. I agree with your very well written summary. I just feel that the mathematical formula to determine when the transfers have to start being reciprocal is not needed. > > The reason why I feel that way is that we're computing something that was said earlier, "To go below the global average, the RIR above the average and closest to > it would need to lose 81,871,002 more addresses, which at the current rate > (14,592 lost per month) would take 5,620 months (468 years)." > > It seems like we're spending time computing something that is not likely to happen.. I would surely hope we are done with IPv4 within the next 468 years :-) > > > Thanks! > -----Cathy > > > {?,?} > (( )) > ? ? > > On Thu, Sep 7, 2017 at 2:46 PM, David Farmer wrote: > Cathy, > > Yes, in some ways it would be more straight forward to just say LACNIC and AFRINIC are allowed an exception to the reciprocity requirement. However, that policy would contain only the facts of the situation. Whereas this policy contains quantifiable reasoning why LACNIC and AFRINIC are exempted from the reciprocity requirement and why APNIC and RIPE are not. > > To be honest, I didn't want the reciprocity requirement in the original transfer policy to being with, because of the optics of this very situation with LACNIC and AFRINIC. However, I didn't push the issue with the original transfer policy because I knew it would be several year before LACNIC and AFRINIC got to the point of approving a transfer policy of any kind. So, when this issue with LACNIC and AFRINIC came up I thought obvious thing to do was to eliminate the reciprocity requirement all together. However, I really like this compromise as well as the reasoning that comes with it. > > There is absolutely no reason for transfers with APNIC and RIPE to not be on a reciprocal basis. However, with LACNIC and AFRINIC I feel there should be room for some nuance. LACNIC and AFRINIC have received the short-end of the stick, so to speak. There was no conspiracy or wrongdoing that caused this result, but it is a stark fact when you look at the numbers. I therefore believe these facts should afford LACNIC and AFRINIC some latitude to decide for themselves how best to move forward. > > In the long-run I totally believe LACNIC and AFRINIC should approve reciprocal transfer policies. However, we need to give them room to decide this for themselves, it is arrogant and inconsiderate of the facts for us to dictate a reciprocal transfer policy to them. If they feel they need to start with a one-way transfer policy, there is logic to such a strategy, and the current facts seem to justify at least some caution on their part. > > Finally, the numbers show we have more than enough room to be magnanimous in this situation, I believe we should give LACNIC and AFRINIC room to maneuver, and choose their own way forward. > > Thanks. > > On Wed, Sep 6, 2017 at 4:10 PM, Cj Aronson wrote: > Okay so this formula.. does it just give us Afrinic and Lacnic right? So why don't we just say that? Since there are only 5 RIRs it seems that maybe a formula isn't needed? > > > {?,?} > (( )) > ? ? > > On Wed, Sep 6, 2017 at 12:35 PM, ARIN wrote: > The following has been revised: > > * Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers > > Revised text is below and can be found at: > https://www.arin.net/policy/proposals/2017_4.html > > You are encouraged to discuss all Draft Policies on PPML. The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet number resource policy as stated in the Policy Development Process (PDP). Specifically, these principles are: > > * Enabling Fair and Impartial Number Resource Administration > * Technically Sound > * Supported by the Community > > The PDP can be found at: > https://www.arin.net/policy/pdp.html > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > Regards, > > Sean Hopkins > Policy Analyst > American Registry for Internet Numbers (ARIN) > > > > Draft Policy ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers > > Version Date: 6 September 2017 > > Problem Statement: > > AFRINIC and LACNIC are currently considering one-way inter-RIR transfer proposals. Those RIR communities feel a one-way policy a policy that allows network operators in their regions to obtain space from another region and transfer it into AFRINIC and LACNIC may best meet the needs of the operators in that region. > > ARIN staff, in reply to an inquiry from AFRINIC, have formally indicated that ARINs 8.4 policy language will not allow ARIN to participate in such one-way transfers. The staff formally indicate to AFRINIC that the word reciprocal in 8.4 prohibits ARIN from allowing ARIN-registered space to transfer directly to AFRINIC (in this context). > > ARIN as a community should recognize that other RIR operator communities have different needs than we do. We should recognize that: > > - network operators in AFRINIC in LACNIC have need to obtain space in the market; > > - have reasons they think are important to not allow two-way transfers; and > > - we should understand that the history of the RIR system has led to LACNIC and AFRINIC having multiple orders of magnitude less IPv4 address space than ARIN does. > > Policy statement: > > Add the following sentence after the first sentence of NRPM 8.4: > > Inter-RIR transfers may take place to an RIR with a non-reciprocal inter-RIR transfer policy only when the recipient RIR has an IPv4 total inventory less than the average (mean) of the IPv4 total inventory among all of the RIRs. > > Timetable for implementation: Upon the ratification of any inter-RIR transfer policy at another RIR that is one-way as described in the problem statement. > _______________________________________________ > 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. > > > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =============================================== > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmer at umn.edu Thu Sep 14 23:49:27 2017 From: farmer at umn.edu (David Farmer) Date: Thu, 14 Sep 2017 22:49:27 -0500 Subject: [arin-ppml] Re-allocations (was: Revised/Retitled: Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements) In-Reply-To: References: Message-ID: On Thu, Aug 31, 2017 at 9:58 AM, Jason Schiller wrote: > David, > > My thoughts, please take with a grain of salt. > > 1. Problem statement is fine, but really is just one of many examples > of why this data is needed > > 2. I'd be careful with the use of the word ISP, > - I recommend it is better just to drop it > - I'd drop the timing part, and leverage pre-existing text instead > (as this is simple, convenient, and keeping them in sync makes > sense) > > ------------- > > 1. Problem statement is fine, but really is just one of many examples > of why this data is needed > > I'm not sure this NEEDS to be separated from the other proposal, > but it certainly could be separated. (What I would optimize for > is getting both changes through as quickly as possible.) > > I think your problem statement is good, but is only a sub-set, > there are many things that require good contact info. > > Certainly LEA is a big one, even more critical than a subpoena > is suicide threats, death threats, and abductions with timely > access is even more critical. > One reason I focused on subpoenas is that it's not only an LEA issue, subpoenas involve civil matters as well, this isn't about just LEA and criminal legal system, but it is equally about civil legal system as well. This is about the exceptions society has on us the people that operate the Internet and not just the exceptions of government authorities. I'll add the other time-sensitive situations, I was a little leery of going over the top on that, and maybe underplayed it a little bit too much. > The info is also used for technical reasons to determine who is > the party best suited to resolve some technical issue. E.g. the > IPs are being blackholed by a third party, a machine in the > address range is infected with malware, a machine in the address > range is misconfigured in a way that leaves it vulnerable to reflection > attacks, abuse or hacking attempts for an address in the range, etc. > I'll add technical and abuse issues to the problem statement. > ---------- > > 2. I'd be careful with the use of the word ISP > > > I would caution the use of the word ISP. I think it reads just fine > without it. > > By definition any time there is a re-allocation, the address space is > going > to be used by an organization that intends to re-use some of their address > space to their own down stream customers. In ARIN terms this makes > them and ISP and not an end-user, but I fear people will get wrapped up in > the term "ISP" and claim they are not one and need not SWIP. > > If you think there is enough organizational separation to treat your > downstream (B) like a customer... > > And they (B) think there is enough organizational separation to treat > their (B's) downstream (C) like a customer, and therefor request a > re-allocation (and not a reassignment)... > > Then B needs to be registered in whois because they have a > re-allocation, and intend to make downstream subdeligations. > > Now Imagine this is ISP "A" with a customer of University of "B" > who has a customer of The "C" department, who has a customer > of computer Lab "D". A. B, and C need to be registered because > they are all registering sub-delegations. This is regardless of if > The "C" department considered themselves an "ISP". > I think the best way to deal this is to work on the definitions of Assign and Allocate in section 2.5. Further while look at that, I realized there is a grammatical question we should look at as well, is "reallocate" and "reassign" or "sub-allocate" and "sub-assign" the proper terms to use? The definitions in section 2.5 uses "sub-assign", but "reassign" is used several other places in the NRPM, and I believe ARIN Online uses the terms "reallocate" and "reassign". --- http://www.dictionary.com/browse/sub- 1. a prefix occurring originally in loanwords from Latin (subject; subtract; subvert; subsidy); on this model, freely attached to elements of any origin and used with the meaning ?under,? ?below,? ?beneath? (subalpine; substratum), ?slightly,? ?imperfectly,? ?nearly? (subcolumnar; subtropical), ?secondary,? ?subordinate? (subcommittee; subplot). http://www.dictionary.com/browse/re- 1. a prefix, occurring originally in loanwords from Latin, used with the meaning ?again? or ?again and again? to indicate repetition, or with the meaning ?back? or ?backward? to indicate withdrawal or backward motion: --- I think there is a strong argument for the use of either, however I don't think using both is a good idea, it only leads to additional confusion. I think reallocate and reassign are used in more places and sub-allocate and sub-assign are use in fewer locations, causing me to lean toward reallocate and reassign. So I think the definition in section 2.5 should use reassign instead. But what do others think? Thanks. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From narten at us.ibm.com Fri Sep 15 00:53:32 2017 From: narten at us.ibm.com (narten at us.ibm.com) Date: Fri, 15 Sep 2017 00:53:32 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201709150453.v8F4rWG3020698@rotala.raleigh.ibm.com> Total of 21 messages in the last 7 days. script run at: Fri Sep 15 00:53:27 EDT 2017 Messages | Bytes | Who --------+------+--------+----------+------------------------ 33.33% | 7 | 44.63% | 222420 | owen at delong.com 23.81% | 5 | 7.69% | 38330 | daveid at panix.com 14.29% | 3 | 13.84% | 68951 | mwinters at edwardrose.com 4.76% | 1 | 11.74% | 58509 | milton at gatech.edu 4.76% | 1 | 11.26% | 56086 | abagrin at omninet.io 4.76% | 1 | 4.85% | 24154 | farmer at umn.edu 4.76% | 1 | 2.34% | 11644 | bill at herrin.us 4.76% | 1 | 1.91% | 9504 | narten at us.ibm.com 4.76% | 1 | 1.75% | 8718 | theone at uneedus.com --------+------+--------+----------+------------------------ 100.00% | 21 |100.00% | 498316 | Total From jschiller at google.com Fri Sep 15 10:14:20 2017 From: jschiller at google.com (Jason Schiller) Date: Fri, 15 Sep 2017 10:14:20 -0400 Subject: [arin-ppml] Re-allocations (was: Revised/Retitled: Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements) In-Reply-To: References: Message-ID: Direct Allocation: an RIR, such as ARIN, designates a block of IPs to be used by an organization and their down stream customers. (re-allocations and re-assignments are permitted) [Note: if there is a requirement for the organization to hold at least one block of IPs that may be used in part or whole by its customers, then all blocks held by that organization will be treated as allocations.] Direct Assignment: an RIR, such as ARIN, designates a block of IPs to be used by an organization for use on equipment that they own/manage/are responsible for. (re-allocations and re-assignments are not permitted) An organization with either a direct allocation, or a re-allocation may sub-delegate a portion of their address space for use by their down stream customers. sub-deligations come in two types: re-allocations and reassignments. Re-allocation: when a sub-deligation is made to a customer, and it is intended to be used on the customer's equipment as well as by their downstream customers, then the sub-deligation must be a re-allocation. (further re-allocations and re-assignments are permitted) [Note: if there is a requirement for the downstream customer to hold at least one block of IPs that may be used in part or whole by its customers, then all blocks held by that organization will be treated as re-allocations.] Reassignment: when a sub-deligation is made to a customer, and it is intended to only be used on the customer's equipment for which they own/mange/are responsible for, then the sub-deligation must be a re-allocation. (further re-allocations and re-assignments are not permitted) My sense is people didn't want to say "allocation/assignment" or "re-allocation/reassignment" in policy as it is clunky. So in some cases we just shortened it but meant the "when you read these requirements about SWIP wrt assignments, it also obviously applies to allocations". This blurred the meaning of the terms. Now that we have re-clarified the exact meaning, we find there is a whole set of policy that should apply to both, but currently only applies to one because we did not mirror the text. I think the simple solution is to clearly define sub-deligation to mean both re-allocatiions, and reassignemnts, and move all the requirements that apply to both under a sub-deligation section, which a breakout for re-assignment specific and reallocation specific bits. Thanks, __Jason On Thu, Sep 14, 2017 at 11:49 PM, David Farmer wrote: > > > On Thu, Aug 31, 2017 at 9:58 AM, Jason Schiller > wrote: > >> David, >> >> My thoughts, please take with a grain of salt. >> >> 1. Problem statement is fine, but really is just one of many examples >> of why this data is needed >> >> 2. I'd be careful with the use of the word ISP, >> - I recommend it is better just to drop it >> - I'd drop the timing part, and leverage pre-existing text instead >> (as this is simple, convenient, and keeping them in sync makes >> sense) >> >> ------------- >> >> 1. Problem statement is fine, but really is just one of many examples >> of why this data is needed >> >> I'm not sure this NEEDS to be separated from the other proposal, >> but it certainly could be separated. (What I would optimize for >> is getting both changes through as quickly as possible.) >> >> I think your problem statement is good, but is only a sub-set, >> there are many things that require good contact info. >> >> Certainly LEA is a big one, even more critical than a subpoena >> is suicide threats, death threats, and abductions with timely >> access is even more critical. >> > > One reason I focused on subpoenas is that it's not only an LEA issue, > subpoenas involve civil matters as well, this isn't about just LEA > and criminal legal system, but it is equally about civil legal system as > well. This is about the exceptions society has on us the people that > operate the Internet and not just the exceptions of government > authorities. I'll add the other time-sensitive situations, I was a little > leery of going over the top on that, and maybe underplayed it a little bit > too much. > > >> The info is also used for technical reasons to determine who is >> the party best suited to resolve some technical issue. E.g. the >> IPs are being blackholed by a third party, a machine in the >> address range is infected with malware, a machine in the address >> range is misconfigured in a way that leaves it vulnerable to reflection >> attacks, abuse or hacking attempts for an address in the range, etc. >> > > I'll add technical and abuse issues to the problem statement. > > >> ---------- >> >> 2. I'd be careful with the use of the word ISP >> >> >> I would caution the use of the word ISP. I think it reads just fine >> without it. >> >> By definition any time there is a re-allocation, the address space is >> going >> to be used by an organization that intends to re-use some of their >> address >> space to their own down stream customers. In ARIN terms this makes >> them and ISP and not an end-user, but I fear people will get wrapped up >> in >> the term "ISP" and claim they are not one and need not SWIP. >> >> If you think there is enough organizational separation to treat your >> downstream (B) like a customer... >> >> And they (B) think there is enough organizational separation to treat >> their (B's) downstream (C) like a customer, and therefor request a >> re-allocation (and not a reassignment)... >> >> Then B needs to be registered in whois because they have a >> re-allocation, and intend to make downstream subdeligations. >> >> Now Imagine this is ISP "A" with a customer of University of "B" >> who has a customer of The "C" department, who has a customer >> of computer Lab "D". A. B, and C need to be registered because >> they are all registering sub-delegations. This is regardless of if >> The "C" department considered themselves an "ISP". >> > > I think the best way to deal this is to work on the definitions of Assign > and Allocate in section 2.5. Further while look at that, I realized there > is a grammatical question we should look at as well, is "reallocate" and > "reassign" or "sub-allocate" and "sub-assign" the proper terms to use? The > definitions in section 2.5 uses "sub-assign", but "reassign" is used > several other places in the NRPM, and I believe ARIN Online uses the terms > "reallocate" and "reassign". > > --- > http://www.dictionary.com/browse/sub- > > 1. a prefix occurring originally in loanwords from Latin (subject; > subtract; subvert; subsidy); on this model, freely attached to elements of > any origin and used with the meaning ?under,? ?below,? ?beneath? > (subalpine; substratum), ?slightly,? ?imperfectly,? ?nearly? (subcolumnar; > subtropical), ?secondary,? ?subordinate? (subcommittee; subplot). > > http://www.dictionary.com/browse/re- > > 1. a prefix, occurring originally in loanwords from Latin, used with the > meaning ?again? or ?again and again? to indicate repetition, or with the > meaning ?back? or ?backward? to indicate withdrawal or backward motion: > --- > > I think there is a strong argument for the use of either, however I don't > think using both is a good idea, it only leads to additional confusion. > > I think reallocate and reassign are used in more places and sub-allocate > and sub-assign are use in fewer locations, causing me to lean toward > reallocate and reassign. So I think the definition in section 2.5 should > use reassign instead. But what do others think? > > Thanks. > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE > > Phone: 612-626-0815 <(612)%20626-0815> > Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> > =============================================== > -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at egh.com Fri Sep 15 11:20:31 2017 From: john at egh.com (John Santos) Date: Fri, 15 Sep 2017 11:20:31 -0400 Subject: [arin-ppml] Re-allocations In-Reply-To: References: Message-ID: <4a388b15-806a-91c9-de75-92e513d8b5e7@egh.com> Typo?? On 9/15/2017 10:14 AM, Jason Schiller wrote: [snip] > Reassignment: when a sub-deligation is made to a customer, and it is > intended to only > be used on the customer's equipment for which they own/mange/are > responsible for, then the > sub-deligation must be a re-allocation. > (further re-allocations and re-assignments are not permitted) Should this say "...then the sub-deligation must be a *reassignment"*? * * > [snip] > Thanks, > > __Jason > -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jschiller at google.com Fri Sep 15 15:07:15 2017 From: jschiller at google.com (Jason Schiller) Date: Fri, 15 Sep 2017 15:07:15 -0400 Subject: [arin-ppml] Re-allocations In-Reply-To: <4a388b15-806a-91c9-de75-92e513d8b5e7@egh.com> References: <4a388b15-806a-91c9-de75-92e513d8b5e7@egh.com> Message-ID: John, Yes. I missed updating text I copied and pasted.... Thank you for reading and catching. __Jason On Fri, Sep 15, 2017 at 11:20 AM, John Santos wrote: > Typo?? > > On 9/15/2017 10:14 AM, Jason Schiller wrote: > [snip] > > Reassignment: when a sub-deligation is made to a customer, and it is > intended to only > be used on the customer's equipment for which they own/mange/are > responsible for, then the > sub-deligation must be a re-allocation. > (further re-allocations and re-assignments are not permitted) > > Should this say "...then the sub-deligation must be a *reassignment"*? > > [snip] > Thanks, > > __Jason > > -- > John Santos > Evans Griffiths & Hart, Inc.781-861-0670 ext 539 <(781)%20861-0670> > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at arin.net Mon Sep 18 10:37:03 2017 From: info at arin.net (ARIN) Date: Mon, 18 Sep 2017 10:37:03 -0400 Subject: [arin-ppml] Revised - Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements Message-ID: <848f1990-7a83-563e-1bef-c6b57c0cd1af@arin.net> The following has been revised: * Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements Revised text is below and can be found at: https://www.arin.net/policy/proposals/2017_5.html You are encouraged to discuss all Draft Policies on PPML. The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet number resource policy as stated in the Policy Development Process (PDP). Specifically, these principles are: * Enabling Fair and Impartial Number Resource Administration * Technically Sound * Supported by the Community The PDP can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Sean Hopkins Policy Analyst American Registry for Internet Numbers (ARIN) Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements Problem Statement: Current ARIN policy has different WHOIS directory registration requirements for IPv4 vs IPv6 address assignments. IPv4 registration is triggered for an assignment of any address block equal to or greater than a /29 (i.e., eight IPv4 addresses). In the case of IPv6, registration occurs for an assignment of any block equal to or greater than a /64, which constitutes one entire IPv6 subnet and is the minimum block size for an allocation. Accordingly, there is a significant disparity between IPv4 and IPv6 WHOIS registration thresholds in the case of assignments, resulting in more work in the case of IPv6 than is the case for IPv4. There is no technical or policy rationale for the disparity, which could serve as a deterrent to more rapid IPv6 adoption. The purpose of this proposal is to eliminate the disparity and corresponding adverse consequences. Policy statement: 1) Alter section 6.5.5.1 "Reassignment information" of the NRPM to strike "assignment containing a /64 or more addresses" and change to "re-allocation, reassignment containing a /47 or more addresses, or subdelegation of any size that will be individually announced," and 2) Alter section 6.5.5.2. "Assignments visible within 7 days" of the NRPM to strike the text "4.2.3.7.1" and change to "6.5.5.1" and 3) Alter section 6.5.5.3.1. "Residential Customer Privacy" of the NRPM by deleting the phrase "holding /64 and larger blocks" and 4) Add new section 6.5.5.4 "Registration Requested by Recipient" of the NRPM, to read: "If the downstream recipient of a static assignment of /64 or more addresses requests publishing of that assignment in ARIN's registration database, the ISP should register that assignment as described in section 6.5.5.1." Comments: a. Timetable for implementation: Policy should be adopted as soon as possible. b. Anything else: Author Comments: IPv6 should not be more burdensome than the equivalent IPv4 network size. Currently, assignments of /29 or more of IPv4 space (8 addresses) require registration. The greatest majority of ISP customers who have assignments of IPv4 space are of a single IPv4 address which do not trigger any ARIN registration requirement when using IPv4. This is NOT true when these same exact customers use IPv6, as assignments of /64 or more of IPv6 space require registration. Beginning with RFC 3177, it has been standard practice to assign a minimum assignment of /64 to every customer end user site, and less is never used. This means that ALL IPv6 assignments, including those customers that only use a single IPv4 address must be registered with ARIN if they are given the minimum assignment of /64 of IPv6 space. This additional effort may prevent ISP's from giving IPv6 addresses because of the additional expense of registering those addresses with ARIN, which is not required for IPv4.The administrative burden of 100% customer registration of IPv6 customers is unreasonable, when such is not required for those customers receiving only IPv4 connections. From john at egh.com Mon Sep 18 12:14:18 2017 From: john at egh.com (John Santos) Date: Mon, 18 Sep 2017 12:14:18 -0400 Subject: [arin-ppml] Revised - Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements In-Reply-To: <848f1990-7a83-563e-1bef-c6b57c0cd1af@arin.net> References: <848f1990-7a83-563e-1bef-c6b57c0cd1af@arin.net> Message-ID: <69335cd6-7fab-d3da-d3f4-a33bd5e69289@egh.com> On 9/18/2017 10:37 AM, ARIN wrote: > The following has been revised: > > * Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements [snip] > 4) Add new section 6.5.5.4 "Registration Requested by Recipient" of > the NRPM, to read: "If the downstream recipient of a static assignment > of /64 or more addresses requests publishing of that assignment in > ARIN's registration database, the ISP should register that assignment > as described in section 6.5.5.1." I have been under the impression that a common goal of most people proposing NRPM changes is to eliminate the use of the term "ISP", since it is not defined in the policy and most or all the relevant sections also apply to other organizations that, while they re-allocate or reassign address space, are not, properly speaking, ISPs.? Shouldn't this says "LIR" or "provider" or some other more generic term? [snip] -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From farmer at umn.edu Mon Sep 18 12:48:27 2017 From: farmer at umn.edu (David Farmer) Date: Mon, 18 Sep 2017 11:48:27 -0500 Subject: [arin-ppml] Revised - Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements In-Reply-To: <69335cd6-7fab-d3da-d3f4-a33bd5e69289@egh.com> References: <848f1990-7a83-563e-1bef-c6b57c0cd1af@arin.net> <69335cd6-7fab-d3da-d3f4-a33bd5e69289@egh.com> Message-ID: This has gone back and forth over the years, some people think "LIR" is too abstract and some people think "ISP" is too specific. While ISP doesn't have it's own subsection under definitions it is discussed under "LIR", section 2.5, so I wouldn't say it's undefined. I think it's probably dangerous to make a hard and fast rule either way. I think it is probably best to think of "ISP" and "LIR" as synonyms, at least from an ARIN policy perspective, but just like many synonyms they have subtly different connotations. Thanks. On Mon, Sep 18, 2017 at 11:14 AM, John Santos wrote: > > > On 9/18/2017 10:37 AM, ARIN wrote: > >> The following has been revised: >> >> * Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements >> > [snip] > > 4) Add new section 6.5.5.4 "Registration Requested by Recipient" of the >> NRPM, to read: "If the downstream recipient of a static assignment of /64 >> or more addresses requests publishing of that assignment in ARIN's >> registration database, the ISP should register that assignment as described >> in section 6.5.5.1." >> > > I have been under the impression that a common goal of most people > proposing NRPM changes is to eliminate the use of the term "ISP", since it > is not defined in the policy and most or all the relevant sections also > apply to other organizations that, while they re-allocate or reassign > address space, are not, properly speaking, ISPs. Shouldn't this says "LIR" > or "provider" or some other more generic term? > > > [snip] > > -- > John Santos > Evans Griffiths & Hart, Inc. > 781-861-0670 ext 539 > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at semihuman.com Mon Sep 18 14:02:55 2017 From: chris at semihuman.com (Chris Woodfield) Date: Mon, 18 Sep 2017 11:02:55 -0700 Subject: [arin-ppml] Revised - Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements In-Reply-To: References: <848f1990-7a83-563e-1bef-c6b57c0cd1af@arin.net> <69335cd6-7fab-d3da-d3f4-a33bd5e69289@egh.com> Message-ID: <7BC78B52-4E04-47C2-AA1E-2F7F11178B9A@semihuman.com> I?d argue the opposite - when crafting policy, we must be precise in our language, and in general we must avoid ambiguous terms, unless there?s a specific goal to leaving a section of language open for interpretation (and even then, it must be clear whose interpretation reigns supreme). I?m a fan of the term LIR, even if it is somewhat abstract. Language clearly linking the two terms, defining an ISP as the most common example of an LIR, would be helpful as well. -C > On Sep 18, 2017, at 9:48 AM, David Farmer wrote: > > This has gone back and forth over the years, some people think "LIR" is too abstract and some people think "ISP" is too specific. While ISP doesn't have it's own subsection under definitions it is discussed under "LIR", section 2.5, so I wouldn't say it's undefined. I think it's probably dangerous to make a hard and fast rule either way. I think it is probably best to think of "ISP" and "LIR" as synonyms, at least from an ARIN policy perspective, but just like many synonyms they have subtly different connotations. > > Thanks. > > On Mon, Sep 18, 2017 at 11:14 AM, John Santos > wrote: > > > On 9/18/2017 10:37 AM, ARIN wrote: > The following has been revised: > > * Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements > [snip] > > 4) Add new section 6.5.5.4 "Registration Requested by Recipient" of the NRPM, to read: "If the downstream recipient of a static assignment of /64 or more addresses requests publishing of that assignment in ARIN's registration database, the ISP should register that assignment as described in section 6.5.5.1." > > I have been under the impression that a common goal of most people proposing NRPM changes is to eliminate the use of the term "ISP", since it is not defined in the policy and most or all the relevant sections also apply to other organizations that, while they re-allocate or reassign address space, are not, properly speaking, ISPs. Shouldn't this says "LIR" or "provider" or some other more generic term? > > > [snip] > > -- > John Santos > Evans Griffiths & Hart, Inc. > 781-861-0670 ext 539 > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =============================================== > _______________________________________________ > 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 kevinb at thewire.ca Mon Sep 18 14:32:19 2017 From: kevinb at thewire.ca (Kevin Blumberg) Date: Mon, 18 Sep 2017 18:32:19 +0000 Subject: [arin-ppml] Revised - Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements In-Reply-To: <7BC78B52-4E04-47C2-AA1E-2F7F11178B9A@semihuman.com> References: <848f1990-7a83-563e-1bef-c6b57c0cd1af@arin.net> <69335cd6-7fab-d3da-d3f4-a33bd5e69289@egh.com> <7BC78B52-4E04-47C2-AA1E-2F7F11178B9A@semihuman.com> Message-ID: <7E7773B523E82C478734E793E58F69E7A52A389F@SBS2011.thewireinc.local> The term ISP is used in the ARIN region but is also defined in such a way as to be almost synonym of LIR. In other regions, the term LIR is used in a different manner. 2.4. Local Internet Registry (LIR) A Local Internet Registry (LIR) is an IR that primarily assigns address space to the users of the network services that it provides. LIRs are generally Internet Service Providers (ISPs), whose customers are primarily end users and possibly other ISPs. LIR = 27 Times in NRPM ISP = 72 Times in NRPM The majority of LIR use is in IPv6 and the majority of ISP is in IPv4. Maybe a proposal to pick one would be in order, but until then I don?t think it matters as long as it is consistent with the wording used in the section. Thanks, Kevin Blumberg From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Chris Woodfield Sent: Monday, September 18, 2017 2:03 PM To: David Farmer ; arin-ppml at arin.net Subject: Re: [arin-ppml] Revised - Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements I?d argue the opposite - when crafting policy, we must be precise in our language, and in general we must avoid ambiguous terms, unless there?s a specific goal to leaving a section of language open for interpretation (and even then, it must be clear whose interpretation reigns supreme). I?m a fan of the term LIR, even if it is somewhat abstract. Language clearly linking the two terms, defining an ISP as the most common example of an LIR, would be helpful as well. -C On Sep 18, 2017, at 9:48 AM, David Farmer > wrote: This has gone back and forth over the years, some people think "LIR" is too abstract and some people think "ISP" is too specific. While ISP doesn't have it's own subsection under definitions it is discussed under "LIR", section 2.5, so I wouldn't say it's undefined. I think it's probably dangerous to make a hard and fast rule either way. I think it is probably best to think of "ISP" and "LIR" as synonyms, at least from an ARIN policy perspective, but just like many synonyms they have subtly different connotations. Thanks. On Mon, Sep 18, 2017 at 11:14 AM, John Santos > wrote: On 9/18/2017 10:37 AM, ARIN wrote: The following has been revised: * Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements [snip] 4) Add new section 6.5.5.4 "Registration Requested by Recipient" of the NRPM, to read: "If the downstream recipient of a static assignment of /64 or more addresses requests publishing of that assignment in ARIN's registration database, the ISP should register that assignment as described in section 6.5.5.1." I have been under the impression that a common goal of most people proposing NRPM changes is to eliminate the use of the term "ISP", since it is not defined in the policy and most or all the relevant sections also apply to other organizations that, while they re-allocate or reassign address space, are not, properly speaking, ISPs. Shouldn't this says "LIR" or "provider" or some other more generic term? [snip] -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Mon Sep 18 18:08:42 2017 From: owen at delong.com (Owen DeLong) Date: Mon, 18 Sep 2017 19:08:42 -0300 Subject: [arin-ppml] Revised - Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements In-Reply-To: <69335cd6-7fab-d3da-d3f4-a33bd5e69289@egh.com> References: <848f1990-7a83-563e-1bef-c6b57c0cd1af@arin.net> <69335cd6-7fab-d3da-d3f4-a33bd5e69289@egh.com> Message-ID: I refer you to section 6.5.1? 6.5.1. Terminology The terms ISP and LIR are used interchangeably in this document and any use of either term shall be construed to include both meanings. The term nibble boundary shall mean a network mask which aligns on a 4-bit boundary (in slash notation, /n, where n is evenly divisible by 4, allowing unit quantities of X such that 2^n=X where n is evenly divisible by 4, such as 16, 256, 4096, etc.) While it is a little unusual to have definitions outside of section 2, these were placed here in section 6.5.1 in order to avoid potential conflicts with certain language that was in section 4 at the time of writing. Owen > On Sep 18, 2017, at 1:14 PM, John Santos wrote: > > > > On 9/18/2017 10:37 AM, ARIN wrote: >> The following has been revised: >> >> * Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements > [snip] > >> 4) Add new section 6.5.5.4 "Registration Requested by Recipient" of the NRPM, to read: "If the downstream recipient of a static assignment of /64 or more addresses requests publishing of that assignment in ARIN's registration database, the ISP should register that assignment as described in section 6.5.5.1." > > I have been under the impression that a common goal of most people proposing NRPM changes is to eliminate the use of the term "ISP", since it is not defined in the policy and most or all the relevant sections also apply to other organizations that, while they re-allocate or reassign address space, are not, properly speaking, ISPs. Shouldn't this says "LIR" or "provider" or some other more generic term? > > > [snip] > > -- > John Santos > Evans Griffiths & Hart, Inc. > 781-861-0670 ext 539 > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hostmaster at uneedus.com Tue Sep 19 07:24:43 2017 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Tue, 19 Sep 2017 07:24:43 -0400 (EDT) Subject: [arin-ppml] Revised - Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements In-Reply-To: References: <848f1990-7a83-563e-1bef-c6b57c0cd1af@arin.net> <69335cd6-7fab-d3da-d3f4-a33bd5e69289@egh.com> Message-ID: Placing ISP/LIR in place of ISP might be the best way to avoid confusion. As has been pointed out, they are really one and the same. Otherwise, I think that everything else about the draft is good and support. One thing to consider for future discussion is that because of the nature of IPv6, and its end-to-end nature, and assignment of public addresses, that the difference between allocate and assign using IPv6 on a specific /64 segment used for public wifi or otherwise is becoming more fluid. With SLAAC, an address is formed in part using a MAC address, which according to the rules for MAC addresses is supposed to be unique. It could be argued that these addresses are in effect "static", which could be argued is an assignment of part of the host network's /64, in effect a static /128 of that network. Due to the rules of SLAAC this happens without involvement of the host network, other than router advertisements, since the MAC originates from the guest device, as a different device will have a different MAC address. The requirement of at least a /64 in the proposed 6.5.5.4 is good in that end user networks that have SLAAC cannot be required to register the /128 associated with someones MAC address on their request. Since this limit is in the proposal, I think we do not need to address the fact that end user networks running IPv6 and SLAAC in effect are assigning addresses to end user devices, even though they are not supposed to do this unless the addresses were allocated to them like an ISP/LIR. Unlike DHCP6, which has a time limit, one could argue that SLAAC addresses are static. Something to think about. Albert Erdmann Network Administrator Paradise On Line Inc. On Mon, 18 Sep 2017, Owen DeLong wrote: > I refer you to section 6.5.1??? > > 6.5.1. Terminology > > The terms ISP and LIR are used interchangeably in this document and any use of either term shall be construed to include both meanings. > The term nibble boundary shall mean a network mask which aligns on a 4-bit boundary (in slash notation, /n, where n is evenly divisible by 4, allowing unit quantities of X such that 2^n=X where n is evenly divisible by 4, such as 16, 256, 4096, etc.) > > While it is a little unusual to have definitions outside of section 2, these were placed here in section 6.5.1 in order to avoid potential conflicts with certain language that was in section 4 at the time of writing. > > Owen > >> On Sep 18, 2017, at 1:14 PM, John Santos wrote: >> >> >> >> On 9/18/2017 10:37 AM, ARIN wrote: >>> The following has been revised: >>> >>> * Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements >> [snip] >> >>> 4) Add new section 6.5.5.4 "Registration Requested by Recipient" of the NRPM, to read: "If the downstream recipient of a static assignment of /64 or more addresses requests publishing of that assignment in ARIN's registration database, the ISP should register that assignment as described in section 6.5.5.1." >> >> I have been under the impression that a common goal of most people proposing NRPM changes is to eliminate the use of the term "ISP", since it is not defined in the policy and most or all the relevant sections also apply to other organizations that, while they re-allocate or reassign address space, are not, properly speaking, ISPs. Shouldn't this says "LIR" or "provider" or some other more generic term? >> >> >> [snip] >> >> -- >> John Santos >> Evans Griffiths & Hart, Inc. >> 781-861-0670 ext 539 >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > > From andrew.dul at quark.net Tue Sep 19 11:21:20 2017 From: andrew.dul at quark.net (Andrew Dul) Date: Tue, 19 Sep 2017 08:21:20 -0700 Subject: [arin-ppml] Revised: Draft Policy ARIN-2017-8: Amend the Definition of Community Network In-Reply-To: References: Message-ID: <36ac1e47-b55b-ebb2-46b2-522248c783d1@quark.net> Hello all, We will be discussing this draft proposal at the upcoming ARIN meeting in San Jose. If you have comments on the updated draft posted below, we'd certainly like to hear from you so we can help shape the conversation in person. We have seen some support for this updated draft, but not a lot. Furthermore, have we addressed all of your concerns which you might have noted earlier on the 1st version of the policy text. Thanks, Andrew On 8/24/2017 8:22 AM, ARIN wrote: > > > Draft Policy ARIN-2017-8: Amend the Definition of Community Network > > Problem Statement: > > The Community Networks section of the NRPM has not been used since > implementation in January 2010. Proposal ARIN-2016-7, to increase the > number of use cases, was abandoned by the Advisory Council due to lack > of feedback. Proposal ARIN 2017-2, to remove all mention of community > networks from NRPM was met with opposition by the community. Many > responded that the definition of ?community network? was too narrow, > which could be the reason for lack of uptake. > > Policy statement: > > CURRENT NRPM TEXT: > > ?2.11. Community Network > > A community network is any network organized and operated by a > volunteer group operating as or under the fiscal support of a > nonprofit organization or university for the purpose of providing free > or low-cost connectivity to the residents of their local service area. > To be treated as a community network under ARIN policy, the applicant > must certify to ARIN that the community network staff is 100% > volunteers.? > > NEW NRPM TEXT: > > ?2.11 Community Network > > A community network is a network organized and operated by a volunteer > group, not-for-profit, non-profit, charitable organization, or > educational institution for the purpose of providing free or low-cost > connectivity, or other Information Technology services to persons or > entities within their community. Critical functions may be handled by > paid staff, but volunteers play a large role in offering services > available through community networks.? > > Comments: > > Timetable for implementation: Immediate > _ From chris at semihuman.com Tue Sep 19 11:29:16 2017 From: chris at semihuman.com (Chris Woodfield) Date: Tue, 19 Sep 2017 08:29:16 -0700 Subject: [arin-ppml] Revised: Draft Policy ARIN-2017-8: Amend the Definition of Community Network In-Reply-To: <36ac1e47-b55b-ebb2-46b2-522248c783d1@quark.net> References: <36ac1e47-b55b-ebb2-46b2-522248c783d1@quark.net> Message-ID: <4DE9EC12-82B9-4581-9544-C4915AC6AB21@semihuman.com> I support this, with the comment that the phrase ?volunteers play a large role? will be open to interpretation. Is this intentional? I?m fine if that is the case, but if not, I?d advocate for a more precise definition. Thanks, -C > On Sep 19, 2017, at 8:21 AM, Andrew Dul wrote: > > Hello all, > > We will be discussing this draft proposal at the upcoming ARIN meeting > in San Jose. If you have comments on the updated draft posted below, > we'd certainly like to hear from you so we can help shape the > conversation in person. > > We have seen some support for this updated draft, but not a lot. > Furthermore, have we addressed all of your concerns which you might have > noted earlier on the 1st version of the policy text. > > Thanks, > Andrew > > On 8/24/2017 8:22 AM, ARIN wrote: >> >> >> Draft Policy ARIN-2017-8: Amend the Definition of Community Network >> >> Problem Statement: >> >> The Community Networks section of the NRPM has not been used since >> implementation in January 2010. Proposal ARIN-2016-7, to increase the >> number of use cases, was abandoned by the Advisory Council due to lack >> of feedback. Proposal ARIN 2017-2, to remove all mention of community >> networks from NRPM was met with opposition by the community. Many >> responded that the definition of ?community network? was too narrow, >> which could be the reason for lack of uptake. >> >> Policy statement: >> >> CURRENT NRPM TEXT: >> >> ?2.11. Community Network >> >> A community network is any network organized and operated by a >> volunteer group operating as or under the fiscal support of a >> nonprofit organization or university for the purpose of providing free >> or low-cost connectivity to the residents of their local service area. >> To be treated as a community network under ARIN policy, the applicant >> must certify to ARIN that the community network staff is 100% >> volunteers.? >> >> NEW NRPM TEXT: >> >> ?2.11 Community Network >> >> A community network is a network organized and operated by a volunteer >> group, not-for-profit, non-profit, charitable organization, or >> educational institution for the purpose of providing free or low-cost >> connectivity, or other Information Technology services to persons or >> entities within their community. Critical functions may be handled by >> paid staff, but volunteers play a large role in offering services >> available through community networks.? >> >> Comments: >> >> Timetable for implementation: Immediate >> _ > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lsawyer at gci.com Tue Sep 19 12:28:41 2017 From: lsawyer at gci.com (Leif Sawyer) Date: Tue, 19 Sep 2017 16:28:41 +0000 Subject: [arin-ppml] Revised - Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements In-Reply-To: References: <848f1990-7a83-563e-1bef-c6b57c0cd1af@arin.net> <69335cd6-7fab-d3da-d3f4-a33bd5e69289@egh.com> Message-ID: The majority of devices no longer register on SLAAC with MAC-bound addresses. Privacy Extensions for Stateless Address Autoconfiguration in IPv6?, which is codified in RFC 4941 means randomly generated addresses on a rotating basis. You could disable SLAAC-PE, and get "effectively static" IPv6 - but it's really not. Leif From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of hostmaster at uneedus.com Sent: Tuesday, September 19, 2017 3:25 AM To: arin-ppml at arin.net Subject: Re: [arin-ppml] Revised - Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements [External Email] Placing ISP/LIR in place of ISP might be the best way to avoid confusion. As has been pointed out, they are really one and the same. Otherwise, I think that everything else about the draft is good and support. One thing to consider for future discussion is that because of the nature of IPv6, and its end-to-end nature, and assignment of public addresses, that the difference between allocate and assign using IPv6 on a specific /64 segment used for public wifi or otherwise is becoming more fluid. With SLAAC, an address is formed in part using a MAC address, which according to the rules for MAC addresses is supposed to be unique. It could be argued that these addresses are in effect "static", which could be argued is an assignment of part of the host network's /64, in effect a static /128 of that network. Due to the rules of SLAAC this happens without involvement of the host network, other than router advertisements, since the MAC originates from the guest device, as a different device will have a different MAC address. The requirement of at least a /64 in the proposed 6.5.5.4 is good in that end user networks that have SLAAC cannot be required to register the /128 associated with someones MAC address on their request. Since this limit is in the proposal, I think we do not need to address the fact that end user networks running IPv6 and SLAAC in effect are assigning addresses to end user devices, even though they are not supposed to do this unless the addresses were allocated to them like an ISP/LIR. Unlike DHCP6, which has a time limit, one could argue that SLAAC addresses are static. Something to think about. Albert Erdmann Network Administrator Paradise On Line Inc. On Mon, 18 Sep 2017, Owen DeLong wrote: > I refer you to section 6.5.1??? > > 6.5.1. Terminology > > The terms ISP and LIR are used interchangeably in this document and any use of either term shall be construed to include both meanings. > The term nibble boundary shall mean a network mask which aligns on a 4-bit boundary (in slash notation, /n, where n is evenly divisible by 4, allowing unit quantities of X such that 2^n=X where n is evenly divisible by 4, such as 16, 256, 4096, etc.) > > While it is a little unusual to have definitions outside of section 2, these were placed here in section 6.5.1 in order to avoid potential conflicts with certain language that was in section 4 at the time of writing. > > Owen > >> On Sep 18, 2017, at 1:14 PM, John Santos > wrote: >> >> >> >> On 9/18/2017 10:37 AM, ARIN wrote: >>> The following has been revised: >>> >>> * Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements >> [snip] >> >>> 4) Add new section 6.5.5.4 "Registration Requested by Recipient" of the NRPM, to read: "If the downstream recipient of a static assignment of /64 or more addresses requests publishing of that assignment in ARIN's registration database, the ISP should register that assignment as described in section 6.5.5.1." >> >> I have been under the impression that a common goal of most people proposing NRPM changes is to eliminate the use of the term "ISP", since it is not defined in the policy and most or all the relevant sections also apply to other organizations that, while they re-allocate or reassign address space, are not, properly speaking, ISPs. Shouldn't this says "LIR" or "provider" or some other more generic term? >> >> >> [snip] >> >> -- >> John Santos >> Evans Griffiths & Hart, Inc. >> 781-861-0670 ext 539 >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Tue Sep 19 13:17:04 2017 From: owen at delong.com (Owen DeLong) Date: Tue, 19 Sep 2017 14:17:04 -0300 Subject: [arin-ppml] Revised - Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements In-Reply-To: References: <848f1990-7a83-563e-1bef-c6b57c0cd1af@arin.net> <69335cd6-7fab-d3da-d3f4-a33bd5e69289@egh.com> Message-ID: <3DDC6227-B07C-40A7-90B7-C2EA5C705E37@delong.com> > On Sep 19, 2017, at 1:28 PM, Leif Sawyer wrote: > > The majority of devices no longer register on SLAAC with MAC-bound addresses. Technically, this isn?t true. The majority of devices now register both one or more privacy addresses _AND_ a MAC-bound address. The MAC-bound address on such devices is not used as a preferred or primary address for originating sessions, but can be used (if known by the remote device) as a stable address to connect to services provided by the host. > Privacy Extensions for Stateless Address Autoconfiguration in IPv6?, which is codified in RFC 4941 > means randomly generated addresses on a rotating basis. > > You could disable SLAAC-PE, and get "effectively static" IPv6 - but it's really not. I think the better consideration is that when we talk of allocation and/or assignment, we are talking of the allocation/assignment of network numbers end not of host-portions to end devices. As such, I don?t think that the blurring Albert perceives as being created by SLAAC truly exists regardless of whether it is static or not. Owen > > Leif > > > From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net ] On Behalf Of hostmaster at uneedus.com > Sent: Tuesday, September 19, 2017 3:25 AM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Revised - Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements > > [External Email] > > Placing ISP/LIR in place of ISP might be the best way to avoid confusion. > As has been pointed out, they are really one and the same. > > Otherwise, I think that everything else about the draft is good and > support. > > One thing to consider for future discussion is that because of the nature > of IPv6, and its end-to-end nature, and assignment of public addresses, > that the difference between allocate and assign using IPv6 on a specific > /64 segment used for public wifi or otherwise is becoming more fluid. > > With SLAAC, an address is formed in part using a MAC address, which > according to the rules for MAC addresses is supposed to be unique. It > could be argued that these addresses are in effect "static", which could > be argued is an assignment of part of the host network's /64, in effect a > static /128 of that network. Due to the rules of SLAAC this happens > without involvement of the host network, other than router advertisements, > since the MAC originates from the guest device, as a different device will > have a different MAC address. > > The requirement of at least a /64 in the proposed 6.5.5.4 is good in that > end user networks that have SLAAC cannot be required to register the /128 > associated with someones MAC address on their request. Since this limit > is in the proposal, I think we do not need to address the fact that end > user networks running IPv6 and SLAAC in effect are assigning addresses to > end user devices, even though they are not supposed to do this unless the > addresses were allocated to them like an ISP/LIR. Unlike DHCP6, which has > a time limit, one could argue that SLAAC addresses are static. > > Something to think about. > > Albert Erdmann > Network Administrator > Paradise On Line Inc. > > On Mon, 18 Sep 2017, Owen DeLong wrote: > > > I refer you to section 6.5.1??? > > > > 6.5.1. Terminology > > > > The terms ISP and LIR are used interchangeably in this document and any use of either term shall be construed to include both meanings. > > The term nibble boundary shall mean a network mask which aligns on a 4-bit boundary (in slash notation, /n, where n is evenly divisible by 4, allowing unit quantities of X such that 2^n=X where n is evenly divisible by 4, such as 16, 256, 4096, etc.) > > > > While it is a little unusual to have definitions outside of section 2, these were placed here in section 6.5.1 in order to avoid potential conflicts with certain language that was in section 4 at the time of writing. > > > > Owen > > > >> On Sep 18, 2017, at 1:14 PM, John Santos > wrote: > >> > >> > >> > >> On 9/18/2017 10:37 AM, ARIN wrote: > >>> The following has been revised: > >>> > >>> * Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements > >> [snip] > >> > >>> 4) Add new section 6.5.5.4 "Registration Requested by Recipient" of the NRPM, to read: "If the downstream recipient of a static assignment of /64 or more addresses requests publishing of that assignment in ARIN's registration database, the ISP should register that assignment as described in section 6.5.5.1." > >> > >> I have been under the impression that a common goal of most people proposing NRPM changes is to eliminate the use of the term "ISP", since it is not defined in the policy and most or all the relevant sections also apply to other organizations that, while they re-allocate or reassign address space, are not, properly speaking, ISPs. Shouldn't this says "LIR" or "provider" or some other more generic term? > >> > >> > >> [snip] > >> > >> -- > >> John Santos > >> Evans Griffiths & Hart, Inc. > >> 781-861-0670 ext 539 > >> > >> _______________________________________________ > >> PPML > >> You are receiving this message because you are subscribed to > >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). > >> Unsubscribe or manage your mailing list subscription at: > >> http://lists.arin.net/mailman/listinfo/arin-ppml > >> Please contact info at arin.net if you experience any issues. > > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Tue Sep 19 13:19:04 2017 From: owen at delong.com (Owen DeLong) Date: Tue, 19 Sep 2017 14:19:04 -0300 Subject: [arin-ppml] Revised: Draft Policy ARIN-2017-8: Amend the Definition of Community Network In-Reply-To: <4DE9EC12-82B9-4581-9544-C4915AC6AB21@semihuman.com> References: <36ac1e47-b55b-ebb2-46b2-522248c783d1@quark.net> <4DE9EC12-82B9-4581-9544-C4915AC6AB21@semihuman.com> Message-ID: I?d like to point out that I just learned of a community network that claims they did take advantage of the existing policy recently, so there is apparently at least one use of the present policy. I support this draft as an improvement to the existing policy, but I believe the argument that the community networks policy is never used no longer applies. Owen > On Sep 19, 2017, at 12:29 PM, Chris Woodfield wrote: > > I support this, with the comment that the phrase ?volunteers play a large role? will be open to interpretation. Is this intentional? I?m fine if that is the case, but if not, I?d advocate for a more precise definition. > > Thanks, > > -C > >> On Sep 19, 2017, at 8:21 AM, Andrew Dul > wrote: >> >> Hello all, >> >> We will be discussing this draft proposal at the upcoming ARIN meeting >> in San Jose. If you have comments on the updated draft posted below, >> we'd certainly like to hear from you so we can help shape the >> conversation in person. >> >> We have seen some support for this updated draft, but not a lot. >> Furthermore, have we addressed all of your concerns which you might have >> noted earlier on the 1st version of the policy text. >> >> Thanks, >> Andrew >> >> On 8/24/2017 8:22 AM, ARIN wrote: >>> >>> >>> Draft Policy ARIN-2017-8: Amend the Definition of Community Network >>> >>> Problem Statement: >>> >>> The Community Networks section of the NRPM has not been used since >>> implementation in January 2010. Proposal ARIN-2016-7, to increase the >>> number of use cases, was abandoned by the Advisory Council due to lack >>> of feedback. Proposal ARIN 2017-2, to remove all mention of community >>> networks from NRPM was met with opposition by the community. Many >>> responded that the definition of ?community network? was too narrow, >>> which could be the reason for lack of uptake. >>> >>> Policy statement: >>> >>> CURRENT NRPM TEXT: >>> >>> ?2.11. Community Network >>> >>> A community network is any network organized and operated by a >>> volunteer group operating as or under the fiscal support of a >>> nonprofit organization or university for the purpose of providing free >>> or low-cost connectivity to the residents of their local service area. >>> To be treated as a community network under ARIN policy, the applicant >>> must certify to ARIN that the community network staff is 100% >>> volunteers.? >>> >>> NEW NRPM TEXT: >>> >>> ?2.11 Community Network >>> >>> A community network is a network organized and operated by a volunteer >>> group, not-for-profit, non-profit, charitable organization, or >>> educational institution for the purpose of providing free or low-cost >>> connectivity, or other Information Technology services to persons or >>> entities within their community. Critical functions may be handled by >>> paid staff, but volunteers play a large role in offering services >>> available through community networks.? >>> >>> Comments: >>> >>> Timetable for implementation: Immediate >>> _ >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjones at vt.edu Tue Sep 19 15:19:59 2017 From: bjones at vt.edu (Brian Jones) Date: Tue, 19 Sep 2017 19:19:59 +0000 Subject: [arin-ppml] Revised: Draft Policy ARIN-2017-8: Amend the Definition of Community Network In-Reply-To: References: <36ac1e47-b55b-ebb2-46b2-522248c783d1@quark.net> <4DE9EC12-82B9-4581-9544-C4915AC6AB21@semihuman.com> Message-ID: On Tue, Sep 19, 2017 at 1:20 PM Owen DeLong wrote: > I?d like to point out that I just learned of a community network that > claims they did take advantage > of the existing policy recently, so there is apparently at least one use > of the present policy. > > I support this draft as an improvement to the existing policy, but I > believe the argument that the > community networks policy is never used no longer applies. > +1 As wireless becomes more prevalent in communities and small towns there may be an increase in the number of community networks who wish to use this part of the policy. > Owen > > On Sep 19, 2017, at 12:29 PM, Chris Woodfield wrote: > > I support this, with the comment that the phrase ?volunteers play a large > role? will be open to interpretation. Is this intentional? I?m fine if that > is the case, but if not, I?d advocate for a more precise definition. > > I also support this policy with the stipulation Chris makes here. It needs to be open to interpretation or flexible enough to allow for communities to request the needed resources without too much hassle while meeting the desirable documentation of resources needs of the ARIN community. -- Brian > Thanks, > > -C > > On Sep 19, 2017, at 8:21 AM, Andrew Dul wrote: > > Hello all, > > We will be discussing this draft proposal at the upcoming ARIN meeting > in San Jose. If you have comments on the updated draft posted below, > we'd certainly like to hear from you so we can help shape the > conversation in person. > > We have seen some support for this updated draft, but not a lot. > Furthermore, have we addressed all of your concerns which you might have > noted earlier on the 1st version of the policy text. > > Thanks, > Andrew > > On 8/24/2017 8:22 AM, ARIN wrote: > > > > Draft Policy ARIN-2017-8: Amend the Definition of Community Network > > Problem Statement: > > The Community Networks section of the NRPM has not been used since > implementation in January 2010. Proposal ARIN-2016-7, to increase the > number of use cases, was abandoned by the Advisory Council due to lack > of feedback. Proposal ARIN 2017-2, to remove all mention of community > networks from NRPM was met with opposition by the community. Many > responded that the definition of ?community network? was too narrow, > which could be the reason for lack of uptake. > > Policy statement: > > CURRENT NRPM TEXT: > > ?2.11. Community Network > > A community network is any network organized and operated by a > volunteer group operating as or under the fiscal support of a > nonprofit organization or university for the purpose of providing free > or low-cost connectivity to the residents of their local service area. > To be treated as a community network under ARIN policy, the applicant > must certify to ARIN that the community network staff is 100% > volunteers.? > > NEW NRPM TEXT: > > ?2.11 Community Network > > A community network is a network organized and operated by a volunteer > group, not-for-profit, non-profit, charitable organization, or > educational institution for the purpose of providing free or low-cost > connectivity, or other Information Technology services to persons or > entities within their community. Critical functions may be handled by > paid staff, but volunteers play a large role in offering services > available through community networks.? > > Comments: > > Timetable for implementation: Immediate > _ > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmer at umn.edu Tue Sep 19 15:28:36 2017 From: farmer at umn.edu (David Farmer) Date: Tue, 19 Sep 2017 14:28:36 -0500 Subject: [arin-ppml] Revised - Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements In-Reply-To: <3DDC6227-B07C-40A7-90B7-C2EA5C705E37@delong.com> References: <848f1990-7a83-563e-1bef-c6b57c0cd1af@arin.net> <69335cd6-7fab-d3da-d3f4-a33bd5e69289@egh.com> <3DDC6227-B07C-40A7-90B7-C2EA5C705E37@delong.com> Message-ID: I don't know if its a majority of devices yet, but with RFC8064 the use of IIDs based on MAC addresses are no longer recommended, and stable addresses are recommended to be generated on based on RFC7217. https://tools.ietf.org/html/rfc8064 https://tools.ietf.org/html/rfc7217 Now it will take a while for new code to completely permeate the industry, but I believe the latest updated for Windows, MAC OS, iOS, and Android, all use this new standard. I have anecdotal evidence, by playing with my iPhone that was just upgraded to iOS11 that it support this standard. I don't remember if this was a feature added iOS 10.X or not. I believe it is safe to say the majority of new devices no longer use an IID based on a MAC address. Other than the MAC address of the interface is one of the seeds into the pseudo-random algorithm. Thanks On Tue, Sep 19, 2017 at 12:17 PM, Owen DeLong wrote: > > On Sep 19, 2017, at 1:28 PM, Leif Sawyer wrote: > > The majority of devices no longer register on SLAAC with MAC-bound > addresses. > > > Technically, this isn?t true. > > The majority of devices now register both one or more privacy addresses > _AND_ a MAC-bound address. The MAC-bound address on such devices is not > used as a preferred or primary address for originating sessions, but can be > used (if known by the remote device) as a stable address to connect to > services provided by the host. > > > Privacy Extensions for Stateless Address Autoconfiguration in IPv6?, which > is codified in RFC 4941 > means randomly generated addresses on a rotating basis. > > You could disable SLAAC-PE, and get "effectively static" IPv6 - but it's > really not. > > > I think the better consideration is that when we talk of allocation and/or > assignment, we are talking of the allocation/assignment of network numbers > end not of host-portions to end devices. As such, I don?t think that the > blurring Albert perceives as being created by SLAAC truly exists regardless > of whether it is static or not. > > Owen > > > Leif > > > *From:* ARIN-PPML [mailto:arin-ppml-bounces at arin.net > ] *On Behalf Of *hostmaster at uneedus.com > *Sent:* Tuesday, September 19, 2017 3:25 AM > *To:* arin-ppml at arin.net > *Subject:* Re: [arin-ppml] Revised - Draft Policy ARIN-2017-5: Improved > IPv6 Registration Requirements > > [External Email] > > Placing ISP/LIR in place of ISP might be the best way to avoid confusion. > As has been pointed out, they are really one and the same. > > Otherwise, I think that everything else about the draft is good and > support. > > One thing to consider for future discussion is that because of the nature > of IPv6, and its end-to-end nature, and assignment of public addresses, > that the difference between allocate and assign using IPv6 on a specific > /64 segment used for public wifi or otherwise is becoming more fluid. > > With SLAAC, an address is formed in part using a MAC address, which > according to the rules for MAC addresses is supposed to be unique. It > could be argued that these addresses are in effect "static", which could > be argued is an assignment of part of the host network's /64, in effect a > static /128 of that network. Due to the rules of SLAAC this happens > without involvement of the host network, other than router advertisements, > > since the MAC originates from the guest device, as a different device will > > have a different MAC address. > > The requirement of at least a /64 in the proposed 6.5.5.4 is good in that > end user networks that have SLAAC cannot be required to register the /128 > associated with someones MAC address on their request. Since this limit > is in the proposal, I think we do not need to address the fact that end > user networks running IPv6 and SLAAC in effect are assigning addresses to > end user devices, even though they are not supposed to do this unless the > addresses were allocated to them like an ISP/LIR. Unlike DHCP6, which has > a time limit, one could argue that SLAAC addresses are static. > > Something to think about. > > Albert Erdmann > Network Administrator > Paradise On Line Inc. > > On Mon, 18 Sep 2017, Owen DeLong wrote: > > > I refer you to section 6.5.1??? > > > > 6.5.1. Terminology > > > > The terms ISP and LIR are used interchangeably in this document and any > use of either term shall be construed to include both meanings. > > The term nibble boundary shall mean a network mask which aligns on a > 4-bit boundary (in slash notation, /n, where n is evenly divisible by 4, > allowing unit quantities of X such that 2^n=X where n is evenly divisible > by 4, such as 16, 256, 4096, etc.) > > > > While it is a little unusual to have definitions outside of section 2, > these were placed here in section 6.5.1 in order to avoid potential > conflicts with certain language that was in section 4 at the time of > writing. > > > > Owen > > > >> On Sep 18, 2017, at 1:14 PM, John Santos wrote: > >> > >> > >> > >> On 9/18/2017 10:37 AM, ARIN wrote: > >>> The following has been revised: > >>> > >>> * Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements > >> [snip] > >> > >>> 4) Add new section 6.5.5.4 "Registration Requested by Recipient" of > the NRPM, to read: "If the downstream recipient of a static assignment of > /64 or more addresses requests publishing of that assignment in ARIN's > registration database, the ISP should register that assignment as described > in section 6.5.5.1." > >> > >> I have been under the impression that a common goal of most people > proposing NRPM changes is to eliminate the use of the term "ISP", since it > is not defined in the policy and most or all the relevant sections also > apply to other organizations that, while they re-allocate or reassign > address space, are not, properly speaking, ISPs. Shouldn't this says "LIR" > or "provider" or some other more generic term? > >> > >> > >> [snip] > >> > >> -- > >> John Santos > >> Evans Griffiths & Hart, Inc. > >> 781-861-0670 ext 539 <(781)%20861-0670> > >> > >> _______________________________________________ > >> 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. > -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Tue Sep 19 15:40:05 2017 From: owen at delong.com (Owen DeLong) Date: Tue, 19 Sep 2017 16:40:05 -0300 Subject: [arin-ppml] Revised - Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements In-Reply-To: References: <848f1990-7a83-563e-1bef-c6b57c0cd1af@arin.net> <69335cd6-7fab-d3da-d3f4-a33bd5e69289@egh.com> <3DDC6227-B07C-40A7-90B7-C2EA5C705E37@delong.com> Message-ID: Linux (Fedora 25) and MacOS (Sierra) at least, it?s still using stable addresses based on MAC address. Owen > On Sep 19, 2017, at 4:28 PM, David Farmer wrote: > > I don't know if its a majority of devices yet, but with RFC8064 the use of IIDs based on MAC addresses are no longer recommended, and stable addresses are recommended to be generated on based on RFC7217. > > https://tools.ietf.org/html/rfc8064 > https://tools.ietf.org/html/rfc7217 > > Now it will take a while for new code to completely permeate the industry, but I believe the latest updated for Windows, MAC OS, iOS, and Android, all use this new standard. I have anecdotal evidence, by playing with my iPhone that was just upgraded to iOS11 that it support this standard. I don't remember if this was a feature added iOS 10.X or not. > > I believe it is safe to say the majority of new devices no longer use an IID based on a MAC address. Other than the MAC address of the interface is one of the seeds into the pseudo-random algorithm. > > Thanks > > On Tue, Sep 19, 2017 at 12:17 PM, Owen DeLong > wrote: > >> On Sep 19, 2017, at 1:28 PM, Leif Sawyer > wrote: >> >> The majority of devices no longer register on SLAAC with MAC-bound addresses. > > Technically, this isn?t true. > > The majority of devices now register both one or more privacy addresses _AND_ a MAC-bound address. The MAC-bound address on such devices is not used as a preferred or primary address for originating sessions, but can be used (if known by the remote device) as a stable address to connect to services provided by the host. > >> Privacy Extensions for Stateless Address Autoconfiguration in IPv6?, which is codified in RFC 4941 >> means randomly generated addresses on a rotating basis. >> >> You could disable SLAAC-PE, and get "effectively static" IPv6 - but it's really not. > > I think the better consideration is that when we talk of allocation and/or assignment, we are talking of the allocation/assignment of network numbers end not of host-portions to end devices. As such, I don?t think that the blurring Albert perceives as being created by SLAAC truly exists regardless of whether it is static or not. > > Owen > >> >> Leif >> >> >> From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net ] On Behalf Of hostmaster at uneedus.com >> Sent: Tuesday, September 19, 2017 3:25 AM >> To: arin-ppml at arin.net >> Subject: Re: [arin-ppml] Revised - Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements >> >> [External Email] >> >> Placing ISP/LIR in place of ISP might be the best way to avoid confusion. >> As has been pointed out, they are really one and the same. >> >> Otherwise, I think that everything else about the draft is good and >> support. >> >> One thing to consider for future discussion is that because of the nature >> of IPv6, and its end-to-end nature, and assignment of public addresses, >> that the difference between allocate and assign using IPv6 on a specific >> /64 segment used for public wifi or otherwise is becoming more fluid. >> >> With SLAAC, an address is formed in part using a MAC address, which >> according to the rules for MAC addresses is supposed to be unique. It >> could be argued that these addresses are in effect "static", which could >> be argued is an assignment of part of the host network's /64, in effect a >> static /128 of that network. Due to the rules of SLAAC this happens >> without involvement of the host network, other than router advertisements, >> since the MAC originates from the guest device, as a different device will >> have a different MAC address. >> >> The requirement of at least a /64 in the proposed 6.5.5.4 is good in that >> end user networks that have SLAAC cannot be required to register the /128 >> associated with someones MAC address on their request. Since this limit >> is in the proposal, I think we do not need to address the fact that end >> user networks running IPv6 and SLAAC in effect are assigning addresses to >> end user devices, even though they are not supposed to do this unless the >> addresses were allocated to them like an ISP/LIR. Unlike DHCP6, which has >> a time limit, one could argue that SLAAC addresses are static. >> >> Something to think about. >> >> Albert Erdmann >> Network Administrator >> Paradise On Line Inc. >> >> On Mon, 18 Sep 2017, Owen DeLong wrote: >> >> > I refer you to section 6.5.1??? >> > >> > 6.5.1. Terminology >> > >> > The terms ISP and LIR are used interchangeably in this document and any use of either term shall be construed to include both meanings. >> > The term nibble boundary shall mean a network mask which aligns on a 4-bit boundary (in slash notation, /n, where n is evenly divisible by 4, allowing unit quantities of X such that 2^n=X where n is evenly divisible by 4, such as 16, 256, 4096, etc.) >> > >> > While it is a little unusual to have definitions outside of section 2, these were placed here in section 6.5.1 in order to avoid potential conflicts with certain language that was in section 4 at the time of writing. >> > >> > Owen >> > >> >> On Sep 18, 2017, at 1:14 PM, John Santos > wrote: >> >> >> >> >> >> >> >> On 9/18/2017 10:37 AM, ARIN wrote: >> >>> The following has been revised: >> >>> >> >>> * Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements >> >> [snip] >> >> >> >>> 4) Add new section 6.5.5.4 "Registration Requested by Recipient" of the NRPM, to read: "If the downstream recipient of a static assignment of /64 or more addresses requests publishing of that assignment in ARIN's registration database, the ISP should register that assignment as described in section 6.5.5.1." >> >> >> >> I have been under the impression that a common goal of most people proposing NRPM changes is to eliminate the use of the term "ISP", since it is not defined in the policy and most or all the relevant sections also apply to other organizations that, while they re-allocate or reassign address space, are not, properly speaking, ISPs. Shouldn't this says "LIR" or "provider" or some other more generic term? >> >> >> >> >> >> [snip] >> >> >> >> -- >> >> John Santos >> >> Evans Griffiths & Hart, Inc. >> >> 781-861-0670 ext 539 >> >> >> >> _______________________________________________ >> >> 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. > > > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From hostmaster at uneedus.com Tue Sep 19 16:05:54 2017 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Tue, 19 Sep 2017 16:05:54 -0400 (EDT) Subject: [arin-ppml] Revised - Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements In-Reply-To: References: <848f1990-7a83-563e-1bef-c6b57c0cd1af@arin.net> <69335cd6-7fab-d3da-d3f4-a33bd5e69289@egh.com> <3DDC6227-B07C-40A7-90B7-C2EA5C705E37@delong.com> Message-ID: While these OS's do use the privacy extensions by default for all outbound connections, and the addresses are changed every 24 hours or so, from what I see, they also listen on the MAC address based address as well, and if they accept inbound connections with their firewall, the MAC based address can be used inbound as well. Also, if there is a DHCP6 server, an additional address is also obtained, and the system listens on this address. With IPv6, most systems might have both the old and new privacy address configured (the new being the default for outbound) as well as DHCP6 and SLAAC based addresses all in use. Most do not release the privacy address until there is no longer any outbound connection using it. Ifconfig/ipconfig will show this fact, even on the latest OS's I simply brought it up as a possible counter argument, but in no case would I consider any of these addresses to be "Static". Also, older Android does not use DHCP6 or privacy addresses, leading to one of the biggest tracking leaks. Albert Erdmann Network Administrator Paradise On Line Inc. On Tue, 19 Sep 2017, David Farmer wrote: > I don't know if its a majority of devices yet, but with RFC8064 the use of > IIDs based on MAC addresses are no longer recommended, and stable addresses > are recommended to be generated on based on RFC7217. > > https://tools.ietf.org/html/rfc8064 > https://tools.ietf.org/html/rfc7217 > > Now it will take a while for new code to completely permeate the industry, > but I believe the latest updated for Windows, MAC OS, iOS, and Android, all > use this new standard. I have anecdotal evidence, by playing with my > iPhone that was just upgraded to iOS11 that it support this standard. I > don't remember if this was a feature added iOS 10.X or not. > > I believe it is safe to say the majority of new devices no longer use an > IID based on a MAC address. Other than the MAC address of the interface is > one of the seeds into the pseudo-random algorithm. > > Thanks > > On Tue, Sep 19, 2017 at 12:17 PM, Owen DeLong wrote: > >> >> On Sep 19, 2017, at 1:28 PM, Leif Sawyer wrote: >> >> The majority of devices no longer register on SLAAC with MAC-bound >> addresses. >> >> >> Technically, this isn???t true. >> >> The majority of devices now register both one or more privacy addresses >> _AND_ a MAC-bound address. The MAC-bound address on such devices is not >> used as a preferred or primary address for originating sessions, but can be >> used (if known by the remote device) as a stable address to connect to >> services provided by the host. >> >> >> Privacy Extensions for Stateless Address Autoconfiguration in IPv6???, which >> is codified in RFC 4941 >> means randomly generated addresses on a rotating basis. >> >> You could disable SLAAC-PE, and get "effectively static" IPv6 - but it's >> really not. >> >> >> I think the better consideration is that when we talk of allocation and/or >> assignment, we are talking of the allocation/assignment of network numbers >> end not of host-portions to end devices. As such, I don???t think that the >> blurring Albert perceives as being created by SLAAC truly exists regardless >> of whether it is static or not. >> >> Owen >> >> >> Leif >> >> >> *From:* ARIN-PPML [mailto:arin-ppml-bounces at arin.net >> ] *On Behalf Of *hostmaster at uneedus.com >> *Sent:* Tuesday, September 19, 2017 3:25 AM >> *To:* arin-ppml at arin.net >> *Subject:* Re: [arin-ppml] Revised - Draft Policy ARIN-2017-5: Improved >> IPv6 Registration Requirements >> >> [External Email] >> >> Placing ISP/LIR in place of ISP might be the best way to avoid confusion. >> As has been pointed out, they are really one and the same. >> >> Otherwise, I think that everything else about the draft is good and >> support. >> >> One thing to consider for future discussion is that because of the nature >> of IPv6, and its end-to-end nature, and assignment of public addresses, >> that the difference between allocate and assign using IPv6 on a specific >> /64 segment used for public wifi or otherwise is becoming more fluid. >> >> With SLAAC, an address is formed in part using a MAC address, which >> according to the rules for MAC addresses is supposed to be unique. It >> could be argued that these addresses are in effect "static", which could >> be argued is an assignment of part of the host network's /64, in effect a >> static /128 of that network. Due to the rules of SLAAC this happens >> without involvement of the host network, other than router advertisements, >> >> since the MAC originates from the guest device, as a different device will >> >> have a different MAC address. >> >> The requirement of at least a /64 in the proposed 6.5.5.4 is good in that >> end user networks that have SLAAC cannot be required to register the /128 >> associated with someones MAC address on their request. Since this limit >> is in the proposal, I think we do not need to address the fact that end >> user networks running IPv6 and SLAAC in effect are assigning addresses to >> end user devices, even though they are not supposed to do this unless the >> addresses were allocated to them like an ISP/LIR. Unlike DHCP6, which has >> a time limit, one could argue that SLAAC addresses are static. >> >> Something to think about. >> >> Albert Erdmann >> Network Administrator >> Paradise On Line Inc. >> >> On Mon, 18 Sep 2017, Owen DeLong wrote: >> >>> I refer you to section 6.5.1??????? >>> >>> 6.5.1. Terminology >>> >>> The terms ISP and LIR are used interchangeably in this document and any >> use of either term shall be construed to include both meanings. >>> The term nibble boundary shall mean a network mask which aligns on a >> 4-bit boundary (in slash notation, /n, where n is evenly divisible by 4, >> allowing unit quantities of X such that 2^n=X where n is evenly divisible >> by 4, such as 16, 256, 4096, etc.) >>> >>> While it is a little unusual to have definitions outside of section 2, >> these were placed here in section 6.5.1 in order to avoid potential >> conflicts with certain language that was in section 4 at the time of >> writing. >>> >>> Owen >>> >>>> On Sep 18, 2017, at 1:14 PM, John Santos wrote: >>>> >>>> >>>> >>>> On 9/18/2017 10:37 AM, ARIN wrote: >>>>> The following has been revised: >>>>> >>>>> * Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements >>>> [snip] >>>> >>>>> 4) Add new section 6.5.5.4 "Registration Requested by Recipient" of >> the NRPM, to read: "If the downstream recipient of a static assignment of >> /64 or more addresses requests publishing of that assignment in ARIN's >> registration database, the ISP should register that assignment as described >> in section 6.5.5.1." >>>> >>>> I have been under the impression that a common goal of most people >> proposing NRPM changes is to eliminate the use of the term "ISP", since it >> is not defined in the policy and most or all the relevant sections also >> apply to other organizations that, while they re-allocate or reassign >> address space, are not, properly speaking, ISPs. Shouldn't this says "LIR" >> or "provider" or some other more generic term? >>>> >>>> >>>> [snip] >>>> >>>> -- >>>> John Santos >>>> Evans Griffiths & Hart, Inc. >>>> 781-861-0670 ext 539 <(781)%20861-0670> >>>> >>>> _______________________________________________ >>>> 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. >> > > > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =============================================== > From akoch at wiscnet.net Wed Sep 20 11:53:14 2017 From: akoch at wiscnet.net (Andy Koch) Date: Wed, 20 Sep 2017 10:53:14 -0500 Subject: [arin-ppml] Revised: Draft Policy ARIN-2017-8: Amend the Definition of Community Network In-Reply-To: References: Message-ID: <59C28EEA.10007@wiscnet.net> On 24 August 2017 at 10:22:11, Arin wrote: > The following has been revised: > > * Draft Policy ARIN-2017-8: Amend the Definition of Community Network > > Revised text is below and can be found at: > https://www.arin.net/policy/proposals/2017_8.html I support this policy proposal to update the definition of community network. Andy -- Andy Koch Network Engineer WiscNet - Wisconsin's Research and Education Network Connecting People and Strategies 605 Science Drive Madison, WI 53711 608-210-3967 akoch at wiscnet.net | https://wiscnet.net/events From kevinb at thewire.ca Wed Sep 20 13:21:32 2017 From: kevinb at thewire.ca (Kevin Blumberg) Date: Wed, 20 Sep 2017 17:21:32 +0000 Subject: [arin-ppml] Revised: Draft Policy ARIN-2017-8: Amend the Definition of Community Network In-Reply-To: <36ac1e47-b55b-ebb2-46b2-522248c783d1@quark.net> References: <36ac1e47-b55b-ebb2-46b2-522248c783d1@quark.net> Message-ID: <7E7773B523E82C478734E793E58F69E7A52ADB6A@SBS2011.thewireinc.local> Andrew, Is this the current text of the policy? The text on 2017-8 on the website does not match. The text below includes " or other Information Technology services" which does not appear on the website (https://www.arin.net/policy/proposals/2017_8.html) Can you please confirm which is the correct version, I have written my repsonses based on the website. 1) Can a "Volunteer Group" sign the RSA? 2) Is charitable organization a synonym or fall under the umbrella of non-profit? 3) Why is the scope limited to post-secondary institution when many smaller communities would not have that? Could accredited educational institution be used instead? 4) I agree with Chris W. that "play a large role" is very ambigous. 5) The last sentence should be reworded completely. Critical functions may be handled by paid staff, implies that volunteers shouldn't handle Critical functions or that paid staff shouldn't handle menial work? Thanks, Kevin Blumberg -----Original Message----- From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Andrew Dul Sent: Tuesday, September 19, 2017 11:21 AM To: arin-ppml at arin.net Subject: Re: [arin-ppml] Revised: Draft Policy ARIN-2017-8: Amend the Definition of Community Network Hello all, We will be discussing this draft proposal at the upcoming ARIN meeting in San Jose. If you have comments on the updated draft posted below, we'd certainly like to hear from you so we can help shape the conversation in person. We have seen some support for this updated draft, but not a lot. Furthermore, have we addressed all of your concerns which you might have noted earlier on the 1st version of the policy text. Thanks, Andrew On 8/24/2017 8:22 AM, ARIN wrote: > > > Draft Policy ARIN-2017-8: Amend the Definition of Community Network > > Problem Statement: > > The Community Networks section of the NRPM has not been used since > implementation in January 2010. Proposal ARIN-2016-7, to increase the > number of use cases, was abandoned by the Advisory Council due to lack > of feedback. Proposal ARIN 2017-2, to remove all mention of community > networks from NRPM was met with opposition by the community. Many > responded that the definition of ?community network? was too narrow, > which could be the reason for lack of uptake. > > Policy statement: > > CURRENT NRPM TEXT: > > ?2.11. Community Network > > A community network is any network organized and operated by a > volunteer group operating as or under the fiscal support of a > nonprofit organization or university for the purpose of providing free > or low-cost connectivity to the residents of their local service area. > To be treated as a community network under ARIN policy, the applicant > must certify to ARIN that the community network staff is 100% > volunteers.? > > NEW NRPM TEXT: > > ?2.11 Community Network > > A community network is a network organized and operated by a volunteer > group, not-for-profit, non-profit, charitable organization, or > educational institution for the purpose of providing free or low-cost > connectivity, or other Information Technology services to persons or > entities within their community. Critical functions may be handled by > paid staff, but volunteers play a large role in offering services > available through community networks.? > > Comments: > > Timetable for implementation: Immediate _ _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From farmer at umn.edu Wed Sep 20 13:51:02 2017 From: farmer at umn.edu (David Farmer) Date: Wed, 20 Sep 2017 12:51:02 -0500 Subject: [arin-ppml] Revised: Draft Policy ARIN-2017-8: Amend the Definition of Community Network In-Reply-To: <7E7773B523E82C478734E793E58F69E7A52ADB6A@SBS2011.thewireinc.local> References: <36ac1e47-b55b-ebb2-46b2-522248c783d1@quark.net> <7E7773B523E82C478734E793E58F69E7A52ADB6A@SBS2011.thewireinc.local> Message-ID: Kevin, On that page (https://www.arin.net/policy/proposals/2017_8.html) the "current version" is higher on the page and the "earlier version" is lower on the page, below the marking; ########## Earlier Version ########## This is extra confusing in that both versions seem have the same version date of 24 August 2017. I believe the "earlier version" should have a version date of 22 August 2017, at least based on the information in Discussion Tracking section above. I have a request into Staff asking for this to be corrected. For Clarity the current version of the NEW NRPM TEXT is: "2.11 Community Network A community network is a network organized and operated by a volunteer group, not-for-profit, non-profit, charitable organization, or educational institution for the purpose of providing free or low-cost connectivity, or other Information Technology services to persons or entities within their community. Critical functions may be handled by paid staff, but volunteers play a large role in offering services available through community networks." Sorry about the confusion, hope that helps. On Wed, Sep 20, 2017 at 12:21 PM, Kevin Blumberg wrote: > Andrew, > > Is this the current text of the policy? > > The text on 2017-8 on the website does not match. The text below includes > " or other Information Technology services" which does not appear on the > website (https://www.arin.net/policy/proposals/2017_8.html) > > Can you please confirm which is the correct version, I have written my > repsonses based on the website. > > 1) Can a "Volunteer Group" sign the RSA? > 2) Is charitable organization a synonym or fall under the umbrella of > non-profit? > 3) Why is the scope limited to post-secondary institution when many > smaller communities would not have that? Could accredited educational > institution be used instead? > 4) I agree with Chris W. that "play a large role" is very ambigous. > 5) The last sentence should be reworded completely. Critical functions may > be handled by paid staff, implies that volunteers shouldn't handle Critical > functions or that paid staff shouldn't handle menial work? > > Thanks, > > Kevin Blumberg > -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevinb at thewire.ca Wed Sep 20 14:01:30 2017 From: kevinb at thewire.ca (Kevin Blumberg) Date: Wed, 20 Sep 2017 18:01:30 +0000 Subject: [arin-ppml] Revised: Draft Policy ARIN-2017-8: Amend the Definition of Community Network In-Reply-To: References: <36ac1e47-b55b-ebb2-46b2-522248c783d1@quark.net> <7E7773B523E82C478734E793E58F69E7A52ADB6A@SBS2011.thewireinc.local> Message-ID: <7E7773B523E82C478734E793E58F69E7A52ADFFC@SBS2011.thewireinc.local> David, I appreciate that, I missed it ? Given that I will add one more concern. I am opposed to the policy if it includes ?or other Information Technology services?. That would basically be any defined organization that has a website. Thanks, Kevin Blumberg From: David Farmer [mailto:farmer at umn.edu] Sent: Wednesday, September 20, 2017 1:51 PM To: Kevin Blumberg Cc: andrew.dul at quark.net; arin-ppml at arin.net Subject: Re: [arin-ppml] Revised: Draft Policy ARIN-2017-8: Amend the Definition of Community Network Kevin, On that page (https://www.arin.net/policy/proposals/2017_8.html) the "current version" is higher on the page and the "earlier version" is lower on the page, below the marking; ########## Earlier Version ########## This is extra confusing in that both versions seem have the same version date of 24 August 2017. I believe the "earlier version" should have a version date of 22 August 2017, at least based on the information in Discussion Tracking section above. I have a request into Staff asking for this to be corrected. For Clarity the current version of the NEW NRPM TEXT is: "2.11 Community Network A community network is a network organized and operated by a volunteer group, not-for-profit, non-profit, charitable organization, or educational institution for the purpose of providing free or low-cost connectivity, or other Information Technology services to persons or entities within their community. Critical functions may be handled by paid staff, but volunteers play a large role in offering services available through community networks." Sorry about the confusion, hope that helps. On Wed, Sep 20, 2017 at 12:21 PM, Kevin Blumberg > wrote: Andrew, Is this the current text of the policy? The text on 2017-8 on the website does not match. The text below includes " or other Information Technology services" which does not appear on the website (https://www.arin.net/policy/proposals/2017_8.html) Can you please confirm which is the correct version, I have written my repsonses based on the website. 1) Can a "Volunteer Group" sign the RSA? 2) Is charitable organization a synonym or fall under the umbrella of non-profit? 3) Why is the scope limited to post-secondary institution when many smaller communities would not have that? Could accredited educational institution be used instead? 4) I agree with Chris W. that "play a large role" is very ambigous. 5) The last sentence should be reworded completely. Critical functions may be handled by paid staff, implies that volunteers shouldn't handle Critical functions or that paid staff shouldn't handle menial work? Thanks, Kevin Blumberg -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From admin at wsfnet.org Wed Sep 20 15:54:09 2017 From: admin at wsfnet.org (Whitestone IT) Date: Wed, 20 Sep 2017 11:54:09 -0800 Subject: [arin-ppml] Revised: Draft Policy ARIN-2017-8: Amend the Definition of Community Network In-Reply-To: <7E7773B523E82C478734E793E58F69E7A52ADB6A@SBS2011.thewireinc.local> References: <36ac1e47-b55b-ebb2-46b2-522248c783d1@quark.net> <7E7773B523E82C478734E793E58F69E7A52ADB6A@SBS2011.thewireinc.local> Message-ID: On Wed, Sep 20, 2017 at 9:21 AM, Kevin Blumberg wrote: > Andrew, > > 3) Why is the scope limited to post-secondary institution when many > smaller communities would not have that? Could accredited educational > institution be used instead? > > Kevin &c, There are educational institutions that would perhaps qualify as a volunteer or non-profit that would not qualify as an accredited institution ? accreditation is largely outside the reach of organizations that I believe this policy is targeting. Is it necessary to limit to accredited educational institutions? Is it possible to have a for-profit educational institution that would otherwise qualify for a community network designation? Does the policy need to reference education at all? -- Jeremy Austin Whitestone, Alaska -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.dul at quark.net Wed Sep 20 17:45:29 2017 From: andrew.dul at quark.net (Andrew Dul) Date: Wed, 20 Sep 2017 14:45:29 -0700 Subject: [arin-ppml] Revised: Draft Policy ARIN-2017-8: Amend the Definition of Community Network In-Reply-To: <7E7773B523E82C478734E793E58F69E7A52ADB6A@SBS2011.thewireinc.local> References: <36ac1e47-b55b-ebb2-46b2-522248c783d1@quark.net> <7E7773B523E82C478734E793E58F69E7A52ADB6A@SBS2011.thewireinc.local> Message-ID: <80cd0ba1-91d6-1ca1-fdd0-f008d3c5c087@quark.net> On 9/20/2017 11:01 AM, Kevin Blumberg wrote: > > > I am opposed to the policy if it includes ?or other Information Technology services?. That would basically be any defined organization that has a website. Do you have a suggestion of what might be more appropriate wording?? We were trying to suggest that a community network might provide more than basic connectivity.? On 9/20/2017 10:21 AM, Kevin Blumberg wrote: > Andrew, > > Is this the current text of the policy? > > The text on 2017-8 on the website does not match. The text below includes " or other Information Technology services" which does not appear on the website (https://www.arin.net/policy/proposals/2017_8.html) > > Can you please confirm which is the correct version, I have written my repsonses based on the website. > > 1) Can a "Volunteer Group" sign the RSA? I'll let ARIN staff answer this part. > 2) Is charitable organization a synonym or fall under the umbrella of non-profit? My understanding is that this was intended as a synonym, a list of descriptors that could be used to define a community network. > 3) Why is the scope limited to post-secondary institution when many smaller communities would not have that? Could accredited educational institution be used instead? The text has been updated to "educational institution" > 4) I agree with Chris W. that "play a large role" is very ambigous. Do you have a suggestion of text that might be more descriptive?? For example would a percentage of revenue / wages ratio be applicable??? That was an idea, but I'm not sure one could easily come up with a ratio that works. > 5) The last sentence should be reworded completely. Critical functions may be handled by paid staff, implies that volunteers shouldn't handle Critical functions or that paid staff shouldn't handle menial work? Should we substitute "Critical" with "Some"? > > > > > -----Original Message----- > From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Andrew Dul > Sent: Tuesday, September 19, 2017 11:21 AM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Revised: Draft Policy ARIN-2017-8: Amend the Definition of Community Network > > Hello all, > > We will be discussing this draft proposal at the upcoming ARIN meeting in San Jose. If you have comments on the updated draft posted below, we'd certainly like to hear from you so we can help shape the conversation in person. > > We have seen some support for this updated draft, but not a lot. > Furthermore, have we addressed all of your concerns which you might have noted earlier on the 1st version of the policy text. > > Thanks, > Andrew > > On 8/24/2017 8:22 AM, ARIN wrote: >> >> Draft Policy ARIN-2017-8: Amend the Definition of Community Network >> >> Problem Statement: >> >> The Community Networks section of the NRPM has not been used since >> implementation in January 2010. Proposal ARIN-2016-7, to increase the >> number of use cases, was abandoned by the Advisory Council due to lack >> of feedback. Proposal ARIN 2017-2, to remove all mention of community >> networks from NRPM was met with opposition by the community. Many >> responded that the definition of ?community network? was too narrow, >> which could be the reason for lack of uptake. >> >> Policy statement: >> >> CURRENT NRPM TEXT: >> >> ?2.11. Community Network >> >> A community network is any network organized and operated by a >> volunteer group operating as or under the fiscal support of a >> nonprofit organization or university for the purpose of providing free >> or low-cost connectivity to the residents of their local service area. >> To be treated as a community network under ARIN policy, the applicant >> must certify to ARIN that the community network staff is 100% >> volunteers.? >> >> NEW NRPM TEXT: >> >> ?2.11 Community Network >> >> A community network is a network organized and operated by a volunteer >> group, not-for-profit, non-profit, charitable organization, or >> educational institution for the purpose of providing free or low-cost >> connectivity, or other Information Technology services to persons or >> entities within their community. Critical functions may be handled by >> paid staff, but volunteers play a large role in offering services >> available through community networks.? >> >> Comments: >> >> Timetable for implementation: Immediate _ > _______________________________________________ > PPML > You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmer at umn.edu Wed Sep 20 17:59:34 2017 From: farmer at umn.edu (David Farmer) Date: Wed, 20 Sep 2017 16:59:34 -0500 Subject: [arin-ppml] Revised: Draft Policy ARIN-2017-8: Amend the Definition of Community Network In-Reply-To: References: <36ac1e47-b55b-ebb2-46b2-522248c783d1@quark.net> <7E7773B523E82C478734E793E58F69E7A52ADB6A@SBS2011.thewireinc.local> Message-ID: The new version simply says "educational institutions". I'd like to suggest libraries should be added as well. Libraries and educational institutions historically are an important focal points for ensuring access to various services by broad segments of society. Ensuring everyone in society has access to education and information, are their primary missions. Ensuring everyone, especially the disadvantaged in their communities, has access to the Internet is frequently becoming an important strategy for them and critical to achieving success within their primary missions. Therefore, I believe it is important to, as broadly as possible, include both libraries and educational institutions, regardless of how they are organized. Thanks. On Wed, Sep 20, 2017 at 2:54 PM, Whitestone IT wrote: > > > On Wed, Sep 20, 2017 at 9:21 AM, Kevin Blumberg wrote: > >> Andrew, >> >> 3) Why is the scope limited to post-secondary institution when many >> smaller communities would not have that? Could accredited educational >> institution be used instead? >> >> > Kevin &c, > > There are educational institutions that would perhaps qualify as a > volunteer or non-profit that would not qualify as an accredited institution > ? accreditation is largely outside the reach of organizations that I > believe this policy is targeting. > > Is it necessary to limit to accredited educational institutions? Is it > possible to have a for-profit educational institution that would otherwise > qualify for a community network designation? > > Does the policy need to reference education at all? > > -- > Jeremy Austin > Whitestone, Alaska > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.dul at quark.net Wed Sep 20 18:00:50 2017 From: andrew.dul at quark.net (Andrew Dul) Date: Wed, 20 Sep 2017 15:00:50 -0700 Subject: [arin-ppml] Revised: Draft Policy ARIN-2017-8: Amend the Definition of Community Network In-Reply-To: References: <36ac1e47-b55b-ebb2-46b2-522248c783d1@quark.net> <7E7773B523E82C478734E793E58F69E7A52ADB6A@SBS2011.thewireinc.local> Message-ID: <0458d586-dcb6-4ed9-e147-c6f8ef2c2b18@quark.net> The current text uses the terms "volunteer group, not-for-profit, non-profit, charitable organization, or educational institution" My reading of this is that accreditation isn't a requirement.? The text could be rewritten to remove educational institutions, but some of the community networks one might imagine are educational organizations (which are government entities, not necessarily registered/chartered as non-profit organization) Andrew On 9/20/2017 12:54 PM, Whitestone IT wrote: > > > On Wed, Sep 20, 2017 at 9:21 AM, Kevin Blumberg > wrote: > > Andrew, > > 3) Why is the scope limited to post-secondary institution when > many smaller communities would not have that? Could accredited > educational institution be used instead? > > > Kevin &c, > > There are educational institutions that would perhaps qualify as a > volunteer or non-profit that would not qualify as an accredited > institution ? accreditation is largely outside the reach of > organizations that I believe this policy is targeting. > > Is it necessary to limit to accredited educational institutions? Is it > possible to have a for-profit educational institution that would > otherwise qualify for a community network designation? > > Does the policy need to reference education at all? > > -- > Jeremy Austin > Whitestone, Alaska -------------- next part -------------- An HTML attachment was scrubbed... URL: From admin at wsfnet.org Wed Sep 20 18:07:28 2017 From: admin at wsfnet.org (Whitestone IT) Date: Wed, 20 Sep 2017 14:07:28 -0800 Subject: [arin-ppml] Revised: Draft Policy ARIN-2017-8: Amend the Definition of Community Network In-Reply-To: <0458d586-dcb6-4ed9-e147-c6f8ef2c2b18@quark.net> References: <36ac1e47-b55b-ebb2-46b2-522248c783d1@quark.net> <7E7773B523E82C478734E793E58F69E7A52ADB6A@SBS2011.thewireinc.local> <0458d586-dcb6-4ed9-e147-c6f8ef2c2b18@quark.net> Message-ID: On Wed, Sep 20, 2017 at 2:00 PM, Andrew Dul wrote: > The current text uses the terms "volunteer group, not-for-profit, > non-profit, charitable organization, or educational institution" > > My reading of this is that accreditation isn't a requirement. The text > could be rewritten to remove educational institutions, but some of the > community networks one might imagine are educational organizations (which > are government entities, not necessarily registered/chartered as non-profit > organization) > Thanks, Andrew ? it's good to consider not just what structures run community networks today but which could arise in future. In my case I worked for a non-government educational organization that ran a community network. I think the current language is open-ended enough while signaling a fairly clear intent. -- Jeremy Austin Whitestone, Alaska -------------- next part -------------- An HTML attachment was scrubbed... URL: From narten at us.ibm.com Fri Sep 22 00:53:33 2017 From: narten at us.ibm.com (narten at us.ibm.com) Date: Fri, 22 Sep 2017 00:53:33 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201709220453.v8M4rXdB002273@rotala.raleigh.ibm.com> Total of 28 messages in the last 7 days. script run at: Fri Sep 22 00:53:28 EDT 2017 Messages | Bytes | Who --------+------+--------+----------+------------------------ 14.29% | 4 | 22.57% | 123230 | owen at delong.com 14.29% | 4 | 16.29% | 88944 | farmer at umn.edu 10.71% | 3 | 10.63% | 58031 | kevinb at thewire.ca 10.71% | 3 | 8.15% | 44518 | andrew.dul at quark.net 7.14% | 2 | 8.70% | 47504 | chris at semihuman.com 7.14% | 2 | 8.17% | 44634 | jschiller at google.com 7.14% | 2 | 5.13% | 28015 | hostmaster at uneedus.com 7.14% | 2 | 3.89% | 21254 | admin at wsfnet.org 7.14% | 2 | 2.85% | 15571 | john at egh.com 3.57% | 1 | 6.01% | 32804 | bjones at vt.edu 3.57% | 1 | 4.11% | 22460 | lsawyer at gci.com 3.57% | 1 | 1.87% | 10237 | info at arin.net 3.57% | 1 | 1.63% | 8881 | narten at us.ibm.com --------+------+--------+----------+------------------------ 100.00% | 28 |100.00% | 546083 | Total From kevinb at thewire.ca Fri Sep 22 01:40:56 2017 From: kevinb at thewire.ca (Kevin Blumberg) Date: Fri, 22 Sep 2017 05:40:56 +0000 Subject: [arin-ppml] Revised: Draft Policy ARIN-2017-8: Amend the Definition of Community Network In-Reply-To: <80cd0ba1-91d6-1ca1-fdd0-f008d3c5c087@quark.net> References: <36ac1e47-b55b-ebb2-46b2-522248c783d1@quark.net> <7E7773B523E82C478734E793E58F69E7A52ADB6A@SBS2011.thewireinc.local> <80cd0ba1-91d6-1ca1-fdd0-f008d3c5c087@quark.net> Message-ID: <7E7773B523E82C478734E793E58F69E7A52B32C1@SBS2011.thewireinc.local> Andrew, I don?t have a solution for the Information Technology text, other than to remove it. It creates a loophole that anything could be considered a Community Network. Replying to your answers. 2) Is charitable organization a synonym or fall under the umbrella of non-profit? AD: My understanding is that this was intended as a synonym, a list of descriptors that could be used to define a community network. KB: It would make sense to remove Charitable organization if it is only a synonym. 3) Why is the scope limited to post-secondary institution when many smaller communities would not have that? Could accredited educational institution be used instead? AD: The text has been updated to "educational institution" KB: My apologies on reading the wrong text from the website. Thanks for the clarification. 4) I agree with Chris W. that "play a large role" is very ambigous. AD: Do you have a suggestion of text that might be more descriptive? For example would a percentage of revenue / wages ratio be applicable? That was an idea, but I'm not sure one could easily come up with a ratio that works. KB: The word large could be 15%, depending on who you ask. In TCP/IP 1 percent loss is large. A non-specific term will more than likely default to the lowest possible. I would suggest that majority or 50% are more appropriate. 5) The last sentence should be reworded completely. Critical functions may be handled by paid staff, implies that volunteers shouldn't handle Critical functions or that paid staff shouldn't handle menial work? AD: Should we substitute "Critical" with "Some"? KB: Changing Critical to Some would be fine. Thanks, Kevin Blumberg From: Andrew Dul [mailto:andrew.dul at quark.net] Sent: Wednesday, September 20, 2017 5:45 PM To: Kevin Blumberg ; arin-ppml at arin.net Subject: Re: [arin-ppml] Revised: Draft Policy ARIN-2017-8: Amend the Definition of Community Network On 9/20/2017 11:01 AM, Kevin Blumberg wrote: > > > I am opposed to the policy if it includes ?or other Information Technology services?. That would basically be any defined organization that has a website. Do you have a suggestion of what might be more appropriate wording? We were trying to suggest that a community network might provide more than basic connectivity. On 9/20/2017 10:21 AM, Kevin Blumberg wrote: Andrew, Is this the current text of the policy? The text on 2017-8 on the website does not match. The text below includes " or other Information Technology services" which does not appear on the website (https://www.arin.net/policy/proposals/2017_8.html) Can you please confirm which is the correct version, I have written my repsonses based on the website. 1) Can a "Volunteer Group" sign the RSA? I'll let ARIN staff answer this part. 2) Is charitable organization a synonym or fall under the umbrella of non-profit? My understanding is that this was intended as a synonym, a list of descriptors that could be used to define a community network. 3) Why is the scope limited to post-secondary institution when many smaller communities would not have that? Could accredited educational institution be used instead? The text has been updated to "educational institution" 4) I agree with Chris W. that "play a large role" is very ambigous. Do you have a suggestion of text that might be more descriptive? For example would a percentage of revenue / wages ratio be applicable? That was an idea, but I'm not sure one could easily come up with a ratio that works. 5) The last sentence should be reworded completely. Critical functions may be handled by paid staff, implies that volunteers shouldn't handle Critical functions or that paid staff shouldn't handle menial work? Should we substitute "Critical" with "Some"? -----Original Message----- From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Andrew Dul Sent: Tuesday, September 19, 2017 11:21 AM To: arin-ppml at arin.net Subject: Re: [arin-ppml] Revised: Draft Policy ARIN-2017-8: Amend the Definition of Community Network Hello all, We will be discussing this draft proposal at the upcoming ARIN meeting in San Jose. If you have comments on the updated draft posted below, we'd certainly like to hear from you so we can help shape the conversation in person. We have seen some support for this updated draft, but not a lot. Furthermore, have we addressed all of your concerns which you might have noted earlier on the 1st version of the policy text. Thanks, Andrew On 8/24/2017 8:22 AM, ARIN wrote: Draft Policy ARIN-2017-8: Amend the Definition of Community Network Problem Statement: The Community Networks section of the NRPM has not been used since implementation in January 2010. Proposal ARIN-2016-7, to increase the number of use cases, was abandoned by the Advisory Council due to lack of feedback. Proposal ARIN 2017-2, to remove all mention of community networks from NRPM was met with opposition by the community. Many responded that the definition of ?community network? was too narrow, which could be the reason for lack of uptake. Policy statement: CURRENT NRPM TEXT: ?2.11. Community Network A community network is any network organized and operated by a volunteer group operating as or under the fiscal support of a nonprofit organization or university for the purpose of providing free or low-cost connectivity to the residents of their local service area. To be treated as a community network under ARIN policy, the applicant must certify to ARIN that the community network staff is 100% volunteers.? NEW NRPM TEXT: ?2.11 Community Network A community network is a network organized and operated by a volunteer group, not-for-profit, non-profit, charitable organization, or educational institution for the purpose of providing free or low-cost connectivity, or other Information Technology services to persons or entities within their community. Critical functions may be handled by paid staff, but volunteers play a large role in offering services available through community networks.? Comments: Timetable for implementation: Immediate _ _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at arin.net Tue Sep 26 13:31:03 2017 From: info at arin.net (ARIN) Date: Tue, 26 Sep 2017 13:31:03 -0400 Subject: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements Message-ID: On 21 September 2017, the ARIN Advisory Council (AC) advanced the following Draft Policy to Recommended Draft Policy status: ARIN-2017-5: Improved IPv6 Registration Requirements The text of the Recommended Draft Policy is below, and may also be found at: https://www.arin.net/policy/proposals/2017_5.html You are encouraged to discuss all Recommended Draft Policies on PPML prior to their presentation at the next ARIN Public Policy and Members Meeting. PPML and PPC discussions are invaluable to the AC when determining community consensus. The PDP can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Sean Hopkins Policy Analyst American Registry for Internet Numbers (ARIN) AC's Statement of Conformance with ARIN's Principles of Internet Number Resource Policy: This proposal is technically sound and enables fair and impartial number policy for easier IPv6 Registrations. The staff and legal review noted a single clarification issue which has been addressed. There is ample support for the proposal on PPML and no concerns have been raised by the community regarding the proposal. Problem Statement: Current ARIN policy has different WHOIS directory registration requirements for IPv4 vs IPv6 address assignments. IPv4 registration is triggered for an assignment of any address block equal to or greater than a /29 (i.e., eight IPv4 addresses). In the case of IPv6, registration occurs for an assignment of any block equal to or greater than a /64, which constitutes one entire IPv6 subnet and is the minimum block size for an allocation. Accordingly, there is a significant disparity between IPv4 and IPv6 WHOIS registration thresholds in the case of assignments, resulting in more work in the case of IPv6 than is the case for IPv4. There is no technical or policy rationale for the disparity, which could serve as a deterrent to more rapid IPv6 adoption. The purpose of this proposal is to eliminate the disparity and corresponding adverse consequences. Policy statement: 1) Alter section 6.5.5.1 "Reassignment information" of the NRPM to strike "assignment containing a /64 or more addresses" and change to "re-allocation, reassignment containing a /47 or more addresses, or subdelegation of any size that will be individually announced," and 2) Alter section 6.5.5.2. "Assignments visible within 7 days" of the NRPM to strike the text "4.2.3.7.1" and change to "6.5.5.1" and 3) Alter section 6.5.5.3.1. "Residential Customer Privacy" of the NRPM by deleting the phrase "holding /64 and larger blocks" and 4) Add new section 6.5.5.4 "Registration Requested by Recipient" of the NRPM, to read: "If the downstream recipient of a static assignment of /64 or more addresses requests publishing of that assignment in ARIN's registration database, the ISP should register that assignment as described in section 6.5.5.1." Comments: a. Timetable for implementation: Policy should be adopted as soon as possible. b. Anything else: Author Comments: IPv6 should not be more burdensome than the equivalent IPv4 network size. Currently, assignments of /29 or more of IPv4 space (8 addresses) require registration. The greatest majority of ISP customers who have assignments of IPv4 space are of a single IPv4 address which do not trigger any ARIN registration requirement when using IPv4. This is NOT true when these same exact customers use IPv6, as assignments of /64 or more of IPv6 space require registration. Beginning with RFC 3177, it has been standard practice to assign a minimum assignment of /64 to every customer end user site, and less is never used. This means that ALL IPv6 assignments, including those customers that only use a single IPv4 address must be registered with ARIN if they are given the minimum assignment of /64 of IPv6 space. This additional effort may prevent ISP's from giving IPv6 addresses because of the additional expense of registering those addresses with ARIN, which is not required for IPv4. The administrative burden of 100% customer registration of IPv6 customers is unreasonable, when such is not required for those customers receiving only IPv4 connections. From info at arin.net Tue Sep 26 13:32:20 2017 From: info at arin.net (ARIN) Date: Tue, 26 Sep 2017 13:32:20 -0400 Subject: [arin-ppml] Advisory Council Meeting Results - September 2017 Message-ID: <9d9ab141-d3b2-17be-2427-6391404ac23e@arin.net> In accordance with the Policy Development Process (PDP), the Advisory Council (AC) met on 21 September 2017. The AC has advanced the following to Recommended Draft Policy status (will be posted separately as such): * ARIN-2017-5: Improved IPv6 Registration Requirements The AC advances Draft Policies to Recommended Draft Policy status once they have been fully developed and meet ARIN's Principles of Internet Number Resource Policy. Specifically, these principles are: * Enabling Fair and Impartial Number Resource Administration * Technically Sound * Supported by the Community The AC is continuing to work on: * ARIN-2017-3: Update to NPRM 3.6: Annual Whois POC Validation * ARIN-2017-4: Remove Reciprocity Requirement for Inter-RIR Transfers * ARIN-2017-6: Improve Reciprocity Requirement for Inter-RIR Transfers * ARIN-2017-8: Amend the Definition of Community Network The PDP can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Sean Hopkins Policy Analyst American Registry for Internet Numbers (ARIN) From scottleibrand at gmail.com Tue Sep 26 13:36:51 2017 From: scottleibrand at gmail.com (Scott Leibrand) Date: Tue, 26 Sep 2017 10:36:51 -0700 Subject: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements In-Reply-To: References: Message-ID: +1 I support RDP ARIN-2017-5 as written. -Scott On Tue, Sep 26, 2017 at 10:31 AM, ARIN wrote: > On 21 September 2017, the ARIN Advisory Council (AC) advanced the > following Draft Policy to Recommended Draft Policy status: > > ARIN-2017-5: Improved IPv6 Registration Requirements > > The text of the Recommended Draft Policy is below, and may also be found > at: > > https://www.arin.net/policy/proposals/2017_5.html > > You are encouraged to discuss all Recommended Draft Policies on PPML > prior to their presentation at the next ARIN Public Policy and Members > Meeting. PPML and PPC discussions are invaluable to the AC when > determining community consensus. > > The PDP can be found at: > https://www.arin.net/policy/pdp.html > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > Regards, > > Sean Hopkins > Policy Analyst > American Registry for Internet Numbers (ARIN) > > > > AC's Statement of Conformance with ARIN's Principles of Internet Number > Resource Policy: > > This proposal is technically sound and enables fair and impartial number > policy for easier IPv6 Registrations. The staff and legal review noted a > single clarification issue which has been addressed. There is ample support > for the proposal on PPML and no concerns have been raised by the community > regarding the proposal. > > Problem Statement: > > Current ARIN policy has different WHOIS directory registration > requirements for IPv4 vs IPv6 address assignments. IPv4 registration is > triggered for an assignment of any address block equal to or greater than a > /29 (i.e., eight IPv4 addresses). In the case of IPv6, registration occurs > for an assignment of any block equal to or greater than a /64, which > constitutes one entire IPv6 subnet and is the minimum block size for an > allocation. Accordingly, there is a significant disparity between IPv4 and > IPv6 WHOIS registration thresholds in the case of assignments, resulting in > more work in the case of IPv6 than is the case for IPv4. There is no > technical or policy rationale for the disparity, which could serve as a > deterrent to more rapid IPv6 adoption. The purpose of this proposal is to > eliminate the disparity and corresponding adverse consequences. > > Policy statement: > > 1) Alter section 6.5.5.1 "Reassignment information" of the NRPM to strike > "assignment containing a /64 or more addresses" and change to > "re-allocation, reassignment containing a /47 or more addresses, or > subdelegation of any size that will be individually announced," > > and > > 2) Alter section 6.5.5.2. "Assignments visible within 7 days" of the NRPM > to strike the text "4.2.3.7.1" and change to "6.5.5.1" > > and > > 3) Alter section 6.5.5.3.1. "Residential Customer Privacy" of the NRPM by > deleting the phrase "holding /64 and larger blocks" > > and > > 4) Add new section 6.5.5.4 "Registration Requested by Recipient" of the > NRPM, to read: "If the downstream recipient of a static assignment of /64 > or more addresses requests publishing of that assignment in ARIN's > registration database, the ISP should register that assignment as described > in section 6.5.5.1." > > Comments: > > a. Timetable for implementation: > > Policy should be adopted as soon as possible. > > b. Anything else: > > Author Comments: > > IPv6 should not be more burdensome than the equivalent IPv4 network size. > Currently, assignments of /29 or more of IPv4 space (8 addresses) require > registration. The greatest majority of ISP customers who have assignments > of IPv4 space are of a single IPv4 address which do not trigger any ARIN > registration requirement when using IPv4. This is NOT true when these same > exact customers use IPv6, as assignments of /64 or more of IPv6 space > require registration. Beginning with RFC 3177, it has been standard > practice to assign a minimum assignment of /64 to every customer end user > site, and less is never used. This means that ALL IPv6 assignments, > including those customers that only use a single IPv4 address must be > registered with ARIN if they are given the minimum assignment of /64 of > IPv6 space. This additional effort may prevent ISP's from giving IPv6 > addresses because of the additional expense of registering those addresses > with ARIN, which is not required for IPv4. The administrative burden of > 100% customer registration of IPv6 customers is unreasonable, when such is > not required for those customers receiving only IPv4 connections. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at semihuman.com Tue Sep 26 14:06:19 2017 From: chris at semihuman.com (Chris Woodfield) Date: Tue, 26 Sep 2017 11:06:19 -0700 Subject: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements In-Reply-To: References: Message-ID: Support as written. Great work everyone on this! -C > On Sep 26, 2017, at 10:31 AM, ARIN wrote: > > On 21 September 2017, the ARIN Advisory Council (AC) advanced the following Draft Policy to Recommended Draft Policy status: > > ARIN-2017-5: Improved IPv6 Registration Requirements > > The text of the Recommended Draft Policy is below, and may also be found at: > > https://www.arin.net/policy/proposals/2017_5.html > > You are encouraged to discuss all Recommended Draft Policies on PPML > prior to their presentation at the next ARIN Public Policy and Members Meeting. PPML and PPC discussions are invaluable to the AC when > determining community consensus. > > The PDP can be found at: > https://www.arin.net/policy/pdp.html > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > Regards, > > Sean Hopkins > Policy Analyst > American Registry for Internet Numbers (ARIN) > > > > AC's Statement of Conformance with ARIN's Principles of Internet Number Resource Policy: > > This proposal is technically sound and enables fair and impartial number policy for easier IPv6 Registrations. The staff and legal review noted a single clarification issue which has been addressed. There is ample support for the proposal on PPML and no concerns have been raised by the community regarding the proposal. > > Problem Statement: > > Current ARIN policy has different WHOIS directory registration requirements for IPv4 vs IPv6 address assignments. IPv4 registration is triggered for an assignment of any address block equal to or greater than a /29 (i.e., eight IPv4 addresses). In the case of IPv6, registration occurs for an assignment of any block equal to or greater than a /64, which constitutes one entire IPv6 subnet and is the minimum block size for an allocation. Accordingly, there is a significant disparity between IPv4 and IPv6 WHOIS registration thresholds in the case of assignments, resulting in more work in the case of IPv6 than is the case for IPv4. There is no technical or policy rationale for the disparity, which could serve as a deterrent to more rapid IPv6 adoption. The purpose of this proposal is to eliminate the disparity and corresponding adverse consequences. > > Policy statement: > > 1) Alter section 6.5.5.1 "Reassignment information" of the NRPM to strike "assignment containing a /64 or more addresses" and change to "re-allocation, reassignment containing a /47 or more addresses, or subdelegation of any size that will be individually announced," > > and > > 2) Alter section 6.5.5.2. "Assignments visible within 7 days" of the NRPM to strike the text "4.2.3.7.1" and change to "6.5.5.1" > > and > > 3) Alter section 6.5.5.3.1. "Residential Customer Privacy" of the NRPM by deleting the phrase "holding /64 and larger blocks" > > and > > 4) Add new section 6.5.5.4 "Registration Requested by Recipient" of the NRPM, to read: "If the downstream recipient of a static assignment of /64 or more addresses requests publishing of that assignment in ARIN's registration database, the ISP should register that assignment as described in section 6.5.5.1." > > Comments: > > a. Timetable for implementation: > > Policy should be adopted as soon as possible. > > b. Anything else: > > Author Comments: > > IPv6 should not be more burdensome than the equivalent IPv4 network size. Currently, assignments of /29 or more of IPv4 space (8 addresses) require registration. The greatest majority of ISP customers who have assignments of IPv4 space are of a single IPv4 address which do not trigger any ARIN registration requirement when using IPv4. This is NOT true when these same exact customers use IPv6, as assignments of /64 or more of IPv6 space require registration. Beginning with RFC 3177, it has been standard practice to assign a minimum assignment of /64 to every customer end user site, and less is never used. This means that ALL IPv6 assignments, including those customers that only use a single IPv4 address must be registered with ARIN if they are given the minimum assignment of /64 of IPv6 space. This additional effort may prevent ISP's from giving IPv6 addresses because of the additional expense of registering those addresses with ARIN, which is not required for IPv4. The administrative burden of 100% customer registration of IPv6 customers is unreasonable, when such is not required for those customers receiving only IPv4 connections. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From jschiller at google.com Tue Sep 26 15:03:31 2017 From: jschiller at google.com (Jason Schiller) Date: Tue, 26 Sep 2017 15:03:31 -0400 Subject: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements In-Reply-To: References: Message-ID: current policy: 6.5.5.1. Reassignment information Each static IPv6 assignment containing a /64 or more addresses shall be registered in the WHOIS directory via SWIP or a distributed service which meets the standards set forth in section 3.2. Reassignment registrations shall include each client's organizational information, except where specifically exempted by this policy. 6.5.5.2. Assignments visible within 7 days All assignments shall be made visible as required in section 4.2.3.7.1 within seven calendar days of assignment. 6.5.5.3. Residential Subscribers 6.5.5.3.1. Residential Customer Privacy To maintain the privacy of their residential customers, an organization with downstream residential customers holding /64 and larger blocks may substitute that organization's name for the customer's name, e.g. 'Private Customer - XYZ Network', and the customer's street address may read 'Private Residence'. Each private downstream residential reassignment must have accurate upstream Abuse and Technical POCs visible on the WHOIS record for that block. New proposed policy: 6.5.5.1. Reassignment information Each static IPv6 + re-allocation, reassignment containing a /47 or more addresses, or subdelegation of any + size that will be individually announced, shall be registered in the WHOIS directory via SWIP or a distributed service which meets the standards set forth in section 3.2. Reassignment registrations shall include each client's organizational information, except where specifically exempted by this policy. 6.5.5.2. Assignments visible within 7 days All assignments shall be made visible as required in section + 6.5.5.1 within seven calendar days of assignment. 6.5.5.3. Residential Subscribers 6.5.5.3.1. Residential Customer Privacy To maintain the privacy of their residential customers, an organization with downstream residential customers may substitute that organization's name for the customer's name, e.g. 'Private Customer - XYZ Network', and the customer's street address may read 'Private Residence'. Each private downstream residential reassignment must have accurate upstream Abuse and Technical POCs visible on the WHOIS record for that block. 6.5.5.4 Registration Requested by Recipient If the downstream recipient of a static assignment of /64 or more addresses requests publishing of that assignment in ARIN's registration database, the ISP should register that assignment as described in section 6.5.5.1. On Tue, Sep 26, 2017 at 1:31 PM, ARIN wrote: > On 21 September 2017, the ARIN Advisory Council (AC) advanced the > following Draft Policy to Recommended Draft Policy status: > > ARIN-2017-5: Improved IPv6 Registration Requirements > > The text of the Recommended Draft Policy is below, and may also be found > at: > > https://www.arin.net/policy/proposals/2017_5.html > > You are encouraged to discuss all Recommended Draft Policies on PPML > prior to their presentation at the next ARIN Public Policy and Members > Meeting. PPML and PPC discussions are invaluable to the AC when > determining community consensus. > > The PDP can be found at: > https://www.arin.net/policy/pdp.html > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > Regards, > > Sean Hopkins > Policy Analyst > American Registry for Internet Numbers (ARIN) > > > > AC's Statement of Conformance with ARIN's Principles of Internet Number > Resource Policy: > > This proposal is technically sound and enables fair and impartial number > policy for easier IPv6 Registrations. The staff and legal review noted a > single clarification issue which has been addressed. There is ample support > for the proposal on PPML and no concerns have been raised by the community > regarding the proposal. > > Problem Statement: > > Current ARIN policy has different WHOIS directory registration > requirements for IPv4 vs IPv6 address assignments. IPv4 registration is > triggered for an assignment of any address block equal to or greater than a > /29 (i.e., eight IPv4 addresses). In the case of IPv6, registration occurs > for an assignment of any block equal to or greater than a /64, which > constitutes one entire IPv6 subnet and is the minimum block size for an > allocation. Accordingly, there is a significant disparity between IPv4 and > IPv6 WHOIS registration thresholds in the case of assignments, resulting in > more work in the case of IPv6 than is the case for IPv4. There is no > technical or policy rationale for the disparity, which could serve as a > deterrent to more rapid IPv6 adoption. The purpose of this proposal is to > eliminate the disparity and corresponding adverse consequences. > > Policy statement: > > 1) Alter section 6.5.5.1 "Reassignment information" of the NRPM to strike > "assignment containing a /64 or more addresses" and change to > "re-allocation, reassignment containing a /47 or more addresses, or > subdelegation of any size that will be individually announced," > > and > > 2) Alter section 6.5.5.2. "Assignments visible within 7 days" of the NRPM > to strike the text "4.2.3.7.1" and change to "6.5.5.1" > > and > > 3) Alter section 6.5.5.3.1. "Residential Customer Privacy" of the NRPM by > deleting the phrase "holding /64 and larger blocks" > > and > > 4) Add new section 6.5.5.4 "Registration Requested by Recipient" of the > NRPM, to read: "If the downstream recipient of a static assignment of /64 > or more addresses requests publishing of that assignment in ARIN's > registration database, the ISP should register that assignment as described > in section 6.5.5.1." > > Comments: > > a. Timetable for implementation: > > Policy should be adopted as soon as possible. > > b. Anything else: > > Author Comments: > > IPv6 should not be more burdensome than the equivalent IPv4 network size. > Currently, assignments of /29 or more of IPv4 space (8 addresses) require > registration. The greatest majority of ISP customers who have assignments > of IPv4 space are of a single IPv4 address which do not trigger any ARIN > registration requirement when using IPv4. This is NOT true when these same > exact customers use IPv6, as assignments of /64 or more of IPv6 space > require registration. Beginning with RFC 3177, it has been standard > practice to assign a minimum assignment of /64 to every customer end user > site, and less is never used. This means that ALL IPv6 assignments, > including those customers that only use a single IPv4 address must be > registered with ARIN if they are given the minimum assignment of /64 of > IPv6 space. This additional effort may prevent ISP's from giving IPv6 > addresses because of the additional expense of registering those addresses > with ARIN, which is not required for IPv4. The administrative burden of > 100% customer registration of IPv6 customers is unreasonable, when such is > not required for those customers receiving only IPv4 connections. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jschiller at google.com Tue Sep 26 15:18:08 2017 From: jschiller at google.com (Jason Schiller) Date: Tue, 26 Sep 2017 15:18:08 -0400 Subject: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements In-Reply-To: References: Message-ID: I oppose as written. There should not be a different standard of requirement for: - re-allocation - reassignment containing a /47 or more addresses - subdelegation of any size that will be individually announced which is "shall" and Registration Requested by Recipient which is "should" I would support if they are both "shall". Can ARIN staff discuss what actions it will take if an ISP's down stream customer contacts them and explains that their ISP refuses to SWIP their reassignment to them? Will they do anything more than reach out to the ISP and tell them they "should" SWIP it? How does this course of action differ if the customer intends to route the space individually? How does this course of action differ if the customer holds other direct allocations, and or re-allocates for another provider? How does this course of action differ if the customer has down stream customers? ___Jason On Tue, Sep 26, 2017 at 3:03 PM, Jason Schiller wrote: > current policy: > > 6.5.5.1. Reassignment information > Each static IPv6 assignment containing a /64 or more addresses shall be > registered in > the WHOIS directory via SWIP or a distributed service which meets the > standards set forth in > section 3.2. Reassignment registrations shall include each client's > organizational information, > except where specifically exempted by this policy. > > 6.5.5.2. Assignments visible within 7 days > All assignments shall be made visible as required in section 4.2.3.7.1 > within seven calendar > days of assignment. > > 6.5.5.3. Residential Subscribers > 6.5.5.3.1. Residential Customer Privacy > To maintain the privacy of their residential customers, an organization > with downstream > residential customers holding /64 and larger blocks may substitute that > organization's > name for the customer's name, e.g. 'Private Customer - XYZ Network', and > the customer's > street address may read 'Private Residence'. Each private downstream > residential > reassignment must have accurate upstream Abuse and Technical POCs > visible on the > WHOIS record for that block. > > > New proposed policy: > > 6.5.5.1. Reassignment information > Each static IPv6 > + re-allocation, reassignment containing a /47 or more addresses, or > subdelegation of any > + size that will be individually announced, > > shall be registered in > the WHOIS directory via SWIP or a distributed service which meets the > standards set forth in > section 3.2. Reassignment registrations shall include each client's > organizational information, > except where specifically exempted by this policy. > > 6.5.5.2. Assignments visible within 7 days > All assignments shall be made visible as required in section > + 6.5.5.1 > within seven calendar > days of assignment. > > 6.5.5.3. Residential Subscribers > 6.5.5.3.1. Residential Customer Privacy > To maintain the privacy of their residential customers, an organization > with downstream > residential customers > may substitute that organization's > name for the customer's name, e.g. 'Private Customer - XYZ Network', and > the customer's > street address may read 'Private Residence'. Each private downstream > residential > reassignment must have accurate upstream Abuse and Technical POCs > visible on the > WHOIS record for that block. > > 6.5.5.4 Registration Requested by Recipient > If the downstream recipient of a static assignment of /64 or more > addresses requests > publishing of that assignment in ARIN's registration database, the ISP > should register > that assignment as described in section 6.5.5.1. > > On Tue, Sep 26, 2017 at 1:31 PM, ARIN wrote: > >> On 21 September 2017, the ARIN Advisory Council (AC) advanced the >> following Draft Policy to Recommended Draft Policy status: >> >> ARIN-2017-5: Improved IPv6 Registration Requirements >> >> The text of the Recommended Draft Policy is below, and may also be found >> at: >> >> https://www.arin.net/policy/proposals/2017_5.html >> >> You are encouraged to discuss all Recommended Draft Policies on PPML >> prior to their presentation at the next ARIN Public Policy and Members >> Meeting. PPML and PPC discussions are invaluable to the AC when >> determining community consensus. >> >> The PDP can be found at: >> https://www.arin.net/policy/pdp.html >> >> Draft Policies and Proposals under discussion can be found at: >> https://www.arin.net/policy/proposals/index.html >> >> Regards, >> >> Sean Hopkins >> Policy Analyst >> American Registry for Internet Numbers (ARIN) >> >> >> >> AC's Statement of Conformance with ARIN's Principles of Internet Number >> Resource Policy: >> >> This proposal is technically sound and enables fair and impartial number >> policy for easier IPv6 Registrations. The staff and legal review noted a >> single clarification issue which has been addressed. There is ample support >> for the proposal on PPML and no concerns have been raised by the community >> regarding the proposal. >> >> Problem Statement: >> >> Current ARIN policy has different WHOIS directory registration >> requirements for IPv4 vs IPv6 address assignments. IPv4 registration is >> triggered for an assignment of any address block equal to or greater than a >> /29 (i.e., eight IPv4 addresses). In the case of IPv6, registration occurs >> for an assignment of any block equal to or greater than a /64, which >> constitutes one entire IPv6 subnet and is the minimum block size for an >> allocation. Accordingly, there is a significant disparity between IPv4 and >> IPv6 WHOIS registration thresholds in the case of assignments, resulting in >> more work in the case of IPv6 than is the case for IPv4. There is no >> technical or policy rationale for the disparity, which could serve as a >> deterrent to more rapid IPv6 adoption. The purpose of this proposal is to >> eliminate the disparity and corresponding adverse consequences. >> >> Policy statement: >> >> 1) Alter section 6.5.5.1 "Reassignment information" of the NRPM to strike >> "assignment containing a /64 or more addresses" and change to >> "re-allocation, reassignment containing a /47 or more addresses, or >> subdelegation of any size that will be individually announced," >> >> and >> >> 2) Alter section 6.5.5.2. "Assignments visible within 7 days" of the NRPM >> to strike the text "4.2.3.7.1" and change to "6.5.5.1" >> >> and >> >> 3) Alter section 6.5.5.3.1. "Residential Customer Privacy" of the NRPM by >> deleting the phrase "holding /64 and larger blocks" >> >> and >> >> 4) Add new section 6.5.5.4 "Registration Requested by Recipient" of the >> NRPM, to read: "If the downstream recipient of a static assignment of /64 >> or more addresses requests publishing of that assignment in ARIN's >> registration database, the ISP should register that assignment as described >> in section 6.5.5.1." >> >> Comments: >> >> a. Timetable for implementation: >> >> Policy should be adopted as soon as possible. >> >> b. Anything else: >> >> Author Comments: >> >> IPv6 should not be more burdensome than the equivalent IPv4 network size. >> Currently, assignments of /29 or more of IPv4 space (8 addresses) require >> registration. The greatest majority of ISP customers who have assignments >> of IPv4 space are of a single IPv4 address which do not trigger any ARIN >> registration requirement when using IPv4. This is NOT true when these same >> exact customers use IPv6, as assignments of /64 or more of IPv6 space >> require registration. Beginning with RFC 3177, it has been standard >> practice to assign a minimum assignment of /64 to every customer end user >> site, and less is never used. This means that ALL IPv6 assignments, >> including those customers that only use a single IPv4 address must be >> registered with ARIN if they are given the minimum assignment of /64 of >> IPv6 space. This additional effort may prevent ISP's from giving IPv6 >> addresses because of the additional expense of registering those addresses >> with ARIN, which is not required for IPv4. The administrative burden of >> 100% customer registration of IPv6 customers is unreasonable, when such is >> not required for those customers receiving only IPv4 connections. >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> > > > > -- > _______________________________________________________ > Jason Schiller|NetOps|jschiller at google.com|571-266-0006 <(571)%20266-0006> > > -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjones at vt.edu Tue Sep 26 20:44:31 2017 From: bjones at vt.edu (Brian Jones) Date: Wed, 27 Sep 2017 00:44:31 +0000 Subject: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements In-Reply-To: References: Message-ID: Support RDP ARIN 2017-5: Improved IPv6 Registration Requirements as written. -- Brian Jones On Tue, Sep 26, 2017 at 1:37 PM Scott Leibrand wrote: > +1 > > I support RDP ARIN-2017-5 as written. > > -Scott > > On Tue, Sep 26, 2017 at 10:31 AM, ARIN wrote: > >> On 21 September 2017, the ARIN Advisory Council (AC) advanced the >> following Draft Policy to Recommended Draft Policy status: >> >> ARIN-2017-5: Improved IPv6 Registration Requirements >> >> The text of the Recommended Draft Policy is below, and may also be found >> at: >> >> https://www.arin.net/policy/proposals/2017_5.html >> >> You are encouraged to discuss all Recommended Draft Policies on PPML >> prior to their presentation at the next ARIN Public Policy and Members >> Meeting. PPML and PPC discussions are invaluable to the AC when >> determining community consensus. >> >> The PDP can be found at: >> https://www.arin.net/policy/pdp.html >> >> Draft Policies and Proposals under discussion can be found at: >> https://www.arin.net/policy/proposals/index.html >> >> Regards, >> >> Sean Hopkins >> Policy Analyst >> American Registry for Internet Numbers (ARIN) >> >> >> >> AC's Statement of Conformance with ARIN's Principles of Internet Number >> Resource Policy: >> >> This proposal is technically sound and enables fair and impartial number >> policy for easier IPv6 Registrations. The staff and legal review noted a >> single clarification issue which has been addressed. There is ample support >> for the proposal on PPML and no concerns have been raised by the community >> regarding the proposal. >> >> Problem Statement: >> >> Current ARIN policy has different WHOIS directory registration >> requirements for IPv4 vs IPv6 address assignments. IPv4 registration is >> triggered for an assignment of any address block equal to or greater than a >> /29 (i.e., eight IPv4 addresses). In the case of IPv6, registration occurs >> for an assignment of any block equal to or greater than a /64, which >> constitutes one entire IPv6 subnet and is the minimum block size for an >> allocation. Accordingly, there is a significant disparity between IPv4 and >> IPv6 WHOIS registration thresholds in the case of assignments, resulting in >> more work in the case of IPv6 than is the case for IPv4. There is no >> technical or policy rationale for the disparity, which could serve as a >> deterrent to more rapid IPv6 adoption. The purpose of this proposal is to >> eliminate the disparity and corresponding adverse consequences. >> >> Policy statement: >> >> 1) Alter section 6.5.5.1 "Reassignment information" of the NRPM to strike >> "assignment containing a /64 or more addresses" and change to >> "re-allocation, reassignment containing a /47 or more addresses, or >> subdelegation of any size that will be individually announced," >> >> and >> >> 2) Alter section 6.5.5.2. "Assignments visible within 7 days" of the NRPM >> to strike the text "4.2.3.7.1" and change to "6.5.5.1" >> >> and >> >> 3) Alter section 6.5.5.3.1. "Residential Customer Privacy" of the NRPM by >> deleting the phrase "holding /64 and larger blocks" >> >> and >> >> 4) Add new section 6.5.5.4 "Registration Requested by Recipient" of the >> NRPM, to read: "If the downstream recipient of a static assignment of /64 >> or more addresses requests publishing of that assignment in ARIN's >> registration database, the ISP should register that assignment as described >> in section 6.5.5.1." >> >> Comments: >> >> a. Timetable for implementation: >> >> Policy should be adopted as soon as possible. >> >> b. Anything else: >> >> Author Comments: >> >> IPv6 should not be more burdensome than the equivalent IPv4 network size. >> Currently, assignments of /29 or more of IPv4 space (8 addresses) require >> registration. The greatest majority of ISP customers who have assignments >> of IPv4 space are of a single IPv4 address which do not trigger any ARIN >> registration requirement when using IPv4. This is NOT true when these same >> exact customers use IPv6, as assignments of /64 or more of IPv6 space >> require registration. Beginning with RFC 3177, it has been standard >> practice to assign a minimum assignment of /64 to every customer end user >> site, and less is never used. This means that ALL IPv6 assignments, >> including those customers that only use a single IPv4 address must be >> registered with ARIN if they are given the minimum assignment of /64 of >> IPv6 space. This additional effort may prevent ISP's from giving IPv6 >> addresses because of the additional expense of registering those addresses >> with ARIN, which is not required for IPv4. The administrative burden of >> 100% customer registration of IPv6 customers is unreasonable, when such is >> not required for those customers receiving only IPv4 connections. >> _______________________________________________ >> 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 lsawyer at gci.com Tue Sep 26 20:54:42 2017 From: lsawyer at gci.com (Leif Sawyer) Date: Wed, 27 Sep 2017 00:54:42 +0000 Subject: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements In-Reply-To: References: Message-ID: Jason - The reason for the "should" (as opposed to shall, or must) is because, after careful consideration by staff and legal, there is no method of enforcement, by ARIN, upon the ISP to actually provide the registration. But leaving it in as "should" is to hopefully provide additional guidance to reticent companies who receive requests from their downstreams, as to what the appropriate action is. I hope that brings some clarity to your questions, and I'll let ARIN speak directly and specifically to them. From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Jason Schiller Sent: Tuesday, September 26, 2017 11:18 AM To: ARIN Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements [External Email] I oppose as written. There should not be a different standard of requirement for: - re-allocation - reassignment containing a /47 or more addresses - subdelegation of any size that will be individually announced which is "shall" and Registration Requested by Recipient which is "should" I would support if they are both "shall". Can ARIN staff discuss what actions it will take if an ISP's down stream customer contacts them and explains that their ISP refuses to SWIP their reassignment to them? Will they do anything more than reach out to the ISP and tell them they "should" SWIP it? How does this course of action differ if the customer intends to route the space individually? How does this course of action differ if the customer holds other direct allocations, and or re-allocates for another provider? How does this course of action differ if the customer has down stream customers? ___Jason On Tue, Sep 26, 2017 at 3:03 PM, Jason Schiller > wrote: current policy: 6.5.5.1. Reassignment information Each static IPv6 assignment containing a /64 or more addresses shall be registered in the WHOIS directory via SWIP or a distributed service which meets the standards set forth in section 3.2. Reassignment registrations shall include each client's organizational information, except where specifically exempted by this policy. 6.5.5.2. Assignments visible within 7 days All assignments shall be made visible as required in section 4.2.3.7.1 within seven calendar days of assignment. 6.5.5.3. Residential Subscribers 6.5.5.3.1. Residential Customer Privacy To maintain the privacy of their residential customers, an organization with downstream residential customers holding /64 and larger blocks may substitute that organization's name for the customer's name, e.g. 'Private Customer - XYZ Network', and the customer's street address may read 'Private Residence'. Each private downstream residential reassignment must have accurate upstream Abuse and Technical POCs visible on the WHOIS record for that block. New proposed policy: 6.5.5.1. Reassignment information Each static IPv6 + re-allocation, reassignment containing a /47 or more addresses, or subdelegation of any + size that will be individually announced, shall be registered in the WHOIS directory via SWIP or a distributed service which meets the standards set forth in section 3.2. Reassignment registrations shall include each client's organizational information, except where specifically exempted by this policy. 6.5.5.2. Assignments visible within 7 days All assignments shall be made visible as required in section + 6.5.5.1 within seven calendar days of assignment. 6.5.5.3. Residential Subscribers 6.5.5.3.1. Residential Customer Privacy To maintain the privacy of their residential customers, an organization with downstream residential customers may substitute that organization's name for the customer's name, e.g. 'Private Customer - XYZ Network', and the customer's street address may read 'Private Residence'. Each private downstream residential reassignment must have accurate upstream Abuse and Technical POCs visible on the WHOIS record for that block. 6.5.5.4 Registration Requested by Recipient If the downstream recipient of a static assignment of /64 or more addresses requests publishing of that assignment in ARIN's registration database, the ISP should register that assignment as described in section 6.5.5.1. On Tue, Sep 26, 2017 at 1:31 PM, ARIN > wrote: On 21 September 2017, the ARIN Advisory Council (AC) advanced the following Draft Policy to Recommended Draft Policy status: ARIN-2017-5: Improved IPv6 Registration Requirements The text of the Recommended Draft Policy is below, and may also be found at: https://www.arin.net/policy/proposals/2017_5.html You are encouraged to discuss all Recommended Draft Policies on PPML prior to their presentation at the next ARIN Public Policy and Members Meeting. PPML and PPC discussions are invaluable to the AC when determining community consensus. The PDP can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Sean Hopkins Policy Analyst American Registry for Internet Numbers (ARIN) AC's Statement of Conformance with ARIN's Principles of Internet Number Resource Policy: This proposal is technically sound and enables fair and impartial number policy for easier IPv6 Registrations. The staff and legal review noted a single clarification issue which has been addressed. There is ample support for the proposal on PPML and no concerns have been raised by the community regarding the proposal. Problem Statement: Current ARIN policy has different WHOIS directory registration requirements for IPv4 vs IPv6 address assignments. IPv4 registration is triggered for an assignment of any address block equal to or greater than a /29 (i.e., eight IPv4 addresses). In the case of IPv6, registration occurs for an assignment of any block equal to or greater than a /64, which constitutes one entire IPv6 subnet and is the minimum block size for an allocation. Accordingly, there is a significant disparity between IPv4 and IPv6 WHOIS registration thresholds in the case of assignments, resulting in more work in the case of IPv6 than is the case for IPv4. There is no technical or policy rationale for the disparity, which could serve as a deterrent to more rapid IPv6 adoption. The purpose of this proposal is to eliminate the disparity and corresponding adverse consequences. Policy statement: 1) Alter section 6.5.5.1 "Reassignment information" of the NRPM to strike "assignment containing a /64 or more addresses" and change to "re-allocation, reassignment containing a /47 or more addresses, or subdelegation of any size that will be individually announced," and 2) Alter section 6.5.5.2. "Assignments visible within 7 days" of the NRPM to strike the text "4.2.3.7.1" and change to "6.5.5.1" and 3) Alter section 6.5.5.3.1. "Residential Customer Privacy" of the NRPM by deleting the phrase "holding /64 and larger blocks" and 4) Add new section 6.5.5.4 "Registration Requested by Recipient" of the NRPM, to read: "If the downstream recipient of a static assignment of /64 or more addresses requests publishing of that assignment in ARIN's registration database, the ISP should register that assignment as described in section 6.5.5.1." Comments: a. Timetable for implementation: Policy should be adopted as soon as possible. b. Anything else: Author Comments: IPv6 should not be more burdensome than the equivalent IPv4 network size. Currently, assignments of /29 or more of IPv4 space (8 addresses) require registration. The greatest majority of ISP customers who have assignments of IPv4 space are of a single IPv4 address which do not trigger any ARIN registration requirement when using IPv4. This is NOT true when these same exact customers use IPv6, as assignments of /64 or more of IPv6 space require registration. Beginning with RFC 3177, it has been standard practice to assign a minimum assignment of /64 to every customer end user site, and less is never used. This means that ALL IPv6 assignments, including those customers that only use a single IPv4 address must be registered with ARIN if they are given the minimum assignment of /64 of IPv6 space. This additional effort may prevent ISP's from giving IPv6 addresses because of the additional expense of registering those addresses with ARIN, which is not required for IPv4. The administrative burden of 100% customer registration of IPv6 customers is unreasonable, when such is not required for those customers receiving only IPv4 connections. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jschiller at google.com Wed Sep 27 15:26:43 2017 From: jschiller at google.com (Jason Schiller) Date: Wed, 27 Sep 2017 15:26:43 -0400 Subject: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements In-Reply-To: References: Message-ID: Leif, Thanks for the info, but I really don't understand why the enforcement method is necessarily any different. Can you explain the difference? for example: - Customer One is a customer or provider Z with a /48 from provider Z's PA /32. - Customer One then buys transit from provider X, and asked provider X to route their /48 from provider Z. - Provider X refuses, saying that IP space is SWIP'd to provider Z as a /32 and not to customer One as a /48. - Customer One asks provider Z to reassign their /48 to their org ID. - Provider Z never responds, refuses, etc. - Customer One informs ARIN of provider Z's unwillingness to follow policy On the other hand: - Customer Two is a customer or provider Z with a /48 from provider Z's PA /32. - Customer Two has their own support and abuse team because they think it is mission critical that they are ultra responsive to abuse and outage issues. - Customer Two asks provider Z to reassign their /48 to their org ID, which lists their contact info. This will enable the Internet to contact Customer Two an get ultra responsive support. This is not only good service two Customer Two's managed content customer, but to the Internet at large and LEAs. - Provider Z never responds, refuses, etc. - Provider Z automatically logs abuse complaints sent to it wrt Customer Two's IP space. They count the number of requests and so long as they remain below their AUP, do nothing. - Customer Two informs ARIN of provider Z's unwillingness to follow policy Thanks, __Jason On Tue, Sep 26, 2017 at 8:54 PM, Leif Sawyer wrote: > Jason - > > > > The reason for the "should" (as opposed to shall, or must) is > because, after careful consideration by staff and legal, > > there is no method of enforcement, by ARIN, upon the ISP to actually > provide the registration. > > > > But leaving it in as "should" is to hopefully provide additional guidance > to reticent companies who receive > > requests from their downstreams, as to what the appropriate action is. > > > > I hope that brings some clarity to your questions, and I'll let ARIN speak > directly and specifically to them. > > > > *From:* ARIN-PPML [mailto:arin-ppml-bounces at arin.net] *On Behalf Of *Jason > Schiller > *Sent:* Tuesday, September 26, 2017 11:18 AM > *To:* ARIN > *Cc:* arin-ppml at arin.net > *Subject:* Re: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved > IPv6 Registration Requirements > > > > [External Email] > > I oppose as written. > > > > There should not be a different standard of requirement for: > > - re-allocation > > - reassignment containing a /47 or more addresses > > - subdelegation of any size that will be individually announced > > > > which is "shall" > > > > and Registration Requested by Recipient > > > > which is "should" > > > > > > I would support if they are both "shall". > > > > > > Can ARIN staff discuss what actions it will take if an ISP's > > down stream customer contacts them and explains that their > > ISP refuses to SWIP their reassignment to them? > > > > Will they do anything more than reach out to the ISP and tell > > them they "should" SWIP it? > > > > How does this course of action differ if the customer intends to > > route the space individually? > > > > How does this course of action differ if the customer holds other > > direct allocations, and or re-allocates for another provider? > > > > How does this course of action differ if the customer has down > > stream customers? > > > > ___Jason > > > > > > > > > > > > > > On Tue, Sep 26, 2017 at 3:03 PM, Jason Schiller > wrote: > > current policy: > > > > 6.5.5.1. Reassignment information > > Each static IPv6 assignment containing a /64 or more addresses shall be > registered in > > the WHOIS directory via SWIP or a distributed service which meets the > standards set forth in > > section 3.2. Reassignment registrations shall include each client's > organizational information, > > except where specifically exempted by this policy. > > > > 6.5.5.2. Assignments visible within 7 days > > All assignments shall be made visible as required in section 4.2.3.7.1 > within seven calendar > > days of assignment. > > > > 6.5.5.3. Residential Subscribers > > 6.5.5.3.1. Residential Customer Privacy > > To maintain the privacy of their residential customers, an organization > with downstream > > residential customers holding /64 and larger blocks may substitute that > organization's > > name for the customer's name, e.g. 'Private Customer - XYZ Network', and > the customer's > > street address may read 'Private Residence'. Each private downstream > residential > > reassignment must have accurate upstream Abuse and Technical POCs > visible on the > > WHOIS record for that block. > > > > > > New proposed policy: > > > > 6.5.5.1. Reassignment information > > Each static IPv6 > > + re-allocation, reassignment containing a /47 or more addresses, or > subdelegation of any > > + size that will be individually announced, > > > > shall be registered in > > the WHOIS directory via SWIP or a distributed service which meets the > standards set forth in > > section 3.2. Reassignment registrations shall include each client's > organizational information, > > except where specifically exempted by this policy. > > > > 6.5.5.2. Assignments visible within 7 days > > All assignments shall be made visible as required in section > > + 6.5.5.1 > > within seven calendar > > days of assignment. > > > > 6.5.5.3. Residential Subscribers > > 6.5.5.3.1. Residential Customer Privacy > > To maintain the privacy of their residential customers, an organization > with downstream > > residential customers > > may substitute that organization's > > name for the customer's name, e.g. 'Private Customer - XYZ Network', and > the customer's > > street address may read 'Private Residence'. Each private downstream > residential > > reassignment must have accurate upstream Abuse and Technical POCs > visible on the > > WHOIS record for that block. > > > > 6.5.5.4 Registration Requested by Recipient > > If the downstream recipient of a static assignment of /64 or more > addresses requests > > publishing of that assignment in ARIN's registration database, the ISP > should register > > that assignment as described in section 6.5.5.1. > > > > On Tue, Sep 26, 2017 at 1:31 PM, ARIN wrote: > > On 21 September 2017, the ARIN Advisory Council (AC) advanced the > following Draft Policy to Recommended Draft Policy status: > > ARIN-2017-5: Improved IPv6 Registration Requirements > > The text of the Recommended Draft Policy is below, and may also be found > at: > > https://www.arin.net/policy/proposals/2017_5.html > > You are encouraged to discuss all Recommended Draft Policies on PPML > prior to their presentation at the next ARIN Public Policy and Members > Meeting. PPML and PPC discussions are invaluable to the AC when > determining community consensus. > > The PDP can be found at: > https://www.arin.net/policy/pdp.html > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > Regards, > > Sean Hopkins > Policy Analyst > American Registry for Internet Numbers (ARIN) > > > > AC's Statement of Conformance with ARIN's Principles of Internet Number > Resource Policy: > > This proposal is technically sound and enables fair and impartial number > policy for easier IPv6 Registrations. The staff and legal review noted a > single clarification issue which has been addressed. There is ample support > for the proposal on PPML and no concerns have been raised by the community > regarding the proposal. > > Problem Statement: > > Current ARIN policy has different WHOIS directory registration > requirements for IPv4 vs IPv6 address assignments. IPv4 registration is > triggered for an assignment of any address block equal to or greater than a > /29 (i.e., eight IPv4 addresses). In the case of IPv6, registration occurs > for an assignment of any block equal to or greater than a /64, which > constitutes one entire IPv6 subnet and is the minimum block size for an > allocation. Accordingly, there is a significant disparity between IPv4 and > IPv6 WHOIS registration thresholds in the case of assignments, resulting in > more work in the case of IPv6 than is the case for IPv4. There is no > technical or policy rationale for the disparity, which could serve as a > deterrent to more rapid IPv6 adoption. The purpose of this proposal is to > eliminate the disparity and corresponding adverse consequences. > > Policy statement: > > 1) Alter section 6.5.5.1 "Reassignment information" of the NRPM to strike > "assignment containing a /64 or more addresses" and change to > "re-allocation, reassignment containing a /47 or more addresses, or > subdelegation of any size that will be individually announced," > > and > > 2) Alter section 6.5.5.2. "Assignments visible within 7 days" of the NRPM > to strike the text "4.2.3.7.1" and change to "6.5.5.1" > > and > > 3) Alter section 6.5.5.3.1. "Residential Customer Privacy" of the NRPM by > deleting the phrase "holding /64 and larger blocks" > > and > > 4) Add new section 6.5.5.4 "Registration Requested by Recipient" of the > NRPM, to read: "If the downstream recipient of a static assignment of /64 > or more addresses requests publishing of that assignment in ARIN's > registration database, the ISP should register that assignment as described > in section 6.5.5.1." > > Comments: > > a. Timetable for implementation: > > Policy should be adopted as soon as possible. > > b. Anything else: > > Author Comments: > > IPv6 should not be more burdensome than the equivalent IPv4 network size. > Currently, assignments of /29 or more of IPv4 space (8 addresses) require > registration. The greatest majority of ISP customers who have assignments > of IPv4 space are of a single IPv4 address which do not trigger any ARIN > registration requirement when using IPv4. This is NOT true when these same > exact customers use IPv6, as assignments of /64 or more of IPv6 space > require registration. Beginning with RFC 3177, it has been standard > practice to assign a minimum assignment of /64 to every customer end user > site, and less is never used. This means that ALL IPv6 assignments, > including those customers that only use a single IPv4 address must be > registered with ARIN if they are given the minimum assignment of /64 of > IPv6 space. This additional effort may prevent ISP's from giving IPv6 > addresses because of the additional expense of registering those addresses > with ARIN, which is not required for IPv4. The administrative burden of > 100% customer registration of IPv6 customers is unreasonable, when such is > not required for those customers receiving only IPv4 connections. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > > > > > -- > > _______________________________________________________ > > Jason Schiller|NetOps|jschiller at google.com|571-266-0006 <(571)%20266-0006> > > > > > > > > -- > > _______________________________________________________ > > Jason Schiller|NetOps|jschiller at google.com|571-266-0006 <(571)%20266-0006> > > > -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Wed Sep 27 17:59:07 2017 From: jcurran at arin.net (John Curran) Date: Wed, 27 Sep 2017 21:59:07 +0000 Subject: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements In-Reply-To: References: Message-ID: <4D69C6C7-A6C1-41DD-8CF7-7DC198973E9F@arin.net> On 26 Sep 2017, at 3:18 PM, Jason Schiller > wrote: I oppose as written. There should not be a different standard of requirement for: - re-allocation - reassignment containing a /47 or more addresses - subdelegation of any size that will be individually announced which is "shall" and Registration Requested by Recipient which is "should" I would support if they are both "shall". Can ARIN staff discuss what actions it will take if an ISP's down stream customer contacts them and explains that their ISP refuses to SWIP their reassignment to them? Will they do anything more than reach out to the ISP and tell them they "should" SWIP it? Jason - If this policy change 2017-5 is adopted, then a provider that has IPv6 space from ARIN but routinely fails to publish registration information (for /47 or larger reassignments) would be in violation, and ARIN would have clear policy language that would enable us to discuss with the ISP the need to publish this information in a timely manner. Service providers who blatantly ignore such a provision on an ongoing basis will be in the enviable position of hearing me chat with them about their obligations to follow ARIN number resource policy, including the consequences (i.e. potential revocation of the IPv6 number resources.) If the langauge for the new section 6.5.5.4 "Registration Requested by Recipient? reads ?? the ISP should register that assignment?, then ARIN would send on any received customer complaint to the ISP, and remind the ISP that they should follow number resource policy in this regard but not otherwise taking any action. If the language for the new section 6.5.5.4 "Registration Requested by Recipient? reads ?? the ISP shall register that assignment?, then failure to do so would be a far more serious matter that, if left unaddressed on a chronic manner, could have me discussing the customer complaints as a sign of potential failure to comply with number resource policy, including the consequences (i.e. potential revocation of the IPv6 number resources.) I would note that the community should be very clear about its intentions for ISPs with regard to customer requested reassignment publication, given there is large difference in obligations that result from policy language choice. ARIN staff remains, as always, looking forward to implementing whatever policy emerges from the consensus-based policy development process. Thanks! /John John Curran President and CEO American Registry for Internet Numbers -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvgeekwtrvl at gmail.com Thu Sep 28 01:16:34 2017 From: hvgeekwtrvl at gmail.com (james machado) Date: Wed, 27 Sep 2017 22:16:34 -0700 Subject: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements In-Reply-To: References: Message-ID: I oppose as written. I support Jason's language of replacing "should" with "shall" in 6.5.5.4. James -------------- next part -------------- An HTML attachment was scrubbed... URL: From jschiller at google.com Thu Sep 28 11:20:17 2017 From: jschiller at google.com (Jason Schiller) Date: Thu, 28 Sep 2017 11:20:17 -0400 Subject: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements In-Reply-To: References: Message-ID: John, Thanks. My intention was to make 6.5.5.4 not be any less required or give the impression that it is any more optional than 6.5.5.1. It sounds like enforcement of 6.5.5.4 "shall" could reasonably match 6.5.5.1 shall. Talking off line I get the impression that some people thought the intent was that a single complaint of a downstream customer could trigger consequences (i.e. potential revocation of the IPv6 number resources.) That is not my intention. My intention is that a single violation of 6.5.5.4 makes the ISP just as much out of compliance with number resource policy as a single violation of 6.5.5.1. I support shall. Anyone else support shall for both.5.5.4 and 6.5.5.1? Oppose shall for 6.5.5.4 but support it for 6.5.5.1? Oppose shall for both 6.5.5.4 and 6.5.5.1? Either is fine? Don't really care? Support shall for both: 2 Oppose shall for 6.5.5.4 but support it for 6.5.5.1: 0 Oppose shall for both: 0 Either: 0 don't care: 0 (I count 7 unique posters in this thread, and another 27 across other posts on this policy... Of course a bunch of that is concerned with residential privacy and DNS) ___Jason On Thu, Sep 28, 2017 at 1:16 AM, james machado wrote: > I oppose as written. > > I support Jason's language of replacing "should" with "shall" in 6.5.5.4. > > James > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From scottleibrand at gmail.com Thu Sep 28 11:26:20 2017 From: scottleibrand at gmail.com (Scott Leibrand) Date: Thu, 28 Sep 2017 08:26:20 -0700 Subject: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements In-Reply-To: References: Message-ID: I support this policy proposal with "should" and would also support it with "shall". I don't think it's a big deal either way. -Scott On Thu, Sep 28, 2017 at 8:20 AM, Jason Schiller wrote: > John, > > Thanks. > > My intention was to make 6.5.5.4 not be any less required or give the > impression > that it is any more optional than 6.5.5.1. > > It sounds like enforcement of 6.5.5.4 "shall" could reasonably > match 6.5.5.1 shall. > > > Talking off line I get the impression that some people thought the intent > was that > a single complaint of a downstream customer could trigger consequences > (i.e. potential revocation of the IPv6 number resources.) That is not my > intention. > > My intention is that a single violation of 6.5.5.4 makes the ISP just as > much out of > compliance with number resource policy as a single violation of 6.5.5.1. > > > I support shall. > > Anyone else support shall for both.5.5.4 and 6.5.5.1? > Oppose shall for 6.5.5.4 but support it for 6.5.5.1? > Oppose shall for both 6.5.5.4 and 6.5.5.1? > Either is fine? > Don't really care? > > Support shall for both: 2 > Oppose shall for 6.5.5.4 but support it for 6.5.5.1: 0 > Oppose shall for both: 0 > Either: 0 > don't care: 0 > > (I count 7 unique posters in this thread, > and another 27 across other posts on this policy... > Of course a bunch of that is concerned with residential privacy and DNS) > > > ___Jason > > On Thu, Sep 28, 2017 at 1:16 AM, james machado > wrote: > >> I oppose as written. >> >> I support Jason's language of replacing "should" with "shall" in >> 6.5.5.4. >> >> James >> >> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> > > > > -- > _______________________________________________________ > Jason Schiller|NetOps|jschiller at google.com|571-266-0006 <(571)%20266-0006> > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hostmaster at uneedus.com Thu Sep 28 11:31:25 2017 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Thu, 28 Sep 2017 11:31:25 -0400 (EDT) Subject: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements In-Reply-To: References: Message-ID: I support with either shall or should. Shall is perferred. Albert Erdmann Network Administrator Paradise On Line Inc. On Thu, 28 Sep 2017, Scott Leibrand wrote: > I support this policy proposal with "should" and would also support it with > "shall". I don't think it's a big deal either way. > > -Scott > > On Thu, Sep 28, 2017 at 8:20 AM, Jason Schiller > wrote: > >> John, >> >> Thanks. >> >> My intention was to make 6.5.5.4 not be any less required or give the >> impression >> that it is any more optional than 6.5.5.1. >> >> It sounds like enforcement of 6.5.5.4 "shall" could reasonably >> match 6.5.5.1 shall. >> >> >> Talking off line I get the impression that some people thought the intent >> was that >> a single complaint of a downstream customer could trigger consequences >> (i.e. potential revocation of the IPv6 number resources.) That is not my >> intention. >> >> My intention is that a single violation of 6.5.5.4 makes the ISP just as >> much out of >> compliance with number resource policy as a single violation of 6.5.5.1. >> >> >> I support shall. >> >> Anyone else support shall for both.5.5.4 and 6.5.5.1? >> Oppose shall for 6.5.5.4 but support it for 6.5.5.1? >> Oppose shall for both 6.5.5.4 and 6.5.5.1? >> Either is fine? >> Don't really care? >> >> Support shall for both: 2 >> Oppose shall for 6.5.5.4 but support it for 6.5.5.1: 0 >> Oppose shall for both: 0 >> Either: 0 >> don't care: 0 >> >> (I count 7 unique posters in this thread, >> and another 27 across other posts on this policy... >> Of course a bunch of that is concerned with residential privacy and DNS) >> >> >> ___Jason >> >> On Thu, Sep 28, 2017 at 1:16 AM, james machado >> wrote: >> >>> I oppose as written. >>> >>> I support Jason's language of replacing "should" with "shall" in >>> 6.5.5.4. >>> >>> James >>> >>> >>> >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to >>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at arin.net if you experience any issues. >>> >> >> >> >> -- >> _______________________________________________________ >> Jason Schiller|NetOps|jschiller at google.com|571-266-0006 <(571)%20266-0006> >> >> >> _______________________________________________ >> 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 kevinb at thewire.ca Thu Sep 28 11:46:27 2017 From: kevinb at thewire.ca (Kevin Blumberg) Date: Thu, 28 Sep 2017 15:46:27 +0000 Subject: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements In-Reply-To: <4D69C6C7-A6C1-41DD-8CF7-7DC198973E9F@arin.net> References: <4D69C6C7-A6C1-41DD-8CF7-7DC198973E9F@arin.net> Message-ID: <7E7773B523E82C478734E793E58F69E7A52C530A@SBS2011.thewireinc.local> I support the policy as written. If the stick isn?t big enough it appears a simple policy change could be used, not just for this section but all the other areas ?should? is used. I would like to point out that ?should? is currently used 30 times in the NRPM. In reading John?s explanation, I can?t see ?should? and ?shall? being considered an editorial change. To extend the policy cycle to another meeting would be far worse. Out of curiosity, how often has ARIN had to deal with SWIP issues like this, where the other party ignored you? Thanks, Kevin Blumberg From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of John Curran Sent: Wednesday, September 27, 2017 5:59 PM To: Jason Schiller Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements On 26 Sep 2017, at 3:18 PM, Jason Schiller > wrote: I oppose as written. There should not be a different standard of requirement for: - re-allocation - reassignment containing a /47 or more addresses - subdelegation of any size that will be individually announced which is "shall" and Registration Requested by Recipient which is "should" I would support if they are both "shall". Can ARIN staff discuss what actions it will take if an ISP's down stream customer contacts them and explains that their ISP refuses to SWIP their reassignment to them? Will they do anything more than reach out to the ISP and tell them they "should" SWIP it? Jason - If this policy change 2017-5 is adopted, then a provider that has IPv6 space from ARIN but routinely fails to publish registration information (for /47 or larger reassignments) would be in violation, and ARIN would have clear policy language that would enable us to discuss with the ISP the need to publish this information in a timely manner. Service providers who blatantly ignore such a provision on an ongoing basis will be in the enviable position of hearing me chat with them about their obligations to follow ARIN number resource policy, including the consequences (i.e. potential revocation of the IPv6 number resources.) If the langauge for the new section 6.5.5.4 "Registration Requested by Recipient? reads ?? the ISP should register that assignment?, then ARIN would send on any received customer complaint to the ISP, and remind the ISP that they should follow number resource policy in this regard but not otherwise taking any action. If the language for the new section 6.5.5.4 "Registration Requested by Recipient? reads ?? the ISP shall register that assignment?, then failure to do so would be a far more serious matter that, if left unaddressed on a chronic manner, could have me discussing the customer complaints as a sign of potential failure to comply with number resource policy, including the consequences (i.e. potential revocation of the IPv6 number resources.) I would note that the community should be very clear about its intentions for ISPs with regard to customer requested reassignment publication, given there is large difference in obligations that result from policy language choice. ARIN staff remains, as always, looking forward to implementing whatever policy emerges from the consensus-based policy development process. Thanks! /John John Curran President and CEO American Registry for Internet Numbers -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Thu Sep 28 11:46:01 2017 From: owen at delong.com (Owen DeLong) Date: Thu, 28 Sep 2017 10:46:01 -0500 Subject: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements In-Reply-To: <4D69C6C7-A6C1-41DD-8CF7-7DC198973E9F@arin.net> References: <4D69C6C7-A6C1-41DD-8CF7-7DC198973E9F@arin.net> Message-ID: <314B3DC2-87BA-434D-9EEC-F2BD60F678EC@delong.com> Given this, I personally think that shall is the better choice of wording for 6.5.5.4. Owen > On Sep 27, 2017, at 4:59 PM, John Curran wrote: > > On 26 Sep 2017, at 3:18 PM, Jason Schiller > wrote: >> >> I oppose as written. >> >> There should not be a different standard of requirement for: >> - re-allocation >> - reassignment containing a /47 or more addresses >> - subdelegation of any size that will be individually announced >> >> which is "shall" >> >> and Registration Requested by Recipient >> >> which is "should" >> >> I would support if they are both "shall". >> >> Can ARIN staff discuss what actions it will take if an ISP's >> down stream customer contacts them and explains that their >> ISP refuses to SWIP their reassignment to them? >> >> Will they do anything more than reach out to the ISP and tell >> them they "should" SWIP it? > > Jason - > > If this policy change 2017-5 is adopted, then a provider that has IPv6 space from ARIN > but routinely fails to publish registration information (for /47 or larger reassignments) > would be in violation, and ARIN would have clear policy language that would enable > us to discuss with the ISP the need to publish this information in a timely manner. > > Service providers who blatantly ignore such a provision on an ongoing basis will be > in the enviable position of hearing me chat with them about their obligations to follow > ARIN number resource policy, including the consequences (i.e. potential revocation > of the IPv6 number resources.) > > If the langauge for the new section 6.5.5.4 "Registration Requested by Recipient? > reads ?? the ISP should register that assignment?, then ARIN would send on any > received customer complaint to the ISP, and remind the ISP that they should > follow number resource policy in this regard but not otherwise taking any action. > > If the language for the new section 6.5.5.4 "Registration Requested by Recipient? > reads ?? the ISP shall register that assignment?, then failure to do so would be > a far more serious matter that, if left unaddressed on a chronic manner, could have > me discussing the customer complaints as a sign of potential failure to comply with > number resource policy, including the consequences (i.e. potential revocation of > the IPv6 number resources.) > > I would note that the community should be very clear about its intentions for ISPs > with regard to customer requested reassignment publication, given there is large > difference in obligations that result from policy language choice. ARIN staff remains, > as always, looking forward to implementing whatever policy emerges from the > consensus-based policy development process. > > Thanks! > /John > > John Curran > President and CEO > American Registry for Internet Numbers > > > > > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Thu Sep 28 12:03:55 2017 From: owen at delong.com (Owen DeLong) Date: Thu, 28 Sep 2017 11:03:55 -0500 Subject: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements In-Reply-To: <7E7773B523E82C478734E793E58F69E7A52C530A@SBS2011.thewireinc.local> References: <4D69C6C7-A6C1-41DD-8CF7-7DC198973E9F@arin.net> <7E7773B523E82C478734E793E58F69E7A52C530A@SBS2011.thewireinc.local> Message-ID: While I wouldn?t consider it an editorial change, I would consider it a minor change, which, if it had good community discussion and support at the meeting, would, IMHO, be within the scope of pre-last-call changes that could be made between the PPM and last call. The AC has, as has been mentioned before, significant discretion in determining what is a ?minor change?. This is strictly my own opinion and may or may not be shared by other AC members, staff, or anyone else. Owen > On Sep 28, 2017, at 10:46 AM, Kevin Blumberg wrote: > > I support the policy as written. <> > > If the stick isn?t big enough it appears a simple policy change could be used, not just for this section but all the other areas ?should? is used. > > I would like to point out that ?should? is currently used 30 times in the NRPM. > > In reading John?s explanation, I can?t see ?should? and ?shall? being considered an editorial change. To extend the policy cycle to another meeting would be far worse. > > Out of curiosity, how often has ARIN had to deal with SWIP issues like this, where the other party ignored you? > > Thanks, > > Kevin Blumberg > > > From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of John Curran > Sent: Wednesday, September 27, 2017 5:59 PM > To: Jason Schiller > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements > > On 26 Sep 2017, at 3:18 PM, Jason Schiller > wrote: > > I oppose as written. > > There should not be a different standard of requirement for: > - re-allocation > - reassignment containing a /47 or more addresses > - subdelegation of any size that will be individually announced > > which is "shall" > > and Registration Requested by Recipient > > which is "should" > > I would support if they are both "shall". > > Can ARIN staff discuss what actions it will take if an ISP's > down stream customer contacts them and explains that their > ISP refuses to SWIP their reassignment to them? > > Will they do anything more than reach out to the ISP and tell > them they "should" SWIP it? > > Jason - > > If this policy change 2017-5 is adopted, then a provider that has IPv6 space from ARIN > but routinely fails to publish registration information (for /47 or larger reassignments) > would be in violation, and ARIN would have clear policy language that would enable > us to discuss with the ISP the need to publish this information in a timely manner. > > Service providers who blatantly ignore such a provision on an ongoing basis will be > in the enviable position of hearing me chat with them about their obligations to follow > ARIN number resource policy, including the consequences (i.e. potential revocation > of the IPv6 number resources.) > > If the langauge for the new section 6.5.5.4 "Registration Requested by Recipient? > reads ?? the ISP should register that assignment?, then ARIN would send on any > received customer complaint to the ISP, and remind the ISP that they should > follow number resource policy in this regard but not otherwise taking any action. > > If the language for the new section 6.5.5.4 "Registration Requested by Recipient? > reads ?? the ISP shall register that assignment?, then failure to do so would be > a far more serious matter that, if left unaddressed on a chronic manner, could have > me discussing the customer complaints as a sign of potential failure to comply with > number resource policy, including the consequences (i.e. potential revocation of > the IPv6 number resources.) > > I would note that the community should be very clear about its intentions for ISPs > with regard to customer requested reassignment publication, given there is large > difference in obligations that result from policy language choice. ARIN staff remains, > as always, looking forward to implementing whatever policy emerges from the > consensus-based policy development process. > > Thanks! > /John > > John Curran > President and CEO > American Registry for Internet Numbers > > > > > > > > _______________________________________________ > 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 alyssa at alyssamoore.ca Thu Sep 28 12:34:36 2017 From: alyssa at alyssamoore.ca (Alyssa Moore) Date: Thu, 28 Sep 2017 16:34:36 +0000 Subject: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements In-Reply-To: References: <4D69C6C7-A6C1-41DD-8CF7-7DC198973E9F@arin.net> <7E7773B523E82C478734E793E58F69E7A52C530A@SBS2011.thewireinc.local> Message-ID: I support the policy as written. I would not consider swapping *should* for *shall* to be an editorial change. My preferred auxiliary verb for the purposes of the current policy proposal is "should." This is my own opinion and may or may not be shared by other AC members (see: Owen Delong). FWIW, if we encounter problems with the current language of the proposal, it can (shall? should?) be amended in the future, or the community may (shall? should? ought to?) choose to define the intent of auxiliary verbs for the NRPM. On Thu, Sep 28, 2017 at 10:05 AM Owen DeLong wrote: > While I wouldn?t consider it an editorial change, I would consider it a > minor change, which, if it had good community discussion and support at the > meeting, would, IMHO, be within the scope of pre-last-call changes that > could be made between the PPM and last call. > > The AC has, as has been mentioned before, significant discretion in > determining what is a ?minor change?. > > This is strictly my own opinion and may or may not be shared by other AC > members, staff, or anyone else. > > Owen > > On Sep 28, 2017, at 10:46 AM, Kevin Blumberg wrote: > > I support the policy as written. > > If the stick isn?t big enough it appears a simple policy change could be > used, not just for this section but all the other areas ?should? is used. > > I would like to point out that ?should? is currently used 30 times in the > NRPM. > > In reading John?s explanation, I can?t see ?should? and ?shall? being > considered an editorial change. To extend the policy cycle to another > meeting would be far worse. > > Out of curiosity, how often has ARIN had to deal with SWIP issues like > this, where the other party ignored you? > > Thanks, > > Kevin Blumberg > > > *From:* ARIN-PPML [mailto:arin-ppml-bounces at arin.net > ] *On Behalf Of *John Curran > *Sent:* Wednesday, September 27, 2017 5:59 PM > *To:* Jason Schiller > *Cc:* arin-ppml at arin.net > *Subject:* Re: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved > IPv6 Registration Requirements > > On 26 Sep 2017, at 3:18 PM, Jason Schiller wrote: > > > I oppose as written. > > There should not be a different standard of requirement for: > - re-allocation > - reassignment containing a /47 or more addresses > - subdelegation of any size that will be individually announced > > which is "shall" > > and Registration Requested by Recipient > > which is "should" > > I would support if they are both "shall". > > Can ARIN staff discuss what actions it will take if an ISP's > down stream customer contacts them and explains that their > ISP refuses to SWIP their reassignment to them? > > Will they do anything more than reach out to the ISP and tell > them they "should" SWIP it? > > > Jason - > > If this policy change 2017-5 is adopted, then a provider that has IPv6 > space from ARIN > but routinely fails to publish registration information (for /47 or > larger reassignments) > would be in violation, and ARIN would have clear policy language that > would enable > us to discuss with the ISP the need to publish this information in a > timely manner. > > Service providers who blatantly ignore such a provision on an ongoing > basis will be > in the enviable position of hearing me chat with them about their > obligations to follow > ARIN number resource policy, including the consequences (i.e. potential > revocation > of the IPv6 number resources.) > > If the langauge for the new section 6.5.5.4 "Registration Requested by > Recipient? > reads ?? the ISP should register that assignment?, then ARIN would send > on any > received customer complaint to the ISP, and remind the ISP that they > should > follow number resource policy in this regard but not otherwise taking > any action. > > If the language for the new section 6.5.5.4 "Registration Requested by > Recipient? > reads ?? the ISP shall register that assignment?, then failure to do so > would be > a far more serious matter that, if left unaddressed on a chronic > manner, could have > me discussing the customer complaints as a sign of potential failure to > comply with > number resource policy, including the consequences (i.e. potential > revocation of > the IPv6 number resources.) > > I would note that the community should be very clear about its > intentions for ISPs > with regard to customer requested reassignment publication, given there > is large > difference in obligations that result from policy language choice. > ARIN staff remains, > as always, looking forward to implementing whatever policy emerges from > the > consensus-based policy development process. > > Thanks! > /John > > John Curran > President and CEO > American Registry for Internet Numbers > > > > > > > > _______________________________________________ > 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 rudi.daniel at gmail.com Thu Sep 28 13:13:49 2017 From: rudi.daniel at gmail.com (Rudolph Daniel) Date: Thu, 28 Sep 2017 13:13:49 -0400 Subject: [arin-ppml] ARIN-PPML 2017-5 Message-ID: I am in support of the policy proposal with "shall" but I would like to know of possible negative impact if approved as policy; on the past reassignments that were not SWIP ed. Is this perceived as an issue; or will the policy be retroactive? Either way. Rudi Daniel *danielcharles consulting * On Thu, Sep 28, 2017 at 12:05 PM, wrote: > Send ARIN-PPML mailing list submissions to > arin-ppml at arin.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.arin.net/mailman/listinfo/arin-ppml > or, via email, send a message with subject or body 'help' to > arin-ppml-request at arin.net > > You can reach the person managing the list at > arin-ppml-owner at arin.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of ARIN-PPML digest..." > > > Today's Topics: > > 1. Re: Recommended Draft Policy ARIN-2017-5: Improved IPv6 > Registration Requirements (Owen DeLong) > 2. Re: Recommended Draft Policy ARIN-2017-5: Improved IPv6 > Registration Requirements (Owen DeLong) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 28 Sep 2017 10:46:01 -0500 > From: Owen DeLong > To: John Curran > Cc: Jason Schiller , "arin-ppml at arin.net" > > Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2017-5: > Improved IPv6 Registration Requirements > Message-ID: <314B3DC2-87BA-434D-9EEC-F2BD60F678EC at delong.com> > Content-Type: text/plain; charset="utf-8" > > Given this, I personally think that shall is the better choice of wording > for 6.5.5.4. > > Owen > > > On Sep 27, 2017, at 4:59 PM, John Curran wrote: > > > > On 26 Sep 2017, at 3:18 PM, Jason Schiller > wrote: > >> > >> I oppose as written. > >> > >> There should not be a different standard of requirement for: > >> - re-allocation > >> - reassignment containing a /47 or more addresses > >> - subdelegation of any size that will be individually announced > >> > >> which is "shall" > >> > >> and Registration Requested by Recipient > >> > >> which is "should" > >> > >> I would support if they are both "shall". > >> > >> Can ARIN staff discuss what actions it will take if an ISP's > >> down stream customer contacts them and explains that their > >> ISP refuses to SWIP their reassignment to them? > >> > >> Will they do anything more than reach out to the ISP and tell > >> them they "should" SWIP it? > > > > Jason - > > > > If this policy change 2017-5 is adopted, then a provider that has > IPv6 space from ARIN > > but routinely fails to publish registration information (for /47 or > larger reassignments) > > would be in violation, and ARIN would have clear policy language that > would enable > > us to discuss with the ISP the need to publish this information in a > timely manner. > > > > Service providers who blatantly ignore such a provision on an ongoing > basis will be > > in the enviable position of hearing me chat with them about their > obligations to follow > > ARIN number resource policy, including the consequences (i.e. > potential revocation > > of the IPv6 number resources.) > > > > If the langauge for the new section 6.5.5.4 "Registration Requested > by Recipient? > > reads ?? the ISP should register that assignment?, then ARIN would > send on any > > received customer complaint to the ISP, and remind the ISP that they > should > > follow number resource policy in this regard but not otherwise taking > any action. > > > > If the language for the new section 6.5.5.4 "Registration Requested > by Recipient? > > reads ?? the ISP shall register that assignment?, then failure to do > so would be > > a far more serious matter that, if left unaddressed on a chronic > manner, could have > > me discussing the customer complaints as a sign of potential failure > to comply with > > number resource policy, including the consequences (i.e. potential > revocation of > > the IPv6 number resources.) > > > > I would note that the community should be very clear about its > intentions for ISPs > > with regard to customer requested reassignment publication, given > there is large > > difference in obligations that result from policy language choice. > ARIN staff remains, > > as always, looking forward to implementing whatever policy emerges > from the > > consensus-based policy development process. > > > > Thanks! > > /John > > > > John Curran > > President and CEO > > American Registry for Internet Numbers > > > > > > > > > > > > > > > > _______________________________________________ > > 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: attachments/20170928/6d6c415b/attachment-0001.html> > > ------------------------------ > > Message: 2 > Date: Thu, 28 Sep 2017 11:03:55 -0500 > From: Owen DeLong > To: Kevin Blumberg > Cc: John Curran , Jason Schiller > , "arin-ppml at arin.net" > Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2017-5: > Improved IPv6 Registration Requirements > Message-ID: > Content-Type: text/plain; charset="utf-8" > > While I wouldn?t consider it an editorial change, I would consider it a > minor change, which, if it had good community discussion and support at the > meeting, would, IMHO, be within the scope of pre-last-call changes that > could be made between the PPM and last call. > > The AC has, as has been mentioned before, significant discretion in > determining what is a ?minor change?. > > This is strictly my own opinion and may or may not be shared by other AC > members, staff, or anyone else. > > Owen > > > On Sep 28, 2017, at 10:46 AM, Kevin Blumberg wrote: > > > > I support the policy as written. <> > > > > If the stick isn?t big enough it appears a simple policy change could be > used, not just for this section but all the other areas ?should? is used. > > > > I would like to point out that ?should? is currently used 30 times in > the NRPM. > > > > In reading John?s explanation, I can?t see ?should? and ?shall? being > considered an editorial change. To extend the policy cycle to another > meeting would be far worse. > > > > Out of curiosity, how often has ARIN had to deal with SWIP issues like > this, where the other party ignored you? > > > > Thanks, > > > > Kevin Blumberg > > > > > > From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of John > Curran > > Sent: Wednesday, September 27, 2017 5:59 PM > > To: Jason Schiller > > Cc: arin-ppml at arin.net > > Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved > IPv6 Registration Requirements > > > > On 26 Sep 2017, at 3:18 PM, Jason Schiller > wrote: > > > > I oppose as written. > > > > There should not be a different standard of requirement for: > > - re-allocation > > - reassignment containing a /47 or more addresses > > - subdelegation of any size that will be individually announced > > > > which is "shall" > > > > and Registration Requested by Recipient > > > > which is "should" > > > > I would support if they are both "shall". > > > > Can ARIN staff discuss what actions it will take if an ISP's > > down stream customer contacts them and explains that their > > ISP refuses to SWIP their reassignment to them? > > > > Will they do anything more than reach out to the ISP and tell > > them they "should" SWIP it? > > > > Jason - > > > > If this policy change 2017-5 is adopted, then a provider that has > IPv6 space from ARIN > > but routinely fails to publish registration information (for /47 or > larger reassignments) > > would be in violation, and ARIN would have clear policy language that > would enable > > us to discuss with the ISP the need to publish this information in a > timely manner. > > > > Service providers who blatantly ignore such a provision on an ongoing > basis will be > > in the enviable position of hearing me chat with them about their > obligations to follow > > ARIN number resource policy, including the consequences (i.e. > potential revocation > > of the IPv6 number resources.) > > > > If the langauge for the new section 6.5.5.4 "Registration Requested > by Recipient? > > reads ?? the ISP should register that assignment?, then ARIN would > send on any > > received customer complaint to the ISP, and remind the ISP that they > should > > follow number resource policy in this regard but not otherwise taking > any action. > > > > If the language for the new section 6.5.5.4 "Registration Requested > by Recipient? > > reads ?? the ISP shall register that assignment?, then failure to do > so would be > > a far more serious matter that, if left unaddressed on a chronic > manner, could have > > me discussing the customer complaints as a sign of potential failure > to comply with > > number resource policy, including the consequences (i.e. potential > revocation of > > the IPv6 number resources.) > > > > I would note that the community should be very clear about its > intentions for ISPs > > with regard to customer requested reassignment publication, given > there is large > > difference in obligations that result from policy language choice. > ARIN staff remains, > > as always, looking forward to implementing whatever policy emerges > from the > > consensus-based policy development process. > > > > Thanks! > > /John > > > > John Curran > > President and CEO > > American Registry for Internet Numbers > > > > > > > > > > > > > > > > _______________________________________________ > > 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: attachments/20170928/0fbeb396/attachment.html> > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > ARIN-PPML mailing list > ARIN-PPML at arin.net > http://lists.arin.net/mailman/listinfo/arin-ppml > > ------------------------------ > > End of ARIN-PPML Digest, Vol 147, Issue 43 > ****************************************** > -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmer at umn.edu Thu Sep 28 13:18:00 2017 From: farmer at umn.edu (David Farmer) Date: Thu, 28 Sep 2017 12:18:00 -0500 Subject: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements In-Reply-To: <7E7773B523E82C478734E793E58F69E7A52C530A@SBS2011.thewireinc.local> References: <4D69C6C7-A6C1-41DD-8CF7-7DC198973E9F@arin.net> <7E7773B523E82C478734E793E58F69E7A52C530A@SBS2011.thewireinc.local> Message-ID: I agree with Kevin if a bigger stick is need to ensure compliance in the future we can take that step if/when there proves to be a serious non-compliance issue in the future. Personally, I'm not ready to threaten revocation, in this case. My intent in suggesting what is now 6.5.5.4 was to crate an avenue for ARIN Staff to intervene with ISPs on behalf of customers, if a customer wanted their assignment registered and their ISP refused to register their assignment as requested, the customer can appeal the issue to ARIN. I'm fine with that intervention being short of threatening revocation, at least until their proves to be a serious issue with ISP's refusing valid requests by endusers to register assignments. I think the current language provides the proper balance. I'm fine with the standard procedure starting with ARIN Staff forwarding such complaints to an ISP requesting an explanation of the situation. However, if this develops into a chronic matter for an ISP, I would expect ARIN Staff to escalate the issue beyond simply asking for an explanation. Further after escalation, if the matter continues to be chronic, I would expect eventually the community to be altered to the situation. Probably not the specifics of which ISP and customers, but at least that there is an issue and some sense of the situation involved. Therefore, I support the policy as written. I'm not strongly opposed to changing from "should" to "shall" for section 6.5.5.4, but I'd prefer keeping that change in reserve, so we can go there, if there proves to be serious issues with non-compliance in the future. Put another way, I think voluntary compliance is highly preferred for this issue, and if voluntary compliance proves insufficient, then we can deal with that in the future. Thanks. On Thu, Sep 28, 2017 at 10:46 AM, Kevin Blumberg wrote: > I support the policy as written. > > > > If the stick isn?t big enough it appears a simple policy change could be > used, not just for this section but all the other areas ?should? is used. > > > > I would like to point out that ?should? is currently used 30 times in the > NRPM. > > > > In reading John?s explanation, I can?t see ?should? and ?shall? being > considered an editorial change. To extend the policy cycle to another > meeting would be far worse. > > > > Out of curiosity, how often has ARIN had to deal with SWIP issues like > this, where the other party ignored you? > > > > Thanks, > > > > Kevin Blumberg > > > > > > *From:* ARIN-PPML [mailto:arin-ppml-bounces at arin.net] *On Behalf Of *John > Curran > *Sent:* Wednesday, September 27, 2017 5:59 PM > *To:* Jason Schiller > *Cc:* arin-ppml at arin.net > *Subject:* Re: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved > IPv6 Registration Requirements > > > > On 26 Sep 2017, at 3:18 PM, Jason Schiller wrote: > > > > I oppose as written. > > > > There should not be a different standard of requirement for: > > - re-allocation > > - reassignment containing a /47 or more addresses > > - subdelegation of any size that will be individually announced > > > > which is "shall" > > > > and Registration Requested by Recipient > > > > which is "should" > > > > I would support if they are both "shall". > > > > Can ARIN staff discuss what actions it will take if an ISP's > > down stream customer contacts them and explains that their > > ISP refuses to SWIP their reassignment to them? > > > > Will they do anything more than reach out to the ISP and tell > > them they "should" SWIP it? > > > > Jason - > > If this policy change 2017-5 is adopted, then a provider that has IPv6 > space from ARIN > > but routinely fails to publish registration information (for /47 or > larger reassignments) > > would be in violation, and ARIN would have clear policy language that > would enable > > us to discuss with the ISP the need to publish this information in a > timely manner. > > > Service providers who blatantly ignore such a provision on an ongoing > basis will be > in the enviable position of hearing me chat with them about their > obligations to follow > ARIN number resource policy, including the consequences (i.e. potential > revocation > > of the IPv6 number resources.) > > > > If the langauge for the new section 6.5.5.4 "Registration Requested by > Recipient? > > reads ?? the ISP should register that assignment?, then ARIN would send > on any > > received customer complaint to the ISP, and remind the ISP that they > should > > follow number resource policy in this regard but not otherwise taking > any action. > > > > If the language for the new section 6.5.5.4 "Registration Requested by > Recipient? > > reads ?? the ISP shall register that assignment?, then failure to do so > would be > > a far more serious matter that, if left unaddressed on a chronic > manner, could have > > me discussing the customer complaints as a sign of potential failure to > comply with > > number resource policy, including the consequences (i.e. potential > revocation of > > the IPv6 number resources.) > > > > I would note that the community should be very clear about its > intentions for ISPs > > with regard to customer requested reassignment publication, given there > is large > > difference in obligations that result from policy language choice. > ARIN staff remains, > > as always, looking forward to implementing whatever policy emerges from > the > > consensus-based policy development process. > > > > Thanks! > > /John > > > > John Curran > > President and CEO > > American Registry for Internet Numbers > > > > > > > > > > > > > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at semihuman.com Thu Sep 28 13:20:57 2017 From: chris at semihuman.com (Chris Woodfield) Date: Thu, 28 Sep 2017 10:20:57 -0700 Subject: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements In-Reply-To: References: <4D69C6C7-A6C1-41DD-8CF7-7DC198973E9F@arin.net> <7E7773B523E82C478734E793E58F69E7A52C530A@SBS2011.thewireinc.local> Message-ID: <8AC5AC05-1F11-4D94-BBE2-06B2219351E9@semihuman.com> I agree with Owen?s assessment. If there is sufficient community support for changing the phrase to ?shall? at the PPM - I?d define ?sufficient community support? as a show of hands on that specific word choice, in addition to the discussion here - I see no need to require another public consultation in order to go to last call incorporating that change in terms. I?m personally in favor of ?shall", although I still support as written. Perfect as enemy of good, etc etc. Thanks, -C > On Sep 28, 2017, at 9:03 AM, Owen DeLong wrote: > > While I wouldn?t consider it an editorial change, I would consider it a minor change, which, if it had good community discussion and support at the meeting, would, IMHO, be within the scope of pre-last-call changes that could be made between the PPM and last call. > > The AC has, as has been mentioned before, significant discretion in determining what is a ?minor change?. > > This is strictly my own opinion and may or may not be shared by other AC members, staff, or anyone else. > > Owen > >> On Sep 28, 2017, at 10:46 AM, Kevin Blumberg > wrote: >> >> I support the policy as written. <> >> >> If the stick isn?t big enough it appears a simple policy change could be used, not just for this section but all the other areas ?should? is used. >> >> I would like to point out that ?should? is currently used 30 times in the NRPM. >> >> In reading John?s explanation, I can?t see ?should? and ?shall? being considered an editorial change. To extend the policy cycle to another meeting would be far worse. >> >> Out of curiosity, how often has ARIN had to deal with SWIP issues like this, where the other party ignored you? >> >> Thanks, >> >> Kevin Blumberg >> >> >> From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net ] On Behalf Of John Curran >> Sent: Wednesday, September 27, 2017 5:59 PM >> To: Jason Schiller > >> Cc: arin-ppml at arin.net >> Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements >> >> On 26 Sep 2017, at 3:18 PM, Jason Schiller > wrote: >> >> I oppose as written. >> >> There should not be a different standard of requirement for: >> - re-allocation >> - reassignment containing a /47 or more addresses >> - subdelegation of any size that will be individually announced >> >> which is "shall" >> >> and Registration Requested by Recipient >> >> which is "should" >> >> I would support if they are both "shall". >> >> Can ARIN staff discuss what actions it will take if an ISP's >> down stream customer contacts them and explains that their >> ISP refuses to SWIP their reassignment to them? >> >> Will they do anything more than reach out to the ISP and tell >> them they "should" SWIP it? >> >> Jason - >> >> If this policy change 2017-5 is adopted, then a provider that has IPv6 space from ARIN >> but routinely fails to publish registration information (for /47 or larger reassignments) >> would be in violation, and ARIN would have clear policy language that would enable >> us to discuss with the ISP the need to publish this information in a timely manner. >> >> Service providers who blatantly ignore such a provision on an ongoing basis will be >> in the enviable position of hearing me chat with them about their obligations to follow >> ARIN number resource policy, including the consequences (i.e. potential revocation >> of the IPv6 number resources.) >> >> If the langauge for the new section 6.5.5.4 "Registration Requested by Recipient? >> reads ?? the ISP should register that assignment?, then ARIN would send on any >> received customer complaint to the ISP, and remind the ISP that they should >> follow number resource policy in this regard but not otherwise taking any action. >> >> If the language for the new section 6.5.5.4 "Registration Requested by Recipient? >> reads ?? the ISP shall register that assignment?, then failure to do so would be >> a far more serious matter that, if left unaddressed on a chronic manner, could have >> me discussing the customer complaints as a sign of potential failure to comply with >> number resource policy, including the consequences (i.e. potential revocation of >> the IPv6 number resources.) >> >> I would note that the community should be very clear about its intentions for ISPs >> with regard to customer requested reassignment publication, given there is large >> difference in obligations that result from policy language choice. ARIN staff remains, >> as always, looking forward to implementing whatever policy emerges from the >> consensus-based policy development process. >> >> Thanks! >> /John >> >> John Curran >> President and CEO >> American Registry for Internet Numbers >> >> >> >> >> >> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at semihuman.com Thu Sep 28 13:26:56 2017 From: chris at semihuman.com (Chris Woodfield) Date: Thu, 28 Sep 2017 10:26:56 -0700 Subject: [arin-ppml] ARIN-PPML 2017-5 In-Reply-To: References: Message-ID: Rudolph, My reading of the proposal is that the registration is triggered by the request from the downstream recipient, which implies that if no prior requests have been received, then there would be no duty to register. Requests from downstreams received after the policy is implemented would be subject to these terms. I?ll agree that this is ambiguous re: requests from downstreams received prior to implementation, but in practical terms, I?d expect interested downstreams to be aware of the policy change and simply resubmit that request, if the prior request was not granted. Thanks, -C > On Sep 28, 2017, at 10:13 AM, Rudolph Daniel wrote: > > I am in support of the policy proposal with "shall" but I would like to know of possible negative impact if approved as policy; on the past reassignments that were not SWIP ed. > Is this perceived as an issue; or will the policy be retroactive? Either way. > > > Rudi Daniel > danielcharles consulting > > > > On Thu, Sep 28, 2017 at 12:05 PM, > wrote: > Send ARIN-PPML mailing list submissions to > arin-ppml at arin.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.arin.net/mailman/listinfo/arin-ppml > or, via email, send a message with subject or body 'help' to > arin-ppml-request at arin.net > > You can reach the person managing the list at > arin-ppml-owner at arin.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of ARIN-PPML digest..." > > > Today's Topics: > > 1. Re: Recommended Draft Policy ARIN-2017-5: Improved IPv6 > Registration Requirements (Owen DeLong) > 2. Re: Recommended Draft Policy ARIN-2017-5: Improved IPv6 > Registration Requirements (Owen DeLong) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 28 Sep 2017 10:46:01 -0500 > From: Owen DeLong > > To: John Curran > > Cc: Jason Schiller >, "arin-ppml at arin.net " > > > Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2017-5: > Improved IPv6 Registration Requirements > Message-ID: <314B3DC2-87BA-434D-9EEC-F2BD60F678EC at delong.com > > Content-Type: text/plain; charset="utf-8" > > Given this, I personally think that shall is the better choice of wording for 6.5.5.4. > > Owen > > > On Sep 27, 2017, at 4:59 PM, John Curran > wrote: > > > > On 26 Sep 2017, at 3:18 PM, Jason Schiller >> wrote: > >> > >> I oppose as written. > >> > >> There should not be a different standard of requirement for: > >> - re-allocation > >> - reassignment containing a /47 or more addresses > >> - subdelegation of any size that will be individually announced > >> > >> which is "shall" > >> > >> and Registration Requested by Recipient > >> > >> which is "should" > >> > >> I would support if they are both "shall". > >> > >> Can ARIN staff discuss what actions it will take if an ISP's > >> down stream customer contacts them and explains that their > >> ISP refuses to SWIP their reassignment to them? > >> > >> Will they do anything more than reach out to the ISP and tell > >> them they "should" SWIP it? > > > > Jason - > > > > If this policy change 2017-5 is adopted, then a provider that has IPv6 space from ARIN > > but routinely fails to publish registration information (for /47 or larger reassignments) > > would be in violation, and ARIN would have clear policy language that would enable > > us to discuss with the ISP the need to publish this information in a timely manner. > > > > Service providers who blatantly ignore such a provision on an ongoing basis will be > > in the enviable position of hearing me chat with them about their obligations to follow > > ARIN number resource policy, including the consequences (i.e. potential revocation > > of the IPv6 number resources.) > > > > If the langauge for the new section 6.5.5.4 "Registration Requested by Recipient? > > reads ?? the ISP should register that assignment?, then ARIN would send on any > > received customer complaint to the ISP, and remind the ISP that they should > > follow number resource policy in this regard but not otherwise taking any action. > > > > If the language for the new section 6.5.5.4 "Registration Requested by Recipient? > > reads ?? the ISP shall register that assignment?, then failure to do so would be > > a far more serious matter that, if left unaddressed on a chronic manner, could have > > me discussing the customer complaints as a sign of potential failure to comply with > > number resource policy, including the consequences (i.e. potential revocation of > > the IPv6 number resources.) > > > > I would note that the community should be very clear about its intentions for ISPs > > with regard to customer requested reassignment publication, given there is large > > difference in obligations that result from policy language choice. ARIN staff remains, > > as always, looking forward to implementing whatever policy emerges from the > > consensus-based policy development process. > > > > Thanks! > > /John > > > > John Curran > > President and CEO > > American Registry for Internet Numbers > > > > > > > > > > > > > > > > _______________________________________________ > > 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: > > > ------------------------------ > > Message: 2 > Date: Thu, 28 Sep 2017 11:03:55 -0500 > From: Owen DeLong > > To: Kevin Blumberg > > Cc: John Curran >, Jason Schiller > >, "arin-ppml at arin.net " > > Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2017-5: > Improved IPv6 Registration Requirements > Message-ID: > > Content-Type: text/plain; charset="utf-8" > > While I wouldn?t consider it an editorial change, I would consider it a minor change, which, if it had good community discussion and support at the meeting, would, IMHO, be within the scope of pre-last-call changes that could be made between the PPM and last call. > > The AC has, as has been mentioned before, significant discretion in determining what is a ?minor change?. > > This is strictly my own opinion and may or may not be shared by other AC members, staff, or anyone else. > > Owen > > > On Sep 28, 2017, at 10:46 AM, Kevin Blumberg > wrote: > > > > I support the policy as written. <> > > > > If the stick isn?t big enough it appears a simple policy change could be used, not just for this section but all the other areas ?should? is used. > > > > I would like to point out that ?should? is currently used 30 times in the NRPM. > > > > In reading John?s explanation, I can?t see ?should? and ?shall? being considered an editorial change. To extend the policy cycle to another meeting would be far worse. > > > > Out of curiosity, how often has ARIN had to deal with SWIP issues like this, where the other party ignored you? > > > > Thanks, > > > > Kevin Blumberg > > > > > > From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net ] On Behalf Of John Curran > > Sent: Wednesday, September 27, 2017 5:59 PM > > To: Jason Schiller > > > Cc: arin-ppml at arin.net > > Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements > > > > On 26 Sep 2017, at 3:18 PM, Jason Schiller >> wrote: > > > > I oppose as written. > > > > There should not be a different standard of requirement for: > > - re-allocation > > - reassignment containing a /47 or more addresses > > - subdelegation of any size that will be individually announced > > > > which is "shall" > > > > and Registration Requested by Recipient > > > > which is "should" > > > > I would support if they are both "shall". > > > > Can ARIN staff discuss what actions it will take if an ISP's > > down stream customer contacts them and explains that their > > ISP refuses to SWIP their reassignment to them? > > > > Will they do anything more than reach out to the ISP and tell > > them they "should" SWIP it? > > > > Jason - > > > > If this policy change 2017-5 is adopted, then a provider that has IPv6 space from ARIN > > but routinely fails to publish registration information (for /47 or larger reassignments) > > would be in violation, and ARIN would have clear policy language that would enable > > us to discuss with the ISP the need to publish this information in a timely manner. > > > > Service providers who blatantly ignore such a provision on an ongoing basis will be > > in the enviable position of hearing me chat with them about their obligations to follow > > ARIN number resource policy, including the consequences (i.e. potential revocation > > of the IPv6 number resources.) > > > > If the langauge for the new section 6.5.5.4 "Registration Requested by Recipient? > > reads ?? the ISP should register that assignment?, then ARIN would send on any > > received customer complaint to the ISP, and remind the ISP that they should > > follow number resource policy in this regard but not otherwise taking any action. > > > > If the language for the new section 6.5.5.4 "Registration Requested by Recipient? > > reads ?? the ISP shall register that assignment?, then failure to do so would be > > a far more serious matter that, if left unaddressed on a chronic manner, could have > > me discussing the customer complaints as a sign of potential failure to comply with > > number resource policy, including the consequences (i.e. potential revocation of > > the IPv6 number resources.) > > > > I would note that the community should be very clear about its intentions for ISPs > > with regard to customer requested reassignment publication, given there is large > > difference in obligations that result from policy language choice. ARIN staff remains, > > as always, looking forward to implementing whatever policy emerges from the > > consensus-based policy development process. > > > > Thanks! > > /John > > > > John Curran > > President and CEO > > American Registry for Internet Numbers > > > > > > > > > > > > > > > > _______________________________________________ > > 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: > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > ARIN-PPML mailing list > ARIN-PPML at arin.net > http://lists.arin.net/mailman/listinfo/arin-ppml > > ------------------------------ > > End of ARIN-PPML Digest, Vol 147, Issue 43 > ****************************************** > > _______________________________________________ > 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 kevinb at thewire.ca Thu Sep 28 13:56:51 2017 From: kevinb at thewire.ca (Kevin Blumberg) Date: Thu, 28 Sep 2017 17:56:51 +0000 Subject: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements In-Reply-To: <8AC5AC05-1F11-4D94-BBE2-06B2219351E9@semihuman.com> References: <4D69C6C7-A6C1-41DD-8CF7-7DC198973E9F@arin.net> <7E7773B523E82C478734E793E58F69E7A52C530A@SBS2011.thewireinc.local> <8AC5AC05-1F11-4D94-BBE2-06B2219351E9@semihuman.com> Message-ID: <7E7773B523E82C478734E793E58F69E7A52C5BFD@SBS2011.thewireinc.local> Chris, I have had a difference of opinion in the past, with members of the community, with what constitutes an editorial change. I have always erred on the side of caution. While I?m indifferent to the options, I am strongly in support of this policy moving forward. If there is a chance that the change will be questioned during last call, and prevent the policy from moving forward, I?m opposed to any alteration. I believe that staff have shown significant implementation differences between the two words. Some assistance from the Advisory Council and/or Staff to the community as what would constitute an editorial change would probably be helpful. Thanks, Kevin Blumberg From: Chris Woodfield [mailto:chris at semihuman.com] Sent: Thursday, September 28, 2017 1:21 PM To: Owen DeLong ; arin-ppml at arin.net Cc: Kevin Blumberg Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements I agree with Owen?s assessment. If there is sufficient community support for changing the phrase to ?shall? at the PPM - I?d define ?sufficient community support? as a show of hands on that specific word choice, in addition to the discussion here - I see no need to require another public consultation in order to go to last call incorporating that change in terms. I?m personally in favor of ?shall", although I still support as written. Perfect as enemy of good, etc etc. Thanks, -C On Sep 28, 2017, at 9:03 AM, Owen DeLong > wrote: While I wouldn?t consider it an editorial change, I would consider it a minor change, which, if it had good community discussion and support at the meeting, would, IMHO, be within the scope of pre-last-call changes that could be made between the PPM and last call. The AC has, as has been mentioned before, significant discretion in determining what is a ?minor change?. This is strictly my own opinion and may or may not be shared by other AC members, staff, or anyone else. Owen On Sep 28, 2017, at 10:46 AM, Kevin Blumberg > wrote: I support the policy as written. If the stick isn?t big enough it appears a simple policy change could be used, not just for this section but all the other areas ?should? is used. I would like to point out that ?should? is currently used 30 times in the NRPM. In reading John?s explanation, I can?t see ?should? and ?shall? being considered an editorial change. To extend the policy cycle to another meeting would be far worse. Out of curiosity, how often has ARIN had to deal with SWIP issues like this, where the other party ignored you? Thanks, Kevin Blumberg From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of John Curran Sent: Wednesday, September 27, 2017 5:59 PM To: Jason Schiller > Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements On 26 Sep 2017, at 3:18 PM, Jason Schiller > wrote: I oppose as written. There should not be a different standard of requirement for: - re-allocation - reassignment containing a /47 or more addresses - subdelegation of any size that will be individually announced which is "shall" and Registration Requested by Recipient which is "should" I would support if they are both "shall". Can ARIN staff discuss what actions it will take if an ISP's down stream customer contacts them and explains that their ISP refuses to SWIP their reassignment to them? Will they do anything more than reach out to the ISP and tell them they "should" SWIP it? Jason - If this policy change 2017-5 is adopted, then a provider that has IPv6 space from ARIN but routinely fails to publish registration information (for /47 or larger reassignments) would be in violation, and ARIN would have clear policy language that would enable us to discuss with the ISP the need to publish this information in a timely manner. Service providers who blatantly ignore such a provision on an ongoing basis will be in the enviable position of hearing me chat with them about their obligations to follow ARIN number resource policy, including the consequences (i.e. potential revocation of the IPv6 number resources.) If the langauge for the new section 6.5.5.4 "Registration Requested by Recipient? reads ?? the ISP should register that assignment?, then ARIN would send on any received customer complaint to the ISP, and remind the ISP that they should follow number resource policy in this regard but not otherwise taking any action. If the language for the new section 6.5.5.4 "Registration Requested by Recipient? reads ?? the ISP shall register that assignment?, then failure to do so would be a far more serious matter that, if left unaddressed on a chronic manner, could have me discussing the customer complaints as a sign of potential failure to comply with number resource policy, including the consequences (i.e. potential revocation of the IPv6 number resources.) I would note that the community should be very clear about its intentions for ISPs with regard to customer requested reassignment publication, given there is large difference in obligations that result from policy language choice. ARIN staff remains, as always, looking forward to implementing whatever policy emerges from the consensus-based policy development process. Thanks! /John John Curran President and CEO American Registry for Internet Numbers _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at semihuman.com Thu Sep 28 14:09:16 2017 From: chris at semihuman.com (Chris Woodfield) Date: Thu, 28 Sep 2017 11:09:16 -0700 Subject: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements In-Reply-To: <7E7773B523E82C478734E793E58F69E7A52C5BFD@SBS2011.thewireinc.local> References: <4D69C6C7-A6C1-41DD-8CF7-7DC198973E9F@arin.net> <7E7773B523E82C478734E793E58F69E7A52C530A@SBS2011.thewireinc.local> <8AC5AC05-1F11-4D94-BBE2-06B2219351E9@semihuman.com> <7E7773B523E82C478734E793E58F69E7A52C5BFD@SBS2011.thewireinc.local> Message-ID: <8EC4E04F-4CF2-4061-9598-D1A42CE80AD4@semihuman.com> I think we?re talking about the difference between ?editorial change? and ?minor change?. And editorial change, as I understand it, requires no PPM consensus, which isn?t what we?re discussing here. I?d agree with your point that staff would probably be the best arbiters of the implementation changes, which would in turn guide as to whether it?s acceptable to discuss the word change and move forward at PPM, or to require additional consultation if the community consensus is to require the change before adoption. Staff has guided on the practical implications of the change; it?s up to the community to decide whether or not that?s a desired outcome. I?d presume that if the proposal is adopted as written, there are several people primed to submit a new policy proposal to change ?should? to ?shall?. That, in my opinion, is a very reasonable path forward as well. -C > On Sep 28, 2017, at 10:56 AM, Kevin Blumberg wrote: > > Chris, <> > > I have had a difference of opinion in the past, with members of the community, with what constitutes an editorial change. I have always erred on the side of caution. > > While I?m indifferent to the options, I am strongly in support of this policy moving forward. > > If there is a chance that the change will be questioned during last call, and prevent the policy from moving forward, I?m opposed to any alteration. > > I believe that staff have shown significant implementation differences between the two words. > > Some assistance from the Advisory Council and/or Staff to the community as what would constitute an editorial change would probably be helpful. > > Thanks, > > Kevin Blumberg > > From: Chris Woodfield [mailto:chris at semihuman.com] > Sent: Thursday, September 28, 2017 1:21 PM > To: Owen DeLong ; arin-ppml at arin.net > Cc: Kevin Blumberg > Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements > > I agree with Owen?s assessment. If there is sufficient community support for changing the phrase to ?shall? at the PPM - I?d define ?sufficient community support? as a show of hands on that specific word choice, in addition to the discussion here - I see no need to require another public consultation in order to go to last call incorporating that change in terms. > > I?m personally in favor of ?shall", although I still support as written. Perfect as enemy of good, etc etc. > > Thanks, > > -C > > On Sep 28, 2017, at 9:03 AM, Owen DeLong > wrote: > > While I wouldn?t consider it an editorial change, I would consider it a minor change, which, if it had good community discussion and support at the meeting, would, IMHO, be within the scope of pre-last-call changes that could be made between the PPM and last call. > > The AC has, as has been mentioned before, significant discretion in determining what is a ?minor change?. > > This is strictly my own opinion and may or may not be shared by other AC members, staff, or anyone else. > > Owen > > On Sep 28, 2017, at 10:46 AM, Kevin Blumberg > wrote: > > I support the policy as written. > > If the stick isn?t big enough it appears a simple policy change could be used, not just for this section but all the other areas ?should? is used. > > I would like to point out that ?should? is currently used 30 times in the NRPM. > > In reading John?s explanation, I can?t see ?should? and ?shall? being considered an editorial change. To extend the policy cycle to another meeting would be far worse. > > Out of curiosity, how often has ARIN had to deal with SWIP issues like this, where the other party ignored you? > > Thanks, > > Kevin Blumberg > > > From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net ] On Behalf Of John Curran > Sent: Wednesday, September 27, 2017 5:59 PM > To: Jason Schiller > > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements > > On 26 Sep 2017, at 3:18 PM, Jason Schiller > wrote: > > I oppose as written. > > There should not be a different standard of requirement for: > - re-allocation > - reassignment containing a /47 or more addresses > - subdelegation of any size that will be individually announced > > which is "shall" > > and Registration Requested by Recipient > > which is "should" > > I would support if they are both "shall". > > Can ARIN staff discuss what actions it will take if an ISP's > down stream customer contacts them and explains that their > ISP refuses to SWIP their reassignment to them? > > Will they do anything more than reach out to the ISP and tell > them they "should" SWIP it? > > Jason - > > If this policy change 2017-5 is adopted, then a provider that has IPv6 space from ARIN > but routinely fails to publish registration information (for /47 or larger reassignments) > would be in violation, and ARIN would have clear policy language that would enable > us to discuss with the ISP the need to publish this information in a timely manner. > > Service providers who blatantly ignore such a provision on an ongoing basis will be > in the enviable position of hearing me chat with them about their obligations to follow > ARIN number resource policy, including the consequences (i.e. potential revocation > of the IPv6 number resources.) > > If the langauge for the new section 6.5.5.4 "Registration Requested by Recipient? > reads ?? the ISP should register that assignment?, then ARIN would send on any > received customer complaint to the ISP, and remind the ISP that they should > follow number resource policy in this regard but not otherwise taking any action. > > If the language for the new section 6.5.5.4 "Registration Requested by Recipient? > reads ?? the ISP shall register that assignment?, then failure to do so would be > a far more serious matter that, if left unaddressed on a chronic manner, could have > me discussing the customer complaints as a sign of potential failure to comply with > number resource policy, including the consequences (i.e. potential revocation of > the IPv6 number resources.) > > I would note that the community should be very clear about its intentions for ISPs > with regard to customer requested reassignment publication, given there is large > difference in obligations that result from policy language choice. ARIN staff remains, > as always, looking forward to implementing whatever policy emerges from the > consensus-based policy development process. > > Thanks! > /John > > John Curran > President and CEO > American Registry for Internet Numbers > > > > > > > > _______________________________________________ > 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 jschiller at google.com Thu Sep 28 14:30:21 2017 From: jschiller at google.com (Jason Schiller) Date: Thu, 28 Sep 2017 14:30:21 -0400 Subject: [arin-ppml] ARIN-PPML 2017-5 In-Reply-To: References: Message-ID: Rudi, Thanks for commenting on the "shall question". Chris, Can you comment on the "shall" question? Rudi, As it currently stands all static IPv6 customers with a /64 or more are SWIP'd "Each static IPv6 assignment containing a /64 or more addresses shall be registered in the WHOIS directory via SWIP" Dynamic customers don't get a re-assignment or re-allocation. Usually there is a large aggregate re-assigned to the ISP and designated as used by that ISP's customers in a given market. I imagine there are not very many customers with a static IPv6 address smaller than a /64 who would want their address SWIP'd, likely even less who plan to have static down stream customers, and certainly won't be multi-homing, or routing their space discreetly. In the unlikely event that there are, I expect there would be a 6 month time period pending implementation, and even after that point ARIN would happily work with ISPs who are working in good faith, and making progress towards removing hurdles to accomplish this. As it stands this proposed policy has a lower SWIP burden than the current one. ___Jason On Thu, Sep 28, 2017 at 1:26 PM, Chris Woodfield wrote: > Rudolph, > > My reading of the proposal is that the registration is triggered by the > request from the downstream recipient, which implies that if no prior > requests have been received, then there would be no duty to register. > Requests from downstreams received after the policy is implemented would be > subject to these terms. > > I?ll agree that this is ambiguous re: requests from downstreams received > prior to implementation, but in practical terms, I?d expect interested > downstreams to be aware of the policy change and simply resubmit that > request, if the prior request was not granted. > > Thanks, > > -C > > On Sep 28, 2017, at 10:13 AM, Rudolph Daniel > wrote: > > I am in support of the policy proposal with "shall" but I would like to > know of possible negative impact if approved as policy; on the past > reassignments that were not SWIP ed. > Is this perceived as an issue; or will the policy be retroactive? Either > way. > > > Rudi Daniel > *danielcharles consulting > * > > > > On Thu, Sep 28, 2017 at 12:05 PM, wrote: > >> Send ARIN-PPML mailing list submissions to >> arin-ppml at arin.net >> >> To subscribe or unsubscribe via the World Wide Web, visit >> http://lists.arin.net/mailman/listinfo/arin-ppml >> or, via email, send a message with subject or body 'help' to >> arin-ppml-request at arin.net >> >> You can reach the person managing the list at >> arin-ppml-owner at arin.net >> >> When replying, please edit your Subject line so it is more specific >> than "Re: Contents of ARIN-PPML digest..." >> >> >> Today's Topics: >> >> 1. Re: Recommended Draft Policy ARIN-2017-5: Improved IPv6 >> Registration Requirements (Owen DeLong) >> 2. Re: Recommended Draft Policy ARIN-2017-5: Improved IPv6 >> Registration Requirements (Owen DeLong) >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Thu, 28 Sep 2017 10:46:01 -0500 >> From: Owen DeLong >> To: John Curran >> Cc: Jason Schiller , "arin-ppml at arin.net" >> >> Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2017-5: >> Improved IPv6 Registration Requirements >> Message-ID: <314B3DC2-87BA-434D-9EEC-F2BD60F678EC at delong.com> >> Content-Type: text/plain; charset="utf-8" >> >> Given this, I personally think that shall is the better choice of wording >> for 6.5.5.4. >> >> Owen >> >> > On Sep 27, 2017, at 4:59 PM, John Curran wrote: >> > >> > On 26 Sep 2017, at 3:18 PM, Jason Schiller > > wrote: >> >> >> >> I oppose as written. >> >> >> >> There should not be a different standard of requirement for: >> >> - re-allocation >> >> - reassignment containing a /47 or more addresses >> >> - subdelegation of any size that will be individually announced >> >> >> >> which is "shall" >> >> >> >> and Registration Requested by Recipient >> >> >> >> which is "should" >> >> >> >> I would support if they are both "shall". >> >> >> >> Can ARIN staff discuss what actions it will take if an ISP's >> >> down stream customer contacts them and explains that their >> >> ISP refuses to SWIP their reassignment to them? >> >> >> >> Will they do anything more than reach out to the ISP and tell >> >> them they "should" SWIP it? >> > >> > Jason - >> > >> > If this policy change 2017-5 is adopted, then a provider that has >> IPv6 space from ARIN >> > but routinely fails to publish registration information (for /47 or >> larger reassignments) >> > would be in violation, and ARIN would have clear policy language >> that would enable >> > us to discuss with the ISP the need to publish this information in a >> timely manner. >> > >> > Service providers who blatantly ignore such a provision on an >> ongoing basis will be >> > in the enviable position of hearing me chat with them about their >> obligations to follow >> > ARIN number resource policy, including the consequences (i.e. >> potential revocation >> > of the IPv6 number resources.) >> > >> > If the langauge for the new section 6.5.5.4 "Registration Requested >> by Recipient? >> > reads ?? the ISP should register that assignment?, then ARIN would >> send on any >> > received customer complaint to the ISP, and remind the ISP that they >> should >> > follow number resource policy in this regard but not otherwise >> taking any action. >> > >> > If the language for the new section 6.5.5.4 "Registration Requested >> by Recipient? >> > reads ?? the ISP shall register that assignment?, then failure to do >> so would be >> > a far more serious matter that, if left unaddressed on a chronic >> manner, could have >> > me discussing the customer complaints as a sign of potential failure >> to comply with >> > number resource policy, including the consequences (i.e. potential >> revocation of >> > the IPv6 number resources.) >> > >> > I would note that the community should be very clear about its >> intentions for ISPs >> > with regard to customer requested reassignment publication, given >> there is large >> > difference in obligations that result from policy language choice. >> ARIN staff remains, >> > as always, looking forward to implementing whatever policy emerges >> from the >> > consensus-based policy development process. >> > >> > Thanks! >> > /John >> > >> > John Curran >> > President and CEO >> > American Registry for Internet Numbers >> > >> > >> > >> > >> > >> > >> > >> > _______________________________________________ >> > 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: > 20170928/6d6c415b/attachment-0001.html> >> >> ------------------------------ >> >> Message: 2 >> Date: Thu, 28 Sep 2017 11:03:55 -0500 >> From: Owen DeLong >> To: Kevin Blumberg >> Cc: John Curran , Jason Schiller >> , "arin-ppml at arin.net" >> Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2017-5: >> Improved IPv6 Registration Requirements >> Message-ID: >> Content-Type: text/plain; charset="utf-8" >> >> While I wouldn?t consider it an editorial change, I would consider it a >> minor change, which, if it had good community discussion and support at the >> meeting, would, IMHO, be within the scope of pre-last-call changes that >> could be made between the PPM and last call. >> >> The AC has, as has been mentioned before, significant discretion in >> determining what is a ?minor change?. >> >> This is strictly my own opinion and may or may not be shared by other AC >> members, staff, or anyone else. >> >> Owen >> >> > On Sep 28, 2017, at 10:46 AM, Kevin Blumberg wrote: >> > >> > I support the policy as written. <> >> > >> > If the stick isn?t big enough it appears a simple policy change could >> be used, not just for this section but all the other areas ?should? is used. >> > >> > I would like to point out that ?should? is currently used 30 times in >> the NRPM. >> > >> > In reading John?s explanation, I can?t see ?should? and ?shall? being >> considered an editorial change. To extend the policy cycle to another >> meeting would be far worse. >> > >> > Out of curiosity, how often has ARIN had to deal with SWIP issues like >> this, where the other party ignored you? >> > >> > Thanks, >> > >> > Kevin Blumberg >> > >> > >> > From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of John >> Curran >> > Sent: Wednesday, September 27, 2017 5:59 PM >> > To: Jason Schiller >> > Cc: arin-ppml at arin.net >> > Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved >> IPv6 Registration Requirements >> > >> > On 26 Sep 2017, at 3:18 PM, Jason Schiller > > wrote: >> > >> > I oppose as written. >> > >> > There should not be a different standard of requirement for: >> > - re-allocation >> > - reassignment containing a /47 or more addresses >> > - subdelegation of any size that will be individually announced >> > >> > which is "shall" >> > >> > and Registration Requested by Recipient >> > >> > which is "should" >> > >> > I would support if they are both "shall". >> > >> > Can ARIN staff discuss what actions it will take if an ISP's >> > down stream customer contacts them and explains that their >> > ISP refuses to SWIP their reassignment to them? >> > >> > Will they do anything more than reach out to the ISP and tell >> > them they "should" SWIP it? >> > >> > Jason - >> > >> > If this policy change 2017-5 is adopted, then a provider that has >> IPv6 space from ARIN >> > but routinely fails to publish registration information (for /47 or >> larger reassignments) >> > would be in violation, and ARIN would have clear policy language >> that would enable >> > us to discuss with the ISP the need to publish this information in a >> timely manner. >> > >> > Service providers who blatantly ignore such a provision on an >> ongoing basis will be >> > in the enviable position of hearing me chat with them about their >> obligations to follow >> > ARIN number resource policy, including the consequences (i.e. >> potential revocation >> > of the IPv6 number resources.) >> > >> > If the langauge for the new section 6.5.5.4 "Registration Requested >> by Recipient? >> > reads ?? the ISP should register that assignment?, then ARIN would >> send on any >> > received customer complaint to the ISP, and remind the ISP that they >> should >> > follow number resource policy in this regard but not otherwise >> taking any action. >> > >> > If the language for the new section 6.5.5.4 "Registration Requested >> by Recipient? >> > reads ?? the ISP shall register that assignment?, then failure to do >> so would be >> > a far more serious matter that, if left unaddressed on a chronic >> manner, could have >> > me discussing the customer complaints as a sign of potential failure >> to comply with >> > number resource policy, including the consequences (i.e. potential >> revocation of >> > the IPv6 number resources.) >> > >> > I would note that the community should be very clear about its >> intentions for ISPs >> > with regard to customer requested reassignment publication, given >> there is large >> > difference in obligations that result from policy language choice. >> ARIN staff remains, >> > as always, looking forward to implementing whatever policy emerges >> from the >> > consensus-based policy development process. >> > >> > Thanks! >> > /John >> > >> > John Curran >> > President and CEO >> > American Registry for Internet Numbers >> > >> > >> > >> > >> > >> > >> > >> > _______________________________________________ >> > 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: > 20170928/0fbeb396/attachment.html> >> >> ------------------------------ >> >> Subject: Digest Footer >> >> _______________________________________________ >> ARIN-PPML mailing list >> ARIN-PPML at arin.net >> http://lists.arin.net/mailman/listinfo/arin-ppml >> >> ------------------------------ >> >> End of ARIN-PPML Digest, Vol 147, Issue 43 >> ****************************************** >> > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwinters at edwardrose.com Thu Sep 28 14:31:57 2017 From: mwinters at edwardrose.com (Michael Winters) Date: Thu, 28 Sep 2017 18:31:57 +0000 Subject: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements In-Reply-To: <7E7773B523E82C478734E793E58F69E7A52C530A@SBS2011.thewireinc.local> References: <4D69C6C7-A6C1-41DD-8CF7-7DC198973E9F@arin.net> <7E7773B523E82C478734E793E58F69E7A52C530A@SBS2011.thewireinc.local> Message-ID: <319b20a3907f40059c6da8ee2d209563@kz-mail01.manifold.edwardrosekzoo.com> I support the policy as written. In my opinion, there is a huge difference between should and shall. If it does become an issue down the road, we can always change it later. Thanks, Mike From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Kevin Blumberg Sent: Thursday, September 28, 2017 11:46 AM To: John Curran ; Jason Schiller Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements I support the policy as written. If the stick isn?t big enough it appears a simple policy change could be used, not just for this section but all the other areas ?should? is used. I would like to point out that ?should? is currently used 30 times in the NRPM. In reading John?s explanation, I can?t see ?should? and ?shall? being considered an editorial change. To extend the policy cycle to another meeting would be far worse. Out of curiosity, how often has ARIN had to deal with SWIP issues like this, where the other party ignored you? Thanks, Kevin Blumberg From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of John Curran Sent: Wednesday, September 27, 2017 5:59 PM To: Jason Schiller > Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements On 26 Sep 2017, at 3:18 PM, Jason Schiller > wrote: I oppose as written. There should not be a different standard of requirement for: - re-allocation - reassignment containing a /47 or more addresses - subdelegation of any size that will be individually announced which is "shall" and Registration Requested by Recipient which is "should" I would support if they are both "shall". Can ARIN staff discuss what actions it will take if an ISP's down stream customer contacts them and explains that their ISP refuses to SWIP their reassignment to them? Will they do anything more than reach out to the ISP and tell them they "should" SWIP it? Jason - If this policy change 2017-5 is adopted, then a provider that has IPv6 space from ARIN but routinely fails to publish registration information (for /47 or larger reassignments) would be in violation, and ARIN would have clear policy language that would enable us to discuss with the ISP the need to publish this information in a timely manner. Service providers who blatantly ignore such a provision on an ongoing basis will be in the enviable position of hearing me chat with them about their obligations to follow ARIN number resource policy, including the consequences (i.e. potential revocation of the IPv6 number resources.) If the langauge for the new section 6.5.5.4 "Registration Requested by Recipient? reads ?? the ISP should register that assignment?, then ARIN would send on any received customer complaint to the ISP, and remind the ISP that they should follow number resource policy in this regard but not otherwise taking any action. If the language for the new section 6.5.5.4 "Registration Requested by Recipient? reads ?? the ISP shall register that assignment?, then failure to do so would be a far more serious matter that, if left unaddressed on a chronic manner, could have me discussing the customer complaints as a sign of potential failure to comply with number resource policy, including the consequences (i.e. potential revocation of the IPv6 number resources.) I would note that the community should be very clear about its intentions for ISPs with regard to customer requested reassignment publication, given there is large difference in obligations that result from policy language choice. ARIN staff remains, as always, looking forward to implementing whatever policy emerges from the consensus-based policy development process. Thanks! /John John Curran President and CEO American Registry for Internet Numbers ________________________________ ________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjones at vt.edu Thu Sep 28 14:33:06 2017 From: bjones at vt.edu (Brian Jones) Date: Thu, 28 Sep 2017 18:33:06 +0000 Subject: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements In-Reply-To: <7E7773B523E82C478734E793E58F69E7A52C5BFD@SBS2011.thewireinc.local> References: <4D69C6C7-A6C1-41DD-8CF7-7DC198973E9F@arin.net> <7E7773B523E82C478734E793E58F69E7A52C530A@SBS2011.thewireinc.local> <8AC5AC05-1F11-4D94-BBE2-06B2219351E9@semihuman.com> <7E7773B523E82C478734E793E58F69E7A52C5BFD@SBS2011.thewireinc.local> Message-ID: I continue to support the proposal as written. Changes can be made, if necessary, later and "shall" can be incorporated at that time. Brian Jones On Thu, Sep 28, 2017 at 1:57 PM Kevin Blumberg wrote: > Chris, > > > > I have had a difference of opinion in the past, with members of the > community, with what constitutes an editorial change. I have always erred > on the side of caution. > > > > While I?m indifferent to the options, I am strongly in support of this > policy moving forward. > > > > If there is a chance that the change will be questioned during last call, > and prevent the policy from moving forward, I?m opposed to any alteration. > > > > I believe that staff have shown significant implementation differences > between the two words. > > > > Some assistance from the Advisory Council and/or Staff to the community as > what would constitute an editorial change would probably be helpful. > > > > Thanks, > > > > Kevin Blumberg > > > > *From:* Chris Woodfield [mailto:chris at semihuman.com] > *Sent:* Thursday, September 28, 2017 1:21 PM > *To:* Owen DeLong ; arin-ppml at arin.net > *Cc:* Kevin Blumberg > > > *Subject:* Re: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved > IPv6 Registration Requirements > > > > I agree with Owen?s assessment. If there is sufficient community support > for changing the phrase to ?shall? at the PPM - I?d define ?sufficient > community support? as a show of hands on that specific word choice, in > addition to the discussion here - I see no need to require another public > consultation in order to go to last call incorporating that change in terms. > > > > I?m personally in favor of ?shall", although I still support as written. > Perfect as enemy of good, etc etc. > > > > Thanks, > > > > -C > > > > On Sep 28, 2017, at 9:03 AM, Owen DeLong wrote: > > > > While I wouldn?t consider it an editorial change, I would consider it a > minor change, which, if it had good community discussion and support at the > meeting, would, IMHO, be within the scope of pre-last-call changes that > could be made between the PPM and last call. > > > > The AC has, as has been mentioned before, significant discretion in > determining what is a ?minor change?. > > > > This is strictly my own opinion and may or may not be shared by other AC > members, staff, or anyone else. > > > > Owen > > > > On Sep 28, 2017, at 10:46 AM, Kevin Blumberg wrote: > > > > I support the policy as written. > > > > If the stick isn?t big enough it appears a simple policy change could be > used, not just for this section but all the other areas ?should? is used. > > > > I would like to point out that ?should? is currently used 30 times in the > NRPM. > > > > In reading John?s explanation, I can?t see ?should? and ?shall? being > considered an editorial change. To extend the policy cycle to another > meeting would be far worse. > > > > Out of curiosity, how often has ARIN had to deal with SWIP issues like > this, where the other party ignored you? > > > > Thanks, > > > > Kevin Blumberg > > > > > > *From:* ARIN-PPML [mailto:arin-ppml-bounces at arin.net > ] *On Behalf Of *John Curran > *Sent:* Wednesday, September 27, 2017 5:59 PM > *To:* Jason Schiller > *Cc:* arin-ppml at arin.net > *Subject:* Re: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved > IPv6 Registration Requirements > > > > On 26 Sep 2017, at 3:18 PM, Jason Schiller wrote: > > > > I oppose as written. > > > > There should not be a different standard of requirement for: > > - re-allocation > > - reassignment containing a /47 or more addresses > > - subdelegation of any size that will be individually announced > > > > which is "shall" > > > > and Registration Requested by Recipient > > > > which is "should" > > > > I would support if they are both "shall". > > > > Can ARIN staff discuss what actions it will take if an ISP's > > down stream customer contacts them and explains that their > > ISP refuses to SWIP their reassignment to them? > > > > Will they do anything more than reach out to the ISP and tell > > them they "should" SWIP it? > > > > Jason - > > If this policy change 2017-5 is adopted, then a provider that has IPv6 > space from ARIN > > but routinely fails to publish registration information (for /47 or > larger reassignments) > > would be in violation, and ARIN would have clear policy language that > would enable > > us to discuss with the ISP the need to publish this information in a > timely manner. > > > Service providers who blatantly ignore such a provision on an ongoing > basis will be > in the enviable position of hearing me chat with them about their > obligations to follow > ARIN number resource policy, including the consequences (i.e. potential > revocation > > of the IPv6 number resources.) > > > > If the langauge for the new section 6.5.5.4 "Registration Requested by > Recipient? > > reads ?? the ISP should register that assignment?, then ARIN would send > on any > > received customer complaint to the ISP, and remind the ISP that they > should > > follow number resource policy in this regard but not otherwise taking > any action. > > > > If the language for the new section 6.5.5.4 "Registration Requested by > Recipient? > > reads ?? the ISP shall register that assignment?, then failure to do so > would be > > a far more serious matter that, if left unaddressed on a chronic > manner, could have > > me discussing the customer complaints as a sign of potential failure to > comply with > > number resource policy, including the consequences (i.e. potential > revocation of > > the IPv6 number resources.) > > > > I would note that the community should be very clear about its > intentions for ISPs > > with regard to customer requested reassignment publication, given there > is large > > difference in obligations that result from policy language choice. > ARIN staff remains, > > as always, looking forward to implementing whatever policy emerges from > the > > consensus-based policy development process. > > > > Thanks! > > /John > > > > John Curran > > President and CEO > > American Registry for Internet Numbers > > > > > > > > > > > > > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rudi.daniel at gmail.com Thu Sep 28 14:40:06 2017 From: rudi.daniel at gmail.com (Rudolph Daniel) Date: Thu, 28 Sep 2017 14:40:06 -0400 Subject: [arin-ppml] ARIN-PPML 2017-5 Message-ID: Jason /Chris Thank you for the comment; good to go...I will go with "shall". Rudi Daniel *danielcharles consulting * On Thu, Sep 28, 2017 at 2:30 PM, Jason Schiller wrote: > Rudi, > Thanks for commenting on the "shall question". > > Chris, > > Can you comment on the "shall" question? > > Rudi, > > As it currently stands all static IPv6 customers with a /64 or more are > SWIP'd > > "Each static IPv6 assignment containing a /64 or more addresses > shall be registered in the WHOIS directory via SWIP" > > Dynamic customers don't get a re-assignment or re-allocation. > Usually there is a large aggregate re-assigned to the ISP > and designated as used by that ISP's customers in a given market. > > > I imagine there are not very many customers with a static IPv6 address > smaller than a /64 who would want their address SWIP'd, likely even less > who plan to have static down stream customers, and certainly > won't be multi-homing, or routing their space discreetly. > > > In the unlikely event that there are, I expect there would be a 6 month > time period pending implementation, and even after that point ARIN > would happily work with ISPs who are working in good faith, and making > progress towards removing hurdles to accomplish this. > > As it stands this proposed policy has a lower SWIP burden than the current > one. > > ___Jason > > > > > > > > On Thu, Sep 28, 2017 at 1:26 PM, Chris Woodfield > wrote: > >> Rudolph, >> >> My reading of the proposal is that the registration is triggered by the >> request from the downstream recipient, which implies that if no prior >> requests have been received, then there would be no duty to register. >> Requests from downstreams received after the policy is implemented would be >> subject to these terms. >> >> I?ll agree that this is ambiguous re: requests from downstreams received >> prior to implementation, but in practical terms, I?d expect interested >> downstreams to be aware of the policy change and simply resubmit that >> request, if the prior request was not granted. >> >> Thanks, >> >> -C >> >> On Sep 28, 2017, at 10:13 AM, Rudolph Daniel >> wrote: >> >> I am in support of the policy proposal with "shall" but I would like to >> know of possible negative impact if approved as policy; on the past >> reassignments that were not SWIP ed. >> Is this perceived as an issue; or will the policy be retroactive? Either >> way. >> >> >> Rudi Daniel >> *danielcharles consulting >> * >> >> >> >> On Thu, Sep 28, 2017 at 12:05 PM, wrote: >> >>> Send ARIN-PPML mailing list submissions to >>> arin-ppml at arin.net >>> >>> To subscribe or unsubscribe via the World Wide Web, visit >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> or, via email, send a message with subject or body 'help' to >>> arin-ppml-request at arin.net >>> >>> You can reach the person managing the list at >>> arin-ppml-owner at arin.net >>> >>> When replying, please edit your Subject line so it is more specific >>> than "Re: Contents of ARIN-PPML digest..." >>> >>> >>> Today's Topics: >>> >>> 1. Re: Recommended Draft Policy ARIN-2017-5: Improved IPv6 >>> Registration Requirements (Owen DeLong) >>> 2. Re: Recommended Draft Policy ARIN-2017-5: Improved IPv6 >>> Registration Requirements (Owen DeLong) >>> >>> >>> ---------------------------------------------------------------------- >>> >>> Message: 1 >>> Date: Thu, 28 Sep 2017 10:46:01 -0500 >>> From: Owen DeLong >>> To: John Curran >>> Cc: Jason Schiller , "arin-ppml at arin.net" >>> >>> Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2017-5: >>> Improved IPv6 Registration Requirements >>> Message-ID: <314B3DC2-87BA-434D-9EEC-F2BD60F678EC at delong.com> >>> Content-Type: text/plain; charset="utf-8" >>> >>> Given this, I personally think that shall is the better choice of >>> wording for 6.5.5.4. >>> >>> Owen >>> >>> > On Sep 27, 2017, at 4:59 PM, John Curran wrote: >>> > >>> > On 26 Sep 2017, at 3:18 PM, Jason Schiller >> > wrote: >>> >> >>> >> I oppose as written. >>> >> >>> >> There should not be a different standard of requirement for: >>> >> - re-allocation >>> >> - reassignment containing a /47 or more addresses >>> >> - subdelegation of any size that will be individually announced >>> >> >>> >> which is "shall" >>> >> >>> >> and Registration Requested by Recipient >>> >> >>> >> which is "should" >>> >> >>> >> I would support if they are both "shall". >>> >> >>> >> Can ARIN staff discuss what actions it will take if an ISP's >>> >> down stream customer contacts them and explains that their >>> >> ISP refuses to SWIP their reassignment to them? >>> >> >>> >> Will they do anything more than reach out to the ISP and tell >>> >> them they "should" SWIP it? >>> > >>> > Jason - >>> > >>> > If this policy change 2017-5 is adopted, then a provider that has >>> IPv6 space from ARIN >>> > but routinely fails to publish registration information (for /47 or >>> larger reassignments) >>> > would be in violation, and ARIN would have clear policy language >>> that would enable >>> > us to discuss with the ISP the need to publish this information in >>> a timely manner. >>> > >>> > Service providers who blatantly ignore such a provision on an >>> ongoing basis will be >>> > in the enviable position of hearing me chat with them about their >>> obligations to follow >>> > ARIN number resource policy, including the consequences (i.e. >>> potential revocation >>> > of the IPv6 number resources.) >>> > >>> > If the langauge for the new section 6.5.5.4 "Registration Requested >>> by Recipient? >>> > reads ?? the ISP should register that assignment?, then ARIN would >>> send on any >>> > received customer complaint to the ISP, and remind the ISP that >>> they should >>> > follow number resource policy in this regard but not otherwise >>> taking any action. >>> > >>> > If the language for the new section 6.5.5.4 "Registration Requested >>> by Recipient? >>> > reads ?? the ISP shall register that assignment?, then failure to >>> do so would be >>> > a far more serious matter that, if left unaddressed on a chronic >>> manner, could have >>> > me discussing the customer complaints as a sign of potential >>> failure to comply with >>> > number resource policy, including the consequences (i.e. potential >>> revocation of >>> > the IPv6 number resources.) >>> > >>> > I would note that the community should be very clear about its >>> intentions for ISPs >>> > with regard to customer requested reassignment publication, given >>> there is large >>> > difference in obligations that result from policy language choice. >>> ARIN staff remains, >>> > as always, looking forward to implementing whatever policy emerges >>> from the >>> > consensus-based policy development process. >>> > >>> > Thanks! >>> > /John >>> > >>> > John Curran >>> > President and CEO >>> > American Registry for Internet Numbers >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > _______________________________________________ >>> > 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: >> 928/6d6c415b/attachment-0001.html> >>> >>> ------------------------------ >>> >>> Message: 2 >>> Date: Thu, 28 Sep 2017 11:03:55 -0500 >>> From: Owen DeLong >>> To: Kevin Blumberg >>> Cc: John Curran , Jason Schiller >>> , "arin-ppml at arin.net" >> > >>> Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2017-5: >>> Improved IPv6 Registration Requirements >>> Message-ID: >>> Content-Type: text/plain; charset="utf-8" >>> >>> While I wouldn?t consider it an editorial change, I would consider it a >>> minor change, which, if it had good community discussion and support at the >>> meeting, would, IMHO, be within the scope of pre-last-call changes that >>> could be made between the PPM and last call. >>> >>> The AC has, as has been mentioned before, significant discretion in >>> determining what is a ?minor change?. >>> >>> This is strictly my own opinion and may or may not be shared by other AC >>> members, staff, or anyone else. >>> >>> Owen >>> >>> > On Sep 28, 2017, at 10:46 AM, Kevin Blumberg >>> wrote: >>> > >>> > I support the policy as written. <> >>> > >>> > If the stick isn?t big enough it appears a simple policy change could >>> be used, not just for this section but all the other areas ?should? is used. >>> > >>> > I would like to point out that ?should? is currently used 30 times in >>> the NRPM. >>> > >>> > In reading John?s explanation, I can?t see ?should? and ?shall? being >>> considered an editorial change. To extend the policy cycle to another >>> meeting would be far worse. >>> > >>> > Out of curiosity, how often has ARIN had to deal with SWIP issues like >>> this, where the other party ignored you? >>> > >>> > Thanks, >>> > >>> > Kevin Blumberg >>> > >>> > >>> > From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of John >>> Curran >>> > Sent: Wednesday, September 27, 2017 5:59 PM >>> > To: Jason Schiller >>> > Cc: arin-ppml at arin.net >>> > Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2017-5: >>> Improved IPv6 Registration Requirements >>> > >>> > On 26 Sep 2017, at 3:18 PM, Jason Schiller >> > wrote: >>> > >>> > I oppose as written. >>> > >>> > There should not be a different standard of requirement for: >>> > - re-allocation >>> > - reassignment containing a /47 or more addresses >>> > - subdelegation of any size that will be individually announced >>> > >>> > which is "shall" >>> > >>> > and Registration Requested by Recipient >>> > >>> > which is "should" >>> > >>> > I would support if they are both "shall". >>> > >>> > Can ARIN staff discuss what actions it will take if an ISP's >>> > down stream customer contacts them and explains that their >>> > ISP refuses to SWIP their reassignment to them? >>> > >>> > Will they do anything more than reach out to the ISP and tell >>> > them they "should" SWIP it? >>> > >>> > Jason - >>> > >>> > If this policy change 2017-5 is adopted, then a provider that has >>> IPv6 space from ARIN >>> > but routinely fails to publish registration information (for /47 or >>> larger reassignments) >>> > would be in violation, and ARIN would have clear policy language >>> that would enable >>> > us to discuss with the ISP the need to publish this information in >>> a timely manner. >>> > >>> > Service providers who blatantly ignore such a provision on an >>> ongoing basis will be >>> > in the enviable position of hearing me chat with them about their >>> obligations to follow >>> > ARIN number resource policy, including the consequences (i.e. >>> potential revocation >>> > of the IPv6 number resources.) >>> > >>> > If the langauge for the new section 6.5.5.4 "Registration Requested >>> by Recipient? >>> > reads ?? the ISP should register that assignment?, then ARIN would >>> send on any >>> > received customer complaint to the ISP, and remind the ISP that >>> they should >>> > follow number resource policy in this regard but not otherwise >>> taking any action. >>> > >>> > If the language for the new section 6.5.5.4 "Registration Requested >>> by Recipient? >>> > reads ?? the ISP shall register that assignment?, then failure to >>> do so would be >>> > a far more serious matter that, if left unaddressed on a chronic >>> manner, could have >>> > me discussing the customer complaints as a sign of potential >>> failure to comply with >>> > number resource policy, including the consequences (i.e. potential >>> revocation of >>> > the IPv6 number resources.) >>> > >>> > I would note that the community should be very clear about its >>> intentions for ISPs >>> > with regard to customer requested reassignment publication, given >>> there is large >>> > difference in obligations that result from policy language choice. >>> ARIN staff remains, >>> > as always, looking forward to implementing whatever policy emerges >>> from the >>> > consensus-based policy development process. >>> > >>> > Thanks! >>> > /John >>> > >>> > John Curran >>> > President and CEO >>> > American Registry for Internet Numbers >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > _______________________________________________ >>> > 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: >> 928/0fbeb396/attachment.html> >>> >>> ------------------------------ >>> >>> Subject: Digest Footer >>> >>> _______________________________________________ >>> ARIN-PPML mailing list >>> ARIN-PPML at arin.net >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> >>> ------------------------------ >>> >>> End of ARIN-PPML Digest, Vol 147, Issue 43 >>> ****************************************** >>> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> >> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> > > > > -- > _______________________________________________________ > Jason Schiller|NetOps|jschiller at google.com|571-266-0006 <(571)%20266-0006> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Alison.WOOD at oregon.gov Thu Sep 28 14:56:13 2017 From: Alison.WOOD at oregon.gov (WOOD Alison * DAS) Date: Thu, 28 Sep 2017 18:56:13 +0000 Subject: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements In-Reply-To: References: <4D69C6C7-A6C1-41DD-8CF7-7DC198973E9F@arin.net> <7E7773B523E82C478734E793E58F69E7A52C530A@SBS2011.thewireinc.local> Message-ID: I concur with David?s point of view as a valuable starting point. I support as written. Thank you -Alison From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of David Farmer Sent: Thursday, September 28, 2017 10:18 AM To: Kevin Blumberg Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements I agree with Kevin if a bigger stick is need to ensure compliance in the future we can take that step if/when there proves to be a serious non-compliance issue in the future. Personally, I'm not ready to threaten revocation, in this case. My intent in suggesting what is now 6.5.5.4 was to crate an avenue for ARIN Staff to intervene with ISPs on behalf of customers, if a customer wanted their assignment registered and their ISP refused to register their assignment as requested, the customer can appeal the issue to ARIN. I'm fine with that intervention being short of threatening revocation, at least until their proves to be a serious issue with ISP's refusing valid requests by endusers to register assignments. I think the current language provides the proper balance. I'm fine with the standard procedure starting with ARIN Staff forwarding such complaints to an ISP requesting an explanation of the situation. However, if this develops into a chronic matter for an ISP, I would expect ARIN Staff to escalate the issue beyond simply asking for an explanation. Further after escalation, if the matter continues to be chronic, I would expect eventually the community to be altered to the situation. Probably not the specifics of which ISP and customers, but at least that there is an issue and some sense of the situation involved. Therefore, I support the policy as written. I'm not strongly opposed to changing from "should" to "shall" for section 6.5.5.4, but I'd prefer keeping that change in reserve, so we can go there, if there proves to be serious issues with non-compliance in the future. Put another way, I think voluntary compliance is highly preferred for this issue, and if voluntary compliance proves insufficient, then we can deal with that in the future. Thanks. On Thu, Sep 28, 2017 at 10:46 AM, Kevin Blumberg > wrote: I support the policy as written. If the stick isn?t big enough it appears a simple policy change could be used, not just for this section but all the other areas ?should? is used. I would like to point out that ?should? is currently used 30 times in the NRPM. In reading John?s explanation, I can?t see ?should? and ?shall? being considered an editorial change. To extend the policy cycle to another meeting would be far worse. Out of curiosity, how often has ARIN had to deal with SWIP issues like this, where the other party ignored you? Thanks, Kevin Blumberg From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of John Curran Sent: Wednesday, September 27, 2017 5:59 PM To: Jason Schiller > Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements On 26 Sep 2017, at 3:18 PM, Jason Schiller > wrote: I oppose as written. There should not be a different standard of requirement for: - re-allocation - reassignment containing a /47 or more addresses - subdelegation of any size that will be individually announced which is "shall" and Registration Requested by Recipient which is "should" I would support if they are both "shall". Can ARIN staff discuss what actions it will take if an ISP's down stream customer contacts them and explains that their ISP refuses to SWIP their reassignment to them? Will they do anything more than reach out to the ISP and tell them they "should" SWIP it? Jason - If this policy change 2017-5 is adopted, then a provider that has IPv6 space from ARIN but routinely fails to publish registration information (for /47 or larger reassignments) would be in violation, and ARIN would have clear policy language that would enable us to discuss with the ISP the need to publish this information in a timely manner. Service providers who blatantly ignore such a provision on an ongoing basis will be in the enviable position of hearing me chat with them about their obligations to follow ARIN number resource policy, including the consequences (i.e. potential revocation of the IPv6 number resources.) If the langauge for the new section 6.5.5.4 "Registration Requested by Recipient? reads ?? the ISP should register that assignment?, then ARIN would send on any received customer complaint to the ISP, and remind the ISP that they should follow number resource policy in this regard but not otherwise taking any action. If the language for the new section 6.5.5.4 "Registration Requested by Recipient? reads ?? the ISP shall register that assignment?, then failure to do so would be a far more serious matter that, if left unaddressed on a chronic manner, could have me discussing the customer complaints as a sign of potential failure to comply with number resource policy, including the consequences (i.e. potential revocation of the IPv6 number resources.) I would note that the community should be very clear about its intentions for ISPs with regard to customer requested reassignment publication, given there is large difference in obligations that result from policy language choice. ARIN staff remains, as always, looking forward to implementing whatever policy emerges from the consensus-based policy development process. Thanks! /John John Curran President and CEO American Registry for Internet Numbers _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From Daniel_Alexander at comcast.com Thu Sep 28 23:59:54 2017 From: Daniel_Alexander at comcast.com (Alexander, Daniel) Date: Fri, 29 Sep 2017 03:59:54 +0000 Subject: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements In-Reply-To: References: <4D69C6C7-A6C1-41DD-8CF7-7DC198973E9F@arin.net> <7E7773B523E82C478734E793E58F69E7A52C530A@SBS2011.thewireinc.local> Message-ID: Hello All, I just wanted to mention some procedural points to consider in this discussion and thank you all for contributing to this debate. It does provide helpful guidance to the AC. The current text is frozen, and cannot be changed until it is discussed at the meeting in San Jose. However, it can be discussed whether people would prefer "shall" or "should". If the community wanted the AC to advance this proposal by changing "should" to "shall", without going to another meeting, it does have to be discussed in San Jose with clear consensus, since that is not an editorial change. Clear direction from the community helps the AC in their decision making process. If the discussion and feedback at the meeting is clearly split between changes to the text, it can make final decisions challenging. Thank you all for your help in this process. Dan Alexander AC Chair From: ARIN-PPML > on behalf of WOOD Alison * DAS > Date: Thursday, September 28, 2017 at 2:56 PM To: 'David Farmer' > Cc: "arin-ppml at arin.net" > Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements I concur with David?s point of view as a valuable starting point. I support as written. Thank you -Alison From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of David Farmer Sent: Thursday, September 28, 2017 10:18 AM To: Kevin Blumberg > Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements I agree with Kevin if a bigger stick is need to ensure compliance in the future we can take that step if/when there proves to be a serious non-compliance issue in the future. Personally, I'm not ready to threaten revocation, in this case. My intent in suggesting what is now 6.5.5.4 was to crate an avenue for ARIN Staff to intervene with ISPs on behalf of customers, if a customer wanted their assignment registered and their ISP refused to register their assignment as requested, the customer can appeal the issue to ARIN. I'm fine with that intervention being short of threatening revocation, at least until their proves to be a serious issue with ISP's refusing valid requests by endusers to register assignments. I think the current language provides the proper balance. I'm fine with the standard procedure starting with ARIN Staff forwarding such complaints to an ISP requesting an explanation of the situation. However, if this develops into a chronic matter for an ISP, I would expect ARIN Staff to escalate the issue beyond simply asking for an explanation. Further after escalation, if the matter continues to be chronic, I would expect eventually the community to be altered to the situation. Probably not the specifics of which ISP and customers, but at least that there is an issue and some sense of the situation involved. Therefore, I support the policy as written. I'm not strongly opposed to changing from "should" to "shall" for section 6.5.5.4, but I'd prefer keeping that change in reserve, so we can go there, if there proves to be serious issues with non-compliance in the future. Put another way, I think voluntary compliance is highly preferred for this issue, and if voluntary compliance proves insufficient, then we can deal with that in the future. Thanks. On Thu, Sep 28, 2017 at 10:46 AM, Kevin Blumberg > wrote: I support the policy as written. If the stick isn?t big enough it appears a simple policy change could be used, not just for this section but all the other areas ?should? is used. I would like to point out that ?should? is currently used 30 times in the NRPM. In reading John?s explanation, I can?t see ?should? and ?shall? being considered an editorial change. To extend the policy cycle to another meeting would be far worse. Out of curiosity, how often has ARIN had to deal with SWIP issues like this, where the other party ignored you? Thanks, Kevin Blumberg From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of John Curran Sent: Wednesday, September 27, 2017 5:59 PM To: Jason Schiller > Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements On 26 Sep 2017, at 3:18 PM, Jason Schiller > wrote: I oppose as written. There should not be a different standard of requirement for: - re-allocation - reassignment containing a /47 or more addresses - subdelegation of any size that will be individually announced which is "shall" and Registration Requested by Recipient which is "should" I would support if they are both "shall". Can ARIN staff discuss what actions it will take if an ISP's down stream customer contacts them and explains that their ISP refuses to SWIP their reassignment to them? Will they do anything more than reach out to the ISP and tell them they "should" SWIP it? Jason - If this policy change 2017-5 is adopted, then a provider that has IPv6 space from ARIN but routinely fails to publish registration information (for /47 or larger reassignments) would be in violation, and ARIN would have clear policy language that would enable us to discuss with the ISP the need to publish this information in a timely manner. Service providers who blatantly ignore such a provision on an ongoing basis will be in the enviable position of hearing me chat with them about their obligations to follow ARIN number resource policy, including the consequences (i.e. potential revocation of the IPv6 number resources.) If the langauge for the new section 6.5.5.4 "Registration Requested by Recipient? reads ?? the ISP should register that assignment?, then ARIN would send on any received customer complaint to the ISP, and remind the ISP that they should follow number resource policy in this regard but not otherwise taking any action. If the language for the new section 6.5.5.4 "Registration Requested by Recipient? reads ?? the ISP shall register that assignment?, then failure to do so would be a far more serious matter that, if left unaddressed on a chronic manner, could have me discussing the customer complaints as a sign of potential failure to comply with number resource policy, including the consequences (i.e. potential revocation of the IPv6 number resources.) I would note that the community should be very clear about its intentions for ISPs with regard to customer requested reassignment publication, given there is large difference in obligations that result from policy language choice. ARIN staff remains, as always, looking forward to implementing whatever policy emerges from the consensus-based policy development process. Thanks! /John John Curran President and CEO American Registry for Internet Numbers _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From narten at us.ibm.com Fri Sep 29 00:53:33 2017 From: narten at us.ibm.com (narten at us.ibm.com) Date: Fri, 29 Sep 2017 00:53:33 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201709290453.v8T4rX1s023692@rotala.raleigh.ibm.com> Total of 32 messages in the last 7 days. script run at: Fri Sep 29 00:53:27 EDT 2017 Messages | Bytes | Who --------+------+--------+----------+------------------------ 15.62% | 5 | 17.60% | 172800 | jschiller at google.com 12.50% | 4 | 15.89% | 155972 | chris at semihuman.com 9.38% | 3 | 10.43% | 102446 | kevinb at thewire.ca 6.25% | 2 | 9.28% | 91167 | rudi.daniel at gmail.com 6.25% | 2 | 6.26% | 61435 | bjones at vt.edu 6.25% | 2 | 5.77% | 56621 | owen at delong.com 6.25% | 2 | 3.92% | 38494 | scottleibrand at gmail.com 6.25% | 2 | 1.80% | 17669 | info at arin.net 3.12% | 1 | 4.74% | 46575 | daniel_alexander at comcast.com 3.12% | 1 | 4.74% | 46493 | lsawyer at gci.com 3.12% | 1 | 4.33% | 42489 | alison.wood at oregon.gov 3.12% | 1 | 3.91% | 38357 | alyssa at alyssamoore.ca 3.12% | 1 | 3.58% | 35128 | mwinters at edwardrose.com 3.12% | 1 | 3.19% | 31299 | farmer at umn.edu 3.12% | 1 | 1.83% | 17980 | jcurran at arin.net 3.12% | 1 | 0.97% | 9486 | hostmaster at uneedus.com 3.12% | 1 | 0.93% | 9138 | narten at us.ibm.com 3.12% | 1 | 0.85% | 8332 | hvgeekwtrvl at gmail.com --------+------+--------+----------+------------------------ 100.00% | 32 |100.00% | 981881 | Total From jcurran at arin.net Fri Sep 29 06:47:55 2017 From: jcurran at arin.net (John Curran) Date: Fri, 29 Sep 2017 10:47:55 +0000 Subject: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements In-Reply-To: References: <4D69C6C7-A6C1-41DD-8CF7-7DC198973E9F@arin.net> <7E7773B523E82C478734E793E58F69E7A52C530A@SBS2011.thewireinc.local> Message-ID: <5E2CD5F0-ACEC-44F5-A902-B12BE2B2951B@arin.net> On 28 Sep 2017, at 11:59 PM, Alexander, Daniel > wrote: Hello All, I just wanted to mention some procedural points to consider in this discussion and thank you all for contributing to this debate. It does provide helpful guidance to the AC. The current text is frozen, and cannot be changed until it is discussed at the meeting in San Jose. However, it can be discussed whether people would prefer "shall" or "should". If the community wanted the AC to advance this proposal by changing "should" to "shall", without going to another meeting, it does have to be discussed in San Jose with clear consensus, since that is not an editorial change. Clear direction from the community helps the AC in their decision making process. If the discussion and feedback at the meeting is clearly split between changes to the text, it can make final decisions challenging. Thank you all for your help in this process. Dan - Your reading of the ARIN policy development process in this regard is 100% correct. /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From hostmaster at uneedus.com Fri Sep 29 08:38:53 2017 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Fri, 29 Sep 2017 08:38:53 -0400 (EDT) Subject: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements In-Reply-To: <5E2CD5F0-ACEC-44F5-A902-B12BE2B2951B@arin.net> References: <4D69C6C7-A6C1-41DD-8CF7-7DC198973E9F@arin.net> <7E7773B523E82C478734E793E58F69E7A52C530A@SBS2011.thewireinc.local> <5E2CD5F0-ACEC-44F5-A902-B12BE2B2951B@arin.net> Message-ID: As the author of the original proposal, I do want to see the main part of this proposal advance and be passed. Since it has now been pointed out that the language is currently frozen until the meeting, I note for the record that I have no problem with the draft as currently written, and would like to see it advance and pass. Discussion up to this point seems to be that the majority have no issue with the use of either word "should" or "shall". Thus, like the majority, "should" is acceptable for passage, and therefore I move for adoption as is. The current draft is in 4 parts. Part one, to change the SWIP standard from /64 or more to a larger size, currently /47 or more or individually routed, is what I thought was wrong with the earlier standard, and what I was seeking change in policy in the original draft, and what I would like to pass. Sections 2 and 3 are basically corrections, section 2 a mis-identified IPv4 section reference changed to the corresponding IPv6 section, and in section 3, removal of language that would make the new standard unclear since /64 or more would no longer be the standard. Section 4 is the section regarding downstream requests for SWIP, and has the "should" and "shall" issue being discussed. It was identified during discussion, and was not part of the original draft. I would suggest that we allow the draft to pass as is, and come back with a new draft changing that section to "shall" ONLY if it is identified that there are a lot of issues with obtaining SWIP registration by upstreams that do not think "should" is a strong enough word for them to act. Even then, consider that an upstream that refuses to act on "should" may also decide to not act on "shall" either. Albert Erdmann Network Administrator Paradise On Line Inc. On Fri, 29 Sep 2017, John Curran wrote: > On 28 Sep 2017, at 11:59 PM, Alexander, Daniel > wrote: > > Hello All, > > I just wanted to mention some procedural points to consider in this discussion and thank you all for contributing to this debate. It does provide helpful guidance to the AC. > > The current text is frozen, and cannot be changed until it is discussed at the meeting in San Jose. However, it can be discussed whether people would prefer "shall" or "should". If the community wanted the AC to advance this proposal by changing "should" to "shall", without going to another meeting, it does have to be discussed in San Jose with clear consensus, since that is not an editorial change. > > Clear direction from the community helps the AC in their decision making process. If the discussion and feedback at the meeting is clearly split between changes to the text, it can make final decisions challenging. > > Thank you all for your help in this process. > > Dan - > > Your reading of the ARIN policy development process in this regard is 100% correct. > > /John > > John Curran > President and CEO > ARIN > > From jschiller at google.com Fri Sep 29 09:58:31 2017 From: jschiller at google.com (Jason Schiller) Date: Fri, 29 Sep 2017 09:58:31 -0400 Subject: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements In-Reply-To: References: <4D69C6C7-A6C1-41DD-8CF7-7DC198973E9F@arin.net> <7E7773B523E82C478734E793E58F69E7A52C530A@SBS2011.thewireinc.local> Message-ID: David, Kevin, Alison I am actually comfortable with an implementation that is short of revocation, but I am still not comfortable with "should". Should makes it optional. Officially not being out of compliance with ARIN policy makes it optional. I suggest that an ISP refusing to register a downstream customer is out of compliance with ARIN policy, and not just choosing to ignore an optional recommendation. If it is only "should" then an ISP can still hold the moral high ground while refusing to support SWIP on the grounds that they will not implement tooling and commit resources when it is only optional. It is a question of if you can hold someone accountable for not complying or if they are free to ignore something that is optional. Owen, Chris, Kevin, Certainly if there is enough support to move this forward, we shouldn't wait another cycle. (I recognize this weakens the "shall" position) My hope is if we can close out the discussion of this topic at the meeting with a clear understanding of if there is community support to move forward the policy with "shall" and also if there is clear support to move the policy forward with "should" in this cycle. This will give the AC a maximum of leverage to do what is needed, and insure it doesn't fall to the next cycle by forcing people to support only what they perceive as the best option. Assuming there is support for both "shall" and "should" the AC could choose to move "shall" to last call, and if there are then issues, move should to last call. We need to get clear on how to structure the question here. My thoughts are 1. Do you support the policy with "shall" if it doesn't require an extra cycle and support "should" in this cycle if "shall" cannot advance? 2. Do you only support the policy as written? 3. Do you oppose both the policy as written and with "shall"? When considering if there is enough support to move the policy as written forward, the AC should consider the hands in both questions 1 & 2. I support the policy with "shall" with a fall back to "should". __Jason On Thu, Sep 28, 2017 at 1:18 PM, David Farmer wrote: > I agree with Kevin if a bigger stick is need to ensure compliance in the > future we can take that step if/when there proves to be a serious > non-compliance issue in the future. Personally, I'm not ready to threaten > revocation, in this case. My intent in suggesting what is now 6.5.5.4 was > to crate an avenue for ARIN Staff to intervene with ISPs on behalf of > customers, if a customer wanted their assignment registered and their ISP > refused to register their assignment as requested, the customer can appeal > the issue to ARIN. I'm fine with that intervention being short of > threatening revocation, at least until their proves to be a serious issue > with ISP's refusing valid requests by endusers to register assignments. I > think the current language provides the proper balance. > > I'm fine with the standard procedure starting with ARIN Staff forwarding > such complaints to an ISP requesting an explanation of the situation. > However, if this develops into a chronic matter for an ISP, I would expect > ARIN Staff to escalate the issue beyond simply asking for an > explanation. Further after escalation, if the matter continues to be > chronic, I would expect eventually the community to be altered to the > situation. Probably not the specifics of which ISP and customers, but at > least that there is an issue and some sense of the situation involved. > > Therefore, I support the policy as written. I'm not strongly opposed to > changing from "should" to "shall" for section 6.5.5.4, but I'd prefer > keeping that change in reserve, so we can go there, if there proves to be > serious issues with non-compliance in the future. Put another way, I think > voluntary compliance is highly preferred for this issue, and if voluntary > compliance proves insufficient, then we can deal with that in the future. > > > Thanks. > > On Thu, Sep 28, 2017 at 10:46 AM, Kevin Blumberg > wrote: > >> I support the policy as written. >> >> >> >> If the stick isn?t big enough it appears a simple policy change could be >> used, not just for this section but all the other areas ?should? is used. >> >> >> >> I would like to point out that ?should? is currently used 30 times in the >> NRPM. >> >> >> >> In reading John?s explanation, I can?t see ?should? and ?shall? being >> considered an editorial change. To extend the policy cycle to another >> meeting would be far worse. >> >> >> >> Out of curiosity, how often has ARIN had to deal with SWIP issues like >> this, where the other party ignored you? >> >> >> >> Thanks, >> >> >> >> Kevin Blumberg >> >> >> >> >> >> *From:* ARIN-PPML [mailto:arin-ppml-bounces at arin.net] *On Behalf Of *John >> Curran >> *Sent:* Wednesday, September 27, 2017 5:59 PM >> *To:* Jason Schiller >> *Cc:* arin-ppml at arin.net >> *Subject:* Re: [arin-ppml] Recommended Draft Policy ARIN-2017-5: >> Improved IPv6 Registration Requirements >> >> >> >> On 26 Sep 2017, at 3:18 PM, Jason Schiller wrote: >> >> >> >> I oppose as written. >> >> >> >> There should not be a different standard of requirement for: >> >> - re-allocation >> >> - reassignment containing a /47 or more addresses >> >> - subdelegation of any size that will be individually announced >> >> >> >> which is "shall" >> >> >> >> and Registration Requested by Recipient >> >> >> >> which is "should" >> >> >> >> I would support if they are both "shall". >> >> >> >> Can ARIN staff discuss what actions it will take if an ISP's >> >> down stream customer contacts them and explains that their >> >> ISP refuses to SWIP their reassignment to them? >> >> >> >> Will they do anything more than reach out to the ISP and tell >> >> them they "should" SWIP it? >> >> >> >> Jason - >> >> If this policy change 2017-5 is adopted, then a provider that has IPv6 >> space from ARIN >> >> but routinely fails to publish registration information (for /47 or >> larger reassignments) >> >> would be in violation, and ARIN would have clear policy language that >> would enable >> >> us to discuss with the ISP the need to publish this information in a >> timely manner. >> >> >> Service providers who blatantly ignore such a provision on an ongoing >> basis will be >> in the enviable position of hearing me chat with them about their >> obligations to follow >> ARIN number resource policy, including the consequences (i.e. >> potential revocation >> >> of the IPv6 number resources.) >> >> >> >> If the langauge for the new section 6.5.5.4 "Registration Requested by >> Recipient? >> >> reads ?? the ISP should register that assignment?, then ARIN would >> send on any >> >> received customer complaint to the ISP, and remind the ISP that they >> should >> >> follow number resource policy in this regard but not otherwise taking >> any action. >> >> >> >> If the language for the new section 6.5.5.4 "Registration Requested by >> Recipient? >> >> reads ?? the ISP shall register that assignment?, then failure to do >> so would be >> >> a far more serious matter that, if left unaddressed on a chronic >> manner, could have >> >> me discussing the customer complaints as a sign of potential failure >> to comply with >> >> number resource policy, including the consequences (i.e. potential >> revocation of >> >> the IPv6 number resources.) >> >> >> >> I would note that the community should be very clear about its >> intentions for ISPs >> >> with regard to customer requested reassignment publication, given >> there is large >> >> difference in obligations that result from policy language choice. >> ARIN staff remains, >> >> as always, looking forward to implementing whatever policy emerges >> from the >> >> consensus-based policy development process. >> >> >> >> Thanks! >> >> /John >> >> >> >> John Curran >> >> President and CEO >> >> American Registry for Internet Numbers >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> > > > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE > > Phone: 612-626-0815 <(612)%20626-0815> > Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> > =============================================== > -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at delong.com Fri Sep 29 10:12:58 2017 From: owen at delong.com (Owen DeLong) Date: Fri, 29 Sep 2017 09:12:58 -0500 Subject: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements In-Reply-To: References: <4D69C6C7-A6C1-41DD-8CF7-7DC198973E9F@arin.net> <7E7773B523E82C478734E793E58F69E7A52C530A@SBS2011.thewireinc.local> Message-ID: <41243BE0-2E6D-43C7-9AA9-639B70BBCFC3@delong.com> > On Sep 29, 2017, at 8:58 AM, Jason Schiller wrote: > > David, Kevin, Alison > > I am actually comfortable with an implementation that is short of revocation, > but I am still not comfortable with "should". > > Should makes it optional. Officially not being out of compliance with > ARIN policy makes it optional. > > I suggest that an ISP refusing to register a downstream customer > is out of compliance with ARIN policy, and not just choosing to ignore > an optional recommendation. > > If it is only "should" then an ISP can still hold the moral high ground > while refusing to support SWIP on the grounds that they will not > implement tooling and commit resources when it is only optional. > > It is a question of if you can hold someone accountable for not > complying or if they are free to ignore something that is optional. > > > > Owen, Chris, Kevin, > > Certainly if there is enough support to move this forward, we shouldn't > wait another cycle. (I recognize this weakens the "shall" position) Other than AC sophistry or community confusion, there?s absolutely no reason, IMHO, that we can?t get community support and consensus around shall as a minor change prior to last call, so I don?t think it actually weakens the argument. I agree that if we have enough of either of the above that it won?t move forward with shall until another cycle, it?s not worth waiting another cycle and we should push through an additional separate policy for this single-word correction, so I suppose to that extent, it could be seen as weakening the argument for doing it now. > My hope is if we can close out the discussion of this topic at the meeting > with a clear understanding of if there is community support to move forward > the policy with "shall" and also if there is clear support to move the policy forward > with "should" in this cycle. This will give the AC a maximum of leverage to do > what is needed, and insure it doesn't fall to the next cycle by forcing people > to support only what they perceive as the best option. 100% Agreed. > > Assuming there is support for both "shall" and "should" the AC could > choose to move "shall" to last call, and if there are then issues, move > should to last call. Excellent idea, IMHO. > > > We need to get clear on how to structure the question here. > > My thoughts are > > 1. Do you support the policy with "shall" if it doesn't require an extra cycle > and support "should" in this cycle if "shall" cannot advance? > > 2. Do you only support the policy as written? > > 3. Do you oppose both the policy as written and with "shall"? > > When considering if there is enough support to move the policy as > written forward, the AC should consider the hands in both questions 1 & 2. > > > I support the policy with "shall" with a fall back to "should". > > __Jason > > > > On Thu, Sep 28, 2017 at 1:18 PM, David Farmer > wrote: > I agree with Kevin if a bigger stick is need to ensure compliance in the future we can take that step if/when there proves to be a serious non-compliance issue in the future. Personally, I'm not ready to threaten revocation, in this case. My intent in suggesting what is now 6.5.5.4 was to crate an avenue for ARIN Staff to intervene with ISPs on behalf of customers, if a customer wanted their assignment registered and their ISP refused to register their assignment as requested, the customer can appeal the issue to ARIN. I'm fine with that intervention being short of threatening revocation, at least until their proves to be a serious issue with ISP's refusing valid requests by endusers to register assignments. I think the current language provides the proper balance. > > I'm fine with the standard procedure starting with ARIN Staff forwarding such complaints to an ISP requesting an explanation of the situation. However, if this develops into a chronic matter for an ISP, I would expect ARIN Staff to escalate the issue beyond simply asking for an explanation. Further after escalation, if the matter continues to be chronic, I would expect eventually the community to be altered to the situation. Probably not the specifics of which ISP and customers, but at least that there is an issue and some sense of the situation involved. > > Therefore, I support the policy as written. I'm not strongly opposed to changing from "should" to "shall" for section 6.5.5.4, but I'd prefer keeping that change in reserve, so we can go there, if there proves to be serious issues with non-compliance in the future. Put another way, I think voluntary compliance is highly preferred for this issue, and if voluntary compliance proves insufficient, then we can deal with that in the future. > > Thanks. > > On Thu, Sep 28, 2017 at 10:46 AM, Kevin Blumberg > wrote: > I support the policy as written. <> > > > If the stick isn?t big enough it appears a simple policy change could be used, not just for this section but all the other areas ?should? is used. > > > > I would like to point out that ?should? is currently used 30 times in the NRPM. > > > > In reading John?s explanation, I can?t see ?should? and ?shall? being considered an editorial change. To extend the policy cycle to another meeting would be far worse. > > > > Out of curiosity, how often has ARIN had to deal with SWIP issues like this, where the other party ignored you? > > > > Thanks, > > > > Kevin Blumberg > > > > > > From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net ] On Behalf Of John Curran > Sent: Wednesday, September 27, 2017 5:59 PM > To: Jason Schiller > > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements > > > > On 26 Sep 2017, at 3:18 PM, Jason Schiller > wrote: > > > > I oppose as written. > > > > There should not be a different standard of requirement for: > > - re-allocation > > - reassignment containing a /47 or more addresses > > - subdelegation of any size that will be individually announced > > > > which is "shall" > > > > and Registration Requested by Recipient > > > > which is "should" > > > > I would support if they are both "shall". > > > > Can ARIN staff discuss what actions it will take if an ISP's > > down stream customer contacts them and explains that their > > ISP refuses to SWIP their reassignment to them? > > > > Will they do anything more than reach out to the ISP and tell > > them they "should" SWIP it? > > > > Jason - > > If this policy change 2017-5 is adopted, then a provider that has IPv6 space from ARIN > > but routinely fails to publish registration information (for /47 or larger reassignments) > > would be in violation, and ARIN would have clear policy language that would enable > > us to discuss with the ISP the need to publish this information in a timely manner. > > > Service providers who blatantly ignore such a provision on an ongoing basis will be > in the enviable position of hearing me chat with them about their obligations to follow > ARIN number resource policy, including the consequences (i.e. potential revocation > > of the IPv6 number resources.) > > > > If the langauge for the new section 6.5.5.4 "Registration Requested by Recipient? > > reads ?? the ISP should register that assignment?, then ARIN would send on any > > received customer complaint to the ISP, and remind the ISP that they should > > follow number resource policy in this regard but not otherwise taking any action. > > > > If the language for the new section 6.5.5.4 "Registration Requested by Recipient? > > reads ?? the ISP shall register that assignment?, then failure to do so would be > > a far more serious matter that, if left unaddressed on a chronic manner, could have > > me discussing the customer complaints as a sign of potential failure to comply with > > number resource policy, including the consequences (i.e. potential revocation of > > the IPv6 number resources.) > > > > I would note that the community should be very clear about its intentions for ISPs > > with regard to customer requested reassignment publication, given there is large > > difference in obligations that result from policy language choice. ARIN staff remains, > > as always, looking forward to implementing whatever policy emerges from the > > consensus-based policy development process. > > > > Thanks! > > /John > > > > John Curran > > President and CEO > > American Registry for Internet Numbers > > > > > > > > > > > > > > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =============================================== > > > > -- > _______________________________________________________ > Jason Schiller|NetOps|jschiller at google.com |571-266-0006 > > _______________________________________________ > 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 michael at linuxmagic.com Fri Sep 29 10:55:57 2017 From: michael at linuxmagic.com (Michael Peddemors) Date: Fri, 29 Sep 2017 07:55:57 -0700 Subject: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements In-Reply-To: References: <4D69C6C7-A6C1-41DD-8CF7-7DC198973E9F@arin.net> <7E7773B523E82C478734E793E58F69E7A52C530A@SBS2011.thewireinc.local> Message-ID: <53f61942-1409-a7e1-0ffb-bd129d879827@linuxmagic.com> +1 On 17-09-29 06:58 AM, Jason Schiller wrote: > David, Kevin,?Alison > > I am actually comfortable with an implementation that is short of > revocation, > but I am still not comfortable with "should". > > Should makes it optional.? Officially not being out of compliance with > ARIN policy makes it optional. > > I suggest that an ISP refusing to register a downstream customer > is out of compliance with ARIN policy, and not just choosing to ignore > an optional recommendation. > > If it is only "should" then an ISP can still hold the moral high ground > while refusing to support SWIP on the grounds that they will not > implement tooling and commit resources when it is only optional. > > It is a question of if you can hold someone accountable for not > complying or if they are free to ignore something that is optional. > > > > Owen, Chris, Kevin, > > Certainly if there is enough support to move this forward, we shouldn't > wait another cycle. (I recognize this weakens the "shall" position) > > My hope is if we can close out the discussion of this topic at the meeting > with a clear understanding of if there is community support to move forward > the policy with "shall" and also if there is clear support to move the > policy forward > with "should" in this cycle.? This will give the AC a maximum of > leverage to do > what is needed, and insure it doesn't fall to the next cycle by forcing > people > to support only what they perceive?as the best option. > > Assuming there is support for both "shall" and "should" the AC could > choose to move "shall" to last call, and if there are then issues, move > should to last call. > > > We need to get clear on how to structure the question here. > > My thoughts are > > 1. Do you support the policy with "shall" if it doesn't require an extra > cycle > ? ? and support "should" in this cycle if "shall" cannot advance? > > 2. Do you only support the policy as written? > > 3. Do you oppose both the policy as written and with "shall"? > > When considering if there is enough support to move the policy as > written forward, the AC should consider the hands in both questions 1 & 2. > > > I support the policy with "shall" with a fall back to "should". > > __Jason > > > On Thu, Sep 28, 2017 at 1:18 PM, David Farmer > wrote: > > I agree with Kevin if a bigger stick is need to ensure compliance in > the future we can take that step if/when there proves to be a > serious non-compliance?issue in the future. Personally, I'm not > ready to threaten revocation, in this case. My intent in suggesting > what is now 6.5.5.4 was to crate an avenue for ARIN Staff to > intervene with ISPs on behalf of customers, if a customer wanted > their assignment registered and their ISP refused to register their > assignment as requested, the customer can appeal the issue to ARIN. > I'm fine with that intervention being short of threatening > revocation, at least until their proves to be a serious issue with > ISP's refusing valid requests by endusers to register assignments. > I think the current language provides the proper balance. > > I'm fine with the standard procedure starting with ARIN Staff > forwarding such complaints to an ISP requesting an explanation of > the situation. However, if this develops into a chronic matter for > an ISP, I would expect ARIN?Staff to escalate the issue beyond > simply asking for an explanation.??Further after escalation, if the > matter continues to be chronic, I would expect eventually the > community to be altered to the situation. Probably not the specifics > of which ISP and customers, but at least that there is an issue and > some sense of the situation involved. > > Therefore, I support the policy as written. I'm not strongly opposed > to changing from "should" to "shall" for section 6.5.5.4, but I'd > prefer keeping that change in reserve, so we can go there, if there > proves to be serious issues with non-compliance in the future. Put > another way, I think voluntary compliance is highly preferred for > this issue, and if voluntary compliance proves insufficient, then we > can deal with that in the future. > > Thanks. > > On Thu, Sep 28, 2017 at 10:46 AM, Kevin Blumberg > wrote: > > I support the policy as written. ____ > > __ __ > > If the stick isn?t big enough it appears a simple policy change > could be used, not just for this section but all the other areas > ?should? is used.____ > > __ __ > > I would like to point out that ?should? is currently used 30 > times in the NRPM. ____ > > __ __ > > In reading John?s explanation, I can?t see ?should? and ?shall? > being considered an editorial change. To extend the policy cycle > to another meeting would be far worse.____ > > __ __ > > Out of curiosity, how often has ARIN had to deal with SWIP > issues like this, where the other party ignored you?____ > > __ __ > > Thanks,____ > > __ __ > > Kevin Blumberg____ > > __ __ > > __ __ > > *From:*ARIN-PPML [mailto:arin-ppml-bounces at arin.net > ] *On Behalf Of *John Curran > *Sent:* Wednesday, September 27, 2017 5:59 PM > *To:* Jason Schiller > > *Cc:* arin-ppml at arin.net > *Subject:* Re: [arin-ppml] Recommended Draft Policy ARIN-2017-5: > Improved IPv6 Registration Requirements____ > > __ __ > > On 26 Sep 2017, at 3:18 PM, Jason Schiller > wrote:____ > > __ __ > > I oppose as written. ____ > > __ __ > > There should not be a different standard of requirement for:____ > > - re-allocation____ > > - reassignment containing a /47 or more addresses____ > > - subdelegation of any?size that will be individually > announced____ > > __ __ > > which is "shall"____ > > __ __ > > and?Registration Requested by Recipient____ > > __ __ > > which is "should"____ > > __ __ > > I would support if they are both "shall".____ > > __ __ > > Can ARIN staff discuss what actions it will take if an ISP's____ > > down stream customer contacts them and explains that their____ > > ISP refuses to SWIP their reassignment to them?____ > > __ __ > > Will they do anything more than reach out to the ISP and > tell____ > > them they "should" SWIP it?____ > > __ __ > > Jason - > > ? ?If this policy change 2017-5 is adopted, then a provider > that has IPv6 space from ARIN ____ > > ? ?but routinely fails to publish registration information (for > /47 or larger reassignments) ____ > > ? ?would be in violation, and ARIN would have clear policy > language that would enable ____ > > ? ?us to discuss with the ISP the need to publish this > information in a timely manner. ____ > > > ? ?Service providers who blatantly ignore such a provision on > an ongoing basis will be > ? ?in the enviable position of hearing me chat with them about > their obligations to follow > ? ?ARIN number resource policy, including the consequences > (i.e. potential revocation ____ > > ? ?of the IPv6 number?resources.)____ > > __ __ > > ? ?If the langauge for the new section 6.5.5.4 "Registration > Requested by Recipient? ____ > > ? ?reads ?? the ISP should register that assignment?, then ARIN > would send on any____ > > ? ?received customer complaint to the ISP, and remind the ISP > that they should____ > > ? ?follow number resource policy in this regard but not > otherwise taking any action. ____ > > __ __ > > ? ?If the language for the new section 6.5.5.4 "Registration > Requested by Recipient? ____ > > ? ?reads ?? the ISP shall register that assignment?, then > failure to do so would be____ > > ? ?a far more serious matter that, if left unaddressed on a > chronic manner, could have ____ > > ? ?me discussing the customer complaints as a sign of potential > failure to comply with ____ > > ? ?number resource policy, including the consequences (i.e. > potential revocation of ____ > > ? ?the IPv6 number?resources.)____ > > __ __ > > ? ?I would note that the community should be very clear about > its intentions for ISPs____ > > ? ?with regard to customer requested reassignment publication, > given there is large ____ > > ? ?difference in obligations that result from policy language > choice. ? ARIN staff remains, ____ > > ? ?as always, looking forward to implementing whatever policy > emerges from the ____ > > ? ?consensus-based policy development process. ____ > > __ __ > > Thanks!____ > > /John____ > > __ __ > > John Curran____ > > President and CEO____ > > American Registry for Internet Numbers____ > > __ __ > > __ __ > > __ __ > > __ __ > > __ __ > > __ __ > > __ __ > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net > ). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you > experience any issues. > > > > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE > > ? ? ? Phone: 612-626-0815 > Minneapolis, MN 55414-3029?? Cell: 612-812-9952 > > =============================================== > > > > > -- > _______________________________________________________ > Jason Schiller|NetOps|jschiller at google.com > |571-266-0006 > > > > _______________________________________________ > 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. > -- "Catch the Magic of Linux..." ------------------------------------------------------------------------ Michael Peddemors, President/CEO LinuxMagic Inc. Visit us at http://www.linuxmagic.com @linuxmagic ------------------------------------------------------------------------ A Wizard IT Company - For More Info http://www.wizard.ca "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. ------------------------------------------------------------------------ 604-682-0300 Beautiful British Columbia, Canada This email and any electronic data contained are confidential and intended solely for the use of the individual or entity to which they are addressed. Please note that any views or opinions presented in this email are solely those of the author and are not intended to represent those of the company. From mwinters at edwardrose.com Fri Sep 29 12:25:31 2017 From: mwinters at edwardrose.com (Michael Winters) Date: Fri, 29 Sep 2017 16:25:31 +0000 Subject: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements In-Reply-To: References: <4D69C6C7-A6C1-41DD-8CF7-7DC198973E9F@arin.net> <7E7773B523E82C478734E793E58F69E7A52C530A@SBS2011.thewireinc.local> Message-ID: If you are going to change it to shall, then you also need to define the consequences of non-compliance. From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Jason Schiller Sent: Friday, September 29, 2017 9:59 AM To: David Farmer Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements David, Kevin, Alison I am actually comfortable with an implementation that is short of revocation, but I am still not comfortable with "should". Should makes it optional. Officially not being out of compliance with ARIN policy makes it optional. I suggest that an ISP refusing to register a downstream customer is out of compliance with ARIN policy, and not just choosing to ignore an optional recommendation. If it is only "should" then an ISP can still hold the moral high ground while refusing to support SWIP on the grounds that they will not implement tooling and commit resources when it is only optional. It is a question of if you can hold someone accountable for not complying or if they are free to ignore something that is optional. Owen, Chris, Kevin, Certainly if there is enough support to move this forward, we shouldn't wait another cycle. (I recognize this weakens the "shall" position) My hope is if we can close out the discussion of this topic at the meeting with a clear understanding of if there is community support to move forward the policy with "shall" and also if there is clear support to move the policy forward with "should" in this cycle. This will give the AC a maximum of leverage to do what is needed, and insure it doesn't fall to the next cycle by forcing people to support only what they perceive as the best option. Assuming there is support for both "shall" and "should" the AC could choose to move "shall" to last call, and if there are then issues, move should to last call. We need to get clear on how to structure the question here. My thoughts are 1. Do you support the policy with "shall" if it doesn't require an extra cycle and support "should" in this cycle if "shall" cannot advance? 2. Do you only support the policy as written? 3. Do you oppose both the policy as written and with "shall"? When considering if there is enough support to move the policy as written forward, the AC should consider the hands in both questions 1 & 2. I support the policy with "shall" with a fall back to "should". __Jason On Thu, Sep 28, 2017 at 1:18 PM, David Farmer > wrote: I agree with Kevin if a bigger stick is need to ensure compliance in the future we can take that step if/when there proves to be a serious non-compliance issue in the future. Personally, I'm not ready to threaten revocation, in this case. My intent in suggesting what is now 6.5.5.4 was to crate an avenue for ARIN Staff to intervene with ISPs on behalf of customers, if a customer wanted their assignment registered and their ISP refused to register their assignment as requested, the customer can appeal the issue to ARIN. I'm fine with that intervention being short of threatening revocation, at least until their proves to be a serious issue with ISP's refusing valid requests by endusers to register assignments. I think the current language provides the proper balance. I'm fine with the standard procedure starting with ARIN Staff forwarding such complaints to an ISP requesting an explanation of the situation. However, if this develops into a chronic matter for an ISP, I would expect ARIN Staff to escalate the issue beyond simply asking for an explanation. Further after escalation, if the matter continues to be chronic, I would expect eventually the community to be altered to the situation. Probably not the specifics of which ISP and customers, but at least that there is an issue and some sense of the situation involved. Therefore, I support the policy as written. I'm not strongly opposed to changing from "should" to "shall" for section 6.5.5.4, but I'd prefer keeping that change in reserve, so we can go there, if there proves to be serious issues with non-compliance in the future. Put another way, I think voluntary compliance is highly preferred for this issue, and if voluntary compliance proves insufficient, then we can deal with that in the future. Thanks. On Thu, Sep 28, 2017 at 10:46 AM, Kevin Blumberg > wrote: I support the policy as written. If the stick isn?t big enough it appears a simple policy change could be used, not just for this section but all the other areas ?should? is used. I would like to point out that ?should? is currently used 30 times in the NRPM. In reading John?s explanation, I can?t see ?should? and ?shall? being considered an editorial change. To extend the policy cycle to another meeting would be far worse. Out of curiosity, how often has ARIN had to deal with SWIP issues like this, where the other party ignored you? Thanks, Kevin Blumberg From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of John Curran Sent: Wednesday, September 27, 2017 5:59 PM To: Jason Schiller > Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements On 26 Sep 2017, at 3:18 PM, Jason Schiller > wrote: I oppose as written. There should not be a different standard of requirement for: - re-allocation - reassignment containing a /47 or more addresses - subdelegation of any size that will be individually announced which is "shall" and Registration Requested by Recipient which is "should" I would support if they are both "shall". Can ARIN staff discuss what actions it will take if an ISP's down stream customer contacts them and explains that their ISP refuses to SWIP their reassignment to them? Will they do anything more than reach out to the ISP and tell them they "should" SWIP it? Jason - If this policy change 2017-5 is adopted, then a provider that has IPv6 space from ARIN but routinely fails to publish registration information (for /47 or larger reassignments) would be in violation, and ARIN would have clear policy language that would enable us to discuss with the ISP the need to publish this information in a timely manner. Service providers who blatantly ignore such a provision on an ongoing basis will be in the enviable position of hearing me chat with them about their obligations to follow ARIN number resource policy, including the consequences (i.e. potential revocation of the IPv6 number resources.) If the langauge for the new section 6.5.5.4 "Registration Requested by Recipient? reads ?? the ISP should register that assignment?, then ARIN would send on any received customer complaint to the ISP, and remind the ISP that they should follow number resource policy in this regard but not otherwise taking any action. If the language for the new section 6.5.5.4 "Registration Requested by Recipient? reads ?? the ISP shall register that assignment?, then failure to do so would be a far more serious matter that, if left unaddressed on a chronic manner, could have me discussing the customer complaints as a sign of potential failure to comply with number resource policy, including the consequences (i.e. potential revocation of the IPv6 number resources.) I would note that the community should be very clear about its intentions for ISPs with regard to customer requested reassignment publication, given there is large difference in obligations that result from policy language choice. ARIN staff remains, as always, looking forward to implementing whatever policy emerges from the consensus-based policy development process. Thanks! /John John Curran President and CEO American Registry for Internet Numbers _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 ________________________________ ________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwinters at edwardrose.com Fri Sep 29 12:30:31 2017 From: mwinters at edwardrose.com (Michael Winters) Date: Fri, 29 Sep 2017 16:30:31 +0000 Subject: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements In-Reply-To: <41243BE0-2E6D-43C7-9AA9-639B70BBCFC3@delong.com> References: <4D69C6C7-A6C1-41DD-8CF7-7DC198973E9F@arin.net> <7E7773B523E82C478734E793E58F69E7A52C530A@SBS2011.thewireinc.local> <41243BE0-2E6D-43C7-9AA9-639B70BBCFC3@delong.com> Message-ID: <9ad5c4d7bdcd490692d2863db3433c7d@kz-mail01.manifold.edwardrosekzoo.com> Shall is not minor. Ask ARIN legal counsel if there is a big or small difference between should and shall. Additionally, if you are going to say shall, what happens if there is non-compliance? You should define the consequences if you want to say shall. Thanks, Mike From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong Sent: Friday, September 29, 2017 10:13 AM To: Jason Schiller Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements On Sep 29, 2017, at 8:58 AM, Jason Schiller > wrote: David, Kevin, Alison I am actually comfortable with an implementation that is short of revocation, but I am still not comfortable with "should". Should makes it optional. Officially not being out of compliance with ARIN policy makes it optional. I suggest that an ISP refusing to register a downstream customer is out of compliance with ARIN policy, and not just choosing to ignore an optional recommendation. If it is only "should" then an ISP can still hold the moral high ground while refusing to support SWIP on the grounds that they will not implement tooling and commit resources when it is only optional. It is a question of if you can hold someone accountable for not complying or if they are free to ignore something that is optional. Owen, Chris, Kevin, Certainly if there is enough support to move this forward, we shouldn't wait another cycle. (I recognize this weakens the "shall" position) Other than AC sophistry or community confusion, there?s absolutely no reason, IMHO, that we can?t get community support and consensus around shall as a minor change prior to last call, so I don?t think it actually weakens the argument. I agree that if we have enough of either of the above that it won?t move forward with shall until another cycle, it?s not worth waiting another cycle and we should push through an additional separate policy for this single-word correction, so I suppose to that extent, it could be seen as weakening the argument for doing it now. My hope is if we can close out the discussion of this topic at the meeting with a clear understanding of if there is community support to move forward the policy with "shall" and also if there is clear support to move the policy forward with "should" in this cycle. This will give the AC a maximum of leverage to do what is needed, and insure it doesn't fall to the next cycle by forcing people to support only what they perceive as the best option. 100% Agreed. Assuming there is support for both "shall" and "should" the AC could choose to move "shall" to last call, and if there are then issues, move should to last call. Excellent idea, IMHO. We need to get clear on how to structure the question here. My thoughts are 1. Do you support the policy with "shall" if it doesn't require an extra cycle and support "should" in this cycle if "shall" cannot advance? 2. Do you only support the policy as written? 3. Do you oppose both the policy as written and with "shall"? When considering if there is enough support to move the policy as written forward, the AC should consider the hands in both questions 1 & 2. I support the policy with "shall" with a fall back to "should". __Jason On Thu, Sep 28, 2017 at 1:18 PM, David Farmer > wrote: I agree with Kevin if a bigger stick is need to ensure compliance in the future we can take that step if/when there proves to be a serious non-compliance issue in the future. Personally, I'm not ready to threaten revocation, in this case. My intent in suggesting what is now 6.5.5.4 was to crate an avenue for ARIN Staff to intervene with ISPs on behalf of customers, if a customer wanted their assignment registered and their ISP refused to register their assignment as requested, the customer can appeal the issue to ARIN. I'm fine with that intervention being short of threatening revocation, at least until their proves to be a serious issue with ISP's refusing valid requests by endusers to register assignments. I think the current language provides the proper balance. I'm fine with the standard procedure starting with ARIN Staff forwarding such complaints to an ISP requesting an explanation of the situation. However, if this develops into a chronic matter for an ISP, I would expect ARIN Staff to escalate the issue beyond simply asking for an explanation. Further after escalation, if the matter continues to be chronic, I would expect eventually the community to be altered to the situation. Probably not the specifics of which ISP and customers, but at least that there is an issue and some sense of the situation involved. Therefore, I support the policy as written. I'm not strongly opposed to changing from "should" to "shall" for section 6.5.5.4, but I'd prefer keeping that change in reserve, so we can go there, if there proves to be serious issues with non-compliance in the future. Put another way, I think voluntary compliance is highly preferred for this issue, and if voluntary compliance proves insufficient, then we can deal with that in the future. Thanks. On Thu, Sep 28, 2017 at 10:46 AM, Kevin Blumberg > wrote: I support the policy as written. If the stick isn?t big enough it appears a simple policy change could be used, not just for this section but all the other areas ?should? is used. I would like to point out that ?should? is currently used 30 times in the NRPM. In reading John?s explanation, I can?t see ?should? and ?shall? being considered an editorial change. To extend the policy cycle to another meeting would be far worse. Out of curiosity, how often has ARIN had to deal with SWIP issues like this, where the other party ignored you? Thanks, Kevin Blumberg From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of John Curran Sent: Wednesday, September 27, 2017 5:59 PM To: Jason Schiller > Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements On 26 Sep 2017, at 3:18 PM, Jason Schiller > wrote: I oppose as written. There should not be a different standard of requirement for: - re-allocation - reassignment containing a /47 or more addresses - subdelegation of any size that will be individually announced which is "shall" and Registration Requested by Recipient which is "should" I would support if they are both "shall". Can ARIN staff discuss what actions it will take if an ISP's down stream customer contacts them and explains that their ISP refuses to SWIP their reassignment to them? Will they do anything more than reach out to the ISP and tell them they "should" SWIP it? Jason - If this policy change 2017-5 is adopted, then a provider that has IPv6 space from ARIN but routinely fails to publish registration information (for /47 or larger reassignments) would be in violation, and ARIN would have clear policy language that would enable us to discuss with the ISP the need to publish this information in a timely manner. Service providers who blatantly ignore such a provision on an ongoing basis will be in the enviable position of hearing me chat with them about their obligations to follow ARIN number resource policy, including the consequences (i.e. potential revocation of the IPv6 number resources.) If the langauge for the new section 6.5.5.4 "Registration Requested by Recipient? reads ?? the ISP should register that assignment?, then ARIN would send on any received customer complaint to the ISP, and remind the ISP that they should follow number resource policy in this regard but not otherwise taking any action. If the language for the new section 6.5.5.4 "Registration Requested by Recipient? reads ?? the ISP shall register that assignment?, then failure to do so would be a far more serious matter that, if left unaddressed on a chronic manner, could have me discussing the customer complaints as a sign of potential failure to comply with number resource policy, including the consequences (i.e. potential revocation of the IPv6 number resources.) I would note that the community should be very clear about its intentions for ISPs with regard to customer requested reassignment publication, given there is large difference in obligations that result from policy language choice. ARIN staff remains, as always, looking forward to implementing whatever policy emerges from the consensus-based policy development process. Thanks! /John John Curran President and CEO American Registry for Internet Numbers _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 _______________________________________________ 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 lsawyer at gci.com Fri Sep 29 12:40:59 2017 From: lsawyer at gci.com (Leif Sawyer) Date: Fri, 29 Sep 2017 16:40:59 +0000 Subject: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements In-Reply-To: <9ad5c4d7bdcd490692d2863db3433c7d@kz-mail01.manifold.edwardrosekzoo.com> References: <4D69C6C7-A6C1-41DD-8CF7-7DC198973E9F@arin.net> <7E7773B523E82C478734E793E58F69E7A52C530A@SBS2011.thewireinc.local> <41243BE0-2E6D-43C7-9AA9-639B70BBCFC3@delong.com> <9ad5c4d7bdcd490692d2863db3433c7d@kz-mail01.manifold.edwardrosekzoo.com> Message-ID: Thanks for the feedback, everybody. I've captured these thoughts into the slide deck that I'll be presenting during the meeting. Definitely looking forward to the lively discussion next week. Leif From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Michael Winters Sent: Friday, September 29, 2017 8:31 AM To: Owen DeLong; Jason Schiller Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements [External Email] Shall is not minor. Ask ARIN legal counsel if there is a big or small difference between should and shall. Additionally, if you are going to say shall, what happens if there is non-compliance? You should define the consequences if you want to say shall. Thanks, Mike From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Owen DeLong Sent: Friday, September 29, 2017 10:13 AM To: Jason Schiller > Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements On Sep 29, 2017, at 8:58 AM, Jason Schiller > wrote: David, Kevin, Alison I am actually comfortable with an implementation that is short of revocation, but I am still not comfortable with "should". Should makes it optional. Officially not being out of compliance with ARIN policy makes it optional. I suggest that an ISP refusing to register a downstream customer is out of compliance with ARIN policy, and not just choosing to ignore an optional recommendation. If it is only "should" then an ISP can still hold the moral high ground while refusing to support SWIP on the grounds that they will not implement tooling and commit resources when it is only optional. It is a question of if you can hold someone accountable for not complying or if they are free to ignore something that is optional. Owen, Chris, Kevin, Certainly if there is enough support to move this forward, we shouldn't wait another cycle. (I recognize this weakens the "shall" position) Other than AC sophistry or community confusion, there?s absolutely no reason, IMHO, that we can?t get community support and consensus around shall as a minor change prior to last call, so I don?t think it actually weakens the argument. I agree that if we have enough of either of the above that it won?t move forward with shall until another cycle, it?s not worth waiting another cycle and we should push through an additional separate policy for this single-word correction, so I suppose to that extent, it could be seen as weakening the argument for doing it now. My hope is if we can close out the discussion of this topic at the meeting with a clear understanding of if there is community support to move forward the policy with "shall" and also if there is clear support to move the policy forward with "should" in this cycle. This will give the AC a maximum of leverage to do what is needed, and insure it doesn't fall to the next cycle by forcing people to support only what they perceive as the best option. 100% Agreed. Assuming there is support for both "shall" and "should" the AC could choose to move "shall" to last call, and if there are then issues, move should to last call. Excellent idea, IMHO. We need to get clear on how to structure the question here. My thoughts are 1. Do you support the policy with "shall" if it doesn't require an extra cycle and support "should" in this cycle if "shall" cannot advance? 2. Do you only support the policy as written? 3. Do you oppose both the policy as written and with "shall"? When considering if there is enough support to move the policy as written forward, the AC should consider the hands in both questions 1 & 2. I support the policy with "shall" with a fall back to "should". __Jason On Thu, Sep 28, 2017 at 1:18 PM, David Farmer > wrote: I agree with Kevin if a bigger stick is need to ensure compliance in the future we can take that step if/when there proves to be a serious non-compliance issue in the future. Personally, I'm not ready to threaten revocation, in this case. My intent in suggesting what is now 6.5.5.4 was to crate an avenue for ARIN Staff to intervene with ISPs on behalf of customers, if a customer wanted their assignment registered and their ISP refused to register their assignment as requested, the customer can appeal the issue to ARIN. I'm fine with that intervention being short of threatening revocation, at least until their proves to be a serious issue with ISP's refusing valid requests by endusers to register assignments. I think the current language provides the proper balance. I'm fine with the standard procedure starting with ARIN Staff forwarding such complaints to an ISP requesting an explanation of the situation. However, if this develops into a chronic matter for an ISP, I would expect ARIN Staff to escalate the issue beyond simply asking for an explanation. Further after escalation, if the matter continues to be chronic, I would expect eventually the community to be altered to the situation. Probably not the specifics of which ISP and customers, but at least that there is an issue and some sense of the situation involved. Therefore, I support the policy as written. I'm not strongly opposed to changing from "should" to "shall" for section 6.5.5.4, but I'd prefer keeping that change in reserve, so we can go there, if there proves to be serious issues with non-compliance in the future. Put another way, I think voluntary compliance is highly preferred for this issue, and if voluntary compliance proves insufficient, then we can deal with that in the future. Thanks. On Thu, Sep 28, 2017 at 10:46 AM, Kevin Blumberg > wrote: I support the policy as written. If the stick isn?t big enough it appears a simple policy change could be used, not just for this section but all the other areas ?should? is used. I would like to point out that ?should? is currently used 30 times in the NRPM. In reading John?s explanation, I can?t see ?should? and ?shall? being considered an editorial change. To extend the policy cycle to another meeting would be far worse. Out of curiosity, how often has ARIN had to deal with SWIP issues like this, where the other party ignored you? Thanks, Kevin Blumberg From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of John Curran Sent: Wednesday, September 27, 2017 5:59 PM To: Jason Schiller > Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements On 26 Sep 2017, at 3:18 PM, Jason Schiller > wrote: I oppose as written. There should not be a different standard of requirement for: - re-allocation - reassignment containing a /47 or more addresses - subdelegation of any size that will be individually announced which is "shall" and Registration Requested by Recipient which is "should" I would support if they are both "shall". Can ARIN staff discuss what actions it will take if an ISP's down stream customer contacts them and explains that their ISP refuses to SWIP their reassignment to them? Will they do anything more than reach out to the ISP and tell them they "should" SWIP it? Jason - If this policy change 2017-5 is adopted, then a provider that has IPv6 space from ARIN but routinely fails to publish registration information (for /47 or larger reassignments) would be in violation, and ARIN would have clear policy language that would enable us to discuss with the ISP the need to publish this information in a timely manner. Service providers who blatantly ignore such a provision on an ongoing basis will be in the enviable position of hearing me chat with them about their obligations to follow ARIN number resource policy, including the consequences (i.e. potential revocation of the IPv6 number resources.) If the langauge for the new section 6.5.5.4 "Registration Requested by Recipient? reads ?? the ISP should register that assignment?, then ARIN would send on any received customer complaint to the ISP, and remind the ISP that they should follow number resource policy in this regard but not otherwise taking any action. If the language for the new section 6.5.5.4 "Registration Requested by Recipient? reads ?? the ISP shall register that assignment?, then failure to do so would be a far more serious matter that, if left unaddressed on a chronic manner, could have me discussing the customer complaints as a sign of potential failure to comply with number resource policy, including the consequences (i.e. potential revocation of the IPv6 number resources.) I would note that the community should be very clear about its intentions for ISPs with regard to customer requested reassignment publication, given there is large difference in obligations that result from policy language choice. ARIN staff remains, as always, looking forward to implementing whatever policy emerges from the consensus-based policy development process. Thanks! /John John Curran President and CEO American Registry for Internet Numbers _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== -- _______________________________________________________ Jason Schiller|NetOps|jschiller at google.com|571-266-0006 _______________________________________________ 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 rudi.daniel at gmail.com Fri Sep 29 13:16:39 2017 From: rudi.daniel at gmail.com (Rudolph Daniel) Date: Fri, 29 Sep 2017 13:16:39 -0400 Subject: [arin-ppml] ARIN-2017-5 In-Reply-To: References: Message-ID: "shall" Ref: John's comment. ........... if left unaddressed on a chronic manner, could have me discussing the customer complaints as a sign of potential failure to comply with number resource policy, including the consequences (i.e. potential revocation of the IPv6 number resources.). End quote. Would ARIN legal have an issue with suggested consequence .above.. of chronic failure to comply ? rd Sep 29, 2017 12:26 PM, wrote: > > Send ARIN-PPML mailing list submissions to > arin-ppml at arin.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.arin.net/mailman/listinfo/arin-ppml > or, via email, send a message with subject or body 'help' to > arin-ppml-request at arin.net > > You can reach the person managing the list at > arin-ppml-owner at arin.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of ARIN-PPML digest..." > > > Today's Topics: > > 1. Re: Recommended Draft Policy ARIN-2017-5: Improved IPv6 > Registration Requirements (Michael Peddemors) > 2. Re: Recommended Draft Policy ARIN-2017-5: Improved IPv6 > Registration Requirements (Michael Winters) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 29 Sep 2017 07:55:57 -0700 > From: Michael Peddemors > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2017-5: > Improved IPv6 Registration Requirements > Message-ID: <53f61942-1409-a7e1-0ffb-bd129d879827 at linuxmagic.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > +1 > > On 17-09-29 06:58 AM, Jason Schiller wrote: > > David, Kevin,?Alison > > > > I am actually comfortable with an implementation that is short of > > revocation, > > but I am still not comfortable with "should". > > > > Should makes it optional.? Officially not being out of compliance with > > ARIN policy makes it optional. > > > > I suggest that an ISP refusing to register a downstream customer > > is out of compliance with ARIN policy, and not just choosing to ignore > > an optional recommendation. > > > > If it is only "should" then an ISP can still hold the moral high ground > > while refusing to support SWIP on the grounds that they will not > > implement tooling and commit resources when it is only optional. > > > > It is a question of if you can hold someone accountable for not > > complying or if they are free to ignore something that is optional. > > > > > > > > Owen, Chris, Kevin, > > > > Certainly if there is enough support to move this forward, we shouldn't > > wait another cycle. (I recognize this weakens the "shall" position) > > > > My hope is if we can close out the discussion of this topic at the meeting > > with a clear understanding of if there is community support to move forward > > the policy with "shall" and also if there is clear support to move the > > policy forward > > with "should" in this cycle.? This will give the AC a maximum of > > leverage to do > > what is needed, and insure it doesn't fall to the next cycle by forcing > > people > > to support only what they perceive?as the best option. > > > > Assuming there is support for both "shall" and "should" the AC could > > choose to move "shall" to last call, and if there are then issues, move > > should to last call. > > > > > > We need to get clear on how to structure the question here. > > > > My thoughts are > > > > 1. Do you support the policy with "shall" if it doesn't require an extra > > cycle > > ? ? and support "should" in this cycle if "shall" cannot advance? > > > > 2. Do you only support the policy as written? > > > > 3. Do you oppose both the policy as written and with "shall"? > > > > When considering if there is enough support to move the policy as > > written forward, the AC should consider the hands in both questions 1 & 2. > > > > > > I support the policy with "shall" with a fall back to "should". > > > > __Jason > > > > > > On Thu, Sep 28, 2017 at 1:18 PM, David Farmer > > wrote: > > > > I agree with Kevin if a bigger stick is need to ensure compliance in > > the future we can take that step if/when there proves to be a > > serious non-compliance?issue in the future. Personally, I'm not > > ready to threaten revocation, in this case. My intent in suggesting > > what is now 6.5.5.4 was to crate an avenue for ARIN Staff to > > intervene with ISPs on behalf of customers, if a customer wanted > > their assignment registered and their ISP refused to register their > > assignment as requested, the customer can appeal the issue to ARIN. > > I'm fine with that intervention being short of threatening > > revocation, at least until their proves to be a serious issue with > > ISP's refusing valid requests by endusers to register assignments. > > I think the current language provides the proper balance. > > > > I'm fine with the standard procedure starting with ARIN Staff > > forwarding such complaints to an ISP requesting an explanation of > > the situation. However, if this develops into a chronic matter for > > an ISP, I would expect ARIN?Staff to escalate the issue beyond > > simply asking for an explanation.??Further after escalation, if the > > matter continues to be chronic, I would expect eventually the > > community to be altered to the situation. Probably not the specifics > > of which ISP and customers, but at least that there is an issue and > > some sense of the situation involved. > > > > Therefore, I support the policy as written. I'm not strongly opposed > > to changing from "should" to "shall" for section 6.5.5.4, but I'd > > prefer keeping that change in reserve, so we can go there, if there > > proves to be serious issues with non-compliance in the future. Put > > another way, I think voluntary compliance is highly preferred for > > this issue, and if voluntary compliance proves insufficient, then we > > can deal with that in the future. > > > > Thanks. > > > > On Thu, Sep 28, 2017 at 10:46 AM, Kevin Blumberg > > wrote: > > > > I support the policy as written. ____ > > > > __ __ > > > > If the stick isn?t big enough it appears a simple policy change > > could be used, not just for this section but all the other areas > > ?should? is used.____ > > > > __ __ > > > > I would like to point out that ?should? is currently used 30 > > times in the NRPM. ____ > > > > __ __ > > > > In reading John?s explanation, I can?t see ?should? and ?shall? > > being considered an editorial change. To extend the policy cycle > > to another meeting would be far worse.____ > > > > __ __ > > > > Out of curiosity, how often has ARIN had to deal with SWIP > > issues like this, where the other party ignored you?____ > > > > __ __ > > > > Thanks,____ > > > > __ __ > > > > Kevin Blumberg____ > > > > __ __ > > > > __ __ > > > > *From:*ARIN-PPML [mailto:arin-ppml-bounces at arin.net > > ] *On Behalf Of *John Curran > > *Sent:* Wednesday, September 27, 2017 5:59 PM > > *To:* Jason Schiller > > > > *Cc:* arin-ppml at arin.net > > *Subject:* Re: [arin-ppml] Recommended Draft Policy ARIN-2017-5: > > Improved IPv6 Registration Requirements____ > > > > __ __ > > > > On 26 Sep 2017, at 3:18 PM, Jason Schiller > > wrote:____ > > > > __ __ > > > > I oppose as written. ____ > > > > __ __ > > > > There should not be a different standard of requirement for:____ > > > > - re-allocation____ > > > > - reassignment containing a /47 or more addresses____ > > > > - subdelegation of any?size that will be individually > > announced____ > > > > __ __ > > > > which is "shall"____ > > > > __ __ > > > > and?Registration Requested by Recipient____ > > > > __ __ > > > > which is "should"____ > > > > __ __ > > > > I would support if they are both "shall".____ > > > > __ __ > > > > Can ARIN staff discuss what actions it will take if an ISP's____ > > > > down stream customer contacts them and explains that their____ > > > > ISP refuses to SWIP their reassignment to them?____ > > > > __ __ > > > > Will they do anything more than reach out to the ISP and > > tell____ > > > > them they "should" SWIP it?____ > > > > __ __ > > > > Jason - > > > > ? ?If this policy change 2017-5 is adopted, then a provider > > that has IPv6 space from ARIN ____ > > > > ? ?but routinely fails to publish registration information (for > > /47 or larger reassignments) ____ > > > > ? ?would be in violation, and ARIN would have clear policy > > language that would enable ____ > > > > ? ?us to discuss with the ISP the need to publish this > > information in a timely manner. ____ > > > > > > ? ?Service providers who blatantly ignore such a provision on > > an ongoing basis will be > > ? ?in the enviable position of hearing me chat with them about > > their obligations to follow > > ? ?ARIN number resource policy, including the consequences > > (i.e. potential revocation ____ > > > > ? ?of the IPv6 number?resources.)____ > > > > __ __ > > > > ? ?If the langauge for the new section 6.5.5.4 "Registration > > Requested by Recipient? ____ > > > > ? ?reads ?? the ISP should register that assignment?, then ARIN > > would send on any____ > > > > ? ?received customer complaint to the ISP, and remind the ISP > > that they should____ > > > > ? ?follow number resource policy in this regard but not > > otherwise taking any action. ____ > > > > __ __ > > > > ? ?If the language for the new section 6.5.5.4 "Registration > > Requested by Recipient? ____ > > > > ? ?reads ?? the ISP shall register that assignment?, then > > failure to do so would be____ > > > > ? ?a far more serious matter that, if left unaddressed on a > > chronic manner, could have ____ > > > > ? ?me discussing the customer complaints as a sign of potential > > failure to comply with ____ > > > > ? ?number resource policy, including the consequences (i.e. > > potential revocation of ____ > > > > ? ?the IPv6 number?resources.)____ > > > > __ __ > > > > ? ?I would note that the community should be very clear about > > its intentions for ISPs____ > > > > ? ?with regard to customer requested reassignment publication, > > given there is large ____ > > > > ? ?difference in obligations that result from policy language > > choice. ? ARIN staff remains, ____ > > > > ? ?as always, looking forward to implementing whatever policy > > emerges from the ____ > > > > ? ?consensus-based policy development process. ____ > > > > __ __ > > > > Thanks!____ > > > > /John____ > > > > __ __ > > > > John Curran____ > > > > President and CEO____ > > > > American Registry for Internet Numbers____ > > > > __ __ > > > > __ __ > > > > __ __ > > > > __ __ > > > > __ __ > > > > __ __ > > > > __ __ > > > > > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net > > ). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > > > Please contact info at arin.net if you > > experience any issues. > > > > > > > > > > -- > > =============================================== > > David Farmer Email:farmer at umn.edu > > Networking & Telecommunication Services > > Office of Information Technology > > University of Minnesota > > 2218 University Ave SE > > < https://maps.google.com/?q=2218+University+Ave+SE&entry=gmail&source=g> > > ? ? ? Phone: 612-626-0815 > > Minneapolis, MN 55414-3029?? Cell: 612-812-9952 > > > > =============================================== > > > > > > > > > > -- > > _______________________________________________________ > > Jason Schiller|NetOps|jschiller at google.com > > |571-266-0006 > > > > > > > > _______________________________________________ > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact info at arin.net if you experience any issues. > > > > > > -- > "Catch the Magic of Linux..." > ------------------------------------------------------------------------ > Michael Peddemors, President/CEO LinuxMagic Inc. > Visit us at http://www.linuxmagic.com @linuxmagic > ------------------------------------------------------------------------ > A Wizard IT Company - For More Info http://www.wizard.ca > "LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd. > ------------------------------------------------------------------------ > 604-682-0300 Beautiful British Columbia, Canada > > This email and any electronic data contained are confidential and intended > solely for the use of the individual or entity to which they are addressed. > Please note that any views or opinions presented in this email are solely > those of the author and are not intended to represent those of the company. > > > ------------------------------ > > Message: 2 > Date: Fri, 29 Sep 2017 16:25:31 +0000 > From: Michael Winters > To: Jason Schiller , David Farmer > > Cc: "arin-ppml at arin.net" > Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2017-5: > Improved IPv6 Registration Requirements > Message-ID: > < bf6e80e57c734e1da104f9072fd4315a at kz-mail01.manifold.edwardrosekzoo.com> > > Content-Type: text/plain; charset="utf-8" > > If you are going to change it to shall, then you also need to define the consequences of non-compliance. > > From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Jason Schiller > Sent: Friday, September 29, 2017 9:59 AM > To: David Farmer > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements > > David, Kevin, Alison > > I am actually comfortable with an implementation that is short of revocation, > but I am still not comfortable with "should". > > Should makes it optional. Officially not being out of compliance with > ARIN policy makes it optional. > > I suggest that an ISP refusing to register a downstream customer > is out of compliance with ARIN policy, and not just choosing to ignore > an optional recommendation. > > If it is only "should" then an ISP can still hold the moral high ground > while refusing to support SWIP on the grounds that they will not > implement tooling and commit resources when it is only optional. > > It is a question of if you can hold someone accountable for not > complying or if they are free to ignore something that is optional. > > > > Owen, Chris, Kevin, > > Certainly if there is enough support to move this forward, we shouldn't > wait another cycle. (I recognize this weakens the "shall" position) > > My hope is if we can close out the discussion of this topic at the meeting > with a clear understanding of if there is community support to move forward > the policy with "shall" and also if there is clear support to move the policy forward > with "should" in this cycle. This will give the AC a maximum of leverage to do > what is needed, and insure it doesn't fall to the next cycle by forcing people > to support only what they perceive as the best option. > > Assuming there is support for both "shall" and "should" the AC could > choose to move "shall" to last call, and if there are then issues, move > should to last call. > > > We need to get clear on how to structure the question here. > > My thoughts are > > 1. Do you support the policy with "shall" if it doesn't require an extra cycle > and support "should" in this cycle if "shall" cannot advance? > > 2. Do you only support the policy as written? > > 3. Do you oppose both the policy as written and with "shall"? > > When considering if there is enough support to move the policy as > written forward, the AC should consider the hands in both questions 1 & 2. > > > I support the policy with "shall" with a fall back to "should". > > __Jason > > > > On Thu, Sep 28, 2017 at 1:18 PM, David Farmer > wrote: > I agree with Kevin if a bigger stick is need to ensure compliance in the future we can take that step if/when there proves to be a serious non-compliance issue in the future. Personally, I'm not ready to threaten revocation, in this case. My intent in suggesting what is now 6.5.5.4 was to crate an avenue for ARIN Staff to intervene with ISPs on behalf of customers, if a customer wanted their assignment registered and their ISP refused to register their assignment as requested, the customer can appeal the issue to ARIN. I'm fine with that intervention being short of threatening revocation, at least until their proves to be a serious issue with ISP's refusing valid requests by endusers to register assignments. I think the current language provides the proper balance. > > I'm fine with the standard procedure starting with ARIN Staff forwarding such complaints to an ISP requesting an explanation of the situation. However, if this develops into a chronic matter for an ISP, I would expect ARIN Staff to escalate the issue beyond simply asking for an explanation. Further after escalation, if the matter continues to be chronic, I would expect eventually the community to be altered to the situation. Probably not the specifics of which ISP and customers, but at least that there is an issue and some sense of the situation involved. > > Therefore, I support the policy as written. I'm not strongly opposed to changing from "should" to "shall" for section 6.5.5.4, but I'd prefer keeping that change in reserve, so we can go there, if there proves to be serious issues with non-compliance in the future. Put another way, I think voluntary compliance is highly preferred for this issue, and if voluntary compliance proves insufficient, then we can deal with that in the future. > > Thanks. > > On Thu, Sep 28, 2017 at 10:46 AM, Kevin Blumberg > wrote: > I support the policy as written. > > If the stick isn?t big enough it appears a simple policy change could be used, not just for this section but all the other areas ?should? is used. > > I would like to point out that ?should? is currently used 30 times in the NRPM. > > In reading John?s explanation, I can?t see ?should? and ?shall? being considered an editorial change. To extend the policy cycle to another meeting would be far worse. > > Out of curiosity, how often has ARIN had to deal with SWIP issues like this, where the other party ignored you? > > Thanks, > > Kevin Blumberg > > > From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of John Curran > Sent: Wednesday, September 27, 2017 5:59 PM > To: Jason Schiller > > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements > > On 26 Sep 2017, at 3:18 PM, Jason Schiller > wrote: > > I oppose as written. > > There should not be a different standard of requirement for: > - re-allocation > - reassignment containing a /47 or more addresses > - subdelegation of any size that will be individually announced > > which is "shall" > > and Registration Requested by Recipient > > which is "should" > > I would support if they are both "shall". > > Can ARIN staff discuss what actions it will take if an ISP's > down stream customer contacts them and explains that their > ISP refuses to SWIP their reassignment to them? > > Will they do anything more than reach out to the ISP and tell > them they "should" SWIP it? > > Jason - > > If this policy change 2017-5 is adopted, then a provider that has IPv6 space from ARIN > but routinely fails to publish registration information (for /47 or larger reassignments) > would be in violation, and ARIN would have clear policy language that would enable > us to discuss with the ISP the need to publish this information in a timely manner. > > Service providers who blatantly ignore such a provision on an ongoing basis will be > in the enviable position of hearing me chat with them about their obligations to follow > ARIN number resource policy, including the consequences (i.e. potential revocation > of the IPv6 number resources.) > > If the langauge for the new section 6.5.5.4 "Registration Requested by Recipient? > reads ?? the ISP should register that assignment?, then ARIN would send on any > received customer complaint to the ISP, and remind the ISP that they should > follow number resource policy in this regard but not otherwise taking any action. > > If the language for the new section 6.5.5.4 "Registration Requested by Recipient? > reads ?? the ISP shall register that assignment?, then failure to do so would be > a far more serious matter that, if left unaddressed on a chronic manner, could have > me discussing the customer complaints as a sign of potential failure to comply with > number resource policy, including the consequences (i.e. potential revocation of > the IPv6 number resources.) > > I would note that the community should be very clear about its intentions for ISPs > with regard to customer requested reassignment publication, given there is large > difference in obligations that result from policy language choice. ARIN staff remains, > as always, looking forward to implementing whatever policy emerges from the > consensus-based policy development process. > > Thanks! > /John > > John Curran > President and CEO > American Registry for Internet Numbers > > > > > > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > > > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE< https://maps.google.com/?q=2218+University+Ave+SE&entry=gmail&source=g> Phone: 612-626-0815 > Minneapolis, MN 55414-3029 Cell: 612-812-9952 > =============================================== > > > > -- > _______________________________________________________ > Jason Schiller|NetOps|jschiller at google.com|571-266-0006 > > > ________________________________ > > ________________________________ > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < http://lists.arin.net/pipermail/arin-ppml/attachments/20170929/b714fd1f/attachment.html > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > ARIN-PPML mailing list > ARIN-PPML at arin.net > http://lists.arin.net/mailman/listinfo/arin-ppml > > ------------------------------ > > End of ARIN-PPML Digest, Vol 147, Issue 58 > ****************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: From farmer at umn.edu Fri Sep 29 14:25:23 2017 From: farmer at umn.edu (David Farmer) Date: Fri, 29 Sep 2017 13:25:23 -0500 Subject: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements In-Reply-To: References: <4D69C6C7-A6C1-41DD-8CF7-7DC198973E9F@arin.net> <7E7773B523E82C478734E793E58F69E7A52C530A@SBS2011.thewireinc.local> Message-ID: I will note the standard will not universally be "should", if the reason the endusers wants the prefix registered is they were given permission to route it, or its shorter than /47, then the standard will be "shall", because of the clauses in 6.5.5.1. On Fri, Sep 29, 2017 at 8:58 AM, Jason Schiller wrote: > David, Kevin, Alison > > I am actually comfortable with an implementation that is short of > revocation, > but I am still not comfortable with "should". > > Should makes it optional. Officially not being out of compliance with > ARIN policy makes it optional. > > I suggest that an ISP refusing to register a downstream customer > is out of compliance with ARIN policy, and not just choosing to ignore > an optional recommendation. > Further, a "shall" standard would not allow the ISP or ARIN Staff any discretion, with a "shall" standard the mere fact that the enduser made the request means the ISP MUST make the registration, except for the reasons explicitly provided in policy. If the ISP has a valid reason, not explicitly covered in policy, to not make the registration, a "should" standard allows ARIN Staff to consider that on equal footing with the reasons the enduser wants the registration. If it is only "should" then an ISP can still hold the moral high ground > while refusing to support SWIP on the grounds that they will not > implement tooling and commit resources when it is only optional. > > It is a question of if you can hold someone accountable for not > complying or if they are free to ignore something that is optional. > "Should" is not completely optional, it recognizes there could be valid reasons for an exception. Where as, "shall" is required, unless an exception is explicitly provided. "May" is completely optional. Therefore, with a "should" standard, if the situation escalated to the point of ARIN making an official inquiry, the ISP will need to articulate a valid reason why they have not made the requested registration, that is at least as compelling as the reason for the request by the enduser. Not doing so would be tantamount to being out of compliance with ARIN policy. Thanks. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at egh.com Fri Sep 29 15:06:55 2017 From: john at egh.com (John Santos) Date: Fri, 29 Sep 2017 15:06:55 -0400 Subject: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements In-Reply-To: <53f61942-1409-a7e1-0ffb-bd129d879827@linuxmagic.com> References: <4D69C6C7-A6C1-41DD-8CF7-7DC198973E9F@arin.net> <7E7773B523E82C478734E793E58F69E7A52C530A@SBS2011.thewireinc.local> <53f61942-1409-a7e1-0ffb-bd129d879827@linuxmagic.com> Message-ID: <625212a0-e72e-2b80-ce0f-c70b50dca7fb@egh.com> +1 I would also prefer "shall" to "should", but the current text is acceptable to me. The "should", as I read it, only applies when downstream customers who have an assignments of /48 or longer request to be SWIPed by their upstream provider.? If their assignment is a /47 or more, or if it is a re-allocation, the SWIP is required.? Therefore most or all ISP's will have a mechanism and procedures for SWIPing their customers, and this proposal just changes the situations when they do it.? Since the current policy actually requires them to SWIP *all* their IPv6 customers (/64 or more), they should already have mechanisms and procedures in place, so either "should" or "shall" reduces, not increases, any perceived burden on the upstream ISPs. Are there any ISP's that would be happy to SWIP their smaller customers, but aren't really sure that it is allowed?? "Should" would make it clear that they are permitted to do so.? Are there any other reasons to prefer "should" over "shall", or is the objection merely that making this change would delay implementation of the rest of the policy? I would guess most smaller customers would be happy to leave the burden of dealing with abuse complaints, but as a very small end user (IPv4 /24) who already has an abuse contact (me), I would be happy to be SWIPed for IPv6. On 9/29/2017 10:55 AM, Michael Peddemors wrote: > +1 > > On 17-09-29 06:58 AM, Jason Schiller wrote: >> David, Kevin,?Alison >> >> I am actually comfortable with an implementation that is short of >> revocation, >> but I am still not comfortable with "should". >> >> Should makes it optional.? Officially not being out of compliance with >> ARIN policy makes it optional. >> >> I suggest that an ISP refusing to register a downstream customer >> is out of compliance with ARIN policy, and not just choosing to ignore >> an optional recommendation. >> >> If it is only "should" then an ISP can still hold the moral high ground >> while refusing to support SWIP on the grounds that they will not >> implement tooling and commit resources when it is only optional. >> >> It is a question of if you can hold someone accountable for not >> complying or if they are free to ignore something that is optional. >> >> >> >> Owen, Chris, Kevin, >> >> Certainly if there is enough support to move this forward, we shouldn't >> wait another cycle. (I recognize this weakens the "shall" position) >> >> My hope is if we can close out the discussion of this topic at the >> meeting >> with a clear understanding of if there is community support to move >> forward >> the policy with "shall" and also if there is clear support to move >> the policy forward >> with "should" in this cycle.? This will give the AC a maximum of >> leverage to do >> what is needed, and insure it doesn't fall to the next cycle by >> forcing people >> to support only what they perceive?as the best option. >> >> Assuming there is support for both "shall" and "should" the AC could >> choose to move "shall" to last call, and if there are then issues, move >> should to last call. >> >> >> We need to get clear on how to structure the question here. >> >> My thoughts are >> >> 1. Do you support the policy with "shall" if it doesn't require an >> extra cycle >> ?? ? and support "should" in this cycle if "shall" cannot advance? >> >> 2. Do you only support the policy as written? >> >> 3. Do you oppose both the policy as written and with "shall"? >> >> When considering if there is enough support to move the policy as >> written forward, the AC should consider the hands in both questions 1 >> & 2. >> >> >> I support the policy with "shall" with a fall back to "should". >> >> __Jason >> >> >> On Thu, Sep 28, 2017 at 1:18 PM, David Farmer > > wrote: >> >> ??? I agree with Kevin if a bigger stick is need to ensure compliance in >> ??? the future we can take that step if/when there proves to be a >> ??? serious non-compliance?issue in the future. Personally, I'm not >> ??? ready to threaten revocation, in this case. My intent in suggesting >> ??? what is now 6.5.5.4 was to crate an avenue for ARIN Staff to >> ??? intervene with ISPs on behalf of customers, if a customer wanted >> ??? their assignment registered and their ISP refused to register their >> ??? assignment as requested, the customer can appeal the issue to >> ARIN. ??? I'm fine with that intervention being short of threatening >> ??? revocation, at least until their proves to be a serious issue with >> ??? ISP's refusing valid requests by endusers to register >> assignments. ??? I think the current language provides the proper >> balance. >> >> ??? I'm fine with the standard procedure starting with ARIN Staff >> ??? forwarding such complaints to an ISP requesting an explanation of >> ??? the situation. However, if this develops into a chronic matter for >> ??? an ISP, I would expect ARIN?Staff to escalate the issue beyond >> ??? simply asking for an explanation.??Further after escalation, if the >> ??? matter continues to be chronic, I would expect eventually the >> ??? community to be altered to the situation. Probably not the specifics >> ??? of which ISP and customers, but at least that there is an issue and >> ??? some sense of the situation involved. >> >> ??? Therefore, I support the policy as written. I'm not strongly opposed >> ??? to changing from "should" to "shall" for section 6.5.5.4, but I'd >> ??? prefer keeping that change in reserve, so we can go there, if there >> ??? proves to be serious issues with non-compliance in the future. Put >> ??? another way, I think voluntary compliance is highly preferred for >> ??? this issue, and if voluntary compliance proves insufficient, then we >> ??? can deal with that in the future. >> >> ??? Thanks. >> >> ??? On Thu, Sep 28, 2017 at 10:46 AM, Kevin Blumberg > ??? > wrote: >> >> ??????? I support the policy as written. ____ >> >> ??????? __ __ >> >> ??????? If the stick isn?t big enough it appears a simple policy change >> ??????? could be used, not just for this section but all the other areas >> ??????? ?should? is used.____ >> >> ??????? __ __ >> >> ??????? I would like to point out that ?should? is currently used 30 >> ??????? times in the NRPM. ____ >> >> ??????? __ __ >> >> ??????? In reading John?s explanation, I can?t see ?should? and ?shall? >> ??????? being considered an editorial change. To extend the policy cycle >> ??????? to another meeting would be far worse.____ >> >> ??????? __ __ >> >> ??????? Out of curiosity, how often has ARIN had to deal with SWIP >> ??????? issues like this, where the other party ignored you?____ >> >> ??????? __ __ >> >> ??????? Thanks,____ >> >> ??????? __ __ >> >> ??????? Kevin Blumberg____ >> >> ??????? __ __ >> >> ??????? __ __ >> >> ??????? *From:*ARIN-PPML [mailto:arin-ppml-bounces at arin.net >> ??????? ] *On Behalf Of *John Curran >> ??????? *Sent:* Wednesday, September 27, 2017 5:59 PM >> ??????? *To:* Jason Schiller > ??????? > >> ??????? *Cc:* arin-ppml at arin.net >> ??????? *Subject:* Re: [arin-ppml] Recommended Draft Policy ARIN-2017-5: >> ??????? Improved IPv6 Registration Requirements____ >> >> ??????? __ __ >> >> ??????? On 26 Sep 2017, at 3:18 PM, Jason Schiller > ??????? > wrote:____ >> >> ??????????? __ __ >> >> ??????????? I oppose as written. ____ >> >> ??????????? __ __ >> >> ??????????? There should not be a different standard of requirement >> for:____ >> >> ??????????? - re-allocation____ >> >> ??????????? - reassignment containing a /47 or more addresses____ >> >> ??????????? - subdelegation of any?size that will be individually >> ??????????? announced____ >> >> ??????????? __ __ >> >> ??????????? which is "shall"____ >> >> ??????????? __ __ >> >> ??????????? and?Registration Requested by Recipient____ >> >> ??????????? __ __ >> >> ??????????? which is "should"____ >> >> ??????????? __ __ >> >> ??????????? I would support if they are both "shall".____ >> >> ??????????? __ __ >> >> ??????????? Can ARIN staff discuss what actions it will take if an >> ISP's____ >> >> ??????????? down stream customer contacts them and explains that >> their____ >> >> ??????????? ISP refuses to SWIP their reassignment to them?____ >> >> ??????????? __ __ >> >> ??????????? Will they do anything more than reach out to the ISP and >> ??????????? tell____ >> >> ??????????? them they "should" SWIP it?____ >> >> ??????? __ __ >> >> ??????? Jason - >> >> ???????? ? ?If this policy change 2017-5 is adopted, then a provider >> ??????? that has IPv6 space from ARIN ____ >> >> ???????? ? ?but routinely fails to publish registration information (for >> ??????? /47 or larger reassignments) ____ >> >> ???????? ? ?would be in violation, and ARIN would have clear policy >> ??????? language that would enable ____ >> >> ???????? ? ?us to discuss with the ISP the need to publish this >> ??????? information in a timely manner. ____ >> >> >> ???????? ? ?Service providers who blatantly ignore such a provision on >> ??????? an ongoing basis will be >> ???????? ? ?in the enviable position of hearing me chat with them about >> ??????? their obligations to follow >> ???????? ? ?ARIN number resource policy, including the consequences >> ??????? (i.e. potential revocation ____ >> >> ???????? ? ?of the IPv6 number?resources.)____ >> >> ??????? __ __ >> >> ???????? ? ?If the langauge for the new section 6.5.5.4 "Registration >> ??????? Requested by Recipient? ____ >> >> ???????? ? ?reads ?? the ISP should register that assignment?, then ARIN >> ??????? would send on any____ >> >> ???????? ? ?received customer complaint to the ISP, and remind the ISP >> ??????? that they should____ >> >> ???????? ? ?follow number resource policy in this regard but not >> ??????? otherwise taking any action. ____ >> >> ??????? __ __ >> >> ???????? ? ?If the language for the new section 6.5.5.4 "Registration >> ??????? Requested by Recipient? ____ >> >> ???????? ? ?reads ?? the ISP shall register that assignment?, then >> ??????? failure to do so would be____ >> >> ???????? ? ?a far more serious matter that, if left unaddressed on a >> ??????? chronic manner, could have ____ >> >> ???????? ? ?me discussing the customer complaints as a sign of potential >> ??????? failure to comply with ____ >> >> ???????? ? ?number resource policy, including the consequences (i.e. >> ??????? potential revocation of ____ >> >> ???????? ? ?the IPv6 number?resources.)____ >> >> ??????? __ __ >> >> ???????? ? ?I would note that the community should be very clear about >> ??????? its intentions for ISPs____ >> >> ???????? ? ?with regard to customer requested reassignment publication, >> ??????? given there is large ____ >> >> ???????? ? ?difference in obligations that result from policy language >> ??????? choice. ? ARIN staff remains, ____ >> >> ???????? ? ?as always, looking forward to implementing whatever policy >> ??????? emerges from the ____ >> >> ???????? ? ?consensus-based policy development process. ____ >> >> ??????? __ __ >> >> ??????? Thanks!____ >> >> ??????? /John____ >> >> ??????? __ __ >> >> ??????? John Curran____ >> >> ??????? President and CEO____ >> >> ??????? American Registry for Internet Numbers____ >> >> ??????? __ __ >> >> ??????? __ __ >> >> ??????? __ __ >> >> ??????? __ __ >> >> ??????? __ __ >> >> ??????? __ __ >> >> ??????? __ __ >> >> >> ??????? _______________________________________________ >> ??????? PPML >> ??????? You are receiving this message because you are subscribed to >> ??????? the ARIN Public Policy Mailing List (ARIN-PPML at arin.net >> ??????? ). >> ??????? Unsubscribe or manage your mailing list subscription at: >> ??????? http://lists.arin.net/mailman/listinfo/arin-ppml >> ??????? >> ??????? Please contact info at arin.net if you >> ??????? experience any issues. >> >> >> >> >> ??? -- ??? =============================================== >> ??? David Farmer Email:farmer at umn.edu >> ??? Networking & Telecommunication Services >> ??? Office of Information Technology >> ??? University of Minnesota >> ??? 2218 University Ave SE >> >> ???? ? ? ? Phone: 612-626-0815 >> ??? Minneapolis, MN 55414-3029?? Cell: 612-812-9952 >> ??? >> ??? =============================================== >> >> >> >> >> -- >> _______________________________________________________ >> Jason Schiller|NetOps|jschiller at google.com >> |571-266-0006 >> >> >> >> _______________________________________________ >> 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. >> > > > -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 From john at egh.com Fri Sep 29 16:22:38 2017 From: john at egh.com (John Santos) Date: Fri, 29 Sep 2017 16:22:38 -0400 Subject: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements In-Reply-To: References: <4D69C6C7-A6C1-41DD-8CF7-7DC198973E9F@arin.net> <7E7773B523E82C478734E793E58F69E7A52C530A@SBS2011.thewireinc.local> Message-ID: Oops, in my list of cases where the existing wording does not make it optional (in my previous reply), I left out "the prefix is being separately routed". On 9/29/2017 2:25 PM, David Farmer wrote: > I will note the standard will not universally be "should", if the > reason the endusers wants the prefix registered is they were given > permission to route it, or its shorter than /47, then the standard > will be "shall", because of the clauses in 6.5.5.1. > > On Fri, Sep 29, 2017 at 8:58 AM, Jason Schiller > wrote: > > David, Kevin,?Alison > > I am actually comfortable with an implementation that is short of > revocation, > but I am still not comfortable with "should". > > Should makes it optional.? Officially not being out of compliance with > ARIN policy makes it optional. > > I suggest that an ISP refusing to register a downstream customer > is out of compliance with ARIN policy, and not just choosing to > ignore > an optional recommendation. > > > Further, a "shall" standard would not allow the ISP or ARIN Staff any > discretion, with a "shall" standard the mere fact that the enduser > made the request means the ISP MUST make the registration, except for > the reasons explicitly provided in policy.? If the ISP has a valid > reason, not explicitly covered in policy, to not make the > registration, a "should" standard allows ARIN Staff to consider that > on equal footing with the reasons the enduser wants the registration. > > If it is only "should" then an ISP can still hold the moral high > ground > while refusing to support SWIP on the grounds that they will not > implement tooling and commit resources when it is only optional. > > It is a question of if you can hold someone accountable for not > complying or if they are free to ignore something that is optional. > > > "Should" is not completely optional, it recognizes there could be > valid reasons for an exception. Where as, "shall" is required, unless > an exception is explicitly provided. "May" is completely optional. > Therefore, with a "should" standard, if the situation escalated to the > point of ARIN making an official inquiry, the ISP will need to > articulate a valid reason why they have not made the requested > registration, that is at least as compelling as the reason for the > request by the enduser. Not doing so would be tantamount to being out > of compliance with ARIN policy. > > Thanks. > > -- > =============================================== > David Farmer Email:farmer at umn.edu > Networking & Telecommunication Services > Office of Information Technology > University of Minnesota > 2218 University Ave SE? ? ? ? Phone: 612-626-0815 > > Minneapolis, MN 55414-3029?? Cell: 612-812-9952 > =============================================== > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Matthew.Wilder at telus.com Fri Sep 29 19:04:39 2017 From: Matthew.Wilder at telus.com (Matthew Wilder) Date: Fri, 29 Sep 2017 23:04:39 +0000 Subject: [arin-ppml] Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements In-Reply-To: <625212a0-e72e-2b80-ce0f-c70b50dca7fb@egh.com> References: <4D69C6C7-A6C1-41DD-8CF7-7DC198973E9F@arin.net> <7E7773B523E82C478734E793E58F69E7A52C530A@SBS2011.thewireinc.local> <53f61942-1409-a7e1-0ffb-bd129d879827@linuxmagic.com> <625212a0-e72e-2b80-ce0f-c70b50dca7fb@egh.com> Message-ID: Without a doubt the words "should" and "shall" are very different words from a legal standpoint. Should can be understood as "may" while shall can be understood as "must". The difference between permission and obligation is night and day in a legal context. Out of curiosity I took a look through NRPM for instances of should and shall. I found 30 instances of "should" and 67 of "shall". Of these, 5 instances were "ISP/ISPs should" and none were "ISP/ISPs shall". From that standpoint, the should text is more consistent with NRPM language in general. If there is to be some question of the teeth the policy provides to ARIN, I suggest that be considered under another policy discussion / proposal. Also worth noting is that much of the use of shall is generally improper, given that shall is a verb reserved for subjects, not objects. People and entities "shall" would be proper usage, whereas things "shall be" is not generally accepted. I found many such examples, such as: 2.10. End site "The term End Site shall mean..." A bit of an aside there that network folk may not always provide the most legally conscious text, and that was probably fine when we didn't have to, but as we enter a new phase of the Internet with IPv4 address markets, maybe there is need for some attention to this. tl;dr. I support the text as written given the significant change in meaning with the use of the word shall. (full disclosure: TELUS already reports IPv6 reassignments on each service with over /48 size, and then some). Regards, mw On September 29, 2017 12:07 PM, John Santos wrote: > +1 > > I would also prefer "shall" to "should", but the current text is > acceptable to me. > > The "should", as I read it, only applies when downstream customers > who have an assignments of /48 or longer request to be SWIPed by their > upstream provider. If their assignment is a /47 or more, or if it is > a re-allocation, the SWIP is required. Therefore most or all ISP's > will have a mechanism and procedures for SWIPing their customers, and > this proposal just changes the situations when they do it. Since the > current policy actually requires them to SWIP *all* their IPv6 > customers (/64 or more), they should already have mechanisms and > procedures in place, so either "should" or "shall" reduces, not > increases, any perceived burden on the upstream ISPs. > > Are there any ISP's that would be happy to SWIP their smaller > customers, but aren't really sure that it is allowed? "Should" > would make it clear that they are permitted to do so. Are there any > other reasons to prefer "should" over "shall", or is the objection > merely that making this change would delay implementation of the rest > of the policy? > > I would guess most smaller customers would be happy to leave the burden > of dealing with abuse complaints, but as a very small end user (IPv4 > /24) who already has an abuse contact (me), I would be happy to be > SWIPed for IPv6. > > On 9/29/2017 10:55 AM, Michael Peddemors wrote: >> +1 >> >> On 17-09-29 06:58 AM, Jason Schiller wrote: >> David, Kevin, Alison>> >> I am actually comfortable with an implementation that is short of >> revocation, but I am still not comfortable with "should". >> >> Should makes it optional.? Officially not being out of compliance >> with ARIN policy makes it optional. >> >> I suggest that an ISP refusing to register a downstream customer is >> out of compliance with ARIN policy, and not just choosing to ignore >> an optional recommendation. >> >> If it is only "should" then an ISP can still hold the moral high >> ground while refusing to support SWIP on the grounds that they will >> not implement tooling and commit resources when it is only optional. >> >> It is a question of if you can hold someone accountable for not >> complying or if they are free to ignore something that is optional. >> >> >> >> Owen, Chris, Kevin, >> >> Certainly if there is enough support to move this forward, we >> shouldn't wait another cycle. (I recognize this weakens the "shall" >> position) >> >> My hope is if we can close out the discussion of this topic at the >> meeting with a clear understanding of if there is community support >> to move forward the policy with "shall" and also if there is clear >> support to move the policy forward with "should" in this cycle.? This >> will give the AC a maximum of leverage to do what is needed, and >> insure it doesn't fall to the next cycle by forcing people to support >> only what they perceive?as the best option. >> >> Assuming there is support for both "shall" and "should" the AC could >> choose to move "shall" to last call, and if there are then issues, >> move should to last call. >> >> >> We need to get clear on how to structure the question here. >> >> My thoughts are >> >> 1. Do you support the policy with "shall" if it doesn't require an >> extra cycle >> ?? ? and support "should" in this cycle if "shall" cannot advance? >> >> 2. Do you only support the policy as written? >> >> 3. Do you oppose both the policy as written and with "shall"? >> >> When considering if there is enough support to move the policy as >> written forward, the AC should consider the hands in both questions 1 >> & 2. >> >> >> I support the policy with "shall" with a fall back to "should". >> >> __Jason >> >> >> On Thu, Sep 28, 2017 at 1:18 PM, David Farmer > > wrote: >> >> ??? I agree with Kevin if a bigger stick is need to ensure compliance >> in >> ??? the future we can take that step if/when there proves to be a >> ??? serious non-compliance?issue in the future. Personally, I'm not >> ??? ready to threaten revocation, in this case. My intent in >> suggesting >> ??? what is now 6.5.5.4 was to crate an avenue for ARIN Staff to >> ??? intervene with ISPs on behalf of customers, if a customer wanted >> ??? their assignment registered and their ISP refused to register >> their >> ??? assignment as requested, the customer can appeal the issue to >> ARIN. ??? I'm fine with that intervention being short of threatening >> ??? revocation, at least until their proves to be a serious issue >> with >> ??? ISP's refusing valid requests by endusers to register >> assignments. ??? I think the current language provides the proper >> balance. >> >> ??? I'm fine with the standard procedure starting with ARIN Staff >> ??? forwarding such complaints to an ISP requesting an explanation of >> ??? the situation. However, if this develops into a chronic matter >> for >> ??? an ISP, I would expect ARIN?Staff to escalate the issue beyond >> ??? simply asking for an explanation.??Further after escalation, if >> the >> ??? matter continues to be chronic, I would expect eventually the >> ??? community to be altered to the situation. Probably not the >> specifics >> ??? of which ISP and customers, but at least that there is an issue >> and >> ??? some sense of the situation involved. >> >> ??? Therefore, I support the policy as written. I'm not strongly >> opposed >> ??? to changing from "should" to "shall" for section 6.5.5.4, but I'd >> ??? prefer keeping that change in reserve, so we can go there, if >> there >> ??? proves to be serious issues with non-compliance in the future. >> Put >> ??? another way, I think voluntary compliance is highly preferred for >> ??? this issue, and if voluntary compliance proves insufficient, then >> we >> ??? can deal with that in the future. >> >> ??? Thanks. >> >> ??? On Thu, Sep 28, 2017 at 10:46 AM, Kevin Blumberg >> > ??? > wrote: >> >> ??????? I support the policy as written. ____ >> >> ??????? __ __ >> >> ??????? If the stick isn?t big enough it appears a simple policy >> change >> ??????? could be used, not just for this section but all the other >> areas >> ??????? ?should? is used.____ >> >> ??????? __ __ >> >> ??????? I would like to point out that ?should? is currently used 30 >> ??????? times in the NRPM. ____ >> >> ??????? __ __ >> >> ??????? In reading John?s explanation, I can?t see ?should? and ?shall? >> ??????? being considered an editorial change. To extend the policy >> cycle >> ??????? to another meeting would be far worse.____ >> >> ??????? __ __ >> >> ??????? Out of curiosity, how often has ARIN had to deal with SWIP >> ??????? issues like this, where the other party ignored you?____ >> >> ??????? __ __ >> >> ??????? Thanks,____ >> >> ??????? __ __ >> >> ??????? Kevin Blumberg____ >> >> ??????? __ __ >> >> ??????? __ __ >> >> ??????? *From:*ARIN-PPML [mailto:arin-ppml-bounces at arin.net >> ??????? ] *On Behalf Of *John >> Curran >> ??????? *Sent:* Wednesday, September 27, 2017 5:59 PM >> ??????? *To:* Jason Schiller > ??????? > >> ??????? *Cc:* arin-ppml at arin.net >> ??????? *Subject:* Re: [arin-ppml] Recommended Draft Policy ARIN-2017-5: >> ??????? Improved IPv6 Registration Requirements____ >> >> ??????? __ __ >> >> ??????? On 26 Sep 2017, at 3:18 PM, Jason Schiller >> > ??????? > wrote:____ >> >> ??????????? __ __ >> >> ??????????? I oppose as written. ____ >> >> ??????????? __ __ >> >> ??????????? There should not be a different standard of requirement >> for:____ >> >> ??????????? - re-allocation____ >> >> ??????????? - reassignment containing a /47 or more addresses____ >> >> ??????????? - subdelegation of any?size that will be individually >> ??????????? announced____ >> >> ??????????? __ __ >> >> ??????????? which is "shall"____ >> >> ??????????? __ __ >> >> ??????????? and?Registration Requested by Recipient____ >> >> ??????????? __ __ >> >> ??????????? which is "should"____ >> >> ??????????? __ __ >> >> ??????????? I would support if they are both "shall".____ >> >> ??????????? __ __ >> >> ??????????? Can ARIN staff discuss what actions it will take if an >> ISP's____ >> >> ??????????? down stream customer contacts them and explains that >> their____ >> >> ??????????? ISP refuses to SWIP their reassignment to them?____ >> >> ??????????? __ __ >> >> ??????????? Will they do anything more than reach out to the ISP and >> ??????????? tell____ >> >> ??????????? them they "should" SWIP it?____ >> >> ??????? __ __ >> >> ??????? Jason - >> >> ???????? ? ?If this policy change 2017-5 is adopted, then a provider >> ??????? that has IPv6 space from ARIN ____ >> >> ???????? ? ?but routinely fails to publish registration information >> (for >> ??????? /47 or larger reassignments) ____ >> >> ???????? ? ?would be in violation, and ARIN would have clear policy >> ??????? language that would enable ____ >> >> ???????? ? ?us to discuss with the ISP the need to publish this >> ??????? information in a timely manner. ____ >> >> >> ???????? ? ?Service providers who blatantly ignore such a provision >> on >> ??????? an ongoing basis will be >> ???????? ? ?in the enviable position of hearing me chat with them >> about >> ??????? their obligations to follow >> ???????? ? ?ARIN number resource policy, including the consequences >> ??????? (i.e. potential revocation ____ >> >> ???????? ? ?of the IPv6 number?resources.)____ >> >> ??????? __ __ >> >> ???????? ? ?If the langauge for the new section 6.5.5.4 "Registration >> ??????? Requested by Recipient? ____ >> >> ???????? ? ?reads ?? the ISP should register that assignment?, then >> ARIN >> ??????? would send on any____ >> >> ???????? ? ?received customer complaint to the ISP, and remind the >> ISP >> ??????? that they should____ >> >> ???????? ? ?follow number resource policy in this regard but not >> ??????? otherwise taking any action. ____ >> >> ??????? __ __ >> >> ???????? ? ?If the language for the new section 6.5.5.4 "Registration >> ??????? Requested by Recipient? ____ >> >> ???????? ? ?reads ?? the ISP shall register that assignment?, then >> ??????? failure to do so would be____ >> >> ???????? ? ?a far more serious matter that, if left unaddressed on a >> ??????? chronic manner, could have ____ >> >> ???????? ? ?me discussing the customer complaints as a sign of >> potential >> ??????? failure to comply with ____ >> >> ???????? ? ?number resource policy, including the consequences (i.e. >> ??????? potential revocation of ____ >> >> ???????? ? ?the IPv6 number?resources.)____ >> >> ??????? __ __ >> >> ???????? ? ?I would note that the community should be very clear >> about >> ??????? its intentions for ISPs____ >> >> ???????? ? ?with regard to customer requested reassignment >> publication, >> ??????? given there is large ____ >> >> ???????? ? ?difference in obligations that result from policy >> language >> ??????? choice. ? ARIN staff remains, ____ >> >> ???????? ? ?as always, looking forward to implementing whatever >> policy >> ??????? emerges from the ____ >> >> ???????? ? ?consensus-based policy development process. ____ >> >> ??????? __ __ >> >> ??????? Thanks!____ >> >> ??????? /John____ >> >> ??????? __ __ >> >> ??????? John Curran____ >> >> ??????? President and CEO____ >> >> ??????? American Registry for Internet Numbers____ >> >> ??????? __ __ >> >> ??????? __ __ >> >> ??????? __ __ >> >> ??????? __ __ >> >> ??????? __ __ >> >> ??????? __ __ >> >> ??????? __ __ >> >> >> ??????? _______________________________________________ >> ??????? PPML >> ??????? You are receiving this message because you are subscribed to >> ??????? the ARIN Public Policy Mailing List (ARIN-PPML at arin.net >> ??????? ). >> ??????? Unsubscribe or manage your mailing list subscription at: >> ??????? http://lists.arin.net/mailman/listinfo/arin-ppml >> ??????? >> ??????? Please contact info at arin.net if you >> ??????? experience any issues. >> >> >> >> >> ??? -- ??? =============================================== >> ??? David Farmer Email:farmer at umn.edu >> ??? Networking & Telecommunication Services >> ??? Office of Information Technology >> ??? University of Minnesota >> ??? 2218 University Ave SE >> > =g> >> ???? ? ? ? Phone: 612-626-0815 >> ??? Minneapolis, MN 55414-3029?? Cell: 612-812-9952 >> ??? >> ??? =============================================== >> >> >> >> >> -- >> _______________________________________________________ >> Jason Schiller|NetOps|jschiller at google.com >> |571-266-0006 >> >> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to the ARIN >> Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. >> > > > -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. From jcurran at arin.net Sat Sep 30 08:06:28 2017 From: jcurran at arin.net (John Curran) Date: Sat, 30 Sep 2017 12:06:28 +0000 Subject: [arin-ppml] ARIN-2017-5 In-Reply-To: References: Message-ID: On 29 Sep 2017, at 1:16 PM, Rudolph Daniel > wrote: "shall" Ref: John's comment. ........... if left unaddressed on a chronic manner, could have me discussing the customer complaints as a sign of potential failure to comply with number resource policy, including the consequences (i.e. potential revocation of the IPv6 number resources.). End quote. Would ARIN legal have an issue with suggested consequence .above.. of chronic failure to comply Rudolph - In general, no? all parties agree to compliance with resource policies in NRPM per provisions in RSA, with revocation being a potential consequence of chronic non-compliance. /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From rudi.daniel at gmail.com Sat Sep 30 08:41:11 2017 From: rudi.daniel at gmail.com (Rudolph Daniel) Date: Sat, 30 Sep 2017 08:41:11 -0400 Subject: [arin-ppml] ARIN-2017-5 In-Reply-To: References: Message-ID: Thank you for the clarification. rd On Sep 30, 2017 8:06 AM, "John Curran" wrote: > On 29 Sep 2017, at 1:16 PM, Rudolph Daniel wrote: > > > "shall" > > Ref: John's comment. > ........... > if left unaddressed on a chronic manner, could have > me discussing the customer complaints as a sign of potential failure to > comply with > number resource policy, including the consequences (i.e. potential > revocation of the IPv6 number resources.). > > End quote. > > Would ARIN legal have an issue with suggested consequence .above.. of > chronic failure to comply > > Rudolph - > > In general, no? all parties agree to compliance with resource policies > in NRPM > per provisions in RSA, with revocation being a potential consequence of > chronic > non-compliance. > > /John > > John Curran > President and CEO > ARIN > > -------------- next part -------------- An HTML attachment was scrubbed... URL: