Skip to main content

An Architecture for Reputation Reporting
draft-ietf-repute-model-10

Revision differences

Document history

Date Rev. By Action
2013-11-19
10 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2013-11-15
10 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2013-10-29
10 Roni Even Request for Last Call review by GENART Completed: Ready. Reviewer: Roni Even.
2013-10-18
10 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2013-09-30
10 (System) IANA Action state changed to No IC from In Progress
2013-09-30
10 (System) IANA Action state changed to No IC from In Progress
2013-09-30
10 (System) IANA Action state changed to In Progress
2013-09-30
10 (System) IANA Action state changed to In Progress
2013-09-30
10 Cindy Morgan State changed to RFC Ed Queue from Approved-announcement sent
2013-09-30
10 (System) RFC Editor state changed to EDIT
2013-09-30
10 (System) Announcement was received by RFC Editor
2013-09-30
10 Amy Vezza State changed to Approved-announcement sent from Approved-announcement to be sent
2013-09-30
10 Amy Vezza IESG has approved the document
2013-09-30
10 Amy Vezza Closed "Approve" ballot
2013-09-30
10 Amy Vezza Ballot approval text was generated
2013-09-28
10 Pete Resnick State changed to Approved-announcement to be sent from Approved-announcement to be sent::Point Raised - writeup needed
2013-09-17
10 Pete Resnick State changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation::AD Followup
2013-09-17
10 Benoît Claise [Ballot comment]
Thanks for addressing my DISCUSS points.

Editorial: expand the acronyms in figure 1
2013-09-17
10 Benoît Claise [Ballot Position Update] Position for Benoit Claise has been changed to No Objection from Discuss
2013-09-17
10 Murray Kucherawy New version available: draft-ietf-repute-model-10.txt
2013-09-16
09 Stephen Farrell
[Ballot comment]

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

"For interchanges that are sensitive to such exposures, it is
imperative …
[Ballot comment]

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.
2013-09-16
09 Stephen Farrell [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss
2013-09-12
09 (System) Sub state has been changed to AD Followup from Revised ID Needed
2013-09-12
09 Murray Kucherawy IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2013-09-12
09 Murray Kucherawy New version available: draft-ietf-repute-model-09.txt
2013-09-12
08 Cindy Morgan State changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2013-09-12
08 Gonzalo Camarillo [Ballot Position Update] New position, No Objection, has been recorded for Gonzalo Camarillo
2013-09-11
08 Adrian Farrel
[Ballot comment]
I welcome the inclusion of a Privacy Considerations section, but I wonder whether it goes far enough.

In Section 2 you observe:
  …
[Ballot comment]
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.
2013-09-11
08 Adrian Farrel [Ballot Position Update] New position, No Objection, has been recorded for Adrian Farrel
2013-09-11
08 Richard Barnes [Ballot Position Update] New position, No Objection, has been recorded for Richard Barnes
2013-09-11
08 Sean Turner
[Ballot comment]
I support Stephen's discuss position.

Figure 1: There can be more than one author of an email message, so should figure 1 indicate …
[Ballot comment]
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?
2013-09-11
08 Sean Turner [Ballot Position Update] New position, No Objection, has been recorded for Sean Turner
2013-09-11
08 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko
2013-09-10
08 Barry Leiba [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba
2013-09-10
08 Ted Lemon
[Ballot comment]
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 …
[Ballot comment]
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.
2013-09-10
08 Ted Lemon [Ballot Position Update] Position for Ted Lemon has been changed to No Objection from Discuss
2013-09-10
08 Ted Lemon
[Ballot discuss]
Section 4.1 appears to be confusing two different things by referring to them with the same term: "response set."  I think a response …
[Ballot discuss]
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.

In order to address this DISCUSS, you need to reword the first paragraph of section 4.1 so that it clearly distinguishes between response sets and instances of response sets—that is, the data type from a collection of data of that type.  Suggestion:

OLD:
  A "Response Set" comprises those data that are returned in response
  to a reputation query about a particular entity.  The types of data
  are specific to an application; the data returned in the evaluation
  of email senders would be different than the reputation data returned
  about a movie or a baseball player.
NEW:
  A "Response Set" is a data representation for data that is returned
  in response to a reputation query about a particular entity.  The
  data representation is specific to the application; the type of
  reputation data returned in the evaluation of email senders
  would be different than that returned about a movie or a
  baseball player.

BTW, I realize that this DISCUSS could be taken as merely a pedantic comment; the reason I think it's DISCUSS-worthy is that a lack of clarity about what a "response set" is could bite you down the road if this proposal sees widespread adoption.
2013-09-10
08 Ted Lemon Ballot discuss text updated for Ted Lemon
2013-09-10
08 Ted Lemon
[Ballot discuss]
Section 4.1 appears to be confusing two different things by referring to them with the same term: "response set."  I think a response …
[Ballot discuss]
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.

In order to address this DISCUSS, you need to reword the first paragraph of section 4.1 so that it clearly distinguishes between response sets and instances of response sets—that is, the data type from a collection of data of that type.  Suggestion:

OLD:
  A "Response Set" comprises those data that are returned in response
  to a reputation query about a particular entity.  The types of data
  are specific to an application; the data returned in the evaluation
  of email senders would be different than the reputation data returned
  about a movie or a baseball player.
NEW:
  A "Response Set" is a data representation for data that is returned
  in response to a reputation query about a particular entity.  The
  data representation is specific to the application; the type of
  reputation data returned in the evaluation of email senders
  would be different than that returned about a movie or a
  baseball player.

BTW, I realize that this DISCUSS could be taken as merely a pedantic comment; the reason I think it's DISCUSS-worthy is that a lack of clarity about what a "response set" is could bite you down the road if this proposal sees widespread adoption.  Right now, this isn't a serious problem, and it won't be unless the proposal catches on.
2013-09-10
08 Ted Lemon Ballot discuss text updated for Ted Lemon
2013-09-10
08 Ted Lemon
[Ballot discuss]
Section 4.1 appears to be confusing two different things by referring to them with the same term: "response set."  I think a response …
[Ballot discuss]
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.

In order to address this DISCUSS, you need to reword the first paragraph of section 4.1 so that it clearly distinguishes between response sets and instances of response sets—that is, the data type from a collection of data of that type.  Suggestion:

OLD:
  A "Response Set" comprises those data that are returned in response
  to a reputation query about a particular entity.  The types of data
  are specific to an application; the data returned in the evaluation
  of email senders would be different than the reputation data returned
  about a movie or a baseball player.
NEW:
  A "Response Set" is a data representation for data that is returned
  in response
  to a reputation query about a particular entity.  The data
  representation is specific to the application; the type of
  reputation data returned in the evaluation of email senders
  would be different than that returned about a movie or a
  baseball player.

BTW, I realize that this DISCUSS could be taken as merely a pedantic comment; the reason I think it's DISCUSS-worthy is that a lack of clarity about what a "response set" is could bite you down the road if this proposal sees widespread adoption.  Right now, this isn't a serious problem, and it won't be unless the proposal catches on.
2013-09-10
08 Ted Lemon Ballot discuss text updated for Ted Lemon
2013-09-10
08 Ted Lemon
[Ballot discuss]
Section 4.1 appears to be confusing two different things by referring to them with the same term: "response set."  I think a response …
[Ballot discuss]
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.

In order to address this DISCUSS, you need to reword the first paragraph of section 4.1 so that it clearly distinguishes between response sets and instances of response sets—that is, the data type from a collection of data of that type.  Suggestion:

OLD:
  A "Response Set" comprises those data that are returned in response
  to a reputation query about a particular entity.  The types of data
  are specific to an application; the data returned in the evaluation
  of email senders would be different than the reputation data returned
  about a movie or a baseball player.
NEW:
  A "Response Set" is a data representation for data that is returned
  in response
  to a reputation query about a particular entity.  The data representation
  is specific to the application; the type of reputation data returned in the
  evaluation of email senders would be different than that returned
  about a movie or a baseball player.

BTW, I realize that this DISCUSS could be taken as merely a pedantic comment; the reason I think it's DISCUSS-worthy is that a lack of clarity about what a "response set" is could bite you down the road if this proposal sees widespread adoption.  Right now, this isn't a serious problem, and it won't be unless the proposal catches on.
2013-09-10
08 Ted Lemon
[Ballot comment]
The box around the DKIM signer and validator in figure 1 is a bit confusing.  Is it really necessary?  I know the technology …
[Ballot comment]
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.
2013-09-10
08 Ted Lemon [Ballot Position Update] New position, Discuss, has been recorded for Ted Lemon
2013-09-10
08 Stephen Farrell
[Ballot discuss]

8.1 says it is "imperative" to protect sensitive information
in transit. I have no idea how DNS is a suitable transport for
that …
[Ballot discuss]

8.1 says it is "imperative" to protect sensitive information
in transit. I have no idea how DNS is a suitable transport for
that without a way to encrypt data accessed via the DNS.  In
addition, there doesn't seem to be any object-level data
integrity/origin-authentication scheme defined for the non-DNS
transports. And you don't even recommend TLS for the http
transport. How's that all fit together?
2013-09-10
08 Stephen Farrell
[Ballot comment]

- intro: "community or the Internet public generally" is
misleading to the point of being plain wrong. There is
afaik no concept that …
[Ballot comment]

- intro: "community or the Internet public generally" is
misleading to the point of being plain wrong. There is
afaik no concept that repute will use the community or the
Internet public generally at all - its meant for companies
to make money providing useful services as I understand
it. This seems like badly misleading overselling.

- 4.1.1 says the rating is between 0.0 and 1.0, which is
fine. But what precision is the finest granularity? Is
0.000000000000000000000000001 ok to use? Is that transport
dependent or not? If it is, why is it? If its not, why isn't
it specified here?

- the -media-type draft says that ratings could be linear or
e.g. exponential I don't get why that is transport specific
and not specified here. Am I missing something?

- section 8 is missing a consideration: if someone asks a
reputation provider about identifier X then that provider now
knows that X probably exists and can start making a list of
the X's and who's asked about them. That could be privacy
sensitive.
2013-09-10
08 Stephen Farrell [Ballot Position Update] New position, Discuss, has been recorded for Stephen Farrell
2013-09-10
08 Stewart Bryant [Ballot Position Update] New position, No Objection, has been recorded for Stewart Bryant
2013-09-10
08 Brian Haberman [Ballot comment]
Non-blocking... I agree with Joel's assessment that there are some missing pieces to this document series.
2013-09-10
08 Brian Haberman [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman
2013-09-10
08 Pete Resnick State changed to IESG Evaluation from Waiting for AD Go-Ahead
2013-09-10
08 (System) State changed to Waiting for AD Go-Ahead from In Last Call (ends 2013-09-10)
2013-09-09
08 Benoît Claise
[Ballot discuss]
1. The notion of application is not clear, and lead to some ambiguities.

Example 1:
OLD: IANA registries are created in a separate …
[Ballot discuss]
1. The notion of application is not clear, and lead to some ambiguities.

Example 1:
OLD: IANA registries are created in a separate document.

NEW: IANA registries are created in a separate document, application-specific.

Example 2: you don't say that reputon are application-specific. This is a key concept

Example 3:

  One of the key properties of a Response Set is called an Assertion.
  Assertions are claims made about the subject of a reputation query.
  For example, one might assert that a particular restaurant serves
  good food.  In the context of this model, the assertion would be
  "serves good food".

Isn't it?

  In the context of this model, the assertion would be
  "serves good food" for the application "restaurant"?

Because I guess that "serves good food" is not valid for email

You see, an application definition and explaining that reputon are per application would clarify a lot of things.

2.
The document discussed the Response Set, but doesn't tell what is contained in the Query (*) So I can only guess that the application is part of query. Explaining what MUST/SHOULD/MAY be part of the query and reply are important topics for an architecture document.
Also, can I query: get me all the reputons you know about the application "application context = X" and "identity = Y". I'm asking for good food, but I might interested to know that they have good wine, or slow service, etc...
It's a basic answer the architecture document should be answering (**)

(*) is this http://datatracker.ietf.org/doc/draft-ietf-repute-query-http/ section 3.1

    The components to the question being asked comprise the following:

      o  The subject of the query;

      o  The name of the host, or the IP address, at which the reputation
          service is available;

      o  The name of the reputation application, i.e., the context within
          which the subject is being evaluated;

      o  Optionally, name(s) of the specific reputation assertions or
          attributes that are being requested.

(**) I eventually found the information in http://datatracker.ietf.org/doc/draft-ietf-repute-media-type/

  If a client makes a
  request about a subject but does not specify an assertion of
  interest, the server can return reputons about any assertion for
  which it has data; in effect, the client has asked for any available
  information about the subject.  A client that receives an irrelevant
  reputon simply ignores it.


3.

  Each application requires its own specification of the Response Set.

What I understand now (after speaking to Pete who clarified a few things for me) is that each application requires its own registry, with its own set of reputons, but not necessary its own new protocol, with its own new encoding. http://datatracker.ietf.org/doc/draft-ietf-repute-query-http/ is one example of protocol encoding, and this could be reused.
This was very confusing to me.

It seems that there are good piece of information in the different drafts to solve the points 2 and 3 (without rewriting or cutting and pasting a lot of information between the different drafts, which would be ideal solution obviously), but those drafts are not even referenced.
At the very minimum, you would need pointers like the following:

  The key pieces of data found in a reputon for all reputation
  applications are defined in http://datatracker.ietf.org/doc/draft-ietf-repute-media-type/ section 3.1

  The ABNF syntax of a reputon is specified in http://datatracker.ietf.org/doc/draft-ietf-repute-media-type/ section XXX
 
  Some good examples (and you would need these to understand this architecture: OK, no need to mention this :-))
  are specified at http://datatracker.ietf.org/doc/draft-ietf-repute-media-type/ section 6.2

  http://datatracker.ietf.org/doc/draft-ietf-repute-query-http/ specifies one example of protocol encoding:
  over the Hypertext Transfer Protocol using JSON as the payload meta-format. Other encodings could be envisaged.
 

draft-ietf-repute-media-type must be normative, right?

Bottom line: assuming that the architecture draft is the first draft a newcomer to the repute work will read, it lacks some key pieces of information. And this information is spread across the different drafts. Once you have the different pointers, I advice you to review the 4 drafts  with the fresh mind of a newcomer, and if the story is complete.
Therefore, this DISCUSS is valid for the set of 4 repute documents.
2013-09-09
08 Benoît Claise
[Ballot comment]
Editorial: expand the acronyms in figure 1

As OPS AD, this one makes me happy, even if I still have to read the …
[Ballot comment]
Editorial: expand the acronyms in figure 1

As OPS AD, this one makes me happy, even if I still have to read the draft

9.3. Further Discussion

  Numerous other topics related to use and management of reputation
  systems can be found in [I-D.REPUTE-CONSIDERATIONS].

From the draft title/abstract, it might be more appropriate to say

9.3. Further Discussion
  Numerous other topics related to operational considerations of reputation
  systems can be found in [I-D.REPUTE-CONSIDERATIONS].


Not really a DISCUSS, but please consider them or come back to me if you disagree.

- I'm confused by the title. A model?
The abstract says: an architecture
We have architectures, frameworks, (with some disagreement between the two).
Is there really a need for having a third term "model"?
Why don't you simply call it architecture?

- Figure 1/2 and the related text are not consistent.

Section 2 speaks about client/server, then figure 1 speaks about Identifier Assessor
and Reputation Service, then figure 2 speaks about client/server again.
What you call a Client in figure 2 is the Identifier Assessor in figure 1, and the server in figure 2 is the Reputation Service in figure 1. Correct?
It would be great to be consistent and to clearly explain that the protocol is between Identifier Assessor
and Reputation Service.
2013-09-09
08 Benoît Claise [Ballot Position Update] New position, Discuss, has been recorded for Benoit Claise
2013-09-09
08 Martin Stiemerling [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling
2013-09-09
08 Joel Jaeggli
[Ballot comment]
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 …
[Ballot comment]
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.
2013-09-09
08 Joel Jaeggli [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli
2013-09-07
08 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2013-09-07
08 Pete Resnick Ballot has been issued
2013-09-07
08 Pete Resnick [Ballot Position Update] New position, Yes, has been recorded for Pete Resnick
2013-09-07
08 Pete Resnick Created "Approve" ballot
2013-09-07
08 Pete Resnick Ballot writeup was changed
2013-09-05
08 Jean Mahoney Request for Last Call review by GENART is assigned to Roni Even
2013-09-05
08 Jean Mahoney Request for Last Call review by GENART is assigned to Roni Even
2013-09-05
08 Tero Kivinen Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Donald Eastlake.
2013-09-04
08 (System) IANA Review state changed to IANA OK - No Actions Needed from Version Changed - Review Needed
2013-09-04
08 Pearl Liang
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-repute-model-08, which is currently in Last Call, and has the following comments:

We have a comment about this document. …
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-repute-model-08, which is currently in Last Call, and has the following comments:

We have a comment about this document.

We understand that, upon approval of this document, there are no IANA Actions that need completion. IANA requests that the IANA Considerations section of the document remain in place upon publication.

NOTE: Section 4 of this draft document mentioned a new registry called
Reputation Applications Registry.  From separate conversions,
the new registry is defined in draft-ietf-repute-media-type. 
Authors, please check if draft-ietf-repute-model should cite
draft-ietf-repute-media-type for the creation of the Reputation
Applications Registry.

If this assessment is not accurate, please respond as soon as possible.
2013-08-29
08 Jean Mahoney Request for Last Call review by GENART is assigned to Roni Even
2013-08-29
08 Jean Mahoney Request for Last Call review by GENART is assigned to Roni Even
2013-08-27
08 Amy Vezza
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 Model for Reputation Reporting) …
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 Model for Reputation Reporting) to Proposed Standard


The IESG has received a request from the Reputation Services WG (repute)
to consider the following document:
- 'A Model for Reputation Reporting'
  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-09-10. 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.

This is a new Last Call on this document. It was previously in Last Call
for Informational, but after some Last Call comments, the WG decided
that it would be more appropriate on the standards track. The due date
has been extended accordingly.


Abstract


  This document describes a general architecture for a reputation-based
  service and a model for requesting reputation-related data over the
  Internet, where "reputation" refers to predictions or expectations
  about an entity or an identifier such as a domain name.  The document
  roughly follows the recommendations of RFC4101 for describing a
  protocol model.




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

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


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


2013-08-27
08 Amy Vezza State changed to In Last Call from Last Call Requested
2013-08-27
08 Pete Resnick Last call was requested
2013-08-27
08 Pete Resnick State changed to Last Call Requested from In Last Call
2013-08-27
08 Pete Resnick Last call announcement was changed
2013-08-27
08 Pete Resnick Last call announcement was generated
2013-08-27
08 Pete Resnick Intended Status changed to Proposed Standard from Informational
2013-08-27
08 Pete Resnick Last call announcement was generated
2013-08-27
08 Pete Resnick Last call announcement was generated
2013-08-27
08 Murray Kucherawy IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed
2013-08-27
08 Murray Kucherawy New version available: draft-ietf-repute-model-08.txt
2013-08-20
07 (System) IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed
2013-08-20
07 Amanda Baber
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-repute-model-07, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require …
IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-repute-model-07, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

If this assessment is not accurate, please respond as soon as possible.

IANA requests that the IANA Considerations section of the document remain in place upon publication.
2013-08-18
07 Pete Resnick Placed on agenda for telechat - 2013-09-12
2013-08-16
07 Tero Kivinen Request for Last Call review by SECDIR is assigned to Donald Eastlake
2013-08-16
07 Tero Kivinen Request for Last Call review by SECDIR is assigned to Donald Eastlake
2013-08-15
07 Jean Mahoney Request for Last Call review by GENART is assigned to Roni Even
2013-08-15
07 Jean Mahoney Request for Last Call review by GENART is assigned to Roni Even
2013-08-15
07 Cindy Morgan IANA Review state changed to IANA - Review Needed
2013-08-15
07 Cindy Morgan
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 Model for Reputation Reporting) …
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 Model for Reputation Reporting) to Informational RFC


