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 <cta...@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 <jschil...@google.com> > *Sent:* March 15, 2018 4:29 PM > *To:* Christian Tacit <cta...@tacitlaw.com> > *Cc:* firstname.lastname@example.org > *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 <cta...@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@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. > > > > > > -- > > _______________________________________________________ > > Jason Schiller|NetOps|jschil...@google.com|571-266-0006 > > > -- _______________________________________________________ Jason Schiller|NetOps|jschil...@google.com|571-266-0006
_______________________________________________ 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.