ietf-ccamp-wg / ietf-ccamp-layer0-types-ext-RFC9093-bis

CCAMP WG repository for ietf-layer0-types-ext
3 stars 3 forks source link

ietf-layer0-types-ext #3

Closed dhruvdhody closed 1 year ago

dhruvdhody commented 4 years ago

It would be wise to check with Yang experts on what is the best way forward here with ietf-layer0-types-ext.

Is it the current approach of defining a new yang model with a new name "ietf-layer0-types-ext" correct way? Can a revision of the etf-layer0-types yang module can be done using the work related to 'semver' in netmod? Will we do a bis document?

IMHO it is better to get this confirmed upfront.

italobusi commented 4 years ago

If I understand well this mail, I assume some "high level" checks have been done:

https://mailarchive.ietf.org/arch/msg/ccamp/djdYbOuQ87a9QR5JwHCar2Wc-9w/

My understanding is that the existing YANG tools are not yet ready to support the 'semver' approach under definition in Netmod WG:

https://etherpad.ietf.org:9009/p/notes-ietf-107-netmod

Itallo busi - is the solution already supported by YANG tools? Can other WG use this solution in the YANG modules they develop? Robert - the schema solution may be already supported by pyang while packages and versioning is not yet supported

dhruvdhody commented 4 years ago

From the chair's email:

At a later stage transponders can be added to a different module or we can create an updated version of the L0 types document. This is a common practice (e.g. RFC 6021 -> 6991 -> 6991bis) and a lot of work is going on in NETMOD to describe how to evolve modules. (thanks Rob for the pointer).

The example here uses the bis approach (and obsolete the old model), maybe that what we mean with -ext for now. This might turn to bis once we have an RFC?

I think maybe asking a direct question to Rob could be useful, rather than an indirect question about tools (and pyang). Just a thought!

sergiobelotti commented 1 year ago

The issue is superseded by events and the new RFC9093-bis draft and we can consider the issue as closed.