Subject: [Netmod-ver-dt] Netmod Ver DT - Meeting Agenda 24th May

From: Robert Wilton <[email-masked]>
Date: Thu, 24 May 2018 14:06:57 +0100

Hi,

The proposed agenda for today's meeting is as follows:

1) Agenda bashing (if required) (5 mins)
- I will take minutes.  Should we also record meetings?

2) Cover initial scope and timelines for the DT (5 mins):
- I would like to focus just on the Problem Statement and Solution 
Requirements, deferring discussion on the actual solution until we have 
got these broadly agreed.
- It would be nice to aim for an initial draft covering problem 
statement and requirements before IETF 102.  Is this feasible?

3) Discussion on Problem Statement and Solution Requirements (45 mins)
- Benoit has proposed using the problem statement from the clacla draft 
as a starting point.  Does anyone disagree, or propose a different 
starting point for the problem statement?
  - Discussion/refinement on the problem statement and requirements.

5) Wrap up, next steps. (5 mins)
- What frequency of meetings?  Weekly running up to IETF?

Thanks,
Rob

---

From: Qin Wu <[email-masked]>
Date: Thu, 24 May 2018 13:53:00 +0000

I have two questions on the scope of the problem:
1.Do we need to keep YANG module update rule in RFC7950 or relax YANG module update rule in RFC7950?
2.How do we deal with non compatible change, Do we need to force module name change when any non compatible change happens or keep the same module name?
In case of Keeping the module name:
Pro: better traceability of the same functionality or building block on different versions of the module
Con: Keep the same module name when non back compatible change happens seems to violate rule in RFC7950

I think we need to clearly define when to keep the same module name. This is also, I believe, related to requirements we want to set for YANG model versioning
Regarding the requirements, here is my thought:
1.Allow keep module name when the module is revised and re-published
a. When this module is intended as a basis for future data model development or many other modules have dependency on this module, or when this module is referred by non-IETF module or throughout the industry, whether the revision of this module is  back-compatible or not, it is recommended not to change the module name.
b. When this module is standalone module or no other modules have dependency on this module, if the status of module is obsoleted, it is recommended not to change the module name.
c. When one module is revised from non-NMDA compliant module to NMDA compliant module, it is recommended not to change the module name.
2.Using YANG model versioning to Distinguish NMDA compliant Model from NMDA non compliant  model
3.Using YANG model versioning to Distinguish Back-compatible model from non Back-compatible model
4.Using YANG model versioning to identify any content changes between any two version of the same YANG data model
5. Allow indication of inconsistent data or non back-compatible data using module version
6. Allow YANG model versioning work together with YANG status statement
7. Allow automatic discover Obsolete Relationship between versions of the same module

-Qin
-----邮件原件-----
发件人: Netmod-ver-dt [mailto:[email-masked]] 代表 Robert Wilton
发送时间: 2018年5月24日 21:07
收件人: [email-masked]
主题: [Netmod-ver-dt] Netmod Ver DT - Meeting Agenda 24th May

Hi,

2) Cover initial scope and timelines for the DT (5 mins):
- I would like to focus just on the Problem Statement and Solution Requirements, deferring discussion on the actual solution until we have got these broadly agreed.
- It would be nice to aim for an initial draft covering problem statement and requirements before IETF 102.  Is this feasible?

3) Discussion on Problem Statement and Solution Requirements (45 mins)
- Benoit has proposed using the problem statement from the clacla draft as a starting point.  Does anyone disagree, or propose a different starting point for the problem statement?
  - Discussion/refinement on the problem statement and requirements.

Thanks,
Rob

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

---

From: Robert Wilton <[email-masked]>
Date: Thu, 24 May 2018 14:55:52 +0100

I've also created an EtherPad for collaborate meeting notes/minutes.

http://etherpad.tools.ietf.org:9000/p/netmod-ver-dt

Thanks,
Rob

On 24/05/2018 14:06, Robert Wilton wrote:
> Requirements, deferring discussion on the actual solution until we 
> have got these broadly agreed.
> - Benoit has proposed using the problem statement from the clacla 
> draft as a starting point.  Does anyone disagree, or propose a 
> different starting point for the problem statement?

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Thu, 24 May 2018 15:19:18 +0000

Hi,

I joined the meeting 35+ mins late,  so I didn't hear all the discussions. 

Regarding the semver solution in draft-clacla, the version will have to be included in the requests? That's a pretty big change as Juergen mentioned. Also I assume is the expectation is that devices will support multiple versions, otherwise the exercise is futile?

Regards,
Reshad.

On 2018-05-24, 9:56 AM, "Netmod-ver-dt on behalf of Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" <[email-masked] on behalf of [email-masked]> wrote:

    
    Thanks,
    Rob

---

From: Qin Wu <[email-masked]>
Date: Thu, 24 May 2018 15:34:18 +0000

Yes, that's also my understanding, we see many YANG model RFCs have been republished, e.g. Interface model RFC8343, it means the client needs to support two version of the same module during transition stage,
i.e., using old version interface model to talk with legacy device, using new version interface model to talk with advanced device.
Retiring old interface model may take time for some devices.

-Qin
-----邮件原件-----
发件人: Netmod-ver-dt [mailto:[email-masked]] 代表 Reshad Rahman (rrahman)
发送时间: 2018年5月24日 23:19
收件人: Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco); [email-masked]
主题: Re: [Netmod-ver-dt] Netmod Ver DT - Meeting Agenda 24th May

Hi,

Regards,
Reshad.

    
    
    Thanks,
    Rob

---

From: Robert Wilton <[email-masked]>
Date: Thu, 24 May 2018 16:51:08 +0100

These are just my notes/recollections.  Please send any comments or 
corrections if you have any.

Meeting minutes:

Present: Balazs, Benoit, Jergen, Qin, Rob, Michael (only towards the 
end), Reshad (latter half the meeting), Lou (only briefly at the beginning).

Etherpad notes are here: http://etherpad.tools.ietf.org:9000/p/netmod-ver-dt

1) Agenda bashing:
- There were no changes to agenda.  Agreement was to minute meetings 
only, but not record.

2) Scope and timelines:
- There was tacit agreement to keep the initial scope to defining the 
problem and requirements for a solution.
- No discussion/agreement on whether it is feasible to produce a draft 
for IETF 102.  [I think that this will depend on what solution we come 
up with]

3) Discussion on Problem Statement and Requirements:
Most of the meeting was spent on this.
- There was agreement to use section 2 of the clacla draft as a starting 
point, subject to further refinement.
- There seemed to be reasonable (but not unanimous) agreement with the 
problems being stated in section 2 or the clacla draft.
- Concern from Juergen is that we are moving from a tight well defined 
versioning/backwards compatibility definition to a much more vague 
definition.
- Benoit proposed reorganizing section 2 more clearly into a problem 
definition and requirements section (that there was agreement to).
- Balazs to provide some problem statement text describing the issue 
with import-by-revision.
- Qin mentioned that Michael may have other comments on the problem 
definition.  Michael not on the call (at least not initially) so 
recommendation is send these to the DT alias.

4) Wrap up, next steps:
  - There was general agreement that there is a valid problem to be 
solved here.
  - Agreed to meet next week (but Juergen might not be able to make it).
  - Agreed to work on the problem statement over email to make progress.
- Benoit/Joe/Balazs, once you have split between Requirements/Problem 
Statement then please can you email the text to the DT alias, so 
everyone can review and provide comments.

Thanks,
Rob

---

From: Benoit Claise <[email-masked]>
Date: Thu, 31 May 2018 15:08:34 +0200

On 5/24/2018 5:19 PM, Reshad Rahman (rrahman) wrote:
> Regarding the semver solution in draft-clacla, the version will have to be included in the requests?
Not sure I understand the reason why the semver should be part of every 
request? Or maybe I misunderstand the point.
The IETF-YANG-LIBRARY provides the YANG modules, including the revisions.
Within a YANG module specific revision, there is one semver (set of) values.
If we want to make it clean, we could include the semver directly in the 
IETF-YANG-LIBRARY.
See 
https://tools.ietf.org/html/draft-clacla-netmod-yang-model-update-05#section-3.4

Regards, Benoit

> That's a pretty big change as Juergen mentioned. Also I assume is the expectation is that devices will support multiple versions, otherwise the exercise is futile?
>
> Regards,
> Reshad.
>

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Thu, 31 May 2018 14:15:40 +0000

Hi,

My question was when a client sends a request, is the version included in the request? My understanding is yes since the server may support multiple versions for the module, path combo.

Regards,
Reshad.

On 2018-05-31, 9:08 AM, "Benoit Claise (bclaise)" <[email-masked]> wrote:

    Regards, Benoit

---

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

Hi Reshad,

I don't think that there is any proposal or need to include the version 
in the request.

YANG library publishes the set of modules implemented by the server, and 
today it can only implement a single revision of module.  At the moment 
this constraint would also apply to semantic versions in the clacla draft.

I think that it should always be the case, that for a particular 
session, the version of a path is well known and hence doesn't need to 
be included in the request.

My interpretation of Juergen's comment is more about data node 
uniqueness.  He is saying that with the existing YANG rules, uniqueness 
if guaranteed by (module, path), whereas if non backwards compatible 
updates are allowed then to achieve uniqueness it would be necessary to 
track the triple (module, path, version).

However, I don't currently agree with Juergen on this, since a data node 
may get created in a new module revision, or be obsoleted, or be 
deviated by one or more different servers.  So, I actually think that 
uniqueness is really bound to a particular device-schema, so it is 
already the triple (device-schema, module, path), and sem-ver wouldn't 
change this.

I would then define that a schema node in two schemas are equivalent if:
(i) they are defined in the same module (with same namespace)
(ii) they exist on the same path (including keys)
(iii) they have the same type (to ensure encoding is the same)
(iv) they support exactly the same set of values
(v) they have the same must/when/choice constraints.

Thanks,
Rob

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Thu, 31 May 2018 18:06:10 +0000

Hi Rob,

I incorrectly thought there was a need to have devices support multiple versions. As Benoit explained to me via jabber, this is not needed (and contravenes 7950 as someone on the call mentioned). So yes I agree that there is no need to include the version in the request, the client/controller will know via YANG lib which version to use for a device.

Regards,
Reshad.

On 2018-05-31, 1:03 PM, "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" <[email-masked]> wrote:

    Hi Reshad,

    

    
    
    Thanks,
    Rob