This is one unavoidable issue with this proposal. ISPs will effectively be forced into a workflow where a ISP must allocate addresses and submit the SWIP prior to routing the block, and then not start routing until the POC is validated, unless ISPs want to risk customer impact/ire from having to withdraw the routing 10 days afterwards should the POC not complete the validation.
Personally, I consider this a positive change in process, but those actually handling customer turnups are welcome to disagree. -C > On Apr 18, 2018, at 12:48 PM, Delacruz, Anthony B > <[email protected]> wrote: > > The reject will likely alert us but my systems are not setup to wait 10+ day > and then have to go sort out fixing it. I’m worried this is probably going to > break some of that. Legacy Centurylink going back thru the Qwest side have > done a pretty good job of submitting to whois, other companies we have > purchased not so well and we’re working to improve that but it’s a constant > battle of staff and use of time. We won’t allocate folks to go chase down > customers to click off approval. Asking to do on the phone also not likely as > a great many of offerings are moving to more automation. We have entire > service classes that can be ordered online, instantly provisioned and > activated and then the customer plugs into a prewired/fiber’d port never once > interacting with a human. Concerned about both 10 limbo and the loss of info > that might be a lead for LEO’s at the very least. I’ve used at least company > name and phone number 100’s of times when the poc was old outdated as a > starting point in trying to reach folks for issues it would be unfortunate > not to have at least. > > From: Jason Schiller [mailto:[email protected] > <mailto:[email protected]>] > Sent: Wednesday, April 18, 2018 9:01 AM > To: Delacruz, Anthony B > Cc: ARIN-PPML List > Subject: Re: [arin-ppml] Draft Policy 2017-12: Require POC Validation Upon > Reassignment > > Anthony, > > I hear you. And I think we should try a "lets do better" approach. > > I think the goal here is to get good SWIP data, and make sure the > contact info is correct. > > This specific approach is an attempt to prevent a SWIP targeting > a (wrong) unwitting victim. > > In your case I believe you are suggesting you collected the proper > contact info, and explained it will be included in the SWIP, and > verified that they don't have a pre-existing OrgID or POC, to > SWIP to. But then they drop the ARIN email. And the SWIP > gets rejected. > > Rejected SWIPs from email templates get an email > from ARIN Hostmaster <[email protected] <mailto:[email protected]>> > with a subject including --REJECTED > > Is this sufficient for you to track down the > customers who didn't ack, and fix this issue? > > Is there a better way to loop the ISP back in > and unwedge the stuck request? > > Would an ARIN Online page of here are all the SWIPs > that cannot be SWIP'd due to pending ACK help? > A button to resend the request (while your customer > is on the phone)? > > Are you concerned about the 10 days it is in limbo? > Or the long term stuff that never gets acked? > > __Jason > > On Tue, Apr 17, 2018 at 4:54 PM Delacruz, Anthony B > <[email protected] <mailto:[email protected]>> > wrote: > Howdy folks I very much hope I’m not a significant part of this problem but > we do submit 50-100 reassigns a week. If there is any evidence of us causing > trouble in the data I’d be happy to try to run it down and improve. As noted > by others we do this primarily to offload abuse but also to assist LEO’s and > to be upfront with the community how our space is being use. We also try as > hard as we can to populate those records with valid info and have our sales > guys collect and input into our system then the provisioning team validates > at turn up and the system auto generates at activation the record. I worry > greatly that if an entry we send up goes unvalidated for 10 days that it must > be deleted. I think you are going to be losing a lot of good data of legit > usage simply because folks maybe too lazy to click off on an acknowledgment. > If implemented I could be sending all these updates and not seeing them > appear and wondering till 10 days down the road which ones I have to > reattempt? Will there be a notification back that the record did not > populate? That reattempt piece will be a lot of fun to workout with our IT > guys I can tell you it’ll just be dropped for a long time until they work out > the code to automate and thus usability of whois will be impacted. > > > Anthony Delacruz > Senior Lead Engineer > IP Admin Backbone Planning and Design > Office: +1 703 363 8503 > [email protected] <mailto:[email protected]> > [email protected] <mailto:[email protected]> > > > > From: ARIN-PPML [mailto:[email protected] > <mailto:[email protected]>] On Behalf Of John Santos > Sent: Tuesday, April 17, 2018 1:58 PM > To: [email protected] <mailto:[email protected]> > Subject: Re: [arin-ppml] Draft Policy 2017-12: Require POC Validation Upon > Reassignment > > I think anyone who supplies someone else's email address to a third party > without their permission is responsible for any mail they receive. Unless a > SWIPer has permission from their customer to SWIP the customer's email > address, the ISP doing the SWIPing is responsible, not ARIN. If they do this > repeatedly or as a matter of course, they should be barred from SWIPing and > any subnets they have previously SWIPed should revert to them, making them > responsible for all network abuse and connectivity problems originating from > those subnets. > > Isn't the entire point of SWIP to allow ISPs to offload the abuse and other > points of contact to their customers, who presumably are more capable of > dealing with the issues? And shouldn't the customers expect to receive email > at those POC addresses as part of that? Either the ISP has explained that to > their customers, who have agreed to this, in which case no mail sent to them > as a consequence is SPAM, or the ISP has not, in which case the POC (and > SWIP) should be removed or never allowed in the first place. > > > > > On 4/17/2018 11:11 AM, Christian Tacit wrote: > Hi Jason, > > After discussion with staff, I can report that it would be much easier to > send a notification to the email that is swipped as the POC but to add in any > type of ACK or NACK turns it into a very, very heavy lift for the > organizations as it completely changes the flow. Furthemore, the addition of > a requirement for a response could end up creating issues (whether real or > perceived) that ARIN would be sending UCE (Unsolicited Commercial Email) > (SPAM) to all of those contacts as we do not have a formal relationship with > them. > > Chris > > > Christian S. Tacit, > Tacit Law > > P.O. Box 24210 RPO Hazeldean > Kanata, Ontario > K2M 2C3 Canada > > Tel: +1 613 599 5345 > Fax: +1 613 248 5175 > E-mail: [email protected] <mailto:[email protected]> > > This message is intended only for the use of the individual or entity to > which it is addressed and may contain information that is subject to > copyright, privileged, confidential, proprietary or exempt from disclosure > under applicable law. If you are not the intended recipient or the person > responsible for delivering the message to the intended recipient, you are > strictly prohibited from disclosing, distributing, copying or in any way > using this message. If you have received this communication in error, please > notify the sender and destroy or delete copies you may have received. > > From: Jason Schiller <[email protected]> <mailto:[email protected]> > Sent: April 16, 2018 3:05 PM > To: Christian Tacit <[email protected]> <mailto:[email protected]> > Cc: ARIN-PPML List <[email protected]> <mailto:[email protected]> > Subject: Re: [arin-ppml] Draft Policy 2017-12: Require POC Validation Upon > Reassignment > > 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 <[email protected] > <mailto:[email protected]>> 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 <[email protected] <mailto:[email protected]>> > Sent: March 15, 2018 4:29 PM > To: Christian Tacit <[email protected] <mailto:[email protected]>> > Cc: [email protected] <mailto:[email protected]> > 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 <[email protected] > <mailto:[email protected]>> 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. > > > > -- > _______________________________________________________ > Jason Schiller|NetOps|[email protected] > <mailto:[email protected]>|571-266-0006 > > > > -- > _______________________________________________________ > Jason Schiller|NetOps|[email protected] > <mailto:[email protected]>|571-266-0006 > > > > > _______________________________________________ > 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. > > > -- > John Santos > Evans Griffiths & Hart, Inc. > 781-861-0670 ext 539 > This communication is the property of CenturyLink and may contain > confidential or privileged information. Unauthorized use of this > communication is strictly prohibited and may be unlawful. If you have > received this communication in error, please immediately notify the sender by > reply e-mail and destroy all copies of the communication and any attachments. > _______________________________________________ > 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. > > > -- > _______________________________________________________ > Jason Schiller|NetOps|[email protected] > <mailto:[email protected]>|571-266-0006 > > This communication is the property of CenturyLink and may contain > confidential or privileged information. Unauthorized use of this > communication is strictly prohibited and may be unlawful. If you have > received this communication in error, please immediately notify the sender by > reply e-mail and destroy all copies of the communication and any attachments. > _______________________________________________ > 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.
