Re: [Dots] [core] I-D Action: draft-ietf-core-new-block-05.txt

Marco Tiloca <marco.tiloca@ri.se> Tue, 19 January 2021 14:10 UTC

Return-Path: <marco.tiloca@ri.se>
X-Original-To: dots@ietfa.amsl.com
Delivered-To: dots@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 500F63A151B; Tue, 19 Jan 2021 06:10:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.362
X-Spam-Level:
X-Spam-Status: No, score=-2.362 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, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.262, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ri.se
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 FDEbq55iUHIG; Tue, 19 Jan 2021 06:10:02 -0800 (PST)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140042.outbound.protection.outlook.com [40.107.14.42]) (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 447B23A151A; Tue, 19 Jan 2021 06:10:00 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Q3keTZ29EZSj+e36mtBYS2VzmW5InxtMMiK/OFIHc2CL3vzNG2REY8wifp8HkRB9fR2OLdqBWQazN4B5z2L1hdON+aOtmg4Ds+uc8JDE+SYhzApJmE4YlQG6g+cX6BEQdin+iH42o9G/fFl6AyhkPfm1/Lp0Lq4VPg3D1tlKNF6yr8tbcM7cR2DFSlKBTuH8r0TOqwWmPL9WWfauK2mCmQfbFglxLB5QyQ62+7qKTslRhIPI/dpYWiBA5J4DJy3MGwfY/4P/cugth0DZNAAnA0/3c//JYhcHMqaKs/eWxOezSKZMExEyM/iAQGFRLtIsNe4gRlc0VbxtMW/cXsYEgA==
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=7Dx2St47nNbUmZLZSLX3SSDqNeIi9nN/5XUMRjQvA4o=; b=k4za+Zi1ZFrcTzPRtZ8cacID+JzB4baTQIeTt7C+pTB2Kl9VMX5yFh7JNFRTIMYnVyU+QtyPpWwo8M/aggG/L344M3F6X1y5YVAHqIYRtI2Brjx10m7ZJJqnM9dyMSCQtgrI6mewf0lZBiXtKJS3q8ioGiwRyEO2DWWpwrkgZyNXY92EsH0A0uv0+4xvzh54pONIAwAuIEeQ6eJd6L/DL1jKLqb3ZjqZbDsZjfjuUSCGyn/ycBGOXvGmPk0AUF3FhuDymdGpUtAU+e7H1mxc2ya8QpoAy5mypgnv2SZYKdenhdudJgqQeNaAxttyqxiU3JPUCjxMmDAdBw9zARlVYQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7Dx2St47nNbUmZLZSLX3SSDqNeIi9nN/5XUMRjQvA4o=; b=AA+r4VmAvTr9Iu8DVfLy7KmGo02dfG1oFGZKT+X5ZKJ5tlk7Mfnt/phrJLAuUzIuYCZVIFs6ir8p1tg1ir52sllPjXRw/ncdSWPMq5DBoMuK7k3ueWYx+MZXRif1vfvC/eLn0GY5lSgSPZJRLLz+7xH7uNHUDb9FsnO24Yq2Z7o=
Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ri.se;
Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by DB8P189MB1080.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16c::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3784.11; Tue, 19 Jan 2021 14:09:54 +0000
Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::3465:5a04:e16a:9ee0]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::3465:5a04:e16a:9ee0%8]) with mapi id 15.20.3763.014; Tue, 19 Jan 2021 14:09:54 +0000
To: mohamed.boucadair@orange.com, "supjps-ietf@jpshallow.com" <supjps-ietf@jpshallow.com>, "core@ietf.org" <core@ietf.org>
Cc: "draft-ietf-core-new-block@ietf.org" <draft-ietf-core-new-block@ietf.org>, "dots@ietf.org" <dots@ietf.org>
References: <161056117925.23400.10291073677288718681@ietfa.amsl.com> <24069_1610561621_5FFF3855_24069_12_1_787AE7BB302AE849A7480A190F8B9330315B92B9@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <15aa1f32-db32-6c9a-70dc-b30ed6f33466@ri.se> <00d701d6eb31$05fe11f0$11fa35d0$@jpshallow.com> <4feb5743-4193-97f1-5231-038b1838b934@ri.se> <033b01d6eda4$8013a980$803afc80$@jpshallow.com> <5fc34721-6a91-39b9-5f8d-b58e6ec905f6@ri.se> <3017_1611059042_6006CF62_3017_76_1_787AE7BB302AE849A7480A190F8B9330315BCBD4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
From: Marco Tiloca <marco.tiloca@ri.se>
Autocrypt: addr=marco.tiloca@ri.se; prefer-encrypt=mutual; keydata= mQENBFSNeRUBCAC44iazWzj/PE3TiAlBsaWna0JbdIAJFHB8PLrqthI0ZG7GnCLNR8ZhDz6Z aRDPC4FR3UcMhPgZpJIqa6Zi8yWYCqF7A7QhT7E1WdQR1G0+6xUEd0ZD+QBdf29pQadrVZAt 0G4CkUnq5H+Sm05aw2Cpv3JfsATVaemWmujnMTvZ3dFudCGNdsY6kPSVzMRyedX7ArLXyF+0 Kh1T4WUW6NHfEWltnzkcqRhn2NcZtADsxWrMBgZXkLE/dP67SnyFjWYpz7aNpxxA+mb5WBT+ NrSetJlljT0QOXrXMGh98GLfNnLAl6gJryE6MZazN5oxkJgkAep8SevFXzglj7CAsh4PABEB AAG0Nk1hcmNvIFRpbG9jYSAobWFyY28udGlsb2NhQHJpLnNlKSA8bWFyY28udGlsb2NhQHJp LnNlPokBNwQTAQgAIQUCWkAnkAIbAwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRDuJmS0 DljaQwEvCACJKPJIPGH0oGnLJY4G1I2DgNiyVKt1H4kkc/eT8Bz9OSbAxgZo3Jky382e4Dba ayWrQRFen0aLSFuzbU4BX4O/YRSaIqUO3KwUNO1iTC65OHz0XirGohPUOsc0SEMtpm+4zfYG 7G8p35MK0h9gpwgGMG0j0mZX4RDjuywC88i1VxCwMWGaZRlUrPXkC3nqDDRcPtuEGpncWhAV Qt2ZqeyITv9KCUmDntmXLPe6vEXtOfI9Z3HeqeI8OkGwXpotVobgLa/mVmFj6EALDzj7HC2u tfgxECBJddmcDInrvGgTkZtXEVbyLQuiK20lJmYnmPWN8DXaVVaQ4XP/lXUrzoEzuQENBFSN eRUBCACWmp+k6LkY4/ey7eA7umYVc22iyVqAEXmywDYzEjewYwRcjTrH/Nx1EqwjIDuW+BBE oMLRZOHCgmjo6HRmWIutcYVCt9ieokultkor9BBoQVPiI+Tp51Op02ifkGcrEQNZi7q3fmOt hFZwZ6NJnUbA2bycaKZ8oClvDCQj6AjEydBPnS73UaEoDsqsGVjZwChfOMg5OyFm90QjpIw8 m0uDVcCzKKfxq3T/z7tyRgucIUe84EzBuuJBESEjK/hF0nR2LDh1ShD29FWrFZSNVVCVu1UY ZLAayf8oKKHHpM+whfjEYO4XsDpV4zQ15A+D15HRiHR6Adf4PDtPM1DCwggjABEBAAGJAR8E GAECAAkFAlSNeRUCGwwACgkQ7iZktA5Y2kPGEwf/WNjTy3z74vLmHycVsFXXoQ8W1+858mRy Ad0a8JYzY3xB7CVtqI3Hy894Qcw4H6G799A1OL9B1EeA8Yj3aOz0NbUyf5GW+iotr3h8+KIC OYZ34/BQaOLzdvDNmRoGHn+NeTzhF7eSeiPKi2jex+NVodhjOVGXw8EhYGkeZLvynHEboiLM 4TbyPbVR9HsdVqKGVTDxKSE3namo3kvtY6syRFIiUz5WzJfYAuqbt6m3TxDEb8sA9pzaLuhm fnJRc12H5NVZEZmE/EkJFTlkP4wnZyOSf/r2/Vd0iHauBwv57cpY6HFFMe7rvK4s7ME5zctO Ely5C6NCu1ZaNtdUuqDSPA==
Message-ID: <caab5ba1-7f93-e6c4-e58c-6d838d2b17f1@ri.se>
Date: Tue, 19 Jan 2021 15:09:47 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
In-Reply-To: <3017_1611059042_6006CF62_3017_76_1_787AE7BB302AE849A7480A190F8B9330315BCBD4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="JjlH2quIbwmAnOkJzWEChCT8sqHmkOuic"
X-Originating-IP: [37.120.209.212]
X-ClientProxiedBy: HE1P192CA0006.EURP192.PROD.OUTLOOK.COM (2603:10a6:3:fe::16) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from [10.8.2.7] (37.120.209.212) by HE1P192CA0006.EURP192.PROD.OUTLOOK.COM (2603:10a6:3:fe::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3784.11 via Frontend Transport; Tue, 19 Jan 2021 14:09:53 +0000
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: c82628d3-253c-4ab2-022a-08d8bc83e4ee
X-MS-TrafficTypeDiagnostic: DB8P189MB1080:
X-Microsoft-Antispam-PRVS: <DB8P189MB10808B5E58438B0B7E091D5F99A30@DB8P189MB1080.EURP189.PROD.OUTLOOK.COM>
X-MS-Oob-TLC-OOBClassifiers: OLM:8273;
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: pk6XJU1fDKFg+IErAh3KrWGPjyiq5fV8Q0LlxBkHHsvm9Z7opY1aq85bx8/KUaVKUf4Kn+65U5XgLJ3pypMfwsSpjIM9SfecaJ32kFye0uvuyOnY4SfsX7LRMEzQMym+Orpt4IljUo58mg6mpAOxwks+yOw0Papi6SDCh4+c2r9tjWhsag5ilbvtSGjBE7YWEppkuvvKjgEpn5sllTyGmqzpcm6jP3GpTcCJr80HSgndnBaD8U6bP52fz5m3cv+6N9YVPms7q0JsQEAqHDFEyEtZOh+pKlqovzpSlbRB33zFFxTcy6AavzVH5joWobrRY2WtnW5TXzkC4tuTn4bZ7ZEeSBBI9ZPh2YQ+Mcehd1qO58k2DrO+tKN1TzfaOd5+lW+ICOzQCrppGtEfCyxfBRSOTZ+f6+6WG43lLqbA3GyTqVj63gUFbeLEnI2JtMEXjBR7nD2pyen5W96ux8SjRecMIPdpBUqhhN1EjIClKK7OKRlc+lteeXFVWS81bSFQ5GykA/J7wKxcEHIdd9JrAPoTZOK2bfPt2/EnzocS1A4TvaNCdN80QcNe4rU+yDKx
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(396003)(346002)(376002)(136003)(39840400004)(366004)(6486002)(31696002)(2906002)(52116002)(21480400003)(30864003)(44832011)(16576012)(110136005)(316002)(54906003)(5660300002)(45080400002)(478600001)(31686004)(8676002)(4326008)(966005)(235185007)(186003)(956004)(66574015)(66556008)(6666004)(16526019)(26005)(66476007)(86362001)(36756003)(33964004)(8936002)(53546011)(2616005)(66946007)(83380400001)(45980500001)(43740500002); DIR:OUT; SFP:1101;
X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?cEZoWHlxdW9GZXdWV1U0eE1NYVJmSEQyQW1YOVM5bHVIYmZUblBBM290TDlq?= =?utf-8?B?ZktWckdvMzQ1RlZxNHI4aG1USjh4cWlySzMrZm5CQW05WWZJZ1UvNERkRjZP?= =?utf-8?B?c0dseDNIUW9sY1B6bElLRmtxZnBHR1NEbVBtZEx4bWd1eTFWMGZOYmh1OENB?= =?utf-8?B?MHJ4NkNDQUd3QnhhZ1drZkVXaUF5SDdlU2lkZkY0MlpKTXJTL214QW4xL3Yw?= =?utf-8?B?b3JiZDZKTi9UM1pDVm9GYUcxWWlvcEdTSndiMldNb2hhVFZOSGp4M2RUTW1K?= =?utf-8?B?K29Bd0FZT2NyZWVrOUErZVhCSjg4MFpmRFpHZVhtbDdmNnpGbmU4UDhtV21q?= =?utf-8?B?K29Qalp4aGg2T21mK3dSbnZvb2lJNVZqeEZQTCtNRFNOQmVPbDYrNmFpemVp?= =?utf-8?B?czMxRG02ODVWVm9MbGJJb08vd0p5ZWZnd1E0UUZDNjRMWFNQY1FuOHVnajlK?= =?utf-8?B?MTlKUUthYzF3UXlwSmpsL1ljMXh5Qjc3Kzc4M3NYNzVDVDM1cDVQWEs2UzdY?= =?utf-8?B?ZnRoU285Sm5uUzVCcHBTTk5uNTREQ3gyeFNGeWV5dHdJZm5tNytHVU5wZHRu?= =?utf-8?B?OHhNMDVWZEpCeHBFdk5sdGkySStib2V1SXBXdVV1RUlGbElwL3hmMDRPbWQ1?= =?utf-8?B?RWZYQlhsUHB1Z3F2M0V5WGI3dHBPTVF0bEhPR3RUZjJwa28rYnlTaEhNZHl3?= =?utf-8?B?ZGx5TVpHZ3hZdnBOZDRUNUFody9yU21oQXFncUFDNUV4ZXUzR3dUbmJ2WUNW?= =?utf-8?B?Z1h2RVkybE5nSExDWnNIWnJRNUQ0ZVp0NWFYSjdLV3h2eURwWFRNM3JGUHZp?= =?utf-8?B?Y25PbEhydC80OW1Nb2V4TVJpcUxVN3NTOGdSd0dKY2pjYjQ2Z2l6RnJSdUEx?= =?utf-8?B?N3RGQiszdE1MOGtFY2dkTEttR25MS3ZXWnhtdDJXVnMxdGZycUJaaE14V3hh?= =?utf-8?B?OXZ6T3F1U3BiNUNZalhpUGY3alh5T2pyWUJNZE5TTC9YeWVOU3FLSXdKUkRH?= =?utf-8?B?MFFUTVUvbTF4QXdiT1hFaWZhc0FONktnbnkvTlVDWjFwS0Zqak1MZFNSVDNU?= =?utf-8?B?TGRsYnJ6TkFReCs2UTlOc2lwOW5qU3lqcmRvR0lFVjFHYlBkd0JEalR0TkZ5?= =?utf-8?B?cUpGbkFvaEhHRE5YcHhLMFZJRnNIc3djYjM1MlU2MzdUcndEUHR0NjJaM1Vw?= =?utf-8?B?N0dod21tM1pJbis1TFhUNmx0bDMvV0tBZzIrV0xPVUNlbkJwa2FtQkNTZ3A1?= =?utf-8?B?UzBRWHFFU0FyRXFSRnl5blZkd2w5QVFvWm01dWlqZUd1TTdES2NtR0IyTkVV?= =?utf-8?B?VFhuYUk3dk1tZHBPcVRsYnpvdzJ2ZEREcElFNnBOUVZ3Sk4xLzZjN3RZQ0dt?= =?utf-8?B?dHZveW1kR1JndlBET1Nxa1Z1by9LOUZMc2kxNnpOb01COFhiRjA2QlBHVnFN?= =?utf-8?Q?Wlhtu09C?=
X-OriginatorOrg: ri.se
X-MS-Exchange-CrossTenant-Network-Message-Id: c82628d3-253c-4ab2-022a-08d8bc83e4ee
X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Jan 2021 14:09:54.2756 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: WbWxjTtSWFD+TdkGavyRvjn7qi6fNBeHlA6N+C/5YZfl4uRktOsONuRpchtxPGed1n8FE5Jn/ZigSQiWayeuFA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8P189MB1080
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/rDWjEXHz0eFQUlNTKvXeTOl866c>
Subject: Re: [Dots] [core] I-D Action: draft-ietf-core-new-block-05.txt
X-BeenThere: dots@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for discussion of DDoS Open Threat Signaling \(DOTS\) technology and directions." <dots.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dots>, <mailto:dots-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dots/>
List-Post: <mailto:dots@ietf.org>
List-Help: <mailto:dots-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dots>, <mailto:dots-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Jan 2021 14:10:06 -0000

Got it, thanks.

Best,
/Marco

On 2021-01-19 13:24, mohamed.boucadair@orange.com wrote:
> Hi Marco, 
>
> The proposed edits look good to me. Will be fixed in the github. 
>
> 2.31 is not mentioned in in the excerpt you quoted from Section 3.3 because 2.31 is not **required**. A server may decide to not reply with 2.31 as a function of its overall load and prefer to observe a pause before handling the next block. That’s is why we do have SHOULD, not a MUST.    
>
> Cheers,
> Med
>
>> -----Message d'origine-----
>> De : Marco Tiloca [mailto:marco.tiloca@ri.se]
>> Envoyé : mardi 19 janvier 2021 12:50
>> À : supjps-ietf@jpshallow.com; BOUCADAIR Mohamed TGI/OLN
>> <mohamed.boucadair@orange.com>om>; core@ietf.org
>> Cc : draft-ietf-core-new-block@ietf.org; dots@ietf.org
>> Objet : Re: [core] I-D Action: draft-ietf-core-new-block-05.txt
>>
>> Hi Jon,
>>
>> Thanks, please see below some minor points, otherwise it looks good
>> to me.
>>
>> Best,
>> /Marco
>>
>> * Section 3.1 - In the paragraph right above Table 2, s/with CoAP
>> over TCP/with CoAP over reliable transports.
>>
>> * Section 3.1 - I think that the new final paragraph "Note that if
>> Q-Block1 (or Q-Block2) ... MUST NOT be included." fits better before
>> the paragraph discussing the use of OSCORE, i.e. "The Q-Block1 and
>> ...
>> fragmentation of requests."
>>
>> * Section 3.3 - "For Non-confirmable transmission, no response is
>> required until the successful receipt of the body by the server or
>> some of the payloads have not arrived after a timeout and a
>> retransmit missing payloads response is needed."
>>
>>    Shouldn't this also mention the case where the server sends a
>> 2.31 response to have the client continue sending the next
>> MAX_PAYLOADS payloads?
>>
>> * Section 3.3 - Proposed clarification for the 4.02 response code:
>>
>>     "Either this Response Code (in case of Confirmable request) or a
>> reset message (in case of Non-confirmable request) MUST be returned
>> if the server does not support the Q-Block1 Option."
>>
>>
>> On 2021-01-18 15:16, supjps-ietf@jpshallow.com wrote:
>>> Hi Marco,
>>>
>>> We have updated github [1] to take account of your latest comments
>> for your review.
>>> Regards
>>>
>>> Jon
>>>
>>>
>>>
>> [1]https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%252
>> Fw
>>> ww.ietf.org%2Frfcdiff%3Furl1%3Ddraft-ietf-core-new-
>> block%26url2%3Dhttp
>>> s%3A%2F%2Fraw.githubusercontent.com%2Fcore-wg%2Fnew-
>> block%2Fmaster%2Fd
>>> raft-ietf-core-new-
>> block.txt&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7
>> C980404e5b97a4f7d6a2708d8bbbb9b05%7C5a9809cf0bcb413a838a09ecc40cc9e8
>> %7
>> C0%7C0%7C637465761738775081%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw
>> MD
>> AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=uG
>> B%
>>> 2BGu0PztRvMh4hUFutHMItkR5AJXCJqpt440nphj4%3D&amp;reserved=0
>>>
>>>
>>>> -----Original Message-----
>>>> From: Marco Tiloca [mailto: marco.tiloca@ri.se]
>>>> Sent: 15 January 2021 13:58
>>>> To: jon@jpshallow.com; mohamed.boucadair@orange.com;
>> core@ietf.org
>>>> Cc: draft-ietf-core-new-block@ietf.org; dots@ietf.org
>>>> Subject: Re: [core] I-D Action: draft-ietf-core-new-block-05.txt
>>>>
>>>> Hi Jon,
>>>>
>>>> On 2021-01-15 12:24, supjps-ietf@jpshallow.com wrote:
>>>>> Hi Marco,
>>>>>
>>>>> Thanks from this.
>>>>>
>>>>> So moving forward, requests for missing Q-Block2 blocks will
>> follow
>>>>> Section 2.7 RFC7959 being modelled on (assuming the request was
>>>>> using Q-
>>>> Block1) " To continue this Block2 transfer, the client
>>>>>    continues to send requests similar to the requests in the
>> Block1
>>>>>    phase, but leaves out the Block1 Options and includes a
>> Block2
>>>>>    request option with non-zero NUM."
>>>>>
>>>>> Otherwise, please see inline which has a couple of questions.
>>>>>
>>>>> Regards
>>>>>
>>>>> Jon
>>>>>> -----Original Message-----
>>>>>> From: Marco Tiloca [mailto: marco.tiloca@ri.se]
>>>>>> Sent: 14 January 2021 19:58
>>>>>> To: mohamed.boucadair@orange.com; core@ietf.org
>>>>>> Cc: draft-ietf-core-new-block@ietf.org; dots@ietf.org
>>>>>> Subject: Re: [core] I-D Action: draft-ietf-core-new-block-
>> 05.txt
>>>>>> Hi Med,
>>>>>>
>>>>>> Thanks for the new document version.
>>>>>>
>>>>>> Please, see below some comments on the latest additions, also
>>>>>> related to what Jon raised at [1].
>>>>>>
>>>>>> Best,
>>>>>> /Marco
>>>>>>
>>>>>> [1]
>>>>>>
>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fm
>>>>>> ai
>>>>>> larchive.ietf.org%2Farch%2Fmsg%2Fcore%2FOrr8a1WlSu3Dk-
>>>> gtPQZloDT9_1E%2
>>>>
>> F&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7Cf30167412cf14279616708d
>>>> 8b
>>>> 948202a%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C63746306674
>>>> 04024
>>>> 21%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
>>>> CJBTi
>>>>
>> I6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=E4lIccwYQyVGHxxl9v9iBr70
>>>> hU6
>>>>>> BuxRrzAQoZHnZt%2B8%3D&amp;reserved=0
>>>>>>
>>>>>>
>>>>>> * Section 3.5 - This seems to mix aspects specific to Observe,
>> with
>>>>>> more general aspects applicable to requests with a payload,
>> i.e.
>>>>>> FETCH (with or without Observe), PUT, POST and PATCH/iPATCH.
>>>>> [Jon] Now that we understand what needs to be done with
>> requesting
>>>>> missing
>>>> Q-Block2 blocks, working with Observe can be simplified.
>>>>> [Jon] Requesting Observe is only valid for GET and FETCH.  Hence
>>>>> Observe
>>>> request/cancellation setting when using Q-Block1 is only
>> appropriate for FETCH.
>>>>> [Jon]  Unfortunately, RFC8132 does not specify in which of the
>>>>> payloads of as
>>>> Block1 based FETCH request  should contain the Observe option
>>>> assuming observe is required (The first, the last or all of the
>>>> payloads). So, here, I believe the safest way to go is with all
>> the
>>>> payloads carry the observe option if observe is being requested
>> or
>>>> cancelled.  Thus any missing payloads should be resent with the
>>>> observe configured to be consistent with all the other payloads.
>> Are you happy with this?
>>>> ==>MT
>>>> It makes sense to me.
>>>> <==
>>>>
>>>>>>   What is specific of Observe is the first paragraph; and the
>> usage
>>>>>> of the Observe option in the second and third paragraph.
>> Anything
>>>>>> else seems generic and applicable to requests with payload, so
>> it
>>>>>> might be moved up to some earlier section.
>>>>>>
>>>>> [Jon] Sure - will be updated in the simplification tidy up.
>>>>>> * Section 3.5 - In the third paragraph, I'm not sure you
>>>>>> necessarily need a payload to be present in the requests asking
>> for
>>>>>> missing response payloads. For instance, consider:
>>>>> [Jon] Agreed.  Now going with Section 2.7 RFC7959 where both
>> Block1
>>>>> and
>>>> payload are not included.
>>>>>>   - The examples in Figure 10 and Figure 11 of RFC 7959, with
>> the
>>>>>> note "(no payload for requests with Block2 with NUM != 0)" ,
>> during
>>>>>> the phase where the client consecutively asks for the next
>> response payload.
>>>>>>   - The examples in Figure 2 and Figure 3 of [2], where each
>>>>>> request for the next response payload using Block2 has no
>> payload of its own.
>>>>>> This would of course affect the example in Figure 15.
>>>>> [Jon] Yes, will be updated.
>>>>>> [2]
>>>>>>
>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Ft
>>>>>> oo
>>>>>> ls.ietf.org%2Fhtml%2Fdraft-ietf-ace-coap-est-
>>>> 18&amp;data=04%7C01%7Cma
>>>>
>> rco.tiloca%40ri.se%7Cf30167412cf14279616708d8b948202a%7C5a9809cf0bcb
>>>> 4
>>>> 13a838a09ecc40cc9e8%7C0%7C0%7C637463066740402421%7CUnknown%7CT
>>>> WFpbGZs
>>>>
>> b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0
>>>> %3
>>>> D%7C1000&amp;sdata=cSOOuCBEP2jCRzECrJeLli6Z%2Bu%2FUlD%2F1HzVWIM7
>>>> O7%2B
>>>>>> Q%3D&amp;reserved=0
>>>>>>
>>>>>>
>>>>>> * Section 3.5 - About the last sentence regarding the Observe
>>>>>> option, there seems to be an exception to this rule (at least
>> based
>>>>>> on the later examples), where the server actually does include
>> the
>>>>>> Observe option in
>>>> the response.
>>>>> [Jon] If the Observe option is just included with the first
>> payload
>>>>> (NUM = 0) as
>>>> RFC7959, there is a recovery special case should the first
>> payload
>>>> not arrive, but subsequent ones do.  In the general case, blocks
>> that
>>>> are missing are re- requested by the client and the server
>> responds
>>>> with the appropriate block, but without the Observe option. For
>> the
>>>> special case when the client requests missing payload with NUM =
>> 0
>>>> the server needs to know that it must include the Observe in the
>>>> response so that the client following the body re-assembly knows
>> that it is a Observe triggered additional response.
>>>>> [Jon] I had gone with the Observe should be in all the payloads
>> in
>>>>> the response
>>>> apart from specifically re-requested blocks (including NUM = 0).
>> The 'Continue'
>>>> Q-Block2 was just to indicate a continue so the server can send
>> the
>>>> remaining payloads without delay - hence why remaining payloads
>> had Observe set.
>>>>> [Jon] I am beginning to lean to having it in the first payload
>> and
>>>>> special case
>>>> the response to re-request of NUM = 0.  What do you think?
>>>>
>>>> ==>MT
>>>> Ok, I didn't think also of the case for NUM = 0, but that makes
>> sense too.
>>>> Then it's certainly something better to clarify in the main text
>> and
>>>> also to show/comment in the example of Figure 10.
>>>> <==
>>>>
>>>>>>    That is, consider the example in Figure 10, where the
>> response
>>>>>> with M:0xba is lost. Later on, the client asks for that
>> response
>>>>>> payload by sending the request with M:0x87, which correctly
>> does
>>>>>> not include
>>>> the Observe option.
>>>>> [Jon] Yes
>>>>>>    However, the following response with M:oxc3 and (from the
>> point
>>>>>> of view of the server) retransmitting that response payload
>> with
>>>>>> block number 10 does include the Observe option.
>>>>>>
>>>>>>    The exception seems due to the fact that the retransmission
>>>>>> request from the client is specifically what you call
>> 'Continue'
>>>>>> Q-Block-2 in Section 3.4. The Observe option is in fact not
>>>>>> included for the previously retransmitted response payloads
>> with
>>>>>> M:0xbb ... M:0xc2,
>>>> as still part of the current payload set.
>>>>> [Jon] Correct, but obviously not obvious from the text.
>>>> ==>MT
>>>> Right, I mostly focused on that.
>>>>
>>>> I think it's worth clarifying in the main text what the normal
>> case
>>>> is for the server
>>>> (client) to include (expect) the Observe option in a response
>>>> payload; and then highlight the exceptions for the re-request
>> with
>>>> NUM=0 (see above) and for the 'Continue' Q-Block2.
>>>>
>>>> Best,
>>>> /Marco
>>>> <==
>>>>
>>>>>> * Section 3.6 - Part of the first sentence in the second
>> paragraph
>>>>>> seems to repeat what already said in the third paragraph of
>> Section 3.5.
>>>>> [Jon] Will clean up in the simplification.
>>>>> ~Jon
>>>> --
>>>> Marco Tiloca
>>>> Ph.D., Senior Researcher
>>>>
>>>> RISE Research Institutes of Sweden
>>>> Division ICT
>>>> Isafjordsgatan 22 / Kistagången 16
>>>> SE-164 40 Kista (Sweden)
>>>>
>>>> Phone: +46 (0)70 60 46 501
>>>>
>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww
>> w
>> .ri.se%2F&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7C980404e5b97a4f7d
>> 6
>> a2708d8bbbb9b05%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C6374657
>> 6
>> 1738775081%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
>> z
>> IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=LE%2FKQOOUq5aEBbgV
>> R
>>>> dtqmLiOz8n%2Bt60OuEYgM%2FwCrJg%3D&amp;reserved=0
>>>>
>> --
>> Marco Tiloca
>> Ph.D., Senior Researcher
>>
>> RISE Research Institutes of Sweden
>> Division ICT
>> Isafjordsgatan 22 / Kistagången 16
>> SE-164 40 Kista (Sweden)
>>
>> Phone: +46 (0)70 60 46 501
>> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ri.se%2F&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7C21a30f35d4534262c38c08d8bc751b7c%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637466558517629762%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=5npricMtOuyVskAU%2FpP%2BnvzjAc%2Bazs%2BQ1G54jPNW6Wo%3D&amp;reserved=0
>>
>
> _________________________________________________________________________________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>

-- 
Marco Tiloca
Ph.D., Senior Researcher

RISE Research Institutes of Sweden
Division ICT
Isafjordsgatan 22 / Kistagången 16
SE-164 40 Kista (Sweden)

Phone: +46 (0)70 60 46 501
https://www.ri.se