| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
I fully agree with you that IEEE, or at the least 802, should have a consistent look and feel. Early on in the P802.3.2 project I pushed the idea of publishing a guidelines document but there was no support
for the idea at that time. I know BBF had a YANG Best Current Practices web page (not sure if it is public) that is quite
thorough. Maybe it’s time 802 published something? Best Regards Duane From: stds-802-yang@xxxxxxxx [mailto:stds-802-yang@xxxxxxxx]
On Behalf Of Scott Mansfield 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-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 |