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

Marco Tiloca <marco.tiloca@ri.se> Tue, 19 January 2021 11:50 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 834683A147B; Tue, 19 Jan 2021 03:50:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.361
X-Spam-Level:
X-Spam-Status: No, score=-2.361 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_DNSWL_BLOCKED=0.001, 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 W_A_w4YigIZQ; Tue, 19 Jan 2021 03:50:30 -0800 (PST)
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80079.outbound.protection.outlook.com [40.107.8.79]) (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 DE4C63A1479; Tue, 19 Jan 2021 03:50:29 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZUeiHvxfrDraXKzg5H+4KuQgGL7rRTjdEgilvKdHl2mBG1Eae8Q59LflnpxKFJ5YKPREhy3X7iAPUd3OEAEl8DXrLVLK1UFGR01XfbdWFY8/Ykun+5DJ/dh7UapPxDpWFMfkbNM45/lLQdk26i/UWl8Be0Ebt3iOqTnGjSjgKK3K3Zv5hQpv+8Lt48ooMAV2OWhVKjFcaEOcec3xv90Ynfjid4UD6uBBT1D6+qTyboEn+IVoXntQQJqwo3B/vPKjPSaBN6jBXskPEMzS3ic4t0LsekV753/F5hUMOHycBGusPqG9KgbO56izw3ZwTIDwgVWc54tYv8/gXiTVDxgTuQ==
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=Mx9sNUqorWwCfXMhg7RmeUZaqXxbJJ/c+5LUG7sCH4Y=; b=W4s3k3oBbFk58VFRc9ACsuHrTpPjXpe5dBWJfl1Au3gFCvF1D8FrwmogHo4fO88IgRVg+1TyusASCoYGakroOLVpAgm+Io66khrohG7MHI0PfEsHWDLdXdKQNj8U+LKRKnKvZ6oM7Y86/9xKZHKRbuoXgiBOdELK8s/u9nqJ1kyb+ySjaK62zYFOG2GQXaexZhaL/+Y7Zo0XkmDwe5NPLu/K3kp16vItuQRmp+wecrw1Usenl+oKrtRpfvHygd95OPAkeWhxQvStd4UY4M1E9QdN7M//IuD6PYfBMSumzU9a1UUwhJZTBz30jsKgKcZt8xIO4gq/MlKDXJ5VgzFo6w==
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=Mx9sNUqorWwCfXMhg7RmeUZaqXxbJJ/c+5LUG7sCH4Y=; b=ZuRA+79a9emH/FPLDcj4u/dbPt5/DF58a035+/zeMhrLpJYPVvPpj+0Eyu+8w3oLGPnd5MsfpRFoA7v1CQMwDq2ilB7udov0RxKNw9Haf8Bd08+KEZbtyFV02563wL9enn3thXVjxESsQJHt87ntWhtuDCE3rsLHJodNtwOQzG4=
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 DB6P18901MB0135.EURP189.PROD.OUTLOOK.COM (2603:10a6:4:26::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3763.11; Tue, 19 Jan 2021 11:50:26 +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 11:50:26 +0000
To: supjps-ietf@jpshallow.com, mohamed.boucadair@orange.com, core@ietf.org
Cc: draft-ietf-core-new-block@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>
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: <5fc34721-6a91-39b9-5f8d-b58e6ec905f6@ri.se>
Date: Tue, 19 Jan 2021 12:50:16 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
In-Reply-To: <033b01d6eda4$8013a980$803afc80$@jpshallow.com>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="jp3EjbJpE0tGBYJxOyLLxNGLzQ6sXgacO"
X-Originating-IP: [37.120.209.212]
X-ClientProxiedBy: HE1PR1001CA0003.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:3:f7::13) 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 HE1PR1001CA0003.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:3:f7::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3763.10 via Frontend Transport; Tue, 19 Jan 2021 11:50:25 +0000
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 977831cd-f3b8-4318-e8b9-08d8bc70694d
X-MS-TrafficTypeDiagnostic: DB6P18901MB0135:
X-Microsoft-Antispam-PRVS: <DB6P18901MB0135B11AC94CB451358AEE6A99A30@DB6P18901MB0135.EURP189.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: oIGW6v3Aa6L4SzkIvDO4n6x2YTLRB3cLOxVWWfsgRmq4FUciL4mTX3D3cNb33j9HTpPkwuQpyrY0W3eyMc29IdKemmp4fCDwZVA2AoIp8dQ3IKY1MwkS9SvBL/TJ9NBz4v+Je66Of1n0pXnKZxqUAJMwhVykY3Wn50ZBt+3ZWd9b26ig9S5/JISA5aXcyUX3avpTSSd/9kzojHqMtR/7GnhaAroYSQw01VcgtZ82SXHJBRg+LTMhXexWzRXMoV/wlEpKC4MPl2NMoGyG7A/ltlsL9WZ1tUDzadrX9BtIEjn0S0qgZqcHqD98eYOayBjyzzQ2LtqB6G0eq2CXRtPK4mrMLeD+sAJSgVEVuUMysRNBxdJfDKQfOTIRBSbrHNZt49ogGyCAImUUm8hZHZCW4i2bHHCqzDszJh9vA5tT3+e8XIfurC/shTaJfUnVEM7ORBr+xwjVa+k1J4+uX8z3AR7mS+VuCuU0GPFOQs08I6dqtiJ8mdw3VU3P2xOmGdcW2EpFNl+SUQQFYwfizAqCw195q9E/jtSfMQ5kLVTtd64VnGZm+OmRWIjzUg3jjAi+tW/0XCDbwWxG7WxxbMXY6y7XD23t+7n8BcgbqRCEBsqrj7W4BlqLMu6nxgl0ijuYt1MxfUV7EoWUIeYPX9l9SrM9ntO0gG1ID+rXqq4GD3UJCmAGJ4gAupOVW2VCUOM7
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)(346002)(39860400002)(376002)(396003)(366004)(136003)(66574015)(30864003)(5660300002)(235185007)(16526019)(2906002)(6666004)(186003)(83380400001)(36756003)(86362001)(8676002)(53546011)(26005)(8936002)(45080400002)(44832011)(4326008)(31696002)(31686004)(956004)(966005)(52116002)(66556008)(66476007)(33964004)(478600001)(66946007)(21480400003)(6486002)(316002)(16576012)(2616005)(45980500001)(43740500002); DIR:OUT; SFP:1101;
X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?bjkxcDlSZFk4Q3NBbmtLYzI3Tzg5N1JudzFDNmJSUnFENFIrTFVZRFJpcFht?= =?utf-8?B?eDB1Yis0WVMyRm5ranBlMWhXMUpYRFlwVnBhajF2YiszakVOSnFWUDM5dkhy?= =?utf-8?B?b3BvaGtiTVJYTWhuTkxwa2NTTjkzK3dncmpwVW1UbGdOY2ZMTmxrRnhBUzh6?= =?utf-8?B?WHdPZytDWWhHUVJKSnhiUjdka09tT2R1dTFLcTFOMXV1K0FJZi9EK3lPS3Zn?= =?utf-8?B?NnNEbnFlR1Y1elBlTFBnL1N1ZjRFMXNNZUpwdUtxcmNSNFpWNkRySGoxRHdH?= =?utf-8?B?RGMzOXFCbnVGd2xNdmsxemxDTHRkWVMvNHlucFlCaDNlMzljcG5JWS9GbHl4?= =?utf-8?B?d0piOFg1WEkzaE5HNkY0T3NGWTJwUENkTmJObmZVRE85R3U4ZkxmV0t5a3By?= =?utf-8?B?OFEyQ1lZa0FSVnFLeTIzSWZuQnVqaHNVK3FVSkw0aTBGZGpHaC80MVhoWGN3?= =?utf-8?B?VEh0ZjBTRzIwMXI1eGJUV3RHTW5aazNOWGJ5d0JwM0t5SDZ2UGxKQXdRaWwz?= =?utf-8?B?aDlzaGFSS0IxZFdYL3VsNnkvREJQcE5wYllVUExLc0lLbllqUDFVNFJQYmJq?= =?utf-8?B?QjhCMlNTdjAwVlBpSW90Q0RNeGJMZkVvRng3cFFHRVZYdlVQdTZCajRKUm5z?= =?utf-8?B?cDJOT1VsQXJBaS8wQWM4REZ3SXJVajVvQkV1aElzMmIzTVFkeGFkRGtKdkQx?= =?utf-8?B?UUIwclM2SUJVdDYwRTFzT0E4cnExZEVGWFducnZYZHdzcUhobUdVaWtwY0tC?= =?utf-8?B?ME5LYXlNNFAyTGlUQy9nck5STGVqcEl4NVl0MzlxUlY5OUE1TFJhakM0ZGJo?= =?utf-8?B?L0ZUWUJFeVhJKzBpUmQvVmVFRzNEaWVoM3lPbForQS84Y2VJdjdMTE4yL1RL?= =?utf-8?B?R3MzWTZNU1lneUJyQUpqY3dGajVkWVJXTmJMZmZsN1l0enhWMWRnZ2FZQ2F2?= =?utf-8?B?dnF2cUdCdjdYcWZNSTY5NFRLZnJRUWIrajhxSy9GWkJMSURtMHF2OUpXUFlm?= =?utf-8?B?NEYvenpQaGpRd25YQVV6RnE4dGEvOG8wS0V4SHNFSm5WbWNLWkRIRURYeHFs?= =?utf-8?B?MTJVVEhoY2pSdmFzY1JPMkg1TnlpUlJqUWZ4Uk1FZWQxOTE1UjZDOUloTWZy?= =?utf-8?B?bitoR2l4aW5jWVd0UVVQV0xtY25GdUNNSVRLeEhaTlNnVWtldnZVUWJHMm56?= =?utf-8?B?YldoR0NlUzRML0NqNDl5NFJaMWh4RkZZaHltWnBFd2lIdjRQQW1lMm9LZHFJ?= =?utf-8?B?c1FvcFlicUlQSDdZMmhqeWVKNXdSckZUd00vOFJ6Mm85QWVzSDVKdHZLMzJu?= =?utf-8?B?ZUhGU3VoZVBrOFNIalIvSkhXdFBTS0wvcUJrN1BBRVlzdm9aOFpqdFg0Z0lZ?= =?utf-8?B?eHo0VDljRDVJR1QrUXllUVhtRFRybWwwbHdBUjlUazhJaU9WbG4ycFdTaXpS?= =?utf-8?B?SGY0MkRZeTVmOEdIR1RNa2QySFVlSE53NzI2VE1nPT0=?=
X-OriginatorOrg: ri.se
X-MS-Exchange-CrossTenant-Network-Message-Id: 977831cd-f3b8-4318-e8b9-08d8bc70694d
X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Jan 2021 11:50:26.3650 (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: zEf4i4Ye5ObjJgXoxHHEkHMu7NwI6WPxwRfS+lGzq0rh4uxECyA468hwdppIETibvGdPibZq0+nuFncMUqnJlQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P18901MB0135
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/8z2K-7rR6U4P9EHbE-2Oq-qMng0>
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 11:50:35 -0000

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%2Fwww.ietf.org%2Frfcdiff%3Furl1%3Ddraft-ietf-core-new-block%26url2%3Dhttps%3A%2F%2Fraw.githubusercontent.com%2Fcore-wg%2Fnew-block%2Fmaster%2Fdraft-ietf-core-new-block.txt&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7C980404e5b97a4f7d6a2708d8bbbb9b05%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637465761738775081%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=uGB%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%2Fmai
>>>> 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%2Ftoo
>>>> 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%2Fwww.ri.se%2F&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7C980404e5b97a4f7d6a2708d8bbbb9b05%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637465761738775081%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=LE%2FKQOOUq5aEBbgVRdtqmLiOz8n%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://www.ri.se