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

John Scudder <jgs@juniper.net> Wed, 19 May 2021 21:37 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 640723A200C; Wed, 19 May 2021 14:37:21 -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=FNIndS1v; dkim=pass (1024-bit key) header.d=juniper.net header.b=Us+vsvuu
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 nmQsu69GM2n6; Wed, 19 May 2021 14:37:16 -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 3BDF73A2003; Wed, 19 May 2021 14:37:16 -0700 (PDT)
Received: from pps.filterd (m0108162.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.43/8.16.0.43) with SMTP id 14JLP4gb006014; Wed, 19 May 2021 14:37:15 -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=RSKVMfC491LGS57Lamkr5ES7CXLh9up35fWI4Eocl/8=; b=FNIndS1vUNtvxSNHifIG71MSb9AP+4hsAM15A9y7XGReq+SwyhY2Q7bqYmNySQm7PyOT sLePihXFjgrXmdJZA5ExZGb8gY8C+PRfTTvi5qVuHycArdH2eZ0Jh5Fi3bMYwKl8GoS3 MWfQmdudJEacB2WTKThAlUT8IXtf2fJ/F67nhfYdxcFwSNzXbQ8QGP1x0JzGX+JEBgTq Vrn/iFD+qIYx9V7YXcGzyngmrtBa47oXpwtefVG3QRvcpKNKgQuB688bzj7RDzmYlF4S kSi6DGBQCNIngbiW5YtBbmq/hoO6F4UXmaUi6p6SL3QPh0W0nt+5eNE3B2yPr4ZdNd3N AQ==
Received: from nam11-co1-obe.outbound.protection.outlook.com (mail-co1nam11lp2176.outbound.protection.outlook.com [104.47.56.176]) by mx0b-00273201.pphosted.com with ESMTP id 38mvxhhjs2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 19 May 2021 14:37:14 -0700
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BlR4chIMs5uBoR2o2aospPMBlRVEzJyztFocq9Zn7jDnJfNNELegK8UeLwIm8D0+iprYh5WUr61nL8+D3RDGwPtOExy3G9awondVY0+b9zqVK/w7xMYd7MJTZ3Cr7AwaeMs0yDbvX9x4Lk0sXmWf/M07KFrhL7OqtPJcw4sngsaqS2GPHKEKIz97kQ+8NBDFKoYwdYLurXkr8Pogq/L8SrOamOki+oeplqj7V8Xio+T314d/pLyk9f7Q8/6zPu+xXI+afnKkVDx0emjVuNop3LVIiaU5+MfvviYKAr4yIM1DRC19JPPF4rPPRBOKzgMRLa+2J1pm9udW59lu/ZZEuQ==
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=RSKVMfC491LGS57Lamkr5ES7CXLh9up35fWI4Eocl/8=; b=eeWoX2u8Ql55IFeKt4S3H/kg2GaNMgDY5+Gvmmesuazeeijtj1z5riz/+ulvt2iJ45gHsHRRBSXnfYdRWkWg6HazKLYdtXe6+D+UbQRL7HHMcBlgwYjxrP3MJRXXIthyNTeUo0cGBcsX6s2VQ7k53OrwFMmWXX+5+AmfXOAesy1ChOA2UYKplemyIt6xCNys+53OhDI8evs27AKJB0FxKjuTDafDkhzYPsyLCMeF6wAK76OLlnn/zT0D/UkpZ03hGChfayQUKzJpW+cmZrwyAWZjKNsUwuS5YGWaUHJBQafmt/w6t/qfyvA90ATdcbL2MNyA9Pgo0HVELZk27IJ1Qw==
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=RSKVMfC491LGS57Lamkr5ES7CXLh9up35fWI4Eocl/8=; b=Us+vsvuu90gcQmaYkKD1QxvKwwBcXsvWPfOBVJ+yNC5fR4rTIFZ/s2mirN2Dtgga5wEGbOVvxr4gpvbQfEeq8gkRI2gqVGv5LwALu8g7G2k+sOM/gvtBMSOFH2UfRgSeAnM+zG2UvzmrpTWRELdroNBu12XLy7ha6RbUFn3OBfA=
Received: from MN2PR05MB6109.namprd05.prod.outlook.com (2603:10b6:208:c4::20) by MN2PR05MB6127.namprd05.prod.outlook.com (2603:10b6:208:c4::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4150.11; Wed, 19 May 2021 21:37:10 +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; Wed, 19 May 2021 21:37:10 +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/UKru2kURMqcWqrXeDkAgBPx5AA=
Date: Wed, 19 May 2021 21:37:10 +0000
Message-ID: <1CEEABBD-DF9A-4CB5-B052-0ED28FA8B276@juniper.net>
References: <162026169267.30008.8195219304146866165@ietfa.amsl.com> <8334_1620363749_6094C9E5_8334_151_1_787AE7BB302AE849A7480A190F8B9330353782EA@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
In-Reply-To: <8334_1620363749_6094C9E5_8334_151_1_787AE7BB302AE849A7480A190F8B9330353782EA@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: 52e68760-6f38-41a3-fb5f-08d91b0e4261
x-ms-traffictypediagnostic: MN2PR05MB6127:
x-microsoft-antispam-prvs: <MN2PR05MB6127AD88F82464F561680D30AA2B9@MN2PR05MB6127.namprd05.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 3HQC5bBL7UepgKtVaF9OKcqH0/7GMRa91kbzknEecrKXGbByx8M1mvDc2TLQ5bo/ZALCxsNI59fjjmkJ39m615xT+halL2WVippTbPsdzFOnoRTRObrl8t+bRd8KqEAe5VXPce6HF7OINYg7qqY6EboSQ9SP0TrDFfH0pfBgl6yZXIMXY/sQoG2U+swjhOKM2dy5NpeLHwjoQZmqNgN3Ig6ldAgyhmmGyqKWBi0FyNQJsQnH+MlmL+aAAHSv4IBbDLS6uTvQ63aEKP7lLhjXOtCRtCXr4Magk/0U61NW/+CaiNWGnXq0OU7U8yi+e8ES7Sbe3rORz4zxmr1K88OsJTSwkLTfeIzht/92NRmarVZW6Fe+ebT2qKxnA8v18roVmGe8DmMrlmT3mwWyYApU2PHhJCg6aIiGiVuAjkNWjz+9D9VVZfkUkhschXNmsp1LXbs+68Qr+Gr2Olbq5m8WfISlVsGt6nD3Gj0Le2YDzvNTgnNcKpwGk9wUMg61sy82q7hu+6s9Llen4HqmXfynGUSCHL9TuTFNMfWwu6Gxjp7MoE0zXrNqgFYXkq7n31cjX+oYPSvGsS8r+uH5C+uVxtohBA4jrjrF+9wsrfEYAItb88mjbo32VqMs6xM815HB8q//u4uexBpZueygKqIhRRqFKXuW6ni2w/7FpSTokA7qrPO43VlGz/SEaUh9X92u2byS2idwoZtCMLI5frhvoFtObfr2UvtPvjSj/mva96DoKIWiLY6Z1JaRoQZjS0Set1pPuFJhoeA+mIjt3Vg7jQ==
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)(39860400002)(136003)(396003)(346002)(376002)(366004)(6512007)(478600001)(4326008)(966005)(6486002)(54906003)(316002)(8936002)(6916009)(83380400001)(186003)(8676002)(30864003)(66476007)(86362001)(76116006)(64756008)(2906002)(91956017)(122000001)(38100700002)(66556008)(66946007)(66446008)(71200400001)(26005)(6506007)(5660300002)(2616005)(53546011)(33656002)(36756003)(45980500001); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: k8PWGUASSn6k9nNb/CGOr7OlH9nGH7QrNrPDaOTFnG/vO07J9xd3NeiRImyHQb27Z8sVJTIcMOQxq53blCe7u2u7gxIcHU1AiZhLYHF2fBZmi985TJ+ryB6adzK1SstRCPGH+JCSzxLJhtMtPe+4oJ/udF1ZZHGl/PFm6vd/UV5YLA3K9QmqpG94UL712X7VBb9FtU5Ux8CzuBBBykAwHPaR2qKAE0fTWF+kxoLRTUhLBPTIbFddXMjuohPumnE/nNK0O4UsrB/8wNe/WH/0keNBDgEuOoFvtXVU5/R4dM3PCFE2sLC01Y9MdHL3PTo5a47qqvtKPypGDzYEndGK2/WHL4G4hNHwX9o/QUWMoh1vSkOENRmZuIN3yB3VYY+IAVvtCVsuESiURQLcIoQ7RZPM0korwtoVxi7qwodKta+Ilt87vKHCSj8PWju5Gdv4D3jdjCi1lg50440R7rshi3yOpr7H7cRxy1z05rpaMli0J28wAxBxKGL+LVUaA3Scebfm5L++IIq1zz84BX1VgeSM6O8uVlSL+BRxKBxrN1d2R54NrB62DZ0eRodoylCNEHWSsUDlvTlwXib7+dAczlUMm/BdzNzC4RjomSXFSl5seBK7cBC639t34zri2l2Xa6kjXW+UQ9aX8OS7z+aJoKs1PSk/2t0dSBgn7+HTLIDVRdC3VXN9RvSyzYFIVtknOTQULB2nrr742Y1vTRuCMJhrw4mQINwraJITLfxiXsC3NtS+JHBJ7HZS9LHnIBgZ84uMugqAGLY6ylppYANAZ6fBlI8/61m2rsh/P6dzQNmB788e51GDnF1aF10Jt6y5JPntH/BKDeqJHIoBmML2J9PYUd8FF8xoEQ//df5slJprrrKPFluKyZJm1mBWz/tGWx5qs9H97j8QvRGwhWlRIfFtUWYQnNdTMGc4TF+NF41/iTR/jlONPO6/xSbSylfxFTNUc8GVPEw0Oa/UE8ym2HCbb0tzQWf8dPtjXvP8oIR9/ilTz5wLSP4D33xGO+OxtIpe6is67vTjyAdDu7dA2Be/d8cU95bbkt5M1qkSyRcHO06EMynh1MqaPuOUxV39UFTeORyUZSWL71xSl165jpCSzizziMaNTSVf/c7VNIBcxu58AQhsZjLFuscsRtoyPCI809cw1rI8Pte29x0oEUL2GIlLYG1uwIGHrrjugLKaY6VNq4MisQP74zZNSyaNbnZrVMzY6/PH5WHunohMCg91NT6JCzmlIp+2QH+oSbFOg3TvR57fYIOUmu/nbYEB7TyT587TWGlxuV3VeOlFW6HXrxpW7iQI2OkNQle/61lQID6F+gMmTyJudW55booh9q4sgJNHfefUHA1gEWyKAQ==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <D8C0CDB7F34A9A4B98FEBB1426E1AEEC@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: 52e68760-6f38-41a3-fb5f-08d91b0e4261
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 May 2021 21:37:10.5426 (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: LfUVGGaCndc0qIU+5yzwzW+LV9Bah8IufNsBrlf8wxQVOA7K85rpByX82Yi3b+AJ
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR05MB6127
X-Proofpoint-GUID: YBm37Ju-Kw_g2WSkt_JZYPiQnvURFThC
X-Proofpoint-ORIG-GUID: YBm37Ju-Kw_g2WSkt_JZYPiQnvURFThC
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-05-19_10:2021-05-19, 2021-05-19 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 mlxscore=0 phishscore=0 adultscore=0 mlxlogscore=999 malwarescore=0 spamscore=0 impostorscore=0 suspectscore=0 lowpriorityscore=0 bulkscore=0 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104190000 definitions=main-2105190131
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/6geK8P9I0jZBPp9a5qSrQwQNhUo>
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: Wed, 19 May 2021 21:37:32 -0000

Hi Med, Jon,

My responses in-line.

> On May 7, 2021, at 1:02 AM, mohamed.boucadair@orange.com wrote:
> 
> [External Email. Be cautious of content]
> 
> 
> Hi John,
> 
> Thank you for the detailed review. Much appreciated.
> 
> Changes can be tracked at: https://urldefense.com/v3/__https://tinyurl.com/new-block-latest__;!!NEt6yMaO-gk!URwuIUILv1-nibwOiR7nXAxQ0eWbNfKiJLAffIY9XW4eeoYdtLiQqTlOWTPvXA$
> 
> Please see inline.
> 
> Cheers,
> Jon & Med
> 
>> -----Message d'origine-----
>> De : John Scudder via Datatracker [mailto:noreply@ietf.org]
>> Envoyé : jeudi 6 mai 2021 02:42
>> À : The IESG <iesg@ietf.org>
>> Cc : draft-ietf-core-new-block@ietf.org; core-chairs@ietf.org;
>> core@ietf.org; marco.tiloca@ri.se; marco.tiloca@ri.se
>> Objet : John Scudder's Discuss on draft-ietf-core-new-block-11: (with
>> DISCUSS and COMMENT)

[…]

>> ---------------------------------------------------------------------
>> -
>> DISCUSS:
>> ---------------------------------------------------------------------
>> -
>> 
>> For the most part I found this document relatively easy to follow,
>> considering my complete lack of background in CoAP. However, despite
>> a concerted effort I have not been able to nail down with confidence
>> what the intended semantics of several of your timeouts are, notably
>> NON_RECEIVE_TIMEOUT. Some of the text (for example, §4.4) implies
>> that the timeout is an upper bound on how long an implementation
>> should wait before declaring a block to have been lost (“The client
>> SHOULD wait for up to NON_RECEIVE_TIMEOUT”).
> 
> The text around the timeout values have been made absolute (as per your COMMENTS), removing "up to", etc., and once the timeout has expired, then the next activity takes place. Does this help clarify things?

Yes, those changes, plus the other rewrites to §7.2, help a lot. This DISCUSS question is resolved as far as I’m concerned.

I would clear the DISCUSS, but I am concerned about my comment #11 (see below) and I’m going to raise that to a DISCUSS.

[…]

>> ---------------------------------------------------------------------
>> -
>> COMMENT:
>> ——————————————————————————————————

[…]

>> 2. Section 4.1
>> 
>>   Q-Block2 Option is useful with GET, POST, PUT, FETCH, PATCH, and
>>   iPATCH requests and their payload-bearing responses (2.01, 2.02,
>>   2.03, 2.04, and 2.05) (Section 5.5 of [RFC7252]).
>> 
>> I found the list of codes incomprehensible on first encountering it,
>> since the concept of response codes hadn’t been introduced yet. I do
>> understand that the document assumes familiarity with CoAP;
>> nonetheless for basic clarity I think this should say “(response
>> codes 2.01, 2.02…”. Additionally, the reference to RFC 7252 §5.5
>> doesn’t seem to be especially germane?
> 
> The key element in the text you quoted is "payload-bearing responses". Hence the pointer to 5.5 of RFC7252.

OK. I still think the text would be better if you inserted “response codes” within the parentheses, as in “(response codes 2.01, 2.01, …” instead of the current “(2.01, 2.02, …”.

[…]

>> 4. Section 4.1
>> 
>>   The Q-Block1 and Q-Block2 Options are unsafe to forward.  That is,
>> a
>>   CoAP proxy that does not understand the Q-Block1 (or Q-Block2)
>> Option
>>   MUST reject the request or response that uses either option.
>> 
>> Presumably (hopefully) this is simply describing the behavior of
>> existing spec-compliant proxies when processing the new messages. As
>> such, is the MUST appropriate? I would think not.
> 
> This is only for those that are tagged as unsafe to forward. The normative language is OK.

My point here is that the second sentence (the one that begins “that is”) is simply stating the behavior you would expect an existing proxy to exhibit if it were presented with the “unsafe to forward” options. Correct?

If so, then I think the MUST is inappropriate, since you are not specifying new behavior here.

[…]

>> 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?

>> 12. Section 7.2
>> 
>>   If the CoAP peer reports at least one payload has not arrived for
>>   each body for at least a 24 hour period and it is known that there
>>   are no other network issues over that period, then the value of
>>   MAX_PAYLOADS can be reduced by 1 at a time (to a minimum of 1) and
>>   the situation re-evaluated for another 24 hour period until there
>> is
>>   no report of missing payloads under normal operating conditions.
>> The
>>   newly derived value for MAX_PAYLOADS should be used for both ends
>> of
>>   this particular CoAP peer link.  Note that the CoAP peer will not
>>   know about the MAX_PAYLOADS change until it is reconfigured.  As a
>>   consequence of the two peers having different MAX_PAYLOADS values,
>> a
>>   peer may continue indicate that there are some missing payloads as
>>   all of its MAX_PAYLOADS set may not have arrived.  How the two
>> peer
>>   values for MAX_PAYLOADS are synchronized is out of the scope.
>> 
>> I take it this is just thrown in here as an operational suggestion?
>> It’s not specifying protocol, right? It seems a little misplaced, if
>> so.
> 
> This is a guidance to adjust the max_payloads to avoid losses under normal conditions.

OK, but you haven’t said whether this is operational guidance (i.e., you expect this to be done by humans adjusting configuration parameters) or if it’s potentially to be done automatically the implementation. Given that "How the two peer values for MAX_PAYLOADS are synchronized is out of the scope” I would think it’s strictly operational guidance. If that’s correct and it’s operational guidance exclusively, I think it should not be part of §7.2. Section 7.2 specifies protocol; mixing in operational advice potentially confuses the reader. You could add an “Operational Advice for Tuning Parameters” major section, or even a subsection below 7.2, and the concern would be resolved.

By the way, nit:

   not have arrived.  How the two peer values for MAX_PAYLOADS are	
   synchronized is out of the scope.

“Out of the scope” -> “out of scope” or “out of the scope of this document"

>> 13. Section 10.1.3
>> 
>> (This comment relates to the aside in my DISCUSS. You may want to
>> skip over it until we’ve resolved the DISCUSS, after which this may,
>> or may not, be
>> relevant.)
>> 
>> Why doesn’t the server request 1,9,10 in one go? Since its rxmt
>> request is triggered by rx of 11, one would think it could infer 10
>> had been lost.
> 
> Because only the missing blocks of the previous set are included and there may have been some packet arrival re-ordering for 10 and 11.

I see. I guess I was thinking of this in terms of a sliding-window protocol, but your protocol is really still almost stop-and-wait, but with much larger blocks. Your rewrite helped a lot with this, thanks.

[…]

>> 15. Section 10.2.3
>> 
>> (This comment relates to my DISCUSS. You may want to skip over it
>> until we’ve resolved the DISCUSS, after which this may, or may not,
>> be relevant.)
>> 
>> Why doesn’t reception of QB2:10/0/1024 trigger the client to request
>> retransmission? Why does it have to wait for timeout?
> 
> This is fixed as per a similar comment from Ben:
> 
> OLD:
>       [[NON_TIMEOUT (server) delay expires]]
>          |     [[Server sends next set of payloads]]
>          |<---------+ NON 2.05 M:0xab T:0xf0 O:1236 ET=23 QB2:10/0/1024
>          |   ...    |
>       [[NON_RECEIVE_TIMEOUT (client) delay expires]]
>          |     [[Client realizes blocks are missing and asks for the
>          |       missing ones in one go]]
>          +--------->| NON GET /path M:0x04 T:0xf3 QB2:1/0/1024\
>          |          |                             QB2:9/0/1024
>          |     X<---+ NON 2.05 M:0xac T:0xf3 ET=23 QB2:1/1/1024
> 
> NEW:
>       [[NON_TIMEOUT (server) delay expires]]
>          |     [[Server sends next set of payloads]]
>          |<---------+ NON 2.05 M:0xab T:0xf0 O:1236 ET=23 QB2:10/0/1024
>          |     [[On seeing a payload from the next set of payloads,
>          |      Client realizes blocks are missing and asks for the
>          |       missing ones in one go]]
>          +--------->| NON GET /path M:0x04 T:0xf3 QB2:1/0/1024\
>          |          |                             QB2:9/0/1024
>          |     X<---+ NON 2.05 M:0xac T:0xf3 ET=23 QB2:1/1/1024


I presume you’re not concerned about re-ordering between payload 9 and 10 because NON_TIMEOUT is always guaranteed to be inserted between flights of payloads (unless the other side has sent a 2.31 Continue, which means nothing was lost), therefore there’s a delay inserted on the server side between 9 and 10.

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.

Now that I’m looking at RECOMMENDED and SHOULD again, I notice that the specification for use of 2.31 in §4.3 has a similar potential issue:

      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.

I can imagine when an implementation might ignore the first SHOULD NOT: for example if it’s a very small implementation that doesn’t want to keep extra state. But how about the SHOULD? Under what circumstances is it OK for an implementation to use Response Code 2.31 when not all the payloads in a set have been received? If there are no such circumstances, this ought to be a MUST (or turn it around and say “MUST NOT be generated unless…”).

A similar concern exists for the specification of response 4.08.

I quickly skimmed the rest of the document for SHOULD/RECOMMENDED and didn’t find others that seemed equally problematic; however I’m of the school of thought that says you should ask yourself about every SHOULD, “why isn’t this a MUST?” and if you don’t have a good answer, change it.

[…]

>> 16. Section 10.2.4
>> 
>> Since MAX_PAYLOADS is 10, why does the example say “MAX_PAYLOADS has
>> been reached” after payloads 2-9 have been retransmitted? That’s only
>> 8 payloads.
>> 
> 
> MAX_PAYLOADS is not a sliding window. It is a specific set of blocks, blocks #0 - #9 (payloads 1 to 10) in this case, then blocks #10 - #19 and so on.

More or less a meta-block, as I mention in my comment on #13, above. OK.

I have some new questions and comments related to your new revision:

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, 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.

Response Code 2.31 is exactly an intermediate response. I guess maybe your focus is that if the intermediate response isn’t received, transmission continues, albeit more slowly than it would otherwise, and unreliably too, so in that sense the responses aren’t “required”. I think this requires awfully close parsing of the word “required”, though.

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” 

   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?

(I do think this change, to introduce the term MAX_PAYLOADS_SET, is generally helpful; thanks.)

Thanks,

—John