Subject: [domainrep] Comments on draft-ietf-repute-email-identifiers-01

From: SM <[email-masked]>
Date: Sat, 17 Dec 2011 00:04:44 -0800

I have a few comments on 
draft-ietf-repute-email-identifiers-01.  BTW, some of the suggested 
text requires fine-tuning.

In the Abstract Section:

   "This document defines a vocabulary for describing email identifiers
    (typically authors or signers) with the application/reputon media
    type."

I suggest copying some text from the Introduction Section:

    This document defines a vocabulary for describing assertions a
    reputation service provider can make about email identifiers.

In Section 1:

   'This memo defines a "vocabulary" for describing reputation of an
    email identifier.  A "vocabulary" in this context is defined in
    [RFCxxxx]'

If the draft defines a vocabulary, the last part of the above does 
not make sense.

I suggest reusing material from the Feedback Report Type Values 
registry instead of the terms in Section 3.1.

  Abuse: The email identifier is associated with unsolicited email
         or some other kind of email abuse

  Fraud: The email identifier is associated with some kind of fraud
         or phishing activity

  Not-spam: The email identifier is associated with an indication about
            messages not considered to be spam

  Virus:    The email identifier is associated with viruses.

  Invalid-Recipients: The email identifier is associated with delivery
                    attempts to nonexistent recipients

Although I do not see how the last one fits in, I left it in.  In the 
above text, emphasis is on association with an email identifier.

Section 3.2 mentions that the "email-id" reputation application 
recognizes the following OPTIONAL extensions to the basic vocabulary 
defined in [RFCxxxx].  The list looks more like email identifiers 
instead of extensions to the vocabulary.  If so, swap this section 
with the previous one and provide a description of email identifiers.

In Section 3.2:

   "A reply that does not contain the IDENTITY or SOURCES extensions is
    making a non-specific statement about how the reputation returned was
    developed.  A client may use or ignore such a reply at its
    discretion."

I suggest moving this to the protocol document.  For now, leave it in 
and add a note.

In Section 4, there is a typo for "registration".

The RFC 2119 and RFC 5598 references should be normative.

Regards,
-sm

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sat, 24 Dec 2011 23:32:00 -0800

Hi SM,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of SM
> Sent: Saturday, December 17, 2011 12:05 AM
> To: [email-masked]
> Subject: [domainrep] Comments on draft-ietf-repute-email-identifiers-01
> 
> In the Abstract Section:
> 

Works for me, except I think it's appropriate to mention the media type because otherwise someone reading this abstract has no context.

> If the draft defines a vocabulary, the last part of the above does not
> make sense.

I changed it to "This memo specifies a vocabulary for describing...", removing the quotes and changing "defines" to "specifies", to make it clear the other document is the foundational one.

>          or some other kind of email abuse

This seems too general to be a useful assertion.

>   Fraud: The email identifier is associated with some kind of fraud

Modified the FRAUD definition to say, 'such as "phishing"'.  I'll probably be challenged to define that or refer to a definition of it; I'll try to find one.

>             messages not considered to be spam

Wouldn't you just assert the same thing here as one minus the SPAM score?

>   Virus:    The email identifier is associated with viruses.

This also seems a little too general.  I prefer the current MALWARE definition.

> instead of extensions to the vocabulary.  If so, swap this section with
> the previous one and provide a description of email identifiers.

It allows the reputation provider to make a statement about how its score should be applied.  For example, if you don't specify the context somehow as part of the query (or implicitly based on who you're asking), the provider could tell you "this is the SPAM score for example.com as long as you mean to use it to evaluate DKIM signature domains".

The email-id vocabulary is a set of keywords and extensions to the base vocabulary defined in the "model" document.  So I believe it makes sense to put it where it is.

> I suggest moving this to the protocol document.  For now, leave it in

IDENTITY and SOURCES are email-id extensions, so moving them to either the model or media-type document won't make sense.  However, if we feel they ought to be made mandatory parts of all vocabularies, then that would make sense.

> The RFC 2119 and RFC 5598 references should be normative.

I agree with 2119, but do you really have to read 5598 to implement this?

Thanks,
-MSK