Re: [arin-ppml] nrpm typo
Hi William, Thanks for bringing this to our attention. The AC would welcome a proposal to make an editorial change to correct this error. If you would rather not submit such a policy proposal, we will investigate and address this as an Advisory Council. PDP Section 2.8 describes a procedure for editorial updates to address textual errors among a few other cases, based on the contents of the proposal received. See: https://www.arin.net/participate/policy/pdp/ Matthew Wilder did a bit more digging and found this may not have been a typo but part of a very active ARIN-2010-8 rewrite implemented in 2011. Kat Hunter AC Chair Comcast LIR On Wed, Feb 14, 2024, 5:50 PM William Herrin wrote: > > https://www.arin.net/participate/policy/nrpm/#6-5-8-3-subsequent-assignments > > "assignments will result it the expansion of an" > > "it" the expansion of? > > > -- > William Herrin > b...@herrin.us > https://bill.herrin.us/ > ___ > ARIN-PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). > Unsubscribe or manage your mailing list subscription at: > https://lists.arin.net/mailman/listinfo/arin-ppml > Please contact i...@arin.net if you experience any issues. > ___ ARIN-PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-ppml Please contact i...@arin.net if you experience any issues.
Re: [arin-ppml] Draft Policy ARIN-2024-1: Definition of Organization ID/Org ID
All, there seems to be a cut and paste error in the email. Staff has been notified and a follow up email will follow with the correction. Kat Hunter Comcast ARIN AC chair On Wed, Jan 31, 2024 at 2:52 PM ARIN wrote: > On 26 January 2024, the ARIN Advisory Council (AC) accepted > “ARIN-prop-322: Modernization of Registration Requirements” as a Draft > Policy. > > > > Draft Policy ARIN-2024-1 is below and can be found at: > > > > https://www.arin.net/participate/policy/drafts/2024_1 > > > > You are encouraged to discuss all Draft Policies on PPML. The AC will > evaluate the discussion 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/participate/policy/pdp/ > > > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/participate/policy/drafts/ > > > > Regards, > > > > Eddie Diego > > Policy Analyst > > American Registry for Internet Numbers (ARIN) > > > > > > > > Draft Policy ARIN-2024-1: Definition of Organization ID/Org ID > > > > Problem Statement: > > > > During work on a related policy proposal, the NRPM Working Group > determined that a definition of Organization Identifier (Org ID) should be > included in the NRPM to add clarity to the term and unify NRPM references > to match the use of the term in other ARIN publications such as ARIN online. > > > > Policy Statement: > > > > Current: None > > > > Proposed: > > > > Section 2.18 Organizational Identifier (Org ID) > > > > An Organizational Identifier (Org ID) is a record that represents a > business, non-profit corporation, or government entity in the ARIN > database. An entity must have an Organizational Identifier (Org ID) to > request Internet Number Resources. > > > > Comments: > > > > This definition had previously been included in an earlier policy proposal > (ARIN-2023-7), but community feedback recommendations on that proposal > showed a preference for adding the definition separately from that > proposal. As such the definition is now being proposed as a standalone > proposal, and the language will be removed from the current ARIN-2023-7 > proposal, allowing the two sections of that proposal to be evaluated > separately. > > > > Timetable for Implementation: Immediate > > > > > > > > > ___ > ARIN-PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). > Unsubscribe or manage your mailing list subscription at: > https://lists.arin.net/mailman/listinfo/arin-ppml > Please contact i...@arin.net if you experience any issues. > ___ ARIN-PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-ppml Please contact i...@arin.net if you experience any issues.
Re: [arin-ppml] Draft Policy ARIN-2022-12: Direct Assignment Language Update
*correction- Orgs with Direct Allocations can make both Reallocations or Reassignments but end users or Orgs that do not have a direct allocation from ARIN can make reassignments ---Either way, the process should remain the same. Tracking reallocations and reassignments downstream is difficult enough. Kat Hunter On Sun, Aug 28, 2022 at 11:59 PM Kat Hunter wrote: > Even if the direct allocation tag within the database has been removed, > there are still references outside of the NRPM that use this designation > for "direct" assignment or allocation. If the NRPM is changed, > https://www.arin.net/resources/registry/reassignments/ would need to be > adjusted to reflect whatever the new process or terminology will be. > Currently, if you have a direct allocation you can make both reassignments > or reallocations. If you are an end user you can only update ARIN with a > reassignment. So long as the process for this doesn't change, I would > support this policy. However, I did want to remind the shepherds "direct > allocation" is more than just a database tag to many orgs. > > Kat Hunter > ARIN AC/Comcast > > On Tue, Aug 23, 2022 at 12:30 PM ARIN wrote: > >> On 18 August 2022, the ARIN Advisory Council (AC) accepted >> "ARIN-prop-317: Direct Assignment Language Update" as a Draft Policy. >> >> >> >> Draft Policy ARIN-2022-12 is below and can be found at: >> >> >> >> https://www.arin.net/participate/policy/drafts/2022_12/ >> >> >> >> You are encouraged to discuss all Draft Policies on PPML. The AC will >> evaluate the discussion 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/participate/policy/pdp/ >> >> >> >> Draft Policies and Proposals under discussion can be found at: >> https://www.arin.net/participate/policy/drafts/ >> >> >> >> Regards, >> >> >> >> Sean Hopkins >> >> Senior Policy Analyst >> >> American Registry for Internet Numbers (ARIN) >> >> >> >> >> >> >> >> Draft Policy ARIN-2022-12: Direct Assignment Language Update >> >> >> >> Problem Statement: >> >> >> >> As a result of ARIN's fee harmonization direct allocations are no longer >> being utilized within ARIN databases, therefore language around that has >> been deprecated and should be modernized. >> >> >> >> Policy Statement: >> >> >> >> Section 3.6.3: >> >> >> >> Remove “direct allocation” from “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.” >> >> >> >> Section 4.2.2, paragraph 1: change “direct assignments or allocations” to >> “ARIN-issued IPv4 addresses” >> >> >> >> Section 4.2.2, paragraph 2: change “direct allocations, direct >> assignments, re-allocations or reassignments” to “ARIN-issued IPv4 >> addresses, re-allocations or reassignments” >> >> >> >> Section 4.3.2: change “direct assignments or allocations” to “ARIN-issued >> IPv4 addresses” >> >> >> >> Section 6.5.8: change “Direct Assignments from ARIN to End-user >> Organizations” to “End-user Allocations” >> >> >> >> Section 8.5.4: change “direct assignments or allocations” to “ARIN-issued >> IPv4 addresses” >> >> >> >> Section 8.5.6: change “direct assignments or allocations” to “ARIN-issued >> IPv4 addresses” >> >> Comments: >> >> >> >> Timetable for implementation: Immediate >> ___ >> ARIN-PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). >> Unsubscribe or manage your mailing list subscription at: >> https://lists.arin.net/mailman/listinfo/arin-ppml >> Please contact i...@arin.net if you experience any issues. >> > ___ ARIN-PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-ppml Please contact i...@arin.net if you experience any issues.
Re: [arin-ppml] Draft Policy ARIN-2022-12: Direct Assignment Language Update
Even if the direct allocation tag within the database has been removed, there are still references outside of the NRPM that use this designation for "direct" assignment or allocation. If the NRPM is changed, https://www.arin.net/resources/registry/reassignments/ would need to be adjusted to reflect whatever the new process or terminology will be. Currently, if you have a direct allocation you can make both reassignments or reallocations. If you are an end user you can only update ARIN with a reassignment. So long as the process for this doesn't change, I would support this policy. However, I did want to remind the shepherds "direct allocation" is more than just a database tag to many orgs. Kat Hunter ARIN AC/Comcast On Tue, Aug 23, 2022 at 12:30 PM ARIN wrote: > On 18 August 2022, the ARIN Advisory Council (AC) accepted "ARIN-prop-317: > Direct Assignment Language Update" as a Draft Policy. > > > > Draft Policy ARIN-2022-12 is below and can be found at: > > > > https://www.arin.net/participate/policy/drafts/2022_12/ > > > > You are encouraged to discuss all Draft Policies on PPML. The AC will > evaluate the discussion 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/participate/policy/pdp/ > > > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/participate/policy/drafts/ > > > > Regards, > > > > Sean Hopkins > > Senior Policy Analyst > > American Registry for Internet Numbers (ARIN) > > > > > > > > Draft Policy ARIN-2022-12: Direct Assignment Language Update > > > > Problem Statement: > > > > As a result of ARIN's fee harmonization direct allocations are no longer > being utilized within ARIN databases, therefore language around that has > been deprecated and should be modernized. > > > > Policy Statement: > > > > Section 3.6.3: > > > > Remove “direct allocation” from “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.” > > > > Section 4.2.2, paragraph 1: change “direct assignments or allocations” to > “ARIN-issued IPv4 addresses” > > > > Section 4.2.2, paragraph 2: change “direct allocations, direct > assignments, re-allocations or reassignments” to “ARIN-issued IPv4 > addresses, re-allocations or reassignments” > > > > Section 4.3.2: change “direct assignments or allocations” to “ARIN-issued > IPv4 addresses” > > > > Section 6.5.8: change “Direct Assignments from ARIN to End-user > Organizations” to “End-user Allocations” > > > > Section 8.5.4: change “direct assignments or allocations” to “ARIN-issued > IPv4 addresses” > > > > Section 8.5.6: change “direct assignments or allocations” to “ARIN-issued > IPv4 addresses” > > Comments: > > > > Timetable for implementation: Immediate > ___ > ARIN-PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). > Unsubscribe or manage your mailing list subscription at: > https://lists.arin.net/mailman/listinfo/arin-ppml > Please contact i...@arin.net if you experience any issues. > ___ ARIN-PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-ppml Please contact i...@arin.net if you experience any issues.
Re: [arin-ppml] Draft Policy ARIN-2021-5: Update ISP and End User References For 2022 Fee Schedule
Agreed with the interpretation. The Advisory Council does not change/adjust fees. This policy is to line up the text in the NRPM with the new fee schedule. The changes, as stated, are to be put in place on Jan 2022. Even if this policy does not get approved, it would not impact the new fee schedule and the NRPM would still need to be updated to reflect the changes at some point in the future. Kat Hunter ARIN AC On Tue, Sep 21, 2021, 2:16 PM Owen DeLong via ARIN-PPML wrote: > > > > On Sep 21, 2021, at 10:58 , John Santos wrote: > > > > Opposed. > > > > If the Board wishes to impose identical fee structures on LIRs and > end-users. it can do so now. It just needs to adopt identical fee > schedules for each. (If they do so, then obviously, there will be > push-back about any perceived unfairness.) > > Perhaps you were not paying attention… The board has already inflicted > this upon us effective January, 2022. > > > This proposal would remove that power and responsibility from the Board, > given them unwarranted shelter. They would be able to say "We have no > choice, the Policy requires that the fees be the same." But if they aren't > responsible, who is? > > Not exactly. This proposal is aimed at having policy catch up to that > which the board has already inflicted upon us. It’s more a reflection of > the unfortunate actions of the board than an effort to push the board in a > particular direction. > > Cart, horse… > > Owen > > > > > > > > > On 9/21/2021 11:06 AM, ARIN wrote: > >> On 16 September 2021, the ARIN Advisory Council (AC) accepted > "ARIN-prop-300: Update ISP and End User References For 2022 Fee Schedule" > as a Draft Policy. > >> Draft Policy ARIN-2021-5 is below and can be found at: > >> https://www.arin.net/participate/policy/drafts/2021_5/ > >> 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/participate/policy/pdp/ > >> Draft Policies and Proposals under discussion can be found at: > >> https://www.arin.net/participate/policy/drafts/ > >> Regards, > >> Sean Hopkins > >> Senior Policy Analyst > >> American Registry for Internet Numbers (ARIN) > >> Draft Policy ARIN-2021-5: Update ISP and End User References For 2022 > Fee Schedule > >> Problem Statement: > >> Starting in Jan 1 2022, ISPs and end users will no longer have a > distinction in terms of fees and both will be under RSA membership terms. > There is existing policy language in the NRPM which references ISPs and end > users separately. > >> Policy statement: > >> This policy aims to synchronize the NRPM in regards to the new 2022 fee > schedule by consolidating instances where ISPs and End users have clear > distinctions. > >> Old text > >> 4.2.1.2. Annual Renewal > >> An annual fee for registered space is due by the anniversary date of > the ISP’s first allocation from ARIN. ISPs should take care to ensure that > their annual renewal payment is made by their anniversary due date in > accordance with the Registration Services Agreement… > >> 3rd paragraph down 4.4 > >> …ISPs and other organizations receiving these micro-allocations will be > charged under the ISP fee schedule, while end-users will be charged under > the fee schedule for end-users. …. > >> 6.10.1. Micro-allocations for Critical Infrastructure > >> ….ISPs and other organizations receiving these micro-allocations will > be charged under the ISP fee schedule, while end-users will be charged > under the fee schedule for end-users… > >> New policy text: > >> 4.2.1.2. Annual Renewal > >> An annual fee for registered space is due by the anniversary date of an > organization’s first allocation from ARIN. Organizations should take care > to ensure that their annual renewal payment is made by their anniversary > due date in accordance with the Registration Services Agreement… > >> 3rd paragraph down 4.4 > >> …Organizations receiving these micro-allocations will be charged under > the fee schedule. …. > >> 6.10.1. Micro-allocations for Critical Infrastructure > >> ….Organizations receivin
Re: [arin-ppml] Draft Policy 2020-10: Requirement to Demonstrate Utilization of Reassignments and Reallocations for ISPs Seeking Initial Allocation from ARIN
I have some major concerns with fraud. My day job sometimes involves/has involved reviews when business customers would like space. On occasion, ARIN has already denied them. After further review, our security teams find out these people aren't who they say they are, don't own the physical address they list, etc. Speaking for myself and not for my company, I am very concerned that we are opening a huge door to fraud if there are zero checks in place for requirements. I don't feel ARIN should be less stringent than orgs that get space from them. If the main concern is customers are claiming it's too difficult, I have a lot of questions there as well. It should be easy to prove you are who you say you are and have a valid reason to use the space. Kat Hunter Comcast ARIN AC VC On Fri, Jan 22, 2021, 2:33 PM Amy Potter wrote: > Happy friday to the ARIN community! > > I just wanted to poke the crowd to see if I can get some additional > feedback on ARIN-2020-10. Specifically I would love to hear from anyone > that feels it is a problem that ARIN reviews utilization of blocks > reasssigned and reallocated to ISPs when those ISPs apply for their first > direct allocation or direct assignment from ARIN (when an ISP lacking any > reassignments or reallocations that applies for their first direct > assignment or direct allocations would not need to establish efficient > utilization of prior blocks). > > Alternatively, if anyone feels that removing the current requirements > would lead to problems, please speak up! > > Thanks, > > Amy > > On Thu, Dec 17, 2020 at 11:30 AM Owen DeLong wrote: > >> Personally, I oppose the proposal. >> >> I do not believe this levels the playing field, but rather tilts it to >> the advantage of those holding space from their providers already. >> >> An organization holding no space has nothing to efficiently utilize and >> is starting from zero, same as those other organizations presumably did >> back when they were able to obtain space from their upstream. They could >> have chosen to gett that initial space from ARIN, but opted for provider >> assigned space instead for whatever reason. In any case, they have space >> already and are either looking to expand or are looking to replace that >> provider assigned space. In the former case, they are on the same playing >> field as anyone looking to expand today. In the latter case, they have the >> advantage of being able to continue using their provider assigned space >> while waiting, so any disadvantage they may face is rather limited and is >> the result of their own past decisions. >> >> Owen >> >> >> On Dec 16, 2020, at 2:17 PM, Amy Potter wrote: >> >> Hello ppml community! >> >> I just wanted to recirculate Draft Policy ARIN 2020-10 for feedback. This >> draft policy would remove the requirement that ISPs that already hold >> reallocations or reassignments from upstream providers satisfy ARIN's >> efficient utilization requirements for those reallocations/reassignments >> before they are able to qualify for their initial allocation of space >> directly from ARIN, and get on the waitlist to receive that space. >> >> Under current policy a new ISP that does not have any reallocations or >> reassignments qualifies for a /24 without having to establish efficient >> utilization of any previous space. This allows new ISPs to get on the >> waitlist sooner than ISPs holding reassignments/reallocations, despite the >> fact that neither type of organization holds space directly from ARIN yet. >> >> 1. Do you believe that NRPM's current distinction between ISPs holding >> reassignments/reallocations and new ISPs without any >> reallocations/reassignments still makes sense today? >> >> 2. Is leveling the playing field by allowing all ISPs that do not >> currently hold space directly from ARIN to qualify for a /24 without >> demonstrating prior use--regardless of whether or not they hold >> reallocations/reassignments--a fair solution that reflects the realities >> faced by these organizations today? >> >> Thanks! >> >> Amy >> >> On Tue, Nov 24, 2020 at 12:47 PM ARIN wrote: >> >>> On 19 November 2020, the ARIN Advisory Council (AC) accepted >>> "ARIN-prop-293: Requirement to Demonstrate Utilization of Reassignments and >>> Reallocations for ISPs Seeking Initial Allocation from ARIN" as a Draft >>> Policy. >>> >>> Draft Policy ARIN-2020-10 is below and can be found at: >>> >>> https://www.arin.net/participate/policy/drafts/2020_10/ >>> >>> You are encouraged to di
Re: [arin-ppml] Revised - Draft Policy ARIN-2020-5: Clarify and Update Requirements for Allocations to Downstream Customers
Staff and legal has been completed for 2020-5. If the community continues to support this, the shepherds would like to move this to recommended status during our next meeting. You can find the policy staff and legal review here: https://www.arin.net/participate/policy/drafts/2020_5/#slr Summary (Staff Understanding) ARIN-2020-5 replaces RFC2050 references in Sections 4.2.3.4.1. and 4.2.3.6. with references to the End user assignment utilization requirements in Section 4.3.3. Comments ARIN Staff Comments ARIN-2020-5 would align requirements for downstream customers with existing ARIN End user policy and remove outdated RFC2050 references, which have been a source of confusion in the past. This text is clear and understandable, and can be implemented as written. ARIN General Counsel – Legal Assessment No material legal issue. Resource Impact Implementation of this policy would have minimal resource impact. It is estimated that implementation would occur within three months after ratification by the ARIN Board of Trustees. The following would be needed in order to implement: Staff training Updated guidelines and internal procedures Standard documentation updates -Kat Hunter On Wed, Jul 22, 2020 at 11:28 AM ARIN wrote: > The following Draft Policy has been revised: > > * ARIN-2020-5: Clarify and Update Requirements for Allocations to > Downstream Customers > > Revised text is below and can be found at: > > https://www.arin.net/participate/policy/drafts/2020_5/ > > 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/participate/policy/pdp/ > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/participate/policy/drafts/ > > Regards, > > Sean Hopkins > Policy Analyst > American Registry for Internet Numbers (ARIN) > > > > > Draft Policy ARIN-2020-5: Clarify and Update Requirements for > Allocations to Downstream Customers > > Problem Statement: > > A recent Policy Experience Report demonstrated the fact that the > existing Section 4.2.3.6 references RFC2050, which is obsolete, and is > not synchronized with utilization requirements carried in Section 4.3.3, > specifically the utilization rate. > > Policy Statement: > > Given that RFC7020, which supercedes RFC2050, no longer carries specific > utilization requirements for downstream customers of ISPs, its reference > may be removed from Section 4.2.3.6, instead referencing 4.3.3 > (currently, 50% utilization within 24 months) to harmonize the > utilization requirements of both ISPs and their downstream customers. > > Removing these references from Section 4.2.3.6 will simplify the > language of that section. > > Replace sections 4.2.3.4.1 and sections 4.2.3.6 with the following text: > > 4.2.3.4.1. Utilization > > A downstream customer requesting address space from an upstream ISP must > document a plan to the allocating ISP for their utilization to conform > to Section 4.3.3. Reassignment and reallocation information for prior > allocations must show that each customer meets the 80% utilization > criteria and must be available via SWIP / a distributed service which > meets the standards set forth in section 3.2 prior to your issuing them > additional space. > > 4.2.3.6. Reassignments to Multihomed Downstream Customers > > If a downstream customer has a requirement to multihome, that > requirement alone will serve as justification for a /24 allocation. > Downstream customers must provide contact information for all of their > upstream providers to the ISP from whom they are requesting a /24, and > utilize a border routing protocol between the customer and the ISP. > Customers may receive a /24 from only one of their upstream providers > under this policy without providing additional justification. ISPs may > demonstrate they have made an assignment to a downstream customer under > this policy by supplying ARIN with the information they collected from > the customer, as described above, or by identifying the AS number of the > customer. > > Comments: none > > Timetable For Implementation: Immediate > > > > ___ > ARIN-PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). > Unsubscribe or manage your mailing li
Re: [arin-ppml] Draft Policy ARIN-2020-5: Clarify and Update Requirements for Allocations to Downstream Customers
I have updated the language changing it from BGP specifically to "a border routing protocol". -Kat On Fri, Jul 17, 2020 at 2:43 PM Owen DeLong wrote: > Speaking as one fo the proposal's authors, I appreciate and agree with > that bit of feedback. The intent was to express the requirement that the > customer route the prefix over multiple upstream ISPs; while in practical > terms, BGP is the only reasonable way to do this, the policy text should > not preclude other approaches. > > > I suspect a revision will be forthcoming. I provided a language suggestion > to the AC yesterday which I believe addresses this concern, though the > language proposed would still require a routing protocol. > > In this context (IPv4 policy for justifying a /24), approaches which do > not involve a routing protocol do not come with the inherent need to use > the same prefix among multiple providers and therefore do not require a /24. > > Owen > > > ___ > ARIN-PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). > Unsubscribe or manage your mailing list subscription at: > https://lists.arin.net/mailman/listinfo/arin-ppml > Please contact i...@arin.net if you experience any issues. > ___ ARIN-PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-ppml Please contact i...@arin.net if you experience any issues.
Re: [arin-ppml] Draft Policy ARIN-2020-5: Clarify and Update Requirements for Allocations to Downstream Customers
Good morning all- We are looking to see if the following changes will impact ISPs or any impacted parties. This is intended to correct a reference to a deprecated RFC, however, sometimes business operations do not update their policies/procedures and we would not want to see businesses impacted in a detrimental manner due to the new proposed language. We would like to hear both positive and negative feedback for this policy. Thanks in advance. 4.2.3.4.1 Existing text: Reassignment and reallocation information for prior allocations must show that each customer meets the 80% utilization criteria and must be available via SWIP / a distributed service which meets the standards set forth in section 3.2 prior to your issuing them additional space. 4.2.3.4.1 New text (added new first sentence in paragraph): A downstream customer requesting address space from an upstream ISP must document a plan to the allocating ISP for their utilization to conform to Section 4.3.3. Reassignment and reallocation information for prior allocations must show that each customer meets the 80% utilization criteria and must be available via SWIP / a distributed service which meets the standards set forth in section 3.2 prior to your issuing them additional space. 4.2.3.6 Original Text: Under normal circumstances an ISP is required to determine the prefix size of their reassignment to a downstream customer according to the guidelines set forth in RFC 2050. Specifically, a downstream customer justifies their reassignment by demonstrating they have an immediate requirement for 25% of the IP addresses being assigned, and that they have a plan to utilize 50% of their assignment within one year of its receipt. This policy allows a downstream customer’s multihoming requirement to serve as justification for a /24 reassignment from their upstream ISP, regardless of host requirements. Downstream customers must provide contact information for all of their upstream providers to the ISP from whom they are requesting a /24. The ISP will then verify the customer’s multihoming requirement and may assign the customer a /24, based on this policy. Customers may receive a /24 from only one of their upstream providers under this policy without providing additional justification. ISPs may demonstrate they have made an assignment to a downstream customer under this policy by supplying ARIN with the information they collected from the customer, as described above, or by identifying the AS number of the customer. This information may be requested by ARIN staff when reviewing an ISP’s utilization during their request for additional IP addresses space. 4.3.2.6 New Text, replacing old: If a downstream customer has a requirement to multihome, that requirement alone will serve as justification for a /24 allocation. Downstream customers must provide contact information for all of their upstream providers to the ISP from whom they are requesting a /24, and utilize BGP as the routing protocol between the customer and the ISP. Customers may receive a /24 from only one of their upstream providers under this policy without providing additional justification. ISPs may demonstrate they have made an assignment to a downstream customer under this policy by supplying ARIN with the information they collected from the customer, as described above, or by identifying the AS number of the customer. -Kat Hunter On Tue, Jun 23, 2020 at 1:42 PM ARIN wrote: > On 18 June 2020, the ARIN Advisory Council (AC) accepted "ARIN-prop-288: > Clarify and Update Requirements for Allocations to Downstream Customers" > as a Draft Policy. > > Draft Policy ARIN-2020-5 is below and can be found at: > > https://www.arin.net/participate/policy/drafts/2020_5/ > > 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/participate/policy/pdp/ > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/participate/policy/drafts/ > > Regards, > > Sean Hopkins > Policy Analyst > American Registry for Internet Numbers (ARIN) > > > > Draft Policy ARIN-2020-5: Clarify and Update Requirements for > Allocations to Downstream Customers > > Problem Statement: > > A recent Policy Experience Report demonstrated the fact that the > existing Section 4.2.3.6 references RFC2050, which is obsolete, and is > not synchronized with utilization requirements carried in Section 4.3.3, > specifically the utilization rate. > > Policy Statemen
[arin-ppml] Staff and legal 2019-1: Clarify Section 4 IPv4 Request
Staff and legal has been posted for 2019-1. You can review it here: https://www.arin.net/participate/policy/drafts/2019_1/#staff-and-legal-review-5-june-2020 This is in recommended status. The newest language seems to have corrected any problematic language pointed out in the last staff and legal review. If we continue to have support, the shepherds will be looking to move this to last call after the ARIN policy meeting/discussion. Thank you all for your continued input. -Kat Hunter ___ ARIN-PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-ppml Please contact i...@arin.net if you experience any issues.
Re: [arin-ppml] Revised and Reverted to Draft Policy - Draft Policy ARIN-2019-1: Clarify Section 4 IPv4 Request Requirements
This is great feedback. Thank you everyone. I agree with removing "summarily" is an easy correction and is probably an unnecessary word. Thanks all. Kat On Thu, May 14, 2020 at 3:59 PM Martin Hannigan wrote: > > Makes sense to me. +1 > > On Thu, May 14, 2020 at 1:50 PM Mike Burns wrote: > >> I would support it with the removal of the pompous and meaningless word >> “summarily”. >> >> I like a clean NRPM. >> >> >> >> Regards, >> Mike >> >> >> >> >> >> *From:* ARIN-PPML *On Behalf Of *Chris >> Woodfield >> *Sent:* Thursday, May 14, 2020 1:40 PM >> *To:* Owen DeLong ; ARIN-PPML List >> *Subject:* Re: [arin-ppml] Revised and Reverted to Draft Policy - Draft >> Policy ARIN-2019-1: Clarify Section 4 IPv4 Request Requirements >> >> >> >> I support as written, but agree that the word can be removed from the >> proposal without changing its intent, so happy to see it removed. >> >> >> >> -Chris >> >> >> >> On May 14, 2020, at 9:49 AM, Owen DeLong wrote: >> >> >> >> I don’t construe it that way, but I have no objection to either of >> Scott’s suggestions, either. >> >> >> >> My concern is for the end effect of the proposed policy which is the same >> with any of the proposed wordings. >> >> >> >> Owen >> >> >> >> >> >> On May 14, 2020, at 09:10 , Scott Leibrand >> wrote: >> >> >> >> "Summarily" seems punitive, and doesn't seem necessary in this context. >> Perhaps just remove it and just leave "will be removed from the waitlist"? >> Or replace it with something like "immediately". >> >> >> >> -Scott >> >> >> >> On Thu, May 14, 2020 at 8:50 AM Owen DeLong wrote: >> >> I support this addition and support the policy with the addition. >> >> >> >> Owen >> >> >> >> >> >> On May 14, 2020, at 08:37, Fernando Frediani >> wrote: >> >> >> >> I support this proposal. >> It's fair to everybody and helps avoid fraud. >> >> Regards >> Fernando >> >> On 14/05/2020 11:56, Kat Hunter wrote: >> >> After making adjustments to the text, ARIN staff and legal conducted a >> new staff and legal review on 2019-1. You can view the updated review here: >> https://www.arin.net/participate/policy/drafts/2019_1/#staff-and-legal-review-30-april-2020 >> . >> It has been suggested that >> >> "It is worth noting that this Draft Policy does not include the removal >> of pending ARIN Waitlist requests for organizations that act as source >> organizations for 8.2, 8.3, or 8.4 transfers, which would allow them to >> conduct such transfers while waitlisted, and receive resources from the >> ARIN Waitlist immediately thereafter, as all organizations on the ARIN >> Waitlist have already applied, and are pending fulfillment. >> >> The text is clear and understandable, and can be implemented as written." >> >> After some discussion with some members of the AC, it was suggested that >> a new subsection is added to section 8 which would allow for additional >> clarity from this policy and some future cleanup via other future policy. >> >> "8.6 Waitlist Restrictions >> >> Any organization which is on the wait list and submits a request to be >> the source of a transfer under any provision in section 8 will be summarily >> removed from the wait list." >> >> I'd like to get the community's thoughts on the addition. With this >> addition, would you support the policy as written? >> >> -Kat Hunter >> >> >> >> On Tue, Mar 24, 2020 at 1:24 PM Kat Hunter wrote: >> >> Owen, I think this is a good suggestion. I've updated the month >> designations in the other section to 90 days as, I agree, it is more >> precise when we are discussing shorter amounts of time. Additionally, I've >> taken your suggestion on wordsmithing that section and adjusted it just a >> little. >> >> >> >> " An organization which serves as the source of an 8.2 IPv4 transfer will >> not be allowed to apply for IPv4 address space under section 4.1.8 ARIN >> Waitlist for a period of 36 months following said transfer unless the >> recipient organization remains a subsidiary, parent company, or under >> common ownership with the source organization.". >> >> >> >
Re: [arin-ppml] Revised and Reverted to Draft Policy - Draft Policy ARIN-2019-1: Clarify Section 4 IPv4 Request Requirements
After making adjustments to the text, ARIN staff and legal conducted a new staff and legal review on 2019-1. You can view the updated review here: https://www.arin.net/participate/policy/drafts/2019_1/#staff-and-legal-review-30-april-2020 . It has been suggested that "It is worth noting that this Draft Policy does not include the removal of pending ARIN Waitlist requests for organizations that act as source organizations for 8.2, 8.3, or 8.4 transfers, which would allow them to conduct such transfers while waitlisted, and receive resources from the ARIN Waitlist immediately thereafter, as all organizations on the ARIN Waitlist have already applied, and are pending fulfillment. The text is clear and understandable, and can be implemented as written." After some discussion with some members of the AC, it was suggested that a new subsection is added to section 8 which would allow for additional clarity from this policy and some future cleanup via other future policy. "8.6 Waitlist Restrictions Any organization which is on the wait list and submits a request to be the source of a transfer under any provision in section 8 will be summarily removed from the wait list." I'd like to get the community's thoughts on the addition. With this addition, would you support the policy as written? -Kat Hunter On Tue, Mar 24, 2020 at 1:24 PM Kat Hunter wrote: > Owen, I think this is a good suggestion. I've updated the month > designations in the other section to 90 days as, I agree, it is more > precise when we are discussing shorter amounts of time. Additionally, I've > taken your suggestion on wordsmithing that section and adjusted it just a > little. > > " An organization which serves as the source of an 8.2 IPv4 transfer will > not be allowed to apply for IPv4 address space under section 4.1.8 ARIN > Waitlist for a period of 36 months following said transfer unless the > recipient organization remains a subsidiary, parent company, or under > common ownership with the source organization.". > > I wanted to make sure I specified that this was in reference to IPv4 and > that the organization also remains a subsidiary, parent company, or under > common ownership. Thank you for the input. Additionally I'd like to see if > there is anyone else that still supports or no longer longer supports this > policy as written. > > Kat Hunter > > On Wed, Mar 11, 2020 at 4:42 AM Owen DeLong wrote: > >> >> >> > On Mar 9, 2020, at 06:26 , ARIN wrote: >> > >> > On 20 February 2020, the ARIN Advisory Council (AC) reverted the >> following Recommended Draft Policy to Draft Policy Status due to community >> feedback recommending significant substantive changes.: >> > >> > * Draft Policy ARIN-2019-1: Clarify Section 4 IPv4 Request Requirements >> > >> > The text has since been revised in response to that feedback. >> > >> > Revised text is below and can be found at: >> > >> > https://www.arin.net/participate/policy/drafts/2019_1/ >> > >> > 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/participate/policy/pdp/ >> > >> > Draft Policies and Proposals under discussion can be found at: >> > https://www.arin.net/participate/policy/drafts/ >> > >> > Regards, >> > >> > Sean Hopkins >> > Policy Analyst >> > American Registry for Internet Numbers (ARIN) >> > >> > >> > >> > >> > Draft Policy ARIN-2019-1: Clarify Section 4 IPv4 Request Requirements >> > >> > Problem Statement: >> > >> > Per a recent ARIN Policy Experience Report and resulting AC discussion, >> it was noted that the language of Section 4.1.8 is imprecise in that it can >> be interpreted as specifying a waiting period for any allocation activity, >> as opposed to being intended to limit only the frequency of IPv4 >> allocations under Section 4. >> > >> > The same Policy Experience Report also noted that ARIN staff has >> observed a pattern where an organization transfers space under NRPM Section >> 8.2 to a specified recipient, and then immediately applies for space under >> Section 4. This activity appears
Re: [arin-ppml] Revised and Reverted to Draft Policy - Draft Policy ARIN-2019-1: Clarify Section 4 IPv4 Request Requirements
Owen, I think this is a good suggestion. I've updated the month designations in the other section to 90 days as, I agree, it is more precise when we are discussing shorter amounts of time. Additionally, I've taken your suggestion on wordsmithing that section and adjusted it just a little. " An organization which serves as the source of an 8.2 IPv4 transfer will not be allowed to apply for IPv4 address space under section 4.1.8 ARIN Waitlist for a period of 36 months following said transfer unless the recipient organization remains a subsidiary, parent company, or under common ownership with the source organization.". I wanted to make sure I specified that this was in reference to IPv4 and that the organization also remains a subsidiary, parent company, or under common ownership. Thank you for the input. Additionally I'd like to see if there is anyone else that still supports or no longer longer supports this policy as written. Kat Hunter On Wed, Mar 11, 2020 at 4:42 AM Owen DeLong wrote: > > > > On Mar 9, 2020, at 06:26 , ARIN wrote: > > > > On 20 February 2020, the ARIN Advisory Council (AC) reverted the > following Recommended Draft Policy to Draft Policy Status due to community > feedback recommending significant substantive changes.: > > > > * Draft Policy ARIN-2019-1: Clarify Section 4 IPv4 Request Requirements > > > > The text has since been revised in response to that feedback. > > > > Revised text is below and can be found at: > > > > https://www.arin.net/participate/policy/drafts/2019_1/ > > > > 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/participate/policy/pdp/ > > > > Draft Policies and Proposals under discussion can be found at: > > https://www.arin.net/participate/policy/drafts/ > > > > Regards, > > > > Sean Hopkins > > Policy Analyst > > American Registry for Internet Numbers (ARIN) > > > > > > > > > > Draft Policy ARIN-2019-1: Clarify Section 4 IPv4 Request Requirements > > > > Problem Statement: > > > > Per a recent ARIN Policy Experience Report and resulting AC discussion, > it was noted that the language of Section 4.1.8 is imprecise in that it can > be interpreted as specifying a waiting period for any allocation activity, > as opposed to being intended to limit only the frequency of IPv4 > allocations under Section 4. > > > > The same Policy Experience Report also noted that ARIN staff has > observed a pattern where an organization transfers space under NRPM Section > 8.2 to a specified recipient, and then immediately applies for space under > Section 4. This activity appears to be speculative in nature and not > consistent with sound address management policy. > > > > The updated language in this proposal addresses the two issues above, as > both concerns can be addressed via modifications to the same section and > sentence thereof of the NRPM: > > > > Clarifies the waiting period to only prohibit requests for IPv4 > allocations under Section 4 of the NRPM > > Disallows organizations that have transferred space to other parties > within the past 36 months from applying for additional IPv4 space under > NRPM Section 4. > > > > Policy Statement: > > > > Current language found in NRPM Section 4.1.8 - Unmet Requests: > > > > Repeated requests, in a manner that would circumvent 4.1.6, are not > allowed: an organization currently on the waitlist must wait 90 days after > receiving a distribution from the waitlist before applying for additional > space. ARIN, at its sole discretion, may waive this requirement if the > requester can document a change in circumstances since their last request > that could not have been reasonably foreseen at the time of the original > request, and which now justifies additional space. Qualified requesters > will also be advised of the availability of the transfer mechanism in > section 8.3 as an alternative mechanism to obtain IPv4 addresses. > > > > Proposed new language 4.1.8: > > > > Multiple requests are not allowed: an organization currently on the > waitlist must wait 90 days after receiving a distribution from the waitlist > or IPv4 number resources as a recipient of any transfer be
Re: [arin-ppml] ARIN Draft policy 2019-1 Clarify Section 4 IPv4 Request Requirements - Update Dec 2019
I've updated the language for 2019-1 to reflect this suggestion. Please see the updated language here: https://www.arin.net/participate/policy/drafts/2019_1/ Updated text: Multiple requests are not allowed: an organization may not apply for IPv4 address resources under this section if they have received an allocation, assignment, or transfer of IPv4 resources through a specified transfer under sections 8.3 or 8.4 or waitlist allocation less than three months prior, or if the organization has transferred IPv4 address resources to another party under Section 8 less than 36 months prior to its application under this section. However, an organization may apply for IPv4 address resources under this section if they have transferred IPv4 address resources under section 8.2 during the previous 36 months if the recipient organization was and remains a subsidiary, parent company, or an organization under common ownership of the same parent company as the applicant organization. ARIN may at its sole discretion, waive this restriction if the requester can document a change in circumstances since their last request that could not have been reasonably foreseen at the time of the original request, and which now justifies additional space. Qualified requesters will also be advised of the availability of the transfer mechanism in section 8.3 as an alternative mechanism to obtain IPv4 addresses. -Kat Hunter On Fri, Dec 13, 2019 at 1:30 PM Kat Hunter wrote: > That's a great suggestion. Does anyone else have a similar > opinion/suggestion on the same? > > Kat > > On Fri, Dec 13, 2019 at 12:20 PM Scott Leibrand > wrote: > >> Does this open up the possibility that an organization performs its 8.2 >> transfer to a wholly-owned subsidiary, and then sells that subsidiary to a >> third party, to bypass the limitation on applying for more IPv4 space? Do >> we need to change "was a subsidiary" to "was, and remains, a subsidiary" or >> similar? >> >> -Scott >> >> On Fri, Dec 13, 2019 at 8:34 AM Kat Hunter wrote: >> >>> Happy Friday Everyone; >>> Draft Policy ARIN-2019-1 is below and can be found at: >>> https://www.arin.net/participate/policy/drafts/2019_1/ >>> >>> During the Austin meeting there was concern for some of the wording of >>> 2019-1. It was suggested that the word "Repeated" was too vague and that >>> companies that performed M transfer that was a subsidiary, parent >>> company, or an organization under common ownership of the same parent >>> company as the applicant organization should not be removed or kept from >>> the waitlist because of a consolidation of resources. We've updated the >>> wording on 2019-1 and would appreciate discussion on the updates. Thanks so >>> much in advance. >>> --- >>> Problem Statement: >>> >>> Per a recent ARIN Policy Experience Report and resulting AC discussion, >>> it was noted that the language of Section 4.1.8 is imprecise in that it can >>> be interpreted as specifying a waiting period for any allocation activity, >>> as opposed to being intended to limit only the frequency of IPv4 >>> allocations under Section 4. >>> >>> The same Policy Experience Report also noted that ARIN staff has >>> observed a pattern where an organization transfers space under NRPM Section >>> 8.2 to a specified recipient, and then immediately applies for space under >>> Section 4. This activity appears to be speculative in nature and not >>> consistent with sound address management policy. >>> >>> The updated language in this proposal addresses the two issues above, as >>> both concerns can be addressed via modifications to the same section and >>> sentence thereof of the NRPM: >>> >>> Clarifies the waiting period to only prohibit requests for IPv4 >>> allocations under Section 4 of the NRPM >>> Disallows organizations that have transferred space to other parties >>> within the past 36 months from applying for additional IPv4 space under >>> NRPM Section 4. >>> Policy Statement: >>> >>> Current language found in NRPM Section 4.1.8 - Unmet Requests: >>> >>> Repeated requests, in a manner that would circumvent 4.1.6, are not >>> allowed: an organization currently on the waitlist must wait 90 days after >>> receiving a distribution from the waitlist before applying for additional >>> space. ARIN, at its sole discretion, may waive this requirement if the >>> requester can document a change in circumstances since their last request >>> that could not have been reasonably fore
Re: [arin-ppml] ARIN Draft policy 2019-1 Clarify Section 4 IPv4 Request Requirements - Update Dec 2019
That's a great suggestion. Does anyone else have a similar opinion/suggestion on the same? Kat On Fri, Dec 13, 2019 at 12:20 PM Scott Leibrand wrote: > Does this open up the possibility that an organization performs its 8.2 > transfer to a wholly-owned subsidiary, and then sells that subsidiary to a > third party, to bypass the limitation on applying for more IPv4 space? Do > we need to change "was a subsidiary" to "was, and remains, a subsidiary" or > similar? > > -Scott > > On Fri, Dec 13, 2019 at 8:34 AM Kat Hunter wrote: > >> Happy Friday Everyone; >> Draft Policy ARIN-2019-1 is below and can be found at: >> https://www.arin.net/participate/policy/drafts/2019_1/ >> >> During the Austin meeting there was concern for some of the wording of >> 2019-1. It was suggested that the word "Repeated" was too vague and that >> companies that performed M transfer that was a subsidiary, parent >> company, or an organization under common ownership of the same parent >> company as the applicant organization should not be removed or kept from >> the waitlist because of a consolidation of resources. We've updated the >> wording on 2019-1 and would appreciate discussion on the updates. Thanks so >> much in advance. >> --- >> Problem Statement: >> >> Per a recent ARIN Policy Experience Report and resulting AC discussion, >> it was noted that the language of Section 4.1.8 is imprecise in that it can >> be interpreted as specifying a waiting period for any allocation activity, >> as opposed to being intended to limit only the frequency of IPv4 >> allocations under Section 4. >> >> The same Policy Experience Report also noted that ARIN staff has observed >> a pattern where an organization transfers space under NRPM Section 8.2 to a >> specified recipient, and then immediately applies for space under Section >> 4. This activity appears to be speculative in nature and not consistent >> with sound address management policy. >> >> The updated language in this proposal addresses the two issues above, as >> both concerns can be addressed via modifications to the same section and >> sentence thereof of the NRPM: >> >> Clarifies the waiting period to only prohibit requests for IPv4 >> allocations under Section 4 of the NRPM >> Disallows organizations that have transferred space to other parties >> within the past 36 months from applying for additional IPv4 space under >> NRPM Section 4. >> Policy Statement: >> >> Current language found in NRPM Section 4.1.8 - Unmet Requests: >> >> Repeated requests, in a manner that would circumvent 4.1.6, are not >> allowed: an organization currently on the waitlist must wait 90 days after >> receiving a distribution from the waitlist before applying for additional >> space. ARIN, at its sole discretion, may waive this requirement if the >> requester can document a change in circumstances since their last request >> that could not have been reasonably foreseen at the time of the original >> request, and which now justifies additional space. Qualified requesters >> will also be advised of the availability of the transfer mechanism in >> section 8.3 as an alternative mechanism to obtain IPv4 addresses. >> >> Proposed new language: >> >> Multiple requests are not allowed: an organization may not apply for IPv4 >> address resources under this section if they have received an allocation, >> assignment, or transfer of IPv4 resources through a specified transfer >> under sections 8.3 or 8.4 or waitlist allocation less than three months >> prior, or if the organization has transferred IPv4 address resources to >> another party under Section 8 less than 36 months prior to its application >> under this section. However, an organization may apply for IPv4 address >> resources under this section if they have transferred IPv4 address >> resources under section 8.2 during the previous 36 months if the recipient >> organization was a subsidiary, parent company, or an organization under >> common ownership of the same parent company as the applicant organization. >> ARIN may at its sole discretion, waive this restriction if the requester >> can document a change in circumstances since their last request that could >> not have been reasonably foreseen at the time of the original request, and >> which now justifies additional space. Qualified requesters will also be >> advised of the availability of the transfer mechanism in section 8.3 as an >> alternative mechanism to obtain IPv4 addresses. >> >> -Kat Hunter >> >
[arin-ppml] ARIN Draft policy 2019-1 Clarify Section 4 IPv4 Request Requirements - Update Dec 2019
Happy Friday Everyone; Draft Policy ARIN-2019-1 is below and can be found at: https://www.arin.net/participate/policy/drafts/2019_1/ During the Austin meeting there was concern for some of the wording of 2019-1. It was suggested that the word "Repeated" was too vague and that companies that performed M transfer that was a subsidiary, parent company, or an organization under common ownership of the same parent company as the applicant organization should not be removed or kept from the waitlist because of a consolidation of resources. We've updated the wording on 2019-1 and would appreciate discussion on the updates. Thanks so much in advance. --- Problem Statement: Per a recent ARIN Policy Experience Report and resulting AC discussion, it was noted that the language of Section 4.1.8 is imprecise in that it can be interpreted as specifying a waiting period for any allocation activity, as opposed to being intended to limit only the frequency of IPv4 allocations under Section 4. The same Policy Experience Report also noted that ARIN staff has observed a pattern where an organization transfers space under NRPM Section 8.2 to a specified recipient, and then immediately applies for space under Section 4. This activity appears to be speculative in nature and not consistent with sound address management policy. The updated language in this proposal addresses the two issues above, as both concerns can be addressed via modifications to the same section and sentence thereof of the NRPM: Clarifies the waiting period to only prohibit requests for IPv4 allocations under Section 4 of the NRPM Disallows organizations that have transferred space to other parties within the past 36 months from applying for additional IPv4 space under NRPM Section 4. Policy Statement: Current language found in NRPM Section 4.1.8 - Unmet Requests: Repeated requests, in a manner that would circumvent 4.1.6, are not allowed: an organization currently on the waitlist must wait 90 days after receiving a distribution from the waitlist before applying for additional space. ARIN, at its sole discretion, may waive this requirement if the requester can document a change in circumstances since their last request that could not have been reasonably foreseen at the time of the original request, and which now justifies additional space. Qualified requesters will also be advised of the availability of the transfer mechanism in section 8.3 as an alternative mechanism to obtain IPv4 addresses. Proposed new language: Multiple requests are not allowed: an organization may not apply for IPv4 address resources under this section if they have received an allocation, assignment, or transfer of IPv4 resources through a specified transfer under sections 8.3 or 8.4 or waitlist allocation less than three months prior, or if the organization has transferred IPv4 address resources to another party under Section 8 less than 36 months prior to its application under this section. However, an organization may apply for IPv4 address resources under this section if they have transferred IPv4 address resources under section 8.2 during the previous 36 months if the recipient organization was a subsidiary, parent company, or an organization under common ownership of the same parent company as the applicant organization. ARIN may at its sole discretion, waive this restriction if the requester can document a change in circumstances since their last request that could not have been reasonably foreseen at the time of the original request, and which now justifies additional space. Qualified requesters will also be advised of the availability of the transfer mechanism in section 8.3 as an alternative mechanism to obtain IPv4 addresses. -Kat Hunter ___ ARIN-PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-ppml Please contact i...@arin.net if you experience any issues.
Re: [arin-ppml] Revised - Draft Policy ARIN-2019-9: Clarify Interactions Between NRPM 4.10 IPv6 Transition Space Requests and NRPM 4.1.8.2 Unmet Needs Requests
Feedback from the community after the staff and legal review has been all negative for 2019-9. We will be looking to abandon this policy at the next advisory council meeting in September if there is no one else in the community that feels this would be beneficial. We welcome any discussion on the topic. Thank you for all of your input thus far. Kat Hunter ARIN AC On Tue, Jul 30, 2019 at 9:25 PM Michael B. Williams < michael.willi...@glexia.com> wrote: > Agreed, Brian. > > -- > > *Michael B. Williams* > Glexia, Inc. - An IT Company > USA Direct: +1 978 477 6797 > USA Toll Free: +1 800 675 0297 x101 > AUS Direct: +61 3 8594 2265 > AUS Toll Free: +61 1800 931 724 x101 > Fax: +1.815-301-5570 > michael.willi...@glexia.com > https://www.glexia.com/ > https://www.glexia.com.au/ > > *Legal Notice:* > The information in this electronic mail message is the sender's > confidential business and may be legally privileged. It is intended solely > for the addressee(s). Access to this internet electronic mail message by > anyone else is unauthorized. If you are not the intended recipient, any > disclosure, copying, distribution or any action taken or omitted to be > taken in reliance on it is prohibited and may be unlawful. > > > > On Tue, Jul 30, 2019 at 3:50 PM Brian Jones wrote: > >> With the clarification that organizations will be removed from the >> waiting list if they receive an allocation for facilitating their IPv6 >> deployment, I no longer support this proposal for the reasons outlined by >> the ARIN staff below. My organization will not be impacted by this but I >> can understand where some could be detrimentally effected by this change. >> Receiving an allocation for deploying IPv6 should not be tied to the >> waiting list for a regular IPv4 assignment IMO. >> >> -- >> Brian E Jones, CSP-SM, CSP-PO >> NI Virginia Tech >> bjo...@vt.edu >> >> On Jul 30, 2019, at 1:33 PM, Kat Hunter wrote: >> >> All- Staff and legal review has been completed for 2019-9. Please take a >> moment to review the comments. For those that supported this, do you still >> support the policy given the staff notes. Additionally, we'd like to hear >> from anyone that this may impact in a negative way. >> >> Policy: https://www.arin.net/participate/policy/drafts/2019_9/ >> Staff and Legal Review >> https://www.arin.net/participate/policy/drafts/2019_9/#slr >> >> "ARIN Staff Comments >> >> This policy could be implemented as written. Current policy is that any >> organization on the waiting list that receives IPv4 addresses through a >> transfer are removed from the waiting list, but those receiving an NRPM >> 4.10 (Dedicated IPv4 Block to Facilitate IPv6 Deployment) assignment are >> not removed from the waiting list. The proposed change would result those >> organizations receiving an NRPM 4.10 assignment also being removed from the >> waiting list. >> >> Staff notes that adding the “…or an allocation request fulfilled under >> Section 4.10…” may be detrimental to some organizations, as address space >> received per NRPM 4.10 must be used in a manner consistent with IPv6 >> translation services and cannot be used for other purposes such as customer >> assignments, shared hosting services, etc. >> >> Organizations need IPv4 address space to assign to their customers, and >> many organizations will request a block from the Waiting List to be used >> for their customer assignments but still need some IPv4 space for >> deployment of IPv6 translation services as outlined in section NRPM 4.10. >> Removing organizations from the Waiting List when they receive a NRPM 4.10 >> assignment would hinder the existing IPv4 operations & growth of >> organizations, and may provide a disincentive to IPv6 deployment." >> >> >> >> -Kat Hunter >> >> >> On Mon, Jul 15, 2019 at 1:42 PM Brian Jones wrote: >> >>> I support this revised version of draft policy ARIN-2019-9 as written. >>> >>> Brian >>> >>> >>> On Thu, May 23, 2019, 12:44 PM ARIN wrote: >>> >>>> The following has been revised: >>>> >>>> * Draft Policy ARIN-2019-9: Clarify Interactions Between NRPM 4.10 IPv6 >>>> Transition Space Requests and NRPM 4.1.8.2 Unmet Needs Requests >>>> >>>> Revised text is below and can be found at: >>>> https://www.arin.net/participate/policy/drafts/2019_9/ >>>> >>>> You are encouraged to discuss all Draft Policies on PPML. The AC will >&g
Re: [arin-ppml] Revised - Draft Policy ARIN-2019-9: Clarify Interactions Between NRPM 4.10 IPv6 Transition Space Requests and NRPM 4.1.8.2 Unmet Needs Requests
All- Staff and legal review has been completed for 2019-9. Please take a moment to review the comments. For those that supported this, do you still support the policy given the staff notes. Additionally, we'd like to hear from anyone that this may impact in a negative way. Policy: https://www.arin.net/participate/policy/drafts/2019_9/ Staff and Legal Review https://www.arin.net/participate/policy/drafts/2019_9/#slr "ARIN Staff Comments This policy could be implemented as written. Current policy is that any organization on the waiting list that receives IPv4 addresses through a transfer are removed from the waiting list, but those receiving an NRPM 4.10 (Dedicated IPv4 Block to Facilitate IPv6 Deployment) assignment are not removed from the waiting list. The proposed change would result those organizations receiving an NRPM 4.10 assignment also being removed from the waiting list. Staff notes that adding the “…or an allocation request fulfilled under Section 4.10…” may be detrimental to some organizations, as address space received per NRPM 4.10 must be used in a manner consistent with IPv6 translation services and cannot be used for other purposes such as customer assignments, shared hosting services, etc. Organizations need IPv4 address space to assign to their customers, and many organizations will request a block from the Waiting List to be used for their customer assignments but still need some IPv4 space for deployment of IPv6 translation services as outlined in section NRPM 4.10. Removing organizations from the Waiting List when they receive a NRPM 4.10 assignment would hinder the existing IPv4 operations & growth of organizations, and may provide a disincentive to IPv6 deployment." -Kat Hunter On Mon, Jul 15, 2019 at 1:42 PM Brian Jones wrote: > I support this revised version of draft policy ARIN-2019-9 as written. > > Brian > > > On Thu, May 23, 2019, 12:44 PM ARIN wrote: > >> The following has been revised: >> >> * Draft Policy ARIN-2019-9: Clarify Interactions Between NRPM 4.10 IPv6 >> Transition Space Requests and NRPM 4.1.8.2 Unmet Needs Requests >> >> Revised text is below and can be found at: >> https://www.arin.net/participate/policy/drafts/2019_9/ >> >> 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/participate/policy/pdp/ >> >> Draft Policies and Proposals under discussion can be found at: >> https://www.arin.net/participate/policy/drafts/ >> >> Regards, >> >> Sean Hopkins >> Policy Analyst >> American Registry for Internet Numbers (ARIN) >> >> >> >> Draft Policy ARIN-2019-9: Clarify Interactions Between NRPM 4.10 IPv6 >> Transition Space Requests and NRPM 4.1.8.2 Unmet Needs Requests >> >> Problem Statement: >> >> It has been observed that an organization requesting IPv4 resources >> under NRPM Section 4.10, Dedicated IPv4 Block To Facilitate IPv6 >> Deployment, can also request similar or the same resources under Section >> 4.2.1.8, Unmet Needs. This proposal aims to remove this potential for >> duplicate requests under these sections. >> >> Policy Statement: >> >> Section 4.1.8.2, Unmet Needs: >> >> Current language: Any requests met through a transfer will be considered >> fulfilled and removed from the waiting list. >> >> Proposed language: >> >> Any requests met through a transfer or an allocation request fulfilled >> under Section 4.10 will be considered fulfilled and removed from the >> waiting list. >> >> Timetable for Implementation: Immediate >> >> Anything Else: >> >> Currently, organizations can receive no more than a /24 at a time under >> Section 4.10. However, Proposal ARIN-PROP-266, submitted by Chris Tacit >> and myself, could potentially allow an org to receive up to a /21 under >> that section, widening the potential for abuse by “double-dipping” >> waiting list and transition space requests. As such, this proposal >> should be considered in that context. >> ___ >> ARIN-PPML >> You are receiving this message because you are subscribed to >> the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). >> Unsubscribe or manage your m
Re: [arin-ppml] Revised - Draft Policy ARIN-2019-9: Clarify Interactions Between NRPM 4.10 IPv6 Transition Space Requests and NRPM 4.1.8.2 Unmet Needs Requests
All - We haven't received a lot of comments on 2019-9. If you have time today, could you please comment for or against moving forward with this policy? Do you feel this proposal would remove the potential for duplicate requests under these sections? Thank you in advance for any comments Kat Hunter On Thu, May 23, 2019 at 12:44 PM ARIN wrote: > The following has been revised: > > * Draft Policy ARIN-2019-9: Clarify Interactions Between NRPM 4.10 IPv6 > Transition Space Requests and NRPM 4.1.8.2 Unmet Needs Requests > > Revised text is below and can be found at: > https://www.arin.net/participate/policy/drafts/2019_9/ > > 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/participate/policy/pdp/ > > Draft Policies and Proposals under discussion can be found at: > https://www.arin.net/participate/policy/drafts/ > > Regards, > > Sean Hopkins > Policy Analyst > American Registry for Internet Numbers (ARIN) > > > > Draft Policy ARIN-2019-9: Clarify Interactions Between NRPM 4.10 IPv6 > Transition Space Requests and NRPM 4.1.8.2 Unmet Needs Requests > > Problem Statement: > > It has been observed that an organization requesting IPv4 resources > under NRPM Section 4.10, Dedicated IPv4 Block To Facilitate IPv6 > Deployment, can also request similar or the same resources under Section > 4.2.1.8, Unmet Needs. This proposal aims to remove this potential for > duplicate requests under these sections. > > Policy Statement: > > Section 4.1.8.2, Unmet Needs: > > Current language: Any requests met through a transfer will be considered > fulfilled and removed from the waiting list. > > Proposed language: > > Any requests met through a transfer or an allocation request fulfilled > under Section 4.10 will be considered fulfilled and removed from the > waiting list. > > Timetable for Implementation: Immediate > > Anything Else: > > Currently, organizations can receive no more than a /24 at a time under > Section 4.10. However, Proposal ARIN-PROP-266, submitted by Chris Tacit > and myself, could potentially allow an org to receive up to a /21 under > that section, widening the potential for abuse by “double-dipping” > waiting list and transition space requests. As such, this proposal > should be considered in that context. > ___ > ARIN-PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). > Unsubscribe or manage your mailing list subscription at: > https://lists.arin.net/mailman/listinfo/arin-ppml > Please contact i...@arin.net if you experience any issues. > ___ ARIN-PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML@arin.net). Unsubscribe or manage your mailing list subscription at: https://lists.arin.net/mailman/listinfo/arin-ppml Please contact i...@arin.net if you experience any issues.
Re: [arin-ppml] ARIN-PPML Draft 2019-1
Carlton- thank you for your comment. All- Our Advisory Council meeting is this Thursday and I'd like to see if we can get any additional comments for moving this forward. If there are no comments, I will be moving this to a vote on the AC to get this in recommended status. Thanks Kat Hunter On Mon, Jul 8, 2019 at 6:49 PM Carlton Samuels wrote: > I support the change of language for this draft policy. > > Carlton Samuels > > On Mon, 8 Jul 2019, 3:16 pm Kat Hunter, wrote: > >> Good afternoon, >> >> With the ARIN board recently adopting the AC's recommendation to >> re-instate the wait-list policy, we should now reconsider Draft Policy >> ARIN-2019-1: Clarify Section 4 IPv4 Request Requirements draft policy in >> light of those changes. In the AC's recommendation, the specific part of >> this section remains unchanged. Would everyone like to proceed with the >> following changes: >> >> Current language found in NRPM Section 4.1.8 - Unmet Requests: >> >> Repeated requests, in a manner that would circumvent 4.1.6, are not >> allowed: an organization may only receive one allocation, assignment, or >> transfer every 3 months, but ARIN, at its sole discretion, may waive >> this requirement if the requester can document a change in circumstances >> since their last request that could not have been reasonably foreseen at >> the time of the original request, and which now justifies additional >> space. >> >> Proposed new language: >> >> Repeated requests, in a manner that would circumvent 4.1.6 are not >> allowed: an organization may not apply for IPv4 address resources under >> this section if they have received an allocation, assignment, or >> transfer of IPv4 resources less than three months prior, or if the >> organization has transferred space to another party under Section 8 less >> than 36 months prior. ARIN, at its sole discretion, may waive this >> restriction if the requester can document a change in circumstances >> since their last request that could not have been reasonably foreseen at >> the time of the original request, and which now justifies additional >> space. >> >> >> Would you like this to proceed to recommended draft as proposed? Feedback >> before the reinstatement of the wait list was very positive for this and we >> would appreciate any additional comments or verification on moving this to >> recommended draft. >> >> -Thanks >> Kat Hunter >> >> On Thu, Apr 18, 2019 at 8:27 AM Brian Jones wrote: >> >>> I support Draft Policy 2019-1 with the new proposed language. >>> >>> -- >>> Brian E Jones, CSP-SM, CSP-PO >>> NI Virginia Tech >>> bjo...@vt.edu >>> >>> On Apr 18, 2019, at 7:20 AM, Rudolph Daniel >>> wrote: >>> >>> >>> I support this draft proposal.. >>> RD >>> >>> On Wed, Apr 17, 2019 at 12:00 PM wrote: >>> >>>> Send ARIN-PPML mailing list submissions to >>>> arin-ppml@arin.net >>>> >>>> To subscribe or unsubscribe via the World Wide Web, visit >>>> https://lists.arin.net/mailman/listinfo/arin-ppml >>>> or, via email, send a message with subject or body 'help' to >>>> arin-ppml-requ...@arin.net >>>> >>>> You can reach the person managing the list at >>>> arin-ppml-ow...@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. Revised - Draft Policy ARIN-2019-1: Clarify Section 4 IPv4 >>>> Request Requirements (ARIN) >>>> >>>> >>>> -- >>>> >>>> Message: 1 >>>> Date: Tue, 16 Apr 2019 14:26:07 -0400 >>>> From: ARIN >>>> To: arin-ppml@arin.net >>>> Subject: [arin-ppml] Revised - Draft Policy ARIN-2019-1: Clarify >>>> Section 4 IPv4 Request Requirements >>>> Message-ID: <6a411169-0e13-2087-d6f2-5176a56bf...@arin.net> >>>> Content-Type: text/plain; charset=utf-8; format=flowed >>>> >>>> The following has been revised: >>>> >>>> * Draft Policy ARIN-2019-1: Clarify Section 4 IPv4 Request Requirements >>>> >>>> Revised text is below and can be found at: >>>> https://www.arin.net/pa
Re: [arin-ppml] ARIN-PPML Draft 2019-1
Good afternoon, With the ARIN board recently adopting the AC's recommendation to re-instate the wait-list policy, we should now reconsider Draft Policy ARIN-2019-1: Clarify Section 4 IPv4 Request Requirements draft policy in light of those changes. In the AC's recommendation, the specific part of this section remains unchanged. Would everyone like to proceed with the following changes: Current language found in NRPM Section 4.1.8 - Unmet Requests: Repeated requests, in a manner that would circumvent 4.1.6, are not allowed: an organization may only receive one allocation, assignment, or transfer every 3 months, but ARIN, at its sole discretion, may waive this requirement if the requester can document a change in circumstances since their last request that could not have been reasonably foreseen at the time of the original request, and which now justifies additional space. Proposed new language: Repeated requests, in a manner that would circumvent 4.1.6 are not allowed: an organization may not apply for IPv4 address resources under this section if they have received an allocation, assignment, or transfer of IPv4 resources less than three months prior, or if the organization has transferred space to another party under Section 8 less than 36 months prior. ARIN, at its sole discretion, may waive this restriction if the requester can document a change in circumstances since their last request that could not have been reasonably foreseen at the time of the original request, and which now justifies additional space. Would you like this to proceed to recommended draft as proposed? Feedback before the reinstatement of the wait list was very positive for this and we would appreciate any additional comments or verification on moving this to recommended draft. -Thanks Kat Hunter On Thu, Apr 18, 2019 at 8:27 AM Brian Jones wrote: > I support Draft Policy 2019-1 with the new proposed language. > > -- > Brian E Jones, CSP-SM, CSP-PO > NI Virginia Tech > bjo...@vt.edu > > On Apr 18, 2019, at 7:20 AM, Rudolph Daniel wrote: > > > I support this draft proposal.. > RD > > On Wed, Apr 17, 2019 at 12:00 PM wrote: > >> Send ARIN-PPML mailing list submissions to >> arin-ppml@arin.net >> >> To subscribe or unsubscribe via the World Wide Web, visit >> https://lists.arin.net/mailman/listinfo/arin-ppml >> or, via email, send a message with subject or body 'help' to >> arin-ppml-requ...@arin.net >> >> You can reach the person managing the list at >> arin-ppml-ow...@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. Revised - Draft Policy ARIN-2019-1: Clarify Section 4 IPv4 >> Request Requirements (ARIN) >> >> >> -- >> >> Message: 1 >> Date: Tue, 16 Apr 2019 14:26:07 -0400 >> From: ARIN >> To: arin-ppml@arin.net >> Subject: [arin-ppml] Revised - Draft Policy ARIN-2019-1: Clarify >> Section 4 IPv4 Request Requirements >> Message-ID: <6a411169-0e13-2087-d6f2-5176a56bf...@arin.net> >> Content-Type: text/plain; charset=utf-8; format=flowed >> >> The following has been revised: >> >> * Draft Policy ARIN-2019-1: Clarify Section 4 IPv4 Request Requirements >> >> Revised text is below and can be found at: >> https://www.arin.net/participate/policy/drafts/2019_1/ >> >> 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/participate/policy/pdp/ >> >> Draft Policies and Proposals under discussion can be found at: >> https://www.arin.net/participate/policy/drafts/ >> >> Regards, >> >> Sean Hopkins >> Policy Analyst >> American Registry for Internet Numbers (ARIN) >> >> >> >> Draft Policy ARIN-2019-1: Clarify Section 4 IPv4 Request Requirements >> >> Problem Statement: >> >> Per a recent ARIN Policy Experience Report and resulting AC discussion, >> it was noted that the language of Section 4.1.8 is imprecise in that it >> can be interpreted as specifying a waiting period for any allocation >> activity, as op
