Re: [core] Chair's review of draft-ietf-core-echo-request-tag-03.txt

John Mattsson <john.mattsson@ericsson.com> Wed, 27 February 2019 15:13 UTC

Return-Path: <john.mattsson@ericsson.com>
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 C1A46130E71 for <core@ietfa.amsl.com>; Wed, 27 Feb 2019 07:13:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Level:
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=hS9xSUln; dkim=pass (1024-bit key) header.d=ericsson.com header.b=krw0PdbS
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 FkOuHG092V9p for <core@ietfa.amsl.com>; Wed, 27 Feb 2019 07:13:19 -0800 (PST)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 1BA11130FDB for <core@ietf.org>; Wed, 27 Feb 2019 07:13:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1551280396; x=1553872396; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=OXvEmj3P3za6T5fAyS9kpfhB4JBdlrWv6EyO1YPRuZw=; b=hS9xSUlnVI/0KREbgKfhVjtcI+UWiY7Wj72zT9dEK8fR2U888WwrQ2LoFjbfpuYW VnUjUTMOgJoUka+RNIzTMST92buStb/JRk/7AD8a95shgTth7RMrZ8vuGa1QKJdK nwmuLbRi8A8G3WUphOYJ6cmWvD8nml5rPNPrEKonrQU=;
X-AuditID: c1b4fb25-209009e000005ff7-a2-5c76a90c9257
Received: from ESESBMB505.ericsson.se (Unknown_Domain [153.88.183.118]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id FD.D1.24567.C09A67C5; Wed, 27 Feb 2019 16:13:16 +0100 (CET)
Received: from ESESSMB504.ericsson.se (153.88.183.165) by ESESBMB505.ericsson.se (153.88.183.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Wed, 27 Feb 2019 16:13:08 +0100
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB504.ericsson.se (153.88.183.165) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Wed, 27 Feb 2019 16:13:08 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OXvEmj3P3za6T5fAyS9kpfhB4JBdlrWv6EyO1YPRuZw=; b=krw0PdbS5rz/yQBrR5Y8GCiRgEhjiwL6Y5dsDVMvDsuzK8p2cHzb1tAa+9F2TjG7Rx2foBZVy+fkXPz8tW0cdfY+gfNYZJhTmKGhonDnumRG+sxpGgWvFHfwnOVUePFdi3yysmYwbwm5fAAp3yJ6JvHJugbyNHVnjmpCJYKa/1c=
Received: from HE1PR07MB4169.eurprd07.prod.outlook.com (20.176.166.22) by HE1PR07MB4265.eurprd07.prod.outlook.com (20.176.166.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.5; Wed, 27 Feb 2019 15:13:07 +0000
Received: from HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::49f9:ba7d:bd7d:2ffc]) by HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::49f9:ba7d:bd7d:2ffc%5]) with mapi id 15.20.1665.012; Wed, 27 Feb 2019 15:13:07 +0000
From: John Mattsson <john.mattsson@ericsson.com>
To: Carsten Bormann <cabo@tzi.org>, =?utf-8?B?Q2hyaXN0aWFuIE0uIEFtc8O8c3M=?= <christian@amsuess.com>
CC: "core@ietf.org WG" <core@ietf.org>, "draft-ietf-core-echo-request-tag@ietf.org" <draft-ietf-core-echo-request-tag@ietf.org>
Thread-Topic: Chair's review of draft-ietf-core-echo-request-tag-03.txt
Thread-Index: AQHUvixxa6SvJqEWH0a4oRCMNic0caXo7zYAgAsDFgA=
Date: Wed, 27 Feb 2019 15:13:07 +0000
Message-ID: <2B060561-F634-45F7-A801-BF3D94863E52@ericsson.com>
References: <963CE8EA-ABAC-488A-8FA6-81431A2E5B06@tzi.org> <20190220160311.GA19473@hephaistos.amsuess.com>
In-Reply-To: <20190220160311.GA19473@hephaistos.amsuess.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.16.0.190211
authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com;
x-originating-ip: [192.176.1.92]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: a79674f6-d9f0-437b-ab0b-08d69cc61441
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:HE1PR07MB4265;
x-ms-traffictypediagnostic: HE1PR07MB4265:
x-ms-exchange-purlcount: 1
x-microsoft-exchange-diagnostics: =?utf-8?B?MTtIRTFQUjA3TUI0MjY1OzIzOjZWQXczdjJ4blRtNUYzSVRkbUZVOFdMSkFQ?= =?utf-8?B?T2RxVEowVnkzNGNrRGxiZzhxakdLV2thbjk2QXNteDJaWmRVbmZtZTIvc3ZN?= =?utf-8?B?TG1IRFd4Q3FWVmIwUXNEMnluZ1RNaTkwc2JDa1FHSmI2aTBIelh4ckNacmhO?= =?utf-8?B?cnN6K2pZLzB5TlQxaUVqMlJNVCtwenlER0g3V1FDTHd4VzROUEJuMzdWSU85?= =?utf-8?B?NGUvay9KQkdzZzZTZ2RRMWJIVnhOcldPbnJlWDdYTFVGcHJmbFQwaDdmbnVy?= =?utf-8?B?cFdHT3luMzJ2MkVOZ1gzcjV2MXlXQVBCa0R6WGR3dUZJbExVOHAwajltQVFi?= =?utf-8?B?WHdNYWJIWWEyYkpZSGo4LzFEdzRSVWUyNHY4WE92Q0crSENWWWIvMWxWMmtZ?= =?utf-8?B?eEF0RnpyZ0ZKOEtNdDdncmVVUmtVUm5YMlRaWnJlLzA1UU1Xbzk2TFFDVkhr?= =?utf-8?B?djRtSlRtbjJkbThEKzZjSlFmbTljdTl4VkhsUkhURXphSllBazZtL1hjVFZ2?= =?utf-8?B?VDg4TlQxR3ljZURFdXA5RlQzOG9OWk5JNVJnYldKcWVsejZBZkFnWGNSUFMz?= =?utf-8?B?cy9vUlRFV1NIc3kwSk9mVG9xSnRMSDhyVEFIZjE5b1ZMdHJMbVBWd1ZGUndF?= =?utf-8?B?eU9yMXdveVRIT3h2YnM5Umg4NUR1VW1CYUl2dGNNSDgzQVRXVzY4YzNUdWg0?= =?utf-8?B?YzRrV0dYYWV2VCtFMmFlOExHUU1yajJzOTdhVEtGbXg3YSs2QkVyK2pqcmZu?= =?utf-8?B?S0NtTWZGTnd4aWRURGllWURaNlcxUkRkVzVVZm1jbVZjT2FuYkRLQ2lhSmt1?= =?utf-8?B?dFJmT0pvMVBiYWVQY0ZhVGpJdFV5enJIWXZ4L3BXclprRGlvd1ZLcWk4N05v?= =?utf-8?B?Mk1iVERDOEhucng5M2EwRm5BSXp1Ny9MWFJpOUJuMUlZd3pvVUNHaFo5VmY5?= =?utf-8?B?b1p3S3B2UFBzc3F0NzdNSThYMEtaWnU5M3hITGxOVGNGNVN2YjZTT29zS24z?= =?utf-8?B?VkkzK0I1Q3dCWW13NitaNCsvN2duZloyaVg2QkdLNDBLY1RoZkw0cHJXa2Fv?= =?utf-8?B?c2xaMnFSYkNUU1pwdE9ITmltRUxCZXFvaDU1eHJrTUZmaTBINUFXVjJmSkRu?= =?utf-8?B?Vmt4SHhCQVhGKzJuMU84cTVneWt0bWhNS0JjRWFFSVUvRlc1S04wVktxclNN?= =?utf-8?B?SGUrT0VwZ3l2TFZuZVBSZlZTWEdVcHRhQytiZkViWGp2RkYrZ1ZyVExhaXBq?= =?utf-8?B?ekVyM3ZGTzhxdzJwSkRWQ0o4NW5JV1RKRlU3RlUwRGhFclR5U2orczlZOUcr?= =?utf-8?B?clVrVkU2Qk0zSUxQRmhrZ0JHbXE2YlBpWXo5K0JLQmtxNjd4YzdjaVFKZXJy?= =?utf-8?B?eEs3b3dkTTc2NyszOTJ5S0J6MFV0Skl1MnN3UW9obGVqdWpiekt6QXlyLzI0?= =?utf-8?B?VEpjWjlTUnJhbkpoM1RhRHQ5V0pFRkFYOUxwUi8xMFgyRU5hS2duMlFycVZU?= =?utf-8?B?Z0VITkllc3pwMWRpMlNVcEVxL3g4RFg5M0JnRFIyT2tJcWlpL2taUnlUd3RQ?= =?utf-8?B?WXFnQng3NU5JdWVHUWo1a09DU2cxOHNsYTM5NXdMNzl1Z21pNHVQZjk3SSt0?= =?utf-8?B?OEdDQkI2Ujl1NFVRNVZCNXRlWjlyZWRoOTl2TDM1ZWQyWFU0MmtoREFQRkJN?= =?utf-8?B?Zk9jNDE2RkE4aDAyaWVMVW1OQzFDeTVRWWZScU9Fb2ZNeHdiZ3gweXc1M0lF?= =?utf-8?B?c29tTjloMmtkaE0wbjJpTE4zYW0rbWxhNWZxZXoxTWNXdFlFbzF3MU1iM2Yr?= =?utf-8?B?ZzlqOHRIVVlOYk5xbWZ1a0dpN3F3aUx0bTA3UGpwY1drdUlodnpTL2c5WW9x?= =?utf-8?B?TytDVzVmaUZsa0VucXByVERLQUF1TE9NbFhaL3F3TEo1Y0xXNVBJN3UrOFpQ?= =?utf-8?B?ZFhtQXhXakRBPT0=?=
x-microsoft-antispam-prvs: <HE1PR07MB42650441CB0C62405080D1A689740@HE1PR07MB4265.eurprd07.prod.outlook.com>
x-forefront-prvs: 0961DF5286
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(136003)(396003)(346002)(376002)(366004)(189003)(199004)(51914003)(13464003)(5660300002)(71200400001)(71190400001)(478600001)(66066001)(2906002)(26005)(83716004)(97736004)(966005)(102836004)(81156014)(81166006)(44832011)(6506007)(25786009)(68736007)(86362001)(476003)(8676002)(14454004)(36756003)(106356001)(2616005)(486006)(6246003)(53546011)(105586002)(446003)(11346002)(6512007)(6306002)(54906003)(8936002)(99286004)(58126008)(110136005)(6116002)(53936002)(6486002)(3846002)(82746002)(6436002)(229853002)(316002)(66574012)(7736002)(256004)(14444005)(186003)(305945005)(4326008)(33656002)(76176011); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4265; H:HE1PR07MB4169.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: bsmGleQ+8mbKsM6WZ9In1SKOx4UoRXHmW+f63Gat2Im/vHOjPjNTJBljH2L2CUCAvoon8StZa4hsARLqWk/GHuxXHzIG+/M2lhYT4adXUK6KOxYZz8hpkRzYJKWqfYwoaURR1IjIbMIjNuho6jLO1k7UAZG4wDPQI5I+Nx/medeSNNtGJuW67miCp6Qa2W4md9S1Z9XfViIrZyL6XnElwrYGNkbJUqt37LysaZeR+pRVyypFx/ehg9ruPpAgq6RCq5ydrOvX3/sDmQ/44UwqiTpVg+c8WSm89yq3iOZgXU5pdIyeDITiYMO+TLVPnfz0qpHeKoEWO/GjuGP34k1JLqh+GcFEp1oHMyhSP7wp63n9KXXcFE1gv343nIuo1XKEp9gWGf7USBcxM12SBOmAprVs46w6fAuh8ZJOwHS/NPs=
Content-Type: text/plain; charset="utf-8"
Content-ID: <2B381349B21D8745B18839AB42BFF438@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: a79674f6-d9f0-437b-ab0b-08d69cc61441
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Feb 2019 15:13:07.4768 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4265
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTYRzGeXfOmWfLweuc+WcZ6WgfFPLWxVVWBmGj6EJRiGi28uiGc8rO GtmHlGQUXkpIMi2dyaKURDRJUzNdMzTzNkMqFNNmKCRWWuKVdnYM+vZ7n+f53+ClCelDSk7r DCbGaNDoFUIxWRrXZN7hXW1OCC8pJFWO4jFK1d58m1S1z9YRqvHuVmEMqc7rXKbUNtuSQH2v SneaiBdHJzN6nZkxhh28KNY+cXVRmc74q7WuASIHPY3LQyIa8C6oWpkS5CExLcUOBL+GWxBn SPEfBIvWSN6wCcBZ+Z7gHiQuImC2oZ7gU3cFUFq8h09NIhiZfi7kDCEOh/K2HA/LcAqMf+vx VBM4F0FPR4eAM3xxLEyNTlB86CisPupzM+3mfVDbuZ+TSawEy7LV00eCD8GLW3OeiBTr4f5I MCeLcDS0f2j14hjhzbD47pmnO4H94bPLKuDPxGBrGyB49oOZr+ueqX44DOpcfB7hRLBYSig+ Ewirzkkhz1vBac1HPJ+AtcYZkjsF8CcED0bnNgpCoOL3440Bcuge6qL4UIUvOOtyN7ZIA+tN qxd3AOAA+HFHWYTCy/7btcztEDgY6lrCeFkNs45GL56DoDh/wsMS7AM9pS6yElE1yI9l2Evp qZE7Qxmj7jLLZhhCDYypAbn/TGfjirIZDX8/bEeYRgpvyVCVOUFKacxsVrodAU0oZJLt5W5J kqzJusYYM5KMV/QMa0dbaFLhL1mV+iRIcarGxKQxTCZj/OcKaJE8B4VGBTp6N72qDDhZY9x2 flgUllJRNJTzOnY4af5IVP6b9XXRhRvHij6Kpr/8rM7eHXv8gEyW9nJ2LEK8NtgUNNLYmZ4d HTeYiBf2DuqdvQt9yjPxloFQ+Xz/uaSJFGug/brv0rT1lI95cLmgX6s9WWCbO1sYY+h/Wy+Z XJjxZ5dMCpLVaiJCCCOr+QsY2FdVLwMAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/cPKeFMPuHMVrr3uywIMIRsLDfeI>
Subject: Re: [core] Chair's review of draft-ietf-core-echo-request-tag-03.txt
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, 27 Feb 2019 15:13:22 -0000

