Last Call Review of draft-levine-herkula-oneclick-06

Request Review of draft-levine-herkula-oneclick
Requested rev. no specific revision (document currently at 10)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2016-10-25
Requested 2016-09-21
Authors John Levine, Tobias Herkula
Draft last updated 2016-10-12
Completed reviews Genart Last Call review of -07 by Fernando Gont (diff)
Secdir Last Call review of -04 by Ben Laurie (diff)
Opsdir Last Call review of -06 by Victor Kuarsingh (diff)
Assignment Reviewer Victor Kuarsingh
State Completed
Review review-levine-herkula-oneclick-06-opsdir-lc-kuarsingh-2016-10-12
Reviewed rev. 06 (document currently at 10)
Review result Has Issues
Review completed: 2016-10-12


Dear Authors,

** Apologize for lateness, email stuck in my outbox from weekend

      I have reviewed this document as part of the Operational
      directorate's ongoing effort to review all IETF documents being
      processed by the IESG.  These comments were written with the
      intent of improving the operational aspects of the IETF drafts.
      Comments that are not addressed in last call may be included in AD
      reviews during the IESG review.  Document editors and WG chairs
      should treat these comments just like any other last call

      Document Reviewed - Signalling one-click functionality for list
      email headers

      Link to Document -


      This document provides a signalling method and model that provides
      facilities for a "one-click" list-unsubscribe.  The reasoning
      behind this advancement is due to the need for an efficient option
      for list-unsubscribe and operational behaviours observed in the
      field (such as mail software fetching URLs in mail header fields).

The document provides information on header requirements, syntax
      and use.

Text updates (suggestions / recommendations) are provided below
      the general feedback.

General Comments and Feedback:

The document provides the needed header information to provide
      the one-click facilities.  No specific recommendations are made as
      part of this review on changes to the updated header information. 
      However, although security considerations were listed within the
      document, there are a few open questions as to how the authors
      expect this new functionality to coexist with clients and mail
      systems that are not aware of the new one-click function/headers. 
      The document is not quite clear on how the backwards compatibility
      would work (and/or it's to obvious in the body text).

It's possible this information may be know by the typical reader
      of this document, however, it would be advisable that such
      information be specifically captured and highlighted (backwards
      compatibility and co-existence).  Given this is a standards track
      document, the information can be limited to expected protocol,
      client and mail system implementation behaviors.

Other comments and feedback are minor and listed in the section
      below.  To make it easier to know where the in-line review is
      associated with, I have also attached a high-lighted PDF version
      of the -07 draft (for quick reference).

      Textual Review, questions and feedback:

Abstract - ok

      Introduction - three suggestions


      BEFORE: Many mail systems allow

      recipients to report mail as spam or junk, and mail from senders

      a lot of junk reports often has poor deliverability.

      SUGGESTED: Many mail systems allow recipients to report mail as
      spam or junk, and senders whom are associated with

      a higher volume of junk reports will often experience poor ongoing
      deliverability as a result.

      BEFORE: ...since the recipients alternative to a difficult

      unsubscription process is to report mail from the sender as junk

      until it goes away.

      SUGGESTED: ... since the recipient’s alternative to a difficult
      unsubscription process

      is to report mail from the sender as junk until new mail delivery

      SUGGESTION: Define key terms used such as MUA (Mail User Agent). 

      Section 2 - ok

      Section 3.1 - comments below


      BEFORE: "An mail sender that wishes to enable one-click
      unsubscribes places..." 

      SUGGESTED " A mail sender that wishes to enable a one-click
      unsubscription places ... "


      BEFORE: "The server handling the

      unsubscription SHOULD verify that the hard to forge component is


      SUGGESTED: "The server handling the unsubscription SHOULD verify
      that the opaque identifier component is valid"


      TEXT to verify : "The mail

      sender MUST NOT return an HTTPS redirect, since redirected POST

      actions have historically not worked reliably" - is this a well
      known statement/condition which is unrefutable?

      OPTION: Can use language such as "... since redirected POST
      actions are considered unreliable".

      Section 3.2 - comments below


      BEFORE: "A mail receiver that wants do a one-click unsubscription
      performs an

      HTTPS POST to the HTTPS URI...."

      SUGGESTION" "A mail receiver that wishes to conduct a one-click
      unsubsription ..."


      OPS RELATED FEEDBACK: "When and how the user consent is obtained

      not part of this specification.". - would suggesting a few options
      to gain user consent useful here?  

      Section 4 - ok.

      Section 5 - comments below

      OPS RELATED FEEDBACK: You may want to put a box, or change the
      font type for the specification text to make it clear.

      Section 6 - ok.

      Section 7 - ok.

      Section 8 - 


      BEFORE: "Since the mailer’s server that receives the POST request
      cannot in

      general tell where the request coming from,..."

      SUGGESTED: " Since the mailer's server that receives the POST
      request cannot, in general, identify 

      where the request is coming from,.."


Victor K




 Adobe PDF document