Re: [netmod] Instance-data-format - shall we define etag and last-modified annotation ?
Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Mon, 22 July 2019 20:15 UTC
Return-Path: <j.schoenwaelder@jacobs-university.de>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2625B1200DE for <netmod@ietfa.amsl.com>; Mon, 22 Jul 2019 13:15:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 44093bmPXRz8 for <netmod@ietfa.amsl.com>; Mon, 22 Jul 2019 13:15:14 -0700 (PDT)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A43BC12008F for <netmod@ietf.org>; Mon, 22 Jul 2019 13:15:13 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 62F8986D; Mon, 22 Jul 2019 22:15:12 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.198]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id XLbBW2wUdn1D; Mon, 22 Jul 2019 22:15:12 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Mon, 22 Jul 2019 22:15:12 +0200 (CEST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1CD492012C; Mon, 22 Jul 2019 22:15:12 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10028) with ESMTP id xmZV3swC-IMC; Mon, 22 Jul 2019 22:15:11 +0200 (CEST)
Received: from exchange.jacobs-university.de (sxchmb03.jacobs.jacobs-university.de [10.70.0.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "exchange.jacobs-university.de", Issuer "DFN-Verein Global Issuing CA" (verified OK)) by hermes.jacobs-university.de (Postfix) with ESMTPS id B88D020129; Mon, 22 Jul 2019 22:15:11 +0200 (CEST)
Received: from anna.localdomain (10.50.218.117) by sxchmb03.jacobs.jacobs-university.de (10.70.0.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1713.5; Mon, 22 Jul 2019 22:15:11 +0200
Received: by anna.localdomain (Postfix, from userid 501) id D686D2DC918; Mon, 22 Jul 2019 22:15:10 +0200 (CEST)
Date: Mon, 22 Jul 2019 22:15:10 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Balázs Lengyel <balazs.lengyel@ericsson.com>
CC: "netmod@ietf.org" <netmod@ietf.org>
Message-ID: <20190722201510.mom7xg2mdi2ulbby@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: Balázs Lengyel <balazs.lengyel@ericsson.com>, "netmod@ietf.org" <netmod@ietf.org>
References: <VI1PR0701MB2286D806027F541651B0BCE6F0C40@VI1PR0701MB2286.eurprd07.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
In-Reply-To: <VI1PR0701MB2286D806027F541651B0BCE6F0C40@VI1PR0701MB2286.eurprd07.prod.outlook.com>
User-Agent: NeoMutt/20180716
X-ClientProxiedBy: SXCHMB02.jacobs.jacobs-university.de (10.70.0.121) To sxchmb03.jacobs.jacobs-university.de (10.70.0.155)
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/NxRpG8BtVlJj2e5pkYMQlTcUnqo>
Subject: Re: [netmod] Instance-data-format - shall we define etag and last-modified annotation ?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Jul 2019 20:15:16 -0000
On Mon, Jul 22, 2019 at 07:23:59PM +0000, Balázs Lengyel wrote: > Hello, > > Restconf (rfc8040) defined to useful bits of metadata about a YANG defined > datastore: entity-tag and the last-modified timestamp. > > These can be very useful in instance data sets, however Restconf defines an > encoding for these (as part of the http headers) that can not be used in > instance-data-sets. This may actually point out a flaw or omission of RFC 8527. RFC 8040 defines an entity-tag for its "unified" datastore and it says "if the RESTCONF server is co-located with a NETCONF server, then this entity-tag MUST be for the "running" datastore". So it is a bit unclear what happens with other NMDA datastores and I did not quickly find something in RFC 8527. (For example, can have a distinct etag for <startup/>? > draft-ietf-netmod-yang-instance-file-format-03#section-7.2 > <https://tools.ietf.org/html/draft-ietf-netmod-yang-instance-file-format-03# > section-7.2> defines metadata annotations for these two, that can be > used in instance data > > md:annotation entity-tag { > type string; > description "Used to encode the entity-tag "; > } > md:annotation last-modified { > type yang:date-and-time; > description "Contains the date and time when the annotated > instance was last modified (or created)."; > } > > In order to be able to include this data, the annotations need to be defined > in some YANG module. > > The question has been raised whether > > 1. these annotations should be defined in the ietf-yang-instance-data > module as it needs them, as that is open or > 2. the annotations should be defined in another draft in a separate > YANG module as any other annotation > > The first option is better because the instance-data needs these > annotations, and at this point we see no other user for the annotation, and > in this case the ongoing instance data draft will define it > > The second option is better because, if later there are other users for > these annotations, it might be strange to reference the > ietf-yang-instance-data module. Also why provide special treatment to these > 2 annotations? > > The authors support option 1 and dont have the time to start a new draft to > define these annotations. > > On IETF105 in the room there was more support for option 1. > > Please indicate if you have an opinion about the choice of 1 or 2 Version -03 only defines these annotations but does not do anything specific with these definitions. So if the annotations are defined elsewhere, the ID is as complete as before. If entity-tag and last-modified are actually seen as datastore properties, it would be nice to have them defined in the NMDA documents (and it seems we overlooked this when we did the NMDA work). I think this needs a bit of discussion whether these are actually seen as datastore properties. But in this case, I would lean towards option 2. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://www.jacobs-university.de/>
- [netmod] Instance-data-format - shall we define e… Balázs Lengyel
- Re: [netmod] Instance-data-format - shall we defi… Juergen Schoenwaelder
- Re: [netmod] Instance-data-format - shall we defi… Balázs Lengyel
- Re: [netmod] Instance-data-format - shall we defi… Juergen Schoenwaelder
- Re: [netmod] Instance-data-format - shall we defi… Andy Bierman
- Re: [netmod] Instance-data-format - shall we defi… Kent Watsen
- Re: [netmod] Instance-data-format - shall we defi… Balázs Lengyel
- Re: [netmod] Instance-data-format - shall we defi… Rob Wilton (rwilton)
- Re: [netmod] Instance-data-format - shall we defi… Joe Clarke (jclarke)
- Re: [netmod] Instance-data-format - shall we defi… Rob Wilton (rwilton)
- Re: [netmod] Instance-data-format - shall we defi… Balázs Lengyel