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

Marco Tiloca <marco.tiloca@ri.se> Fri, 15 January 2021 13:58 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 4BE313A00C9; Fri, 15 Jan 2021 05:58:18 -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 TSCnfFYtpMYj; Fri, 15 Jan 2021 05:58:14 -0800 (PST)
Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2063.outbound.protection.outlook.com [40.107.21.63]) (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 C05883A005F; Fri, 15 Jan 2021 05:58:13 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mw8ds/q/Ca8dYhLZiMLx+PoXJncrTbCaCWJdMbW6EIJEWW9moeRUmPCJLrr83okvkQxr2o/bHQCC1DIhnQmNqPv3a/Ss/MoHamiu4DakBrAJjoB8MIWoi9gJAa2In6k7ClAoqRyw8ROgZfUbLe+gcpkg+Sp/kHRsDjVbBmPClKQz12+f0CpxIhu2rOM0L17MgXTJvWKCz5JFLpIFRDfcMqZRLzKSgC4WBw4B4hya10tRu1ZYcBtA1J2j9wIP1ePFZ8rdlvWBGLb8hcK2qjAqmj06mfwxn5I4NDzq50icNi8Mxct7WMuu6fgu0xbzOjMVsfuyspODvKwzJT4YfTrmLg==
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=JsbE/EWoSwbOmlGjEHkfhOFJ1xCMQBh9ePpJsS4nxn4=; b=at038UC/2n93QfGM+OEV39zeAsHbW4BdntzomFcPzdozf10/voXzjjFJxRPpAvW46w75pNSJ5W/vA6VliYZT4w0Vrx1AlLxc/2qJhu7+4sNqon5lFHODG6F1Nabr5seBd7Ny3PEJcc8fMoeX/qiq4Mp35gDJLmpuCTjVYrkK6Uzyv0yGrNHxiVkSCHGJAfjK5Y4ao6sajUKlDEkhVfNkN1AQQLNHo4hLo8IAmIYJNPD59rz6bYtKeAedFAB4pyq8GKu1xKY7NkYdBfb+Qw7bou+fhQGVNmxmU/p1vRam70dIf6ze5YPkLBXOgdWeQGiU1252c0/qvMvHRABmnqrO7g==
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=JsbE/EWoSwbOmlGjEHkfhOFJ1xCMQBh9ePpJsS4nxn4=; b=UbV9Pb2G1m83g1S1Phua2X62TbWn6ZHY0WA5/h4ORCyOnbbnFSMmKCVK9RpXjqPhFkifliTZifLL4yrdTlWXpWci1ZvcooRjO6NJPDLpoYDuBKv7IGgTckdZV+HVFqd8WIPh/Xhh2qmAEKPC6DdjV5hUWvLJLm9jBg8CnXtd11g=
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 DB8P189MB0840.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16f::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3763.10; Fri, 15 Jan 2021 13:58:10 +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.012; Fri, 15 Jan 2021 13:58:10 +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>
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: <4feb5743-4193-97f1-5231-038b1838b934@ri.se>
Date: Fri, 15 Jan 2021 14:57:53 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
In-Reply-To: <00d701d6eb31$05fe11f0$11fa35d0$@jpshallow.com>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Pdv8nlHvanNlz4A8E2T7fPi8DfUREuxQX"
X-Originating-IP: [92.34.27.84]
X-ClientProxiedBy: BL1PR13CA0411.namprd13.prod.outlook.com (2603:10b6:208:2c2::26) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from [192.168.0.68] (92.34.27.84) by BL1PR13CA0411.namprd13.prod.outlook.com (2603:10b6:208:2c2::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3784.7 via Frontend Transport; Fri, 15 Jan 2021 13:58:09 +0000
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 76ae1081-b806-489e-3b92-08d8b95d97ca
X-MS-TrafficTypeDiagnostic: DB8P189MB0840:
X-Microsoft-Antispam-PRVS: <DB8P189MB0840F4455A8D937F736B458399A70@DB8P189MB0840.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: 3lmUuUjqVy7cYTaSI6bOMb4ppl/4KpC+OWdNigvQHRuo+4M1EvpjkginsZQvmh/ypoSNY7N6jjupp5124G4Tazre+SruauAjuCBR0AeDXO4MRARFWFE5T1JJvBQ8aQxPFjuJqavmez+IZue/SUE2rlRfLHrZw3GRul8dWWMc6QVg91EO3W7DqztcgA10UHG0V9qQ6g0npt0jCnz2sxKx+aRvdipHG4bVkj0tKElpUB2lkySO1sC9CcJelSfVeBVVWM5oQIaVvFpDtpioj40sVwALxvSUa0WvxBRLsg33pKS+8LkTuc7xKtwW2EPMC53jCZkEUThszLLWYgyEeyUQoKUBHZ48v/qmWVfrwnQh0UDT7onuDarhD1bcoWdKfFwtjEq/Fu9y3gM1QO8UdqpVGKCMwTto3irmeNG3sp4WXM3dyknMuo/SJaKo9l2dJBmfRqNM8zMldK/rJt8/WpKEgVc8vl/2sU6k4+9iUgBm8Oh5PwMn0DdhUIKNiQH8zUpYKMIRHXeDU2suxd72PlywAVzam9Je8g3XshJ5VqM4e4GODn0thWE8e9UWjKMIvwKq
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)(136003)(396003)(366004)(376002)(39850400004)(346002)(8676002)(53546011)(44832011)(4326008)(45080400002)(6486002)(66476007)(316002)(66946007)(66574015)(2906002)(6666004)(235185007)(66556008)(5660300002)(16526019)(36756003)(16576012)(956004)(86362001)(31686004)(966005)(33964004)(26005)(52116002)(478600001)(31696002)(21480400003)(8936002)(83380400001)(2616005)(186003)(45980500001)(43740500002); DIR:OUT; SFP:1101;
X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?ZmJSeDh3bGVJdk55YVdBTlNvOFJwWTBJVFZvQnFOUGw4Yno1M1U3NkVLYlJl?= =?utf-8?B?K3JFMml3V0E2OVFJWkxFcjlIQnpicURhRzMxUlRHZ0N1bFVxNzgxc3Q3cXlH?= =?utf-8?B?NU1pRGo3KzJ4bEkzSDBKTm9MMnNTcDc3bmVIWEpjUDJPb1dvckhaaHd1VGtn?= =?utf-8?B?YUJaTmNQR21HalZvL1hQN1pIUlg2ZFhoRDRrSUxUaHpWc1N2dW5RMndqZmsy?= =?utf-8?B?cjlzYVppNVo0ZzBERHl5UExOQjdXSGNOWjFuYjBJckdlR2Yyelpwb3BHVENR?= =?utf-8?B?dlR3Ritjam9Zc2JEbjdxUXVBbzhzenFKTVl6cUhvajVxVUFIbThsMW5wQU5Y?= =?utf-8?B?aTFtMnpsNHZUN3drV3dvK1ZXdXFzOGRuK2U5b3JCYnBhNmRkMFVnY3l5U0c0?= =?utf-8?B?NGhmbzhzNWtLUTNQajZNZ0M0MktJU3IyQk9ycEthQ2pWSTZDWjZ5SFQrSlhR?= =?utf-8?B?ajhxMXl4UmVMcjVvT2VBekZ5UnNQQktEWmY0aVJCUUxWTEQrQVN1ZlU0N25M?= =?utf-8?B?UUxGTk9pV0RzMFZoRGo2SFdPWHlpN3VkNUtqRHdMK1hIU3g0UHdseEVkeGtw?= =?utf-8?B?MldWMmc0M000SHB3Q2hEWTN0czRWeENxaHlOMEwrQW83eGhITTV1WEM3NzM2?= =?utf-8?B?TWZuQVV5MkxKaENuNzFqZjRoQWRaQXh3OTlwaEVxamgxbEdYNlFjRVgzKzRu?= =?utf-8?B?WXlsMjdwdC9BbWZtSExnWGtpT2dZVUxQLzZ2cm5sZ3FUSXpNSFpUVnZIa1NY?= =?utf-8?B?RGY2ZDVHdHNvaGN5dVFvMW9FSFlzQllZNUltdkQybTMrUHNEYndObFNyN1BZ?= =?utf-8?B?NFF2TGlhZTdkOGxoVjFGV1hqMlZ4bWJtbHRrbU1MR3kyWUc0K2RZaVJqRjBq?= =?utf-8?B?S2Rvald1MmhGNnk1Y09SL1MvREsrcXF5dENEZFBpWnJENlF6T29ZR1FjdWpz?= =?utf-8?B?VVZBeFNDdnNuMFFMd3FIbWE4dGh3ei9aMHIzaGprdmVhNDZHTXBFVXJrME5t?= =?utf-8?B?WDRtUTZ3YVhQU3VpOGYvN01XcmE5dGxJaFBXaDdtcUVETDAwelhyQTVwWTVs?= =?utf-8?B?V0drbmE4NW5qc2F2ZmEzQ09EYnZDQVlhcDFUUmw4Z1E5b1lzRzZRQXVySlRB?= =?utf-8?B?Z1RsK3FVeGIwZ2tpM25MMVRTL0NFcVluMFRxQnZKNWlSdldVY3AzbHo0ZVlO?= =?utf-8?B?alY1V0lhODduNVNWL2NxdHo5enA1dEhuMHB3QTg0YlpwNXo3VmUyZ2NWTTl3?= =?utf-8?B?bnpkTE1VUG5taWVXQjhPWlZuQ3d1WWtvMmxRK21XN3FGUExMTU83YjFDcjI5?= =?utf-8?Q?Q+ba4JHIOGQxk=3D?=
X-OriginatorOrg: ri.se
X-MS-Exchange-CrossTenant-Network-Message-Id: 76ae1081-b806-489e-3b92-08d8b95d97ca
X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Jan 2021 13:58:10.5074 (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: HmRhbXH0zVTQfxUrti853mUAwI6j0yQWi/6FHoRoRt6qQty+baeT2P1+bIypSIcJ7D7gxZEFpRY2FBOFKF39jw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8P189MB0840
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/YCPtxWj1cJmkbL4Te6pzAXpqnAo>
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: Fri, 15 Jan 2021 13:58:18 -0000

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%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Fcore%2FOrr8a1WlSu3Dk-gtPQZloDT9_1E%2F&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7Cf30167412cf14279616708d8b948202a%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637463066740402421%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=E4lIccwYQyVGHxxl9v9iBr70hU6BuxRrzAQoZHnZt%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%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-ace-coap-est-18&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7Cf30167412cf14279616708d8b948202a%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637463066740402421%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=cSOOuCBEP2jCRzECrJeLli6Z%2Bu%2FUlD%2F1HzVWIM7O7%2BQ%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://www.ri.se