Re: [netmod] adoption poll for yang-versioning-reqs-02

[Andy Bierman]

Hi,

I don't know what it means to "accept" NBC changes.
I agree this is a deviation that could be documented somehow.

Andy


On Sun, Mar 24, 2019 at 2:47 PM Reshad Rahman (rrahman) 
wrote:

>
>
> *From: *netmod  on behalf of 'Andy Bierman' <
> a...@yumaworks.com>
> *Date: *Sunday, March 24, 2019 at 9:59 PM
> *To: *Kent Watsen 
> *Cc: *NetMod WG 
> *Subject: *Re: [netmod] adoption poll for yang-versioning-reqs-02
>
>
>
>
>
>
>
> On Sun, Mar 24, 2019 at 1:45 PM Kent Watsen  wrote:
>
>
> Hi Andy,
>
> > Andy Bierman wrote:
> >
> > BTW, I do not support adoption of the requirements document at all.
>
> Can you say why?   Is it a blanket statement about adopting requirements
> drafts in general, or something specific to this draft.
>
>
>
> Because they just waste time.
>
> They are mostly reverse engineered from the desired solution (by the
> authors).
>
>
>
>  I don’t think we’re tied to the solution of semver or modified semver
> (speaking for myself at least). The main question on the requirements is
> whether NBC changes should be accepted. Many people seem to think so, if
> you don’t agree that’s fine, but I disagree with the claim that the
> requirements are reverse engineered from the solution, I believe the design
> team has strived to separate the 2.
>
>
>
> Reshad.
>
>
>
> We end up having the same debates twice.
>
>
>
> It is usually worse then that, since you end up debating the wording in
> the requirements
>
> instead of the merits of the solution-in-progress (considering all factors
> and readjusted requirements).
>
>
>
>
>
> Kent
>
>
>
> Andy
>
>
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] adoption poll for yang-versioning-reqs-02

[Reshad Rahman (rrahman)]

From: netmod  on behalf of 'Andy Bierman' 

Date: Sunday, March 24, 2019 at 9:59 PM
To: Kent Watsen 
Cc: NetMod WG 
Subject: Re: [netmod] adoption poll for yang-versioning-reqs-02



On Sun, Mar 24, 2019 at 1:45 PM Kent Watsen 
mailto:kent%2bi...@watsen.net>> wrote:

Hi Andy,

> Andy Bierman wrote:
>
> BTW, I do not support adoption of the requirements document at all.

Can you say why?   Is it a blanket statement about adopting requirements drafts 
in general, or something specific to this draft.

Because they just waste time.
They are mostly reverse engineered from the desired solution (by the authors).

 I don’t think we’re tied to the solution of semver or modified semver 
(speaking for myself at least). The main question on the requirements is 
whether NBC changes should be accepted. Many people seem to think so, if you 
don’t agree that’s fine, but I disagree with the claim that the requirements 
are reverse engineered from the solution, I believe the design team has strived 
to separate the 2.

Reshad.

We end up having the same debates twice.

It is usually worse then that, since you end up debating the wording in the 
requirements
instead of the merits of the solution-in-progress (considering all factors and 
readjusted requirements).


Kent

Andy

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

Re: [netmod] adoption poll for yang-versioning-reqs-02

[Andy Bierman]

On Sun, Mar 24, 2019 at 1:45 PM Kent Watsen  wrote:

>
> Hi Andy,
>
> > Andy Bierman wrote:
> >
> > BTW, I do not support adoption of the requirements document at all.
>
> Can you say why?   Is it a blanket statement about adopting requirements
> drafts in general, or something specific to this draft.
>
>
Because they just waste time.
They are mostly reverse engineered from the desired solution (by the
authors).
We end up having the same debates twice.

It is usually worse then that, since you end up debating the wording in the
requirements
instead of the merits of the solution-in-progress (considering all factors
and readjusted requirements).



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

Re: [netmod] adoption poll for yang-versioning-reqs-02

[Martin Bjorklund]

