ietf-asrg
[Top] [All Lists]

[Asrg] Back to the charter

2003-03-05 18:48:26
I'm finding the large amount of discussion, albeit interesting,
also depressing, as it doesn't seem directed towards making
progress.  So let me try to get back to the earlier question
concerning the charter:

1. On the use of "Consent-Based Communication" 

The charter begins by arguing that spam is not well-defined,
and therefore moves to generalize the problem with consent-
based communications.  Let me first observe that based
on the discussion here, the definition of consent and consent-
based communication isn't clear enough.

In engineering, when a problem seems intractable, it's certainly 
a legitimate strategy to consider a different problem, as is 
being done here.  But then, unless the original problems falls 
out (as is frequently but not always the case), we must compare 
the original problem to the problem being solved.

In this case, my initial reaction was that consent-based
communication was sufficient but not necessary.  That is,
such a system could significantly address the underlying
problem, but as defined, is more general than is necessary
(at least by any obvious necessity).  But then, it occurred to
me that the approach is really just obscuring the original 
problem.  

My first take on "Consent Expression Component" was that it
was merely the mechanism to communicate my policy to the
software.  We still need a way to identify policies - and
that means coming up with some sort of meaningful definitions
for spam.  The trick is doing so, without forcing a single
definition of spam down everyone's throat.

2.  A framework for classifying definitions of spam:

So let me propose a framework:  Spam, as indicated in the
charter, is loosely defined as unwanted email.  Within that
set, there are a number of very large categories.  The 
categories are not exclusive (they may overlap), nor do
they necessarily cover the entire space (some may slip through).

Some categories are defined intuitively, e.g. "unsolicited,
commercial, bulk".  Others are defined formally, e.g. mail
for which the From field specifies a non-existent domain 
(ignoring issues of DNS reliability and timing windows).
Sometimes there will be a relationship between an intuitive
definition and a formal one; the relationship may be perfect,
or it may have holes (false positives or negatives).  The
closeness of a formal definition to an intuitive definition
is one particular measure of quality for that formal
definition.

At this point in time, arguing about the appropriateness of
any particular category (whether intuitive or formal) is 
inappropriate.  Rather, the point is to establish the structure
in which those categories can be documented and analyzed.

3.  Legal issues

The statement about legal issues limits the investigation to
the extent that legal issues affect the technology.  This needs
to be "and vice versa", i.e. should also consider the extent
to which the technology affects the legal issues.  In particular,
it is a legitimate question to ask whether the technology can
and should play a role in aided the encorceability of legal
sanctions, e.g. can and should the technology make it easier to 
find someone who violates an anti-spam law.

4.  Social issues

The charter is silent on the effect on social (and political) issues.  
The discussion here suggests that these are extremely important to
some number of people.  I'm not convinced that adding such issues
to the charter would be a wise move, but in the interest of 
completeness and fairness, I feel the need to point it out.

5.  Premises or Constraints

The charter say very little about the premises or constraints
of what falls within its scope.  The current set of discussions 
indicates that many people are working under the premise that 
existing (low-level) functionality must not be changed, or other
assumptions about approaches that would be out of bounds.  

Since this is a research group, I believe it important to do
away with preconceived notions about limits.  I also believe
it important to be explicit about this - precisely to avoid
ratholes.  In particular, proposed solution should not be
rejected a priori solely on the basis of change of functionality, 
but should be evaluated according to the same criteria mentioned
in the charter (usefulness, cost, effectivness, accuracy, etc.)

Furthermore, individual subsolutions should be evaluated in the 
context of a complete solution strategy.  In particular, if
one part of a solution breaks existing functionality, but that
purposes served by that functionality can be served by other,
new functionality,  then rather than dismissing the subsolution,
the entire solution, including the replacement of existing
functionality should be evaluted.  (Implicit in this is that
we also don't jump to a priori conclusions concerning the cost
of replacing functionality, but rather evaluate such costs 
seriously.)

I'm sure some won't agree with the above specifics.  Regardless
of the actual specifics chosen, I believe that such high-level
constraints should be clearly identfied early on and documented,
either in the charter or elsewhere.

Gary



_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg



<Prev in Thread] Current Thread [Next in Thread>