Attaching Meaning to Solicitation Class Keywords
draft-malamud-keyword-discovery-05

Moving the DISCUSS to COMMENT as per Brian Carpenter's request:

From Spencer Dawkins, Gen-Art reviewer:

Summary: This document is on the right track, but still has a couple of opportunities for improvement.

The reader has to work to dig out the goal here - I THINK the goal is "given an RFC 3865 solicitation class keyword, discover a URI that points to a resource that tells you what the RFC 3865 keyword actually means", but I'm still not sure about this. The document is correctly pointing to RFC 3865 for its context, but it doesn't stand on its own. Given this, the non-normative example is going to have a lot of influence on the reader's understanding.

(Thus pointing out another opportunity to use the proposed ISD mechanism to clump specifications. But I digress.)

The Security Considerations concern raised is really broad. Is it saying more than "DNSSEC would help a lot of things, including this mechanism", or is this mechanism simply subject to a broad class of insecure-DNS-based vulnerabilities? What is really at risk here? Even saying "in the absence of DNSSEC, this mechanism can be exploited to give mail users incorrect guidance on keyword interpretation", or something. Mumble.

   Use of a URI with the "https:" scheme without the use of DNSSEC makes
   an unwarranted illusion of authenticity and the possibility of active
   attacks a serious concern.

Moved DISCUSS to COMMENTS as requested by Mark Townsley:

The Abstract needs to be rewritten.

There is no Introduction, though Section 1 sorta-kinda looks like one in construction if not heading.

I agree with other DISCUSS points that this document does not *yet* stand on its own, and am concerned that there may security issues with passing around what amount to lightly obfuscated DNS names.

Nits:

>    inserted in a "No-Solicit:" header or in a trace field.  [RFC3865]
>    explicitly placed discovery of the meaning of a solicitation class

s/placed/places

>    keywords as outside of the scope of the basic ESMTP service

s/keywords/keyword

>    If that standard becomes widely deployed, a  mail message might

What standard? I assume RFC3865 (which is not a "Standard" in the strict sense), but since this is the start of a brand new paragraph it is not immediately clear what "that" is referring to. 

Also, there are multiple spaces before "mail" on this line.