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

Re: [802.3_YANG] EPON YANG module (ieee802-ethernet-pon.yang)

Hi Marek, All,

Do you want me to move the Ethernet modules in git?  I'm happy to do that if that helps ...


On 16/03/2017 01:03, Marek Hajduczenia wrote:

Thank you, Mahesh,


In this case, the current published ieee802-ethernet modules should be pushed into the appropriate location. Right now, they are under “experimental/ieee/802.3” and should be under “standard/ieee/802.3” branch down the road. Is that a correct understanding?


I would post then my new model (it is not approved yet) under “standard/ieee/draft” and once it is approved for inclusion, it would be moved to “standard/ieee/802.3” branch. I assume these operations are done by the person in control of the repository


I will create the fork and follow the process you outlined. However, organizationally we (802.3) typically have a more formalized commenting process, and I was wondering how comments from that process and comments on GIT can be merged together into a single commenting & resolution process. Since it has not been attempted before, I was just curious … We can officially resolve comments only at Task Force meetings




From: Mahesh Jethanandani [mailto:mjethanandani@xxxxxxxxx]
Sent: Wednesday, March 15, 2017 8:35 PM
To: Marek Hajduczenia <mxhajduczenia@xxxxxxxxx>
Cc: STDS-802-3-YANG@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_YANG] EPON YANG module (ieee802-ethernet-pon.yang)




If I look at GitHub this is what it says for IEEE YANG models.


IEEE experimental drafts
(1) The "experimental/ieee" branch is intended for IEEE work that does not yet have a Project Authorization Request (PAR).
(2) The "standard/ieee" branch is intended for approved PARs, for drafts as well as published standards.


If I was to follow this logic, you would use standard/ieee/draft to post your model. You had a model in experimental/ieee directory to begin with.


If you create a repository which is a *fork* of this repository, make the changes, push the model to *your* fork of the repository, and generate a “Pull request”, git generates the diffs for the changes you have made and displays it. For an example, see this link:



Reviewers can at that time select any line and provide comment on the code itself. You in response can update the model, provide updated diffs to address those comments. When everyone is satisfied, the pull request can be accepted, and the model merged into GitHub.


Is this what you were looking for?


On Mar 15, 2017, at 10:47 AM, Marek Hajduczenia <mxhajduczenia@xxxxxxxxx> wrote:


Dear colleagues, 


I am in the process of developing the YANG module for EPON, as attached. Before this code is posted on GIT, I wanted to share the module for review purposes. This module imports latest ieee802-ethernet-interface.yang and ieee802-ethernet-interface-legacy.yang modules from GIT (saved on 2017/03/15). 


Note that the syntax is YANG 1.0 compatible. I did not notice any changes in ieee802-ethernet-interface.yang and ieee802-ethernet-interface-legacy.yang as far as 1.0 and 1.1 syntax is concerned (apart from explicit yang-version 1.1 statement). I am not sure whether the modules should be developed going forward for backward compatibility (1.0 compatible) or not (1.1 onwards). Something to bear in mind going forward … 


I would also like to understand *how* we comment on existing modules – given that this is code, it would make most sense to share new proposed updated module and delta from last stable version, or generate delta using some text editors otherwise? I am looking for a suggestion of a commenting process that would work best for people looking at it in detail … 







Mahesh Jethanandani