ietf
[Top] [All Lists]

Re: Categorization of TCP/IP service provision types

2004-03-23 08:56:10
From: John C Klensin 

...
What I see missing are hints why "dynamic addresses" are widely
blacklisted.  There need to be words about the first three
classes usually being priced so low that providers cannot

...
Text would be welcome, but it seems to me that this addresses a 
different theme.  One could say that quality of customer service 
usually improves with categories, but that isn't universally 
true until one starts making categories of customer service 
efforts.  From my experience, I would even question your 
description above, although we don't disagree about the 
consequences: my impression is that a number of the "broadband" 
operators offering low-end services actually have fairly good 
logs.  What they don't have are abuse departments with the will 
and resources to dig through those logs and identify specific 
offenders.  Hand that same provider a subpoena associated with, 
e.g., some clearly criminal behavior, and records seem to turn 
up in a lot of cases.

That's all true.  The details of the reasons and excuses for not
dealing with abuse except when coerced by lawyers or badges vary
and are not germane.


What I've done in response to several comments is to add text to 
the beginning of the terminology section that tries to make it 
clear that these definitions are about what the provider intends 
to offer.  Whether the restrictions are imposed by AUP (or 
contractual terms and conditions) and whether technical means to 
enforce particular restrictions are effective on a particular 
day seems less important.

exactly.

The "dynamic address" issue is, from that point of view, just a 
"technical means" to enforce (or just consistent with) an AUP or 
Ts and Cs.  I.e., if one believes that blacklisting dynamic 
addresses is rational, then part of the reason for that isn't 
"too cheap" or the addresses themselves, it is that these 
dynamic addresses tend to show up only in "server prohibited" 
environments.   Maybe it is equally rational to blacklist an 
address range on the theory that anything coming from that range 
is in violation of provider conditions of service and that one 
bad deed (violating AUPs or Ts and Cs) is as bad as another 
(demonstrated spamming).   But I don't see a reasonable way to 
incorporate any of that reasoning (whether one agrees with it or 
not) into the document without generally weakening it.  If you 
do, please suggest text.

No, the rational reason to blacklist "dynamic" addresses is that
blocking them stops a lot of abuse while affecting very little legitimate
traffic.  Whether the high true positive and low false positive rates
are because providers choose to ignore complaints or some other reason
is, or needs to be irrelevant in this document.

Perhaps it would be enough to say just that, along the lines of

  ... mail directly from the IP addresses of customers of X instead of
  via MTAs run by service providers is rejected by much of the rest
  of the Internet because it is almost certainly "spam" or otherwise
  objectionable.  The terms of service of X usually require the use
  of MTAs operated by the service provider and prohibit the operation
  of MTAs at the customers' IP addresses.  Practically all legitimate
  mail from users of X use their service providers' MTAs.  Some service
  providers use technical mechanisms such as "port 25 filtering" to
  enforce their terms of service that require that their customers'
  mail use the providers' MTAs.

   ("X" because I'm not sure about factoring that text into each
   of the 1st three descriptions or having it one place.)


Thanks.  I've started a discussion with some selected ADs about 
what they want to do with this, if anything.  My intent is to 
wait to see what they have to say.  If they aren't interested, 
and interested in moving toward BCP, then the effort is, as far 
as I'm concerned, dead.  If they want a WG, then the next real 
task is "charter".  Otherwise... well, let's how they want to 
proceed.

That sounds right to me.


Vernon Schryver    vjs(_at_)rhyolite(_dot_)com