That would be great - thank you.
________________________________
From: Reshad Rahman <[email protected]>
Sent: Monday, June 8, 2026 6:13 PM
To: The IESG <[email protected]>; Mike Bishop <[email protected]>
Cc: [email protected]
<[email protected]>; [email protected]
<[email protected]>; [email protected] <[email protected]>;
[email protected] <[email protected]>
Subject: Re: Mike Bishop's No Objection on
draft-ietf-netmod-yang-module-versioning-16: (with COMMENT)
Hi Mike,
Thank you for clearing your discuss position.
Regarding this specific point:
### Section 6.2, paragraph 2
```
* Clients SHOULD be liberal when processing data received from a
server. For example, the server may have increased the range of
an operational node causing the client to receive a value which is
outside the range of the YANG model revision it was coded against.
```
I'm still very cautious about this text. The argument given is "eventual
consistency,"
which is to say that there may be disagreement between data indicated in
various nodes
or from various sources due to differences in perspective. However, that's a
different
beast from tolerating values which are invalid per the schema of the module.
At a minimum, I'd like there to be some improved text focusing the scope of
this. If
a server is using a schema which is not backwards-compatible to the version the
client
is using, it might expect the possibility for changes in ranges, etc., etc.
Clients
need to exercise particular caution about buffer overruns, etc.
Is this text better/acceptable to you (it would replace the paragraph above).
When interacting with a server that implements a non-backwards-compatible
revision of a YANG module, a client may receive data that is valid per the
server's schema but outside the value constraints of the module revision the
client was coded against. For example, the server may have increased the range
of an operational node. Clients SHOULD handle such values defensively, taking
care to guard against issues such as buffer overruns or other unexpected
behavior arising from out-of-range values.
Regards,
Reshad.
On Friday, June 5, 2026 at 03:34:58 PM EDT, Mike Bishop via Datatracker
<[email protected]> wrote:
Mike Bishop has entered the following ballot position for
draft-ietf-netmod-yang-module-versioning-16: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.
The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-module-versioning/
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
## Previous DISCUSS
Thank you for following up over e-mail. I'm summarizing what I understand the
resolution to be here:
## Discuss
### Section 5.1, paragraph 1
```
The ietf-yang-library-status YANG module augments YANG library with
two boolean leafs to allow a server to report how it implements
status "deprecated" and status "obsolete" schema nodes. The leafs
are:
```
This text is intended to increase client certainty, rather than muddy the
waters.
If servers indicate that deprecated nodes are supported in general, they will
also
need to explicitly indicate (through deviations) nodes that it does not support.
Servers that indicate they do not generally support obsolete schema nodes could
still do so for certain nodes.
### Section 5.1, paragraph 4
Clients will need access to both module versions they're comparing, but don't
need to know anything about intervening versions to make this comparison.
### Section 6.2, paragraph 2
```
* Clients SHOULD be liberal when processing data received from a
server. For example, the server may have increased the range of
an operational node causing the client to receive a value which is
outside the range of the YANG model revision it was coded against.
```
I'm still very cautious about this text. The argument given is "eventual
consistency,"
which is to say that there may be disagreement between data indicated in
various nodes
or from various sources due to differences in perspective. However, that's a
different
beast from tolerating values which are invalid per the schema of the module.
At a minimum, I'd like there to be some improved text focusing the scope of
this. If
a server is using a schema which is not backwards-compatible to the version the
client
is using, it might expect the possibility for changes in ranges, etc., etc.
Clients
need to exercise particular caution about buffer overruns, etc.
## Comments
### Section 4.1, paragraph 7
```
Adding, modifying or removing a "recommended-min-date" extension
statement is a BC change.
```
Is this because compliance is optional? Otherwise, I'd think changing a minimum
version on a dependency would be a potentially-breaking change; a dependent
module which matched the old version would no longer match, and you don't know
whether there were breaking changes between those versions.
### Section 6.2, paragraph 3
```
* Clients SHOULD monitor changes to published YANG modules through
their revision history, and use appropriate tooling to understand
the specific changes between module revision. In particular,
clients SHOULD NOT migrate to NBC revisions of a module without
understanding any potential impact of the specific NBC changes.
* Clients SHOULD plan to make changes to match published status
changes. When a node's status changes from "current" to
"deprecated", clients SHOULD plan to stop using that node in a
timely fashion. When a node's status changes to "obsolete",
clients MUST stop using that node.
```
This seems less about client behavior and more about developer behavior. The
required feature on clients is an update mechanism, because changes will be
necessary over time.
### Section 9.2, paragraph 5
```
For published IANA maintained YANG modules that contain non-
backwards-compatible changes between revisions, a new revision should
be published with the "rev:non-backwards-compatible" substatement
retrospectively added to any revisions containing non-backwards-
compatible changes.
```
Has IANA confirmed it's capable of generating that list? This seems like a
potentially large order. Also, presumably this is suggesting a single new
revision wherein the document's revision history is modified, not making
retrospective changes to the older revisions themselves.
## Nits
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.
### Typos
#### Section 1, paragraph 2
```
- if they are impacted by changes between the revisions. The
- -----
```
#### Section 1, paragraph 2
```
- [I-D.ietf-netmod-yang-semver] document defines a YANG extension that
- ---------
```
#### Section 1, paragraph 2
```
- versioning. YANG packages [I-D.ietf-netmod-yang-packages] provides a
- -
```
#### Section 3, paragraph 6
```
- packages [I-D.ietf-netmod-yang-packages], and YANG library [RFC8525],
- - -
```
#### Section 6.1.1, paragraph 2
```
- Section 4.7 of [I-D.ietf-netmod-rfc8407bis]), instead the status
- ^ ^
+ Section 4.7 of [I-D.ietf-netmod-rfc8407bis]). Instead, the status
+ ^ ^ +
```
#### Section 6.1.1, paragraph 7
```
- See Appendix B for examples on how NBC changes can be made.
- ^
+ See Appendix B for examples of how NBC changes can be made.
+ ^
```
### Section 6.1, paragraph 9
Why introduce a bulleted list of one item? This could be "For example,
if a..."
### Outdated references
Document references `draft-ietf-netmod-RFC8407bis`, but that has been published
as `RFC9907`.
Reference `[I-D.ietf-netmod-rfc6991-bis]` to `RFC6991`, which was obsoleted by
`RFC9911` (this may be on purpose).
Document references `draft-ietf-netmod-RFC6991-bis`, but that has been
published as `RFC9911`.
Document references `draft-clacla-netmod-yang-model-update-06`, but `-26` is
the latest available revision.
### Grammar/style
#### "a/an" NBC
Is NBC pronounced "non-breaking change" or "enn-bee-cee"? This affects whether
a/an is the appropriate article. Pick one and check that you're consistent
throughout.
#### Section 3.4, paragraph 4
```
he importing module, and hence section Section 6.1 suggests that authors do n
^^^^^^^^^^^^^^^
```
Possible typo: you repeated a word.
#### Section 10.1, paragraph 8
```
nd the "description" updated. This is a NBC change. B.2. Changing the type o
^
```
#### Section 10.1, paragraph 6
```
remental approach described in section Section 6.1.1. The examples are all f
^^^^^^^^^^^^^^^
```
Possible typo: you repeated a word.
#### "Appendix A.", paragraph 1
```
remental approach described in section Section 6.1.1 can not be followed. Th
^^^^^^^^^^^^^^^
```
Possible typo: you repeated a word.
_______________________________________________
netmod mailing list -- [email protected]
To unsubscribe send an email to [email protected]
