Hello YANG doctors/experts, I'm hoping to get some opinion on the best ways to coordinate development of YANG models among multiple standards organizations (e.g., IETF, IEEE, ITU-T, SMPTE<https://www.smpte.org/>).
As a reference for my questions, let's say that we have two standards organizations, one that specifies a "base" standard, and another that specifies a "profile" of that base standard. The base standard has a core set of required specifications, and a large set of optional specifications. The profile standard uses the base standard as its foundation, and it a) selects a subset of optional specifications from the base that are required for the profile, and b) adds its own unique specifications (some optional, some required). The engineers in each standards organization work on their documents independently. The profile standard uses the latest published revision of the base standard, but otherwise there isn't much explicit coordination. In the context of YANG, the base standard organization will have its own timeline for YANG module revisions, and the profile standard organization will have an independent timeline for YANG module revisions. Each YANG module revision will align with a revision of the organization's published specification document (e.g., IETF RFC, IEEE standard in PDF). The preceding description can apply to almost anything, but a specific example might help to understand. An example of a base standard is IEEE 1588 (Precision Time Protocol), which has a YANG model for its 2008 revision (RFC 8575). There are a large number of standards organizations that specify profiles of IEEE 1588, including ITU-T, IEEE (e.g. IEEE 802.1AS, IEEE C37.238), and SMPTE. Many of these profile organizations are currently planning YANG development for their 1588 profiles. Question 1: What are the best mechanisms in the YANG data modeling language to use for a profile standard? My assumption is that "import" and "augment" provide many benefits. The YANG modules for the profile can "import" the YANG of the base standard. This provides the core specifications from the base, as well as the base features that the profile is using (item a) above). The import also includes some nodes that the profile is not using, but since those nodes are optional in the core standard, they will not be marked as "mandatory", so the profile implementers can ignore them as desired. As for the new specifications in the profile (item b) above), "augment" can be used in the profile's YANG to add new nodes to the base tree. As an alternative, the profile YANG could copy the contents of the base YANG into its own module, and edit from there (without import). The disadvantage of that technique is that the base nodes in the profile's YANG are more likely to diverge from the base standard's YANG over time. In addition to coordination problems between standards organizations, that can create challenges for implementers that are trying to support both YANG models. Maybe there are other alternatives? Maybe there are other aspects of the language that would help? Question 2: Assuming the import/augment technique is used, how do standards best handle a node that migrates from profile YANG to base YANG? As an example, assume the base standard has YANG for 2021, and the profile standard has YANG for 2022 (which imports/augments base 2021). The 2022 profile YANG has an augment that adds a "performance-monitoring" container to the base tree. Later in 2023 the standards organization for the base decides that "performance-monitoring" is a great feature, so the base incorporates "performance-monitoring" into the base standard. The base YANG for 2023 is published with "performance-monitoring" exactly as it is in the profile's 2022 YANG (same location, exact same container and leaves, etc). In 2024 the profile's standards organization is working on the profile YANG, so the profile's revised YANG imports the base YANG from 2023. What should the 2024 profile YANG do with the profile's "performance-monitoring"? Is it sufficient to mark "performance-monitoring" with obsolete status in the 2024 profile YANG, so that "performance-monitoring" in the base 2023 YANG replaces it? As an alternative, in 2023 should the the base standard rename the container to avoid all collisions/confusion, such as "performance-monitoring-v2"? Thanks so much, Rodney Cummings
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
