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

[Christian Tacit]

Hi Jason,

Although I did look into the issue raised by your March 15 email promptly after 
receiving it. I inadvertently forgot to reply to you. Please accept my apology.

Based on ARIN Staff input, a major impediment to the proposed Section 3.8 is 
that ARIN cannot be involved in the contractual relationship between its 
customer and any of the customer’s customers. The ARIN customer may be 
submitting a simple reassignment, precisely because it wants to maintain 
control over POC records. Examples may include branches located in different 
states of an entity that may want to use address information corresponding to 
its  head office and or other locations in which it has a presence. If there is 
a dispute with an entity that already has an OrgID with ARIN and its upstream 
provider on how to register the entity’s reassignments, those organizations 
will have the awareness and knowledge to resolve that issue between themselves.

Chris

From: Jason Schiller 
Sent: March 15, 2018 4:29 PM
To: Christian Tacit 
Cc: arin-ppml@arin.net
Subject: Re: [arin-ppml] Draft Policy 2017-12: Require POC Validation Upon 
Reassignment

This problem is not scoped only to with a new POC is created.

This was also supposed to be a check in 3.7 to insure a resource is not
randomly SWIP'd to a pre-existing org.

3.8 was intended to chatch when a resource is SWIP'd to a pre-existing org,
but that org ID is not used, and that org's address is put into a reassign 
simple.

I don't see how this is not implementable..

- If the compnay name is a match for something ARIN already has a relationship 
with,
  then they should have good contact info.

- If the contact info is a known address of a compnay that ARIN already has a
  relationship with, then they should have good contact info for that compnay.

- If all else fails they can send a post card to the mailing address.

At a mimimum, if the post card is undeliverable, or a holder of the the post 
card
contacts ARIN, they should revoke the SWIP.

___Jason






On Mon, Mar 12, 2018 at 5:47 PM, 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 

[arin-ppml] ARIN-2017-9 and ARIN-2018-2

[David Farmer]

As you are preparing for the public policy meeting next week, please review
two of the policies together, Draft Policy ARIN-2017-9: Clarification of
Initial Block Size for IPv4 ISP Transfers and Draft Policy ARIN-2018-2:
Clarification to ISP Initial Allocation and Permit Renumbering. These two
policies take different approaches to address the same inconsistency that
was discussed in the ARIN 40 Policy Experience Report presented at the
last public
policy meeting, the report is available at the following links;

Slides:
https://www.arin.net/vault/participate/meetings/reports/ARIN_40/PDF/PPM/sweeting-policy-experience.pdf
Transcript:
https://www.arin.net/vault/participate/meetings/reports/ARIN_40/ppm1_transcript.html#anchor_5
Video: https://www.youtube.com/watch?v=QVsfVMG_6fA

Slides 10 - 13, located in the video from 6:30 to 8:30, are the relevant
portion of the report, questions from the audience follow.

ARIN-2017-9 addresses the inconsistency by revising Section 8.5.4 to be
consistent with Section 4.2.2, allowing new ISPs to transfer a /24 up to a
/21 without further justification.

ARIN-2018-2 addresses the inconsistency by revising Section 4.2.2 to
be consistent
with Section 8.5.4, allowing new ISPs to transfer only a /24 without
further justification. However, it clarifies they may transfer up to a /21
when documenting its use within 24 months, as described in Section 4.2.4.3.

Thanks.
-- 
===
David Farmer   Email:far...@umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SEPhone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===
___
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.