Hi, I can confirm that Sabrina and I will be available on Tuesday morning, and Per has contacted us about separate pre-meeting training. About the questions below:
On Thu Oct 09 19:40:10 2025, [email protected] wrote: > Hi Amanda, > > Thanks for the clearly detailed look you took at the drafts. > > I'll start with some initial thoughts below but before I get too far, > it may be good to see another person or two from NETMOD chime in to > make sure I'm on the right track 😊 > > Please see inline. > > Jason <snip> > > To wrap up our semver notes, this is a list of registry/YANG updates > > that we > > wouldn't be sure how to classify: > > > > Replacing reference (as in an obsoleted RFC) - BC? Editorial? > [>>JTS:] This is allowed in RFC7950 ("A "reference" statement may be > added or updated.") and Module Versioning mostly keeps the same rules > as 7950 to determine NBC vs BC (only a few exceptions). I'd propose > this is simply "editorial". Thanks. Can you specify that for us in the document? We've updated references in enum/identity statements before, but weren't sure how this would be classified. > > Listing additional (not replacement) reference for registration - BC? > > Editorial? > [>>JTS:] BC and editorial. > (I'm assuming the net result in the YANG module vs the previously > published version is an additional or changed 'reference' statement > right?) It would. (Maybe I should have used major/minor/patch? But we'd have even less of a clue about "major" vs. "minor.") > > For assignments made immediately after the IESG approved an I-D for > > publication: replacing draft string w/newly-assumed RFC number upon > > publication (also, this is assuming that we're only replacing the > > enum's > > reference, not the original revision statement's reference) - > > Editorial? > [>>JTS:] I'm not 100% certain what change to the YANG you're talking > about here (vs the previous version of the YANG). Can you give a > concrete example of a line(s) in the YANG before and after this > change? Sure. These are the updates we added to the iana-dns-class-rr-type module when we registered RRTYPE 66, DSYNC: enum DSYNC { value 66; description "Endpoint discovery for delegation synchronization"; reference "draft-ietf-dnsop-generalized-notify-03"; } revision 2024-12-10 { description "Registered RR Type DSYNC 66. Added version numbers to draft strings, references to revision statements."; reference "draft-ietf-dnsop-generalized-notify-03"; } When draft-ietf-dnsop-generalized-notify was published, we left the original revision statement untouched, but updated the enum statement's reference substatement and added a new revision statement: enum DSYNC { value 66; description "Endpoint discovery for delegation synchronization"; reference "RFC 9859"; } revision 2025-09-30 { description "Replaced draft string reference to 66 DSYNC with RFC 9859."; reference "RFC 9859" + "[email protected]"; } We almost always register values before documents receive an RFC number. However, if reference changes are editorial, it sounds like we have an answer to this one. > > Errata reports for YANG modules or underlying registries -- does > > NBC/BC/editorial status depend on the content of the errata reports? > [>>JTS:] No - I don't think so. The NBC vs BC categorization is purely > based on the content of the module (before vs after). OK. At the moment, I don't have any useful examples of verified errata that require a change to the module but not the underlying registry, so we may have to follow up on that later. W/r/t the question about verified errata that require changes to the underlying registration, I guess my question was about whether the fact that a change came from an errata report would confer any special status on a change that might otherwise be considered BC. It sounds like the answer would be no (and I can't think of such a change). > > Removing registration (similar to obsoleting, but no trace left > > behind) - NBC? > [>>JTS:] What change in the YANG does this result in? If it removes a > line of YANG then strictly speaking this isn't allowed in RFC7950 and > hence we'd consider it NBC. Got it. > > Chairs decide to mark value as "deprecated" while removing the > > name/description of the registration - Still BC? Also, what's the > > status sub- > > statement in this scenario? (we might need to address approaches to > > deprecation in 8126bis, not sure) > [>>JTS:] Sorry - not positive what YANG change this results in? Same > for the next two. Can you give examples? I don't know what YANG change this would result it. We'd have to ask. The scenario in the underlying registry is this, where RFC YYYY deprecates the original registration: OLD: Value: 5 Name: Example Reference: RFC XXXX NEW: Value: 5 Name: Deprecated Reference: RFC XXXX, RFC YYYY ... as opposed to listing "Example (Deprecated)" in the name field. This isn't our usual practice, but we have received requests to do that. It sounds like we might need to ask the IANABIS group whether there should be a particular way to display deprecations. > > Early allocation allowed to expire + chairs decide to leave the > > registration as-is > > without removing or marking it "deprecated" - NBC? Not sure how we > > add a > > status sub-statement for this either. (These are rare, and once we > > were asked > > to revive the expired allocation a couple of years later.) > > > > Changes to the registration that won't be reflected in the module > > (for example, > > if there are changes, substantive or otherwise, to other fields > > beyond "name" > > and "description," or if we need to update a non-IETF reference) - no > > change? Similarly, where this is the original registration: Value: 5 Name: Example (TEMPORARY - registered 2024-10-01, expires 2025-10-01) Reference: draft-ietf-XXXX If the WG chairs/AD decide not to renew the allocation, they might ask us to leave it in place, as above (in which case they might come back years later and renew); remove the name and mark it "Deprecated"; change the name to "Example (Deprecated)"; or remove the record entirely. I'm not sure we've brought up RFC 7120 early allocations in a YANG context. Any registry that requires an RFC for publication is open to early allocations. These typically become permanent registrations, but descriptions will occasionally change, and one or two allocations from a set of early allocations might be abandoned. Early allocations may not be common in the registries that currently have YANG modules associated with them, though. I'm not sure there's any action to be taken here, because deprecated and obsoleted values generally won't be re-assigned until all other values have been exhausted. It might be worth noting, though, that a deprecated value might be brought back to life if the chairs/AD decide to bring back a set of early allocations that was deliberately allowed to expire. We've only seen this a few times, though. > > thanks, > > Amanda _______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
