Hi Martin, all, Please remember that RFC8407 includes already the following:
== "when" statement evaluation is generally more expensive than "if-feature" or "choice" statements == 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. Thanks. Cheers, Med > -----Message d'origine----- > De : Martin Björklund <mbj+i...@4668.se> > Envoyé : lundi 11 décembre 2023 09:43 > À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucad...@orange.com> > Cc : netmod@ietf.org > Objet : Re: [netmod] case + when in 8407bis > > Hi, > > mohamed.boucad...@orange.com wrote: > > Re-, > > > > Please see inline. > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De : Martin Björklund <mbj+i...@4668.se> Envoyé : vendredi 8 > > > décembre 2023 17:35 À : BOUCADAIR Mohamed INNOV/NET > > > <mohamed.boucad...@orange.com> Cc : netmod@ietf.org Objet : > Re: > > > [netmod] case + when in 8407bis > > > > > > mohamed.boucad...@orange.com wrote: > > > > Re-, > > > > > > > > There was an invitation to review the changes: > > > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2 > Fma > > > > il%2F&data=05%7C01%7Cmohamed.boucadair%40orange.com%7C94804503f64 > c47 > > > > c5e08708dbfa252a29%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6 > 383 > > > > 78809765220362%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIj > oiV > > > > 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=BGyJa > Mq6 > > > i%2B6eh9zd0kRX8oAGJ33x4nFW8XVB9L15E8w%3D&reserved=0 > > > archive.ietf.org%2Farch%2Fmsg%2Fnetmod%2F4NDzo7SLinue- > > > > CeHGRyOD6aWXHI%2F&data=05%7C01%7Cmohamed.boucadair%40orange.com%7 > Cde > > > eb > > > > 1242f9e74a43da5208dbf80baf06%7C90c7a20af34b40bfbc48b9253b6f5d20%7 > C0% > > > 7C > > > > 0%7C638376501320001779%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD > AiL > > > CJ > > > > QIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata > =k4 > > > pc 95TknbyhSk4duRn%2Brt6vlTPOchzrsVbFOiuYv4M%3D&reserved=0, > but no > > > follow-up. > > > > > > > > Do you have any concern with that part? Thanks. > > > > > > I do, but I suspect that there is a reason for this rule, so > I'd > > > like to understand that. (I have some faint memory of such a > > > discussion on the list, but I may be wrong). > > > > > > My objection is (1) why should this legal construct not be > used and > > > > [Med] The reasoning is: What would be intuitive is to see a > model use > > either of these approaches rather than both. This questions the > need > > for the choice/case statement in the first place. > > Ok. I object to this recommendation. It is a valid construct, > and if the model designer thinks that the model is best when this > consruct is used, they should be allowed to use it. > > > /martin > > > > > > > > > (2) I don't think the proposed workaround is correct, since > if you > > > move the when to a container that surrounds the entire > choice, the > > > other cases in the choice are also made conditional. > > > > [Med] Actually, that's not what the text intends to say. The > proposal > > is to consider getting rid of choice. > > > > > > > > > > > > > > /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
