Re: [domainrep] Charter going to the IESG

[Andrew Sullivan <[e-mail]>]

>From the subscribed address this time: I have read this.  Like the
previous drafts, I am ok with it.  I plan to review things.  (I am not
at all convinced that the DNS is a good fit for this, and I have
particular reservations about the mechanism proposed, but I think that
is a discussion for the WG to have once it has a charter.  That topic
should definitely be in.)

A

On Tue, Sep 06, 2011 at 03:15:47PM -0700, Murray S. Kucherawy wrote:
> Hi all,
> 
> Some further charter adjustment has been made in conversation with the advising AD, potential co-chairs, Nathaniel and myself.  The latest version is attached.  It is substantively the same as what you've already seen but nails down a few points while sticking to the feedback that's been sent to the list recently.
> 
> It would help the cause if, once again, people gave it a once-over and indicated they read this particular version, and made some indication of what role they intend to play as the work progresses (document editor, document reviewer, co-chair, implementer, etc.).  The IESG will be discussing it on Thursday (two days from now) so it's important to get as much of such feedback as is possible by then.
> 
> I remain dedicated to being in any or all of those roles except for co-chair, since I'm too close to the material to be able to be effective in that role.
> 
> Thanks for your patience as the process rumbles along.
> 
> -MSK

> Working Group Name:
> 	Reputation Services (REPUTE)
> 
> IETF Area:
> 	Applications Area
> 
> Chair(s):
> 	TBD
> 
> Applications Area Director(s):
> 	Pete Resnick <[e-mail]>
> 	Peter Saint-Andre <[e-mail]>
> 
> Applications Area Advisor:
> 	Pete Resnick <[e-mail]>
> 
> Mailing Lists:
> 	General Discussion: [e-mail]
> 	To Subscribe:	    https://www.ietf.org/mailman/listinfo/repute
> 	Archive:	    http://www.ietf.org/mail-archive/web/repute/
> 
> Description of Working Group:
> 	In the open Internet, making a meaningful choice about the handling
> 	of content requires an assessment of its safety or "trustworthiness".
> 	This is based on a trust metric for the owner (identity) of an
> 	identifier associated with the content, to distinguish (likely)
> 	good actors from bad actors.  The generic term for such information
> 	is "reputation".  This working group will develop mechanisms for
> 	reputation reporting by independent services.  One mechanism will be
> 	for a basic assessment of trustworthiness.  Another will provide a
> 	range of attribute/value data that is used as input to such an
> 	assessment.  Each service determines the attributes it reports.
> 
> 	Various mechanisms have been developed for associating a verified
> 	identifier with email content, such as with SPF (RFC4408) and DKIM
> 	(RFC4871).  An existing reputation query mechanism is
> 	Vouch-by-Reference (RFC5518). It provides a simple Boolean
> 	response concerning a domain name used for email.  The current working
> 	group effort will expand upon this, to support additional
> 	applications -- such as Web pages and hosts -- and a wider range of
> 	reporting information.
> 
> 	Given the recent adoption of domain name verification for email,
> 	by SPF and DKIM, the most obvious initial use case for reputation is
> 	for email.  Inbound email filters that perform message authentication
> 	can obtain a verified domain name and then consult a reputation service
> 	provider to make a determination (perhaps also based on other
> 	factors) of whether or not the content is desirable and take
> 	appropriate action with respect to delivery, routing or rejection.
> 	
> 	Another possible use case is identity-based evaluation of web
> 	content using technologies such as the DKIM-derived DOSETA
> 	(work in progress).
> 
> 	This working group will produce specifications for:
> 
> 	   * the detailed requirements for reporting
> 
> 	   * an end-to-end system architecture in which reporting occurs
> 
> 	   * the mechanisms and formats for reporting
> 
> 	Two mechanisms are under consideration:
> 
> 	   * simple -- a reputation is expressed in a simple manner,
> 	               via records in the DNS
> 		       (see draft-kucherawy-reputation-query-dns)
> 
> 	   * extended -- a response can contain more complex information
> 		         useful to an assessor, reported over HTTP using
> 	                 an encoding such as XML or JSON
> 		         (see draft-kucherawy-reputation-query-http)
> 
> 	The syntactic and semantic aspects of mechanisms and formats will be
> 	designed to be application-independent and portable (i.e., reputation
> 	provider-independent).  By distinguishing reporting information
> 	(format) from reporting mechanism (channel), the specifications
> 	will permit adaptation to support reporting through additional
> 	channels.  Limited application-specific tailoring will be
> 	provided for email, to demonstrate the approach, which can be
> 	applied for supportting additional applications.  The design and
> 	specification will also permit adaptation to support reporting
> 	through additional transport channels.
> 
> 	Items that are specifically out of scope for this work:
> 
> 	   * Specific actions to be taken in response to a reputation reply.
> 	     It is up to assessors (i.e., the consumers of reputation data)
> 	     to determine this.  Non-normative illustrations, however, can
>              be included to demonstrate possible uses of reputation data
> 	     in a particular context.
> 
> 	   * Selection of what data might be valid as the subject of a
> 	     reputation query.  It is up to reputation service providers and
> 	     assessors to select which qualities of a body of data might
> 	     be useful input to reputation evaluation.
> 
> 	   * Concerns about methods of verifying domain names that are used
> 	     for email reputation.  A verified domain name is a starting point
> 	     for this work; the means by which it was obtained and the
> 	     "meaning" of the name or its verification are matters for
> 	     discussion elsewhere.
> 
> 	   * Algorithms to be applied to aggregated feedback in order to
> 	     compute reputations.  These are part of a back-end system, usually
> 	     proprietary, and not appropriate for specification as part of
> 	     a query/reply framework and protocol.
> 
> 	The initial draft set:
> 		draft-kucherawy-reputation-model
> 		draft-kucherawy-reputation-media-type
> 		draft-kucherawy-reputation-query-http
> 		draft-kucherawy-reputation-query-dns
> 		draft-kucherawy-reputation-query-udp
> 		draft-kucherawy-reputation-vocab-identity
> 
> Goals and Milestones:
> 	Mar 2012:	Informational document, defining the problem space
> 			and solution architecture, to the IESG for publication.
> 
> 	Mar 2012:	Specification for the multi-attribute reporting
> 			data structure, to the IESG for publication.
> 
> 	May 2012:	Informational document, defining the vocabulary
> 			for providing reputation in the email sphere, to the
> 			IESG for publication.
> 
> 	Jul 2012:  	Specification defining the simple
> 			query mechanism, to the IESG for publication.
> 
> 	Jul 2012:  	Specification for the extended
> 			query mechanism, to the IESG for publication.
> 
> 	Oct 2012:  	Informational document, discussing issues
> 			of data transparency, redress, meta-reputation
> 			and other important operational considerations, to the
> 			IESG for publication.

> _______________________________________________
> domainrep mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/domainrep


-- 
Andrew Sullivan
[e-mail]