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

[Balázs Lengyel <[e-mail]>]

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) <[e-mail]> 
Sent: 2019. július 23., kedd 18:06
To: Rob Wilton (rwilton) <[e-mail]>
Cc: Balázs Lengyel <[e-mail]>; Andy Bierman <[e-mail]>; Juergen Schoenwaelder <[e-mail]>; [e-mail]
Subject: Re: [netmod] Instance-data-format - shall we define etag and last-modified annotation ?

 

 





On Jul 23, 2019, at 18:01, Rob Wilton (rwilton) <[e-mail] <mailto:[e-mail]> > 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:[e-mail]> [e-mail]> On Behalf Of Balázs Lengyel
Sent: 23 July 2019 13:09
To: Andy Bierman < <mailto:[e-mail]> [e-mail]>; Juergen Schoenwaelder < <mailto:[e-mail]> [e-mail]>;  <mailto:[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 < <mailto:[e-mail]> [e-mail]> 
Sent: 2019. július 23., kedd 11:39
To: Juergen Schoenwaelder < <mailto:[e-mail]> [e-mail]>; Balázs Lengyel < <mailto:[e-mail]> [e-mail]>;  <mailto:[e-mail]> [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 < <mailto:[e-mail]> [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 < <mailto:[e-mail]> [e-mail]> 
> Sent: 2019. július 22., hétfő 16:15
> To: Balázs Lengyel < <mailto:[e-mail]> [e-mail]>
> Cc:  <mailto:[e-mail]> [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/> 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/> https://www.jacobs-university.de/>

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

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