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
> <https://ietf.webex.com/ietf/j.php?MTID=ma7627a2ae7b770537cff5f5b89293c70>
>
> Tap to join from a mobile device (attendees only)
> +1-650-479-3208,,1710690374##
> <tel:%2B1-650-479-3208,,*01*1710690374%23%23*01*> Call-in toll number
> (US/Canada)
>
> Join by phone
> 1-650-479-3208 Call-in toll number (US/Canada)
> Global call-in numbers
> <https://ietf.webex.com/ietf/globalcallin.php?MTID=m5914d38cfac744cced3593159cb7f971>
>
> Join from a video system or application
> Dial [email protected] <x-msg://17/%20sip:[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]
> <x-msg://17/%20sip:[email protected]>
>
>
> Need help? Go to http://help.webex.com <http://help.webex.com/>
>
>
>
> _______________________________________________
> netmod mailing list
> [email protected] <mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/netmod
> <https://www.ietf.org/mailman/listinfo/netmod>
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
