Subject: [Netmod-ver-dt] Requirements draft update

From: Robert Wilton <[email-masked]>
Date: Wed, 3 Oct 2018 11:31:41 +0100

Lou would like us to make a call for WG adoption of the requirements draft.

What do we need to resolve/clarify before we do that?  My list:

(1) Gert asked for a definition of backwards compatible.  So, I think 
that the draft can be updated to state that it is using RFC 7950 sec 11 
definition for backwards compatible changes.

(2) Vladimir had queried requirement 2.2.  I've requested clarification 
on this on the alias.  Proposing no change.

(3) Chris Hopp's would like a rewording of requirement 1.2.  I'm 
proposing sending this alternative wording to Netmod, OK?:

Old:

        1.2  A mechanism is REQUIRED to update a module in a non-backward
             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 is
             updated in a non-backward compatible way then it may be
             desirable for it to be available on the same path and in the
             same module namespace.

New:

        1.2  A mechanism is REQUIRED to update a module in a non-backward
             compatible way without impacting clients that do not access
             any data nodes updated in a non-backwards compatible way.
             For example, if a particular data node is updated in a
             non-backward compatible way then it may be desirable for it
             to be available on the same path and in the same module
             namespace.

(4) Are there any additional requirements that we should define before 
making a call for WG adoption?:

(i) I think we should add an explicit requirement to allow for 
branches/releases:

        1.4  The solution MUST allow for modules to be
             versioned by software release.  In particular,
             backwards compatible enhancements and bug fixes
             MUST be allowed in any non latest release.

Anything else?

Thanks,
Rob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 3 Oct 2018 16:18:47 +0200

On Wed, Oct 03, 2018 at 11:31:41AM +0100, Robert Wilton wrote:
> 
> (3) Chris Hopp's would like a rewording of requirement 1.2.  I'm proposing
> sending this alternative wording to Netmod, OK?:
> 
> Old:
> 

What is the issue that the rewrite tries to solve? I find the original
text clearer, except perhaps this change in the second sentence:

        1.2  A mechanism is REQUIRED to update a module in a non-backward
             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 is
             not updated or updated in a backward compatible way then it
	     may be desirable for it to be available on the same path and
	     in the same module namespace.

/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: Robert Wilton <[email-masked]>
Date: Wed, 3 Oct 2018 15:44:59 +0100

Hi Juergen,

I think that his comment was that the requirement text was predisposing 
a particular solution.  I.e. I think that he was objecting that the 
requirement assumes that the paths/namespaces should be the same for a 
module that has been updated in a nbc way.  In particular he was 
thinking of a solution where each major version gets a new module name 
(foo-<maj-ver-number), with some magic so that clients/imports still work.

Thanks,
Rob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 3 Oct 2018 16:55:49 +0200

On Wed, Oct 03, 2018 at 03:44:59PM +0100, Robert Wilton wrote:
> Hi Juergen,
> 
> I think that his comment was that the requirement text was predisposing a
> particular solution.  I.e. I think that he was objecting that the
> module that has been updated in a nbc way.  In particular he was thinking of
> a solution where each major version gets a new module name

I thought the text talks about instance data access, not data model
imports. Anyway, if the concern is that this text rules out a solution
where a version number is attached to the module namespace, then your
rewrite does not help either I think. And should an nbc updated node
really be accessible on the same path and in the same module
namespace?

I though the requirement is more that nodes that have not changed or
have changed in a backwards compatible way should keep their name and
namespace. Going beyond that likely gets us into solution space.

Or is the requirement indeed that we want the same name to resolve to
different incompatible things? I am not sure this is desirable (but
others may see that as desirable).

/js

---

From: Robert Wilton <[email-masked]>
Date: Wed, 3 Oct 2018 16:21:53 +0100

> really be accessible on the same path and in the same module
So I was trying to say: If a given datanode hasn't been updated, or has 
only been updated in a bc way, then the client should not be impacted.

With Chris's scheme, consider a "foo" module has an nbc update to one 
datanode, so the module name and namespace becomes "foo-2". When my old 
client tries to access the unchanged leaf 
"foo:this-leaf-has-not-changed" it is automatically converted to 
accessing "foo-2:this-leaf-has-not-changed" instead.  I.e. the 
path/namespace has changed (at least according to the server), but the 
old client still continues to work, accessing on the same path as before.

> namespace. Going beyond that likely gets us into solution space
Agreed, that was how the requirement was originally expressed.

> others may see that as desirable).
I think that this depends on whether the unique identifier is <module, 
path> or <module, version, path>.

In general, I think that if the name <module, path> is resolving to the 
same underlying configurable "thing" then I think that it is desirable 
that it is on the same path, even if the definition of that thing 
changes over time (e.g. perhaps it changes types, or supports a 
different value space).  Version numbers are used to help manage the 
changes.

Further, for a given YANG schema (i.e. set of YANG modules@particular 
versions + features + deviations), then I would like a solution where 
each configurable "thing" defined in the schema is only accessible on 
one path.

But I think that this is probably in the solution realm rather than 
requirements realm.  Or otherwise I am completely misunderstanding your 
question/comment.

Thanks,
Rob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 3 Oct 2018 17:28:20 +0200

On Wed, Oct 03, 2018 at 04:21:53PM +0100, Robert Wilton wrote:
> 
> So I was trying to say: If a given datanode hasn't been updated, or has only
> been updated in a bc way, then the client should not be impacted.

OK, this is fine. Now we have to find wording that says this. ;-)
 
> client tries to access the unchanged leaf "foo:this-leaf-has-not-changed" it
> is automatically converted to accessing "foo-2:this-leaf-has-not-changed"
> instead.  I.e. the path/namespace has changed (at least according to the
> server), but the old client still continues to work, accessing on the same
> path as before.

I assume the node would also be accessible as foo-2:this-leaf-has-not-changed,
so we have the same as a hard link in file systems (an alias in the old
namespace).
 
> versions + features + deviations), then I would like a solution where each
> configurable "thing" defined in the schema is only accessible on one path.
>

Yes, I think this goes into solution space. I think we are in agreement
on the requirement.

/js

---

From: Joe Clarke <[email-masked]>
Date: Wed, 3 Oct 2018 11:51:09 -0400

> What do we need to resolve/clarify before we do that?  My list:

Thank you for this.  I wanted to ask on prior calls, but I didn't want
to derail the conversation.

> on this on the alias.  Proposing no change.

He wanted to make sure we weren't going to "pollute" each and every node
with its own semver.  That makes a ton of sense.

In our subsequent conversations, we did discuss adding some indicator
(version or otherwise) to a node that did have its semantics changed in
an NBC way.

>             MUST be allowed in any non latest release.

We had discussed client vs. server backward compatibility.  Said another
way, 7950 deals with server compatibility such that an older client can
interact with a newer server (e.g., <edit-config>).  However, we have
discussed what would happen with telemetry and <get-data> operations.

For example, if a CPU range increases from 1-100 to 0-100 and now the
server returns 0.  We have said that clients should just accept it, but
do we want to clarify anything within the requirements?

Joe

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

---

From: Robert Wilton <[email-masked]>
Date: Wed, 3 Oct 2018 16:57:27 +0100

> OK, this is fine. Now we have to find wording that says this. ;-)
OK.

What about if I reverse the sense of my original first sentence, and 
perhaps delete the second sentence all together, which is just a "may be 
desirable" and hence isn't really a requirement, so I don't think that 
we lose anything by removing it.

-00 text:

Proposed text:

        1.2  A mechanism is REQUIRED to update a module in a non-backward
             compatible way without impacting clients that only access
             module data nodes that have either not been updated or have
             been updated in a backwards compatible way.

