Hi! Did we decide any time for meeting tomorrow? I don't think I have seen any time mentioned.
-- Per On Mon, Oct 13, 2025 at 9:21 PM Amanda Baber via RT <[email protected]> wrote: > > 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]
