Subject: [apps-discuss] AppsDir review of draft-ietf-repute-model-08

From: Tony Hansen <[email-masked]>
Date: Fri, 30 Aug 2013 10:46:45 -0400

I have been selected as the Applications Area Directorate reviewer for this draft (for background on appsdir, please see http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).

Please resolve these comments along with any other Last Call comments you may receive. Please wait for direction from your document shepherd or AD before posting a new version of the draft.

Document:  draft-ietf-repute-model-08
Title: A Model for Reputation Reporting

Reviewer: Tony Hansen
Review Date: 2013-08-29
IESG Telechat Date: 9/12
IETF Last Call Expires: LC for 07 expired on 2013-08-29, but 08 superseded that

Summary:
The document is ready for publication. Minor notes follow that can be fixed in AUTH48.

The document describes a model for reputation services, particularly those being produced by the Repute WG. It follows the recommendations of RFc4101 for describing a protocol model, which requires answers to 1) the problem the protocol is trying to achieve, 2) the meaning of messages transmitted, and 3) important unobvious features of the protocol. This document accomplishes its goals quite well.

==== ORGANIZATIONAL COMMENT ====

Section 3 "High-Level Architecture" starts with an extended example of where a reputation service would fit into an existing service. Finally, more than a page later, it starts describing the architecture that is supposed to be the topic of this section. I suggest that the section be split into two, with the beginning given the heading along the lines of "Example of a Reputation Service Being Used", and the "High-Level Architecture" heading moved right before the paragraph that starts "This document outlines". Alternatively, add subsection titles.

==== MINOR NITS ====

Changes below are marked with >>><<<.

==== Section 1, paragraph 5 starting with "A full trust"

I think this sentence would read better as follows, both for readability and to match the style of the surrounding sentences:

OLD: Some need only produce a basic rating, while others need to provide
OLD: underlying detail.

NEW: Some need >>to<< only produce a basic rating, while others need to provide
NEW: >>the<< underlying detail.

==== Section 2, paragraph 1 starting with "The basic premise"

I think this sentence would read better with the introduction some additional punctuation.

OLD: Typically client and service operators enter into
OLD: some kind of agreement during which some parameters are exchanged
OLD: such as the location at which the reputation service can be reached,
OLD: the nature of the reputation data being offered, possibly some client
OLD: authentication details, and the like.

NEW: Typically client and service operators enter into
NEW: some kind of agreement during which some parameters are exchanged>>>,<<<
NEW: such as>>>:<<< the location at which the reputation service can be reached,
NEW: the nature of the reputation data being offered, possibly some client
NEW: authentication details, and the like.

==== Section 3, paragraph 5 starting with "It provides"

I think there is a typo in this sentence and the word "one" should be "done".

OLD: (Although not typically thought of as a 'transport', the DNS
OLD: provides generic capabilities and can be thought of as a mechanism
OLD: for transporting queries and responses that have nothing to do with
OLD: Internet addresses, such as is one with a DNS BlockList [DNSBL <http://tools.ietf.org/html/draft-ietf-repute-model-08#ref-DNSBL>].)

NEW: (Although not typically thought of as a 'transport', the DNS
NEW: provides generic capabilities and can be thought of as a mechanism
NEW: for transporting queries and responses that have nothing to do with
NEW: Internet addresses, such as is >>>done<<< with a DNS BlockList [DNSBL <http://tools.ietf.org/html/draft-ietf-repute-model-08#ref-DNSBL>].)

==== Section 4.1, paragraph 2 starting with "Response Sets have"

I think this sentence should be parenthetical:

OLD: IANA registries are created in a separate document.

NEW: >>>(<<<IANA registries are created in a separate document.>>>)<<<

==== Section 9.3

I think this sentence reads better as follows:

OLD: Numerous other topics related to use and management of reputation
OLD: systems can be found in [I-D.REPUTE-CONSIDERATIONS].

NEW: Numerous other topics related to >>>the<<< use and management of reputation
NEW: systems can be found in [I-D.REPUTE-CONSIDERATIONS].

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 30 Aug 2013 15:20:34 -0400

On Fri, Aug 30, 2013 at 02:37:13PM -0400, Hector Santos wrote:
> 
> For example, DKIM-REPUTE product designers would need to consider
> SPF reputons product models.  Simple text as follows can resolve the
> integration consideration with little SPF fanfare the draft
> obviously tried to avoid:

Why should the framework document contain details of how various
particular reputation services interact?  If you want a discussion of
reputation-service-interaction mechanisms in the draft, that's one
thing.  If you want to talk about how SPF and DKIM interact, then I
think this is probably the wrong draft.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 30 Aug 2013 16:09:20 -0400

On Fri, Aug 30, 2013 at 03:39:14PM -0400, Hector Santos wrote:

> archives of the Repute WG to find or extract these very real and
> practical integration considerations.  The document should have
> these general considerations summarized.

But your suggestion was for protocol-specific advice.  I don't know
how to write that in a generic way.  If you have specific text you
want, I can evaluate.  Your suggestion here, however, is one for which
I don't know the response.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 30 Aug 2013 13:18:12 -0700

> think this is probably the wrong draft.
The document we're talking about here only describes a general
architecture.  DKIM is present in the document for illustration purposes
only; it doesn't limit REPUTE to being used by DKIM.  The more
protocol-specific stuff, which already does include SPF support, is in
draft-ietf-repute-email-identifiers.

-MSK

---

From: Tony Hansen <[email-masked]>
Date: Fri, 30 Aug 2013 18:26:00 -0400

On 8/30/2013 2:37 PM, Hector Santos wrote:
> On 8/30/2013 10:46 AM, Tony Hansen wrote:
>>
>> The document describes a model for reputation services, particularly
>> those being produced by the Repute WG. It follows the recommendations
>> of RFc4101 for describing a protocol model, which requires answers to
>> 1) the problem the protocol is trying to achieve, 2) the meaning of
>> messages transmitted, and 3) important unobvious features of the
>> protocol. This document accomplishes its goals quite well.
>
> As a high potential implementator of this DKIM-REPUTE framework and
> user of any future REPUTE products based on this DKIM-REPUTE
> framework, I am somewhat disappointed to find not a single integration
> consideration for the highly adopted SPF technology.  Not a single
> mentioning of the word or the integrated use of this highly adopted
> mail transport augmented technology.  ...

Hector, what you're suggesting would be fine for a document that
specifically was written about reputation servers for email services.
But draft-ietf-repute-model is not the place for it.

While draft-ietf-repute-model does contain an example of how a
reputation service could be used to help assess a DKIM identifier, that
is not the thrust of this document.

RFC 4101 (Writing Protocol Models) contains this advice:

    3.2 Abstraction is good
    ... try to abstract away pieces ...
    3.3 A few well-chosen details sometimes help
    ... it's often a good approach to talk about the material in the
abstract and
    then provide a concrete description of one specific piece to bring
it into focus. ...

The DKIM example is just that, an example of one way the model could be
used. It is strictly illustrative and not exclusionary in any way.

    Tony Hansen

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 30 Aug 2013 19:39:24 -0400

Hi Doug!

On Fri, Aug 30, 2013 at 04:24:17PM -0700, Douglas Otis wrote:

> Use of DKIM offers a very poor authentication example

Thanks for the feedback.  I don't recall you having made this point on
the repute mailing list.  Did you, & I missed it?

Do you have a better example, specifically excluding …

> StartTLS would represent a much better example.

…this, which strikes me as suffering from a different but related set
of issues along the lines you're complaining about?

Alternatively, if we recast the description of DKIM to call it
something else, but still used it as an example of what REPUTE is
trying to do, would that solve your objection?

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: S Moonesamy <[email-masked]>
Date: Fri, 30 Aug 2013 17:46:51 -0700

Hello,

After reading the reviews of the Application Area Directorate review 
it seems to me that there is some misunderstanding of what an 
Application Area Directorate review is about.  The review is to give 
the Applications Area Directors a sense of how important it is that 
they pay attention to a draft.

If there is a problem with a working group draft that problem should 
be taken up with the working group instead of the Applications Area 
Directorate reviewer.  If there is a problem with the Applications 
Area Directorate review it is okay in my opinion to discuss about 
that with the reviewer.

Regards,
S. Moonesamy

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 30 Aug 2013 22:50:54 -0400

Colleagues, and Doug especially,

The message I sent (below) wasn't intended as a "shut up and go away"
message, but a genuine query.  I have grave doubts that TLS is the
right example (to begin with, I think fitting it into the REPUTE
approach, given the existing CA structure, would also be
controversial); but I'm genuinely trying to understand how to make the
document better, & not trying to tell anyone to go away.

Best,

A

-- 
Andrew Sullivan
[email-masked]