A Reputation Query Protocol
RFC 7072
Yes
No Objection
Note: This ballot was opened for revision 10 and is now closed.
(Pete Resnick; former steering group member) Yes
(Adrian Farrel; former steering group member) No Objection
I support the Discusses and Comments relating to Security. Notwithstanding the reference to the Considerations document, this document should strengthen the use of the mechanisms it defines by observing that the use of reputation information has no value unless it can be trusted and therefore the mechanisms MUST be run over a secure transport. --- I did not see any mention of how the requester knows the identity of "the host providing reputation service". I think this should be mentioned in section 3.2
(Barry Leiba; former steering group member) No Objection
Clients SHOULD NOT repeat the query prior to the timestamp in the Expires field, or wait no less than one day if the Expires field is not present. Two non-blocking points about this: 1. It's easy to confuse the reference to the expires field with the expires field in the reputon. Maybe you can say something to avoid that possible confusion. 2. I can't make head nor tail of the apparent double negative after the comma. Will you please reword that?
(Benoît Claise; former steering group member) No Objection
(Brian Haberman; former steering group member) No Objection
(Gonzalo Camarillo; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Joel Jaeggli; former steering group member) No Objection
(Martin Stiemerling; former steering group member) No Objection
(Richard Barnes; former steering group member) (was Discuss) No Objection
(Sean Turner; former steering group member) No Objection
I support Ted's position.
(Spencer Dawkins; former steering group member) No Objection
(Stephen Farrell; former steering group member) No Objection
- I assume 6570 defines the syntax that "application", "service", "subject" and "assertion" have to follow and says if any percent encoding is needed? Don't you need to also say that here though or point to a bit of RFC 6570? - Seems odd to have the {service} in all templates but yet say it MUST be the same as the origin to which the template query was sent. - How does HTTP response caching interact with the expires field in the JSON reputon? I expected to be told that here. - I would have thought that setion 5 should encourage running this over TLS at least. Why not? (I have a related DISCUSS on the -model draft.)
(Stewart Bryant; former steering group member) No Objection
(Ted Lemon; former steering group member) (was Discuss) No Objection
The comment points listed below have been addressed. Thanks for working with me on this!
Relating to DISCUSS item 2, I think the only reason to give multiple templates is to address the optional "assertion" variable. If that is so, you might want to say so. If that is not so, you might want to explain what other use multiple templates could have. If you do the latter, you probably want to add some specification language that describes how that works. If you actually mean to do the latter, then this comment probably ought to be a DISCUSS, because the current text isn't explicit enough to allow for interoperability in that case, but I'm assuming you don't mean that.
E.g., perhaps you mean for templates to be able to have an explicit value for one of the variables, so that different queries can go down different query trees, for the benefit of pattern matching in the HTTP server. If so, I don't think this document actually allows that to be done.
DISCUSS points that have been cleared as a result of the -11 update:
1. Underspecified security considerations:
The security considerations section says:
In particular, the basic protocol used for
this service to retrieve a URI template from a well-known
location is basic HTTP, which is not secure without
certain extensions.
Why haven't you said what extensions would make it
secure? I assume you mean TLS? Shouldn't you
say that? In fact, is there a reason not to require TLS?
You could clear this either by satisfactorily explaining
why you didn't just say "TLS," by updating the document
to say TLS, and optionally by updating the document
to require TLS.
2. Underspecified template requirement:
In 3.2, you say that there might be more than one template,
but don't say why. Can you expand on that a bit? It
seems as if one reason for specifying multiple templates
would be so that you could specify one with and one
without the optional "assertion" variable.
There are two problems with this. First, I think specifying
two templates is required, not optional, or, alternatively, a
server that offers only a single template may effectively
either require or prohibit the optional "assertion" variable
by so doing.
You can clear this item by updating the document to explain
which you intend, or by explaining that I am completely
failing to understand what you actually intended, which is
of course quite possible.