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

Roman Danyliw <rdd@cert.org> Thu, 06 May 2021 13:47 UTC

Return-Path: <rdd@cert.org>
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 C9AFC3A22DD; Thu, 6 May 2021 06:47:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org
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 4khBde9miGnh; Thu, 6 May 2021 06:47:31 -0700 (PDT)
Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (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 8A9513A22DA; Thu, 6 May 2021 06:47:31 -0700 (PDT)
Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 146DlTYv020653; Thu, 6 May 2021 09:47:29 -0400
DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu 146DlTYv020653
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1620308849; bh=DR3wT5mcIksmnOE8lDUnfPOpqTwXwNMIkVI4rwlG/pM=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=XglnhTBZlgJwqMZq7HRUQDVAI3kr0jQf6l0iRr7u1J/ukzrhe41OLNXdRNS8Ibp8B Kf9XCkGVpaArKWMHJDplxKj47J1qOH851EEpzaKsCzc8g4aBpfnT7q8UHF6r49q2Ic HoazG/e/4+qiizZHHIpeF8mAwMm6mUTCocUnS+dc=
Received: from MURIEL.ad.sei.cmu.edu (muriel.ad.sei.cmu.edu [147.72.252.47]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 146DlS0t028197; Thu, 6 May 2021 09:47:28 -0400
Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MURIEL.ad.sei.cmu.edu (147.72.252.47) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2242.4; Thu, 6 May 2021 09:47:28 -0400
Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%21]) with mapi id 15.01.2242.008; Thu, 6 May 2021 09:47:28 -0400
From: Roman Danyliw <rdd@cert.org>
To: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, 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: AQHXQeNgQirCS7pC+k22RIReFtLSb6rWPO8AgAA7e+A=
Date: Thu, 06 May 2021 13:47:27 +0000
Message-ID: <1ca5bb75f8764f6cbbca99d9ed0c1213@cert.org>
References: <162024227267.18682.9364450117778772479@ietfa.amsl.com> <2142_1620281565_609388DD_2142_32_1_787AE7BB302AE849A7480A190F8B9330353776FE@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
In-Reply-To: <2142_1620281565_609388DD_2142_32_1_787AE7BB302AE849A7480A190F8B9330353776FE@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.64.201.86]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/c7wnisqdRdm4GpBIKUJ3dFk6bcE>
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 13:47:37 -0000

Hi Med!

> -----Original Message-----
> From: iesg <iesg-bounces@ietf.org> On Behalf Of
> mohamed.boucadair@orange.com
> Sent: Thursday, May 6, 2021 2:13 AM
> To: Roman Danyliw <rdd@cert.org>; The IESG <iesg@ietf.org>
> Cc: draft-ietf-core-new-block@ietf.org; core-chairs@ietf.org; core@ietf.org;
> marco.tiloca@ri.se
> Subject: RE: Roman Danyliw's No Objection on draft-ietf-core-new-block-11:
> (with COMMENT)
> 
> 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".

Thanks for these changes.

> > ** 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.

Got it.  Thanks for explaining it.

Roman

> 
> ___________________________________________________________________
> ______________________________________________________
> 
> 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.