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

[Chris Woodfield]

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 
> <anthony.delac...@centurylink.com> 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:jschil...@google.com 
> <mailto:jschil...@google.com>] 
> 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 <hostmas...@arin.net <mailto:hostmas...@arin.net>>
> 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 
> <anthony.delac...@centurylink.com <mailto:anthony.delac...@centurylink.com>> 
> 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

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

[Delacruz, Anthony B]

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:jschil...@google.com]
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 <hostmas...@arin.net<mailto:hostmas...@arin.net>>
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 
<anthony.delac...@centurylink.com<mailto:anthony.delac...@centurylink.com>> 
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
anthony.delac...@centurylink.com<mailto:anthony.delac...@centurylink.com>
ipad...@centurylink.com<mailto:ipad...@centurylink.com>



From: ARIN-PPML 
[mailto:arin-ppml-boun...@arin.net<mailto:arin-ppml-boun...@arin.net>] On 
Behalf Of John Santos
Sent: Tuesday, April 17, 2018 1:58 PM
To: arin-ppml@arin.net<mailto:arin-ppml@arin.net>
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 th

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

[Jason Schiller]

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 <hostmas...@arin.net>
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 <
anthony.delac...@centurylink.com> 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
>
> anthony.delac...@centurylink.com
>
> ipad...@centurylink.com
>
>
>
>
>
>
>
> *From:* ARIN-PPML [mailto:arin-ppml-boun...@arin.net] *On Behalf Of *John
> Santos
> *Sent:* Tuesday, April 17, 2018 1:58 PM
> *To:* arin-ppml@arin.net
> *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
>
>
>
>

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

[Delacruz, Anthony B]

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
anthony.delac...@centurylink.com
ipad...@centurylink.com



From: ARIN-PPML [mailto:arin-ppml-boun...@arin.net] On Behalf Of John Santos
Sent: Tuesday, April 17, 2018 1:58 PM
To: arin-ppml@arin.net
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: cta...@tacitlaw.com<mailto:cta...@tacitlaw.com>

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 <jschil...@google.com><mailto:jschil...@google.com>
Sent: April 16, 2018 3:05 PM
To: Christian Tacit <cta...@tacitlaw.com><mailto:cta...@tacitlaw.com>
Cc: ARIN-PPML List <arin-ppml@arin.net><mailto:arin-ppml@arin.net>
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 th

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

[John Santos]

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: cta...@tacitlaw.com <mailto:cta...@tacitlaw.com>

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 <jschil...@google.com>
*Sent:* April 16, 2018 3:05 PM
*To:* Christian Tacit <cta...@tacitlaw.com>
*Cc:* ARIN-PPML List <arin-ppml@arin.net>
*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 <cta...@tacitlaw.com 
<mailto: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
<mailto:jschil...@google.com>>
*Sent:* March 15, 2018 4:29 PM
*To:* Christian Tacit <cta...@tacitlaw.com
<mailto:cta...@tacitlaw.com>>
*Cc:* arin-ppml@arin.net <mailto:arin-ppml@arin.net>
    *Subject:* Re: [arin-ppml] Draft Policy 2017-

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

[Christian Tacit]

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: cta...@tacitlaw.com<mailto:cta...@tacitlaw.com>

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 <jschil...@google.com>
Sent: April 16, 2018 3:05 PM
To: Christian Tacit <cta...@tacitlaw.com>
Cc: ARIN-PPML List <arin-ppml@arin.net>
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 
<cta...@tacitlaw.com<mailto: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<mailto:jschil...@google.com>>
Sent: March 15, 2018 4:29 PM
To: Christian Tacit <cta...@tacitlaw.com<mailto:cta...@tacitlaw.com>>
Cc: arin-ppml@arin.net<mailto:arin-ppml@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 
<cta...@tacitlaw.com<mailto: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

Re: [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 <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:* arin-ppml@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 <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/reall

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

[Christian Tacit]

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: arin-ppml@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 
<cta...@tacitlaw.com<mailto: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
- 

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

[Jason Schiller]

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 
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
___
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 

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

[Owen DeLong]

> On Mar 13, 2018, at 11:54 , Scott Leibrand  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,  > 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, 

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

[Scott Leibrand]

Oh, I forgot to mention, I support the proposal in principle and as written.

Thanks,
Scott

On Tue, Mar 13, 2018 at 1:11 PM, Brian Jones  wrote:

> I support draft proposal 2017-12. It is a good step forward for POC
> validation.
>
> --
> Brian
> ​ E Jones
> Agile Process Engineer
> ​Virginia Tech​
> ​
>
> On Mon, Mar 12, 2018 at 5:47 PM, 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 (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.
>>
>
>
> ___
> 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.
>
___
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.

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

[Brian Jones]

I support draft proposal 2017-12. It is a good step forward for POC
validation.

--
Brian
​ E Jones
Agile Process Engineer
​Virginia Tech​
​

On Mon, Mar 12, 2018 at 5:47 PM, 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 (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.
>
___
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.

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

[Scott Leibrand]

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?

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...

-Scott

On Tue, Mar 13, 2018 at 11:07 AM,  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 (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 

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

[hostmaster]

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 (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.

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

[Christian Tacit]

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.