Hi Martin, Please see inline.
Cheers, Med > -----Message d'origine----- > De : Martin Björklund <mbj+i...@4668.se> > Envoyé : jeudi 14 décembre 2023 21:48 > À : 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: > > 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"). > [Med] ACK for the MAY part. However, that excerpt seems to implicitly assume that either a "when" is present or "choice". At least this is how I interpret that text. No? > > 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. _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
