Re: [Dots] [core] WG Last Call on draft-ietf-core-new-block

Marco Tiloca <marco.tiloca@ri.se> Mon, 11 January 2021 19:23 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 BB96F3A10E6; Mon, 11 Jan 2021 11:23:23 -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 2yn2-haQ7WPo; Mon, 11 Jan 2021 11:23:20 -0800 (PST)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150049.outbound.protection.outlook.com [40.107.15.49]) (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 3B9353A10DF; Mon, 11 Jan 2021 11:23:18 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eW+evJa9PqzwqaY7Fq7+olx2f3/irw2j43A9w+68YR2FxvYWkr97Oyc2/26oLGadsoE3O5VUbWhjkFc79FY561K9RqWSyUVuR3lx4JcGpEiIt9B6SdJ+N3u6CPA7B+HRDfNNbitrHu+inLLr9z8m7JhxXbxVtHi5EaF1EkbptwPkr1ynOHuNwBSc5A71hn83AFEkIl3Ct5/UHRGfpo/Fzawny2iZuy/rxUtur13R/l8Wja2erNiu5UxYw6LJOLYsjl/wccKqLQ9ZOaGFDI8tpQcUFCMDQfg0iFSLHxy8S29cylBDQkmCNNCdHwKU9xI0uV+TH/AalDRM6bFUL+ArJw==
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=6LSligQpzMUYWntm2/EfhNzk0t0QNU49hV2nZM0/J58=; b=Us6mf6UWEnIFEMIbpsvfjNiLtzQmk7WMCcB+AUJr7vzWrbSlD7jmbPj589FdltMOEdI1AqA2dzq2Lg+gbNhs5I+W/MYTPzkz4JEpmE+nB/RUfzDTzDwggmhV8gM/zNKAxcRMmBwIVRsizyeWD3XG9+koCYZXq1AlSTw5AWBKjGCV9fre8heBbpfPSRa5umuRLli+dfC0w0NeudmTtU/HV39Xk/Ovc42qAwJppEYKafXvC54nAMgwVY2PCa8olEm+Ylmxe4tHg1DVHZmhQ5giJZK5y5WTKkgm+90L7qHlIV2qY68FkMusNN9Qi8ytwz/EYubV9H/JlH53nlJIhTdluw==
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=6LSligQpzMUYWntm2/EfhNzk0t0QNU49hV2nZM0/J58=; b=GDec57LWJ/kT49HN2wzBuGcSLoUxpHaNWzO0eSMhH3wgmAh6AY2SrJ7pY20OClNRcFHEOYIj/k2Clv0dZhpKKtkjX4JvnJg7SvpNvaWt11EQOTPbrVzYmRLtgGFDwVaXA3n8drQ3RK3f03e1VR4flETFpxJ4blvblH9xi6nrfks=
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 DBBP189MB1308.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:1e5::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3742.6; Mon, 11 Jan 2021 19:23:15 +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.3742.012; Mon, 11 Jan 2021 19:23:15 +0000
To: supjps-ietf@jpshallow.com, jon@jpshallow.com, christian@amsuess.com, draft-ietf-core-new-block@ietf.org
Cc: dots@ietf.org, core@ietf.org
References: <022401d6e440$06763ba0$1362b2e0$@jpshallow.com> <fa7956ae-31a3-7724-3af4-4e755a719045@ri.se> <041101d6e5c2$e17fbef0$a47f3cd0$@jpshallow.com> <a549b34f-3f72-a6df-b2c3-ae9d3759b701@ri.se> <047b01d6e5e2$2115ba50$63412ef0$@jpshallow.com> <f8774b5c-9736-1cff-266f-f9b66653a86c@ri.se> <065301d6e805$286163c0$79242b40$@jpshallow.com> <df2ee5a1-0d36-7f28-534d-42f2eb063040@ri.se> <06e801d6e838$4be6ae30$e3b40a90$@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: <82c69828-fcc7-b039-925b-00d5a3fdce8a@ri.se>
Date: Mon, 11 Jan 2021 20:23:07 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
In-Reply-To: <06e801d6e838$4be6ae30$e3b40a90$@jpshallow.com>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="hxzk1jEBL79PhTWI869EybVhEy2uxce8U"
X-Originating-IP: [185.236.42.23]
X-ClientProxiedBy: HE1PR0402CA0016.eurprd04.prod.outlook.com (2603:10a6:3:d0::26) 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.3] (185.236.42.23) by HE1PR0402CA0016.eurprd04.prod.outlook.com (2603:10a6:3:d0::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3742.6 via Frontend Transport; Mon, 11 Jan 2021 19:23:14 +0000
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: cce4698b-0904-4e90-f51e-08d8b6665845
X-MS-TrafficTypeDiagnostic: DBBP189MB1308:
X-Microsoft-Antispam-PRVS: <DBBP189MB130896909349AB5C9978238A99AB0@DBBP189MB1308.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: 7pJrLyWeM87AYO4FOQKjq7UKQ1Ir034nKrQciy5POAOXvBggxz0RPd7K5CII1PL3Y9ZLAB8t51njd6GCCWvn2XFMJeYn+Ee9IVyOzj1oo6zM1QNZ+Rram0cSUp9b5h+GNnoCyI+ImH3i+RKYLh0ma8Br4uK3V7+vJ+UiDQhz7CEqGOEH+lZVGaVeJvYWj0777gSNJiPYk4UZ9fX3jzTAUFP88nInMUS25J5FpD1czGBqPG6hnEORm4jiAAUK+HkupIrhYuPC81mNt9d83Z9nMQOXMRv9mLu1EDC0uIcnYjmvpGIoXvEqfQJWrKpbEM3phTDRLwFBKQRD7H97HOUnxNXLgeE8EAARZciDWc8XboLUI5F7HLVVudEXs61Ek0UxWp8rqWMVK7ZZ1eY4gNSN34hfCGy/WpZD9V1Q0/i+swuP8Um3VJnBNEXRfCbdptzGVmtQN1iXf3LlOWm02IAM05ypGYZWqzeMGaHCC9nouL1CQRbhz1ofjAcxCFhBYDMcwmkFM0OPd6nlGPEVmrS1yQaJYSb9mI0A4muIwE9CyAp8GrB1abHeCmq9zzwaqLtD
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)(376002)(366004)(396003)(39840400004)(136003)(4326008)(66556008)(186003)(66476007)(16526019)(36756003)(8676002)(33964004)(66946007)(5660300002)(44832011)(26005)(956004)(83380400001)(2906002)(235185007)(316002)(2616005)(6666004)(6486002)(31686004)(52116002)(16576012)(31696002)(45080400002)(53546011)(86362001)(8936002)(966005)(21480400003)(66574015)(478600001)(43740500002)(45980500001); DIR:OUT; SFP:1101;
X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?RC9KQmltWVpqVFY3dnd1VkV3WGRpemFZRlJXTnYydzdCZUdFYWJuc0hDU29B?= =?utf-8?B?RUZSM3BRQWk4a29HQWxXT3VXNmRLSFVFUFJVNnVvaEx2bmxPa05QY2ZtcTNq?= =?utf-8?B?dXI3OHFrZGlTeCttSWJHcWx1KzhHTXJ0aHgvK0l5UUcvWGdQaEU1dFBndEdO?= =?utf-8?B?UHRQd0s5YUFHZkdGclFLTjVVTGpib3RBditFcFpySklXRWdEaGVRSFJmWjZs?= =?utf-8?B?bzBHaGRHYjRMbVBmaExHdGluMkw2TEg3VEl6ZWMrRkZPZTZkQ3pRcEYxOEdK?= =?utf-8?B?YkRSa1BMZUpPeVpvSmZBbEhiS0NaWFZ0Q2dJOXpGYXpVSG95c05YaVZGaUV5?= =?utf-8?B?NVNlbXZseWZ1bWJDdUxVRVdFRDdsZFVWSmdobVZ6RlBITUx0dkFmaldXZDA5?= =?utf-8?B?NzF5TjUzZ0c0YUpFdDdiREVWazBKUCt0d2VrUkc5YzhKTm1aREFyd2NSVk9r?= =?utf-8?B?NjNKUWJSUWUvRWxnbTBVS0VQNFZHNzVtYVhuWHFjMXlLTjZNVlJsUUkxSVQ2?= =?utf-8?B?Tk5MMXZsTnc0QnZJcUhLZ29wY1YzQmErZzJsUXVVM1YzMmtwV2NZbVE1aExi?= =?utf-8?B?MHROTGpWNCtLNzFOSkwxUWdTeEcyemM5cVpGeTB1SzQrMW1aZzVpOGJiSEhs?= =?utf-8?B?ZkJKbzFSdTdvNXF6dHcwQ2VQVXNneW9mUzk0N2E0bDg4cUlzNkxNRW96ZStY?= =?utf-8?B?YkhNWWZYZ0VGWFRTbVdCUTVyRS9UWWQxODMvcUF6WStHaU9jWG5wUWZ0cmdR?= =?utf-8?B?M0lzVjVvQXJxTXQydEFRaVk5SmloWWp4THcxOExobk8yTml5dzdaRzB2QWYr?= =?utf-8?B?Tnh2akdpM3RkTGc2ckRQdTRSTjNJMjhhTTlpaGVHbkhCVkFERkFVd3NZSm9I?= =?utf-8?B?V3VZbGk5d0c5NGR4VmRrWmpVaU1xa2twaUdBTWFNVnRBNHJ1Uk9wOUdzQU13?= =?utf-8?B?VkVlUDlrYTg0V1RyQWZkU3NrTzU0anZla0doQzM5SFlDSklQSnlnTjNwcFB0?= =?utf-8?B?WUU2aDcxK0JoY0NhY295MjNuVEhvL0ZubjZlT2lBQlpFQkd3UEgvK0tpUlUw?= =?utf-8?B?RDlPZUxCN3YrWWdXTHluTDNLbWN0UUtXWGF1SEhLNmxzV205czFZc1lQT0J1?= =?utf-8?B?eHRUY2UwalJxOFR2OENxK2x6RnRIODRJbGh0REhCVWI4R0tybXViaEJ6TTZN?= =?utf-8?B?MmVsY2NaM0syYndVSE4yekhrSVZFaUZGZ2ZpSUhIQjBNYytrWlZ5K0Q2WUc5?= =?utf-8?B?VzJvdkZkekNJU2Jvc01xNk9WRmNPdkVOdVJGa0NYTENUOEs4dURBVDM0dGZF?= =?utf-8?Q?tnoNbnxvYsC34NHQu73+h8Xxw75xsKR7ID?=
X-OriginatorOrg: ri.se
X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 11 Jan 2021 19:23:15.5530 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8
X-MS-Exchange-CrossTenant-Network-Message-Id: cce4698b-0904-4e90-f51e-08d8b6665845
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: Y8P9kyK2cQQ9CuSGg4sDmnpa5DyjPXBmBJozpJIlvNC+eurj1XULDXgH2p4bEw3Wc1+NwoRiSJujQdL1sxP6Mw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBBP189MB1308
Archived-At: <https://mailarchive.ietf.org/arch/msg/dots/l5jZ1jBc5tgWycZo4ntNlQ-YUf0>
Subject: Re: [Dots] [core] WG Last Call on draft-ietf-core-new-block
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: Mon, 11 Jan 2021 19:23:24 -0000

