[arin-ppml] Policy Proposal: Customer Confidentiality

[Kevin Kargel]

> -----Original Message-----
> From: Kevin Stange [mailto:kevin at steadfast.net]
> Sent: Tuesday, June 09, 2009 1:31 PM
> To: Kevin Kargel
> Cc: arin ppml
> Subject: Re: [arin-ppml] Policy Proposal: Customer Confidentiality
> 
> Kevin Kargel wrote:
> > I am in general opposed to this proposal.  There are good and valid
> reasons
> > for making direct contacts for a network discoverable.  If a host runs
> amok
> > and is causing grave problems then I need to be able to contact the
> person
> > responsible for that host.  I do not need to find a contact for someone
> > three tiers up who will contact someone else who will contact someone
> who
> > will contact the host owner.
> >
> 
> Many of our customers would be slow to respond or unsure how to handle
> direct contact, which is one of the reasons I like this proposal.  Even
> when we direct such queries downstream from time to time, we get back a
> "what do I do with this?" response and basically end up having to deal
> with the issue ourselves.  If there's a suitably insane issue going on
> with a customer's machine, contacting us directly can result in
> immediate resolution where it might take hours to days contacting the
> customer directly.  We have the power to shut down VLANs, issue null
> routes, and sometimes just directly access machines to resolve issues.
> Chances are that we know a better way to get in touch with the customer
> faster that may not be something rwhois would generally contain such as
> an IM screen name or alternate phone number or email account, or that
> the customer is noted in our system to be away on vacation for 6 weeks
> and wants us to shut down a box in the event of anything seriously wrong.
> 
> Having centralized contacts gives us a filter, so we can block out
> useless contact to our customers and keep track of what kind of strange
> things our customers are doing with their IPs, intentionally, or
> inadvertently, so that we can handle abuses and keep in touch with
> customers to provide guidance.
> 
> That said, as it stands now, most abuse reporters just contact us
> directly anyway, even if rwhois specifies to contact someone else, so I
> don't expect much to change in this regard anyway.

I would agree that in the best possible world the abuse contact would be
someone who could do something about the issue.  In the real world this is
seldom the end user.

In the case of an ISP they are often the best PoC because they are in a
position to stop routing of a problem host.  In an enterprise network that
would be the NOC center for the aggregate router.  In this case it gets more
confusing because a single network may be distributed amongst several NOC's,
each of which has their own administration and routing policies.

In any case though, this contact "should" be a monitored live person
reachable contact who can directly manage the network in question.  At the
very least the PoC should be one phone call removed from that administrator.

Leaving the PoC as the top level ISP could put contact with an effective
administrator a number of tiers away, and could engender a situation where
resolution of an immediate issue is days away.

Filtering customers from abuse contacts is not a good thing.  If customer
networks are exposed directly to the internet then the customer needs to
have capable administrators on staff or under contract and those
administrators must be reachable.  

Expecting reasonable responsibility is not unreasonable.  Vehicle drivers on
public roads are or should be required to have the knowledge, resources and
skills to operate a vehicle. Network operators on public networks should
likewise be expected to have the knowledge, resources and skills to operate
a network.

I am not saying the PoC needs to be the customer, I am saying the PoC should
be a cognizant administrator or administration center.


> 
> 
> --
> Kevin Stange
> Chief Technology Officer
> Steadfast Networks
> http://steadfast.net
> Phone: 312-602-2689 ext. 203 | Fax: 312-602-2688 | Cell: 312-320-5867

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3224 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20090609/fc992fe4/attachment.bin>