From nobody Wed Feb 3 00:09:46 2021 Return-Path: X-Original-To: core@ietfa.amsl.com Delivered-To: core@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 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: [core] WG Last Call on draft-ietf-core-new-block (No-Response) X-BeenThere: core@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Feb 2021 08:09:44 -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.