[e2e] [unclassified] Re: 64-bit timestamps?

[David P. Reed]

[Top posting because it makes sense in this case, so one does not have 
to dig through intercalated replies as one follows the top level of a 
thread.  And multi-part miming because it is the most polite to the most 
diverse crowd of mail readers, as well as being a *standard* (Dave 
Crocker will verify this).]

Clearly I made a mistake in guessing what makes the introduction of 
64-bit TSOPT worthy of a query.  So let me avoid guessing why this was 
asked, since the only explanation offered by the author of the query was

Instead, I will ask the question that should be asked of every proposal: 
what problem would this solve, does it solve it fully, and is it a 
problem that is best answered by leaving it to the application in 
question?  (this is the end-to-end argument's core question - one that 
should be considered in every network protocol design).

AFAICT from the author's brief posting of his query, the rationale was a 
reference to "back in the day there was an expressed interest" and 
"would it be of some utility".  Neither of these are problem statements 
sufficient to justify a change that affects all TCP stacks on all platforms.

If the author is seeking help, perhaps he will grace us with an 
explanation of a problem that this proposal would be the best approach 
to solve?

I would point out that the sequence space and PAWS tend to fall into the 
category of "functions" that do not fully solve applications problems, 
but are merely "optimizations".  The text in RFC 1323 alludes to exactly 
this point in the cited Appendix B (which I will not requote for the 
readers' convenience here, given the authors' rage at my use of an email 
to cite a key section of design rationale).


On 09/09/2009 04:00 AM, William Allen Simpson wrote:
> David P. Reed wrote:
>> On 09/08/2009 06:42 PM, William Allen Simpson wrote:
>>> David P. Reed wrote:
>>>> In regard to DNS security issues, ...  But PAWS may not be useful, 
>>>> since DNS itself might be made to maintain state across 
>>>> connections, moving the problem out of TCP and into the app (DNS) 
>>>> layer where it probably belongs.
>>>>
>>> This has no relation to the question that I asked, which has no mention
>>> what-so-ever about DNS security.  Nor did I find the cut and paste 
>>> of an
>>> old familiar RFC appendix particularly informative, not even in fancy
>>> multi-part alternative html (instead of the native format)....
>>>
>>> In any case, I've been paying attention to the more recent 1323bis.
>>>
>> List moderator - please suspend Simpson's privileges; the rules 
>> suggest that his obnoxious behavior towards a helpful comment demand 
>> moderation until he stops behaving this way.
>>
> Or vice versa.  Must Mr. Reed "poison the well" of every discussion?
>
> I've fixed his top-posting (again), and his multipart alternative 
> (again).
>
> The comment was *not* helpful, as it bore no relation to the query, and
> his proof by assertion is not good argument.  Nor is his condescension
> appropriate behavior.
>
> Going forward, I'll do my best to ignore his posts, as long as they don't
> interfere with discussion on the merits.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.postel.org/pipermail/end2end-interest/attachments/20090909/cfb343f2/attachment.html