[i2rs] YANG models fast track (was: IETF 91 meeting requested - call for agenda; status reports?)

[Benoit Claise <[e-mail]>]

Dear all,

Since my name has been mentioned multiple times, let me explain what 
I've been trying to do with the YANG modeling fast track.

http://tools.ietf.org/html/draft-yeung-netmod-ospf-00 was created in in 
Oct 2013 (Then later http://tools.ietf.org/html/draft-yeung-netmod-ospf-01)
It was on the agenda for the NETMOD IETF 88, Nov 2013. See 
http://www.ietf.org/proceedings/88/minutes/minutes-88-netmod
Already at that time, there were discussions to align the OSPF and core 
routing YANG models (what became draft-ietf-netmod-routing-cfg-15 
<http://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/> later). 
See the meeting minutes.
This OSPF YANG model was discussed again during the NETMOD IETF 89 
(http://www.ietf.org/proceedings/89/minutes/minutes-89-netmod).
Read specifically this part of the meeting minutes:

    LL: It is not likely that this working group can do all data models.
           There is an OSPF module which is quite Cisco specific. I have
           one that is Bird specific. It is up to the vendors to work out a
           common model. Experience with the routing module tells us that
           the exposition to routing experts is much less here than in the
           routing area. Leave it to the domain experts to do their data
           models. We can help them but not do their work.

The above, plus the following thoughts _at that point in time_, are 
exactly what triggered my action:
     - there is clear demand for YANG models in the industry, but we 
need to gain momentum.
     - the industry/vendors can't agree ("There is an OSPF module which 
is quite Cisco specific")
     - NETMOD is not the right place for all the YANG models, because we 
don't have the technology expertise. And the other WGs don't have the 
YANG expertise.
     - the IETF is an important point in its life, with more and more 
people going to open source to avoid the heavier consensus-based SDO 
such as the IETF,
       typically opendaylight producing a lot of proprietary YANG models
    - At that time, there were no interest to standardize YANG models in 
the routing WGs.

 From there, I tried to evaluate the willingness from vendors to work 
together. I made an experiment with 3 YANG models (syslog, OSPF, and 
ACL) and 3 companies (Brocade, Juniper, Cisco). See this as closed 
author teams if you want to. IMO, the experiment has been successful.
See http://datatracker.ietf.org/doc/draft-bogdanovic-netmod-acl-model/
See http://datatracker.ietf.org/doc/draft-wildes-netmod-syslog-model/
_What I regret_, and this was mentioned to the authors: there is no 
update of http://tools.ietf.org/html/draft-yeung-netmod-ospf-01, so it 
might be perceived as: the work was abandoned or not open. However, work 
was done to first review and improve the base routing model (Lada is 
point of contact here), and to try to come up with a consistent approach 
for routing (VRF versus protocol centric view) among vendors.

At the last IETF, I've been open, and I explained those closed design teams:
     - to the routing ADs
     - to the IESG
     - during the ///YANG/ Advice and /Editing Session/ 
<http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CCAQFjAA&url=http%3A%2F%2Fwww.ietf.org%2Fmeeting%2F90%2Ftutorials%2Fyang-session.html&ei=fZcoVJuaBIuwyASahIKgAg&usg=AFQjCNFwMZaR904mfhpa8RX196v_CFB6RA&bvm=bv.76247554,d.aWw>
     - to the NETMOD WG:
             See "Accelerated  Development" in the meeting minutes 
(http://www.ietf.org/proceedings/90/minutes/minutes-90-netmod)
             See the slides: 
http://www.ietf.org/proceedings/90/slides/slides-90-netmod-5.pdf

What next? (copied from slides 6 of the above presentation)
     Open up and scale up these design teams
     We will be soliciting the next set of YANG models
     The YANG editing session was a first step to list the existing YANG 
models
     Goal: Stretch goal to publish YANG model RFCs within a year
     Where? In the different WGs or in NETMOD (charter is now open)

I'm exactly in that process of collecting the interesting YANG models 
the vendors want to work on.
Why a focus on the vendors? Because I want to focus on the device-level, 
protocol-specific YANG models (the building blocks). Not the services ones.
These days, I'm compiling the list of interesting YANG models from 
multiple vendors: Juniper, Brocade, Huawei, Ericsson, Ciena, ALU, and 
Cisco. More companies are obviously welcome. The findings will be 
shared, don't worry.
 From here, the different WGs (not speaking about routing specifically) 
should organize official design teams, organized by the WG chair. For 
example, to create the version 00 of the draft. Based on my experience 
from those closed design teams, what worked well, and should be followed 
IMO.
     - one point of contact per company to work on the draft (too many 
authors dilutes the responsibility
     - this point of contact should be close the development team
     - ideally, these should different people for the different YANG 
models (we want this process to scale)
     - weekly webex proved to work efficiently
     - a willingness to implement (we learn a lot from implementation)

Is this NETMOD taking over the world of YANG models standardization?
Certainly not. My goal is to get the right experts together.
Coming back to the OSPF model, the experts are not NETMOD expert: Kent 
Leung, Dean Bogdanovic, Kiran Koushik. As you can see, these are not the 
tyipcal YANG experts in the NETMOD WG.
Also, In order to facilitate their work, I have assign a YANG doctor. 
See http://www.ietf.org/iesg/directorate/yang-doctors.html -> YANG 
review assignments 
<http://trac.tools.ietf.org/area/ops/trac/wiki/yang-doctors-review-history>
Where should these YANG models be standardized? Honestly, I don't care, 
as long as we right the right experts. Ideally they should be 
standardized in the respective WGs. Note that the NETMOD charter has 
been open to welcome the YANG models that don't have an appropriate home 
(example: syslog)

As you can see, no willingness to hide anything with this fast-track, 
simply an OPS AD who humbly tries to organize an industry/vendors/a 
community to work together. I have not coordinated enough I2RS (and I 
don't follow the I2RS mailing list, it's just archived in a folder but 
recently I had to read it :-) ), that's probably a mistake. On the other 
hand, from what I can see from the different vendors, there is a 
willingness to implement non I2RS/routing YANG models: QoS,  VLAN, AAA. 
So why warn only the I2RS WG on the not the rest of the community?
Btw, I believe that creating this mailing list for routing YANG models 
coordination would be a plus.

Regards, Benoit (OPS AD)


> Thomas,
>
> On Mon, Sep 29, 2014 at 2:44 PM, Thomas Narten <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>     > It is NOT OK to tell anyone that they should not contribute a draft - because
>     > it may muddy the water
>     > or for ANY other non-technical reason.  Individual drafts or
>     desire to request
>     > WG adoption do not change
>     > this.  I do not ever want to see or hear something like this on
>     an IETF
>     > mailing list.
>
>     Let me defend Acee here a bit and try to chart a course a bit more
>     down the middle. When a WG has an effort underway that is intended to
>     lead to a WG document (and that is what I read the current "design
>     team" effort to be), it is IMO often not helpful to have yet more IDs
>     submitted on the same topic. Rather than complementing the existing
>     work towards a concensus result, additional IDs can be a distraction
>     and require folk to spend time figuring out how the other ID relates
>     to the WG effort. I.e., it's much more constuctive to say "here is
>     what is defficient in the current model, and here is what I think we
>     should do instead". It is much less constructive to have a standalone
>     ID that (probably) overlaps with the other IDs and doesn't focus on
>     the *differences* from the other work that already has a head start.
>
>
> First, I have been encouraging the routing WGs to work on and consider 
> YANG models.
> I have been quite clear in discussing with Benoit that they should be 
> homed in the Routing
> area and that I don't think it makes sense to create a separate 
> working group to just work
> on YANG models.
>
> Second, the assumption that we have had with I2RS is that it will need 
> different and possibly
> more limited models than would be used for configuration of a 
> particular protocol.  A reasonable
> approach could be doing the I2RS-specific models in I2RS and having 
> them cross-reviewed in
> the relevant protocol working-groups.  This is the path that, as I 
> understand it, Sue was working on.
> It would allow review of the interactions between the different models 
> for their I2RS aspects (assuming
> that the WG believes that there are some).
>
> Third, individuals have been working an individual draft 
> (draft-yeung-netmod-ospf-01) for an OSPF configuration YANG model.  
> This was discussed in OSPF last IETF.  I agree that the updated draft, 
> when posted, is likely to be an excellent candidate for the OSPF WG.
>
> However, regardless of whom may be working on writing 
> draft-yeung-netmod-ospf-01 or who may have been going behind the 
> scenes pushing and encouraging (and I am also quite happy and eager 
> and encouraging to see good YANG models for routing functionality), 
> this is not an official design team
> effort.
>
> Deliberately writing a competing draft may not be constructive.  That 
> is not what happened here and
> it was the combination of trying to incorrectly privilege an (expired) 
> individual draft that was written to solve a different problem and 
> asking for someone  who had done work to produce a draft towards a 
> different problem that caused me to be extremely displeased.
>
>  I realize that one of the topics of discussion since the netmod 
> interim has been whether it makes sense to have one YANG model that 
> can be used by NetConf and I2RS for writing and reading.  However, I 
> have not heard discussed much less agreed upon that approach in I2RS 
> and it is inappropriate to presuppose the answer and punt work that it 
> is quite reasonable to assume (and examine to determine) will move the 
> WG forward.
>
>     It is the case that the IETF mantra is "submit a draft", but frankly,
>     I think that is a bit of a sound bite that we would do well to not
>     spit out as often as we seem to because it too often misses what
>     really should happen, namely, how best to contribute to reaching
>     consensus in a WG. We have a huge problem today where there are
>     overlapping/competing drafts that WGs have to sort through. And in
>     many of those cases, additional IDs have very little additional
>     content than what already exists. But since we go around telling folk
>     to "submit an ID", we shouldn't be surprise that we get them beyond
>     the point of diminishing returns. (And I am NOT saying that the draft
>     at issue here is one of those.)
>
>
> Please let's not try to conflate one specific case with its own 
> concerns with
> generalities.  That is not constructive.
>
>     In this case (and I personally don't have any skin in the game), it
>     seems to that both parties are making honest efforts to do the right
>     thing, but unfortunately, the state of play was not fully known to
>     all.
>
>
> Yes, this is communication and clear communication is needed.
>
>     > Very very few drafts start perfect and different models have
>     > different perspectives.  The IETF has a consensus process, as you
>     > well know of course, to resolve differences between perspectives and
>     > drafts.
>
>     I didn't hear anyone say that consensus has already been called.  My
>     take away is that we have a WG making an honest effort to move forward
>     in a particular direction and it is doing exactly what it should be in
>     terms of getting behind a design team effort. And IMO, once you have a
>     WG design team working on an effort, having others submit drafts in
>     the same space is not always what we should be encouraging people to
>     do.
>
>
> There IS NOT a WG Design Team in OSPF working on the YANG model.  There
> are individuals, whom were encouraged to work together, but that does 
> not make it
> a design team.  IFF there were an announced WG Design Team and IFF 
> there were
> consensus in I2RS that I2RS would use exactly the same YANG models, 
> then this
> point might hold water.   Since neither are the case, I do not believe 
> that it does so.
>
>     Does that mean we should not allow additional IDs? Of course not. Does
>     it mean we won't look at them and give them consideration"? Of course
>     not. But we should also be honest that if a WG has an official
>     document or has a DT working on a document, having additional
>     "competing" documents show up is often not the most constructive way
>     to contribute. Unless news IDs really are clear about how they relate
>     to the other efforts and what those other efforts are lacking.
>
>
> Yes - and official WG design teams are different from a group of 
> individuals.  To be
> extremely clear yet again, this is a group of individuals.
>
> Regards,
> Alia
>
>     Thomas
>
>
>
>
> _______________________________________________
> i2rs mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i2rs