Subject: Re: [netmod] FW: New Version Notification for draft-chin-netmod-iana-af-numbers-00.txt

From: "Acee Lindem (acee)" <[email-masked]>
Date: Mon, 22 May 2017 11:31:53 +0000

Chin, 

These are already defined in iana-routing-types …
https://www.ietf.org/id/draft-ietf-rtgwg-routing-types-04.txt

Furthermore, if you propose future YANG models, let's not bring back
MIB-esque camelCase naming conventions. Like baggy jeans and neon, it was
a fad should rest in peace with the 90s.

Thanks,
Acee

On 5/21/17, 10:42 PM, "netmod on behalf of Chin Chen"
<[email-masked] on behalf of [email-masked]> wrote:

>Hi, Kent, Lou and all,
>      I’d like to propose the YANG module for IANA Address family numbers.
>      When draft IETF/IEEE YANG, some modules refer the values in IANA
>address family numbers. That is the motivation for this I-D.
>
>Please help to review the draft. Any comments are appreciated!
>
>BR
>///Chin
>
>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]]
>Sent: Monday, May 22, 2017 10:37 AM
>To: Chin Chen <[email-masked]>
>Subject: New Version Notification for
>draft-chin-netmod-iana-af-numbers-00.txt
>
>
>A new version of I-D, draft-chin-netmod-iana-af-numbers-00.txt
>has been successfully submitted by Chin Chen and posted to the IETF
>repository.
>
>Name:		draft-chin-netmod-iana-af-numbers
>Revision:	00
>Title:		IANA Address Family Numbers Yang Model
>Document date:	2017-05-22
>Group:		Individual Submission
>Pages:		13
>URL:            
>https://www.ietf.org/internet-drafts/draft-chin-netmod-iana-af-numbers-00.
>txt
>Status:         
>https://datatracker.ietf.org/doc/draft-chin-netmod-iana-af-numbers/
>Htmlized:       
>https://tools.ietf.org/html/draft-chin-netmod-iana-af-numbers-00
>Htmlized:       
>https://datatracker.ietf.org/doc/html/draft-chin-netmod-iana-af-numbers-00
>
>
>Abstract:
>   This document defines initial version of the iana-af-numbers YANG
>model.
>
>                  
>        
>
>
>Please note that it may take a couple of minutes from the time of
>submission until the htmlized version and diff are available at
>tools.ietf.org.
>
>The IETF Secretariat
>
>_______________________________________________
>netmod mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/netmod

---

From: Chin Chen <[email-masked]>
Date: Tue, 23 May 2017 03:37:28 +0000

Hi, Acee,
      Thanks for your information.
      Let's use iana-routing-types to define AF.
      Regarding the camelCase, just follow the RFC 7224 iana-if-type YANG. In IANA consideration, there is a statement: "The name of the "identity" is the same as the corresponding enumeration in the IANAifType-MIB." I thought we have kind of consensus on this part of YANG modelling.
      Anyway, if we all have got an agreement on that, I'd like to follow the fad. It's never too late to follow. Thanks.

BR
///Chin

-----Original Message-----
From: Acee Lindem (acee) [mailto:[email-masked]] 
Sent: Monday, May 22, 2017 7:32 PM
To: Chin Chen <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [netmod] FW: New Version Notification for draft-chin-netmod-iana-af-numbers-00.txt

Chin, 

These are already defined in iana-routing-types … https://www.ietf.org/id/draft-ietf-rtgwg-routing-types-04.txt

Furthermore, if you propose future YANG models, let's not bring back MIB-esque camelCase naming conventions. Like baggy jeans and neon, it was a fad should rest in peace with the 90s.

Thanks,
Acee

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 23 May 2017 11:12:32 +0000

On 5/22/17, 11:37 PM, "Chin Chen" <[email-masked]> wrote:

>      Regarding the camelCase, just follow the RFC 7224 iana-if-type
>YANG. In IANA consideration, there is a statement: "The name of the
>"identity" is the same as the corresponding enumeration in the
>IANAifType-MIB." I thought we have kind of consensus on this part of YANG
>modelling.

I think it was a mistake to follow MIB naming conventions in iana-if-type
and I don’t want to see it for address families, e.g., ipV4. We should
follow RFC 6087Bis.

5.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 and the underscore
   character MAY be used if the identifier represents a well-known value
   that uses these characters.

   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.

Thanks,
Acee 

>      Anyway, if we all have got an agreement on that, I'd like to follow
>the fad. It's never too late to follow. Thanks.
>
>BR
>///Chin
>

---

From: Chin Chen <[email-masked]>
Date: Wed, 24 May 2017 03:01:46 +0000

Got it!

Thanks for your sharing.

BR
///Chin

-----Original Message-----
From: Acee Lindem (acee) [mailto:[email-masked]] 
Sent: Tuesday, May 23, 2017 7:13 PM
To: Chin Chen <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [netmod] FW: New Version Notification for draft-chin-netmod-iana-af-numbers-00.txt

On 5/22/17, 11:37 PM, "Chin Chen" <[email-masked]> wrote:

>IANAifType-MIB." I thought we have kind of consensus on this part of 
>YANG modelling.

I think it was a mistake to follow MIB naming conventions in iana-if-type and I don’t want to see it for address families, e.g., ipV4. We should follow RFC 6087Bis.

 

Thanks,
Acee 

>      Anyway, if we all have got an agreement on that, I'd like to 
>follow the fad. It's never too late to follow. Thanks.
>
>BR
>///Chin
>
>MIB-esque camelCase naming conventions. Like baggy jeans and neon, it 
>was a fad should rest in peace with the 90s.
>
>Thanks,
>Acee
>
>
>>https://www.ietf.org/internet-drafts/draft-chin-netmod-iana-af-numbers
>>-00
>>.
>>txt
>>Status:         
>>https://datatracker.ietf.org/doc/html/draft-chin-netmod-iana-af-number
>>s
>>-00
>>
>>
>>Abstract: