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 <[email protected]> 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 ([email protected]).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact [email protected] if you experience any issues.
> 

_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List ([email protected]).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact [email protected] if you experience any issues.

Reply via email to