Subject: Re: [Netmod-ver-dt] YANG versioning - Design team meetings

From: wangzitao <[email-masked]>
Date: Fri, 27 Jul 2018 00:56:08 +0000

August 2nd and 23rd seems good to me. 

B.R.
Michael 

-----邮件原件-----
发件人: Netmod-ver-dt [mailto:[email-masked]] 代表 Robert Wilton
发送时间: 2018年7月26日 22:12
收件人: Joe Clarke (jclarke) <jclarke=[email-masked]>; [email-masked]
主题: Re: [Netmod-ver-dt] YANG versioning - Design team meetings

Well, it looks like nobody was expecting a meeting today. :-)

So, I will cancel now, but we should meet next Thursday.

Please can everyone state a preference as to whether they would like the meetings to continue through the remainder of August, or should we just wait until September.  The only two dates that I can make in August are next week (2nd) and the 23rd.

Thanks,
Rob

On 26/07/2018 14:58, Joe Clarke (jclarke) wrote:
> I am good with this plan.  However, I will not make today’s meeting.  I’ll be back next week.
>
> Joe
>
> PGP Key : http://www.marcuscom.com/pgp.asc
>
>> On Jul 26, 2018, at 05:37, Robert Wilton <rwilton=[email-masked]> wrote:
>>
>> Hi,
>>
>> Sorry, I should have emailed earlier, but I suggest that we continue the design team meetings at the same time slot.  I.e. Thursday, 3 pm BST.
>>
>> I am around this week, and next week, but then away for a reasonable amount of August.  I don't know if folks want to continue the meetings over August, or have a break until September?
>>
>> In terms of next steps for the DT, then my proposal is:
>>
>> (1) Finalize the requirements text.  I think that this is relative minor and can be done over email, perhaps best on the NETMOD alias directly.
>> (2) Discuss solutions:
>>
>> Personally, I'm still of the opinion, that the semver draft seems like the most likely path forward, but I think that we need to at least consider the broad pros and cons of alternative solutions. My aim here is try and get buy in from the WG on the direction of the solution now rather than in 4 months time.
>>
>> To this end I would like to suggest that we aim to produce a short ID that lists the main alternative solutions and has bullet point lists of the relative pros and cons.
>>
>> In particular I think that the three solution spaces that are worth comparing are:
>>    (i) The solution that we have today (i.e. RFC 7950 rules).
>>    (ii) The Chris Hopps variant of RFC 7950:
>>        - Change the module name for major version changes, use revision date for minor versions.
>>        - Consider whether tooling, or changes to the protocols, can minimize the impact of changing the module name.
>>   (iii) A semver solution, as described in the clacla draft.
>>
>> Note that I mainly want to evaluate against requirements in section 5.  In particular subsections 1, 2 and 3, and 5.  I think that we can ignore the requirements for subsection 4 related to data node life cycle since I think that it a tangential problem, and the solution space is much simpler.
>>
>> Is everyone happy doing this, and agree that this is a useful step? Or perhaps, better put, is anyone opposed to doing this?
>>
>> 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