Subject: [tcpm] RFC 4614 bis comments

From: Martin Duke <[email-masked]>
Date: Mon, 11 Nov 2013 20:35:29 -0800

Alexander,

First of all, let me emerge from deep lurking to thank you for updating
this document. It is long overdue. Although I haven't been as involved in
TCP work as I would have liked, perhaps I can offer some constructive
comments based on the original philosophy of the RFC's organization.

Martin

********
EDITORIAL ISSUES:
Sec. 2: If RFC 5681 contains 3390 is 3390 a "core requirement?" It seems
like a novice could skip over it entirely. 5681 even refers to 3390 for
further background it they're interested. Recommendation: move RFC 3390 to
Section 6 (Support Documents).

Sec 3: I like how this section has been reorganized.

RFC 3042, 3465: At a minimum we should indicate this has been rolled into
RFC 5681. At most we could strike the reference entirely. Recommendation:
Move to Section 6.

Section 3.4: So I take it that, based on its inclusion in Section 3, we
specifically recommend F-RTO and Eifel Response over the alternatives? If
that is not the intent here than this section must be substantially revised.

Sec 6.6 Generally we do not separately list obsolete RFCs in this document.
>From the text I gather that everything but RFC 4022 is obsolete in this
section, so I recommend we keep the introductory text and the entry for RFC
4022.

****
NITS:

P.3 para 6: "...important implementation practices that ARE not currently
documented..."

RFC 6298, last sentence is worded ambiguously. Suggest "RFC 6298 updates
RFC 2988 by changing the initial RTO from 3s to 1s." (It can currently be
read to say that 2988 sets it to 1s.)

Sec 3.4. "implemented, and IPR status" -> "implemented, and concerns about
IPR status"

RFC 5682: "describes" -> "described"

Sec 3.6. "Header compressions schemes... these overhead." --> "Header
compression schemes for TCP/IP like "RObust Header Compression (ROHC) can
significantly compress this overhead."

Sec 3.7.
RFC 4953. "resets (RSTs)" -> "reset (RST)"

RFC 5961. "are less vulnerable" -> "less vulnerable"

Sec. 4.1 RFC 3124 : "which supports sharing information among TCP
connections as well" delete the words "as well". Taking it outside of
connections is not formally the same as sharing it between connections.

Sec. 4.4. "simultaneous" -> "simultaneously"; "additinal" -> "additional"

Sec. 5 "reclassifies" -> "reclassified"; "seen widespread" -> "seen
widespread deployment"

RFC 721: "has not been included" -> "was not included"

RFC 1078: "propose a protocol" -> "proposes a protocol"

RFC 6013: para 1: "to negotiates" -> "to negotiate";
para 2: "describes method to extent" -> "describes a method to extend"
para 3: "Although the RFC 6013 is publish in 2011" -> "Although RFC 6013
was published in 2011"

Section 6. "implementation advices can be found in Section 6.5" ->
"implementation advice can be found in Section 6.5"

Section 6.1. Is RFC 675 really "infamous?" Suggest "fundamental".

Section 6.2 RFC 3439 "extents" -> "extends"

Sec 6.4 RFC 5166 "Among others" -> "Among other topics"

Sec 6.7 RFC 5783 "The focus of the document are on" -> "The focus of the
document is"

Sec 6.8 RFC 1337 "Hazardsin" --> "Hazards in"

---

From: "Zimmermann, Alexander" <[email-masked]>
Date: Wed, 20 Nov 2013 10:29:21 +0000

Hi Martin,

thanks for reviewing the draft. Comments below.

Alex

Am 12.11.2013 um 05:35 schrieb Martin Duke <[email-masked]>:

> Alexander,
> 
> First of all, let me emerge from deep lurking to thank you for updating this document. It is long overdue. Although I haven't been as involved in TCP work as I would have liked, perhaps I can offer some constructive comments based on the original philosophy of the RFC's organization.
> 
> Martin
> 
> ********
> EDITORIAL ISSUES:
> Sec. 2: If RFC 5681 contains 3390 is 3390 a "core requirement?“

You are right.  I move rfc3390 into the (new) section  3.2.  Congestion Control Extensions

> It seems like a novice could skip over it entirely. 5681 even refers to 3390 for further background it they're interested. Recommendation: move RFC 3390 to Section 6 (Support Documents).

At the moment I suggest to not move RFC3390, RFC3042 and RFC3465 into sec. 7. Support Documents.
RFC 5861 does not obsolete any of these documents. All of them are still „valid“. Maybe in further, in particular
with 793bis, which obsolete a lot of RFC, we need a new subsection in sec. 7.

