User talk:Dgtsyb/Archives/2008/05
Appearance
![]() | This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page. |
Reversions on Stream Control Transmission Protocol
May I ask why did you revert my edits to the Stream Control Transmission Protocol article? Reverting legitimate edits without any hints in the edit summary or article's talk page is rude and stops people from learning from their mistakes. -- intgr [talk] 13:57, 20 May 2008 (UTC)
- Sorry, I missed your explanation due to wrapping on the history view. You say "Change added text to quote not present in source of quote"
- It was not supposed to be a quote, it is a citation. Quoting any of these papers would be unnecessary because the article is about SCTP, not TCP.
- I was citing the fact that "TCP is relatively vulnerable to denial-of-service attacks, such as SYN attacks. This can be mitigated by the use of SYN cookies, but SYN cookies present challenges when used with TCP extensions." Both of the references clearly address the topic of SYN floods as a serious threat, and point out problems with the SYN cookies defense. I.e. RFC 4987:
- "This document describes TCP SYN flooding attacks, which have been well-known to the community for several years. Various countermeasures against these attacks, and the trade-offs of each, are described"
- "The problem with SYN cookies is that commonly implemented schemes are incompatible with some TCP options, if the cookie generation scheme does not consider them. For example, [...]"
- "however, SYN cookies may not be fully compatible with some TCP options, and may hamper development of future TCP extensions that require state. For these reasons, SYN cookies should not be enabled by default on systems that provide them"
- The Paper "Improving the Functionality of SYN Cookies" extensively explains the implications and limitations of SYN cookies on page 2, and notes that the proposed solution is not fully interoperable.
- -- intgr [talk] 14:24, 20 May 2008 (UTC)
- The section you added the text (and citation) to was a quote directly from RFC 2960. You made changes inside the quotation marks (blockquote). They you removed the blockquote but did not change the leading sentence which still identified the following text as a quote from RFC 2960. This is what I meant by "Change added text to quote not present in source of quote"; that is, your change added text to the quote from RFC 2960 that is not in RFC 2960.
- Also, the additional text and citation would detail TCP more than in necessary (particularly in an article on SCTP) as it does not alter the comparison that TCP is relatively vunlerable to SYN attacks, (relative to SCTP), regardless of countermeasures. I think that your citation would be better placed on the TCP page, as it is not pertinent to SCTP, but if you must replace it on SCTP, please place it outside the block quote so that it does not appear to come from RFC 2960 (which it does not). -- Dgtsyb 12:17, 21 May 2008 (UTC)
- Ouch, now I see; I didn't notice the fact that I was editing a quote, and was wondering why someone would use blockquote for a normal list. Thanks for fixing this up after me! :) -- intgr [talk] 22:51, 22 May 2008 (UTC)