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 <[email protected]
<mailto:[email protected]>> 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
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
