Subject: [domainrep] WG Action: Reputation Services (REPUTE)

From: IESG Secretary <[email-masked]>
Date: Mon, 7 Nov 2011 09:36:01 -0800 (PST)

A new IETF working group has been formed in the Applications Area.  For 
additional information, please contact the Area Directors or the WG 
Chairs.

Reputation Services (REPUTE)
---------------------------------------------------
Current Status: Active Working Group

Chairs:
    Dave Crocker <[email-masked]>
    Chris Lewis <[email-masked]>

Applications Area Directors:
    Pete Resnick <[email-masked]>
    Peter Saint-Andre <[email-masked]>

Applications Area Advisor:
    Pete Resnick <[email-masked]>

Mailing Lists:
General Discussion: [email-masked]
    To Subscribe: https://www.ietf.org/mailman/listinfo/domainrep/
    Archive: http://www.ietf.org/mail-archive/web/domainrep/

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 can be 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 (targeting the
  standards track, though the working group will determine the
  appropriate status) 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 supporting 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.

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 07 Nov 2011 09:44:38 -0800

> Reputation Services (REPUTE)

Folks,

Howdy.

As always, getting chartered is the hard part.  No doubt the actual work of the 
group will be straightforward and run into no controversy, just as we've all 
become accustomed to in the IETF...

Please review the text of the charter carefully, with special regard both for 
what we are obligated to deliver and for what is /out/ of scope.

The group already has a good discussion history.  Let's keep going!

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 7 Nov 2011 10:31:19 -0800

In terms of agenda items for Taipei, we should have a slot of five minutes or less for deciding formally to adopt the various working drafts as REPUTE WG items.

(Although if the chairs decide that's a given, they can just pre-approve the names and we can post them under the new names once the embargo is lifted.)

-MSK

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 07 Nov 2011 10:52:11 -0800

> (Although if the chairs decide that's a given, they can just pre-approve the names and we can post them under the new names once the embargo is lifted.)

Thanks for raising this.  It is a rather more interesting question than it 
should be, since I try to be careful about this specific point, when formulating 
wg charter text and there is existing work.  Oops.

About the drafts, the charter says:

    "The initial draft set:"

which doesn't clearly declare what level of "input" they constitute.

So, yeah, we need to decide on how to use the documents.  Unfortunately, that 
could take more than 5 minutes if we defer talking about it until the meeting.

So let's talk about it now.

The kinds of choices:

    1. Accept all documents as working group documents

    2. Decide on each document separately.

    3. Start on new documents, using the initial set merely as discussion input.

There are other possibilities, but let's see where we get with this set.

So, I hereby solicit comments about, and/or in favor of, one of the above choices...

The goal of this thread is to decide upon the status of the "initial set" 
documents.  It would be nice to resolve this /before/ the face-to-face.

d/

-- 

   Dave Crocker

---

From: Peter Murray <[email-masked]>
Date: Mon, 7 Nov 2011 14:09:39 -0500

I have just tuned into the efforts of this working group.  This is a useful topic, and my interests lay in how this protocol might be used by libraries to become nodes of feedback particularly around the collective evaluation of scholarly materials.  Is there -- or will there be -- a summary of the discussion so far beyond the initial draft set of documents?

Peter
-- 
Peter Murray
Assistant Director, Technology Services Development
LYRASIS
[email-masked]
+1 678-235-2955
 
1438 West Peachtree Street NW
Suite 200
Atlanta, GA 30309
Toll Free: 800.999.8558
Fax: 404.892.7879 
www.lyrasis.org
 
LYRASIS: Great Libraries. Strong Communities. Innovative Answers.

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 7 Nov 2011 14:16:46 -0500

>    1. Accept all documents as working group documents

I suggest this.  There is no restriction that the WG can't just decide
to merge documents afterwards, or abandon efforts, or so on -- new WGs
in particular tend to have a lot of leeway in this matter.

The alternative will be to spend an overwhelming amount of time on
administrative decisions instead of ploughing forward on work.  The
administrative work can instead be dealt with as it arises, which
means that (1) we don't have to deal with all of it at once and (2)
all the important administrative work will get coped with anyway.

Best,

A (yes, I know my contributions are sparse)

-- 
Andrew Sullivan
[email-masked]

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 7 Nov 2011 20:22:54 +0100

> favor of, one of the above choices...

At some point in time I might favour to merge the
query-dns and query-udp memos, but renaming all
I-D.kucherawy-reputation-* to I-D.ietf-repute-*
is no problem (if the co-authors agree to their
"demotion" to co-editors; i.e., if they volunteer
to be co-editors.)

-Frank

---

From: Douglas Otis <[email-masked]>
Date: Mon, 07 Nov 2011 12:09:06 -0800

> all the important administrative work will get coped with anyway.
The charter excludes considerations regarding identities assigned 
reputations.  The charter did not clarify whether "verification" ensures 
identified domains acted in an event leading to reputation assertions.  
An approach permitting assessment of unauthenticated actors seems 
destine to devolve into high ratings based on size, and low ratings 
lacking redress.

The charter appears to incorrectly presume either DKIM or SPF positively 
identify actors that might only appear involved in events leading to 
negative reputations.  As today's financial debacle has shown, accuracy 
can not be presumed from opaque derivations or those premised upon false 
assumptions.

When based upon the IP address, there also should be considerations 
regarding shared addresses such as those used by transition 
technologies, and how 1.4 quadrillion prefix ratings might be safely 
exchanged.

-Doug

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 07 Nov 2011 12:19:49 -0800

On 11/7/2011 11:09 AM, Peter Murray wrote:
> I have just tuned into the efforts of this working group.

welcome!

>   Is there -- or will there be -- a summary of the
> discussion so far beyond the initial draft set of documents?

That's an entirely reasonable query, but I don't recall seeing "summaries" occur 
that much for new IETF working groups that have had discussions underway for 
awhile.  That's what the mailing list archive is for, in spite of how painful 
slogging through an archive can be.

If there are specific, open issues that folks believe are pending, I'll ask that 
they cite them.  (Oh.  Right.  We need to get the issue tracker happening.  sigh.)

Other than that, as you note, the drafts are a form of summary...

d/

-- 

   Dave Crocker

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 7 Nov 2011 15:31:46 -0500

Doug,

On Mon, Nov 07, 2011 at 12:09:06PM -0800, Douglas Otis wrote:

> reputations.  The charter did not clarify whether "verification"
> ensures identified domains acted in an event leading to reputation
> assertions.  An approach permitting assessment of unauthenticated
> actors seems destine to devolve into high ratings based on size, and
> low ratings lacking redress.
> 
> The charter appears to incorrectly presume either DKIM or SPF
> positively identify actors that might only appear involved in events
> leading to negative reputations.  As today's financial debacle has
> shown, accuracy can not be presumed from opaque derivations or those
> premised upon false assumptions.
> 

Not one single thing you say above is even remotely relevant as to
whether to adopt the documents already written.  If you think those
documents don't _cover_ something, then you should either make
suggestions for how to improve one of them or else write another one
that is an attempt to argue for (1) different use cases or (2) the
replacement of some (== at least one) of those documents with
something else.

"Adopt a document" in no way signifies, "I think this document should
be made an RFC".  It merely says, "I think this is on topic, and I
think this document is a start on it."  What is the problem you see
with any one of these documents _as a starting point_?

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 7 Nov 2011 13:57:48 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Andrew Sullivan
> Sent: Monday, November 07, 2011 12:32 PM
> To: [email-masked]
> Subject: Re: [domainrep] WG Action: Reputation Services (REPUTE)
> 

+1.  None of that is charter material, but it is certainly valid fodder for discussion in the existing or extended document set.

If we want to have some discussion about what sorts of things are valid as reputation subjects, that would best go either in the model document that Nathaniel is editing (in which case, I suggest some text needs to be contributed), or in its own document, perhaps the final chartered work item (which has not yet been started).

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 07 Nov 2011 14:08:50 -0800

On 11/7/2011 1:57 PM, Murray S. Kucherawy wrote:
>> "Adopt a document" in no way signifies, "I think this document should be
>> made an RFC".  It merely says, "I think this is on topic, and I think this
>> document is a start on it."  What is the problem you see with any one of
>> these documents _as a starting point_?
>
> +1.  None of that is charter material, but it is certainly valid fodder for
> discussion in the existing or extended document set.
>
> If we want to have some discussion about what sorts of things are valid as
> reputation subjects, that would best go either in the model document that

Hmmm...

Let's be pristine here.

I believe the rules and semantics of having a formal "working group document" 
have never been adopted by IETF consensus or evel well documented, in spite of 
long and elaborate formalities having been developed, including the 
draft-ietf-<wgname>- convention.

That said, I think I've never seen a working group formally adopt a document 
that was not intended for direct publication as an RFC.  As work proceeds, the 
intention can change, but at the time of adoption, I believe the universal 
convention is to intend that a revised version /of that document/ is intended by 
the working group for publication.

Otherwise, the document is merely being used as input to discussion.  That's 
fine, too, but it doesn't require formal adoption.

d/

-- 

   Dave Crocker

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 7 Nov 2011 14:17:56 -0800

> From: Dave CROCKER [mailto:[email-masked]]
> Sent: Monday, November 07, 2011 2:09 PM
> To: Murray S. Kucherawy
> Cc: [email-masked]
> Subject: Adopting "working group" documents
> 

All the tools are built around that naming convention implying that a document is now "owned" by the working group, which changes things like where it gets discussed, last call duration, etc.  That's the assumption my previous message made.

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 07 Nov 2011 14:25:06 -0800

> All the tools are built around that naming convention implying that a document is now "owned" by the working group, which changes things like where it gets discussed, last call duration, etc.  That…

Yup.

The de facto practice is there, all the way into software.  What's impressive is 
how little formal documentation about IETF and working group "policy" there is 
concerning this.

But my deeper comment was meant to be about the usual (universal) semantics of 
that adoption.  I'm pressing the point because I don't think I've ever seen 
adoption be as casual as "we'll use it as input" which I took your note to be. 
And I'm pursuing this on the list to make sure we get group resolution of the point.

I don't see much benefit in going through formal processes for stuff that is 
just "input".  The IETF is fundamentally oriented towards easy incorporation of 
lots of input.  The formal part comes into play when we need to develop 
consensus about documents.

Besides, the less we adopt formally, the less we have to track and otherwise 
take responsibility for...

d/

-- 

   Dave Crocker

---

From: Chris Lewis <[email-masked]>
Date: Mon, 07 Nov 2011 17:27:31 -0500

On 11-11-07 01:52 PM, Dave CROCKER wrote:
>> In terms of agenda items for Taipei, we should have a slot of five
>> minutes or less for deciding formally to adopt the various working
>> drafts as REPUTE WG items.
>>
>> (Although if the chairs decide that's a given, they can just
>> pre-approve the names and we can post them under the new names once
>> the embargo is lifted.)
>
>
> Thanks for raising this. It is a rather more interesting question than
> it should be, since I try to be careful about this specific point, when
> formulating wg charter text and there is existing work. Oops.
>
> So, yeah, we need to decide on how to use the documents. Unfortunately,
> that could take more than 5 minutes if we defer talking about it until
> the meeting.
>
> The goal of this thread is to decide upon the status of the "initial
> set" documents. It would be nice to resolve this /before/ the face-to-face.

I'd tentatively accept all documents (do we have a complete list, with 
links?  I need to catch up fast! ;-) with the caveat that we'd amend 
(change, merge, add, delete) as we went forward.  They seem to scope the 
work pretty well and provide neat compartmentalization of the bits the 
WG needs to do.

Trying to decide each one separately/starting afresh seems premature and 
perhaps self-limiting (eg: if the WG decides to do JSON instead of XML). 
  I'd rather have the discussion drive the document set than the other 
way around.

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 7 Nov 2011 17:30:35 -0500

On Mon, Nov 07, 2011 at 02:08:50PM -0800, Dave CROCKER wrote:

> That said, I think I've never seen a working group formally adopt a
> document that was not intended for direct publication as an RFC.  As
> work proceeds, the intention can change, but at the time of
> adoption, I believe the universal convention is to intend that a
> revised version /of that document/ is intended by the working group
> for publication.

With this I fully agree, but that's usually because the documents are
roughly aligned with what the WG is doing (especially in the case of a
new WG like this).  My objection to Doug's comments was basically that
he didn't say anything at all about any of the docs nor how they met
the chartered tasks; neither did he say what he wanted to be
different.

In case this wasn't plain from my previous note, I think the drafts we
have before us are a good basic set of work items, that they conform
roughly to the charter, that things they suggest that are (IMO) bad
ideas are going to be thrashed out here anyway, and that therefore
they are all good candidates for adoption.  I would not be astonished
if, as we work, some of them turn out to fall away, that some of them
end up merged together, or so on.  But I don't especially care about
determining whether that will happen in advance, and it seemed to me
as a practical matter to be as good just to adopt them all and then,
if we discover that there is an administrative problem to face with a
document or two later, we face that problem then with that document
(or those documents).  The alternative, if recent history around the
IETF is any guide, is endless threads talking about whether something
is good enough to be a working document and conflating substantive
comments on the details in the document with the question of whether
we have a basic structure for future work sitting there in front of
us. 

I want to cut the latter conversation off at the knees wherever we
can, because it's a waste of everyone's time (we'll have the same
conversation post-adoption).  If the Chairs feel otherwise, I'm happy
for them to rule otherwise (I don't have a strong feeling).  It was
just a suggestion.

For what it's worth, I also would prefer a more organized work plan,
putting "what do we have to do?" before "what do we need to do it?"
But despite what people sometimes say about me, I'm not actually such
a purist, and so I think that just adopting all the drafts as a
starting point is a quick and pragmatic way to move ahead.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 7 Nov 2011 14:30:38 -0800

> Sent: Monday, November 07, 2011 10:52 AM
> To: Murray S. Kucherawy
> Cc: [email-masked]

In my opinion, the "model", "media-type", "query-http", and "vocab-identity" documents are ready to be handed over to the WG for development.  The others are either not there yet, or have yet to be initiated even as individual submissions.

The "vocab-email" one is probably not needed and can just quietly expire.

There's still discussion about the "query-dns" vs. "query-udp" ones.  Someone else should take up editing of (one of) them, and the WG should decide which, unless of course we decide instead that we don't need the heavyweight query mechanism after all.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 7 Nov 2011 14:32:29 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Murray S. Kucherawy
> Sent: Monday, November 07, 2011 2:31 PM
> To: [email-masked]
> Cc: [email-masked]
> There's still discussion about the "query-dns" vs. "query-udp" ones.
> Someone else should take up editing of (one of) them, and the WG should
> decide which, unless of course we decide instead that we don't need the
> heavyweight query mechanism after all.

s/heavy/light/

---

From: Dave CROCKER <[email-masked]>
Date: Mon, 07 Nov 2011 14:39:14 -0800

> There's still discussion about the "query-dns" vs. "query-udp" ones.  Someone else should take up editing of (one of) them, and the WG should decide which, unless of course we decide instead that w…

This sounds like the foundation to a set of actions.

Does anyone agree or disagree with Murray's assessments of the documents?  In 
particular, he's stated 3 categories (ready to be adopted, ready to be retired, 
and still needs discussion before adoption).

    1.  Do folks agree/disagree with the categories?

    2.  Do folks agree/disagree with the assessments of which document go in 
which categories?

d/
-- 

   Dave Crocker

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 7 Nov 2011 23:45:18 +0100

> s/heavy/light/

Let's discuss the content first (= no TXT and UDP
hacks before it's clear that using UDP could work.)

Above all no XML over TXT/UDP, that was already a
bad idea in MARID.  The "netalyzr" paper found
that EDNS0 still has problems in practice (2010).

-Frank

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 7 Nov 2011 17:46:24 -0500

On Mon, Nov 07, 2011 at 02:39:14PM -0800, Dave CROCKER wrote:

> Does anyone agree or disagree with Murray's assessments of the
> documents?  In particular, he's stated 3 categories (ready to be
> adopted, ready to be retired, and still needs discussion before
> adoption).
> 
>    2.  Do folks agree/disagree with the assessments of which
> document go in which categories?

For exactly the same reasons I had for saying "adopt them all", I'm
prepared to go with Murray's categories and assessments.  I'm being
hyper-lightweight about process here, so probably any list remotely
related to the discussion we've so far seen on list will garner a
"yea" from me. 

A

-- 
Andrew Sullivan
[email-masked]

---

From: Douglas Otis <[email-masked]>
Date: Mon, 07 Nov 2011 15:08:38 -0800

On 11/7/11 12:31 PM, Andrew Sullivan wrote:
> > The charter did not clarify whether "verification" ensures
> > identified domains acted in an event leading to reputation
> > actors seems destine to devolve into high ratings based on size,
> > and low ratings lacking redress.
> >
> > positively identify actors that might only appear involved in
> > events leading to negative reputations. As today's financial
> > debacle has shown, accuracy can not be presumed from opaque
> > derivations or those premised upon false assumptions.
> >
> > When based upon the IP address, there also should be
> > considerations regarding shared addresses such as those used by
> > transition technologies, and how 1.4 quadrillion prefix ratings
> > might be safely exchanged.
>
>  whether to adopt the documents already written.

There should be a principle statement that any reputation be based upon 
"AUTHENTICATED" actors.  Not just "validated signatures covering some 
portion of a message", or authorized outbound IP addresses for what 
might represent shared resources.  Assessing the wrong identity will 
prove highly disruptive and expensive.

