Subject: [yang-doctors] Mixed naming conventions

From: Balazs Lengyel <[email-masked]>
Date: Mon, 3 Sep 2018 17:17:01 +0200

Hello,

I was looking at the YANG module
https://www.yangcatalog.org/yang-search/module_details.php?module=ietf-dmm-threegpp

I noticed that it is partly following the 3GPP naming style using 
camelCase instead of the usual dashed lowercase identifiers.  They 
probably just lifted these names from the 3gpp specs.

Is this a good thing to do? Is this a preferred way?

regards Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: [email-masked]

---

From: "Reshad Rahman (rrahman)" <[email-masked]>
Date: Mon, 3 Sep 2018 19:23:09 +0000

From https://www.ietf.org/id/draft-ietf-netmod-rfc6087bis-20.txt

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.

On 2018-09-03, 11:17 AM, "yang-doctors on behalf of Balazs Lengyel" <[email-masked] on behalf of [email-masked]> wrote:

    Hello,

    
    
    regards Balazs

    _______________________________________________
    yang-doctors mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/yang-doctors

---

From: Ebben Aries <[email-masked]>
Date: Mon, 3 Sep 2018 14:07:19 -0600

I've seen this in other SDO/initiative models quite frequently but also
within published IETF models (such as RFC5277 w/ stopTime and startTime)

As pointed out in the section below, this is a SHOULD but the mix and
match that we've seen to date is not good for consistency sake

On Sep 03 19:23 PM, Reshad Rahman (rrahman) wrote:
> From https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_id_draft-2Dietf-2Dnetmod-2Drfc6087bis-2D20.txt&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=GIehbDpQlo31lSi6WbnEkA&m=83tXynvUuAMBssZZmAoIQxuQH3pn-H_0EgUp3Rgefjc&s=lbyLKxetx_jnpO5mrKxVyx6RzwpKwuyAs3W5xkQGWVY&e=
> 
>     https://urldefense.proofpoint.com/v2/url?u=https-3A__www.yangcatalog.org_yang-2Dsearch_module-5Fdetails.php-3Fmodule-3Dietf-2Ddmm-2Dthreegpp&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=GIehbDpQlo31lSi6WbnEkA&m=83tXynvUuAMBssZZmAoIQxuQH3pn-H_0EgUp3Rgefjc&s=efSXVx9kInJhf-c_Sa8vMApTKIHOCQnd9EAL_7CLuMQ&e=
>     
>     https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_yang-2Ddoctors&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=GIehbDpQlo31lSi6WbnEkA&m=83tXynvUuAMBssZZmAoIQxuQH3pn-H_0EgUp3Rgefjc&s=KGU0UtCj27gWFwopMi8gF1Qh7aQ7oQUuy1ADr2C-VBc&e=
>     
> 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_yang-2Ddoctors&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=GIehbDpQlo31lSi6WbnEkA&m=83tXynvUuAMBssZZmAoIQxuQH3pn-H_0EgUp3Rgefjc&s=KGU0UtCj27gWFwopMi8gF1Qh7aQ7oQUuy1ADr2C-VBc&e=

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 03 Sep 2018 22:21:19 +0200 (CEST)

> within published IETF models (such as RFC5277 w/ stopTime and startTime)

5277 is pre-YANG.  The YANG model for subscriptions uses start-time
and stop-time (in draft-ietf-netconf-subscribed-notifications).

> match that we've seen to date is not good for consistency sake

I agree.  The 6087bis says that hyphens SHOULD be used but other
styles MAY be used when it is well-known.  In this case they should
probably stick to hyphens; people probably understand what
ipv4-local-address means.

/martin

---

From: Ebben Aries <[email-masked]>
Date: Tue, 4 Sep 2018 09:18:13 -0600

> and stop-time (in draft-ietf-netconf-subscribed-notifications).

While I don't believe there is an officially "published" module for
5277, the demand for support still comes up which I've seen result in
modules built from 5277 specifications

