[arin-ppml] Draft Policy 2017-12: Require POC Validation Upon Reassignment

[Scott Leibrand]

How do we address the risk that companies with fully automated
whois-population systems simply don't bother to do that research, and their
delegation ends up not getting added to whois at all?

This may be an implementation detail, but I think we should make sure the
policy allows for an option for the new POC to replace the proposed new POC
object with a reference to one of their existing POC records...

-Scott

On Tue, Mar 13, 2018 at 11:07 AM, <hostmaster at uneedus.com> wrote:

> I support.
>
> I think this will go a long way in getting correct POC's in the database
> at the start.  Currently, whoever is doing the ordering might end up with
> their contacts in the database, because that is the only information that
> the service provider has. This is how we end up with purchasing or
> accounting contacts in Whois who have no clue as to abuse complaints and/or
> the annual validation email.  This will force the service provider to
> actually ASK who the company wants as a Whois contact, and to explain to
> them what duties this involves, including a reminder of the annual
> validation email that they need to respond to.
>
> Albert Erdmann
> Network Administrator
> Paradise On Line Inc.
>
>
> On Mon, 12 Mar 2018, Christian Tacit wrote:
>
> Dear Community Members,
>>
>> The shepherds for the Draft Policy 2017-12: Require POC Validation Upon
>> Reassignment, are making two changes to its text.
>>
>> First, the problem statement is being expanded a bit to explain how POCs
>> for reassigned blocks can be assigned without the knowledge of the
>> individuals so assigned under the present policy.
>>
>> Second, proposed section 3.8 has been deleted. This is because it is
>> unintentionally misleading because a simple reassignment results in a
>> customer identifier versus an OrgID.  There is no contact information
>> contained in a simple reassignment other than street address that could be
>> used for notification, and thus it does not appear that the proposed NRPM
>> 3.8 policy text is implementable.  Even if notification were possible, the
>> "OR postal address" in this section may also cause significant problems for
>> some companies as many companies have the same name associated with many
>> different locations and there are several locations that have many
>> companies registered there.
>>
>> Based on these changes, the revised text reads:
>>
>>
>> Version Date: March 12, 2018
>>
>>
>>
>> Problem Statement:
>>
>> Some large ISPs assign individuals to be POCs for reassigned blocks
>> without consultation of the individual they are inserting into Whois. For
>> example, during the reassignment/reallocation process, some large ISPs
>> automatically create POCs from their customer's order form. This process is
>> automated for many ISPs and therefore the resulting POCs are not validated
>> prior to being created in the ARIN Whois database. This creates unknowing
>> POCs that have no idea what Whois is or even who ARIN is at the time they
>> receive the annual POC validation email. It can also create multiple POCs
>> per email address causing that same person to receive a multitude of POC
>> Validation emails each year.
>>
>> This policy proposal seeks to improve the situation where a POC is
>> unwittingly and unintentionally 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 one new section 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.
>>
>>
>>
>> Timetable for implementation: Immediate
>>
>> Comments from the community are welcome!
>>
>>
>> Christian S. Tacit
>>
>>
>>
>> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage 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: <https://lists.arin.net/pipermail/arin-ppml/attachments/20180313/d8b66779/attachment.htm>