> so we have the same as a hard link in file systems (an alias in the old
Yes, I would also assume so.

> Yes, I think this goes into solution space. I think we are in agreement
OK.

Thanks,
Rob

---

From: Robert Wilton <[email-masked]>
Date: Wed, 3 Oct 2018 17:03:20 +0100

> (version or otherwise) to a node that did have its semantics changed in
OK.  I've raised this with Vladimir on the alias, and he is OK with the 
existing text because it is a SHOULD rather than a MUST.  So, I think 
that this one is closed.

> do we want to clarify anything within the requirements?
Ah, yes.  I agree that we should add this, perhaps under a new 
subsection to chapter 5, "6. Requirements on clients".  Would you like 
to propose text for this? Or I can have a go ...

Thanks,
Rob

> .

---

From: Joe Clarke <[email-masked]>
Date: Wed, 3 Oct 2018 12:04:45 -0400

> to propose text for this? Or I can have a go ...

I can, but I am in a workshop this week, and it will take me some time
to focus on this.  I could likely have some by the end of the week.

Oh, I'll be traveling tomorrow, so I will not be on the call.

Joe

---

From: Robert Wilton <[email-masked]>
Date: Wed, 3 Oct 2018 17:40:49 +0100

> to focus on this.  I could likely have some by the end of the week.
I'll have a first stab.  I would like to try and get an updated draft 
(that we think would be ready for an adoption call by the chairs) to the 
WG by the end of the week, if possible.  Ideally so there is time for an 
adoption call before IETF 103.

   6.  Requirements on clients:

        5.1  A client capable of supporting backwards compatible updates to
             a module can be expected to handle, or ignore, unexpected instance data
             received from a server.  This includes instance data on paths the
             client is not expecting, or values outside the range that the client
             is expecting.

Thanks,
Rob

---

From: Joe Clarke <[email-masked]>
Date: Wed, 3 Oct 2018 15:00:28 -0400

>             client is not expecting, or values outside the range that the client

This is good, Rob.  Should we add normative language to this to say,
"MUST be expected to handle"?

Joe

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 3 Oct 2018 21:20:19 +0200

>             been updated in a backwards compatible way.

Some of my tweaking produced this:

  Non-backward compatible updates of a module MUST not impact
  clients that only access data nodes of the module that have
  either not been updated or have been updated in a backwards
  compatible way.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 3 Oct 2018 21:36:42 +0200

>             client is not expecting, or values outside the range that the client

Frankly, I am not sure what this is really saying. It sounds a bit
like "clients capable of supporting backwards compatible updates must
be capable to support backwards compatible updates".

I am not sure to what extend this is a versioning requirement.

Yes, RFC 7950 rules of what is backwards compatible are primarily for
config data and configuration clients. But even for config true data,
ranges can be extended and a new server may then return config data
that an old client will find potentially surprising. But yes, I
believe the general assumption is that clients must be able to handle
changes that are allowed by RFC 7950 section 11.

I am not convinced yet we need another requirement here. Or the
requirement needs to be stricter (not conditional):

    Clients MUST be able to handle backwards compatible changes.

I think we should not say how they handle things. We should not talk
about unexpected instance data; given YANG augmentations, there is
lots of unexpected instance data clients have handle (and we should
not write ignore - some might think ignore means "drop" but when it
comes to config data, ignore means "do not touch".

/js

---

From: Joe Clarke <[email-masked]>
Date: Wed, 3 Oct 2018 15:44:20 -0400

> be capable to support backwards compatible updates".

The backwards compatible change according to 7950 may not be backwards
compatible to the client if the client expects, for example, a
<get-data> to return an integer between 1 and 100, but the server
returns a 0.  Expanding a range from 1..100 to 0..100 would be backward
compatible according to 7950.

> I am not sure to what extend this is a versioning requirement.

It's not per se.  However, the clacla draft has tried to inform some
changes to 7950.

> changes that are allowed by RFC 7950 section 11.

And my question was do we need text to make this explicit?

> comes to config data, ignore means "do not touch".

So how do we make it clear what these clients should do?  In lieu of
anything formal, they may choose to drop.

Joe

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 3 Oct 2018 22:32:58 +0200

> anything formal, they may choose to drop.

I think we can't give a clear guideline. What should be done may
depend on the purpose and goals of the client.

A client that deals with a specific service and which removes
everything it does not understand is likely fundamentally flawed (and
I assume people will likely figure this out quickly), perhaps after
trying to mess around with NACM to hide anything such a client would
remove because of a somewhat narrow world view.

That said, there may be a need for a 'config cop' client that is in
charge to remove unwanted complexity but such a config cop should act
based on specific policies but you do not want arbitrary clients to
become 'config cops' because of their limited world view.

For monitoring applications, it likely depends on the details of the
system design; for some changes, the monitoring applications might
just tolerate the changes, for other changes the monitoring
applications may drop some data. There has also been historically an
assumption that clients are easier to adapt than servers.

/js

---

From: Joe Clarke <[email-masked]>
Date: Thu, 4 Oct 2018 00:12:48 -0400

> assumption that clients are easier to adapt than servers.

The impression I get from conversations at 102 is that some text may be
required to at least specify the scope of our work and that clients may
encounter data that is -- to them -- NBC.  I got the impression we
should provide some guidance as to what could be done (maybe in less of
a strict sense).

Joe

---

From: Robert Wilton <[email-masked]>
Date: Thu, 4 Oct 2018 10:35:41 +0100

Juergen, your text is fine with me.

I'll post this to Chris and Netmod to see if they are happy with this 
change.

Thanks,
Rob

---

From: Robert Wilton <[email-masked]>
Date: Thu, 4 Oct 2018 13:02:00 +0100

> I am not sure to what extend this is a versioning requirement.
OK, it doesn't have to be listed as a requirement, but I do think that 
this (or something similar) should be stated in the requirements 
document.  I.e. the basic premise is that YANG clients will be somewhat 
flexible with what they receive (NMDA makes and states this assumption too).

If solutions are allowed to make assumptions on how a client will behave 
then it is reasonable for those assumptions to be stated, even if some 
experts regard them to be obvious :-)

> changes that are allowed by RFC 7950 section 11.
I think that we should state this.  I don't think that it causes any harm.

Thanks,
Rob

---

From: Balázs Lengyel <[email-masked]>
Date: Thu, 4 Oct 2018 12:20:05 +0000

Hello,

That a given data node must have one single path (instance-identifier 
value) identifying it is a strong requirement: If a data node would have 
two instance-identifier values referring to it, comparing them would 
really be a problem. Remember comparison might take place in the (old) 
client. E.g. If you get the alarms from 
/al:alarms/al:alarm-list/al:alarm/al:resource (draft in CCAMP) then 
which instance-identifier will you get? Try compiling a list of alarms 
for a specific object.  IMHO this is unacceptable.

regards Balazs

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

---

From: Balázs Lengyel <[email-masked]>
Date: Thu, 4 Oct 2018 16:05:49 +0000

Hello Rob,

After reading  all the emails in the thread, I agree with Jurgens
statement:

While we could specifically mention some specific changes like
value ranges,  extra elements, why should we leave out other like
changes to min-element, max-element, structural-changes, prefix
changes etc.

So I would propose a short text:

"Clients are
expected to be able to handle unexpected instance data
resulting from changes described in RFC 7950 section 11. "

Or if you want a more detailed description (IMHO not needed) you
could add a second part"

"When handling
instance data the most common changes to be prepared for
include:

instance data on
paths the client is not expecting,

values outside
the range that the client is expecting,

fewer or more
elements then what min-elements and/or max-elements would
allow."

regards Balazs

On 10/4/2018 2:02 PM, Robert Wilton
wrote:

On Wed, Oct 03, 2018 at 05:40:49PM +0100,
Robert Wilton wrote:

5.1  A client capable of supporting backwards
compatible updates to

a module can be expected to handle, or ignore,
unexpected instance data

received from a server.  This includes instance
data on paths the

client is not expecting, or values outside the
range that the client

is expecting.

Frankly, I am not sure what this is really saying. It sounds a
bit

like "clients capable of supporting backwards compatible updates
must

OK, it doesn't have to be listed as a requirement, but I do think
that this (or something similar) should be stated in the
requirements document.  I.e. the basic premise is that YANG
clients will be somewhat flexible with what they receive (NMDA
makes and states this assumption too).

If solutions are allowed to make assumptions on how a client will
behave then it is reasonable for those assumptions to be stated,
even if some experts regard them to be obvious :-)

Yes, RFC 7950 rules of what is backwards compatible are
primarily for

config data and configuration clients. But even for config true
data,

ranges can be extended and a new server may then return config
data

believe the general assumption is that clients must be able to
handle

I think that we should state this.  I don't think that it causes
any harm.

Thanks,

Rob

Clients MUST be able to handle backwards compatible
changes.

I think we should not say how they handle things. We should not
talk

about unexpected instance data; given YANG augmentations, there
is

lots of unexpected instance data clients have handle (and we
should

not write ignore - some might think ignore means "drop" but when
it

/js

[email-masked]

---

From: Balazs Lengyel <[email-masked]>
Date: Thu, 11 Oct 2018 16:30:10 +0200

On 2018. 10. 04. 18:05, Balazs Lengyel
wrote:

Hello Rob,

After reading  all the emails in the thread, I agree with
Jurgens statement:

"Clients are

Or if you want a more detailed description (IMHO not needed)
you could add a second part"

"When handling

instance data
on paths the client is not expecting,

values outside

fewer or more

regards Balazs

On Wed, Oct 03, 2018 at 05:40:49PM
+0100, Robert Wilton wrote:

is expecting.

like "clients capable of supporting backwards compatible
updates must

OK, it doesn't have to be listed as a requirement, but I do
think that this (or something similar) should be stated in the
requirements document.  I.e. the basic premise is that YANG
clients will be somewhat flexible with what they receive (NMDA
makes and states this assumption too).

If solutions are allowed to make assumptions on how a client
will behave then it is reasonable for those assumptions to be
stated, even if some experts regard them to be obvious :-)

config data and configuration clients. But even for config
true data,

that an old client will find potentially surprising. But yes,
I

Thanks,

Rob

I am not convinced yet we need another requirement here. Or
the

I think we should not say how they handle things. We should
not talk

about unexpected instance data; given YANG augmentations,
there is

not write ignore - some might think ignore means "drop" but
when it

/js

[email-masked]