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

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

 

 





On Jul 23, 2019, at 18:01, Rob Wilton (rwilton) mailto:rwil...@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 < <mailto:netmod-boun...@ietf.org> netmod-boun...@ietf.org> On 
Behalf Of Balázs Lengyel
Sent: 23 July 2019 13:09
To: Andy Bierman < <mailto:a...@yumaworks.com> a...@yumaworks.com>; Juergen 
Schoenwaelder < <mailto:j.schoenwael...@jacobs-university.de> 
j.schoenwael...@jacobs-university.de>;  <mailto:netmod@ietf.org> 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 < <mailto:a...@yumaworks.com> a...@yumaworks.com> 
Sent: 2019. július 23., kedd 11:39
To: Juergen Schoenwaelder < <mailto:j.schoenwael...@jacobs-university.de> 
j.schoenwael...@jacobs-university.de>; Balázs Lengyel < 
<mailto:balazs.leng...@ericsson.com> balazs.leng...@ericsson.com>;  
<mailto:netmod@ietf.org> 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 < 
<mailto:j.schoenwael...@jacobs-university.de> 
j.schoenwael...@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 , 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 +, 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:j.schoenwael...@jacobs-university.de> 
> j.schoenwael...@jacobs-university.de> 
> Sent: 2019. július 22., hétfő 16:15
> To: Balázs Lengyel < <mailto:balazs.leng...@ericsson.com> 
> balazs.leng...@ericsson.com>
> Cc:  <mailto:netmod@ietf.org> 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 +, 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.
> >

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

2019-07-23 Thread Rob Wilton (rwilton) 

From: Joe Clarke (jclarke)
Sent: 23 July 2019 18:06
To: Rob Wilton (rwilton) 
Cc: Balázs Lengyel ; Andy Bierman 
; Juergen Schoenwaelder 
; netmod@ietf.org
Subject: Re: [netmod] Instance-data-format - shall we define etag and 
last-modified annotation ?




On Jul 23, 2019, at 18:01, Rob Wilton (rwilton) 
mailto:rwil...@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.
[RW]
I was more interested in the timestamps associated with when individual config 
items have changed.  E.g. could this be useful when doing a post mortem of a 
network failure?

Thanks,
Rob

Joe



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

Thanks,
Rob


From: netmod mailto:netmod-boun...@ietf.org>> On 
Behalf Of Balázs Lengyel
Sent: 23 July 2019 13:09
To: Andy Bierman mailto:a...@yumaworks.com>>; Juergen 
Schoenwaelder 
mailto:j.schoenwael...@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 mailto:a...@yumaworks.com>>
Sent: 2019. július 23., kedd 11:39
To: Juergen Schoenwaelder 
mailto:j.schoenwael...@jacobs-university.de>>;
 Balázs Lengyel 
mailto:balazs.leng...@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 
mailto:j.schoenwael...@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 , 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 +, 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:j.schoenwael...@jacobs-university.de>>
> Sent: 2019. július 22., hétfő 16:15
> To: Balázs Lengyel 
> mailto:balazs.leng...@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 +, 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 quickl

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

2019-07-23 Thread Joe Clarke (jclarke) 


On Jul 23, 2019, at 18:01, Rob Wilton (rwilton) 
mailto:rwil...@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 mailto:netmod-boun...@ietf.org>> On 
Behalf Of Balázs Lengyel
Sent: 23 July 2019 13:09
To: Andy Bierman mailto:a...@yumaworks.com>>; Juergen 
Schoenwaelder 
mailto:j.schoenwael...@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 mailto:a...@yumaworks.com>>
Sent: 2019. július 23., kedd 11:39
To: Juergen Schoenwaelder 
mailto:j.schoenwael...@jacobs-university.de>>;
 Balázs Lengyel 
mailto:balazs.leng...@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 
mailto:j.schoenwael...@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 , 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 +, 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:j.schoenwael...@jacobs-university.de>>
> Sent: 2019. július 22., hétfő 16:15
> To: Balázs Lengyel 
> mailto:balazs.leng...@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 +, 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 ?
>
> > 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 instanc

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

2019-07-23 Thread Rob Wilton (rwilton) 
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  On Behalf Of Balázs Lengyel
Sent: 23 July 2019 13:09
To: Andy Bierman ; Juergen Schoenwaelder 
; 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 mailto:a...@yumaworks.com>>
Sent: 2019. július 23., kedd 11:39
To: Juergen Schoenwaelder 
mailto:j.schoenwael...@jacobs-university.de>>;
 Balázs Lengyel 
mailto:balazs.leng...@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 
mailto:j.schoenwael...@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 , 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 +, 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:j.schoenwael...@jacobs-university.de>>
> Sent: 2019. július 22., hétfő 16:15
> To: Balázs Lengyel 
> mailto:balazs.leng...@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 +, 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 ?
>
> > 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

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

2019-07-23 Thread Balázs Lengyel 
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  
Sent: 2019. július 23., kedd 11:39
To: Juergen Schoenwaelder ; Balázs 
Lengyel ; 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 
mailto:j.schoenwael...@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 , 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 +, 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  
> Sent: 2019. július 22., hétfő 16:15
> To: Balázs Lengyel  <mailto:balazs.leng...@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 +, 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 ?
>  
> > 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

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

2019-07-23 Thread Kent Watsen 


> 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).

AFAIK, this is not required, and definitely not desirable. 

> I suggest new meta-data be defined that has semantics specific to datastore 
> contents, not
> the HTTP representation of the response.

agreed. 

> 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.

unsure, but inclined to think that it should be the same value that the target 
device would return. 


Kent // contributor 
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

2019-07-23 Thread Andy Bierman 
On Tue, Jul 23, 2019 at 7:24 AM Juergen Schoenwaelder <
j.schoenwael...@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 , 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 +, 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 
> > Sent: 2019. július 22., hétfő 16:15
> > To: Balázs Lengyel 
> > Cc: 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 +, 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 ?
> >
> > > draft-ietf-netmod-yang-instance-file-format-03#section-7.2
> > >
> > <
> 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 opti

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

2019-07-23 Thread Juergen Schoenwaelder 
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 , 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.

/js

On Tue, Jul 23, 2019 at 02:11:23PM +, 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  
> Sent: 2019. július 22., hétfő 16:15
> To: Balázs Lengyel 
> Cc: 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 +, 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 ?
>  
> > draft-ietf-netmod-yang-instance-file-format-03#section-7.2
> >
> <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
https://www.ietf.org/mailman/listinfo/netmod

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

2019-07-23 Thread Balázs Lengyel 
Hello Jürgen,
Could the etag and last-modified annotations be moved to 6991bis?
Regards Balazs

-Original Message-
From: Juergen Schoenwaelder  
Sent: 2019. július 22., hétfő 16:15
To: Balázs Lengyel 
Cc: 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 +, 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 ?
 
> draft-ietf-netmod-yang-instance-file-format-03#section-7.2
>
<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/>


smime.p7s
Description: S/MIME cryptographic signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

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

2019-07-22 Thread Juergen Schoenwaelder 
On Mon, Jul 22, 2019 at 07:23:59PM +, 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
?
 
> draft-ietf-netmod-yang-instance-file-format-03#section-7.2
>  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 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod