Subject: [Taps] YANG updates

From: "Holland, Jake" <[email-masked]>
Date: Mon, 23 Sep 2019 17:16:44 +0000

Hi taps,

It turns out sometimes forcing functions can do some work even
when the trigger is cancelled.  I have a few minor yang updates,
plus a question (in #4):

1. Tooling update

I cleaned up the make process for the yang module draft a bit, while
still keeping the structure of importing external files + automated
validation.

This version only requires pyang and rsync to build if you're not
validating, and adds in a requirement for the yanglint executable
(included with libyang), but only if you use 'make yanglint' or
set "VALIDATE_YANG=1" as an environment variable.  In return, it
removes my extra c file that linked to libyang.

It also no longer auto-builds its dependencies, it just complains
if you don't have the requirements installed.

The current Makefile points to my i-d-template fork that has these
changes, since otherwise it won't build a proper draft:
https://github.com/GrumpyOldTroll/ietf-taps-yang/blob/master/Makefile#L11

I've sent a pull request to merge the cleanup upstream:
https://github.com/martinthomson/i-d-template/pull/193

As far as I know, nobody has reviewed it, so it could use some
sanity-checking and probably some feedback.  Good chance some changes
would be in order, if only I knew what they were.

2. Theresa made a pull request to make the identity and algorithm
in the security container optional:
https://github.com/GrumpyOldTroll/ietf-taps-yang/commit/265e3a0219e115a181618915a73b893409ef5a29

It sounded plausible to me, so I pulled it.  (But not before checking
whether 'mandatory false' should be added also, and finding that I get
warnings from yanglint if I try making it explicit, so it's better as
written.)  Thanks Theresa!

3. I think I also addressed one of the 4 issues Theresa opened after
Montreal, by adding a constraint that there must be at least 1 remote
or local endpoint in a preconnection and adding a negative test for it:
https://github.com/GrumpyOldTroll/ietf-taps-yang/commit/886b5ee1e4a37c59c74c9b60b1dfbdd7097d156f

And thanks for the review and for opening the issues, Theresa!

4. I think in Montreal, Tommy suggested to me offline that I transfer the
ietf-taps-yang repo to https://github.com/ietf-tapswg.

I'll go ahead and do that if I get a couple of "yes, go ahead"s, but I
thought I'd check first, because right now I think I don't have consensus,
so much as a vague memory of a mumbled suggestion that I'm only 70%
certain I understood correctly.  I think it makes sense, but I don't want
to surprise anyone or clutter things up if people believe it needs work
before going there.

So does it sound right to just transfer the repo now?

Best regards,
Jake

---

From: Theresa Enghardt <[email-masked]>
Date: Wed, 25 Sep 2019 17:06:35 +0200

Hi Jake,

thanks for the updates!

One question and an one answer inline:

> removes my extra c file that linked to libyang.

Trying to make sure I understand this correctly, as I'm not too familiar
with the tooling yet:

By default, when I build the draft, it still reads the .yang and then
dumps the XML and the tree structure, but it does not validate the
model, right?

To test, I changed an identifier in the model, and the tool did complain
about an unknown identifier -- but it still built the draft as .txt and
.html. That's the intended behavior, right?

And to validate the model means that it won't build if there's an error
in the model?

As I have to use "make yanglint" to validate, does that mean yanglint is
the same as validating? I thought "linting" was something else.

"make" works for me, but "make yanglint" doesn't. It complains that
there's no target called "yanglint". I'm probably missing something
really obvious here... but could you give me a pointer, please?

> […]

I'd be fine with that, as it would make PRs easier for me. ;)

Best,
Theresa

---

From: "Holland, Jake" <[email-masked]>
Date: Wed, 25 Sep 2019 21:34:42 +0000

Hi Theresa,

Thanks for taking a look.

> dumps the XML and the tree structure, but it does not validate the

Yes, exactly.

> .html. That's the intended behavior, right?
...
> there's no target called "yanglint".

This isn't what I expect, no.  This behavior sounds like the lib/ directory
is not hooked up--if you built it before, the old lib/ would still be there
(nothing auto-updates it).  That would probably explain what you're seeing.

To check whether that's right, something like this is expected if you start
from a clean ietf-taps-yang directory now (one without a lib/), after
running any kind of make (it does pull the lib/, but only if it's missing,
I think):

~~~
jake-lap:ietf-taps-yang jholland$ cd lib
jake-lap:lib jholland$ git status
On branch yang-support
Your branch is up to date with 'origin/yang-support'.

nothing to commit, working tree clean
jake-lap:lib jholland$ git remote -v
origin	https://github.com/GrumpyOldTroll/i-d-template (fetch)
origin	https://github.com/GrumpyOldTroll/i-d-template (push)
~~~

If that's not what you see (if it's on master instead of yang-support,
for instance), maybe try moving the lib/ directory away and then doing
a make again, or 'git pull; git checkout yang-support'.

What I expect if lib/ is on the right branch, and an error has been
introduced (e.g. by changing an identifier in an example):
- if you type 'make yanglint' it'll report the error
- regardless of whether you make yanglint, if you
  'export VALIDATE_YANG=1; make', it will NOT build a .txt/.html, and will
  report the same error as 'make yanglint'.
- if you unset VALIDATE_YANG or never used it and just 'make',
  you'll see no error*, and it'll build a .txt that contains the error.

* you might still see an error if you don't have pyang installed.  You
might also get warnings about missing imports if you haven't done a make
yanglint, which fetches them.  But it turns out those aren't required for
the tree-building, and won't stop the build from completing.

HTH.

Best,
Jake