A C/R system is one of the tools that fit into the model.
At 11:01 AM 7/7/2003 -0400, Eric Dean wrote:
Further defining taxonomy and models are always of value to a research
group.
How does this differ from a challenge/response system?
> -----Original Message-----
> From: asrg-admin(_at_)ietf(_dot_)org
[mailto:asrg-admin(_at_)ietf(_dot_)org]On Behalf Of Yakov
> Shafranovich
> Sent: Friday, July 04, 2003 5:54 PM
> To: bob(_at_)wyman(_dot_)us; 'Paul Judge'; asrg(_at_)ietf(_dot_)org
> Subject: RE: [Asrg] 4. Survey of Solutions - Consent Model
>
>
> I am thinking of reformatting the document along the lines of RFC 2778
> which defines a model for instant messaging. Tell me what you think.
>
> Yakov
>
> At 01:50 PM 7/4/2003 -0400, Bob Wyman wrote:
>
> >Yakov Shafranovich wrote:
> > >I wrote up an document on the consent model
> > I think it would be good to strip from the document the general
> >discussion of the spam problem and focus on the technical framework. One
> >can assume that the nature of the problem is well understood -- the
> >"evils" of spam are well-known problems. As it stands now, the
> >discussion of motivation for the proposal simply makes the document much
> >larger without really adding much.
> > Also, while I would certainly include a short (one-paragraph?)
> >section on motivation and ensure that the paragraph mentions spam, I
> >think the document should focus on "consent" not "spam." Ideally, spam
> >would only be explicitly mentioned in a short description of motivation.
> >The rest of the document should only talk about consent. The challenge
> >of the document is to define how consent is expressed and managed. Such
> >a framework can have value dealing with more problems than simply
> >providing part of a solution to the spam problem.
> > In general, I think it is not useful to quote other documents at
> >length. Given hypertext, we're able to easily and effectively reference
> >other documents without burdening every document with large extracts of
> >others. Ideally, the consent framework would be a concise description
> >where every line had value on its own and wasn't simply a repetition of
> >data found elsewhere. The simpler the document is, the easier it will be
> >for people to understand it and evaluate it.
> > I think there are some labeling problems in the current
> >document. For instance, a "lookup in a realtime black list" is not a
> >"policy enforcement mechanism." Rather it is a means for determining
> >some attribute of a message which can then be fed into the policy
> >enforcement mechanism. (i.e. Message has the "sent from blacklisted
> >node" attribute. Thus, the enforcement mechanism -- which is distinct
> >from the mechanism that did the blacklist lookup -- decides to reject
> >the message or put it in a graybox.) The same comment applies to most of
> >the other things mentioned in this section. They are all means to
> >discover attributes of a message -- it is only anecdotal that most
> >implementations of these methods are bound to specific enforcement
> >policies. The framework should clearly identify the distinctions between
> >components of a system.
> >
> > bob wyman
>
>
> _______________________________________________
> 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
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg