Subject: [domainrep] Reputation information data which flows from a reputation client to a reputation provider

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Tue, 09 Aug 2011 22:21:01 +0200

Hi, all,

one of the milestones in the REPUTE charter is:

     mmm yyyy:      Standards track document, defining mechanisms
             for sending data to reputation providers, to the
             IESG for publication.

I suppose 'sending data to reputation providers' is the feedback 
mechanism discussed previously on this list? If so, I'd like this to be 
explicitly mentioned as 'sending feedback data'. So let's make this:

     mmm yyyy:      Standards track document, defining mechanisms
             for sending feedback data to reputation providers, to the
             IESG for publication.

The reason for making this more explicit, is that there can be multiple 
types of data that can/will be sent to reputation providers. The charter 
mentions query mechanisms for reputation clients to retrieve information 
from reputation providers, but in my view we should not restrict the 
reputation information flows to just 'queries' and 'feedback'.

To give a few examples of other types of reputation information data flow:

    * at the end of the day there can and will be multiple reputation
      providers, some of them may want to exchange/interchange/share
      (part of) their reputation information with others
    * or it is possible a single provider of reputation has a mesh of
      reputation servers, which communicate with each other using a
      reputation protocol. This will not be restricted to one-way
      traffic, it will require a mechanism that supports reputation
      information flows in both directions.
    * another scenario can be, that reputation providers build
      reputations from data/information that will be provided by
      thousands or millions of clients, which need to be able to
      communicate a unit of reputation from client to reputation provider
    * as far as I know there are providers of RBLs/DNSBLs data which
      pushes complete DNS zones using zone transfers to customers. We
      will probably something equivalent for REPUTE, but not restricted
      to simple DNS zone transfers

Or is this meant with the charter section?:

     "The group will also produce specifications for providing source data
     into to a reputation service."

I suggest we spend some (more) words on this type of data flow and add 
and extra document on the milestone agenda:

     mmm yyyy:      Standards track document, defining mechanisms
             for sending reputation data to reputation providers, to the
             IESG for publication.

If there is consensus that such a document is in scope and that it 
should be part of the document output of this WG, I volunteer to work on 
this document.

For the remainder of the charter: WFM.

/rolf

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 9 Aug 2011 13:31:30 -0700

Hi Rolf,

My intent there was to constrain the charter to talk about how a single end-point reports reputation data back to a server that aggregates it, such as an end user clicking a "report spam" button that provokes a message back to the reputation server.  This is partly because it's obviously something needed, and partly because the work is already half done for us in the form of what Mimedefang uses (plus some undocumented commercial versions of the same thing, so there exists a body of knowledge about it).

My feeling is that it would be fairly ambitious to talk about how reputation data providers exchange data amongst themselves in a first go.  The work in the charter now, which focuses only on producer-consumer protocols and formats, and maybe how events are reported into a reputation system, is a big enough slice even though we've constrained the initial output to focus on email domain reputation.

That said, this is prime material for a potential re-charter after the initial work is done, along with a possible second application like reputation about reputation providers, or reputation about WHOIS registries.  We can see what the working group has momentum for when that day comes.

As for your milestone tweak (i.e., change "sending data" to "sending feedback data"), it looks fine to me.

Thanks,
-MSK

From: [email-masked] [mailto:[email-masked]] On Behalf Of Rolf E. Sonneveld
Sent: Tuesday, August 09, 2011 1:21 PM
To: [email-masked]
Subject: [domainrep] Reputation information data which flows from a reputation client to a reputation provider

Hi, all,

I suppose 'sending data to reputation providers' is the feedback mechanism discussed previously on this list? If so, I'd like this to be explicitly mentioned as 'sending feedback data'. So let's make this:

The reason for making this more explicit, is that there can be multiple types of data that can/will be sent to reputation providers. The charter mentions query mechanisms for reputation clients to retrieve information from reputation providers, but in my view we should not restrict the reputation information flows to just 'queries' and 'feedback'.

 *   at the end of the day there can and will be multiple reputation providers, some of them may want to exchange/interchange/share (part of) their reputation information with others
 *   or it is possible a single provider of reputation has a mesh of reputation servers, which communicate with each other using a reputation protocol. This will not be restricted to one-way traffic, it will require a mechanism that supports reputation information flows in both directions.
 *   another scenario can be, that reputation providers build reputations from data/information that will be provided by thousands or millions of clients, which need to be able to communicate a unit of reputation from client to reputation provider
 *   as far as I know there are providers of RBLs/DNSBLs data which pushes complete DNS zones using zone transfers to customers. We will probably something equivalent for REPUTE, but not restricted to simple DNS zone transfers

I suggest we spend some (more) words on this type of data flow and add and extra document on the milestone agenda:

If there is consensus that such a document is in scope and that it should be part of the document output of this WG, I volunteer to work on this document.

/rolf

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Wed, 10 Aug 2011 10:25:08 +0200

Hi, Murray,

On 8/9/11 10:31 PM, Murray S. Kucherawy wrote:
>
> My intent there was to constrain the charter to talk about how a 
> single end-point reports reputation data back to a server that 
> aggregates it, such as an end user clicking a "report spam" button 
> that provokes a message back to the reputation server.
>

OK. I suggest we'd add this text to that paragraph, in order to make it 
more clear, like:

    The group will also produce specifications on reporting reputation
    data from (a) single end-point(s) to a server, that aggregates it[,
    for example when an end user clicks on a 'report spam' button that
    provokes a message back to the reputation server].

The 'for example...' may not fit for a charter document, hence I put it 
in square brackets.

> This is partly because it's obviously something needed, and partly 
> because the work is already half done for us in the form of what 
> Mimedefang uses (plus some undocumented commercial versions of the 
> same thing, so there exists a body of knowledge about it).
>
> My feeling is that it would be fairly ambitious to talk about how 
> reputation data providers exchange data amongst themselves in a first go.
>

The internal data exchange of reputation providers is not my primary 
concern, indeed. My primary concern was that we should not limit the 
reputation model to be a model where there's only one-way traffic from 
provider to consumer.

> The work in the charter now, which focuses only on producer-consumer 
> protocols and formats, and maybe how events are reported into a 
> reputation system, is a big enough slice even though we've constrained 
> the initial output to focus on email domain reputation.
>

Given the 'nature' of reputation, it sure will prove to be a big enough 
slice ;-)

>
> That said, this is prime material for a potential re-charter after the 
> initial work is done, along with a possible second application like 
> reputation about reputation providers, or reputation about WHOIS 
> registries.  We can see what the working group has momentum for when 
> that day comes.
>

Agreed.

/rolf