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

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

Re: [netmod] YANG next

[Qin Wu]

Thanks Adrian for clarification. The goal of YANG side meeting is not to 
discuss YANG-Next but fill the gap with operator community.
Thanks Dan and Adrian to take minutes. I have uploaded to IETF YANG Side 
meeting wiki page. 
To folks who participant in the meeting, thanks for your participation and 
input. If there is any correction needed, please
let us know.
Room: Notre Dame - Tuesday ¶
Occupancy: up to 50 attendees 
Configuration: classroom 
Location: ​Notre Dame 

Meeting NameArea ContactMeeting Description More information 
08:30 Next Step of IETF YANG OPS Area bill.wu@… Discuss the gap between IETF 
YANG and Industry needs The presentation slides and minutes: 
​https://github.com/sunseawq/IETF-YANG-side-meeting 
The relevant draft is 
​https://www.ietf.org/id/draft-wu-model-driven-management-virtualization-05.txt 

Regards!
-Qin

发件人: netmod [netmod-boun...@ietf.org] 代表 Adrian Farrel [adr...@olddog.co.uk]
发送时间: 2019年7月24日 2:14
收件人: 'Ladislav Lhotka'; 'Andy Bierman'
抄送: 'NETMOD WG'
主题: Re: [netmod] YANG next

>> I hope a summary of the meeting is posted to the WG mailing list.
>
> I think so, minutes were taken.

I scribbled.
So did Dan King.
We sent our scribbles to Geng Liang and Qin Wu.
They will process.

It was a side meeting.
As Lou says, it was not part of any existing WG. Nor was it a BoF.

How and where and if the minutes are published is not a question for me to
answer.

Adrian

PS I don't think this was a debate about creating a new version of the YANG
language, and I don't think extensions or modifications to the YANG language
were high on the list of "fixes" to the questions raised in the meeting.
That doesn't mean that debate shouldn't/cannot happen, just that it is not
(highly) relevant to the discussion at hand.


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
___
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 ?

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

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

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

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

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

Re: [netmod] YANG next

[Balázs Lengyel]

+1   Balazs

-Original Message-
From: netmod  On Behalf Of Rob Wilton (rwilton)
Sent: 2019. július 23., kedd 17:51
To: Ladislav Lhotka ; NETMOD WG 
Subject: Re: [netmod] YANG next

Hi Lada,

I still think that it makes sense to do YANG Next, on the assumption that it
will take a couple of years to work out, maybe longer if the work doesn't
properly get started until the YANG versioning work has progressed further.

When I look at the YANG Next issue list, I think that there are quite a lot
of things on that list (some of which are quite small) that would be good to
do, and will help modelling efforts.

Thanks,
Rob


-Original Message-
From: netmod  On Behalf Of Ladislav Lhotka
Sent: 23 July 2019 12:03
To: NETMOD WG 
Subject: [netmod] YANG next

Hi,

this morning I attended the side meeting "Next Step of IETF YANG". I was
somewhat misled into thinking that it would be about future evolution of
YANG the language, which was not the case at all. However, my personal
conclusion from the meeting is that it would be a total disaster to throw in
a new version of YANG within the next few years or so.

The operators and equipment vendors are busy putting together YANG modules
and tools, filling the gaps, coping with NMDA, schema mount, IETF versus
OpenConfig etc. A new YANG version (and modules written in it) would IMO be
extremely counter-productive at this rather turbulent stage.

So, if we want to continue the yang-next discussion, I think we first have
to figure out how to evolve YANG without making waves in the current YANG
pond and let the operators and vendors do their work, without which YANG can
never succeed.

Lada

--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

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

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


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

Re: [netmod] YANG next

[Rob Wilton (rwilton)]

Hi Lada,

I still think that it makes sense to do YANG Next, on the assumption that it 
will take a couple of years to work out, maybe longer if the work doesn't 
properly get started until the YANG versioning work has progressed further.

When I look at the YANG Next issue list, I think that there are quite a lot of 
things on that list (some of which are quite small) that would be good to do, 
and will help modelling efforts.

Thanks,
Rob


-Original Message-
From: netmod  On Behalf Of Ladislav Lhotka
Sent: 23 July 2019 12:03
To: NETMOD WG 
Subject: [netmod] YANG next

Hi,

this morning I attended the side meeting "Next Step of IETF YANG". I was 
somewhat misled into thinking that it would be about future evolution of YANG 
the language, which was not the case at all. However, my personal conclusion 
from the meeting is that it would be a total disaster to throw in a new version 
of YANG within the next few years or so.

The operators and equipment vendors are busy putting together YANG modules and 
tools, filling the gaps, coping with NMDA, schema mount, IETF versus OpenConfig 
etc. A new YANG version (and modules written in it) would IMO be extremely 
counter-productive at this rather turbulent stage.

So, if we want to continue the yang-next discussion, I think we first have to 
figure out how to evolve YANG without making waves in the current YANG pond and 
let the operators and vendors do their work, without which YANG can never 
succeed.

Lada

--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

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

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

Re: [netmod] Instance-data-format -additional simplified format to define content schema

[Rob Wilton (rwilton)]

Hi Balazs,

Yes, I think this looks good to me.

Thanks,
Rob


From: netmod  On Behalf Of Balázs Lengyel
Sent: 22 July 2019 16:13
To: 'netmod@ietf.org' 
Subject: [netmod] Instance-data-format -additional simplified format to define 
content schema

Hello,
At the IETF 105 Netmod meeting it was stated that the flexible solution to 
define the context schema inline (requested earlier on the mailing list) is 
quite complex, so a fourth simpler method to define content schema inline is 
needed.
The fourth method would add one more choice to "choice content-schema-spec   "

case simplified-inline {
  leaf-list module  {
type string {
   pattern '.+@\d{4}-\d{2}-\d{2}\.yang';
 }
 description "The list of content defining YANG
   modules including the revision date for each.
   Usage of this leaf-list implies the modules are
   used without any deviations and with all features
   supported.";
  }
}

An example instant data example could be:

  read-only-acm-rules
  
ietf-yang-libr...@2019-01-04.yangmailto:ietf-yang-libr...@2019-01-04.yang%3c/module>>

  
ietf-netconf-...@2012-02-22.yangmailto:ietf-netconf-...@2012-02-22.yang%3c/module>>

  

1776-07-04

Initial version

  

  Access control rules for a read-only role.

  ...

Do you like it ? Adding this case are you OK with the content-schema-spec 
definition?
Regards Balazs
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] YANG next

[Ladislav Lhotka]

On Tue, 2019-07-23 at 11:35 -0700, Andy Bierman wrote:
> 
> 
> On Tue, Jul 23, 2019 at 11:00 AM Ladislav Lhotka  wrote:
> > On Tue, 2019-07-23 at 09:22 -0700, Andy Bierman wrote:
> > > 
> > > 
> > > On Tue, Jul 23, 2019 at 9:03 AM Ladislav Lhotka  wrote:
> > > > Hi,
> > > > 
> > > > this morning I attended the side meeting "Next Step of IETF YANG". I was
> > > > somewhat misled into thinking that it would be about future evolution of
> > > > YANG
> > > > the language, which was not the case at all. However, my personal
> > conclusion
> > > > from the meeting is that it would be a total disaster to throw in a new
> > > > version
> > > > of YANG within the next few years or so.
> > > > 
> > > 
> > > 
> > > I hope a summary of the meeting is posted to the WG mailing list.
> > 
> > I think so, minutes were taken.
> > 
> > >  
> > > > The operators and equipment vendors are busy putting together YANG
> > modules
> > > > and
> > > > tools, filling the gaps, coping with NMDA, schema mount, IETF versus
> > > > OpenConfig
> > > > etc. A new YANG version (and modules written in it) would IMO be
> > extremely
> > > > counter-productive at this rather turbulent stage.
> > > > 
> > > > So, if we want to continue the yang-next discussion, I think we first
> > have
> > > > to
> > > > figure out how to evolve YANG without making waves in the current YANG
> > pond
> > > > and
> > > > let the operators and vendors do their work, without which YANG can
> > never
> > > > succeed.
> > > > 
> > > 
> > > IMO a new version of YANG would not be disruptive (if done right).
> > > The issue is whether it is cleaner in the long-run to introduce NBC
> > changes
> > > properly
> > > with a new version number, or not so properly, through YANG extensions.
> > 
> > I don't see much difference provided that the extensions will be properly
> > signalled. But we have to take into account that some tools that people use
> > may
> > not be updated for quite some time, and if they cannot properly work with
> > modules written for the new version (or extensions), then things will break.
> > 
> 
> So you want to work on YANG 1.2, but just the parts you want to change? ;-)

