A Reputation Response Set for Email Identifiers
draft-ietf-repute-email-identifiers-10

[Ballot discuss]
I wasn't sure whether to put this on the model draft or this draft but since this question is specific to email I figured here would be better:

In reading the draft, it seems to assume a single value for RFC5321.MailFrom and RFC5322.From.  If there's more than one value, and yes I know it's rare that this happens, are you getting a reputation of the aggregation of all the "froms" or is it split somwhow so that you only get reputation from one value? (I hope that makes sense)

[Ballot comment]
This document registers an item in a registry that is not yet created, but that requires expert review (via specification required).  Changing my DISCUSS on the creating document to clarify that it's not necessary for IETF consensus RFCs.

[Ballot discuss]
This is for the responsible AD, and no response from the document authors or shepherd is necessary.

This document regusters an item in a registry that is not yet created, but that requires expert review.  A designated expert has to be assigned and has to approve this registration before we can approve the document.

[Ballot comment]
From 3.2:
      rfc5321.helo:  The RFC5321.Helo value used by the (see [SMTP])
        client

      rfc5321.mailfrom:  The RFC5321.MailFrom value of the envelope of
        the message (see [SMTP])

      rfc5322.from:  The RFC5322.From field of the message (see [MAIL])

Given that these data are not validated except in the case where SPF is used, it seems like a bad idea to maintain statistics on them.  The fact that someone is joe-jobbing me does not mean that my email address is meaningfully associated with spam, but it'll sure look like that given the way reputations are calculated.

If you want to retain these, you ought to mention the security problems associated with them in the security considerations section, but I really question the validity of using them at all.  They are certainly useful in combination with other information on a per-message basis, but I don't see how that can work with the repute data model.

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

  That document also defines a media type to
  contain a reputon for transport, and also creates a registry for
  reputation applications and the interesting parameters of each.

This should be: for a reputation application. Right? Since the reputons are valid for a single application.

IESG/Authors/WG Chairs:

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

We have questions about the action requested in this document.

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

IANA notes that the IANA actions requested in this document depend upon the publication of another document being considered by the IESG.

The IANA actions are dependent upon draft-ietf-repute-model-08.

QUESTION: The IANA Considerations section of the [I-D.REPUTE-MODEL]
said:

[[[
7.  IANA Considerations

  This document presents no actions for IANA.

  [RFC Editor: Please remove this section prior to publication.]

]]]

That seems to be contradict to section 4.1 of the draft document
[I-D.REPUTE-MODEL].  It said:

[[[
  Response Sets have symbolic names, and these have to be registered
  with IANA, in the Reputation Applications Registry, to prevent name
  collisions.  IANA registries are created in a separate document.
  Each definition of a Response Set also needs to define its registry
  entry.
]]]

Which document is responsible for the creation of the Reputation
Applications Registry?

Are both [I-D.REPUTE-MODEL] and draft-ietf-repute-email-identifiers
dependent upon draft-ietf-repute-considerations?


IANA understands that, upon approval of this document a single IANA action is required to be completed.

In the Reputation Application Registry created upon the approval of
draft-ietf-repute-model.txt a single reputation application is to be registered as follows:

QUESTION: see above.  Which document is the defining reference?
What is the registration procedure and what information should be
included in the "new" Reputation Application Registry created?

Application name: email-id
Short description: Evaluates DNS domain names or IP addresses found in email identifiers
Reference: [ RFC-to-be ]
Status: current
Subject: A string appropriate to the identifier of interest
Application-specific query parameters:
identity: (current)
Application-specific assertions:
abusive: (current)
fraud: (current)
invalid-recipients: (current)
malware: (current)
spam: (current)
Application-specific response set extensions:
identity: (current)

IANA understands that this action is the only one that needs 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 Response Set for Email Identifiers) to Proposed Standard


The IESG has received a request from the Reputation Services WG (repute)
to consider the following document:
- 'A Reputation Response Set for Email Identifiers'
  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 response set for describing assertions a
  reputation service provider can make about email identifers, for use
  in generating reputons.




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

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


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