Re: [netmod] comments on YANG versioning
On Wed, Nov 14, 2018 at 7:48 AM Robert Wilton wrote: > Hi Martin, > On 14/11/2018 11:48, Martin Bjorklund wrote: > > Hi, > > Robert Wilton wrote: > > On 08/11/2018 22:52, Andy Bierman wrote: > > Hi, > > A few comments on the netmod meeting yesterday > > 1) what is a bugfix? > It is not encouraging that the DT cannot agree on the scope of a > bugfix. > But not sure it matters if NBC updates can occur for any reason. > IMO it is easy to define a bugfix in the IETF -- it is called an > Errata. > If an Errata is approved for a YANG module in an RFC then it is a > bugfix. > > Ultimately we have customers that will say "this part of your YANG is > broken" and we want you to fix it in that release train, either in the > next release, or as a software patch. > > Sometimes vendors will disagree with their customers as to whether it > is really a bug fix or an enhancement. Sometimes we will fix what we > think is an obvious bug but that will unfortunately break another > customer whom was relying on the existing behavior and then ask us to > revert the fix. > > I think that it should be down to the module author/owner to decide > whether or not it is a bug fix or an enhancement, and I would just > like a versioning scheme that allows these changes to be expressed. > > So the requirement is that the versioning scheme must support > branching, and must support expressing NBC changes on any version? > > I deem that 1.4 (without the sentence about versioning by software > release) defines this: > >1.4 The solution MUST allow for backwards-compatible > enhancements and bug fixes to be allowed in any non-latest > release. > > Although this text is ambiguous, perhaps stating it more clearly, I see > the requirement as: > >1.4 The solution MUST allow for backwards-compatible > enhancements, and backward-compatible or non-backwards compatible > bug fixes to be allowed in non-latest releases. > > > This new 1.4 (2nd one) is much better. Thanks for rewriting it. Andy > This requirement isn't present in the current draft, AFAICT. > > (not that I support it as a requirement) > > But vendors *have* to do this today. I don't think telling our customers > that no, we can't fix that bug, because the versioning scheme doesn't allow > it is really pragmatic. > > Rob Shakir also indicated in the Netmod meeting that he does not support > this requirement. However, this conflicts with the fact that there are > examples in OpenConfig when it has been necessary to apply fixes to older > versions, which has been achieved using deviations. > > > None of this changes the fact that I think that we should be avoiding > making these changes in the first place. I.e. I think that there is a > clear separation between what the versioning scheme should be able to > express, and what is recommended practice. > > > > 2) SEMVER to the rescue? > If every module release can be its own feature release train then the > value of > ascending numeric identifiers is greatly diminished. The (m) and (M) > tags > do not really help. I strongly agree with the comment that > cherry-picking new > features can (and should) be done with deviations. Updates of old > revisions needs to be for bugfixes only. > > I prefer the OpenConfig "SEMVER Classic" rather than introducing a new > incompatible complex numbering scheme to support something that > should not be done anyway. > > SEMVER classic does not support making bug fixes (even bc ones) on > older releases. > > In an older release, SEMVER classic allows: > - editorial changes, e.g. spelling corrections or clarifications in > description statements that do not change the API semantics in anyway. > - bug fixes to the *implementation*, but then we are not using SEMVER > to version the implementation anyway, only the API. > > If you want to allow bug fixes (even just bc ones) in an older release > then you either need something like modified semver, or a different > versioning scheme that allows them. Or you do what Rob Shakir > suggests and use deviations for this instead, which I think is a > misuse of deviations. > > But, as you state in the solution draft, not even modified semver can > determine if a specific change is NBC or not. It seems you would need > the entire history to determine this - which goes against the original > idea that a client should be able to easily determine if a new version > is NBC or not, compared to the version the client knows. > > The (m|M) is intended to be a tool of last resort. So provide a mechanism > to make bug fixes to older versions, but don't encourage it. It provides a > mechanism to provide bug fixes on an existing release, but at the cost that > you lose some of the benefits of semver (which is unavoidable). > > If the server is on a version of the form "A.B.X(m)" then the client knows > that all changes between "A.B.0" and "A.B.X(m)" are backwards compatible. > If the version is
Re: [netmod] Confirming draft-ietf-netmod-module-tags-03 consensus call
On 14/11/2018 16:43, Christian Hopps wrote: On Nov 14, 2018, at 10:14 AM, Robert Wilton wrote: Hi Chris, On 14/11/2018 13:46, Christian Hopps wrote: Do you have similar objections over comments in CLI config files? No, not at all. But one difference here is that the tags are bound to modules, not to the config, or config paths. This has nothing to do with the point I am addressing that you and Alex raised regarding "Servers not using the tags so why should they store them". My point was not that "servers shouldn't have to do this", but more "it is isn't obvious why operators want servers to do this". The answer is: 1) B/c there's literally no where else they could be stored (no way for a vendor to add tags) 2) There are other examples of servers storing things they don't use like comments, so "server not using what it stores" isn't a reason to not store them on the server in the first place. Regarding the rest. Maybe we should write a requirements draft and a use cases draft for the use of meta-data/tags for organizing things. That is not what I was suggesting. I was suggesting text something like this: Introduction: OLD: The use of tags for classification and organization is fairly ubiquitous not only within IETF protocols, but in the internet itself (e.g., #hashtags). Tags can be usefully standardized, but they can also serve as a non-standardized mechanism available for users to define themselves. Our solution provides for both cases allowing for the most flexibility. In particular, tags may be standardized as well as assigned during module definition; assigned by implementations; or dynamically defined and set by users. NEW: The use of tags for classification and organization is fairly ubiquitous not only within IETF protocols, but in the internet itself (e.g., #hashtags). One benefit of using tags for organization over a rigid structure is that it is more flexible and can more easily adapt over time as technologies evolve. Tags can be usefully standardized, but they can also serve as a non-standardized mechanism available for users to define themselves. This document provides a mechanism to define tags and associate them with YANG modules in a flexible manner. In particular, tags may be standardized as well as assigned during module definition; assigned by implementations; or dynamically defined and set by users. NEW: 1.1 Some example use cases of YANG module tags Tags can be used to help filter different discrete categories of YANG modules supported by a device. E.g., if modules are suitably tagged, then an XPath query can be used to list all of the vendor modules supported by a device. Tags can also be used to help coordination when multiple semi-independent clients are interacting with the same devices. E.g., one management client could mark that some modules should not be used because they have not been verified to behave correctly, so that other management clients avoid querying the data associated with those modules. Tag classification is useful for users searching module repositories (e.g. YANG catalog). A query restricted to the 'ietf:routing' module tag could be used to return only the IETF YANG modules associated with routing. Without tags, a user would need to know the name of all the IETF routing protocol YANG modules. Future management protocol extensions could allow for filtering queries of configuration or operational state on a server based on tags. E.g., return all operational state related to system-management. If you think that this text is helpful, and it allowed, then please add it, refining as required. If you think that it detracts from the clarify of document, and is superfluous then leave it out, that is also fine with me ... Thanks, Rob And maybe let's put this work on hold until we can find someone that is willing to do all that busy work. I understand more and more why openconfig exists. Thanks, Chris. Routers (the server) certainly don't use those and clients write them and read them -- yet they are stored on the server. Perhaps if you thought of there being more than just one client possible this might all make more sense? Yes, perhaps. Regarding the yang library you keep bringing up. This was in the work originally and the WG decided that we should remove it. Sorry, I had missed the WG discussion where this was removed. But OK. I do not think the tail end of a WGLC is an appropriate time or place to start wondering out loud about whether it would be a good to have. I admit to being confused by this since I believe you were actively participating WRT this work when it had the yang library augmentation as well as after we removed it. My apologies, but I had intended to review this more thoroughly during the WG LC but ran out of time. If was when I read Alex's comments that I thought that he was raising some valid points. The key one that struck a chord is that
Re: [netmod] Confirming draft-ietf-netmod-module-tags-03 consensus call
Hi,
I think there are some legitimate issues that should be addressed for this
work to go forward
wrt/ how it will be used.
1) IANA registry: is this really needed at all? Doesn't the module-tag
extension
make the registry unnecessary?
2) Standard solution: will there be one or is the intent to have
proprietary solutions
to actually utilize module-tags?
3) If there is going to be a standard protocol solution to use module-tags,
then is it
really wise to nail down the tag format before starting work on mechanisms
that use
module tags?
4) How do I distinguish openconfig from mef from bbf from my router vendor?
All their tags seem to share the same prefix "vendor:" What if I want to
match all routing modules? Then the prefix actually gets in the way because
I have to specify 3 tags ("ietf:routing", "vendor:routing" and
"user:routing")
5) Who decides what module tags apply to a new IETF YANG module?
Is it each independent WG? A design team? The IESG? What guidelines exist
for reviewers to determine if the correct module tags have been assigned?
I do not agree this work is being held up because there is no way to use
a module-tag with any standard protocols.
Andy
On Wed, Nov 14, 2018 at 8:44 AM Christian Hopps wrote:
>
>
> > On Nov 14, 2018, at 10:14 AM, Robert Wilton wrote:
> >
> > Hi Chris,
> >
> > On 14/11/2018 13:46, Christian Hopps wrote:
> >> Do you have similar objections over comments in CLI config files?
> >
> > No, not at all.
> >
> > But one difference here is that the tags are bound to modules, not to
> the config, or config paths.
>
> This has nothing to do with the point I am addressing that you and Alex
> raised regarding "Servers not using the tags so why should they store them".
>
> The answer is:
>
> 1) B/c there's literally no where else they could be stored (no way for a
> vendor to add tags)
> 2) There are other examples of servers storing things they don't use like
> comments, so "server not using what it stores" isn't a reason to not store
> them on the server in the first place.
>
> Regarding the rest. Maybe we should write a requirements draft and a use
> cases draft for the use of meta-data/tags for organizing things.
>
> And maybe let's put this work on hold until we can find someone that is
> willing to do all that busy work.
>
> I understand more and more why openconfig exists.
>
> Thanks,
> Chris.
>
> >
> >> Routers (the server) certainly don't use those and clients write them
> and read them -- yet they are stored on the server. Perhaps if you thought
> of there being more than just one client possible this might all make more
> sense?
> >
> > Yes, perhaps.
> >
> >
> >>
> >> Regarding the yang library you keep bringing up. This was in the work
> originally and the WG decided that we should remove it.
> >
> > Sorry, I had missed the WG discussion where this was removed. But OK.
> >
> >
> >> I do not think the tail end of a WGLC is an appropriate time or place
> to start wondering out loud about whether it would be a good to have. I
> admit to being confused by this since I believe you were actively
> participating WRT this work when it had the yang library augmentation as
> well as after we removed it.
> >
> > My apologies, but I had intended to review this more thoroughly during
> the WG LC but ran out of time. If was when I read Alex's comments that I
> thought that he was raising some valid points. The key one that struck a
> chord is that this document describes a solution but doesn't seem to
> clearly describe what problem it is solving (other than tags are good), or
> how it is intending to be used. When I reviewed this document after
> reading Alex's comments, I was asking myself how this was going to be used,
> and the answer I came up with was that I didn't really know. Or the case
> that I had in mind (YANG catalog filtering on module tag) doesn't seem to
> match the authors envisaged use cases. Looking back at some of the
> previous comments on this work (not just Alex), others have also questioned
> what problem it is solving and how it will be used.
> >
> >
> >> I'm OK with taking the editorial suggestions. I'm not so OK with going
> back and redoing this document or it's fundamental design at the tail end
> of a WGLC. Unless the WG agrees that it's truly broken. This would be
> pretty odd given it seemed like we were done, including during the 103
> meeting in which you were in attendance.
> >>
> >> You say your not trying to hold the work up; however, that is exactly
> what your last minute public pondering is doing.
> >
> > Yes, I admit that I should have reviewed it earlier. My aim is not to
> slow it down but to ensure that the document is as clear as possible. As
> I've said lots of times, I like the idea of tags for classifying YANG
> modules :-)
> >
> > Given all that, it is still my opinion that this document would benefit
> from the introduction being slightly clearer on the specific problem being
> solved - e.g. I think that the
Re: [netmod] Confirming draft-ietf-netmod-module-tags-03 consensus call
> On Nov 14, 2018, at 10:14 AM, Robert Wilton wrote: > > Hi Chris, > > On 14/11/2018 13:46, Christian Hopps wrote: >> Do you have similar objections over comments in CLI config files? > > No, not at all. > > But one difference here is that the tags are bound to modules, not to the > config, or config paths. This has nothing to do with the point I am addressing that you and Alex raised regarding "Servers not using the tags so why should they store them". The answer is: 1) B/c there's literally no where else they could be stored (no way for a vendor to add tags) 2) There are other examples of servers storing things they don't use like comments, so "server not using what it stores" isn't a reason to not store them on the server in the first place. Regarding the rest. Maybe we should write a requirements draft and a use cases draft for the use of meta-data/tags for organizing things. And maybe let's put this work on hold until we can find someone that is willing to do all that busy work. I understand more and more why openconfig exists. Thanks, Chris. > >> Routers (the server) certainly don't use those and clients write them and >> read them -- yet they are stored on the server. Perhaps if you thought of >> there being more than just one client possible this might all make more >> sense? > > Yes, perhaps. > > >> >> Regarding the yang library you keep bringing up. This was in the work >> originally and the WG decided that we should remove it. > > Sorry, I had missed the WG discussion where this was removed. But OK. > > >> I do not think the tail end of a WGLC is an appropriate time or place to >> start wondering out loud about whether it would be a good to have. I admit >> to being confused by this since I believe you were actively participating >> WRT this work when it had the yang library augmentation as well as after we >> removed it. > > My apologies, but I had intended to review this more thoroughly during the WG > LC but ran out of time. If was when I read Alex's comments that I thought > that he was raising some valid points. The key one that struck a chord is > that this document describes a solution but doesn't seem to clearly describe > what problem it is solving (other than tags are good), or how it is intending > to be used. When I reviewed this document after reading Alex's comments, I > was asking myself how this was going to be used, and the answer I came up > with was that I didn't really know. Or the case that I had in mind (YANG > catalog filtering on module tag) doesn't seem to match the authors envisaged > use cases. Looking back at some of the previous comments on this work (not > just Alex), others have also questioned what problem it is solving and how it > will be used. > > >> I'm OK with taking the editorial suggestions. I'm not so OK with going back >> and redoing this document or it's fundamental design at the tail end of a >> WGLC. Unless the WG agrees that it's truly broken. This would be pretty odd >> given it seemed like we were done, including during the 103 meeting in which >> you were in attendance. >> >> You say your not trying to hold the work up; however, that is exactly what >> your last minute public pondering is doing. > > Yes, I admit that I should have reviewed it earlier. My aim is not to slow > it down but to ensure that the document is as clear as possible. As I've > said lots of times, I like the idea of tags for classifying YANG modules :-) > > Given all that, it is still my opinion that this document would benefit from > the introduction being slightly clearer on the specific problem being solved > - e.g. I think that the abstract is more clear than the introduction, and > also think that the document would benefit having some examples of how module > tags could be used. > > But I appreciate that my comments are after the WGLC and have no issues if > the authors/chairs decide that they are too late. After all, no one else, > other than Alex, has expressed any concern. > > Thanks, > Rob > > >> >> Thanks, >> Chris. >> >>> On Nov 14, 2018, at 5:04 AM, Robert Wilton wrote: >>> >>> Hi Chris, >>> >>> On 13/11/2018 21:05, Christian Hopps wrote: The servers implement the modules which can have predefined tags from the module designer as well as the implementer (vendor) which literally cannot come from anywhere *but* the server that implements the module. >>> Clients should also be able to know find out the predefined tags from the >>> module definition. I agree that the any tags added by the implementation >>> can only be known by querying the server, although its not obvious to me >>> what those tags would be. E.g. if Cisco had a YANG module for EIGRP and >>> wanted to give it the ietf:protocol and ietf:routing tag then it would >>> ideally use the extension and put it in the YANG file. >>> This is not what I thought would hold this work up. >>> Sorry, I'm
Re: [netmod] comments on YANG versioning
On 14/11/2018 16:04, Martin Bjorklund wrote:
Robert Wilton wrote:
Hi Martin,
On 14/11/2018 11:48, Martin Bjorklund wrote:
Hi,
Robert Wilton wrote:
On 08/11/2018 22:52, Andy Bierman wrote:
Hi,
A few comments on the netmod meeting yesterday
1) what is a bugfix?
It is not encouraging that the DT cannot agree on the scope of a
bugfix.
But not sure it matters if NBC updates can occur for any reason.
IMO it is easy to define a bugfix in the IETF -- it is called an
Errata.
If an Errata is approved for a YANG module in an RFC then it is a
bugfix.
Ultimately we have customers that will say "this part of your YANG is
broken" and we want you to fix it in that release train, either in the
next release, or as a software patch.
Sometimes vendors will disagree with their customers as to whether it
is really a bug fix or an enhancement. Sometimes we will fix what we
think is an obvious bug but that will unfortunately break another
customer whom was relying on the existing behavior and then ask us to
revert the fix.
I think that it should be down to the module author/owner to decide
whether or not it is a bug fix or an enhancement, and I would just
like a versioning scheme that allows these changes to be expressed.
So the requirement is that the versioning scheme must support
branching, and must support expressing NBC changes on any version?
I deem that 1.4 (without the sentence about versioning by software
release) defines this:
1.4 The solution MUST allow for backwards-compatible
enhancements and bug fixes to be allowed in any non-latest
release.
Although this text is ambiguous, perhaps stating it more clearly, I
see the requirement as:
1.4 The solution MUST allow for backwards-compatible
enhancements, and backward-compatible or non-backwards compatible
bug fixes to be allowed in non-latest releases.
This requirement isn't present in the current draft, AFAICT.
(not that I support it as a requirement)
But vendors *have* to do this today. I don't think telling our
customers that no, we can't fix that bug, because the versioning
scheme doesn't allow it is really pragmatic.
The pragmatic thing to do is to violate the rule when you think your
customers can accept it, and introduce a NBC even though it doesn't
follow 7950 section 11 rules.
Yes, but say we adopt vanilla semver, it cannot express this as an NBC
change, or even as a BC change!
Say the released software on the server is using module version 1.2.0.
Module versions 1.3.0 and 2.0.0 already exist with new added
functionality (that we can't/won't backport)
Is it really right to label the fixed version as a patch update (e.g.
going from 1.2.0 to 1.2.1, which semver states is an editorial change)
even through it is actually an NBC change and could break some clients?
This is the reason that I introduced the modified semver scheme, so that
it could be labelled as "1.2.1(M)". I.e. the client can easily
determine that it is an NBC update.
Of course, if there isn't a "2.0.0" version at the time that an NBC fix
is made to 1.2.0 then it should follow the normal semver rules and use
"2.0.0" instead. The "(m|M)" notation is only used whether there isn't
a semver number available to use because it has already been used for
new development. Similarly, if the code change that was present in
"1.3.0" was only an BC bugfix, and if the fix being made was BC, then it
would be recommended to use "1.4.0" for the bug fix version. I.e.
although I don't think that it pragmatic to require that new
functionality be backported to an old release to pick up a bug fix, it
does seem more pragmatic to think that a bug fix could be back ported to
an older software release, if required. But ultimately I think that it
is at the discretion of the module author to decide where to put the
fix, with the suggestion that if it is created as "1.2.1(M)" then the
fix should probably also be made to head of the tree ("3.0.0") as well.
The real aim of the modified semver solution is to be able to describe
these changes, rather than say that they are good or bad. Hence
guidance would be provided to recommend how they are used.
---
If the modified semver solution is really disliked, then an alternative
is to just not use semver, and use a 3 digit version number, e.g. as I
proposed to Juergen yesterday, when the "patch" field always means bug
fix. This has the downside that it is incompatible with what OpenConfig
is doing though, and clients would have to use a schema compare tool to
understand the changes between two modules.
Rob Shakir also indicated in the Netmod meeting that he does not
support this requirement. However, this conflicts with the fact that
there are examples in OpenConfig when it has been necessary to apply
fixes to older versions, which has been achieved using deviations.
None of this changes the fact that I think that we should be
Re: [netmod] comments on YANG versioning
Robert Wilton wrote: > Hi Martin, > > On 14/11/2018 11:48, Martin Bjorklund wrote: > > Hi, > > > > Robert Wilton wrote: > >> On 08/11/2018 22:52, Andy Bierman wrote: > >>> Hi, > >>> > >>> A few comments on the netmod meeting yesterday > >>> > >>> 1) what is a bugfix? > >>> It is not encouraging that the DT cannot agree on the scope of a > >>> bugfix. > >>> But not sure it matters if NBC updates can occur for any reason. > >>> IMO it is easy to define a bugfix in the IETF -- it is called an > >>> Errata. > >>> If an Errata is approved for a YANG module in an RFC then it is a > >>> bugfix. > >> Ultimately we have customers that will say "this part of your YANG is > >> broken" and we want you to fix it in that release train, either in the > >> next release, or as a software patch. > >> > >> Sometimes vendors will disagree with their customers as to whether it > >> is really a bug fix or an enhancement. Sometimes we will fix what we > >> think is an obvious bug but that will unfortunately break another > >> customer whom was relying on the existing behavior and then ask us to > >> revert the fix. > >> > >> I think that it should be down to the module author/owner to decide > >> whether or not it is a bug fix or an enhancement, and I would just > >> like a versioning scheme that allows these changes to be expressed. > > So the requirement is that the versioning scheme must support > > branching, and must support expressing NBC changes on any version? > > I deem that 1.4 (without the sentence about versioning by software > release) defines this: > >1.4 The solution MUST allow for backwards-compatible > enhancements and bug fixes to be allowed in any non-latest > release. > > Although this text is ambiguous, perhaps stating it more clearly, I > see the requirement as: > >1.4 The solution MUST allow for backwards-compatible > enhancements, and backward-compatible or non-backwards compatible > bug fixes to be allowed in non-latest releases. > > > > > > This requirement isn't present in the current draft, AFAICT. > > > > (not that I support it as a requirement) > > But vendors *have* to do this today. I don't think telling our > customers that no, we can't fix that bug, because the versioning > scheme doesn't allow it is really pragmatic. The pragmatic thing to do is to violate the rule when you think your customers can accept it, and introduce a NBC even though it doesn't follow 7950 section 11 rules. > Rob Shakir also indicated in the Netmod meeting that he does not > support this requirement. However, this conflicts with the fact that > there are examples in OpenConfig when it has been necessary to apply > fixes to older versions, which has been achieved using deviations. > > > > > > > >> None of this changes the fact that I think that we should be avoiding > >> making these changes in the first place. I.e. I think that there is a > >> clear separation between what the versioning scheme should be able to > >> express, and what is recommended practice. > >> > >> > >>> > >>> 2) SEMVER to the rescue? > >>> If every module release can be its own feature release train then the > >>> value of > >>> ascending numeric identifiers is greatly diminished. The (m) and (M) > >>> tags > >>> do not really help. I strongly agree with the comment that > >>> cherry-picking new > >>> features can (and should) be done with deviations. Updates of old > >>> revisions needs to be for bugfixes only. > >>> > >>> I prefer the OpenConfig "SEMVER Classic" rather than introducing a new > >>> incompatible complex numbering scheme to support something that > >>> should not be done anyway. > >> SEMVER classic does not support making bug fixes (even bc ones) on > >> older releases. > >> > >> In an older release, SEMVER classic allows: > >> - editorial changes, e.g. spelling corrections or clarifications in > >> description statements that do not change the API semantics in anyway. > >> - bug fixes to the *implementation*, but then we are not using SEMVER > >> to version the implementation anyway, only the API. > >> > >> If you want to allow bug fixes (even just bc ones) in an older release > >> then you either need something like modified semver, or a different > >> versioning scheme that allows them. Or you do what Rob Shakir > >> suggests and use deviations for this instead, which I think is a > >> misuse of deviations. > > But, as you state in the solution draft, not even modified semver can > > determine if a specific change is NBC or not. It seems you would need > > the entire history to determine this - which goes against the original > > idea that a client should be able to easily determine if a new version > > is NBC or not, compared to the version the client knows. > > The (m|M) is intended to be a tool of last resort. So provide a > mechanism to make bug fixes to older versions, but don't encourage > it. It provides a mechanism to provide
Re: [netmod] comments on YANG versioning
Hi Martin, On 14/11/2018 11:48, Martin Bjorklund wrote: Hi, Robert Wilton wrote: On 08/11/2018 22:52, Andy Bierman wrote: Hi, A few comments on the netmod meeting yesterday 1) what is a bugfix? It is not encouraging that the DT cannot agree on the scope of a bugfix. But not sure it matters if NBC updates can occur for any reason. IMO it is easy to define a bugfix in the IETF -- it is called an Errata. If an Errata is approved for a YANG module in an RFC then it is a bugfix. Ultimately we have customers that will say "this part of your YANG is broken" and we want you to fix it in that release train, either in the next release, or as a software patch. Sometimes vendors will disagree with their customers as to whether it is really a bug fix or an enhancement. Sometimes we will fix what we think is an obvious bug but that will unfortunately break another customer whom was relying on the existing behavior and then ask us to revert the fix. I think that it should be down to the module author/owner to decide whether or not it is a bug fix or an enhancement, and I would just like a versioning scheme that allows these changes to be expressed. So the requirement is that the versioning scheme must support branching, and must support expressing NBC changes on any version? I deem that 1.4 (without the sentence about versioning by software release) defines this: 1.4 The solution MUST allow for backwards-compatible enhancements and bug fixes to be allowed in any non-latest release. Although this text is ambiguous, perhaps stating it more clearly, I see the requirement as: 1.4 The solution MUST allow for backwards-compatible enhancements, and backward-compatible or non-backwards compatible bug fixes to be allowed in non-latest releases. This requirement isn't present in the current draft, AFAICT. (not that I support it as a requirement) But vendors *have* to do this today. I don't think telling our customers that no, we can't fix that bug, because the versioning scheme doesn't allow it is really pragmatic. Rob Shakir also indicated in the Netmod meeting that he does not support this requirement. However, this conflicts with the fact that there are examples in OpenConfig when it has been necessary to apply fixes to older versions, which has been achieved using deviations. None of this changes the fact that I think that we should be avoiding making these changes in the first place. I.e. I think that there is a clear separation between what the versioning scheme should be able to express, and what is recommended practice. 2) SEMVER to the rescue? If every module release can be its own feature release train then the value of ascending numeric identifiers is greatly diminished. The (m) and (M) tags do not really help. I strongly agree with the comment that cherry-picking new features can (and should) be done with deviations. Updates of old revisions needs to be for bugfixes only. I prefer the OpenConfig "SEMVER Classic" rather than introducing a new incompatible complex numbering scheme to support something that should not be done anyway. SEMVER classic does not support making bug fixes (even bc ones) on older releases. In an older release, SEMVER classic allows: - editorial changes, e.g. spelling corrections or clarifications in description statements that do not change the API semantics in anyway. - bug fixes to the *implementation*, but then we are not using SEMVER to version the implementation anyway, only the API. If you want to allow bug fixes (even just bc ones) in an older release then you either need something like modified semver, or a different versioning scheme that allows them. Or you do what Rob Shakir suggests and use deviations for this instead, which I think is a misuse of deviations. But, as you state in the solution draft, not even modified semver can determine if a specific change is NBC or not. It seems you would need the entire history to determine this - which goes against the original idea that a client should be able to easily determine if a new version is NBC or not, compared to the version the client knows. The (m|M) is intended to be a tool of last resort. So provide a mechanism to make bug fixes to older versions, but don't encourage it. It provides a mechanism to provide bug fixes on an existing release, but at the cost that you lose some of the benefits of semver (which is unavoidable). If the server is on a version of the form "A.B.X(m)" then the client knows that all changes between "A.B.0" and "A.B.X(m)" are backwards compatible. If the version is "A.B.X(M)" then the client knows that there is at least one nbc change between "A.B.0" and "A.B.X(M)". The client does not know whether going from "A.B.X(m|M)" to "A.B+1.0" is a backwards incompatible change or not. Thanks, Rob /martin . ___ netmod mailing
Re: [netmod] Confirming draft-ietf-netmod-module-tags-03 consensus call
Hi Chris, On 14/11/2018 13:46, Christian Hopps wrote: Do you have similar objections over comments in CLI config files? No, not at all. But one difference here is that the tags are bound to modules, not to the config, or config paths. Routers (the server) certainly don't use those and clients write them and read them -- yet they are stored on the server. Perhaps if you thought of there being more than just one client possible this might all make more sense? Yes, perhaps. Regarding the yang library you keep bringing up. This was in the work originally and the WG decided that we should remove it. Sorry, I had missed the WG discussion where this was removed. But OK. I do not think the tail end of a WGLC is an appropriate time or place to start wondering out loud about whether it would be a good to have. I admit to being confused by this since I believe you were actively participating WRT this work when it had the yang library augmentation as well as after we removed it. My apologies, but I had intended to review this more thoroughly during the WG LC but ran out of time. If was when I read Alex's comments that I thought that he was raising some valid points. The key one that struck a chord is that this document describes a solution but doesn't seem to clearly describe what problem it is solving (other than tags are good), or how it is intending to be used. When I reviewed this document after reading Alex's comments, I was asking myself how this was going to be used, and the answer I came up with was that I didn't really know. Or the case that I had in mind (YANG catalog filtering on module tag) doesn't seem to match the authors envisaged use cases. Looking back at some of the previous comments on this work (not just Alex), others have also questioned what problem it is solving and how it will be used. I'm OK with taking the editorial suggestions. I'm not so OK with going back and redoing this document or it's fundamental design at the tail end of a WGLC. Unless the WG agrees that it's truly broken. This would be pretty odd given it seemed like we were done, including during the 103 meeting in which you were in attendance. You say your not trying to hold the work up; however, that is exactly what your last minute public pondering is doing. Yes, I admit that I should have reviewed it earlier. My aim is not to slow it down but to ensure that the document is as clear as possible. As I've said lots of times, I like the idea of tags for classifying YANG modules :-) Given all that, it is still my opinion that this document would benefit from the introduction being slightly clearer on the specific problem being solved - e.g. I think that the abstract is more clear than the introduction, and also think that the document would benefit having some examples of how module tags could be used. But I appreciate that my comments are after the WGLC and have no issues if the authors/chairs decide that they are too late. After all, no one else, other than Alex, has expressed any concern. Thanks, Rob Thanks, Chris. On Nov 14, 2018, at 5:04 AM, Robert Wilton wrote: Hi Chris, On 13/11/2018 21:05, Christian Hopps wrote: The servers implement the modules which can have predefined tags from the module designer as well as the implementer (vendor) which literally cannot come from anywhere *but* the server that implements the module. Clients should also be able to know find out the predefined tags from the module definition. I agree that the any tags added by the implementation can only be known by querying the server, although its not obvious to me what those tags would be. E.g. if Cisco had a YANG module for EIGRP and wanted to give it the ietf:protocol and ietf:routing tag then it would ideally use the extension and put it in the YANG file. This is not what I thought would hold this work up. Sorry, I'm not trying to hold anything up. It not obvious to me how the ietf-module-tags modules will actually be used on a device: 1) being able to ask a device: "What are all the YANG modules that are implemented on this device that are routing protocols" seems a useful thing to do. Although personally I would ideally want the answer in the context of YANG library. I.e. to see the modules with the given tags, along with module evision/version, features and any deviations. This can probably be achieved today with an appropriate xpath query, if supported, or could perhaps be achieved more easily if the operational list of tags also augmented the module entries in the YANG library structure. But perhaps for your envisaged use case just getting back the list of modules with that tag is sufficient and is what you are after. Is this how you are envisaging YANG module tags would be used, and if so, would it do any harm to add a short section near the intro explaining this (and perhaps the YANG catalogue example as well)? Or do you
Re: [netmod] Confirming draft-ietf-netmod-module-tags-03 consensus call
Do you have similar objections over comments in CLI config files? Routers (the server) certainly don't use those and clients write them and read them -- yet they are stored on the server. Perhaps if you thought of there being more than just one client possible this might all make more sense? Regarding the yang library you keep bringing up. This was in the work originally and the WG decided that we should remove it. I do not think the tail end of a WGLC is an appropriate time or place to start wondering out loud about whether it would be a good to have. I admit to being confused by this since I believe you were actively participating WRT this work when it had the yang library augmentation as well as after we removed it. I'm OK with taking the editorial suggestions. I'm not so OK with going back and redoing this document or it's fundamental design at the tail end of a WGLC. Unless the WG agrees that it's truly broken. This would be pretty odd given it seemed like we were done, including during the 103 meeting in which you were in attendance. You say your not trying to hold the work up; however, that is exactly what your last minute public pondering is doing. Thanks, Chris. > On Nov 14, 2018, at 5:04 AM, Robert Wilton wrote: > > Hi Chris, > > On 13/11/2018 21:05, Christian Hopps wrote: >> The servers implement the modules which can have predefined tags from the >> module designer as well as the implementer (vendor) which literally cannot >> come from anywhere *but* the server that implements the module. > > Clients should also be able to know find out the predefined tags from the > module definition. I agree that the any tags added by the implementation can > only be known by querying the server, although its not obvious to me what > those tags would be. E.g. if Cisco had a YANG module for EIGRP and wanted to > give it the ietf:protocol and ietf:routing tag then it would ideally use the > extension and put it in the YANG file. > >> This is not what I thought would hold this work up. > > Sorry, I'm not trying to hold anything up. > > It not obvious to me how the ietf-module-tags modules will actually be used > on a device: > 1) being able to ask a device: "What are all the YANG modules that are > implemented on this device that are routing protocols" seems a useful thing > to do. Although personally I would ideally want the answer in the context of > YANG library. I.e. to see the modules with the given tags, along with module > evision/version, features and any deviations. This can probably be achieved > today with an appropriate xpath query, if supported, or could perhaps be > achieved more easily if the operational list of tags also augmented the > module entries in the YANG library structure. But perhaps for your envisaged > use case just getting back the list of modules with that tag is sufficient > and is what you are after. > > Is this how you are envisaging YANG module tags would be used, and if so, > would it do any harm to add a short section near the intro explaining this > (and perhaps the YANG catalogue example as well)? Or do you think that this > would just be needless noise. > > 2) Being able to filter queried data based on tags may also be useful, but > this would require protocol extensions, perhaps something to be done in > future? > > Thanks, > Rob > > >> >> Thanks, >> Chris. >> >>> On Nov 13, 2018, at 5:58 AM, Robert Wilton wrote: >>> >>> Hi Joel, authors, >>> >>> I have to confess that I didn't have time to review this during the last >>> call (but have reviewed/provided comments on previous versions). >>> >>> These comments may be too late, but I will provide them anyway, so make of >>> them what you will :-) >>> >>> In summary, I like the idea of tags and I think that they are a good fit >>> for classifying YANG models. In particular, I think that a flexible >>> classification of YANG modules is better than a rigid structure that can >>> never be changed. >>> >>> For me the one of the great utilities of module tags could be in >>> applications like YANG catalog search >>> (https://yangcatalog.org/yang-search/). Being able to search for modules >>> by tag seems like it would be a particularly useful thing to be able to do. >>> >>> However, I do have some sympathy with Alex's comment, in that it is a bit >>> unclear as to benefits of configuring the tag information on the devices. >>> At the moment, the configuration doesn't have any material affect on the >>> device, and the only thing that a client can do is read back the tag >>> configuration. Is the intention that the protocols may be extended in >>> future to allow filter queries to be based on module tags? >>> >>> So, I am supportive of Alex's comment that it would give the document more >>> clarity if some of the specific use cases could be described. >>> >>> >>> Some other random comments/nits: >>> >>> 1) 6087bis references can be updated to
Re: [netmod] comments on YANG versioning
Hi, Robert Wilton wrote: > > On 08/11/2018 22:52, Andy Bierman wrote: > > Hi, > > > > A few comments on the netmod meeting yesterday > > > > 1) what is a bugfix? > > It is not encouraging that the DT cannot agree on the scope of a > > bugfix. > > But not sure it matters if NBC updates can occur for any reason. > > IMO it is easy to define a bugfix in the IETF -- it is called an > > Errata. > > If an Errata is approved for a YANG module in an RFC then it is a > > bugfix. > > Ultimately we have customers that will say "this part of your YANG is > broken" and we want you to fix it in that release train, either in the > next release, or as a software patch. > > Sometimes vendors will disagree with their customers as to whether it > is really a bug fix or an enhancement. Sometimes we will fix what we > think is an obvious bug but that will unfortunately break another > customer whom was relying on the existing behavior and then ask us to > revert the fix. > > I think that it should be down to the module author/owner to decide > whether or not it is a bug fix or an enhancement, and I would just > like a versioning scheme that allows these changes to be expressed. So the requirement is that the versioning scheme must support branching, and must support expressing NBC changes on any version? This requirement isn't present in the current draft, AFAICT. (not that I support it as a requirement) > None of this changes the fact that I think that we should be avoiding > making these changes in the first place. I.e. I think that there is a > clear separation between what the versioning scheme should be able to > express, and what is recommended practice. > > > > > > > > 2) SEMVER to the rescue? > > If every module release can be its own feature release train then the > > value of > > ascending numeric identifiers is greatly diminished. The (m) and (M) > > tags > > do not really help. I strongly agree with the comment that > > cherry-picking new > > features can (and should) be done with deviations. Updates of old > > revisions needs to be for bugfixes only. > > > > I prefer the OpenConfig "SEMVER Classic" rather than introducing a new > > incompatible complex numbering scheme to support something that > > should not be done anyway. > > SEMVER classic does not support making bug fixes (even bc ones) on > older releases. > > In an older release, SEMVER classic allows: > - editorial changes, e.g. spelling corrections or clarifications in > description statements that do not change the API semantics in anyway. > - bug fixes to the *implementation*, but then we are not using SEMVER > to version the implementation anyway, only the API. > > If you want to allow bug fixes (even just bc ones) in an older release > then you either need something like modified semver, or a different > versioning scheme that allows them. Or you do what Rob Shakir > suggests and use deviations for this instead, which I think is a > misuse of deviations. But, as you state in the solution draft, not even modified semver can determine if a specific change is NBC or not. It seems you would need the entire history to determine this - which goes against the original idea that a client should be able to easily determine if a new version is NBC or not, compared to the version the client knows. /martin ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] comments on YANG versioning
On 08/11/2018 22:52, Andy Bierman wrote: Hi, A few comments on the netmod meeting yesterday 1) what is a bugfix? It is not encouraging that the DT cannot agree on the scope of a bugfix. But not sure it matters if NBC updates can occur for any reason. IMO it is easy to define a bugfix in the IETF -- it is called an Errata. If an Errata is approved for a YANG module in an RFC then it is a bugfix. Ultimately we have customers that will say "this part of your YANG is broken" and we want you to fix it in that release train, either in the next release, or as a software patch. Sometimes vendors will disagree with their customers as to whether it is really a bug fix or an enhancement. Sometimes we will fix what we think is an obvious bug but that will unfortunately break another customer whom was relying on the existing behavior and then ask us to revert the fix. I think that it should be down to the module author/owner to decide whether or not it is a bug fix or an enhancement, and I would just like a versioning scheme that allows these changes to be expressed. None of this changes the fact that I think that we should be avoiding making these changes in the first place. I.e. I think that there is a clear separation between what the versioning scheme should be able to express, and what is recommended practice. 2) SEMVER to the rescue? If every module release can be its own feature release train then the value of ascending numeric identifiers is greatly diminished. The (m) and (M) tags do not really help. I strongly agree with the comment that cherry-picking new features can (and should) be done with deviations. Updates of old revisions needs to be for bugfixes only. I prefer the OpenConfig "SEMVER Classic" rather than introducing a new incompatible complex numbering scheme to support something that should not be done anyway. SEMVER classic does not support making bug fixes (even bc ones) on older releases. In an older release, SEMVER classic allows: - editorial changes, e.g. spelling corrections or clarifications in description statements that do not change the API semantics in anyway. - bug fixes to the *implementation*, but then we are not using SEMVER to version the implementation anyway, only the API. If you want to allow bug fixes (even just bc ones) in an older release then you either need something like modified semver, or a different versioning scheme that allows them. Or you do what Rob Shakir suggests and use deviations for this instead, which I think is a misuse of deviations. 3) Bundles and compatibility modules I strongly agree this solution approach is far better than treating every revision as a separate feature release train. I don't see how I am going to track the major.minor.patch for 100 different modules. SEMVER is not very useful for telling if module A works with B, C, and D. Import by SEMVER will probably be OK at first, but become too error-prone after awhile. +1. I think that the versioning solution needs to consider something like bundles or packages. 4) Automation tools Ad-hoc WEB pages from IANA do not cut it anymore. We need a way to get patch versions of modules published and usable by automation tools (without an RFC) with just the Errata report as a patch. SEMVER requires that a module be released with the change but this is not that practical. I think that we need to have a place where all revisions of modules are published and easily accessible. Think how yocto works, using a base source version of a package + patches. (IMO we need YANG Packages, which would serve as recipes for a set of modules, features, annotations, patches and deviations, that have been tested to work together.) 5) YANG 1.2 vs Extensions IMO a new YANG version would be better than extensions, especially to fix status-stmt, import-by-revision, deviations, and add annotation, patch, and many other new mechanisms to help backward compatibility. Perhaps. There is currently a long list of stuff on the YANG.next issue tracker. My concern is that this effort will get bogged down. Also, some of these changes we want to apply across YANG language versions. E.g. I want the updated status behaviour to apply to all YANG modules on the server, regardless of whether of which version of YANG they were defined in. Thanks, Rob 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] Deviations and augmentations
On 13/11/2018 18:26, Juergen Schoenwaelder wrote: On Tue, Nov 13, 2018 at 05:54:27PM +, Robert Wilton wrote: I think that my main point regarding version numbers is: - If we are going to use semver then we should define and follow the rules strictly. I.e. assuming that the semver has been populated correctly then it should be possible to determine whether the change is a nbc, bc, or editorial change. I think that a solution where semver is done in a half-hearted way is entirely useless (e.g. if clients cannot trust the version number). I think that there is a pretty clear requirement to support NBC changes to older revisions (i.e. I really mean bug fixes but a looser interpretation than your definition), and hence I don't think that vanilla semver is sufficient. But even if you make the 'YANG world' use semvers correctly (not sure how you want to achieve that but lets pretend you manage), then the three digit number does not tell a client whether it will work or not. What should a client do if semver indicate nbc? What should it do if semver indicates bc? What should it do if semver indicates editorial change? Where is the "protocol specification" for this? In theory, for editorial or bc changes an existing client, coded correctly SHOULD work unchanged (assuming that it doesn't barf on operational state that it doesn't understand or config that it isn't aware of) I.e. I see that it is effectively making the same promise that 7950 module updates rules are trying to enforce today (putting status obsolete aside). For an nbc change they would need to check, manually or using a schema compare tool, to see what has changed. But I agree that a scheme level version number is really giving a suggestion rather than a robust promise that the client won't break. Even the schema compare tool doesn't guarantee that a client won't break, since it does not guarantee that the server implementation doesn't have any bugs. The next step is a solid set of tests that can be run against the updated schema and servers, and check that they behave as expected. Rob Shakir indicated that OpenConfig is busy building such as test framework. Then I think that the operator still rolls out the changes gradually, monitors for unexpected conditions, and is able to roll back if something goes wrong. But none of these stages prove that the network will still be fine afterwards, they just help catch issues earlier, where they should be easier to handle, and give a bit more confidence that the previous step. - An alternative is to not use a semver version number at all, instead we define a non semantic 3 digit version number that is something like: major = significant changes to the module have been made minor = smaller changes/feature enhancements to the module have been made patch = a bug fix to the module has been made. Clients, module readers, etc, and then required to use a schema comparison tool to determine what the actual changes between two revisions are and whether or not they will be broken by those changes. The only robust solution is schema comparison and we may think about what kind of annotations make such schema comparisons easier or faster or how we can help clients to adapt (e.g., providing pointers where definitions have moved, providing machine readable information allowing tools to track which modules replace others etc.). Yes, I think that all of this is a good idea. But I still think that having a human readable version number per module is also helpful, even if it is only to help humans label the module revision in an easy way. E.g. I think that a version number is easier to parse/remember than a revision date. Thanks, Rob /js ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Confirming draft-ietf-netmod-module-tags-03 consensus call
Hi Chris, On 13/11/2018 21:05, Christian Hopps wrote: The servers implement the modules which can have predefined tags from the module designer as well as the implementer (vendor) which literally cannot come from anywhere *but* the server that implements the module. Clients should also be able to know find out the predefined tags from the module definition. I agree that the any tags added by the implementation can only be known by querying the server, although its not obvious to me what those tags would be. E.g. if Cisco had a YANG module for EIGRP and wanted to give it the ietf:protocol and ietf:routing tag then it would ideally use the extension and put it in the YANG file. This is not what I thought would hold this work up. Sorry, I'm not trying to hold anything up. It not obvious to me how the ietf-module-tags modules will actually be used on a device: 1) being able to ask a device: "What are all the YANG modules that are implemented on this device that are routing protocols" seems a useful thing to do. Although personally I would ideally want the answer in the context of YANG library. I.e. to see the modules with the given tags, along with module evision/version, features and any deviations. This can probably be achieved today with an appropriate xpath query, if supported, or could perhaps be achieved more easily if the operational list of tags also augmented the module entries in the YANG library structure. But perhaps for your envisaged use case just getting back the list of modules with that tag is sufficient and is what you are after. Is this how you are envisaging YANG module tags would be used, and if so, would it do any harm to add a short section near the intro explaining this (and perhaps the YANG catalogue example as well)? Or do you think that this would just be needless noise. 2) Being able to filter queried data based on tags may also be useful, but this would require protocol extensions, perhaps something to be done in future? Thanks, Rob Thanks, Chris. On Nov 13, 2018, at 5:58 AM, Robert Wilton wrote: Hi Joel, authors, I have to confess that I didn't have time to review this during the last call (but have reviewed/provided comments on previous versions). These comments may be too late, but I will provide them anyway, so make of them what you will :-) In summary, I like the idea of tags and I think that they are a good fit for classifying YANG models. In particular, I think that a flexible classification of YANG modules is better than a rigid structure that can never be changed. For me the one of the great utilities of module tags could be in applications like YANG catalog search (https://yangcatalog.org/yang-search/). Being able to search for modules by tag seems like it would be a particularly useful thing to be able to do. However, I do have some sympathy with Alex's comment, in that it is a bit unclear as to benefits of configuring the tag information on the devices. At the moment, the configuration doesn't have any material affect on the device, and the only thing that a client can do is read back the tag configuration. Is the intention that the protocols may be extended in future to allow filter queries to be based on module tags? So, I am supportive of Alex's comment that it would give the document more clarity if some of the specific use cases could be described. Some other random comments/nits: 1) 6087bis references can be updated to RFC 8407. Is a reference even allowed in the abstract? 2) Abstract: "writing a modules tags" => "writing a module's tags" or "writing module tags" 3) The module is YANG 1.1, so RFC 6020 reference can be changed to RFC 7950. 4) Section 3.4: Should there be a tag prefix for "experimental"? Or perhaps this would be "ietf:experimental:" anyway. 5) Section 5.1: It might be useful if the tags were also reported under YANG library, e.g. as an augmentation to rfc7895bis. E.g. this would report the same information as "modules-tags/module[name]/tag" leaf-list. 6) YANG module: Should you limit the maximum size of a tag? Perhaps to 255, or 1000 characters. 7) Line length for "The operational view of this list is constructed ..." looks like it may be too long. 8) Section 7, Guidelines to authors. I was wondering if this section should state that YANG modules SHOULD define standard tags that are associated with it. At the moment, it just states what can be done, without providing guidance of what should be done. 9) Section 9.2. A few more possible categories: discovery protocol, vpn, tunnel. I'm not sure that I particularly like "rfc8199-" as a module name, and possibly "classification-" would be better. Apologies for the tardy review comments, Rob On 12/11/2018 16:46, joel jaeggli wrote: During the Thursday nov 8 session of netmod, we asked if there were any objections to the publication of the Draft-03 version of draft-ietf-netmod-module-tags
Re: [netmod] for a future rfc6991bis
Hi,
Alex Campbell wrote:
> Does a percentage really need a single standard type in the first
> place? How about "units percent;"?
At this point, after hearing about how different modules have
differing requirement on this type, I tend to agree.
/martin
>
>
> From: netmod on behalf of Acee Lindem (acee)
>
> Sent: Wednesday, 14 November 2018 5:03 a.m.
> To: Juergen Schoenwaelder; Balázs Lengyel
> Cc: NETMOD WG
> Subject: Re: [netmod] for a future rfc6991bis
>
> On 11/13/18, 9:07 AM, "netmod on behalf of Juergen Schoenwaelder"
> j.schoenwael...@jacobs-university.de> wrote:
>
> On Tue, Nov 13, 2018 at 01:33:01PM +, Balázs Lengyel wrote:
> > Hello,
> >
> > In some cases I want a percentage without fractions. This could be
> > defined
> > using range, by specifying the numbers 0 | 1 | 2 ... 99 | 100 in the
> > range's
> > argument.
> >
> > typedef percent-short {
> > type percent { range 0 | 1 | 2 ... 99 | 100; } // didn't type out
> > all the 101 integer values :-)
> > }
> >
>
> I guess we need to settle on a small number of percentage types that
> people find useful and then module authors hopefully find what they
> need. I am not sure that listing 101 numbers is a good pattern to use
> (although it does achieve what you want). For percentages that have no
> fraction, you likely want to derive from a base type that is efficient
> to encode for binary encodings such as CBOR.
>
> Or simply define a type with a base type of unit8 type and a range of
> 0-100.
>
> Acee
>
>
>
>
>
> /js
>
> --
> Juergen Schoenwaelder Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax: +49 421 200 3103
