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

Balázs Lengyel <balazs.lengyel@ericsson.com> Tue, 23 July 2019 17:08 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 09FFC12041F for <netmod@ietfa.amsl.com>; Tue, 23 Jul 2019 10:08:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, URIBL_BLOCKED=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 toTE1J8r7w1R for <netmod@ietfa.amsl.com>; Tue, 23 Jul 2019 10:08:41 -0700 (PDT)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130078.outbound.protection.outlook.com [40.107.13.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C323120437 for <netmod@ietf.org>; Tue, 23 Jul 2019 10:08:40 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=j31ZwgNOhEJIiv1kehZHmeGt0hDdf4Ck2spJz6md6ZvlBK52A6e3l46CGnT3YVrYGxgEF/YioJgbDZ3lUdjiygO70WAHepw32b6rvFk21KP4bQp0GerXjQpow22pCq5iuruGsByf7FnLdc9JzMQLcNYqK1gsWRviMf7PwXz8AcJGEMR6KVKKJhRFHf1SrAuT55iowjvQHy8EOwWQ1fBGjOg4E3fdUGKLYaV3XN+upQ9xzMu8cnLFyeOArG+y5jMNV86ETa1e24czydCHnk+ietc/XPxjml0Mg0GhcMyekw1fmpPrXNyXUQtKzGTek/MGl5EhYJnSgcsCAXzcW6fBWw==
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=CNQSfpiQga4aQZMjhLFiOSD9OOWB5bbQryFh4DoKlXU=; b=CwtLtvgtCVJJZ+honrJgi1j18zWiCkHfSqq9iXy45NDyo49Pmnlwg4a+Gj0h28hu0TzeQOcbn+fi/oZNeeDF7K5NjnunvBvLJhhx97/8hqBLWUq7dPqp3I2480nYxcX+6Sc3rsn8D08WuEx+1Z5ARnDs4tvPySba/dOBvXxYZU1GlCJo2noZDM2ZgjVtSRvAUpjMb4HDgjmEu0d2YW5VrjEow/Awm8PeapQW/aPg5GWFm7JFZLELtURgqs6TD19T7nVOM9CcRP26kB8BDKwXpFE41H4+F3P3MnzNfJ/ifV9fRDnKRrwEZQf/QyHO7KaLhsem8M9CxLdST8X/T28Rvw==
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=CNQSfpiQga4aQZMjhLFiOSD9OOWB5bbQryFh4DoKlXU=; b=Gd42GSsyVgE6QOw4qeB8vZ3ptbbE1jBIO3JTT+Qyk9GqxmNmiObG43qx6ld9zEBOx4golXZHNg9J+TQtrmUkR0qAr+KKjQUQm51OQc2ENLGoBEsQouGGASPQc+f6i3f2SA5/h1xUTjxPFQ2cH4oZmBLL/hWsPy0T3hSB1T/s2F4=
Received: from VI1PR0701MB2286.eurprd07.prod.outlook.com (10.169.137.153) by VI1PR0701MB2877.eurprd07.prod.outlook.com (10.173.72.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2115.10; Tue, 23 Jul 2019 17:08:36 +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; Tue, 23 Jul 2019 17:08:36 +0000
From: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= <balazs.lengyel@ericsson.com>
To: 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: AdVAwv3YCGqZ1KMoT7S8jMt8r0MeZgAByuUAACWODXAAAHr3AAACm5IAAAIGGnA=
Date: Tue, 23 Jul 2019 17:08:36 +0000
Message-ID: <VI1PR0701MB22861EC59BE79943C7E833F4F0C70@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>
In-Reply-To: <CABCOCHQrAQaK2XEfnC9EPwhsu4+Qe=tPyLe-bT9=7x9t1LN3BQ@mail.gmail.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:9062:8680:a1b2:fc75]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 8828fb35-e9d9-41cd-4c60-08d70f9066b6
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:VI1PR0701MB2877;
x-ms-traffictypediagnostic: VI1PR0701MB2877:
x-microsoft-antispam-prvs: <VI1PR0701MB28774669E145FC67E340AC9CF0C70@VI1PR0701MB2877.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:7691;
x-forefront-prvs: 0107098B6C
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(136003)(366004)(39860400002)(376002)(396003)(199004)(189003)(13464003)(66616009)(99286004)(33656002)(66446008)(66946007)(14444005)(76116006)(85202003)(66556008)(256004)(71190400001)(316002)(64756008)(606006)(66476007)(66574012)(2906002)(9326002)(6116002)(102836004)(486006)(99936001)(790700001)(71200400001)(110136005)(81166006)(81156014)(478600001)(52536014)(54896002)(25786009)(9686003)(7736002)(53546011)(966005)(186003)(8676002)(2501003)(5660300002)(11346002)(6246003)(476003)(53936002)(46003)(86362001)(446003)(68736007)(85182001)(14454004)(6506007)(76176011)(236005)(6306002)(74316002)(229853002)(6436002)(7696005)(8936002)(55016002)(369524004); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0701MB2877; H:VI1PR0701MB2286.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX: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: wyfDWq8AISyeBpvLClAUz6gz/kjG78/UqjSAZ2OTVRzaZ0eieCDiHh2Lx0S/lwvvkCcNvizGxJFtxzcAUUCpHswFiCmDIzLZ52tVCZSarTlOJPTvhNMM/eocDw6u+eFlR+NxBeItsRrtyYqBD4vio9J0gepJAqG6IuA4TC/fei93Vy9kb+WxyG/8WgFaJ0+pZ+mEGV6IlkRiKp0v6wqqpN4e1OvPyWG369V0KRqcwyFcTOIoZhkXfzbtFrKUYehylWOhGcdixkSUdT0TqZ1ob+xkfjcGCCfBBd9tIZRt5ix/c0NN2SqsxOM4Hkd3ugIsCR6AKmdSUX8hnJ1SS/rjM5CMX95E+QAMhm4u2B0lzXaSWwaeW4DL72/lgFxCSqpDj1AsWJoXZrUMQRxnSWfsdjk+knkfkmG/NxsyyF5Z7cw=
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_02DB_01D54154.D18F5EB0"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 8828fb35-e9d9-41cd-4c60-08d70f9066b6
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jul 2019 17:08:36.7515 (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: VI1PR0701MB2877
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/Uf9grHqyprdKzgYkzed5YmfpF3c>
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: Tue, 23 Jul 2019 17:08:44 -0000

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 <andy@yumaworks.com>; 
Sent: 2019. július 23., kedd 11:39
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>;; Balázs Lengyel <balazs.lengyel@ericsson.com>;; 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 <j.schoenwaelder@jacobs-university.de <mailto: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 <j.schoenwaelder@jacobs-university.de>; 
> Sent: 2019. július 22., hétfő 16:15
> To: Balázs Lengyel <balazs.lengyel@ericsson.com <mailto:balazs.lengyel@ericsson.com> >
> Cc: netmod@ietf.org <mailto: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/>



-- 
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 mailing list
netmod@ietf.org <mailto:netmod@ietf.org> 
https://www.ietf.org/mailman/listinfo/netmod