Re: [yang-doctors] [netmod] Operational State usage of YANG choices and constraints (fix draft address)

[Andy Bierman <[e-mail]>]

Hi,

On Mon, Jan 22, 2024 at 8:42 AM Mahesh Jethanandani <[e-mail]>
wrote:

> Hi Med,
>
> On Jan 21, 2024, at 11:44 PM, [e-mail] wrote:
>
> Hi Acee,
>
> > I think these points are worth addressing in RFC8407 BIS.
>
> We do already have the following in the bis, which I think covers your
> initial question about “mandatory true” data nodes for operational state”:
>
>    Section 8.1 of [RFC7950] includes a provision for defining a
>    constraint on state data and specifies that the constraint must be
>    true in a valid state data.  However, Section 5.3 of [RFC8342]
>    softens that behavior by allowing semantic constraints to be violated
>    under some circumstances to help detecting anomalies.  Relaxing
>    validation constraints on state data is meant to reveal deviations of
>    the observed behavior vs. intended behavior of a managed entity and
>    hopefully trigger corrective actions by a management system.  From
>    that perspective, it is RECOMMENDED to avoid defining constraints on
>    state data that would hinder the detection by a management system of
>    abnormal behaviors of a managed entity.
>
>
> [mj] When I read this, it tells me that it is ok to put constraints on
> state data.
>
> What I am hearing on the mailing list, by Juergen and others, is
> questioning the use of constraints on state data. What I am interested in
> understanding is, would there be a problem in dropping/ignoring constraints
> on state data?
>
>
The text in question is in sec 8.1

https://datatracker.ietf.org/doc/html/rfc7950#section-8.1

What is a "valid state data tree"?
Any representation of <operational> that is filtered in any way or
incomplete in any way
is not a valid state data tree, so this section does not apply.




   o  If the constraint is defined on state data, it MUST be true in a
      valid state data tree.




Andy

Thanks.
>
>
> No?
>
> Cheers,
> Med
>
> *De :* netmod <[e-mail]> *De la part de* Acee Lindem
> *Envoyé :* vendredi 19 janvier 2024 18:47
> *À :* Andy Bierman <[e-mail]>
> *Cc :* Jürgen Schönwälder <[e-mail]>; YANG
> Doctors <[e-mail]>; [e-mail];
> [e-mail]
> *Objet :* Re: [netmod] [yang-doctors] Operational State usage of YANG
> choices and constraints (fix draft address)
>
> Hi Andy,
>
>
> On Jan 19, 2024, at 12:17, Andy Bierman <[e-mail]> wrote:
>
>
>
> On Fri, Jan 19, 2024 at 9:02 AM Acee Lindem <[e-mail]> wrote:
>
> Along the same lines, what is the sentiment for “mandatory true” data
> nodes for operational state (i.e., “config false” nodes)? Does this make
> sense to identify data nodes the must be returned if the parent node is
> returned?
>
>
>
> What does "must be returned" mean?
>
> Obviously, it does not mean returning the data even if the filters do not
> select that node. (I hope)
> I used to think it meant conformance  (whether the server must implement
> or may implement).
> I was told years ago that is not the case. Use if-feature for that. No
> if-feature == mandatory-to-implement.
>
> If a client requests the parent subtree, then how would it know the
> difference between config=false
> nodes that are not present vs. the server just decided not to return them
> (even though conformance
> to the retrieval operation requires them)?
>
> IMO the mandatory-stmt for config=false nodes does not make any sense at
> all.
>
>
> I’m fine with that - we just need to make sure that this is reflected in
> our IETF models. I think these points are worth addressing in RFC8407 BIS.
>
> Thanks,
> Acee
>
>
>
>
>
>
>
> Thanks
> Acee
>
>
> Andy
>
>
> > On Dec 22, 2023, at 2:36 PM, Jürgen Schönwälder <
> [e-mail]> wrote:
> >
> > On Fri, Dec 22, 2023 at 07:22:55PM +0000, Kent Watsen wrote:
> >> With limited experience wrt the impact on servers, as a client, it’s
> always best for the opstate data to be modeled as accurately as possible,
> for better processing and user experience.
> >>
> >
> > What is accurate?
> >
> > I think the answer is "it depends". There are states that a model
> > allows to represent and there are states it does not allow to
> > represent. If a device ends up in a state that the model can't
> > represent, then the device has a problem, From a debugging point of
> > view, the worst is a device in a state that can't be represented
> > propoerly reporting a valid state it is not in.
> >
> > So like everything else, it is a modeling decision, like picking types
> > and everything else. I am not sure that 'as accurate as possible" is a
> > helpful guideline; for operational state I prefer to see as much as
> > possible the device's true state. (But even picking data types for
> > leaves restricts what can be represented, so it is a judgement call.)
> >
> > /js
> >
> > --
> > Jürgen Schönwälder              Constructor University Bremen gGmbH
> > Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   [phone]         <https://constructor.university/>
>
> _______________________________________________
> yang-doctors mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/yang-doctors
>
> ____________________________________________________________________________________________________________
> 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.
>
> _______________________________________________
> yang-doctors mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/yang-doctors
>
>
>
> Mahesh Jethanandani
> [e-mail]
>
>
>
>
>
>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
>