Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: YANG in IEEE discussion

I use yang2dsdl.  I will ask my Ericsson YANG people to see if they have anything else better.





From: Bush, Stephen F (GE Global Research, US) <bushsf@xxxxxxxxxxxxxxx>
Sent: Wednesday, September 19, 2018 8:59 AM
To: Scott Mansfield <scott.mansfield@xxxxxxxxxxxx>; STDS-802-YANG@xxxxxxxxxxxxxxxxx; STDS-802-3-YANG@xxxxxxxxxxxxxxxxx
Subject: RE: YANG in IEEE discussion




What tools are folks using to validate YANG instance data? I’m using yang2dsdl, but that tool seems to give minimalistic error messages most of the time to the point of being painful to use with complex models.


Are there better publicly available tools for this?


This is important to ensure that YANG data is compliant with the IEEE models.



Stephen F Bush


From: stds-802-yang@xxxxxxxx <stds-802-yang@xxxxxxxx> On Behalf Of Scott Mansfield
Sent: Wednesday, September 12, 2018 4:21 AM
To: STDS-802-YANG@xxxxxxxxxxxxxxxxx; STDS-802-3-YANG@xxxxxxxxxxxxxxxxx
Subject: EXT: YANG in IEEE discussion


There were two presentations given at the IEEE 802.1 interim meeting in Oslo with considerations related to YANG’s impact on the IEEE Standards process.



Related background for the discussions can be found here:



There was a good deal of discussion during the meeting, so I am trying to put some structure to aid coming to closure on how we can utilize YANG and YANG tooling without impacting the IEEE Standards Process.


For those in Oslo – I suggest we have a face-to-face breakout to clarify the discussion paper (draft below) and then schedule a few eMeetings to discuss (if this runs afoul of the IEEE process, we can use the already scheduled YANGsters calls for the discussion)




YANG Process Discussion Paper


There are several decisions that need to be made related to YANG development.  The first section of this paper will provide background on the impact of YANG on the IEEE Standards Process.  The next section provides an overview of utilizing a YANG repository in conjunction with the IEEE Standard Process.  The third section provides considerations related to the text that needs to be included related to licensing.  Then considerations for distributed development and thoughts about the repository are provided. Finally, a set of actions is listed.


IEEE Standards Process impact

The primary requirement is that including YANG modules in an IEEE Standard will follow the existing IEEE Standards Process.  There are no changes to process. The collection of YANG modules in a repository is meant to speed development, but not change how an IEEE document is progressed through the standards process.  The YANG modules (just like MIB modules or any other technical contribution) are an integral clause in the draft standard.  Regardless of how YANG is developed and stored, the IEEE Standards Process is followed to publish IEEE Standard that includes the YANG modules.


YANG Repository

To make the development of YANG easier for distributed teams, the use of a repository is suggested.  The IETF has a capability known as the YANG Catalog, which provides a GitHub-based repository along with meta-data that make the ability to search and validate the modules in an automated way.

For discussion see which provides a suggested structure and starts the discussion on the license and documentation requirements that need to part of the repository.


Licensing Details

It is key to ensure the IEEE License information is clearly explained.  Text has been provided by the IEEE lawyers that must be provided verbatim.  Explanatory text and text that provides pointers to the IEEE license information need to be put in every IEEE-related branch and (importantly) in the top-level YANG branch that indicates the license attribution per branch.  The license information should be in a separate license file and the readme files should point to the license file where necessary.  It is also important to ensure any file uploaded to the repository is considered either an IEEE Contribution or (at least) something that carries the IEEE Copyright.  See the section below on the difference between draft YANG and YANG that is included in a published IEEE Standard.


Multi-developer considerations

A decision on how YANG development is coordinated is important.  Like with MIBs, there are use-cases where multiple .1Q updates are inflight that are modifying the same YANG modules.  A guideline to follow is to make the YANG modules easier to use for the end-user.  While convenience of the editor is important, it is secondary to making the end-product easy to use.


Repository Considerations

The current suggested structure that is based on other SDOs in the GitHub has an “experimental” branch, a “draft” branch, and a “published” branch.  Any file uploaded under either “experimental” or “draft” is considered an IEEE Contribution.  Once an IEEE Standard (that includes YANG) is published, the related YANG modules are removed from the “draft” branch and the files from the IEEE Standard are extracted and placed in the published branch.  It is important to note that the definitive source for the YANG is the IEEE Standard, not the repository (which is only provided as a convenience to aid industry adoption).


An alternative is to only use the YANG Catalog’s repository for published YANG files.  But this would limit the visibility of the inflight IEEE YANG work.



  • Review the multi-developer issues related to multiple projects modifying the same YANG files
  • Review the IEEE Standards Process and discuss how (and when) to delete draft YANG and populate the published branch
  • Repository structure discussion
  • License file discussion
  • Readme file discussion
  • Discuss how to socialize the recommendations outside of IEEE 802.
  • Discuss Repository coordination (guidelines for naming, versions/revisions, etc.)





To unsubscribe from the STDS-802-YANG list, click the following link:

To unsubscribe from the STDS-802-YANG list, click the following link: