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-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, duringthe
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
<mailto: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 <mailto:i...@arin.net> if you
experience any issues.
--
_______________________________________________________
Jason Schiller|NetOps|jschil...@google.com
<mailto:jschil...@google.com>|571-266-0006
--
_______________________________________________________
Jason Schiller|NetOps|jschil...@google.com
<mailto:jschil...@google.com>|571-266-0006
_______________________________________________
PPML
You are receiving this message because you are subscribed to
the ARIN Public Policy Mailing List (ARIN-PPML@arin.net).
Unsubscribe or manage your mailing list subscription at:
http://lists.arin.net/mailman/listinfo/arin-ppml
Please contact i...@arin.net if you experience any issues.
--
John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539
_______________________________________________
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.
