An Architecture for Reputation Reporting
RFC 7070

I welcome the inclusion of a Privacy Considerations section, but I wonder whether it goes far enough.

In Section 2 you observe:
   Typically client and service operators enter into
   some kind of agreement during which some parameters are exchanged
   such as the location at which the reputation service can be reached,
   the nature of the reputation data being offered, possibly some client
   authentication details, and the like.
If *that* agreement can be breached, then any party may be able to issue requests to the server. While securing the client-server exchanges can help to protect the privacy of the entities about which reputation information is held, it is of no value if the "agreement during which some parameters are exchanged" is leaky. So I think you should say more about the mechanisms and security underlying this agreement.

I am also looking ahead a little toward the inevitable legal action caused by a reputation server holding, in private, information about an entity that that entity holds to be false or misleading. There will inevitably be a requirement one day for entities to be able to make reputation enquiries about themselves. I wonder whether this needs to be discussed.

Thanks for addressing my DISCUSS points.

Editorial: expand the acronyms in figure 1

Non-blocking... I agree with Joel's assessment that there are some missing pieces to this document series.

this is non-blocking...

Manageability considerations for a reputation system? addition/state change/determination of state change.

I can imagine a number of things that I don't see well described in the document series.

I support Stephen's discuss position.

Figure 1: There can be more than one author of an email message, so should figure 1 indicate that by replacing Author with Author(s)?

Figure 2: Are the lines to the transport boxes really needed?  It seems like you're trying to show protocol interactions as well as protocol layers and keep wondering why that's necessary in one Figure.

s5: Isn't it the identifier of the entity being rated not the identity of the entity?  Or is the idea that the application context scopes the identity to the an identifier?

Thanks for making the changes for my discuss. Your new 
text says:

"For interchanges that are sensitive to such exposures, it is	
imperative to protect the information from unauthorized access 
and	viewing, and possibly add the capability to do object-level 
integrity and origin verification. Not all transport options can be 
adequately secured in these ways (e.g., DNS queries and 
responses are entirely insecure), and so it might be necessary 
to change to a transport	method that does have such 
capabilities or extensions.	

The architecture described here neither suggests nor precludes any	
particular transport mechanism for the data. However, for the	
purpose of illustration, a reputation service that operates over HTTP	
might employ any of several well-known mechanisms to solve these	
problems, which include OpenPGP [OPENPGP], HTTP over TLS [HTTP-TLS],	
and S/MIME [SMIME]."

As non-blocking comments on the above, I'd say that:

- "change to a transport method" seems like the kind of thing that'll
not happen, or at least not until its too late. I think it'd be better if
you said that clients and servers MUST NOT use insufficiently
secure services for anything that might be sensitive. The reason
I'd ask you to think about that is that I do expect that people
will want to use repute over DNS and that is liable to be a
problem.

- "for the purposes of illustration" and "might employ" are all
a bit weasel-wordy. I think PGP or SMIME are mythical here
but that use of HTTP/TLS ought be much more strongly 
recommended.

Clearing the following DISCUSS on the basis of Murray Kucherawy's proposal:

Section 4.1 appears to be confusing two different things by referring to them with the same term: "response set."   I think a response set is a predefined data type.   But the first paragraph of 4.1 refers to a response set as if it were data, not a data type.   The second paragraph says that each response set has an IANA-registered name, which is consistent with a response set being a data type.   You also have a related draft that actually defines a response set for email, so that confirms my belief that a response set is a data type, not data.

Proposed text from Murray:

A "Response Set" is a representation for data that are returned in response to a reputation query about a particular entity.  The data representation is specific to the application; though all applications have a few key fields in common, some of the reputation data returned in the evaluation of email senders would be different than that returned about a movie, restaurant, or baseball player.

Non-discuss comments:

The box around the DKIM signer and validator in figure 1 is a bit confusing.   Is it really necessary?   I know the technology well enough that the meaning was clear to me, but someone who isn't particularly knowledgeable about DKIM and SMTP might not successfully navigate this.   I think the dotted line makes the relationship clear enough.   But this is clearly a matter of opinion, so please take it as input, not a directive.

Figure 2 is even more confusing—you have dotted arrows going between the client and server, and solid arrows going two and between two transport boxes.   Is there a reason to have the two sets of arrows?   I get the value of showing that more than one transport is possible, but why the dotted arrows here?   Also, why is the arrow between the database and server unidirectional?   Doesn't the server query the database?   Again, this is just my opinion, but I really encourage you to consider changing this diagram.