+1 on what Jurgen and Rob are pointing out here. I'm not sure it makes a ton of sense to actually have a lot of "must" statements in state models. We could consider discouraging them? (but we need to continue *allowing* them).
Jason > -----Original Message----- > From: netmod <netmod-boun...@ietf.org> On Behalf Of Rob Wilton > (rwilton) > Sent: Thursday, November 2, 2023 5:17 AM > To: Jürgen Schönwälder <jschoenwaelder@constructor.university>; > mohamed.boucad...@orange.com > Cc: netmod@ietf.org > Subject: Re: [netmod] draft-ietf-netmod-rfc8407bis: must + error-message > for "config false" > > > CAUTION: This is an external email. Please be very careful when clicking > links or opening attachments. See the URL nok.it/ext for additional > information. > > > > Specifically regarding MUST statements on state date, RFC 8342 section 5.3, > also has this statement (which effectively aligns to Jürgen's last paragraph): > > <operational> SHOULD conform to any constraints specified in the data > model, but given the principal aim of returning "in use" values, it > is possible that constraints MAY be violated under some circumstances > (e.g., an abnormal value is "in use", the structure of a list is > being modified, or remnant configuration (see Section 5.3.1) still > exists). Note that deviations SHOULD be used when it is known in > advance that a device does not fully conform to the <operational> > schema. > > Only semantic constraints MAY be violated. These are the YANG > "when", "must", "mandatory", "unique", "min-elements", and > "max-elements" statements; and the uniqueness of key values. > > Syntactic constraints MUST NOT be violated, including hierarchical > organization, identifiers, and type-based constraints. If a node in > <operational> does not meet the syntactic constraints, then it > MUST NOT be returned, and some other mechanism should be used to > flag > the error. > > Regards, > Rob > > > -----Original Message----- > From: netmod <netmod-boun...@ietf.org> On Behalf Of Jürgen > Schönwälder > Sent: Wednesday, November 1, 2023 7:46 AM > To: mohamed.boucad...@orange.com > Cc: netmod@ietf.org > Subject: Re: [netmod] draft-ietf-netmod-rfc8407bis: must + error-message > for "config false" > > Here is what RFC 7950 says: > > 7.5.4.1. The "error-message" Statement > > The "error-message" statement, which is optional, takes a string as > an argument. If the constraint evaluates to "false", the string is > passed as <error-message> in the <rpc-error> in NETCONF. > > Since state data is not (directly) modified by processing RPCs, which > <rpc-error> would carry the <error-message>? If the answer is 'none', > then why define an <error-message> for state data? > > My take has always been that operational state data should report as > much as possible the true state of the device - even if the current > state violates certain constraints. The entity to check constraints > would be a managing system, not the managed system. That said, the > wording in section 7.5.4.1 indicates that the designers had servers > processing RPCs in mind. > > /js > > On Tue, Oct 31, 2023 at 10:40:15AM +0000, > mohamed.boucad...@orange.com wrote: > > Hi all, > > > > In the context of > > https://datatracker.ietf.org/doc/draft-ietf-pce-pcep-yang/, > Dhruv has received in the past a comment about the use of "must + error- > message" for "config false" data nodes. He reported that comment at > https://mailarchive.ietf.org/arch/msg/yang- > doctors/gWnXnyNHPVv_nZB1PQjThAwP1JY/, but without any follow-up. > > > > rfc7950#section-8.1 includes a provision for the use of "must" for state > data, but silent about the use of error-message. Some guidance for authors > may be useful here. > > > > The following options are being considered: > > > > (1) Remove both must and error-message for config false data nodes > > (2) Remove error-message but keep the must > > (3) keep both > > > > I think that (3) is OK as this is a formal way to detect anomalies in state > data, but I'm open to hear what the WG thinks. > > > > Opinions whether we need to include a mention about this in draft-ietf- > netmod-rfc8407bis are welcome. > > > > Thank you. > > > > Cheers, > > Med > > > > > __________________________________________________________________ > __________________________________________ > > 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 > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > -- > 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/> > > _______________________________________________ > 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 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
