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

["Jason Sterne (Nokia)" <[e-mail]>]

+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 <[e-mail]> On Behalf Of Rob Wilton
> (rwilton)
> Sent: Thursday, November 2, 2023 5:17 AM
> To: Jürgen Schönwälder <[e-mail]>;
> [e-mail]
> Cc: [e-mail]
> 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 <[e-mail]> On Behalf Of Jürgen
> Schönwälder
> Sent: Wednesday, November 1, 2023 7:46 AM
> To: [e-mail]
> Cc: [e-mail]
> 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,
> [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/>
> 
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod