| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
My understanding of the YANG github is that anyone can put anything they want under the experimental branch.
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 branch. If there is 802.1 related work that is not covered by an on-going project (PAR) in IEEE 802.1 then the branch
https://github.com/YangModels/yang/tree/master/experimental/ieee/802.1 can be used for that work. However if this is really a vendor specific thing, I would suggest creating a branch under
https://github.com/YangModels/yang/tree/master/vendor to avoid all confusion about who is progressing the work. Just my 2 pence. The community is encouraged to pile on. -scott. From: Bush, Stephen F (GE Global Research, US) <bushsf@xxxxxxxxxxxxxxx>
Scott, 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 development.
Thanks, Stephen F Bush From: Scott Mansfield <scott.mansfield@xxxxxxxxxxxx>
Thank you for your question! In 802.1, the authors of YANG have been following the guidance in
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6087bis/?include_text=1 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 ->
https://github.com/YangModels/yang/blob/master/standard/ieee/802.1/draft/ieee802-dot1q-bridge.yang 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. https://1.ieee802.org/yangsters/ https://1.ieee802.org/yangsters/yangsters-call-information/ Regards, -scott.
4.3.1. Identifier Naming Conventions
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.
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 namespace.
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. From: stds-802-yang@xxxxxxxx <stds-802-yang@xxxxxxxx>
On Behalf Of Bush, Stephen F (GE Global Research, US) 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 subtraction. Thanks, Stephen F Bush To unsubscribe from the STDS-802-YANG list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-YANG&A=1 To unsubscribe from the STDS-802-3-YANG list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-YANG&A=1 |