Subject: [Netmod-ver-dt] Updated proposed requirements text

From: Robert Wilton <[email-masked]>
Date: Tue, 19 Jun 2018 17:54:26 +0100

I've tried to update the requirements text based on the feedback 
received so far.  I've also split it into sections to try and group 
similar requirements together.  Comments are of course welcome.  Are all 
requirements listed, and at appropriate importance?

* Requirements of a YANG versioning solution: *

1. Requirements related to making non backwards compatible updates to 
modules:

1.1 A mechanism is required to update a module in a non backwards 
compatible way without forcing all modules with import dependencies on 
the updated module from being updated at the same time (e.g. to change 
its import to use a new module name).

1.2 A mechanism is required to update a module in a non backwards 
compatible way without forcing all clients/servers to access data nodes 
in the model on new paths, or in a new namespace. Specifically, if a 
particular data node has not been updated in a non backwards compatible 
way then it must be available on the same path, and in the same 
namespace. Even if a particular node has been updated in a non backwards 
compatible way (e.g. due to a bug fix) then it may still be desirable 
for it to be available on the same path and in the same namespace.

1.3 A refined form of YANG's 'import' statement should be provided that 
is more restrictive than "import any revision" and less restrictive than 
"import a specific revision".  Once non backwards compatible changes to 
modules are allowed, the refined import statement is helpful to express 
the correct dependency between modules.

2. Requirements related to identifying changes between different module 
revisions:

2.1 Readers of modules, and tools that use modules, need to be able to 
determine whether changes between two revisions of a module constitute a 
backwards compatible or not backwards compatible version change.  In 
addition, it may be helpful to identify whether change represents bug 
fixes, new functionality, or both.

2.2 A mechanism should be defined to determine whether particular data 
nodes between two arbitrary YANG module versions have been (i) not 
changed, (ii) changed in a backwards compatible way, (iii) changed in a 
non backwards compatible way.

3. Requirements related to supporting existing clients in a backwards 
compatible way:

3.1. The solution needs a mechanism to allow servers to support existing 
clients in a backwards compatible way.

3.2. The solution needs a mechanism to allow servers to simultaneously 
support client using different versions of modules.  A clients choice of 
particular version of one or more modules may restict the particular 
version of other modules that may be used in the same request or session.

4. Requirements related to managing and documenting the life cycle of 
data nodes:

Data nodes may be deprecated or become obsolete over time.  These 
requirements relate to how these deprecated and obsolete data nodes are 
handled.

4.1 A mechanism is required to allow a client to determine whether 
deprecated nodes are implemented by the server.  Solutions that required 
all deprecated nodes to be handled in the same way are acceptable.  If 
servers are allowed to implement a subset of the deprecated nodes, then 
the mechanism must allow clients to determine whether individual 
deprecated nodes are implemented.

4.2 A mechanism is required to allow a client to determine whether 
obsolete nodes are implemented by the server. Solutions that required 
all obsolete nodes to be handled in the same way are acceptable.  If 
servers are allowed to implement a subset of the obsolete nodes, then 
the mechanism must allow it to determine whether individual obsolete 
nodes are implemented.

4.3 If a data node is deprecated or obsolete then it would be useful if 
the YANG module could indicate what alternatives exist.

4.4 For any data node that is currently supported, it would be useful to 
indicate that the data node is expected to become unsupported in a 
future revision.

4.5 If multiple revisions of a YANG module are published and currently 
supported, then the solution should allow for bug fixes to be made to an 
older revision of the module. Specifically, the solution should not 
require that all non backwards compatible bug fixes are only made to the 
latest revision of the module.

5. Requirements related to documentation and education:

5.1. The solution should provide guidance to model authors and clients 
on how to use the
new YANG versioning scheme.

Thanks,
Rob

---

From: Joe Clarke <[email-masked]>
Date: Tue, 19 Jun 2018 15:12:18 -0400

> requirements listed, and at appropriate importance?

I think these line up with what we discussed.  I seem to recall we moved
the import requirement to a MUST, though.

I have committed/pushed the first revision of the problem statement and
requirements draft work to GH in a develop branch.  (I made this
SHOULD/MUST change, too).

I generally took text from the clacla draft around the problem statement
and fixed it up some.  I tried to remove some of the editorializing
text.  I then folded in these points using normative text.

Everyone on the DT has access to write, but as editor, I can also
incorporate changes.

I figure when we're happy, I can merge the changes to master and submit
to Data Tracker.

https://github.com/netmod-wg/yang-ver-dt/tree/develop

Joe

> _______________________________________________
> Netmod-ver-dt mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod-ver-dt

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 20 Jun 2018 09:28:53 +0200

On Tue, Jun 19, 2018 at 05:54:26PM +0100, Robert Wilton wrote:
> 1.1 A mechanism is required to update a module in a non backwards compatible
> way without forcing all modules with import dependencies on the updated
> module from being updated at the same time (e.g. to change its import to use
> a new module name).
> 
> 1.2 A mechanism is required to update a module in a non backwards compatible
> way without forcing all clients/servers to access data nodes in the model on
> new paths, or in a new namespace. Specifically, if a particular data node
> has not been updated in a non backwards compatible way then it must be
> available on the same path, and in the same namespace. Even if a particular
> node has been updated in a non backwards compatible way (e.g. due to a bug
> fix) then it may still be desirable for it to be available on the same path
> and in the same namespace.

I suggest we use 'module namespace' instead 'namespace'.
 
> 1.3 A refined form of YANG's 'import' statement should be provided that is
> more restrictive than "import any revision" and less restrictive than
> modules are allowed, the refined import statement is helpful to express the
> correct dependency between modules.

What does 'is helpful' mean? If we allow nbc changes, then being able
to constrain the imports in a more fine grained ways I think is a must
and not a should and 'is helpful' should be 'is required'.

> addition, it may be helpful to identify whether change represents bug fixes,
> new functionality, or both.

s/change represents/changes represent/

> 2.2 A mechanism should be defined to determine whether particular data nodes
> between two arbitrary YANG module versions have been (i) not changed, (ii)
> changed in a backwards compatible way, (iii) changed in a non backwards
> compatible way.

Do we need 'particular' here?
 
> particular version of one or more modules may restict the particular version
> of other modules that may be used in the same request or session.

s/clients/client's/
 
> 4. Requirements related to managing and documenting the life cycle of data
> nodes:
> 
> deprecated nodes are implemented by the server. Solutions that required all
> deprecated nodes to be handled in the same way are acceptable. If servers
> are allowed to implement a subset of the deprecated nodes, then the
> mechanism must allow clients to determine whether individual deprecated
> nodes are implemented.

The text after the first sentence already discusses solutions. (If we
change YANG such that deprecated nodes must be implemented, then there
is already a mechanism to declare deviations.) I would reduce this to
just the first sentence since this is sufficient to state the
requirement.

> 4.2 A mechanism is required to allow a client to determine whether obsolete
> nodes are implemented by the server. Solutions that required all obsolete
> nodes to be handled in the same way are acceptable. If servers are allowed
> to implement a subset of the obsolete nodes, then the mechanism must allow
> it to determine whether individual obsolete nodes are implemented.

Some as above. I believe the first sentence is sufficient to state the
requirement.

> 4.3 If a data node is deprecated or obsolete then it would be useful if the
> YANG module could indicate what alternatives exist.

Should this include also an explicit requirement to have a mechansim
to document status changes of YANG definitions with explicit
description text?

> indicate that the data node is expected to become unsupported in a future
> revision.

I am not sure I understand this. What is 'supported' and 'unsupported'
and how does this relate to YANG's notion of 'current', 'deprecated',
'obsolete'? This also means that one has to make predictions about
future version identifiers (which will be tough in the IETF).

> older revision of the module. Specifically, the solution should not require
> that all non backwards compatible bug fixes are only made to the latest
> revision of the module.

The notion of 'non backwards compatible bug fixes' is a somewhat
slippery slope. I believe we should not go there and just talk about
bug fixes (i.e., remove the second sentence above).

It will be a judgement call how to deal with certain 'bugs'. Perhaps
what you really wanted to get to is to be able to document that a data
node may be changed 'in a _possibly non backwards compatible_ way due
to a bug fix'. I believe a bug fix requires that there was a certain
intent to do X but somehow you ended up with X' and hence you fix
things by changing X' to be X. If the intent to do X is not clear,
then changing X' to X is not a bug fix. So it boils down to settle the
question whether the intend to do X was clear. If a specification
allows for two (or more) interpretations X and X', then this can't be
easily settled by a 'bug fix'.

I suggest that we reduce the requirement to just the first sentence
and we consider to add a section that discusses specifically bug fixes
and 

> 5.1. The solution should provide guidance to model authors and clients on
> how to use the

Should we also have an explicit requirement that a new YANG versioning
scheme should describe how to transition from the current versioning
scheme to the new versioning scheme?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 20 Jun 2018 09:33:22 +0200

> text.  I then folded in these points using normative text.

As stated before, I do not agree with the problem statement text. I
would rather finish the discussion of the requirements and then start
a new email thread on the problem statement.

/js

---

From: Robert Wilton <[email-masked]>
Date: Wed, 20 Jun 2018 11:56:38 +0100

> I suggest we use 'module namespace' instead 'namespace'.
OK.

> s/change represents/changes represent/
OK.

> Do we need 'particular' here?
My aim is to express that the comparison is on per data node basis 
rather than just at the module level.

To give an example, rather than knowing whether ietf-interfaces@rev2 is 
backwards incompatible in some way with ietf-interfaces@rev1, I would 
like to know for each data node path, whether or not it has been changed 
in a backwards incompatible way.

If the client is only actually using a subset of a modules data nodes, 
then they probably only care whether that subset has been updated in a 
non backwards compatible way.

Do you still think "particular" is redundant, or could this be expressed 
in a better way, or is the alternative text below better?

"2.2 A mechanism should be defined to determine, for any two arbitrary YANG
module versions, and for any given data node path, whether the data node has
(i) not changed, (ii) changed in a backwards compatible way, (iii) changed
in a non backwards compatible way."

>> of other modules that may be used in the same request or session.
OK

> just the first sentence since this is sufficient to state the
OK.

> Some as above. I believe the first sentence is sufficient to state the
OK.

> to document status changes of YANG definitions with explicit
My aim was for the requirement text above to cover this.

It is possible that a new optional YANG statement could be added that 
gives a schema path of an alternative object to use instead. (E.g. for 
operational state data, a deprecated 32 bit counter could point to a 64 
bit equivalent instead).  But I think that this is probably too much 
unnecessary complexity, and hence allowing status to have a description 
statement is probably adequate.

So, would it make sense to reword this requirement to just cover the 
status description element?

E.g to replace the requirement above with:

"4.3 A mechanism is required to associate descriptive status text with any deprecated or obsolete YANG definitions."

> future version identifiers (which will be tough in the IETF).
OK, I used "current"/"unsupported" to get round the fact that it is 
unclear whether deprecated nodes are implemented.

Balazs may be able to explain/define this better, I think that the idea 
is to be able to provide forward guidance.  E.g, mark a node that has 
been deprecated that it will become obsolete at some time, or future 
release, or future version.

Balazs, I don't know if just having a description statement under status 
is sufficient to meet this requirement?

> bug fixes (i.e., remove the second sentence above).
Yes, OK.  Particularly, if we describe bug fixes separately.

> to a bug fix'.
Yes, that was my aim.

>   I believe a bug fix requires that there was a certain
I agree.

I think that it comes down in YANG to what defines the formal 
specification.  E.g. does a pattern statement (or range) form part of 
the specification of a data node?  Or is it the description that 
specifies the behaviour and the pattern statement is actually just an 
implementation of the API (that could have bugs in it).

Note, I agree with one of your previous comments that a pattern 
statement does not need to be definitive.  I see it as a mechanism to 
remove obviously invalid values, but I think that it is OK if a pattern 
statement still allows invalid values to pass (e.g. sometimes a shorter 
more readable regex may be preferred over a less comprehensible, but 
more precise regex).

Is reducing the set of values supported by a pattern statement still a 
backwards compatible enhancement if the set of allowed values defined by 
the description statement hasn't changed?  My view is that it is.

> and we consider to add a section that discusses specifically bug fixes
Yes, do you mean just in the problem definition, or the requirements 
section as well?  Could you provide some text please?

> scheme to the new versioning scheme?
Yes, I think so.

Perhaps:

"5.2 The solution is required to describe how to transition from the
existing YANG 1.0/1.1 versioning scheme to the new scheme."

Thanks,
Rob

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Wed, 20 Jun 2018 11:59:11 +0000

Rob, the text looks good to me.

Minor comments:
- I agree that we should try to reformulate soft statements like "may be helpful" and "is helpful". 
- 1.2 We have 2 negatives "has not been updated in a non backwards compatible way", change to "has been updated in a backwards compatible way"?
- 3.2 " support client using different versions of modules", should this be " support clients using different versions of modules "?

Regards,
Reshad.

On 2018-06-20, 6:57 AM, "Netmod-ver-dt on behalf of Robert Wilton" <[email-masked] on behalf of rwilton=[email-masked]> wrote:

    OK.
    
    OK.

    

    
    OK
    
    OK.
    
    OK.

    

    

    
    Yes, that was my aim.
    
    I agree.

    

    Yes, I think so.
    
    Perhaps:

    Thanks,
    Rob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 20 Jun 2018 15:11:55 +0200

On Wed, Jun 20, 2018 at 11:56:38AM +0100, Robert Wilton wrote:
> My aim is to express that the comparison is on per data node basis rather
> than just at the module level.
> 
> backwards incompatible in some way with ietf-interfaces@rev1, I would like
> to know for each data node path, whether or not it has been changed in a
> backwards incompatible way.
> 
> If the client is only actually using a subset of a modules data nodes, then
> they probably only care whether that subset has been updated in a non
> backwards compatible way.
> 
> Do you still think "particular" is redundant, or could this be expressed in
> a better way, or is the alternative text below better?
> 

Simply remove 'particular' from the original text. Since you talk
about data nodes, you talk about data nodes and I see no reason to
further complicate the statement.
 
> It is possible that a new optional YANG statement could be added that gives
> a schema path of an alternative object to use instead. (E.g. for operational
> state data, a deprecated 32 bit counter could point to a 64 bit equivalent
> instead).  But I think that this is probably too much unnecessary
> complexity, and hence allowing status to have a description statement is
> probably adequate.
> 
> So, would it make sense to reword this requirement to just cover the status
> description element?
> 

I think we talk about two different things. Adding an optional
description statement to the status statement is trivial. Adding a
'replaced-by' reference is simple as long as a leaf is replaced by
another leaf, but what about more complex replacements? Do we point to
an entire list? Or even an xpath expression resulting in a nodeset?
What is a client exactly supposed to do with this? Is there any
expectation of automation or is this just a machine readable pointer?
Hence, a 'replaced-by' reference is more complicated to define and
thus it might help to break this into two separate requirements.

> specification.  E.g. does a pattern statement (or range) form part of the
> specification of a data node?  Or is it the description that specifies the
> behaviour and the pattern statement is actually just an implementation of
> the API (that could have bugs in it).

Both can be wrong. See also my example with an enum where the label
did not match the likely intended value. There simply is no generic
answer.

> backwards compatible enhancement if the set of allowed values defined by the
> description statement hasn't changed?  My view is that it is.

In this case, the change only changes when during the processing an
illegal value will be detected. It does not change the allowed value
set.

> Yes, do you mean just in the problem definition, or the requirements section
> as well?  Could you provide some text please?

My proposal was to use simpley this:

 4.5 If multiple revisions of a YANG module are published and currently
 supported, then the solution should allow for bug fixes to be made to an
 older revision of the module.
 
> existing YANG 1.0/1.1 versioning scheme to the new scheme."

Works for me.

/js

---

From: Joe Clarke <[email-masked]>
Date: Wed, 20 Jun 2018 09:39:57 -0400

> - I agree that we should try to reformulate soft statements like "may be helpful" and "is helpful". 

In the draft text pushed to GH, I changed this to be normative text.  I
took this to mean SHOULD.

> - 1.2 We have 2 negatives "has not been updated in a non backwards compatible way", change to "has been updated in a backwards compatible way"?

Good catch.  You can change this in the GH text.  My plan is to let
things settle and if need be, I can do a batch of changes.

> - 3.2 " support client using different versions of modules", should this be " support clients using different versions of modules "?

Same.

Joe

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Wed, 20 Jun 2018 13:46:50 +0000

Will make the changes in GH.

On 2018-06-20, 9:40 AM, "Netmod-ver-dt on behalf of Joe Clarke" <[email-masked] on behalf of jclarke=[email-masked]> wrote:

    

    
    Same.
    
    Joe

---

From: Robert Wilton <[email-masked]>
Date: Wed, 20 Jun 2018 15:23:23 +0100

I've updated the github develop branch with most of the resolved issues 
(but left the ones that Reshad is fixing).

OK.

> description statement to the status statement is trivial.
Yes, so this requirement text can cover that?

"4.X A mechanism is required to associate descriptive status text with any deprecated or obsolete YANG definitions."

>   Adding a
Agreed.  I am questioning whether we should list this as a requirement 
at all.  There is no harm adding it for the moment, and then we can 
review/discuss in the meeting tomorrow.

>   older revision of the module.
Yes, by providing text, I meant the second part of your suggestion, i.e. 
adding some text specifically discussing bug fixes.  I think that this 
would be useful to clarify.  Hence, I'm asking where you envisage the 
text going and whether you want to write it :-)

>> existing YANG 1.0/1.1 versioning scheme to the new scheme."
Added.

Thanks,
Rob

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Wed, 20 Jun 2018 15:25:44 +0000

Done.

On 2018-06-20, 10:23 AM, "Netmod-ver-dt on behalf of Robert Wilton" <[email-masked] on behalf of rwilton=[email-masked]> wrote:

    
    OK.

    

    Added.
    
    Thanks,
    Rob

---

From: Robert Wilton <[email-masked]>
Date: Wed, 20 Jun 2018 16:47:28 +0100

So, the current requirement text from github is as follows, please can 
everyone review before the meeting tomorrow.  It would be good if we can 
agree the requirements so that we can get to consensus on the problem 
definition before the IETF publication deadline.

There is still one open issue for 4.3: Should we split this into (i) a 
description requirement vs (ii) machine readable reference (e.g. xpath).

4.4 is also open, do we need this? Really waiting for Balazs to comment 
since he was pushing for this requirement.

