Re: [netmod] Unknown bits - backwards compatibility

[Andy Bierman <[e-mail]>]

On Thu, Apr 13, 2023 at 2:00 PM Jason Sterne (Nokia) <[e-mail]>
wrote:

> Hi Jeff,
>
>
>
> We avoided getting into subtleties about “severity” of an NBC change (hard
> enough to just get agreement on basic rules). But I do think it is useful
> to come up with changes and approaches that have lower impact on
> users/clients even if they are still marked as NBC.
>
>
>
> For the new versioning marking, it would basically be the following. In
> the “revision” statement of the new module:
>
>    1. Add "rev:non-backwards-compatible" as per draft-ietf-netmod-yang-module-versioning-08
>    - Updated YANG Module Revision Handling
>    <https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-module-versioning/>
>    2. Increment the major version of the YANG Semver (i.e. go from 1.0.0
>    to 2.0.0) as per draft-ietf-netmod-yang-semver-11 - YANG Semantic
>    Versioning
>    <https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-semver/11/>
>
>
>

I do not see any way to interpret RFC 7950 such that a YANG extension can
be added
later to another document that overrides any normative behavior defined in
RFC 7950.

So as long as a vendor wants to claim conformance to YANG 1.1, no MUSTs in
7950 can
be violated. Period.  That may be harsh, but MUST and MUST NOT work that
way.


That may seem harsh, but we leaned towards being strict on flagging any NBC
> change in order to avoid false-negatives (i.e. false-positives aren’t as
> bad). Users can then diff the module versions, see that only the
> unknown-bits stuff has changed, and then decide if they need to update
> their client, etc.
>
>
>
> Jason
>
>
>


Andy


> *From:* Jeffrey Haas <[e-mail]>
> *Sent:* Thursday, April 13, 2023 4:44 PM
> *To:* Jason Sterne (Nokia) <[e-mail]>
> *Cc:* [e-mail]
> *Subject:* Re: Unknown bits - backwards compatibility
>
>
>
>
>
> *CAUTION:* This is an external email. Please be very careful when
> clicking links or opening attachments. See the URL nok.it/ext for
> additional information.
>
>
>
> Jason,
>
>
>
>
>
> On Apr 13, 2023, at 4:29 PM, Jason Sterne (Nokia) <[e-mail]>
> wrote:
>
> *[>>JTS:] Yeah – I see that perspective. But a client using the old
> API/contract gets new/different behavior for the unknown-flags leaf from a
> new server. Hence NBC – unless we decide in the end to somehow make this
> specific case/typedef an exception but I’m not sure about that yet. The
> typedef and behavior you are describing there may still be useful as-is
> even if we decide to still officially consider the change to unknown-flags
> behavior as NBC (i.e. in new the version of the module that changes a bit
> from unknown to known).*
>
>
>
> Understood.  True to form, I seldom seem to come to netmod with easy
> problems. :-)
>
>
>
> Not having read the current versioning material, this would seem to be a
> case where you could consider this NBC, but likely not-problematic.  I'm
> not sure if you have "severity" as a concept in the discussions thus far.
>
>
>
> If there's current verbiage about documenting NBC considerations, feel
> free to point me to the appropriate documents.  As a general purpose
> mechanism, the draft could simply describe that any time an update to the
> known leaf type is done that the unknown leaf type is flagged for NBC for
> the newly assigned bits.
>
>
>
>
>
> I wish to point you and others concerned on these points to the BGP YANG
> modeling for Extended Communities, which will have these problems in a
> different flavor: Known communities will render via the typedefs, unknown
> will render using the prefix 'raw'.  (See typedef bgp-ext-community-type.)
>  This headache is already a consideration in every BGP implementation that
> deals with extended communities in changing meaning.
>
> *[>>JTS:] Can you point me to a repository or RFC where I can see this?
> I’m not familiar with where this YANG work is being done.*
>
>
>
> Sorry for not including the URL.  This document went to WGLC for IDR a few
> days ago.  We'll be asking (yet yet yet again) for YANG doctor review.
>
> https://www.ietf.org/archive/id/draft-ietf-idr-bgp-model-16.html
>
>
>
> You'll find the typedef issue for extended communities in there, and also
> the field for unknown bits in the operational state that is the genesis for
> this conversation.
>
>
>
> Figure 4 in draft version -02 shows how the type gets modified to add the
> new bit. The model doesn't change between step 1/ step 2 beyond this.  *[>>JTS:]
> Sure – maybe just mention explicitly that the model for unknown-flags stays
> unchanged.*
>
>
>
> If you'd find it helpful, I could add to the text covering Figure 8 "after
> assignment, bit-1 is no longer returned in unknown-flags".  Is that what
> you're looking for?*[>>JTS:] Yes – that would probably help.*
>
>
>
> I'll try to roll in these changes soon. Thanks.
>
>
>
> -- Jeff
>
>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
>