Andy Bierman  wrote:
> On Sun, Mar 24, 2019 at 11:39 AM Joel Jaeggli  wrote:
> 
> >
> >
> > On Mar 22, 2019, at 12:07, Lou Berger  wrote:
> >
> > Hi,
> >
> > Thank you all for the good input on this thread.
> >
> > With the understanding that a 00 working group document is a starting
> > point for the working group rather than a document that is ready for last
> > call - we believe there is sufficient support to adopt this document as a
> > starting point for the requirements we wish to address on this topic.
> >
> > It is clear that there is still work to be done on this document before we
> > can declare consensus on it and, not surprisingly, that there is more work
> > to be done on the solution.
> >
> > Authors,
> >
> > Please resubmit this document as draft-ietf-netmod-yang-revision-reqs-00
> > with the only change being the name and publication date.  The -01 version
> > should focus on resolving issues raised during adoption.  Of course the
> > document is subject to normal WG input and processing.
> >
> > Please note the 'file' name change -this is to indicate that the
> > requirements are not presupposing a specific solution. It is also
> > consistent with how versioning is defined within the document currently.
> >
> > Note: we would like to try to continue the list discussion in next week's
> > session and ask the Authors/DT to summarize issues raised during the
> > adoption call and lead a discussion to help resolve these issues.
> >
> > I think this meeting is great opportunity to decide what steps need to be
> > taken to advance the document within the working group.
> >
> > Martin specifically objects to the presence of of Non-Backward-Compatible
> > changes.
> >
> > Many modules outside the IETF are already incompatible with roc 7950 yang
> > 1.1 revision rules. So that cat may be out of the bag at least with respect
> > to the real world. the question remains what to do about that?
> >
> >
> 
> I do not look at the problem as allowing NBC so much as making it clear to
> toolmakers what is going on,
> like a deviation to the versioning rules.
> 
> BTW, I do not support adoption of the requirements document at all.
> I support the work on versioning as part of the charter, and I am happy to
> accept the design team solution draft as the starting point, and just work
> on a solution.
> 
> But I think the solution is a bit flawed.
> 
> 1) extensions are optional and problematic since they can be revisioned
> without changing
> the language version; the solution needs to use new YANG 1.2 statements
> instead of extensions
> 
> 2) the version string does not have to contain all the NBC semantics.
> The solution draft does not show modified semver.
> It should be done differently than overloading the version string;
> 
> Let's say a fork is done on 1.3.0.
> 
>  revision 2017-07-30 {
>description "Added leaf foo-64";
>semver:module-version "1.3.0";
>  }
> 
> start with a legal change, just not at the HEAD
> 
>  revision 2019-01-10 {
>description "Added leaf bar-64";
>semver:module-version "1.3.1";
>  }
> 
> 
> then later, an NBC change
> 
> revision 2019-02-10 {
>description "Changed leaf bar-64 default-stmt";
>semver:module-version "1.3.2";
>semver:nbc-change;
> 
>  }
> 
> then later, a legal change
> 
> revision 2019-03-10 {
>description "Added leaf baz-64";
>semver:module-version "1.3.3";
> 
>  }

+1  I have suggested something similar.

> This is a form of an inline deviation-stmt.
> The YANG update rules are not changing. They are just not being followed.

Right!

> The NBC info belongs in the revision-stmt, not overloading the version string.

Agreed.


> Not every major revision will mean NBC changes anyway.





/martin



> 
> 
> Andy
> 
> 
> 
> 
> 
> >
> >
> > ___
> > 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] import-by-semver issue

[Martin Bjorklund]

Andy Bierman  wrote:
> On Sun, Mar 24, 2019 at 9:14 AM Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de> wrote:
> 
> > On Sun, Mar 24, 2019 at 03:14:18PM +, Rob Wilton (rwilton) wrote:
> > >
> > > But that is true of YANG compilers today.  If there are multiple
> > revisions of a module that could be chosen, then each compiler is at
> > liberty to decide which revision to choose (last paragraph of section 5.1.1
> > in RFC 7950).
> > >
> >
> > The difference is that NBC changes are not allowed. As long as you
> > find a certain symbol, it has fixed and predictable semantics.
> >
> > Sorry, but changing the way the import statement works is an NBC
> > change of YANG and this can't be done with extensions.
> >
> >
> I strongly agree.
> The expected behavior for tools needs to be consistent, especially for
> the construction of the schema tree, which depends on the import rules.
> 
> Implementation complexity should matter in the IETF, but it does not.
> Just keep raising the complexity up to 10 and complain that the tools have
> bugs,
> as if the two are unrelated. (Simply looking for a hardwired string
> "semver:version"
> will not work since the prefix is not required to be "semver" in the
> import-stmt.)

Agreed, but it quite easy to first build a prefix map (prefix ->
module name), and then instead of ":semver" you see ("ietf-semver",
"semver"); and _this_ can be hardcoded in the compiler.  (pyang works
like this)

This said, it is a bit weird with:

import ietf-semver {
  prefix "semver";
  semver:version 1.1.2;
}

so in order to handle the "semver:version" statement, you need to
import the module that has the prefix "semver".  But we can't just
import it like a normal import, b/c it has the semver: statement that
modifies how we do imports!



/matrin

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

Re: [netmod] adoption poll for yang-versioning-reqs-02

[Kent Watsen]

Hi Andy,

> Andy Bierman wrote:
> 
> BTW, I do not support adoption of the requirements document at all.

Can you say why?   Is it a blanket statement about adopting requirements drafts 
in general, or something specific to this draft.

Kent


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

Re: [netmod] adoption poll for yang-versioning-reqs-02

[Charles Eckel (eckelcu)]

Please see inline, marked with [cue].

From: netmod  on behalf of "Rob Wilton (rwilton)" 

Date: Wednesday, March 20, 2019 at 12:55 PM
To: Andy Bierman 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] adoption poll for yang-versioning-reqs-02

Hi Andy,

Thanks for the comments.

