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

Re: camelCase vs dashes



CC Einar, one of the owners of the Github YANG Models project.

Thanks,
Rob


On 24/07/2018 15:14, Scott Mansfield wrote:

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>
Sent: Tuesday, July 24, 2018 8:51 AM
To: Scott Mansfield <scott.mansfield@xxxxxxxxxxxx>; STDS-802-YANG@xxxxxxxxxxxxxxxxx; STDS-802-3-YANG@xxxxxxxxxxxxxxxxx
Subject: RE: camelCase vs dashes

 

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>
Sent: Tuesday, July 24, 2018 8:29 AM
To: Bush, Stephen F (GE Global Research, US) <bushsf@xxxxxxxxxxxxxxx>; STDS-802-YANG@xxxxxxxxxxxxxxxxx; STDS-802-3-YANG@xxxxxxxxxxxxxxxxx
Subject: EXT: RE: camelCase vs dashes

 

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)
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.

 

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-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-YANG list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-YANG&A=1