Re: [netmod] WG Last Call: draft-ietf-netmod-yang-module-versioning-05

[Italo Busi <[e-mail]>]

I have read the draft and I think it is ready to move forward

I think that the draft is well written and it is addressing some real needs

I have few comments which could be addressed as part of this WG LC:

1) Section 3 says:

   <...> As per [RFC7950] and [RFC6020], YANG module
   and submodule revisions continue to be uniquely identified by their
   revision date, and hence all revisions of a given module or submodule
   MUST have unique revision dates.

I think that this requirement would limit the possibility for non-linear development.

If I need to apply a fix to 5 different versions, I need to release them in 5 different days rather than at once, which is quite impractical.

If this constraint is hard to remove (as I would guess), I am wondering whether its removal can be considered at least for the next version of YANG language

2) Editorial: Section 8 contains two YANG modules

It would be easier to read if section 8 is split into two sub-section: section 8.1 for ietf-yang-revisions and section 8.2 for ietf-yang-library-revisions

3) Just a question: why it has been decided to augment the  yang-library rather than revising it?

4) Appending B.2

I like the proposal here and in particular the suggestion to use the "when" statement in point 3.1:
- it allows also to support cases where specifying either the vpn-id or the vpn-name is mandatory;
- it also allows supporting cases where the new node is better placed somewhere else in the YANG tree

My only concern is that this suggestion is not compliant with the following requirement in section 7.21.2 of RFC 7950:

   If a definition is "current", it MUST NOT reference a "deprecated" or
   "obsolete" definition within the same module.

IMHO, it would be worthwhile adding some text, e.g., in section 7.1.1, to update this text in section 7.21.2 of RFC 7950 to support incremental NBC changes

A possible text could be:

   If a definition is "current", it MUST NOT reference a "obsolete"
   definition within the same module and it SHOULD NOT reference a
   "deprecated" definition within the same module, unless this is
   needed to support incremental NBC changes.

5) Appendix B.3

The current text in point 1 is not fully clear to me

I understand and I agree that the change is BC for the functionality (semantic) but NBC for the YANG model (syntax)

However, I do not understand whether the YANG model revision should declare this change as NBC (because it is not in line with section 3.1.1) or as BC (because not impacting the clients)

In the latter case, I think that some text should be added to section 3.1.1 to allow these "exceptions"

Italo

> -----Original Message-----
> From: Lou Berger [mailto:[e-mail]]
> Sent: lunedì 21 febbraio 2022 18:21
> To: NETMOD Group <[e-mail]>
> Cc: NetMod WG Chairs <[e-mail]>
> Subject: [netmod] WG Last Call: draft-ietf-netmod-yang-module-versioning-05
> 
> 
> 
> All,
> 
> This starts working group last call on
> https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-module-versioning/
> 
> The working group last call ends on March 7 th.
> Please send your comments to the working group mailing list.
> 
> Positive comments, e.g., "I've reviewed this document and believe it is ready
> for publication", are welcome!
> This is useful and important, even from authors.
> 
> Please note that once WG Last call is complete, this document will be held and
> submitted as a set with the other versioning documents (once they are ready)
> for publication request to the IESG.
> 
> Thank you,
> Lou (Co-Chair & doc Shepherd)
> 
> 
> 
>