A Reputation Query Protocol
draft-ietf-repute-query-http-11

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

   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?

See https://datatracker.ietf.org/doc/draft-ietf-repute-model/ballot/#benoit-claise

I support Ted's position.

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

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.