Hi Jon,

Thanks for the fast reaction. Please, see inline.

Best,
/Marco

On 2021-01-11 17:39, supjps-ietf@jpshallow.com wrote:
> Hi Marco,
>
> It is good that you are thinking this properly through.  FETCH was added later into this draft and the consequences were not properly thought through.
>
> The new updates have been pushed to https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcore-wg%2Fnew-block&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7C4c6021fd365344ae633908d8b64f6af1%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637459799554192170%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=P5eiQyl8meRhZX9t6gtNqwc29ryqLRGnOUwmFQxAydo%3D&amp;reserved=0 and the differences with the draft can be found at 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%7C4c6021fd365344ae633908d8b64f6af1%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637459799554197148%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=IYKVrC1a56Cva5mR4xoM0VM5y6dhjtQ7M6L5PwlCqzA%3D&amp;reserved=0
>
> The PR for the responses below can be found at https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcore-wg%2Fnew-block%2Fpull%2F13&amp;data=04%7C01%7Cmarco.tiloca%40ri.se%7C4c6021fd365344ae633908d8b64f6af1%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637459799554197148%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=b9hq1V5X136oGB65e9Ni12V0weXoNa%2FY1DT8QtzFRqQ%3D&amp;reserved=0 
>
> Otherwise, see inline.
>
> Regards
>
> Jon
>
>> -----Original Message-----
>> From: Marco Tiloca [mailto: marco.tiloca@ri.se]
>> Sent: 11 January 2021 11:39
>> To:supjps-ietf@jpshallow.com; christian@amsuess.com; draft-ietf-core-new-
>> block@ietf.org
>> Cc: dots@ietf.org; core@ietf.org
>> Subject: Re: [core] WG Last Call on draft-ietf-core-new-block
>>
>> Hi Jon,
>>
>> Thanks, the updates look good.
> [Jon] Thanks
>> As to the response codes in Section 3.3 "Using the Q-Block1 Option",
>> wouldn't it make sense to mention also 2.05 (Content) ? Think of a FETCH
>> request with a big body, which is actually mentioned at the beginning of
>> Section 3.3 and in Section 3.1 (though missing the 2.05 response code
>> beside it).
> [Jon] Thanks - added.  Also added in 2.02 and 2.05 as being expected response codes in 3.3.

==>MT
Looks good.
<==

>
> [Jon] For the 2.02,  I struggle with why anyone would want to use a POST with a large payload to cause the resource to get deleted (instead of using DELETE) , but RFC7252 allows this to happen.

==>MT
If it's really about the client just asking to delete a resource, then a
DELETE is more efficient.

But, the client might just be asking the server to process its POST
payload, and it's the server that eventually takes the decision to
delete the resource, as a possible side-effect following the request
processing.

I think that's what the "if" wanted to suggest in RFC 7252, Section
5.8.2: "If the POST succeeds and results in the target resource being
deleted, the response SHOULD have a 2.02 (Deleted) Response Code."

Alternatively, the client may actually want to delete the resource as
somehow indicated in the payload, only following the processing of the
rest of the payload. This would not be possible with a DELETE (that has
no payload) and if supported by the application it is more efficient
than sending first a POST and then a DELETE.
<==

>
> OLD
>    Q-Block1 Option is useful with the payload-bearing POST, PUT, FETCH,
>    PATCH, and iPATCH requests and their responses (2.01 and 2.04).
> NEW
> Q-Block1 Option is useful with the payload-bearing POST, PUT, FETCH, PATCH, and iPATCH requests and their responses (2.01, 2.02, 2.04, and 2.05).