I am actually fine with not doing any changes to YANG 1.1 at all, except perhaps
bug fixes. This doesn't necessarily mean closing the NETMOD WG, it would IMO be
immensely useful to rewrite the language specification and remove NETCONF- and
XML-specific part.

> There is no such thing as a critical extension in YANG 1.1.

One alternative to doing nothing is to introduce critical extensions but
temporarily forbid their use in IETF modules (so that existing tools continue to
work). This would allow for developing and testing new YANG features without
causing troubles to current YANG users. Specific areas and communities may
decide to treat some crictical extensions as required and use tools that support
them.

> IMO it would be a bad idea to develop standard modules that relied on tool
> support of
> any extension. A tool is allowed to skip any extension when parsing a module.
> This cannot be changed in YANG 1.1.
>  
> > This problem is actually not limited to YANG itself - people are reporting
> > problems with the transition to NMDA. 
> > 
> > > 
> > > E.g -- adding a leaf to the datastore that says "I don't follow the rules
> > in
> > > 7950"
> > > is still breaking the YANG 1.1 contract.  Using extensions instead of real
> > > statements
> > > is problematic because they are optional to implement (as you point out
> > all
> > > the time).
> > 
> > Yes, hence critical extensions. However, the problem is still the same -
> > these
> > changes require updated tools, and not all tools will be updated
> > immediately. I
> > think that we should make sure that (at least in the IETF) all modules will
> > be
> > compatible with tools supporting YANG 1.1, say for the next 5 years.
> > 
> 
> I am OK with the current WG priorities such as versioning.

Yes, work on versioning and packages should continue.

> Those YANG extensions simply clarify YANG 1.1 so no rules are broken
> and no YANG 1.1 functionality is removed if a tool ignores the extensions.
> Also OK with not working on YANG 1.2 or critical extensions.
> There are no must-have features at this time.

I agree.

Lada

> 
> > Lada
> > 
> 
> Andy
>  
> > > 
> > > Seems like the WG is going the YANG extension route, which has its own set
> > of
> > > problems
> > > compared to a new YANG language version.
> > > 
> > > 
> > > > Lada
> > > 
> > > Andy
> > >  
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

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

Re: [netmod] YANG next

[Andy Bierman]

On Tue, Jul 23, 2019 at 11:00 AM Ladislav Lhotka  wrote:

> On Tue, 2019-07-23 at 09:22 -0700, Andy Bierman wrote:
> >
> >
> > On Tue, Jul 23, 2019 at 9:03 AM Ladislav Lhotka  wrote:
> > > Hi,
> > >
> > > this morning I attended the side meeting "Next Step of IETF YANG". I
> was
> > > somewhat misled into thinking that it would be about future evolution
> of
> > > YANG
> > > the language, which was not the case at all. However, my personal
> conclusion
> > > from the meeting is that it would be a total disaster to throw in a new
> > > version
> > > of YANG within the next few years or so.
> > >
> >
> >
> > I hope a summary of the meeting is posted to the WG mailing list.
>
> I think so, minutes were taken.
>
> >
> > > The operators and equipment vendors are busy putting together YANG
> modules
> > > and
> > > tools, filling the gaps, coping with NMDA, schema mount, IETF versus
> > > OpenConfig
> > > etc. A new YANG version (and modules written in it) would IMO be
> extremely
> > > counter-productive at this rather turbulent stage.
> > >
> > > So, if we want to continue the yang-next discussion, I think we first
> have
> > > to
> > > figure out how to evolve YANG without making waves in the current YANG
> pond
> > > and
> > > let the operators and vendors do their work, without which YANG can
> never
> > > succeed.
> > >
> >
> > IMO a new version of YANG would not be disruptive (if done right).
> > The issue is whether it is cleaner in the long-run to introduce NBC
> changes
> > properly
> > with a new version number, or not so properly, through YANG extensions.
>
> I don't see much difference provided that the extensions will be properly
> signalled. But we have to take into account that some tools that people
> use may
> not be updated for quite some time, and if they cannot properly work with
> modules written for the new version (or extensions), then things will
> break.
>
>
So you want to work on YANG 1.2, but just the parts you want to change? ;-)
There is no such thing as a critical extension in YANG 1.1.
IMO it would be a bad idea to develop standard modules that relied on tool
support of
any extension. A tool is allowed to skip any extension when parsing a
module.
This cannot be changed in YANG 1.1.


