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

RE: camelCase vs dashes

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 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)
Sent: Tuesday, July 24, 2018 8:15 AM
To: STDS-802-YANG@xxxxxxxxxxxxxxxxx
Subject: camelCase vs dashes


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.



Stephen F Bush


To unsubscribe from the STDS-802-YANG list, click the following link:

To unsubscribe from the STDS-802-YANG list, click the following link: