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

[Ballot comment]
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.

[Ballot comment]
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

[Ballot discuss]
The Introduction says "The mechanism is a two-stage query", but the first stage is never defined.  (That is, how the client gets the templat.). This document needs to define the first-stage query, or else make the description one-stage -- since if the first stage is undefined, the the template is just a configuration parameter.

[Ballot discuss]
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.

[Ballot discuss]
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.

[Ballot comment]
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.

[Ballot comment]
  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?

[Ballot comment]

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

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-repute-query-http-09.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA has however a follow-up action for this document.

We received the following comments/questions from the IANA's reviewer:

IANA understands that, upon approval of this document, there is a single action which IANA must complete.

In the Well-Known URI registry located at:

http://www.iana.org/assignments/well-known-uris

a single, new Well-known URI will be registered as follows:

URI Suffix: repute-template
Change controller: IETF
Reference: [ RFC-to-be ]
Related information:

NOTE: The Well-known URI registry is managed through Expert Review as defined by RFC 5226. We will initiate a request and send this to the designated
expert Mark Nottingham for review.

IANA understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed
until the document has been approved for publication as an RFC.
This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (A Reputation Query Protocol) to Proposed Standard


The IESG has received a request from the Reputation Services WG (repute)
to consider the following document:
- 'A Reputation Query Protocol'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-08-29. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document defines a mechanism to conduct queries for reputation
  information over the Hypertext Transfer Protocol using JSON as the
  payload meta-format.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-repute-query-http/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-repute-query-http/ballot/


No IPR declarations have been submitted directly on this I-D.

Discussed with author (MK) - Update to this and to model document to make clear that the two-stage nature of the query is http specific, not part of the model itself.

> == Document Writeup ==

> === 1. Summary ===
>
> Who is the document shepherd?

  D. Crocker


> Who is the responsible Area Director?

  P. Resnick


> Explain briefly what the intent of the document is (the document's
> abstract is usually good for this), and why the working group has
> chosen the requested publication type (BCP, Proposed Standard,
> Internet Standard, Informational, Experimental, or Historic).

    Once there is a validated identifier associated with an object or activity, it is possible to develop and communicate its behavioral "reputation".  The current draft is part of an effort to define a reputation query/report mechanism. This draft specifically defines the query/response protocol and its conveyance over HTTP.


> === 2. Review and Consensus ===
>
> Explain how actively the document was reviewed and discussed, by the
> working group and external parties, and explain in a general sense
> how much of the interested community is behind the document.  Explain
> anything notable about the discussion of the document.

  The document has gone through multiple drafts, over a period of time,
that were discussed in the working group. Discussion was mild and
supportive, with no significant controversy. The working group 'style'
was mostly of a small, collaborative set of active participants.

  The specified protocol is reasonable simple and flexible, tailored to
the semantics of requesting reputation-related attributes about a "subject".


> === 3. Intellectual Property ===
>
> Confirm that each author has stated that their direct, personal
> knowledge of any IPR related to this document has already been
> disclosed, in conformance with BCPs 78 and 79.  Explain briefly the
> working group discussion about any IPR disclosures regarding this
> document, and summarize the outcome.

  The author is highly experienced with IETF work and the document IPR
standard is the default.  No IPR concerns are anticipated.


> === 4. Other Points ===

  None noted.