Subject: Re: [netmod] Blog: YANG Really Takes Off in the Industry

From: Benoit Claise <[email-masked]>
Date: Mon, 01 Dec 2014 09:26:56 +0100

Dean,

See in-line.
> Benoit,
>
> You describe the situation really well, but as next step we have to 
> get more organized and more coordination in modeling work. We have to 
> make sure that there is not too much overlap between efforts, not too 
> waste resources
... and inconsistencies between data models, which is my primary concern.

Let's take one example: policies. I see policies in many YANG models. 
How do we make sure the policie definitions are consistent and 
extensible? How can we coordinate this (huge) effort? Who is in charge? 
The collective responsibility might not be enough...

> and as well create an architecture description document, where the 
> relationship between models will be described. With that we can see 
> which models can be reused as base model in other models.
> Good example of coordination is the rtg-coord-yang mailing list, but 
> we need one for all IETF, to be able to find what are other the teams 
> working on.
Right.

Regards, Benoit
>
> We should not let this momentum go away and with few simple steps 
> (like improving coordination and system meta architecture), continue 
> to feed positive energy into this situation.
>
> Dean
> On Nov 27, 2014, at 6:31 AM, Benoit Claise <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> Dear all,
>>
>> [netmod WG list is bcc'ed]
>>
>> Enjoy 
>> http://www.ietf.org/blog/2014/11/yang-really-takes-off-in-the-industry/
>>
>> Regards, Benoit
>>
>>
>> _______________________________________________
>> netmod mailing list
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 1 Dec 2014 09:42:06 -0500

Benoit,

	Thanks for writing this article. It punctuates the rapid increase in interest not only by the IETF community around Yang models, but also the wider open source and netops communities. Interest from operators is also starting to ramp up with the Open Config project starting up, which is very much related to both the work that has happened within the IETF but also outside.   It is important that we help and encourage these cross-organizational collaborations as this will only mean good things for Yang going forward.

	—Tom

> On Nov 27, 2014:6:31 AM, at 6:31 AM, Benoit Claise <[email-masked]> wrote:
> 
> Dear all, 
> 
> Enjoy http://www.ietf.org/blog/2014/11/yang-really-takes-off-in-the-industry/ <http://www.ietf.org/blog/2014/11/yang-really-takes-off-in-the-industry/> 
> 
> Regards, Benoit 
> 
>

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 1 Dec 2014 09:46:36 -0500

One of the things that came up in a number of discussions I had in Hawaii and afterwards was around the coordination and encouragement topics. A number of people commented both during these discussions (and I think someone did during one of the Netmod sessions) that the “MIB Doctor” model we are using is not going to scale out to the numbers of Yang models that are in need of advice or review, nor will be scale in terms of progressing models through the IETF’s RFC process. The fact is that we simply do not have enough Yang Doctors to cover all of the models in question, despite our best efforts.   It is for this reason that I strongly encourage other venues of review and advice such as a continued “advice” or “Yangathon” session at each IETF meeting going forward, as well as encouraging a loosening of the interim WG meeting rules to encourage more meetings, as well as perhaps less formalized ones.  I also encourage the IETF to start pairing up with other organizations such as OpenDaylight, Openstack and OP-NFV and join their Yangathons there.

	—Tom

> On Nov 28, 2014:8:12 AM, at 8:12 AM, Benoit Claise <[email-masked]> wrote:
> 
> Hi Jari,
> 
> Let me open the discussion.
> What is important at this point in time is the coordination of those YANG models.
> All of them come at the same time, and this required some urgent attention.
> Focusing on the routing YANG models with "[email-masked]" <[email-masked]> <https://www.ietf.org/mailman/listinfo/rtg-yang-coord> is a step in the right direction. Indeed the community needs to agree on how to model IGPs, BGP, the topology, etc...
> However, the coordination should also occur with the data models developed in other IETF WGs. And the IETF might need to reach out to different SDOs/consortia. 
> As the operators told me: we can't afford to develop those data models independently from each others.
> 
> Regards, Benoit
>> Thanks for writing this article, Benoit!
>> 
>> The wave of new data models is obviously interesting and exciting. But I wanted to open a discussion with you all on what we should do with regards to serving this need better. Is there something that we could do better at the IETF to be able deal with this new work?
>> 
>> Jari
>> 
>

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 1 Dec 2014 09:48:49 -0500

> On Dec 1, 2014:3:26 AM, at 3:26 AM, Benoit Claise <[email-masked]> wrote:
> 
> Dean,
> 
> See in-line.
>> Benoit,
>> 
>> You describe the situation really well, but as next step we have to get more organized and more coordination in modeling work. We have to make sure that there is not too much overlap between efforts, not too waste resources 
> Let's take one example: policies. I see policies in many YANG models. How do we make sure the policie definitions are consistent and extensible? How can we coordinate this (huge) effort? Who is in charge? The collective responsibility might not be enough…

	Coordination is only one issue: its operational efficacy that is also of paramount importance here. We should do what we’ve done in NETMOD's “design teams”: pair up people that are truly implementing functionality in real or virtual devices with operators to ensure that the models created are grounded in the realities of implementation and deployment. 

	—Tom

> 
>> and as well create an architecture description document, where the relationship between models will be described. With that we can see which models can be reused as base model in other models. 
>> Good example of coordination is the rtg-coord-yang mailing list, but we need one for all IETF, to be able to find what are other the teams working on.
> Right.
> 
> Regards, Benoit
>> 
>> We should not let this momentum go away and with few simple steps (like improving coordination and system meta architecture), continue to feed positive energy into this situation.
>> 
>> Dean
>> On Nov 27, 2014, at 6:31 AM, Benoit Claise <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>>> Dear all, 
>>> 
>>> https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>
>> 
> 
>

---

From: Dean Bogdanovic <[email-masked]>
Date: Mon, 1 Dec 2014 21:25:22 +0000

Tom,

See in-line
On Dec 1, 2014, at 9:48 AM, Thomas D. Nadeau <[email-masked]<mailto:[email-masked]>> wrote:

On Dec 1, 2014:3:26 AM, at 3:26 AM, Benoit Claise <[email-masked]<mailto:[email-masked]>> wrote:

Dean,

See in-line.
Benoit,

I agree with you on operational efficacy, but as there are more and more models, I see some duplication work, so I really see a need to get a meta architecture asap, so that the teams can be more efficient.

Dean

—Tom

Regards, Benoit

Dean
On Nov 27, 2014, at 6:31 AM, Benoit Claise <[email-masked]<mailto:[email-masked]>> wrote:

Dear all,

Enjoy http://www.ietf.org/blog/2014/11/yang-really-takes-off-in-the-industry/

Regards, Benoit

_______________________________________________
netmod mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netmod

---

From: Benoit Claise <[email-masked]>
Date: Mon, 01 Dec 2014 23:30:24 +0100

On 01/12/2014 15:48, Thomas D. Nadeau wrote:
>>> get more organized and more coordination in modeling work. We have 
>>> to make sure that there is not too much overlap between efforts, not 
>>> too waste resources
>> extensible? How can we coordinate this (huge) effort? Who is in 
>> charge? The collective responsibility might not be enough…
>
> Coordination is only one issue: its operational efficacy that is also 
> of paramount importance here. We should do what we’ve done in NETMOD's 
> “design teams”: pair up people that are truly implementing 
> functionality in real or virtual devices with operators to ensure that 
> the models created are grounded in the realities of implementation and 
> deployment.
+1

Regards, Benoit
>>> we need one for all IETF, to be able to find what are other the 
>>> teams working on.
>> Right.
>>
>> Regards, Benoit
>>>
>>>> Enjoyhttp://www.ietf.org/blog/2014/11/yang-really-takes-off-in-the-industry/
>>>>
>>>> Regards, Benoit
>>>>
>>>>

---

From: Randy Bush <[email-masked]>
Date: Tue, 02 Dec 2014 09:10:39 +0900

> the “MIB Doctor” model we are using is not going to scale out to the
> numbers of Yang models that are in need of advice or review, nor will
> be scale in terms of progressing models through the IETF’s RFC
> process.  The fact is that we simply do not have enough Yang Doctors
> to cover all of the models in question, despite our best efforts.

is this a sign that we do not have enough medical care or that we are
unleashing an unarchitected epidemic of overly device-specific snmp with
the syntax changed?

randy

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 1 Dec 2014 19:15:58 -0500

> On Dec 1, 2014:7:10 PM, at 7:10 PM, Randy Bush <[email-masked]> wrote:
> 

	Speaking from my own personal opinion, it seems that operators are finding this stuff useful and are 
demanding that people build products with it. Its a retrofit for many products, and so there is an 
avalanche of work to do here to get caught up to build non-device-specific models.  As you know,
most vendors that support Netconf have basically wrapped their CLIs with Netconf, so the models are
proprietary and do not translate across devices well. So this effort is to build standard (here
at the IETF), or at least non-device-specific (in the case of the related open source efforts). 

	--Tom

---

From: Dean Bogdanovic <[email-masked]>
Date: Tue, 2 Dec 2014 00:38:39 +0000

On Dec 1, 2014, at 7:15 PM, "Thomas D. Nadeau" <[email-masked]>
 wrote:

> demanding that people build products with it.

I agree with you on this one. See it from multiple operators in Americas and EMEA (haven't seen in APAC personally). Operators have been translating their service configurations into YANG and are looking how to adapt their service models to proprietary operator models. For them, having standard config models, would make it much more easier to translate their service models and let the vendors worry about translation from standard to proprietary models.

Dean

---

From: Tim Wicinski <[email-masked]>
Date: Mon, 01 Dec 2014 19:42:18 -0500

> I agree with you on this one. See it from multiple operators in Americas and EMEA (haven't seen in APAC personally). Operators have been translating their service configurations into YANG and are l…

What is the IETF when many of the newer networking companies do not find 
YANG worth investing in?  I'm thinking of Arista as a good example of a 
networking vendor that (i've been told) feels supporting YANG makes them 
less agile than their APIs.

tim

---

From: Dean Bogdanovic <[email-masked]>
Date: Tue, 2 Dec 2014 02:54:28 +0000

On Dec 1, 2014, at 7:42 PM, Tim Wicinski <[email-masked]>
 wrote:

> What is the IETF when many of the newer networking companies do not find YANG worth investing in? 

As far I know Arista has their own proprietary schema language (as many other companies have it too), that describes their data model. Arista uses that schema to generate binding to be able to access all objects generated from the data model from python.
If they use their proprietary or use IETF YANG to describe the data model is a decision companies have to make by them self. There is a benefit to have a standardized language that everyone is able to understand.

>  I'm thinking of Arista as a good example of a networking vendor that (i've been told) feels supporting YANG makes them less agile than their APIs.

this is one part I don't understand. Why adding another language would make them less agile?

Dean

---

From: Ted Lemon <[email-masked]>
Date: Mon, 1 Dec 2014 20:59:08 -0600

> this is one part I don't understand. Why adding another language would make them less agile?

If the yang model isn't a good representation of what is being modeled, it can cause more harm than good.   Same problem exists with MIBs.   When different implementations of the same thing use different base assumptions, it can be difficult to come up with a management model that is congruent with all of the different base assumptions and is still useful.   I wouldn't say it's impossible, but it's a good bet that a poorly thought out model or a model that is based on experience with a single implementation will fail in this regard.

---

From: Dean Bogdanovic <[email-masked]>
Date: Tue, 2 Dec 2014 03:06:49 +0000

On Dec 1, 2014, at 9:59 PM, Ted Lemon <[email-masked]>
 wrote:

> If the yang model isn't a good representation of what is being modeled, it can cause more harm than good.   

This is not the answer to my question. I asked about adding support for another language, not how the models are architected. Vendors can (and, in my personal opinion, will) provide proprietary and standard data models. The operator can choose then which model they want to use for their purposes.

> Same problem exists with MIBs.   When different implementations of the same thing use different base assumptions, it can be difficult to come up with a management model that is congruent with all of the different base assumptions and is still useful.   I wouldn't say it's impossible, but it's a good bet that a poorly thought out model or a model that is based on experience with a single implementation will fail in this regard.
>

---

From: Ted Lemon <[email-masked]>
Date: Mon, 1 Dec 2014 21:16:43 -0600

On Dec 1, 2014, at 9:06 PM, Dean Bogdanovic <[email-masked]> wrote:
> This is not the answer to my question.

It's certainly an answer to your question.

> I asked about adding support for another language, not how the models are architected. Vendors can (and, in my personal opinion, will) provide proprietary and standard data models. The operator can choose then which model they want to use for their purposes.

If the YANG data model is architected badly, then the vendor may not be _able_ to support that data model, and then the operator won't be able to choose that model.   If a vendor's experience of data models written in that language is that they aren't good enough, then the vendor might well decide that there's no value in supporting the language.

That said, one of the issues with YANG that has been reported back to me, but with which I do yet have specific experience of my own, is that the language is not sufficiently expressive.   E.g., it was not thought possible to express DHCP option extensions in YANG.   This would mean that certain basic functions of a DHCP server could not be supported without a non-YANG management model.

---

From: Randy Bush <[email-masked]>
Date: Tue, 02 Dec 2014 13:08:38 +0900

> I asked about adding support for another language, not how the models
> are architected.

if they are unrelated, when will juniper be adding fortran to the cli?

randy

---

From: Dean Bogdanovic <[email-masked]>
Date: Tue, 2 Dec 2014 13:46:47 +0000

> if they are unrelated, when will juniper be adding fortran to the cli?

You can run Fortran on Junos, another question is if you really want to do it. :-)

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 2 Dec 2014 09:43:11 -0500

Please, it is not a question of whether YANG is a good or a bad data
model. Whether it is applicable to a problem depends on what that
problem is.

There are two sorts of (useful) schema language for two different problems.

If your problem is modeling existing data formats then you need an
expressive schema language that allows the irregularities and
inconsistencies of the existing formats to be described. XML Schema is
horribly complex because one of the constraints was that it should be
a superset of SGML DTDs to allow automatic translation from DTDs to
Schema.

I have schemas that describe DNS and RFC822 headers and the like and
while they are fairly straightforward, they are not 'clean'. There are
six different ways to encode headers in RFC822 style and DNS RRs are
much more complicated.

So if you are trying to model IP headers or the like you are going to
want an expressive language.

If what you want to do is to define an application protocol that does
not need to be backwards compatible with a legacy system then you want
as little flexibility as possible. Because standards writing is taking
decisions that don't matter out of the equation.

This is why ASN.1 is so unfit for purpose. Despite the claim to be
'abstract', the data model is full of design choices that only exist
to micromanage the wire format. The distinction between sets and
lists, implicit versus explicit tagging etc. etc.

At the end of the day, every message in an application protocol is
going to map to an API call or return somewhere in the application
implementation. We can make that mapping complicated or we can make it
simple.

If we have a protocol TimeService with method for finding the time:

class TimeService {
    public Status GetTime (out DateTime Now);
    }

We can have a schema language that allows fifty different encodings
for the DateTime object or we can pick one and stick to it. If we are
using a JSON encoding which is text, we would probably map DateTime
onto a string and use ISO 8601 or RFC 3339 to describe the encoding.

If we were dealing with legacy we might have to deal with other forms.
But the best schema language for writing new apps would not provide
that flexibility.

{GetTimeResult : {Now: "2014-01-02T13:10:00Z"}}

Now the reason I chose this particular example is that time is
actually a case where encoding does matter because embedded devices
might not know about the leap seconds which some idiots have managed
to visit on us:

class TimeService {
    public Status GetTime (out DateTime Now, out Int64? ElapsedSeconds);
    }

Here we do have a schema issue since JSON integers can be of any size
while using bignum arithmetic in an API has a severe impact on
performance and convenience. And in this case we will have bigger
problems long before the Int64 time rollover occurs.

Now since the C# syntax for a nullable type (Int64?) doesn't make the
message signature obvious, I actually use my own private schema
language:

Message GetTimeResult
    DateTime Now
        Required
    Integer ElapsedSeconds
        Bits 64

YANG is a lot more powerful and flexible than my system. And that is
why I would not use it for the type of applications I work on. I do
not want to have the option of encoding the data in more than one way
because in a new application that is 'bikeshedding'.

If your problem is dealing with legacy systems and requires modeling
of statefull interactions then you need that flexibility.

In summary, there is a place for YANG but it is certainly not the only
schema language that is useful. There is also a place for XML Schema
but that place is not describing Web Service protocols. There is also
a place for simpler schema formats that allow a direct mapping of API
calls to messages. And there are some schema languages that should
never be used at all.

---

From: t.p. <[email-masked]>
Date: Wed, 3 Dec 2014 10:18:22 +0000

----- Original Message -----
From: "Ted Lemon" <[email-masked]>
To: "Dean Bogdanovic" <[email-masked]>
Cc: "IETF-Discussion list" <[email-masked]>
Sent: Tuesday, December 02, 2014 2:59 AM
Subject: Re: Blog: YANG Really Takes Off in the Industry

> this is one part I don't understand. Why adding another language would
make them less agile?

If the yang model isn't a good representation of what is being modeled,
it can cause more harm than good.   Same problem exists with MIBs.

<tp>

The difference is that MIBs are written in a much simpler language; what
object should there be, its syntax and status (index, read-only,
read-write) and that's about it (even augmentation tends to confuse many
people).  I have never yet met a MIB module that I could not reverse
engineer to determine the design, even the requirements.

YANG is different, it is capable of much more complicated things and
occasionally it is unclear what it does mean (something that surfaces on
the netmod WG list now and again).  What I think I see happening is what
happened when programming languages became more widely used, an
inability to keep things as simple as they could be, resulting in code
whose purpose was unclear, that was error-prone and hard to understand
or maintain.  Not an issue with SMI.

The YANG models of the IETF seem to be diving into complex code from
which it is hard to discern what the purpose is, and the fact that most
of the exemplars are written by those highly expert in YANG, and so use
the wide range of constructs available, does not help.

Perhaps the IESG should require that any IETF YANG data model must be
accompanied by an information model so that we can debate what should be
done independently of deciding how to do it.  After all, this is a
stricture that has been imposed on the I2RS WG.

Tom Petch

When different implementations of the same thing use different base
assumptions, it can be difficult to come up with a management model that
is congruent with all of the different base assumptions and is still
useful.   I wouldn't say it's impossible, but it's a good bet that a
poorly thought out model or a model that is based on experience with a
single implementation will fail in this regard.

---

From: Alia Atlas <[email-masked]>
Date: Wed, 3 Dec 2014 09:27:19 -0500

Hi Tom,

> the wide range of constructs available, does not help.

Thanks - this is an interesting perspective.

> stricture that has been imposed on the I2RS WG.

I do think that it is useful to understand what information is being
modeled and
what the relationships are.  Having separate info models for I2RS hasn't
worked
ideally; I'd rather see a section in the YANG model that describes the
information
and relationships - and then the pyang tree and the detailed model.  Such
sections
are common with MIB models and do, I think, help clarify.

Alia

---

From: Dean Bogdanovic <[email-masked]>
Date: Wed, 3 Dec 2014 20:56:33 +0000

Phillip,

Thank you for bringing us back to the topic and a very good post.

So my original comment was that YANG as language that is being used for modeling.  Models can be done badly in any language, it doesn't matter which one. If Arista has a good model, the representation of that model shouldn't matter if it is in YANG or another language. Using YANG, it gives a more widely understanding then using a proprietary language.

Dean

---

From: Ted Lemon <[email-masked]>
Date: Wed, 3 Dec 2014 15:28:07 -0500

> the wide range of constructs available, does not help.

Can you give an example of the problem you are talking about here?

---

From: Benoit Claise <[email-masked]>
Date: Mon, 08 Dec 2014 10:32:23 +0100

Hi Tom,

In light of the numerous YANG models these days, there is the YANG 
doctors scaling issue. You're right, even if the number of YANG doctors 
recently increased, we need other venues to provide advice to YANG model 
designers. This should solve the issue of designing properly the YANG 
models.
On the other hand, there is a bigger issue, IMO: the proper coordination 
of those YANG models. This is not the YANG doctors responsibility. This 
can't be: see the YANG doctors scalability issue.  So who's 
responsibility is this? Simply asserting "it's the community 
responsibility" is the easy answer, but I'm afraid it will not work.

Regards, Benoit
>
> One of the things that came up in a number of discussions I had in 
> Hawaii and afterwards was around the coordination and encouragement 
> topics. A number of people commented both during these discussions 
> (and I think someone did during one of the Netmod sessions) that the 
> “MIB Doctor” model we are using is not going to scale out to the 
> process. The fact is that we simply do not have enough Yang Doctors to 
> cover all of the models in question, despite our best efforts.   It is 
> for this reason that I strongly encourage other venues of review and 
> advice such as a continued “advice” or “Yangathon” session at each 
> IETF meeting going forward, as well as encouraging a loosening of the 
> interim WG meeting rules to encourage more meetings, as well as 
> perhaps less formalized ones.  I also encourage the IETF to start 
> pairing up with other organizations such as OpenDaylight, Openstack 
> and OP-NFV and join their Yangathons there.
>
> —Tom
>
>
>
>> On Nov 28, 2014:8:12 AM, at 8:12 AM, Benoit Claise <[email-masked] 
>> Focusing on the routing YANG models with "[email-masked]" 
>> <[email-masked]> 
>> <https://www.ietf.org/mailman/listinfo/rtg-yang-coord> is a step in 
>> the right direction. Indeed the community needs to agree on how to 
>> model IGPs, BGP, the topology, etc...
>> However, the coordination should also occur with the data models 
>> developed in other IETF WGs. And the IETF might need to reach out to 
>> different SDOs/consortia.

---

From: Benoit Claise <[email-masked]>
Date: Mon, 08 Dec 2014 10:51:41 +0100

Hi Tom,
> stricture that has been imposed on the I2RS WG.
Having information models (IM) before data models (DM) is the right 
theoretical approach. And I pushed that approach in the past, when YANG 
was not the data modeling of choice for configuration. I mean before the 
Writable MIB Module IESG Statement 
<https://www.ietf.org/iesg/statement/writable-mib-module.html>

However, I don't think it's appropriate any longer.
- what is the language for IM: text, UML, pseudo-code?
- when I discussed IM for DM with some operators, the answers were along 
these lines: "no IMs please, give me something that I can work with, so 
vendor-neutral DMs. And btw, this is urgent."
- as Alia mentioned, IM before DM didn't work too well for I2RS

In conclusion, at the time were DMs are urgent, I agree with Alia:

    "I'd rather see a section in the YANG model that describes the
    information and relationships - and then the pyang tree and the
    detailed model."

Regards, Benoit
> .

---

From: Benoit Claise <[email-masked]>
Date: Mon, 08 Dec 2014 10:54:42 +0100

Ted,
> That said, one of the issues with YANG that has been reported back to me, but with which I do yet have specific experience of my own, is that the language is not sufficiently expressive.   E.g., it…
Can you please follow up on this claim that YANG is not sufficiently 
expressive. I would like to understand if there is a (YANG) problem to 
be solved.

Regards, Benoit

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Mon, 8 Dec 2014 07:40:42 -0500

You are right that "community responsibility" is a bit nebulous. What we need to do is setup a community place or places where people can meet up online or in person (at relatively frequent intervals) to work on modeling. The open source communities do this via virtual and real "hackathons" -- which are what we've setup just as part of official IETF meetings. I set one up at the previous ODL dev meetup, and will do so going forward as well as part of a few well attended conferences. Other ideas (and help!) for these is appreciated. 

	--Tom

> On Dec 8, 2014:4:32 AM, at 4:32 AM, Benoit Claise <[email-masked]> wrote:
> 
> Hi Tom,
> 
> In light of the numerous YANG models these days, there is the YANG doctors scaling issue. You're right, even if the number of YANG doctors recently increased, we need other venues to provide advice to YANG model designers. This should solve the issue of designing properly the YANG models. 
> On the other hand, there is a bigger issue, IMO: the proper coordination of those YANG models. This is not the YANG doctors responsibility. This can't be: see the YANG doctors scalability issue.  So who's responsibility is this? Simply asserting "it's the community responsibility" is the easy answer, but I'm afraid it will not work. 
> 
> Regards, Benoit
>> 
>> 
>>> On Nov 28, 2014:8:12 AM, at 8:12 AM, Benoit Claise <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Hi Jari,
>>>

---

From: "Ersue, Mehmet (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 8 Dec 2014 17:30:15 +0000

Hi Benoit, All,

to be able to reduce the necessary amount reviews and publications, I assume we need to define some categories:

- YANG models might be interesting to have but they don't need to be standardized in many cases. So, the category for Standard track RFC has to be defined with a clear criteria.
- Others may be Informational or Experimental. However for these we need to see the relevance to IETF work and necessity for publication.

The other categorization could be concerning the dispatching of YANG models within IETF:

- There are particularly important YANG models related to a specific WG. They should be developed in that WG.
- There might be others which are still important to publish but don't have any home. I would discuss them in an OPSAWG meeting and decide whether it should be published in OPSAWG or NETMOD WG
.
The other category I see is related to YANG models which should be matched to another SDO. If we think a model is e.g. related to IEEE or MEF, they should be done there and not at IETF.

There might be also other YANG models which are interesting but not related to IETF. One particular category is concerning models, which were originally Enterprise models but people would like to have an IETF publication.

In general, over time we might need to be strict to stick to the categories and the matched process per category.

That said, I would like to suggest to use the resources of the YANG doctor team for models, which are essential for the IETF at the first place, especially those seen under the category Standard track RFC.

Cheers,
Mehmet

From: ietf [mailto:[email-masked]] On Behalf Of ext Benoit Claise
Sent: Monday, December 08, 2014 10:32 AM
To: Thomas D. Nadeau
Cc: IETF-Discussion list
Subject: Re: Blog: YANG Really Takes Off in the Industry

Hi Tom,

Regards, Benoit

        One of the things that came up in a number of discussions I had in Hawaii and afterwards was around the coordination and encouragement topics. A number of people commented both during these discussions (and I think someone did during one of the Netmod sessions) that the "MIB Doctor" model we are using is not going to scale out to the numbers of Yang models that are in need of advice or review, nor will be scale in terms of progressing models through the IETF's RFC process. The fact is that we simply do not have enough Yang Doctors to cover all of the models in question, despite our best efforts.   It is for this reason that I strongly encourage other venues of review and advice such as a continued "advice" or "Yangathon" session at each IETF meeting going forward, as well as encouraging a loosening of the interim WG meeting rules to encourage more meetings, as well as perhaps less formalized ones.  I also encourage the IETF to start pairing up with other organizations such as OpenDaylight, Openstack and OP-NFV and join their Yangathons there.

        -Tom

On Nov 28, 2014:8:12 AM, at 8:12 AM, Benoit Claise <[email-masked]<mailto:[email-masked]>> wrote:

Hi Jari,

Focusing on the routing YANG models with "[email-masked]" <[email-masked]><https://www.ietf.org/mailman/listinfo/rtg-yang-coord> is a step in the right direction. Indeed the community needs to agree on how to model IGPs, BGP, the topology, etc...

Regards, Benoit

Jari

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 9 Dec 2014 10:54:58 +0000

Hi,

Success comes sometimes together with its own risks. In the case of YANG, the risk is that six months or one year from now people who enthusiastically engaged with developing YANG module will have at hand bad modules that do not meet their expectations of functionality, quality, interoperability. The pushback can then follow at the same intensity as the current embracing. To avoid this situation we need to provide answers to the problem of non-scalability of the 'Doctors' team model which is IMO real. The answer cannot be just 'let us focus on what we do in the standards track in the IETF' because much of the development of YANG modules happens out of the IETF and this is how we want it to be. We need to encourage the open source and SDOs that engage on the YANG path to develop their own Yangathon events and maybe in time their own YANG doctors teams. We need however to make clear that this is the model we recommend (rather than developing YANG modules and coming to the YANG doctors to review) and offer help in organizing these first activities and teams at their homes.

Regards,

Dan

From: ietf [mailto:[email-masked]] On Behalf Of Ersue, Mehmet (NSN - DE/Munich)
Sent: Monday, December 08, 2014 7:30 PM
To: ext Benoit Claise; Thomas D. Nadeau
Cc: IETF-Discussion list
Subject: RE: Blog: YANG Really Takes Off in the Industry

Hi Benoit, All,

Cheers,
Mehmet

Hi Tom,

Regards, Benoit

        -Tom

Hi Jari,

Focusing on the routing YANG models with "[email-masked]" <[email-masked]><https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_rtg-2Dyang-2Dcoord&d=AAMFAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=EldXn4rzRf97Z5Y7A2KouM2hYYBbL5m9IMpucoilFZE&s=14IGX58lMwSyD8bOPQb_MqlsYeQ3u_s0T7YwNmjqqU0&e=> is a step in the right direction. Indeed the community needs to agree on how to model IGPs, BGP, the topology, etc...

Regards, Benoit

Jari

---

From: t.p. <[email-masked]>
Date: Tue, 9 Dec 2014 14:31:47 +0000

----- Original Message -----
From: "Ted Lemon" <[email-masked]>
To: "t.p." <[email-masked]>
Cc: "Dean Bogdanovic" <[email-masked]>; "IETF-Discussion list"
<[email-masked]>
Sent: Wednesday, December 03, 2014 8:28 PM

Ted,

Apologies for the delay.

The expression that controls the permissible format of IPv6 addresses in
yang-types is of this ilk.
"       type string {
         pattern '((:|[0-9a-fA-F]{0,4}):)([0-9a-fA-F]{0,4}:){0,5}'
               + '((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|'
               + '(((25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])\.){3}'
               + '(25[0-5]|2[0-4][0-9]|[01]?[0-9]?[0-9])))'
               + '(/(([0-9])|([0-9]{2})|(1[0-1][0-9])|(12[0-8])))';
         pattern '(([^:]+:){6}(([^:]+:[^:]+)|(.*\..*)))|'
               + '((([^:]+:)*[^:]+)?::(([^:]+:)*[^:]+)?)'
               + '(/.+)'; "
which was got wrong several times before it became what it is now (which
rings alarm bells for me).

netmod-routing-cfg-02 on the netmod WG list 29feb2012 tripped over that
fact that a unique-stmt for container/list/leaf is not allowed in trying
to make a name unique (because there is a 'list' in there) which led to
a debate as to what YANG(RFC6020) was actually trying to say on this
topic with the conclusion that the RFC is ambiguous.

By the time this I-D  was up to netmod-routing-cfg-08 13feb2013 Martin
suggested
"> I think the majestic must expression for the connected-routing-table
> might be wrong.  The problem is that it checks that:
>    not (*some* preceding-sibling has same afi
>         AND
>         *some* preceding-sibling has same safi)  "
so it was revised from
"                  must "not(/routing/routing-tables/"
                    + "routing-table[name=current()/"
                    + "preceding-sibling::connected-routing-table/"
                    + "name]/address-family=/routing/routing-tables/"
                    + "routing-table[name=current()/name]/"
                    + "address-family and /routing/routing-tables/"
                    + "routing-table[name=current()/"
                    + "preceding-sibling::connected-routing-table/"
                    + "name]/safi=/routing/routing-tables/"
                    + "routing-table[name=current()/name]/safi)" {
                   error-message "Duplicate address family for "
                               + "connected routing tables.";   "
to
"    must "not(/routing/routing-tables/"
       + "routing-table[name=current()/"
       + "preceding-sibling::connected-routing-table/"
       + "name and address-family=/routing/routing-tables/"
       + "routing-table[name=current()/name]/"
       + "address-family and safi=/routing/routing-tables/"
       + "routing-table[name=current()/name]/safi])" {
      error-message "Duplicate address family for "
                  + "connected routing tables.";    "

draft-ietf-netmod-snmp-cfg-00 started out with
"     when "../type = trap or ../type = inform";  "
which looks ok, but isn't, generating the error message
"Warning: no child nodes found in XPath expr '../type = trap or ../type
= inform'
ietf-snmp-proxy.yang:123.42: warning(432): no child node available "
because unquoted strings are node names not values.  And
"      when "snmp:params/snmp:v1 or snmp:params/snmp:v2c"; "
generates the same error message because a solidus is missing while
"         must '/snmp/usm/remote[engine-id=current()]/'
           + 'user[name=current()/../usm/user-name]' "
also generates the same error message which led to a lengthy discussion
about interactions of 'augment', 'when' and such like; the condition got
removed, but the discussions about those interactions continue still, as
in issue Y26 of the enhacements for YANG 1.1.

On a slightly different tack, YANG enumerations have no mandatory value,
unlike SMI, and this has triggered a number of discussions, such as an
ambiguity when RFC6020 says
"the assigned value is one greater than the current highest enum value."
as to what the next value should be. This then has an impact on the
ordering of lists.

Do I know what I am talking about?  On a good day, after I have been
browsing recent posts to the netmod WG list (all of which I read),
maybe; but after a time away from netmod, I struggle.  And the issues
that arise on the netmod WG list suggests to me that those whom I
clearly see are the experts on this topic in the IETF may, at times,
struggle too.

Tom Petch

---

From: Ted Lemon <[email-masked]>
Date: Tue, 9 Dec 2014 09:54:05 -0500

>               + '((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|'

Wow, so there's no way to do this ABNF-style?

> in issue Y26 of the enhacements for YANG 1.1.

This certainly seems quite ugly.   If it can be fixed in an update, that's a positive thing.

> as to what the next value should be. This then has an impact on the

Can this be fixed in an update, or is there some reason why this decision was made?

> clearly see are the experts on this topic in the IETF may, at times,

This is certainly something to be concerned about.   A syntax that is difficult to internalize without working on it full-time is not a good idea.   OTOH, it's hard to have a syntax that is not at least _somewhat_ difficult to internalize if you aren't working on it full time, so to some extent this is a matter of degree.

---

From: Benoit Claise <[email-masked]>
Date: Tue, 09 Dec 2014 16:06:34 +0100

Hi Dan,

> Hi,
>
> Success comes sometimes together with its own risks. In the case of 
> YANG, the risk is that six months or one year from now people who 
> enthusiastically engaged with developing YANG module will have at hand 
> bad modules that do not meet their expectations of functionality, 
> quality, interoperability. The pushback can then follow at the same 
> intensity as the current embracing.
>
This is exactly my concern, and why we have a limited amount of time to 
organize ourselves.

> To avoid this situation we need to provide answers to the problem of 
> non-scalability of the 'Doctors' team model which is IMO real. The 
> answer cannot be just 'let us focus on what we do in the standards 
> track in the IETF' because much of the development of YANG modules 
> happens out of the IETF and this is how we want it to be. We need to 
> encourage the open source and SDOs that engage on the YANG path to 
> develop their own Yangathon events and maybe in time their own YANG 
> doctors teams. We need however to make clear that this is the model we 
> recommend (rather than developing YANG modules and coming to the YANG 
> doctors to review) and offer help in organizing these first activities 
> and teams at their homes.
>
+1.

Regards, Benoit
>
> Regards,
>
> Dan
>
> *From:*ietf [mailto:[email-masked]] *On Behalf Of *Ersue, 
> Mehmet (NSN - DE/Munich)
> *Sent:* Monday, December 08, 2014 7:30 PM
> *To:* ext Benoit Claise; Thomas D. Nadeau
> *Cc:* IETF-Discussion list
> *Subject:* RE: Blog: YANG Really Takes Off in the Industry
>
> Hi Benoit, All,
>
> to be able to reduce the necessary amount reviews and publications, I 
> assume we need to define some categories:
>
> - YANG models might be interesting to have but they don't need to be 
> standardized in many cases. So, the category for Standard track RFC 
> has to be defined with a clear criteria.
>
> - Others may be Informational or Experimental. However for these we 
> need to see the relevance to IETF work and necessity for publication.
>
> - There might be others which are still important to publish but don't 
> have any home. I would discuss them in an OPSAWG meeting and decide 
> whether it should be published in OPSAWG or NETMOD WG
>
> .
>
> The other category I see is related to YANG models which should be 
> matched to another SDO. If we think a model is e.g. related to IEEE or 
> MEF, they should be done there and not at IETF.
>
> There might be also other YANG models which are interesting but not 
> related to IETF. One particular category is concerning models, which 
> were originally Enterprise models but people would like to have an 
> IETF publication.
>
> In general, over time we might need to be strict to stick to the 
> categories and the matched process per category.
>
> That said, I would like to suggest to use the resources of the YANG 
> doctor team for models, which are essential for the IETF at the first 
> place, especially those seen under the category Standard track RFC.
>
> Cheers,
> Mehmet
>
> *From:*ietf [mailto:[email-masked]] *On Behalf Of *ext Benoit 
> Claise
> *Sent:* Monday, December 08, 2014 10:32 AM
> *To:* Thomas D. Nadeau
> *Cc:* IETF-Discussion list
> *Subject:* Re: Blog: YANG Really Takes Off in the Industry
>
> Hi Tom,
>
> doctors scaling issue. You're right, even if the number of YANG 
> doctors recently increased, we need other venues to provide advice to 
> YANG model designers. This should solve the issue of designing 
> properly the YANG models.
> On the other hand, there is a bigger issue, IMO: the proper 
> coordination of those YANG models. This is not the YANG doctors 
> responsibility. This can't be: see the YANG doctors scalability 
> issue.  So who's responsibility is this? Simply asserting "it's the 
> community responsibility" is the easy answer, but I'm afraid it will 
> not work.
>
> Regards, Benoit
>
>     Hawaii and afterwards was around the coordination and
>     encouragement topics. A number of people commented both during
>     these discussions (and I think someone did during one of the
>     Netmod sessions) that the "MIB Doctor" model we are using is not
>     going to scale out to the numbers of Yang models that are in need
>     of advice or review, nor will be scale in terms of progressing
>     models through the IETF's RFC process. The fact is that we simply
>     do not have enough Yang Doctors to cover all of the models in
>     question, despite our best efforts.   It is for this reason that I
>     strongly encourage other venues of review and advice such as a
>     continued "advice" or "Yangathon" session at each IETF meeting
>     going forward, as well as encouraging a loosening of the interim
>     WG meeting rules to encourage more meetings, as well as perhaps
>     less formalized ones.  I also encourage the IETF to start pairing
>     up with other organizations such as OpenDaylight, Openstack and
>     OP-NFV and join their Yangathons there.
>
>     ---Tom
>
>         On Nov 28, 2014:8:12 AM, at 8:12 AM, Benoit Claise
>         <[email-masked] <mailto:[email-masked]>> wrote:
>
>         Hi Jari,
>
>         Focusing on the routing YANG models with
>         "[email-masked]" <[email-masked]>
>         <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_rtg-2Dyang-2Dcoord&d=AAMFAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=I4dzGxR31OcNXCJfQzvlsiLQfucBXRucPvdrphpBsFA&m=EldXn4rzRf97Z5Y7A2KouM2hYYBbL5m9IMpucoilFZE&s=14IGX58lMwSyD8bOPQb_MqlsYeQ3u_s0T7YwNmjqqU0&e=>
>         is a step in the right direction. Indeed the community needs
>         to agree on how to model IGPs, BGP, the topology, etc...
>         However, the coordination should also occur with the data
>         models developed in other IETF WGs. And the IETF might need to
>         reach out to different SDOs/consortia.
>         As the operators told me: we can't afford to develop those
>         data models independently from each others.
>
>         Regards, Benoit
>

---

From: Tim Wicinski <[email-masked]>
Date: Tue, 09 Dec 2014 12:00:45 -0500

> This is certainly something to be concerned about.   A syntax that is difficult to internalize without working on it full-time is not a good idea.   OTOH, it's hard to have a syntax that is not at…

I would concur that is something that the everyday yang user should 
never have to do on a regular basis.  If we do, then we need to fix 
this.  I believe this is why libraries were invented.

tim

---

From: Randy Bush <[email-masked]>
Date: Wed, 10 Dec 2014 02:01:52 +0900

>                + '((([0-9a-fA-F]{0,4}:)?(:|[0-9a-fA-F]{0,4}))|'

when the bsi botched modula-2 standardisation and destroyed the language [0],
professor wirth pinned to his wall the a4 page it took them to describe the
null statement.

this piece of dystopian beauty is worthy of a wall.

randy

--

[0] http://www.scifac.ru.ac.za/cspt/sc22wg13.htm

---

From: Ted Lemon <[email-masked]>
Date: Tue, 9 Dec 2014 12:07:46 -0500

On Dec 9, 2014, at 12:00 PM, Tim Wicinski <[email-masked]> wrote:
> I would concur that is something that the everyday yang user should never have to do on a regular basis.  If we do, then we need to fix this.  I believe this is why libraries were invented.

If by "everyday yang user" you mean an ops person in a data center, then I agree, but that's not what I was talking about.   What I mean is that if yang is hard enough to understand well that only someone who hacks yang models full-time can do it, then that's a bit of a problem since we need people who are experts in the protocols and systems being _managed_ to be writing yang data models.   And those people are not going to be doing yang full-time.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 9 Dec 2014 12:08:50 -0500

On Tue, Dec 9, 2014 at 12:00 PM, Tim Wicinski <[email-masked]> wrote:

>> This is certainly something to be concerned about.   A syntax that is
>> difficult to internalize without working on it full-time is not a good
>> idea.   OTOH, it's hard to have a syntax that is not at least _somewhat_
>> difficult to internalize if you aren't working on it full time, so to some
>> extent this is a matter of degree.
>>
>>
> I would concur that is something that the everyday yang user should never
> have to do on a regular basis.  If we do, then we need to fix this.  I
> believe this is why libraries were invented.

I disagree.

Any tool capable of describing IPv6 should ONLY be used for describing
structures at the packet layer. That is the only layer where bit twiddling
to save a few bytes on the wire is acceptable.

When I design a tool, my objective is to narrow the gap between the
abstract formalism used to describe the specification and the concrete
specification. The above syntax does not look like this is a tool that is
of the slightest use to me because I don't think it reduces the likelihood
of error. I am just as likely to get the specification wrong as the code.

This is why I became disillusioned with formal methods back in the day.

Trying to use one tool for bit twiddling and for application work is a
disaster. The point of a specification is to take away flexibility that
does not matter. YANG is a general purpose tool that lets anything be
specified. I want greater constraints.

---

From: t.p. <[email-masked]>
Date: Tue, 9 Dec 2014 18:36:41 +0000

----- Original Message -----
From: "Ted Lemon" <[email-masked]>
To: "Tim Wicinski" <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, December 09, 2014 5:07 PM

If by "everyday yang user" you mean an ops person in a data center, then
I agree, but that's not what I was talking about.   What I mean is that
if yang is hard enough to understand well that only someone who hacks
yang models full-time can do it, then that's a bit of a problem since we
need people who are experts in the protocols and systems being _managed_
to be writing yang data models.   And those people are not going to be
doing yang full-time.

<tp>

That is my concern. We have had examples in the past where it would be
possible to nail something down completely with ABNF but it was not
considered worth the complexity of doing so - instead, go part way with
ABNF and add a sentence of text/plain that conveys the rest of the
requirement.

YANG has conditionals, 'must' 'when' 'if-feature', which, coupled with
augmentation of one model by another, allow for complicated constructs.
'grouping's and 'container's, presence and non-presence, make for a more
complex model.  I don't think that
"    augment "/rt:routing-state/rt:ribs/rt:rib/rt:routes/rt:route/"
           + "rt:next-hop/rt:next-hop-options/rt:simple-next-hop" {
       when "../../../rt:address-family = 'v6ur:ipv6-unicast'" "
will ever trip easily off my tongue.  (Perhaps I underestimate the
prevalence of XPath 1.0 and the understanding of its contexts).  Yes it
can deliver the sort of integrity checking that the operators asked for
but what I seem to see with the standard models is that it is hard (even
for experts) to get right.  You can automate the checking of the syntax
but does it really have the semantics that the description clause says
it does?  And do we want the expert in a proprietary protocol (SMB
anyone?) to be using this as an exemplar of what YANG should look like?

I used to read (as a child) on the workshop wall 'The supreme excellence
is simplicity' but I had to write code for several years before I
understood what it meant - and became an engineer.

Tom Petch

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 10 Dec 2014 08:39:41 +1300

> Wow, so there's no way to do this ABNF-style?

In fairness, it took numerous attempts to get the ABNF for the text
representation of IPv6 addresses right, with RFC 6874 being the latest
twist (which, if I am not mistaken, is not covered by the above
gobbledygook; at least, I don't see anything in there that seems
equivalent to '"%25" ZoneID', but maybe I missed it).

    Brian

---

From: t.p. <[email-masked]>
Date: Wed, 10 Dec 2014 10:07:44 +0000

----- Original Message -----
From: "Brian E Carpenter" <[email-masked]>
To: "Ted Lemon" <[email-masked]>
Cc: "t.p." <[email-masked]>; "IETF-Discussion list"
<[email-masked]>
Sent: Tuesday, December 09, 2014 7:39 PM

Brian

The question of zone index did come up and it appears in RFC6991 which
has the

" ipv6-address type represents an IPv6 address in full, mixed,
shortened, and shortened-mixed notation.  The IPv6 address may include a
zone index, separated by a % sign."

as well as

"ipv6-address-no-zone ...
An IPv6 address without a zone index "

but whether we should be using a language to achieve such precise
control in the general case I am less sure of.

Tom Petch