Hi Med, > On Jan 22, 2024, at 02:44, [email protected] 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.
It does cover it with “validation constraints” and “deviations of observed behavior”. However, it might be good to explicitly cover “mandatory” since this indicates to return a data node rather than suppress data nodes not being returned due to validation. Thanks, Acee > > No? > > Cheers, > Med > > De : netmod <[email protected] <mailto:[email protected]>> De la > part de Acee Lindem > Envoyé : vendredi 19 janvier 2024 18:47 > À : Andy Bierman <[email protected] <mailto:[email protected]>> > Cc : Jürgen Schönwälder <[email protected] > <mailto:[email protected]>>; YANG Doctors > <[email protected] <mailto:[email protected]>>; [email protected] > <mailto:[email protected]>; [email protected] > <mailto:[email protected]> > 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 <[email protected] > <mailto:[email protected]>> wrote: > > > > On Fri, Jan 19, 2024 at 9:02 AM Acee Lindem <[email protected] > <mailto:[email protected]>> 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 > > <[email protected] > > <mailto:[email protected]>> 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: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 <https://constructor.university/> > > _______________________________________________ > yang-doctors mailing list > [email protected] <mailto:[email protected]> > 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.
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
