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

["Rob Wilton (rwilton)" <[e-mail]>]

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 <[e-mail]> On Behalf Of Balázs Lengyel
Sent: 23 July 2019 13:09
To: Andy Bierman <[e-mail]>; Juergen Schoenwaelder <[e-mail]>; [e-mail]
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 <[e-mail]<mailto:[e-mail]>>
Sent: 2019. július 23., kedd 11:39
To: Juergen Schoenwaelder <[e-mail]<mailto:[e-mail]>>; Balázs Lengyel <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>>
> Sent: 2019. július 22., hétfő 16:15
> To: Balázs Lengyel <[e-mail]<mailto:[e-mail]>>
> Cc: [e-mail]<mailto:[e-mail]>
> 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: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   [phone]         <https://www.jacobs-university.de/>



--
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>

_______________________________________________
netmod mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/netmod