Subject: [yang-doctors] recommending yang 1.1

From: Kent Watsen <[email-masked]>
Date: Mon, 18 Jul 2016 16:36:34 +0000

>From the NETMOD meeting just now, doctors SHOULD:

1) recommend modules upgrade to 1.1 iff they could take advantage of 1.1 functionality. 

2) recommend they use 1.0 when no 1.1 functionality is being used. 

Kent

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 18 Jul 2016 18:52:37 +0200

> 2) recommend they use 1.0 when no 1.1 functionality is being used. 

I think 2) should be rather 'accept they use 1.0 when no 1.1
functionality is being used or useful'. I think it is just fine to
have modules use 1.1 that do not have specific strong technical reason
to do so - why would we force them downwards?

Personally, I would rather push for 1.1 since this is the long-term
direction and most RFCs have a somewhat longish and static lifecycle
but then my opinion is likely very much biased towards 1.1 being
desirable. :)

/js

PS: This whole topic was discussed before at least once, see the
    minutes of the Prague meeting.

    https://www.ietf.org/proceedings/93/minutes/minutes-93-netmod

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Mon, 18 Jul 2016 19:48:47 +0200

I agree with Juergen here.

Bert

---

From: Benoit Claise <[email-masked]>
Date: Tue, 19 Jul 2016 01:31:33 +0200

Me too.
It should be in RFC6087bis. Now, this doc. is for both Authors and 
Reviewers of YANG Data Model Documents.
So we have to find the appropriate language.

Regards, B.
> _______________________________________________
> yang-doctors mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/yang-doctors
> .
>

---

From: Andy Bierman <[email-masked]>
Date: Tue, 19 Jul 2016 02:01:06 -0700

Hi,

I will update the guidelines draft but I have no delusions that YANG 1.1
tools
are as solid as YANG 1.0 tools.  We get a false sense of interoperability
because
there is really only 1 toolset being used by the IETF. The IETF used to
hold interoperability tests to verify tool maturity but we stopped doing
that
about 5 years ago.

The new components in the pipeline like schema mount dramatically increase
the tool complexity.  I don't expect YANG Doctors to solve this problem,
just be aware that "pyang --ietf" is not a substitute for real
interoperability.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 19 Jul 2016 12:00:20 +0200

> just be aware that "pyang --ietf" is not a substitute for real

The sooner tools mature the better. Perhaps it would help to collect
facts about how far the various implementations are concerning YANG
1.1 support and what their plans are.

So far, pyang was good enough for me to write modules. pyang has been
reported to support 1.1 (minus the things pyang never did such as
analyzing xpath expressions). During the hackathon, I learned about
libyang and I immediately fell in love with it. It is YANG 1.0 right
now but I can easily check with Radek when he will add support for
YANG 1.1. So what about YANG 1.1 support in yumapro? What about confd?
What about YANG 1.1 support in ODL tools? There are a couple of
commerical tools (e.g. <http://www.seguesoft.com/>,
<http://www.mg-soft.com>). I can easily ask Matjaz concerning the
MG-Soft implementation.

[...]

Since I did not find a good web page of YANG implementations, I
started a new section on the YANG wikipedia page (i have largely
edited in the past) <https://en.wikipedia.org/wiki/YANG>. Any key
implementations missing before I ask on the NETMOD list for additional
input? I am also happy to add which versions of YANG the tools
support.

/js

---

From: Andy Bierman <[email-masked]>
Date: Tue, 19 Jul 2016 03:16:40 -0700

Hi,

I understand it is hard to do client/server testing without agreeing on the
YANG modules first.  One of our engineers has been doing testing
with the opensource tools and not found very good results.

I am about 70% done implementing YANG 1.1 in all our tools.
Getting a compiler to validate YANG 1.1 is easy compared
to client and server support.

Our tools should be done by the next IETF.
Implementing the protocols so the code is robust and also fast
is challenging.  We have seen the performance of existing implementations
and I can see everybody is in the same boat.  The "edits per second"
out there sucks. I guess that's good news for commercial tools.

Nobody cares about the implementation complexity of YANG so
I am not looking for sympathy, but full toolchains for YANG 1.1
might take 1 - 2 years to be as good as the 1.0 tools.
I don't really care that the IETF wants it yesterday.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 19 Jul 2016 13:03:52 +0200

Andy,

I hear you but given the lifetime of RFCs and the typical adoption
speed of data models defined in RFCs, I think we can affort to mature
toolchains in parallel as long as there is sufficient out there to get
started.

More interoperability testing of protocol interactions surely will
help as well but I see this as a different activity somone has to
organize. Finding common data models should be easier today given that
we have ietf-interfaces and friends. What I personally found missing
at the hackathon was someone trying to run ODL against
netopeer2/sysrepo etc. Most people are focussed on improving their own
project, which is understandable, but if I attend another hackathon
(currently no plans to travel to Seoul or Chicago) I would like to try
something like this (just to learn more about open source tools out
there).

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 19 Jul 2016 17:04:22 +0200

> to do so - why would we force them downwards?

A related question is what tools are supposed to do. In my view, a tool
should accept 1.1 modules only after they support at least non-trivial
part of 1.1 features.

So I guess I am more in favour of Kent's original formulation - we
shouldn't create unnecessary problems to existing tools. As Andy wrote, some
of the new features require substantial work, so it takes time to
implement them.

Of course, I do support 1.

>     https://www.ietf.org/proceedings/93/minutes/minutes-93-netmod

Now that 6020bis is about to become an RFC, this question has just
become more pressing.

Lada

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Andy Bierman <[email-masked]>
Date: Tue, 19 Jul 2016 08:44:40 -0700

> should accept 1.1 modules only after they support at least non-trivial

I agree.
We have not enable 1.1 in our released code.
Source code licensees can turn it on.
I have been relying on Martin's list of changes to keep track of to-do
tasks.

Obviously very implementation-specific, but simple concepts like
"allow a leaf-list to have N defaults" is a bit tricky to implement in the
server.
We certainly have enough implemented to cover all the stuff IETF
modules are using, including all the new XPath, anydata, actions,
if-feature,
and notifications.  We will turn on 1.1 for real in our October release.

Andy