A Media Type for Reputation Interchange
draft-ietf-repute-media-type-13

[Ballot comment]
And the antiparticle of the reputon is... a disreputon?

It seems strange that the context for the reputon is relegated to a parameter of the media type, when it's really a semantic attribute, not a type/encoding attribute.  Suggest moving it inside the reputon or reputon collection structures.

In "sample-size": JSON doesn't have a notion of the length of an integer, so saying "64-bit" here seems odd, unless you mean that it MUST NOT exceed 2**64-1.

I agree with Barry's comment that a collection of reputons (repu-meson?) should be an array rather than an object.

[Ballot discuss]
Three points, if you please (UPDATED):

1. RFC 4627 says that the names within a JSON object SHOULD be unique.  Yet this explicitly defines a setup wherein a reputation object contains multiple reputons, all of which have the same name, "reputon".  Why is that a good design?  Perhaps just make the reputation object be an array, where each reputon is an element of the array?

2. You specify information to be included with a registration request, but not the information that will actually be in the registry table.  As the policy for the registry is Specification required, I suggest that you make it clear that the information you're asking for has to be clearly documented in the specification, and that you limit the actual registry to a minimum of information -- maybe the first four items: name, description, reference, status.  That avoids an awkward and cluttered registry, and also avoids duplicatin of information in the registry that's already in the specification.  The actual registry information needs to be specified in the document, so IANA knows what to do.

3. Specification Required implies Expert Review, so you need to give instructions to the designated expert.  As part of that, you should say what the DE should consider when reviewing.  You can also say that no DE review is necessary if the specification is in an IETF consensus RFC.  (Alternatively on that last point, you can explicitly designate the policy as "Specification Required or IETF Review".)  If you want expert review *even* for IETF consensus documents, it would be good to say that explicitly.

[Ballot discuss]
Three points, if you please (UPDATED):

1. RFC 4627 says that the names within a JSON object SHOULD be unique.  Yet this explicitly defines a setup wherein a reputation object contains multiple reputons, all of which have the same name, "reputon".  Why is that a good design?  Perhaps just make the reputation object be an array, where each reputon is an element of the array?

2. You specify information to be included with a registration request, but not the information that will actually be in the registry table.  As the policy for the registry is Specification required, I suggest that you make it clear that the information you're asking for has to be clearly documented in the specification, and that you limit the actual registry to a minimum of information -- maybe the first four items: name, description, reference, status.  That avoids an awkward and cluttered registry, and also avoids duplicatin of information in the registry that's already in the specification.  The actual registry information needs to be specified in the document, so IANA knows what to do.

3. Specification Required implies Expert Review, so you need to give instructions to the designated expert.  As part of that, you should say what the DE should consider when reviewing.  You can also say that no DE review is necessary if the specification is in an IETF consensus RFC.  (Alternatively on that last point, you can explicitly designate the policy as "Specification Required or IETF Review.)  If you want expert review *even* for IETF consensus documents, it would be good to say that explicitly.

[Ballot discuss]
Three points, if you please:

1. An extremely easy one: the media type registration uses an obsolete email addres for Murray's contact info.

2. A harder one: RFC 4627 says that the names within a JSON object SHOULD be unique.  Yet this explicitly defines a setup wherein a reputation object contains multiple reputons, all of which have the same name, "reputon".  Why is that a good design?

3. You specify information to be included with a registration request, but not the information that will actually be in the registry table.  As the policy for the registry is Specification required, I suggest that you make it clear that the information you're asking for has to be clearly documented in the specification, and that you limit the actual registry to a minimum of information -- a name and reference, and maybe a short description.  That avoids an awkward and cluttered registry, and also avoids duplicatin of information in the registry that's already in the specification.  The actual registry information needs to be specified in the document, so IANA knows what to do.

[Ballot comment]
If I am reading this ABNF correctly:
    reputon = "{" [ reputon-object
        *(value-separator reputon-object) ] "}"

    reputon-object = "reputon" name-separator response-set

...then a reputon is one or more reputon objects, each of which is denoted with the string "reputon".  IOW:

{ "reputon": { ... }, "reputon": {...} }

Is that correct?  If so, isn't a little weird to use "reputon" as the string that denotes a reputon object, which is a _part_ of a reputon, not a whole reputon?  Or am I just not understanding the ABNF (which is quite possible—I'm hardly an expert).

The relationship between the term "clutch hitter" and "choke" is not going to be obvious to many readers (e.g., not obvious to me).  This may not be the best example to use to make the point you are making here.

Are assertions not allowed to contain whitespace characters?  I ask because you use names like "choke-hitter" and "is-good" instead of "choke hitter" and "is good".  Given that these appear in quotes, it seems unnecessary to substitute dashes for spaces.

IESG/Authors/WG Chairs:

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

IANA's reviewer has the following comments/questions:

QUESTION: Should the new registry have its own page, or be added to an existing page?

NOTE: If the fields to be listed in the registry are different from the fields to be included in the registration request, please add that list to the IANA Considerations section. Note that the list in draft-ietf-repute-email-identifiers appears to be different from the list provided here.

IANA understands that, upon approval of this document two IANA actions are required to be completed.

First, in the Application Media Types registry located at:

http://www.iana.org/assignments/media-types/application

a new application type is to be registered as follows:

application/reputon+json

with a reference of [ RFC-to-be ]

Second, IANA is to create a new registry called the Reputation Applications registry. The new registry is to be managed through Specification Required as defined by RFC 5226. There are no initial registrations in the new registry. However, IANA notes that the document draft-ietf-repute-evalu-identifiers, which is under review by the IESG, contains a single Reputation Application to be added to this new registry.

The registry will contain the following fields:

- Name of the application being registered or updated
- Short description of the application (i.e., the class of entity about which it reports reputation data)
- The reference
- New or updated status, which is to be one of:
current: The application is in current use
deprecated: The application is in current use but its use is discouraged
historic: The application is no longer in current use
- A description of the subject of a query within this reputation, and a legal syntax for the same
- An optional table of query parameters that are specific to this application; each table entry must include:
Name: Name of the query parameter
Status: (as above)
Description: A short description of the purpose of this parameter
Syntax: A reference to a description of valid syntax for the parameter's value
Required: "yes" if the parameter is mandatory, "no" otherwise
- A list of one or more assertions registered within this application; each table entry is to include:
Name: Name of the assertion
Description: A short description of the assertion, with specific meanings for values of 0.0 and 1.0
Scale: A short description of the scale used in computing the value
- An optional list of one or more response set extension keys for use within this application; each table entry is to include:
Name: Name of the extension key
Description: A short description of the key's intended meaning
Syntax: A description of valid values that can appear associated with the key

IANA understands that these two actions are the only ones that need 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 Media Type for Reputation Interchange) to Proposed Standard


The IESG has received a request from the Reputation Services WG (repute)
to consider the following document:
- 'A Media Type for Reputation Interchange'
  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 the format of reputation response data
  ("reputons"), the media-type for packaging it, and definition of a
  registry for the names of reputation applications and response sets.




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

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


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