Re: [yang-doctors] [netmod] Operational State usage of YANG choices and constraints (fix draft address)

[Mahesh Jethanandani <[e-mail]>]

Hi Med,

> On Jan 21, 2024, at 11:44 PM, [e-mail] wrote:
> 
> Hi Acee,
>  
> > I think these points are worth addressing in RFC8407 BIS.
>  
> We do already have the following in the bis, which I think covers your initial question about “mandatory true” data nodes for operational state”:
>  
>    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]
>    softens 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 by a management system of
>    abnormal behaviors of a managed entity.

[mj] When I read this, it tells me that it is ok to put constraints on state data.

What I am hearing on the mailing list, by Juergen and others, is questioning the use of constraints on state data. What I am interested in understanding is, would there be a problem in dropping/ignoring constraints on state data?

Thanks.

>  
> No?
>  
> Cheers,
> Med
>  
> De : netmod <[e-mail] <mailto:[e-mail]>> De la part de Acee Lindem
> Envoyé : vendredi 19 janvier 2024 18:47
> À : Andy Bierman <[e-mail] <mailto:[e-mail]>>
> Cc : Jürgen Schönwälder <[e-mail] <mailto:[e-mail]>>; YANG Doctors <[e-mail] <mailto:[e-mail]>>; [e-mail] <mailto:[e-mail]>; [e-mail] <mailto:[e-mail]>
> Objet : Re: [netmod] [yang-doctors] Operational State usage of YANG choices and constraints (fix draft address)
>  
> Hi Andy, 
> 
> 
> On Jan 19, 2024, at 12:17, Andy Bierman <[e-mail] <mailto:[e-mail]>> wrote:
>  
>  
>  
> On Fri, Jan 19, 2024 at 9:02 AM Acee Lindem <[e-mail] <mailto:[e-mail]>> wrote:
> Along the same lines, what is the sentiment for “mandatory true” data nodes for operational state (i.e., “config false” nodes)? Does this make sense to identify data nodes the must be returned if the parent node is returned?
> 
>  
>  
> What does "must be returned" mean?
>  
> Obviously, it does not mean returning the data even if the filters do not select that node. (I hope)
> I used to think it meant conformance  (whether the server must implement or may implement).
> I was told years ago that is not the case. Use if-feature for that. No if-feature == mandatory-to-implement.
>  
> If a client requests the parent subtree, then how would it know the difference between config=false
> nodes that are not present vs. the server just decided not to return them (even though conformance
> to the retrieval operation requires them)?
>  
> IMO the mandatory-stmt for config=false nodes does not make any sense at all.
>  
> I’m fine with that - we just need to make sure that this is reflected in our IETF models. I think these points are worth addressing in RFC8407 BIS. 
>  
> Thanks,
> Acee
>  
>  
> 
> 
>  
>  
> Thanks
> Acee
> 
>  
> Andy
>  
> > On Dec 22, 2023, at 2:36 PM, Jürgen Schönwälder <[e-mail] <mailto:[e-mail]>> wrote:
> > 
> > On Fri, Dec 22, 2023 at 07:22:55PM +0000, Kent Watsen wrote:
> >> With limited experience wrt the impact on servers, as a client, it’s always best for the opstate data to be modeled as accurately as possible, for better processing and user experience.
> >> 
> > 
> > What is accurate?
> > 
> > I think the answer is "it depends". There are states that a model
> > allows to represent and there are states it does not allow to
> > represent. If a device ends up in a state that the model can't
> > represent, then the device has a problem, From a debugging point of
> > view, the worst is a device in a state that can't be represented
> > propoerly reporting a valid state it is not in.
> > 
> > So like everything else, it is a modeling decision, like picking types
> > and everything else. I am not sure that 'as accurate as possible" is a
> > helpful guideline; for operational state I prefer to see as much as
> > possible the device's true state. (But even picking data types for
> > leaves restricts what can be represented, so it is a judgement call.)
> > 
> > /js
> > 
> > -- 
> > Jürgen Schönwälder              Constructor University Bremen gGmbH
> > Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   [phone]         <https://constructor.university/ <https://constructor.university/>>
> 
> _______________________________________________
> yang-doctors mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/yang-doctors <https://www.ietf.org/mailman/listinfo/yang-doctors>
> ____________________________________________________________________________________________________________
> 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.
> _______________________________________________
> yang-doctors mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/yang-doctors <https://www.ietf.org/mailman/listinfo/yang-doctors>

Mahesh Jethanandani
[e-mail]