4.  Requirements of a YANG Versioning Solution

    The following is a list of requirements that a solution to the
    problems mentioned above MUST or SHOULD have.  The list is grouped by
    similar requirements, but is not presented in a set priority order.

    1.  Requirements related to making non backwards compatible updates
        to modules:

        1.1  A mechanism is REQUIRED to update a module in a non
             backwards compatible way without forcing all modules with
             import dependencies on the updated module from being updated
             at the same time (e.g. to change its import to use a new
             module name).

        1.2  A mechanism is REQUIRED to update a module in a non
             backwards compatible way without forcing all clients/servers
             to access data nodes in the model on new paths, or in a new
             module namespace.  Specifically, if a particular data node
             has been updated in a backwards compatible way then it must
             be available on the same path, and in the same module
             namespace.  Even if a particular node has been updated in a
             non backwards compatible way (e.g. due to a bug fix) then it
             may still be desirable for it to be available on the same
             path and in the same module namespace.

        1.3  A refined form of YANG's 'import' statement MUST be provided
             that is more restrictive than "import any revision" and less
             restrictive than "import a specific revision".  Once non
             backwards compatible changes to modules are allowed, the
             refined import statement is used to express the correct
             dependency between modules.

    2.  Requirements related to identifying changes between different
        module revisions:

        2.1  Readers of modules, and tools that use modules, MUST be able
             to determine whether changes between two revisions of a
             module constitute a backwards compatible or non backwards
             compatible version change.  In addition, it MAY be helpful
             to identify whether changes represent bug fixes, new
             functionality, or both.

        2.2  A mechanism SHOULD be defined to determine whether data
             nodes between two arbitrary YANG module versions have (i)
             not changed, (ii) changed in a backwards compatible way,
             (iii) changed in a non backwards compatible way.

Clarke                  Expires December 22, 2018               [Page 7]

Internet-Draft        YANG Versioning Requirements             June 2018

    3.  Requirements related to supporting existing clients in a
        backwards compatible way:

        3.1  The solution MUST provide a mechanism to allow servers to
             support existing clients in a backwards compatible way.

        3.2  The solution MUST provide a mechanism to allow servers to
             simultaneously support clients using different versions of
             modules.  A client's choice of particular version of one or
             more modules may restict the particular version of other
             modules that may be used in the same request or session.

    4.  Requirements related to managing and documenting the life cycle
        of data nodes:

        4.1  A mechanism is REQUIRED to allow a client to determine
             whether deprecated nodes are implemented by the server.

        4.2  A mechanism is REQUIRED to allow a client to determine
             whether obsolete nodes are implemented by the server.

        4.3  If a data node is deprecated or obsolete then it SHOULD be
             possible for the YANG module to indicate what alternatives
             exist.

        4.4  For any data node that is currently supported, it SHOULD be
             possible to indicate that it will become unsupported in a
             future version.

        4.5  If multiple revisions of a YANG module are published and
             currently supported, then the solution SHOULD allow for bug
             fixes to be made to an older revision of the module.

        5.1  The solution SHOULD provide guidance to model authors and
             clients on how to use the new YANG versioning scheme.

        5.2  The solution is REQUIRED to describe how to transition from
             the existing YANG 1.0/1.1 versioning scheme to the new
             scheme.

Thanks,
Rob

---

From: Joe Clarke <[email-masked]>
Date: Wed, 20 Jun 2018 12:03:33 -0400

> definition before the IETF publication deadline.

I am in agreement on the requirements.

> description requirement vs (ii) machine readable reference (e.g. xpath).

We considered this.  However, sometimes one node might now be two (or
more) to fully realize the same behavior.  This is why we thought to
leave this more open.  Even if it is a 1:1 mapping, the meaning or
semantics might be slightly different in the new node, so blindly using
it might yield some unexpected results.

> since he was pushing for this requirement.

I don't think we should specify a date (or even version) at which a node
will become deprecated or obsolete.  These are always subject to change.

I don't know that this requirement needs to be this strong.  Some
vendors may not know they're going to deprecate a node until late in a
release cycle.  I might relax this to a MAY.

Joe

>> On 2018-06-20, 10:23 AM, "Netmod-ver-dt on behalf of Robert Wilton" <[email-masked] on behalf of
>> rwilton=[email-masked]> wrote:
>>

---

From: Robert Wilton <[email-masked]>
Date: Wed, 20 Jun 2018 17:34:01 +0100

> it might yield some unexpected results.
Yes, I'm not keen on a programmatic mechanism, because I'm not convinced 
by the effort vs reward trade off.

I suspect that it would end up being complicated and I'm not convinced 
that many clients would be coded to generically use them, which would 
seemingly make it less likely that model authors would put them in, or 
check that they are right.

> will become deprecated or obsolete.  These are always subject to change.

I think that this requirement can probably be fulfilled just by allowing 
the description statement under status.  E.g. someone could always add 
something similar to the following if they wanted to provide forward 
guidance (although I would question why it isn't already status 
deprecated at this stage).

status current {
   description "This leaf is only being added as a temporary fix, and is 
expected to be deprecated in release X (where it will be replaced with a 
full solution), and obsoleted in release Y".
}

> release cycle.  I might relax this to a MAY.
So the requirement isn't that vendors have to do this, just that there 
SHOULD be a mechanism to allow this to be done for those who wish to do so.

I'm not sure whether any requirement should really be expressed as a 
MAY, since I think that means that it is not a requirement at all, and 
probably can just be deleted.  Noting that there is nothing stopping a 
solution from exceeding the requirements.

Thanks,
Rob

> .

---

From: Joe Clarke <[email-masked]>
Date: Wed, 20 Jun 2018 12:38:48 -0400

> solution from exceeding the requirements.

Indeed there is not.  And having it as a MAY simply puts it there to
document that some find this desirable (i.e., if you were going to
exceed, here's a good thing to consider).

Joe

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 21 Jun 2018 08:36:40 +0200

> description requirement vs (ii) machine readable reference (e.g. xpath).

I think (i) is sufficient since (ii) can get complex and automated
adaptation to non backwards compatible changes likely won't work
except in relatively trivial corner cases (i.e., in situations where
there is simply a redirect).

>             path and in the same module namespace.

The last sentence does not seem to add anything. I think the last two
sentences should actually be merged into this in order to indicate that
keeping the same (module, path) identifier may be desirable (but it is
not a must).

	      [...] Specifically, if a particular data node
              is updated in a backwards compatible way then it
	      may be desirable for it to be available on the same
	      path and in the same module namespace.

>             whether obsolete nodes are implemented by the server.

I am still not sure why we need this; clients should not rely on the
existance of obsolete definitions. This is what RFC 7950 already says
today - although in an implicit manner by focusing on the server side
(SHOULD NOT be implemented and/or can be removed from implementations).
I do not see the value to tighten this up to the point that a server
implementing an obsolete leaf becomes non-compliant.

>             possible to indicate that it will become unsupported in a

So we add a new stated between 'current' and 'deprecated', a 'soon to
be deprecated' state? I do not believe this is needed. Or I still do
not know what 'supported' and 'unsupported' means.

>             fixes to be made to an older revision of the module.

What does 'and currently supported' mean? Can we simply remove this?
If not, we have to say what this means.

>             the existing YANG 1.0/1.1 versioning scheme to the new

I think we need to add a requirement that a solution needs to specify
how references that today use the combination of module namespace and
path are going to work if non-backwards compatible changes are allowed
in the future. An example is NACM (RFC 8341) but there may be more
data models that use unrestricted references to other data nodes.

/js

---

From: Qin Wu <[email-masked]>
Date: Thu, 21 Jun 2018 08:31:57 +0000

Hi, Rob:
A few comments inline below.

发件人: Netmod-ver-dt [mailto:[email-masked]] 代表 Robert Wilton
发送时间: 2018年6月20日 23:47
收件人: Reshad Rahman (rrahman); Juergen Schoenwaelder; [email-masked]; Balazs Lengyel
主题: Re: [Netmod-ver-dt] Updated proposed requirements text

So, the current requirement text from github is as follows, please can everyone review before the meeting tomorrow.  It would be good if we can agree the requirements so that we can get to consensus on the problem definition before the IETF publication deadline.

There is still one open issue for 4.3: Should we split this into (i) a description requirement vs (ii) machine readable reference (e.g. xpath).

4.4 is also open, do we need this? Really waiting for Balazs to comment since he was pushing for this requirement.

       to modules:

            module name).

[Qin]:dependency between different versions of the same module or dependency between one module with another module that is imported?

Secondly I think “import a specific revision” is equivalent to a refined form YANG’s import statement. The only missing from “import a specific revision”

Is whether a specific revision of the module has been changed in a non-backward compatible way.

       module revisions:

            functionality, or both.

[Qin]: As described in section 12 of RFC7950, a client may support different YANG versions of modules, e.g.,

A client support a YANG version 1 module A importing YANG version 1.1 module B. I want make sure versions of modules

Are not referred to different YANG versions of modules.

       of data nodes:

            exist.

            future version.

            scheme.

[Qin]: A little bit confused, do we need to mix YANG version with version of the module? Or  new scheme is referred to YANG 2.0, YANG x.x?
Thanks,
Rob

Done.

On 2018-06-20, 10:23 AM, "Netmod-ver-dt on behalf of Robert Wilton" <[email-masked] on behalf of rwilton=[email-masked]><mailto:[email-masked]=[email-masked]> wrote:

    OK.

    Added.

    Thanks,

    Rob

    [email-masked]<mailto:[email-masked]>

