[e2e] was Re: A message to authors - nsdi

[David P. Reed]

Putting "features" in the Berkeley Sockets interface doesn't solve the 
problem generically.  The problem has nothing to do with the lack of 
features "in the network".  Papering over that fact by positing that 
"there exists a generic solution" doesn't actually prove that there 
really is a generic *solution*.  Just a pile of crappy new features 
justified by a questionable claim of relevance.

The same logic justifies scanning airport passengers for Arabic names 
and presuming that contributes to "security".

Michael Welzl wrote:
>> The simplest possible answer to program committee stuff is for the 
>> committee to say: you will recieve a response by date A to acknowledge 
>> your submission and date X to accept or reject.   If you don't get 
>> responses by those dates, send inquiries to Y.  We will endeavor to 
>> reply by mail within one day. 
>>     
>
> That's a nice idea, but...
>
>  
>   
>> Note that all of the timeouts above are not "automagic".   They are 
>> protocol specifications.   They don't require guesses, but embed the 
>> timeout in the end-to-end protocol def.   There is no need for generic 
>> solutions.
>>     
>
> I disagree that there's no need for generic solutions, because of the
> mismatch between people's expectations about the service they get
> from email, and the service that the system offers (as well as the
> work involved in personally checking! Note that your solution above
> involves people typing stuff on keyboards - as the reliability declines,
> the scalability of that system will become limited by the hours that
> people can devote to that kind of solution).
>
> Cheers,
> Michael
>
>
>