The IESG has received a request from the Reputation Services WG (repute)
to consider the following document:
- 'A Model for Reputation Reporting'
  as Informational RFC

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 describes a general architecture for a reputation-based
  service and a model for requesting reputation-related data over the
  Internet, where "reputation" refers to predictions or expectations
  about an entity or an identifier such as a domain name.  The document
  roughly follows the recommendations of RFC4101 for describing a
  protocol model.




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

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


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


2013-08-15
07 Cindy Morgan State changed to In Last Call from Last Call Requested
2013-08-15
07 Pete Resnick Last call was requested
2013-08-15
07 Pete Resnick Ballot approval text was generated
2013-08-15
07 Pete Resnick State changed to Last Call Requested from AD Evaluation::AD Followup
2013-08-15
07 Pete Resnick Last call announcement was generated
2013-08-15
07 Pete Resnick Intended Status changed to Informational from None
2013-08-15
07 Pete Resnick Last call announcement was generated
2013-08-15
07 Pete Resnick Last call announcement was generated
2013-07-12
07 Pete Resnick Ballot writeup was changed
2013-07-12
07 Pete Resnick Ballot writeup was generated
2013-07-12
07 (System) Sub state has been changed to AD Followup from Revised ID Needed
2013-07-12
07 Murray Kucherawy New version available: draft-ietf-repute-model-07.txt
2013-07-12
06 Pete Resnick
Discussed with author (MK) - Update to this and to http-query document to make clear that the two-stage nature of the query is http specific, …
Discussed with author (MK) - Update to this and to http-query document to make clear that the two-stage nature of the query is http specific, not part of the model itself.
2013-07-12
06 Pete Resnick State changed to AD Evaluation::Revised I-D Needed from AD Evaluation::AD Followup
2013-07-04
06 Pete Resnick State changed to AD Evaluation::AD Followup from AD Evaluation::Point Raised - writeup needed
2013-07-03
06 Murray Kucherawy New version available: draft-ietf-repute-model-06.txt
2013-06-06
05 Murray Kucherawy New version available: draft-ietf-repute-model-05.txt
2013-05-25
04 Pete Resnick Waiting for reply from authors/shepherds.
2013-05-25
04 Pete Resnick State changed to AD Evaluation::Point Raised - writeup needed from AD Evaluation
2013-05-25
04 Pete Resnick Changed document writeup
2013-05-20
04 Pete Resnick Misunderstood chair. This document is ready for publication. Going ahead with AD Evaluation.
2013-05-20
04 Pete Resnick State changed to AD Evaluation from AD Evaluation::External Party
2013-05-20
04 Pete Resnick Waiting for go-ahead from chair.
2013-05-20
04 Pete Resnick State changed to AD Evaluation::External Party from AD Evaluation
2013-03-21
04 Pete Resnick State changed to AD Evaluation from Publication Requested
2013-03-04
04 Stephanie McCammon New version available: draft-ietf-repute-model-04.txt
2013-02-25
03 Pete Resnick State changed to Publication Requested from AD is watching
2013-02-25
03 Dave Crocker Annotation tag Doc Shepherd Follow-up Underway cleared.
2013-02-25
03 Dave Crocker Changed protocol writeup
2013-02-25
03 Dave Crocker IETF state changed to Submitted to IESG for Publication from In WG Last Call
2013-02-25
03 Dave Crocker Changed shepherd to DCrocker
2012-11-13
03 Murray Kucherawy New version available: draft-ietf-repute-model-03.txt
2012-11-09
02 Dave Crocker IETF state changed to In WG Last Call from WG Document
2012-06-15
02 Andrew Sullivan New version available: draft-ietf-repute-model-02.txt
2012-03-05
01 Andrew Sullivan New version available: draft-ietf-repute-model-01.txt
2011-12-16
00 Dave Crocker discussed at ietf82; room consensus. no objection on mailing list, when queried.
2011-12-16
00 Dave Crocker IETF state changed to WG Document from Adopted by a WG
2011-12-16
00 Dave Crocker discussed at ietf82; room consensus. no objection on mailing list, when queried.
2011-12-16
00 Dave Crocker IETF state changed to Adopted by a WG from Call For Adoption By WG Issued
2011-12-16
00 Pete Resnick Draft added in state AD is watching
2011-11-29
00 (System) New version available: draft-ietf-repute-model-00.txt