Hi Med, all, I have a mixed feeling about this proposal
I understand the need to report the actual state in the operational datastore and IMHO this is a MUST requirement for any implementation However, there are some cases where it is still desirable to express a level of requirement to the server implementation. For example, I have seen examples where a state leaf has been marked as mandatory because in the reference standard it is mandatory to report this information and the authors of the YANG model wanted to keep compliance with the reference standard I am also wondering whether recommending not to use YANG syntax constraints would not encourage describing these standard requirements on the server implementation using the description statements Moreover, my understanding of the text in RFC8342 is that: * when the server is not fully compliant with the reference standard and does not support reporting the information in a mandatory true leaf, it SHOULD flag this lack of compliancy using the deviation statement; * when the server is fully compliant with the reference standard but, due to an expected condition, it is not able to report a mandatory true leaf it can omit this from the operational datastore; * the client should not assume that the mandatory true leaves are always present (or in general that the YANG constraints are always satisfied by the operational data store) Therefore I am wondering whether we would like to discourage people who are willing to define some requirements on the server behavior to use YANG constraints to achieve that Regarding the original question (i.e., the need for the error-message), I think they might be useful when doing offline validation of the operational data store Italo > -----Original Message----- > From: mohamed.boucad...@orange.com > <mohamed.boucad...@orange.com> > Sent: giovedì 16 novembre 2023 10:33 > To: Kent Watsen <k...@watsen.net>; Jason Sterne (Nokia) > <jason.ste...@nokia.com>; Jürgen Schönwälder > <jschoenwaelder@constructor.university>; netmod@ietf.org; Rob Wilton > (rwilton) <rwilton=40cisco....@dmarc.ietf.org> > Subject: Re: [netmod] draft-ietf-netmod-rfc8407bis: must + error-message > for "config false" > > 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<mailto:netmod-boun...@ietf.org>> De la > > part de Kent Watsen > Envoyé > > : mardi 7 novembre 2023 09:17 À : Jason Sterne (Nokia) > > <jason.ste...@nokia.com<mailto:jason.ste...@nokia.com>> Cc : Jürgen > > Schönwälder > > <jschoenwaelder@constructor.university<mailto:jschoenwaelder@constructor.university>>; > > netmod@ietf.org<mailto:netmod@ietf.org>; Rob Wilton (rwilton) > > <rwilton=40cisco....@dmarc.ietf.org<mailto: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<mailto: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<mailto: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<mailto: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<mailto:jschoenwaelder@constructor.university>>; > > >>> mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com> > > >>> Cc: netmod@ietf.org<mailto: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<mailto: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<mailto:mohamed.boucad...@orange.com> > > >>> Cc: netmod@ietf.org<mailto: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<mailto: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%7Cc1ac68c885cb4711756508db > df69fe > > >>>> > > > 8f%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C6383494185533 > 84436% > > >>>> > > > 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ > BTiI > > >>>> > > > 6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=BHSDJ75gIDhVP > GK6Wd4jw > > >>>> 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%7C90c7a20af > 34b4 > > >>> > > > 0bfbc48b9253b6f5d20%7C0%7C0%7C638349418553384436%7CUnknown% > 7CTWFpbGZ > > >>> > > > sb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6M > n0 > > >>> > > %3D%7C3000%7C%7C%7C&sdata=zDx1qDuMLXzjpfQu8W0TmTT40rEzuAP > P%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<mailto:netmod@ietf.org> > > >>>> > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw > > >>>> > > > ww.ietf.org%2Fmailman%2Flistinfo%2Fnetmod&data=05%7C01%7Cmohame > d.bo > > >>>> > > > ucadair%40orange.com%7Cc1ac68c885cb4711756508dbdf69fe8f%7C90c7a > 20af > > >>>> > > > 34b40bfbc48b9253b6f5d20%7C0%7C0%7C638349418553384436%7CUnkno > wn%7CTW > > >>>> > > > FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX > V > > >>>> > > > CI6Mn0%3D%7C3000%7C%7C%7C&sdata=xv80aOKrF0iGDzNvoa%2FemQBlo > 9GT9JUPH > > >>>> 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%7C90c7a20af34b40bfbc48b9253b6f > 5d20%7 > > > C0%7C0%7C638349418553384436%7CUnknown%7CTWFpbGZsb3d8eyJWIjo > iMC4wLjAwMD > > > AiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C > &sdata > > > =76T5wjMZGFhAXNT2WqG9BsJSqAeBI0eAz2fhoHpvD%2B4%3D&reserved=0> > > >>> > > >>> _______________________________________________ > > >>> netmod mailing list > > >>> netmod@ietf.org<mailto: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%7C90c7a20 > af34b > > >>> > > > 40bfbc48b9253b6f5d20%7C0%7C0%7C638349418553384436%7CUnknown > %7CTWFpbG > > >>> > > > Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6 > Mn > > >>> > > > 0%3D%7C3000%7C%7C%7C&sdata=xv80aOKrF0iGDzNvoa%2FemQBlo9GT9J > UPHD%2Fuq > > >>> 8OW%2Bz4%3D&reserved=0 > > >>> _______________________________________________ > > >>> netmod mailing list > > >>> netmod@ietf.org<mailto: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%7C90c7a20 > af34b > > >>> > > > 40bfbc48b9253b6f5d20%7C0%7C0%7C638349418553384436%7CUnknown > %7CTWFpbG > > >>> > > > Zsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6 > Mn > > >>> > > > 0%3D%7C3000%7C%7C%7C&sdata=xv80aOKrF0iGDzNvoa%2FemQBlo9GT9J > UPHD%2Fuq > > >>> 8OW%2Bz4%3D&reserved=0 > > >> _______________________________________________ > > >> netmod mailing list > > >> netmod@ietf.org<mailto: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%7C90c7a20af3 > 4b40b > > >> > > > fbc48b9253b6f5d20%7C0%7C0%7C638349418553384436%7CUnknown%7C > TWFpbGZsb3 > > >> > > > d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0 > %3D% > > >> > > > 7C3000%7C%7C%7C&sdata=xv80aOKrF0iGDzNvoa%2FemQBlo9GT9JUPHD% > 2Fuq8OW%2B > > >> z4%3D&reserved=0 > > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org<mailto:netmod@ietf.org> > > > > > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > > > > > > ietf.org%2Fmailman%2Flistinfo%2Fnetmod&data=05%7C01%7Cmohamed.b > oucadai > > > > > > r%40orange.com%7Cc1ac68c885cb4711756508dbdf69fe8f%7C90c7a20af34 > b40bfbc > > > > > > 48b9253b6f5d20%7C0%7C0%7C638349418553384436%7CUnknown%7CTW > FpbGZsb3d8ey > > > > > > JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D% > 7C300 > > > > > > 0%7C%7C%7C&sdata=xv80aOKrF0iGDzNvoa%2FemQBlo9GT9JUPHD%2Fuq8 > OW%2Bz4%3D& > > > reserved=0 > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org<mailto:netmod@ietf.org> > > > https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. > > > ietf.org%2Fmailman%2Flistinfo%2Fnetmod&data=05%7C01%7Cmohamed.b > oucadai > > > r%40orange.com%7Cc1ac68c885cb4711756508dbdf69fe8f%7C90c7a20af34 > b40bfbc > > > 48b9253b6f5d20%7C0%7C0%7C638349418553384436%7CUnknown%7CTW > FpbGZsb3d8ey > > > JWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D% > 7C300 > > > 0%7C%7C%7C&sdata=xv80aOKrF0iGDzNvoa%2FemQBlo9GT9JUPHD%2Fuq8 > OW%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
