I am ok with the draft announcing backward incompatibility and explaining the backward incompatibility with a combination of description statement and “What has changed since RFC 9127” section in the draft.
But I would defer to the netmod WG and/or YANG doctors to produce the guidelines. I do not think this draft is the right place to write the guidelines. Thanks. > On Feb 9, 2022, at 9:36 AM, Jan Lindblad (jlindbla) <jlind...@cisco.com> > wrote: > > Tom, Jeff, > >>> If an implementation, for whatever reason, couldn't support the items that >>> were covered under the new if-feature, they would have already deviated >>> them away. >> >> I do not understand. The case that concerns me is an implementation written >> to RFC9127 that knows the rules for backwards compatibility and so knows >> what it can rely on when a revised module of the same name is found. >> Except, AFAICT, it cannot because we are breaking the rules and giving the >> user little or no help in this I-D to work out why their software no longer >> works. > > I think what Jeff and the BFD team are saying is that there are no such > implementations in the real world. As far as I can tell, that may well be > true. > >> As Jan said, we have not done this before and are in uncharted territory. I >> think we should be more helpful. And the NETMOD WG or the YANG doctors, or >> both, need to produce guidelines ready for the next time. > > This is exactly my point. We're setting a precedence here. Let's do it right. > There may be nobody that cares that it's not compatible, but I still prefer > that we establish a good template for how to declare breakages of this kind, > and then stick to it. At least until the YANG Rev DT publishes revised rules > and official YANG statements. > > Best Regards, > /jan > > >>> >>> An implementation now has the option to not advertise the feature for that >>> case. It may also perversely choose to continue to apply a deviation. >>> >>> No new nodes have been added. Implementations (however unlikely they were >>> to have been done) for RFC 9127 for these nodes would have already had to >>> have dealt with them. >>> >>> -- Jeff >>> >>> >>>> On Feb 7, 2022, at 12:34 PM, t petch <ie...@btconnect.com> wrote: >>>> >>>> On 07/02/2022 15:49, Jan Lindblad (jlindbla) wrote: >>>>> Mahesh, all, >>>>> >>>>> I tend to agree with Tom that the revision description you proposed was a >>>>> bit terse. What I had in mind was perhaps more along these lines: >>>>> >>>>> description >>>>> "This revision is non-backwards-compatible with the previous >>>>> revision. >>>>> >>>>> This revision adds an if-feature statement for the client >>>>> configuration parameters. >>>>> If a client using the previous YANG revision of this module >>>>> connects to a >>>>> server that implements the current YANG revision of this module, >>>>> but does >>>>> not implement the feature, the client may not function properly. >>>>> >>>>> This change was introduced despite this incompatibility because ... >>>>> ... >>>>> "; >>>>> >>>>> Don't take the text above literally, I only wrote that to give an idea >>>>> what I had in mind. There isn't much precedence for how IETF documents >>>>> NBC breakage in YANG modules, so we have to decide upon the right >>>>> verbiage level here. In the drafts produced by the versioning design >>>>> team, there will be an annotation to include in cases like this, >>>>> rev:non-backwards-compatible; which will make this rather clear. While >>>>> waiting for that to be implemented, I'd say we should err on the side of >>>>> making it a little overly clear, rather than hiding the fact. >>>> >>>> >>>> That is more what I would hope to see. The key part for me is that fact >>>> that an if-feature has been added. I would have added something like >>>> 'Consequently, a client that does not support this feature may be unable >>>> to retrieve the objects it would expect to be able to.' >>>> although that may be stating the obvious! >>>> >>>> Tom Petch >>>> >>>> >>>>> >>>>> Best Regards, >>>>> /jan >>>>> >>>>> >>>>> >>>>> Thanks first of all for the review. >>>>> >>>>> On Feb 3, 2022, at 3:22 AM, Jan Lindblad via Datatracker >>>>> <nore...@ietf.org<mailto:nore...@ietf.org>> wrote: >>>>> >>>>> Reviewer: Jan Lindblad >>>>> Review result: Ready with Issues >>>>> >>>>> This is the last call YANG Doctor review of draft-ietf-bfd-rfc9127-bis. >>>>> Browsing the mail archives, this has been a long story. Realizing that the >>>>> context of the bis is to fix a particular issue, I have focused only on >>>>> the >>>>> diffs from RFC 9127. I feel any additional nitpicks I might find in a >>>>> complete >>>>> review would not be welcome at this stage. >>>>> >>>>> I have reviewed the diffs, and find them fulfill the desired technical >>>>> goals. >>>>> Since this update breaks backwards compatibility as defined in RFC 6020 >>>>> sec 10 >>>>> and RFC 7950 sec 11, the process for approving this change has been >>>>> discussed >>>>> at length. One argument that has been put forward for going ahead is that >>>>> the >>>>> previous version of this module was released only a short time ago, so >>>>> there is >>>>> no proliferation of impacted systems in the field. >>>>> >>>>> Another argument has been that the YANG Versioning Design Team is working >>>>> on >>>>> updated backwards compatibility rules. The Ver-DT proposed updates to the >>>>> compatibility rules would indeed allow a change of this kind under certain >>>>> conditions. A key condition for allowing such a break with the backwards >>>>> compatibility is that the module revision history announces this break >>>>> clearly >>>>> to all readers. This is not the case in the -01 version of the modules. >>>>> >>>>> revision 2022-01-04 { >>>>> description >>>>> "Updates to add client configuration parameters feature."; >>>>> >>>>> In my YANG Doctor opinion, updating the revision statement to clearly >>>>> state >>>>> that this version is not backwards compatible with the previous version >>>>> is an >>>>> absolute requirement. I think it would also be fair to module readers to >>>>> add a >>>>> few sentences explaining what's going on here. >>>>> >>>>> How does this sound? >>>>> >>>>> OLD: >>>>> "Updates to add client configuration parameters feature."; >>>>> >>>>> NEW: >>>>> "Updates to add client configuration parameters feature. >>>>> This update breaks backward compatability with earlier >>>>> version of the model. The new feature prevents up to >>>>> three client configuration parameters from being >>>>> included, where they were not needed."; >>>>> >>>>> >>>>> I think that you need more than that (for the reader who does not follow >>>>> the BFD WG). I think that there needs to be a reference to where the >>>>> compatability rules are - RFC7950 s.11 - and the nature of the breakage >>>>> in the language of NETMOD so that readers can judge the impact thereof. >>>>> >>>>> Tom Petch >>>>> >>>>> >>>>> Thanks. >>>>> >>>>> >>>>> Mahesh Jethanandani >>>>> mjethanand...@gmail.com<mailto:mjethanand...@gmail.com> >>>>> >>>>> >>>> >>>> -- >>>> last-call mailing list >>>> last-c...@ietf.org >>>> https://www.ietf.org/mailman/listinfo/last-call >>> >>> . >>> > Mahesh Jethanandani mjethanand...@gmail.com
