From nobody Wed Feb 3 00:03:58 2021 Return-Path: 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 430BF3A1570; Wed, 3 Feb 2021 00:03:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.118 X-Spam-Level: X-Spam-Status: No, score=-2.118 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=orange.com 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 ymCU-aGRtFPk; Wed, 3 Feb 2021 00:03:55 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 698003A155E; Wed, 3 Feb 2021 00:03:54 -0800 (PST) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr26.francetelecom.fr (ESMTP service) with ESMTP id 4DVvMX5d5hz1004; Wed, 3 Feb 2021 09:03:52 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1612339432; bh=pXy1N/OpKm7RCWYYA3/F3bl/IuSvocC/QgSoApITk0I=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=L2HwINIzCpxpYLb+mYPtOx5ngFxi2iL0YwfkyGABmTAv2tZLrL9crwjmRw1CukAWf H7LEKsYcydbPIUh4CgHCTlzVKmkOHNkJdhBH9ZpoheOLrBnvmMzzLTGhI5VVXO4XYM mb8XzEn27cj9dovduU0RvX9tHWOaEo4bDZQpXjJLvJoNtkd2T50D3rHjlfXyT5TxJC +l5/jSKpMj8CZ48Sh/PfF8x7DpqqFueB1Xna7W9jBN19fdM2A64VC84QnVqLqu5f80 hFCAUV2tfI9xBe5L5mfgoCUc3IOsDBjPRrHqfxOsXlkQtHbZmBhDYHl9t6oguH8vM5 A4QpHg8Obb7RQ== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.70]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 4DVvMX4m0YzyQF; Wed, 3 Feb 2021 09:03:52 +0100 (CET) From: To: "supjps-ietf@jpshallow.com" , "christian@amsuess.com" , "draft-ietf-core-new-block@ietf.org" CC: "dots@ietf.org" , "core@ietf.org" Thread-Topic: [core] WG Last Call on draft-ietf-core-new-block Thread-Index: AQE9efsT42/5NWOZF7Ah7uUxJLBzEAIREyNWqyb5urCAQY0GoA== Date: Wed, 3 Feb 2021 08:03:51 +0000 Message-ID: <32574_1612339432_601A58E8_32574_29_1_787AE7BB302AE849A7480A190F8B9330315C6345@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <263d6f84-4a57-2085-288f-068b1d78f7ae@ri.se> <04a201d6d9d8$c7919ae0$56b4d0a0$@jpshallow.com> In-Reply-To: <04a201d6d9d8$c7919ae0$56b4d0a0$@jpshallow.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [core] WG Last Call on draft-ietf-core-new-block X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2021 08:03:57 -0000 Hi Christian, We would appreciate if you can check the latest version of the spec and let= us know whether your issues were adequately addressed. A diff can be found= at: https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-core-new-block-03&url2= =3Ddraft-ietf-core-new-block-06=20 To ease tracking issues, please see below an update to the initial replies.= =20 Replies to the second part of your review can be seen at:=20 https://mailarchive.ietf.org/arch/msg/core/zTjLyXkjtjEUka44mvD8E4HSke8/=20 Cheers, Jon & Med > -----Message d'origine----- > De=A0: core [mailto:core-bounces@ietf.org] De la part de supjps- > ietf@jpshallow.com > Envoy=E9=A0: jeudi 24 d=E9cembre 2020 10:40 > =C0=A0: christian@amsuess.com; draft-ietf-core-new-block@ietf.org > Cc=A0: dots@ietf.org; core@ietf.org > Objet=A0: Re: [core] WG Last Call on draft-ietf-core-new-block >=20 > Hi Christian, >=20 > Thanks for this and the time spent thinking about it. Some items > have already become separate threads. >=20 > Otherwise responses inline - part 1. Some of the changes can be seen > at https://tinyurl.com/new-block-latest >=20 > Regards >=20 > Jon >=20 > > -----Original Message----- > > From: Christian Ams=FCss [mailto: christian@amsuess.com] > > Sent: 23 December 2020 05:01 > > To: draft-ietf-core-new-block@ietf.org > > Cc: dots@ietf.org; core@ietf.org WG (core@ietf.org) > > Subject: Re: [core] WG Last Call on draft-ietf-core-new-block > > > > Hello new-block authors, hello CoRE, > > > > I've finally managed to have another look at the document (and it's > > still > the > > 22nd *somewhere*...). > > > > My over-all summary is that while this document has matured quite a > > bit (and turned out better than I had expected for the special- > purpose > > blocks > it > > is), I think that the topic of response suppression and congestion > > control sections still have to be sharpened, and the examples could > > pick a more realistic balance between going all-NON and all-CON (or > > explain why that's something that wouldn't be done even though the > > text reads like that's what's expected to be used but maybe it's > just me). > > > > > > Except for the first item (which is coming back to the notes for > the > WGLC), > > all should be more or less sequential in the document (with > > forward/back references as needed). > > > > * On the downref to No-Response: I don't see the downref as too big > an > > issue. It's a bit odd that that document didn't go through the > CoRE > > WG, but my impression is that it's widely used (on a "when the > library > > I maintain broke it people filed issues" level), and both OSCORE > and > > groupcomm-bis (which is to replace RFC7390) reference it. It's an > > informative reference because they don't mechanically depend on > it, > > but it shows how well No-Response has been taken up. > > > > (Frankly, I'd support a retroactive adoption. I don't suppose we > can > > do that with "adults"?). > > > > From how I understand Q-Block to be intended to work, No-Response > does > > not cover all of the behavior (as it's timeout based); still, > that > > document lays good groundwork for what's done here in a rather > precise > > way (see comment on "For Confirmable transmission, the server > MUST > > continue" later on) where this document needs the examples to be > fully > > understood. > > > > Based on the later text on MAX_TRANSMIT_SPAN, why not at least > > acknowledge the equivalence? Maybe like this: > > > > > The behavior of endpoints following this draft can equivalently > b > > > described in terms of the No-Response option {{?RFC7967}}: > > > > > > For a message with a Q-Block1 option with M=3D1 that is followed > by > > > another message on the same Request-Tag within > MAX_TRANSMIT_SPAN [ > > > or MAX_BLOCK_JITTER, see later ], the default value for No- > Response > > > is 8 (suppressing the 4.xx code that would be returned due to > the > > > incomplete request); an explicitly set No-Response option would > > > override that." > > > > although I'd still advocate just using No-Response for the whole > > definition even if No-Response is not typically expressed. > > > > (I'm not really sure what the correct response would be for an > > individual non-terminal request if it were to be answered due to > an > > explicit No-Response:0 -- might be 2.31 Continue that's just not > > used in this specification because it's always suppressed? I'll > come > > back to that -- but then it'd rather be No-Response: 10). > > > > * intro: WebSockets (capitalization) >=20 > [Jon] OK > > > > * The list of pros and cons (with the cons being almost trivial) > does > > not explain to the reader why these are not a replacement; I > suggest > > to add: > > > > * The Q-Block options do not support stateless operation / random > > access. >=20 > [Jon] Actually Q-Block2 does now support this following the > redefinition of the M bit usage in a previous iteration (with M=3D0 you > can ask for any individual block). >=20 > [Jon] For stateless, Request-Tag is included so this should be fine. > https://datatracker.ietf.org/doc/html/draft-ietf-core-stateless- > 06#section-4 > .2 > > > > * Proxying of Q-Block is limited to caching full representations. > > > > (The latter might be mitigated by additional text around caching, > but > > I doubt it's worth the effort given it's not part of the use > case). > [Jon] I am not entirely convinced that Block1/2 have got the caching > by block properly sorted out - e.g. what happens when different > clients make requests with different SZX and Block2 is part of the > cache key. The limiting to caching full representations is there so > that a new can of worms is not opened up. >=20 > [Jon] I will see if I can think of any further cons. [Med] The following two items were added:=20 o To reduce the transmission times for CON transmission of large=09 bodies, NSTART needs to be increased from 1, but this affects=09 congestion control where other parameters need to be tuned=09 (Section 4.7 of [RFC7252]). Such tuning is out of scope of this=09 document.=09 =09=09=20=09=09 o There is no multicast support. > > > > * "compromises of": I don't understand that sentence. >=20 > [Jon] OK s/compromises of/comprises of/ > > > > * "the asymmetrical packet loss is not a benefit here": It never > is; > > what is meant here? >=20 > [Jon] OK. How about (which is obvious, but a reminder to the > implementer) OLD However, the asymmetrical packet loss is not a > benefit here. > NEW > However, the use of Confirmable messages will not work if there > asymmetrical packet loss. > > > > * "Updated CoAP Response Code": "This document updates" sounds like > a > > formal update to RFC7959, which it neither is nor needs to be. > > Phrasing it along the lines of "adds a media type that can be > used > > with 4.08" would ease that. >=20 > [Jon] > OLD > 1.2. Updated CoAP Response Code (4.08) >=20 > This document updates the 4.08 (Request Entity Incomplete) by > defining an additional message format for reporting on payloads > using > the Q-Block1 Option that are not received by the server. > NEW > 1.2. CoAP Response Code (4.08) Usage >=20 > This document adds a media type for the 4.08 (Request Entity > Incomplete) response defining an additional message format for > reporting on payloads using the Q-Block1 Option that are not received > by the server. > > > > * "Only C and U columns are marked": "The Q-Block1 option is > critical, and > > unsafe for proxies to forward" would be easier to read -- which > > checkboxes are marked is visible alrady from the table. (Or just > leave > > it for the later paragraphs that say that in more detail). >=20 > [Jon] OK. Gone with Critical etc. > > > > * "Q-Block1 Option is useful with": ... and FETCH. (Also in "Using > the > > Q-Block1 option" first paragraph). >=20 > [Jon] OK > > > > * "Is opaque in nature, but it is RECOMMENDED" on being a counter > and > > starting off random: Like other similar suggestions (ETag), this > is > > implementation guidance level and not required for > interoperability. > > Maybe phrase this the same way as the recommendations on tokens? >=20 > [Jon] > OLD > The Request-Tag is opaque > in nature, but it is RECOMMENDED that the client treats it as an > unsigned integer of 8 bytes in length. An implementation may want > to > consider limiting this to 4 bytes to reduce packet overhead size. > The server still treats it as an opaque entity. The Request-Tag > value MUST be different for distinct bodies or sets of blocks of > data > and SHOULD be incremented whenever a new body of data is being > transmitted between peers. The initial Request-Tag value SHOULD > be > randomly generated by the client. > NEW > The Request-Tag is opaque, the server still treats it as opaque but > the client SHOULD ensure that it is unique for every different body > of transmitted data. >=20 > Implementation Note: It is suggested that the client treats the > Request-Tag as an > unsigned integer of 8 bytes in length. An implementation may want > to > consider limiting this to 4 bytes to reduce packet overhead size. > The initial Request-Tag value should be randomly generated and then > subsequently incremented by the client whenever a new body of data > is being > transmitted between peers. >=20 > OLD > The ETag is opaque in nature, but it is RECOMMENDED that the > server > treats it as an unsigned integer of 8 bytes in length. An > implementation may want to consider limiting this to 4 bytes to > reduce packet overhead size. The client still treats it as an > opaque > entity. The ETag value MUST be different for distinct bodies or > sets > of blocks of data and SHOULD be incremented whenever a new body of > data is being transmitted between peers. The initial ETag value > SHOULD be randomly generated by the server. > NEW > The ETag is opaque, the client still treats it as opaque but the > server SHOULD ensure that it is unique for every different body of > transmitted data. >=20 > Implementation Note: It is suggested that the server treats the ETag > as an > unsigned integer of 8 bytes in length. An implementation may want > to > consider limiting this to 4 bytes to reduce packet overhead size. > The initial ETag value should be randomly generated and then > subsequently incremented by the server whenever a new body of data > is being > transmitted between peers. >=20 > > > > * "For Confirmable transmission, the server MUST continue": This > reads > > like new-block could change anything about that, when all it does > is > > do things on the response level. [1] has a good note on that > > separation topic. > > > > [1]: https://tools.ietf.org/html/rfc7967#section-2 >=20 > [Jon] The intent here was that CON continues to work for each > request/response in that the request needs to be acknowledged, but a > response (piggybacked or separate) is not required. > OLD > For Confirmable transmission, the server MUST continue to acknowledge > each packet. > NEW > For Confirmable transmission, the server continues to acknowledge > each packet, but a response is not required (whether separate or > piggybacked) until retransmission or successful receipt of the body. >=20 > [Jon] To be continued in part 2. >=20 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles 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 el= ectroniques 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 inf= ormation 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 dele= te 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.