From narten at us.ibm.com Fri Nov 3 00:53:03 2017 From: narten at us.ibm.com (narten at us.ibm.com) Date: Fri, 03 Nov 2017 00:53:03 -0400 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201711030453.vA34r3Oj017771@rotala.raleigh.ibm.com> Total of 1 messages in the last 7 days. script run at: Fri Nov 3 00:53:02 EDT 2017 Messages | Bytes | Who --------+------+--------+----------+------------------------ 100.00% | 1 |100.00% | 9529 | narten at us.ibm.com --------+------+--------+----------+------------------------ 100.00% | 1 |100.00% | 9529 | Total From narten at us.ibm.com Fri Nov 10 00:53:03 2017 From: narten at us.ibm.com (narten at us.ibm.com) Date: Fri, 10 Nov 2017 00:53:03 -0500 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201711100553.vAA5r3Vg012785@rotala.raleigh.ibm.com> Total of 1 messages in the last 7 days. script run at: Fri Nov 10 00:53:03 EST 2017 Messages | Bytes | Who --------+------+--------+----------+------------------------ 100.00% | 1 |100.00% | 9448 | narten at us.ibm.com --------+------+--------+----------+------------------------ 100.00% | 1 |100.00% | 9448 | Total From apotter at hilcoglobal.com Tue Nov 14 11:05:04 2017 From: apotter at hilcoglobal.com (Potter, Amy) Date: Tue, 14 Nov 2017 16:05:04 +0000 Subject: [arin-ppml] 2017-3 Message-ID: <62DD04C9CA033342B055D0C8BFE2A0FCD875FF9E@NB-EXCH10.hgag.hilcotrading.com> Updated text of 2017-3 is provided below. The problem statement has been simplified, and language has been cleaned up a bit. Feedback would be appreciated. UPDATE TO NPRM 3.6: Annual Whois POC Validation Problem Statement: Many of the Point of Contacts listed in ARIN's public Whois database contain out-of-date and inaccurate contact information. 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 Whois Point of Contact Data 3.6.1 Annual POC Verification ARIN will perform an annual verification of specific Points of Contact registered in the public Whois using the criteria and procedures outlined in sections 3.6.2, 3.6.3, and 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 Point of Contact or POC throughout this policy, and should be understood to be both organization and resource POCs: - Admin - Tech - NOC - Abuse 3.6.3 Organizations Covered by this Policy This policy applies to every Organization that has a direct assignment, direct allocation, or AS number from ARIN (or one of its predecessor registries) or a reallocation from an upstream ISP. This includes but is not limited to upstream ISPs and their downstream ISP customers (as defined by NRPM 2.5 and 2.6), but not reassignments made to their downstream end user customers. 3.6.4 Procedure for Verification An annual email notification will be sent to each of the Points of Contact outlined 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 an affirmative that their Whois contact information is correct and complete or to submit new data to correct and complete it. If after careful analysis, ARIN staff deems a POC to be completely and permanently abandoned or otherwise illegitimate, the POC record shall be marked invalid in Whois. 3.6.5 Non-Responsive Point of Contact Records Once a non-responsive POC has been marked invalid in the public Whois, any organization lacking a validated Admin or Tech POC will be unable to access the full suite of functionality within ARIN Online until the invalid POC(s) have either validated that their information is accurate or modified their POC to contain up-to-date information. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jschiller at google.com Tue Nov 14 14:54:17 2017 From: jschiller at google.com (Jason Schiller) Date: Tue, 14 Nov 2017 14:54:17 -0500 Subject: [arin-ppml] 2017-3 In-Reply-To: <62DD04C9CA033342B055D0C8BFE2A0FCD875FF9E@NB-EXCH10.hgag.hilcotrading.com> References: <62DD04C9CA033342B055D0C8BFE2A0FCD875FF9E@NB-EXCH10.hgag.hilcotrading.com> Message-ID: I support this policy as written but... It fails to address one concern that was clearly voiced by more than a few people when discussing this policy in the past on list and at public policy consultations (PPCs) held at recent public policy meetings (PPMs): How do we prevent resources being randomly re-assigned simple to a random contact. Today we catch these during the annual POC validation. The proposal floated was that all re-assign simple need to be verified by the email listed prior to the SWIP being processed. Will that be addressed in this proposal or in a parallel proposal? ___Jason On Tue, Nov 14, 2017 at 11:05 AM, Potter, Amy wrote: > Updated text of 2017-3 is provided below. The problem statement has been > simplified, and language has been cleaned up a bit. Feedback would be > appreciated. > > > > UPDATE TO NPRM 3.6: Annual Whois POC Validation > > > > *Problem Statement:* > > > > Many of the Point of Contacts listed in ARIN?s public Whois database > contain out-of-date and inaccurate contact information. > > > > *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 Whois Point of Contact Data > > > > 3.6.1 Annual POC Verification > > ARIN will perform an annual verification of specific Points of Contact > registered in the public Whois using the criteria and procedures outlined > in sections 3.6.2, 3.6.3, and 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 Point of Contact or POC throughout this policy, and > should be understood to be both organization and resource POCs: > > - Admin > - Tech > - NOC > - Abuse > > > > 3.6.3 Organizations Covered by this Policy > > This policy applies to every Organization that has a direct assignment, > direct allocation, or AS number from ARIN (or one of its predecessor > registries) or a reallocation from an upstream ISP. This includes but is > not limited to upstream ISPs and their downstream ISP customers (as defined > by NRPM 2.5 and 2.6), but not reassignments made to their downstream end > user customers. > > > > > > 3.6.4 Procedure for Verification > > An annual email notification will be sent to each of the Points of Contact > outlined 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 an affirmative that their Whois contact information is correct > and complete or to submit new data to correct and complete it. If after > careful analysis, ARIN staff deems a POC to be completely and permanently > abandoned or otherwise illegitimate, the POC record shall be marked invalid > in Whois. > > > > > > 3.6.5 Non-Responsive Point of Contact Records > > Once a non-responsive POC has been marked invalid in the public Whois, any > organization lacking a validated Admin or Tech POC will be unable to access > the full suite of functionality within ARIN Online until the invalid POC(s) > have either validated that their information is accurate or > modified their POC to contain up-to-date information. > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage 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 Nov 14 14:56:32 2017 From: jschiller at google.com (Jason Schiller) Date: Tue, 14 Nov 2017 14:56:32 -0500 Subject: [arin-ppml] 2017-3 In-Reply-To: References: <62DD04C9CA033342B055D0C8BFE2A0FCD875FF9E@NB-EXCH10.hgag.hilcotrading.com> Message-ID: this needs to also include re-assign detail where a "01. Downstream Org ID:" is not included. __Jason On Tue, Nov 14, 2017 at 2:54 PM, Jason Schiller wrote: > I support this policy as written but... > > It fails to address one concern that was clearly voiced by more than a few > people > when discussing this policy in the past on list and at public policy > consultations (PPCs) > held at recent public policy meetings (PPMs): > > How do we prevent resources being randomly re-assigned simple to a random > contact. > Today we catch these during the annual POC validation. > > The proposal floated was that all re-assign simple need to be verified by > the email listed > prior to the SWIP being processed. > > Will that be addressed in this proposal or in a parallel proposal? > > ___Jason > > On Tue, Nov 14, 2017 at 11:05 AM, Potter, Amy > wrote: > >> Updated text of 2017-3 is provided below. The problem statement has been >> simplified, and language has been cleaned up a bit. Feedback would be >> appreciated. >> >> >> >> UPDATE TO NPRM 3.6: Annual Whois POC Validation >> >> >> >> *Problem Statement:* >> >> >> >> Many of the Point of Contacts listed in ARIN?s public Whois database >> contain out-of-date and inaccurate contact information. >> >> >> >> *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 Whois Point of Contact Data >> >> >> >> 3.6.1 Annual POC Verification >> >> ARIN will perform an annual verification of specific Points of Contact >> registered in the public Whois using the criteria and procedures outlined >> in sections 3.6.2, 3.6.3, and 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 Point of Contact or POC throughout this policy, and >> should be understood to be both organization and resource POCs: >> >> - Admin >> - Tech >> - NOC >> - Abuse >> >> >> >> 3.6.3 Organizations Covered by this Policy >> >> This policy applies to every Organization that has a direct assignment, >> direct allocation, or AS number from ARIN (or one of its predecessor >> registries) or a reallocation from an upstream ISP. This includes but is >> not limited to upstream ISPs and their downstream ISP customers (as defined >> by NRPM 2.5 and 2.6), but not reassignments made to their downstream end >> user customers. >> >> >> >> >> >> 3.6.4 Procedure for Verification >> >> An annual email notification will be sent to each of the Points of >> Contact outlined 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 an affirmative that their Whois contact information is >> correct and complete or to submit new data to correct and complete it. If >> after careful analysis, ARIN staff deems a POC to be completely and >> permanently abandoned or otherwise illegitimate, the POC record shall be >> marked invalid in Whois. >> >> >> >> >> >> 3.6.5 Non-Responsive Point of Contact Records >> >> Once a non-responsive POC has been marked invalid in the public Whois, >> any organization lacking a validated Admin or Tech POC will be unable to >> access the full suite of functionality within ARIN Online until the invalid >> POC(s) have either validated that their information is accurate or >> modified their POC to contain up-to-date information. >> >> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage 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 john at egh.com Tue Nov 14 17:28:45 2017 From: john at egh.com (John Santos) Date: Tue, 14 Nov 2017 17:28:45 -0500 Subject: [arin-ppml] 2017-3 In-Reply-To: <62DD04C9CA033342B055D0C8BFE2A0FCD875FF9E@NB-EXCH10.hgag.hilcotrading.com> References: <62DD04C9CA033342B055D0C8BFE2A0FCD875FF9E@NB-EXCH10.hgag.hilcotrading.com> Message-ID: The first sentence of section 3.6.4 redundantly says "annual" twice. "An annual email notification will be sent ... on an annual basis." Either the first "annual" or the last phrase ("on an annual basis") should be struck. Otherwise, this is better.? The original wording didn't actually say that if the POC was reachable, but there were mistakes in the contact information, the mistakes could and should be corrected! The only options for a POC were to confirm the POC information as correct and complete, or to be non-responsive.? I know from experience that if there were were errors in the POC information, ARIN would correct it, but the policy as is doesn't actually say so.? I just fought (and lost) this battle with one of the credit reporting agencies which had completely garbled the name of my current employer.? I would be astounded if ARIN wasn't more competent!? :-) On 11/14/2017 11:05 AM, Potter, Amy wrote: > > 3.6.4?Procedure for Verification > > An annual email notification will be sent to each of the Points of > Contact outlined 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 an affirmative that their Whois > contact information is correct and complete or to submit new data to > correct and complete it.? If after careful analysis, ARIN staff deems > a POC to be completely and permanently abandoned or otherwise > illegitimate, the POC record shall be marked invalid in Whois. > > -- John Santos Evans Griffiths & Hart, Inc. 781-861-0670 ext 539 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcurran at arin.net Wed Nov 15 10:43:22 2017 From: jcurran at arin.net (John Curran) Date: Wed, 15 Nov 2017 15:43:22 +0000 Subject: [arin-ppml] 2017-3 In-Reply-To: References: <62DD04C9CA033342B055D0C8BFE2A0FCD875FF9E@NB-EXCH10.hgag.hilcotrading.com> Message-ID: <36ABDC65-C097-4E2C-A25B-278A29742350@arin.net> On 14 Nov 2017, at 2:54 PM, Jason Schiller > wrote: I support this policy as written but... It fails to address one concern that was clearly voiced by more than a few people when discussing this policy in the past on list and at public policy consultations (PPCs) held at recent public policy meetings (PPMs): How do we prevent resources being randomly re-assigned simple to a random contact. Today we catch these during the annual POC validation. The proposal floated was that all re-assign simple need to be verified by the email listed prior to the SWIP being processed. Will that be addressed in this proposal or in a parallel proposal? Jason - As that represents a fairly distinct policy requirement, it would be relatively straightforward to consider it via a distinct policy proposal. For avoidance of doubt, you may find information on submitting policy proposals here - Thanks! /John John Curran President and CEO American Registry for Internet Numbers -------------- next part -------------- An HTML attachment was scrubbed... URL: From austin.murkland at qscend.com Wed Nov 15 17:24:09 2017 From: austin.murkland at qscend.com (Austin Murkland) Date: Wed, 15 Nov 2017 17:24:09 -0500 Subject: [arin-ppml] 2017-3 In-Reply-To: <62DD04C9CA033342B055D0C8BFE2A0FCD875FF9E@NB-EXCH10.hgag.hilcotrading.com> References: <62DD04C9CA033342B055D0C8BFE2A0FCD875FF9E@NB-EXCH10.hgag.hilcotrading.com> Message-ID: i support this policy as written, and also agree with Jason that it doesn't address the issues he describes. I would also be in favor of a parallel policy proposal built upon this one which seeks to remedy this. -Austin On Tue, Nov 14, 2017 at 11:05 AM, Potter, Amy wrote: > Updated text of 2017-3 is provided below. The problem statement has been > simplified, and language has been cleaned up a bit. Feedback would be > appreciated. > > > > UPDATE TO NPRM 3.6: Annual Whois POC Validation > > > > *Problem Statement:* > > > > Many of the Point of Contacts listed in ARIN?s public Whois database > contain out-of-date and inaccurate contact information. > > > > *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 Whois Point of Contact Data > > > > 3.6.1 Annual POC Verification > > ARIN will perform an annual verification of specific Points of Contact > registered in the public Whois using the criteria and procedures outlined > in sections 3.6.2, 3.6.3, and 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 Point of Contact or POC throughout this policy, and > should be understood to be both organization and resource POCs: > > - Admin > - Tech > - NOC > - Abuse > > > > 3.6.3 Organizations Covered by this Policy > > This policy applies to every Organization that has a direct assignment, > direct allocation, or AS number from ARIN (or one of its predecessor > registries) or a reallocation from an upstream ISP. This includes but is > not limited to upstream ISPs and their downstream ISP customers (as defined > by NRPM 2.5 and 2.6), but not reassignments made to their downstream end > user customers. > > > > > > 3.6.4 Procedure for Verification > > An annual email notification will be sent to each of the Points of Contact > outlined 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 an affirmative that their Whois contact information is correct > and complete or to submit new data to correct and complete it. If after > careful analysis, ARIN staff deems a POC to be completely and permanently > abandoned or otherwise illegitimate, the POC record shall be marked invalid > in Whois. > > > > > > 3.6.5 Non-Responsive Point of Contact Records > > Once a non-responsive POC has been marked invalid in the public Whois, any > organization lacking a validated Admin or Tech POC will be unable to access > the full suite of functionality within ARIN Online until the invalid POC(s) > have either validated that their information is accurate or > modified their POC to contain up-to-date information. > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage 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 Nov 16 11:17:12 2017 From: jschiller at google.com (Jason Schiller) Date: Thu, 16 Nov 2017 11:17:12 -0500 Subject: [arin-ppml] 2017-3 In-Reply-To: References: <62DD04C9CA033342B055D0C8BFE2A0FCD875FF9E@NB-EXCH10.hgag.hilcotrading.com> Message-ID: FYI, I submitted a proposal for verifying with re-assignment victims to see if they are an unwitting POC. Seems there was already a proposal on the docket prop-247 https://www.arin.net/policy/proposals/ARIN_prop_247_orig.html. I did quickly check the proposals on the docket, and mis-read the status "Clarity and Understanding". Incorrectly thinking this was just an ARIN AC "editorial update" so I didn't bother to check the text. I am withdrawing my proposal, and have contacted the originator of prop-247 to include a narrow corner case my proposal covered but prop-247 didn't. ___Jason On Wed, Nov 15, 2017 at 5:24 PM, Austin Murkland wrote: > i support this policy as written, and also agree with Jason that it > doesn't address the issues he describes. I would also be in favor of a > parallel policy proposal built upon this one which seeks to remedy this. > > -Austin > > On Tue, Nov 14, 2017 at 11:05 AM, Potter, Amy > wrote: > >> Updated text of 2017-3 is provided below. The problem statement has been >> simplified, and language has been cleaned up a bit. Feedback would be >> appreciated. >> >> >> >> UPDATE TO NPRM 3.6: Annual Whois POC Validation >> >> >> >> *Problem Statement:* >> >> >> >> Many of the Point of Contacts listed in ARIN?s public Whois database >> contain out-of-date and inaccurate contact information. >> >> >> >> *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 Whois Point of Contact Data >> >> >> >> 3.6.1 Annual POC Verification >> >> ARIN will perform an annual verification of specific Points of Contact >> registered in the public Whois using the criteria and procedures outlined >> in sections 3.6.2, 3.6.3, and 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 Point of Contact or POC throughout this policy, and >> should be understood to be both organization and resource POCs: >> >> - Admin >> - Tech >> - NOC >> - Abuse >> >> >> >> 3.6.3 Organizations Covered by this Policy >> >> This policy applies to every Organization that has a direct assignment, >> direct allocation, or AS number from ARIN (or one of its predecessor >> registries) or a reallocation from an upstream ISP. This includes but is >> not limited to upstream ISPs and their downstream ISP customers (as defined >> by NRPM 2.5 and 2.6), but not reassignments made to their downstream end >> user customers. >> >> >> >> >> >> 3.6.4 Procedure for Verification >> >> An annual email notification will be sent to each of the Points of >> Contact outlined 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 an affirmative that their Whois contact information is >> correct and complete or to submit new data to correct and complete it. If >> after careful analysis, ARIN staff deems a POC to be completely and >> permanently abandoned or otherwise illegitimate, the POC record shall be >> marked invalid in Whois. >> >> >> >> >> >> 3.6.5 Non-Responsive Point of Contact Records >> >> Once a non-responsive POC has been marked invalid in the public Whois, >> any organization lacking a validated Admin or Tech POC will be unable to >> access the full suite of functionality within ARIN Online until the invalid >> POC(s) have either validated that their information is accurate or >> modified their POC to contain up-to-date information. >> >> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage 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 narten at us.ibm.com Fri Nov 17 00:53:04 2017 From: narten at us.ibm.com (narten at us.ibm.com) Date: Fri, 17 Nov 2017 00:53:04 -0500 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201711170553.vAH5r4cK004727@rotala.raleigh.ibm.com> Total of 8 messages in the last 7 days. script run at: Fri Nov 17 00:53:04 EST 2017 Messages | Bytes | Who --------+------+--------+----------+------------------------ 37.50% | 3 | 49.03% | 80469 | jschiller at google.com 12.50% | 1 | 14.00% | 22986 | austin.murkland at qscend.com 12.50% | 1 | 13.09% | 21478 | apotter at hilcoglobal.com 12.50% | 1 | 9.69% | 15900 | jcurran at arin.net 12.50% | 1 | 8.42% | 13815 | john at egh.com 12.50% | 1 | 5.78% | 9488 | narten at us.ibm.com --------+------+--------+----------+------------------------ 100.00% | 8 |100.00% | 164136 | Total From rs-lists at seastrom.com Fri Nov 17 08:12:33 2017 From: rs-lists at seastrom.com (Rob Seastrom) Date: Fri, 17 Nov 2017 08:12:33 -0500 Subject: [arin-ppml] Post-ARIN-40 updates to 2017-4 Message-ID: <31C30A2F-129D-4CD7-98FA-EF41ACD05756@seastrom.com> Dear Colleagues, Based on feedback received at the ARIN-40 conference, the AC Shepherds have updated Draft Policy 2017-4 - "Remove bidirectional requirement for inter-RIR transfers". The proposal in its entirety is below. We seek feedback and comment. 2017-4 - Remove bidirectional requirement for inter-RIR transfers Problem Statement: ARIN?s inter-RIR transfer policy is functionally one-way, so the assertion of a reciprocal two-way requirement is gratuitous. Policy statement: Add the following sentence after the first sentence of NRPM 8.4: Inter-RIR transfers may take place only via RIRs who agree to the transfer and share compatible, needs-based policies. Timetable for implementation: Immediate. From farmer at umn.edu Fri Nov 17 10:26:49 2017 From: farmer at umn.edu (David Farmer) Date: Fri, 17 Nov 2017 09:26:49 -0600 Subject: [arin-ppml] Post-ARIN-40 updates to 2017-4 In-Reply-To: <31C30A2F-129D-4CD7-98FA-EF41ACD05756@seastrom.com> References: <31C30A2F-129D-4CD7-98FA-EF41ACD05756@seastrom.com> Message-ID: I support this policy as written. The current reciprocity requirement does not recognize that the vast majority of IPv4 transfers are out of the ARIN region and the vast majority of the supply of IPv4 resources available for transfer exist within the ARIN region. Finally there are legitimate operational reasons that companies within the ARIN region need to transfer resources to themselves or their foreign subsidiaries in other regions regardless of reciprocal transfer policies being available. Thank you for simplifying the text. On Fri, Nov 17, 2017 at 7:12 AM, Rob Seastrom wrote: > > Dear Colleagues, > > Based on feedback received at the ARIN-40 conference, the AC Shepherds > have updated Draft Policy 2017-4 - "Remove bidirectional requirement for > inter-RIR transfers". > > The proposal in its entirety is below. We seek feedback and comment. > > > 2017-4 - Remove bidirectional requirement for inter-RIR transfers > > Problem Statement: > ARIN?s inter-RIR transfer policy is functionally one-way, so the assertion > of a reciprocal two-way requirement is gratuitous. > > Policy statement: > Add the following sentence after the first sentence of NRPM 8.4: > Inter-RIR transfers may take place only via RIRs who agree to the transfer > and share compatible, needs-based policies. > > 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. -- =============================================== 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 Fri Nov 17 10:43:46 2017 From: mike at iptrading.com (Mike Burns) Date: Fri, 17 Nov 2017 10:43:46 -0500 Subject: [arin-ppml] Post-ARIN-40 updates to 2017-4 In-Reply-To: References: <31C30A2F-129D-4CD7-98FA-EF41ACD05756@seastrom.com> Message-ID: <004a01d35fba$db358570$91a09050$@iptrading.com> I support as written for the reasons David describes. From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of David Farmer Sent: Friday, November 17, 2017 10:27 AM To: Rob Seastrom Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Post-ARIN-40 updates to 2017-4 I support this policy as written. The current reciprocity requirement does not recognize that the vast majority of IPv4 transfers are out of the ARIN region and the vast majority of the supply of IPv4 resources available for transfer exist within the ARIN region. Finally there are legitimate operational reasons that companies within the ARIN region need to transfer resources to themselves or their foreign subsidiaries in other regions regardless of reciprocal transfer policies being available. Thank you for simplifying the text. On Fri, Nov 17, 2017 at 7:12 AM, Rob Seastrom > wrote: Dear Colleagues, Based on feedback received at the ARIN-40 conference, the AC Shepherds have updated Draft Policy 2017-4 - "Remove bidirectional requirement for inter-RIR transfers". The proposal in its entirety is below. We seek feedback and comment. 2017-4 - Remove bidirectional requirement for inter-RIR transfers Problem Statement: ARIN?s inter-RIR transfer policy is functionally one-way, so the assertion of a reciprocal two-way requirement is gratuitous. Policy statement: Add the following sentence after the first sentence of NRPM 8.4: Inter-RIR transfers may take place only via RIRs who agree to the transfer and share compatible, needs-based policies. 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. -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at arin.net Tue Nov 21 17:37:31 2017 From: info at arin.net (ARIN) Date: Tue, 21 Nov 2017 17:37:31 -0500 Subject: [arin-ppml] Advisory Council Meeting Results - November 2017 Message-ID: <90ca93ea-ba77-0fc6-538d-c788ce02590f@arin.net> In accordance with the Policy Development Process (PDP), the Advisory Council (AC) met on 16 November 2017. The AC has advanced the following Proposals to Draft Policy status (each will be posted for discussion): * ARIN-prop-244: Clarification of initial block size for IPv4 ISP transfers * ARIN-prop-245: Repeal of Immediate Need for IPv4 Address Space (NRPM Section 4.2.1.6) * ARIN-prop-246: Reallocation and Reassignment Language Cleanup * ARIN-prop-247: Require New POC Validation Upon Reassignment * ARIN-prop-248: Remove ARIN Review Requirements for Large IPv4 Reassignments/Reallocations The AC advances Proposals to Draft Policy status once they are found to be within the scope of the PDP, and contain a clear problem statement and suggested changes to Internet number resource policy text. The AC has sent the following to the Board of Trustees for adoption consideration: * Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements The AC provided the following statement: "After a successful conclusion of the Last Call period, the ARIN AC is forwarding Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements to the ARIN Board with a request for adoption. Based on the consensus of the community at ARIN 40, the policy text was adjusted going into Last Call. While a minority dissent during Last Call period was in favor of the original text, the AC is of the view that the community thoroughly discussed that matter both at ARIN 40 and on PPML, and the consensus of the community supports the change in the text." The AC is continuing to work on: * ARIN-2017-3: Update to NPRM 3.6: Annual Whois POC Validation * ARIN-2017-4: Remove Bidirectional Requirement for Inter-RIR Transfers * ARIN-2017-8: Amend the Definition of Community Network The PDP can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Sean Hopkins Policy Analyst American Registry for Internet Numbers (ARIN) From info at arin.net Tue Nov 21 17:40:39 2017 From: info at arin.net (ARIN) Date: Tue, 21 Nov 2017 17:40:39 -0500 Subject: [arin-ppml] Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers Message-ID: <652abd11-68d7-900e-7776-b97b2311ea05@arin.net> On 16 November 2017, the ARIN Advisory Council (AC) advanced "ARIN-prop-244: Clarification of Initial Block Size for IPv4 ISP Transfers" to Draft Policy status. Draft Policy ARIN-2017-9 is below and can be found at: https://www.arin.net/policy/proposals/2017_9.html You are encouraged to discuss all Draft Policies on PPML. The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet number resource policy as stated in the Policy Development Process (PDP). Specifically, these principles are: * Enabling Fair and Impartial Number Resource Administration * Technically Sound * Supported by the Community The PDP can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Sean Hopkins Policy Analyst American Registry for Internet Numbers (ARIN) Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers Problem Statement: It was noted at the ARIN 40 Policy Experience Report, that there is an inconsistency in the initial block size for ISPs. Section 4.2.2 notes that the initial ISP block size should be /21 whereas the initial block size in 8.5.4 is noted as "minimum transfer size" which is effectively a /24. The intent of the new 8.5.4 was to match the previous policy. This policy is intended to clarify this issue. It was noted that ARIN staff current operational practice is to allow ISPs an initial /21 for Section 8 transfers. Policy statement: Add the following to 8.5.4 ISP organizations without direct assignments or allocations from ARIN qualify for an initial allocation of up to a /21. Comments: a. Timetable for implementation: Immediate From info at arin.net Tue Nov 21 17:42:02 2017 From: info at arin.net (ARIN) Date: Tue, 21 Nov 2017 17:42:02 -0500 Subject: [arin-ppml] Draft Policy ARIN-2017-10: Repeal of Immediate Need for IPv4 Address Space (NRPM Section 4.2.1.6) Message-ID: <0ea280c3-adf7-1ee3-422f-5bd39b75a31c@arin.net> On 16 November 2017, the ARIN Advisory Council (AC) advanced "ARIN-prop-245: Repeal of Immediate Need for IPv4 Address Space (NRPM Section 4.2.1.6)" to Draft Policy status. Draft Policy ARIN-2017-10 is below and can be found at: https://www.arin.net/policy/proposals/2017_10.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-10: Repeal of Immediate Need for IPv4 Address Space (NRPM Section 4.2.1.6) Problem Statement: Section 4.2.1.6 of the ARIN Numbering Resource Policy Manual (NRPM) provides that an ISP having an immediate need for IPv4 address space that will be utilized within thirty days of a request may obtain a block of IPv4 address space of the size specified in section 4.2.1.6 from ARIN on an exceptional basis. However, as noted in the ARIN 40 Policy Experience Report, since IPv4 exhaustion, obtaining IPv4 addresses in this manner is no longer possible as a practical matter. Instead an ISP must join the waiting list and wait until it reaches the front of the queue to obtain any IPv4 address space, however long that may take. In effect, section 4.2.1.6 is non-operative. Accordingly, its continued presence in the NRPM is misleading and confusing. Policy statement: Section 4.2.1.6 of the NRPM is hereby repealed and section number 4.2.1.6 is hereby retired. Comments: a. Timetable for implementation: Immediate b. Comments: Given the constraints created by the exhaustion of IPv4 addresses, this proposal does not require any changes in the current ARIN practices for the allocation of IPv4 address space. From info at arin.net Tue Nov 21 17:43:05 2017 From: info at arin.net (ARIN) Date: Tue, 21 Nov 2017 17:43:05 -0500 Subject: [arin-ppml] Draft Policy ARIN-2017-11: Reallocation and Reassignment Language Cleanup Message-ID: <98d17d2f-c3f8-f395-77a2-6493f7d36452@arin.net> On 16 November 2017, the ARIN Advisory Council (AC) advanced "ARIN-prop-246: Reallocation and Reassignment Language Cleanup" to Draft Policy status. Draft Policy ARIN-2017-11 is below and can be found at: https://www.arin.net/policy/proposals/2017_11.html You are encouraged to discuss all Draft Policies on PPML. The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet number resource policy as stated in the Policy Development Process (PDP). Specifically, these principles are: * Enabling Fair and Impartial Number Resource Administration * Technically Sound * Supported by the Community The PDP can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Sean Hopkins Policy Analyst American Registry for Internet Numbers (ARIN) Draft Policy ARIN-2017-11: Reallocation and Reassignment Language Cleanup Problem Statement: The current text of NRPM uses the terms ?reallocate? and ?reassign? in ways that are both internally inconsistent within NRPM and inconsistent with the definitions of Reassignments and Reallocations as fields within the ARIN database. Frequently the term ?reassignment? or ?reassign? is used in NRPM as an umbrella term for both reallocations and reassignments. As a result, someone familiar with the ARIN Whois database, but unfamiliar with history of particular portions of NRPM and their intended meaning may interpret certain NRPM requirements as applying only to reassignments and not to reallocations. This is particularly problematic when it comes to SWIP requirements and the requirement to record reallocations and reassignments with ARIN, which under current text could be read to only apply to reassignments. Policy Statement: Make the following changes to the definitions in Section 2.5 Current text: 2.5. Allocate and Assign A distinction is made between address allocation and address assignment, i.e., ISPs are "allocated" address space as described herein, while end-users are "assigned" address space. Allocate - To allocate means to distribute address space to IRs for the purpose of subsequent distribution by them. Assign - To assign means to delegate address space to an ISP or end-user, for specific use within the Internet infrastructure they operate. Assignments must only be made for specific purposes documented by specific organizations and are not to be sub-assigned to other parties. Proposed Editorial Change: 2.5 Allocation, Assignment, Reallocation, Reassignment Allocation - Address space delegated to an organization directly by ARIN for the purpose of subsequent distribution by the recipient organization to other parties. Assignment - Address space delegated to an organization directly by ARIN for the exclusive use of the recipient organization. Reallocation - Address space sub-delegated to an organization by an upstream provider for the purpose of subsequent distribution by the recipient organization to other parties. Reassignment - Address space sub-delegated to an organization by an upstream provider for the exclusive use of the recipient organization. Make the following editorial changes to section 4.2: Current text: 4.2.1.1. Purpose ARIN allocates blocks of IP addresses to ISPs for the purpose of reassigning that space to their customers. Proposed Editorial Change: 4.2.1.1. Purpose ARIN allocates blocks of IP addresses to ISPs for the purpose of reassigning and reallocating that space to their customers. Current text: 4.2.3. Reassigning Address Space to Customers Proposed Editorial Change: 4.2.3. Reassigning and Reallocating Address Space to Customers Current Text: 4.2.3.1. Efficient utilization ISPs are required to apply a utilization efficiency criterion in providing address space to their customers. To this end, ISPs should have documented justification available for each reassignment. ARIN may request this justification at any time. If justification is not provided, future receipt of allocations may be impacted. Proposed Editorial Change: 4.2.3.1. Efficient utilization ISPs are required to apply a utilization efficiency criterion in providing address space to their customers. To this end, ISPs should have documented justification available for each reassignment and reallocation. ARIN may request this justification at any time. If justification is not provided, future receipt of allocations may be impacted. Current text: 4.2.3.4. Downstream customer adherence ISPs must require their downstream customers to adhere to the following criteria: 4.2.3.4.1. Utilization Reassignment information for prior allocations must show that each customer meets the 80% utilization criteria and must be available via SWIP / RWhois prior to your issuing them additional space. Proposed Editorial Changes: 4.2.3.4. Downstream customer adherence ISPs must require their downstream customers to adhere to the following criteria: 4.2.3.4.1. Utilization Reassignment and reallocation information for prior allocations must show that each customer meets the 80% utilization criteria and must be available via SWIP / RWhois prior to your issuing them additional space. Current text: 4.2.3.5. ARIN approval of reassignments/reallocations 4.2.3.5.1. /18 All extra-large ISPs making reassignments of a /18 or larger to a customer must first have these reassignments reviewed and approved by ARIN. 4.2.3.5.2. /19 Small to large ISPs making customer reassignments of a /19 or larger must first seek ARIN's approval. Proposed Editorial Changes: 4.2.3.5. ARIN approval of reassignments/reallocations 4.2.3.5.1. /18 All extra-large ISPs making reassignments or reallocations of a /18 or larger to a customer must first have these reassignments or reallocations reviewed and approved by ARIN. 4.2.3.5.2. /19 Small to large ISPs making customer reassignments or reallocations of a /19 or larger must first seek ARIN's approval. Current text: 4.2.3.7.1. Reassignment Information Each IPv4 assignment containing a /29 or more addresses shall be registered in the WHOIS directory via SWIP or a distributed service which meets the standards set forth in section 3.2. Reassignment registrations shall include each client's organizational information, except where specifically exempted by this policy. Proposed Editorial Changes: 4.2.3.7.1. Reassignment and Reallocation Information Each IPv4 reassignment or reallocation containing a /29 or more addresses shall be registered in the WHOIS directory via SWIP or a distributed service which meets the standards set forth in section 3.2. Reassignment and reallocation registrations shall include each client's organizational information, except where specifically exempted by this policy. Current text: 4.2.3.7.2.Assignments visible within 7 days All assignments shall be made visible as required in section 4.2.3.7.1 within seven calendar days of assignment. Proposed Editorial Changes: 4.2.3.7.2.Reassignments and Reallocations visible within 7 days All reassignments and reallocations shall be made visible as required in section 4.2.3.7.1 within seven calendar days of reassignment or reallocation. Current text: 4.2.4. ISP Additional Requests 4.2.4.1. Utilization percentage (80%) ISPs must have efficiently utilized all allocations, in aggregate, to at least 80% and at least 50% of every allocation in order to receive additional space. This includes all space reassigned to their customers. Proposed Editorial Changes: 4.2.4. ISP Additional Requests 4.2.4.1. Utilization percentage (80%) ISPs must have efficiently utilized all allocations, in aggregate, to at least 80% and at least 50% of every allocation in order to receive additional space. This includes all space reassigned or reallocated to their customers. Make the following editorial changes to section 6 to clarify language regarding current practices and requirements for reallocations and reassignments, and specifically to clarify that recording reallocation information is required where current language is ambiguous: Current text: 6.5.2.1(e) Initial Allocations to LIRs, Size For purposes of the calculation in (c), an LIR which has subordinate LIRs shall make such allocations according to the same policies and criteria as ARIN. In such a case, the prefixes necessary for such an allocation should be treated as fully utilized in determining the block sizing for the parent LIR. LIRs which do not receive resources directly from ARIN will not be able to make such allocations to subordinate LIRs and subordinate LIRs which need more than a /32 shall apply directly to ARIN. Proposed Editorial Changes: 6.5.2.1(e) Initial Allocations to LIRs, Size For purposes of the calculation in (c), an LIR which has subordinate LIRs shall make such reallocations according to the same policies and criteria as ARIN. In such a case, the prefixes necessary for such a reallocation should be treated as fully utilized in determining the block sizing for the parent LIR. LIRs which do not receive resources directly from ARIN will not be able to make such reallocations to subordinate LIRs and subordinate LIRs which need more than a /32 shall apply directly to ARIN. Current text: 6.5.2.2. Qualifications An organization qualifies for an allocation under this policy if they meet any of the following criteria: a. Have a previously justified IPv4 ISP allocation from ARIN or one of its predecessor registries or can qualify for an IPv4 ISP allocation under current criteria. b. Are currently multihomed for IPv6 or will immediately become multihomed for IPv6 using a valid assigned global AS number. In either case, they will be making reassignments from allocation(s) under this policy to other organizations. Provide ARIN a reasonable technical justification indicating why an allocation is necessary. Justification must include the intended purposes for the allocation and describe the network infrastructure the allocation will be used to support. Justification must also include a plan detailing anticipated assignments to other organizations or customers for one, two and five year periods, with a minimum of 50 assignments within 5 years. Proposed Editorial Changes: 6.5.2.2. Qualifications An organization qualifies for an allocation under this policy if they meet any of the following criteria: a. Have a previously justified IPv4 ISP allocation from ARIN or one of its predecessor registries or can qualify for an IPv4 ISP allocation under current criteria. b. Are currently multihomed for IPv6 or will immediately become multihomed for IPv6 using a valid assigned global AS number. In either case, they will be making reassignments or reallocations from allocation(s) under this policy to other organizations. Provide ARIN a reasonable technical justification indicating why an allocation is necessary. Justification must include the intended purposes for the allocation and describe the network infrastructure the allocation will be used to support. Justification must also include a plan detailing anticipated reassignments and reallocations to other organizations or customers for one, two and five year periods, with a minimum of 50 assignments within 5 years. Current text: 6.5.4. Assignments from LIRs/ISPs Assignments to end users shall be governed by the same practices adopted by the community in section 6.5.8 except that the requirements in 6.5.8.1 do not apply. Proposed Editorial Changes: 6.5.4. Reassignments from LIRs/ISPs Reassignments to end users shall be governed by the same practices adopted by the community in section 6.5.8 except that the requirements in 6.5.8.1 do not apply. Current text: 6.5.4.1. Assignment to operator's infrastructure An LIR may assign up to a /48 per PoP as well as up to an additional /48 globally for its own infrastructure. Proposed Editorial Changes: 6.5.4.1. Reassignment to operator's infrastructure An LIR may reassign up to a /48 per PoP as well as up to an additional /48 globally for its own infrastructure. Current text: 6.5.5. Registration ISPs are required to demonstrate efficient use of IP address space allocations by providing appropriate documentation, including but not limited to assignment histories, showing their efficient use. Proposed Editorial Changes: 6.5.5. Registration ISPs are required to demonstrate efficient use of IP address space allocations by providing appropriate documentation, including but not limited to reassignment and reallocation histories, showing their efficient use. Current text: 6.5.5.1. Reassignment information Each static IPv6 assignment containing a /64 or more addresses shall be registered in the WHOIS directory via SWIP or a distributed service which meets the standards set forth in section 3.2. Reassignment registrations shall include each client's organizational information, except where specifically exempted by this policy. Proposed Editorial Changes: 6.5.5.1. Reassignment information Each static IPv6 reassignment or reallocation containing a /64 or more addresses shall be registered in the WHOIS directory via SWIP or a distributed service which meets the standards set forth in section 3.2. Reassignment and reallocation registrations shall include each client's organizational information, except where specifically exempted by this policy. Current text: 6.5.5.2. Assignments visible within 7 days All assignments shall be made visible as required in section 4.2.3.7.1 within seven calendar days of assignment Proposed Editorial Changes: 6.5.5.2. Reassignments and Reallocations visible within 7 days All reassignments and reallocations shall be made visible as required in section 4.2.3.7.1 within seven calendar days of reassignment or reallocation. From info at arin.net Tue Nov 21 17:43:39 2017 From: info at arin.net (ARIN) Date: Tue, 21 Nov 2017 17:43:39 -0500 Subject: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment Message-ID: On 16 November 2017, the ARIN Advisory Council (AC) advanced "ARIN-prop-247: Require New POC Validation Upon Reassignment" to Draft Policy status. Draft Policy ARIN-2017-12 is below and can be found at: https://www.arin.net/policy/proposals/2017_12.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-12: Require New POC Validation Upon Reassignment Problem Statement: Some large ISPs assign individuals to be POCs for reassigned blocks without consultation of the individual they are inserting into Whois. One year later, the POC is contacted by ARIN as part of Annual POC Validation policies. The POC often does not know who ARIN is, what Whois is, and why they are in Whois. This policy proposal seeks to improve the situation where a POC is unwittingly and unwantingly inserted into Whois. It also seeks to mitigate the significant amount of time that ARIN staff reports that they spend fielding phone calls from POCs who have no idea they are in Whois. Finally, it is hopeful that this proposal will improve the overall POC validation situation, by forcing ISPs and customers to work together to insert proper information into Whois at the time of sub-delegation. Policy statement: Insert two new sections into NRPM 3: 3.7 New POC Validation Upon Reassignment When an ISP submits a valid reallocation or detailed reassignment request to ARIN which would result in a new POC object being created, ARIN must (before otherwise approving the request) contact the new POC by email for validation. ARIN's notification will, at a minimum, notify the POC of: - the information about the organization submitting the record; and - the resource(s) to which the POC is being attached; and - the organization(s) to which the POC is being attached. If the POC validates the request, the request shall be accepted by ARIN and the new objects inserted into Whois. If the POC does not validate the request within 10 days, ARIN must reject the request. 3.8 Downstream Validation of Simple Reassignments When an ISP submits a valid simple reassigment request to ARIN with an organization name OR postal address that is identical to one or more existing OrgIDs, ARIN will notify the downstream organization and obtain guidance on whether to accept the simple reassigment, or redirect it to one of the existing OrgIDs as a detailed reassignment. Comments: Timetable for implementation: Immediate From info at arin.net Tue Nov 21 17:44:21 2017 From: info at arin.net (ARIN) Date: Tue, 21 Nov 2017 17:44:21 -0500 Subject: [arin-ppml] Draft Policy ARIN-2017-13: Remove ARIN Review Requirements for Large, IPv4 Reassignments/Reallocations Message-ID: <88404d28-06a3-504c-547a-3eb742b2f11f@arin.net> On 16 November 2017 the ARIN Advisory Council (AC) advanced "ARIN-prop-248: Remove ARIN Review Requirements for Large IPv4 Reassignments/Reallocations" to Draft Policy status. Draft Policy ARIN-2017-13 is below and can be found at: https://www.arin.net/policy/proposals/2017_13.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-13: Remove ARIN Review Requirements for Large IPv4 Reassignments/Reallocations Problem Statement: ARIN review of large IPv4 reassignments or rellocations was put in place when ARIN had a free pool of IPv4 addresses. The main purpose of the review was to ensure that ISPs were following RFC2050 and ARIN policy for large blocks. Since there is no longer a free pool and blocks have a value through transfer, there is now a disincentive for ISPs to over assign blocks to downstream customers. Thus this policy is no longer needed. Policy statement: Remove Section 4.2.3.5 of NRPM Comments: Timetable for implementation: Immediate From scottleibrand at gmail.com Tue Nov 21 17:52:52 2017 From: scottleibrand at gmail.com (Scott Leibrand) Date: Tue, 21 Nov 2017 14:52:52 -0800 Subject: [arin-ppml] Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers In-Reply-To: <652abd11-68d7-900e-7776-b97b2311ea05@arin.net> References: <652abd11-68d7-900e-7776-b97b2311ea05@arin.net> Message-ID: I believe this problem statement is incorrect, and therefore oppose the policy proposal as-is. 8.5.4 was intended (by me, as one of the authors, and in PPML discussions I just pulled up) to allow ISPs to transfer a /24 without justification. It was *not* intended to "match the previous policy" in 4.2.2. 8.5.5 reads "8.5.5. Block size Organizations may qualify for the transfer of a larger initial block, or an additional block, by providing documentation to ARIN which details the use of at least 50% of the requested IPv4 block size within 24 months. An officer of the organization shall attest to the documentation provided to ARIN." The intention was that any ISP needing a /21 would need to "provide documentation to ARIN which details the use of at least 50% of the requested IPv4 block size within 24 months", with officer attestation to same. If that policy is deemed insufficient, and we believe it's better to allow transfers of up to /21 without providing documentation to ARIN and officer attestation of such, then this proposal would need to be re-written with a new problem statement justifying that. -Scott On Tue, Nov 21, 2017 at 2:40 PM, ARIN wrote: > On 16 November 2017, the ARIN Advisory Council (AC) advanced > "ARIN-prop-244: Clarification of Initial Block Size for IPv4 ISP Transfers" > to Draft Policy status. > > Draft Policy ARIN-2017-9 is below and can be found at: > https://www.arin.net/policy/proposals/2017_9.html > > You are encouraged to discuss all Draft Policies on PPML. The AC will > evaluate the discussion in order to assess the conformance of this draft > policy with ARIN's Principles of Internet number resource policy as stated > in the Policy Development Process (PDP). Specifically, these principles are: > > * Enabling Fair and Impartial Number Resource Administration > * Technically Sound > * Supported by the Community > > The PDP can be found at: > https://www.arin.net/policy/pdp.html > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > Regards, > > Sean Hopkins > Policy Analyst > American Registry for Internet Numbers (ARIN) > > > > Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP > Transfers > > Problem Statement: > > It was noted at the ARIN 40 Policy Experience Report, that there is an > inconsistency in the initial block size for ISPs. Section 4.2.2 notes that > the initial ISP block size should be /21 whereas the initial block size in > 8.5.4 is noted as "minimum transfer size" which is effectively a /24. The > intent of the new 8.5.4 was to match the previous policy. This policy is > intended to clarify this issue. It was noted that ARIN staff current > operational practice is to allow ISPs an initial /21 for Section 8 > transfers. > > Policy statement: > > Add the following to 8.5.4 > > ISP organizations without direct assignments or allocations from ARIN > qualify for an initial allocation of up to a /21. > > Comments: > > a. Timetable for implementation: Immediate > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From scottleibrand at gmail.com Tue Nov 21 17:53:52 2017 From: scottleibrand at gmail.com (Scott Leibrand) Date: Tue, 21 Nov 2017 14:53:52 -0800 Subject: [arin-ppml] Draft Policy ARIN-2017-10: Repeal of Immediate Need for IPv4 Address Space (NRPM Section 4.2.1.6) In-Reply-To: <0ea280c3-adf7-1ee3-422f-5bd39b75a31c@arin.net> References: <0ea280c3-adf7-1ee3-422f-5bd39b75a31c@arin.net> Message-ID: +1 - support as written. On Tue, Nov 21, 2017 at 2:42 PM, ARIN wrote: > On 16 November 2017, the ARIN Advisory Council (AC) advanced > "ARIN-prop-245: Repeal of Immediate Need for IPv4 Address Space (NRPM > Section 4.2.1.6)" to Draft Policy status. > > Draft Policy ARIN-2017-10 is below and can be found at: > https://www.arin.net/policy/proposals/2017_10.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-10: Repeal of Immediate Need for IPv4 Address Space > (NRPM Section 4.2.1.6) > > Problem Statement: > > Section 4.2.1.6 of the ARIN Numbering Resource Policy Manual (NRPM) > provides that an ISP having an immediate need for IPv4 address space that > will be utilized within thirty days of a request may obtain a block of IPv4 > address space of the size specified in section 4.2.1.6 from ARIN on an > exceptional basis. However, as noted in the ARIN 40 Policy Experience > Report, since IPv4 exhaustion, obtaining IPv4 addresses in this manner is > no longer possible as a practical matter. Instead an ISP must join the > waiting list and wait until it reaches the front of the queue to obtain any > IPv4 address space, however long that may take. In effect, section 4.2.1.6 > is non-operative. Accordingly, its continued presence in the NRPM is > misleading and confusing. > > Policy statement: > > Section 4.2.1.6 of the NRPM is hereby repealed and section number 4.2.1.6 > is hereby retired. > > Comments: > > a. Timetable for implementation: Immediate > > b. Comments: Given the constraints created by the exhaustion of IPv4 > addresses, this proposal does not require any changes in the current ARIN > practices for the allocation of IPv4 address space. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage 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 Tue Nov 21 18:04:19 2017 From: scottleibrand at gmail.com (Scott Leibrand) Date: Tue, 21 Nov 2017 15:04:19 -0800 Subject: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment In-Reply-To: References: Message-ID: +1 - I support the general idea here, and would be fine with this text as-is. I suspect others will have feedback on the exact mechanisms prescribed here, so I'm expressing no prior opinion on any changes there. -Scott On Tue, Nov 21, 2017 at 2:43 PM, ARIN wrote: > On 16 November 2017, the ARIN Advisory Council (AC) advanced > "ARIN-prop-247: Require New POC Validation Upon Reassignment" to Draft > Policy status. > > Draft Policy ARIN-2017-12 is below and can be found at: > https://www.arin.net/policy/proposals/2017_12.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-12: Require New POC Validation Upon Reassignment > > Problem Statement: > > Some large ISPs assign individuals to be POCs for reassigned blocks > without consultation of the individual they are inserting into Whois. One > year later, the POC is contacted by ARIN as part of Annual POC Validation > policies. The POC often does not know who ARIN is, what Whois is, and why > they are in Whois. > > This policy proposal seeks to improve the situation where a POC is > unwittingly and unwantingly inserted into Whois. > > It also seeks to mitigate the significant amount of time that ARIN staff > reports that they spend fielding phone calls from POCs who have no idea > they are in Whois. > > Finally, it is hopeful that this proposal will improve the overall POC > validation situation, by forcing ISPs and customers to work together to > insert proper information into Whois at the time of sub-delegation. > > Policy statement: > > Insert two new sections into NRPM 3: > > 3.7 New POC Validation Upon Reassignment > > When an ISP submits a valid reallocation or detailed reassignment request > to ARIN which would result in a new POC object being created, ARIN must > (before otherwise approving the request) contact the new POC by email for > validation. ARIN's notification will, at a minimum, notify the POC of: > > - the information about the organization submitting the record; and > - the resource(s) to which the POC is being attached; and > - the organization(s) to which the POC is being attached. > > If the POC validates the request, the request shall be accepted by ARIN > and the new objects inserted into Whois. If the POC does not validate the > request within 10 days, ARIN must reject the request. > > 3.8 Downstream Validation of Simple Reassignments > > When an ISP submits a valid simple reassigment request to ARIN with an > organization name OR postal address that is identical to one or more > existing OrgIDs, ARIN will notify the downstream organization and obtain > guidance on whether to accept the simple reassigment, or redirect it to one > of the existing OrgIDs as a detailed reassignment. > > 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 scottleibrand at gmail.com Tue Nov 21 18:05:40 2017 From: scottleibrand at gmail.com (Scott Leibrand) Date: Tue, 21 Nov 2017 15:05:40 -0800 Subject: [arin-ppml] Draft Policy ARIN-2017-13: Remove ARIN Review Requirements for Large, IPv4 Reassignments/Reallocations In-Reply-To: <88404d28-06a3-504c-547a-3eb742b2f11f@arin.net> References: <88404d28-06a3-504c-547a-3eb742b2f11f@arin.net> Message-ID: +1 - Support Do we have any statistics on the last time 4.2.3.5 was invoked and/or frequently it was invoked? I suspect it's been awhile... -Scott On Tue, Nov 21, 2017 at 2:44 PM, ARIN wrote: > On 16 November 2017 the ARIN Advisory Council (AC) advanced > "ARIN-prop-248: Remove ARIN Review Requirements for Large IPv4 > Reassignments/Reallocations" to Draft Policy status. > > Draft Policy ARIN-2017-13 is below and can be found at: > https://www.arin.net/policy/proposals/2017_13.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-13: Remove ARIN Review Requirements for Large > IPv4 Reassignments/Reallocations > > Problem Statement: > > ARIN review of large IPv4 reassignments or rellocations was put in place > when ARIN had a free pool of IPv4 addresses. The main purpose of the review > was to ensure that ISPs were following RFC2050 and ARIN policy for large > blocks. Since there is no longer a free pool and blocks have a value > through transfer, there is now a disincentive for ISPs to over assign > blocks to downstream customers. Thus this policy is no longer needed. > > Policy statement: > > Remove Section 4.2.3.5 of NRPM > > 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 daveid at panix.com Tue Nov 21 18:13:46 2017 From: daveid at panix.com (David Huberman) Date: Tue, 21 Nov 2017 18:13:46 -0500 Subject: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment In-Reply-To: References: Message-ID: Thank you Scott. As the co-author, I very much recognize this proposal text is a ?first draft?. Working with my co-author Jason Schiller, and having solicited feedback from the AC, this proposal was submitted to solve the general problem. My hope was the mechanics would be looked at critically by the community during the PDP, and we would work together to improve them. Regards David Huberman > On Nov 21, 2017, at 6:04 PM, Scott Leibrand wrote: > > +1 - I support the general idea here, and would be fine with this text as-is. > > I suspect others will have feedback on the exact mechanisms prescribed here, so I'm expressing no prior opinion on any changes there. > > -Scott > >> On Tue, Nov 21, 2017 at 2:43 PM, ARIN wrote: >> On 16 November 2017, the ARIN Advisory Council (AC) advanced "ARIN-prop-247: Require New POC Validation Upon Reassignment" to Draft Policy status. >> >> Draft Policy ARIN-2017-12 is below and can be found at: >> https://www.arin.net/policy/proposals/2017_12.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-12: Require New POC Validation Upon Reassignment >> >> Problem Statement: >> >> Some large ISPs assign individuals to be POCs for reassigned blocks without consultation of the individual they are inserting into Whois. One year later, the POC is contacted by ARIN as part of Annual POC Validation policies. The POC often does not know who ARIN is, what Whois is, and why they are in Whois. >> >> This policy proposal seeks to improve the situation where a POC is unwittingly and unwantingly inserted into Whois. >> >> It also seeks to mitigate the significant amount of time that ARIN staff reports that they spend fielding phone calls from POCs who have no idea they are in Whois. >> >> Finally, it is hopeful that this proposal will improve the overall POC validation situation, by forcing ISPs and customers to work together to insert proper information into Whois at the time of sub-delegation. >> >> Policy statement: >> >> Insert two new sections into NRPM 3: >> >> 3.7 New POC Validation Upon Reassignment >> >> When an ISP submits a valid reallocation or detailed reassignment request to ARIN which would result in a new POC object being created, ARIN must (before otherwise approving the request) contact the new POC by email for validation. ARIN's notification will, at a minimum, notify the POC of: >> >> - the information about the organization submitting the record; and >> - the resource(s) to which the POC is being attached; and >> - the organization(s) to which the POC is being attached. >> >> If the POC validates the request, the request shall be accepted by ARIN and the new objects inserted into Whois. If the POC does not validate the request within 10 days, ARIN must reject the request. >> >> 3.8 Downstream Validation of Simple Reassignments >> >> When an ISP submits a valid simple reassigment request to ARIN with an organization name OR postal address that is identical to one or more existing OrgIDs, ARIN will notify the downstream organization and obtain guidance on whether to accept the simple reassigment, or redirect it to one of the existing OrgIDs as a detailed reassignment. >> >> 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 rudi.daniel at gmail.com Tue Nov 21 18:29:38 2017 From: rudi.daniel at gmail.com (Rudolph Daniel) Date: Tue, 21 Nov 2017 19:29:38 -0400 Subject: [arin-ppml] Draft Policy 2017-4 Post ARIN 40 In-Reply-To: References: Message-ID: I support the motion as written. RD On 21 Nov 2017 18:43, 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: Post-ARIN-40 updates to 2017-4 (Mike Burns) 2. Advisory Council Meeting Results - November 2017 (ARIN) 3. Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers (ARIN) 4. Draft Policy ARIN-2017-10: Repeal of Immediate Need for IPv4 Address Space (NRPM Section 4.2.1.6) (ARIN) 5. Draft Policy ARIN-2017-11: Reallocation and Reassignment Language Cleanup (ARIN) ---------------------------------------------------------------------- Message: 1 Date: Fri, 17 Nov 2017 10:43:46 -0500 From: "Mike Burns" To: "'David Farmer'" , "'Rob Seastrom'" Cc: Subject: Re: [arin-ppml] Post-ARIN-40 updates to 2017-4 Message-ID: <004a01d35fba$db358570$91a09050$@iptrading.com> Content-Type: text/plain; charset="utf-8" I support as written for the reasons David describes. From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of David Farmer Sent: Friday, November 17, 2017 10:27 AM To: Rob Seastrom Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Post-ARIN-40 updates to 2017-4 I support this policy as written. The current reciprocity requirement does not recognize that the vast majority of IPv4 transfers are out of the ARIN region and the vast majority of the supply of IPv4 resources available for transfer exist within the ARIN region. Finally there are legitimate operational reasons that companies within the ARIN region need to transfer resources to themselves or their foreign subsidiaries in other regions regardless of reciprocal transfer policies being available. Thank you for simplifying the text. On Fri, Nov 17, 2017 at 7:12 AM, Rob Seastrom > wrote: Dear Colleagues, Based on feedback received at the ARIN-40 conference, the AC Shepherds have updated Draft Policy 2017-4 - "Remove bidirectional requirement for inter-RIR transfers". The proposal in its entirety is below. We seek feedback and comment. 2017-4 - Remove bidirectional requirement for inter-RIR transfers Problem Statement: ARIN?s inter-RIR transfer policy is functionally one-way, so the assertion of a reciprocal two-way requirement is gratuitous. Policy statement: Add the following sentence after the first sentence of NRPM 8.4: Inter-RIR transfers may take place only via RIRs who agree to the transfer and share compatible, needs-based policies. 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. -- =============================================== 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: ------------------------------ Message: 2 Date: Tue, 21 Nov 2017 17:37:31 -0500 From: ARIN To: arin-ppml at arin.net Subject: [arin-ppml] Advisory Council Meeting Results - November 2017 Message-ID: <90ca93ea-ba77-0fc6-538d-c788ce02590f at arin.net> Content-Type: text/plain; charset=utf-8; format=flowed In accordance with the Policy Development Process (PDP), the Advisory Council (AC) met on 16 November 2017. The AC has advanced the following Proposals to Draft Policy status (each will be posted for discussion): * ARIN-prop-244: Clarification of initial block size for IPv4 ISP transfers * ARIN-prop-245: Repeal of Immediate Need for IPv4 Address Space (NRPM Section 4.2.1.6) * ARIN-prop-246: Reallocation and Reassignment Language Cleanup * ARIN-prop-247: Require New POC Validation Upon Reassignment * ARIN-prop-248: Remove ARIN Review Requirements for Large IPv4 Reassignments/Reallocations The AC advances Proposals to Draft Policy status once they are found to be within the scope of the PDP, and contain a clear problem statement and suggested changes to Internet number resource policy text. The AC has sent the following to the Board of Trustees for adoption consideration: * Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements The AC provided the following statement: "After a successful conclusion of the Last Call period, the ARIN AC is forwarding Recommended Draft Policy ARIN-2017-5: Improved IPv6 Registration Requirements to the ARIN Board with a request for adoption. Based on the consensus of the community at ARIN 40, the policy text was adjusted going into Last Call. While a minority dissent during Last Call period was in favor of the original text, the AC is of the view that the community thoroughly discussed that matter both at ARIN 40 and on PPML, and the consensus of the community supports the change in the text." The AC is continuing to work on: * ARIN-2017-3: Update to NPRM 3.6: Annual Whois POC Validation * ARIN-2017-4: Remove Bidirectional Requirement for Inter-RIR Transfers * ARIN-2017-8: Amend the Definition of Community Network 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) ------------------------------ Message: 3 Date: Tue, 21 Nov 2017 17:40:39 -0500 From: ARIN To: arin-ppml at arin.net Subject: [arin-ppml] Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers Message-ID: <652abd11-68d7-900e-7776-b97b2311ea05 at arin.net> Content-Type: text/plain; charset=utf-8; format=flowed On 16 November 2017, the ARIN Advisory Council (AC) advanced "ARIN-prop-244: Clarification of Initial Block Size for IPv4 ISP Transfers" to Draft Policy status. Draft Policy ARIN-2017-9 is below and can be found at: https://www.arin.net/policy/proposals/2017_9.html You are encouraged to discuss all Draft Policies on PPML. The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet number resource policy as stated in the Policy Development Process (PDP). Specifically, these principles are: * Enabling Fair and Impartial Number Resource Administration * Technically Sound * Supported by the Community The PDP can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Sean Hopkins Policy Analyst American Registry for Internet Numbers (ARIN) Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers Problem Statement: It was noted at the ARIN 40 Policy Experience Report, that there is an inconsistency in the initial block size for ISPs. Section 4.2.2 notes that the initial ISP block size should be /21 whereas the initial block size in 8.5.4 is noted as "minimum transfer size" which is effectively a /24. The intent of the new 8.5.4 was to match the previous policy. This policy is intended to clarify this issue. It was noted that ARIN staff current operational practice is to allow ISPs an initial /21 for Section 8 transfers. Policy statement: Add the following to 8.5.4 ISP organizations without direct assignments or allocations from ARIN qualify for an initial allocation of up to a /21. Comments: a. Timetable for implementation: Immediate ------------------------------ Message: 4 Date: Tue, 21 Nov 2017 17:42:02 -0500 From: ARIN To: arin-ppml at arin.net Subject: [arin-ppml] Draft Policy ARIN-2017-10: Repeal of Immediate Need for IPv4 Address Space (NRPM Section 4.2.1.6) Message-ID: <0ea280c3-adf7-1ee3-422f-5bd39b75a31c at arin.net> Content-Type: text/plain; charset=utf-8; format=flowed On 16 November 2017, the ARIN Advisory Council (AC) advanced "ARIN-prop-245: Repeal of Immediate Need for IPv4 Address Space (NRPM Section 4.2.1.6)" to Draft Policy status. Draft Policy ARIN-2017-10 is below and can be found at: https://www.arin.net/policy/proposals/2017_10.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-10: Repeal of Immediate Need for IPv4 Address Space (NRPM Section 4.2.1.6) Problem Statement: Section 4.2.1.6 of the ARIN Numbering Resource Policy Manual (NRPM) provides that an ISP having an immediate need for IPv4 address space that will be utilized within thirty days of a request may obtain a block of IPv4 address space of the size specified in section 4.2.1.6 from ARIN on an exceptional basis. However, as noted in the ARIN 40 Policy Experience Report, since IPv4 exhaustion, obtaining IPv4 addresses in this manner is no longer possible as a practical matter. Instead an ISP must join the waiting list and wait until it reaches the front of the queue to obtain any IPv4 address space, however long that may take. In effect, section 4.2.1.6 is non-operative. Accordingly, its continued presence in the NRPM is misleading and confusing. Policy statement: Section 4.2.1.6 of the NRPM is hereby repealed and section number 4.2.1.6 is hereby retired. Comments: a. Timetable for implementation: Immediate b. Comments: Given the constraints created by the exhaustion of IPv4 addresses, this proposal does not require any changes in the current ARIN practices for the allocation of IPv4 address space. ------------------------------ Message: 5 Date: Tue, 21 Nov 2017 17:43:05 -0500 From: ARIN To: arin-ppml at arin.net Subject: [arin-ppml] Draft Policy ARIN-2017-11: Reallocation and Reassignment Language Cleanup Message-ID: <98d17d2f-c3f8-f395-77a2-6493f7d36452 at arin.net> Content-Type: text/plain; charset=utf-8; format=flowed On 16 November 2017, the ARIN Advisory Council (AC) advanced "ARIN-prop-246: Reallocation and Reassignment Language Cleanup" to Draft Policy status. Draft Policy ARIN-2017-11 is below and can be found at: https://www.arin.net/policy/proposals/2017_11.html You are encouraged to discuss all Draft Policies on PPML. The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet number resource policy as stated in the Policy Development Process (PDP). Specifically, these principles are: * Enabling Fair and Impartial Number Resource Administration * Technically Sound * Supported by the Community The PDP can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Sean Hopkins Policy Analyst American Registry for Internet Numbers (ARIN) Draft Policy ARIN-2017-11: Reallocation and Reassignment Language Cleanup Problem Statement: The current text of NRPM uses the terms ?reallocate? and ?reassign? in ways that are both internally inconsistent within NRPM and inconsistent with the definitions of Reassignments and Reallocations as fields within the ARIN database. Frequently the term ?reassignment? or ?reassign? is used in NRPM as an umbrella term for both reallocations and reassignments. As a result, someone familiar with the ARIN Whois database, but unfamiliar with history of particular portions of NRPM and their intended meaning may interpret certain NRPM requirements as applying only to reassignments and not to reallocations. This is particularly problematic when it comes to SWIP requirements and the requirement to record reallocations and reassignments with ARIN, which under current text could be read to only apply to reassignments. Policy Statement: Make the following changes to the definitions in Section 2.5 Current text: 2.5. Allocate and Assign A distinction is made between address allocation and address assignment, i.e., ISPs are "allocated" address space as described herein, while end-users are "assigned" address space. Allocate - To allocate means to distribute address space to IRs for the purpose of subsequent distribution by them. Assign - To assign means to delegate address space to an ISP or end-user, for specific use within the Internet infrastructure they operate. Assignments must only be made for specific purposes documented by specific organizations and are not to be sub-assigned to other parties. Proposed Editorial Change: 2.5 Allocation, Assignment, Reallocation, Reassignment Allocation - Address space delegated to an organization directly by ARIN for the purpose of subsequent distribution by the recipient organization to other parties. Assignment - Address space delegated to an organization directly by ARIN for the exclusive use of the recipient organization. Reallocation - Address space sub-delegated to an organization by an upstream provider for the purpose of subsequent distribution by the recipient organization to other parties. Reassignment - Address space sub-delegated to an organization by an upstream provider for the exclusive use of the recipient organization. Make the following editorial changes to section 4.2: Current text: 4.2.1.1. Purpose ARIN allocates blocks of IP addresses to ISPs for the purpose of reassigning that space to their customers. Proposed Editorial Change: 4.2.1.1. Purpose ARIN allocates blocks of IP addresses to ISPs for the purpose of reassigning and reallocating that space to their customers. Current text: 4.2.3. Reassigning Address Space to Customers Proposed Editorial Change: 4.2.3. Reassigning and Reallocating Address Space to Customers Current Text: 4.2.3.1. Efficient utilization ISPs are required to apply a utilization efficiency criterion in providing address space to their customers. To this end, ISPs should have documented justification available for each reassignment. ARIN may request this justification at any time. If justification is not provided, future receipt of allocations may be impacted. Proposed Editorial Change: 4.2.3.1. Efficient utilization ISPs are required to apply a utilization efficiency criterion in providing address space to their customers. To this end, ISPs should have documented justification available for each reassignment and reallocation. ARIN may request this justification at any time. If justification is not provided, future receipt of allocations may be impacted. Current text: 4.2.3.4. Downstream customer adherence ISPs must require their downstream customers to adhere to the following criteria: 4.2.3.4.1. Utilization Reassignment information for prior allocations must show that each customer meets the 80% utilization criteria and must be available via SWIP / RWhois prior to your issuing them additional space. Proposed Editorial Changes: 4.2.3.4. Downstream customer adherence ISPs must require their downstream customers to adhere to the following criteria: 4.2.3.4.1. Utilization Reassignment and reallocation information for prior allocations must show that each customer meets the 80% utilization criteria and must be available via SWIP / RWhois prior to your issuing them additional space. Current text: 4.2.3.5. ARIN approval of reassignments/reallocations 4.2.3.5.1. /18 All extra-large ISPs making reassignments of a /18 or larger to a customer must first have these reassignments reviewed and approved by ARIN. 4.2.3.5.2. /19 Small to large ISPs making customer reassignments of a /19 or larger must first seek ARIN's approval. Proposed Editorial Changes: 4.2.3.5. ARIN approval of reassignments/reallocations 4.2.3.5.1. /18 All extra-large ISPs making reassignments or reallocations of a /18 or larger to a customer must first have these reassignments or reallocations reviewed and approved by ARIN. 4.2.3.5.2. /19 Small to large ISPs making customer reassignments or reallocations of a /19 or larger must first seek ARIN's approval. Current text: 4.2.3.7.1. Reassignment Information Each IPv4 assignment containing a /29 or more addresses shall be registered in the WHOIS directory via SWIP or a distributed service which meets the standards set forth in section 3.2. Reassignment registrations shall include each client's organizational information, except where specifically exempted by this policy. Proposed Editorial Changes: 4.2.3.7.1. Reassignment and Reallocation Information Each IPv4 reassignment or reallocation containing a /29 or more addresses shall be registered in the WHOIS directory via SWIP or a distributed service which meets the standards set forth in section 3.2. Reassignment and reallocation registrations shall include each client's organizational information, except where specifically exempted by this policy. Current text: 4.2.3.7.2.Assignments visible within 7 days All assignments shall be made visible as required in section 4.2.3.7.1 within seven calendar days of assignment. Proposed Editorial Changes: 4.2.3.7.2.Reassignments and Reallocations visible within 7 days All reassignments and reallocations shall be made visible as required in section 4.2.3.7.1 within seven calendar days of reassignment or reallocation. Current text: 4.2.4. ISP Additional Requests 4.2.4.1. Utilization percentage (80%) ISPs must have efficiently utilized all allocations, in aggregate, to at least 80% and at least 50% of every allocation in order to receive additional space. This includes all space reassigned to their customers. Proposed Editorial Changes: 4.2.4. ISP Additional Requests 4.2.4.1. Utilization percentage (80%) ISPs must have efficiently utilized all allocations, in aggregate, to at least 80% and at least 50% of every allocation in order to receive additional space. This includes all space reassigned or reallocated to their customers. Make the following editorial changes to section 6 to clarify language regarding current practices and requirements for reallocations and reassignments, and specifically to clarify that recording reallocation information is required where current language is ambiguous: Current text: 6.5.2.1(e) Initial Allocations to LIRs, Size For purposes of the calculation in (c), an LIR which has subordinate LIRs shall make such allocations according to the same policies and criteria as ARIN. In such a case, the prefixes necessary for such an allocation should be treated as fully utilized in determining the block sizing for the parent LIR. LIRs which do not receive resources directly from ARIN will not be able to make such allocations to subordinate LIRs and subordinate LIRs which need more than a /32 shall apply directly to ARIN. Proposed Editorial Changes: 6.5.2.1(e) Initial Allocations to LIRs, Size For purposes of the calculation in (c), an LIR which has subordinate LIRs shall make such reallocations according to the same policies and criteria as ARIN. In such a case, the prefixes necessary for such a reallocation should be treated as fully utilized in determining the block sizing for the parent LIR. LIRs which do not receive resources directly from ARIN will not be able to make such reallocations to subordinate LIRs and subordinate LIRs which need more than a /32 shall apply directly to ARIN. Current text: 6.5.2.2. Qualifications An organization qualifies for an allocation under this policy if they meet any of the following criteria: a. Have a previously justified IPv4 ISP allocation from ARIN or one of its predecessor registries or can qualify for an IPv4 ISP allocation under current criteria. b. Are currently multihomed for IPv6 or will immediately become multihomed for IPv6 using a valid assigned global AS number. In either case, they will be making reassignments from allocation(s) under this policy to other organizations. Provide ARIN a reasonable technical justification indicating why an allocation is necessary. Justification must include the intended purposes for the allocation and describe the network infrastructure the allocation will be used to support. Justification must also include a plan detailing anticipated assignments to other organizations or customers for one, two and five year periods, with a minimum of 50 assignments within 5 years. Proposed Editorial Changes: 6.5.2.2. Qualifications An organization qualifies for an allocation under this policy if they meet any of the following criteria: a. Have a previously justified IPv4 ISP allocation from ARIN or one of its predecessor registries or can qualify for an IPv4 ISP allocation under current criteria. b. Are currently multihomed for IPv6 or will immediately become multihomed for IPv6 using a valid assigned global AS number. In either case, they will be making reassignments or reallocations from allocation(s) under this policy to other organizations. Provide ARIN a reasonable technical justification indicating why an allocation is necessary. Justification must include the intended purposes for the allocation and describe the network infrastructure the allocation will be used to support. Justification must also include a plan detailing anticipated reassignments and reallocations to other organizations or customers for one, two and five year periods, with a minimum of 50 assignments within 5 years. Current text: 6.5.4. Assignments from LIRs/ISPs Assignments to end users shall be governed by the same practices adopted by the community in section 6.5.8 except that the requirements in 6.5.8.1 do not apply. Proposed Editorial Changes: 6.5.4. Reassignments from LIRs/ISPs Reassignments to end users shall be governed by the same practices adopted by the community in section 6.5.8 except that the requirements in 6.5.8.1 do not apply. Current text: 6.5.4.1. Assignment to operator's infrastructure An LIR may assign up to a /48 per PoP as well as up to an additional /48 globally for its own infrastructure. Proposed Editorial Changes: 6.5.4.1. Reassignment to operator's infrastructure An LIR may reassign up to a /48 per PoP as well as up to an additional /48 globally for its own infrastructure. Current text: 6.5.5. Registration ISPs are required to demonstrate efficient use of IP address space allocations by providing appropriate documentation, including but not limited to assignment histories, showing their efficient use. Proposed Editorial Changes: 6.5.5. Registration ISPs are required to demonstrate efficient use of IP address space allocations by providing appropriate documentation, including but not limited to reassignment and reallocation histories, showing their efficient use. Current text: 6.5.5.1. Reassignment information Each static IPv6 assignment containing a /64 or more addresses shall be registered in the WHOIS directory via SWIP or a distributed service which meets the standards set forth in section 3.2. Reassignment registrations shall include each client's organizational information, except where specifically exempted by this policy. Proposed Editorial Changes: 6.5.5.1. Reassignment information Each static IPv6 reassignment or reallocation containing a /64 or more addresses shall be registered in the WHOIS directory via SWIP or a distributed service which meets the standards set forth in section 3.2. Reassignment and reallocation registrations shall include each client's organizational information, except where specifically exempted by this policy. Current text: 6.5.5.2. Assignments visible within 7 days All assignments shall be made visible as required in section 4.2.3.7.1 within seven calendar days of assignment Proposed Editorial Changes: 6.5.5.2. Reassignments and Reallocations visible within 7 days All reassignments and reallocations shall be made visible as required in section 4.2.3.7.1 within seven calendar days of reassignment or reallocation. ------------------------------ 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 149, Issue 5 ***************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: From hostmaster at uneedus.com Tue Nov 21 18:41:24 2017 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Tue, 21 Nov 2017 18:41:24 -0500 (EST) Subject: [arin-ppml] Draft Policy ARIN-2017-11: Reallocation and Reassignment Language Cleanup In-Reply-To: <98d17d2f-c3f8-f395-77a2-6493f7d36452@arin.net> References: <98d17d2f-c3f8-f395-77a2-6493f7d36452@arin.net> Message-ID: Recommended policy 2017-5 proposes changing the language in 6.5.5.1 from /64 or more to /47 or more. According to an earlier email, this has been sent to the ARIN Board for adoption. The editoral changes in this draft include cleanup of 6.5.5.1, without noting that the ARIN Board may soon change the standard from /64 or more to /47 or more. I would not like to see this draft adopted as is, as it might be considered proposingg changing that standard back to /64 or more. I propose that this draft make clear that it does not seek to change whatever the current standard is (/47 or /64) at the time of its adoption, but simply desires to modify the remaining editoral language in that section. Albert Erdmann Network Administrator Paradise On Line Inc. On Tue, 21 Nov 2017, ARIN wrote: > On 16 November 2017, the ARIN Advisory Council (AC) advanced "ARIN-prop-246: > Reallocation and Reassignment Language Cleanup" to Draft Policy status. > > Draft Policy ARIN-2017-11 is below and can be found at: > https://www.arin.net/policy/proposals/2017_11.html > > You are encouraged to discuss all Draft Policies on PPML. The AC will > evaluate the discussion in order to assess the conformance of this draft > policy with ARIN's Principles of Internet number resource policy as stated in > the Policy Development Process (PDP). Specifically, these principles are: > > * Enabling Fair and Impartial Number Resource Administration > * Technically Sound > * Supported by the Community > > The PDP can be found at: > https://www.arin.net/policy/pdp.html > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > Regards, > > Sean Hopkins > Policy Analyst > American Registry for Internet Numbers (ARIN) > > > > Draft Policy ARIN-2017-11: Reallocation and Reassignment Language Cleanup > > Problem Statement: > > The current text of NRPM uses the terms ???reallocate??? and ???reassign??? > in ways that are both internally inconsistent within NRPM and inconsistent > with the definitions of Reassignments and Reallocations as fields within the > ARIN database. Frequently the term ???reassignment??? or ???reassign??? is > used in NRPM as an umbrella term for both reallocations and reassignments. As > a result, someone familiar with the ARIN Whois database, but unfamiliar with > history of particular portions of NRPM and their intended meaning may > interpret certain NRPM requirements as applying only to reassignments and not > to reallocations. This is particularly problematic when it comes to SWIP > requirements and the requirement to record reallocations and reassignments > with ARIN, which under current text could be read to only apply to > reassignments. > > Policy Statement: > > Make the following changes to the definitions in Section 2.5 > > Current text: > > 2.5. Allocate and Assign > > A distinction is made between address allocation and address assignment, > i.e., ISPs are "allocated" address space as described herein, while end-users > are "assigned" address space. > > Allocate - To allocate means to distribute address space to IRs for the > purpose of subsequent distribution by them. > > Assign - To assign means to delegate address space to an ISP or end-user, for > specific use within the Internet infrastructure they operate. Assignments > must only be made for specific purposes documented by specific organizations > and are not to be sub-assigned to other parties. > > Proposed Editorial Change: > > 2.5 Allocation, Assignment, Reallocation, Reassignment > > Allocation - Address space delegated to an organization directly by ARIN for > the purpose of subsequent distribution by the recipient organization to other > parties. > > Assignment - Address space delegated to an organization directly by ARIN for > the exclusive use of the recipient organization. > > Reallocation - Address space sub-delegated to an organization by an upstream > provider for the purpose of subsequent distribution by the recipient > organization to other parties. > > Reassignment - Address space sub-delegated to an organization by an upstream > provider for the exclusive use of the recipient organization. > > Make the following editorial changes to section 4.2: > > Current text: > > 4.2.1.1. Purpose > > ARIN allocates blocks of IP addresses to ISPs for the purpose of reassigning > that space to their customers. > > Proposed Editorial Change: > > 4.2.1.1. Purpose > > ARIN allocates blocks of IP addresses to ISPs for the purpose of reassigning > and reallocating that space to their customers. > > Current text: > > 4.2.3. Reassigning Address Space to Customers > > Proposed Editorial Change: > > 4.2.3. Reassigning and Reallocating Address Space to Customers > > Current Text: > > 4.2.3.1. Efficient utilization > > ISPs are required to apply a utilization efficiency criterion in providing > address space to their customers. To this end, ISPs should have documented > justification available for each reassignment. ARIN may request this > justification at any time. If justification is not provided, future receipt > of allocations may be impacted. > > Proposed Editorial Change: > > 4.2.3.1. Efficient utilization > > ISPs are required to apply a utilization efficiency criterion in providing > address space to their customers. To this end, ISPs should have documented > justification available for each reassignment and reallocation. ARIN may > request this justification at any time. If justification is not provided, > future receipt of allocations may be impacted. > > Current text: > > 4.2.3.4. Downstream customer adherence > > ISPs must require their downstream customers to adhere to the following > criteria: > > 4.2.3.4.1. Utilization > > Reassignment information for prior allocations must show that each customer > meets the 80% utilization criteria and must be available via SWIP / RWhois > prior to your issuing them additional space. > > Proposed Editorial Changes: > > 4.2.3.4. Downstream customer adherence > > ISPs must require their downstream customers to adhere to the following > criteria: > > 4.2.3.4.1. Utilization > > Reassignment and reallocation information for prior allocations must show > that each customer meets the 80% utilization criteria and must be available > via SWIP / RWhois prior to your issuing them additional space. > > Current text: > > 4.2.3.5. ARIN approval of reassignments/reallocations > > 4.2.3.5.1. /18 > > All extra-large ISPs making reassignments of a /18 or larger to a customer > must first have these reassignments reviewed and approved by ARIN. > > 4.2.3.5.2. /19 > > Small to large ISPs making customer reassignments of a /19 or larger must > first seek ARIN's approval. > > Proposed Editorial Changes: > > 4.2.3.5. ARIN approval of reassignments/reallocations > > 4.2.3.5.1. /18 > > All extra-large ISPs making reassignments or reallocations of a /18 or larger > to a customer must first have these reassignments or reallocations reviewed > and approved by ARIN. > > 4.2.3.5.2. /19 > > Small to large ISPs making customer reassignments or reallocations of a /19 > or larger must first seek ARIN's approval. > > Current text: > > 4.2.3.7.1. Reassignment Information > > Each IPv4 assignment containing a /29 or more addresses shall be registered > in the WHOIS directory via SWIP or a distributed service which meets the > standards set forth in section 3.2. Reassignment registrations shall include > each client's organizational information, except where specifically exempted > by this policy. > > Proposed Editorial Changes: > > 4.2.3.7.1. Reassignment and Reallocation Information > > Each IPv4 reassignment or reallocation containing a /29 or more addresses > shall be registered in the WHOIS directory via SWIP or a distributed service > which meets the standards set forth in section 3.2. Reassignment and > reallocation registrations shall include each client's organizational > information, except where specifically exempted by this policy. > > Current text: > > 4.2.3.7.2.Assignments visible within 7 days > > All assignments shall be made visible as required in section 4.2.3.7.1 within > seven calendar days of assignment. > > Proposed Editorial Changes: > > 4.2.3.7.2.Reassignments and Reallocations visible within 7 days > > All reassignments and reallocations shall be made visible as required in > section 4.2.3.7.1 within seven calendar days of reassignment or reallocation. > > Current text: > > 4.2.4. ISP Additional Requests > > 4.2.4.1. Utilization percentage (80%) > > ISPs must have efficiently utilized all allocations, in aggregate, to at > least 80% and at least 50% of every allocation in order to receive additional > space. This includes all space reassigned to their customers. > > Proposed Editorial Changes: > > 4.2.4. ISP Additional Requests > > 4.2.4.1. Utilization percentage (80%) > > ISPs must have efficiently utilized all allocations, in aggregate, to at > least 80% and at least 50% of every allocation in order to receive additional > space. This includes all space reassigned or reallocated to their customers. > > Make the following editorial changes to section 6 to clarify language > regarding current practices and requirements for reallocations and > reassignments, and specifically to clarify that recording reallocation > information is required where current language is ambiguous: > > Current text: > > 6.5.2.1(e) Initial Allocations to LIRs, Size > > For purposes of the calculation in (c), an LIR which has subordinate LIRs > shall make such allocations according to the same policies and criteria as > ARIN. In such a case, the prefixes necessary for such an allocation should be > treated as fully utilized in determining the block sizing for the parent LIR. > LIRs which do not receive resources directly from ARIN will not be able to > make such allocations to subordinate LIRs and subordinate LIRs which need > more than a /32 shall apply directly to ARIN. > > Proposed Editorial Changes: > > 6.5.2.1(e) Initial Allocations to LIRs, Size > > For purposes of the calculation in (c), an LIR which has subordinate LIRs > shall make such reallocations according to the same policies and criteria as > ARIN. In such a case, the prefixes necessary for such a reallocation should > be treated as fully utilized in determining the block sizing for the parent > LIR. LIRs which do not receive resources directly from ARIN will not be able > to make such reallocations to subordinate LIRs and subordinate LIRs which > need more than a /32 shall apply directly to ARIN. > > Current text: > > 6.5.2.2. Qualifications > > An organization qualifies for an allocation under this policy if they meet > any of the following criteria: > > a. Have a previously justified IPv4 ISP allocation from ARIN or one of its > predecessor registries or can qualify for an IPv4 ISP allocation under > current criteria. > > b. Are currently multihomed for IPv6 or will immediately become multihomed > for IPv6 using a valid assigned global AS number. > > In either case, they will be making reassignments from allocation(s) under > this policy to other organizations. > > Provide ARIN a reasonable technical justification indicating why an > allocation is necessary. Justification must include the intended purposes for > the allocation and describe the network infrastructure the allocation will be > used to support. Justification must also include a plan detailing anticipated > assignments to other organizations or customers for one, two and five year > periods, with a minimum of 50 assignments within 5 years. > > Proposed Editorial Changes: > > 6.5.2.2. Qualifications > > An organization qualifies for an allocation under this policy if they meet > any of the following criteria: > > a. Have a previously justified IPv4 ISP allocation from ARIN or one of its > predecessor registries or can qualify for an IPv4 ISP allocation under > current criteria. > > b. Are currently multihomed for IPv6 or will immediately become multihomed > for IPv6 using a valid assigned global AS number. > > In either case, they will be making reassignments or reallocations from > allocation(s) under this policy to other organizations. > > Provide ARIN a reasonable technical justification indicating why an > allocation is necessary. Justification must include the intended purposes for > the allocation and describe the network infrastructure the allocation will be > used to support. Justification must also include a plan detailing anticipated > reassignments and reallocations to other organizations or customers for one, > two and five year periods, with a minimum of 50 assignments within 5 years. > > Current text: > > 6.5.4. Assignments from LIRs/ISPs > > Assignments to end users shall be governed by the same practices adopted by > the community in section 6.5.8 except that the requirements in 6.5.8.1 do not > apply. > > Proposed Editorial Changes: > > 6.5.4. Reassignments from LIRs/ISPs > > Reassignments to end users shall be governed by the same practices adopted by > the community in section 6.5.8 except that the requirements in 6.5.8.1 do not > apply. > > Current text: > > 6.5.4.1. Assignment to operator's infrastructure > > An LIR may assign up to a /48 per PoP as well as up to an additional /48 > globally for its own infrastructure. > > Proposed Editorial Changes: > > 6.5.4.1. Reassignment to operator's infrastructure > > An LIR may reassign up to a /48 per PoP as well as up to an additional /48 > globally for its own infrastructure. > > Current text: > > 6.5.5. Registration > > ISPs are required to demonstrate efficient use of IP address space > allocations by providing appropriate documentation, including but not limited > to assignment histories, showing their efficient use. > > Proposed Editorial Changes: > > 6.5.5. Registration > > ISPs are required to demonstrate efficient use of IP address space > allocations by providing appropriate documentation, including but not limited > to reassignment and reallocation histories, showing their efficient use. > > Current text: > > 6.5.5.1. Reassignment information > > Each static IPv6 assignment containing a /64 or more addresses shall be > registered in the WHOIS directory via SWIP or a distributed service which > meets the standards set forth in section 3.2. Reassignment registrations > shall include each client's organizational information, except where > specifically exempted by this policy. > > Proposed Editorial Changes: > > 6.5.5.1. Reassignment information > > Each static IPv6 reassignment or reallocation containing a /64 or more > addresses shall be registered in the WHOIS directory via SWIP or a > distributed service which meets the standards set forth in section 3.2. > Reassignment and reallocation registrations shall include each client's > organizational information, except where specifically exempted by this > policy. > > Current text: > > 6.5.5.2. Assignments visible within 7 days > > All assignments shall be made visible as required in section 4.2.3.7.1 within > seven calendar days of assignment > > Proposed Editorial Changes: > > 6.5.5.2. Reassignments and Reallocations visible within 7 days > > All reassignments and reallocations shall be made visible as required in > section 4.2.3.7.1 within seven calendar days of reassignment or reallocation. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From theone at uneedus.com Tue Nov 21 18:48:21 2017 From: theone at uneedus.com (theone at uneedus.com) Date: Tue, 21 Nov 2017 18:48:21 -0500 (EST) Subject: [arin-ppml] Draft Policy ARIN-2017-11: Reallocation and Reassignment Language Cleanup In-Reply-To: <98d17d2f-c3f8-f395-77a2-6493f7d36452@arin.net> References: <98d17d2f-c3f8-f395-77a2-6493f7d36452@arin.net> Message-ID: For the same reason as stated in comments to ARIN-2017-10, this proposal changes language in 6.5.5.1 which is before the ARIN Board regarding a change of the standard from /64 or more to /47 or more, or any size individually announced. I suggest the author take into consideration the change of this section in ARIN-2017-5 before the ARIN Board, before any changes to this section are made. Albert Erdmann Network Administrator Paradise On Line Inc. On Tue, 21 Nov 2017, ARIN wrote: > On 16 November 2017, the ARIN Advisory Council (AC) advanced "ARIN-prop-246: > Reallocation and Reassignment Language Cleanup" to Draft Policy status. > > Draft Policy ARIN-2017-11 is below and can be found at: > https://www.arin.net/policy/proposals/2017_11.html > > You are encouraged to discuss all Draft Policies on PPML. The AC will > evaluate the discussion in order to assess the conformance of this draft > policy with ARIN's Principles of Internet number resource policy as stated in > the Policy Development Process (PDP). Specifically, these principles are: > > * Enabling Fair and Impartial Number Resource Administration > * Technically Sound > * Supported by the Community > > The PDP can be found at: > https://www.arin.net/policy/pdp.html > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/policy/proposals/index.html > > Regards, > > Sean Hopkins > Policy Analyst > American Registry for Internet Numbers (ARIN) > > > > Draft Policy ARIN-2017-11: Reallocation and Reassignment Language Cleanup > > Problem Statement: > > The current text of NRPM uses the terms ?reallocate? and ?reassign? > in ways that are both internally inconsistent within NRPM and inconsistent > with the definitions of Reassignments and Reallocations as fields within the > ARIN database. Frequently the term ?reassignment? or ?reassign? is > used in NRPM as an umbrella term for both reallocations and reassignments. As > a result, someone familiar with the ARIN Whois database, but unfamiliar with > history of particular portions of NRPM and their intended meaning may > interpret certain NRPM requirements as applying only to reassignments and not > to reallocations. This is particularly problematic when it comes to SWIP > requirements and the requirement to record reallocations and reassignments > with ARIN, which under current text could be read to only apply to > reassignments. > > Policy Statement: > > Make the following changes to the definitions in Section 2.5 > > Current text: > > 2.5. Allocate and Assign > > A distinction is made between address allocation and address assignment, > i.e., ISPs are "allocated" address space as described herein, while end-users > are "assigned" address space. > > Allocate - To allocate means to distribute address space to IRs for the > purpose of subsequent distribution by them. > > Assign - To assign means to delegate address space to an ISP or end-user, for > specific use within the Internet infrastructure they operate. Assignments > must only be made for specific purposes documented by specific organizations > and are not to be sub-assigned to other parties. > > Proposed Editorial Change: > > 2.5 Allocation, Assignment, Reallocation, Reassignment > > Allocation - Address space delegated to an organization directly by ARIN for > the purpose of subsequent distribution by the recipient organization to other > parties. > > Assignment - Address space delegated to an organization directly by ARIN for > the exclusive use of the recipient organization. > > Reallocation - Address space sub-delegated to an organization by an upstream > provider for the purpose of subsequent distribution by the recipient > organization to other parties. > > Reassignment - Address space sub-delegated to an organization by an upstream > provider for the exclusive use of the recipient organization. > > Make the following editorial changes to section 4.2: > > Current text: > > 4.2.1.1. Purpose > > ARIN allocates blocks of IP addresses to ISPs for the purpose of reassigning > that space to their customers. > > Proposed Editorial Change: > > 4.2.1.1. Purpose > > ARIN allocates blocks of IP addresses to ISPs for the purpose of reassigning > and reallocating that space to their customers. > > Current text: > > 4.2.3. Reassigning Address Space to Customers > > Proposed Editorial Change: > > 4.2.3. Reassigning and Reallocating Address Space to Customers > > Current Text: > > 4.2.3.1. Efficient utilization > > ISPs are required to apply a utilization efficiency criterion in providing > address space to their customers. To this end, ISPs should have documented > justification available for each reassignment. ARIN may request this > justification at any time. If justification is not provided, future receipt > of allocations may be impacted. > > Proposed Editorial Change: > > 4.2.3.1. Efficient utilization > > ISPs are required to apply a utilization efficiency criterion in providing > address space to their customers. To this end, ISPs should have documented > justification available for each reassignment and reallocation. ARIN may > request this justification at any time. If justification is not provided, > future receipt of allocations may be impacted. > > Current text: > > 4.2.3.4. Downstream customer adherence > > ISPs must require their downstream customers to adhere to the following > criteria: > > 4.2.3.4.1. Utilization > > Reassignment information for prior allocations must show that each customer > meets the 80% utilization criteria and must be available via SWIP / RWhois > prior to your issuing them additional space. > > Proposed Editorial Changes: > > 4.2.3.4. Downstream customer adherence > > ISPs must require their downstream customers to adhere to the following > criteria: > > 4.2.3.4.1. Utilization > > Reassignment and reallocation information for prior allocations must show > that each customer meets the 80% utilization criteria and must be available > via SWIP / RWhois prior to your issuing them additional space. > > Current text: > > 4.2.3.5. ARIN approval of reassignments/reallocations > > 4.2.3.5.1. /18 > > All extra-large ISPs making reassignments of a /18 or larger to a customer > must first have these reassignments reviewed and approved by ARIN. > > 4.2.3.5.2. /19 > > Small to large ISPs making customer reassignments of a /19 or larger must > first seek ARIN's approval. > > Proposed Editorial Changes: > > 4.2.3.5. ARIN approval of reassignments/reallocations > > 4.2.3.5.1. /18 > > All extra-large ISPs making reassignments or reallocations of a /18 or larger > to a customer must first have these reassignments or reallocations reviewed > and approved by ARIN. > > 4.2.3.5.2. /19 > > Small to large ISPs making customer reassignments or reallocations of a /19 > or larger must first seek ARIN's approval. > > Current text: > > 4.2.3.7.1. Reassignment Information > > Each IPv4 assignment containing a /29 or more addresses shall be registered > in the WHOIS directory via SWIP or a distributed service which meets the > standards set forth in section 3.2. Reassignment registrations shall include > each client's organizational information, except where specifically exempted > by this policy. > > Proposed Editorial Changes: > > 4.2.3.7.1. Reassignment and Reallocation Information > > Each IPv4 reassignment or reallocation containing a /29 or more addresses > shall be registered in the WHOIS directory via SWIP or a distributed service > which meets the standards set forth in section 3.2. Reassignment and > reallocation registrations shall include each client's organizational > information, except where specifically exempted by this policy. > > Current text: > > 4.2.3.7.2.Assignments visible within 7 days > > All assignments shall be made visible as required in section 4.2.3.7.1 within > seven calendar days of assignment. > > Proposed Editorial Changes: > > 4.2.3.7.2.Reassignments and Reallocations visible within 7 days > > All reassignments and reallocations shall be made visible as required in > section 4.2.3.7.1 within seven calendar days of reassignment or reallocation. > > Current text: > > 4.2.4. ISP Additional Requests > > 4.2.4.1. Utilization percentage (80%) > > ISPs must have efficiently utilized all allocations, in aggregate, to at > least 80% and at least 50% of every allocation in order to receive additional > space. This includes all space reassigned to their customers. > > Proposed Editorial Changes: > > 4.2.4. ISP Additional Requests > > 4.2.4.1. Utilization percentage (80%) > > ISPs must have efficiently utilized all allocations, in aggregate, to at > least 80% and at least 50% of every allocation in order to receive additional > space. This includes all space reassigned or reallocated to their customers. > > Make the following editorial changes to section 6 to clarify language > regarding current practices and requirements for reallocations and > reassignments, and specifically to clarify that recording reallocation > information is required where current language is ambiguous: > > Current text: > > 6.5.2.1(e) Initial Allocations to LIRs, Size > > For purposes of the calculation in (c), an LIR which has subordinate LIRs > shall make such allocations according to the same policies and criteria as > ARIN. In such a case, the prefixes necessary for such an allocation should be > treated as fully utilized in determining the block sizing for the parent LIR. > LIRs which do not receive resources directly from ARIN will not be able to > make such allocations to subordinate LIRs and subordinate LIRs which need > more than a /32 shall apply directly to ARIN. > > Proposed Editorial Changes: > > 6.5.2.1(e) Initial Allocations to LIRs, Size > > For purposes of the calculation in (c), an LIR which has subordinate LIRs > shall make such reallocations according to the same policies and criteria as > ARIN. In such a case, the prefixes necessary for such a reallocation should > be treated as fully utilized in determining the block sizing for the parent > LIR. LIRs which do not receive resources directly from ARIN will not be able > to make such reallocations to subordinate LIRs and subordinate LIRs which > need more than a /32 shall apply directly to ARIN. > > Current text: > > 6.5.2.2. Qualifications > > An organization qualifies for an allocation under this policy if they meet > any of the following criteria: > > a. Have a previously justified IPv4 ISP allocation from ARIN or one of its > predecessor registries or can qualify for an IPv4 ISP allocation under > current criteria. > > b. Are currently multihomed for IPv6 or will immediately become multihomed > for IPv6 using a valid assigned global AS number. > > In either case, they will be making reassignments from allocation(s) under > this policy to other organizations. > > Provide ARIN a reasonable technical justification indicating why an > allocation is necessary. Justification must include the intended purposes for > the allocation and describe the network infrastructure the allocation will be > used to support. Justification must also include a plan detailing anticipated > assignments to other organizations or customers for one, two and five year > periods, with a minimum of 50 assignments within 5 years. > > Proposed Editorial Changes: > > 6.5.2.2. Qualifications > > An organization qualifies for an allocation under this policy if they meet > any of the following criteria: > > a. Have a previously justified IPv4 ISP allocation from ARIN or one of its > predecessor registries or can qualify for an IPv4 ISP allocation under > current criteria. > > b. Are currently multihomed for IPv6 or will immediately become multihomed > for IPv6 using a valid assigned global AS number. > > In either case, they will be making reassignments or reallocations from > allocation(s) under this policy to other organizations. > > Provide ARIN a reasonable technical justification indicating why an > allocation is necessary. Justification must include the intended purposes for > the allocation and describe the network infrastructure the allocation will be > used to support. Justification must also include a plan detailing anticipated > reassignments and reallocations to other organizations or customers for one, > two and five year periods, with a minimum of 50 assignments within 5 years. > > Current text: > > 6.5.4. Assignments from LIRs/ISPs > > Assignments to end users shall be governed by the same practices adopted by > the community in section 6.5.8 except that the requirements in 6.5.8.1 do not > apply. > > Proposed Editorial Changes: > > 6.5.4. Reassignments from LIRs/ISPs > > Reassignments to end users shall be governed by the same practices adopted by > the community in section 6.5.8 except that the requirements in 6.5.8.1 do not > apply. > > Current text: > > 6.5.4.1. Assignment to operator's infrastructure > > An LIR may assign up to a /48 per PoP as well as up to an additional /48 > globally for its own infrastructure. > > Proposed Editorial Changes: > > 6.5.4.1. Reassignment to operator's infrastructure > > An LIR may reassign up to a /48 per PoP as well as up to an additional /48 > globally for its own infrastructure. > > Current text: > > 6.5.5. Registration > > ISPs are required to demonstrate efficient use of IP address space > allocations by providing appropriate documentation, including but not limited > to assignment histories, showing their efficient use. > > Proposed Editorial Changes: > > 6.5.5. Registration > > ISPs are required to demonstrate efficient use of IP address space > allocations by providing appropriate documentation, including but not limited > to reassignment and reallocation histories, showing their efficient use. > > Current text: > > 6.5.5.1. Reassignment information > > Each static IPv6 assignment containing a /64 or more addresses shall be > registered in the WHOIS directory via SWIP or a distributed service which > meets the standards set forth in section 3.2. Reassignment registrations > shall include each client's organizational information, except where > specifically exempted by this policy. > > Proposed Editorial Changes: > > 6.5.5.1. Reassignment information > > Each static IPv6 reassignment or reallocation containing a /64 or more > addresses shall be registered in the WHOIS directory via SWIP or a > distributed service which meets the standards set forth in section 3.2. > Reassignment and reallocation registrations shall include each client's > organizational information, except where specifically exempted by this > policy. > > Current text: > > 6.5.5.2. Assignments visible within 7 days > > All assignments shall be made visible as required in section 4.2.3.7.1 within > seven calendar days of assignment > > Proposed Editorial Changes: > > 6.5.5.2. Reassignments and Reallocations visible within 7 days > > All reassignments and reallocations shall be made visible as required in > section 4.2.3.7.1 within seven calendar days of reassignment or reallocation. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. > From farmer at umn.edu Tue Nov 21 19:16:59 2017 From: farmer at umn.edu (David Farmer) Date: Tue, 21 Nov 2017 18:16:59 -0600 Subject: [arin-ppml] Draft Policy ARIN-2017-13: Remove ARIN Review Requirements for Large, IPv4 Reassignments/Reallocations In-Reply-To: References: <88404d28-06a3-504c-547a-3eb742b2f11f@arin.net> Message-ID: No it actively requires a significant workload by ARIN Staff, which is why I believe it was brought to the communities attention. >From slide #5 of the ARIN 40 Policy Experience Report; Ticket Workload {for 4.2.3.5.}, 1,327 in 2016, approximately 70% are self SWIPs Slides: https://www.arin.net/vault/participate/meetings/reports/ARIN _40/PDF/PPM/sweeting-policy-experience.pdf Transcript: https://www.arin.net/vault/participate/meetings/ reports/ARIN_40/ppm1_transcript.html#anchor_5 Video: https://www.youtube.com/watch?v=QVsfVMG_6fA FYI, this report is the genesis for what is now ARIN-2017-9 and ARIN-2017-10 as well. Hope that helps. On Tue, Nov 21, 2017 at 5:05 PM, Scott Leibrand wrote: > +1 - Support > > Do we have any statistics on the last time 4.2.3.5 was invoked and/or > frequently it was invoked? I suspect it's been awhile... > > -Scott > > On Tue, Nov 21, 2017 at 2:44 PM, ARIN wrote: > >> On 16 November 2017 the ARIN Advisory Council (AC) advanced >> "ARIN-prop-248: Remove ARIN Review Requirements for Large IPv4 >> Reassignments/Reallocations" to Draft Policy status. >> >> Draft Policy ARIN-2017-13 is below and can be found at: >> https://www.arin.net/policy/proposals/2017_13.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-13: Remove ARIN Review Requirements for Large >> IPv4 Reassignments/Reallocations >> >> Problem Statement: >> >> ARIN review of large IPv4 reassignments or rellocations was put in place >> when ARIN had a free pool of IPv4 addresses. The main purpose of the review >> was to ensure that ISPs were following RFC2050 and ARIN policy for large >> blocks. Since there is no longer a free pool and blocks have a value >> through transfer, there is now a disincentive for ISPs to over assign >> blocks to downstream customers. Thus this policy is no longer needed. >> >> Policy statement: >> >> Remove Section 4.2.3.5 of NRPM >> >> 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. > -- =============================================== David Farmer Email:farmer at umn.edu Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 <(612)%20626-0815> Minneapolis, MN 55414-3029 Cell: 612-812-9952 <(612)%20812-9952> =============================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From scottleibrand at gmail.com Tue Nov 21 19:32:19 2017 From: scottleibrand at gmail.com (Scott Leibrand) Date: Tue, 21 Nov 2017 16:32:19 -0800 Subject: [arin-ppml] Draft Policy ARIN-2017-13: Remove ARIN Review Requirements for Large, IPv4 Reassignments/Reallocations In-Reply-To: References: <88404d28-06a3-504c-547a-3eb742b2f11f@arin.net> Message-ID: Thanks for that context. In that case, I stand corrected, and am even more strongly in favor of this proposal. :-) -Scott On Tue, Nov 21, 2017 at 4:16 PM, David Farmer wrote: > No it actively requires a significant workload by ARIN Staff, which is why > I believe it was brought to the communities attention. > > From slide #5 of the ARIN 40 Policy Experience Report; > > Ticket Workload {for 4.2.3.5.}, 1,327 in 2016, approximately 70% are self > SWIPs > > Slides: https://www.arin.net/vault/participate/meetings/reports/ARIN > _40/PDF/PPM/sweeting-policy-experience.pdf > Transcript: https://www.arin.net/vault/participate/meetings/ > reports/ARIN_40/ppm1_transcript.html#anchor_5 > Video: https://www.youtube.com/watch?v=QVsfVMG_6fA > > FYI, this report is the genesis for what is now ARIN-2017-9 > and ARIN-2017-10 as well. > > Hope that helps. > > On Tue, Nov 21, 2017 at 5:05 PM, Scott Leibrand > wrote: > >> +1 - Support >> >> Do we have any statistics on the last time 4.2.3.5 was invoked and/or >> frequently it was invoked? I suspect it's been awhile... >> >> -Scott >> >> On Tue, Nov 21, 2017 at 2:44 PM, ARIN wrote: >> >>> On 16 November 2017 the ARIN Advisory Council (AC) advanced >>> "ARIN-prop-248: Remove ARIN Review Requirements for Large IPv4 >>> Reassignments/Reallocations" to Draft Policy status. >>> >>> Draft Policy ARIN-2017-13 is below and can be found at: >>> https://www.arin.net/policy/proposals/2017_13.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-13: Remove ARIN Review Requirements for Large >>> IPv4 Reassignments/Reallocations >>> >>> Problem Statement: >>> >>> ARIN review of large IPv4 reassignments or rellocations was put in place >>> when ARIN had a free pool of IPv4 addresses. The main purpose of the review >>> was to ensure that ISPs were following RFC2050 and ARIN policy for large >>> blocks. Since there is no longer a free pool and blocks have a value >>> through transfer, there is now a disincentive for ISPs to over assign >>> blocks to downstream customers. Thus this policy is no longer needed. >>> >>> Policy statement: >>> >>> Remove Section 4.2.3.5 of NRPM >>> >>> 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. >> > > > > -- > =============================================== > 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 hvgeekwtrvl at gmail.com Tue Nov 21 19:36:03 2017 From: hvgeekwtrvl at gmail.com (james machado) Date: Tue, 21 Nov 2017 16:36:03 -0800 Subject: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment In-Reply-To: References: Message-ID: Generally I support this idea but I would expand on 3.7. In the event that an entity already has an ARIN POC they would have the option of accepting the new POC or utilizing an existing POC at the entities discretion for the reallocation or reassignment. I have been in the position of having multiple unknown POCs with ARIN for $dayjob and having them connected random employees depending on whom the salesman spoke too at the time they were filling out the documents. I want the option to have all the reassignments/reallocations associated with the POCs I choose. James -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris at semihuman.com Tue Nov 21 20:10:57 2017 From: chris at semihuman.com (Chris Woodfield) Date: Tue, 21 Nov 2017 17:10:57 -0800 Subject: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment In-Reply-To: References: Message-ID: <8F41F7C9-3CF7-498E-8006-CF2E2D248176@semihuman.com> First off, I?m in favor of the goal of this proposal; I?m sure that a large percentage of unverified POCs are due to SWIPs being made with POCs that are invalid from the get-go. I expect the language will evolve through the PDP, so I?ll hold off on my ?as written? judgement for the time being. To your specific suggestion: I?d expect that such a mechanism would be a great enhancement to the current validation process, independent of this particular policy proposal. It would be great if it was possible to set up rules in the ARIN portal that, for example, funneled all POC creation attempts with @my.domain as the email address to a specific role account, for example. That said, your suggestion defines an implementation mechanism, not a policy, and as such, doesn?t belong in the NRPM. Thanks, -C > On Nov 21, 2017, at 4:36 PM, james machado wrote: > > Generally I support this idea but I would expand on 3.7. > > In the event that an entity already has an ARIN POC they would have the option of accepting the new POC or utilizing an existing POC at the entities discretion for the reallocation or reassignment. > > I have been in the position of having multiple unknown POCs with ARIN for $dayjob and having them connected random employees depending on whom the salesman spoke too at the time they were filling out the documents. I want the option to have all the reassignments/reallocations associated with the POCs I choose. > > 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. From andrew.dul at quark.net Tue Nov 21 22:28:19 2017 From: andrew.dul at quark.net (Andrew Dul) Date: Tue, 21 Nov 2017 19:28:19 -0800 Subject: [arin-ppml] Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers In-Reply-To: References: <652abd11-68d7-900e-7776-b97b2311ea05@arin.net> Message-ID: <846F1403-01F5-4DA1-A241-3B58108E111C@quark.net> It sounds like our recollections of what we intended for ISP initial allocations have diverged. I will admit when I drafted the problem statement I did not go back through email to see if there was anything about this issue. Assuming we harmonize the problem statement, would you prefer the /24 as initial no questions asked size or a /21? What do others prefer? .Andrew > On Nov 21, 2017, at 2:52 PM, Scott Leibrand wrote: > > I believe this problem statement is incorrect, and therefore oppose the policy proposal as-is. > > 8.5.4 was intended (by me, as one of the authors, and in PPML discussions I just pulled up) to allow ISPs to transfer a /24 without justification. It was *not* intended to "match the previous policy" in 4.2.2. > > 8.5.5 reads "8.5.5. Block size > Organizations may qualify for the transfer of a larger initial block, or an additional block, by providing documentation to ARIN which details the use of at least 50% of the requested IPv4 block size within 24 months. An officer of the organization shall attest to the documentation provided to ARIN." > > The intention was that any ISP needing a /21 would need to "provide documentation to ARIN which details the use of at least 50% of the requested IPv4 block size within 24 months", with officer attestation to same. > > If that policy is deemed insufficient, and we believe it's better to allow transfers of up to /21 without providing documentation to ARIN and officer attestation of such, then this proposal would need to be re-written with a new problem statement justifying that. > > -Scott > >> On Tue, Nov 21, 2017 at 2:40 PM, ARIN wrote: >> On 16 November 2017, the ARIN Advisory Council (AC) advanced "ARIN-prop-244: Clarification of Initial Block Size for IPv4 ISP Transfers" to Draft Policy status. >> >> Draft Policy ARIN-2017-9 is below and can be found at: >> https://www.arin.net/policy/proposals/2017_9.html >> >> You are encouraged to discuss all Draft Policies on PPML. The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet number resource policy as stated in the Policy Development Process (PDP). Specifically, these principles are: >> >> * Enabling Fair and Impartial Number Resource Administration >> * Technically Sound >> * Supported by the Community >> >> The PDP can be found at: >> https://www.arin.net/policy/pdp.html >> >> Draft Policies and Proposals under discussion can be found at: >> https://www.arin.net/policy/proposals/index.html >> >> Regards, >> >> Sean Hopkins >> Policy Analyst >> American Registry for Internet Numbers (ARIN) >> >> >> >> Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers >> >> Problem Statement: >> >> It was noted at the ARIN 40 Policy Experience Report, that there is an inconsistency in the initial block size for ISPs. Section 4.2.2 notes that the initial ISP block size should be /21 whereas the initial block size in 8.5.4 is noted as "minimum transfer size" which is effectively a /24. The intent of the new 8.5.4 was to match the previous policy. This policy is intended to clarify this issue. It was noted that ARIN staff current operational practice is to allow ISPs an initial /21 for Section 8 transfers. >> >> Policy statement: >> >> Add the following to 8.5.4 >> >> ISP organizations without direct assignments or allocations from ARIN qualify for an initial allocation of up to a /21. >> >> Comments: >> >> a. Timetable for implementation: Immediate >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From scottleibrand at gmail.com Wed Nov 22 00:19:27 2017 From: scottleibrand at gmail.com (Scott Leibrand) Date: Tue, 21 Nov 2017 21:19:27 -0800 Subject: [arin-ppml] Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers In-Reply-To: <846F1403-01F5-4DA1-A241-3B58108E111C@quark.net> References: <652abd11-68d7-900e-7776-b97b2311ea05@arin.net> <846F1403-01F5-4DA1-A241-3B58108E111C@quark.net> Message-ID: <053B38B3-B8BD-43A8-9328-B4DDFE1F7E7B@gmail.com> I?d be ok with a /21, but there?s nothing magical about that size in a post-exhaustion world. I?d rather base a loosening on actual transfer statistics, and consider doing so for both allocations and assignments. Scott > On Nov 21, 2017, at 7:28 PM, Andrew Dul wrote: > > It sounds like our recollections of what we intended for ISP initial allocations have diverged. I will admit when I drafted the problem statement I did not go back through email to see if there was anything about this issue. > > Assuming we harmonize the problem statement, would you prefer the /24 as initial no questions asked size or a /21? > > What do others prefer? > > .Andrew > >> On Nov 21, 2017, at 2:52 PM, Scott Leibrand wrote: >> >> I believe this problem statement is incorrect, and therefore oppose the policy proposal as-is. >> >> 8.5.4 was intended (by me, as one of the authors, and in PPML discussions I just pulled up) to allow ISPs to transfer a /24 without justification. It was *not* intended to "match the previous policy" in 4.2.2. >> >> 8.5.5 reads "8.5.5. Block size >> Organizations may qualify for the transfer of a larger initial block, or an additional block, by providing documentation to ARIN which details the use of at least 50% of the requested IPv4 block size within 24 months. An officer of the organization shall attest to the documentation provided to ARIN." >> >> The intention was that any ISP needing a /21 would need to "provide documentation to ARIN which details the use of at least 50% of the requested IPv4 block size within 24 months", with officer attestation to same. >> >> If that policy is deemed insufficient, and we believe it's better to allow transfers of up to /21 without providing documentation to ARIN and officer attestation of such, then this proposal would need to be re-written with a new problem statement justifying that. >> >> -Scott >> >>> On Tue, Nov 21, 2017 at 2:40 PM, ARIN wrote: >>> On 16 November 2017, the ARIN Advisory Council (AC) advanced "ARIN-prop-244: Clarification of Initial Block Size for IPv4 ISP Transfers" to Draft Policy status. >>> >>> Draft Policy ARIN-2017-9 is below and can be found at: >>> https://www.arin.net/policy/proposals/2017_9.html >>> >>> You are encouraged to discuss all Draft Policies on PPML. The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet number resource policy as stated in the Policy Development Process (PDP). Specifically, these principles are: >>> >>> * Enabling Fair and Impartial Number Resource Administration >>> * Technically Sound >>> * Supported by the Community >>> >>> The PDP can be found at: >>> https://www.arin.net/policy/pdp.html >>> >>> Draft Policies and Proposals under discussion can be found at: >>> https://www.arin.net/policy/proposals/index.html >>> >>> Regards, >>> >>> Sean Hopkins >>> Policy Analyst >>> American Registry for Internet Numbers (ARIN) >>> >>> >>> >>> Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers >>> >>> Problem Statement: >>> >>> It was noted at the ARIN 40 Policy Experience Report, that there is an inconsistency in the initial block size for ISPs. Section 4.2.2 notes that the initial ISP block size should be /21 whereas the initial block size in 8.5.4 is noted as "minimum transfer size" which is effectively a /24. The intent of the new 8.5.4 was to match the previous policy. This policy is intended to clarify this issue. It was noted that ARIN staff current operational practice is to allow ISPs an initial /21 for Section 8 transfers. >>> >>> Policy statement: >>> >>> Add the following to 8.5.4 >>> >>> ISP organizations without direct assignments or allocations from ARIN qualify for an initial allocation of up to a /21. >>> >>> Comments: >>> >>> a. Timetable for implementation: Immediate >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to >>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contact info at arin.net if you experience any issues. >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjones at vt.edu Wed Nov 22 09:30:48 2017 From: bjones at vt.edu (Brian Jones) Date: Wed, 22 Nov 2017 14:30:48 +0000 Subject: [arin-ppml] Draft Policy ARIN-2017-10: Repeal of Immediate Need for IPv4 Address Space (NRPM Section 4.2.1.6) In-Reply-To: <0ea280c3-adf7-1ee3-422f-5bd39b75a31c@arin.net> References: <0ea280c3-adf7-1ee3-422f-5bd39b75a31c@arin.net> Message-ID: I support this draft policy as written. Brian Jones On Tue, Nov 21, 2017, 17:42 ARIN wrote: > On 16 November 2017, the ARIN Advisory Council (AC) advanced > "ARIN-prop-245: Repeal of Immediate Need for IPv4 Address Space (NRPM > Section 4.2.1.6)" to Draft Policy status. > > Draft Policy ARIN-2017-10 is below and can be found at: > https://www.arin.net/policy/proposals/2017_10.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-10: Repeal of Immediate Need for IPv4 Address > Space (NRPM Section 4.2.1.6) > > Problem Statement: > > Section 4.2.1.6 of the ARIN Numbering Resource Policy Manual (NRPM) > provides that an ISP having an immediate need for IPv4 address space > that will be utilized within thirty days of a request may obtain a block > of IPv4 address space of the size specified in section 4.2.1.6 from ARIN > on an exceptional basis. However, as noted in the ARIN 40 Policy > Experience Report, since IPv4 exhaustion, obtaining IPv4 addresses in > this manner is no longer possible as a practical matter. Instead an ISP > must join the waiting list and wait until it reaches the front of the > queue to obtain any IPv4 address space, however long that may take. In > effect, section 4.2.1.6 is non-operative. Accordingly, its continued > presence in the NRPM is misleading and confusing. > > Policy statement: > > Section 4.2.1.6 of the NRPM is hereby repealed and section number > 4.2.1.6 is hereby retired. > > Comments: > > a. Timetable for implementation: Immediate > > b. Comments: Given the constraints created by the exhaustion of IPv4 > addresses, this proposal does not require any changes in the current > ARIN practices for the allocation of IPv4 address space. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage 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 ppml at rsuc.gweep.net Wed Nov 22 11:01:59 2017 From: ppml at rsuc.gweep.net (Joe Provo) Date: Wed, 22 Nov 2017 11:01:59 -0500 Subject: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment In-Reply-To: References: Message-ID: <20171122160159.GA41025@gweep.net> On Tue, Nov 21, 2017 at 06:13:46PM -0500, David Huberman wrote: > Thank you Scott. As the co-author, I very much recognize this > proposal text is a ???first draft???. Working with my co-author > Jason Schiller, and having solicited feedback from the AC, this > proposal was submitted to solve the general problem. My hope was > the mechanics would be looked at critically by the community during > the PDP, and we would work together to improve them. With my personal hat on I'm very happy to see this getting to discussion. +100 for intent and I look forward to useful language suggestions here. -- Posted from my personal account - see X-Disclaimer header. Joe Provo / Gweep / Earthling From SRyerse at eclipse-networks.com Wed Nov 22 11:59:51 2017 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Wed, 22 Nov 2017 16:59:51 +0000 Subject: [arin-ppml] Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers In-Reply-To: <846F1403-01F5-4DA1-A241-3B58108E111C@quark.net> References: <652abd11-68d7-900e-7776-b97b2311ea05@arin.net> , <846F1403-01F5-4DA1-A241-3B58108E111C@quark.net> Message-ID: <8FD93FEB-0B7A-4DD0-8496-6446B35A47A3@eclipse-networks.com> Yes I would like that change. Sent from my iPhone On Nov 21, 2017, at 10:28 PM, Andrew Dul > wrote: It sounds like our recollections of what we intended for ISP initial allocations have diverged. I will admit when I drafted the problem statement I did not go back through email to see if there was anything about this issue. Assuming we harmonize the problem statement, would you prefer the /24 as initial no questions asked size or a /21? What do others prefer? .Andrew On Nov 21, 2017, at 2:52 PM, Scott Leibrand > wrote: I believe this problem statement is incorrect, and therefore oppose the policy proposal as-is. 8.5.4 was intended (by me, as one of the authors, and in PPML discussions I just pulled up) to allow ISPs to transfer a /24 without justification. It was *not* intended to "match the previous policy" in 4.2.2. 8.5.5 reads "8.5.5. Block size Organizations may qualify for the transfer of a larger initial block, or an additional block, by providing documentation to ARIN which details the use of at least 50% of the requested IPv4 block size within 24 months. An officer of the organization shall attest to the documentation provided to ARIN." The intention was that any ISP needing a /21 would need to "provide documentation to ARIN which details the use of at least 50% of the requested IPv4 block size within 24 months", with officer attestation to same. If that policy is deemed insufficient, and we believe it's better to allow transfers of up to /21 without providing documentation to ARIN and officer attestation of such, then this proposal would need to be re-written with a new problem statement justifying that. -Scott On Tue, Nov 21, 2017 at 2:40 PM, ARIN > wrote: On 16 November 2017, the ARIN Advisory Council (AC) advanced "ARIN-prop-244: Clarification of Initial Block Size for IPv4 ISP Transfers" to Draft Policy status. Draft Policy ARIN-2017-9 is below and can be found at: https://www.arin.net/policy/proposals/2017_9.html You are encouraged to discuss all Draft Policies on PPML. The AC will evaluate the discussion in order to assess the conformance of this draft policy with ARIN's Principles of Internet number resource policy as stated in the Policy Development Process (PDP). Specifically, these principles are: * Enabling Fair and Impartial Number Resource Administration * Technically Sound * Supported by the Community The PDP can be found at: https://www.arin.net/policy/pdp.html Draft Policies and Proposals under discussion can be found at: https://www.arin.net/policy/proposals/index.html Regards, Sean Hopkins Policy Analyst American Registry for Internet Numbers (ARIN) Draft Policy ARIN-2017-9: Clarification of Initial Block Size for IPv4 ISP Transfers Problem Statement: It was noted at the ARIN 40 Policy Experience Report, that there is an inconsistency in the initial block size for ISPs. Section 4.2.2 notes that the initial ISP block size should be /21 whereas the initial block size in 8.5.4 is noted as "minimum transfer size" which is effectively a /24. The intent of the new 8.5.4 was to match the previous policy. This policy is intended to clarify this issue. It was noted that ARIN staff current operational practice is to allow ISPs an initial /21 for Section 8 transfers. Policy statement: Add the following to 8.5.4 ISP organizations without direct assignments or allocations from ARIN qualify for an initial allocation of up to a /21. Comments: a. Timetable for implementation: Immediate _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From adalle at ncf.ca Wed Nov 22 18:20:22 2017 From: adalle at ncf.ca (Andre Dalle) Date: Wed, 22 Nov 2017 18:20:22 -0500 (EST) Subject: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment In-Reply-To: <20171122160159.GA41025@gweep.net> References: <20171122160159.GA41025@gweep.net> Message-ID: <1965618547.183023.1511392822657.JavaMail.zimbra@ncf.ca> All my IPv4 space is reassigned, and I discovered last year that not all of it - from the same carrier - is properly associated with us. Upstream created a POC for us (even though we were an existing customer with multiple reassignments), and it's been sluggish getting them to sort it out. We have rDNS, so most abuse reporting still finds us, but some abuse mechanisms out there rely on POC info. So I think this is necessary. +100 from here as well. ---- Andr? Dalle Systems Administrator National Capital FreeNet [http://www.ncf.ca] ----- Original Message ----- From: "Joe Provo" To: "ARIN-PPML List" Sent: Wednesday, 22 November, 2017 11:01:59 Subject: Re: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment On Tue, Nov 21, 2017 at 06:13:46PM -0500, David Huberman wrote: > Thank you Scott. As the co-author, I very much recognize this > proposal text is a ???first draft???. Working with my co-author > Jason Schiller, and having solicited feedback from the AC, this > proposal was submitted to solve the general problem. My hope was > the mechanics would be looked at critically by the community during > the PDP, and we would work together to improve them. With my personal hat on I'm very happy to see this getting to discussion. +100 for intent and I look forward to useful language suggestions here. -- Posted from my personal account - see X-Disclaimer header. Joe Provo / Gweep / Earthling _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage 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 rs-lists at seastrom.com Wed Nov 22 22:34:45 2017 From: rs-lists at seastrom.com (Rob Seastrom) Date: Wed, 22 Nov 2017 22:34:45 -0500 Subject: [arin-ppml] Post-ARIN-40 updates to 2017-4 In-Reply-To: <004a01d35fba$db358570$91a09050$@iptrading.com> References: <31C30A2F-129D-4CD7-98FA-EF41ACD05756@seastrom.com> <004a01d35fba$db358570$91a09050$@iptrading.com> Message-ID: It was brought to my attention that the policy statement as-written would result in a nonsensical introduction to 8.4. I updated "Add the following sentence after the first sentence of NRPM 8.4" in the working policy proposal to be "Replace the first sentence of NRPM 8.4 thus:". -r > On Nov 17, 2017, at 10:43 AM, Mike Burns wrote: > > I support as written for the reasons David describes. > > > From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of David Farmer > Sent: Friday, November 17, 2017 10:27 AM > To: Rob Seastrom > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Post-ARIN-40 updates to 2017-4 > > I support this policy as written. > > The current reciprocity requirement does not recognize that the vast majority of IPv4 transfers are out of the ARIN region and the vast majority of the supply of IPv4 resources available for transfer exist within the ARIN region. Finally there are legitimate operational reasons that companies within the ARIN region need to transfer resources to themselves or their foreign subsidiaries in other regions regardless of reciprocal transfer policies being available. > > Thank you for simplifying the text. > > > On Fri, Nov 17, 2017 at 7:12 AM, Rob Seastrom wrote: >> >> Dear Colleagues, >> >> Based on feedback received at the ARIN-40 conference, the AC Shepherds have updated Draft Policy 2017-4 - "Remove bidirectional requirement for inter-RIR transfers". >> >> The proposal in its entirety is below. We seek feedback and comment. >> >> >> 2017-4 - Remove bidirectional requirement for inter-RIR transfers >> >> Problem Statement: >> ARIN?s inter-RIR transfer policy is functionally one-way, so the assertion of a reciprocal two-way requirement is gratuitous. >> >> Policy statement: >> Add the following sentence after the first sentence of NRPM 8.4: >> Inter-RIR transfers may take place only via RIRs who agree to the transfer and share compatible, needs-based policies. >> >> 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. > > > > -- > =============================================== > 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 narten at us.ibm.com Fri Nov 24 00:53:03 2017 From: narten at us.ibm.com (narten at us.ibm.com) Date: Fri, 24 Nov 2017 00:53:03 -0500 Subject: [arin-ppml] Weekly posting summary for ppml@arin.net Message-ID: <201711240553.vAO5r3Gu025842@rotala.raleigh.ibm.com> Total of 29 messages in the last 7 days. script run at: Fri Nov 24 00:53:03 EST 2017 Messages | Bytes | Who --------+------+--------+----------+------------------------ 20.69% | 6 | 23.35% | 123353 | scottleibrand at gmail.com 20.69% | 6 | 12.99% | 68641 | info at arin.net 3.45% | 1 | 14.51% | 76636 | rudi.daniel at gmail.com 6.90% | 2 | 7.79% | 41150 | farmer at umn.edu 6.90% | 2 | 3.36% | 17758 | rs-lists at seastrom.com 3.45% | 1 | 4.73% | 24965 | hostmaster at uneedus.com 3.45% | 1 | 4.70% | 24842 | sryerse at eclipse-networks.com 3.45% | 1 | 4.63% | 24442 | theone at uneedus.com 3.45% | 1 | 4.38% | 23137 | andrew.dul at quark.net 3.45% | 1 | 4.08% | 21565 | daveid at panix.com 3.45% | 1 | 3.31% | 17510 | bjones at vt.edu 3.45% | 1 | 3.27% | 17299 | mike at iptrading.com 3.45% | 1 | 1.93% | 10209 | adalle at ncf.ca 3.45% | 1 | 1.93% | 10194 | hvgeekwtrvl at gmail.com 3.45% | 1 | 1.87% | 9898 | narten at us.ibm.com 3.45% | 1 | 1.71% | 9054 | chris at semihuman.com 3.45% | 1 | 1.44% | 7611 | ppml at rsuc.gweep.net --------+------+--------+----------+------------------------ 100.00% | 29 |100.00% | 528264 | Total From austin.murkland at qscend.com Mon Nov 27 15:20:08 2017 From: austin.murkland at qscend.com (Austin Murkland) Date: Mon, 27 Nov 2017 15:20:08 -0500 Subject: [arin-ppml] Draft Policy ARIN-2017-10: Repeal of Immediate Need for IPv4 Address Space (NRPM Section 4.2.1.6) In-Reply-To: References: <0ea280c3-adf7-1ee3-422f-5bd39b75a31c@arin.net> Message-ID: I support as written. On Wed, Nov 22, 2017 at 9:30 AM, Brian Jones wrote: > I support this draft policy as written. > > Brian Jones > > > On Tue, Nov 21, 2017, 17:42 ARIN wrote: > >> On 16 November 2017, the ARIN Advisory Council (AC) advanced >> "ARIN-prop-245: Repeal of Immediate Need for IPv4 Address Space (NRPM >> Section 4.2.1.6)" to Draft Policy status. >> >> Draft Policy ARIN-2017-10 is below and can be found at: >> https://www.arin.net/policy/proposals/2017_10.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-10: Repeal of Immediate Need for IPv4 Address >> Space (NRPM Section 4.2.1.6) >> >> Problem Statement: >> >> Section 4.2.1.6 of the ARIN Numbering Resource Policy Manual (NRPM) >> provides that an ISP having an immediate need for IPv4 address space >> that will be utilized within thirty days of a request may obtain a block >> of IPv4 address space of the size specified in section 4.2.1.6 from ARIN >> on an exceptional basis. However, as noted in the ARIN 40 Policy >> Experience Report, since IPv4 exhaustion, obtaining IPv4 addresses in >> this manner is no longer possible as a practical matter. Instead an ISP >> must join the waiting list and wait until it reaches the front of the >> queue to obtain any IPv4 address space, however long that may take. In >> effect, section 4.2.1.6 is non-operative. Accordingly, its continued >> presence in the NRPM is misleading and confusing. >> >> Policy statement: >> >> Section 4.2.1.6 of the NRPM is hereby repealed and section number >> 4.2.1.6 is hereby retired. >> >> Comments: >> >> a. Timetable for implementation: Immediate >> >> b. Comments: Given the constraints created by the exhaustion of IPv4 >> addresses, this proposal does not require any changes in the current >> ARIN practices for the allocation of IPv4 address space. >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage 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 adalle at ncf.ca Mon Nov 27 15:23:01 2017 From: adalle at ncf.ca (Andre Dalle) Date: Mon, 27 Nov 2017 15:23:01 -0500 (EST) Subject: [arin-ppml] Draft Policy ARIN-2017-10: Repeal of Immediate Need for IPv4 Address Space (NRPM Section 4.2.1.6) In-Reply-To: <0ea280c3-adf7-1ee3-422f-5bd39b75a31c@arin.net> References: <0ea280c3-adf7-1ee3-422f-5bd39b75a31c@arin.net> Message-ID: <1602917767.167244.1511814181456.JavaMail.zimbra@ncf.ca> Support as written. ---- Andr? Dalle Systems Administrator National Capital FreeNet [http://www.ncf.ca] ----- Original Message ----- From: "ARIN" To: arin-ppml at arin.net Sent: Tuesday, 21 November, 2017 17:42:02 Subject: [arin-ppml] Draft Policy ARIN-2017-10: Repeal of Immediate Need for IPv4 Address Space (NRPM Section 4.2.1.6) On 16 November 2017, the ARIN Advisory Council (AC) advanced "ARIN-prop-245: Repeal of Immediate Need for IPv4 Address Space (NRPM Section 4.2.1.6)" to Draft Policy status. Draft Policy ARIN-2017-10 is below and can be found at: https://www.arin.net/policy/proposals/2017_10.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-10: Repeal of Immediate Need for IPv4 Address Space (NRPM Section 4.2.1.6) Problem Statement: Section 4.2.1.6 of the ARIN Numbering Resource Policy Manual (NRPM) provides that an ISP having an immediate need for IPv4 address space that will be utilized within thirty days of a request may obtain a block of IPv4 address space of the size specified in section 4.2.1.6 from ARIN on an exceptional basis. However, as noted in the ARIN 40 Policy Experience Report, since IPv4 exhaustion, obtaining IPv4 addresses in this manner is no longer possible as a practical matter. Instead an ISP must join the waiting list and wait until it reaches the front of the queue to obtain any IPv4 address space, however long that may take. In effect, section 4.2.1.6 is non-operative. Accordingly, its continued presence in the NRPM is misleading and confusing. Policy statement: Section 4.2.1.6 of the NRPM is hereby repealed and section number 4.2.1.6 is hereby retired. Comments: a. Timetable for implementation: Immediate b. Comments: Given the constraints created by the exhaustion of IPv4 addresses, this proposal does not require any changes in the current ARIN practices for the allocation of IPv4 address space. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage 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 austin.murkland at qscend.com Mon Nov 27 15:26:16 2017 From: austin.murkland at qscend.com (Austin Murkland) Date: Mon, 27 Nov 2017 15:26:16 -0500 Subject: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment In-Reply-To: <1965618547.183023.1511392822657.JavaMail.zimbra@ncf.ca> References: <20171122160159.GA41025@gweep.net> <1965618547.183023.1511392822657.JavaMail.zimbra@ncf.ca> Message-ID: Also support this On Wed, Nov 22, 2017 at 6:20 PM, Andre Dalle wrote: > > All my IPv4 space is reassigned, and I discovered last year that not all > of it - from the same carrier - is properly associated with us. > > Upstream created a POC for us (even though we were an existing customer > with multiple reassignments), and it's been sluggish getting them to > sort it out. We have rDNS, so most abuse reporting still finds us, but > some abuse mechanisms out there rely on POC info. > > So I think this is necessary. +100 from here as well. > > ---- > Andr? Dalle > Systems Administrator > National Capital FreeNet [http://www.ncf.ca] > > ----- Original Message ----- > From: "Joe Provo" > To: "ARIN-PPML List" > Sent: Wednesday, 22 November, 2017 11:01:59 > Subject: Re: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC > Validation Upon Reassignment > > On Tue, Nov 21, 2017 at 06:13:46PM -0500, David Huberman wrote: > > Thank you Scott. As the co-author, I very much recognize this > > proposal text is a ???first draft???. Working with my co-author > > Jason Schiller, and having solicited feedback from the AC, this > > proposal was submitted to solve the general problem. My hope was > > the mechanics would be looked at critically by the community during > > the PDP, and we would work together to improve them. > > With my personal hat on I'm very happy to see this getting > to discussion. +100 for intent and I look forward to useful > language suggestions here. > > -- > Posted from my personal account - see X-Disclaimer header. > Joe Provo / Gweep / Earthling > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage 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 Nov 27 15:29:43 2017 From: abagrin at omninet.io (Andrew Bagrin) Date: Mon, 27 Nov 2017 15:29:43 -0500 Subject: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment In-Reply-To: References: <20171122160159.GA41025@gweep.net> <1965618547.183023.1511392822657.JavaMail.zimbra@ncf.ca> Message-ID: <93433147c4783f7fe66d9ee1a9e38d54@mail.gmail.com> Me three. *From:* ARIN-PPML [mailto:arin-ppml-bounces at arin.net] *On Behalf Of *Austin Murkland *Sent:* Monday, November 27, 2017 3:26 PM *To:* Andre Dalle *Cc:* ARIN-PPML List *Subject:* Re: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment Also support this On Wed, Nov 22, 2017 at 6:20 PM, Andre Dalle wrote: All my IPv4 space is reassigned, and I discovered last year that not all of it - from the same carrier - is properly associated with us. Upstream created a POC for us (even though we were an existing customer with multiple reassignments), and it's been sluggish getting them to sort it out. We have rDNS, so most abuse reporting still finds us, but some abuse mechanisms out there rely on POC info. So I think this is necessary. +100 from here as well. ---- Andr? Dalle Systems Administrator National Capital FreeNet [http://www.ncf.ca] ----- Original Message ----- From: "Joe Provo" To: "ARIN-PPML List" Sent: Wednesday, 22 November, 2017 11:01:59 Subject: Re: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment On Tue, Nov 21, 2017 at 06:13:46PM -0500, David Huberman wrote: > Thank you Scott. As the co-author, I very much recognize this > proposal text is a ???first draft???. Working with my co-author > Jason Schiller, and having solicited feedback from the AC, this > proposal was submitted to solve the general problem. My hope was > the mechanics would be looked at critically by the community during > the PDP, and we would work together to improve them. With my personal hat on I'm very happy to see this getting to discussion. +100 for intent and I look forward to useful language suggestions here. -- Posted from my personal account - see X-Disclaimer header. Joe Provo / Gweep / Earthling _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage 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 Nov 27 15:35:08 2017 From: abagrin at omninet.io (Andrew Bagrin) Date: Mon, 27 Nov 2017 15:35:08 -0500 Subject: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment In-Reply-To: References: <20171122160159.GA41025@gweep.net> <1965618547.183023.1511392822657.JavaMail.zimbra@ncf.ca> Message-ID: <0d4075293a247645e6bf46b7343b767c@mail.gmail.com> I?d also like to see a $100 monthly fee per IPv4 /24 currently assigned. I held onto a /16 at a previous company, just because it was cool but had no use for it. I checked recently and it is still assigned to the same company and not being used 15 years later. By adding a $25k monthly fee, they would quickly return the block. Currently we have to pay brokers or sellers to acquire more IPv4 space. I would rather pay ARIN which could go to better funding the organization. *From:* ARIN-PPML [mailto:arin-ppml-bounces at arin.net] *On Behalf Of *Austin Murkland *Sent:* Monday, November 27, 2017 3:26 PM *To:* Andre Dalle *Cc:* ARIN-PPML List *Subject:* Re: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment Also support this On Wed, Nov 22, 2017 at 6:20 PM, Andre Dalle wrote: All my IPv4 space is reassigned, and I discovered last year that not all of it - from the same carrier - is properly associated with us. Upstream created a POC for us (even though we were an existing customer with multiple reassignments), and it's been sluggish getting them to sort it out. We have rDNS, so most abuse reporting still finds us, but some abuse mechanisms out there rely on POC info. So I think this is necessary. +100 from here as well. ---- Andr? Dalle Systems Administrator National Capital FreeNet [http://www.ncf.ca] ----- Original Message ----- From: "Joe Provo" To: "ARIN-PPML List" Sent: Wednesday, 22 November, 2017 11:01:59 Subject: Re: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment On Tue, Nov 21, 2017 at 06:13:46PM -0500, David Huberman wrote: > Thank you Scott. As the co-author, I very much recognize this > proposal text is a ???first draft???. Working with my co-author > Jason Schiller, and having solicited feedback from the AC, this > proposal was submitted to solve the general problem. My hope was > the mechanics would be looked at critically by the community during > the PDP, and we would work together to improve them. With my personal hat on I'm very happy to see this getting to discussion. +100 for intent and I look forward to useful language suggestions here. -- Posted from my personal account - see X-Disclaimer header. Joe Provo / Gweep / Earthling _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage 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 oroberts at bell.ca Mon Nov 27 15:42:14 2017 From: oroberts at bell.ca (Roberts, Orin) Date: Mon, 27 Nov 2017 20:42:14 +0000 Subject: [arin-ppml] Draft Policy ARIN-2017-10: Repeal of Immediate Need for IPv4 Address Space (NRPM Section 4.2.1.6) In-Reply-To: References: <0ea280c3-adf7-1ee3-422f-5bd39b75a31c@arin.net> Message-ID: I also support this draft policy as written, no more jumping to the front of the queue. Go IPv6. Orin Roberts From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Brian Jones Sent: November-22-17 9:31 AM To: ARIN Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2017-10: Repeal of Immediate Need for IPv4 Address Space (NRPM Section 4.2.1.6) I support this draft policy as written. Brian Jones On Tue, Nov 21, 2017, 17:42 ARIN > wrote: On 16 November 2017, the ARIN Advisory Council (AC) advanced "ARIN-prop-245: Repeal of Immediate Need for IPv4 Address Space (NRPM Section 4.2.1.6)" to Draft Policy status. Draft Policy ARIN-2017-10 is below and can be found at: https://www.arin.net/policy/proposals/2017_10.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-10: Repeal of Immediate Need for IPv4 Address Space (NRPM Section 4.2.1.6) Problem Statement: Section 4.2.1.6 of the ARIN Numbering Resource Policy Manual (NRPM) provides that an ISP having an immediate need for IPv4 address space that will be utilized within thirty days of a request may obtain a block of IPv4 address space of the size specified in section 4.2.1.6 from ARIN on an exceptional basis. However, as noted in the ARIN 40 Policy Experience Report, since IPv4 exhaustion, obtaining IPv4 addresses in this manner is no longer possible as a practical matter. Instead an ISP must join the waiting list and wait until it reaches the front of the queue to obtain any IPv4 address space, however long that may take. In effect, section 4.2.1.6 is non-operative. Accordingly, its continued presence in the NRPM is misleading and confusing. Policy statement: Section 4.2.1.6 of the NRPM is hereby repealed and section number 4.2.1.6 is hereby retired. Comments: a. Timetable for implementation: Immediate b. Comments: Given the constraints created by the exhaustion of IPv4 addresses, this proposal does not require any changes in the current ARIN practices for the allocation of IPv4 address space. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at iptrading.com Mon Nov 27 15:46:54 2017 From: mike at iptrading.com (Mike Burns) Date: Mon, 27 Nov 2017 15:46:54 -0500 Subject: [arin-ppml] Draft Policy ARIN-2017-10: Repeal of Immediate Need for IPv4 Address Space (NRPM Section 4.2.1.6) In-Reply-To: References: <0ea280c3-adf7-1ee3-422f-5bd39b75a31c@arin.net> Message-ID: <069901d367c0$dc597bb0$950c7310$@iptrading.com> Support as written and appreciate the pruning of the NRPM. Mike Burns From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Roberts, Orin Sent: Monday, November 27, 2017 3:42 PM To: ARIN Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2017-10: Repeal of Immediate Need for IPv4 Address Space (NRPM Section 4.2.1.6) I also support this draft policy as written, no more jumping to the front of the queue. Go IPv6. Orin Roberts From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Brian Jones Sent: November-22-17 9:31 AM To: ARIN > Cc: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2017-10: Repeal of Immediate Need for IPv4 Address Space (NRPM Section 4.2.1.6) I support this draft policy as written. Brian Jones On Tue, Nov 21, 2017, 17:42 ARIN > wrote: On 16 November 2017, the ARIN Advisory Council (AC) advanced "ARIN-prop-245: Repeal of Immediate Need for IPv4 Address Space (NRPM Section 4.2.1.6)" to Draft Policy status. Draft Policy ARIN-2017-10 is below and can be found at: https://www.arin.net/policy/proposals/2017_10.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-10: Repeal of Immediate Need for IPv4 Address Space (NRPM Section 4.2.1.6) Problem Statement: Section 4.2.1.6 of the ARIN Numbering Resource Policy Manual (NRPM) provides that an ISP having an immediate need for IPv4 address space that will be utilized within thirty days of a request may obtain a block of IPv4 address space of the size specified in section 4.2.1.6 from ARIN on an exceptional basis. However, as noted in the ARIN 40 Policy Experience Report, since IPv4 exhaustion, obtaining IPv4 addresses in this manner is no longer possible as a practical matter. Instead an ISP must join the waiting list and wait until it reaches the front of the queue to obtain any IPv4 address space, however long that may take. In effect, section 4.2.1.6 is non-operative. Accordingly, its continued presence in the NRPM is misleading and confusing. Policy statement: Section 4.2.1.6 of the NRPM is hereby repealed and section number 4.2.1.6 is hereby retired. Comments: a. Timetable for implementation: Immediate b. Comments: Given the constraints created by the exhaustion of IPv4 addresses, this proposal does not require any changes in the current ARIN practices for the allocation of IPv4 address space. _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact info at arin.net if you experience any issues. -------------- next part -------------- An HTML attachment was scrubbed... URL: From scottleibrand at gmail.com Mon Nov 27 15:56:00 2017 From: scottleibrand at gmail.com (Scott Leibrand) Date: Mon, 27 Nov 2017 12:56:00 -0800 Subject: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment In-Reply-To: <0d4075293a247645e6bf46b7343b767c@mail.gmail.com> References: <20171122160159.GA41025@gweep.net> <1965618547.183023.1511392822657.JavaMail.zimbra@ncf.ca> <0d4075293a247645e6bf46b7343b767c@mail.gmail.com> Message-ID: This would be a new policy proposal. If you'd like to discuss it before deciding whether to formally propose something, I would recommend a new thread, as it's off-topic for this thread. -Scott On Mon, Nov 27, 2017 at 12:35 PM, Andrew Bagrin wrote: > I?d also like to see a $100 monthly fee per IPv4 /24 currently assigned. > > > > I held onto a /16 at a previous company, just because it was cool but had > no use for it. I checked recently and it is still assigned to the same > company and not being used 15 years later. > > > > By adding a $25k monthly fee, they would quickly return the block. > > > > Currently we have to pay brokers or sellers to acquire more IPv4 space. I > would rather pay ARIN which could go to better funding the organization. > > > > *From:* ARIN-PPML [mailto:arin-ppml-bounces at arin.net] *On Behalf Of *Austin > Murkland > *Sent:* Monday, November 27, 2017 3:26 PM > *To:* Andre Dalle > *Cc:* ARIN-PPML List > *Subject:* Re: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC > Validation Upon Reassignment > > > > Also support this > > > > On Wed, Nov 22, 2017 at 6:20 PM, Andre Dalle wrote: > > > All my IPv4 space is reassigned, and I discovered last year that not all > of it - from the same carrier - is properly associated with us. > > Upstream created a POC for us (even though we were an existing customer > with multiple reassignments), and it's been sluggish getting them to > sort it out. We have rDNS, so most abuse reporting still finds us, but > some abuse mechanisms out there rely on POC info. > > So I think this is necessary. +100 from here as well. > > ---- > Andr? Dalle > Systems Administrator > National Capital FreeNet [http://www.ncf.ca] > > > ----- Original Message ----- > From: "Joe Provo" > To: "ARIN-PPML List" > Sent: Wednesday, 22 November, 2017 11:01:59 > Subject: Re: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC > Validation Upon Reassignment > > On Tue, Nov 21, 2017 at 06:13:46PM -0500, David Huberman wrote: > > Thank you Scott. As the co-author, I very much recognize this > > proposal text is a ???first draft???. Working with my co-author > > Jason Schiller, and having solicited feedback from the AC, this > > proposal was submitted to solve the general problem. My hope was > > the mechanics would be looked at critically by the community during > > the PDP, and we would work together to improve them. > > With my personal hat on I'm very happy to see this getting > to discussion. +100 for intent and I look forward to useful > language suggestions here. > > -- > Posted from my personal account - see X-Disclaimer header. > Joe Provo / Gweep / Earthling > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage 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 oroberts at bell.ca Mon Nov 27 15:58:55 2017 From: oroberts at bell.ca (Roberts, Orin) Date: Mon, 27 Nov 2017 20:58:55 +0000 Subject: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment In-Reply-To: <0d4075293a247645e6bf46b7343b767c@mail.gmail.com> References: <20171122160159.GA41025@gweep.net> <1965618547.183023.1511392822657.JavaMail.zimbra@ncf.ca> <0d4075293a247645e6bf46b7343b767c@mail.gmail.com> Message-ID: I see obstacles but increased fees would lead to greater efficiency in IPv4 assignments and usage or at the very least aid in the migration to IPv6. A. Charging a monthly fee (or higher monthly fee), means increased costs to end-users for whatever services said company provides. B. ISP?s with VERY LARGE inventory of IPs would lobby against such a proposal. A typical ISP would have several /16?s in reservation - capacity planning. C. What?s to stop companies from doing what they do now? ? Reassign or Reallocate unused inventory (ie trade and monetize via brokers). Orin Roberts From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Andrew Bagrin Sent: November-27-17 3:35 PM To: Austin Murkland ; Andre Dalle Cc: ARIN-PPML List Subject: Re: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment I?d also like to see a $100 monthly fee per IPv4 /24 currently assigned. I held onto a /16 at a previous company, just because it was cool but had no use for it. I checked recently and it is still assigned to the same company and not being used 15 years later. By adding a $25k monthly fee, they would quickly return the block. Currently we have to pay brokers or sellers to acquire more IPv4 space. I would rather pay ARIN which could go to better funding the organization. From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Austin Murkland Sent: Monday, November 27, 2017 3:26 PM To: Andre Dalle > Cc: ARIN-PPML List > Subject: Re: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment Also support this On Wed, Nov 22, 2017 at 6:20 PM, Andre Dalle > wrote: All my IPv4 space is reassigned, and I discovered last year that not all of it - from the same carrier - is properly associated with us. Upstream created a POC for us (even though we were an existing customer with multiple reassignments), and it's been sluggish getting them to sort it out. We have rDNS, so most abuse reporting still finds us, but some abuse mechanisms out there rely on POC info. So I think this is necessary. +100 from here as well. ---- Andr? Dalle Systems Administrator National Capital FreeNet [http://www.ncf.ca] ----- Original Message ----- From: "Joe Provo" > To: "ARIN-PPML List" > Sent: Wednesday, 22 November, 2017 11:01:59 Subject: Re: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment On Tue, Nov 21, 2017 at 06:13:46PM -0500, David Huberman wrote: > Thank you Scott. As the co-author, I very much recognize this > proposal text is a ???first draft???. Working with my co-author > Jason Schiller, and having solicited feedback from the AC, this > proposal was submitted to solve the general problem. My hope was > the mechanics would be looked at critically by the community during > the PDP, and we would work together to improve them. With my personal hat on I'm very happy to see this getting to discussion. +100 for intent and I look forward to useful language suggestions here. -- Posted from my personal account - see X-Disclaimer header. Joe Provo / Gweep / Earthling _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage 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 SRyerse at eclipse-networks.com Mon Nov 27 16:08:35 2017 From: SRyerse at eclipse-networks.com (Steven Ryerse) Date: Mon, 27 Nov 2017 21:08:35 +0000 Subject: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment In-Reply-To: References: <20171122160159.GA41025@gweep.net> <1965618547.183023.1511392822657.JavaMail.zimbra@ncf.ca> <0d4075293a247645e6bf46b7343b767c@mail.gmail.com> Message-ID: I don?t see how you can go back and start charging Legacy holders that obtained their blocks before ARIN was created. You would have to charge big companies like AT&T & IBM and you would have to somehow charge the Dept. of Defense and so forth to make it fair to everyone. Seems like that ship sailed long ago. Steven Ryerse President 100 Ashford Center North, Suite 110, Atlanta, GA 30338 770.656.1460 - Cell 770.399.9099 - Office 770.392.0076 - Fax [Description: Description: Eclipse Networks Logo_small.png]? Eclipse Networks, Inc. Conquering Complex Networks? From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Roberts, Orin Sent: Monday, November 27, 2017 3:59 PM To: Andrew Bagrin Cc: ARIN-PPML List Subject: Re: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment I see obstacles but increased fees would lead to greater efficiency in IPv4 assignments and usage or at the very least aid in the migration to IPv6. 1. Charging a monthly fee (or higher monthly fee), means increased costs to end-users for whatever services said company provides. 2. ISP?s with VERY LARGE inventory of IPs would lobby against such a proposal. A typical ISP would have several /16?s in reservation - capacity planning. 3. What?s to stop companies from doing what they do now? ? Reassign or Reallocate unused inventory (ie trade and monetize via brokers). Orin Roberts From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Andrew Bagrin Sent: November-27-17 3:35 PM To: Austin Murkland >; Andre Dalle > Cc: ARIN-PPML List > Subject: Re: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment I?d also like to see a $100 monthly fee per IPv4 /24 currently assigned. I held onto a /16 at a previous company, just because it was cool but had no use for it. I checked recently and it is still assigned to the same company and not being used 15 years later. By adding a $25k monthly fee, they would quickly return the block. Currently we have to pay brokers or sellers to acquire more IPv4 space. I would rather pay ARIN which could go to better funding the organization. From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of Austin Murkland Sent: Monday, November 27, 2017 3:26 PM To: Andre Dalle > Cc: ARIN-PPML List > Subject: Re: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment Also support this On Wed, Nov 22, 2017 at 6:20 PM, Andre Dalle > wrote: All my IPv4 space is reassigned, and I discovered last year that not all of it - from the same carrier - is properly associated with us. Upstream created a POC for us (even though we were an existing customer with multiple reassignments), and it's been sluggish getting them to sort it out. We have rDNS, so most abuse reporting still finds us, but some abuse mechanisms out there rely on POC info. So I think this is necessary. +100 from here as well. ---- Andr? Dalle Systems Administrator National Capital FreeNet [http://www.ncf.ca] ----- Original Message ----- From: "Joe Provo" > To: "ARIN-PPML List" > Sent: Wednesday, 22 November, 2017 11:01:59 Subject: Re: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment On Tue, Nov 21, 2017 at 06:13:46PM -0500, David Huberman wrote: > Thank you Scott. As the co-author, I very much recognize this > proposal text is a ???first draft???. Working with my co-author > Jason Schiller, and having solicited feedback from the AC, this > proposal was submitted to solve the general problem. My hope was > the mechanics would be looked at critically by the community during > the PDP, and we would work together to improve them. With my personal hat on I'm very happy to see this getting to discussion. +100 for intent and I look forward to useful language suggestions here. -- Posted from my personal account - see X-Disclaimer header. Joe Provo / Gweep / Earthling _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). Unsubscribe or manage 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: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 1468 bytes Desc: image001.jpg URL: From bjones at vt.edu Mon Nov 27 16:28:18 2017 From: bjones at vt.edu (Brian Jones) Date: Mon, 27 Nov 2017 16:28:18 -0500 Subject: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment In-Reply-To: References: Message-ID: I support this proposal in principle. I'm not sure that 10 days is enough time to work out a valid POC in some cases. If it is a new POC they need to be made aware of what it means to be the POC and what is expected of them, and some folks may want to set up a listserv or email group and make sure all the members of the group understand the role associated with being a POC. -- Brian ? Jones? On Tue, Nov 21, 2017 at 5:43 PM, ARIN wrote: > On 16 November 2017, the ARIN Advisory Council (AC) advanced > "ARIN-prop-247: Require New POC Validation Upon Reassignment" to Draft > Policy status. > > Draft Policy ARIN-2017-12 is below and can be found at: > https://www.arin.net/policy/proposals/2017_12.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-12: Require New POC Validation Upon Reassignment > > Problem Statement: > > Some large ISPs assign individuals to be POCs for reassigned blocks > without consultation of the individual they are inserting into Whois. One > year later, the POC is contacted by ARIN as part of Annual POC Validation > policies. The POC often does not know who ARIN is, what Whois is, and why > they are in Whois. > > This policy proposal seeks to improve the situation where a POC is > unwittingly and unwantingly inserted into Whois. > > It also seeks to mitigate the significant amount of time that ARIN staff > reports that they spend fielding phone calls from POCs who have no idea > they are in Whois. > > Finally, it is hopeful that this proposal will improve the overall POC > validation situation, by forcing ISPs and customers to work together to > insert proper information into Whois at the time of sub-delegation. > > Policy statement: > > Insert two new sections into NRPM 3: > > 3.7 New POC Validation Upon Reassignment > > When an ISP submits a valid reallocation or detailed reassignment request > to ARIN which would result in a new POC object being created, ARIN must > (before otherwise approving the request) contact the new POC by email for > validation. ARIN's notification will, at a minimum, notify the POC of: > > - the information about the organization submitting the record; and > - the resource(s) to which the POC is being attached; and > - the organization(s) to which the POC is being attached. > > If the POC validates the request, the request shall be accepted by ARIN > and the new objects inserted into Whois. If the POC does not validate the > request within 10 days, ARIN must reject the request. > > 3.8 Downstream Validation of Simple Reassignments > > When an ISP submits a valid simple reassigment request to ARIN with an > organization name OR postal address that is identical to one or more > existing OrgIDs, ARIN will notify the downstream organization and obtain > guidance on whether to accept the simple reassigment, or redirect it to one > of the existing OrgIDs as a detailed reassignment. > > 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 owen at delong.com Mon Nov 27 19:24:00 2017 From: owen at delong.com (Owen DeLong) Date: Mon, 27 Nov 2017 16:24:00 -0800 Subject: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment In-Reply-To: References: <20171122160159.GA41025@gweep.net> <1965618547.183023.1511392822657.JavaMail.zimbra@ncf.ca> <0d4075293a247645e6bf46b7343b767c@mail.gmail.com> Message-ID: Before we travel too far down this branch of discussion, I?d like to point out that fees are not within the realm of ARIN policy debate and therefore aren?t really an appropriate topic for this list. If you?d like to discuss such a fee, there is arin-discuss (open to Members/Staff/Board/AC) where fee discussions are appropriate. Alternatively, there is also the ARIN Consultation and Suggestion Process (ACSP) available via the Participate tab on the ARIN web site. Thanks, Owen > On Nov 27, 2017, at 13:08 , Steven Ryerse wrote: > > I don?t see how you can go back and start charging Legacy holders that obtained their blocks before ARIN was created. You would have to charge big companies like AT&T & IBM and you would have to somehow charge the Dept. of Defense and so forth to make it fair to everyone. Seems like that ship sailed long ago. > > > Steven Ryerse > President > 100 Ashford Center North, Suite 110, Atlanta, GA 30338 > 770.656.1460 - Cell > 770.399.9099 - Office > 770.392.0076 - Fax > > ? Eclipse Networks, Inc. > Conquering Complex Networks? > > From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net ] On Behalf Of Roberts, Orin > Sent: Monday, November 27, 2017 3:59 PM > To: Andrew Bagrin > > Cc: ARIN-PPML List > > Subject: Re: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment > > I see obstacles but increased fees would lead to greater efficiency in IPv4 assignments and usage or at the very least aid in the migration to IPv6. > > Charging a monthly fee (or higher monthly fee), means increased costs to end-users for whatever services said company provides. > ISP?s with VERY LARGE inventory of IPs would lobby against such a proposal. A typical ISP would have several /16?s in reservation - capacity planning. > What?s to stop companies from doing what they do now? ? Reassign or Reallocate unused inventory (ie trade and monetize via brokers). > > Orin Roberts > > From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net ] On Behalf Of Andrew Bagrin > Sent: November-27-17 3:35 PM > To: Austin Murkland >; Andre Dalle > > Cc: ARIN-PPML List > > Subject: Re: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment > > I?d also like to see a $100 monthly fee per IPv4 /24 currently assigned. > > I held onto a /16 at a previous company, just because it was cool but had no use for it. I checked recently and it is still assigned to the same company and not being used 15 years later. > > By adding a $25k monthly fee, they would quickly return the block. > > Currently we have to pay brokers or sellers to acquire more IPv4 space. I would rather pay ARIN which could go to better funding the organization. > ? <> > From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net ] On Behalf Of Austin Murkland > Sent: Monday, November 27, 2017 3:26 PM > To: Andre Dalle > > Cc: ARIN-PPML List > > Subject: Re: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment > > Also support this > > On Wed, Nov 22, 2017 at 6:20 PM, Andre Dalle > wrote: > > All my IPv4 space is reassigned, and I discovered last year that not all of it - from the same carrier - is properly associated with us. > > Upstream created a POC for us (even though we were an existing customer with multiple reassignments), and it's been sluggish getting them to > sort it out. We have rDNS, so most abuse reporting still finds us, but some abuse mechanisms out there rely on POC info. > > So I think this is necessary. +100 from here as well. > > ---- > Andr? Dalle > Systems Administrator > National Capital FreeNet [http://www.ncf.ca ] > > ----- Original Message ----- > From: "Joe Provo" > > To: "ARIN-PPML List" > > Sent: Wednesday, 22 November, 2017 11:01:59 > Subject: Re: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment > > On Tue, Nov 21, 2017 at 06:13:46PM -0500, David Huberman wrote: > > Thank you Scott. As the co-author, I very much recognize this > > proposal text is a ???first draft???. Working with my co-author > > Jason Schiller, and having solicited feedback from the AC, this > > proposal was submitted to solve the general problem. My hope was > > the mechanics would be looked at critically by the community during > > the PDP, and we would work together to improve them. > > With my personal hat on I'm very happy to see this getting > to discussion. +100 for intent and I look forward to useful > language suggestions here. > > -- > Posted from my personal account - see X-Disclaimer header. > Joe Provo / Gweep / Earthling > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). > Unsubscribe or manage 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 Nov 27 19:26:03 2017 From: owen at delong.com (Owen DeLong) Date: Mon, 27 Nov 2017 16:26:03 -0800 Subject: [arin-ppml] Draft Policy ARIN-2017-10: Repeal of Immediate Need for IPv4 Address Space (NRPM Section 4.2.1.6) In-Reply-To: References: <0ea280c3-adf7-1ee3-422f-5bd39b75a31c@arin.net> Message-ID: I am confused by your statement. Immediate need does not allow one to jump to the front of the queue, it merely provides an alternative means for justifying an initial allocation/assignment. Owen > On Nov 27, 2017, at 12:42 , Roberts, Orin wrote: > > I also support this draft policy as written, no more jumping to the front of the queue. Go IPv6. > > Orin Roberts > > > From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net ] On Behalf Of Brian Jones > Sent: November-22-17 9:31 AM > To: ARIN > > Cc: arin-ppml at arin.net > Subject: Re: [arin-ppml] Draft Policy ARIN-2017-10: Repeal of Immediate Need for IPv4 Address Space (NRPM Section 4.2.1.6) > > I support this draft policy as written. > > Brian Jones > > On Tue, Nov 21, 2017, 17:42 ARIN > wrote: > On 16 November 2017, the ARIN Advisory Council (AC) advanced > "ARIN-prop-245: Repeal of Immediate Need for IPv4 Address Space (NRPM > Section 4.2.1.6)" to Draft Policy status. > > Draft Policy ARIN-2017-10 is below and can be found at: > https://www.arin.net/policy/proposals/2017_10.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-10: Repeal of Immediate Need for IPv4 Address > Space (NRPM Section 4.2.1.6) > > Problem Statement: > > Section 4.2.1.6 of the ARIN Numbering Resource Policy Manual (NRPM) > provides that an ISP having an immediate need for IPv4 address space > that will be utilized within thirty days of a request may obtain a block > of IPv4 address space of the size specified in section 4.2.1.6 from ARIN > on an exceptional basis. However, as noted in the ARIN 40 Policy > Experience Report, since IPv4 exhaustion, obtaining IPv4 addresses in > this manner is no longer possible as a practical matter. Instead an ISP > must join the waiting list and wait until it reaches the front of the > queue to obtain any IPv4 address space, however long that may take. In > effect, section 4.2.1.6 is non-operative. Accordingly, its continued > presence in the NRPM is misleading and confusing. > > Policy statement: > > Section 4.2.1.6 of the NRPM is hereby repealed and section number > 4.2.1.6 is hereby retired. > > Comments: > > a. Timetable for implementation: Immediate > > b. Comments: Given the constraints created by the exhaustion of IPv4 > addresses, this proposal does not require any changes in the current > ARIN practices for the allocation of IPv4 address space. > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net ). > Unsubscribe or manage 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 AHadenfeldt at allophone.net Tue Nov 28 14:02:53 2017 From: AHadenfeldt at allophone.net (Hadenfeldt, Andrew) Date: Tue, 28 Nov 2017 19:02:53 +0000 Subject: [arin-ppml] Draft Policy ARIN-2017-13: Remove ARIN Review Requirements for Large, IPv4 Reassignments/Reallocations In-Reply-To: References: <88404d28-06a3-504c-547a-3eb742b2f11f@arin.net> Message-ID: +1/Support as written. Thank you for the context, David?I found it helpful. -Andy From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of David Farmer Sent: Tuesday, November 21, 2017 6:17 PM To: Scott Leibrand Cc: ARIN-PPML List Subject: Re: [arin-ppml] Draft Policy ARIN-2017-13: Remove ARIN Review Requirements for Large, IPv4 Reassignments/Reallocations No it actively requires a significant workload by ARIN Staff, which is why I believe it was brought to the communities attention. From slide #5 of the ARIN 40 Policy Experience Report; Ticket Workload {for 4.2.3.5.}, 1,327 in 2016, approximately 70% are self SWIPs Slides: https://www.arin.net/vault/participate/meetings/reports/ARIN_40/PDF/PPM/sweeting-policy-experience.pdf Transcript: https://www.arin.net/vault/participate/meetings/reports/ARIN_40/ppm1_transcript.html#anchor_5 Video: https://www.youtube.com/watch?v=QVsfVMG_6fA FYI, this report is the genesis for what is now ARIN-2017-9 and ARIN-2017-10 as well. Hope that helps. On Tue, Nov 21, 2017 at 5:05 PM, Scott Leibrand > wrote: +1 - Support Do we have any statistics on the last time 4.2.3.5 was invoked and/or frequently it was invoked? I suspect it's been awhile... -Scott On Tue, Nov 21, 2017 at 2:44 PM, ARIN > wrote: On 16 November 2017 the ARIN Advisory Council (AC) advanced "ARIN-prop-248: Remove ARIN Review Requirements for Large IPv4 Reassignments/Reallocations" to Draft Policy status. Draft Policy ARIN-2017-13 is below and can be found at: https://www.arin.net/policy/proposals/2017_13.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-13: Remove ARIN Review Requirements for Large IPv4 Reassignments/Reallocations Problem Statement: ARIN review of large IPv4 reassignments or rellocations was put in place when ARIN had a free pool of IPv4 addresses. The main purpose of the review was to ensure that ISPs were following RFC2050 and ARIN policy for large blocks. Since there is no longer a free pool and blocks have a value through transfer, there is now a disincentive for ISPs to over assign blocks to downstream customers. Thus this policy is no longer needed. Policy statement: Remove Section 4.2.3.5 of NRPM 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. -- =============================================== 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 tedm at ipinc.net Thu Nov 30 01:08:32 2017 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Wed, 29 Nov 2017 22:08:32 -0800 Subject: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment In-Reply-To: References: <20171122160159.GA41025@gweep.net> <1965618547.183023.1511392822657.JavaMail.zimbra@ncf.ca> <0d4075293a247645e6bf46b7343b767c@mail.gmail.com> Message-ID: <5A1FA060.7090609@ipinc.net> And I will point out that the entire point of validating POCs is to discover things like /16's that haven't been used for 15 years. It would seem to me that ARIN staff vacillates between loving and hating section 3.6 of the NRPM. Some years they see any attempt at housecleaning stale assignments that are just on autopilot (like this mythical /16 - I love how when people cite these examples they never state the actual numbers - hello!) as an obstacle to increased IPv6 adoption so they hate it and undercut it. Other years they desperately need to get some IPv4 for someone very big and powerful with maybe a whole lot of guns and rocket launchers and such and they love this section since it allows them to scrape together some IPv4 for a need. Ted On 11/27/2017 4:24 PM, Owen DeLong wrote: > Before we travel too far down this branch of discussion, I?d like to > point out that fees are not within the realm of ARIN policy debate and > therefore aren?t really an appropriate topic for this list. > > If you?d like to discuss such a fee, there is arin-discuss (open to > Members/Staff/Board/AC) where fee discussions are appropriate. > > Alternatively, there is also the ARIN Consultation and Suggestion > Process (ACSP) available via the Participate tab on the ARIN web site. > > Thanks, > > Owen > >> On Nov 27, 2017, at 13:08 , Steven Ryerse >> > >> wrote: >> >> I don?t see how you can go back and start charging Legacy holders that >> obtained their blocks before ARIN was created. You would have to >> charge big companies like AT&T & IBM and you would have to somehow >> charge the Dept. of Defense and so forth to make it fair to everyone. >> Seems like that ship sailed long ago. >> /Steven Ryerse/ >> /President/ >> /100 Ashford Center North, Suite 110, Atlanta, GA 30338/ >> /770.656.1460 - Cell/ >> /770.399.9099 - Office/ >> /770.392.0076 - Fax/ >> ?Eclipse Networks, Inc. >> ^Conquering Complex Networks ^? ^ >> *From:*ARIN-PPML [mailto:arin-ppml-bounces at arin.net]*On Behalf >> Of*Roberts, Orin >> *Sent:*Monday, November 27, 2017 3:59 PM >> *To:*Andrew Bagrin > >> *Cc:*ARIN-PPML List > >> *Subject:*Re: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC >> Validation Upon Reassignment >> I see obstacles but increased fees would lead to greater efficiency in >> IPv4 assignments and usage or at the very least aid in the migration >> to IPv6. >> >> 1. Charging a monthly fee (or higher monthly fee), means increased >> costs to end-users for whatever services said company provides. >> 2. ISP?s with VERY LARGE inventory of IPs would lobby against such a >> proposal. A typical ISP would have several /16?s in reservation - >> capacity planning. >> 3. What?s to stop companies from doing what they do now? ? Reassign >> or Reallocate unused inventory (ie trade and monetize via brokers). >> >> Orin Roberts >> *From:*ARIN-PPML [mailto:arin-ppml-bounces at arin.net]*On Behalf >> Of*Andrew Bagrin >> *Sent:*November-27-17 3:35 PM >> *To:*Austin Murkland > >; Andre Dalle > > >> *Cc:*ARIN-PPML List > >> *Subject:*Re: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC >> Validation Upon Reassignment >> I?d also like to see a $100 monthly fee per IPv4 /24 currently assigned. >> I held onto a /16 at a previous company, just because it was cool but >> had no use for it. I checked recently and it is still assigned to the >> same company and not being used 15 years later. >> By adding a $25k monthly fee, they would quickly return the block. >> Currently we have to pay brokers or sellers to acquire more IPv4 >> space. I would rather pay ARIN which could go to better funding the >> organization. >> *From:*ARIN-PPML [mailto:arin-ppml-bounces at arin.net >> ]*On Behalf Of*Austin Murkland >> *Sent:*Monday, November 27, 2017 3:26 PM >> *To:*Andre Dalle > >> *Cc:*ARIN-PPML List > >> *Subject:*Re: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC >> Validation Upon Reassignment >> Also support this >> On Wed, Nov 22, 2017 at 6:20 PM, Andre Dalle > > wrote: >> >> >> All my IPv4 space is reassigned, and I discovered last year that >> not all of it - from the same carrier - is properly associated >> with us. >> >> Upstream created a POC for us (even though we were an existing >> customer with multiple reassignments), and it's been sluggish >> getting them to >> sort it out. We have rDNS, so most abuse reporting still finds us, >> but some abuse mechanisms out there rely on POC info. >> >> So I think this is necessary. +100 from here as well. >> >> ---- >> Andr? Dalle >> Systems Administrator >> National Capital FreeNet [http://www.ncf.ca ] >> >> ----- Original Message ----- >> From: "Joe Provo" > >> To: "ARIN-PPML List" > >> Sent: Wednesday, 22 November, 2017 11:01:59 >> Subject: Re: [arin-ppml] Draft Policy ARIN-2017-12: Require New >> POC Validation Upon Reassignment >> >> On Tue, Nov 21, 2017 at 06:13:46PM -0500, David Huberman wrote: >> > Thank you Scott. As the co-author, I very much recognize this >> > proposal text is a ???first draft???. Working with my co-author >> > Jason Schiller, and having solicited feedback from the AC, this >> > proposal was submitted to solve the general problem. My hope was >> > the mechanics would be looked at critically by the community during >> > the PDP, and we would work together to improve them. >> >> With my personal hat on I'm very happy to see this getting >> to discussion. +100 for intent and I look forward to useful >> language suggestions here. >> >> -- >> Posted from my personal account - see X-Disclaimer header. >> Joe Provo / Gweep / Earthling >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net >> ). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contactinfo at arin.net if you >> experience any issues. >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net >> ). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contactinfo at arin.net if you >> experience any issues. >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net >> ). >> Unsubscribe or manage your mailing list subscription at: >> http://lists.arin.net/mailman/listinfo/arin-ppml >> Please contactinfo at arin.net if you experience >> any issues. > > > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact info at arin.net if you experience any issues. From jcurran at arin.net Thu Nov 30 05:48:29 2017 From: jcurran at arin.net (John Curran) Date: Thu, 30 Nov 2017 10:48:29 +0000 Subject: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment In-Reply-To: <5A1FA060.7090609@ipinc.net> References: <20171122160159.GA41025@gweep.net> <1965618547.183023.1511392822657.JavaMail.zimbra@ncf.ca> <0d4075293a247645e6bf46b7343b767c@mail.gmail.com> <5A1FA060.7090609@ipinc.net> Message-ID: <8C9AE578-5019-446D-A666-7B2E760A7A40@arin.net> On 30 Nov 2017, at 1:08 AM, Ted Mittelstaedt > wrote: And I will point out that the entire point of validating POCs is to discover things like /16's that haven't been used for 15 years. It would seem to me that ARIN staff vacillates between loving and hating section 3.6 of the NRPM. Some years they see any attempt at housecleaning stale assignments that are just on autopilot (like this mythical /16 - I love how when people cite these examples they never state the actual numbers - hello!) as an obstacle to increased IPv6 adoption so they hate it and undercut it. Other years they desperately need to get some IPv4 for someone very big and powerful with maybe a whole lot of guns and rocket launchers and such and they love this section since it allows them to scrape together some IPv4 for a need. Ted - You?d be amazed, but ARIN staff actually doesn?t ?feel? much about the various policy text contained in the NRPM? It is entirely the community?s collective work product, and the only time I hear staff express ?grumbling' over policy text is when it is overly ambiguous regarding the intended policy. (To the extent that there are concerns on any aspects of the NRPM, we report such to the community in periodic Policy Experience and Implementation reports.) As usual, the key question is (and remains): what the does the ARIN community feel is the desired policy for POC validation, both when initially set and with respect to any periodic update? Thanks! /John John Curran President and CEO ARIN -------------- next part -------------- An HTML attachment was scrubbed... URL: From tedm at ipinc.net Thu Nov 30 06:26:21 2017 From: tedm at ipinc.net (Ted Mittelstaedt) Date: Thu, 30 Nov 2017 03:26:21 -0800 Subject: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment In-Reply-To: <8C9AE578-5019-446D-A666-7B2E760A7A40@arin.net> References: <20171122160159.GA41025@gweep.net> <1965618547.183023.1511392822657.JavaMail.zimbra@ncf.ca> <0d4075293a247645e6bf46b7343b767c@mail.gmail.com> <5A1FA060.7090609@ipinc.net> <8C9AE578-5019-446D-A666-7B2E760A7A40@arin.net> Message-ID: <5A1FEADD.50904@ipinc.net> John, I cannot comment for everyone in the community other than to say that any network administrator who sees no value in accurate POCs is certifiably insane. I submit the following for your enjoyment: There once was an admin named Hein Who thought lying on his POC was just fine then along came a scammer gunned his hosts with a scanner and Hein could do nothing but whine! thank you thank you I'll be here till Friday.... Ted On 11/30/2017 2:48 AM, John Curran wrote: > On 30 Nov 2017, at 1:08 AM, Ted Mittelstaedt > wrote: >> >> >> And I will point out that the entire point of validating POCs is to >> discover things like /16's that haven't been used for 15 years. >> >> It would seem to me that ARIN staff vacillates between loving and >> hating section 3.6 of the NRPM. >> Some years they see any attempt at housecleaning stale assignments >> that are just on autopilot >> (like this mythical /16 - I love how when people cite these examples >> they never >> state the actual numbers - hello!) as an obstacle to increased IPv6 >> adoption so they hate it and undercut it. Other years they desperately >> need to get some IPv4 for someone very big and powerful with maybe a >> whole lot of guns and rocket launchers and such and they love this >> section since it allows them to scrape together some IPv4 for a need. > > > > Ted - > You?d be amazed, but ARIN staff actually doesn?t ?feel? much about the > various policy text contained in the NRPM? It is entirely the community?s > collective work product, and the only time I hear staff express ?grumbling' > over policy text is when it is overly ambiguous regarding the intended > policy. > (To the extent that there are concerns on any aspects of the NRPM, we > report such to the community in periodic Policy Experience and > Implementation reports.) > > As usual, the key question is (and remains): what the does the ARIN > community feel is the desired policy for POC validation, both when > initially set and with respect to any periodic update? > > Thanks! > /John > > John Curran > President and CEO > ARIN > From hostmaster at uneedus.com Thu Nov 30 08:38:27 2017 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Thu, 30 Nov 2017 08:38:27 -0500 (EST) Subject: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment In-Reply-To: References: <20171122160159.GA41025@gweep.net> <1965618547.183023.1511392822657.JavaMail.zimbra@ncf.ca> Message-ID: I support this policy. Giving ISP's/LIR's the ability to add reassignment contacts without verification from the contacts being added I think was always wrong. Often, the email added was NOT someone who actually processed abuse issues, but often was instead someone from purchasing or marketing who had absolutely no clue who or why we have ARIN. Often that person had no clue as to what address should be used (often a role account), and thus never provided the ISP with that correct information. Thus, the ISP used that person's info instead. As a result, when they got the verification email, they thought it was phishing or spam and ignored it. Ensuring that added contacts in the database have been verified at creation time should go a long way in helping to keep the database clean. At a minimum, at least those who have verified their contact before entry into the database should know who ARIN is, and why they need to respond to that annual email. I would suggest that the verification email also remind the person of the future annual verification email that will be sent, and reminding them that they need to confirm their info once a year. Albert Erdmann Network Administrator Paradise On Line Inc. From hostmaster at uneedus.com Thu Nov 30 09:08:05 2017 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Thu, 30 Nov 2017 09:08:05 -0500 (EST) Subject: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment In-Reply-To: <5A1FA060.7090609@ipinc.net> References: <20171122160159.GA41025@gweep.net> <1965618547.183023.1511392822657.JavaMail.zimbra@ncf.ca> <0d4075293a247645e6bf46b7343b767c@mail.gmail.com> <5A1FA060.7090609@ipinc.net> Message-ID: Unless the space is legacy, I do not see how space can remain open for 15 years on autopilot, as someone must be paying the ARIN bill. Even under the original policies, review of use of IPv4 space only comes up in the context of requesting more space from ARIN. In light of the marketability of unused space, eventually someone from that org will eventually either use/lease/sell the space, and the tighter things go, the more likely this will happen. It is very unlikely anyone will just return the space, since it now has value. This has been discussed before. The amount of resources that would be required at ARIN to recover space from orgs that no longer exist far exceed the current value of the space recovered. The mythical class B we are discussing here is in fact getting quite rare, and the brokers are getting better at tracking these down and getting them back to use. In fact, it looks like the bulk of the legacy space with bad contacts are approaching the /22 to /24 level, not really worth the effort, considering that we all know the basic math is always against continued use of IPv4. That math being the simple fact that the total number of possible IPv4 addresses is much less than the world population. At some point, we will pass a hump in IPv6 adoption, and this will drive us toward IPv6 becoming the main protocol on the worldwide internet. I think at that point, that will become the peak of IPv4 value. Once IPv6 becomes the main protocol, the value of IPv4 addresses will fall like a rock. Albert Erdmann Network Administrator Paradise On Line Inc. On Wed, 29 Nov 2017, Ted Mittelstaedt wrote: > > And I will point out that the entire point of validating POCs is to discover > things like /16's that haven't been used for 15 years. > > It would seem to me that ARIN staff vacillates between loving and hating > section 3.6 of the NRPM. Some years they see any attempt at > housecleaning stale assignments that are just on autopilot (like this > mythical /16 - I love how when people cite these examples they never > state the actual numbers - hello!) as an obstacle to increased IPv6 > adoption so they hate it and undercut it. Other years they desperately > need to get some IPv4 for someone very big and powerful with maybe a > whole lot of guns and rocket launchers and such and they love this > section since it allows them to scrape together some IPv4 for a need. > > Ted > > On 11/27/2017 4:24 PM, Owen DeLong wrote: >> Before we travel too far down this branch of discussion, I?d like to >> point out that fees are not within the realm of ARIN policy debate and >> therefore aren?t really an appropriate topic for this list. >> >> If you?d like to discuss such a fee, there is arin-discuss (open to >> Members/Staff/Board/AC) where fee discussions are appropriate. >> >> Alternatively, there is also the ARIN Consultation and Suggestion >> Process (ACSP) available via the Participate tab on the ARIN web site. >> >> Thanks, >> >> Owen >> >>> On Nov 27, 2017, at 13:08 , Steven Ryerse >>> > >>> wrote: >>> >>> I don?t see how you can go back and start charging Legacy holders that >>> obtained their blocks before ARIN was created. You would have to >>> charge big companies like AT&T & IBM and you would have to somehow >>> charge the Dept. of Defense and so forth to make it fair to everyone. >>> Seems like that ship sailed long ago. >>> /Steven Ryerse/ >>> /President/ >>> /100 Ashford Center North, Suite 110, Atlanta, GA 30338/ >>> /770.656.1460 - Cell/ >>> /770.399.9099 - Office/ >>> /770.392.0076 - Fax/ >>> ?Eclipse Networks, Inc. >>> ^Conquering Complex Networks ^? ^ >>> *From:*ARIN-PPML [mailto:arin-ppml-bounces at arin.net]*On Behalf >>> Of*Roberts, Orin >>> *Sent:*Monday, November 27, 2017 3:59 PM >>> *To:*Andrew Bagrin > >>> *Cc:*ARIN-PPML List > >>> *Subject:*Re: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC >>> Validation Upon Reassignment >>> I see obstacles but increased fees would lead to greater efficiency in >>> IPv4 assignments and usage or at the very least aid in the migration >>> to IPv6. >>> >>> 1. Charging a monthly fee (or higher monthly fee), means increased >>> costs to end-users for whatever services said company provides. >>> 2. ISP?s with VERY LARGE inventory of IPs would lobby against such a >>> proposal. A typical ISP would have several /16?s in reservation - >>> capacity planning. >>> 3. What?s to stop companies from doing what they do now? ? Reassign >>> or Reallocate unused inventory (ie trade and monetize via brokers). >>> >>> Orin Roberts >>> *From:*ARIN-PPML [mailto:arin-ppml-bounces at arin.net]*On Behalf >>> Of*Andrew Bagrin >>> *Sent:*November-27-17 3:35 PM >>> *To:*Austin Murkland >> >; Andre Dalle >> > >>> *Cc:*ARIN-PPML List > >>> *Subject:*Re: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC >>> Validation Upon Reassignment >>> I?d also like to see a $100 monthly fee per IPv4 /24 currently assigned. >>> I held onto a /16 at a previous company, just because it was cool but >>> had no use for it. I checked recently and it is still assigned to the >>> same company and not being used 15 years later. >>> By adding a $25k monthly fee, they would quickly return the block. >>> Currently we have to pay brokers or sellers to acquire more IPv4 >>> space. I would rather pay ARIN which could go to better funding the >>> organization. >>> *From:*ARIN-PPML [mailto:arin-ppml-bounces at arin.net >>> ]*On Behalf Of*Austin Murkland >>> *Sent:*Monday, November 27, 2017 3:26 PM >>> *To:*Andre Dalle > >>> *Cc:*ARIN-PPML List > >>> *Subject:*Re: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC >>> Validation Upon Reassignment >>> Also support this >>> On Wed, Nov 22, 2017 at 6:20 PM, Andre Dalle >> > wrote: >>> >>> >>> All my IPv4 space is reassigned, and I discovered last year that >>> not all of it - from the same carrier - is properly associated >>> with us. >>> >>> Upstream created a POC for us (even though we were an existing >>> customer with multiple reassignments), and it's been sluggish >>> getting them to >>> sort it out. We have rDNS, so most abuse reporting still finds us, >>> but some abuse mechanisms out there rely on POC info. >>> >>> So I think this is necessary. +100 from here as well. >>> >>> ---- >>> Andr? Dalle >>> Systems Administrator >>> National Capital FreeNet [http://www.ncf.ca ] >>> >>> ----- Original Message ----- >>> From: "Joe Provo" > >>> To: "ARIN-PPML List" > >>> Sent: Wednesday, 22 November, 2017 11:01:59 >>> Subject: Re: [arin-ppml] Draft Policy ARIN-2017-12: Require New >>> POC Validation Upon Reassignment >>> >>> On Tue, Nov 21, 2017 at 06:13:46PM -0500, David Huberman wrote: >>> > Thank you Scott. As the co-author, I very much recognize this >>> > proposal text is a ???first draft???. Working with my co-author >>> > Jason Schiller, and having solicited feedback from the AC, this >>> > proposal was submitted to solve the general problem. My hope was >>> > the mechanics would be looked at critically by the community during >>> > the PDP, and we would work together to improve them. >>> >>> With my personal hat on I'm very happy to see this getting >>> to discussion. +100 for intent and I look forward to useful >>> language suggestions here. >>> >>> -- >>> Posted from my personal account - see X-Disclaimer header. >>> Joe Provo / Gweep / Earthling >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to >>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net >>> ). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contactinfo at arin.net if you >>> experience any issues. >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to >>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net >>> ). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contactinfo at arin.net if you >>> experience any issues. >>> >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to >>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net >>> ). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contactinfo at arin.net if you experience >>> any issues. >> >> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage 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 Nov 30 10:51:14 2017 From: chris at semihuman.com (Chris Woodfield) Date: Thu, 30 Nov 2017 07:51:14 -0800 Subject: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment In-Reply-To: References: Message-ID: One point to make on this proposal is that this may change how ISPs assign blocks, given that both transfers and allocations have needs-based policies in force (for both v4 and v6), and SWIPs are generally used as evidence of utilization of existing blocks. With this proposal in force, adding a SWIP to an allocated block should no longer be considered a parallel process to assigning space to a downstream customer; instead, the insertion of a SWIP with a validated POC will be a blocking function on the downstream allocation, otherwise customers will be utilizing blocks without SWIPs if the POC is never validated. IMO this is how I feel the system *should* work, but then again, I?m currently not in the business of doing these kinds of assignments. Those who would be more directly impacted by this may have a different point of view :) -C > On Nov 21, 2017, at 2:43 PM, ARIN wrote: > > On 16 November 2017, the ARIN Advisory Council (AC) advanced "ARIN-prop-247: Require New POC Validation Upon Reassignment" to Draft Policy status. > > Draft Policy ARIN-2017-12 is below and can be found at: > https://www.arin.net/policy/proposals/2017_12.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-12: Require New POC Validation Upon Reassignment > > Problem Statement: > > Some large ISPs assign individuals to be POCs for reassigned blocks without consultation of the individual they are inserting into Whois. One year later, the POC is contacted by ARIN as part of Annual POC Validation policies. The POC often does not know who ARIN is, what Whois is, and why they are in Whois. > > This policy proposal seeks to improve the situation where a POC is unwittingly and unwantingly inserted into Whois. > > It also seeks to mitigate the significant amount of time that ARIN staff reports that they spend fielding phone calls from POCs who have no idea they are in Whois. > > Finally, it is hopeful that this proposal will improve the overall POC validation situation, by forcing ISPs and customers to work together to insert proper information into Whois at the time of sub-delegation. > > Policy statement: > > Insert two new sections into NRPM 3: > > 3.7 New POC Validation Upon Reassignment > > When an ISP submits a valid reallocation or detailed reassignment request to ARIN which would result in a new POC object being created, ARIN must (before otherwise approving the request) contact the new POC by email for validation. ARIN's notification will, at a minimum, notify the POC of: > > - the information about the organization submitting the record; and > - the resource(s) to which the POC is being attached; and > - the organization(s) to which the POC is being attached. > > If the POC validates the request, the request shall be accepted by ARIN and the new objects inserted into Whois. If the POC does not validate the request within 10 days, ARIN must reject the request. > > 3.8 Downstream Validation of Simple Reassignments > > When an ISP submits a valid simple reassigment request to ARIN with an organization name OR postal address that is identical to one or more existing OrgIDs, ARIN will notify the downstream organization and obtain guidance on whether to accept the simple reassigment, or redirect it to one of the existing OrgIDs as a detailed reassignment. > > 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 abagrin at omninet.io Thu Nov 30 11:14:51 2017 From: abagrin at omninet.io (Andrew Bagrin) Date: Thu, 30 Nov 2017 11:14:51 -0500 Subject: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment In-Reply-To: References: <20171122160159.GA41025@gweep.net> <1965618547.183023.1511392822657.JavaMail.zimbra@ncf.ca> <0d4075293a247645e6bf46b7343b767c@mail.gmail.com> <5A1FA060.7090609@ipinc.net> Message-ID: <9f6dd4f4ec02404447cffb4596e59194@mail.gmail.com> The mythical space is 168.86.0.0/16 direct assignment NATIO-42 https://whois.arin.net/rest/net/NET-168-86-0-0-1/pft?s=168.86.1.1 I got a hold of it when we acquire United Artists. They used it as private space. I just did a ping sweep and got no replies. Nothing on BGP dig either. I have a hard time believing they are the only ones. -----Original Message----- From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of hostmaster at uneedus.com Sent: Thursday, November 30, 2017 9:08 AM To: arin-ppml at arin.net Subject: Re: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment Unless the space is legacy, I do not see how space can remain open for 15 years on autopilot, as someone must be paying the ARIN bill. Even under the original policies, review of use of IPv4 space only comes up in the context of requesting more space from ARIN. In light of the marketability of unused space, eventually someone from that org will eventually either use/lease/sell the space, and the tighter things go, the more likely this will happen. It is very unlikely anyone will just return the space, since it now has value. This has been discussed before. The amount of resources that would be required at ARIN to recover space from orgs that no longer exist far exceed the current value of the space recovered. The mythical class B we are discussing here is in fact getting quite rare, and the brokers are getting better at tracking these down and getting them back to use. In fact, it looks like the bulk of the legacy space with bad contacts are approaching the /22 to /24 level, not really worth the effort, considering that we all know the basic math is always against continued use of IPv4. That math being the simple fact that the total number of possible IPv4 addresses is much less than the world population. At some point, we will pass a hump in IPv6 adoption, and this will drive us toward IPv6 becoming the main protocol on the worldwide internet. I think at that point, that will become the peak of IPv4 value. Once IPv6 becomes the main protocol, the value of IPv4 addresses will fall like a rock. Albert Erdmann Network Administrator Paradise On Line Inc. On Wed, 29 Nov 2017, Ted Mittelstaedt wrote: > > And I will point out that the entire point of validating POCs is to > discover things like /16's that haven't been used for 15 years. > > It would seem to me that ARIN staff vacillates between loving and > hating section 3.6 of the NRPM. Some years they see any attempt at > housecleaning stale assignments that are just on autopilot (like this > mythical /16 - I love how when people cite these examples they never > state the actual numbers - hello!) as an obstacle to increased IPv6 > adoption so they hate it and undercut it. Other years they desperately > need to get some IPv4 for someone very big and powerful with maybe a > whole lot of guns and rocket launchers and such and they love this > section since it allows them to scrape together some IPv4 for a need. > > Ted > > On 11/27/2017 4:24 PM, Owen DeLong wrote: >> Before we travel too far down this branch of discussion, I?d like to >> point out that fees are not within the realm of ARIN policy debate >> and therefore aren?t really an appropriate topic for this list. >> >> If you?d like to discuss such a fee, there is arin-discuss (open to >> Members/Staff/Board/AC) where fee discussions are appropriate. >> >> Alternatively, there is also the ARIN Consultation and Suggestion >> Process (ACSP) available via the Participate tab on the ARIN web site. >> >> Thanks, >> >> Owen >> >>> On Nov 27, 2017, at 13:08 , Steven Ryerse >>> > >>> wrote: >>> >>> I don?t see how you can go back and start charging Legacy holders >>> that obtained their blocks before ARIN was created. You would have >>> to charge big companies like AT&T & IBM and you would have to >>> somehow charge the Dept. of Defense and so forth to make it fair to >>> everyone. >>> Seems like that ship sailed long ago. >>> /Steven Ryerse/ >>> /President/ >>> /100 Ashford Center North, Suite 110, Atlanta, GA 30338/ >>> /770.656.1460 - Cell/ >>> /770.399.9099 - Office/ >>> /770.392.0076 - Fax/ >>> ?Eclipse Networks, Inc. >>> ^Conquering Complex Networks ^? ^ >>> *From:*ARIN-PPML [mailto:arin-ppml-bounces at arin.net]*On Behalf >>> Of*Roberts, Orin *Sent:*Monday, November 27, 2017 3:59 PM >>> *To:*Andrew Bagrin > >>> *Cc:*ARIN-PPML List > >>> *Subject:*Re: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC >>> Validation Upon Reassignment I see obstacles but increased fees >>> would lead to greater efficiency in >>> IPv4 assignments and usage or at the very least aid in the migration >>> to IPv6. >>> >>> 1. Charging a monthly fee (or higher monthly fee), means increased >>> costs to end-users for whatever services said company provides. >>> 2. ISP?s with VERY LARGE inventory of IPs would lobby against such a >>> proposal. A typical ISP would have several /16?s in reservation - >>> capacity planning. >>> 3. What?s to stop companies from doing what they do now? ? Reassign >>> or Reallocate unused inventory (ie trade and monetize via brokers). >>> >>> Orin Roberts >>> *From:*ARIN-PPML [mailto:arin-ppml-bounces at arin.net]*On Behalf >>> Of*Andrew Bagrin >>> *Sent:*November-27-17 3:35 PM >>> *To:*Austin Murkland >> >; Andre Dalle >> > *Cc:*ARIN-PPML List >> > >>> *Subject:*Re: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC >>> Validation Upon Reassignment I?d also like to see a $100 monthly fee >>> per IPv4 /24 currently assigned. >>> I held onto a /16 at a previous company, just because it was cool >>> but had no use for it. I checked recently and it is still assigned >>> to the same company and not being used 15 years later. >>> By adding a $25k monthly fee, they would quickly return the block. >>> Currently we have to pay brokers or sellers to acquire more IPv4 >>> space. I would rather pay ARIN which could go to better funding the >>> organization. >>> *From:*ARIN-PPML [mailto:arin-ppml-bounces at arin.net >>> ]*On Behalf Of*Austin Murkland >>> *Sent:*Monday, November 27, 2017 3:26 PM *To:*Andre Dalle >>> > *Cc:*ARIN-PPML List >>> > >>> *Subject:*Re: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC >>> Validation Upon Reassignment Also support this On Wed, Nov 22, 2017 >>> at 6:20 PM, Andre Dalle > >>> wrote: >>> >>> >>> All my IPv4 space is reassigned, and I discovered last year that >>> not all of it - from the same carrier - is properly associated >>> with us. >>> >>> Upstream created a POC for us (even though we were an existing >>> customer with multiple reassignments), and it's been sluggish >>> getting them to >>> sort it out. We have rDNS, so most abuse reporting still finds us, >>> but some abuse mechanisms out there rely on POC info. >>> >>> So I think this is necessary. +100 from here as well. >>> >>> ---- >>> Andr? Dalle >>> Systems Administrator >>> National Capital FreeNet [http://www.ncf.ca >>> ] >>> >>> ----- Original Message ----- >>> From: "Joe Provo" > >>> To: "ARIN-PPML List" >> > >>> Sent: Wednesday, 22 November, 2017 11:01:59 >>> Subject: Re: [arin-ppml] Draft Policy ARIN-2017-12: Require New >>> POC Validation Upon Reassignment >>> >>> On Tue, Nov 21, 2017 at 06:13:46PM -0500, David Huberman wrote: >>> > Thank you Scott. As the co-author, I very much recognize this >>> > proposal text is a ???first draft???. Working with my co-author >>> > Jason Schiller, and having solicited feedback from the AC, this >>> > proposal was submitted to solve the general problem. My hope was >>> > the mechanics would be looked at critically by the community >>> during >>> > the PDP, and we would work together to improve them. >>> >>> With my personal hat on I'm very happy to see this getting >>> to discussion. +100 for intent and I look forward to useful >>> language suggestions here. >>> >>> -- >>> Posted from my personal account - see X-Disclaimer header. >>> Joe Provo / Gweep / Earthling >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to >>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net >>> ). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contactinfo at arin.net if you >>> experience any issues. >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to >>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net >>> ). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contactinfo at arin.net if you >>> experience any issues. >>> >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to the >>> ARIN Public Policy Mailing List (ARIN-PPML at arin.net >>> ). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contactinfo at arin.net if you experience >>> any issues. >> >> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to the ARIN >> Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage 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 hostmaster at uneedus.com Thu Nov 30 11:46:05 2017 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Thu, 30 Nov 2017 11:46:05 -0500 (EST) Subject: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment In-Reply-To: <9f6dd4f4ec02404447cffb4596e59194@mail.gmail.com> References: <20171122160159.GA41025@gweep.net> <1965618547.183023.1511392822657.JavaMail.zimbra@ncf.ca> <0d4075293a247645e6bf46b7343b767c@mail.gmail.com> <5A1FA060.7090609@ipinc.net> <9f6dd4f4ec02404447cffb4596e59194@mail.gmail.com> Message-ID: Private space is a valid use, as this is one of the only ways to ensure uniqueness. Look at the US Postal Service as an example of this. They have gobs of mail sorting machines on their class A, none of which is exposed to the internet. Their public facing services are also in the lower portion of this block, so they have both uses. If you are not using it, and there are no future plans for it, is is quite likely that the company will eventually be contacted by a broker regarding the sale or lease of the space. I suspect that most of the contacts by brokers are initially made by the broker, to those in charge of possible space that might be available. Most of their work is trying to track down possible available space. Without available space, the broker really does not have a product to offer, since the buyer is the source of the money for both the buyer and the broker's commission. You are right that this is not likely the only available network. Even so, we will never find enough IPv4 space to cover demand. As the available blocks get smaller, it becomes an even more cost intense job. Albert Erdmann Network Administrator Paradise On Line Inc. On Thu, 30 Nov 2017, Andrew Bagrin wrote: > The mythical space is 168.86.0.0/16 direct assignment NATIO-42 > https://whois.arin.net/rest/net/NET-168-86-0-0-1/pft?s=168.86.1.1 > I got a hold of it when we acquire United Artists. They used it as private > space. > I just did a ping sweep and got no replies. Nothing on BGP dig either. > > I have a hard time believing they are the only ones. > > > > -----Original Message----- > From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of > hostmaster at uneedus.com > Sent: Thursday, November 30, 2017 9:08 AM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC > Validation Upon Reassignment > > Unless the space is legacy, I do not see how space can remain open for 15 > years on autopilot, as someone must be paying the ARIN bill. > > Even under the original policies, review of use of IPv4 space only comes up > in the context of requesting more space from ARIN. In light of the > marketability of unused space, eventually someone from that org will > eventually either use/lease/sell the space, and the tighter things go, the > more likely this will happen. It is very unlikely anyone will just return > the space, since it now has value. > > This has been discussed before. The amount of resources that would be > required at ARIN to recover space from orgs that no longer exist far exceed > the current value of the space recovered. The mythical class B we are > discussing here is in fact getting quite rare, and the brokers are getting > better at tracking these down and getting them back to use. > > In fact, it looks like the bulk of the legacy space with bad contacts are > approaching the /22 to /24 level, not really worth the effort, considering > that we all know the basic math is always against continued use of IPv4. > That math being the simple fact that the total number of possible IPv4 > addresses is much less than the world population. > > At some point, we will pass a hump in IPv6 adoption, and this will drive us > toward IPv6 becoming the main protocol on the worldwide internet. I think > at that point, that will become the peak of IPv4 value. Once IPv6 becomes > the main protocol, the value of IPv4 addresses will fall like a rock. > > Albert Erdmann > Network Administrator > Paradise On Line Inc. > > > On Wed, 29 Nov 2017, Ted Mittelstaedt wrote: > >> >> And I will point out that the entire point of validating POCs is to >> discover things like /16's that haven't been used for 15 years. >> >> It would seem to me that ARIN staff vacillates between loving and >> hating section 3.6 of the NRPM. Some years they see any attempt at >> housecleaning stale assignments that are just on autopilot (like this >> mythical /16 - I love how when people cite these examples they never >> state the actual numbers - hello!) as an obstacle to increased IPv6 >> adoption so they hate it and undercut it. Other years they desperately >> need to get some IPv4 for someone very big and powerful with maybe a >> whole lot of guns and rocket launchers and such and they love this >> section since it allows them to scrape together some IPv4 for a need. >> >> Ted >> >> On 11/27/2017 4:24 PM, Owen DeLong wrote: >>> Before we travel too far down this branch of discussion, I?d like to >>> point out that fees are not within the realm of ARIN policy debate >>> and therefore aren?t really an appropriate topic for this list. >>> >>> If you?d like to discuss such a fee, there is arin-discuss (open to >>> Members/Staff/Board/AC) where fee discussions are appropriate. >>> >>> Alternatively, there is also the ARIN Consultation and Suggestion >>> Process (ACSP) available via the Participate tab on the ARIN web site. >>> >>> Thanks, >>> >>> Owen >>> >>>> On Nov 27, 2017, at 13:08 , Steven Ryerse >>>> > >>>> wrote: >>>> >>>> I don?t see how you can go back and start charging Legacy holders >>>> that obtained their blocks before ARIN was created. You would have >>>> to charge big companies like AT&T & IBM and you would have to >>>> somehow charge the Dept. of Defense and so forth to make it fair to >>>> everyone. >>>> Seems like that ship sailed long ago. >>>> /Steven Ryerse/ >>>> /President/ >>>> /100 Ashford Center North, Suite 110, Atlanta, GA 30338/ >>>> /770.656.1460 - Cell/ >>>> /770.399.9099 - Office/ >>>> /770.392.0076 - Fax/ >>>> ?Eclipse Networks, Inc. >>>> ^Conquering Complex Networks ^? ^ >>>> *From:*ARIN-PPML [mailto:arin-ppml-bounces at arin.net]*On Behalf >>>> Of*Roberts, Orin *Sent:*Monday, November 27, 2017 3:59 PM >>>> *To:*Andrew Bagrin > >>>> *Cc:*ARIN-PPML List > >>>> *Subject:*Re: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC >>>> Validation Upon Reassignment I see obstacles but increased fees >>>> would lead to greater efficiency in >>>> IPv4 assignments and usage or at the very least aid in the migration >>>> to IPv6. >>>> >>>> 1. Charging a monthly fee (or higher monthly fee), means increased >>>> costs to end-users for whatever services said company provides. >>>> 2. ISP?s with VERY LARGE inventory of IPs would lobby against such a >>>> proposal. A typical ISP would have several /16?s in reservation - >>>> capacity planning. >>>> 3. What?s to stop companies from doing what they do now? ? Reassign >>>> or Reallocate unused inventory (ie trade and monetize via brokers). >>>> >>>> Orin Roberts >>>> *From:*ARIN-PPML [mailto:arin-ppml-bounces at arin.net]*On Behalf >>>> Of*Andrew Bagrin >>>> *Sent:*November-27-17 3:35 PM >>>> *To:*Austin Murkland >>> >; Andre Dalle >>> > *Cc:*ARIN-PPML List >>> > >>>> *Subject:*Re: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC >>>> Validation Upon Reassignment I?d also like to see a $100 monthly fee >>>> per IPv4 /24 currently assigned. >>>> I held onto a /16 at a previous company, just because it was cool >>>> but had no use for it. I checked recently and it is still assigned >>>> to the same company and not being used 15 years later. >>>> By adding a $25k monthly fee, they would quickly return the block. >>>> Currently we have to pay brokers or sellers to acquire more IPv4 >>>> space. I would rather pay ARIN which could go to better funding the >>>> organization. >>>> *From:*ARIN-PPML [mailto:arin-ppml-bounces at arin.net >>>> ]*On Behalf Of*Austin Murkland >>>> *Sent:*Monday, November 27, 2017 3:26 PM *To:*Andre Dalle >>>> > *Cc:*ARIN-PPML List >>>> > >>>> *Subject:*Re: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC >>>> Validation Upon Reassignment Also support this On Wed, Nov 22, 2017 >>>> at 6:20 PM, Andre Dalle > >>>> wrote: >>>> >>>> >>>> All my IPv4 space is reassigned, and I discovered last year that >>>> not all of it - from the same carrier - is properly associated >>>> with us. >>>> >>>> Upstream created a POC for us (even though we were an existing >>>> customer with multiple reassignments), and it's been sluggish >>>> getting them to >>>> sort it out. We have rDNS, so most abuse reporting still finds us, >>>> but some abuse mechanisms out there rely on POC info. >>>> >>>> So I think this is necessary. +100 from here as well. >>>> >>>> ---- >>>> Andr? Dalle >>>> Systems Administrator >>>> National Capital FreeNet [http://www.ncf.ca >>>> ] >>>> >>>> ----- Original Message ----- >>>> From: "Joe Provo" > >>>> To: "ARIN-PPML List" >>> > >>>> Sent: Wednesday, 22 November, 2017 11:01:59 >>>> Subject: Re: [arin-ppml] Draft Policy ARIN-2017-12: Require New >>>> POC Validation Upon Reassignment >>>> >>>> On Tue, Nov 21, 2017 at 06:13:46PM -0500, David Huberman wrote: >>>> > Thank you Scott. As the co-author, I very much recognize this >>>> > proposal text is a ???first draft???. Working with my co-author >>>> > Jason Schiller, and having solicited feedback from the AC, this >>>> > proposal was submitted to solve the general problem. My hope was >>>> > the mechanics would be looked at critically by the community >>>> during >>>> > the PDP, and we would work together to improve them. >>>> >>>> With my personal hat on I'm very happy to see this getting >>>> to discussion. +100 for intent and I look forward to useful >>>> language suggestions here. >>>> >>>> -- >>>> Posted from my personal account - see X-Disclaimer header. >>>> Joe Provo / Gweep / Earthling >>>> _______________________________________________ >>>> PPML >>>> You are receiving this message because you are subscribed to >>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net >>>> ). >>>> Unsubscribe or manage your mailing list subscription at: >>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>> Please contactinfo at arin.net if you >>>> experience any issues. >>>> _______________________________________________ >>>> PPML >>>> You are receiving this message because you are subscribed to >>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net >>>> ). >>>> Unsubscribe or manage your mailing list subscription at: >>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>> Please contactinfo at arin.net if you >>>> experience any issues. >>>> >>>> _______________________________________________ >>>> PPML >>>> You are receiving this message because you are subscribed to the >>>> ARIN Public Policy Mailing List (ARIN-PPML at arin.net >>>> ). >>>> Unsubscribe or manage your mailing list subscription at: >>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>> Please contactinfo at arin.net if you experience >>>> any issues. >>> >>> >>> >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to the ARIN >>> Public Policy Mailing List (ARIN-PPML at arin.net). >>> Unsubscribe or manage 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 abagrin at omninet.io Thu Nov 30 11:51:42 2017 From: abagrin at omninet.io (Andrew Bagrin) Date: Thu, 30 Nov 2017 11:51:42 -0500 Subject: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment In-Reply-To: References: <20171122160159.GA41025@gweep.net> <1965618547.183023.1511392822657.JavaMail.zimbra@ncf.ca> <0d4075293a247645e6bf46b7343b767c@mail.gmail.com> <5A1FA060.7090609@ipinc.net> <9f6dd4f4ec02404447cffb4596e59194@mail.gmail.com> Message-ID: That's why a suggested a fee, to make that space find us instead of us finding it. I can see this is not really of interest and the bigger interest is to launch v6 and forget about v4, so I'll stick to the plan. -----Original Message----- From: hostmaster at uneedus.com [mailto:hostmaster at uneedus.com] Sent: Thursday, November 30, 2017 11:46 AM To: arin-ppml at arin.net Cc: Andrew Bagrin Subject: RE: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment Private space is a valid use, as this is one of the only ways to ensure uniqueness. Look at the US Postal Service as an example of this. They have gobs of mail sorting machines on their class A, none of which is exposed to the internet. Their public facing services are also in the lower portion of this block, so they have both uses. If you are not using it, and there are no future plans for it, is is quite likely that the company will eventually be contacted by a broker regarding the sale or lease of the space. I suspect that most of the contacts by brokers are initially made by the broker, to those in charge of possible space that might be available. Most of their work is trying to track down possible available space. Without available space, the broker really does not have a product to offer, since the buyer is the source of the money for both the buyer and the broker's commission. You are right that this is not likely the only available network. Even so, we will never find enough IPv4 space to cover demand. As the available blocks get smaller, it becomes an even more cost intense job. Albert Erdmann Network Administrator Paradise On Line Inc. On Thu, 30 Nov 2017, Andrew Bagrin wrote: > The mythical space is 168.86.0.0/16 direct assignment NATIO-42 > https://whois.arin.net/rest/net/NET-168-86-0-0-1/pft?s=168.86.1.1 > I got a hold of it when we acquire United Artists. They used it as > private space. > I just did a ping sweep and got no replies. Nothing on BGP dig either. > > I have a hard time believing they are the only ones. > > > > -----Original Message----- > From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of > hostmaster at uneedus.com > Sent: Thursday, November 30, 2017 9:08 AM > To: arin-ppml at arin.net > Subject: Re: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC > Validation Upon Reassignment > > Unless the space is legacy, I do not see how space can remain open for > 15 years on autopilot, as someone must be paying the ARIN bill. > > Even under the original policies, review of use of IPv4 space only > comes up in the context of requesting more space from ARIN. In light > of the marketability of unused space, eventually someone from that org > will eventually either use/lease/sell the space, and the tighter > things go, the more likely this will happen. It is very unlikely > anyone will just return the space, since it now has value. > > This has been discussed before. The amount of resources that would be > required at ARIN to recover space from orgs that no longer exist far > exceed the current value of the space recovered. The mythical class B > we are discussing here is in fact getting quite rare, and the brokers > are getting better at tracking these down and getting them back to use. > > In fact, it looks like the bulk of the legacy space with bad contacts > are approaching the /22 to /24 level, not really worth the effort, > considering that we all know the basic math is always against continued > use of IPv4. > That math being the simple fact that the total number of possible IPv4 > addresses is much less than the world population. > > At some point, we will pass a hump in IPv6 adoption, and this will > drive us toward IPv6 becoming the main protocol on the worldwide > internet. I think at that point, that will become the peak of IPv4 > value. Once IPv6 becomes the main protocol, the value of IPv4 addresses > will fall like a rock. > > Albert Erdmann > Network Administrator > Paradise On Line Inc. > > > On Wed, 29 Nov 2017, Ted Mittelstaedt wrote: > >> >> And I will point out that the entire point of validating POCs is to >> discover things like /16's that haven't been used for 15 years. >> >> It would seem to me that ARIN staff vacillates between loving and >> hating section 3.6 of the NRPM. Some years they see any attempt at >> housecleaning stale assignments that are just on autopilot (like this >> mythical /16 - I love how when people cite these examples they never >> state the actual numbers - hello!) as an obstacle to increased IPv6 >> adoption so they hate it and undercut it. Other years they desperately >> need to get some IPv4 for someone very big and powerful with maybe a >> whole lot of guns and rocket launchers and such and they love this >> section since it allows them to scrape together some IPv4 for a need. >> >> Ted >> >> On 11/27/2017 4:24 PM, Owen DeLong wrote: >>> Before we travel too far down this branch of discussion, I?d like to >>> point out that fees are not within the realm of ARIN policy debate >>> and therefore aren?t really an appropriate topic for this list. >>> >>> If you?d like to discuss such a fee, there is arin-discuss (open to >>> Members/Staff/Board/AC) where fee discussions are appropriate. >>> >>> Alternatively, there is also the ARIN Consultation and Suggestion >>> Process (ACSP) available via the Participate tab on the ARIN web site. >>> >>> Thanks, >>> >>> Owen >>> >>>> On Nov 27, 2017, at 13:08 , Steven Ryerse >>>> >>> > >>>> wrote: >>>> >>>> I don?t see how you can go back and start charging Legacy holders >>>> that obtained their blocks before ARIN was created. You would have >>>> to charge big companies like AT&T & IBM and you would have to >>>> somehow charge the Dept. of Defense and so forth to make it fair to >>>> everyone. >>>> Seems like that ship sailed long ago. >>>> /Steven Ryerse/ >>>> /President/ >>>> /100 Ashford Center North, Suite 110, Atlanta, GA 30338/ >>>> /770.656.1460 - Cell/ >>>> /770.399.9099 - Office/ >>>> /770.392.0076 - Fax/ >>>> ?Eclipse Networks, Inc. >>>> ^Conquering Complex Networks ^? ^ >>>> *From:*ARIN-PPML [mailto:arin-ppml-bounces at arin.net]*On Behalf >>>> Of*Roberts, Orin *Sent:*Monday, November 27, 2017 3:59 PM >>>> *To:*Andrew Bagrin > >>>> *Cc:*ARIN-PPML List >>> > >>>> *Subject:*Re: [arin-ppml] Draft Policy ARIN-2017-12: Require New >>>> POC Validation Upon Reassignment I see obstacles but increased fees >>>> would lead to greater efficiency in >>>> IPv4 assignments and usage or at the very least aid in the >>>> migration to IPv6. >>>> >>>> 1. Charging a monthly fee (or higher monthly fee), means increased >>>> costs to end-users for whatever services said company provides. >>>> 2. ISP?s with VERY LARGE inventory of IPs would lobby against such a >>>> proposal. A typical ISP would have several /16?s in reservation - >>>> capacity planning. >>>> 3. What?s to stop companies from doing what they do now? ? Reassign >>>> or Reallocate unused inventory (ie trade and monetize via brokers). >>>> >>>> Orin Roberts >>>> *From:*ARIN-PPML [mailto:arin-ppml-bounces at arin.net]*On Behalf >>>> Of*Andrew Bagrin >>>> *Sent:*November-27-17 3:35 PM >>>> *To:*Austin Murkland >>> >; Andre Dalle >>> > *Cc:*ARIN-PPML List >>> > >>>> *Subject:*Re: [arin-ppml] Draft Policy ARIN-2017-12: Require New >>>> POC Validation Upon Reassignment I?d also like to see a $100 >>>> monthly fee per IPv4 /24 currently assigned. >>>> I held onto a /16 at a previous company, just because it was cool >>>> but had no use for it. I checked recently and it is still assigned >>>> to the same company and not being used 15 years later. >>>> By adding a $25k monthly fee, they would quickly return the block. >>>> Currently we have to pay brokers or sellers to acquire more IPv4 >>>> space. I would rather pay ARIN which could go to better funding the >>>> organization. >>>> *From:*ARIN-PPML [mailto:arin-ppml-bounces at arin.net >>>> ]*On Behalf Of*Austin Murkland >>>> *Sent:*Monday, November 27, 2017 3:26 PM *To:*Andre Dalle >>>> > *Cc:*ARIN-PPML List >>>> > >>>> *Subject:*Re: [arin-ppml] Draft Policy ARIN-2017-12: Require New >>>> POC Validation Upon Reassignment Also support this On Wed, Nov 22, >>>> 2017 at 6:20 PM, Andre Dalle > >>>> wrote: >>>> >>>> >>>> All my IPv4 space is reassigned, and I discovered last year that >>>> not all of it - from the same carrier - is properly associated >>>> with us. >>>> >>>> Upstream created a POC for us (even though we were an existing >>>> customer with multiple reassignments), and it's been sluggish >>>> getting them to >>>> sort it out. We have rDNS, so most abuse reporting still finds us, >>>> but some abuse mechanisms out there rely on POC info. >>>> >>>> So I think this is necessary. +100 from here as well. >>>> >>>> ---- >>>> Andr? Dalle >>>> Systems Administrator >>>> National Capital FreeNet [http://www.ncf.ca >>>> ] >>>> >>>> ----- Original Message ----- >>>> From: "Joe Provo" >>> > >>>> To: "ARIN-PPML List" >>> > >>>> Sent: Wednesday, 22 November, 2017 11:01:59 >>>> Subject: Re: [arin-ppml] Draft Policy ARIN-2017-12: Require New >>>> POC Validation Upon Reassignment >>>> >>>> On Tue, Nov 21, 2017 at 06:13:46PM -0500, David Huberman wrote: >>>> > Thank you Scott. As the co-author, I very much recognize this >>>> > proposal text is a ???first draft???. Working with my co-author >>>> > Jason Schiller, and having solicited feedback from the AC, this >>>> > proposal was submitted to solve the general problem. My hope was >>>> > the mechanics would be looked at critically by the community >>>> during >>>> > the PDP, and we would work together to improve them. >>>> >>>> With my personal hat on I'm very happy to see this getting >>>> to discussion. +100 for intent and I look forward to useful >>>> language suggestions here. >>>> >>>> -- >>>> Posted from my personal account - see X-Disclaimer header. >>>> Joe Provo / Gweep / Earthling >>>> _______________________________________________ >>>> PPML >>>> You are receiving this message because you are subscribed to >>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net >>>> ). >>>> Unsubscribe or manage your mailing list subscription at: >>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>> Please contactinfo at arin.net if you >>>> experience any issues. >>>> _______________________________________________ >>>> PPML >>>> You are receiving this message because you are subscribed to >>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net >>>> ). >>>> Unsubscribe or manage your mailing list subscription at: >>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>> Please contactinfo at arin.net if you >>>> experience any issues. >>>> >>>> _______________________________________________ >>>> PPML >>>> You are receiving this message because you are subscribed to the >>>> ARIN Public Policy Mailing List (ARIN-PPML at arin.net >>>> ). >>>> Unsubscribe or manage your mailing list subscription at: >>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>> Please contactinfo at arin.net if you experience >>>> any issues. >>> >>> >>> >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to the >>> ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>> Unsubscribe or manage 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 Nov 30 13:03:11 2017 From: owen at delong.com (Owen DeLong) Date: Thu, 30 Nov 2017 10:03:11 -0800 Subject: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment In-Reply-To: References: <20171122160159.GA41025@gweep.net> <1965618547.183023.1511392822657.JavaMail.zimbra@ncf.ca> <0d4075293a247645e6bf46b7343b767c@mail.gmail.com> <5A1FA060.7090609@ipinc.net> <9f6dd4f4ec02404447cffb4596e59194@mail.gmail.com> Message-ID: Can we please take this rat-hole out of the policy discussion and move it to an appropriate list? Fees are _NOT_ the purview of the PPML or the ARIN PDP. Owen > On Nov 30, 2017, at 08:51 , Andrew Bagrin wrote: > > That's why a suggested a fee, to make that space find us instead of us > finding it. > I can see this is not really of interest and the bigger interest is to > launch v6 and forget about v4, so I'll stick to the plan. > > -----Original Message----- > From: hostmaster at uneedus.com [mailto:hostmaster at uneedus.com] > Sent: Thursday, November 30, 2017 11:46 AM > To: arin-ppml at arin.net > Cc: Andrew Bagrin > Subject: RE: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC > Validation Upon Reassignment > > Private space is a valid use, as this is one of the only ways to ensure > uniqueness. Look at the US Postal Service as an example of this. They have > gobs of mail sorting machines on their class A, none of which is exposed to > the internet. Their public facing services are also in the lower portion of > this block, so they have both uses. > > If you are not using it, and there are no future plans for it, is is quite > likely that the company will eventually be contacted by a broker regarding > the sale or lease of the space. I suspect that most of the contacts by > brokers are initially made by the broker, to those in charge of possible > space that might be available. Most of their work is trying to track down > possible available space. Without available space, the broker really does > not have a product to offer, since the buyer is the source of the money for > both the buyer and the broker's commission. > > You are right that this is not likely the only available network. Even so, > we will never find enough IPv4 space to cover demand. As the available > blocks get smaller, it becomes an even more cost intense job. > > Albert Erdmann > Network Administrator > Paradise On Line Inc. > > > On Thu, 30 Nov 2017, Andrew Bagrin wrote: > >> The mythical space is 168.86.0.0/16 direct assignment NATIO-42 >> https://whois.arin.net/rest/net/NET-168-86-0-0-1/pft?s=168.86.1.1 >> I got a hold of it when we acquire United Artists. They used it as >> private space. >> I just did a ping sweep and got no replies. Nothing on BGP dig either. >> >> I have a hard time believing they are the only ones. >> >> >> >> -----Original Message----- >> From: ARIN-PPML [mailto:arin-ppml-bounces at arin.net] On Behalf Of >> hostmaster at uneedus.com >> Sent: Thursday, November 30, 2017 9:08 AM >> To: arin-ppml at arin.net >> Subject: Re: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC >> Validation Upon Reassignment >> >> Unless the space is legacy, I do not see how space can remain open for >> 15 years on autopilot, as someone must be paying the ARIN bill. >> >> Even under the original policies, review of use of IPv4 space only >> comes up in the context of requesting more space from ARIN. In light >> of the marketability of unused space, eventually someone from that org >> will eventually either use/lease/sell the space, and the tighter >> things go, the more likely this will happen. It is very unlikely >> anyone will just return the space, since it now has value. >> >> This has been discussed before. The amount of resources that would be >> required at ARIN to recover space from orgs that no longer exist far >> exceed the current value of the space recovered. The mythical class B >> we are discussing here is in fact getting quite rare, and the brokers >> are getting better at tracking these down and getting them back to use. >> >> In fact, it looks like the bulk of the legacy space with bad contacts >> are approaching the /22 to /24 level, not really worth the effort, >> considering that we all know the basic math is always against continued >> use of IPv4. >> That math being the simple fact that the total number of possible IPv4 >> addresses is much less than the world population. >> >> At some point, we will pass a hump in IPv6 adoption, and this will >> drive us toward IPv6 becoming the main protocol on the worldwide >> internet. I think at that point, that will become the peak of IPv4 >> value. Once IPv6 becomes the main protocol, the value of IPv4 addresses >> will fall like a rock. >> >> Albert Erdmann >> Network Administrator >> Paradise On Line Inc. >> >> >> On Wed, 29 Nov 2017, Ted Mittelstaedt wrote: >> >>> >>> And I will point out that the entire point of validating POCs is to >>> discover things like /16's that haven't been used for 15 years. >>> >>> It would seem to me that ARIN staff vacillates between loving and >>> hating section 3.6 of the NRPM. Some years they see any attempt at >>> housecleaning stale assignments that are just on autopilot (like this >>> mythical /16 - I love how when people cite these examples they never >>> state the actual numbers - hello!) as an obstacle to increased IPv6 >>> adoption so they hate it and undercut it. Other years they desperately >>> need to get some IPv4 for someone very big and powerful with maybe a >>> whole lot of guns and rocket launchers and such and they love this >>> section since it allows them to scrape together some IPv4 for a need. >>> >>> Ted >>> >>> On 11/27/2017 4:24 PM, Owen DeLong wrote: >>>> Before we travel too far down this branch of discussion, I?d like to >>>> point out that fees are not within the realm of ARIN policy debate >>>> and therefore aren?t really an appropriate topic for this list. >>>> >>>> If you?d like to discuss such a fee, there is arin-discuss (open to >>>> Members/Staff/Board/AC) where fee discussions are appropriate. >>>> >>>> Alternatively, there is also the ARIN Consultation and Suggestion >>>> Process (ACSP) available via the Participate tab on the ARIN web site. >>>> >>>> Thanks, >>>> >>>> Owen >>>> >>>>> On Nov 27, 2017, at 13:08 , Steven Ryerse >>>>> >>>> > >>>>> wrote: >>>>> >>>>> I don?t see how you can go back and start charging Legacy holders >>>>> that obtained their blocks before ARIN was created. You would have >>>>> to charge big companies like AT&T & IBM and you would have to >>>>> somehow charge the Dept. of Defense and so forth to make it fair to >>>>> everyone. >>>>> Seems like that ship sailed long ago. >>>>> /Steven Ryerse/ >>>>> /President/ >>>>> /100 Ashford Center North, Suite 110, Atlanta, GA 30338/ >>>>> /770.656.1460 - Cell/ >>>>> /770.399.9099 - Office/ >>>>> /770.392.0076 - Fax/ >>>>> ?Eclipse Networks, Inc. >>>>> ^Conquering Complex Networks ^? ^ >>>>> *From:*ARIN-PPML [mailto:arin-ppml-bounces at arin.net]*On Behalf >>>>> Of*Roberts, Orin *Sent:*Monday, November 27, 2017 3:59 PM >>>>> *To:*Andrew Bagrin > >>>>> *Cc:*ARIN-PPML List >>>> > >>>>> *Subject:*Re: [arin-ppml] Draft Policy ARIN-2017-12: Require New >>>>> POC Validation Upon Reassignment I see obstacles but increased fees >>>>> would lead to greater efficiency in >>>>> IPv4 assignments and usage or at the very least aid in the >>>>> migration to IPv6. >>>>> >>>>> 1. Charging a monthly fee (or higher monthly fee), means increased >>>>> costs to end-users for whatever services said company provides. >>>>> 2. ISP?s with VERY LARGE inventory of IPs would lobby against such a >>>>> proposal. A typical ISP would have several /16?s in reservation - >>>>> capacity planning. >>>>> 3. What?s to stop companies from doing what they do now? ? Reassign >>>>> or Reallocate unused inventory (ie trade and monetize via brokers). >>>>> >>>>> Orin Roberts >>>>> *From:*ARIN-PPML [mailto:arin-ppml-bounces at arin.net]*On Behalf >>>>> Of*Andrew Bagrin >>>>> *Sent:*November-27-17 3:35 PM >>>>> *To:*Austin Murkland >>>> >; Andre Dalle >>>> > *Cc:*ARIN-PPML List >>>> > >>>>> *Subject:*Re: [arin-ppml] Draft Policy ARIN-2017-12: Require New >>>>> POC Validation Upon Reassignment I?d also like to see a $100 >>>>> monthly fee per IPv4 /24 currently assigned. >>>>> I held onto a /16 at a previous company, just because it was cool >>>>> but had no use for it. I checked recently and it is still assigned >>>>> to the same company and not being used 15 years later. >>>>> By adding a $25k monthly fee, they would quickly return the block. >>>>> Currently we have to pay brokers or sellers to acquire more IPv4 >>>>> space. I would rather pay ARIN which could go to better funding the >>>>> organization. >>>>> *From:*ARIN-PPML [mailto:arin-ppml-bounces at arin.net >>>>> ]*On Behalf Of*Austin Murkland >>>>> *Sent:*Monday, November 27, 2017 3:26 PM *To:*Andre Dalle >>>>> > *Cc:*ARIN-PPML List >>>>> > >>>>> *Subject:*Re: [arin-ppml] Draft Policy ARIN-2017-12: Require New >>>>> POC Validation Upon Reassignment Also support this On Wed, Nov 22, >>>>> 2017 at 6:20 PM, Andre Dalle > >>>>> wrote: >>>>> >>>>> >>>>> All my IPv4 space is reassigned, and I discovered last year that >>>>> not all of it - from the same carrier - is properly associated >>>>> with us. >>>>> >>>>> Upstream created a POC for us (even though we were an existing >>>>> customer with multiple reassignments), and it's been sluggish >>>>> getting them to >>>>> sort it out. We have rDNS, so most abuse reporting still finds us, >>>>> but some abuse mechanisms out there rely on POC info. >>>>> >>>>> So I think this is necessary. +100 from here as well. >>>>> >>>>> ---- >>>>> Andr? Dalle >>>>> Systems Administrator >>>>> National Capital FreeNet [http://www.ncf.ca >>>>> ] >>>>> >>>>> ----- Original Message ----- >>>>> From: "Joe Provo" >>>> > >>>>> To: "ARIN-PPML List" >>>> > >>>>> Sent: Wednesday, 22 November, 2017 11:01:59 >>>>> Subject: Re: [arin-ppml] Draft Policy ARIN-2017-12: Require New >>>>> POC Validation Upon Reassignment >>>>> >>>>> On Tue, Nov 21, 2017 at 06:13:46PM -0500, David Huberman wrote: >>>>>> Thank you Scott. As the co-author, I very much recognize this >>>>>> proposal text is a ???first draft???. Working with my co-author >>>>>> Jason Schiller, and having solicited feedback from the AC, this >>>>>> proposal was submitted to solve the general problem. My hope was >>>>>> the mechanics would be looked at critically by the community >>>>> during >>>>>> the PDP, and we would work together to improve them. >>>>> >>>>> With my personal hat on I'm very happy to see this getting >>>>> to discussion. +100 for intent and I look forward to useful >>>>> language suggestions here. >>>>> >>>>> -- >>>>> Posted from my personal account - see X-Disclaimer header. >>>>> Joe Provo / Gweep / Earthling >>>>> _______________________________________________ >>>>> PPML >>>>> You are receiving this message because you are subscribed to >>>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net >>>>> ). >>>>> Unsubscribe or manage your mailing list subscription at: >>>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>>> Please contactinfo at arin.net if you >>>>> experience any issues. >>>>> _______________________________________________ >>>>> PPML >>>>> You are receiving this message because you are subscribed to >>>>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net >>>>> ). >>>>> Unsubscribe or manage your mailing list subscription at: >>>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>>> Please contactinfo at arin.net if you >>>>> experience any issues. >>>>> >>>>> _______________________________________________ >>>>> PPML >>>>> You are receiving this message because you are subscribed to the >>>>> ARIN Public Policy Mailing List (ARIN-PPML at arin.net >>>>> ). >>>>> Unsubscribe or manage your mailing list subscription at: >>>>> http://lists.arin.net/mailman/listinfo/arin-ppml >>>>> Please contactinfo at arin.net if you experience >>>>> any issues. >>>> >>>> >>>> >>>> _______________________________________________ >>>> PPML >>>> You are receiving this message because you are subscribed to the >>>> ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >>>> Unsubscribe or manage 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 Thu Nov 30 13:15:37 2017 From: owen at delong.com (Owen DeLong) Date: Thu, 30 Nov 2017 10:15:37 -0800 Subject: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment In-Reply-To: References: Message-ID: <238D16DF-59FF-4A98-91D7-A073F87CD228@delong.com> IMO, it is absolutely how the system should work. Owen > On Nov 30, 2017, at 07:51 , Chris Woodfield wrote: > > One point to make on this proposal is that this may change how ISPs assign blocks, given that both transfers and allocations have needs-based policies in force (for both v4 and v6), and SWIPs are generally used as evidence of utilization of existing blocks. With this proposal in force, adding a SWIP to an allocated block should no longer be considered a parallel process to assigning space to a downstream customer; instead, the insertion of a SWIP with a validated POC will be a blocking function on the downstream allocation, otherwise customers will be utilizing blocks without SWIPs if the POC is never validated. > > IMO this is how I feel the system *should* work, but then again, I?m currently not in the business of doing these kinds of assignments. Those who would be more directly impacted by this may have a different point of view :) > > -C > >> On Nov 21, 2017, at 2:43 PM, ARIN wrote: >> >> On 16 November 2017, the ARIN Advisory Council (AC) advanced "ARIN-prop-247: Require New POC Validation Upon Reassignment" to Draft Policy status. >> >> Draft Policy ARIN-2017-12 is below and can be found at: >> https://www.arin.net/policy/proposals/2017_12.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-12: Require New POC Validation Upon Reassignment >> >> Problem Statement: >> >> Some large ISPs assign individuals to be POCs for reassigned blocks without consultation of the individual they are inserting into Whois. One year later, the POC is contacted by ARIN as part of Annual POC Validation policies. The POC often does not know who ARIN is, what Whois is, and why they are in Whois. >> >> This policy proposal seeks to improve the situation where a POC is unwittingly and unwantingly inserted into Whois. >> >> It also seeks to mitigate the significant amount of time that ARIN staff reports that they spend fielding phone calls from POCs who have no idea they are in Whois. >> >> Finally, it is hopeful that this proposal will improve the overall POC validation situation, by forcing ISPs and customers to work together to insert proper information into Whois at the time of sub-delegation. >> >> Policy statement: >> >> Insert two new sections into NRPM 3: >> >> 3.7 New POC Validation Upon Reassignment >> >> When an ISP submits a valid reallocation or detailed reassignment request to ARIN which would result in a new POC object being created, ARIN must (before otherwise approving the request) contact the new POC by email for validation. ARIN's notification will, at a minimum, notify the POC of: >> >> - the information about the organization submitting the record; and >> - the resource(s) to which the POC is being attached; and >> - the organization(s) to which the POC is being attached. >> >> If the POC validates the request, the request shall be accepted by ARIN and the new objects inserted into Whois. If the POC does not validate the request within 10 days, ARIN must reject the request. >> >> 3.8 Downstream Validation of Simple Reassignments >> >> When an ISP submits a valid simple reassigment request to ARIN with an organization name OR postal address that is identical to one or more existing OrgIDs, ARIN will notify the downstream organization and obtain guidance on whether to accept the simple reassigment, or redirect it to one of the existing OrgIDs as a detailed reassignment. >> >> 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. From owen at delong.com Thu Nov 30 13:25:21 2017 From: owen at delong.com (Owen DeLong) Date: Thu, 30 Nov 2017 10:25:21 -0800 Subject: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment In-Reply-To: References: <20171122160159.GA41025@gweep.net> <1965618547.183023.1511392822657.JavaMail.zimbra@ncf.ca> Message-ID: > On Nov 30, 2017, at 05:38 , hostmaster at uneedus.com wrote: > > I support this policy. > > Giving ISP's/LIR's the ability to add reassignment contacts without verification from the contacts being added I think was always wrong. Often, the email added was NOT someone who actually processed abuse issues, but often was instead someone from purchasing or marketing who had absolutely no clue who or why we have ARIN. Often that person had no clue as to what address should be used (often a role account), and thus never provided the ISP with that correct information. Thus, the ISP used that person's info instead. As a result, when they got the verification email, they thought it was phishing or spam and ignored it. In our case, at least, it was often some contracting agent or other similar role who dealt with signing the legal documents with the ISP or filling out the order forms with the ISP to get the space and had little or no correlation to the technical, billing, or abuse aspects of actually administering the space. > Ensuring that added contacts in the database have been verified at creation time should go a long way in helping to keep the database clean. At a minimum, at least those who have verified their contact before entry into the database should know who ARIN is, and why they need to respond to that annual email. I would suggest that the verification email also remind the person of the future annual verification email that will be sent, and reminding them that they need to confirm their info once a year. It will also remove an ongoing problem that I?ve spent roughly 200 hours per year for the last 2 years sorting out. Owen From owen at delong.com Thu Nov 30 13:36:28 2017 From: owen at delong.com (Owen DeLong) Date: Thu, 30 Nov 2017 10:36:28 -0800 Subject: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment In-Reply-To: <5A1FA060.7090609@ipinc.net> References: <20171122160159.GA41025@gweep.net> <1965618547.183023.1511392822657.JavaMail.zimbra@ncf.ca> <0d4075293a247645e6bf46b7343b767c@mail.gmail.com> <5A1FA060.7090609@ipinc.net> Message-ID: <1FBD1C3B-543C-4F91-BC7D-E0017E79E9B9@delong.com> > On Nov 29, 2017, at 22:08 , Ted Mittelstaedt wrote: > > > And I will point out that the entire point of validating POCs is to discover things like /16's that haven't been used for 15 years. I?m not convinced this is true. I think the entire point of validating POCs is to make sure that all resources have valid POCs. I think that if the entire point were discovering /16s that haven?t been used for 15 years, then POC validation would be tied to some process for liberating those resources for reissue. Owen > > It would seem to me that ARIN staff vacillates between loving and hating section 3.6 of the NRPM. Some years they see any attempt at > housecleaning stale assignments that are just on autopilot (like this > mythical /16 - I love how when people cite these examples they never > state the actual numbers - hello!) as an obstacle to increased IPv6 > adoption so they hate it and undercut it. Other years they desperately > need to get some IPv4 for someone very big and powerful with maybe a > whole lot of guns and rocket launchers and such and they love this > section since it allows them to scrape together some IPv4 for a need. > > Ted > > On 11/27/2017 4:24 PM, Owen DeLong wrote: >> Before we travel too far down this branch of discussion, I?d like to >> point out that fees are not within the realm of ARIN policy debate and >> therefore aren?t really an appropriate topic for this list. >> >> If you?d like to discuss such a fee, there is arin-discuss (open to >> Members/Staff/Board/AC) where fee discussions are appropriate. >> >> Alternatively, there is also the ARIN Consultation and Suggestion >> Process (ACSP) available via the Participate tab on the ARIN web site. >> >> Thanks, >> >> Owen >> >>> On Nov 27, 2017, at 13:08 , Steven Ryerse >>> > >>> wrote: >>> >>> I don?t see how you can go back and start charging Legacy holders that >>> obtained their blocks before ARIN was created. You would have to >>> charge big companies like AT&T & IBM and you would have to somehow >>> charge the Dept. of Defense and so forth to make it fair to everyone. >>> Seems like that ship sailed long ago. >>> /Steven Ryerse/ >>> /President/ >>> /100 Ashford Center North, Suite 110, Atlanta, GA 30338/ >>> /770.656.1460 - Cell/ >>> /770.399.9099 - Office/ >>> /770.392.0076 - Fax/ >>> ?Eclipse Networks, Inc. >>> ^Conquering Complex Networks ^? ^ >>> *From:*ARIN-PPML [mailto:arin-ppml-bounces at arin.net]*On Behalf >>> Of*Roberts, Orin >>> *Sent:*Monday, November 27, 2017 3:59 PM >>> *To:*Andrew Bagrin > >>> *Cc:*ARIN-PPML List > >>> *Subject:*Re: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC >>> Validation Upon Reassignment >>> I see obstacles but increased fees would lead to greater efficiency in >>> IPv4 assignments and usage or at the very least aid in the migration >>> to IPv6. >>> >>> 1. Charging a monthly fee (or higher monthly fee), means increased >>> costs to end-users for whatever services said company provides. >>> 2. ISP?s with VERY LARGE inventory of IPs would lobby against such a >>> proposal. A typical ISP would have several /16?s in reservation - >>> capacity planning. >>> 3. What?s to stop companies from doing what they do now? ? Reassign >>> or Reallocate unused inventory (ie trade and monetize via brokers). >>> >>> Orin Roberts >>> *From:*ARIN-PPML [mailto:arin-ppml-bounces at arin.net]*On Behalf >>> Of*Andrew Bagrin >>> *Sent:*November-27-17 3:35 PM >>> *To:*Austin Murkland >> >; Andre Dalle >> > >>> *Cc:*ARIN-PPML List > >>> *Subject:*Re: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC >>> Validation Upon Reassignment >>> I?d also like to see a $100 monthly fee per IPv4 /24 currently assigned. >>> I held onto a /16 at a previous company, just because it was cool but >>> had no use for it. I checked recently and it is still assigned to the >>> same company and not being used 15 years later. >>> By adding a $25k monthly fee, they would quickly return the block. >>> Currently we have to pay brokers or sellers to acquire more IPv4 >>> space. I would rather pay ARIN which could go to better funding the >>> organization. >>> *From:*ARIN-PPML [mailto:arin-ppml-bounces at arin.net >>> ]*On Behalf Of*Austin Murkland >>> *Sent:*Monday, November 27, 2017 3:26 PM >>> *To:*Andre Dalle > >>> *Cc:*ARIN-PPML List > >>> *Subject:*Re: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC >>> Validation Upon Reassignment >>> Also support this >>> On Wed, Nov 22, 2017 at 6:20 PM, Andre Dalle >> > wrote: >>> >>> >>> All my IPv4 space is reassigned, and I discovered last year that >>> not all of it - from the same carrier - is properly associated >>> with us. >>> >>> Upstream created a POC for us (even though we were an existing >>> customer with multiple reassignments), and it's been sluggish >>> getting them to >>> sort it out. We have rDNS, so most abuse reporting still finds us, >>> but some abuse mechanisms out there rely on POC info. >>> >>> So I think this is necessary. +100 from here as well. >>> >>> ---- >>> Andr? Dalle >>> Systems Administrator >>> National Capital FreeNet [http://www.ncf.ca ] >>> >>> ----- Original Message ----- >>> From: "Joe Provo" > >>> To: "ARIN-PPML List" > >>> Sent: Wednesday, 22 November, 2017 11:01:59 >>> Subject: Re: [arin-ppml] Draft Policy ARIN-2017-12: Require New >>> POC Validation Upon Reassignment >>> >>> On Tue, Nov 21, 2017 at 06:13:46PM -0500, David Huberman wrote: >>> > Thank you Scott. As the co-author, I very much recognize this >>> > proposal text is a ???first draft???. Working with my co-author >>> > Jason Schiller, and having solicited feedback from the AC, this >>> > proposal was submitted to solve the general problem. My hope was >>> > the mechanics would be looked at critically by the community during >>> > the PDP, and we would work together to improve them. >>> >>> With my personal hat on I'm very happy to see this getting >>> to discussion. +100 for intent and I look forward to useful >>> language suggestions here. >>> >>> -- >>> Posted from my personal account - see X-Disclaimer header. >>> Joe Provo / Gweep / Earthling >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to >>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net >>> ). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contactinfo at arin.net if you >>> experience any issues. >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to >>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net >>> ). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contactinfo at arin.net if you >>> experience any issues. >>> >>> _______________________________________________ >>> PPML >>> You are receiving this message because you are subscribed to >>> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net >>> ). >>> Unsubscribe or manage your mailing list subscription at: >>> http://lists.arin.net/mailman/listinfo/arin-ppml >>> Please contactinfo at arin.net if you experience >>> any issues. >> >> >> >> _______________________________________________ >> PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net). >> Unsubscribe or manage 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 hostmaster at uneedus.com Thu Nov 30 13:44:45 2017 From: hostmaster at uneedus.com (hostmaster at uneedus.com) Date: Thu, 30 Nov 2017 13:44:45 -0500 (EST) Subject: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment In-Reply-To: <238D16DF-59FF-4A98-91D7-A073F87CD228@delong.com> References: <238D16DF-59FF-4A98-91D7-A073F87CD228@delong.com> Message-ID: While SWIP assignments are used for determining the amount of addressses in use, there is nothing in the current rules that would require reporting this data down to the individual customer level in most cases. As an example, most ISP's/LIR's provide each customer with a single IPv4 address for their use. This address may be either static or dynamic. In any case, since this assigment is below /27, there is no requirement that SWIP be done to the customer level. Such ISP could SWIP a block of addresses used for dynamic customer addresses, showing them in use, but not showing an individual record for each customer. Ditto with a block of addresses used for static single address assignments. These collective SWIP records show the addresses are being used, but do not require detail down to the customer level. In the dialup days of the past, blocks of addresses used for dial up pools were commonly registered as one collective block. When these became address pools for CTMS and DSL PPPoe, the same thing was often done, registering the blocks to show their use, often showing what area in the detail records. However, without an assignment of at least /27 to a individual customer, there has never been a requirement to SWIP to the customer level. Before 2013, that line was /24. Because of the massive (compared to IPv4) blocks given out with IPv6, the need for SWIP except for multihome and downstream ISP's may go away. My experence is that many ISP's with v6 blocks have SWIP'ed nothing, and since they are not going back to ARIN for more space, and having to justify their current use, it is unlikely that SWIP in IPv6 will ever be used to the extent it is in IPv4, since they are not seeking another bite of the apple. Albert Erdmann Network Administrator Paradise On Line Inc. On Thu, 30 Nov 2017, Owen DeLong wrote: > IMO, it is absolutely how the system should work. > > Owen > >> On Nov 30, 2017, at 07:51 , Chris Woodfield wrote: >> >> One point to make on this proposal is that this may change how ISPs assign blocks, given that both transfers and allocations have needs-based policies in force (for both v4 and v6), and SWIPs are generally used as evidence of utilization of existing blocks. With this proposal in force, adding a SWIP to an allocated block should no longer be considered a parallel process to assigning space to a downstream customer; instead, the insertion of a SWIP with a validated POC will be a blocking function on the downstream allocation, otherwise customers will be utilizing blocks without SWIPs if the POC is never validated. >> >> IMO this is how I feel the system *should* work, but then again, I???m currently not in the business of doing these kinds of assignments. Those who would be more directly impacted by this may have a different point of view :) >> >> -C >> >>> On Nov 21, 2017, at 2:43 PM, ARIN wrote: >>> >>> On 16 November 2017, the ARIN Advisory Council (AC) advanced "ARIN-prop-247: Require New POC Validation Upon Reassignment" to Draft Policy status. >>> >>> Draft Policy ARIN-2017-12 is below and can be found at: >>> https://www.arin.net/policy/proposals/2017_12.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-12: Require New POC Validation Upon Reassignment >>> >>> Problem Statement: >>> >>> Some large ISPs assign individuals to be POCs for reassigned blocks without consultation of the individual they are inserting into Whois. One year later, the POC is contacted by ARIN as part of Annual POC Validation policies. The POC often does not know who ARIN is, what Whois is, and why they are in Whois. >>> >>> This policy proposal seeks to improve the situation where a POC is unwittingly and unwantingly inserted into Whois. >>> >>> It also seeks to mitigate the significant amount of time that ARIN staff reports that they spend fielding phone calls from POCs who have no idea they are in Whois. >>> >>> Finally, it is hopeful that this proposal will improve the overall POC validation situation, by forcing ISPs and customers to work together to insert proper information into Whois at the time of sub-delegation. >>> >>> Policy statement: >>> >>> Insert two new sections into NRPM 3: >>> >>> 3.7 New POC Validation Upon Reassignment >>> >>> When an ISP submits a valid reallocation or detailed reassignment request to ARIN which would result in a new POC object being created, ARIN must (before otherwise approving the request) contact the new POC by email for validation. ARIN's notification will, at a minimum, notify the POC of: >>> >>> - the information about the organization submitting the record; and >>> - the resource(s) to which the POC is being attached; and >>> - the organization(s) to which the POC is being attached. >>> >>> If the POC validates the request, the request shall be accepted by ARIN and the new objects inserted into Whois. If the POC does not validate the request within 10 days, ARIN must reject the request. >>> >>> 3.8 Downstream Validation of Simple Reassignments >>> >>> When an ISP submits a valid simple reassigment request to ARIN with an organization name OR postal address that is identical to one or more existing OrgIDs, ARIN will notify the downstream organization and obtain guidance on whether to accept the simple reassigment, or redirect it to one of the existing OrgIDs as a detailed reassignment. >>> >>> 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. > From lar at mwtcorp.net Thu Nov 30 17:04:08 2017 From: lar at mwtcorp.net (Larry Ash) Date: Thu, 30 Nov 2017 15:04:08 -0700 Subject: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment In-Reply-To: References: Message-ID: I oppose this Policy, The result of this would be I would have to pretty much stop SWIP submissions. Many of my reassignments are small enough that SWIP is optional anyway. Of the aprox 110 reassignments I have made, 3 have someone there that could respond to an issue, one of which for some reason hates ARIN and refuses to have anything to do with them. An additional dozen or so might very well send you their email password if you ask and claim to be their email provider. I have chosen to SWIP small reassignments for ease of justification if further IPv4 is needed and for transparency to the net if an issue arises. Some are multiple geographically dispersed offices of a single enity. Some are multiple tenents of a larger multi-tenent building. The IT resources for many of these offices are frequently consultants or corporate folks that might be hundreds of miles away. Neither is likely to respond to POC requests. That, I though, was the idea for the simple reassignment. I remain the POC for the reassignment and am responsive to issues when contacted. Larry Ash COO Mountain West Telephone 123 W 1st St. Casper, WY 82601 Office 307 233-8387 >> >> Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment >> >> Problem Statement: >> >> Some large ISPs assign individuals to be POCs for reassigned blocks without consultation of the individual they are inserting >>into Whois. One year later, the POC is contacted by ARIN as part of Annual POC Validation policies. The POC often does not know >>who ARIN is, what Whois is, and why they are in Whois. >> >> This policy proposal seeks to improve the situation where a POC is unwittingly and unwantingly inserted into Whois. >> >> It also seeks to mitigate the significant amount of time that ARIN staff reports that they spend fielding phone calls from POCs >>who have no idea they are in Whois. >> >> Finally, it is hopeful that this proposal will improve the overall POC validation situation, by forcing ISPs and customers to >>work together to insert proper information into Whois at the time of sub-delegation. >> >> Policy statement: >> >> Insert two new sections into NRPM 3: >> >> 3.7 New POC Validation Upon Reassignment >> >> When an ISP submits a valid reallocation or detailed reassignment request to ARIN which would result in a new POC object being >>created, ARIN must (before otherwise approving the request) contact the new POC by email for validation. ARIN's notification >>will, at a minimum, notify the POC of: >> >> - the information about the organization submitting the record; and >> - the resource(s) to which the POC is being attached; and >> - the organization(s) to which the POC is being attached. >> >> If the POC validates the request, the request shall be accepted by ARIN and the new objects inserted into Whois. If the POC >>does not validate the request within 10 days, ARIN must reject the request. >> >> 3.8 Downstream Validation of Simple Reassignments >> >> When an ISP submits a valid simple reassigment request to ARIN with an organization name OR postal address that is identical to >>one or more existing OrgIDs, ARIN will notify the downstream organization and obtain guidance on whether to accept the simple >>reassigment, or redirect it to one of the existing OrgIDs as a detailed reassignment. >> >> 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 Thu Nov 30 18:30:41 2017 From: farmer at umn.edu (David Farmer) Date: Thu, 30 Nov 2017 17:30:41 -0600 Subject: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment In-Reply-To: References: Message-ID: Larry, Out of curiosity, are the reassignments you refer to Simple or Detailed Reassignments? I ask be cause this policy should only affect Detailed Reassignments, as they have their own POCs, and it is those POC will have to be validated because of this policy. Simple Reassignments don't have their own POCs, the organization making the reassignment remains the POC. Therefore this policy has no affect on Simple Reassignments, it should only affect Detailed Reassignments. Reading what you say below, I get the impression that most of the SWIPs in question are or at least could be Simple Reassignments. If they are not Simple Reassignments, please help me understand the reasons for that. Thanks. On Thu, Nov 30, 2017 at 4:04 PM, Larry Ash wrote: > I oppose this Policy, > > The result of this would be I would have to pretty much stop SWIP > submissions. Many of my reassignments are > small enough that SWIP is optional anyway. Of the aprox 110 reassignments > I have made, 3 have someone there that could > respond to an issue, one of which for some reason hates ARIN and refuses > to have anything to do with them. An additional > dozen or so might very well send you their email password if you ask and > claim to be their email provider. > > I have chosen to SWIP small reassignments for ease of justification if > further IPv4 is needed and for transparency to > the net if an issue arises. Some are multiple geographically dispersed > offices of a single enity. Some are multiple > tenents of a larger multi-tenent building. The IT resources for many of > these offices are frequently consultants > or corporate folks that might be hundreds of miles away. Neither is likely > to respond to POC requests. > > That, I though, was the idea for the simple reassignment. I remain the POC > for the reassignment and am responsive to > issues when contacted. > > Larry Ash COO > Mountain West Telephone > 123 W 1st St. > Casper, WY 82601 > Office 307 233-8387 -- =============================================== 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 lar at mwtcorp.net Thu Nov 30 19:25:05 2017 From: lar at mwtcorp.net (Larry Ash) Date: Thu, 30 Nov 2017 17:25:05 -0700 Subject: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment In-Reply-To: References: Message-ID: On Thu, 30 Nov 2017 17:30:41 -0600 David Farmer wrote: > Larry, > > Out of curiosity, are the reassignments you refer to Simple or Detailed > Reassignments? I ask be cause this policy should only affect Detailed > Reassignments, as they have their own POCs, and it is those POC will have > to be validated because of this policy. Simple Reassignments don't have > their own POCs, the organization making the reassignment remains the POC. > Therefore this policy has no affect on Simple Reassignments, it should only > affect Detailed Reassignments. > > Reading what you say below, I get the impression that most of the SWIPs in > question are or at least could be Simple Reassignments. If they are not > Simple Reassignments, please help me understand the reasons for that. > They are simple reassignments. I am reacting mostly to: > 3.8 Downstream Validation of Simple Reassignments > > When an ISP submits a valid simple reassigment request to ARIN with an organization name OR postal address that is identical to one or more existing OrgIDs, ARIN will notify the downstream organization and obtain guidance on whether to accept the simple reassigment, or redirect it to one of the existing OrgIDs as a detailed reassignment. > My problem that the ORG name is sometimes the same for multiple remote offices and the address can be the same for multiple offices in the same building. Larry > Thanks. > > On Thu, Nov 30, 2017 at 4:04 PM, Larry Ash wrote: > >> I oppose this Policy, >> >> The result of this would be I would have to pretty much stop SWIP >> submissions. Many of my reassignments are >> small enough that SWIP is optional anyway. Of the aprox 110 reassignments >> I have made, 3 have someone there that could >> respond to an issue, one of which for some reason hates ARIN and refuses >> to have anything to do with them. An additional >> dozen or so might very well send you their email password if you ask and >> claim to be their email provider. >> >> I have chosen to SWIP small reassignments for ease of justification if >> further IPv4 is needed and for transparency to >> the net if an issue arises. Some are multiple geographically dispersed >> offices of a single enity. Some are multiple >> tenents of a larger multi-tenent building. The IT resources for many of >> these offices are frequently consultants >> or corporate folks that might be hundreds of miles away. Neither is likely >> to respond to POC requests. >> >> That, I though, was the idea for the simple reassignment. I remain the POC >> for the reassignment and am responsive to >> issues when contacted. >> >> Larry Ash COO >> Mountain West Telephone >> 123 W 1st St. >> Casper, WY 82601 >> Office 307 233-8387 > > > > -- > =============================================== > 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> > =============================================== Larry Ash COO Mountain West Telephone 123 W 1st St. Casper, WY 82601 Office 307 233-8387 From owen at delong.com Thu Nov 30 21:19:30 2017 From: owen at delong.com (Owen DeLong) Date: Thu, 30 Nov 2017 18:19:30 -0800 Subject: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment In-Reply-To: References: Message-ID: Larry, If I understand you correctly, then this policy won?t affect you. The point of this policy is that if you do a reassignment that produces a new POC for a known organization, ARIN will make a good-faith effort to contact that organization and make sure the action is valid and in line with said organization?s expectations. If you?re reassignments all use existing POC handles within your organization and/or even new POCs that are within your organization, then you?re going to be the one that gets the verification requests in question (if any). (Existing POCs don?t get any new verification requests under this proposal, only newly created ones). An example of the problem this is intended to solve: XYZ Corp is a large service provider that has many discrete islands of service that get addresses from their transit providers. Transit provider Q should be SWIPing these addresses to ORG-ID XYZCORP, but instead creates a new ORG-ID ZZYZX and new POC (ZZYCONT-ARIN) referencing the purchasing agent at XYZ Corp that signed the paperwork for the circuit order. In this case, ARIN would match the organization up and send a message to the known contacts of XYZCORP asking them to validate the new ZZYCONT-ARIN POC. This would allow XYZCORP to either validate the new POC or contact provider Q and let them know that they need to fix the SWIP. To put the problem in perspective, I?ve personally spent several hours tracking down and correcting a bunch of these just in the last two weeks, and, as I stated earlier on the list, it?s been an average of 200 hours per year for the last 2 years wasted finding and correcting similar provider errors. Hope that clarifies things. In light of the fact that it sounds like this wouldn?t actually affect your reassign-simple SWIPs, does that change your position? Thanks, Owen > On Nov 30, 2017, at 14:04 , Larry Ash wrote: > > I oppose this Policy, > > The result of this would be I would have to pretty much stop SWIP submissions. Many of my reassignments are > small enough that SWIP is optional anyway. Of the aprox 110 reassignments I have made, 3 have someone there that could > respond to an issue, one of which for some reason hates ARIN and refuses to have anything to do with them. An additional > dozen or so might very well send you their email password if you ask and claim to be their email provider. > > I have chosen to SWIP small reassignments for ease of justification if further IPv4 is needed and for transparency to > the net if an issue arises. Some are multiple geographically dispersed offices of a single enity. Some are multiple > tenents of a larger multi-tenent building. The IT resources for many of these offices are frequently consultants > or corporate folks that might be hundreds of miles away. Neither is likely to respond to POC requests. > > That, I though, was the idea for the simple reassignment. I remain the POC for the reassignment and am responsive to > issues when contacted. > > Larry Ash COO > Mountain West Telephone > 123 W 1st St. > Casper, WY 82601 > Office 307 233-8387 > >>> Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment >>> Problem Statement: >>> Some large ISPs assign individuals to be POCs for reassigned blocks without consultation of the individual they are inserting into Whois. One year later, the POC is contacted by ARIN as part of Annual POC Validation policies. The POC often does not know who ARIN is, what Whois is, and why they are in Whois. >>> This policy proposal seeks to improve the situation where a POC is unwittingly and unwantingly inserted into Whois. >>> It also seeks to mitigate the significant amount of time that ARIN staff reports that they spend fielding phone calls from POCs who have no idea they are in Whois. >>> Finally, it is hopeful that this proposal will improve the overall POC validation situation, by forcing ISPs and customers to work together to insert proper information into Whois at the time of sub-delegation. >>> Policy statement: >>> Insert two new sections into NRPM 3: >>> 3.7 New POC Validation Upon Reassignment >>> When an ISP submits a valid reallocation or detailed reassignment request to ARIN which would result in a new POC object being created, ARIN must (before otherwise approving the request) contact the new POC by email for validation. ARIN's notification will, at a minimum, notify the POC of: >>> - the information about the organization submitting the record; and >>> - the resource(s) to which the POC is being attached; and >>> - the organization(s) to which the POC is being attached. >>> If the POC validates the request, the request shall be accepted by ARIN and the new objects inserted into Whois. If the POC does not validate the request within 10 days, ARIN must reject the request. >>> 3.8 Downstream Validation of Simple Reassignments >>> When an ISP submits a valid simple reassigment request to ARIN with an organization name OR postal address that is identical to one or more existing OrgIDs, ARIN will notify the downstream organization and obtain guidance on whether to accept the simple reassigment, or redirect it to one of the existing OrgIDs as a detailed reassignment. >>> 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. From farmer at umn.edu Thu Nov 30 22:02:46 2017 From: farmer at umn.edu (David Farmer) Date: Thu, 30 Nov 2017 21:02:46 -0600 Subject: [arin-ppml] Draft Policy ARIN-2017-12: Require New POC Validation Upon Reassignment In-Reply-To: References: Message-ID: On Thu, Nov 30, 2017 at 6:25 PM, Larry Ash wrote: > On Thu, 30 Nov 2017 17:30:41 -0600 > David Farmer wrote: > >> Larry, >> >> Out of curiosity, are the reassignments you refer to Simple or Detailed >> Reassignments? I ask be cause this policy should only affect Detailed >> Reassignments, as they have their own POCs, and it is those POC will have >> to be validated because of this policy. Simple Reassignments don't have >> their own POCs, the organization making the reassignment remains the POC. >> Therefore this policy has no affect on Simple Reassignments, it should >> only >> affect Detailed Reassignments. >> >> Reading what you say below, I get the impression that most of the SWIPs in >> question are or at least could be Simple Reassignments. If they are not >> Simple Reassignments, please help me understand the reasons for that. >> >> They are simple reassignments. I am reacting mostly to: > > 3.8 Downstream Validation of Simple Reassignments >> >> When an ISP submits a valid simple reassigment request to ARIN with an >> organization name OR postal address that is identical to one or more >> existing OrgIDs, ARIN will notify the downstream organization and obtain >> guidance on whether to accept the simple reassigment, or redirect it to one >> of the existing OrgIDs as a detailed reassignment. >> >> > My problem that the ORG name is sometimes the same for multiple remote > offices and the address can be the same for multiple offices > in the same building. > > > Larry > Section 3.8 doesn't apply to an Organization that only has Simple Reassignments. It only applies to an Organization that already has an OrdID, or in other words either an Allocation or Assignment directly from ARIN or a Reallocation or Detailed Reassignments from an ISP. If an Organization only has Simple Reassignments, it has no OrgID and therefore 3.8 doesn't apply to them. So if you make only Simple Reassignments to Mom & Pop's Bait & Tackle in multiple separate locations, that shouldn't trigger this. However, if you make a Simple Reassignment MEGA-BOX Bait & Tackle that already has a /16 direct assignment from ARIN then this should apply. Do you read it differently? 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: