Hi Joe,
The extra spaces are due to xml2rfc? Should we bump up the version because of extra white-space 😊 Section 3.3.2, good with me. Last sentence may need a small tweak, e.g s/may cause loss of visibility to when/may cause loss of visibility as to when/? Yang-semver changes also good with me. Regards, Reshad. From: netmod <netmod-boun...@ietf.org> on behalf of "Joe Clarke (jclarke)" <jclarke=40cisco....@dmarc.ietf.org> Date: Wednesday, February 10, 2021 at 4:02 PM To: "Sterne, Jason (Nokia - CA/Ottawa)" <jason.ste...@nokia.com>, "netmod@ietf.org" <netmod@ietf.org> Subject: Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-01-12 On T4 (gaps in revision numbers and revision history), I have some proposed text for both draft-ietf-netmod-yang-module-versioning and draft-ietf-netmod-yang-semver. See these diffs (some changes are due to xml2rfc changes, but you'll note the more substantive text additions). Thoughts: module-versioning : https://tools.ietf.org/rfcdiff?url1=draft-ietf-netmod-yang-module-versioning&url2=https://namale.marcuscom.com/~jclarke/draft-ietf-netmod-yang-module-versioning.txt yang-semver : https://tools.ietf.org/rfcdiff?url1=draft-ietf-netmod-yang-semver&url2=https://namale.marcuscom.com/~jclarke/draft-ietf-netmod-yang-semver.txt Joe On 1/12/21 13:43, Sterne, Jason (Nokia - CA/Ottawa) wrote: YANG Versioning Weekly Call Minutes - 2021-01-12 Topics and owners for Feb virtual interim: Reshad - editor for YANG versioning draft Jason - coordinate virtual interim, agenda. Do introduction at VI. T1) Definition/meaning of BC vs NBC for config false nodes https://github.com/netmod-wg/yang-ver-dt/issues/15 - Balazs T2) IANA considerations: how are final RFC revision labels assigned ? https://github.com/netmod-wg/yang-ver-dt/issues/59 - Rob T3) YANG file naming when revision labels are being used (symbolic links? @<revision-label>) ? - Reshad to prepare material, TBD to present/lead at VI T4) SemVer: gaps in history, removing revision statements https://github.com/netmod-wg/yang-ver-dt/issues/61 - Joe We spent most of the time discussing Balazs' rules for backwards compatibility of config false nodes (T1 above): - clients SHOULD be able to deal with (not crash) unexpected output - some changes to config false nodes should be BC (increasing value space within the same type), some will be NBC (e.g. removing mandatory, changing type) - the YANG author can mark a change that increases value space as NBC if they feel it is significant & breaks compatibility We also talked briefly about Rob's proposal for IANA considerations (T2 above). - we may also want some guidance for RFC editors (coordinate with authors on final SemVer for example) Next week we'll continue focus on the four Virtual Interim topics. Other topics we need to get back to at some point: - whitespace - github issues (left off at #15) Jason _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
