From nobody Wed Feb 3 00:04:02 2021 Return-Path: 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 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: [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." 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. From nobody Wed Feb 3 00:09:49 2021 Return-Path: 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 4966C3A15A8; Wed, 3 Feb 2021 00:09:44 -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 chFjqeneV9ZI; Wed, 3 Feb 2021 00:09:42 -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 273033A15A7; Wed, 3 Feb 2021 00:09:42 -0800 (PST) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr24.francetelecom.fr (ESMTP service) with ESMTP id 4DVvVD4dpFz1y9n; Wed, 3 Feb 2021 09:09:40 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1612339780; bh=11yR63W3Lvdvo8F32r+kLY9kxL9WAH+Rk8D/VrlmtT4=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=vAnH2aLrcrDx6P2pytLZIpNMNrVPfUpbf63zUS2DTzshTnslXj1pZ2ATSu9XHOee3 l66y5C4xqf/7JKhOga1IstZgJxWu08Z4lzs0oUnVo4r0sa7A5CD/9/Ajmpe/oFlRvy 5PsjC0lpCXGn3kAeCkAzVQyw3VFDQyPpexO0b4tZ4nXnZ7ri1dvkMxDPIapqGx/YmU QybaPZhcZxLW6zCumUDh1HstCoI7CyJ2UfPwBxhMqqlNVMJjIeARcjuCANRTxasvbJ 5UTmdKz3dlbKip9vJfmAbGw1k8uu2uobSQkXwR8X4yyuBQYqOge8yDV3gHmikh3KrW mkqpci0V8B4Qg== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.45]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 4DVvVD3nDhzDq7Q; Wed, 3 Feb 2021 09:09:40 +0100 (CET) From: To: =?iso-8859-1?Q?Christian_Ams=FCss?= CC: "draft-ietf-core-new-block@ietf.org" , "core@ietf.org WG (core@ietf.org)" , "dots@ietf.org" Thread-Topic: [core] WG Last Call on draft-ietf-core-new-block (No-Response) Thread-Index: AQHW2RFADVSDS+77YE2WSWeKTWYPaaoEtA4QgEGgIIA= Date: Wed, 3 Feb 2021 08:09:40 +0000 Message-ID: <23740_1612339780_601A5A44_23740_98_8_787AE7BB302AE849A7480A190F8B9330315C6374@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <18741_1608713479_5FE30507_18741_81_1_787AE7BB302AE849A7480A190F8B9330315A177C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <28095_1608732578_5FE34FA2_28095_105_1_787AE7BB302AE849A7480A190F8B9330315A1C90@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <28095_1608732578_5FE34FA2_28095_105_1_787AE7BB302AE849A7480A190F8B9330315A1C90@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> 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: [Dots] [core] WG Last Call on draft-ietf-core-new-block (No-Response) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2021 08:09:45 -0000 Christian,=20 As a follow-up on this issue, we finally went with an approach that does no= t require No-Response. We do have the following to avoid extra delays, e.g.= ,=20 For the server receiving NON Q-Block1 requests, it SHOULD send back a 2.31 (Continue) Response Code on receipt of all of the MAX_PAYLOADS payloads to prevent the client unnecessarily delaying. Otherwise the server SHOULD delay for NON_RECEIVE_TIMEOUT (exponentially scaled based on the repeat request count for a payload), before sending the 4.08 (Request Entity Incomplete) Response Code for the missing payload(s). If the repeat request count for a missing payload exceeds NON_MAX_RETRANSMIT, the server SHOULD discard the partial body and stop requesting the missing payloads. Or=20 For the client receiving NON Q-Block2 responses, it SHOULD send a 'Continue' Q-Block2 request (Section 3.4) for the next set of payloads on receipt of all of the MAX_PAYLOADS payloads to prevent the server unnecessarily delaying. Otherwise the client SHOULD delay for NON_RECEIVE_TIMEOUT (exponentially scaled based on the repeat request count for a payload), before sending the request for the missing payload(s). If the repeat request count for a missing payload exceeds NON_MAX_RETRANSMIT, the client SHOULD discard the partial body and stop requesting the missing payloads. Cheers, Jon & Med > -----Message d'origine----- > De=A0: mohamed.boucadair@orange.com > [mailto:mohamed.boucadair@orange.com] > Envoy=E9=A0: mercredi 23 d=E9cembre 2020 15:10 > =C0=A0: Christian Ams=FCss > Cc=A0: draft-ietf-core-new-block@ietf.org; core@ietf.org WG > (core@ietf.org) ; dots@ietf.org > Objet=A0: RE: [core] WG Last Call on draft-ietf-core-new-block (No- > Response) >=20 > Re-, >=20 > Please see inline. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Christian Ams=FCss [mailto:christian@amsuess.com] Envoy=E9=A0: > mercredi > > 23 d=E9cembre 2020 10:52 =C0=A0: BOUCADAIR Mohamed TGI/OLN > > Cc=A0: > > draft-ietf-core-new-block@ietf.org; core@ietf.org WG > > (core@ietf.org) ; dots@ietf.org Objet=A0: Re: [core] > WG > > Last Call on draft-ietf-core-new-block (No- > > Response) > > > > Hello Med, > > > > > The text we have in the draft does not preclude No-Response (or > > any > > > solution that will be endorsed by the WG in the future): > > > > > > If both endpoints support No-Response, they can use it as a > > "signal in > > > the MAX_PAYLOADS" to trigger a 2.31 mentioned in the last > > sentence. > > > > > > As we don't recommend No-Response (for reasons echoed in your > > > message), it is not worth to include much more details on how > > > No-Response can be used. > > > > The only reason for No-Response I echo in my mail is the downref, > and > > merely showing how these can interoperate does not create a > normative > > reference. It's quite a stretch to assume people would read > "requires > > an additional signal" as "could use No-Response". > > > > Working group documents time and again have outward references like > > "One way of doing this is being explored in [draft-...]", which is > > clearly non-normative, but at the same time allow the reader to get > at > > least > > *some* indication of how things are meant to be used. >=20 > [Med] Simply adding a pointer would work for me. We can go for the > following change: >=20 > s/an additional signal in the MAX_PAYLOADS packet/an additional > signal in the MAX_PAYLOADS packet (e.g., [RFC7967]) >=20 > > > > What makes things worse here is that as long as this specification > > does not mention No-Response at all, it is not ensured that it > > interoperates well at all with No-Response; thus even if a reader > can > > make the jump, they'd have to figure out on their own that it's > > probably best if No-Response overrides the response behavior of Q- > > Block. >=20 > [Med] Here is where I disagree. As we don't recommend any solution > (including No-Response), it is not up to this document to discuss how > to graft the various pieces. >=20 > > > > > The use of NON is thus superior but requires > > > an additional signal in the MAX_PAYLOADS packet to seek for > > a 2.31 > > > (Continue) from the peer if it is ready to receive the next > > set of > > > blocks. > > > > I missed that in the part where I'm asking for whether 2.31 would > be > > produced. That paragraph really opens more questions than it > > answers: If Q-Block is intended to be usable with something to > signal > > that now would be a good time for a response, then this almost > > contradicts the "2.31 > > (Continue) Response is not used in the current version" statement. >=20 > [Med] That statement is factual. It is meant to remind that 2.31 is > legal and that it is there as a provision for any future optimization > that would require it. >=20 > > > > Either this is a possibility already planned here, then the 2.31 > cases > > should be properly described, even if it's just with a "but > requires > > additional signaling, which for example can be achieved by > combining > > this with No-Response:0". Or it's not planned out here, then the > 2.31 > > mentioned in the quoted note is more of a note on future updates of > > Q-Block that would be necessary to leverage that combination (but I > > don't see any such document happening). > > > > Best regards > > Christian > > ___________________________________________________________________________= ______________________________________________ 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. From nobody Wed Feb 3 00:15:19 2021 Return-Path: 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 0A1E63A15B2; Wed, 3 Feb 2021 00:15:14 -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 QBPh3zvDsUOv; Wed, 3 Feb 2021 00:15:12 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1C623A15B1; Wed, 3 Feb 2021 00:15:11 -0800 (PST) Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id 4DVvcZ1g8Rz8spq; Wed, 3 Feb 2021 09:15:10 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1612340110; bh=kNH9nckd/4cQZlExKBuTuBQrThYHC3+e+qbDySLQUFI=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=UdWZU2VGTiCzpD/DCJ7JhUbOetuxWfuxRAZpeolSVytwV3GzPRu3AogBW+zdGVrcY mszmgHfJFTKdCJR4nEFqvz975G6SYv+Wb7sDpesaTgu2mnmdU7OVE6BGA2Gi8mHdR9 2Ausra0q+fqAH44xkVVdFRLlDQSOfr4vhiaFAUSq0LAyMSOMeTWVvqshdHd9dpzaVP 4S+8BOipRU5f90rg2Bxl3+fVRF6OKENdONQ3mVbuGeezNkAzyUgd7pusK0m12Xsmd7 6mF35/IVq7vf4um7mW2xW/VstBnnVDTJrO7731fkyLzvT9ocZOyKY/CCmd/7GF1NFB kPtlR8HorF1sQ== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.48]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 4DVvcZ0VFDzCqm4; Wed, 3 Feb 2021 09:15:10 +0100 (CET) From: To: =?iso-8859-1?Q?Christian_Ams=FCss?= CC: "core@ietf.org WG (core@ietf.org)" , "dots@ietf.org" , "draft-ietf-core-new-block@ietf.org" Thread-Topic: [core] WG Last Call on draft-ietf-core-new-block (Congestion Control) Thread-Index: AdbZC/aiJQkTFqGDTZuAOZL1HdyQ6wg+A0MA Date: Wed, 3 Feb 2021 08:15:09 +0000 Message-ID: <15830_1612340110_601A5B8E_15830_95_1_787AE7BB302AE849A7480A190F8B9330315C6397@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <31613_1608714849_5FE30A61_31613_100_2_787AE7BB302AE849A7480A190F8B9330315A17B3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <31613_1608714849_5FE30A61_31613_100_2_787AE7BB302AE849A7480A190F8B9330315A17B3@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> 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: [Dots] [core] WG Last Call on draft-ietf-core-new-block (Congestion Control) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2021 08:15:14 -0000 Re-, FWIW, we significantly updated the congestion control as you can see in: ht= tps://tools.ietf.org/html/draft-ietf-core-new-block-06#section-6=20 We finally added this text to point to how some parameters can be tweaked b= y an application:=20 Note: For the particular DOTS application, PROBING_RATE and other transmission parameters are negotiated between peers. Even when not negotiated, the DOTS application uses customized defaults as discussed in Section 4.5.2 of [RFC8782]. Note that MAX_PAYLOADS, NON_MAX_RETRANSMIT, and NON_TIMEOUT can be negotiated between DOTS peers as per [I-D.bosh-dots-quick-blocks]. We believe that we addressed your initial concern, but having an ACK would = be appreciated. Thanks.=20 Cheers, Jon & Med > -----Message d'origine----- > De=A0: mohamed.boucadair@orange.com > [mailto:mohamed.boucadair@orange.com] > Envoy=E9=A0: mercredi 23 d=E9cembre 2020 10:14 > =C0=A0: Christian Ams=FCss ; draft-ietf-core-new- > block@ietf.org > Cc=A0: core@ietf.org WG (core@ietf.org) ; dots@ietf.org > Objet=A0: RE: [core] WG Last Call on draft-ietf-core-new-block > (Congestion Control) >=20 > Re-, >=20 > You are completely right that the default probing-rate is to be > increased for the DOTS case. FYI, this is why we went with the > following in RFC8782: >=20 > | Given that the size of the heartbeat request cannot exceed > | ('heartbeat-interval' * 'probing-rate') bytes, 'probing- > rate' > | should be set appropriately to avoid slowing down heartbeat > | exchanges. For example, 'probing-rate' may be set to 2 * > | ("size of encrypted DOTS heartbeat request"/'heartbeat- > | interval') or (("size of encrypted DOTS heartbeat request" + > | "average size of an encrypted mitigation > request")/'heartbeat- > | interval'). Absent any explicit configuration or inability > to > | dynamically adjust 'probing-rate' values (Section 4.8.1 of > | [RFC7252]), DOTS agents use 5 bytes/second as a default > | 'probing-rate' value. >=20 > We also allow DOTS peers to negotiate the transmission parameters > (and probing rate) with the following as default: >=20 > "The RECOMMENDED values of > transmission parameter values are 'ack-timeout' (2 seconds), 'max- > retransmit' (3), and 'ack-random-factor' (1.5). In addition to > those > parameters, the RECOMMENDED specific DOTS transmission parameter > values are 'heartbeat-interval' (30 seconds) and 'missing-hb- > allowed' > (15)." >=20 > We avoided to include a pointer to these details as these are > application-specific and that, even if the draft is motivated by the > DOTS use case, other applications can make use of the new block > functionality. >=20 > For NSTART, we already have the following: >=20 > " NSTART will also need to be increased from the default > (1) to get faster transmission rates." >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: Christian Ams=FCss [mailto:christian@amsuess.com] Envoy=E9=A0: > mercredi > > 23 d=E9cembre 2020 06:01 =C0=A0: draft-ietf-core-new-block@ietf.org > > Cc=A0: core@ietf.org WG (core@ietf.org) ; > dots@ietf.org > > Objet=A0: Re: [core] WG Last Call on draft-ietf-core-new-block > > > > * Also on parameters: This document is describing flow control > stuff > > around a situation CoAP was not originally designed for. Wouldn't > it > > make sense to include a set of parameters (PROBING_RATE, > > MAX_LATENCY, > > ACK_TIMEOUT) that's suitable for the DOTS use case? I doubt that > > PROBING_RATE will be left to 1 byte/second for any DOTS > application > > using this (for sending 10KiB in the initial 10-package > MAX_PAYLOADS > > burst would mark that connection as unusable for about 3 hours if > > they > > all get lost), so better give justifiable numbers here than rely > on > > implemnetors to come up with unreviewed numbers or disregard > > PROBING_RATE altogether. > > > > I don't know if it needs additional justification, but an > increased > > N_START may be justifiable there. > > ___________________________________________________________________________= ______________________________________________ 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. From nobody Mon Feb 8 01:45:59 2021 Return-Path: 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 145B83A1536 for ; Mon, 8 Feb 2021 01:45:58 -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 7EBfzhCDIuIP for ; Mon, 8 Feb 2021 01:45:56 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFB0B3A1538 for ; Mon, 8 Feb 2021 01:45:55 -0800 (PST) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 4DZ1Nx5P8Gz103v for ; Mon, 8 Feb 2021 10:45:53 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1612777553; bh=gtpJq4T+qGv915YlrvLlkWsBcM3UH+VRiRRMP4/TCTA=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=Vf3ujs7Y+DhA78hMPNNvfNR2TcRkSBklIzbJ9+aE2oxw1L569MMvrUOpQIP+GLGqs wxlDzbPqAMg61gxZxaOO7I2mmsH3H9wfA7DcAaprE803DaAg5eEljzyD7+mqtQLDjp RjVgYsqW085MFTeNsutFv5uJiHSrWuaPddoMb6f5lkVQhSThBNamUGIjUs4FLR0LXi 8XNnZVUYOoiC1KrnAJvG5m/uIc3nwalRRNhBP+k+3h0n8q9n5Ovew+HXTBEzAidk9B tqZQb/Q8DBOkgRdLd0GywjPQZZ6Fh/nmSvWgvocV1j0I7RXhEMJ5pvqIqDYx43bxgi hV5LHzLPKK7kg== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.26]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 4DZ1Nx4cQvzDqB1 for ; Mon, 8 Feb 2021 10:45:53 +0100 (CET) From: To: "dots@ietf.org" Thread-Topic: New Version Notification for draft-bosh-dots-quick-blocks-00.txt Thread-Index: AQHW6BE+e4a7glWno0iUb+SxdUBAEKoiUnHwgAMGbtCAKNUuIA== Date: Mon, 8 Feb 2021 09:45:53 +0000 Message-ID: <15745_1612777553_60210851_15745_33_1_787AE7BB302AE849A7480A190F8B9330315C91E4@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <161036637813.11527.15818091495971687767@ietfa.amsl.com> <30749_1610366791_5FFC3F47_30749_168_2_787AE7BB302AE849A7480A190F8B9330315B71FE@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <10787_1610532921_5FFEC839_10787_48_1_787AE7BB302AE849A7480A190F8B9330315B8A2F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <10787_1610532921_5FFEC839_10787_48_1_787AE7BB302AE849A7480A190F8B9330315B8A2F@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dots] New Version Notification for draft-bosh-dots-quick-blocks-00.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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Feb 2021 09:45:58 -0000 SGksIA0KDQpGV0lXLCB0aGUgZm9sbG93aW5nIHZhbHVlcyBhcmUgdXNlZCBmb3IgaW50ZXJvcCB0 ZXN0aW5nOg0KDQpodHRwczovL2dpdGh1Yi5jb20vYm91Y2FkYWlyL2RyYWZ0LWJvc2gtZG90cy1x dWljay1ibG9ja3MvYmxvYi9tYWluL21hcHBpbmctdGFibGUudHh0IA0KDQpDaGVlcnMsDQpNZWQN Cg0KPiAtLS0tLU1lc3NhZ2UgZCdvcmlnaW5lLS0tLS0NCj4gRGXCoDogRG90cyBbbWFpbHRvOmRv dHMtYm91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZQ0KPiBtb2hhbWVkLmJvdWNhZGFpckBv cmFuZ2UuY29tDQo+IEVudm95w6nCoDogbWVyY3JlZGkgMTMgamFudmllciAyMDIxIDExOjE1DQo+ IMOAwqA6IGRvdHNAaWV0Zi5vcmcNCj4gT2JqZXTCoDogUmU6IFtEb3RzXSBOZXcgVmVyc2lvbiBO b3RpZmljYXRpb24gZm9yIGRyYWZ0LWJvc2gtZG90cy0NCj4gcXVpY2stYmxvY2tzLTAwLnR4dA0K PiANCj4gSGkgYWxsLA0KPiANCj4gQW4gdXBkYXRlZCB2ZXJzaW9uIHdpdGggYW4gZXhhbXBsZSBh bmQgYSBuZXcgYXR0cmlidXRlIGlzIGF2YWlsYWJsZToNCj4gDQo+IEh0bWxpemVkOiAgICAgICBo dHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYm9zaC1kb3RzLXF1aWNrLQ0KPiBibG9j a3MtMDENCj4gRGlmZjogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJs Mj1kcmFmdC1ib3NoLWRvdHMtDQo+IHF1aWNrLWJsb2Nrcy0wMQ0KPiANCj4gQ29tbWVudHMgYW5k IHN1Z2dlc3Rpb25zIGFyZSB3ZWxjb21lLg0KPiANCj4gQ2hlZXJzLA0KPiBNZWQNCj4gDQo+ID4g LS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+ID4gRGXCoDogRG90cyBbbWFpbHRvOmRvdHMt Ym91bmNlc0BpZXRmLm9yZ10gRGUgbGEgcGFydCBkZQ0KPiA+IG1vaGFtZWQuYm91Y2FkYWlyQG9y YW5nZS5jb20gRW52b3nDqcKgOiBsdW5kaSAxMSBqYW52aWVyIDIwMjEgMTM6MDcNCj4gw4DCoDoN Cj4gPiBkb3RzQGlldGYub3JnIE9iamV0wqA6IFtEb3RzXSBUUjogTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvcg0KPiA+IGRyYWZ0LWJvc2gtZG90cy0gcXVpY2stYmxvY2tzLTAwLnR4dA0KPiA+ DQo+ID4gSGkgYWxsLA0KPiA+DQo+ID4gKENjaSdpbmcgY29yZSBXRyB3aGVyZSB0aGUgbmV3IGJs b2NrcyBhcmUgZGVmaW5lZCkNCj4gPg0KPiA+IFRoaXMgc3BlYyBkZWZpbmVzIG5ldyBhdHRyaWJ1 dGVzIHRoYXQgY2FuIGJlIG5lZ290aWF0ZWQgYmV0d2Vlbg0KPiBET1RTDQo+ID4gYWdlbnRzIHRo YXQgc3VwcG9ydCBRLUJsb2NrMS8yLiBBcyBhIHJlbWluZGVyLCB0aGVzZSBvcHRpb25zIGFyZQ0K PiA+IGRlc2lnbmVkIHRvIGFsbG93IGZvciBmYXN0ZXIgdHJhbnNtaXNzaW9uIGluIERPVFMtbGlr ZQ0KPiBlbnZpcm9ubWVudHMuDQo+ID4NCj4gPiBDb21tZW50cyBhcmUgd2VsY29tZS4NCj4gPg0K PiA+IENoZWVycywNCj4gPiBKb24gJiBNZWQNCj4gPg0KPiA+IC0tLS0tTWVzc2FnZSBkJ29yaWdp bmUtLS0tLQ0KPiA+IERlwqA6IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZ10NCj4gRW52b3nDqQ0KPiA+IDogbHVuZGkgMTEgamFudmllciAy MDIxIDEzOjAwIMOAwqA6IEpvbiBTaGFsbG93IDxzdXBqcHMtDQo+ID4gaWV0ZkBqcHNoYWxsb3cu Y29tPjsgQk9VQ0FEQUlSIE1vaGFtZWQgVEdJL09MTg0KPiA+IDxtb2hhbWVkLmJvdWNhZGFpckBv cmFuZ2UuY29tPiBPYmpldMKgOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQo+ID4gZHJh ZnQtYm9zaC1kb3RzLXF1aWNrLWJsb2Nrcy0wMC50eHQNCj4gPg0KPiA+DQo+ID4gQSBuZXcgdmVy c2lvbiBvZiBJLUQsIGRyYWZ0LWJvc2gtZG90cy1xdWljay1ibG9ja3MtMDAudHh0DQo+ID4gaGFz IGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBNb2hhbWVkIEJvdWNhZGFpciBhbmQgcG9z dGVkIHRvDQo+IHRoZQ0KPiA+IElFVEYgcmVwb3NpdG9yeS4NCj4gPg0KPiA+IE5hbWU6CQlkcmFm dC1ib3NoLWRvdHMtcXVpY2stYmxvY2tzDQo+ID4gUmV2aXNpb246CTAwDQo+ID4gVGl0bGU6CQlE aXN0cmlidXRlZCBEZW5pYWwtb2YtU2VydmljZSBPcGVuIFRocmVhdCBTaWduYWxpbmcNCj4gPiAo RE9UUykgU2lnbmFsIENoYW5uZWwgQ29uZmlndXJhdGlvbiBBdHRyaWJ1dGVzIGZvciBGYXN0ZXIg QmxvY2sNCj4gPiBUcmFuc21pc3Npb24NCj4gPiBEb2N1bWVudCBkYXRlOgkyMDIxLTAxLTExDQo+ ID4gR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj4gPiBQYWdlczoJCTE0DQo+ID4gVVJM OiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtYm9zaC1k b3RzLQ0KPiA+IHF1aWNrLWJsb2Nrcy0wMC50eHQNCj4gPiBTdGF0dXM6ICAgICAgICAgaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYm9zaC1kb3RzLQ0KPiA+IHF1aWNrLWJs b2Nrcy8NCj4gPiBIdG1saXplZDogICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2MvaHRtbC9kcmFmdC1ib3NoLQ0KPiA+IGRvdHMtcXVpY2stYmxvY2tzDQo+ID4gSHRtbGl6ZWQ6 ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ib3NoLWRvdHMtcXVpY2st DQo+ID4gYmxvY2tzLTAwDQo+ID4NCj4gPg0KPiA+IEFic3RyYWN0Og0KPiA+ICAgIFRoaXMgZG9j dW1lbnQgc3BlY2lmaWVzIG5ldyBET1RTIHNpZ25hbCBjaGFubmVsIGNvbmZpZ3VyYXRpb24NCj4g PiAgICBwYXJhbWV0ZXJzIHRoYXQgYXJlIG5lZ290aWF0ZWQgYmV0d2VlbiBET1RTIHBlZXJzIHRv IGVuYWJsZSB0aGUNCj4gdXNlDQo+ID4gICAgb2YgUS1CbG9jazEgYW5kIFEtQmxvY2syIE9wdGlv bnMuICBUaGVzZSBvcHRpb25zIGVuYWJsZSBmYXN0ZXINCj4gPiAgICB0cmFuc21pc3Npb24gcmF0 ZXMgZm9yIGxhcmdlIGFtb3VudHMgb2YgZGF0YSB3aXRoIGxlc3MgcGFja2V0DQo+ID4gICAgaW50 ZXJjaGFuZ2VzIGFzIHdlbGwgYXMgc3VwcG9ydGluZyBmYXN0ZXIgcmVjb3Zlcnkgc2hvdWxkIGFu eSBvZg0KPiA+IHRoZQ0KPiA+ICAgIGJsb2NrcyBnZXQgbG9zdCBpbiB0cmFuc21pc3Npb24uDQo+ ID4NCj4gPg0KPiA+DQo+ID4NCj4gPiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291 cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZg0KPiA+IHN1Ym1pc3Npb24gdW50aWwgdGhl IGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdA0KPiA+IHRvb2xzLmll dGYub3JnLg0KPiA+DQo+ID4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCj4gPg0KPiA+DQo+ID4NCj4g Pg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+ID4NCj4gPiBDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9p bnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMNCj4gPiBjb25maWRlbnRpZWxs ZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYyBwYXMgZXRyZQ0KPiBkaWZmdXNl cywNCj4gPiBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2 ZXogcmVjdSBjZSBtZXNzYWdlDQo+ID4gcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIg YSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUNCj4gYWluc2kNCj4gPiBxdWUgbGVzIHBpZWNl cyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudA0KPiBzdXNjZXB0aWJs ZXMNCj4gPiBkJ2FsdGVyYXRpb24sIE9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRl IHNpIGNlIG1lc3NhZ2UgYQ0KPiBldGUNCj4gPiBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUu IE1lcmNpLg0KPiA+DQo+ID4gVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNv bnRhaW4gY29uZmlkZW50aWFsIG9yDQo+ID4gcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1h eSBiZSBwcm90ZWN0ZWQgYnkgbGF3OyB0aGV5IHNob3VsZA0KPiBub3QNCj4gPiBiZSBkaXN0cmli dXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KPiA+IElmIHlvdSBo YXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRl cg0KPiBhbmQNCj4gPiBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQo+ ID4gQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVz c2FnZXMgdGhhdA0KPiBoYXZlDQo+ID4gYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZp ZWQuDQo+ID4gVGhhbmsgeW91Lg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gPiBEb3RzIG1haWxpbmcgbGlzdA0KPiA+IERvdHNAaWV0 Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RvdHMNCj4g DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IA0KPiBDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBw ZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMNCj4gY29uZmlkZW50aWVsbGVzIG91IHBy aXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMgcGFzIGV0cmUgZGlmZnVzZXMsDQo+IGV4cGxv aXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1l c3NhZ2UNCj4gcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIgYSBsJ2V4cGVkaXRldXIg ZXQgbGUgZGV0cnVpcmUgYWluc2kNCj4gcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3Nh Z2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzDQo+IGQnYWx0ZXJhdGlvbiwgT3Jh bmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZQ0KPiBh bHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KPiANCj4gVGhpcyBtZXNzYWdlIGFu ZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yDQo+IHByaXZpbGVn ZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsgdGhleSBzaG91bGQg bm90DQo+IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRp b24uDQo+IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBu b3RpZnkgdGhlIHNlbmRlcg0KPiBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFj aG1lbnRzLg0KPiBBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxl IGZvciBtZXNzYWdlcyB0aGF0IGhhdmUNCj4gYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxz aWZpZWQuDQo+IFRoYW5rIHlvdS4NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+IERvdHMgbWFpbGluZyBsaXN0DQo+IERvdHNAaWV0Zi5vcmcN Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9kb3RzDQoKX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoK Q2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5m b3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBk b25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0 aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxl IHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGll Y2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxl cyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNl IG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMg bWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBw cml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkg c2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jp c2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ug bm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2ht ZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3Ig bWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpU aGFuayB5b3UuCgo= From nobody Tue Feb 16 15:49:07 2021 Return-Path: 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 2414B3A12F0; Tue, 16 Feb 2021 15:49:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 VSQAYUerv_Ng; Tue, 16 Feb 2021 15:48:58 -0800 (PST) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC5243A12E9; Tue, 16 Feb 2021 15:48:55 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 9AEB540887; Wed, 17 Feb 2021 00:48:53 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 6472FFD; Wed, 17 Feb 2021 00:48:52 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::aa6]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 2FD9D44; Wed, 17 Feb 2021 00:48:52 +0100 (CET) Received: (nullmailer pid 612178 invoked by uid 1000); Tue, 16 Feb 2021 23:48:51 -0000 Date: Wed, 17 Feb 2021 00:48:51 +0100 From: Christian =?iso-8859-1?B?TS4gQW1z/HNz?= To: supjps-ietf@jpshallow.com, mohamed.boucadair@orange.com Cc: draft-ietf-core-new-block@ietf.org, dots@ietf.org, core@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="gBSk+H9RigFJnM2C" Content-Disposition: inline In-Reply-To: <32574_1612339432_601A58E8_32574_29_1_787AE7BB302AE849A7480A190F8B9330315C6345@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <04a201d6d9d8$c7919ae0$56b4d0a0$@jpshallow.com> Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2021 23:49:01 -0000 --gBSk+H9RigFJnM2C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, where not explicitly responded to, the updates address my points, thank you for updating the document. > > * 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). Random access can also be in the Block1 phase; a standalone `PUT /resource Block1:5/0/6` can be used independenlty of other operations to overwrite a particular part of a resource. > [Jon] For stateless, Request-Tag is included so this should be fine. > https://datatracker.ietf.org/doc/html/draft-ietf-core-stateless-06#sectio= n-4 By stateless, I was referring to the server not keeping state per body. That is the opposite of using a Request-Tag. > > * Proxying of Q-Block is limited to caching full representations. > >=20 > > (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 wo= rms > is not opened up. The Block options are not part of the cache key -- they are not-safe-to-forward and thus come with rules as to the cache behavior, rather than havign a cache-key property. The behavior is sorted out: If an earlier client requested, say, block2:0//6 (first 1KiB), then while that is fresh, it may be used to serve any request for smaller chunks (say, block2:1//5 for bytes 512-1024). The same is true in the other direction: A proxy may use its cached 3x256 bytes (even exceeding the Max-Age), ask the server for the 4th 256 byte block (which by its ETag confirms the others are still good), and then serve them combined as a 1KiB response. Thus, I think these two points (Incomplete support for random access, and block-by-block proxying) still stand to be added to the considerations. To give you background on why I'm so picky about this list: People *will* still get the initial impression that this is the later-and-greater version, and for the outlined purposes it is, but if we don't set the expectations right here, there will be disappointment. BR c --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --gBSk+H9RigFJnM2C Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAmAsWeAACgkQOY0REtOk veHSYBAAuK173YgteA42G9jYZ7Oa0MySwEli/ctRAhWOVAoQ+GVLeA18PS6SA53r od5OEwoZtmGa7+QgV3rUZgu9jAi3gLoWM8IwQ804bUfsPgK78qFuIdp+ebNQN3cY Cdh5sSnor1DcScFve42rJmtRxr4Ey3hOvU058BDINBiq9+hix0zki/jPDuCQo7Zm UNH8L6e84QCA1JtuzGV+MbBkaR+wBtavTda+2c2Yy66lcZdtC2+emwtx/8L0/bzg coCzkr8pKTfmXFfVO2PA8vfg7CzdIh8AVDyQ7sKijCLihmm7WK3hNDVW2gXn8hQC bVwaEKNfPPqMHPdR/3FdyaSjhmR6W88ttwbPobvVTQD6oG0mhZYcm6MvrZ/m4lfZ aZBn+KEbxtM01ZkNx67lltjHf4D4QNIpbeS1U/nalaGJuzLdRI8X95OKiVmP2cwT 1LJajvj9S9IrW682dsIEbXaB9U4Sl/Bp26JhIu8vLq7zdghlFQFbIll0PG0aueN3 gxFSdEqtL3qf7v5ruNCvMObhVz7y7kG1i/QDa0gXxAuTq3LiTIduxVfe21Sq6Q7i OoasTEkJiLB8Q+hTHjR6qyaDJfvEYBmypAdc0uzhZOKzhkFfrA0Us8embGhEWEeK OOPCBHADcGbp5ZyseDy6Mznn+mNlebvgiohAO3XDUHWX+EdiAfA= =IAL3 -----END PGP SIGNATURE----- --gBSk+H9RigFJnM2C-- From nobody Tue Feb 16 15:53:53 2021 Return-Path: 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 D206D3A12FA; Tue, 16 Feb 2021 15:53:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 aVH1Dz7sHn2n; Tue, 16 Feb 2021 15:53:44 -0800 (PST) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76EDF3A12F4; Tue, 16 Feb 2021 15:53:43 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (095129206250.cust.akis.net [95.129.206.250]) by prometheus.amsuess.com (Postfix) with ESMTPS id 0CCC740887; Wed, 17 Feb 2021 00:53:41 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (poseidon-mailbox.amsuess.com [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bf]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 1AACAFD; Wed, 17 Feb 2021 00:53:40 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::aa6]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id D720944; Wed, 17 Feb 2021 00:53:39 +0100 (CET) Received: (nullmailer pid 612561 invoked by uid 1000); Tue, 16 Feb 2021 23:53:39 -0000 Date: Wed, 17 Feb 2021 00:53:39 +0100 From: Christian =?iso-8859-1?B?TS4gQW1z/HNz?= To: mohamed.boucadair@orange.com Cc: "draft-ietf-core-new-block@ietf.org" , "core@ietf.org WG (core@ietf.org)" , "dots@ietf.org" Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="HoBOzF5stQ3CqCEx" Content-Disposition: inline In-Reply-To: <23740_1612339780_601A5A44_23740_98_8_787AE7BB302AE849A7480A190F8B9330315C6374@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <28095_1608732578_5FE34FA2_28095_105_1_787AE7BB302AE849A7480A190F8B9330315A1C90@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Archived-At: Subject: Re: [Dots] [core] WG Last Call on draft-ietf-core-new-block (No-Response) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Feb 2021 23:53:47 -0000 --HoBOzF5stQ3CqCEx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Med, On Wed, Feb 03, 2021 at 08:09:40AM +0000, mohamed.boucadair@orange.com wrot= e: > As a follow-up on this issue, we finally went with an approach that > does not require No-Response. We do have the following to avoid extra > delays, e.g.,=20 The need to indicate when a client wants confirmation has been avoided by having timeouts on both sides, and relying more on MAX_PAYLOADS being aligned. For my taste, that makes unnecessary sacrifices in robustness over the simple two-byte NoResponse:0 that'd go with every MAX_PAYLOADS'th Q-Block2 from the client (and would completey avoid the risk of stalling in a lossless situation). (For the other direction, corective heuristics can easily be applied). But given they are explicitly configured in the DOTS case where Q-Block is used, so -- well. Food for a block-bis (or generalized additions that allow block to be used that way). That aside, in the interest of readers who try to understand the ecosystem and the trade-offs involved, I think that at least a reference to it in a statement like "was not chosen because of X" would be helpful. The "Note that similar performance benefits" section would lend itself to that. Text suggestion: [messages are provided in Appendix A.] Similarly, The No-Response option can be applied to Block1 requests, but offers no corresponding facility for Block2 responses. BR c --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --HoBOzF5stQ3CqCEx Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAmAsWwMACgkQOY0REtOk veE0+g//evS9LOaNlDgc8UJnmAr6U7EFVScfJVd2qZIb2eMaxD0JDDVgYy4pjnoI ekMIvCN65ZNC97y7eTNRH4G9nPrJSJdOBaIB0yLJn7BW4mrgqCWersJ+V0dninR0 PDZGcDGvpOoNvPUWmO2nDTLnS6s2VGTO3PZlxdYgNvk8PVsgOx6nCr5zP0YXIg4a GDSjVhssbBAoMgqDw7E0aok8nntDESjufdA8DTulVXanYI9v48CSvIUcfBiuNdBt hgZ92drQhdpyTQcZt9S4ygapVDpTCEwv6UsxoxdPbZOrwl2OkGjlk6fNdeeNv22X ztgXQ9IkPhf3UOb1st2Jt9dljebGlN36jX/L4zVcItHoQnzi9tRl/XXJTQMgumth hdnp2kOsJUICB6RT3P/6DQGWEEbsRFrKwQwPDFwWuSpCyqBQC5pHkjm+ysKtTKZy BfqdfEyMEGhPL9AQHCYy9snJ+ZXG/f5qP8B7wD3RKB5sHPb82v5h7lqQHn9+rkG9 6V1PE0N0FFqNBLNYP+99RZ/NB7rYb7NHAFINqr4FXOXj6wBIzZyczzMCZE3/WpR6 PDNgjTvDhsw9lQ4iM0ZAXSuq7S/ABHNZ2FWT9gZJK92+cE95y1prL1dADkAb4hW+ kJc7Q3DMGhbwIxExax+rvqNGS/1T8IncgoU4GEK9ul5Bs/h7EnM= =7oZB -----END PGP SIGNATURE----- --HoBOzF5stQ3CqCEx-- From nobody Tue Feb 16 16:26:06 2021 Return-Path: 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 422CB3A1342; Tue, 16 Feb 2021 16:26:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 wd3X90a7i4cc; Tue, 16 Feb 2021 16:26:01 -0800 (PST) Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECE093A1365; Tue, 16 Feb 2021 16:25:59 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 4C0B640887; Wed, 17 Feb 2021 01:25:57 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 38E07FD; Wed, 17 Feb 2021 01:25:56 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::aa6]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id BFF6E44; Wed, 17 Feb 2021 01:25:55 +0100 (CET) Received: (nullmailer pid 613591 invoked by uid 1000); Wed, 17 Feb 2021 00:25:55 -0000 Date: Wed, 17 Feb 2021 01:25:55 +0100 From: Christian =?iso-8859-1?Q?Ams=FCss?= To: supjps-ietf@jpshallow.com, Michael Richardson Cc: draft-ietf-core-new-block@ietf.org, dots@ietf.org, core@ietf.org Message-ID: References: <022401d6e440$06763ba0$1362b2e0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="I678fPgJbZy4TJia" Content-Disposition: inline In-Reply-To: <022401d6e440$06763ba0$1362b2e0$@jpshallow.com> Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Feb 2021 00:26:04 -0000 --I678fPgJbZy4TJia Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Jon, and hello Michael (grep for MCR, first point could use your response), thanks for your responses and updates; on these concrete points, the only that remain are: > > * "If there is insufficient space to create a response PDU": I don't > > understand what that means. (Where are request options reflected > > back?). >=20 > [Jon] This was triggered by a question by Michael Richardson " So, given a > Christmas-Tree-Packet (largest packet, every possible option space used, > every extension turned on...) how much data can I get back? :-)" and not > fully thought through. > It could happen though with Location-Path, Location-Query, Q-Block2, ETag, > Size2 and possibly Maxage, Content-Type, Hop-Limit or OSCORE in response= to > a POST. > OLD > If there is insufficient space to create a response PDU with a block > size of 16 bytes (SZX =3D 0) to reflect back all the request options as > appropriate, a 4.13 (Request Entity Too Large) is returned without > the Size2 Option. > NEW > If there is insufficient space to create a response PDU with a block > size of 16 bytes (SZX =3D 0) to send back all the response options as > appropriate, a 4.13 (Request Entity Too Large) is returned without > the Size1 Option. I think that is a corner case that deserves an error in *every* CoAP based protocol and is not specific to it; MCR do you think that this comment needs to be resolved in this way? > > * "For NON transmissions": This seems to imply that the full exchange of > > a body is either NON or CON; I don't see where that'd come from. I'd > > have expected to read something like "Each individual request can be > > NON or CON independent of the others. In particular, it can be > > convenient to send the ultimate payload...". >=20 > [Jon]The DOTS environment will only be using NON. To make Congestion > Control simple, > the expectation is that all transmissions are NON or (not recommended) are > all CON. The draft now generally records this expectation. Then why spend time talking about CON in the first place, and risk that things go awry in a case that's neither tested nor really specified for? It may be worth considering (ie. working group discussion; next interim maybe?) to just state that this works with NON only. I do see potential for the use of CON and NON mixed (in particular, the "but it doesn't have a dual version for server pushes" you dread of No-Response problem might go away), but if it's not explored to fruition in the problem set out for this document, confirmable messages may be better ruled out at all rather than getting second-class treatment. > > Caching: > >=20 > > * "are not part of the cache key": How about "are removed as part of the > > block assembly and thus do not reach the cache"? >=20 > [Jon] OK. > OLD > As the entire body is being cached in the proxy, the Q-Block1 and > Q-Block2 Options are not part of the cache key. > NEW > As the entire body is being cached in the proxy, the Q-Block1 and > Q-Block2 Options are removed as part of the > block assembly and thus do not reach the cache. It may help to make the same statement about Request-Tag; then, there is no more (IMO questionable) SHOULD about "a new Request-Tag [being] generated", and the "Ideally" sentence can be dropped too. > > Generally, the all-NON and all-CON examples don't look to me like > > what I'd be doing with this spec; the mixed "a CON every > > MAX_PAYLOADS" appears much more realistic. >=20 > [Jon] It is unsafe to use CON in the (potentially lossy) DOTS environment > (up to 93 secs timeout per payload with the defaults). Hence why we are > separating out the NON / CON usage. See above: then maybe don't do it at all. (Also, in the "not related to previous points" follow-up mail to come, there are some CON related questions that might be moot then). Best regards Christian --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --I678fPgJbZy4TJia Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAmAsYpAACgkQOY0REtOk veGfvhAAjpKcfSj6kmq0sXGHgAdgdGa70doOTsEb+TXYe1cIR27rTQqY6klXlra4 L73PLM5lLAADLhYRjz847tH8YkdjYJx166KK7USjAwPlpdSjaS3Th4LrpZQZ6iP4 TvRq5n4rmvYwaW1a6h4dsMH1b8/eMs41VbpDO7o4LTZZMxZNdsfZ1tKkKioqm8QJ ktIqjjl4h2+Qvz+OzSXOli3ROs9wdZtWEO/qYAmWJXubd8hvBmu7l1jvaoxHowqD +D6La/k7z2iLUq4+rg9FxrLqQ+gvIcQ/r/i+y88u79Y7bcw4K5AvH/msOyts8Wor 4q4eEudafOwGH+xj84orFBXrJsOwsS/JmCXeepbrwjfT00E02fJJheyknXNXsXM1 SbpUFm5MjKF+ML/IV6EBPj4hVLYRx8n5osfjVd65SoX6CCyMeisnRQ52e7SqJTuO Zc8CaMW5uF+wq9pdWmJ4l02B40cSBwq3GUmWoN4IQeeDafXenH7GjP2Pw6Nh998j i6JH8cZlib93+jrtkvXV3hmjelFPoenMVyQ+TimJoyOSJxiZhoIg+OwiQkx1BKGi XoCfXbsV0ekXQEr1dbfCgUs5QRhabrbhLWUau2GNgSV6v7ejgfzx/l9ujW65vyZf ymPvb7MDA/l9ZVjmBL21mjfM0xjQ+Haon6DfuLJkFvPMw6wTQWY= =Pc+U -----END PGP SIGNATURE----- --I678fPgJbZy4TJia-- From nobody Thu Feb 18 05:18:59 2021 Return-Path: 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 A66A03A11F2 for ; Thu, 18 Feb 2021 05:18:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 IhaUQhf32GEW for ; Thu, 18 Feb 2021 05:18:53 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 EDB943A11F1 for ; Thu, 18 Feb 2021 05:18:52 -0800 (PST) Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from ) id 1lCjCi-0005KQ-Tv; Thu, 18 Feb 2021 13:18:48 +0000 From: To: , Cc: , , References: <32574_1612339432_601A58E8_32574_29_1_787AE7BB302AE849A7480A190F8B9330315C6345@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <04a201d6d9d8$c7919ae0$56b4d0a0$@jpshallow.com> In-Reply-To: Date: Thu, 18 Feb 2021 13:18:52 -0000 Message-ID: <004201d705f8$9a108080$ce318180$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF93Q3vI61hNRrbjU+ftA4PQN3RvasQHx+g Content-Language: en-gb Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2021 13:18:58 -0000 Hi Christian, We have gone for adding in the following to the disadvantages list.=20 * The Q-Block Options do not support stateless operation/random access. * Proxying of Q-Block is limited to caching full representations. Regards Jon > -----Original Message----- > From: Christian M. Ams=FCss [mailto: christian@amsuess.com] > Sent: 16 February 2021 23:49 > To: jon@jpshallow.com; mohamed.boucadair@orange.com > Cc: draft-ietf-core-new-block@ietf.org; dots@ietf.org; core@ietf.org > Subject: Re: [core] WG Last Call on draft-ietf-core-new-block >=20 > Hello, >=20 > where not explicitly responded to, the updates address my points, = thank you for > updating the document. >=20 > > > * The Q-Block options do not support stateless operation / = random > > > access. > > > > [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 > Random access can also be in the Block1 phase; a standalone `PUT = /resource > Block1:5/0/6` can be used independenlty of other operations to = overwrite a > particular part of a resource. >=20 > > [Jon] For stateless, Request-Tag is included so this should be fine. > > = https://datatracker.ietf.org/doc/html/draft-ietf-core-stateless-06#sec > > tion-4 >=20 > By stateless, I was referring to the server not keeping state per = body. > That is the opposite of using a Request-Tag. >=20 > > > * 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 > The Block options are not part of the cache key -- they are not-safe-to-forward > and thus come with rules as to the cache behavior, rather than havign = a cache- > key property. >=20 > The behavior is sorted out: If an earlier client requested, say, > block2:0//6 (first 1KiB), then while that is fresh, it may be used to serve any > request for smaller chunks (say, block2:1//5 for bytes 512-1024). >=20 > The same is true in the other direction: A proxy may use its cached > 3x256 bytes (even exceeding the Max-Age), ask the server for the 4th = 256 byte > block (which by its ETag confirms the others are still good), and then serve them > combined as a 1KiB response. >=20 >=20 > Thus, I think these two points (Incomplete support for random access, = and block- > by-block proxying) still stand to be added to the considerations. >=20 > To give you background on why I'm so picky about this list: People > *will* still get the initial impression that this is the = later-and-greater version, and > for the outlined purposes it is, but if we don't set the expectations right here, > there will be disappointment. >=20 > BR > c >=20 > -- > To use raw power is to make yourself infinitely vulnerable to greater powers. > -- Bene Gesserit axiom From nobody Thu Feb 18 05:31:52 2021 Return-Path: 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 0B91F3A1209; Thu, 18 Feb 2021 05:31:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 34kEmk4IQOO0; Thu, 18 Feb 2021 05:31:47 -0800 (PST) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42D673A1200; Thu, 18 Feb 2021 05:31:44 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id 3016A40887; Thu, 18 Feb 2021 14:31:42 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id 52C14FD; Thu, 18 Feb 2021 14:31:41 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::aa6]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id C608B190; Thu, 18 Feb 2021 14:31:40 +0100 (CET) Received: (nullmailer pid 826586 invoked by uid 1000); Thu, 18 Feb 2021 13:31:40 -0000 Date: Thu, 18 Feb 2021 14:31:40 +0100 From: Christian =?iso-8859-1?B?TS4gQW1z/HNz?= To: supjps-ietf@jpshallow.com Cc: draft-ietf-core-new-block@ietf.org, dots@ietf.org, core@ietf.org Message-ID: References: <022401d6e440$06763ba0$1362b2e0$@jpshallow.com> <004601d705f8$acbec250$063c46f0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Jd9hOaZ5pb197ncl" Content-Disposition: inline In-Reply-To: <004601d705f8$acbec250$063c46f0$@jpshallow.com> Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2021 13:31:50 -0000 --Jd9hOaZ5pb197ncl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Picking a quick one because I don't know when I'll get to the rest: > > * 4 the new 4.08 format: Since this is a CBOR sequence, the > > implementation note on telling the array length in advance does not > > apply. As for the CDDL, I don't know whether the array format is OK to > > use for the sequence, or whether the CBOR >=20 > [Jon] Not sure what you are trying to ask here. I know we removed the > Request-Tag from the CDDL which may have changed things. If the array were sent in CBOR, indeed the sequence 1, 10, 20 would look like this (courtesy of cbor.me): 83 # array(3) <--- here is where you need to know the length in advance 01 # unsigned(1) 0A # unsigned(10) 14 # unsigned(20) But as the content format is a cbor-sequence one, what you actually send is this: 01 # unsigned(1) 0A # unsigned(10) 14 # unsigned(20) (No array header, just a sequence of self-delimited items). So now the implementer's worst worry is that if they start writing an item in the last byte and the item needs a u16 they gotta roll back, but that is simple. Picking the array length in advance would be hard (and the implementation note's suggestion of not exceeding 23 items would apply), but by using a CBOR sequence you're already free of that. BR c --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --Jd9hOaZ5pb197ncl Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAmAubDQACgkQOY0REtOk veFbbA/7BPh7S3PNlQ/WckFLVe0zY3/W5v8360+3mDw7jDRi7sIgMf3GMnbimR1+ VMtCCcUvA+Vt/SHANhVHVtV+919P5yvOWK3VCnmE8pcfA7Wloa9V6tV+BA/tCiEc Gsj9szQruXRnrCLI6q0wXbZhhPqSGAyQsuB0qNPBA+jgT3vmjPV2nvttEjf/2TRk Ml8VrRVIyO0wuIzgmJ3dRyQELeQRa5BTNShfom5TIxKWrb8UZ47sarkOIauRJqVO 77p7Wg6WMVMTp6NH1fL1/k2qj3GgLeoaGfUQa7MKeda8hMycWKsuVLitbGinBHo0 ebAbmgKcyyF2GVywJ7v1LMYn7g/sFctzA++2Su7LwMkPgPzsRGYtcMWcTG/ojlxN rf28Tr3yYKpRT3R9yF4xDmAvE1Zo2BGnZVWOa+AuwdKFyXzRGzPPBmT7C2e1GMrt XCs6jGkCl4PwY2eTMpHK31YEG12IZkcGC9av9vQ+2NRtyKDHImJJV/13t1x+zBtE 1uvepZ1s7KBXq80eqWRtDMJnCqZQ0UWm35/q0qVTiDFeZkc+fcEuV2PNw85esz9Q cS+yWxRsFcwYYMnm6DrGeHis/CrOmWoprHNCpL22EHUkuKX8CBKd2NfrsWnTU1N0 9sSkjtoBMmgN51OgnO7X7a/V3VsUamfMW3L45p2GLRPRgejnEVU= =uxQb -----END PGP SIGNATURE----- --Jd9hOaZ5pb197ncl-- From nobody Thu Feb 18 06:29:29 2021 Return-Path: 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 E61E93A12A0 for ; Thu, 18 Feb 2021 06:29:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 EsMzmVpzCdmP for ; Thu, 18 Feb 2021 06:29:24 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 F22CD3A129D for ; Thu, 18 Feb 2021 06:29:22 -0800 (PST) Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from ) id 1lCjDE-0005Ko-8f; Thu, 18 Feb 2021 13:19:20 +0000 From: To: , "'Michael Richardson'" Cc: , , References: <022401d6e440$06763ba0$1362b2e0$@jpshallow.com> In-Reply-To: Date: Thu, 18 Feb 2021 13:19:23 -0000 Message-ID: <004601d705f8$acbec250$063c46f0$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKHUmmxquhArXd4h/ZvumPsHfcPaAHVBsU8qO6PjMA= Content-Language: en-gb Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2021 14:29:28 -0000 Hi Christian, Thanks for taking the time to review this. See inline [Jon] Changes can be seen at https://tinyurl.com/new-block-latest=20 Regards Jon > -----Original Message----- > From: Christian Ams=FCss [mailto: christian@amsuess.com] > Sent: 17 February 2021 00:26 > To: core@ietf.org; draft-ietf-core-new-block@ietf.org > Subject: Re: [core] I-D Action: draft-ietf-core-new-block-06.txt >=20 > Hello new-block authors, >=20 > here a few notes that I didn't see fitting any of the previous threads = > (or so I > hope): >=20 > * "can fall back to using Block1 and Block2 Options, respectively": = Even > though the rest says (as agreed on) that it's both-or-none, the > "respectively" seems to imply otherwise -- maybe just drop the word. [Jon] "respectively" dropped >=20 > * CSM option: "There is little, if any, benefit of using these options > with [reliable transports]" ... and reliable transports are the only > thing CSMs are defined for. So why define a CSM if it's not expected > to be useful? [Jon] This is here for completeness. DOTS tries to use UDP, but falls = back to using TCP if unable to use UDP.=20 >=20 > * Ad Class E/U: It may be worth stating that it *is* allowed to mix > Block and Q-Block when one is inner and the other is outer -- for = the > simple reason that there'd be no way to enforce anything else, for > proxies along the path can perform outer-blockwise transfers in > ignorance of the content. >=20 > (Then, at a receiver, an outer Block option could arrive, and when > that's done, it should still process the inner Q-Block without = erring > just because the two worlds met). [Jon] Good point. OLD Note that if Q-Block1 (or Q-Block2) Option is included in a packet, = Block1 (or Block2) Option MUST NOT be included. NEW (moved to after the OSCORE statement) Note that if Q-Block1 or Q-Block2 Options are included in a packet as = Inner options, Block1 or Block2 Options MUST NOT be included as Inner options. Similarly there MUST NOT be a mix of Q-Block and Block for the Outer options. Q-Block and Block Options can be mixed across Inner and Outer options as these are handled independently of each other. >=20 > * 3.3 Use of the QB1 option: >=20 > The rules for the final message are different between 2.04 Changed > ("token SHOULD be from the last received payload") and 2.05 Content > (~"MUST be the one in the final block"). Any reason for that? [Jon] The original thinking was that with FETCH and Observe, the server needs a token for sending back any Observes. The client needs to know = the exact token that will get used for matching up any Observe responses. = Hence the MUST. However, see next response. > The > former sounds more sensible. (I originally favored the latter, but > then when a 4.08 comes back on the last-block request, the same = token > would need to be used for the final successful response too, and > that'd be awkward -- and I'd prefer to avoid it if we can pick the = one > rule set ("SHOULD from the last received") that allows having only = one > response per token unless there are actually multiple blocks > transported on it). [Jon] It is true that the final block can be sent, and then = re-requested, so the server does not know which token to pick for the Observe in this = case. OLD This Response Code indicates successful receipt of the entire FETCH = request body (Section 2 of [RFC8132]) and the appropriate representation of the resource is being 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. NEW This Response Code indicates successful receipt of the entire FETCH = request body (Section 2 of [RFC8132]) and the appropriate representation of the resource is being returned. The token used in the response SHOULD be = from the last received payload. If the FETCH request includes the Observe = Option, then the server MUST use the same token for returning any Observe = triggered responses so that the client can match them up. >=20 > * 3.5 Block + Observation: Has this been implemented and tested? The > combination of Block1(!)+Block2+Observer is already tricky with > regular blocks, and made harder by the semi-noresponse blocks here. >=20 > Unless you have a use case for it, I'd ask to see this implmeneted > before it is published, or else to leave this as "interactions are = up > to further specification" (with a corresponding note in the > ups-and-downs list) in the interest of getting this on speedily = (given > this document's purpose is to get the DOTS use case running). [Jon] Yes, this has been implemented and tested. =20 >=20 > * The 2.31 Continue rules: Why not send it with CON? A 2.31 Continue = is > just as compact as an ACK, and can convey to the client that all > packages up to that point have been received, so it doesn't need to > retransmit the earlier ones even though the corresponding ACK may = have > gotten lost. [Jon] For DOTS, we have to have the entire conversation for the = transmission of the telemetry data as NON, as there could be a flooded pipe in one direction because of a DDoS attack. >=20 > * The new QB2 M-bit rules depend on MAX_PAYLOADS to be agreed. But=20 > that > agreement is SHOULD only, and even that's already stretching what = I'd > expect of a configurable CoAP parameter. [Jon] Having the flexibility and ability to configure the actual value = and mutually agree on the new value could beneficial to DOTS (clients on low bandwidth networks may want to tune it down as suggested as per:- "If the CoAP peer reports at least one payload has not arrived for each = body for at least a 24 hour period and it is known that there are no other network issues over that period, then the value of MAX_PAYLOADS can be reduced by 1 at a time (to a minimum of 1) and the situation = re-evaluated for another 24 hour period until there is no report of missing payloads under normal operating conditions. The newly derived value for = MAX_PAYLOADS should be used for both ends of this particular CoAP peer link. Note = that the CoAP peer will not know about the MAX_PAYLOADS change until it is reconfigured. As a consequence of not being reconfigured, the peer may indicate that there are some missing payloads prior to the actual = payload being transmitted as all of its MAX_PAYLOADS payloads have not arrived." >=20 > It's also rather complicated. How is this better than a simple = "M=3D1 > means this block plus as many as you can comfortably send, where = M=3D0 > is for this one only"? [Jon] We still need to have a concept of 'Continue' to reduce any NON_TIMEOUT delays for every MAX_PAYLOADS for handling congestion = control. 'Continue' is used in multiple places in the draft. >=20 > * "is meant to prevent amplification attacks": Could you elaborate? A > client permitted the use of QB2 has already some leverag on the = server > to start attacks, and would in any case (overlaps or not) only be > permitted MAX_PAYLOADS on a single request by the server, no matter > how it requests more than that. [Jon] A single request, containing multiple Q-Block2 with M set and the = same NUM (0 meaning all blocks is a really bad case) would otherwise (no = overlap protection) cause MAX_PAYLOADS to be sent, NON_TIMEOUT pause, next set = of MAX_PAYLOADS, NON_TIMEOUT pause etc. for quite some time. Request = packet of 1k+, each Q-Block2 being 2 bytes gives 500+ requests for lots of = packets. Yes, there are NON_TIMEOUT gaps giving respite against a single request, = but multiple requests would average things out. >=20 > * "then the body response SHOULD be restarted with a different ETag > Option value": That behavior sounds like a recipe for endless = running > requests when CON is involed (which, granted, are under flow = control, > but still don't do anything useful). Given there is also a > recommendation to keep the being-transmitted version alive, why not > just stop the transmission? Or send just one final block of the new > value -- and then it's up to the client to decide whether that's a > representation it already knows (and just got a freshness statement > for) or needs to get it as a whole again? [Jon] My implementation maintains the cached body as per previous RECOMMENDED statement which keeps things simple. I was then trying to = cover the non-cached copy case. I agree with your concern. [Jon] From the client's perspective, ETag is opaque with no way of = knowing a newly seen ETag is earlier or later. If a NON (old) ETag is out of = sequence on arrival or there is a CON retransmit with an (old) ETag the client = has to make a decision on seeing the (old) ETag (which may be for a single = packet that holds the whole body and hence is not in the clients history). = Does the current receipt of multiple payloads get aborted or ... when the = (old) ETag is seen? [Jon] The new data length may be less than the previous payload, and so = the currently being transmitted block is beyond the size of the new data. [Jon] The (needs terminating) response can be for something other than a GET, making it a bit more problematic for the client to continue - especially if there is non-idempotent usage. [Jon] Two ways forward here 1. Make previous statement a MUST and delete this statement Or 2. OLD If the server detects part way through a body transfer that the resource data has changed and the server is not maintaining a cached copy of the = old data, then the body response SHOULD be restarted with a different ETag Option value. Any subsequent missing block requests MUST be responded to using the latest ETag Option value. NEW If the server detects part way through a body transfer that the resource data has changed and the server is not maintaining a cached copy of the = old data, then the transmission is terminated. Any subsequent missing block requests MUST be responded to using the latest ETag and Size2 Option = values with the updated data. [Jon] Preferences ? >=20 > * 3.6 Size1/2: These options MUST be used per 3rd paragraph, so the = "If" > in the 4th is odd. >=20 > * (General wording: It's "A comprise X and Y" or "A is comprised of X > and Y"; https://en.wiktionary.org/wiki/comprise#Usage_notes "in the > passive voice") [Jon] OLD The Size1 Option MUST be used with the Q-Block1 Option when used in a request. The Size2 Option MUST be used with the Q-Block2 Option when = used in a response. If Size1 or Size2 Options are used, they MUST be used in all payloads of = the body and MUST preserve the same value in each of those payloads. NEW The Size1 Option MUST be used with the Q-Block1 Option when used in a request and MUST be present in all payloads of the request preserving = the same value. The Size2 Option MUST be used with the Q-Block2 Option when = used in a response and MUST be present in all payloads of the response = preserving the same value. >=20 > * 4 the new 4.08 format: Since this is a CBOR sequence, the > implementation note on telling the array length in advance does not > apply. As for the CDDL, I don't know whether the array format is OK = to > use for the sequence, or whether the CBOR [Jon] Not sure what you are trying to ask here. I know we removed the Request-Tag from the CDDL which may have changed things. >=20 > * 5. Use of Tokens: The MUST on the unique tokens misrepresents > echo-request-tag. There are rules there about when a token can or = can > not be reused, and they depend on factors immaterial to the present > specification. >=20 > In particular, when used with CoAP-over-TLS or with OSCORE, using > non-unique tokens is quite alright. >=20 > I recmomend not making a normative statement where none is required; > eg. >=20 > "Each new request generally uses a new Token (and sometimes must, = see > Section 4 of ERT). Additional responses to a request all use the > token of the request they respond to". [Jon] Gone with your suggestion. >=20 > * "Implementation Note: To minimize": I'd prefer to go with "it is > suggested" rather than "recommended", but as long as it's not in > normative language, I don't care too much. [Jon] Ok >=20 > * "Servers continue to treat": While not factually incorrect = considering > the above recommendation, the reference to the 32 bits in the > paragraph about the server is confusing. Last prenthized expression > could read "(i.e., is sent on the token of the request that caused > its retransmission)". [Jon] OLD To minimize on the number of tokens that have to be tracked by clients, = it is recommended that the bottom 32 bits is kept the same for the same = body and the upper 32 bits contains the current body's request number (incrementing every request). This allows the client to be alleviated = from keeping all the per-request-state, e.g., in Section 3 of [RFC8974]. Servers continue to treat the token as a unique opaque entity. If an individual payload has to be resent (e.g., requested upon packet loss), = then the retransmitted packet keeps the same bottom 32 bits and the upper 32 = bits is incremented. NEW To minimize on the number of tokens that have to be tracked by clients, = it is suggested that the bottom 32 bits is kept the same for the same body = and the upper 32 bits contains the current body's request number = (incrementing every request, including for every re-transmit). This allows the client = to be alleviated from keeping all the per-request-state, e.g., in Section 3 = of [RFC8974]. >=20 > * (I skipped through the congestion contol section for the time being; > it's probably best read by someone with some experience in = congestion > control which I lack). [Jon] Noted. >=20 > * "When the next client completes building the body, any existing > partial body transmission to the CoAP server is terminated": Just a > note, you're already using Request-Tag, so you could leave it up to > the proxy to try to run them simultaneously (it obviously can, as it > already got to the point of having both request bodies loaded in > full). The server can then still cancel one or postpone the other. [Jon] If the proxy uses multi-plexing client logic to talk to a singular server with a common 'CoAP session', it has to determine which body = entity to terminate - and may chose the wrong one based as timing, whereas it = is simpler to get the proxy to make the correct decision. >=20 > * Figure 6: The first line says "for RT=3D11", that's probably a = remnant > from when the Request-Tag was copied into the payload. (Same for = later > '[for RT=3D...]' items [Jon] Fixed ~Jon >=20 > Best regards > Christian >=20 > -- > To use raw power is to make yourself infinitely vulnerable to greater=20 > powers. > -- Bene Gesserit axiom From nobody Thu Feb 18 08:29:34 2021 Return-Path: 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 9EBCD3A13EA for ; Thu, 18 Feb 2021 08:29:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no 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 D2h_fIavX7ik for ; Thu, 18 Feb 2021 08:29:27 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 E18C43A13F9 for ; Thu, 18 Feb 2021 08:29:23 -0800 (PST) Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from ) id 1lCjCt-0005KZ-7A; Thu, 18 Feb 2021 13:18:59 +0000 From: To: , Cc: , , References: <23740_1612339780_601A5A44_23740_98_8_787AE7BB302AE849A7480A190F8B9330315C6374@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <28095_1608732578_5FE34FA2_28095_105_1_787AE7BB302AE849A7480A190F8B9330315A1C90@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: Date: Thu, 18 Feb 2021 13:19:02 -0000 Message-ID: <004401d705f8$a0333de0$e099b9a0$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKB62JphLL4G1Ld1UlfNpXpEuFZPqkIBQCQ Content-Language: en-gb Archived-At: Subject: Re: [Dots] [core] WG Last Call on draft-ietf-core-new-block (No-Response) 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2021 16:29:30 -0000 Hi Christian, We have gone with adding to Section 1.1 " The No-Response Option was considered but was abandoned as it does not apply to Q-Block2 responses. A unified solution is defined in the = document." Regards Jon > -----Original Message----- > From: Christian M. Ams=FCss [mailto:christian@amsuess.com] > Sent: 16 February 2021 23:54 > To: mohamed.boucadair@orange.com > Cc: draft-ietf-core-new-block@ietf.org; dots@ietf.org; core@ietf.org = WG > (core@ietf.org) > Subject: Re: [core] WG Last Call on draft-ietf-core-new-block (No-Response) >=20 > Hello Med, >=20 > On Wed, Feb 03, 2021 at 08:09:40AM +0000, mohamed.boucadair@orange.com > wrote: > > As a follow-up on this issue, we finally went with an approach that > > does not require No-Response. We do have the following to avoid = extra > > delays, e.g., >=20 > The need to indicate when a client wants confirmation has been avoided = by > having timeouts on both sides, and relying more on MAX_PAYLOADS being > aligned. >=20 > For my taste, that makes unnecessary sacrifices in robustness over the simple > two-byte NoResponse:0 that'd go with every MAX_PAYLOADS'th > Q-Block2 from the client (and would completey avoid the risk of = stalling in a > lossless situation). >=20 > (For the other direction, corective heuristics can easily be applied). >=20 > But given they are explicitly configured in the DOTS case where = Q-Block is used, > so -- well. Food for a block-bis (or generalized additions that allow block to be > used that way). >=20 >=20 > That aside, in the interest of readers who try to understand the = ecosystem and > the trade-offs involved, I think that at least a reference to it in a statement like > "was not chosen because of X" would be helpful. The "Note that similar > performance benefits" section would lend itself to that. Text = suggestion: >=20 > [messages are provided in Appendix A.] Similarly, The No-Response = option > can be applied to Block1 requests, but offers no corresponding = facility > for Block2 responses. >=20 > BR > c >=20 > -- > To use raw power is to make yourself infinitely vulnerable to greater powers. > -- Bene Gesserit axiom From nobody Thu Feb 18 08:40:27 2021 Return-Path: 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 809863A1429 for ; Thu, 18 Feb 2021 08:40:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 CICMCESZxxi9 for ; Thu, 18 Feb 2021 08:40:22 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 B322D3A1425 for ; Thu, 18 Feb 2021 08:40:18 -0800 (PST) Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from ) id 1lCmIy-0005Tw-LR; Thu, 18 Feb 2021 16:37:28 +0000 From: To: Cc: , , References: <022401d6e440$06763ba0$1362b2e0$@jpshallow.com> <004601d705f8$acbec250$063c46f0$@jpshallow.com> In-Reply-To: Date: Thu, 18 Feb 2021 16:37:32 -0000 Message-ID: <00f901d70614$5ab51b50$101f51f0$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKHUmmxquhArXd4h/ZvumPsHfcPaAHVBsU8AgePCMYCKEdkN6jNWQ8Q Content-Language: en-gb Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2021 16:40:27 -0000 Hi Christian, We are following https://tools.ietf.org/html/rfc8742#section-4.1 here. = CDDL does not support a notation for top-level CBOR sequences so have gone = with the recommendations of this section. As CDDL defines it as an array using the documentation text "This = defines an array, the elements of which are to be used in a CBOR Sequence:", I am thinking that we need to keep it as an array. I guess that we need an expert understanding of what to do here. - Maybe leave out the CDDL definition and give an example? Regards Jon > -----Original Message----- > From: Christian M. Ams=FCss [mailto: christian@amsuess.com] > Sent: 18 February 2021 13:32 > To: supjps-ietf@jpshallow.com > Cc: draft-ietf-core-new-block@ietf.org; dots@ietf.org; core@ietf.org > Subject: Re: [core] WG Last Call on draft-ietf-core-new-block >=20 > Picking a quick one because I don't know when I'll get to the rest: >=20 > > > * 4 the new 4.08 format: Since this is a CBOR sequence, the > > > implementation note on telling the array length in advance does = not > > > apply. As for the CDDL, I don't know whether the array format is = OK to > > > use for the sequence, or whether the CBOR > > > > [Jon] Not sure what you are trying to ask here. I know we removed = the > > Request-Tag from the CDDL which may have changed things. >=20 > If the array were sent in CBOR, indeed the sequence 1, 10, 20 would = look like this > (courtesy of cbor.me): >=20 > 83 # array(3) <--- here is where you need to know the length in = advance > 01 # unsigned(1) > 0A # unsigned(10) > 14 # unsigned(20) >=20 > But as the content format is a cbor-sequence one, what you actually = send is this: >=20 > 01 # unsigned(1) > 0A # unsigned(10) > 14 # unsigned(20) >=20 > (No array header, just a sequence of self-delimited items). >=20 > So now the implementer's worst worry is that if they start writing an = item in the > last byte and the item needs a u16 they gotta roll back, but that is simple. Picking > the array length in advance would be hard (and the implementation = note's > suggestion of not exceeding 23 items would apply), but by using a CBOR > sequence you're already free of that. >=20 > BR > c >=20 > -- > To use raw power is to make yourself infinitely vulnerable to greater powers. > -- Bene Gesserit axiom From nobody Thu Feb 18 08:43:56 2021 Return-Path: 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 36F203A136C; Thu, 18 Feb 2021 08:43:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 ikpC00kFSe0Z; Thu, 18 Feb 2021 08:43:52 -0800 (PST) Received: from prometheus.amsuess.com (prometheus.amsuess.com [5.9.147.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 466793A142D; Thu, 18 Feb 2021 08:43:49 -0800 (PST) Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id DCDED40887; Thu, 18 Feb 2021 17:43:47 +0100 (CET) Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id DF2EAFD; Thu, 18 Feb 2021 17:43:46 +0100 (CET) Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::aa6]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 9DB99190; Thu, 18 Feb 2021 17:43:46 +0100 (CET) Received: (nullmailer pid 839522 invoked by uid 1000); Thu, 18 Feb 2021 16:43:46 -0000 Date: Thu, 18 Feb 2021 17:43:46 +0100 From: Christian =?iso-8859-1?B?TS4gQW1z/HNz?= To: supjps-ietf@jpshallow.com Cc: draft-ietf-core-new-block@ietf.org, dots@ietf.org, core@ietf.org Message-ID: References: <022401d6e440$06763ba0$1362b2e0$@jpshallow.com> <004601d705f8$acbec250$063c46f0$@jpshallow.com> <00f901d70614$5ab51b50$101f51f0$@jpshallow.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="aDaF68xRb12J6Va2" Content-Disposition: inline In-Reply-To: <00f901d70614$5ab51b50$101f51f0$@jpshallow.com> Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2021 16:43:54 -0000 --aDaF68xRb12J6Va2 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello Jon, On Thu, Feb 18, 2021 at 04:37:32PM -0000, supjps-ietf@jpshallow.com wrote: > I guess that we need an expert understanding of what to do here. > - Maybe leave out the CDDL definition and give an example? the CDDL definition is fine and following the state-of-the-art workaround. But what it means is that the array wrapping is only there on paper to make the CDDL happy. And as the array header does not hit the wire (and is not generally constructed in memory either), the implementation note is moot. BR c --=20 To use raw power is to make yourself infinitely vulnerable to greater power= s. -- Bene Gesserit axiom --aDaF68xRb12J6Va2 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEECM1tElX6OodcH7CWOY0REtOkveEFAmAumT4ACgkQOY0REtOk veEPbA//d865P9xMR7jFfd+6JWJ9+Ou5RMIvFyDqPN/whCO3V3Zv6ib80RLX3edj GFzqitykklEIEUQZDCxGDcOU2P3h3GqSfBvVs4Xl2dWRp6nbIUXSndYw7bqVp7Ba q8RHWeM1DZaYxwudFW4pXuYoPGlGczK5VvQVujuFjsHCFfQN9tODgSFzzKYfZgzE TAsINVyXaAVfgW9qVP5VbTxCzWvPli9+rfSOlm+Oh61eDmwdrIkRHHjV2rjwcI8W k50e2/e8nFCyGgmKVcmr255H7f37WiAkIgOwCIzx5UXD4WWZ+kwEw6EvlaTpxzZx LpcY5kIGCBgHRJ85xU2izMBa2brJko8J5sK1jx56xJtYsbyDeMv6AevWviQCbFKa l1cFlUF4qgLv6R7Nbb03omyo7KSYgSRVQ0EgB9WCXmLtHT/ZXST7PxyBTV7sC4mN 3MBY8j20BF2vP3yJxHKFVto10VsVssfxfHprwAymWI3RDf0hftLkLMlXkzITMjcP M5pU6L/DuZPZuEov1H/X+kXHJikoYwM0Hj5LJ99FOpH7wCCViCymlBnJuo57GTCo aBRwcmkctqm5ov++s2Z9P77RCfePweQxUpDo3sSRZtG7uROnEoVrd+GIFVTjRFr5 ShEDjzDf6CwKzsFZaYIDdJTrMUQYA3Ov5EBgv5Lm00tsVwLH10A= =AZjU -----END PGP SIGNATURE----- --aDaF68xRb12J6Va2-- From nobody Thu Feb 18 09:01:08 2021 Return-Path: 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 A43043A1454 for ; Thu, 18 Feb 2021 09:01:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no 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 yv34-BuJwNjN for ; Thu, 18 Feb 2021 09:01:01 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 012903A145E for ; Thu, 18 Feb 2021 09:01:00 -0800 (PST) Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from ) id 1lCmfb-0005Vy-Jv; Thu, 18 Feb 2021 17:00:51 +0000 From: To: Cc: , , References: <022401d6e440$06763ba0$1362b2e0$@jpshallow.com> <004601d705f8$acbec250$063c46f0$@jpshallow.com> <00f901d70614$5ab51b50$101f51f0$@jpshallow.com> In-Reply-To: Date: Thu, 18 Feb 2021 17:00:55 -0000 Message-ID: <011801d70617$9eeb3c70$dcc1b550$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKHUmmxquhArXd4h/ZvumPsHfcPaAHVBsU8AgePCMYCKEdkNwJGSVBOANS1kPiotIo9wA== Content-Language: en-gb Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Feb 2021 17:01:04 -0000 Hi Christian, > the CDDL definition is fine and following the state-of-the-art workaround. > > But what it means is that the array wrapping is only there on paper to make the > CDDL happy. And as the array header does not hit the wire (and is not generally > constructed in memory either), the implementation note is moot. Happy to remove the (actual) array wrappers and associated stuff despite CDDL documentation text. I think I will add in an example to keep me happy by removing any ambiguity about the array. Regards Jon From nobody Fri Feb 19 01:47:45 2021 Return-Path: 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 ABE003A1277 for ; Fri, 19 Feb 2021 01:47:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no 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 7_0x3T8D5I97 for ; Fri, 19 Feb 2021 01:47:39 -0800 (PST) Received: from mail.jpshallow.com (mail.jpshallow.com [217.40.240.153]) (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 204623A132F for ; Fri, 19 Feb 2021 01:47:38 -0800 (PST) Received: from mail2.jpshallow.com ([192.168.0.3] helo=N01332) by mail.jpshallow.com with esmtp (Exim 4.92.3) (envelope-from ) id 1lD2Nq-0006BJ-Rj; Fri, 19 Feb 2021 09:47:34 +0000 From: To: Cc: , , References: <022401d6e440$06763ba0$1362b2e0$@jpshallow.com> <004601d705f8$acbec250$063c46f0$@jpshallow.com> <00f901d70614$5ab51b50$101f51f0$@jpshallow.com> <011801d70617$9eeb3c70$dcc1b550$@jpshallow.com> In-Reply-To: <011801d70617$9eeb3c70$dcc1b550$@jpshallow.com> Date: Fri, 19 Feb 2021 09:47:37 -0000 Message-ID: <01ab01d706a4$41b1bf10$c5153d30$@jpshallow.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKHUmmxquhArXd4h/ZvumPsHfcPaAHVBsU8AgePCMYCKEdkNwJGSVBOANS1kPgBkCyM3KipIksA Content-Language: en-gb Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Feb 2021 09:47:41 -0000 Hi Christian, I have gone with just updating the wording. Changes can be found at https://tinyurl.com/new-block-latest for page 16. Regards Jon > -----Original Message----- > From: supjps-ietf@jpshallow.com [mailto:ietf-supjps-supjps- > ietf@jpshallow.com] > Sent: 18 February 2021 17:01 > To: christian@amsuess.com > Cc: draft-ietf-core-new-block@ietf.org; dots@ietf.org; core@ietf.org > Subject: Re: [core] WG Last Call on draft-ietf-core-new-block > > Hi Christian, > > > the CDDL definition is fine and following the state-of-the-art workaround. > > > > But what it means is that the array wrapping is only there on paper to > make the > > CDDL happy. And as the array header does not hit the wire (and is not > generally > > constructed in memory either), the implementation note is moot. > > Happy to remove the (actual) array wrappers and associated stuff despite > CDDL documentation text. > > I think I will add in an example to keep me happy by removing any ambiguity > about the array. > > Regards > > Jon > > _______________________________________________ > core mailing list > core@ietf.org > https://www.ietf.org/mailman/listinfo/core