<div dir="ltr">Chris,<br><div><br></div><div>Thanks. </div><div><br></div><div>One of the problems with POC validation is that ARIN tries to validate all POCS, and does not have a relationship with some.</div><div><br></div><div>There is a proposal to reduce the validation to only the set of POCs that ARIN has a direct relationship with.</div><div><br></div><div>This is problematic because it is through this annual validation that one finds they have become a POC on some resource.</div><div>So without out the annual check, those organizations will NOT have the awareness and knowledge to resolve that issue between themselves.</div><div><br></div><div>The solution is a bi-directional check. </div><div><br></div><div>I think the ARIN objection is that it is problematic for the SWIPee to modify the record of the SWIPer.</div><div>But I see no problem with the SWIPee getting notified, or even ACKing or NACKIing the SWIP.</div><div><br></div><div>__Jason</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr">On Sat, Apr 14, 2018 at 2:23 PM Christian Tacit <<a href="mailto:ctacit@tacitlaw.com">ctacit@tacitlaw.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-CA" link="blue" vlink="purple">
<div class="m_-161291718103620114WordSection1">
<p class="MsoNormal"><span>Hi Jason,<u></u><u></u></span></p>
<p class="MsoNormal"><span><u></u> <u></u></span></p>
<p class="MsoNormal"><span>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.
<u></u><u></u></span></p>
<p class="MsoNormal"><span><u></u> <u></u></span></p>
<p class="MsoNormal"><span>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. <u></u><u></u></span></p>
<p class="MsoNormal"><span><u></u> <u></u></span></p>
<p class="MsoNormal"><span>Chris</span><u></u><u></u></p>
<p class="MsoNormal"><span><u></u> <u></u></span></p>
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> Jason Schiller <<a href="mailto:jschiller@google.com" target="_blank">jschiller@google.com</a>>
<br>
<b>Sent:</b> March 15, 2018 4:29 PM<br>
<b>To:</b> Christian Tacit <<a href="mailto:ctacit@tacitlaw.com" target="_blank">ctacit@tacitlaw.com</a>><br>
<b>Cc:</b> <a href="mailto:arin-ppml@arin.net" target="_blank">arin-ppml@arin.net</a><br>
<b>Subject:</b> Re: [arin-ppml] Draft Policy 2017-12: Require POC Validation Upon Reassignment<u></u><u></u></span></p>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<div>
<p class="MsoNormal">This problem is not scoped only to with a new POC is created.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">This was also supposed to be a check in 3.7 to insure a resource is not<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">randomly SWIP'd to a pre-existing org.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">3.8 was intended to chatch when a resource is SWIP'd to a pre-existing org, <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">but that org ID is not used, and that org's address is put into a reassign simple.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<div>
<p class="MsoNormal">I don't see how this is not implementable..<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">- If the compnay name is a match for something ARIN already has a relationship with,<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> then they should have good contact info.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">- If the contact info is a known address of a compnay that ARIN already has a <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"> relationship with, then they should have good contact info for that compnay.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">- If all else fails they can send a post card to the mailing address.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">At a mimimum, if the post card is undeliverable, or a holder of the the post card<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">contacts ARIN, they should revoke the SWIP.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal">___Jason<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal">On Mon, Mar 12, 2018 at 5:47 PM, Christian Tacit <<a href="mailto:ctacit@tacitlaw.com" target="_blank">ctacit@tacitlaw.com</a>> wrote:<u></u><u></u></p>
<blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Times New Roman",serif">Dear Community Members,</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Times New Roman",serif"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Times New Roman",serif">The shepherds for the Draft Policy 2017-12: Require POC Validation Upon Reassignment, are making two changes to
its text.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Times New Roman",serif"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Times New Roman",serif">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.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Times New Roman",serif"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Times New Roman",serif">Second, proposed section 3.8 has been deleted. This is because it is unintentionally misleading
</span><span lang="EN-US" style="font-size:14.0pt;font-family:"Times New Roman",serif;color:black">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.</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Times New Roman",serif"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Times New Roman",serif">Based on these changes, the revised text reads:</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Times New Roman",serif"> </span><u></u><u></u></p>
<p style="margin:0cm;margin-bottom:.0001pt;line-height:18.0pt;background:white"><strong><span style="font-size:14.0pt;font-family:"Calibri",sans-serif;color:black;border:none windowtext 1.0pt;padding:0cm">Version Date: March 12, 2018</span></strong><u></u><u></u></p>
<p style="margin:0cm;margin-bottom:.0001pt;line-height:18.0pt;background:white"><strong><span style="font-size:14.0pt;font-family:"Calibri",sans-serif;color:black;border:none windowtext 1.0pt;padding:0cm"> </span></strong><u></u><u></u></p>
<p style="margin:0cm;margin-bottom:.0001pt;line-height:18.0pt;background:white"><strong><span style="font-size:14.0pt;font-family:"Calibri",sans-serif;color:black;border:none windowtext 1.0pt;padding:0cm">Problem Statement:</span></strong><u></u><u></u></p>
<p style="margin-bottom:6.0pt;line-height:18.0pt;background:white;font-variant-ligatures:normal;font-variant-caps:normal;text-align:start;text-decoration-style:initial;text-decoration-color:initial;word-spacing:0px">
<span style="font-size:14.0pt;color:black">Some large ISPs assign individuals to be POCs for reassigned blocks without consultation of the individual they are inserting into Whois. For example, during</span><span lang="EN-US" style="font-size:14.0pt;color:black">
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.</span><u></u><u></u></p>
<p style="margin-bottom:6.0pt;line-height:18.0pt;background:white"><span style="font-size:14.0pt;color:black">This policy proposal seeks to improve the situation where a POC is unwittingly and unintentionally inserted into Whois.</span><u></u><u></u></p>
<p style="margin-bottom:6.0pt;line-height:18.0pt;background:white;font-variant-ligatures:normal;font-variant-caps:normal;text-align:start;text-decoration-style:initial;text-decoration-color:initial;word-spacing:0px">
<span style="font-size:14.0pt;color:black">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.</span><u></u><u></u></p>
<p style="margin-bottom:6.0pt;line-height:18.0pt;background:white;font-variant-ligatures:normal;font-variant-caps:normal;text-align:start;text-decoration-style:initial;text-decoration-color:initial;word-spacing:0px">
<span style="font-size:14.0pt;color:black">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.</span><u></u><u></u></p>
<p style="margin:0cm;margin-bottom:.0001pt;line-height:18.0pt;background:white;font-variant-ligatures:normal;font-variant-caps:normal;text-align:start;text-decoration-style:initial;text-decoration-color:initial;word-spacing:0px">
<strong><span style="font-size:14.0pt;font-family:"Calibri",sans-serif;color:black;border:none windowtext 1.0pt;padding:0cm"> </span></strong><u></u><u></u></p>
<p style="margin:0cm;margin-bottom:.0001pt;line-height:18.0pt;background:white"><strong><span style="font-size:14.0pt;font-family:"Calibri",sans-serif;color:black;border:none windowtext 1.0pt;padding:0cm">Policy statement:</span></strong><u></u><u></u></p>
<p style="margin-bottom:6.0pt;line-height:18.0pt;background:white;font-variant-ligatures:normal;font-variant-caps:normal;text-align:start;text-decoration-style:initial;text-decoration-color:initial;word-spacing:0px">
<span style="font-size:14.0pt;color:black">Insert one new section into NRPM 3:</span><u></u><u></u></p>
<p style="margin-bottom:6.0pt;line-height:18.0pt;background:white;font-variant-ligatures:normal;font-variant-caps:normal;text-align:start;text-decoration-style:initial;text-decoration-color:initial;word-spacing:0px">
<span style="font-size:14.0pt;color:black">3.7 New POC Validation Upon Reassignment</span><u></u><u></u></p>
<p style="margin-bottom:6.0pt;line-height:18.0pt;background:white;font-variant-ligatures:normal;font-variant-caps:normal;text-align:start;text-decoration-style:initial;text-decoration-color:initial;word-spacing:0px">
<span style="font-size:14.0pt;color:black">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:</span><u></u><u></u></p>
<p style="margin-bottom:6.0pt;line-height:18.0pt;background:white;font-variant-ligatures:normal;font-variant-caps:normal;text-align:start;text-decoration-style:initial;text-decoration-color:initial;word-spacing:0px">
<span style="font-size:14.0pt;color:black">- the information about the organization submitting the record; and<br>
- the resource(s) to which the POC is being attached; and<br>
- the organization(s) to which the POC is being attached.</span><u></u><u></u></p>
<p style="margin-bottom:6.0pt;line-height:18.0pt;background:white;font-variant-ligatures:normal;font-variant-caps:normal;text-align:start;text-decoration-style:initial;text-decoration-color:initial;word-spacing:0px">
<span style="font-size:14.0pt;color:black">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.</span><u></u><u></u></p>
<p style="margin:0cm;margin-bottom:.0001pt;line-height:18.0pt;background:white;font-variant-ligatures:normal;font-variant-caps:normal;text-align:start;text-decoration-style:initial;text-decoration-color:initial;word-spacing:0px">
<strong><span style="font-size:14.0pt;font-family:"Calibri",sans-serif;color:black;border:none windowtext 1.0pt;padding:0cm"> </span></strong><u></u><u></u></p>
<p style="margin:0cm;margin-bottom:.0001pt;line-height:18.0pt;background:white"><strong><span style="font-size:14.0pt;font-family:"Calibri",sans-serif;color:black;border:none windowtext 1.0pt;padding:0cm">Timetable for implementation:</span></strong><span style="font-size:14.0pt;color:black"> Immediate</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Times New Roman",serif"> </span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Times New Roman",serif">Comments from the community are welcome!</span><u></u><u></u></p>
<p class="MsoNormal"><span style="font-size:14.0pt;font-family:"Times New Roman",serif"> </span><u></u><u></u></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:14.0pt;font-family:"Times New Roman",serif"><br>
Christian S. Tacit</span><u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"><br>
_______________________________________________<br>
PPML<br>
You are receiving this message because you are subscribed to<br>
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net" target="_blank">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a href="http://lists.arin.net/mailman/listinfo/arin-ppml" target="_blank">http://lists.arin.net/mailman/listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net" target="_blank">info@arin.net</a> if you experience any issues.<u></u><u></u></p>
</blockquote>
</div>
<p class="MsoNormal"><br>
<br clear="all">
<u></u><u></u></p>
<div>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
<p class="MsoNormal">-- <u></u><u></u></p>
<div>
<div>
<p class="MsoNormal"><span style="font-family:"Courier New";color:#555555">_______________________________________________________</span><span style="font-family:"Arial",sans-serif;color:black"><u></u><u></u></span></p>
<div>
<p class="MsoNormal"><span style="font-family:"Courier New";color:black">Jason Schiller|NetOps|<a href="mailto:jschiller@google.com" target="_blank">jschiller@google.com</a>|571-266-0006</span><span style="font-family:"Arial",sans-serif;color:black"><u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-family:"Arial",sans-serif;color:black"><u></u> <u></u></span></p>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><font color="#555555" face="'courier new', monospace"><div><span style="color:rgb(0,0,0);font-family:arial"><font color="#555555" face="'courier new', monospace">_______________________________________________________<br></font><div><font face="'courier new', monospace">Jason Schiller|NetOps|<a href="mailto:jschiller@google.com" target="_blank">jschiller@google.com</a>|571-266-0006</font></div><div><font face="'courier new', monospace"><br></font></div></span></div></font></div>