Tried pyang and yanglint.

pyang warns about filename: should consist of "[_A-Za-z][._\-A-Za-z0-9]*" (see 
warning below).  

yanglint warns about mismatch between filename and module name also.

Basically, both accept the characters we want to allow, they treat @ as 
delimiter for the module-name and don’t recognize # as such (as expected).

 

Regards,

Reshad 

$ pyang test#1.0.0.yang  
test#1.0.0.yang:1: warning: filename "test#1.0.0.yang" suggests invalid module 
name "test#1.0.0", should match "[_A-Za-z][._\-A-Za-z0-9]*"

$ pyang test#{1\,0\,\0}.yang 
test#{1,0,0}.yang:1: warning: filename "test#{1,0,0}.yang" suggests invalid 
module name "test#{1,0,0}", should match "[_A-Za-z][._\-A-Za-z0-9]*"

$ pyang test#{1.0.0}.yang    
test#{1.0.0}.yang:1: warning: filename "test#{1.0.0}.yang" suggests invalid 
module name "test#{1.0.0}", should match "[_A-Za-z][._\-A-Za-z0-9]*"

$ pyang test#1.0.0+.yang
test#1.0.0+.yang:1: warning: filename "test#1.0.0+.yang" suggests invalid 
module name "test#1.0.0+", should match "[_A-Za-z][._\-A-Za-z0-9]*"

 

$ yanglint test#1.0.0.yang        
libyang warn: File name "test#1.0.0.yang" does not match module name "test".

$ yanglint test#{1\,0\,0}.yang  
libyang warn: File name "test#{1,0,0}.yang" does not match module name "test".

$ yanglint test#{1.0.0}.yang       
libyang warn: File name "test#{1.0.0}.yang" does not match module name "test".

$ yanglint test#1.0.0+.yang  
libyang warn: File name "test#1.0.0+.yang" does not match module name "test".

 

Regards,

Reshad.

 

From: netmod <netmod-boun...@ietf.org> on behalf of Jan Lindblad 
<j...@tail-f.com>
Date: Wednesday, February 3, 2021 at 10:06 AM
To: "Sterne, Jason (Nokia - CA/Ottawa)" <jason.ste...@nokia.com>
Cc: "netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] YANG Versioning Weekly Call Minutes - 2021-02-02

 

Tried out confdc/yanger behavior with filenames containing quirky characters. 
In order to make this somewhat realistic, I used a Darwin/MacOS (utf-8 aware) 
command line invoked with "double quoted" filenames, and a Makefile to do the 
building.

 

Category 1: Characters that just work

    ascii-alphabetic numerals period comma _ + - ~ @ # % ^ : { } [ ]

    Anything behind the @ is not considered part of the module name

 

Category 2: Characters that need to be specifically \ escaped in the shell, but 
then work

    ( ) ; & *

 

Category 3: Characters that need to be doubly escaped or similar, but then work

    backtick space singlequote doublequote \ | $ ! ? * < > =

 

Category 4: Characters that do not work

    forwardtick slash

    non-ascii alphabetical (e.g. swedish, german, japanese characters)

 

Best Regards,

/jan

 

 

 

 



On 2 Feb 2021, at 23:46, Sterne, Jason (Nokia - CA/Ottawa) 
<jason.ste...@nokia.com> wrote:

 

YANG Versioning Weekly Call Minutes - 2021-02-02

 

Agenda bashing:

- quick recap on 4 topics

- status of topics from previous interim

- updates needed to yang versioning and yang semver drafts

- whitespace

- continue through Github issues

 

Deadline on draft sunmissions is 3 weeks from now.  Try to get first cut in 2 
weeks max.

 

Summary of where we left off yesterday on the Virtual Interim topics:

 

T3:

- get feedback from WG on acceptable chars (especially highlight new ones)

- no semicolon

- 2 sets of files is acceptable, but systems will work with one in general

- try with a few tools ( Reshad to try pyang and yanglint, Jan try confd which 
includes yanger,

- someone try Yuma?  (or ask Andy?)

- try google tools ?  maybe not worth it

- Reshad to update draft with weekly call group & send updated snippets to WG

 

T2:

- Lou asked to post comments on list. People happy with direction being 
proposed.

- try drafting text to indicate when IANA owns a module vs a WG

- Rob to propose text to WG

 

T1:

- nobody objected to defining NBC rules for config false

- mix of opinions still?

- deleting a leaf is NBC (to stay in sync with 7950 on this point, and likely 
more common expectations)

- decreasing value space on optional leafs is BC (but decreasing it on 
mandatory leafs is NBC ?)

- this should also be considered in YANG NEXT

- rules we define need to separate optional vs mandatory elements

- Balasz to propose specific text to weekly call group first

 

T4:

- mostly aligned with slides

- not recommended having gaps or removing history, but we won't disallow it

- Joe to propose text to WG 

 

First interim topics:

(A) import by revision or derived

- not using revision-or-derived-compatible

- impact of changing import statements: did we post back to the WG?  Said it 
was BC (but you can mark it NBC if you wanted to)

- Reshad the draft with the results

 

(B) Whitespace

 

>From the first virtual interim:

 

   JS: we need to decide if the version represents 

   the file or the underlying YANG statements

   JC: no matter what we do, we’ll need YANG-aware 

   tooling (to go to the next level of analysis to 

   see if what actually changed in the API)

   JL: time is almost up. Summary: no clear consensus

 

- got rid of checksums from the scope, but whitespace topic was still open

- you are *allowed* to bump the (editorial) version if you want to, but you 
don't *have* to for insignificant whitespace changes

- checksums in the future may have to be for a URL (i.e. there is not a 
checksum associated with version 3.2.2 of module-xxx, there is only a checksum 
associated with url:\xxx\yyy\foo.yang)

- comments? are they versioned? They can be more important than insig whitespace

- remember /n/r vs /n in unix vs dos

- new IETF modules and updating IETF modules will have different revision 
labels during development vs the finally published RFC (so it doesn't matter 
what we decide here)

- note: tools refer to line numbers in yang files.

- change in API hasn't changed, but the file describing the API changed

- JS: we should focus on this issue and not let it go quiet until we come to a 
decision

 

 

NETMOD Working Group changed the Webex meeting information.
 
When it's time, join the Webex meeting here.
 
Meeting number (access code): 171 069 0374
Meeting password: semver?
 

 
Occurs every Tuesday effective Tuesday, September 1, 2020 until Tuesday, August 
24, 2021 from 9:00 AM to 10:00 AM, (UTC-04:00) Eastern Time (US & Canada)
9:00 am  |  (UTC-04:00) Eastern Time (US & Canada)  |  1 hr
 
 

Join meeting
 

 
Tap to join from a mobile device (attendees only)
+1-650-479-3208,,1710690374## Call-in toll number (US/Canada)
 
 

Join by phone
1-650-479-3208 Call-in toll number (US/Canada)
Global call-in numbers
 
 

Join from a video system or application
Dial 1710690...@ietf.webex.com
You can also dial 173.243.2.68 and enter your meeting number.
 
 

Join using Microsoft Lync or Microsoft Skype for Business
Dial 1710690374.i...@lync.webex.com
 

 

 
Need help? Go to http://help.webex.com
 
 

 

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

 

_______________________________________________ netmod mailing list 
netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod 

_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to