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

From: wangzitao <[email-masked]>
Date: Fri, 25 May 2018 06:47:47 +0000

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]>; [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.

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

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

> 	- 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]
> 主题: 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]
> https://www.ietf.org/mailman/listinfo/netmod-ver-dt

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

---

From: Robert Wilton <[email-masked]>
Date: Wed, 30 May 2018 11:15:14 +0100

Hi Michael,

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

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

> 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