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

"Rob Wilton (rwilton)" <rwilton@cisco.com> Tue, 23 July 2019 22:01 UTC

Return-Path: <rwilton@cisco.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 3891F1209D4 for <netmod@ietfa.amsl.com>; Tue, 23 Jul 2019 15:01:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level:
X-Spam-Status: No, score=-14.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=B5ADUSFO; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=QGlxGtWA
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 t8nfNsrPxTdb for <netmod@ietfa.amsl.com>; Tue, 23 Jul 2019 15:01:50 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6191A120996 for <netmod@ietf.org>; Tue, 23 Jul 2019 15:01:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=32280; q=dns/txt; s=iport; t=1563919310; x=1565128910; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=4K1bpp8dlWE5TVwmW2ozbWH7zHjDX1T2Nql4Z78LNmM=; b=B5ADUSFOnqNfacnia6mPpudtZDj7TCgSU3l/wByf7Eikt8ocOKwpXrSG WWAvQaylroRl0yrolzgFOMD+FjLFkvpxmRhpRPaa1R65jfMkas397oGAj 4f6CgVTuvpcOL1QwAWsNRCD8x91Whzwe8zxPaoNPO+FxK5hIFwnWCyznd g=;
IronPort-PHdr: =?us-ascii?q?9a23=3AgTbvfhVqz8mU0dYjsECGEBLNLNzV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSA92J8OpK3uzRta2oGXcN55qMqjgjSNRNTF?= =?us-ascii?q?dE7KdehAk8GIiAAEz/IuTtankgA8VGSFhj13q6KkNSXs35Yg6arw=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAAB1gzdd/40NJK1jAxoBAQEBAQI?= =?us-ascii?q?BAQEBBwIBAQEBgVUDAQEBAQsBgRQvJCwDbVUgBAsqhB2DRwONf0yCD5dQgS4?= =?us-ascii?q?UgRADVAkBAQEMAQEYAQwIAgEBg3pGAheCNyM2Bw4BAwEBBAEBAgEGbYUeDIV?= =?us-ascii?q?KAQEBAQIBAQEQEQoTAQEsDAQHAgICAQgQAQQBAQEgBwMCAgIZDAsUCQgCBAE?= =?us-ascii?q?SCBqDAYEdTQMODwECDJ92AoE4iGBxgTKCeQEBBYE2AoNRGIITAwYFgS8BhHG?= =?us-ascii?q?GbReBQD+BEUaCTD6CYQEBA4FGAhgVCgwJEYJEMoImgWKKTQWCRIR+lnEJAoI?= =?us-ascii?q?ZhXlfhG6IYYIthyWOOIQRhXmDK4dIkAgCBAIEBQIOAQEFgVYBMYFYcBU7gmy?= =?us-ascii?q?CQgwXFIM6M4RhhT9ygSmOJAEB?=
X-IronPort-AV: E=Sophos;i="5.64,300,1559520000"; d="scan'208,217";a="297118303"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 23 Jul 2019 22:01:49 +0000
Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id x6NM1nfP008059 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 23 Jul 2019 22:01:49 GMT
Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 23 Jul 2019 17:01:48 -0500
Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 23 Jul 2019 17:01:47 -0500
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 23 Jul 2019 17:01:47 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=c4KqYULfFKayaLXN4nzeXOsQEdS8jan9I6aIqYiJ4tFWKdQ3ZW1uuv9sMwOC4CZ8aRw1UT2Yu7OvNJjBnmqaW9qggQx6J9/Mz6x5Bdf+vbc61pym97AQ1SJxf11+1zUnPkUbT5e6ceF1BRAUR0JoMrCf1NMfnchPaxJHIrI2c8Y0Bx/qAFQYL4Ue1LT0gwUdFAn99l3KTYLJ0bSWB/fytJc+e+GpiEZfM+u1eJZrmciyUfE2RKC3x04BCGcU48hEMDTHu4II/4dl4xkBg6WqYdu8V86Q0hdwfAu2EBLXNglgnYvA9pOvCf/v5Coy3e6FNZ2/CqpYMSYvlDDK3ZCCcQ==
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=4K1bpp8dlWE5TVwmW2ozbWH7zHjDX1T2Nql4Z78LNmM=; b=E//56PZgdrGiUB8ohjODklNEcNKi7IRYvjUSDFB0k+eGzlM35Nx8u2ZCz8P8OM+26NUTmzbKyQm9VTcvCYccwlcTR6v6M/n6TTGiOp7KdpP8srrck8798L5W2me29B+9Dyl8bYawPBMKQb7w8//PryK1wf7BwUV+PLCIonfSwgpg4hxlP0XjON4WUC3MwifLsKQP2RAC+LBmmTd0rD2kuTkDQzRS0J7oc+fe6hgYqd5Rjt3BiBcyYhmDHTleOtoF4FzoALH+OFxghUnz0kRmJcq4rsLuFk6eVRVVli+OZb2ASF0/r2vkQdfGhbJn8pFgRTnjxvmZsogTlUtqmHS0lw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=cisco.com;dmarc=pass action=none header.from=cisco.com;dkim=pass header.d=cisco.com;arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=4K1bpp8dlWE5TVwmW2ozbWH7zHjDX1T2Nql4Z78LNmM=; b=QGlxGtWAeXMe/OJudy33j1QV5bxekeG+YWlsG5SakxLb6AFF7JnF4J6VuwoZbwcOmOMkLSv7f43HkkEMN7ZOqp/ghoLiG9Gmx6KuD4sC33T6A/3narc8AS90GOdJE6DUejaocEi6krii89XyOcMi/k32tspbwLYgr9IfwhJnzkw=
Received: from BYAPR11MB2631.namprd11.prod.outlook.com (52.135.227.28) by BYAPR11MB2775.namprd11.prod.outlook.com (52.135.228.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2094.16; Tue, 23 Jul 2019 22:01:46 +0000
Received: from BYAPR11MB2631.namprd11.prod.outlook.com ([fe80::91da:1669:aaf0:d428]) by BYAPR11MB2631.namprd11.prod.outlook.com ([fe80::91da:1669:aaf0:d428%4]) with mapi id 15.20.2094.013; Tue, 23 Jul 2019 22:01:46 +0000
From: "Rob Wilton (rwilton)" <rwilton@cisco.com>
To: =?utf-8?B?QmFsw6F6cyBMZW5neWVs?= <balazs.lengyel@ericsson.com>, "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: AdVAwv3YCGqZ1KMoT7S8jMt8r0MeZgAByuUAACWODXAAAHr3AAACm5IAAAIGGnAACz2xMA==
Date: Tue, 23 Jul 2019 22:01:45 +0000
Message-ID: <BYAPR11MB26314E4A3754A9B5D6EC9CDAB5C70@BYAPR11MB2631.namprd11.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>
In-Reply-To: <VI1PR0701MB22861EC59BE79943C7E833F4F0C70@VI1PR0701MB2286.eurprd07.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=rwilton@cisco.com;
x-originating-ip: [2001:420:c0c8:1002::367]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 378a4aff-4909-449c-bc8b-08d70fb95ab0
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BYAPR11MB2775;
x-ms-traffictypediagnostic: BYAPR11MB2775:
x-ms-exchange-purlcount: 5
x-microsoft-antispam-prvs: <BYAPR11MB2775E78FEC8CC971072084AEB5C70@BYAPR11MB2775.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0107098B6C
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(346002)(396003)(376002)(366004)(136003)(199004)(189003)(13464003)(966005)(478600001)(256004)(25786009)(11346002)(110136005)(446003)(66946007)(66476007)(76116006)(76176011)(99286004)(66446008)(316002)(476003)(53546011)(6506007)(46003)(486006)(74316002)(66556008)(64756008)(186003)(8676002)(7736002)(52536014)(102836004)(81166006)(54896002)(6436002)(55016002)(2906002)(2501003)(236005)(6246003)(33656002)(790700001)(6116002)(9686003)(86362001)(6306002)(606006)(66574012)(71190400001)(71200400001)(229853002)(14454004)(14444005)(5660300002)(53936002)(8936002)(7696005)(81156014)(68736007)(369524004); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB2775; H:BYAPR11MB2631.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: lSnIWBB+iXG7AE5rrz4jpMitC5wRlZ3exJZntbno9KdiAcbpup2UlK5PJnh25pBiwrzIzYPEl5z9G84FkFP91PxZVTv5RJQk5Bv1IweyFcyJu1Z41llmBSnady2aVc+3e0xhdn59RfCjyuLIm1JeZH1zCZmDAW5I8WhBtoPBxeWzsFv6xHZQ+jLW9oX4OfhfGBsEJX/RVHk/1JUmwPBnSTjIDoyXV27UiwttPoYAv0UWHX38rFRdcBL7/NpFICPS77GoMF1vlKBeFMgpwdNW5noM3uZhyN8ImVF5PR+XCriA2o0XBM3ZWsIXvsClkHCIYFgUVusazsDRrNip4avIC2WqrI83TKfQYM/iaJZpf3ixZXigNuGbrlvIhMaOZ+JxZKIWp6yeV6mJE/BQoTtCd1Ls3sUhRSNKK8I7J93F7sY=
Content-Type: multipart/alternative; boundary="_000_BYAPR11MB26314E4A3754A9B5D6EC9CDAB5C70BYAPR11MB2631namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 378a4aff-4909-449c-bc8b-08d70fb95ab0
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jul 2019 22:01:45.9483 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: rwilton@cisco.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB2775
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.21, xch-aln-011.cisco.com
X-Outbound-Node: alln-core-8.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/xGLdMB1LBWkKiF_F2pr2LjKfTIE>
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 22:02:03 -0000

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.

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

Thanks,
Rob


From: netmod <netmod-bounces@ietf.org>; On Behalf Of Balázs Lengyel
Sent: 23 July 2019 13:09
To: 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 ?

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