The Session Initiation Protocol (SIP) and Spam
draft-ietf-sipping-spam-05

This is an important document and I believe it would benefit the
community to have this published soon.

However, this document repeatly makes the mistake of being too
authoritative in an area which is more of a research problem space.  As
a result, it includes several statements that are factually incorrect or
execessively authoritative.  This weakens the document significantly. I
recommend one editing pass to try to at least fix the factual errors.


The first problem I noticed was this:

"   a plague on the Internet email system, rendering it nearly useless."

The phrase "rendering it nearly useless" is a factual error.  Spam has
done a great deal of damage to the Internet mail system -- made it
_much_ more expensive to run, it has made it annoying, it has swaped
solicited/desired traffic with unsolicited/undesired traffic, and it has
basically destroyed the robustness principle.  But it has not made email
"nearly useless".  Starting this document with a false statement greatly
weakens an otherwise interesting analysis.

Other factual errors:

  "These kinds of consent-based systems are used widely in presence and
   IM but not in email."

Factually incorrect -- most email mailing lists use consent-based systems, including IETF mailing lists.

   "This is likely due to the need for a secure
   authenticated identity mechanism, which is a pre-requisite for this
   kind of solution."

Email mailing lists provide a consent-based mechanism without a secure authenticated identity mechanism.  They leverage the fact that it is quite difficult to intercept mail destined for a specific address.

   "Email does not have this kind of secure
   domain identification, although new techniques are being investigated
   to add it using reverse DNS checks (see below)."

What about RFC 4871?

   "In email, there are no standards established for
   securely identifying the identity of the sending domain of a message."

RFC 4871 is such a standard.  Also SMTP STARTTLS could be used for inter-domain transfers (although deployment of the key infrastructure is likely impractical for this purpose at the moment).



I also think it's very easy to fall into pitfalls when talking about
spam absent an attack tree analysis of spamming.  An attack tree looks
at what kinds of spammers are out there and what their motivations are. 
I would put 3 nodes under the root of the spam attack tree:
"pranksters", "commercial" and "organized international crime".  Under
"commercial", we have in-house and out-sourced UBE sub-nodes.  An
important sub-node of the organized international crime node is phising
(very profitable and thus largely immune to costs).  The anlaysis in
this document applies well to the in-house sub-node of the commercial
node.  The analysis starts to fall apart on some of the other nodes in
the attack tree.

Examples of text which is too authoritative:

 "As a result, the problem of forged senders can be eliminated, making the
  white list solution feasible."

The problem may be largely addressed, but it's not eliminated as there are always attacks that work (as a last resort, social engineering or coersion of
the identity the attacker is forging).

  "Fortunately, it is possible to apply traditional content
   filtering systems to the header fields in the SIP messages, thus
   blocking these kinds of consent requests."

Content filtering only partially blocks such requests.  

  "Thus, if consent is required first, and nearly all users do not give consent
   to spammers, the value in sending spam is reduced"

This varies based on the node in the attack tree, while true for commercial
spam this is much less true for phishers.

  "One way to prevent spam is to make your address difficult or impossible to
   gather."

This is a way to _reduce_ spam, not prevent it.

   "This technique has the potential to truly make it prohibitively
   expensive to send spam of any sort."

It depends on how profitable the spam product happens to be.  In the case of phishing, I doubt this statement is true.

  "Since spam is a consequence of untrusted domains and users that get
   connected to the network,"

Spam can be a consequence of a _trusted_ user who manages their Windows machine poorly. ;-)

> magntiude cheaper to send than traditional circuit-based telemarketer

Typo