<div dir="ltr"><div>> On Wed, Jul 26, 2017 at 3:24 PM, Owen DeLong <<a href="mailto:owen@delong.com">owen@delong.com</a>> wrote:</div><div><br></div><div>> > On Jul 26, 2017, at 07:20 , Michael Peddemors <<a href="mailto:michael@linuxmagic.com">michael@linuxmagic.com</a>> wrote:</div><div>> ></div><div>> > But, in keeping with your 'flippant' style, we do have some ISP's that aren't responsible for the traffic that happens on their networks too ;)</div><div><br></div><div>> Well… We have ISPs that fail to act responsibly about traffic that happens on their network. Saying they are not actually responsible is another </div><div>> question which I don’t necessarily agree with.</div><div><br></div><div>three points:</div><div>1. This proposal is not trying to address the problem of how ISPs handle abuse.</div><div><br></div><div>If that is a problem the community wants to tackle, lets define the problem </div><div>and propose policy in a DIFFERENT proposal</div><div><br></div><div>2. I do not believe the suggested changes impact how ISPs handle abuse.</div><div> </div><div>How ISPs handle abuse is orthogonal to this proposal.</div><div><br></div><div>3. How ISPs handle abuse is complicated and opaque and requires more</div><div>nuance and clarity about what is actually required for compliance.</div><div><br></div><div> </div><div>As is said before compliance tends to be very good when it is either </div><div>required, or beneficial to the organization.</div><div><br></div><div><br></div><div><div>If an organization is trying in good faith, to follow ARIN rules, then they </div><div>will try to keep SWIP information for their networks accurate, as well as </div><div>for their down stream customers.</div><div><br></div><div>There is no ARIN requirement that a provider need to process or respond </div><div>to abuse complaints on their network space, nor that they take action on </div><div>downstream customers who fail to process abuse complaints.</div><div><br></div><div>In some cases their are particular legal rules in particular countries that some </div><div>types of abuse complaints are required to be processed, for example legal take </div><div>down requests. I suspect you will find very high compliance in processing these </div><div>types of abuse complaints.</div><div><br></div><div>In other cases there are unwritten standards of conduct that when violated results </div><div>in a TOS agreement violation leading to loss of service. I suspect you will find a </div><div>wide mix in terms of what is permitted under various TOS (although generally it is </div><div>expected that the requirements are at least as strict for down stream customers) </div><div>as well as a wide mix on level of compliance in processing TOS abuse complaints.</div><div><br></div><div>In yet other cases, media agreements will contractually require DMCA violations to </div><div>be processed. These are often completed by a pre-defined process and not through </div><div>abuse@ email contact. These will also have a wide range of compliance directly </div><div>proportional to the strength of the contract and importance of the media agreement.</div><div><br></div><div>In yet other cases there is an unwritten standard of conduct that when violated results </div><div>in being published on a black list. This also has a wide mix in terms of what is needed </div><div>to be added and removed from the blacklist. Furthermore there is a wide mix of </div><div>corresponding behavior by blacklisted organizations from aggressively cleaning up </div><div>black listed space and maintain a positive reputation (and usable IP space for its </div><div>customers), to organizations that do not engage black listers. Often times innocent </div><div>customers are caught in the middle, and network abusers move on to new IP space </div><div>often with newly stolen credentials, with very little that well meaning providers can do </div><div>to prevent re-occurrence. </div></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jul 26, 2017 at 3:24 PM, Owen DeLong <span dir="ltr"><<a href="mailto:owen@delong.com" target="_blank">owen@delong.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On Jul 26, 2017, at 07:20 , Michael Peddemors <<a href="mailto:michael@linuxmagic.com">michael@linuxmagic.com</a>> wrote:<br>
><br>
> On 17-07-25 02:31 PM, Owen DeLong wrote:<br>
>>> On Jul 25, 2017, at 10:34 , Michael Peddemors <<a href="mailto:michael@linuxmagic.com">michael@linuxmagic.com</a>> wrote:<br>
>>><br>
>>> On 17-07-24 05:06 PM, Tony Hain wrote:<br>
>>>> I still don’t see any value in specifying length. What you are looking for is contact info for someone with a clue about how a given network works and using length as a really poor proxy. I could live with a fourth line:<br>
>>>> Any end network emitting SMTP system SHOULD provide SWIP.<br>
>>>> I just don’t know how that gets enforced in any reasonable way. In general SMTP & independent routing are the big targets needing accurate contact info, and length has absolutely nothing to do with either.<br>
>>>> Tony<br>
>>><br>
>>> While I agree in principle, it CAN be provided by "SWIP" OR 'rwhois', and that should be pointed out, as rwhois is more flexible in the IPv4 space, eg providing allocation information to the /32 level.<br>
>>><br>
>>> This again goes to an earlier email where I described that it should be more conceptual, than specific ranges..<br>
>>><br>
>>> It should be, "if a party is responsible for the originating traffic", then that party should be displayed via SWIP/rwhois.<br>
>> Well… That’s hard to implement in practice. How do we go about SWIPing all those home windows boxes to the hackers that are actually controlling the emitted traffic?<br>
>> Owen<br>
><br>
> I assume you were being flippant/joking. The person who should be contacted if the device is hacked in that case, would 'normally' be the ISP, unless the person notified the ISP that they were taking responsibility. (Same way as they now request a static IP address instead of dynamic)<br>
<br>
</span>Yes, Of course I was joking, but my point is that it really isn’t “the party responsible for originating the traffic” rather than “the closest knowledgeable party to the party responsible for the operation of the machine originating the traffic.<br>
<span class=""><br>
> But, in keeping with your 'flippant' style, we do have some ISP's that aren't responsible for the traffic that happens on their networks too ;)<br>
<br>
</span>Well… We have ISPs that fail to act responsibly about traffic that happens on their network. Saying they are not actually responsible is another question which I don’t necessarily agree with.<br>
<span class="HOEnZb"><font color="#888888"><br>
Owen<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
______________________________<wbr>_________________<br>
PPML<br>
You are receiving this message because you are subscribed to<br>
the ARIN Public Policy Mailing List (<a href="mailto:ARIN-PPML@arin.net">ARIN-PPML@arin.net</a>).<br>
Unsubscribe or manage your mailing list subscription at:<br>
<a href="http://lists.arin.net/mailman/listinfo/arin-ppml" rel="noreferrer" target="_blank">http://lists.arin.net/mailman/<wbr>listinfo/arin-ppml</a><br>
Please contact <a href="mailto:info@arin.net">info@arin.net</a> if you experience any issues.</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><font color="#555555" face="'courier new', monospace"><div><span style="color:rgb(0,0,0);font-family:arial"><font color="#555555" face="'courier new', monospace">_______________________________________________________<br></font><div><font face="'courier new', monospace">Jason Schiller|NetOps|<a href="mailto:jschiller@google.com" target="_blank">jschiller@google.com</a>|571-266-0006</font></div><div><font face="'courier new', monospace"><br></font></div></span></div></font></div>
</div>