Hi Italo, Thanks for sharing your thoughts.
I do still think there is a value in providing some guidance for such constructs. I updated the PR with the example you provided as I find it better that the one we used to have. Feel free to review and proposed changes to the proposed PR at: https://github.com/boucadair/rfc8407bis/pull/33/files. Cheers, Med De : Italo Busi <italo.b...@huawei.com> Envoyé : vendredi 12 janvier 2024 23:17 À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com>; Martin Björklund <mbj+i...@4668.se> Cc : netmod@ietf.org Objet : RE: [netmod] case + when in 8407bis In my current experience the use of case+when has been in many cases useless and in some cases even misleading and I am now pushing back when proposed For example, with the following YANG code, the leaf bar is not mandatory in case of type c as it would appear at the first glance (that was the intention when a similar YANG code was designed): leaf type { type enumeration { enum a; enum b; enum c; } mandatory true; } choice type-choice { case b { container type-b { when "../type = 'b'"; leaf foo { type string; } } } case c { container type-c { when "../type = 'c'"; leaf bar { mandatory true; type string; } } } } However, thinking further, in the following example (I have never found something similar so far but it is possible at least in theory), using case+when can be useful: leaf type { type enumeration { enum a; enum b; enum c; } } choice second-type { mandatory true; case foo { container foo { presence "When present, indicates type foo" leaf foo-attribute { type string; } } } case b { container bar { when "../type = 'a' or ../type = 'b'"; presence "When present, indicates type bar" leaf bar-attribute { type string; } } } case c { container baz { when "../type = 'c'"; leaf baz-attribute { mandatory true; type string; } } } } It seems to me that the main difference between the two examples if the fact that in the first example the case and attributes used in the when statements are providing duplicated information while in the second example they are providing complimentary information Based on my current thoughts I think it would be worthwhile saying that the use of case+when SHOULD NOT be used when providing duplicated information (i.e., when the when statements is constraining a single case in the choice) My 2 cent Italo > -----Original Message----- > From: mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> > <mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>> > Sent: venerdì 15 dicembre 2023 08:28 > To: Martin Björklund <mbj+i...@4668.se<mailto:mbj+i...@4668.se>> > Cc: netmod@ietf.org<mailto:netmod@ietf.org> > Subject: Re: [netmod] case + when in 8407bis > > Re-, > > > To be clear, I think the paragraph: > > > > Some modules use "case + when" construct such as shown in the > > example > > below. Such a construct MUST be avoided by removing the "when" > > statement or using a "container" outside the "choice". > > > > and the example that follows should be removed. > > > > Noted your objection. > > For now, I removed the text from the main, i.e., will be removed from the > next iteration of the draft that will be submitted early next week. > > However, I created a PR > (https://github.com/boucadair/rfc8407bis/pull/33/files<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fboucadair%2Frfc8407bis%2Fpull%2F33%2Ffiles&data=05%7C02%7Cmohamed.boucadair%40orange.com%7C1e35b09e88674dcbd46808dc13bc3cdf%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638406946394095808%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=oYpDSPV87CpYqp2H5IFFbcv3NxWuhjKhMTEnsMFjoRo%3D&reserved=0>) > to keep the > discussion running as I think there is room for some guidance there. > > I f you consider the example share by Tom, if the "when" is important, > removing choice/case and define these as container+when for these data > nodes is cleaner. After all, the check leads to exclusive choices. > > Cheers, > Med > > > -----Message d'origine----- > > De : Martin Björklund <mbj+i...@4668.se<mailto:mbj+i...@4668.se>> Envoyé : > > jeudi 14 décembre > > 2023 21:48 À : BOUCADAIR Mohamed INNOV/NET > > <mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>> Cc : > > netmod@ietf.org<mailto:netmod@ietf.org> Objet : Re: > > [netmod] case + when in 8407bis > > > > Hi, > > > > > > mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> wrote: > > > Hi Martin, all, > > > > > > Please remember that RFC8407 includes already the following: > > > > > > == > > > "when" statement evaluation is generally more expensive than > > > "if-feature" or "choice" statements == > > > > Yes, this is fine. It is something that the module designer can keep > > in mind when designing the module (actually, the text says "MAY be > > considered"). > > > > > I understand that you may have a concern with the MUST NOT > > language, > > > but we do need some guidance for such constraints. If there are > > cases > > > where having both makes sense, we can transform the MUST NOT to > > SHOULD > > > NOT with a guidance when it is OK to maintain that constraint. > > > > I don't agree that we should have SHOULD NOT either. It feels very > > arbitrary to have such a statement for this particular construct. > > > > To be clear, I think the paragraph: > > > > Some modules use "case + when" construct such as shown in the > > example > > below. Such a construct MUST be avoided by removing the "when" > > statement or using a "container" outside the "choice". > > > > and the example that follows should be removed. > > > > > > /martin > ________________________________________________________________ > ____________________________________________ > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > exploites > ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez > le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les > messages electroniques etant susceptibles d'alteration, Orange decline toute > responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; they should not be distributed, > used or copied without authorisation. > If you have received this email in error, please notify the sender and delete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you. > ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
