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: =?utf-8?Q?Bal=C3=A1zs?= 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: =?utf-8?Q?Bal=C3=A1zs?= 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 don’t 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/>