Thanks for the review and apologies for the delay in responding for
module-versioning (Per and Joe have responded for the 2 other documents)...
Please see inline.
On Friday, November 1, 2024 at 12:07:22 PM EDT, Jürgen Schönwälder
<[email protected]> wrote:
On Tue, Oct 08, 2024 at 06:08:11PM -0400, Lou Berger wrote:
> All,
>
> This starts working group last call on our core versioning documents:
[...]
> The working group last call ends on Friday October 25th - slightly extended
> since LC for 3 documents.
>
> Please send your comments to the working group mailing list.
* Updated YANG Module Revision Handling
<draft-ietf-netmod-yang-module-versioning-12>
- The flagging of NBC changes still is at the module level and not
at the level of definitions. Why not? (Other real world languages
do have annotations such @since etc.) It always matters _which_
definition has actually an NBC change, not whether something in a
module has an NBC change. Why do we not mark the definitions that
have non-backwards-compatible changes and then the rest follows
from this? Instead, we give readers and compilers the puzzle to
find out what has actually changed. This feels backwards. If there
is an NBC change in YANG module, you want to quickly find out
whether your module is affected or not. Why do we make this
complicated? If we were to make an NBC change to
yang:date-and-time, why would I not mark this typedef and instead
mark ietf-yang as NBC? If an importing module does not use
yang:date-and-time, it is not affected. Why do we make it hard to
determine whether an importing module is affected?<RR> The
authors/contributors considered this and actually started doing some work on
per-node indicators. Eventually we decided to stick with only per-module NBC
indicator in this document, the decision and the reasons behind it were
communicated on the list here:
https://mailarchive.ietf.org/arch/msg/netmod/eXYt-SKJ3necZ_T_jUPVKhFPUac/
If not already done, this should be added to the yang-next issues.
- If a module import a definition from some other module that has an
NBC change of say a typedef used by the importing module, does
this module have to declare an NBC change as well? And if so, what
if the presence of an NBC change depends on how the import is
resolved, i.e., it may not be in the hands of the module author?<RR> No,
the importing module does not have to declare an NBC change as well. We added
text in 3.1.1 of rev-13 to clarify this.
- I wonder whether extension statements were ever allowed "to change
the semantic of a module". It should always be possible to ignore
extensions. See RFC 7950: "An extension attaches non-YANG
semantics to statements." And then later:
Care must be taken when defining extensions so that modules that use
the extensions are meaningful also for applications that do not
support the extensions.
Hence, I do not understand bullet #3 in section 3.1.1.<RR> That 3rd bullet
has been reworded. We have removed "semantics of a module".
- Section 6.2 is a bit confusing because it talks about clients but
the guidance seems to apply to developers of clients, or do you
really expect that client code itself can "plan to make changes to
match published status changes". To me, this section seems to
provide guidance for client developers not clients.
<RR> I think it's a given that developers have to make the changes to clients,
but rev-13 now mentions developers of clients. No we are not alluding to
clients with "AI" yet :-)
- The definition of revision date could be as well:
typedef revision-date {
type yang:date-no-zone;
description
"A date associated with a YANG revision.
Matches dates formatted as YYYY-MM-DD.";
reference
"RFC XXXX: Common YANG Data Types";
}
But perhaps the idea is to avoid dependencies. I do not care much
but I thought I at least mention that we now (or soon) have a
suitable type in place.<RR> Avoiding dependencies was the initial reason
why we didn't use the definition from 6991-bis. But that was a few years ago
and 6991-bis is close to the finish line now. Made the change you suggested
above.
- Is ietf-yang-status-conformance is a good module name given that
this module is essentially an extension of ietf-yang-library? Did
you consider to name the module say ietf-yang-library-status and
to also use a prefix like yanglib-status (or yl-status - see
below)?
<RR> Changed the module name to ietf-yang-library-status and the prefix to
"yls".
- Appendix A: Changing a type is NBC only if the new type is having
different syntax or semantics. See section 11 of RFC 7950, there
is an explicit bullet for this.<RR> Modified bullet 2 and added bullet 3
with a reference to RFC7950.
Regards,Reshad.
_______________________________________________
netmod mailing list -- [email protected]
To unsubscribe send an email to [email protected]