> This problem is actually not limited to YANG itself - people are reporting
> problems with the transition to NMDA.
>
> >
> > E.g -- adding a leaf to the datastore that says "I don't follow the
> rules in
> > 7950"
> > is still breaking the YANG 1.1 contract.  Using extensions instead of
> real
> > statements
> > is problematic because they are optional to implement (as you point out
> all
> > the time).
>
> Yes, hence critical extensions. However, the problem is still the same -
> these
> changes require updated tools, and not all tools will be updated
> immediately. I
> think that we should make sure that (at least in the IETF) all modules
> will be
> compatible with tools supporting YANG 1.1, say for the next 5 years.
>
>
I am OK with the current WG priorities such as versioning.
Those YANG extensions simply clarify YANG 1.1 so no rules are broken
and no YANG 1.1 functionality is removed if a tool ignores the extensions.
Also OK with not working on YANG 1.2 or critical extensions.
There are no must-have features at this time.

Lada
>
>
Andy


> >
> > Seems like the WG is going the YANG extension route, which has its own
> set of
> > problems
> > compared to a new YANG language version.
> >
> >
> > > Lada
> >
> > Andy
> >
> --
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
>
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] YANG next

[Juergen Schoenwaelder]

On Tue, Jul 23, 2019 at 02:00:29PM -0400, Ladislav Lhotka wrote:
> 
> This problem is actually not limited to YANG itself - people are reporting
> problems with the transition to NMDA. 
>

The YANG update from 1 to 1.1 mostly affected compiler writers - and
to a much lesser extend module authors and module implementors. NMDA,
affects client and server implementors much more directly, additional
instrumentation on the server side needs to be written, application
logic on the client side needs to be adjusted. NMDA is an evolution of
architectural principles and this already indicates that there is a
certain investment to make.

If we discuss YANG next, we should compare it to the YANG 1 to 1.1
transition and not to the NMDA transition. When we started YANG 1.1
work, there were people who said that nobody would implement it. But
then implementations were adopted relatively fast when we finalized
YANG 1.1.

While a collection of patches (updates) of YANG 1.1 may sound simpler,
I am not sure this is really true. We will loose a common baseline and
instead get complexity since we will get systems that all support
different sets of patches (updates) of YANG 1.1. I believe we are all
much better off if we have a common baseline language and tools that
support the common baseline language. Again, if done right, YANG next
will mostly affect compiler writers and tool makers and not so much
module authors and implementors.

/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

Re: [netmod] YANG next

[Ladislav Lhotka]

On Tue, 2019-07-23 at 19:14 +0100, Adrian Farrel wrote:
> > > I hope a summary of the meeting is posted to the WG mailing list.
> > 
> > I think so, minutes were taken.
> 
> I scribbled.
> So did Dan King.
> We sent our scribbles to Geng Liang and Qin Wu. 
> They will process.

Thanks for that.

> 
> It was a side meeting. 
> As Lou says, it was not part of any existing WG. Nor was it a BoF.
> 
> How and where and if the minutes are published is not a question for me to
> answer.
> 
> Adrian
> 
> PS I don't think this was a debate about creating a new version of the YANG
> language, and I don't think extensions or modifications to the YANG language
> were high on the list of "fixes" to the questions raised in the meeting.

