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

"Joe Clarke (jclarke)" <jclarke@cisco.com> Tue, 23 July 2019 22:06 UTC

Return-Path: <jclarke@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 218551209AB for <netmod@ietfa.amsl.com>; Tue, 23 Jul 2019 15:06:02 -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=goykVWBG; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=iOrxmpQz
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 T0U_m7DviL64 for <netmod@ietfa.amsl.com>; Tue, 23 Jul 2019 15:05:58 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F41391209DA for <netmod@ietf.org>; Tue, 23 Jul 2019 15:05:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=47449; q=dns/txt; s=iport; t=1563919558; x=1565129158; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ssDf75HZ+Sp8nJQqkP6LmGcoNyg+sxTON8ZfH5VLNcQ=; b=goykVWBG1RsrUCPl6ixMNTtwvQsQ0Tx9nvdsHPdzTuIDfsUNxMHfzR/q u4fwgU3vQDgWwaFOrSTnkLjzlyOsjyr6SuqEegsS4tGIgcl1wafDR2EWs CjB8qQe2d76UkHOOWxtwQ4PrtQb3PcTHc5ZwAEClObRn0bjbV9VlgKtlk 8=;
IronPort-PHdr: =?us-ascii?q?9a23=3ABI1SIxBQxGKDi4zZw/YkUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qs13kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMfkuHw?= =?us-ascii?q?QAld1QmgUhBMCfDkiuLvXuZjY5EexJVURu+DewNk0GUMs=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AYAAAThDdd/5ldJa1jAxoBAQEBAQI?= =?us-ascii?q?BAQEBBwIBAQEBgVUDAQEBAQsBgRQvJCwDbVUgBAsWFAqEE4NHA41/gjYll1C?= =?us-ascii?q?BLhSBEANQBAkBAQEMAQEYAQwIAgEBg3pGAheCNyM2Bw4BAwEBBAEBAgEGbYU?= =?us-ascii?q?eDIVKAQEBAQIBAQEQER0BASwLAQQHAgICAQgQAQQBAQEgAQYDAgICGQwLFAk?= =?us-ascii?q?IAgQOBSKDAAGBHU0DDg8BDp9wAoE4iGBxgTKCeQEBBYE2AoNRGIITAwYFgS8?= =?us-ascii?q?BhHGGbReBQD+BEScME4JMPoJhAQEDgUYCLQoMCRGCRDKCJoFiik0FgkSEfpZ?= =?us-ascii?q?xCQKCGYV5X4RuiEYbgi2HJY44hBGFeYpzkAgCBAIEBQIOAQEFgVcMJYFYcBU?= =?us-ascii?q?7KgGCQYJCDBcUgzozhGGFP3KBKY0DAYEgAQE?=
X-IronPort-AV: E=Sophos;i="5.64,300,1559520000"; d="scan'208,217";a="601264063"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 23 Jul 2019 22:05:56 +0000
Received: from XCH-RCD-016.cisco.com (xch-rcd-016.cisco.com [173.37.102.26]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x6NM5tLT012810 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 23 Jul 2019 22:05:56 GMT
Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-RCD-016.cisco.com (173.37.102.26) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 23 Jul 2019 17:05:55 -0500
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 23 Jul 2019 17:05:54 -0500
Received: from NAM05-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 23 Jul 2019 17:05:54 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aUu3xLHOJ53xj/ZAUcAelLYkpWjmi8rEOokHMnsQwg9zyUccf2xrTEjRcufr1Lk7RA5Vwet1pEMexWut3hBmtGiuq6NTo8Mr32dhV1axBmWWMtJqjZOF3QOr0sWmpfDhFGo7jyUo0s/RKT2uqg22dNtXXNn4qh+dB1ReazePEcN8tEkNjsNbtxj50ZKYNA+TFO6ei2FHealfphzXBRBvxvKCtykvLrcSnLaoGAPJAc7yBz+xqAhrt4IMXiZXsA1GYJyanVaPIzKLlXrTXEvglraqxiw4QAwOem6yF8RoTXRFkaLCEob8B/JxU7Y+sueDq0I3fRqOH1TPGwuBJPO+mg==
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=ssDf75HZ+Sp8nJQqkP6LmGcoNyg+sxTON8ZfH5VLNcQ=; b=UblzdrJAWfDXwE71qOBPgSY2/R4LZM32N3S7jG0omyfKYyV0mDbRNbCAcTzL8glZdz1lXs35n+o2OXmyJm0UEaINhRcnC6Nv5OGrae2bgTe7LBjCxgdMxK26xlqbyK/H1cOUkaXjC68dxquM6qRP87YP/VPMtgYr/AIAP1moZO4Skere7MufvPX44FeXjJ5E0pyt2SEn33lR1eU+ewPS27EOasJfhKcNgz3rIa64s3zHwrOBAnIcL94m+Tz0y9IOxUk7wgzc4ZwUOvKEUonpHU2LX9AigPTDp/gl83CAokg7qsj0130wRCsFrZhLkmKRQfpBBrf8zl6i0kOpyXMxXg==
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=ssDf75HZ+Sp8nJQqkP6LmGcoNyg+sxTON8ZfH5VLNcQ=; b=iOrxmpQzDKGyRD5a54Q5j4G/8nPnBzsuyw/ffwEZwWlXf7cQGIJ5jFJZCrJjWWM1bi/rKwVNT06fTA6b32ttMrvOjUs1acuZOmO826rss/oQn+evkMkl5aPTtv1VkzhUm8paInBlU+SaQH0sD2JY7Tv5TNF7qBsgJIRLxPPZW9o=
Received: from CH2PR11MB4200.namprd11.prod.outlook.com (10.141.118.161) by CH2PR11MB4327.namprd11.prod.outlook.com (10.186.148.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2094.17; Tue, 23 Jul 2019 22:05:53 +0000
Received: from CH2PR11MB4200.namprd11.prod.outlook.com ([fe80::9dc4:365:907d:c943]) by CH2PR11MB4200.namprd11.prod.outlook.com ([fe80::9dc4:365:907d:c943%7]) with mapi id 15.20.2094.013; Tue, 23 Jul 2019 22:05:53 +0000
From: "Joe Clarke (jclarke)" <jclarke@cisco.com>
To: "Rob Wilton (rwilton)" <rwilton@cisco.com>
CC: =?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: AdVAwv3YCGqZ1KMoT7S8jMt8r0MeZgAByuUAACWODXAAAHr3AAACm5IAAAIGGnAACz2xMAAAPZMA
Date: Tue, 23 Jul 2019 22:05:53 +0000
Message-ID: <F88AE433-1864-4C50-8156-7ADD8D2F6D2B@cisco.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>
In-Reply-To: <BYAPR11MB26314E4A3754A9B5D6EC9CDAB5C70@BYAPR11MB2631.namprd11.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=jclarke@cisco.com;
x-originating-ip: [70.231.19.155]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: f7f6d75d-0213-4190-d2fd-08d70fb9edf4
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:CH2PR11MB4327;
x-ms-traffictypediagnostic: CH2PR11MB4327:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: <CH2PR11MB4327B13752109ECD480C0066B8C70@CH2PR11MB4327.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0107098B6C
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(366004)(396003)(39860400002)(376002)(136003)(189003)(199004)(13464003)(37006003)(2906002)(14454004)(54906003)(6636002)(71190400001)(316002)(68736007)(36756003)(6116002)(71200400001)(33656002)(86362001)(3846002)(7736002)(99286004)(8676002)(186003)(6506007)(476003)(2616005)(446003)(606006)(11346002)(66066001)(25786009)(102836004)(66476007)(486006)(66574012)(229853002)(6436002)(6246003)(91956017)(53546011)(76176011)(6486002)(66446008)(66556008)(966005)(66946007)(5660300002)(26005)(81156014)(8936002)(14444005)(256004)(6512007)(54896002)(478600001)(236005)(6306002)(4326008)(6862004)(53936002)(64756008)(76116006)(81166006)(369524004); DIR:OUT; SFP:1101; SCL:1; SRVR:CH2PR11MB4327; H:CH2PR11MB4200.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A: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: +E+2ZN6suxGhU0/fe5xMPTBls1KseTJshMOdZbrK8JDzAyLt5GfcOr09d9w3jN+lbdFC1o7npwDsmNPxHyMLD8jI4bgxzkT06f/H9qp14Sd1vF2u+6yAouzB5eZJDrI58myYFZCotpZWhCXhuIfk4WusCus5Z0ANuIbKWZXSYvaZbX/WHAeBKn/fdyWj40onnbNtMcSjEqyQOu6bDW147Ya8FxwbwRoKidak/TuYAL8G7IJHsLhtbTDK0T+M+Ac80xjDmTLTZSCIBCHFKiJtek+EH3BN9rURe6lGuda7LRnRkPZAA6K5JweHjryelJgt6mDV7BxPaAo77hO0Dz75ZhtyMh4shyoaD73NiuwADdb60ZJ4p/61OwCqRDNHtVWUzIH2lKVFexMqTUHXcMiFXxgLcdp2oc3ou56v45znzxE=
Content-Type: multipart/alternative; boundary="_000_F88AE43318644C5081567ADD8D2F6D2Bciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: f7f6d75d-0213-4190-d2fd-08d70fb9edf4
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jul 2019 22:05:53.0306 (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: jclarke@cisco.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR11MB4327
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.26, xch-rcd-016.cisco.com
X-Outbound-Node: rcdn-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/YPdtHuTsTJSkc442X7aR8_jw9Os>
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:06:14 -0000


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 <netmod-bounces@ietf.org<mailto:netmod-bounces@ietf.org>> On Behalf Of Balázs Lengyel
Sent: 23 July 2019 13:09
To: Andy Bierman <andy@yumaworks.com<mailto:andy@yumaworks.com>>; Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de<mailto:j.schoenwaelder@jacobs-university.de>>; netmod@ietf.org<mailto: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
_______________________________________________
netmod mailing list
netmod@ietf.org<mailto:netmod@ietf.org>
https://www.ietf.org/mailman/listinfo/netmod