Re: [netmod] draft-ietf-netmod-rfc8407bis: must + error-message for "config false"

[Jürgen Schönwälder <[e-mail]>]

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, [e-mail] 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod


-- 
Jürgen Schönwälder              Constructor University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://constructor.university/>