https://www.yangcatalog.org/yang-search/show_node.php?module=notifications&path=%2FncEvent%3Acreate-subscription&revision=2013-03-15
https://github.com/YangModels/yang/blob/master/vendor/cisco/xr/651/notifications.yang#L56

But I suppose that falls into it's own unique bucket and possibly not
the best example atm

More frequent in other SDO produced models...

> > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_yang-2Ddoctors&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=GIehbDpQlo31lSi6WbnEkA&m=_-n1ntKPunZZ-UTyuLtVn5j8udeDj5_YNjIUYyD5BJo&s=eGJogG4vuWbqy54SPfwW6b6TaaI2P2I1cD4keT42Unk&e=

---

From: Andy Bierman <[email-masked]>
Date: Tue, 4 Sep 2018 11:29:12 -0700

On Tue, Sep 4, 2018 at 8:18 AM, Ebben Aries <[email-masked]> wrote:

> https://www.yangcatalog.org/yang-search/show_node.php?
> module=notifications&path=%2FncEvent%3Acreate-
> subscription&revision=2013-03-15

This module has been on Netconf Central for a long time:
http://www.netconfcentral.org/modulereport/notifications

IMO naming conventions are not very important, and rather subjective.
In this case, consistency with the origin document was considered more
important.

I have no problem parsing between some-term or some_term or someTerm.
Arguing which one is best is not useful.

Andy

> > > > From https://urldefense.proofpoint.com/v2/url?u=https-3A__www.
> ietf.org_id_draft-2Dietf-2Dnetmod-2Drfc6087bis-2D20.txt&d=DwIGaQ&c=
> HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=GIehbDpQlo31lSi6WbnEkA&m=
> 83tXynvUuAMBssZZmAoIQxuQH3pn-H_0EgUp3Rgefjc&s=lbyLKxetx_
> jnpO5mrKxVyx6RzwpKwuyAs3W5xkQGWVY&e=
> > > >
> > > > On 2018-09-03, 11:17 AM, "yang-doctors on behalf of Balazs Lengyel"
> <[email-masked] on behalf of [email-masked]>
> wrote:
> > > >
> > > >     Hello,
> > > >
> > > >     https://urldefense.proofpoint.com/v2/url?u=https-3A__www.
> yangcatalog.org_yang-2Dsearch_module-5Fdetails.php-3Fmodule-
> 3Dietf-2Ddmm-2Dthreegpp&d=DwIGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-
> ndb3voDTXcWzoCI&r=GIehbDpQlo31lSi6WbnEkA&m=83tXynvUuAMBssZZmAoIQxuQH3pn-
> H_0EgUp3Rgefjc&s=efSXVx9kInJhf-c_Sa8vMApTKIHOCQnd9EAL_7CLuMQ&e=
> > > >
> > > >     https://urldefense.proofpoint.com/v2/url?u=https-3A__www.
> ietf.org_mailman_listinfo_yang-2Ddoctors&d=DwIGaQ&c=
> HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=GIehbDpQlo31lSi6WbnEkA&m=
> 83tXynvUuAMBssZZmAoIQxuQH3pn-H_0EgUp3Rgefjc&s=
> KGU0UtCj27gWFwopMi8gF1Qh7aQ7oQUuy1ADr2C-VBc&e=
> > > >
> > > >
> > > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.
> ietf.org_mailman_listinfo_yang-2Ddoctors&d=DwIGaQ&c=
> HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=GIehbDpQlo31lSi6WbnEkA&m=
> 83tXynvUuAMBssZZmAoIQxuQH3pn-H_0EgUp3Rgefjc&s=
> KGU0UtCj27gWFwopMi8gF1Qh7aQ7oQUuy1ADr2C-VBc&e=
> > >
> > > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.
> ietf.org_mailman_listinfo_yang-2Ddoctors&d=DwIGaQ&c=
> HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=GIehbDpQlo31lSi6WbnEkA&m=_-
> n1ntKPunZZ-UTyuLtVn5j8udeDj5_YNjIUYyD5BJo&s=eGJogG4vuWbqy54SPfwW6b6TaaI2P2
> I1cD4keT42Unk&e=
>