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

[Bob Briscoe <[e-mail]>]

Gorry,

On 22/03/2022 11:49, Bob Briscoe wrote:
> 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')
>

[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
>             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/

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