==>MT
Looks good.
<==

> [Jon] And added into 3.3 (2.05 is done further into this discussion)
>
> NEW
> 2.02 (Deleted)
>
> This Response Code indicates successful receipt of the entire body and the resource was deleted when using POST (See Section 5.8.2 [RFC7252]). The token used SHOULD be from the last received payload. The client should then release all of the tokens used for this body.

==>MT
Looks good.
<==

>
>> Also, more in general, think of an observe registration, for which the
>> server eventually sends back a first notification (possibly split into
>> multiple payloads) with Q-Block2, with a certain Token value.
> [Jon] OK
>> If the observation request used FETCH and was fragmented into several
>> payloads with Q-Block1, each of which with a different Token, it's still
>> true that the notifications can all have any of those Token values and
>> should have the one of the last received request payload.
> Jon[OK]
>> However, later on the client has to retain that Token value as the one
>> associated to the observation, to match future notifications to come. In
>> this case, there is a deviation from the claim used for other response
>> codes, i.e. "The client should then release all of the tokens used for
>> this body." This should concern only 2.01 notifications (hence including
>> the Observe option) in response to observation requests with FETCH, so
>> it can be limited to the context of this section about Q-Block1.
> [Jon] I was not aware that FETCH could return 2.01 or 2.04.  GET does not return these codes and it is only GET and FETCH that can Observe.  

==>MT
Oops, I actually meant 2.05 in the paragraph above. Sorry for the confusion.
<==

> However, it is true what you say for 2.05, so I have added that the tracked Observe token must be the (if Q-Block1) the one used for Q-Block1 that has the M bit unset.  I have added in some FETCH examples into the draft.
>
> NEW
> 2.05 (Content)
>
> This Response Code indicates successful receipt of the entire FETCH request body (See Section 2 [RFC8132]) and the appropriate representation of the resource has been returned. The token used in the response MUST be the one in the FETCH request that has the Q-Block1 with the M bit unset. If the FETCH request includes the Observe Option, then the server MUST use the same token for returning any Observe triggered responses. The client should then release all of the tokens used for this body unless a resource is being observed.

==>MT
Looks good.

As to the two new examples in Figures 11 and 12, please add the Observe
option with value 0 to the requests from the client, i.e. O:0, just like
you do in Figures 7 and 8.

Best,
/Marco
<==

> ~jon
>> Best,
>> /Marco
>>
> <snip>
>

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