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

2023-11-24 Thread Italo Busi 
Hi Med, all,

I have a mixed feeling about this proposal

I understand the need to report the actual state in the operational datastore 
and IMHO this is a MUST requirement for any implementation

However, there are some cases where it is still desirable to express a level of 
requirement to the server implementation. For example, I have seen examples 
where a state leaf has been marked as mandatory because in the reference 
standard it is mandatory to report this information and the authors of the YANG 
model wanted to keep compliance with the reference standard

I am also wondering whether recommending not to use YANG syntax constraints 
would not encourage describing these standard requirements on the server 
implementation using the description statements

Moreover, my understanding of the text in RFC8342 is that:
*   when the server is not fully compliant with the reference standard and 
does not support reporting the information in a mandatory true leaf, it SHOULD 
flag this lack of compliancy using the deviation statement;
*   when the server is fully compliant with the reference standard but, due 
to an expected condition, it is not able to report a mandatory true leaf it can 
omit this from the operational datastore;
*   the client should not assume that the mandatory true leaves are always 
present (or in general that the YANG constraints are always satisfied by the 
operational data store)

Therefore I am wondering whether we would like to discourage people who are 
willing to define some requirements on the server behavior to use YANG 
constraints to achieve that

Regarding the original question (i.e., the need for the error-message), I think 
they might be useful when doing offline validation of the operational data store

Italo

> -Original Message-
> From: mohamed.boucad...@orange.com
> 
> Sent: giovedì 16 novembre 2023 10:33
> To: Kent Watsen ; Jason Sterne (Nokia)
> ; Jürgen Schönwälder
> ; netmod@ietf.org; Rob Wilton
> (rwilton) 
> Subject: Re: [netmod] draft-ietf-netmod-rfc8407bis: must + error-message
> for "config false"
>
> Hi all,
>
> Thank you all for the feedback.
>
> Here is the text I suggest to capture the outcome of the discussion:
>
>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] soften
>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 of abnormal behaviors of a
>managed entity.
>
> Comments are still welcome.
>
> You can also proposed change here:
> https://github.com/boucadair/rfc8407bis/pull/24/files
>
> Thanks.
>
> Cheers,
> Med
>
> > -Message d'origine-
> > De : netmod mailto:netmod-boun...@ietf.org>> De la 
> > part de Kent Watsen
> Envoyé
> > : mardi 7 novembre 2023 09:17 À : Jason Sterne (Nokia)
> > mailto:jason.ste...@nokia.com>> Cc : Jürgen 
> > Schönwälder
> > mailto:jschoenwaelder@constructor.university>>;
> > netmod@ietf.org; Rob Wilton (rwilton)
> > mailto:rwilton=40cisco@dmarc.ietf.org>>
> > Objet : Re: [netmod] draft-ietf-netmod-rfc8407bis: must + error-
> > message for "config false"
> >
> > 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 
> > > mailto:k...@watsen.net>> 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)
> > mailto:jason.ste...@nokia.com>> 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 mailto:netmod-boun...@ietf.org>> 
> > >>> On Behalf Of Rob Wilton
> > >>> (rwilton)
> > >>> Sent: Thursday, November 2, 2023 5:17 AM
> > >>> To: Jürgen Schönwälder 
> > >>> mailto:jschoenwaelder@constructor.university>>;
> > >>> mohamed.boucad...@orange.com
> >

Re: [netmod] I-D Action: draft-ietf-netmod-rfc8407bis-04.txt

2023-11-24 Thread mohamed . boucadair 
Hi all,

This version implements the change about conditional checks on state data. It 
also adds an example for the use of yangson (received offline requests about 
this).

Italo raised a comment during teas session about the lack of instructions in 
8407bis about listing changes in bis doc. After double checking, no change is 
needed to 8407bis as that is already covered by the ID-Guidelines cited in the 
doc. 

Also, sent a message to SAAG for the review of the security cons: 
https://mailarchive.ietf.org/arch/msg/saag/z338jOL6mpYIIzT0Xk8ioCvi6v4/. Rich 
Salz already reviewed that text and he thinks that all is OK. Will report to 
the WG if feedback from saag is received.

Cheers,
Med

> -Message d'origine-
> De : I-D-Announce  De la part de
> internet-dra...@ietf.org
> Envoyé : jeudi 23 novembre 2023 14:31
> À : i-d-annou...@ietf.org
> Cc : netmod@ietf.org
> Objet : I-D Action: draft-ietf-netmod-rfc8407bis-04.txt
> 
> Internet-Draft draft-ietf-netmod-rfc8407bis-04.txt is now available.
> It is a work item of the Network Modeling (NETMOD) WG of the IETF.
> 
>Title:   Guidelines for Authors and Reviewers of Documents
> Containing YANG Data Models
>Authors: Mohamed Boucadair
> Qin Wu
>Name:draft-ietf-netmod-rfc8407bis-04.txt
>Pages:   76
>Dates:   2023-11-23
> 
> Abstract:
> 
>This memo provides guidelines for authors and reviewers of
>specifications containing YANG modules, including IANA-maintained
>modules.  Recommendations and procedures are defined, which are
>intended to increase interoperability and usability of Network
>Configuration Protocol (NETCONF) and RESTCONF protocol
>implementations that utilize YANG modules.  This document obsoletes
>RFC 8407.
> 
>Also, this document updates RFC 8126 by providing additional
>guidelines for writing the IANA considerations for RFCs that
> specify
>IANA-maintained modules.
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> tracker.ietf.org%2Fdoc%2Fdraft-ietf-netmod-
> rfc8407bis%2F=05%7C01%7Cmohamed.boucadair%40orange.com%7C547adf8f
> a5a4408288ec08dbec2892c5%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C
> 638363431226567474%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjo
> iV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=ctbIDOKn
> %2BCNfAMK%2F4Xr%2FrRMfmhmY3uLMLmk2fENujc8%3D=0
> 
> There is also an HTML version available at:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Farchive%2Fid%2Fdraft-ietf-netmod-rfc8407bis-
> 04.html=05%7C01%7Cmohamed.boucadair%40orange.com%7C547adf8fa5a440
> 8288ec08dbec2892c5%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C638363
> 431226567474%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM
> zIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=vBipgU72pusIP8
> h4x4vGOKpoiauxWbgb60lMIKJV5bg%3D=0
> 
> A diff from the previous version is available at:
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauth
> or-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-netmod-rfc8407bis-
> 04=05%7C01%7Cmohamed.boucadair%40orange.com%7C547adf8fa5a4408288e
> c08dbec2892c5%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63836343122
> 6567474%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC
> JBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=aZaM%2FwCgzBjHPhhib
> Xivg5RXOo4%2B9gNHvbNWuYluWjY%3D=0
> 
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
> 
> 
> ___
> I-D-Announce mailing list
> i-d-annou...@ietf.org
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Fi-d-
> announce=05%7C01%7Cmohamed.boucadair%40orange.com%7C547adf8fa5a44
> 08288ec08dbec2892c5%7C90c7a20af34b40bfbc48b9253b6f5d20%7C0%7C0%7C63836
> 3431226723798%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2lu
> MzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=HADq32A4SHz%2
> BNukgl7FJR0si%2BSRrc6hiP4ZVpYtl864%3D=0


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