On 19. 8. 2025 9:51, Andy Bierman wrote:
On Mon, Aug 18, 2025 at 11:02 PM Michal Vasko <mvasko=40cesnet...@dmarc.ietf.org> wrote:Hi Andy, I do not fully agree with your interpretation but the situation is generally more complicated, I think. As for the operational datastore and its validity, the NMDA RFC <https://www.rfc-editor.org/rfc/rfc8342.html#page-15> does not say it does not have to be valid or that it is not validated. It only mentions that some constraints (`mandatory` among them) can be temporarily violated. I believe that is perhaps subtle but important difference. However, none of this is even relevant for the issues discussed. Libyang (or `yanglint`) has no actual concept of datastores, which is left for applications linking this library. But it should support all the common use-cases including this special operational datastore validation when semantic constraints are not validated (but it seems this is not available in `yanglint`, only in the library). Finally, I think the main question is for Reshad and what exactly was he trying to check. The command he used is for full validation of both configuration and state data and that was performed correctly, I think.A mandatory database data definition is defined as a node that a client must provide for the database to be valid. The server is not required to provide a value.What is the exact guideline that yanglint is enforcing?This section does not apply, as it only refers to client-provided values, which are never config=false nodes.
I may definitely be biased and affected by the specific implementation of all these principles in our software but the roles of client and server do not have to always be that clear-cut. But to answer you, I suppose the specific command being discussed does not have a defined use-case and is something now obsolete and present in `yanglint` since the beginning of its development lots of years back. What we used it for was strictly YANG-level validation of both configuration and state data when there have been no NMDA specified yet. I will make a note of this and replace the vague `data` validation for something better, maybe `operational` that will not check the semantic constraints.
Michal
Regards, Michal Andy On 18. 8. 2025 20:11, Andy Bierman wrote:On Fri, Aug 15, 2025 at 1:10 PM Andy Bierman <a...@yumaworks.com> wrote: On Fri, Aug 15, 2025 at 12:38 PM Reshad Rahman <reshad=40yahoo....@dmarc.ietf.org> wrote: Hi, Using yanglint, when I try to validate the example in Appendix C of RFC8525, I get the following error: > data /home/xyz/YANG/example-yang-library.xml libyang[0]: Mandatory node "module-set-id" instance does not exist. (path: Data location "/ietf-yang-library:modules-state".) YANGLINT[E]: Failed to parse input data file "/home/xyz/YANG/example-yang-library.xml". > My understanding is that yanglint is behaving correctly (no presence-stmt in the modules-state container), but would like confirmation. If yes, is that worth an errata on RFC8525? This may violate a guideline in RFC8407bis, but nothing in RFC 7950. I do not think yanglint is correct. This warning should only be for config=true data nodes. https://www.ietf.org/archive/id/draft-ietf-netmod-rfc8407bis-28.html#section-4.10 The guideline is for top-level "database" data nodes. The term should really be "datastore", and config=false nodes are only part of <operational>, which is not subject to validation. Andy In practice, the server creates its own config=false data at boot-time, so the constraint is not actually violated. Mandatory=true for config=false is not validated on the server. It means the node is expected in a response from the server requesting this data. It is validated by the client. Regards, Reshad. Andy container modules-state { config false; status deprecated; description "Contains YANG module monitoring information."; leaf module-set-id { type string; mandatory true; status deprecated; description "Contains a server-specific identifier representing the current set of modules and submodules. The server MUST change the value of this leaf if the information represented by the 'module' list instances has changed."; } uses module-list { status deprecated; } } _______________________________________________ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org _______________________________________________ netmod mailing list --netmod@ietf.org To unsubscribe send an email tonetmod-le...@ietf.org_______________________________________________ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org _______________________________________________ netmod mailing list --netmod@ietf.org To unsubscribe send an email tonetmod-le...@ietf.org
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
