Last Call Review of draft-ietf-appsawg-rrvs-header-field-07
review-ietf-appsawg-rrvs-header-field-07-opsdir-lc-black-2014-03-27-00

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 primarily for the benefit of the operational
area directors.  

Summary: Ready with nits

This draft describes both an SMTP extension and a mail header field that
enable validation that an email address is still valid for the intended
recipient.  The draft is well-written and clear.

-- Nits:

a) Section 5.2 Header Field Used

   4.  RECOMMENDED: If local delivery is being performed, remove all
       instances of this field prior to delivery to a mailbox; if the
       message is being forwarded, remove those instances of this header
       field that were not discarded by steps 1-4 above.

Well, only step 2 can discard instances, so "steps 1-4" -> "step 2".

b) Section 9.2 Single-Recipient Aliases

   Upon delivery of an RRVS-protected message to an alias (acting in
   place of a mailbox) that results in relaying of the message to a
   single other destination, the usual RRVS check is performed.  The
   continuous ownership test here might succeed if a conventional user
   inbox was replaced with an alias on behalf of that same user, and
   this information is recorded someplace.  If the message is thus
   accepted, the relaying MTA can choose to do one of the following:

   1.  Do not include an RRVS parameter or header field when relaying to
       the new address.  (RECOMMENDED)

This exposes the message to relaying via an alias at the new address
to an unintended recipient.  That should be noted, although this
double-relaying feels like a case where the original user ought to be
responsible for ensuring that the first alias is updated when the
second alias is installed so that relaying occurs only once (which is
probably also worth noting).  Options 2 and 3 eliminate this exposure,
but note the additional operational complexity of doing so, and Section
5.2.1 indicates that a single alias-based relay is the design center
for this draft.

-- Operational Review Q&A (selected questions)

A.1.1. Has deployment been discussed?

	Yes, this is an extension to the existing SMTP protocol that would
	be added to existing implementations; deployment is straightforward.

A.1.3.  Has the migration path been discussed?

	Yes, there is good discussion of what happens when a downstream MTA
	does not support the SMTP extension or header field.  The header field
	is noted as transparent to implementations that do not support it,
	thereby providing functionality that can cross MTAs that lack support.

A.1.6.  Have suggestions for verifying correct operation been discussed?

	No, Section 7 describes relaying scenarios in which the protection
	provided by this protocol can be removed.  While doing so is NOT
	RECOMMENDED for MTA implementations, there is no obvious way for a
	sender or originating MTA to figure out what the scope of protection
	is when relaying occurs.

A.2   Do you anticipate any manageability issues with the specification?

	Not directly.  This functionality requires that receiving MTAs keep
	time-based records of address ownership, which has implications for
	management of such MTAs, but such MTA management implications are
	well beyond the scope of this draft.

Thanks,
--David
----------------------------------------------------
David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
david.black at emc.com        Mobile: +1 (978) 394-7754
----------------------------------------------------