> Sec 3: I like how this section has been reorganized.

Thanks ;-)

> 
> RFC 3042, 3465: At a minimum we should indicate this has been rolled into RFC 5681.

Good idea

> At most we could strike the reference entirely. Recommendation: Move to Section 6.

See above.

> 
> Section 3.4: So I take it that, based on its inclusion in Section 3, we specifically recommend F-RTO and Eifel Response over the alternatives? If that is not the intent here than this section must be substantially revised.

IMO the roadmap „recommend“ nothing; it’s a survey. From the introduction:

„This document is not an update of RFC 1122 and is not a rigorous
standard for what needs to be implemented in TCP.  This document is
merely an informational roadmap that captures, organizes, and
summarizes most of the RFC documents that a TCP implementer,
experimenter, or student should be aware of.  Particular comments or
broad categorizations that this document makes about individual
mechanisms and behaviors are not to be taken as definitive, nor
should the content of this document alone influence implementation
decisions.“

and

„Note that the category of an RFC does not necessarily reflect its
current relevance.  For instance, RFC 5681 is nearly universally
deployed although it is only a Draft Standard.  Similarly, some
Informational RFCs contain significant technical proposals for
changing TCP.“

If it is not clear that we do not make any implementation recommendation
in this doc, we should instead work on introduction.

Further, the introductions says:

"This roadmap is divided into three main sections.  Section 2 lists
the RFCs that describe absolutely required TCP behaviors for proper
functioning and interoperability.  Further RFCs that describe
strongly encouraged, but non-essential, behaviors are listed in
Section 3.  Experimental extensions that are not yet standard
practices, but that potentially could be in the future, are described
in Section 4.“

IMO its clear, why for example Eifel response is in sec 4.4, since
it is an Experimental draft.

> 
> Sec 6.6 Generally we do not separately list obsolete RFCs in this document. From the text I gather that everything but RFC 4022 is obsolete in this section, so I recommend we keep the introductory text and the entry for RFC 4022.

I don’t get this. I think you mean sec 7.6 and not 6.6, but still I have no clue :-)
The entire sec 7.6 is C&P from the old roadmap. Nothing that I changed.

> 
> ****
> NITS:
> 
> P.3 para 6: "...important implementation practices that ARE not currently documented…"

OK

> 
> RFC 6298, last sentence is worded ambiguously. Suggest "RFC 6298 updates RFC 2988 by changing the initial RTO from 3s to 1s." (It can currently be read to say that 2988 sets it to 1s.)

OK

> 
> Sec 3.4. "implemented, and IPR status" -> "implemented, and concerns about IPR status“

OK

> 
> RFC 5682: "describes" -> „described"

OK

> 
> Sec 3.6. "Header compressions schemes... these overhead." --> "Header compression schemes for TCP/IP like "RObust Header Compression (ROHC) can significantly compress this overhead.“

OK

> 
> Sec 3.7.
> RFC 4953. "resets (RSTs)" -> "reset (RST)“

OK

> 
> RFC 5961. "are less vulnerable" -> "less vulnerable“

OK

> 
> Sec. 4.1 RFC 3124 : "which supports sharing information among TCP connections as well" delete the words "as well". Taking it outside of connections is not formally the same as sharing it between connections.

OK

> 
> Sec. 4.4. "simultaneous" -> "simultaneously"; "additinal" -> „additional"

OK

> 
> Sec. 5 "reclassifies" -> "reclassified"; "seen widespread" -> "seen widespread deployment“

OK

> 
> RFC 721: "has not been included" -> "was not included“

OK

> 
> RFC 1078: "propose a protocol" -> "proposes a protocol“

OK

> para 3: "Although the RFC 6013 is publish in 2011" -> "Although RFC 6013 was published in 2011“

OK

> 
> Section 6. "implementation advices can be found in Section 6.5" -> "implementation advice can be found in Section 6.5“

OK

> 
> Section 6.1. Is RFC 675 really "infamous?" Suggest "fundamental“.

:-)

> 
> Section 6.2 RFC 3439 "extents" -> „extends“

OK

> 
> Sec 6.4 RFC 5166 "Among others" -> "Among other topics“

OK

> 
> Sec 6.7 RFC 5783 "The focus of the document are on" -> "The focus of the document is“

OK

> 
> Sec 6.8 RFC 1337 "Hazardsin" --> "Hazards in“

OK

> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm