From nobody Wed Mar 23 11:22:43 2022 Return-Path: X-Original-To: tcpm@ietfa.amsl.com Delivered-To: tcpm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C6D53A0E0F for ; Wed, 23 Mar 2022 11:22:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.109 X-Spam-Level: X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y9lx6-DElRQH for ; Wed, 23 Mar 2022 11:22:36 -0700 (PDT) Received: from mail-ssdrsserver2.hostinginterface.eu (mail-ssdrsserver2.hostinginterface.eu [185.185.85.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 646A53A0DB1 for ; Wed, 23 Mar 2022 11:22:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=In-Reply-To:References:To:From:Subject: MIME-Version:Date:Message-ID:Content-Type:Sender:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ozXNYfXHN5wVed4j5S+/3Y3sh8lSPwqP3XD2jfhWLEQ=; b=pxrbfdCkpogBvj2pgCrYmqdYrF NC34VixgrG2rf1sEXauqx3If0z4/IGbp50MR9xgE3pv4SsfjtjsliXsJFmmkXMuEHvjMV9ce9915d 9gHOSumPOGmHamYT9UgCCWx/wWrhCIFbUXVuLlOsPu0DQEkMvsNG3n+25OVE4Uel9SHTVGpVschiR b7XjZIS2lX/fuY9Gc/icnAuA3juL1xHJoOGabRnDO0yMREvSxl8/H8rVk52A1dKeeUkh1zirG2FSp X35U/GfHPzoZkFur88ZCAYKjh5d6vdrby5UoKONkwRvZadIJkuFJWerKS27kkbIOWQ/kfZuqwnc8Y hv6ABIFw==; Received: from 67.153.238.178.in-addr.arpa ([178.238.153.67]:54594 helo=[192.168.1.4]) by ssdrsserver2.hostinginterface.eu with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1nX5d2-000505-64 for tcpm@ietf.org; Wed, 23 Mar 2022 18:22:34 +0000 Content-Type: multipart/alternative; boundary="------------l8PvOiL2UCJkVaB3gvYBXc7E" Message-ID: <9d618e7c-a5f0-174f-367a-afe9b3ea9e31@bobbriscoe.net> Date: Wed, 23 Mar 2022 18:22:33 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Content-Language: en-GB From: Bob Briscoe To: tcpm IETF list References: In-Reply-To: X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ssdrsserver2.hostinginterface.eu X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: ssdrsserver2.hostinginterface.eu: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: ssdrsserver2.hostinginterface.eu: in@bobbriscoe.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [tcpm] Summary of updates in draft-ietf-tcpm-accurate-ecn-18 X-BeenThere: tcpm@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: TCP Maintenance and Minor Extensions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2022 18:22:43 -0000 This is a multi-part message in MIME format. --------------l8PvOiL2UCJkVaB3gvYBXc7E Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 > > RECOMMENDED that AccECN implemented alongside  SACK and > ECN++  (was 'recommended') > + §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 > > Generic (Dumb) Reflector > + Emphasized handshake reflection here is an example, not > normative > o §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 > > 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/ --------------l8PvOiL2UCJkVaB3gvYBXc7E Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit 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
    • Throughout: reworded lower-case normative words, except upper-cased these two:
      • §1 RECOMMENDED that AccECN implemented alongside  SACK and ECN++  (was 'recommended')
      • §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'
    • §2.5 Generic (Dumb) Reflector
      • Emphasized handshake reflection here is an example, not normative
    • §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
    • 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
    • §3.2.2.4 If Data Sender detects zeroing of ACE field after handshake
      • Advised not to respond to congestion f/b
  • Technical Changes:
    • None
  • Editorial Changes:
    • Throughout: reworded lower-case normative words and minor edits


Bob


-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/

-- 
________________________________________________________________
Bob Briscoe                               http://bobbriscoe.net/
--------------l8PvOiL2UCJkVaB3gvYBXc7E--