> On Mar 13, 2018, at 11:54 , Scott Leibrand <[email protected]> wrote: > > 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?
I see that as less of a problem than the current situation. Eventually, this will result in complaints that reach their whois contacts and/or their ARIN billing contacts. If the billing contacts don’t respond, well, then their use of the IP addresses will become a short-term problem in most cases. > 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… Not sure how you expect that to work, but would be interested if you think you have a feasible proposal. The devil is in the details. You have Company A creating a POC for an individual that works at Company B and now you want that individual from Company B to be able to ask ARIN to substitute the link on an IP block registered to Company A with an alternative POC provided by the individual from Company B. What could possibly go wrong? Owen > > -Scott > > On Tue, Mar 13, 2018 at 11:07 AM, <[email protected] > <mailto:[email protected]>> 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 ([email protected] > <mailto:[email protected]>). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > <http://lists.arin.net/mailman/listinfo/arin-ppml> > Please contact [email protected] <mailto:[email protected]> if you experience any > issues. > > _______________________________________________ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List ([email protected]). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact [email protected] if you experience any issues.
_______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List ([email protected]). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/arin-ppml Please contact [email protected] if you experience any issues.
