Re: [netmod] Instance-data-format - shall we define etag and last-modified annotation ?

Balázs Lengyel <balazs.lengyel@ericsson.com> Wed, 24 July 2019 02:57 UTC

Return-Path: <balazs.lengyel@ericsson.com>
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 14AD11200B6 for <netmod@ietfa.amsl.com>; Tue, 23 Jul 2019 19:57:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
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 HOzLSs8K275f for <netmod@ietfa.amsl.com>; Tue, 23 Jul 2019 19:57:51 -0700 (PDT)
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10076.outbound.protection.outlook.com [40.107.1.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C047120046 for <netmod@ietf.org>; Tue, 23 Jul 2019 19:57:50 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Uc6+qMK9zOQe+ZVEmwY2xDZQ8709huLwclXkb3PMVpwh6bb5EPGTTsJdxBEdK8ptdQhRHox4rvdxitZkcS2ulOmUYmcX/X82w3QeSDYYRWP08FP/eEd4wq/8aMwFhP1GFmYXV3t+d+iUa7jfSucejqp01WXkUYx29OP7qLxVEKMd6C9LyCEgs4FnII1/JFHYesuWIcP5MRcEG6jAxGw4HaFtoz6tV5auxOeBLmQQn5ZloK5gKQ1L1QznTqjn9nf00mHwC8h8UhqxuuRmlVMTAynzfPN3HZZK9HZNcji/VVHjQhzFGPnTqVMGUNjX82t5LXIzMUHA5hJJulasbL7uXQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aD/7R/Ju9NKIgguWT/dG8fKq84RSrJNMkzPzVlN8RtY=; b=jH39vr+arfsj2xdZ6Ugw3IaWJzsJSDhIe897qMZcgEIgqyKLuBJl4hCS8PFwiCdgEo1ICZzeWovwXGV73gKIAaNHb86uXHkczQhdtIPjgRvYGuq6JlReM3w6ZVz76ajILDh3fPizFlz0lQIvi2G3YfaKy7DwCQRSAlspEi4KFW6gOS2+mFNQxvTh6DyfJUcFsRnv1R8tvVCKarVUMVfFiS5FXwyVf4dHR34VKBU0Cpy7XzND9FWLVrgbB+6D6I5Ur7BFBxzS9sRRQCpNDuTG1V/Wv8BFcy0G7wcYvk+JRuT3U8J+xH9E981zUzJlMTJPo9ekVX4dZfQOG9kDfv/jag==
ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=ericsson.com;dmarc=pass action=none header.from=ericsson.com;dkim=pass header.d=ericsson.com;arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aD/7R/Ju9NKIgguWT/dG8fKq84RSrJNMkzPzVlN8RtY=; b=pog4lpmck/Wr0hQpxWzI4GxAd7kxP8XI687qyDUPjbfQRu7ffx6btZxvdVAJpwiLtx+b6vEJYh/vuuJ7obj+BzpRrKKPklD3QJk5JKGwSwiB+PNJYcQDydytKM2ZULrH4B0xM5SSiyF2Zt0QxZ6bt27Ewsp908doWeU0AVAVKX0=
Received: from VI1PR0701MB2286.eurprd07.prod.outlook.com (10.169.137.153) by VI1PR0701MB2784.eurprd07.prod.outlook.com (10.173.84.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2115.10; Wed, 24 Jul 2019 02:57:47 +0000
Received: from VI1PR0701MB2286.eurprd07.prod.outlook.com ([fe80::5556:4c20:cd8d:686a]) by VI1PR0701MB2286.eurprd07.prod.outlook.com ([fe80::5556:4c20:cd8d:686a%11]) with mapi id 15.20.2115.005; Wed, 24 Jul 2019 02:57:47 +0000
From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= <balazs.lengyel@ericsson.com>
To: "Joe Clarke (jclarke)" <jclarke@cisco.com>, "Rob Wilton (rwilton)" <rwilton@cisco.com>
CC: Andy Bierman <andy@yumaworks.com>, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [netmod] Instance-data-format - shall we define etag and last-modified annotation ?
Thread-Index: AdVAwv3YCGqZ1KMoT7S8jMt8r0MeZgAByuUAACWODXAAAHr3AAACm5IAAAIGGnAACz2xMAAAPZMAAAnVd0A=
Date: Wed, 24 Jul 2019 02:57:46 +0000
Message-ID: <VI1PR0701MB2286C24E8B4BA8A19DBA2428F0C60@VI1PR0701MB2286.eurprd07.prod.outlook.com>
References: <VI1PR0701MB2286D806027F541651B0BCE6F0C40@VI1PR0701MB2286.eurprd07.prod.outlook.com> <20190722201510.mom7xg2mdi2ulbby@anna.jacobs.jacobs-university.de> <VI1PR0701MB2286001A8E05E099C066BF61F0C70@VI1PR0701MB2286.eurprd07.prod.outlook.com> <20190723142414.4sc5o2j6dawblwrm@anna.jacobs.jacobs-university.de> <CABCOCHQrAQaK2XEfnC9EPwhsu4+Qe=tPyLe-bT9=7x9t1LN3BQ@mail.gmail.com> <VI1PR0701MB22861EC59BE79943C7E833F4F0C70@VI1PR0701MB2286.eurprd07.prod.outlook.com> <BYAPR11MB26314E4A3754A9B5D6EC9CDAB5C70@BYAPR11MB2631.namprd11.prod.outlook.com> <F88AE433-1864-4C50-8156-7ADD8D2F6D2B@cisco.com>
In-Reply-To: <F88AE433-1864-4C50-8156-7ADD8D2F6D2B@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com;
x-originating-ip: [2001:67c:1232:144:9d0e:22e7:fee3:9117]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: c9eb2da3-8efa-4b40-2f39-08d70fe2b525
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(49563074)(7193020); SRVR:VI1PR0701MB2784;
x-ms-traffictypediagnostic: VI1PR0701MB2784:
x-microsoft-antispam-prvs: <VI1PR0701MB278486524ABE561D06A2F940F0C60@VI1PR0701MB2784.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0108A997B2
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(366004)(376002)(136003)(396003)(346002)(13464003)(189003)(199004)(229853002)(11346002)(966005)(86362001)(316002)(6506007)(606006)(8676002)(85202003)(5660300002)(6116002)(14454004)(52536014)(55016002)(110136005)(54896002)(6306002)(25786009)(446003)(486006)(6436002)(14444005)(99286004)(236005)(9686003)(74316002)(54906003)(476003)(33656002)(7736002)(68736007)(71200400001)(4326008)(66446008)(99936001)(64756008)(53936002)(66616009)(76116006)(81166006)(66556008)(66476007)(6246003)(81156014)(85182001)(76176011)(256004)(2906002)(8936002)(102836004)(186003)(46003)(478600001)(7696005)(66574012)(790700001)(66946007)(71190400001)(53546011)(369524004); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0701MB2784; H:VI1PR0701MB2286.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: bex0L2f8uPqy5t6k/zB6JT+L4neB9UDaFFF4zTzyNA5OVpA1tZ2NF4plNHjf/YRMDGl/6I9qBUFFdQBVD3CFvQ7Y3WKzv1S0OPNraOfdQRKQZVg3YOnYfqRRlJJ5z14GgxhX7IdqeXxM4Hdt05nEXwtTEmfOA+aF84Swf52Pvcs2PvzXxnLx+dUHY21XBqepqvy1o4posoF39F9paAbhMAlLVqDfjy7fql1H7kZzCecoKasKFVObMbAHjm8BXdHqoN60GNhpTvDvVrTZM4yZmb3nJo/cZ3xVpmakgdK3DcXsfFaH1jXq6pCxER7zt6e5gs5cW/NAqS/ZP1C2k3B+34G9+eS29VtkBZ3Yw+yLvUPira491bpLDrT/d4ALVAc74iFdoNHfCOouI6Us3C3mOoEeuFFveKyUsI3+qMGvQHk=
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0434_01D541AA.08E29350"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: c9eb2da3-8efa-4b40-2f39-08d70fe2b525
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jul 2019 02:57:47.0054 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: balazs.lengyel@ericsson.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB2784
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/ee4xrNCfybFTebkfnRe4SNz4_-4>
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: Wed, 24 Jul 2019 02:57:56 -0000

The instance-data-set’s timestamp is about the time the config dump is taken.

If the last modification happened 7 days before the dump, then the last-modified metadata and the instance-data-set’s timestamp will have a week difference.

Also the last-modified metadata can be different for different parts of the configuration.

Regards Balazs

 

From: Joe Clarke (jclarke) <jclarke@cisco.com>; 
Sent: 2019. július 23., kedd 18:06
To: Rob Wilton (rwilton) <rwilton@cisco.com>;
Cc: Balázs Lengyel <balazs.lengyel@ericsson.com>;; Andy Bierman <andy@yumaworks.com>;; Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>;; netmod@ietf.org
Subject: Re: [netmod] Instance-data-format - shall we define etag and last-modified annotation ?

 

 





On Jul 23, 2019, at 18:01, Rob Wilton (rwilton) <rwilton@cisco.com <mailto:rwilton@cisco.com> > wrote:

 

If you want to dump the configuration on the device to a file for some offline analysis, then it might be useful if it is possible for that file to have the timestamps of when the configuration changed annotated into the file.

 

Isn’t that the purpose of the “timestamp" metadata leaf in instance-data?  That is the timestamp of the ID set itself.

 

Joe





 

I don’t think that this is critical, but I can see that it might be useful.

 

Thanks,

Rob

 

 

From: netmod < <mailto:netmod-bounces@ietf.org> netmod-bounces@ietf.org>; On Behalf Of Balázs Lengyel
Sent: 23 July 2019 13:09
To: Andy Bierman < <mailto:andy@yumaworks.com> andy@yumaworks.com>;; Juergen Schoenwaelder < <mailto:j.schoenwaelder@jacobs-university.de> j.schoenwaelder@jacobs-university.de>;;  <mailto:netmod@ietf.org> netmod@ietf.org
Subject: Re: [netmod] Instance-data-format - shall we define etag and last-modified annotation ?

 

Hello,

As Jurgen, Andy, Lada and Joe is opposed to defining the annotations in the instance model draft, and I don’t see it as crucial, I will take it out.

IMHO it is a useful bit of functionality for configuration data based use-cases, and I very much fear it will not happen at all now; unless people speak up it is removed.

Regards  Balazs

 

From: Andy Bierman < <mailto:andy@yumaworks.com> andy@yumaworks.com>; 
Sent: 2019. július 23., kedd 11:39
To: Juergen Schoenwaelder < <mailto:j.schoenwaelder@jacobs-university.de> j.schoenwaelder@jacobs-university.de>;; Balázs Lengyel < <mailto:balazs.lengyel@ericsson.com> balazs.lengyel@ericsson.com>;;  <mailto:netmod@ietf.org> netmod@ietf.org
Subject: Re: [netmod] Instance-data-format - shall we define etag and last-modified annotation ?

 

 

 

On Tue, Jul 23, 2019 at 7:24 AM Juergen Schoenwaelder < <mailto:j.schoenwaelder@jacobs-university.de> j.schoenwaelder@jacobs-university.de>; wrote:

Balázs,

I am not sure these belongs to the data types collection. If these
annotations are a per datastore properties or per configuration
datastore properties (I am not sure these properties make a lot of
sense for dynamically changing data in <operational>, or these
properties only make sense for config true nodes, more discussion
needed I guess), then the logical place would be to define them would
be where the datastores are defined.

I understand the timing concern but my preference is to workout what
these annotations really are in an NMDA world and in a second step to
figure out a way to define them in a reasonable amount of time.

 

This work needs a lot more thought because this WG is sort of abusing these fields,

intended for HTTP caching. The values are associated with a representation of a response

to a request for some portion of the datastore contents.  E.g., a representation in XML must be a different

ETag than a JSON representation (of the exact same datastore contents).

 

I suggest new meta-data be defined that has semantics specific to datastore contents, not

the HTTP representation of the response.

 

IMO this meta-data is not really needed inside an instance file, but if included, then the values

should be associated with the representation (the instance file) and not the datastores.

 

 

/js

 

 

Andy

 


On Tue, Jul 23, 2019 at 02:11:23PM +0000, Balázs Lengyel wrote:
> Hello Jürgen,
> Could the etag and last-modified annotations be moved to 6991bis?
> Regards Balazs
> 
> -----Original Message-----
> From: Juergen Schoenwaelder < <mailto:j.schoenwaelder@jacobs-university.de> j.schoenwaelder@jacobs-university.de>; 
> Sent: 2019. július 22., hétfő 16:15
> To: Balázs Lengyel < <mailto:balazs.lengyel@ericsson.com> balazs.lengyel@ericsson.com>;
> Cc:  <mailto:netmod@ietf.org> netmod@ietf.org
> Subject: Re: [netmod] Instance-data-format - shall we define etag and
> last-modified annotation ?
> 
> 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> 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/> https://www.jacobs-university.de/>



-- 
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/> https://www.jacobs-university.de/>

_______________________________________________
netmod mailing list
 <mailto:netmod@ietf.org> netmod@ietf.org
 <https://www.ietf.org/mailman/listinfo/netmod> https://www.ietf.org/mailman/listinfo/netmod

_______________________________________________
netmod mailing list
 <mailto:netmod@ietf.org> netmod@ietf.org
 <https://www.ietf.org/mailman/listinfo/netmod> https://www.ietf.org/mailman/listinfo/netmod