Subject: [tcpm] AD review: draft-ietf-tcpm-tcp-timestamps-01

From: Lars Eggert <[email-masked]>
Date: Tue, 23 Nov 2010 13:42:56 +0200

Summary: No show-stoppers, will initiate IETF last call. (Take the comments below as last call comments.)

Section 1., paragraph 4:

>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>    document are to be interpreted as described in RFC 2119 [RFC2119].

  The document doesn't use any RFC 2119 keywords, yet seems to have RFC
  2119 boilerplate text. The boilerplate text and reference can hence be
  removed.

Section 250000, paragraph 2:
>       The upcoming revision of RFC 1323, [I-D.ietf-tcpm-1323bis],
>       recommends the selection of timestamps such that they are
>       monotonically-increasing across connections.  Specific
>       implementation details for such a Timestamps generation scheme can
>       be found in [I-D.gont-timestamps-generation].

  I'm a bit uncomfortable with a BCP pointing to an individual ID for
  implementation details of a purely informative reference. Is there
  really a need for this reference?

Section 4., paragraph 1:
>    [RFC0793] suggests that the ISNs of TCP conections be generated from

  Nit: s/conections/connections/

Section 5., paragraph 1:
>    require monotonically-increasing timestamps across conenctions.

  Nit: s/conenctions./connections./

Section 8.1., paragraph 4:
>    [RFC1337]  Braden, B., "TIME-WAIT Assassination Hazards in TCP",
>               RFC 1337, May 1992.

  This is a DOWNREF to an Informational document. I will call this out
  during the IETF last call.

Appendix A., paragraph 2:
>    The question was raised on the tcpm mailing-list as to how this
>    algorithm would operate in case a computer reboots, keeps the same IP
>    address, looses memory of the previous time stamps, and then tries to
>    reestablish a previous connection.

  It doesn't matter where this question was raised - suggest to
  rephrase.

---

From: Joe Touch <[email-masked]>
Date: Tue, 23 Nov 2010 09:10:57 -0800

Lars, et al.,

How can this be a BCP if it makes no 2119 recommendations?

There appears to already be some language to this effect, just not 
capitalized. It seems worth doing a quick revision to see if this point 
can be corrected by changing the caps judiciously.

Joe

On 11/23/2010 3:42 AM, Lars Eggert wrote:
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Fernando Gont <[email-masked]>
Date: Tue, 23 Nov 2010 18:29:41 -0300

Hi, Lars,

>  2119 boilerplate text. The boilerplate text and reference can hence be

As pointed out by Joe, I should probably CAPitalize the specific
requirements contained in the document, instead.

>  really a need for this reference?

Maybe changing the text to "An example of such a Timestamps...." looks better?

I think the reference is useful -- some had even proposed to include a
sample algorithm in an Appendix. --- if there's no pointer, the read
is left alone to figure out a possible algorithm.

>  during the IETF last call.

Should I move this one to the "Informative" references?

>  It doesn't matter where this question was raised - suggest to

How about either:

option 1: "This section clarifies how this algorithm...."

option 2: "While producing this document, the question was raised as to how..."

Pick one, or propose an alternative ;-)

P.S.: Thanks for the reported nits, too! -- I'll fix them.

Thanks!

Kind regards,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Fernando Gont <[email-masked]>
Date: Tue, 23 Nov 2010 18:33:58 -0300

On Tue, Nov 23, 2010 at 2:10 PM, Joe Touch <[email-masked]> wrote:

> capitalized. It seems worth doing a quick revision to see if this point can
> be corrected by changing the caps judiciously.

How about changing the text in Section 2 (right above the bulleted list) to:

"  Processing of SYN segments received for connections in the TIME-WAIT
   state SHOULD occur as follows:"

Thanks!

Kind regards,

---

From: Joe Touch <[email-masked]>
Date: Tue, 23 Nov 2010 13:37:21 -0800

>     state SHOULD occur as follows:"

There has to be more to it than just one 2119 sentence.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Tue, 23 Nov 2010 18:46:33 -0300

> There has to be more to it than just one 2119 sentence.

Do you mean that I should include RFC2119-speak in each of the
bullets, or what? -- a proposed way forward would be appreciated.

Thanks!

Kind regards,

---

From: Joe Touch <[email-masked]>
Date: Tue, 23 Nov 2010 14:14:13 -0800

On 11/23/2010 1:46 PM, Fernando Gont wrote:
> On Tue, Nov 23, 2010 at 6:37 PM, Joe Touch<[email-masked]>  wrote:
>

Take a look at other BCPs. They don't express their suggestions in a 
single 2119 sentence.

Joe

---

From: Fernando Gont <[email-masked]>
Date: Tue, 23 Nov 2010 19:35:27 -0300

On Tue, Nov 23, 2010 at 7:14 PM, Joe Touch <[email-masked]> wrote:

> Take a look at other BCPs. They don't express their suggestions in a single
> 2119 sentence.

They may have multiple suggestions. Many BCPs have only a few RFC2119 terms.

So far, I will apply the change I mentioned above. If you have any
specific proposal to improve this aspect, please do let me know.

Thanks!

Kind regards,