Hi Carsten,

Thanks for your review! There were a lot a good comments. I updated the GitHub version based on your comments.

https://tools.ietf.org/rfcdiff?url1=https://tools.ietf.org/id/draft-ietf-core-echo-request-tag.txt&url2=https://core-wg.github.io/echo-request-tag/draft-ietf-core-echo-request-tag.txt

On Wed, Feb 06, 2019 at 03:58:02PM +0100, Carsten Bormann wrote:

>* Title and Abstract.  The title probably should mention CoAP.  The
>  abstract might want to say what the introduction already says: This
>  is for supporting specific use cases (i.e., not all use cases will
>  need these additions).

Good suggestions, I have updated title and abstract.

>Completely outlawing token reuse is throwing out the baby with the
>bathwater -- requiring stable storage for token numbers even in
>situations where that is not needed.  (Of course, if you have that,
>keeping a token counter e.g. per DTLS connection is a great
>implementation strategy.)  Instead, the recommendations about Token
>reuse should be specific to the cases covered.  This does require some
>additional work.  (The actual wording in Section 5 is closer to
>reason, but the introductory material gives a different impression.)

Very good with some feedback on this, I asked for that at an earlier interim. 

If the intro gave a different impression than the specification text, that is obviously wrong, I changed intro text to align with Section 5. The current specification text was chosen because it is easy to analyse that it is secure, easy to describe, and easy to implement correctly. It was also partly based on a comment from Klaus that token reuse caused all kinds of other non-security problems and should therefore in general be avoided. If we change the current text, what kind of specification text would you like?

