Hi David,
That is good point and we as a community needs to figure it out - the API
version (YANG revision) was included into package name to signify
the change of the API contract - this versioning could be also achieved
with package versions in OSGI.

Without including revision in the package names the code could be easily
migrated to new version of YANG module if the changes we're backward
compatible (and should be if the author of module updates the module
with section 10 of RFC6020 in mind).

The inclusion of revision also allows for components, which could use
multiple revisions of API contracts simultaneosly, but I think
this will be very rare.

Also other is should we generate package names
from YANG module name (which is easily readable, but there will be chance
of conflicts) or from XML namespace which identifies module.

Tony Tkacik

---