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

From: wangzitao <[email-masked]>
Date: Thu, 31 May 2018 12:12:56 +0000

Hi Robert,

I prepared some text input, please see following:

Problem: It lacks of some methods or conventions to help the designer to improve update efficiency

Due to the complex interdependence between different modules, if we updated a model it may cause a series of chain reactions - a large number of modules may need to be updated or synchronized accordingly. For example:

If we updated the module A without synchronizing module B and C, it may cause some syntax error.

Typically, to solve this problem, the designers and maintainers of module B and C need to keep track of the status of model A, and to determine whether the changes of module A will affect model B and C.

And the above example just describes a simple case, however, there are some models which import a large number of other modules.  In extreme cases, if all the imported models are updated, it will inevitably bring a lot of works to the designer or maintainer.

How to help the designer to improve efficiency and to quickly complete the update is a key issue. Therefore, it may needs some tools to programmatically compare two module revisions to identify the changes. And it also need some documentation conventions to help reader quickly retrieve the changes.

-----邮件原件-----
发件人: Netmod-ver-dt [mailto:[email-masked]] 代表 Robert Wilton
发送时间: 2018年5月30日 18:15
收件人: wangzitao <[email-masked]>; [email-masked]
主题: Re: [Netmod-ver-dt] Netmod Ver DT - Meeting Agenda 24th May

Hi Michael,

On 25/05/2018 07:47, wangzitao wrote:

> Hi Robert,

> Please find my feedback inline.

> Best Regards!

> -Michael

> -----邮件原件-----

> 发件人: Netmod-ver-dt [mailto:[email-masked]] 代表 Robert

> Wilton

> 发送时间: 2018年5月25日 0:13

> 收件人: wangzitao <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>

> 主题: Re: [Netmod-ver-dt] Netmod Ver DT - Meeting Agenda 24th May

> Hi Michael,

> Some comments inline ...

> On 24/05/2018 16:26, wangzitao wrote:

>> Dear All,

>> Sorry for late joining in and missing a lot of interesting discussions.

>> I had a quick review of Benoit’s problem statements, it seems well and is a good start.

>> And I also proposed some inputs of problem statements/requirements which come from some model designers and customers’ feedbacks. Please see following:

>> #1 Updating a model may cause a chain reaction, a lot of modules which dependent on it need to update.

>>   - How to quickly complete the update, close the issue?

> Yes, this one came up in discussions, and I agree that it is an issue to be solved.  I think that this is similar to the problem described in 2.4 YANG Module Transition Strategy of the clacla draft.

> [Michael] : I think that they are same causes, but with different emphasis.

> 'Module Transition Strategy' pointed that change the model's name will impact a lot of modules which depended on it.

> And I want to emphasis that even if you don't change the model's name, any changes may cause a lot of related module's update works.

>   Do you think that changing the text would make this clearer and if so please can you send some proposed text.

> [Michael]: Yes, I think so, and I'd like to contribute some text.

Would you be able to send proposed text to this alias and then it can be discussed.

>> #2 It need some method to reflect the changes to help to improve the module designer’s efficiency.

> I agree that module designers/users need to be able to understand the change history between different versions/revisions of a YANG module. Tooling can certainly help here, but it can't capture everything.

> [Michael]: I agree. So I think some document writing specifications may also helpful.

> Is this requirement similar to the one captured in section 2.7 of the clacla draft: "No way to easily decide whether a change in Backwards Compatible"?

> [Michael]: I think there are some differences.

> Clacla draft seems to do some works like notified the users that a model had some non-backwards updates;

> And my proposal is that if I received the notification, then I will do some related modules' update, and if I can get the changed model's update details, it can help to quickly close the issues.

> So, it seems like two steps: 1) notifies the user that there are some non-backwards updates, 2) helps user to complete the update works.

At the moment, I'm trying to focus on the problem statement and

requirements rather than the solution.

I think that the problem that you are describing is: "It is difficult to

determine the actual differences between two module revisions."

Is that correct?

>>   - May need some tools to present the change log.

>>   - May need some guidance for user onboarding, teaching them how to use these tools.

>> #3 It also may need some document writing specifications / YANG coding conventions to help reader quickly retrieve the change log. E.g.

>>   - In document’s some section to present the update details;

> I would expect to see a summary of the changes in the revision history. Are you thinking of something more detailed?

> [Michael]: There are some documents have that section, but a lot of drafts do not provide this.

> So can we define some documentation conventions, like: if model changed, the changes summary should be wrote in appendix.

Can we phrase these as part of a problem definition, and/or a list of

requirements first.

Thanks,

Rob

>>   - Or in model’s description statement to embed external links, like https://www.yangcatalog.org, to retrieve the change log.

> Not sure on this one.

> Thanks,

> Rob

>> Any comments?

>> Best Regards!

>> -Michael

>> -----邮件原件-----

>> 发件人: Netmod-ver-dt [mailto:[email-masked]] 代表 Robert

>> Wilton

>> 发送时间: 2018年5月24日 21:56

>> 收件人: [email-masked]<mailto:[email-masked]>

>> 主题: Re: [Netmod-ver-dt] Netmod Ver DT - Meeting Agenda 24th May

>> 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:

>>> 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

>> _______________________________________________

>> Netmod-ver-dt mailing list

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

>> https://www.ietf.org/mailman/listinfo/netmod-ver-dt

> _______________________________________________

> Netmod-ver-dt mailing list

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

> https://www.ietf.org/mailman/listinfo/netmod-ver-dt

> _______________________________________________

> Netmod-ver-dt mailing list

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

> https://www.ietf.org/mailman/listinfo/netmod-ver-dt

_______________________________________________

Netmod-ver-dt mailing list

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

https://www.ietf.org/mailman/listinfo/netmod-ver-dt

---

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

Hi Michael,

Thanks for providing this.  Let's also discuss this in the meeting today.

Thanks,
Rob

On 31/05/2018 13:12, wangzitao wrote:
> Due to the complex interdependence between different modules, if we 
> updated a model it may cause a series of chain reactions - a large 
> number of modules may need to be updated or synchronized accordingly. 
> For example:
>
> Typically, to solve this problem, the designers and maintainers of 
> module B and C need to keep track of the status of model A, and to 
> determine whether the changes of module A will affect model B and C.
>
> And the above example just describes a simple case, however, there are 
> some models which import a large number of other modules.  In extreme 
> cases, if all the imported models are updated, it will inevitably 
> bring a lot of works to the designer or maintainer.
>
> How to help the designer to improve efficiency and to quickly complete 
> the update is a key issue. Therefore, it may needs some tools to 
> programmatically compare two module revisions to identify the changes. 
> And it also need some documentation conventions to help reader quickly 
> retrieve the changes.
>
> -----邮件原件-----
> 发送时间: 2018年5月30日18:15
> > 发件人: Netmod-ver-dt [mailto:[email-masked]] 代表Robert
>
> > Wilton
>
> > 发送时间: 2018年5月25日0:13
>
> > 收件人: wangzitao <[email-masked] <mailto:[email-masked]>>; 
> [email-masked] <mailto:[email-masked]>
>
> >> And I also proposed some inputs of problem statements/requirements which come 
> from some model designers and customers’feedbacks. Please see following:
>
> >>
>
> > Yes, this one came up in discussions, and I agree that it is an issue to be 
> solved.I think that this is similar to the problem described in 2.4 
> YANG Module Transition Strategy of the clacla draft.
>
> >
>
> > And I want to emphasis that even if you don't change the model's name, any changes 
> may cause a lot of related module's update works.
>
> >
>
> > I agree that module designers/users need to be able to understand the change 
> history between different versions/revisions of a YANG module. Tooling 
> can certainly help here, but it can't capture everything.
>
> > Is this requirement similar to the one captured in section 2.7 of the clacla 
> draft: "No way to easily decide whether a change in Backwards Compatible"?
>
> > And my proposal is that if I received the notification, then I will do some related 
> modules' update, and if I can get the changed model's update details, 
> it can help to quickly close the issues.
>
> > So, it seems like two steps: 1) notifies the user that there are some 
> non-backwards updates, 2) helps user to complete the update works.
>
> >> #3 It also may need some document writing specifications / YANG coding 
> conventions to help reader quickly retrieve the change log. E.g.
>
> >>   - Or in model’s description statement to embed external links, like 
> https://www.yangcatalog.org, to retrieve the change log.
>
> > Not sure on this one.
>
> >
>
> > Thanks,
>
> > Rob
>
> >
>
> >
>
> >> Any comments?
>
> >>
>
> >> Best Regards!
>
> >> -Michael
>
> >>
>
> >> -----邮件原件-----
>
> >> 发件人: Netmod-ver-dt [mailto:[email-masked]] 代表Robert
>
> >> Wilton
>
> >> 发送时间: 2018年5月24日21:56
>
> >> 收件人: [email-masked] <mailto:[email-masked]>
>
> >>> - I will take minutes.Should we also record meetings?
>
> >>>
>
> >>> statement and requirements before IETF 102.Is this feasible?
>
> >>>
>
> >>> draft as a starting point.Does anyone disagree, or propose a
>
> >>> - What frequency of meetings?Weekly running up to IETF?
>
> >>>
>
> >>> Thanks,
>
> >>> Rob
>
> >>>
>
> >> [email-masked] <mailto:[email-masked]>
>
> > [email-masked] <mailto:[email-masked]>
>
> > [email-masked] <mailto:[email-masked]>
>
> [email-masked] <mailto:[email-masked]>
>