My understanding of the YANG github is that
anyone can put anything they want under the experimental
YANGsters has been discussing the URN
conventions, to ensure the URN used in the experimental branch
doesn’t look like something that should be in the standards
If there is 802.1 related work that is not
covered by an on-going project (PAR) in IEEE 802.1 then the
can be used for that work. However if this is really a vendor
specific thing, I would suggest creating a branch under
to avoid all confusion about who is progressing the work.
Just my 2 pence. The community is
encouraged to pile on.
Thanks for the quick response.
[ It would have been nice to see the
rationale behind IETF’s choice in this regard. ]
What is the process/policy regarding the
Avnu Alliance to post temporary (TSN-related) modules to the
YANG github? For example, under and Avnu branch?
The rationale is that we cannot wait for
official modules to be released and it provides a common
repository for learning from the modules that we have under
Thank you for your question!
In 802.1, the authors of YANG have been
following the guidance in
which (in section 4.3.1) talks about identifier naming
conventions (pasted below). The first YANG module approved by
802.1 (from the P802.1Qcp) can be found here ->
and follows the guidance from the IETF.
I would like to collect such guidance and
include some examples on the YANGsters site. Naming is only
one of the issues, modularization, augmentation, use of XPath,
and Documentation norms are all reasonable things to have IEEE
oriented guidance on. It is important to have a consistent
look and feel so the IEEE YANG has is cohesive. Other
organizations have different guidelines for the conventions
used in developing YANG modules, that are worth reviewing.
The YANGsters group meets the last
Wednesday of every month to talk about such things.
4.3.1. Identifier Naming
Identifiers SHOULD follow a
consistent naming pattern throughout the
module. Only lower-case
letters, numbers, and dashes SHOULD be used
in identifier names. Upper-case
characters, the period character,
and the underscore character MAY
be used if the identifier represents
a well-known value that uses
these characters. YANG does not permit
any other characters in YANG
Identifiers SHOULD include
complete words and/or well-known acronyms
or abbreviations. Child nodes
within a container or list SHOULD NOT
replicate the parent
identifier. YANG identifiers are hierarchical
and are only meant to be unique
within the the set of sibling nodes
defined in the same module
It is permissible to use common
identifiers such as "name" or "id" in
data definition statements,
especially if these data nodes share a
common data type.
Identifiers SHOULD NOT carry any
special semantics that identify data
modelling properties. Only YANG
statements and YANG extension
statements are designed to
convey machine readable data modelling
properties. For example, naming
an object "config" or "state" does
not change whether it is
configuration data or state data. Only
defined YANG statements or YANG
extension statements can be used to
assign semantics in a machine
readable format in YANG.
What is the official ruling and rationale
on camelCase vs dashes for YANG modules?
IEEE standard managed objects are camelCase
as well as most SNMP MIB object names that I’ve seen.
It would make finding and tracking the
relationship between managed objects and YANG leaves easier.
We also suggest the argument regarding
potential confusion between the use of dashes and arithmetic
Stephen F Bush
To unsubscribe from the STDS-802-YANG list, click the