---

From: Robert Wilton <[email-masked]>
Date: Thu, 21 Jun 2018 10:54:42 +0100

> there is simply a redirect).
OK, so for clarify, the existing 4.3 text is acceptable?

> 	      path and in the same module namespace.
Actually, should this just be:

	      [...] Specifically, if a particular data node
               is updated then it may be desirable for it to be
               available on the same path and in the same module
               namespace.

> implementing an obsolete leaf becomes non-compliant.
This might be a good one to discuss later.

Certainly, I would be happy to weaken this one to:

        4.2  A mechanism SHOULD be provided to allow a client to determine
             whether obsolete nodes are implemented by the server.

I'm not thinking that we make servers that implement obsolete leaves non 
compliant, rather this could just be a leaf in YANG library that 
indicates strictly whether the server implements obsolete nodes or not 
(e.g. either it doesn't implement any, or it might implement some or all 
of them).

The benefit of this is that is allows the client to know the 'exact' 
schema, but I agree with that the real benefit of this is somewhat unclear:
  - clients should not expect obsolete configuration to work (and the 
flag doesn't help here).
  - clients should expect to receive (and ignore or cope with) unknown 
operational state values (including nodes that are marked as obsolete).  
This is also required to make the client robust and forward compatible 
with future revisions/versions.

The one possible small benefit of such a leaf is that it might allow a 
client to categories warnings appropriately, but even that seems 
somewhat unlikely  to me.

> be deprecated' state?
I definitely don't want this :-)

>   I do not believe this is needed. Or I still do
I think that this one would also be good to discuss in the meeting later.

The benefits of this requirement are also unclear to me. Specifically, 
if we change YANG so that deprecated nodes must be implemented (or 
deviate deleted), then as soon as the author intends that the node is 
going to be removed it should immediately be marked as status 
deprecated, so this requirement doesn't seem to add anything.

> What does 'and currently supported' mean?
I was trying to mean "YANG modules" that are still regarded as current 
rather than ones that are effectively obsoleted and not used.  But 
thinking about this some more, it probably isn't really relevant anyway.

>   Can we simply remove this?
Yes, I think that it fine.  I.e. the requirement becomes:

        4.5  If multiple revisions of a YANG module are published, then the solution
             SHOULD allow for bug fixes to be made to an older revision of the module.

> data models that use unrestricted references to other data nodes.
This sounds reasonable, please can you provide text.

Do you mean, for example, node-instance-identifier from RFC 8341?

Thanks,
Rob

---

From: Robert Wilton <[email-masked]>
Date: Thu, 21 Jun 2018 11:28:01 +0100

Hi Qin,

On 21/06/2018 09:31, Qin Wu wrote:
> *发件人:*Netmod-ver-dt [mailto:[email-masked]] *代表 
> *Robert Wilton
> *发送时间:*2018年6月20日23:47
> *收件人:*Reshad Rahman (rrahman); Juergen Schoenwaelder; 
> [email-masked]; Balazs Lengyel
> *主题:*Re: [Netmod-ver-dt] Updated proposed requirements text
>
> everyone review before the meeting tomorrow.  It would be good if we 
> can agree the requirements so that we can get to consensus on the 
> problem definition before the IETF publication deadline.
>
> 4.4 is also open, do we need this? Really waiting for Balazs to 
> comment since he was pushing for this requirement.
>
> [Qin]:dependency between different versions of the same module or 
> dependency between one module with another module that is imported?
The dependency is between one module and another that is imported.

To give a random, made up example, we want to be to say that "ietf-ip 
version 1.x.y" can import from "ietf-interfaces version 1-3.*", but not 
anything later than "version 4.*" because it is not compatible.  
Instead, I would expect that there would also be a new revision of 
ietf-ip published (e.g. "ietf-ip version 2.e.f") that imports version 4 
or later (e.g. ietf-interfaces version 4.*).

> Secondly I think “import a specific revision” is equivalent to a 
> refined form YANG’s import statement.
"import a specific revision" is meant to equate to YANG 1.1 sec 5.1.1 
"import by revision", which I don't think really works because it 
introduces a very tight dependency between versions.  E.g. if all 
modules uses import by revision, then even making a backwards compatible 
change to one module would require that all importing modules are 
updated with a new revision to fix the import by revision statements.

So we are looking for an import mechanism that can handle both backwards 
compatible and non-backwards compatible changes.

Do you think that the requirement needs further clarification?

> The only missing from “import a specific revision”
> [Qin]: As described in section 12 of RFC7950, a client may support 
> different YANG versions of modules, e.g.,
> A client support a YANG version 1 module A importing YANG version 1.1 
> module B. I want make sure versions of modules
Good point.  Yes, we don't mean YANG version here.

Perhaps it would be more clear to use "revision" instead of "version" 
for requirements 2.2, 3.2, 4.4 (if kept), 5.2?  E.g. updated as per below:

Proposed replacement text for 2.2, 2.3, 4.4 and 5.2:

             nodes between two arbitrary YANG module revisions have (i)

             simultaneously support clients using different revisions of

             modules.  A client's choice of particular revision of one or

             more modules may restrict the particular revision of other

             future revision.

             the existing YANG 1.0/1.1 module update scheme [RFC 7950, 
section 11] to the newversioning scheme.

> [Qin]: A little bit confused, do we need to mix YANG version with 
> version of the module? Or  new scheme is referred to YANG 2.0, YANG x.x?

Does this text help clarify the requirement:

             the existing YANG 1.0/1.1 module update scheme [RFC 7950, 
section 11] to the newversioning scheme.

I don't think that we have properly discussed whether a new version of 
YANG is required.  I suspect that this point will get healthy debate 
once the requirements have been finalized and we get on to discussing 
solutions.

Thanks,
Rob

>     On 2018-06-20, 10:23 AM, "Netmod-ver-dt on behalf of Robert
>     Wilton" <[email-masked] on behalf of
>     rwilton=[email-masked]>
>     <mailto:[email-masked]=[email-masked]>
>     wrote:
>
>         > On Wed, Jun 20, 2018 at 11:56:38AM +0100, Robert Wilton wrote:
>
>         >>>> 2.2 A mechanism should be defined to determine whether
>     particular data nodes
>
>         >>>> between two arbitrary YANG module versions have been (i)
>     not changed, (ii)
>
>         >>>> changed in a backwards compatible way, (iii) changed in a
>     non backwards
>
>         >>>> compatible way.
>
>         >>> Do we need 'particular' here?
>
>         >> My aim is to express that the comparison is on per data
>     node basis rather
>
>         >> than just at the module level.
>
>         >>
>
>         >> To give an example, rather than knowing whether
>     ietf-interfaces@rev2 is
>
>         >> backwards incompatible in some way with
>     ietf-interfaces@rev1, I would like
>
>         >> to know for each data node path, whether or not it has been
>     changed in a
>
>         >> backwards incompatible way.
>
>         >>
>
>         >> If the client is only actually using a subset of a modules
>     data nodes, then
>
>         >> they probably only care whether that subset has been
>     updated in a non
>
>         >> backwards compatible way.
>
>         >>
>
>         >> Do you still think "particular" is redundant, or could this
>     be expressed in
>
>         >> a better way, or is the alternative text below better?
>
>         >>
>
>         >> "2.2 A mechanism should be defined to determine, for any
>     two arbitrary YANG
>
>         >> module versions, and for any given data node path, whether
>     the data node has
>
>         >> (i) not changed, (ii) changed in a backwards compatible
>     way, (iii) changed
>
>         >> in a non backwards compatible way."
>
>         >>
>
>         > Simply remove 'particular' from the original text. Since you
>     talk
>
>         > about data nodes, you talk about data nodes and I see no
>     reason to
>
>         > further complicate the statement.
>
>         OK.
>
>         >
>
>         >>>> 4.3 If a data node is deprecated or obsolete then it
>     would be useful if the
>
>         >>>> YANG module could indicate what alternatives exist.
>
>         >>> Should this include also an explicit requirement to have a
>     mechansim
>
>         >>> to document status changes of YANG definitions with explicit
>
>         >>> description text?
>
>         >> My aim was for the requirement text above to cover this.
>
>         >>
>
>         >> It is possible that a new optional YANG statement could be
>     added that gives
>
>         >> a schema path of an alternative object to use instead.
>     (E.g. for operational
>
>         >> state data, a deprecated 32 bit counter could point to a 64
>     bit equivalent
>
>         >> instead).  But I think that this is probably too much
>     unnecessary
>
>         >> complexity, and hence allowing status to have a description
>     statement is
>
>         >> probably adequate.
>
>         >>
>
>         >> So, would it make sense to reword this requirement to just
>     cover the status
>
>         >> description element?
>
>         >>
>
>         >> E.g to replace the requirement above with:
>
>         >>
>
>         >> "4.3 A mechanism is required to associate descriptive
>     status text with any deprecated or obsolete YANG definitions."
>
>         > I think we talk about two different things. Adding an optional
>
>         > description statement to the status statement is trivial.
>
>         "4.X A mechanism is required to associate descriptive status
>     text with any deprecated or obsolete YANG definitions."
>
>         >   Adding a
>
>         > 'replaced-by' reference is simple as long as a leaf is
>     replaced by
>
>         > another leaf, but what about more complex replacements? Do
>     we point to
>
>         > an entire list? Or even an xpath expression resulting in a
>     nodeset?
>
>         > What is a client exactly supposed to do with this? Is there any
>
>         > expectation of automation or is this just a machine readable
>     pointer?
>
>         > Hence, a 'replaced-by' reference is more complicated to
>     define and
>
>         > thus it might help to break this into two separate requirements.
>
>         >
>         >> I think that it comes down in YANG to what defines the formal
>
>         >> specification.  E.g. does a pattern statement (or range)
>     form part of the
>
>         >> specification of a data node?  Or is it the description
>     that specifies the
>
>         >> behaviour and the pattern statement is actually just an
>     implementation of
>
>         >> the API (that could have bugs in it).
>
>         > Both can be wrong. See also my example with an enum where
>     the label
>
>         > did not match the likely intended value. There simply is no
>     generic
>
>         > answer.
>
>         >
>
>         >> Is reducing the set of values supported by a pattern
>     statement still a
>
>         >> backwards compatible enhancement if the set of allowed
>     values defined by the
>
>         >> description statement hasn't changed?  My view is that it is.
>
>         > In this case, the change only changes when during the
>     processing an
>
>         > illegal value will be detected. It does not change the
>     allowed value
>
>         > set.
>
>         >
>
>         >>> I suggest that we reduce the requirement to just the first
>     sentence
>
>         >>> and we consider to add a section that discusses
>     specifically bug fixes
>
>         >>> and
>
>         >> Yes, do you mean just in the problem definition, or the
>     requirements section
>
>         >> as well?  Could you provide some text please?
>
>         > My proposal was to use simpley this:
>
>         >
>
>         >   4.5 If multiple revisions of a YANG module are published
>     and currently
>
>         >   supported, then the solution should allow for bug fixes to
>     be made to an
>
>         >   older revision of the module.
>
>         >
>         >>>> 5. Requirements related to documentation and education:
>
>         >>>>
>
>         >>>> 5.1. The solution should provide guidance to model
>     authors and clients on
>
>         >>>> how to use the
>
>         >>>> new YANG versioning scheme.
>
>         >>> Should we also have an explicit requirement that a new
>     YANG versioning
>
>         >>> scheme should describe how to transition from the current
>     versioning
>
>         >>> scheme to the new versioning scheme?
>
>         >> Yes, I think so.
>
>         >>
>
>         >> Perhaps:
>
>         >>
>
>         >> "5.2 The solution is required to describe how to transition
>     from the
>
>         >> existing YANG 1.0/1.1 versioning scheme to the new scheme."
>
>         > Works for me.
>
>         Added.
>
>         Thanks,
>
>         Rob
>
>         >
>
>         > /js
>
>         >
>
>     [email-masked] <mailto:[email-masked]>
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 21 Jun 2018 13:24:30 +0200

> OK, so for clarify, the existing 4.3 text is acceptable?

No, not the way it is written. See inline.

>               available on the same path and in the same module

Oh. I see that I left out 'non' in my proposal. Sorry. I do not think
backwards compatible changes are an issue. So my proposal was to say
this:

          [...] Specifically, if a particular data node
            is updated in a non backwards compatible way then it
            may be desirable for it to be available on the same
            path and in the same module namespace.

I believe there is value to stress the non backwards compatible case.
 
>             whether obsolete nodes are implemented by the server.

I am still not sure what the value of this is. Lets discuss later.
 
> compliant, rather this could just be a leaf in YANG library that indicates
> strictly whether the server implements obsolete nodes or not (e.g. either it
> doesn't implement any, or it might implement some or all of them).
> The benefit of this is that is allows the client to know the 'exact' schema,
> but I agree with that the real benefit of this is somewhat unclear:
>  - clients should not expect obsolete configuration to work (and the flag
> doesn't help here).
> This is also required to make the client robust and forward compatible with
> future revisions/versions.
> 
> client to categories warnings appropriately, but even that seems somewhat
> unlikely  to me.
> 

What is the value of this bit for a client? A client not using
obsolete definitions does not need this bit. And if we consider
clients that only work with obsolete stuff, then the client needs to
know what is obsolete and implemented. In practice, people will be
forced to think twice before moving deprecated to obsolete but once
its obsolete, you took the decision that clients lagging behind will
stop or finally need to be updated. Any gray area inbetween is
implementation choice. (You move to obsolete, applications you did not
know if break badly, you may implement a bunch of obsolete leafs to
lower the pain but still the message is that the application needs
updates.)

> > >              possible for the YANG module to indicate what alternatives

The question here is what 'indicate what alternatives exist' means. I
would not read this as 'we provide the guideline that replacements are
explained in description statements'.

> The benefits of this requirement are also unclear to me. Specifically, if we
> change YANG so that deprecated nodes must be implemented (or deviate
> deleted), then as soon as the author intends that the node is going to be
> removed it should immediately be marked as status deprecated, so this
> requirement doesn't seem to add anything.

Yes, this is how I look at this. While some vendors may have
controlled release schedules, clearly anything in the IETF does not
have this (and even worse, by the time an update of an IETF
specification is actually done, almost anything can happen).

The programming languages I know that have some deprecated annotations
do not seem to bind this to future releases and dates.

> rather than ones that are effectively obsoleted and not used.  But thinking
> about this some more, it probably isn't really relevant anyway.
> 

Yes, this rewrite is good and avoids the problem.
 
> Do you mean, for example, node-instance-identifier from RFC 8341?

For example. This goes back to my statement that we move the naming
scheme effectively from (module, path) to (module, path, version) and
hence everywhere where we use (module, path) we now need to have a
version context. Within YANG modules, version constrained imports may
help. For accessing datastores, a version context in which a
NETCONF/RESTCONF session exist may be needed to support multiple
versions. For other stuff that is operating on datastores data (NACM
is an example), you need this version context as well. Now the answer
for NACM may be that the version context is resolved from the
NETCONF/RESTCONF session version context. But what about data obtained
by clients and stored in say files or a database? I think we need at
least discuss this and make sure that implementors understand that
(module, path) is not sufficient anymore to know what it is (and this
may affect applications - so a clear warning about this is I think the
minimum that is needed).

/js

---

From: Qin Wu <[email-masked]>
Date: Thu, 21 Jun 2018 11:44:31 +0000

Hi,Rob:

发件人: Robert Wilton [mailto:[email-masked]]
发送时间: 2018年6月21日 18:28
收件人: Qin Wu; Reshad Rahman (rrahman); Juergen Schoenwaelder; [email-masked]; Balazs Lengyel
主题: Re: [Netmod-ver-dt] Updated proposed requirements text

Hi Qin,

发件人: Netmod-ver-dt [mailto:[email-masked]] 代表 Robert Wilton
发送时间: 2018年6月20日 23:47
收件人: Reshad Rahman (rrahman); Juergen Schoenwaelder; [email-masked]<mailto:[email-masked]>; Balazs Lengyel
主题: Re: [Netmod-ver-dt] Updated proposed requirements text

       to modules:

            module name).

To give a random, made up example, we want to be to say that "ietf-ip version 1.x.y" can import from "ietf-interfaces version 1-3.*", but not anything later than "version 4.*" because it is not compatible.  Instead, I would expect that there would also be a new revision of ietf-ip published (e.g. "ietf-ip version 2.e.f") that imports version 4 or later (e.g. ietf-interfaces version 4.*).

Secondly I think “import a specific revision” is equivalent to a refined form YANG’s import statement.
"import a specific revision" is meant to equate to YANG 1.1 sec 5.1.1 "import by revision", which I don't think really works because it introduces a very tight dependency between versions.  E.g. if all modules uses import by revision, then even making a backwards compatible change to one module would require that all importing modules are updated with a new revision to fix the import by revision statements.

So we are looking for an import mechanism that can handle both backwards compatible and non-backwards compatible changes.

[Qin]: Yes, that is limitation of existing import mechanism, we can consider to add meatadata to existing import mechanism. Alternatively,if my understanding is correct, the existing revision date and new versioning scheme is one to one relationship, if we can establish a database to maintain mapping between revision date and new versioning scheme, we
May not need to bother import mechanism,:-) ,is this opt out?

       module revisions:

            functionality, or both.

Perhaps it would be more clear to use "revision" instead of "version" for requirements 2.2, 3.2, 4.4 (if kept), 5.2?  E.g. updated as per below:

[Qin]:Agree. The proposed changes look good.

            future revision.

                       section 11] to the new versioning scheme.

       of data nodes:

            exist.

            future version.

            scheme.

                       section 11] to the new versioning scheme.

I don't think that we have properly discussed whether a new version of YANG is required.  I suspect that this point will get healthy debate once the requirements have been finalized and we get on to discussing solutions.

[Qin]: The proposed change looks good, thanks.

Thanks,
Rob

Thanks,
Rob

Done.

    OK.

    Added.

    Thanks,

    Rob

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 21 Jun 2018 13:49:21 +0200

On 6/20/2018 9:28 AM, Juergen
Schoenwaelder wrote:

BALAZS: There are multiple different things
here you may want to document:

potential alternatives

probable time of removal of the implementation (often known in
vendor modules)

reason for removal (not-used, change over to a standard solution,
etc.

proposed new text:

"If a data node is deprecated or obsolete then it SHALL be
possible to indicate whether alternatives exist, the reason for
the status change or any other status related information."

BALAZS:  change supported to implemented. The
problem is we do not know how implemented/supported relates to
obsolete/deprecated. That is one of our aims to clarify this. You
are absolutely right that removing (the implementation) for
something is much more frequent in vendor modules, and will
probably be rare in IETF.

How the process works in Ericsson (vendor YAMs not standard ones)

You decide something should go away

deprecate it, to give notice to its
users that it will be removed, but it still must works as
defined by the YAM

after 2 releases or one more year it is
obsoleted and its implementation is removed.

There can always be special agreements to
remove it faster, slower, not at all just use deprecation to "try"
to push users to a better alternative.

--
Balazs Lengyel Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909 email: [email-masked]

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 21 Jun 2018 13:54:44 +0200

On 6/20/2018 12:56 PM, Robert Wilton
wrote:

4.4 For any data
node that is currently supported, it would be useful to

indicate that the data node is expected to become unsupported
in a future

revision.

I am not sure I understand this. What is 'supported' and
'unsupported'

and how does this relate to YANG's notion of 'current',
'deprecated',

'obsolete'? This also means that one has to make predictions
about

OK, I used "current"/"unsupported" to get round the fact that it
is unclear whether deprecated nodes are implemented.

Balazs may be able to explain/define this better, I think that the
idea is to be able to provide forward guidance.  E.g, mark a node
that has been deprecated that it will become obsolete at some
time, or future release, or future version.

Balazs, I don't know if just having a description statement under
status is sufficient to meet this requirement?

BALAZS: Replied in a separate mail. IMHO some
text would be enough. That's what we use today. There are multiple
different types of information that could be needed/useful here.
Even alternative nodes are often not just a simple schema node
identifier. Often the replacement may split a leaf into two leafs,
or in replace 4 deprecated leafs with 5 others.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 21 Jun 2018 14:01:58 +0200

On Thu, Jun 21, 2018 at 01:49:21PM +0200, Balazs Lengyel wrote:
>    On 6/20/2018 9:28 AM, Juergen Schoenwaelder wrote:
> 
>    BALAZS: There are multiple different things here you may want to document:
>    potential alternatives
>    probable time of removal of the implementation (often known in vendor
>    modules)
>    reason for removal (not-used, change over to a standard solution, etc.
>    proposed new text:
>    "If a data node is deprecated or obsolete then it SHALL be possible to
>    indicate whether alternatives exist, the reason for the status change or
>    any other status related information."

Perhaps s/indicate/document/ (and perhaps s/SHALL/MUST since they mean
the same per RFC 2119 and MUST is more commonly known).

>    BALAZS:  change supported to implemented. The problem is we do not know
>    how implemented/supported relates to obsolete/deprecated. That is one of
>    our aims to clarify this. You are absolutely right that removing (the
>    implementation) for something is much more frequent in vendor modules, and
>    will probably be rare in IETF.
>     1. You decide something should go away
>     2. deprecate it, to give notice to its users that it will be removed, but
>        it still must works as defined by the YAM
>     3. after 2 releases or one more year it is obsoleted and its
>        implementation is removed.
> 
>    There can always be special agreements to remove it faster, slower, not at
>    all just use deprecation to "try" to push users to a better alternative.
>

I am still confused what the requirement here is. Once we have solved
4.1, is there anything left to do? Perhaps you want is to have 4.1
stated tighter that decprecated must mean continued implementation and
then we do not need 4.4? Of if decprecated keeps a fuzzy may implement
definition, then we need an additional to-be-deprecated stated
instead? Perhaps 4.1 and 4.4 then become a new requirement:

4.X A mechanism is REQUIRED to indicate that certain YANG definitions
    are not supported anymore in future revisions but definitions
    marked as such MUST still be implemented by compliant servers.

And then a possible solution is to change 'status deprecated' to do
exactly that (i.e., deprecated nodes MUST be implemented).

/js

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 21 Jun 2018 14:06:38 +0200

On 6/20/2018 5:47 PM, Robert Wilton
wrote:

So, the current requirement text from github is as follows,
please can everyone review before the meeting tomorrow.  It
would be good if we can agree the requirements so that we can
get to consensus on the problem definition before the IETF
publication deadline.

There is still one open issue for 4.3: Should we split this
into (i) a description requirement vs (ii) machine readable
reference (e.g. xpath).

BALAZS: IMHO text is absolutely needed for
more then just alternatives.  The goal is for the human user to
understand it. In my practice a simple replacement is very rare so machine
readable reference is not needed. If you replace
something you always change something (structure, valuespace,
behavior, etc.). It will not be possible to automate this change.
Just thing about ietf-yang-library for NMDA, the modules list was
moved into a different location and spit in two.

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 21 Jun 2018 14:14:51 +0200

> data models that use unrestricted references to other data nodes.
BALAZS: IMHO allowing different NACM rules for different versions of the 
YAM would be very complicated and I would like to avoid it. If you look 
at it from a human operator point of view this could become really ugly. 
So at least for NACM namespace/path should be valid for all versions of 
the model.

---

From: Robert Wilton <[email-masked]>
Date: Thu, 21 Jun 2018 13:17:32 +0100

On 21/06/2018 12:44, Qin Wu wrote:
>
> Hi,Rob:
>
> *发件人:*Robert Wilton [mailto:[email-masked]]
> *发送时间:*2018年6月21日18:28
> *收件人:*Qin Wu; Reshad Rahman (rrahman); Juergen Schoenwaelder; 
>     [email-masked] <mailto:[email-masked]>; Balazs Lengyel
>     So, the current requirement text from github is as follows, please
>     can everyone review before the meeting tomorrow.  It would be good
>     if we can agree the requirements so that we can get to consensus
>     on the problem definition before the IETF publication deadline.
>
>     There is still one open issue for 4.3: Should we split this into
>     (i) a description requirement vs (ii) machine readable reference
>     (e.g. xpath).
>
> version 1.x.y" can import from "ietf-interfaces version 1-3.*", but 
> not anything later than "version 4.*" because it is not compatible.  
> ietf-ip published (e.g. "ietf-ip version 2.e.f") that imports version 
> 4 or later (e.g. ietf-interfaces version 4.*).
>
>
>
> modules uses import by revision, then even making a backwards 
> compatible change to one module would require that all importing 
> modules are updated with a new revision to fix the import by revision 
> statements.
>
> So we are looking for an import mechanism that can handle both 
> backwards compatible and non-backwards compatible changes.
>
> [Qin]: Yes, that is limitation of existing import mechanism, we can 
> consider to add meatadata to existing import mechanism. 
> Alternatively,if my understanding is correct, the existing revision 
> date and new versioning scheme is one to one relationship, if we can 
> establish a database to maintain mapping between revision date and new 
> versioning scheme, we
>

It will be part of the solution proposals to define what (if anything) 
happens to the existing revision date (e.g. covered by requirement 5.2).

I think that import with revision date is essentially broken - at least 
for standard models.  For vendor models that are auto-generated then it 
may be OK, since updating the import revision for a 1000 modules can be 
done in an automated way, although that is probably a lot less helpful 
for clients.

The other opt out is to just use the existing import, but then that is 
missing the dependency information.  E.g. imagine trying to manage a 
linux server where each package can specify what other packages it 
depends on, but not what particular revision of package it depends on.  
I think that you would have a mess.

So, I think that any viable solution must address this problem, but that 
doesn't mean that everyone has to use it.

Thanks,
Rob

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 21 Jun 2018 14:19:54 +0200

On 6/21/2018 8:36 AM, Juergen
Schoenwaelder wrote:

BALAZS:  Both obsolete and Deprecated currently means it may or may
not be implemented. Not very useful

Compared to that we do introduce a
deprecated-but-still-implemented-as-described state. IMHO this is
what deprecated should have been originally. A still better solution
if possible would be to redefine the meaning of deprecated to
deprecated-but-still-implemented-as-described: in short a fix on
rfc7950.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 21 Jun 2018 14:26:22 +0200

Balazs,

we need to come down to _requirements_.

/js

On Thu, Jun 21, 2018 at 02:19:54PM +0200, Balazs Lengyel wrote:
>    BALAZS:  Both obsolete and Deprecated currently means it may or may not be
>    implemented. Not very useful
>    deprecated-but-still-implemented-as-described state. IMHO this is what
>    deprecated should have been originally. A still better solution if
>    possible would be to redefine the meaning of deprecated to
>    deprecated-but-still-implemented-as-described: in short a fix on rfc7950.
> 
>  --
>  Mobile: +36-70-330-7909              email: [1][email-masked]
> 
> References
> 
>    Visible links
>    1. mailto:[email-masked]

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 21 Jun 2018 14:27:46 +0200

On 6/21/2018 11:54 AM, Robert Wilton
wrote:

4.4  For
any data node that is currently supported, it SHOULD be

possible to indicate that it will become
unsupported in a

future version.

So we add a new stated between 'current' and 'deprecated', a
'soon to

be deprecated' state?

I do not believe
this is needed. Or I still do

I think that this one would also be good to discuss in the meeting
later.

The benefits of this requirement are also unclear to me.
Specifically, if we change YANG so that deprecated nodes must be
implemented (or deviate deleted), then as soon as the author
intends that the node is going to be removed it should immediately
be marked as status deprecated, so this requirement doesn't seem
to add anything.

BALAZS: You are mixing the requirement with the solution.

The requirement is to be able to have a node deprecated but still
implemented.

The solution maybe a bugfix on deprecated or may be a new state if
deprecated can not be changed without going to YANG 2.0.

The functionality is what's needed, the solution can be many things.

---

From: Robert Wilton <[email-masked]>
Date: Thu, 21 Jun 2018 13:28:35 +0100

> the same per RFC 2119 and MUST is more commonly known).
Yes.

> exactly that (i.e., deprecated nodes MUST be implemented).
I like this requirement text (and proposed solution :-)

Thanks,
Rob

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 21 Jun 2018 14:30:33 +0200

4.5  If
multiple revisions of a YANG module are published and

currently supported, then the solution SHOULD
allow for bug

fixes to be made to an older revision of the
module.

I was trying to mean "YANG modules" that are still regarded as
current rather than ones that are effectively obsoleted and not
used.  But thinking about this some more, it probably isn't really
relevant anyway.

Can we simply
remove this?

4.5  If multiple revisions of a YANG module are published,
then the solution

SHOULD allow for bug fixes to be made to an older
revision of the module.

BALAZS: IMHO the original text is easier to understand.

However I would generally use the word implemented for
data nodes that are still available via netconf/restconf/etc.
Support is a very generic term, it can mean many things.

---

From: Robert Wilton <[email-masked]>
Date: Thu, 21 Jun 2018 13:31:06 +0100

> I believe there is value to stress the non backwards compatible case.
OK, agreed, this is fine.

OK.

Yes.

> may affect applications - so a clear warning about this is I think the
Yes, I agree to adding this as a requirement.  If you can provide text 
before the meeting that would be great, or otherwise I can have a go 
after I have made the other markups.

I'm hoping that we can broadly agree the requirements text quite quickly 
in the meeting so that we can work on the problem statement text.

Thanks,
Rob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 21 Jun 2018 14:34:31 +0200

On Thu, Jun 21, 2018 at 02:14:51PM +0200, Balazs Lengyel wrote:
> 
> BALAZS: IMHO allowing different NACM rules for different versions of the YAM
> would be very complicated and I would like to avoid it. If you look at it
> from a human operator point of view this could become really ugly. So at
> least for NACM namespace/path should be valid for all versions of the model.
>

If we allow arbitrary non-backwards compatible changes, then things
may fall apart since semantics can change and what was harmless to
expose in 1.x.z may be harmful to expose in 2.x.y or vice versa. I
understand that we all want a simple world but in engineering a
benefit here usually comes with a cost there. But NACM is just _an
example_ for something that does not have a version context today (and
may ultimately need one).

/js

---

From: Robert Wilton <[email-masked]>
Date: Thu, 21 Jun 2018 13:40:06 +0100

> may ultimately need one).

