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

[[e-mail]]

Hi Mahesh,

Please see inline.

Cheers,
Med

De : Mahesh Jethanandani <[e-mail]>
Envoyé : lundi 22 janvier 2024 17:43
À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>
Cc : Acee Lindem <[e-mail]>; YANG Doctors <[e-mail]>; [e-mail]; [e-mail]
Objet : Re: [yang-doctors] [netmod] Operational State usage of YANG choices and constraints (fix draft address)

Hi Med,


On Jan 21, 2024, at 11:44 PM, [e-mail]<mailto:[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.

[Med] The key part is the reco in the last sentence. I think we have a valid path here given what is in 8.1 of 7950 and the provisions in 5.3 of 8342.

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/>

_______________________________________________
yang-doctors mailing list
[e-mail]<mailto:[e-mail]>
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


Mahesh Jethanandani
[e-mail]<mailto:[e-mail]>





____________________________________________________________________________________________________________
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.