Subject: [domainrep] Topics for IETF Repute wg meeting

From: Dave Crocker <[email-masked]>
Date: Mon, 12 Mar 2012 09:28:38 -0700

Folks,

Happy Monday.

The Repute wg meeting during IETF week will be Wednesday, 28 March, 1-3pm. 16 
days away...

What shall we discuss?

    What issues are pending that you believe we can resolve with a face-to-face 
meeting?

    What issues should be raised that we are likely to make progress on with a 
f2f meeting?  For these, /please raise them in a separate thread/ with a new 
Subject line, so that we can treat them as new topics and start discussing them 
before the meeting?

    What else should be discussed?

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 14 Mar 2012 18:33:45 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave Crocker
> Sent: Monday, March 12, 2012 9:29 AM
> To: [email-masked]
> Subject: [domainrep] Topics for IETF Repute wg meeting
> 
> What shall we discuss?

A brief overview of each of the documents' content and states might be good.  They've all changed since Taipei.  Each of them might lead into some of the topics below.  There are some things we talked about in Taipei that haven't been revisited on the list yet, such as the complexity forced on clients by using the URI template scheme.

I think we could spend some time bashing around the JSON/XML question again.  This has come up in a few related areas lately, including the nascent WEIRDS work, so we could review and use some of their arguments, or we could do a good job and let them use ours.  I can talk briefly about my experience converting my implementation from XML to JSON to see if it would help answer this question, but there's not that much to say at least from my own perspective.  There might be other comments to consider, however.

A review of the newly-revised model document would be helpful, to see if there are things we want to change before progressing it.

We should talk about the final deliverable:  "Informational document, discussing issues of data transparency, redress, meta-reputation and other important operational considerations, to the IESG for publication."  If we don't actually want to start that now and find an editor, we might at least collect input to act as a starting point to such work.  A lot of things on this topic were brought up during the BoF in Quebec City (in fact, most of our time was spent on this), so the minutes from that would also be a good source of input.

Some older issues that we've tabled, but could be revisited:
	- do we need a lightweight protocol?
	- if so, DNS?  CoAP?  A new UDP thing?

-MSK

---

From: Steve Allam <[email-masked]>
Date: Fri, 23 Mar 2012 08:01:12 +0000

Murray,

 From my side, I still see some mileage in a lightweight repute scheme, 
of course I am biased, and we already used both  HTTP and DNS based 
reputation queries.  Therefore, I am biased towards DNS in preference to 
other CoaP, UDP approaches.  On the other hand, there are already a 
number of definitions for DNS based reputation services, IP block/white 
lists, domain lists etc - which are all providing reputation - are these 
going to be wrapped up into the repute model, or left alone?  The latter 
I expect.

The DNS lookup we do basically takes a sender and a domain, concatenates 
them, MD5 hashes them and forms a DNS query, such as:

   {md5-string}.{custkey}.{service-uri}

At the time, the whole concat - MD5 mechanism was used to ensure (some) 
privacy of data, whilst making it possible to still use a standard 
RWL/RBL lookup mechanism within an MTA.  Clearly for our HTTP reputation 
lookup, we have had to build connectors for all major MTAs, requiring 
work on our side, and integration work on the customer side.  The 
requirement for integration work has thwarted one customer who simply 
would not add extensions to their MTA set-up.

Making use of the standard RWL mechanism enabled us to leverage exiting 
functionality in some MTAs - clearly some are not capable of MD5 hashing 
before doing a lookup, but it got us part way there.  By contrast, the 
HTTP lookup has required connectors to be written to all but two of the 
MTA's we use (and one of them Murray, belongs to 
Cloudmark...thanks...err. Bizanga, exim being the other).

So, in summary - maybe a lightweight protocol in fact isn't required, 
because it's too late?
Or maybe, when looking at what to use, DNS can be used to leverage 
existing MTA functionality?
Or, maybe, REPUTE will look beyond email, and so MTAs don't matter - 
however, that doesn't negate DNS as a delivery mechanism for reputation 
data; already having mechanisms to distribute zone files and 
applications to serve them effectively.

Regards,

Steve

On 14/03/2012 6:33 PM, Murray S. Kucherawy wrote:
> _______________________________________________
> domainrep mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/domainrep

-- 
*
Steve Allam | * Chief Technology Officer *| TrustSphere *

3 Phillip Street, #13-03 Commerce Point, Singapore, 048693
Tel: +65 6536 5203 | Fax: +65 6536 5463
[email-masked] | www.trustsphere.com