[netmod] YANG Versioning Weekly Call Minutes - 2021-03-02
YANG Versioning Weekly Call Minutes - 2021-03-02 Meeting notes from Tuesday's meeting on YANG versioning. Regarding the NBC changes text (that have been discussed over email) - We are close to agreement that the current text - It was agreed that having a paragraph to reference the pre-release markers would be useful Next step: Joe has the action of: - Merging Rob's pull request - Fixing XML to v3 format (e.g., rerun conversion tool) - Adding a paragraph to reference pre-release markers. There was further discussion as to whether the "rev:nbc-changes" marker MAY be added even when it is known that there are no nbc-changes. The consensus of the folk on the call (but Jason was absent) is that it should only be added when the changes are known to be, or suspected that they may be, non-backwards-compatible. Next step: Still trying to reach consensus We discussed changing "rev:nbc-changes" marker to expand nbc, and avoid potential confusion. There is agreement to expand the tag, but there were two proposed expanded versions, and there didn't seem to be strong consensus for, or against, either of them: The two choices are: rev:non-backwards-compatible; rev:non-backwards-compatible-changes; - Reshad has the action of changing the module versioning doc to one of these. Semver doc will also need to be updated. Rob to send IANA text to WG (now done). We also discussed Reshad's proposed slides for IETF 110. Of particular note was the discussion regarding whitespace: - Tom commented that the build metadata could be used to indicate where another version of a YANG module has been published with whitespace changes. - It was noted that this might help with Semver version numbers, but the impact to revision date also need to be considered. - No conclusion on this, future discussion with the WG on this issue is likely needed. We also discussed a couple of issues that were raised by Joseph (in the context of the Semver 2.0.0 github repository): 1. Is Semver 2.0.0 a stable reference, or is the specification being changed without changing the version number. Joe to check, whether the current Semver 2.0.0 specification seems to be stable. 2. Check whether our usage of pre-release labels is aligned with Semver 2.0.0, or requires tweaking. Action is on Joe to check. Rob ___ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
Re: [netmod] Proposed IANA text for YANG Module Versioning and Semver Drafts
Hi Rob, I don't know whether this has been discussed, but one issue that might need to be addressed is the difference between IANA and YANG in the definitions of "obsolete" and "deprecated" - the details are here (slide 5): https://datatracker.ietf.org/meeting/104/materials/slides-104-dnsop-sessa-yang-types-for-dns-classes-and-resource-record-types-00 The best solution would be to unify the definitions. If this is not possible (in a short term), then it is IMO necessary to mark an entry that is made obsolete or deprecated in an IANA registry as "obsolete" in the YANG module. Lada "Rob Wilton \(rwilton\)" writes: > Hi, > > // As an individual contributor > > We discussed proposed IANA text at the last NETMOD interim on the YANG > versioning work. Tracked by issue > https://github.com/netmod-wg/yang-ver-dt/issues/59 > > I had the action of updating the text based on comments received in the > interim meeting and then sending that text to the list. > > The proposed text is below (that is in the current published versions of both > drafts). If the WG has no objections to this text, then the planned next > step is to ask IANA for an early review of this text. > > > IANA section in draft-ietf-netmod-yang-module-versioning-02: > > 11.2. Guidance for versioning in IANA maintained YANG modules > >Note for IANA (to be removed by the RFC editor): Please check that >the registries and IANA YANG modules are referenced in the >appropriate way. > >IANA is responsible for maintaining and versioning YANG modules that >are derived from other IANA registries. For example, "iana-if- >type.yang" [IfTypeYang] is derived from the "Interface Types (ifType) >IANA registry" [IfTypesReg], and "iana-routing-types.yang" >[RoutingTypesYang] is derived from the "Address Family Numbers" >[AddrFamilyReg] and "Subsequent Address Family Identifiers (SAFI) >Parameters" [SAFIReg] IANA registries. > >Normally, updates to the registries cause any derived YANG modules to >be updated in a backwards-compatible way, but there are some cases >where the registry updates can cause non-backward-compatible updates >to the derived YANG module. An example of such an update is the >2020-12-31 revision of iana-routing-types.yang > >[RoutingTypesDecRevision], where the enum name for two SAFI values >was changed. > >In all cases, IANA MUST follow the versioning guidance specified in >Section 3.1, and MUST include a "rev:nbc-changes" substatement to the >latest revision statement whenever an IANA maintained module is >updated in a non-backwards-compatible way, as described in >Section 3.2. > >Note: For published IANA maintained YANG modules that contain non- >backwards-compatible changes between revisions, a new revision should >be published with the "rev:nbc-changes" substatement retrospectively >added to any revisions containing non-backwards-compatible changes. > >Non normative examples of updates to enumeration types in IANA >maintained modules that would be classified as non-backwards- >compatible changes are: Changing the status of an enumeration typedef >to obsolete, changing the status of an enum entry to obsolete, >removing an enum entry, changing the identifier of an enum entry, or >changing the described meaning of an enum entry. > >Non normative examples of updates to enumeration types in IANA >maintained modules that would be classified as backwards-compatible >changes are: Adding a new enum entry to the end of the enumeration, >changing the status or an enum entry to deprecated, or improving the >description of an enumeration that does not change its defined >meaning. > >Non normative examples of updates to identity types in IANA >maintained modules that would be classified as non-backwards- >compatible changes are: Changing the status of an identity to >obsolete, removing an identity, renaming an identity, or changing the >described meaning of an identity. > >Non normative examples of updates to identity types in IANA >maintained modules that would be classified as backwards-compatible >changes are: Adding a new identity, changing the status or an >identity to deprecated, or improving the description of an identity >that does not change its defined meaning. > > IANA section for draft-ietf-netmod-yang-semver-02 > > 9.2. Guidance for YANG Semver in IANA maintained YANG modules > >Note for IANA (to be removed by the RFC editor): Please check that >the registries and IANA YANG modules are referenced in the >appropriate way. > >IANA is responsible for maintaining and versioning some YANG modules, >e.g., iana-if-types.yang [IfTypeYang] and iana-routing-types.yang >[RoutingTypesYang] . > >In addition to following the rules specified in the IANA >Considerations section of
[netmod] Proposed IANA text for YANG Module Versioning and Semver Drafts
Hi, // As an individual contributor We discussed proposed IANA text at the last NETMOD interim on the YANG versioning work. Tracked by issue https://github.com/netmod-wg/yang-ver-dt/issues/59 I had the action of updating the text based on comments received in the interim meeting and then sending that text to the list. The proposed text is below (that is in the current published versions of both drafts). If the WG has no objections to this text, then the planned next step is to ask IANA for an early review of this text. IANA section in draft-ietf-netmod-yang-module-versioning-02: 11.2. Guidance for versioning in IANA maintained YANG modules Note for IANA (to be removed by the RFC editor): Please check that the registries and IANA YANG modules are referenced in the appropriate way. IANA is responsible for maintaining and versioning YANG modules that are derived from other IANA registries. For example, "iana-if- type.yang" [IfTypeYang] is derived from the "Interface Types (ifType) IANA registry" [IfTypesReg], and "iana-routing-types.yang" [RoutingTypesYang] is derived from the "Address Family Numbers" [AddrFamilyReg] and "Subsequent Address Family Identifiers (SAFI) Parameters" [SAFIReg] IANA registries. Normally, updates to the registries cause any derived YANG modules to be updated in a backwards-compatible way, but there are some cases where the registry updates can cause non-backward-compatible updates to the derived YANG module. An example of such an update is the 2020-12-31 revision of iana-routing-types.yang [RoutingTypesDecRevision], where the enum name for two SAFI values was changed. In all cases, IANA MUST follow the versioning guidance specified in Section 3.1, and MUST include a "rev:nbc-changes" substatement to the latest revision statement whenever an IANA maintained module is updated in a non-backwards-compatible way, as described in Section 3.2. Note: For published IANA maintained YANG modules that contain non- backwards-compatible changes between revisions, a new revision should be published with the "rev:nbc-changes" substatement retrospectively added to any revisions containing non-backwards-compatible changes. Non normative examples of updates to enumeration types in IANA maintained modules that would be classified as non-backwards- compatible changes are: Changing the status of an enumeration typedef to obsolete, changing the status of an enum entry to obsolete, removing an enum entry, changing the identifier of an enum entry, or changing the described meaning of an enum entry. Non normative examples of updates to enumeration types in IANA maintained modules that would be classified as backwards-compatible changes are: Adding a new enum entry to the end of the enumeration, changing the status or an enum entry to deprecated, or improving the description of an enumeration that does not change its defined meaning. Non normative examples of updates to identity types in IANA maintained modules that would be classified as non-backwards- compatible changes are: Changing the status of an identity to obsolete, removing an identity, renaming an identity, or changing the described meaning of an identity. Non normative examples of updates to identity types in IANA maintained modules that would be classified as backwards-compatible changes are: Adding a new identity, changing the status or an identity to deprecated, or improving the description of an identity that does not change its defined meaning. IANA section for draft-ietf-netmod-yang-semver-02 9.2. Guidance for YANG Semver in IANA maintained YANG modules Note for IANA (to be removed by the RFC editor): Please check that the registries and IANA YANG modules are referenced in the appropriate way. IANA is responsible for maintaining and versioning some YANG modules, e.g., iana-if-types.yang [IfTypeYang] and iana-routing-types.yang [RoutingTypesYang] . In addition to following the rules specified in the IANA Considerations section of [I-D.ietf-netmod-yang-module-versioning] , IANA maintained YANG modules MUST also include a YANG Semver revision label for all new revisions, as defined in Section 3 . The YANG Semver version associated with the new revision MUST follow the rules defined in Section 3.3 . Note: For IANA maintained YANG modules that have already been published, revision labels MUST be retrospectively applied to all existing revisions when the next new revision is created, starting at version "1.0.0" for the initial published revision, and then incrementing according to the YANG Semver version rules specified in Section 3.3 . Most changes to IANA maintained YANG modules are expected to be backwards-compatible changes and classified as MINOR version changes. The PATCH version may be incremented
