Subject: Re: [tcpm] RFC 4614 bis comments

From: Martin Duke <[email-masked]>
Date: Wed, 4 Dec 2013 10:21:18 -0800

On Wed, Nov 20, 2013 at 2:29 AM, Zimmermann, Alexander <
[email-masked]> wrote:

<snip>

>
> > 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.
>

I disagree with this interpretation. Section 3 is entitled "Recommended
Enhancements". Given the Informational nature of this RFC, it's probably
incorrect to use the word "recommended", but I think the phrase "strong
encouraged" is appropriate. The original intent was taht implementers
really ought to use the RFCs in Section 3 in a modern TCP implementation
even if they're not strictly required. If something is not well-understood
as a common feature of modern implementations it should be in Section 4,
whether it's experimental, information, or proposed standard.

---

From: "Zimmermann, Alexander" <[email-masked]>
Date: Tue, 10 Dec 2013 15:53:31 +0000

Hi Martin,

Am 04.12.2013 um 19:21 schrieb Martin Duke <[email-masked]>:

> 
> 
> 
> On Wed, Nov 20, 2013 at 2:29 AM, Zimmermann, Alexander <[email-masked]> wrote:
>  
> <snip>
> 
> >
> > 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.
> 
> I disagree with this interpretation. Section 3 is entitled "Recommended Enhancements". Given the Informational nature of this RFC, it's probably incorrect to use the word "recommended", but I think the phrase "strong encouraged" is appropriate.

I don’t think that we are not on same page here :-) As I wrote, I also believe that we should not recommend
something.

IMO the only thing we should changed is the title of Section 3 to „Strong Encouraged 	Enhancements“.

> The original intent was taht implementers really ought to use the RFCs in Section 3 in a modern TCP implementation even if they're not strictly required. If something is not well-understood as a common feature of modern implementations it should be in Section 4, whether it's experimental, information, or proposed standard.

Which is still true in the current Draft.

Alex