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

Tony Hansen <tony@att.com> Fri, 30 August 2013 14:47 UTC

Message-ID: <5220B055.2000704@att.com>
Date: Fri, 30 Aug 2013 10:46:45 -0400
From: Tony Hansen <tony@att.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: IETF Discussion <ietf@ietf.org>, General discussion of application-layer protocols <apps-discuss@ietf.org>, draft-ietf-repute-model.all@tools.ietf.org
Content-Type: multipart/alternative; boundary="------------060402010505070101090409"
Subject: [apps-discuss] AppsDir review of draft-ietf-repute-model-08
Precedence: list

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].

[apps-discuss] AppsDir review of draft-ietf-reput… Tony Hansen
Re: [apps-discuss] AppsDir review of draft-ietf-r… Andrew Sullivan
Re: [apps-discuss] AppsDir review of draft-ietf-r… Andrew Sullivan
Re: [apps-discuss] AppsDir review of draft-ietf-r… Murray S. Kucherawy
Re: [apps-discuss] AppsDir review of draft-ietf-r… Tony Hansen
Re: [apps-discuss] AppsDir review of draft-ietf-r… Andrew Sullivan
Re: [apps-discuss] AppsDir review of draft-ietf-r… S Moonesamy
Re: [apps-discuss] AppsDir review of draft-ietf-r… Andrew Sullivan
Re: [apps-discuss] AppsDir review of draft-ietf-r… Douglas Otis
Re: [apps-discuss] AppsDir review of draft-ietf-r… Douglas Otis
Re: [apps-discuss] AppsDir review of draft-ietf-r… Hector Santos
Re: [apps-discuss] AppsDir review of draft-ietf-r… Hector Santos
Re: [apps-discuss] AppsDir review of draft-ietf-r… Hector Santos
Re: [apps-discuss] AppsDir review of draft-ietf-r… Murray S. Kucherawy
Re: [apps-discuss] AppsDir review of draft-ietf-r… Murray S. Kucherawy