Re: [Asrg] 8a. Evaluation Model - Technical Considerations Document

Just a reminder to everyone - the technical considerations document is 
one of the foundational documents for the group, and it is important for 
us to get it done. Please participate in the discussions or if you're 
shy contact us off-list :)
Yakov

> Yakov Shafranovich wrote:
>
> > > The technical considerations document has been available for some 
> > > time at:
> > > http://www.ietf.org/internet-drafts/draft-crocker-spam-techconsider-02.txt 
> > >
> > > This document outlines some of the most important underlying assumptions
> > > for proposals and evaluation of proposals.  We would like to jump start
> > > a discussion on it, to move it towards the next draft. Please review the
> > > document and post your comments, questions, concerns to the list.
>
> I wanted to add some points and thoughts, and hope that all of you will 
> contribute as well.
> 1. What is the intent of this document? It is titled "Technical 
> Considerations" however tt seems that the document includes aside from 
> general considerations, also a discussion on available points where 
> control can be placed, standards opportunities and an evaluation model 
> (towards the end). Perhaps the title of the note should be changed, or 
> the document should be split up into several smaller ones (for 
> standards, for evaluation, etc.).
> 2. In section 1 of the document, there is a considerable discussion as 
> to what the definition of spam is. However, the charter states that:
> <snip>
>     The definition of spam messages is not clear and is
>     not consistent across different individuals or
>     organizations. Therefore, we generalize the problem into
>     "consent-based communication".
> <snip>
>
> The intent of the charter seems to stay away from defining spam. 
> Additionally, section 1 is title "spam and consent" but does not go into 
> a discussion about consent. Perhaps this section can be synced with the 
> charter or with the consent framework 
> (http://www.solidmatrix.com/research/asrg/asrg-consent-framework.html). 
> Additionally, perhaps importance of an overall framework or model for 
> anti-spam tools such is the consent framework needs to be mentioned.
> 3. In section 2.1 during the discussion of control points, the 
> discussion stops at originator's MTA (MTA.o). First of all, a bit more 
> discussion can be spent on the MTA.o especially if it is controller by 
> the spammers, and also discussion is needed on points of control at 
> MTA.i, MTA.r, and UA.r which are on the side of the ISP or the receiver. 
> Even though it is preferable to have control closer to the source of the 
> spam, nevertheless many anti-spam tools operate on the receiver's side.
> 4. In section 2.2.1 several types of evalutions are given: originator, 
> content, destination and traffic. What about consent, should we be 
> evaluating whether the sender has consent to send email to the receiver 
> in line with the charter?
> 5. Section 2.2.1 also states "The other avenue is post-hoc removal of 
> the right to make further use of the MTA service." What about post-hoc 
> removal of network access?
> 6. In section 2.2.3, 2.2.4 and 2.2.5 examples are given with a filter. 
> Are these sections refering only to detection with filters, or any 
> anti-spam tool? If later, then it should be mentioned.
> 7. Additionally the entire section 2.2 seems a bit strange. It starts 
> off with four foci of evaluation yet proceeds to go into explaining one 
> of them and defining additional terminology. More clarification and 
> organization in this section is needed.
> 8. Section 3, approached to controlling spam and the taxonomy of 
> anti-spam systems 
> (http://www.irtf.org/asrg/draft-asrg-taxonomy-anti-spam-systems.txt) 
> need to be synced. The research agenda also needs to be synced with this.
> 9. Section 3.1, administrative and legal approaches - should a note be 
> made that the document addresses mainly technical approaches?
> 10. Section 3 needs to be reorganized. It includes four approaches - 
> legal/admin, infrastructure, filtering and negotiation. However, some 
> approaches are placed in the wrong section - for example replacing SMTP 
> is within infrastructure not filtering. DNS-based approaches and 
> network-wide spam detection approaches are not mentioned in the 
> infrastructure either, while a lot of discussion is spent on filtering. 
>  Collaborative filtering is not mentioned, and many other proposals and 
> approaches are missing. Additionally, the filtering section needs to be 
> re-organized better and re-written to be more clear.
> 11. The entire evaluation section (section 4) and the requirements 
> document 
> (http://www.irtf.org/asrg/draft-irtf-asrg-requirements-xx-01.txt) need 
> to be coordinated and synced.
> Yakov
>
>
> _______________________________________________
> Asrg mailing list
> Asrg(_at_)ietf(_dot_)org
> https://www1.ietf.org/mailman/listinfo/asrg


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