Right, this is what I said in the beginning of my message.

Lada

> That doesn't mean that debate shouldn't/cannot happen, just that it is not
> (highly) relevant to the discussion at hand.
> 
> 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

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

Re: [netmod] YANG next

[Adrian Farrel]

>> I hope a summary of the meeting is posted to the WG mailing list.
>
> I think so, minutes were taken.

I scribbled.
So did Dan King.
We sent our scribbles to Geng Liang and Qin Wu. 
They will process.

It was a side meeting. 
As Lou says, it was not part of any existing WG. Nor was it a BoF.

How and where and if the minutes are published is not a question for me to
answer.

Adrian

PS I don't think this was a debate about creating a new version of the YANG
language, and I don't think extensions or modifications to the YANG language
were high on the list of "fixes" to the questions raised in the meeting.
That doesn't mean that debate shouldn't/cannot happen, just that it is not
(highly) relevant to the discussion at hand.


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

Re: [netmod] 6991bis add protocol identities ?

[Juergen Schoenwaelder]

Balázs,

I am not sure I fully understand what you are looking for but it
sounds to me like you are looking for an IANA maintained YANG module
rather than a common YANG type (i.e., this may be considered out of
scope for RFC 6991 bis).

By doing this, you will likely face the same problem the crypto types
are facing; having a long list of protocol identities (crypto
identities) does not express that only certain subsets are useful in
certain contexts (a design time subset) and that implementations are
supporting only certain subsets of the subset (an implementation time
subset). I am sure we have a YANG next isssue for the later one, I am
not sure we have one for the first.

/js

On Tue, Jul 23, 2019 at 04:10:05PM +, Balázs Lengyel wrote:
> Hello Jurgen,
> 
> I have seen multiple places where protocol identities are needed.
> (Subscribed notifications, draft-mahesh-netconf-https-notif
>  , 3GPP
> YAMs). Wouldn’t it be a good idea to define these centrally e.g. in 6991bis?
> 
> I know collecting a complete set of protocols would be a problem, but
> defining at least the most important ones centrally, is better than every
> module defining its own identities, enums, strings.
> 
> If we provide these protocol identities, it would also be good to find a way
> to specify, that a YANG module supports only a subset of them not the full
> set going back to X.25 and pigeon based IP.
> 
> Regards Balazs
> 
>  
> 
>  
> 



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


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

Re: [netmod] YANG next

[Lou Berger]

On 7/23/2019 12:03 PM, Ladislav Lhotka wrote:

this morning I attended the side meeting "Next Step of IETF YANG". I was
somewhat misled ...


This IETF's "side-meeting" approach to non-WG meetings is quite 
confusing.  This meeting was *not* a WG nor was it part of any NetMod WG 
coordinated activity.


Of course, any discussion on yang or other in-charter topics is always 
welcome on the list.


Lou

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

Re: [netmod] YANG next

[Ladislav Lhotka]

On Tue, 2019-07-23 at 09:22 -0700, Andy Bierman wrote:
> 
> 
> On Tue, Jul 23, 2019 at 9:03 AM Ladislav Lhotka  wrote:
> > Hi,
> > 
> > this morning I attended the side meeting "Next Step of IETF YANG". I was
> > somewhat misled into thinking that it would be about future evolution of
> > YANG
> > the language, which was not the case at all. However, my personal conclusion
> > from the meeting is that it would be a total disaster to throw in a new
> > version
> > of YANG within the next few years or so.
> > 
> 
> 
> I hope a summary of the meeting is posted to the WG mailing list.

I think so, minutes were taken.

>  
> > The operators and equipment vendors are busy putting together YANG modules
> > and
> > tools, filling the gaps, coping with NMDA, schema mount, IETF versus
> > OpenConfig
> > etc. A new YANG version (and modules written in it) would IMO be extremely
> > counter-productive at this rather turbulent stage.
> > 
> > So, if we want to continue the yang-next discussion, I think we first have
> > to
> > figure out how to evolve YANG without making waves in the current YANG pond
> > and
> > let the operators and vendors do their work, without which YANG can never
> > succeed.
> > 
> 
> IMO a new version of YANG would not be disruptive (if done right).
> The issue is whether it is cleaner in the long-run to introduce NBC changes
> properly
> with a new version number, or not so properly, through YANG extensions.

