“Must” statements on opstate usefully helps clients know when certain values will always appear, enabling better optimization and usability.
E.g., for Syslog messages, there must always be a timestamp, severity, and a message. It would be unhelpful for the server to not declare its intention to always send these fields. Kent > On Nov 6, 2023, at 10:49 AM, Jason Sterne (Nokia) <jason.ste...@nokia.com> > wrote: > > +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 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
