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 <[email protected]> on behalf of Jan Lindblad
<[email protected]>
Date: Wednesday, February 3, 2021 at 10:06 AM
To: "Sterne, Jason (Nokia - CA/Ottawa)" <[email protected]>
Cc: "[email protected]" <[email protected]>
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)
<[email protected]> 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 [email protected]
You can also dial 173.243.2.68 and enter your meeting number.
Join using Microsoft Lync or Microsoft Skype for Business
Dial [email protected]
Need help? Go to http://help.webex.com
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________ netmod mailing list
[email protected] https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
