Hi all, Thank you all for the feedback.
Here is the text I suggest to capture the outcome of the discussion: 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] soften 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 of abnormal behaviors of a managed entity. Comments are still welcome. You can also proposed change here: https://github.com/boucadair/rfc8407bis/pull/24/files Thanks. Cheers, Med > -----Message d'origine----- > De : netmod <netmod-boun...@ietf.org> De la part de Kent Watsen > Envoyé : mardi 7 novembre 2023 09:17 > À : Jason Sterne (Nokia) <jason.ste...@nokia.com> > Cc : Jürgen Schönwälder <jschoenwaelder@constructor.university>; > netmod@ietf.org; Rob Wilton (rwilton) > <rwilton=40cisco....@dmarc.ietf.org> > Objet : Re: [netmod] draft-ietf-netmod-rfc8407bis: must + error- > message for "config false" > > My confusion, sorry, I was thinking "mandatory". > > Must statements on opstate are useful, but less important. > > Kent > > > > On Nov 6, 2023, at 5:26 PM, Kent Watsen <k...@watsen.net> wrote: > > > > "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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fd > >>>> atatracker.ietf.org%2Fdoc%2Fdraft-ietf-pce-pcep- > yang%2F&data=05%7C0 > >>>> > 1%7Cmohamed.boucadair%40orange.com%7Cc1ac68c885cb4711756508dbdf69fe > >>>> > 8f%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638349418553384436% > >>>> > 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI > >>>> > 6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=BHSDJ75gIDhVPGK6Wd4jw > >>>> nVqvoPmod8Tdgqs2aE2My4%3D&reserved=0, > >>> 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fma > >>> ilarchive.ietf.org%2Farch%2Fmsg%2Fyang- > &data=05%7C01%7Cmohamed.bouca > >>> > dair%40orange.com%7Cc1ac68c885cb4711756508dbdf69fe8f%7C90c7a20af34b4 > >>> > 0bfbc48b9253b6f5d20%7C0%7C0%7C638349418553384436%7CUnknown%7CTWFpbGZ > >>> > sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0 > >>> > %3D%7C3000%7C%7C%7C&sdata=zDx1qDuMLXzjpfQu8W0TmTT40rEzuAPP%2F%2Bzs9i > >>> pRN1w%3D&reserved=0 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw > >>>> > ww.ietf.org%2Fmailman%2Flistinfo%2Fnetmod&data=05%7C01%7Cmohamed.bo > >>>> > ucadair%40orange.com%7Cc1ac68c885cb4711756508dbdf69fe8f%7C90c7a20af > >>>> > 34b40bfbc48b9253b6f5d20%7C0%7C0%7C638349418553384436%7CUnknown%7CTW > >>>> > FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXV > >>>> > CI6Mn0%3D%7C3000%7C%7C%7C&sdata=xv80aOKrF0iGDzNvoa%2FemQBlo9GT9JUPH > >>>> D%2Fuq8OW%2Bz4%3D&reserved=0 > >>> > >>> > >>> -- > >>> 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://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcon > structor.university%2F&data=05%7C01%7Cmohamed.boucadair%40orange.com%7 > Cc1ac68c885cb4711756508dbdf69fe8f%7C90c7a20af34b40bfbc48b9253b6f5d20%7 > C0%7C0%7C638349418553384436%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMD > AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata > =76T5wjMZGFhAXNT2WqG9BsJSqAeBI0eAz2fhoHpvD%2B4%3D&reserved=0> > >>> > >>> _______________________________________________ > >>> netmod mailing list > >>> netmod@ietf.org > >>> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww > >>> > w.ietf.org%2Fmailman%2Flistinfo%2Fnetmod&data=05%7C01%7Cmohamed.bouc > >>> > adair%40orange.com%7Cc1ac68c885cb4711756508dbdf69fe8f%7C90c7a20af34b > >>> > 40bfbc48b9253b6f5d20%7C0%7C0%7C638349418553384436%7CUnknown%7CTWFpbG > >>> > Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn > >>> > 0%3D%7C3000%7C%7C%7C&sdata=xv80aOKrF0iGDzNvoa%2FemQBlo9GT9JUPHD%2Fuq > >>> 8OW%2Bz4%3D&reserved=0 > >>> _______________________________________________ > >>> netmod mailing list > >>> netmod@ietf.org > >>> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww > >>> > w.ietf.org%2Fmailman%2Flistinfo%2Fnetmod&data=05%7C01%7Cmohamed.bouc > >>> > adair%40orange.com%7Cc1ac68c885cb4711756508dbdf69fe8f%7C90c7a20af34b > >>> > 40bfbc48b9253b6f5d20%7C0%7C0%7C638349418553384436%7CUnknown%7CTWFpbG > >>> > Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn > >>> > 0%3D%7C3000%7C%7C%7C&sdata=xv80aOKrF0iGDzNvoa%2FemQBlo9GT9JUPHD%2Fuq > >>> 8OW%2Bz4%3D&reserved=0 > >> _______________________________________________ > >> netmod mailing list > >> netmod@ietf.org > >> > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww > >> > .ietf.org%2Fmailman%2Flistinfo%2Fnetmod&data=05%7C01%7Cmohamed.boucad > >> > air%40orange.com%7Cc1ac68c885cb4711756508dbdf69fe8f%7C90c7a20af34b40b > >> > fbc48b9253b6f5d20%7C0%7C0%7C638349418553384436%7CUnknown%7CTWFpbGZsb3 > >> > d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D% > >> > 7C3000%7C%7C%7C&sdata=xv80aOKrF0iGDzNvoa%2FemQBlo9GT9JUPHD%2Fuq8OW%2B > >> z4%3D&reserved=0 > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > > > ietf.org%2Fmailman%2Flistinfo%2Fnetmod&data=05%7C01%7Cmohamed.boucadai > > > r%40orange.com%7Cc1ac68c885cb4711756508dbdf69fe8f%7C90c7a20af34b40bfbc > > > 48b9253b6f5d20%7C0%7C0%7C638349418553384436%7CUnknown%7CTWFpbGZsb3d8ey > > > JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C300 > > > 0%7C%7C%7C&sdata=xv80aOKrF0iGDzNvoa%2FemQBlo9GT9JUPHD%2Fuq8OW%2Bz4%3D& > > reserved=0 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > ietf.org%2Fmailman%2Flistinfo%2Fnetmod&data=05%7C01%7Cmohamed.boucadai > r%40orange.com%7Cc1ac68c885cb4711756508dbdf69fe8f%7C90c7a20af34b40bfbc > 48b9253b6f5d20%7C0%7C0%7C638349418553384436%7CUnknown%7CTWFpbGZsb3d8ey > JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C300 > 0%7C%7C%7C&sdata=xv80aOKrF0iGDzNvoa%2FemQBlo9GT9JUPHD%2Fuq8OW%2Bz4%3D& > reserved=0 ____________________________________________________________________________________________________________ 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
