Subject: Re: [apps-discuss] Applications Area Review of draft-ietf-appsawg-rrvs-header-field-05

From: Eric Burger <[email-masked]>
Date: Thu, 26 Dec 2013 12:53:20 -0500

Agreed

Sent from my mobile device. Thanks be to LEMONADE: http://www.standardstrack.com/ietf/lemonade
S2ERC: http://s2erc.georgetown.edu/
GCSC: http://gcsc.georgetown.edu/
Me: http://www.cs.georgetown.edu/~ eburger

-------- Original message --------
From: Hector Santos <[email-masked]> 
Date:12/26/2013  11:59 AM  (GMT-05:00) 
To: "Murray S. Kucherawy" <[email-masked]> 
Cc: Eric Burger <[email-masked]>,[email-masked],The IESG <[email-masked]>,IETF Apps Discuss <[email-masked]> 
Subject: Re: [apps-discuss] Applications Area Review of draft-ietf-appsawg-rrvs-header-field-05 

On 12/25/2013 1:31 AM, Murray S. Kucherawy wrote:
> On Tue, Dec 24, 2013 at 4:19 AM, Eric Burger
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     �
>>
>>
>>         Along the lines of the above, we could use a mechanism such
>>         as RFC3459. If you are a MUA and your SUBMIT server does not
>>         support RRVS, fail. If you are a SUBMIT server or MTA and
>>         the next hop does not support RRVS, fail.
>>
>>
>>     The latter is certainly an option, and some prefer it.� Section
>>     7 indicates that preference in general.� However, there is
>>     running code out there already that we need to acknowledge which
>>     isn't so strict.
>
>     Which part of �draft-� is not understood by the community? I
>     thought this was a standards track document, not an individual
>     informational documenting current practice.
>
>
> I don't believe "standards track document" and "documenting current
> practice" are mutually exclusive, are they?

IMO, in this case, yes, they are.  Given a short list of:

1) The unclear, "non-standard" definition of what the RRVS "time" is,
2) Its potential for inconsistent usage,
3) The high risk of user data exposure here, a Pandora Box consideration,
4) The risk of still sending and received unsecured messages,
5) No one is using this yet across the board, not in production mode 
yet, that I am aware of, etc.

This all sounds like an EXPERIMENT, not a standard track item.  It 
could be an INFORMATIONAL document at this time and probably better to 
be describing a problem looking for a solution. I am not sure the RRVS 
is it.  This is currently an experimentation with a very high 
potential of being only used for exclusive relationships, i.e. a joint 
venture (Yahoo and Facebook) with a technology transfer of information 
to better synchronized heterogeneous user databases.   To do this in a 
standard way, the RRVS time has to be better defined. It is not.

The "problem" has long existed for all Online Application Hosting 
Vendors, such as us with over 30 years of deployments systems in all 
market segments, all vendors that offer a public signup service had 
the same constraints. It absolutely did not nor does not apply to just 
the "big industrial" guys.  It applies to all market segments, small, 
large, even the hobbiest public service system and especially the 
smaller systems were user account expirations is more frequent.

What has changed since yesteryears is the higher collision rates of 
more people with similar user names, not only within the USA, but 
global, to be used for authentication and electronic media contact 
addresses.  In the past, the normal practice to deal with a collision 
was to just assign a different user id.

But if the user account was deleted (for whatever reasons), and then 
reclaimed by a different person or assigned to a different person by 
the owner domain, we have the email security risk this proposal is 
attempting to address.  So the problem is well understood, But I am 
not sure the RRVS is the solution without a well defined terminology 
for the TIME attribute.  It is too open-ended for this to be declared 
a standard.  I don't think it is correct to just say this is a local 
design/policy decision. There has to be some persistency and 
consistency in the public and private mail transport business.

Note, this is not to say I won't support it in our package, but I 
can't until that TIME value is better defined.  The way I see it from 
an software engineering standpoint, each potential RRVS client can 
have different definitions of what the RRVS time is and what also 
different fields of what it is suppose to be compared to in the 
receiver's local user database.  Overall, it sounds like it wants us 
to create a new "Change of Ownership Date" field in user databases. 
Yet, it also appears this means this is more of a 1 to Many multiple 
definition field -- one for each potential RRVS client sending mail to 
a user but each has their own idea for what this time is.  This means 
that a SENDER DOMAIN field may need to be added as well

     OwnerShipDateTime.DateTime
     OwnerShipDateTime.SenderDomain

Overall, this smells, walks and talks all like an experimentation.  We 
should slow down on labeling everything that comes out of here as a 
"Proposed Standard" when there hasn't been any long term, multiple 
vendors R&D done.

I suggest, change this to a experimental status and let Yahoo and 
Facebook work out the details of this "experiment" as far as what this 
RRVS TIME field is and come back in a few year and let us know how it 
worked out.  I think once the RRVS field is defined, we might see a 
higher potential for adoption and rest assured, this is one idea that 
can apply across all market segments, not just the big guys.

-- 
HLS