Re: [core] John Scudder's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and COMMENT)

John Scudder <jgs@juniper.net> Thu, 20 May 2021 22:03 UTC

Return-Path: <jgs@juniper.net>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 023913A0A2E; Thu, 20 May 2021 15:03:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.497
X-Spam-Level:
X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.698, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net header.b=AX2Q8Epe; dkim=pass (1024-bit key) header.d=juniper.net header.b=V6QmwRtD
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 KpRlTvM5r0Va; Thu, 20 May 2021 15:03:29 -0700 (PDT)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 1B8BC3A0A2C; Thu, 20 May 2021 15:03:28 -0700 (PDT)
Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 14KM34iG026356; Thu, 20 May 2021 15:03:27 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=WFK+JscuJ1SGG+qU6U0s1n3Sf/9CEIIBhIPXG4ZkTa0=; b=AX2Q8Epe9HElkfjz10WYDTDHWnakJXsomXx8I34cCM4BwHsNpZFq08lQyVsiF5O6VFu5 a1Wq9OD9BDrrrN97+lMw5jf/NsHIxXBkHxqIoadMYWENIxgAiphojd/OEO2l3SnzNTnj JibG/ZZ47II+kkxFoLOo8cjKu+8WX51bnXTDLQWRKLe48EdcJUJmlabWIUC1LjWvwmBQ nsaYaclOhU5d58RL1DsWiAcAF/BtP5e3XMgGv4EUOQ4m47jpuFWU5Benp+33tdjB5q3Y JS3acjIVCC6OhT2hzJzGp7+4QBphi4+smCaYC9/MckjSXcwy3b6bdnrvBF8q7joz6D6z 0w==
Received: from nam10-mw2-obe.outbound.protection.outlook.com (mail-mw2nam10lp2101.outbound.protection.outlook.com [104.47.55.101]) by mx0b-00273201.pphosted.com with ESMTP id 38nq4q94fy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 20 May 2021 15:03:27 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fbGaOh6MAo3weoTpyfTxjtlc1V95F6v/5tEgaJhREFJ7iKs2oFOVRPQoe6IHnpov2TE0nKkKe/WUJtfaP4CKULcfXNKcfiyzOaXjXuwpE+ZSI3AOTn8+3meQm0ex49pSUXw9KpWnTh+Sf/IPxHMPVmVRNY5pzI9ZBto1Q2esIF9tQe+YCDV6zC+Kz22e9Lh0/C1nMZc37o+vi6bi2860E3hYNXpmT++RCZfIYLJIc+ihh5ELi9gLfVyTRSKEQGhpdv/pWYlIC0Ws0fxyOCX4Bv6eV0Hc1hQ+Bc2XnrD12p89R54xhIzyQI2VLQmIEmoDUNgewootTdqdXzNavz8KGg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WFK+JscuJ1SGG+qU6U0s1n3Sf/9CEIIBhIPXG4ZkTa0=; b=kJsgG/+0Nw7abTqTfyVseQhKrCFA0zHkWxk8//dVW2a+eBmT802ytJmhzNI/o5n3JUao+iOU5r9GswYUJfeiVfUzwYQb24q4uW3w4IvfvQTHcFk/dcoGnCzMFratm9Z45/6kzqCx9jlKlAWL68OKN3sLd9n6QaAtgUJ7UuOBNl+EAVMYFhMo/VzQIpFlI/oziPfQGhm4z2TAbLHkflRX65CthypX1J25HpDV8ZjFw8Le+7AtrFDrRIRANCbjRzOYsSDmSQMWtVFdxUT62pQOCqZ7SPIEFjxtfSwpBO2ZWA1a8JMubbOMesGskPJ7R7GUev0bMBakRyHw/GR2946OoQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=juniper.net; dmarc=pass action=none header.from=juniper.net; dkim=pass header.d=juniper.net; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WFK+JscuJ1SGG+qU6U0s1n3Sf/9CEIIBhIPXG4ZkTa0=; b=V6QmwRtDm98hTt9LAkMtjkqMyySLh/0Jo8HRWD5a6p1Th/t/N/viWDOjE26EQ4+IHhREIeLyIm9XhZTadR545Cb0HLp140+UCvlnOOZ8+VYfo5D3QnBazLNmpvKnMoV1Cu8kvm9hr6+YhYyJEtkWdj7XxEs05io18Sjur302tTI=
Received: from MN2PR05MB6109.namprd05.prod.outlook.com (2603:10b6:208:c4::20) by MN2PR05MB6431.namprd05.prod.outlook.com (2603:10b6:208:dc::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4173.12; Thu, 20 May 2021 22:03:22 +0000
Received: from MN2PR05MB6109.namprd05.prod.outlook.com ([fe80::3020:ac3:590d:83f1]) by MN2PR05MB6109.namprd05.prod.outlook.com ([fe80::3020:ac3:590d:83f1%5]) with mapi id 15.20.4150.017; Thu, 20 May 2021 22:03:22 +0000
From: John Scudder <jgs@juniper.net>
To: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>
CC: The IESG <iesg@ietf.org>, "draft-ietf-core-new-block@ietf.org" <draft-ietf-core-new-block@ietf.org>, "core-chairs@ietf.org" <core-chairs@ietf.org>, "core@ietf.org" <core@ietf.org>, "marco.tiloca@ri.se" <marco.tiloca@ri.se>
Thread-Topic: John Scudder's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and COMMENT)
Thread-Index: AQHXQhCbJLPvcFdg/UKru2kURMqcWqrXeDkAgBPx5ACAAQGlMIAAmAIA
Date: Thu, 20 May 2021 22:03:22 +0000
Message-ID: <B7CF0ABB-4AE4-4D13-979B-A3242EDF5C9D@juniper.net>
References: <162026169267.30008.8195219304146866165@ietfa.amsl.com> <8334_1620363749_6094C9E5_8334_151_1_787AE7BB302AE849A7480A190F8B9330353782EA@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <1CEEABBD-DF9A-4CB5-B052-0ED28FA8B276@juniper.net> <23771_1621516652_60A6616C_23771_79_1_787AE7BB302AE849A7480A190F8B93303538BB63@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
In-Reply-To: <23771_1621516652_60A6616C_23771_79_1_787AE7BB302AE849A7480A190F8B93303538BB63@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3608.120.23.2.6)
authentication-results: orange.com; dkim=none (message not signed) header.d=none;orange.com; dmarc=none action=none header.from=juniper.net;
x-originating-ip: [162.225.191.192]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: f53c6626-6bd0-412a-73db-08d91bdb15da
x-ms-traffictypediagnostic: MN2PR05MB6431:
x-microsoft-antispam-prvs: <MN2PR05MB6431FC5461140B6C8EC07DBAAA2A9@MN2PR05MB6431.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: EGXWTPCscGScOhxLdjLQIYieGfSJmZySD35opNootHYeI7U0MVzknSehYnq387GcnMeqbgtt1VFs5UlF9TfnmN0Acr0HgsNpUGcXjyWF+k9c04HNW7Ao2QLhstseWGaY96zzaz72eBifiQYOzwe90El75TI7kzKKF0GnAtbgM5IHvt0UxRTIQwDZE8tZSPb2vPELW7ZOiouTnkxvhfuZV6KI2k1664ArLsms1Oue68bRHPgCaGqgBdZDPlxqR4eznNk3+vjBTAjeEgnxe61yXHoYP3i5uP0fTcI1gfjgPDk4K6Vi/COhfbHEa2rv1S89bVxIxdx17f9OUVJ2Mcayr575gxB0j1YRo2yVuh/JMgcnjLKQJvwFA0y4tZiaIWh1VleR41B3WU783nyJ5kmtEH6qfl/SpH18ApARxlC0APYKNT3GbpkLR5OM1r6i3uvFoxgZnLH2UQCot13R+vLfex/lH7ILE0ViyPnl0/lj82rKd4wHtiPohGVWmyUh01SdXEuXzL9exnZTkGJrCEg0YZGcT0mRCjcSUp8ECfnp+irtGaA8RnuMbV//NWyDZB4b8H+wXNWbM3dqwB4EHLNckXLVUNSZnQUJhKvlU5vbKPvd7sjvx9Vqigsu0jtxT8Wf17pAKfCUEX3OYmAAhfyMAvnFkkhi7PFmWsGkavx4gcc=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR05MB6109.namprd05.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(376002)(366004)(396003)(346002)(136003)(39860400002)(76116006)(91956017)(66556008)(66476007)(38100700002)(6916009)(33656002)(2906002)(122000001)(5660300002)(4326008)(83380400001)(86362001)(66946007)(64756008)(66446008)(8676002)(53546011)(6486002)(186003)(316002)(6512007)(478600001)(8936002)(26005)(71200400001)(36756003)(54906003)(6506007)(2616005)(45980500001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: =?utf-8?B?Q0hkYlY4R1BXcW1HZTJ6QkFTSy9BcE5adlVUOGF4TlZucFdGaEY3SEg1UmVX?= =?utf-8?B?S0o1QTE2MHJzTFJsWmd2dnBaaU9Fa3RQYWlUVEF2aXZ0V05FQ2N0YUxPMWc2?= =?utf-8?B?d3pHd3lhMGUvUG9YNXdGNkJsSHc5V0w5bDk5eVc3NTJRVzErNGRrN0lJdXJQ?= =?utf-8?B?Z0lyTklqVU9Pbi9pcWNrREJpU0FkRWRoUzJFbkdQMTVPQWVBZ3RrQk5Id2Nr?= =?utf-8?B?cEl0NnFPT3ZSSEw2ekg1MGZVcjlyOWxINDViQmYyWnNKTFRnaUZjeVRQZGdw?= =?utf-8?B?L1VMakRKeWFYT3QzZHJUWS9UM3d0WXgvckRzUTRtMlBLTDg5TEJxeTJpSTJV?= =?utf-8?B?MW4zclFDM01NWFZQTExDY3Y3Y0NmRnRvVFlsUHRaWndkcWZsNzZxczRqbURM?= =?utf-8?B?K2l1Umk2RWQvS3JreTNOWWRnRDVEWW1JUzRvUEdCbkZNdDRyVXM1bHQzUURt?= =?utf-8?B?TXdqc0NtSUtuYXVaMytjcWhZNnpTRHhNRFFzUkE3TnJwV0g5ODFhaFg3ZVhy?= =?utf-8?B?cHRTVCs2ZzNZLzU0RU1sYkw4cHVIQU5vOVRIQ3doRzhRdUJBVGR5SnJaUXpS?= =?utf-8?B?Z1J6VTFPcVFOSHplTWZOb1NjVk9OcnFOd2ZoTFIrUmlGT2FiNExHSHE5V2k5?= =?utf-8?B?UjFUUWc2T1B6SWlna3d0dU9mZGxqYWF3eXNON2NkSERITTNjY0ZESUZka3Ni?= =?utf-8?B?WTFoVXJ1bXRZc05OOWdoWFl5N2VvT2pJdzUyWGw4NXZSczZhenZTOHNNT3pZ?= =?utf-8?B?Y3ZkalRPaDBWZ2hRRkM3Yis1cEhiTjVMakZ1Y2pxRmRVV3JGNlJCQjdVVU41?= =?utf-8?B?aTcvUjNUSklmWklyaDRFVFpuR25PejZ2RE5wWXdSM1RYVG5vOGtpSGpWOHlj?= =?utf-8?B?cGFXVGxKRmR3U3piN2ViWUk1ZXN2U2RibkVvaS9iT0lVMWNDeUgzTjAzQVdx?= =?utf-8?B?WEFRbXNuVVppVGx3ekd6cHg5SnRyNU4wWTNZMzN6M0M3NTRoamQ4aEZkbmFW?= =?utf-8?B?TlJzRjBGMERxWnQzWWdVUDN1R2VBZFpFMTAxSW1VVForQ1V3OGxiUWJnVDFk?= =?utf-8?B?Vno5Q0VFR1lHbExqb0RCK200QktERkh3RXo5bGxTMURWYURpcDRPYmNCa0pa?= =?utf-8?B?VUdLMmZIa1pqNVp3bnhXUDlKcUNBa0NhQmlsdEJ4OTBSUFI4bjRuQkxCcjNu?= =?utf-8?B?anBlcGhaYU5KQmhaWWtCN2JaZUVzNmNZRVg5NmFNSDhnQ2tCK3hiT0dmSGNm?= =?utf-8?B?UHNPQmk0bmF3T291ZlB6Z0h2RTdvZXpqRENjS3Zub3FXR0NEMlhnaXVZRHVS?= =?utf-8?B?NzNJd3VjQnV0RWlJS1crb2NiaUVaSjZaZENjeXZIMnA2MHFBcms2dDN2YUwy?= =?utf-8?B?ME1HVXRKVW8zeEpHUzNKSzN2UGl5WWV5Um4yaWFPSjVuem5ndkYvSkVaeitW?= =?utf-8?B?WTdUTFFQeWY4SlZmRkdHdFFORFMxWktaL24yOURveXplcy8zOXZTcndlLytl?= =?utf-8?B?Zi9IcVo2d0p0V3p1ZXpIRDRUbXlrTVU2N1RXdGVjZlZlbmJVM0xpOFRBQkNh?= =?utf-8?B?cU9vNnM1a3dJWTRNZFlsS3lsNU9DRjM4Vm4va1RyOWNlN0lXWE5oSE9GVW9W?= =?utf-8?B?ODZhODJ3c3A5MS9TNDNZcFV5OStEbW83QnZxOHB5TkpoQVZFUUQzQ20vdXlV?= =?utf-8?B?UVpTRWJXRHAzK3FwSVFrRGhhREhyZTdpUjIyL1E0Wnd6ZFIzUzhsZUF3ejVF?= =?utf-8?B?WEVWOWgyTGxZbGhvODI2SlpQbmxMZWlDM3FzemNoenptenl2Y3k4L2ZGYkRq?= =?utf-8?B?SGpERmdMWW5RSWhOQXpGdz09?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <F8B084BE4AFFDC43940E3192121FC254@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: MN2PR05MB6109.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: f53c6626-6bd0-412a-73db-08d91bdb15da
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 May 2021 22:03:22.6222 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: /yfazu0L6OGFen6M4fLKJ28bcUe78LynO33Y/ZFRB0DRbBs1oKeX9tlgWWuE1Ahs
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR05MB6431
X-Proofpoint-ORIG-GUID: 7m-tcSgV_e_pxVfBpyYze5sffbsjuwpz
X-Proofpoint-GUID: 7m-tcSgV_e_pxVfBpyYze5sffbsjuwpz
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-05-20_06:2021-05-20, 2021-05-20 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 adultscore=0 priorityscore=1501 mlxlogscore=999 malwarescore=0 mlxscore=0 suspectscore=0 phishscore=0 spamscore=0 bulkscore=0 impostorscore=0 lowpriorityscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2105200137
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/sFj_6MvrtTTfRX7wDLUeaSIXJcA>
Subject: Re: [core] John Scudder's Discuss on draft-ietf-core-new-block-11: (with DISCUSS and COMMENT)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 May 2021 22:03:35 -0000

Hi Mohamed,

I think we are converging. My comments in line. I’ve snipped agreed points for brevity, indicated by […]. 

> On May 20, 2021, at 9:17 AM, mohamed.boucadair@orange.com wrote:

[…]

>>>> 11. General
>>>> 
>>>> By the way, none of the timers specify jitter (and indeed, if read
>>>> literally, jitter would be forbidden). Is this intentional?
>>> 
>>> No +/- tolerances have been defined. When a timer expires, then the
>> next action takes place.
>> 
>> I notice that RFC 7252 jitters its timers, for example:
>> 
>>   counter.  For a new Confirmable message, the initial timeout is
>> set
>>   to a random duration (often not an integral number of seconds)
>>   between ACK_TIMEOUT and (ACK_TIMEOUT * ACK_RANDOM_FACTOR) (see
>>   Section 4.8)
>> …
>>   ACK_RANDOM_FACTOR MUST NOT be decreased below 1.0, and it SHOULD
>> have
>>   a value that is sufficiently different from 1.0 to provide some
>>   protection from synchronization effects.
>> 
>> MAX_TRANSMIT_SPAN and MAX_TRANSMIT_WAIT are similarly jittered. A
>> number of your introduced parameters
>> 
>>   This document introduces new parameters MAX_PAYLOADS, NON_TIMEOUT,
>>   NON_RECEIVE_TIMEOUT, NON_MAX_RETRANSMIT, NON_PROBING_WAIT, and
>>   NON_PARTIAL_TIMEOUT primarily for use with NON (Table 3).
>> 
>> appear at least superficially similar to the timers the authors of
>> RFC 7252 deemed important to jitter to prevent synchronization
>> effects. Did you specifically consider jittering them, and decide
>> that jitter was unnecessary? If so, can you explain what is different
>> about your specification, compared to the base spec, that eliminates
>> the concern?
> 
> RFC7252 introduces ACK_RANDOM_FACTOR jitter and separately jitter for multicast responses (which is not relevant here).
> 
> The ACK_RANDOM_FACTOR is there for when re-transmitting a packet that has not been acknowledged for some reason by its peer. NON_TIMEOUT is for when the next MAX_PAYLOADS_SET can start transmission (not re-transmission) assuming a 'Continue' has not arrived in the interim, and so was not thought necessary to add in ACK_RANDOM_FACTOR style jitter here.
> 
> For NON_RECEIVE_TIMEOUT, what is important is that NON_RECEIVE_TIMEOUT is greater than NON_TIMEOUT (We say in the spec a minimum of one second) so that a peer does not fire off a re-transmission request before the local agent has a chance to start to transmit the next MAX_PAYLOADS_SET.  NON_RECEIVE_TIMEOUT is exponentially scaled for each retry to make sure that stability is preserved. So, again, ACK_RANDOM_FACTOR jitter was not thought to be necessary here.
> 
> NON_MAX_RETRANSMIT is a fixed count.
> 
> NON_PROBING_WAIT is used to put a limit on the potential delay that could incur when obeying PROBING_WAIT when there is no peer response. If the implementation goes with the default EXCHANGE_LIFETIME computation, then NON_PROBING_WAIT includes ACK_RANDOM_FACTOR in the math.
> 
> NON_PARTIAL_TIMEOUT if computed using the default EXCHANGE_LIFETIME includes ACK_RANDOM_FACTOR.

Thanks for taking the time to explain. You don’t comment regarding whether NON_PROBING_WAIT and NON_PARTIAL_TIMEOUT should be jittered or not, you just explain that if they use the default they get jitter “for free”. The missing detail is that if they don’t use the default they don’t get jittered, so I think some consideration is still called for regarding whether having them not be jittered is OK.

[…]

>>>> 15. Section 10.2.3

[…]

>> One concern related to that: waiting NON_TIMEOUT isn’t actually
>> required, it’s only RECOMMENDED, therefore this isn’t actually a
>> guarantee. From §7.2:
>> 
>>   As the sending of many payloads of a single body may itself cause
>>   congestion, it is RECOMMENDED that after transmission of every
>>   MAX_PAYLOADS_SET of a single body, a delay is introduced of
>>   NON_TIMEOUT before sending the next MAX_PAYLOADS_SET to manage
>>   potential congestion issues.
>> 
>> I am curious why you made this a RECOMMENDED instead of a MUST. In a
>> situation like this it would be preferable for you to explain to the
>> implementor what situation they can ignore the RECOMMENDED in and
>> what they should do instead, or of course to make it into a MUST.
> 
> Because a continue signal may be received from the peer and then continue without waiting for the timeout to expire.
> 
> This is to be linked with this text:
> 
>      A response using this Response Code SHOULD NOT be generated for
>      every received Q-Block1 Option request (Section 7.2).  It SHOULD
>      only be generated when all the payload requests are Non-
>      confirmable and a MAX_PAYLOADS_SET has been received by the
>       server.  More details about the motivations for this optimization
>                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>      are discussed in Section 7.2.
>      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> We could use **MUST unless a 'Continue' is received**, e.g.,
> 
> OLD:
>   As the sending of many payloads of a single body may itself cause
>   congestion, it is RECOMMENDED that after transmission of every
>   MAX_PAYLOADS_SET of a single body, a delay is introduced of
>   NON_TIMEOUT before sending the next MAX_PAYLOADS_SET to manage
>   potential congestion issues.
> 
> NEW:
>   As the sending of many payloads of a single body may itself cause
>   congestion, after transmission of every MAX_PAYLOADS_SET of a single
>   body, a delay MUST be introduced of NON_TIMEOUT before sending the
>   next MAX_PAYLOADS_SET to manage potential congestion issues.
>   However, if a 'Continue' is received from the peer for the current
>   MAX_PAYLOADS_SET, then the next MAX_PAYLOADS_SET can start
>   transmission immediately.
> 
> ... but I know that many would argue this is a SHOULD.

I would be OK with either your proposed new text, or a SHOULD/MAY pair as in 

NEW:
  As the sending of many payloads of a single body may itself cause
  congestion, after transmission of every MAX_PAYLOADS_SET of a single
  body, a delay SHOULD be introduced of NON_TIMEOUT before sending the
  next MAX_PAYLOADS_SET to manage potential congestion issues.
  However, if a 'Continue' is received from the peer for the current
  MAX_PAYLOADS_SET, then the next MAX_PAYLOADS_SET MAY start
  transmission immediately.

If you want to stick with MUST I think you can clear up the pain with something like

NEW:
  As the sending of many payloads of a single body may itself cause
  congestion, after transmission of every MAX_PAYLOADS_SET of a single
  body, a delay MUST be introduced of NON_TIMEOUT before sending the
  next MAX_PAYLOADS_SET unless a 'Continue' is received from the peer 
  for the current MAX_PAYLOADS_SET, in which case the next 
  MAX_PAYLOADS_SET MAY start transmission immediately.

(To my eye presenting the option in this way makes it clear when the MUST does, and doesn’t, apply. This is my preferred form but I don’t insist.)

[…]

>> 17. Section 1:
>> 
>>   This document introduces the CoAP Q-Block1 and Q-Block2 Options
>> which
>>   allow block-wise transfer to work with series of Non-confirmable
>>   messages, instead of lock-stepping using Confirmable messages
>>   (Section 3).  In other words, this document provides a missing
>> piece
>>   of [RFC7959], namely the support of block-wise transfer using Non-
>>   confirmable where an entire body of data can be transmitted
>> without
>>   the requirement for an acknowledgement (but recovery is available
>>   should it be needed).
>> 
>> As far as I can tell the spec does not really remove the requirement
>> for acknowledgement,
> 
> These are not required. They were added as an optimization to avoid the non-timeout if the peer decides to use it.

As I mentioned below (“awfully close parsing”), I think that although you can find some justification for this reading, it’s debatable. Transmission of the acknowledgement (at least the final acknowledgement of the entire body, in the form of a Response Code) is required, is it not? Reception isn’t required though. Without the verb, I’m not sure whether I can say whether acknowledgement is, or isn’t, required.

I don’t insist that you change this, but I do think you could improve the clarity of the document, if you edited the above to read “… without the requirement that an acknowledgment be received from the peer"

>> it just amortizes the acknowledgements by only
>> sending them every MAX_PAYLOADS_SET. Response Code 2.31 is
>> essentially an acknowledgement, and it gets sent that frequently,
>> right? There’s also (if I recall correctly) some flavor of
>> acknowledgement that is sent when the entire body has been
>> transferred. So, I think the new paragraph isn’t accurate.
>> 
>> This observation also applies to this claimed benefit in §3:
>> 
>>   o  They support sending an entire body using NON messages without
>>      requiring an intermediate response from the peer.

And similarly, “… without requiring that an intermediate response be received from the peer.”

[…]

>> 18. Section 2:
>> 
>>   MAX_PAYLOADS_SET is the set of blocks identified by block numbers
>>   that, when divided by MAX_PAYLOADS, they have the same numeric
>> 
>> Remove “they”
> 
> Fixed. Thanks.
> 
>> 
>>   result.  For example, if MAX_PAYLOADS is set to '10', a
>>   MAX_PAYLOADS_SET could be blocks #0 to #9, #10 to #19, etc.
>>   Depending on the data size, the MAX_PAYLOADS_SET may not comprise
>> all
>>   the MAX_PAYLOADS blocks.
>> 
>> I don’t understand the last sentence ("Depending on the data size,
>> the MAX_PAYLOADS_SET may not comprise all the MAX_PAYLOADS blocks.”)
>> Are you trying to say that if the body size isn’t evenly divisible by
>> MAX_PAYLOADS then the final MAX_PAYLOADS_SET will have fewer than
>> MAX_PAYLOADS blocks in it?
> 
> We meant that the last set may include fewer blocks than MAX_PAYLOADS. Changed to:
> 
> " Depending on the overall data
>                    ^^^^^^^^
>   size, the final MAX_PAYLOADS_SET may not comprise all the
>             ^^^^^
>   MAX_PAYLOADS blocks. "
> 
> Better?

Improving. The word “comprise” is prone to misinterpretation in my experience, I would suggest something like “… there could be fewer than MAX_PAYLOADS blocks in the final MAX_PAYLOADS_SET.”

Thanks,

—John