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

[Kent Watsen <[e-mail]>]

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