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: [email protected]
> <[email protected]>
> Sent: venerdì 15 dicembre 2023 08:28
> To: Martin Björklund <[email protected]>
> Cc: [email protected]
> 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) 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 <[email protected]<mailto:[email protected]>> Envoyé :
> > jeudi 14 décembre
> > 2023 21:48 À : BOUCADAIR Mohamed INNOV/NET
> > <[email protected]<mailto:[email protected]>> Cc :
> > [email protected]<mailto:[email protected]> Objet : Re:
> > [netmod] case + when in 8407bis
> >
> > Hi,
> >
> >
> > [email protected]<mailto:[email protected]> 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.
>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
