Subject: [tcpm] Summary of updates in draft-ietf-tcpm-accurate-ecn-18

From: Bob Briscoe <[email-masked]>
Date: Tue, 22 Mar 2022 11:49:56 +0000

tcpm-ers,

I must apologise to Vidhi. After the excellent discussions on the list 
about whether to respond to congestion feedback after mangling has been 
detected, we had broadly agreed the text. But then I introduced a load 
of other changes at draft-17, but omitted all the ones agreed with 
Vidhi. So I just posted a new rev (-18) with them all in.

I also reviewed all the occurrences of normative words that appeared in 
lower-case (must, should, may, recommended). In the two cases below 
where it seemed non-controversial, I upper-cased to RECOMMENDED, but pls 
review. In other cases, where there was potential for misunderstanding, 
I reworded to 'needs to', 'ought to', might, etc.

So, I've just posted a new rev. Here's the summary of the diff (see list 
archive for previous discussion):

  * Changes related to Normative text
      o Throughout: reworded lower-case normative words, except
        upper-cased these two:
          + §1
            <https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-accurate-ecn#section-1>
            RECOMMENDED that AccECN implemented alongside  SACK and
            ECN++  (was 'recommended')
          + §3.2.3
            <https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-accurate-ecn#section-3.2.3>
            strongly RECOMMENDED to also test path traversal of the
            AccECN Option (was 'recommended')
            and gave a reason why it is 'RECOMMENDED to implement both
            sending and receiving of the AccECN'
      o §2.5
        <https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-accurate-ecn#section-2.5>
        Generic (Dumb) Reflector
          + Emphasized handshake reflection here is an example, not
            normative
      o §3.2.2.3
        <https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-accurate-ecn#section-3.2.2.3>
        If either Data Sender detects IP/ECN Mangling during handshake:
          + Advised not to send ECT packets but still respond to
            congestion f/b
            (was MUST NOT and MUST)
          + Added "MUST remain in AccECN mode", in case that was not clear
      o If Data Sender detects continuous congestion f/b:
          + Advised not to send ECT packets and not to respond to
            congestion f/b
            (was SHOULD NOT and SHOULD NOT)
          + Added "MUST remain in AccECN mode", in case that was not clear
      o §3.2.2.4
        <https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-accurate-ecn#section-3.2.2.4>
        If Data Sender detects zeroing of ACE field after handshake
          + Advised not to respond to congestion f/b
  * Technical Changes:
      o None
  * Editorial Changes:
      o Throughout: reworded lower-case normative words and minor edits

Bob

-- 
________________________________________________________________
Bob Briscoehttp://bobbriscoe.net/

---

From: Bob Briscoe <[email-masked]>
Date: Wed, 23 Mar 2022 18:22:33 +0000

Gorry,

On 22/03/2022 11:49, Bob Briscoe wrote:
> about whether to respond to congestion feedback after mangling has 
> been detected, we had broadly agreed the text. But then I introduced a 
> load of other changes at draft-17, but omitted all the ones agreed 
> with Vidhi. So I just posted a new rev (-18) with them all in.
>
> I also reviewed all the occurrences of normative words that appeared 
> in lower-case (must, should, may, recommended). In the two cases below 
> where it seemed non-controversial, I upper-cased to RECOMMENDED, but 
> pls review. In other cases, where there was potential for 
> misunderstanding, I reworded to 'needs to', 'ought to', might, etc.
>
> So, I've just posted a new rev. Here's the summary of the diff (see 
> list archive for previous discussion):
>

[BB] Following from your comment in tcpm just now, I've just removed 
'strongly'. Altho, I would agree that adding why the recommendation is 
important would be preferable, it's obvious enough already from context, 
so I left it as it is:
     "If a Data Receiver intends to send the AccECN Option at any time 
during the rest of the connection it is [strongly] RECOMMENDED to also 
test path traversal of the AccECN Option as specified in Section..."

Bob

>           + and gave a reason why it is 'RECOMMENDED to implement both