Subject: [Netmod-ver-dt] Netmod Ver DT - Meeting Agenda 31st May

From: Robert Wilton <[email-masked]>
Date: Thu, 31 May 2018 12:18:25 +0100

Hi,

My proposed agenda for today's meeting is below, please reply with any 
proposed changes/additions.

1) Agenda bashing (if required) (5 mins)

2) Open questions relating to the problem statement/requirements:

(i) What are the implications of allowing backwards compatible changes 
to a module (without changing the name)?  E.g. considering stability, 
augmentations, references.

a) Does this mean that clients need to track (module, path, [major] 
revision)?

b) Do clients already have to do that today anyway (e.g. new 
definitions, deprecated/obsolete nodes, deviations)?

ii) What the problems with only making backwards compatible changes 
(i.e. only add new nodes, deprecate existing ones)?

iii) Do we need to identify changes between two module revisions beyond 
tooling + revision statement?

v) Does RFC 7950 allow bug fixes?  What is the scope/definition of a bug 
fix anyway?

vi) Do we need to support bug fixes (or even enhancements) to an older 
revision without pulling in all changes from a newer revision?  E.g. 
revision dates are linear, but semantic versioning is allows for tree 
like dependencies.

3) Structure of the problem statement
We could also discuss what the right structure should be (e.g. my mail 
form yesterday).

4) Wrap up, actions before next meeting (5 mins)

------------

Webex details:

https://cisco.webex.com/ciscosales/j.php?MTID=m196086ddc16716f4da6338e481c01246 

Meeting number (access code): 200 574 017
Meeting password: UdTbwvpT (83829878 from phones)

JOIN BY PHONE
+1-866-432-9903 Call-in toll-free number (US/Canada)
+1-408-525-6800 Call-in toll number (US/Canada)

Global call-in numbers: 
https://cisco.webex.com/ciscosales/globalcallin.php?serviceType=MC&ED=435913767&tollFree=1 

Toll-free dialing restrictions: 
https://www.webex.com/pdf/tollfree_restrictions.pdf

Thanks,
Rob

---

From: Lou Berger <[email-masked]>
Date: Thu, 31 May 2018 09:17:59 -0400

Rob,

     A couple of questions below.

> tooling + revision statement?
At some point I'd like to hear how a server supports client backward 
compatibility (e.g., different clients asking for / using different 
versions of a model.)  From my perspective, avoiding the issues with CLI 
changes on every s/w version updates is a key driver for the use of YANG...

Lou

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

---

From: Robert Wilton <[email-masked]>
Date: Thu, 31 May 2018 14:28:41 +0100

Hi Lou,

OK, I 'll add your question to the list to discuss today.

Are you specifically asking:

  - Can I configure a server to support a particular version of 
model(s), and all clients would interact with that version?

- Or, can I have multiple concurrent clients interacting to a server 
each using different versions of model(s)?

Note, that this also opens a can of worms regarding the 
inter-relatedness of module versions.

Thanks,
Rob

On 31/05/2018 14:17, Lou Berger wrote:
> versions of a model.)  From my perspective, avoiding the issues with 
> CLI changes on every s/w version updates is a key driver for the use 
> of YANG...

---

From: Lou Berger <[email-masked]>
Date: Thu, 31 May 2018 10:00:57 -0400

> model(s), and all clients would interact with that version?
not this one

> each using different versions of model(s)?
yes, and the supported versions would be reported via the normal means, 
e.g., library.

> inter-relatedness of module versions.
Understood - but I think anything short leads us to repeat the CLI pitfalls.

Lou