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? Thanks. > > No? > > Cheers, > Med > > De : netmod <netmod-boun...@ietf.org <mailto:netmod-boun...@ietf.org>> De la > part de Acee Lindem > Envoyé : vendredi 19 janvier 2024 18:47 > À : Andy Bierman <a...@yumaworks.com <mailto:a...@yumaworks.com>> > Cc : Jürgen Schönwälder <jschoenwaelder@constructor.university > <mailto:jschoenwaelder@constructor.university>>; YANG Doctors > <yang-doct...@ietf.org <mailto:yang-doct...@ietf.org>>; netmod@ietf.org > <mailto:netmod@ietf.org>; draft-ietf-netmod-rfc8407...@ietf.org > <mailto: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 > <mailto:a...@yumaworks.com>> wrote: > > > > On Fri, Jan 19, 2024 at 9:02 AM Acee Lindem <acee.i...@gmail.com > <mailto: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 > > <mailto: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/ > > <https://constructor.university/>> > > _______________________________________________ > yang-doctors mailing list > yang-doct...@ietf.org <mailto:yang-doct...@ietf.org> > https://www.ietf.org/mailman/listinfo/yang-doctors > <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 <mailto:yang-doct...@ietf.org> > https://www.ietf.org/mailman/listinfo/yang-doctors > <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
