Hi, On Mon, Jan 22, 2024 at 8:42 AM Mahesh Jethanandani <mjethanand...@gmail.com> wrote:
> Hi Med, > > On Jan 21, 2024, at 11:44 PM, mohamed.boucad...@orange.com 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 <netmod-boun...@ietf.org> *De la part de* Acee Lindem > *Envoyé :* vendredi 19 janvier 2024 18:47 > *À :* Andy Bierman <a...@yumaworks.com> > *Cc :* Jürgen Schönwälder <jschoenwaelder@constructor.university>; YANG > Doctors <yang-doct...@ietf.org>; netmod@ietf.org; > draft-ietf-netmod-rfc8407...@ietf.org > *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 <a...@yumaworks.com> wrote: > > > > On Fri, Jan 19, 2024 at 9:02 AM Acee Lindem <acee.i...@gmail.com> 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 < > jschoenwaelder@constructor.university> 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 > yang-doct...@ietf.org > 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 > yang-doct...@ietf.org > https://www.ietf.org/mailman/listinfo/yang-doctors > > > > Mahesh Jethanandani > mjethanand...@gmail.com > > > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
