Re: Last Call: <draft-kucherawy-dkim-atps-11.txt> (DKIM Authorized Third-Party Signers) to Experimental RFC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



At 11:38 30-11-2011, The IESG wrote:

The IESG has received a request from an individual submitter to consider
the following document:
- 'DKIM Authorized Third-Party Signers'
  <draft-kucherawy-dkim-atps-11.txt> as an Experimental 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@xxxxxxxx mailing lists by 2011-12-28. Exceptionally, comments may be

In Section 2:

  "Readers should be familiar with the material and terminology
   discussed in [MAIL] and [EMAIL-ARCH]."

The references to RFC 5598 and RFC 5322 should be normative.

In Section 3:

  "An Author participates in this protocol if it wishes to announce that
   a message from it (in the RFC5322.From sense) should be considered
   authentic as long as it bears a signature from any in a set of
   specified domains."

It's the domain and not the author which participates in this protocol. As a nit, the RFC 5598 term looks more like Originator instead of Author.

The Abstract section uses the term "authorization" whereas "authentic" is used in the above text. Shouldn't that be "considered as authorized"?

In Section 4.1:

  "When the Signer generates a DKIM signature on behalf of an Author, it
   MUST include an "atps" tag in the signature and include as its value
   the Author's domain name."

See above comment about originator.

In Section 6:

  "A Verifier implementing both ADSP and ATPS SHOULD treat a message for
   which the ATPS test described above passes as if it were signed by
   the author domain.  That is, a pass of ATPS means a pass for ADSP."

In plain English, this reads as an update of ADSP but this draft does not update RFC 5617.

In Section 8:

  "No actions are required by IANA at this time.  The following need
   only be applied if and when this specification reaches the Standards
   Track."

The IANA Considerations section is unusual. If no action is required at this time, the sub-sections are not needed. I suggest updating the "DKIM-Signature Tag Specification Registry" for the tags as they will appear on the Internet.

Regards,
-sm
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]