IETF Logo Mail Archive

Re: [netconf] last-modified timestamp format (draft-lindblad-netconf-transaction-id)

Kent Watsen <kent@watsen.net> Tue, 02 August 2022 15:24 UTC

Return-Path: <010001825f284856-b6afa4ca-6214-4960-a5f7-122a418afaff-000000@amazonses.watsen.net>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A6F1C15C52E for <netconf@ietfa.amsl.com>; Tue, 2 Aug 2022 08:24:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kuUfxVp2M5Yh for <netconf@ietfa.amsl.com>; Tue, 2 Aug 2022 08:24:13 -0700 (PDT)
Received: from a48-90.smtp-out.amazonses.com (a48-90.smtp-out.amazonses.com [54.240.48.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0091AC0D2F7C for <netconf@ietf.org>; Tue, 2 Aug 2022 08:24:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1659453852; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=twYHIhyyZmWLoT3+ZESwSnQCclIa1O2B0oZPOwpxxlo=; b=W93jeQVfNdEZzlwxA/S0DdoQN75ivXVgjIIt1hmm9N21Ssl6CDl2RnzHubXqFeVx 1/SmPjwxZtwagqz2JCzMsZDyuwrUWyuDjntwE48x0euhN3S+izPBODjhXk6fyShZ2Wu y0X+cZFTMSWnjx/dz3c9AsCQTKA4fNS4tifuqis4=
From: Kent Watsen <kent@watsen.net>
Message-ID: <010001825f284856-b6afa4ca-6214-4960-a5f7-122a418afaff-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_B460F10D-7B7E-4D5E-95E6-CA3027F2F181"
Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\))
Date: Tue, 02 Aug 2022 15:24:11 +0000
In-Reply-To: <26ef60f392d74accac61c6b935cc2066@huawei.com>
Cc: "netconf@ietf.org" <netconf@ietf.org>
To: "maqiufang (A)" <maqiufang1=40huawei.com@dmarc.ietf.org>
References: <26ef60f392d74accac61c6b935cc2066@huawei.com>
X-Mailer: Apple Mail (2.3693.60.0.1.1)
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
X-SES-Outgoing: 2022.08.02-54.240.48.90
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/3Xt1EfrSeYSoDBZo4Rn8iH2tt0Q>
Subject: Re: [netconf] last-modified timestamp format (draft-lindblad-netconf-transaction-id)
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Aug 2022 15:24:14 -0000

Agreed.  Second-level granularity seems adequate in light of ETag being always present.

BTW, RFC 7232 says:

   A recipient MUST ignore If-Modified-Since if the request contains an
   If-None-Match header field; the condition in If-None-Match is
   considered to be a more accurate replacement for the condition in
   If-Modified-Since, and the two are only combined for the sake of
   interoperating with older intermediaries that might not implement
   If-None-Match.

   A recipient MUST ignore If-Unmodified-Since if the request contains
   an If-Match header field; the condition in If-Match is considered to
   be a more accurate replacement for the condition in
   If-Unmodified-Since, and the two are only combined for the sake of
   interoperating with older intermediaries that might not implement
   If-Match.

Generic clients will always send Etag because they cannot assume the servers support Last-Modfied.

That said, I strongly feel that servers SHOULD always send Last-Modified, even if knowing that clients will never send requests conditional on time, because it helps client better reason about the data internally.

Kent


> On Jul 26, 2022, at 8:15 AM, maqiufang (A) <maqiufang1=40huawei.com@dmarc.ietf.org> wrote:
> 
> Hi, all
>  
> Regarding yesterday’s transaction-ID presentation, there were some discussion about the “last-modified” timestamp resolution for NETCONF protocol.
>  
> Since RFC8040 says “the server MUST maintain a unique opaque entity-tag for the datastore resource” and “the server SHOULD maintain a last-modified timestamp for the datastore resource”, does this mean that a last-modified timestamp(if present) must always co-exist with etag at the same time? Is this also the case for NETCONF protocol? I think so since a server MUST maintain a mandatory-to-implement etag value for a configuration datasore.
> Then I am thinking that maybe a second-level timestamp resolution doesn’t hurt, since a client can always have a double check of the etag value, which works as a supplement to last-modified timestamp in this case.
>  
>  
> Best Regards,
> Qiufang
>  
>  
> _______________________________________________
> netconf mailing list
> netconf@ietf.org <mailto:netconf@ietf.org>
> https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>

v2.23.0 | Report a Bug | By Email