Rather than again reviewing logical errors made in the Repute charter, 
please note an example assertion made in:
http://tools.ietf.org/html/draft-kucherawy-reputation-model-00

The Introduction states:
,---
For example, the [DKIM] protocol permits a much higher level of
trust in the identity of the sending domain of an email message.
'---

DKIM does NOT identify the "SENDING" domain!!!  It identifies a domain 
that _signed_ a portion of a message.  DKIM does not identify who 
actually sent the message or to whom.  DKIM lacks context necessary to 
establish "SENDING" accountability.

A message sent to those expressing an interest will not represent a 
negative event reducing a domain's reputation.  When some malefactor 
replays the _same_ valid DKIM message to those who never expressed an 
interest, this would represent a negative event when based upon the 
false assertion DKIM identifies the SENDING domain.  Worse still, the 
message may include pre-pended headers obfuscating signed portions of 
the message and yet still produce valid DKIM results!  DKIM's lack of 
context also means malefactors will be able to feint being victims.

This is but one of many logical errors littering these documents and the 
charter.

The current charter suffers the same flawed logic that overlook the need 
for authentication that then reappears in follow-on documents where 
critical issues of accountability try to be deemed out of scope.  This 
seems highly irresponsible because those reporting incorrectly 
identified reputations might be liable in some jurisdictions.  This 
would be a shameful result of such flawed logic embedded within the WG 
charter. :^(

There should also be a document reviewing scalability and network 
amplifications of the applied system.

-Doug

---

From: "John Levine" <[email-masked]>
Date: 7 Nov 2011 23:10:50 -0000

>in particular tend to have a lot of leeway in this matter.

Agreed.  Arguments along the lines of whether to merge the DNS and UDP
documents don't impress me as a great use of limited face time.

R's,
John

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 7 Nov 2011 15:20:50 -0800

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Douglas Otis
> Sent: Monday, November 07, 2011 3:09 PM
> To: Andrew Sullivan
> Cc: [email-masked]

The charter actually explicitly says the opposite.  The REPUTE framework enables the delivery of reputation about anything, with email domains being the exemplary application.  The reputation producer and consumer need to consider and understand the material on which they are focusing.  The charter does call out an informational document to talk about those things, so we'll get to that at some point.  Specific reputation applications can also document such considerations, but they don't belong in the framework itself or in the charter.

To say REPUTE has to constrain itself only to specific classes of identifiers is like saying SMTP shouldn't be allowed to relay spam.  It's a framework, nothing more.

> establish "SENDING" accountability.

Yes, that's true, this needs to be corrected, but it hardly invalidates the entire body of the work to date.

> context also means malefactors will be able to feint being victims.

This stuff is explicitly outside of our charter, and for good reason: REPUTE should not be a new stomping ground for the same old arguments about why a few people believe DKIM and SPF are flawed.  Those debates took place in other venues, some long ago, so they are well-documented and we don't need to have them again.

> amplifications of the applied system.

We'll watch for your I-D.  :-)

-MSK

---

From: "John Levine" <[email-masked]>
Date: 7 Nov 2011 23:24:48 -0000

>> In my opinion, the "model", "media-type", "query-http", and
>"vocab-identity" documents are ready to be handed over to the WG for
>development.  The others are either not there yet, or have yet to be
>initiated even as individual submissions.

I think the media-type and query-http documents need to be merged and
perhaps one of them killed in the process, but the WG can deal with that.

So yes, I agree with Murray's current suggestion.

R's,
John

---

From: Douglas Otis <[email-masked]>
Date: Mon, 07 Nov 2011 16:09:15 -0800

> This stuff is explicitly outside of our charter, and for good reason: REPUTE should not be a new stomping ground for the same old arguments about why a few people believe DKIM and SPF are flawed.…
Murray,

Few "prior" discussions relate to DKIM's suitability as a basis for 
reputation.  The original intent of DKIM to provide anti-spoofing and 
anti-phishing of "recognized" domains.  Even that limited goal was 
eroded when pre-pending of signed header fields was permitted.  This 
inability means positive reputation assertions become dangerous when 
applied to these obfuscated messages.

These concerns are not dredging up old arguments.  This is about 
considerations necessary for safe and non-disruptive application of 
reputation.  Such considerations are important and should not be deemed 
outside of a reputation charter.

-Doug

---

From: SM <[email-masked]>
Date: Mon, 07 Nov 2011 21:36:28 -0800

>initiated even as individual submissions.

These three documents are good as a starting point for the work.

>The "vocab-email" one is probably not needed and can just quietly expire.

Ok.

>There's still discussion about the "query-dns" vs. "query-udp" 
>ones.  Someone else should take up editing of (one of) them, and the 
>WG should decide which, unless of course we decide instead that we 
>don't need the heavyweight query mechanism after all.

I suggest not picking up these two for now.

draft-kucherawy-reputation-model-00 identifies seven RFCs for the 
document series.  The goals mention six RFCs.  The three main documents are:

  - document defining the problem space and solution architecture
  - multi-attribute reporting data structure
  - document defining the vocabulary for providing reputation

I suggest using draft-kucherawy-reputation-model-00, 
draft-kucherawy-reputation-query-http-03 and 
draft-kucherawy-reputation-vocab-identity-02 for the initial 
discussion.  This working group could discuss 
draft-kucherawy-reputation-model-00 and flush out some of the problem 
space and solution architecture issues.  It would also give the 
working group a feel of what is in scope and what is out of scope 
(and allow WG participants to build their reputation 
:-)).  draft-kucherawy-reputation-vocab-identity-02 could shadow the 
work on "model".

I'll list a few points and leave it to the WG Chairs to determine 
whether they are worth picking up or not:

  (a) Whether to use HTTP/XML for the architecture

  (b) Whether a heavyweight and lightweight solution should be considered now

  (c) Information represented in the protocol

Regards,
-sm

---

From: "Rolf E. Sonneveld" <[email-masked]>
Date: Tue, 08 Nov 2011 22:23:29 +0100

On 11/8/11 6:36 AM, SM wrote:
>> Someone else should take up editing of (one of) them, and the WG 
>> should decide which, unless of course we decide instead that we don't 
>> need the heavyweight query mechanism after all.
>

My view is: reputation is a complex 'thing'. So let's first write out 
and get experience with a simple mechanism and then we can extend upon 
the experience we get, by moving on to more complex mechanisms. So we 
can't skip the DNS/UDP documents in my view.

/rolf