[netconf] last-modified timestamp format (draft-lindblad-netconf-transaction-id)
"maqiufang (A)" <maqiufang1@huawei.com> Tue, 26 July 2022 12:15 UTC
Return-Path: <maqiufang1@huawei.com>
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 C1988C1BED09 for <netconf@ietfa.amsl.com>; Tue, 26 Jul 2022 05:15:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level:
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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] autolearn=ham autolearn_force=no
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 suWr4y5oBVKu for <netconf@ietfa.amsl.com>; Tue, 26 Jul 2022 05:15:21 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53D28C1BED06 for <netconf@ietf.org>; Tue, 26 Jul 2022 05:15:21 -0700 (PDT)
Received: from fraeml734-chm.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4LsbMx2PcZz6823d for <netconf@ietf.org>; Tue, 26 Jul 2022 20:10:37 +0800 (CST)
Received: from kwepemm600018.china.huawei.com (7.193.23.140) by fraeml734-chm.china.huawei.com (10.206.15.215) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Tue, 26 Jul 2022 14:15:18 +0200
Received: from kwepemm600017.china.huawei.com (7.193.23.234) by kwepemm600018.china.huawei.com (7.193.23.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Tue, 26 Jul 2022 20:15:16 +0800
Received: from kwepemm600017.china.huawei.com ([7.193.23.234]) by kwepemm600017.china.huawei.com ([7.193.23.234]) with mapi id 15.01.2375.024; Tue, 26 Jul 2022 20:15:16 +0800
From: "maqiufang (A)" <maqiufang1@huawei.com>
To: "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: [netconf] last-modified timestamp format (draft-lindblad-netconf-transaction-id)
Thread-Index: Adig6QULEkepyrqTSsSxabh0jmXtvw==
Date: Tue, 26 Jul 2022 12:15:16 +0000
Message-ID: <26ef60f392d74accac61c6b935cc2066@huawei.com>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.136.100.87]
Content-Type: multipart/alternative; boundary="_000_26ef60f392d74accac61c6b935cc2066huaweicom_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/FZIYGe1_FpOBqZguE9Of_-mzET8>
Subject: [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, 26 Jul 2022 12:15:25 -0000
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] last-modified timestamp format (draft-l… maqiufang (A)
- Re: [netconf] last-modified timestamp format (dra… Kent Watsen