> Its quirky. Ideally we would have a data model for some technology > X. Often we start with that and a corresponding YANG module (it could > be several YANG modules but it is often exactly one). Over time, there > are extensions of the technology X and thus extensions of the data > model for X, typically encoded in additional YANG modules. Instead of > seeing this as an extension of the X data model, we often treat the > extension as its own universe. Here is an example: > > RFC 9129: YANG Data Model for the OSPF Protocol > RFC 9587: YANG Data Model for OSPFv3 Extended Link State Advertisements (LSAs) > > Perhaps RFC 9587 should have been titled "Extension of the YANG Data > Model for the OSPF Protocol for Extended Link State Advertisements > (LSAs)”.
Agreed, an extension alone doesn’t define a data model. Regarding this discussion: 1) The “Terminology" sections in RFC 6020 and RFC 7950 only define the terms “data model” and “module”. 2) The body of RFC 6020 and RFC 7950 contain “YANG module” in numerous locations. 3) The body RFC 6020 contains “YANG data model” once, and the body of RFC 7950 contains it just twice. 4) It would be good if Med’s proposed update [1] could reflect points 1-3 more accurately. 5) The reason why “module” is most always prefixed with “YANG” is because “module” alone is unclear. I strongly support stating that “module” SHOULD always be prefixed with “YANG”. 6) Despite the RFCs using “YANG data model” in a couple places, I personally dislike its use, because it seems like slang for “A data model described by YANG”. That said, “YANG data model” has been used by many RFCs since, e.g., [2], and thus likely cemented into our venacular now. 7) I disagree with the blanket statement in [1] “(the) YANG data model term should be used in the title, abstract, and when the overall design is described.” At a minimum it should be qualifed, see (9) below. 8) Clarifying (7), a YANG module does NOT define a “data model” if it only contains the following statements: typedef, identity, rpc, notification, augment, extension, feature, and deviation. In such cases, document titles should be more explicit. For instance, "YANG Data Types for X”. 9) It is a grey area as to if a module containing only “grouping” statements defines a "data model”, but it seems okay given that the groupings are intended to be instantiated in datastores. Still, I think it better for document titles to be more explicit. For instance, “YANG Groupings for X”. 10) Corollary to (8), a YANG module defines a “data model” only if it defines data nodes to be instantiated in a datastore. The term “data node” is defined in RFC 6020 and 7950. The term “datastore” is defined in RFC 8342. 11) RPCs and Notifications do not define data nodes to be instantiated in a datastore. [1] https://author-tools.ietf.org/api/iddiff?url_1=https://netmod-wg.github.io/rfc8407bis/draft-ietf-netmod-rfc8407bis.txt&url_2=https://netmod-wg.github.io/rfc8407bis/model-vs-module/draft-ietf-netmod-rfc8407bis.txt [2] https://en.wikipedia.org/wiki/YANG#Standards-track_data_models Kent
_______________________________________________ netmod mailing list -- netmod@ietf.org To unsubscribe send an email to netmod-le...@ietf.org