1. Regular Semver 2.0.0 (as per semver.org) allows some branching.  I.e. you 
can create version 2.0.0 based of version 1.1.0, and then subsequently create 
version 1.2.0 based of 1.1.0.  So structure wise this would logically look like:

   1.0.0
  | \
  |   1.1.0 – 1.2.0 - …
  |
   2.0.0
  |

I also raised https://github.com/semver/semver/issues/504  on the semver 2.0.0 
github to confirm that my interpretation is correct, and no one has disputed it 
yet.


2. Vendor software releases can have a very long support time (e.g. easily 5+ 
years), with an expectation that bugs get fixed.  Requiring that customers 
upgrade their software (or perhaps hardware) to the very latest software 
version to pick up a small bug fix is not realistic.  This is primarily why I 
think that the ‘m’ and ‘M’ are so important.  They allow for bug fixes in a way 
that Semver 2.0.0 simply does not.

Semver 2.0.0 only allows for bugfixes in the implementation (by updating the 
patch version number), but has the expectation that there are *never* any 
non-backwards-compatible changes in the API, not even to fix a bug, except at 
the tip of the development tree.

In short, I think that vanilla Semver 2.0.0 is a good fit for open source 
projects where you can just tell the client to update to the latest version to 
pick up the fix.  I don’t think that Semver 2.0.0 is so well aligned to APIs 
that are required to be maintained for long periods of time.
[cue]
Let me start by admitting that I am a YANG neophyte, so take this as a question 
rather than a suggestion, but would it make any sense to apply the semantics of 
Semver 2.0.0 for standard models and allow the use of something more 
expressive, such as that proposed in 
https://tools.ietf.org/html/draft-verdt-netmod-yang-versioning-reqs-02, for 
native models? My guess is that standard vs. native model is a distinction that 
we discuss and that is evident by YANG model name; however, a YANG compiler has 
no knowledge of this and makes no distinction. Nevertheless, I thought I’d 
throw it out there.

Cheers,
Charles


The alternative that Rob Shakir mentioned at IETF 103 in the context of 
OpenConfig, which uses strict Semver 2.0.0, is to handle these bug fixes using 
deviations.  But it seems to be significantly more complex to manage bug fixes 
using extra deviation modules rather than allowing the ‘m’ | ‘M’ modifiers.  
Versioning would no longer limited to a module version number, but require 
knowledge of the module version and set of deviations that are applied to it.  
I would rather deviations are reserved to indicate whether an implementation 
doesn’t match the module specification rather than use them as a way of fixing 
bugs in the specification itself.


3. I agree that the use of Semver + packages + version selection does not 
reduce the overall number of paths to a configurable property, but it does 
ensure that there is only a single path to a configurable property within a 
YANG datastore schema.   So whichever version each client is using, they only 
use a single path.  I.e. mirroring the way that a classic programming API might 
be versioned.

Servers that wish to support this would have to map the data between different 
YANG datastore schema versions.  Not all mappings are possible, but at least 
any cases where it is not possible can be detected and reported to the client 
via an out of band mechanism.

If the module content changes significantly between module versions that 
mapping will be much harder than if the changes are minimal or backwards 
compatible.  So there is still a strong incentive for model writers to minimize 
churn to the YANG models.

Thanks,
Rob


From: Andy Bierman 
Sent: 19 March 2019 18:35
To: Rob Wilton (rwilton) 
Cc: Martin Bjorklund ; kent+i...@watsen.net; netmod@ietf.org
Subject: Re: [netmod] adoption poll for yang-versioning-reqs-02



On Tue, Mar 19, 2019 at 9:38 AM Rob Wilton (rwilton) 
mailto:rwil...@cisco.com>> wrote:
Hi Martin,

Thanks for the review and comments.

A couple of points:

1) Lots of models outside those published in SDOs are already not following the 
RFC 7950 revision rules.  I think that it is better to have a versioning scheme 
that reflects how YANG models are actually evolving rather than have all vendor 
and OC YANG modules either just ignoring the rules, or using clever tricks that 
strictly conform with the rules but go against the spirit of them (e.g. just 
publish an entirely new set of YANG modules for each release).  Also noting 
that having a scheme that allows non-backwards-compatible changes does not 
require that everyone uses them - IETF could continue to always publish 
backwards compatible modules.  The 

Re: [netmod] artwork folding: dual support modes?

[Kent Watsen]

I’ve been thinking about Martin’s desire for the pretty single backslash 
approach.  I think the discussion should be about the probability of collisions 
(I.e., files that cannot be folded due to false positives)

Assuming 95 printable characters (127-32) plus ‘\n’, a total of 96 characters, 
the unconditioned probability of a given of an n-character string occurring on 
a line is (1/96)^n.

Here are the 3 options being discussed (please check my math!)

1. The pretty double backslash approach in the current draft
   - folds only on any column and supports indents

Scan the text content to ensure no existing lines already end with a backslash 
('\') character when the subsequent line starts with a backslash ('\') 
character as the first non-space (' ') character.

P(“\\\n[ ]*\\”)
  = sum of (1/96)^n for 3<=n<69
  = ∑((1÷96)^x; x; 3; 69)
  = 0.011421783625730994152046783625731
  ~= 1 / 1,000,000

2. The not pretty single backslash approach in I-D -06
   - folds only on max-column with no support for indents

Scan the artwork to ensure no existing lines already end with a '\' character 
on the desired maximum column.

 P(“.\{$maxcol-1\}\\\n”)
   = P( (not ‘\n’ for $maxcol-1 chars), followed by a “\\\n”)
   = ((1−(1÷96))^68)×(1÷96)^2
   = 0.532376463396105463857306859461496
~= 1 / 20,000

3. Martin’s pretty single backslash approach
   - folds only on any column and supports indents

Scan the artwork to ensure no existing lines already end with a '\' character 
OR that a white space character appears on the max column.

  P(“\\\n”) + P(“.\{$maxcol\} “)
= (1/96)^2 + ((1−(1÷96))^69)×(1÷96)
= 0.00516608334670744635108885960932866
~= 1 / 200

Note that each of these assume a long-line.  The number of long lines in a 
given piece of text is small, 1/100?  Thusly, while option #3 is two orders of 
magnitude more like than option #2, it may only be detected 1 / 200,000 text 
samples, that are themselves detected as needing to be folded (1/5?), so maybe 
one in a million text samples?

Maybe an automated folding algorithm could try #3 and, only if detecting the 
precondition, switch to option #1?

Kent // contributor 



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

Re: [netmod] adoption poll for yang-versioning-reqs-02

[Andy Bierman]

On Sun, Mar 24, 2019 at 11:39 AM Joel Jaeggli  wrote:

>
>
> On Mar 22, 2019, at 12:07, Lou Berger  wrote:
>
> Hi,
>
> Thank you all for the good input on this thread.
>
> With the understanding that a 00 working group document is a starting
> point for the working group rather than a document that is ready for last
> call - we believe there is sufficient support to adopt this document as a
> starting point for the requirements we wish to address on this topic.
>
> It is clear that there is still work to be done on this document before we
> can declare consensus on it and, not surprisingly, that there is more work
> to be done on the solution.
>
> Authors,
>
> Please resubmit this document as draft-ietf-netmod-yang-revision-reqs-00
> with the only change being the name and publication date.  The -01 version
> should focus on resolving issues raised during adoption.  Of course the
> document is subject to normal WG input and processing.
>
> Please note the 'file' name change -this is to indicate that the
> requirements are not presupposing a specific solution. It is also
> consistent with how versioning is defined within the document currently.
>
> Note: we would like to try to continue the list discussion in next week's
> session and ask the Authors/DT to summarize issues raised during the
> adoption call and lead a discussion to help resolve these issues.
>
> I think this meeting is great opportunity to decide what steps need to be
> taken to advance the document within the working group.
>
> Martin specifically objects to the presence of of Non-Backward-Compatible
> changes.
>
> Many modules outside the IETF are already incompatible with roc 7950 yang
> 1.1 revision rules. So that cat may be out of the bag at least with respect
> to the real world. the question remains what to do about that?
>
>

I do not look at the problem as allowing NBC so much as making it clear to
toolmakers what is going on,
like a deviation to the versioning rules.

BTW, I do not support adoption of the requirements document at all.
I support the work on versioning as part of the charter, and I am happy to
accept the design team solution draft as the starting point, and just work
on a solution.

But I think the solution is a bit flawed.

1) extensions are optional and problematic since they can be revisioned
without changing
the language version; the solution needs to use new YANG 1.2 statements
instead of extensions

2) the version string does not have to contain all the NBC semantics.
The solution draft does not show modified semver.
It should be done differently than overloading the version string;

Let's say a fork is done on 1.3.0.

 revision 2017-07-30 {
   description "Added leaf foo-64";
   semver:module-version "1.3.0";
 }

start with a legal change, just not at the HEAD

 revision 2019-01-10 {
   description "Added leaf bar-64";
   semver:module-version "1.3.1";
 }


then later, an NBC change

revision 2019-02-10 {
   description "Changed leaf bar-64 default-stmt";
   semver:module-version "1.3.2";
   semver:nbc-change;

 }

then later, a legal change

revision 2019-03-10 {
   description "Added leaf baz-64";
   semver:module-version "1.3.3";

 }


This is a form of an inline deviation-stmt.
The YANG update rules are not changing. They are just not being followed.


The NBC info belongs in the revision-stmt, not overloading the version string.
Not every major revision will mean NBC changes anyway.


Andy





>
>
> ___
> 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] adoption poll for yang-versioning-reqs-02

[Joel Jaeggli]

> On Mar 22, 2019, at 12:07, Lou Berger  wrote:
> 
> Hi,
> 
> Thank you all for the good input on this thread.
> 
> With the understanding that a 00 working group document is a starting point 
> for the working group rather than a document that is ready for last call - we 
> believe there is sufficient support to adopt this document as a starting 
> point for the requirements we wish to address on this topic.
> 
> It is clear that there is still work to be done on this document before we 
> can declare consensus on it and, not surprisingly, that there is more work to 
> be done on the solution.
> 
> Authors, 
> 
> Please resubmit this document as draft-ietf-netmod-yang-revision-reqs-00 with 
> the only change being the name and publication date.  The -01 version should 
> focus on resolving issues raised during adoption.  Of course the document is 
> subject to normal WG input and processing.
> 
> Please note the 'file' name change -this is to indicate that the requirements 
> are not presupposing a specific solution. It is also consistent with how 
> versioning is defined within the document currently.
> 
> Note: we would like to try to continue the list discussion in next week's 
> session and ask the Authors/DT to summarize issues raised during the adoption 
> call and lead a discussion to help resolve these issues.
> 
I think this meeting is great opportunity to decide what steps need to be taken 
to advance the document within the working group.

Martin specifically objects to the presence of of Non-Backward-Compatible 
changes. 

Many modules outside the IETF are already incompatible with roc 7950 yang 1.1 
revision rules. So that cat may be out of the bag at least with respect to the 
real world. the question remains what to do about that?




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

Re: [netmod] import-by-semver issue

[Andy Bierman]

On Sun, Mar 24, 2019 at 9:14 AM Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:

> On Sun, Mar 24, 2019 at 03:14:18PM +, Rob Wilton (rwilton) wrote:
> >
> > But that is true of YANG compilers today.  If there are multiple
> revisions of a module that could be chosen, then each compiler is at
> liberty to decide which revision to choose (last paragraph of section 5.1.1
> in RFC 7950).
> >
>
> The difference is that NBC changes are not allowed. As long as you
> find a certain symbol, it has fixed and predictable semantics.
>
> Sorry, but changing the way the import statement works is an NBC
> change of YANG and this can't be done with extensions.
>
>
I strongly agree.
The expected behavior for tools needs to be consistent, especially for
the construction of the schema tree, which depends on the import rules.

Implementation complexity should matter in the IETF, but it does not.
Just keep raising the complexity up to 10 and complain that the tools have
bugs,
as if the two are unrelated. (Simply looking for a hardwired string
"semver:version"
will not work since the prefix is not required to be "semver" in the
import-stmt.)




> /js
>


Andy


> --
> 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] import-by-semver issue

[Juergen Schoenwaelder]

On Sun, Mar 24, 2019 at 03:14:18PM +, Rob Wilton (rwilton) wrote:
> 
> But that is true of YANG compilers today.  If there are multiple revisions of 
> a module that could be chosen, then each compiler is at liberty to decide 
> which revision to choose (last paragraph of section 5.1.1 in RFC 7950).
>

The difference is that NBC changes are not allowed. As long as you
find a certain symbol, it has fixed and predictable semantics.

Sorry, but changing the way the import statement works is an NBC
change of YANG and this can't be done with extensions.

/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] import-by-semver issue

[Rob Wilton (rwilton)]

> -Original Message-
> From: Martin Bjorklund 
> Sent: 24 March 2019 16:22
> To: Rob Wilton (rwilton) 
> Cc: j.schoenwael...@jacobs-university.de; netmod@ietf.org
> Subject: Re: [netmod] import-by-semver issue
> 
> "Rob Wilton (rwilton)"  wrote:
> > Hi Juergen,
> >
> > > -Original Message-
> > > From: Juergen Schoenwaelder 
> > > Sent: 24 March 2019 15:31
> > > To: Rob Wilton (rwilton) 
> > > Cc: Andy Bierman ; NetMod WG
> 
> > > Subject: Re: [netmod] import-by-semver issue
> > >
> > > On Sun, Mar 24, 2019 at 02:07:15PM +, Rob Wilton (rwilton) wrote:
> > > > Hi Andy,
> > > >
> > > > There are many ways to write and design compilers.
> > > >
> > > > Compilers that don’t understand import-by-semver just ignore the
> > > > extension,
> > > no deviation is required.  They just import whichever arbitrary
> > > revision that they would have imported anyway, as specified by YANG
> > > 1.1.  The import-by-semver statement just reduces the set of valid
> > > modules revisions that can be used for import.
> > > >
> > >
> > > If two compilers (one supporting semver, the other not) resolve
> > > imports differently, then the design is in my view somewhat broken,
> > > in particular if you allow NBC changes.
> >
> > But that is true of YANG compilers today.  If there are multiple
> > revisions of a module that could be chosen, then each compiler is at
> > liberty to decide which revision to choose (last paragraph of section
> > 5.1.1 in RFC 7950).
> 
> This is by design, of course.  With an "open" import (not import by 
> revision), the
> server implementor is free to implement any set of modules that work together.
> 
> > So, I would argue that "import-by-version" doesn't make YANG compilers
> > any less consistent that they are already today, since that
> > inconsistency already exists.
> 
> I don't think I understand Andy's objection.   I also think that this
> is just another implementation detail.
> 
> > I presume that the real solution here is to explicitly define the full
> > set of implemented, import-only-modules to the compiler so that it
> > always compiles a consistent schema.  Perhaps other compilers have
> > different ways to solve this problem.
> >
> > Note, I also think that YANG library has a similar inconsistency.
> > I.e. there is no guarantee that two different compilers will construct
> > exactly the same datastore schema from the YANG library output.
> 
> Can you elaborate?  Given an instance of YANG library, it should be clear 
> which
> set of modules are used.

For modules that are "import-only" rather than "implemented" then some modules 
might use import-by-revision to import a specific revision, and other modules 
might just use import (without revision).  In this case, the compiler can 
choose which revision it uses to satisfy that import (e.g. getting different 
grouping definitions).

In draft-verdt-netmod-yang-semver-00, we aim to resolve this ambiguity with the 
following text that incorporates semver, a similar solution or just using the 
latest revision dates could also be devised:

5.2.  Resolving ambiguous module imports

   A YANG datastore schema, defined in [RFC8525], can specify multiple
   revisions of a YANG module in the schema using the 'import-only'
   list, with the requirement from [RFC7950] that only a single revision
   of a YANG module may be implemented.

   If a YANG module import statement does not specify a specific version
   or revision within the datastore schema then it could be ambiguous as
   to which module revision the import statement should resolve to.
   Hence, a datastore schema constructed by a client using the
   information contained in YANG library may not exactly match the
   datastore schema actually used by the server.

   The following rules remove the ambiguity:

   If a module import statement could resolve to more than one module
   revision defined in the datastore schema, and one of those revisions
   is implemented (i.e., not an 'import-only' module), then the import
   statement MUST resolve to the revision of the module that is defined
   as being implemented by the datastore schema.

   If a module import statement could resolve to more than one module
   revision defined in the datastore schema, and none of those revisions
   are implemented, but one of more modules revisions specify a YANG
   semantic version, then the import MUST resolve to the module with the
   greatest version number, according to the version comparison rules in
   Section 3.

   If a module import statement could resolve to more than one module
   revision defined in the datastore schema, none of those revisions are
   implemented, and none of the modules revisions have a YANG semantic
   version number, then the import MUST resolve to the module that has
   the most recent revision date.

Thanks,
Rob


> 
> 
> 
> > I
> > think that this is a design bug, but also one that we attempt to
> > address in draft-verdt-netmod-yang-semver-00.
> >
> 

Re: [netmod] import-by-semver issue

[Martin Bjorklund]

"Rob Wilton (rwilton)"  wrote:
> Hi Juergen,
> 
> > -Original Message-
> > From: Juergen Schoenwaelder 
> > Sent: 24 March 2019 15:31
> > To: Rob Wilton (rwilton) 
> > Cc: Andy Bierman ; NetMod WG 
> > Subject: Re: [netmod] import-by-semver issue
> > 
> > On Sun, Mar 24, 2019 at 02:07:15PM +, Rob Wilton (rwilton) wrote:
> > > Hi Andy,
> > >
> > > There are many ways to write and design compilers.
> > >
> > > Compilers that don’t understand import-by-semver just ignore the
> > > extension,
> > no deviation is required.  They just import whichever arbitrary
> > revision that they
> > would have imported anyway, as specified by YANG 1.1.  The
> > import-by-semver
> > statement just reduces the set of valid modules revisions that can be
> > used for
> > import.
> > >
> > 
> > If two compilers (one supporting semver, the other not) resolve
> > imports
> > differently, then the design is in my view somewhat broken, in
> > particular if you
> > allow NBC changes.
> 
> But that is true of YANG compilers today.  If there are multiple
> revisions of a module that could be chosen, then each compiler is at
> liberty to decide which revision to choose (last paragraph of section
> 5.1.1 in RFC 7950).

This is by design, of course.  With an "open" import (not import by
revision), the server implementor is free to implement any set of
modules that work together.

> So, I would argue that "import-by-version" doesn't make YANG compilers
> any less consistent that they are already today, since that
> inconsistency already exists.

I don't think I understand Andy's objection.   I also think that this
is just another implementation detail.

> I presume that the real solution here is to explicitly define the full
> set of implemented, import-only-modules to the compiler so that it
> always compiles a consistent schema.  Perhaps other compilers have
> different ways to solve this problem.
> 
> Note, I also think that YANG library has a similar inconsistency.
> I.e. there is no guarantee that two different compilers will construct
> exactly the same datastore schema from the YANG library output.

Can you elaborate?  Given an instance of YANG library, it should be
clear which set of modules are used.



> I
> think that this is a design bug, but also one that we attempt to
> address in draft-verdt-netmod-yang-semver-00.
> 
> Thanks,
> Rob
> 
> > 
> > /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
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] import-by-semver issue

[Rob Wilton (rwilton)]

Hi Juergen,

> -Original Message-
> From: Juergen Schoenwaelder 
> Sent: 24 March 2019 15:31
> To: Rob Wilton (rwilton) 
> Cc: Andy Bierman ; NetMod WG 
> Subject: Re: [netmod] import-by-semver issue
> 
> On Sun, Mar 24, 2019 at 02:07:15PM +, Rob Wilton (rwilton) wrote:
> > Hi Andy,
> >
> > There are many ways to write and design compilers.
> >
> > Compilers that don’t understand import-by-semver just ignore the extension,
> no deviation is required.  They just import whichever arbitrary revision that 
> they
> would have imported anyway, as specified by YANG 1.1.  The import-by-semver
> statement just reduces the set of valid modules revisions that can be used for
> import.
> >
> 
> If two compilers (one supporting semver, the other not) resolve imports
> differently, then the design is in my view somewhat broken, in particular if 
> you
> allow NBC changes.

But that is true of YANG compilers today.  If there are multiple revisions of a 
module that could be chosen, then each compiler is at liberty to decide which 
revision to choose (last paragraph of section 5.1.1 in RFC 7950).

So, I would argue that "import-by-version" doesn't make YANG compilers any less 
consistent that they are already today, since that inconsistency already exists.

I presume that the real solution here is to explicitly define the full set of 
implemented, import-only-modules to the compiler so that it always compiles a 
consistent schema.  Perhaps other compilers have different ways to solve this 
problem.

Note, I also think that YANG library has a similar inconsistency.  I.e. there 
is no guarantee that two different compilers will construct exactly the same 
datastore schema from the YANG library output.  I think that this is a design 
bug, but also one that we attempt to address in 
draft-verdt-netmod-yang-semver-00.

Thanks,
Rob

> 
> /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] import-by-semver issue

[Juergen Schoenwaelder]

On Sun, Mar 24, 2019 at 02:07:15PM +, Rob Wilton (rwilton) wrote:
> Hi Andy,
> 
> There are many ways to write and design compilers.
> 
> Compilers that don’t understand import-by-semver just ignore the extension, 
> no deviation is required.  They just import whichever arbitrary revision that 
> they would have imported anyway, as specified by YANG 1.1.  The 
> import-by-semver statement just reduces the set of valid modules revisions 
> that can be used for import.
>

If two compilers (one supporting semver, the other not) resolve
imports differently, then the design is in my view somewhat broken,
in particular if you allow NBC changes.

/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] import-by-semver issue

[Rob Wilton (rwilton)]

Hi Andy,

There are many ways to write and design compilers.

Compilers that don’t understand import-by-semver just ignore the extension, no 
deviation is required.  They just import whichever arbitrary revision that they 
would have imported anyway, as specified by YANG 1.1.  The import-by-semver 
statement just reduces the set of valid modules revisions that can be used for 
import.

Thanks,
Rob


From: Andy Bierman 
Sent: 24 March 2019 12:07
To: Rob Wilton (rwilton) 
Cc: NetMod WG 
Subject: Re: [netmod] import-by-semver issue



On Sun, Mar 24, 2019 at 2:40 AM Rob Wilton (rwilton) 
mailto:rwil...@cisco.com>> wrote:
Hi Andy,

Yes we are currently implementing the module version field, although that may 
change depending on what different the final solution ends up being.

Support for import-by-version is less critical for us, and hence implementation 
would lag.

In terms of the issue that you raise:

-I would expect that a compiler that understands semver to preload the 
semver extension, possibly allow with other common YANG type files, extensions).

-For a compile that doesn’t understand semver then it would just ignore 
the extension, which should be fine.


Try to find even 1 compiler in the world that works this way.
Yes you can specially hack the extension implementation as if it were a 
built-in keyword.

I agree that it would be nice if this extension was part of the core YANG 
language, but I don’t think that is necessarily required.


I don't think any of semver is required for anything.
IMO it provides a minor improvement to  people familiar with the 
MAJOR.MINOR.PATCH numbering.
This improvement is lost as soon as extra letters are added and the string is 
no longer familiar.

Import-by-semver seems like it is part of the base module (no if-feature on the 
extension-stmt is even possible)
so skipping the implementation of it needs a deviation (oh wait, YANG 1.1 can't 
do that either).


Thanks,
Rob

Andy



From: netmod mailto:netmod-boun...@ietf.org>> On 
Behalf Of Andy Bierman
Sent: 23 March 2019 19:01
To: NetMod WG mailto:netmod@ietf.org>>
Subject: [netmod] import-by-semver issue

Hi,

I am wondering if there are implementations of this draft:

https://tools.ietf.org/html/draft-verdt-netmod-yang-semver-00


Specifically, implementation of the  'version' extension

https://tools.ietf.org/html/draft-verdt-netmod-yang-semver-00#section-3


IMO it is a really bad idea to put the semantics of how to import modules
in one of the modules that is imported.  Your example shows ietf-semver
imported first with no extension, but it could be last with a version extension.

  // all other imports, then last


import ietf-semver {

  prefix "semver";

  semver:version 1.1.2;

}

Translation unit parsing is something that needs to be built into the compiler.
This should be part of YANG 1.2 if it is done.



  import example-module {

 prefix exmod;

 version 1.2.0+;

   }


To a compiler writer, the difference is huge. (ietf-semver extensions need to
be built-in statements in YANG, at least 'version')


BTW, all the import examples are missing the mandatory prefix-stmt


Andy

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

Re: [netmod] import-by-semver issue

[Andy Bierman]

On Sun, Mar 24, 2019 at 2:40 AM Rob Wilton (rwilton) 
wrote:

> Hi Andy,
>
>
>
> Yes we are currently implementing the module version field, although that
> may change depending on what different the final solution ends up being.
>
>
>
> Support for import-by-version is less critical for us, and hence
> implementation would lag.
>
>
>
> In terms of the issue that you raise:
>
> -I would expect that a compiler that understands semver to
> preload the semver extension, possibly allow with other common YANG type
> files, extensions).
>
> -For a compile that doesn’t understand semver then it would just
> ignore the extension, which should be fine.
>
>
>

Try to find even 1 compiler in the world that works this way.
Yes you can specially hack the extension implementation as if it were a
built-in keyword.

I agree that it would be nice if this extension was part of the core YANG
> language, but I don’t think that is necessarily required.
>
>
>

I don't think any of semver is required for anything.
IMO it provides a minor improvement to  people familiar with the
MAJOR.MINOR.PATCH numbering.
This improvement is lost as soon as extra letters are added and the string
is no longer familiar.

Import-by-semver seems like it is part of the base module (no if-feature on
the extension-stmt is even possible)
so skipping the implementation of it needs a deviation (oh wait, YANG 1.1
can't do that either).


Thanks,
>
> Rob
>
>
Andy


>
>
>
>
> *From:* netmod  *On Behalf Of *Andy Bierman
> *Sent:* 23 March 2019 19:01
> *To:* NetMod WG 
> *Subject:* [netmod] import-by-semver issue
>
>
>
> Hi,
>
>
>
> I am wondering if there are implementations of this draft:
>
>
>
> https://tools.ietf.org/html/draft-verdt-netmod-yang-semver-00
>
>
>
>
>
> Specifically, implementation of the  'version' extension
>
>
>
> https://tools.ietf.org/html/draft-verdt-netmod-yang-semver-00#section-3
>
>
>
>
>
> IMO it is a really bad idea to put the semantics of how to import modules
>
> in one of the modules that is imported.  Your example shows ietf-semver
>
> imported first with no extension, but it could be last with a version
> extension.
>
>
>
>   // all other imports, then last
>
>
>
> import ietf-semver {
>
>   prefix "semver";
>
>   semver:version 1.1.2;
>
> }
>
>
> Translation unit parsing is something that needs to be built into the
> compiler.
>
> This should be part of YANG 1.2 if it is done.
>
>
>
>   import example-module {
>
>  prefix exmod;
>
>  version 1.2.0+;
>
>}
>
>
>
> To a compiler writer, the difference is huge. (ietf-semver extensions need
> to
>
> be built-in statements in YANG, at least 'version')
>
>
>
> BTW, all the import examples are missing the mandatory prefix-stmt
>
>
>
>
>
> Andy
>
>
>
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] import-by-semver issue

[Rob Wilton (rwilton)]

Hi Andy,

Yes we are currently implementing the module version field, although that may 
change depending on what different the final solution ends up being.

Support for import-by-version is less critical for us, and hence implementation 
would lag.

In terms of the issue that you raise:

-I would expect that a compiler that understands semver to preload the 
semver extension, possibly allow with other common YANG type files, extensions).

-For a compile that doesn’t understand semver then it would just ignore 
the extension, which should be fine.

I agree that it would be nice if this extension was part of the core YANG 
language, but I don’t think that is necessarily required.

Thanks,
Rob


From: netmod  On Behalf Of Andy Bierman
Sent: 23 March 2019 19:01
To: NetMod WG 
Subject: [netmod] import-by-semver issue

Hi,

I am wondering if there are implementations of this draft:

https://tools.ietf.org/html/draft-verdt-netmod-yang-semver-00


Specifically, implementation of the  'version' extension

https://tools.ietf.org/html/draft-verdt-netmod-yang-semver-00#section-3


IMO it is a really bad idea to put the semantics of how to import modules
in one of the modules that is imported.  Your example shows ietf-semver
imported first with no extension, but it could be last with a version extension.

  // all other imports, then last


import ietf-semver {

  prefix "semver";

  semver:version 1.1.2;

}

Translation unit parsing is something that needs to be built into the compiler.
This should be part of YANG 1.2 if it is done.



  import example-module {

 prefix exmod;

 version 1.2.0+;

   }


To a compiler writer, the difference is huge. (ietf-semver extensions need to
be built-in statements in YANG, at least 'version')



BTW, all the import examples are missing the mandatory prefix-stmt


Andy

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