Re: [core] Roman Danyliw's No Objection on draft-ietf-core-new-block-11: (with COMMENT)

mohamed.boucadair@orange.com Thu, 06 May 2021 06:12 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E7BB3A1083; Wed, 5 May 2021 23:12:54 -0700 (PDT)
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 Ge8FLY7m-CkF; Wed, 5 May 2021 23:12:49 -0700 (PDT)
Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.39]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C2443A1071; Wed, 5 May 2021 23:12:48 -0700 (PDT)
Received: from opfedar01.francetelecom.fr (unknown [xx.xx.xx.2]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 4FbNXs3vJHzFqKF; Thu, 6 May 2021 08:12:45 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1620281565; bh=KAF8FD5b555CB0/NHAkNFDWzUy9OtSWYMGE0G81OWs4=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=ucpCyxTyjPGLMpNTj0aJr+22GOxzfQ68NwPEU1UVkixi04OG6DIYF4OKdlQyRI7Ic pmP1ANq/3N+Shr6+Dq3W6IGBKkmbjWg5rxZvg8pk7l9kPcsFEskoNUevL1Y5iwBoMf fhvU+yMLSZj8NTKKjgzByn4FnhN6TSUMuYfL9KvRN2yJ/okI3rfUgNkm9Su1Z3yejY lXWbbhpzcpk4XR7CQSwBmyDOmgVAaSp5dm3zYPDdVuYzBrIA4bbeWRPeSEW6Uv7AkI OKGkGe4milVo4gA/qzQ14VxwvK9v4Y1ZQSDLA+3WYo5ovn5APaBpkSBfAkAygu4maz ZGRlpoRD5/f6A==
Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.101]) by opfedar01.francetelecom.fr (ESMTP service) with ESMTP id 4FbNXs2P4zzBrLj; Thu, 6 May 2021 08:12:45 +0200 (CEST)
From: mohamed.boucadair@orange.com
To: Roman Danyliw <rdd@cert.org>, The IESG <iesg@ietf.org>
CC: "draft-ietf-core-new-block@ietf.org" <draft-ietf-core-new-block@ietf.org>, "core-chairs@ietf.org" <core-chairs@ietf.org>, "core@ietf.org" <core@ietf.org>, "marco.tiloca@ri.se" <marco.tiloca@ri.se>
Thread-Topic: Roman Danyliw's No Objection on draft-ietf-core-new-block-11: (with COMMENT)
Thread-Index: AQHXQeNbFwKD5z5uIk+Qp/pk7eHOL6rV7ZMQ
Date: Thu, 06 May 2021 06:12:44 +0000
Message-ID: <2142_1620281565_609388DD_2142_32_1_787AE7BB302AE849A7480A190F8B9330353776FE@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
References: <162024227267.18682.9364450117778772479@ietfa.amsl.com>
In-Reply-To: <162024227267.18682.9364450117778772479@ietfa.amsl.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="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/DbvXFBxyNOinALsuynwFydQoVTw>
Subject: Re: [core] Roman Danyliw's No Objection on draft-ietf-core-new-block-11: (with COMMENT)
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 06 May 2021 06:12:58 -0000

Hi Roman, 

Thank you for the review. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Roman Danyliw via Datatracker [mailto:noreply@ietf.org]
> Envoyé : mercredi 5 mai 2021 21:18
> À : The IESG <iesg@ietf.org>
> Cc : draft-ietf-core-new-block@ietf.org; core-chairs@ietf.org;
> core@ietf.org; marco.tiloca@ri.se; marco.tiloca@ri.se
> Objet : Roman Danyliw's No Objection on draft-ietf-core-new-block-11:
> (with COMMENT)
> 
> Roman Danyliw has entered the following ballot position for
> draft-ietf-core-new-block-11: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut
> this introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-
> criteria.html
> for more information about DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-core-new-block/
> 
> 
> 
> ---------------------------------------------------------------------
> -
> COMMENT:
> ---------------------------------------------------------------------
> -
> 
> ** Section 3.2 and Section 11
> (a) Section 3.2. It is not recommended that these options are used in
> a NoSec security mode
> 
> (b) Section 11. It is NOT RECOMMENDED that the NoSec security mode is
>    used if the Q-Block1 and Q-Block2 Options are to be used.
> 
> I believe that the intend of (a) and (b) is to caution against using
> NoSec mode with either Q-Block1 or 2.  One read of (b) would be that
> this guidance is only about when both options are used together
> (e.g., the language of Section 4.7).
> I recommend restating (b) to be more along the lines of:
> 
> Therefore, it is NOT RECOMMENDED to use the NoSec security mode if
> either the
> Q-Block1 or Q-Block2 Options is used.

[Med] ACK.

> 
> ** Section 4.1.  Colloquialism. s/local configuration knob/local
> configuration option/
> 

[Med] Changed it to "local configuration parameter".

> ** Section 4.4.
> 
> (a)   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.
> 
> ...
> 
> (b) If the server transmits a new body of data (e.g., a triggered
> Observe
>    notification) with a new ETag to the same client as an additional
>    response, the client should remove any partially received body
> held
>    for a previous ETag for that resource as it is unlikely the
> missing
>    blocks can be retrieved.
> 
> (1) Is (a) suggesting that the missing block requests would be
> serviced from a copy of the “resource data that has changed”?  This
> would mean that the client would get an inconsistent version of the
> resource which is neither the old or new version.

[Med] The client will detect that as per the text right after the one you quoted: 

   If the server responds during a body update with a different ETag
                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   Option value (as the resource representation has changed), then the
   client should treat the partial body with the old ETag as no longer
                                                 ^^^^^^^^^^^^^^^^^^^^^^            
   being fresh.
   ^^^^^^^^^^^^  

The client can then get the new version. It can't get the old one as the server does not cache it. 

> 
> (2) (b) seems like it is noting that the partially received body
> should in fact be discarded to avoid the situation in (1).  However,
> how does the client get the initial, now discarded blocks?  I’m not
> sure where that transmission shouldn’t fail with an error as I don’t
> follow how recover is possible.
> 

[Med] This is not an error given that the client is getting the new resource representation as maintained by the server. The old one is obsolete if you will. 


_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles 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 electroniques 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 information 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 delete 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.