Re: [tcpm] TCP Tuning for HTTP - update

[Mark Nottingham <[e-mail]>]

Joe,

I've pinged some ADs to weigh in on this.

In the meantime -

> On 17 Aug 2016, at 3:23 PM, Joe Touch <[e-mail]> wrote:
> 
> Plagiarism requires only that the material was published elsewhere
> before. Intent has no bearing.

So to paraphrase, you're accusing Daniel of failure to cite a relevant source out of ignorance in the first case... 


> In addition, I informed the author - and both lists - about this over 5
> months ago. You might claim that the first two versions were issued out
> of ignorance, but you cannot claim that of the update.

... and then continuing to do so after being notified.

Correct?

Looking over <http://www.isi.edu/touch/pubs/ton97.pdf> and <http://www.isi.edu/touch/pubs/infocomm99/infocomm99-web/>, I'm having trouble identifying passages that are plagiarised; can you show us?

In particular, the latter paper proposes TIME-WAIT negotiation using a TCP option, sending a RST from clients, and a HTTP extension, whereas Daniel's draft only says this about TIME_WAIT:

"""
2.5.  Lower the TCP FIN timeout


   High connection completion rates will consume ephemeral ports
   quickly.  Lower the time during which connections are in FIN-WAIT-2/
   TIME_WAIT states so that they can be purged faster and thus maintain
   a maximal number of available sockets.  The primitives for the
   assignment of these values were described in [RFC0793], however
   significantly lower values are commonly used.


2.6.  Reuse sockets in TIME_WAIT state


   When running backend servers on a managed, low latency network you
   might allow the reuse of sockets in TIME_WAIT state for new
   connections when a protocol complete termination has occurred.  There
   is no RFC that covers this behaviour.
"""

So, where is the plagiarism?

Also, how do you reconcile that with the statement in your original e-mail that the draft repeats your material "sometimes correctly, sometimes in error"? Have you considered that what you consider to be an error in his plagiarism might in fact be a different idea (no matter whose is ultimately correct)?


>> If that's the case, I'd observe that the IETF isn't an academic publisher, and acknowledging all prior work in an area is neither practical, nor required, nor current practice.
> Plagiarism isn't an issue limited to academic environments. Publication
> of a document on the web is still publication.

Sure. It also isn't a legal issue in this form (unless you're asserting copyright?). Effectively, it's a cultural norm. Again, I will point out that in the culture of the IETF, we historically have not cited the complete provenance of every idea, both because it's impractical and because it doesn't benefit the reader. 

As far as I know, the IETF does not have a stated position about what you regard as PLAGIARISM. Hopefully we can get some clarity about that from the ADs, as well as some definitive evidence of what you're asserting.


>> On the other hand, if it turns out that directing readers toward other documents (including yours) adds value, a reference might make sense.
> 
> Those docs explain the issues more correctly and in more detail. That
> should add enough value.
> 
> The real question is whether this draft adds value to those - which are
> *already published*.
> 
> 
>> 
>>> Not only of two of my works, but of many others that pointed out most of
>>> the information summarized in this doc.
>>> 
>>> Second, the step of "adoption" needs to wait until there's something new
>>> here that wasn't known 20 years ago and the issue of plagiarism is
>>> addressed.
>> Other people in the HTTP *and* TCP communities have commented that such a document would be very useful, whether or not it's something "new that wasn't known 20 years ago". 
> 
> We don't need to issue new documents for people who don't read old ones.



--
Mark Nottingham   https://www.mnot.net/