On Mon, Sep 29, 2014 at 5:41 PM, Acee Lindem (acee) <[email protected]> wrote:
> > > From: Alia Atlas <[email protected]> > Date: Monday, September 29, 2014 at 5:33 PM > To: Acee Lindem <[email protected]> > Cc: Thomas Narten <[email protected]>, Jeff Haas <[email protected]>, " > [email protected]" <[email protected]>, Susan Hares <[email protected]> > Subject: Re: [i2rs] IETF 91 meeting requested - call for agenda; status > reports? > > Acee, > > On Mon, Sep 29, 2014 at 4:49 PM, Acee Lindem (acee) <[email protected]> > wrote: > >> Thanks Much Thomas! Given that I was the victim of considerable back-door >> escalations and machinations, I was giving myself a ³cooling off² period >> prior responding. However, you expressed my sentiments with much more >> patience than I could have myself. Moving forward, we are going to have to >> agree on a home for these protocol models drafts. Of course, my preference >> would be to keep them in the protocol WGs with I2RS and I2RS review. Given >> the IESG statement on YANG models replaced MIBs >> (<http://www.ietf.org/iesg/statement/writable-mib-module.html>), I had >> viewed this as self-evident. > > > First, I really appreciate that you gave yourself a cooling-off period > before responding. > I did exactly the same thing before responding. The last thing that is > needed or desired > is escalations. I think this is an excellent practice when email > conversations get heated. > > Second, what I have been encouraging is absolutely that the YANG > configuration models > should go to each protocol group. What is confusing the situation here is > that the I2RS related > models are not/have not been assumed to be the same thing. Instead, the > assumption has been > that they would be more limited and perhaps have I2RS specifics (such as > for events) - and > therefore would happen in I2RS and also be discussed in the specific > protocol WG. > > Third, there was discussion on the mailing list and at the interim about > "option 4" which is > pushing I2RS to use exactly the same YANG models. I have seen discussion > trying to understand > what this would look like but certainly nothing around consensus that that > should be the case. > > > I would hope that we have a single model for NETCONF and I2RS or at > least a core OSPF model that contains the large intersection. > Yes, one of the things that Jeff has been actively working on is coordination between models, understanding what should be groups for reuse, etc. The desire to have a large intersection defined only once is part of why getting good IM/DM from the I2RS perspective is really useful too. For something like the RIB DM, it's easy to talk about events (active/inactive, etc) that one doesn't see or expect in a non-I2RS model. Whether we have the similar events and other examples for OSPF is the question. > My strong reaction and email was to several things that I saw happening > together: > a) Efforts to privilege an individual draft (expired) and push away > other approaches. I do understand that it was very well received last > IETF, that a new version will be out soon, and that you can't ask for WG > adoption in OSPF until that occurs. > b) A claim that the draft targeted at a config model for OSPF was all > that was needed for I2RS (prejudging the situation) > > > The latest OSPF model includes operational state as well as > configuration and this is one reason why it has taken a long time to > publish. > Yes - unfortunate though because I believe that it has changed significantly from what is published and that makes it basically impossible to review. I do know that the authors are trying to get out a new version very very soon; this isn't trying to push them more. I look forward to reviewing it (and I don't say that about many drafts these days). Regards, Alia > > Thanks, > Acee > > > > I know that we want to get really great YANG models out of this and > encourage more > people to work in this space and also want to see I2RS make actual > progress. > > I also agree that there are better ways for people to collaborate than > to go away and write a competing draft - but I do not think that was the > intent or what happened here. > > Regards, > Alia > > > >> Acee >> >> On 9/29/14, 2:44 PM, "Thomas Narten" <[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. >> > >> >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.) >> > >> >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. >> > >> >> 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. >> > >> >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. >> > >> >Thomas >> > >> >> >
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
