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