I don't see much difference provided that the extensions will be properly
signalled. But we have to take into account that some tools that people use may
not be updated for quite some time, and if they cannot properly work with
modules written for the new version (or extensions), then things will break.

This problem is actually not limited to YANG itself - people are reporting
problems with the transition to NMDA. 

> 
> E.g -- adding a leaf to the datastore that says "I don't follow the rules in
> 7950"
> is still breaking the YANG 1.1 contract.  Using extensions instead of real
> statements
> is problematic because they are optional to implement (as you point out all
> the time).

Yes, hence critical extensions. However, the problem is still the same - these
changes require updated tools, and not all tools will be updated immediately. I
think that we should make sure that (at least in the IETF) all modules will be
compatible with tools supporting YANG 1.1, say for the next 5 years.

Lada

> 
> Seems like the WG is going the YANG extension route, which has its own set of
> problems
> compared to a new YANG language version.
> 
> 
> > Lada
> 
> Andy
>  
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

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

Re: [netmod] YANG next

[Ladislav Lhotka]

On Tue, 2019-07-23 at 16:22 +, Balázs Lengyel wrote:
> Hello,
> I share your concerns. However I see some ways of mitigating the problem:
> 1) Maybe the extension based solution is better than many people would
> believe. If we put new features (like status-information,
> import-revision-or-derived, preliminary-status etc.) into extensions e.g.
> Yang1-2:status-information older systems can just ignore them while never
> systems would still be able to use them. This might not work for all new
> functionality, but would definitely work for some.

This could work only for extensions that do not affect YANG semantics. For
example, if a server actively uses schema mount, then a client that ignores it
is next to useless.

For critical extensions that affect YANG semantics, it would IMO be necessary to
develop modules supporting them in separate branches, along with their 1.1-only
versions.

> 2) Some yang-next ideas are really clarifications of yang 1.1 (e.g. Clarify
> YANG "status" keyword usage (e.g., hierarchical)) so they will not disturb
> current users.

Of course, clarifications and bug fixes are OK.

Lada

> Regards Balazs
> 
> -Original Message-
> From: netmod  On Behalf Of Ladislav Lhotka
> Sent: 2019. július 23., kedd 12:03
> To: NETMOD WG 
> Subject: [netmod] YANG next
> 
> Hi,
> 
> this morning I attended the side meeting "Next Step of IETF YANG". I was
> somewhat misled into thinking that it would be about future evolution of
> YANG the language, which was not the case at all. However, my personal
> conclusion from the meeting is that it would be a total disaster to throw in
> a new version of YANG within the next few years or so.
> 
> The operators and equipment vendors are busy putting together YANG modules
> and tools, filling the gaps, coping with NMDA, schema mount, IETF versus
> OpenConfig etc. A new YANG version (and modules written in it) would IMO be
> extremely counter-productive at this rather turbulent stage.
> 
> So, if we want to continue the yang-next discussion, I think we first have
> to figure out how to evolve YANG without making waves in the current YANG
> pond and let the operators and vendors do their work, without which YANG can
> never succeed.
> 
> Lada
> 
> --
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

___
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 ?

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

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

[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] YANG next

[Balázs Lengyel]

Hello,
I share your concerns. However I see some ways of mitigating the problem:
1) Maybe the extension based solution is better than many people would
believe. If we put new features (like status-information,
import-revision-or-derived, preliminary-status etc.) into extensions e.g.
Yang1-2:status-information older systems can just ignore them while never
systems would still be able to use them. This might not work for all new
functionality, but would definitely work for some.
2) Some yang-next ideas are really clarifications of yang 1.1 (e.g. Clarify
YANG "status" keyword usage (e.g., hierarchical)) so they will not disturb
current users.
Regards Balazs

-Original Message-
From: netmod  On Behalf Of Ladislav Lhotka
Sent: 2019. július 23., kedd 12:03
To: NETMOD WG 
Subject: [netmod] YANG next

Hi,

this morning I attended the side meeting "Next Step of IETF YANG". I was
somewhat misled into thinking that it would be about future evolution of
YANG the language, which was not the case at all. However, my personal
conclusion from the meeting is that it would be a total disaster to throw in
a new version of YANG within the next few years or so.

The operators and equipment vendors are busy putting together YANG modules
and tools, filling the gaps, coping with NMDA, schema mount, IETF versus
OpenConfig etc. A new YANG version (and modules written in it) would IMO be
extremely counter-productive at this rather turbulent stage.

So, if we want to continue the yang-next discussion, I think we first have
to figure out how to evolve YANG without making waves in the current YANG
pond and let the operators and vendors do their work, without which YANG can
never succeed.

Lada

--
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

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


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

Re: [netmod] YANG next

[Andy Bierman]

On Tue, Jul 23, 2019 at 9:03 AM Ladislav Lhotka  wrote:

> Hi,
>
> this morning I attended the side meeting "Next Step of IETF YANG". I was
> somewhat misled into thinking that it would be about future evolution of
> YANG
> the language, which was not the case at all. However, my personal
> conclusion
> from the meeting is that it would be a total disaster to throw in a new
> version
> of YANG within the next few years or so.
>
>

I hope a summary of the meeting is posted to the WG mailing list.


> The operators and equipment vendors are busy putting together YANG modules
> and
> tools, filling the gaps, coping with NMDA, schema mount, IETF versus
> OpenConfig
> etc. A new YANG version (and modules written in it) would IMO be extremely
> counter-productive at this rather turbulent stage.
>
> So, if we want to continue the yang-next discussion, I think we first have
> to
> figure out how to evolve YANG without making waves in the current YANG
> pond and
> let the operators and vendors do their work, without which YANG can never
> succeed.
>
>
IMO a new version of YANG would not be disruptive (if done right).
The issue is whether it is cleaner in the long-run to introduce NBC changes
properly
with a new version number, or not so properly, through YANG extensions.

E.g -- adding a leaf to the datastore that says "I don't follow the rules
in 7950"
is still breaking the YANG 1.1 contract.  Using extensions instead of real
statements
is problematic because they are optional to implement (as you point out all
the time).

Seems like the WG is going the YANG extension route, which has its own set
of problems
compared to a new YANG language version.


Lada
>

Andy


>
> --
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
>
> ___
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] 6991bis add protocol identities ?

[Balázs Lengyel]

Hello Jurgen,

I have seen multiple places where protocol identities are needed.
(Subscribed notifications, draft-mahesh-netconf-https-notif
 , 3GPP
YAMs). Wouldn’t it be a good idea to define these centrally e.g. in 6991bis?

I know collecting a complete set of protocols would be a problem, but
defining at least the most important ones centrally, is better than every
module defining its own identities, enums, strings.

If we provide these protocol identities, it would also be good to find a way
to specify, that a YANG module supports only a subset of them not the full
set going back to X.25 and pigeon based IP.

Regards Balazs

 

 



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

[netmod] YANG next

[Ladislav Lhotka]

Hi,

this morning I attended the side meeting "Next Step of IETF YANG". I was
somewhat misled into thinking that it would be about future evolution of YANG
the language, which was not the case at all. However, my personal conclusion
from the meeting is that it would be a total disaster to throw in a new version
of YANG within the next few years or so.

The operators and equipment vendors are busy putting together YANG modules and
tools, filling the gaps, coping with NMDA, schema mount, IETF versus OpenConfig
etc. A new YANG version (and modules written in it) would IMO be extremely
counter-productive at this rather turbulent stage.

So, if we want to continue the yang-next discussion, I think we first have to
figure out how to evolve YANG without making waves in the current YANG pond and
let the operators and vendors do their work, without which YANG can never
succeed.

Lada

-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

___
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 ?

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

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

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



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

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

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


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