This is on to solutions, but If we have a mechanism for tooling to 
determine whether a data node between two schema revisions has been 
updated in a non backwards compatible way, then it would at least be 
possible to check the NACM paths and flag to an operator whether the 
NACM policy has been potentially broken.

Thanks,
Rob

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 21 Jun 2018 14:40:23 +0200

On 6/21/2018 2:01 PM, Juergen
Schoenwaelder wrote:

BALAZS: OK

BALAZS: I would be happy to change deprecated
to deprecated-but-must-still-be-implemented.

However 4.1 only states that we must be able to find out what
deprecated means. If we might find, it means
deprecated-and-not-implemented, 4.4 is still needed. If we change
deprecated to deprecated-but-must-still-be-implmented we can
remove 4.4

---

From: Robert Wilton <[email-masked]>
Date: Thu, 21 Jun 2018 13:41:54 +0100

On 21/06/2018 13:30, Balazs Lengyel wrote:
>
>
>
> On 6/21/2018 11:54 AM, Robert Wilton wrote:
> However I would generally use the word */implemented /*for data nodes 
> that are still available via netconf/restconf/etc. Support is a very 
> generic term, it can mean many things.
Problem with "implemented" is that can easily also be interpreted as 
"are there any networks still using that data node", something that is 
generally quite hard to determine ;-)

Thanks,
Rob

> Mobile: +36-70-330-7909              email:[email-masked]  
>
>

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 21 Jun 2018 14:47:50 +0200

On 6/21/2018 2:34 PM, Juergen
Schoenwaelder wrote:

BALAZS: I see a risk of over-engineering here.
If you want/need different NACM rules, that is a really big
change, that should be done by changing the data nodes name/path,
not just its properties.

A modeler will always need to strike a delicate balance: if the
NBC change is big rename your node/module. If it is small and
might be used without clients being effected do an NBC update. Now
don't even ask me what I mean by big :-)

---

From: Robert Wilton <[email-masked]>
Date: Thu, 21 Jun 2018 13:50:03 +0100

OK, for the requirements in section 4, I currently have:

        4.3  If a data node is deprecated or obsolete then it MUST be
             possible to document in the YANG module what alternatives
             exist, the reason for the status change, or any other status
             related information.

        4.4  PROPOSE ADDING: A mechanism is REQUIRED to indicate that
             certain YANG definitions are not supported anymore in future
             revisions but definitions marked as such MUST still be
             implemented by compliant servers.

        4.5  PROPOSE REMOVING: For any data node that is currently
             supported, it SHOULD be possible to indicate that it will
             become unsupported in a future version.

        4.6  If multiple revisions of a YANG module are published, then
             the solution SHOULD allow for bug fixes to be made to an
             older revision of the module.

Are we agreed to keep 4.4 and remove 4.5.  I've tweaked the text for 
4.3, is it OK?

Thanks,
Rob

On 21/06/2018 13:40, Balazs Lengyel wrote:
>
>
>
> On 6/21/2018 2:01 PM, Juergen Schoenwaelder wrote:
> BALAZS: I would be happy to change deprecated to 
> deprecated-but-must-still-be-implemented.
> deprecated to deprecated-but-must-still-be-implmented we can remove 4.4
> --

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 21 Jun 2018 14:52:12 +0200

On Thu, Jun 21, 2018 at 02:47:50PM +0200, Balazs Lengyel wrote:
>    On 6/21/2018 2:34 PM, Juergen Schoenwaelder wrote:
> 
>    BALAZS: I see a risk of over-engineering here. If you want/need different
>    NACM rules, that is a really big change, that should be done by changing
>    the data nodes name/path, not just its properties.
>    A modeler will always need to strike a delicate balance: if the NBC change
>    is big rename your node/module. If it is small and might be used without
>    clients being effected do an NBC update. Now don't even ask me what I mean
>    by big :-)
>

I am not proposing to change NACM but I want a requirement that the
implications of different update rules may affect other systems that
so far could simply assume (module, path) has a fixed semantic.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 21 Jun 2018 14:53:33 +0200

On Thu, Jun 21, 2018 at 02:40:23PM +0200, Balazs Lengyel wrote:
>    However 4.1 only states that we must be able to find out what deprecated
>    means. If we might find, it means deprecated-and-not-implemented, 4.4 is
>    still needed. If we change deprecated to
>    deprecated-but-must-still-be-implmented we can remove 4.4
> 

This is why I proposed 4.X as a replacement for 4.1 and 4.4. Does this
work for you?

/js

---

From: Robert Wilton <[email-masked]>
Date: Thu, 21 Jun 2018 13:58:53 +0100

On 21/06/2018 13:47, Balazs Lengyel wrote:
> BALAZS: I see a risk of over-engineering here. If you want/need 
> different NACM rules, that is a really big change, that should be done 
> by changing the data nodes name/path, not just its properties.
> A modeler will always need to strike a delicate balance: if the NBC 
> change is big rename your node/module. If it is small and might be 
> used without clients being effected do an NBC update. Now don't even 
> ask me what I mean by big :-)

As a module author you don't know what NACM rules someone might choose 
to implement that reference your nodes.

The issue you be if you had a module about user information.
In v1 of your user model, the "private" leaf contains "some private 
information about the user, not to be made available to outside entities"
In v2 of your user model, the "private" leaf contains "the user password 
(insecurely stored as plain text)"

It might be OK for an operator to have read access to the "private" leaf 
in v1 or the model, but not the "private" leaf in the v2 model.  So the 
NACM policy would need to change if this model was updated, how this 
still problem get detected and mitigated?

I appreciate that this is a somewhat contrived example, but I suspect 
that more subtle realistic examples also exist.

Thanks,
Rob

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 21 Jun 2018 15:00:03 +0200

Maybe we should have a terminology section about what supported
means.

- implemented in the network node / yang-server as defined by
the YAM

- supported as in maintained by a company issuing bugfixes and
upgrade

On 6/21/2018 2:50 PM, Robert Wilton
wrote:

BALAZS: OK but maybe

s/are not supported anymore in future/will not be supported in
future/

The intent is OK, but mixing the word future and present tense
seems strange.

Are we agreed to keep 4.4 and remove 4.5.  I've tweaked the text
for 4.3, is it OK?

BALAZS: OK

Thanks,

Rob

On 21/06/2018 13:40, Balazs Lengyel
wrote:

BALAZS: OK

BALAZS: I would be happy to change
deprecated to deprecated-but-must-still-be-implemented.

However 4.1 only states that we must be able to find out what
deprecated means. If we might find, it means
deprecated-and-not-implemented, 4.4 is still needed. If we
change deprecated to deprecated-but-must-still-be-implmented
we can remove 4.4

.

---

From: Robert Wilton <[email-masked]>
Date: Thu, 21 Jun 2018 14:00:50 +0100

>              whether obsolete nodes are implemented by the server.
Sorry - this one is also still open, I'll flag this one for discussion 
as well.

Thanks,
Rob

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 21 Jun 2018 15:03:31 +0200

On 6/21/2018 2:52 PM, Juergen
Schoenwaelder wrote:

/js

BALAZS: I like your idea.

What do you think in the solution draft shouldn't we have a
related discussion about when to use NBC changes and when to rename
things. Basically trying to give an idea about what a "big" change
means. I assume we can't define it precisely, but giving some
guidelines seems better then keeping silent.

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 21 Jun 2018 15:06:55 +0200

> This is why I proposed 4.X as a replacement for 4.1 and 4.4. Does this
BALAZS: It works for me. Fixing deprecated is preferred. (I assume 
that's what you mean by 4.X.)
Just I don't know if others will accept that or claim that it is an NBC 
change on YANG itself, so we must do a YANG 2.0.

---

From: Robert Wilton <[email-masked]>
Date: Thu, 21 Jun 2018 14:10:40 +0100

On 21/06/2018 14:00, Balazs Lengyel wrote:
>
> Maybe we should have a terminology section about what supported means.
>
>   * - implemented in the network node / yang-server as defined by the YAM
>   * - supported as in maintained by a company issuing bugfixes and upgrade
>
Not sure.  If we can requirements that can be understood without 
terminology that might be better.

>  *
>
>
> On 6/21/2018 2:50 PM, Robert Wilton wrote:
>>
> s/are not supported anymore in future/will not be supported in future/
> The intent is OK, but mixing the word future and present tense seems 
> strange.

Or perhaps the following wording is better (to avoid "supported"):

A mechanism is REQUIRED to indicate that certain YANG definitions will 
become status obsolete in a future revision but definitions marked as 
such MUST still be implemented by compliant servers.

Thanks,
Rob

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 21 Jun 2018 15:11:22 +0200

On 6/21/2018 2:58 PM, Robert Wilton
wrote:

On 21/06/2018 13:47, Balazs Lengyel
wrote:

BALAZS: I see a risk of over-engineering
here. If you want/need different NACM rules, that is a really
big change, that should be done by changing the data nodes
name/path, not just its properties.

A modeler will always need to strike a delicate balance: if
the NBC change is big rename your node/module. If it is small
and might be used without clients being effected do an NBC
update. Now don't even ask me what I mean by big :-)

As a module author you don't know what NACM rules someone might
choose to implement that reference your nodes.

In v1 of your user model, the "private" leaf contains "some
private information about the user, not to be made available to
outside entities"

In v2 of your user model, the "private" leaf contains "the user
password (insecurely stored as plain text)"

It might be OK for an operator to have read access to the
"private" leaf in v1 or the model, but not the "private" leaf in
the v2 model.  So the NACM policy would need to change if this
model was updated, how this still problem get detected and
mitigated?

I appreciate that this is a somewhat contrived example, but I
suspect that more subtle realistic examples also exist.

BALAZS: This is not a contrived example. This is just an example
where you crossed the border between what you should or should not
do using NBC changes. IMHO changing security aspects is a big
changed. In another mail I already proposed to have guidelines about
what you should and shouldn't do with NBC changes.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 21 Jun 2018 15:11:44 +0200

>    The intent is OK, but mixing the word future and present tense seems

yep
 
>      Are we agreed to keep 4.4 and remove 4.5.  I've tweaked the text for

With 4.4 in place, I think we can remove 4.1 and 4.2 and 4.5.

/js

---

From: Robert Wilton <[email-masked]>
Date: Thu, 21 Jun 2018 14:13:40 +0100

> so far could simply assume (module, path) has a fixed semantic.
Do we need a similar requirement about versioning of instance data, or 
would this be covered by the same requirement that you have proposed?

Thanks,
Rob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 21 Jun 2018 15:14:00 +0200

On Thu, Jun 21, 2018 at 03:06:55PM +0200, Balazs Lengyel wrote:
> 
> BALAZS: It works for me. Fixing deprecated is preferred. (I assume that's
> what you mean by 4.X.)

I trying to separate the requirement from the solution. I agree that
fixing deprecated is a viable solution.

> change on YANG itself, so we must do a YANG 2.0.

I personally believe YANG 2.0 is the proper way to go but not because
we change deprecated... But whether YANG 2.0 is needed or not is not
relevant for getting the requirements nailed down.

/js

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 21 Jun 2018 15:14:10 +0200

On 6/21/2018 3:00 PM, Robert Wilton
wrote:

On 21/06/2018 13:50, Robert Wilton
wrote:

Sorry - this one is also still open, I'll flag this one for
discussion as well.

BALAZS: I could live without the obsolete part. In that case we just
say:

obsolete may or may not be there and you touch it at your own risk.

Fixing deprecated is important, fixing obsolete is not so much.

Thanks,

Rob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 21 Jun 2018 15:16:31 +0200

On Thu, Jun 21, 2018 at 02:10:40PM +0100, Robert Wilton wrote:
 
> become status obsolete in a future revision but definitions marked as such
> MUST still be implemented by compliant servers.

s/become status obsolete/become obsolete/

Perhaps also:

s/YANG definitions/definitions in a YANG module/

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 21 Jun 2018 15:19:10 +0200

On Thu, Jun 21, 2018 at 02:13:40PM +0100, Robert Wilton wrote:
> Do we need a similar requirement about versioning of instance data, or would
> this be covered by the same requirement that you have proposed?
>

I think I am mostly talking about instance data or references to
instance data. Yes, if I store a counter in a database and the range
of the counter changes, then to do proper data analytics, I need to
know which counter instances have which range (e.g., to understand
rollovers correctly).

/js

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 21 Jun 2018 15:21:28 +0200

On 6/21/2018 3:11 PM, Juergen
Schoenwaelder wrote:

BALAZS: OK but maybe

yep

/js

BALAZS:  OK to remove 4.2 and 4.5. But unless
we fix deprecated to mean deprecated-but-still-implemented I would
like to keep 4.1. There will be deprecated schema nodes, and I
would like to uinderstand whether they are reliably usable (at
least usable on a specific individual yang-server).

(Unless we deprecate the deprecated status :-)  )

---

From: Robert Wilton <[email-masked]>
Date: Thu, 21 Jun 2018 14:23:50 +0100

> know which counter instances have which range (e.g., to understand
OK, as a starting point, perhaps something like:

        5.3  The solution MUST describe how the versioning scheme applies
             to instance data, and references to instance data, for which
             the schema definition has been updated in a non backwards
             compatible way.

Thanks,
Rob

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 21 Jun 2018 15:25:41 +0200

On 6/21/2018 3:13 PM, Robert Wilton wrote:
>>> different
>>> NBC change
BALAZS: What exactly would versioning of instance data mean?

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 21 Jun 2018 15:27:51 +0200

On Thu, Jun 21, 2018 at 03:21:28PM +0200, Balazs Lengyel wrote:
> 
>    BALAZS:  OK to remove 4.2 and 4.5. But unless we fix deprecated to mean
>    deprecated-but-still-implemented I would like to keep 4.1. There will be
>    deprecated schema nodes, and I would like to uinderstand whether they are
>    reliably usable (at least usable on a specific individual yang-server).

As of today, you can't rely on deprecated nodes to be available. We
can only do something for the future (either by fixing deprecated or
introducing a new to-be-deprecated state). I do not see why 4.1 is
really needed - it seems to favour a specific solution for 4.4. (On
the other hand, I am not strongly against keeping 4.1 since adding a
new to-be-deprecated state does not seem like a good solution to me).
But from a pure requirements perspective, it seems 4.4 is sufficient.

/js

---

From: Robert Wilton <[email-masked]>
Date: Thu, 21 Jun 2018 14:30:15 +0100

On 21/06/2018 14:25, Balazs Lengyel wrote:
>> Do we need a similar requirement about versioning of instance data, 
>> or would this be covered by the same requirement that you have proposed?
I don't know.  I think that has to be figured out, but any solution 
should at least consider what it means :-)

E.g. perhaps it should mean that in your instance data draft, that it 
lists the module revisions of the embodied instance data? Perhaps that 
is there already - I can't remember :-)

Thanks,
Rob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 21 Jun 2018 15:30:49 +0200

> BALAZS: What exactly would versioning of instance data mean?

I think it is sloppy wording for "a value may have different
interpretations depending on the version of the underlying data node
definition". So to interpret instance data correctly, you need to
know (module, path, version) and not just (module, path).

/js

---

From: Robert Wilton <[email-masked]>
Date: Thu, 21 Jun 2018 14:32:45 +0100

> know (module, path, version) and not just (module, path).
Sorry, yes, that is what I meant.

Thanks,
Rob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 21 Jun 2018 15:33:00 +0200

>             the schema definition has been updated in a non backwards

I suggest 'affects the interpretation of' instead of 'applies':

       5.3  The solution MUST describe how the versioning scheme affects
            the interpretation of instance data and references to instance
	    data, for which the schema definition has been updated in a
	    non backwards compatible way.

/js

---

From: Robert Wilton <[email-masked]>
Date: Thu, 21 Jun 2018 14:37:03 +0100

OK.

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 21 Jun 2018 15:43:04 +0200

I would still like to add:

17.19   The solution MUST describe potential risks of changing the 
meaning of a schema node in a non-backwards compatible way, and SHOULD 
describe when a change SHOULD be done by renaming the schema node 
instead of just changing it's definition.

E.g. completely redefining an existing node, or changing the security 
sensitivity of a data node should be done by renaming the schema node.

Balazs