- One option is to write a high level requirement that the client MUST NOT reuse a token if it can lead to a mismatch, and then give sequence number per traffic key as the recommended implementation strategy. But this is not very helpful for implementors as the problem is quite tricky to analyse. I updated the current github version to say:

"When CoAP is used with a security protocol not providing bindings between requests and responses, the tokens have cryptographic importance. The client MUST make sure that tokens are not used in a way so that responses risk being associated with the wrong request. The easiest way to accomplish this is to implement the Token (or part of the Token) as a sequence number starting at zero for each new or rekeyed secure connection, this approach SHOULD be followed. To avoid collisions the sequence number can be encoded with a fixed length or with some length-value encoding."

If we go this route I think we need to give more detailed guidance on when a token MUST NOT be reused. Such guidance would likely include the size of the lower layer replay window, a list of verified received responses, and whether Observe is used or not. It that worth doing?

I do not really see the problem with "requiring stable storage for token numbers even in situations where that is not needed", if you are using DTLS in a secure way you obviously store the DTLS sequence number already....

>The wording in Section 5 needs to be clarified that this is a
>requirement on clients, not a license to servers to base their
>operations on the assumption that this requirement is always fulfilled
>by a client -- the token processing rules of RFC 7252 still apply.

Yes, I updated the text in Section 5 to clearly state that the updated requirement is on the client and that token processing for servers is not updated.

>* Section 2 would benefit from discussing freshness as a concept
>  first, and then introducing the Echo Option as one convention to
>  achieve the objectives.  In particular it should be clear that the
>  rendition of Echo with a 4.01 may be an unusual case in many
>  applications.

I made an attempt to discuss freshness as a concept first. Could you expand on how sending Echo in 4.01 would be unusual for applications?

>* The document fails to mention that the "echo" function can also be
>  provided at the application layer, e.g., with freshness tokens in
>  "forms", as they are widely used with HTTP.  It should make clearer
>  that "Echo" is just a convention to provide these freshness tokens, in
>  particular when there is no natural way to keep the freshness tokens
>  in the application data.

Good point. Added new text saying just this.

>* The "MUST NOT process" in 2.2 is weird, as it is qualified by the
>  undetermined "has freshness requirements".  Maybe the text should
>  focus on the concept of "fresh enough", which would also explain the
>  license for the client to re-use Echo values in further requests.
>  The time-based processing model ("RTT < T") is one way to handle
>  "fresh enough", but certainly not a MUST -- there are event-based
>  freshness models.
>
>* Requiring a monotonic clock is a consequence of the implementation
>  model proposed (time-based freshness) and is not needed with other
>  forms of freshness.  In any case, if the non-monotonisms are limited
>  to below the freshness requirements (as they would be for most
>  usages of civil time), the are inconsequential, so these security
>  considerations require some qualification even when phrased as such.
>  Monotonic vs. wall-clock is somewhat orthogonal to non-hackable
>  vs. hackable, anyway.

Good points, agree that models are also valid and that non-monotonic time may be used. I softened the language conserning these aspects and added more guidance instead.

>* Section 6 (Security Considerations) MUST NOT use BCP14 language.
>  Move the mandates up to where they belong.  

Is this some new IETF guidance I have missed? Most RFCs (e.g. RFC 6347, RFC 7540, RFC 7252, RFC 8442) have BCP14 language in the security considerations... 

> * Appendix A could contain some help with the selection of n.

Good suggestions, I added some guidance.

-----Original Message-----
From: "Christian M. Amsüss" <christian@amsuess.com>
Date: Wednesday, 20 February 2019 at 17:03
To: Carsten Bormann <cabo@tzi.org>
Cc: "core@ietf.org WG" <core@ietf.org>rg>, <draft-ietf-core-echo-request-tag@ietf.org>
Subject: Re: Chair's review of draft-ietf-core-echo-request-tag-03.txt
Resent-From: <alias-bounces@ietf.org>
Resent-To: <christian@amsuess.com>om>, John Mattsson <john.mattsson@ericsson.com>om>, <goran.selander@ericsson.com>
Resent-Date: Wed, 20 Feb 2019 08:03:31 -0800

Hello Carsten,

thanks for the review, addressing the points that are not still being
processed by the authors:


On Wed, Feb 06, 2019 at 03:58:02PM +0100, Carsten Bormann wrote:
> * Is "operation" the term we want to use henceforth?

Would "transfer" be more suitable? It's probably well-aligned with
RFC7959's use of the term to just give a precise definition again and
use that.

> * Section 3 is confused about Request-Tag Options and lists of those.
>   Why was the option marked repeatable?

The option is repeatable to allow tiny proxies to satisfy all their
blockwise-handling obligations by adding a per-sender Request-Tag
option. (The alternative would be that they string-append to any
existing Request-Tag option, which is somethign I'd perfer not to do as
an implementor).

That's outlined in section 3.5 but I agree that the wording is far from
straightforward.

> * Title and Abstract.  The title probably should mention CoAP.  The
>   abstract might want to say what the introduction already says: This
>   is for supporting specific use cases (i.e., not all use cases will
>   need these additions).

Addressed in the next version.

> * Introduction.  The introduction could say earlier that Request-Tag
>   is intended exclusively for combination with Block1 options.

Added.

Note that the Request-Tag option can be present in messages that carry
no Block1 option they are later messages of a combined Block1+Block2
oper..ransfer.

> * Section 3 would benefit from explaining that Request-Tag is only
>   meant to be used with Block1 Options in requests.

Added (note as above). Is a MUST NOT be used in response messages
suitable there?


Thanks for your input
Christian


-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom