Hi Mahesh, Please see inline.
Cheers, Med De : Mahesh Jethanandani <[email protected]> Envoyé : lundi 22 janvier 2024 17:43 À : BOUCADAIR Mohamed INNOV/NET <[email protected]> Cc : Acee Lindem <[email protected]>; YANG Doctors <[email protected]>; [email protected]; [email protected] Objet : Re: [yang-doctors] [netmod] Operational State usage of YANG choices and constraints (fix draft address) Hi Med, On Jan 21, 2024, at 11:44 PM, [email protected]<mailto:[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. [mj] When I read this, it tells me that it is ok to put constraints on state data. [Med] The key part is the reco in the last sentence. I think we have a valid path here given what is in 8.1 of 7950 and the provisions in 5.3 of 8342. 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? Thanks. 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. _______________________________________________ yang-doctors mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/yang-doctors Mahesh Jethanandani [email protected]<mailto:[email protected]> ____________________________________________________________________________________________________________ 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
