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

[Jason Schiller]

Chris,

Thanks.

One of the problems with POC validation is that ARIN tries to validate all
POCS, and does not have a relationship with some.

There is a proposal to reduce the validation to only the set of POCs that
ARIN has a direct relationship with.

This is problematic because it is through this annual validation that one
finds they have become a POC on some resource.
So without out the annual check, those organizations will NOT have the
awareness and knowledge to resolve that issue between themselves.

The solution is a bi-directional check.

I think the ARIN objection is that it is problematic for the SWIPee to
modify the record of the SWIPer.
But I see no problem with the SWIPee getting notified, or even ACKing or
NACKIing the SWIP.

__Jason



On Sat, Apr 14, 2018 at 2:23 PM Christian Tacit <ctacit at tacitlaw.com> wrote:

> 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 <jschiller at google.com>
> *Sent:* March 15, 2018 4:29 PM
> *To:* Christian Tacit <ctacit at tacitlaw.com>
> *Cc:* arin-ppml at 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 <ctacit at tacitlaw.com>
> 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.
>
>
>
>
>
> --
>
> _______________________________________________________
>
> Jason Schiller|NetOps|jschiller at google.com|571-266-0006
>
>
>


-- 
_______________________________________________________
Jason Schiller|NetOps|jschiller at google.com|571-266-0006
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20180416/a2b7de29/attachment.htm>