WG, An update on this topic is overdue (my fault). A large part of the delay has been figuring out how to proceed with the conclusions from the analysis. Basically the/my conclusion is that none of the solution fulfills all requirements/considerations and that having a discussion centered around picking one (or even how our analysis got it wrong) isn't the right place to focus anyone's energy.
I have therefore asked the that the authors to work together to come up with and propose a unified technical solution. I'll update the WG when I have some thing to report, which might include that I don't think a unified proposal is going to happen or that a new proposal will soon be put forward. Lou PS I do expect that the analysis will be published at some point in the future for general reference. My current thinking is at the same time as the unified solution. (Although, as Benoit initiated the analysis, he's the one who really gets the final say.) The analysis has been shared with the solutions authors. If you really want to see the analysis now, send me mail and I'll send you a link. On 12/15/2015 4:30 PM, Benoit Claise wrote: > Dear all: > > Background: the operational state is a blocking factor for the > publication of the YANG models. For example, I've been told that the > ISIS and OSPF models are ready, pending resolution on the operational > state. > > Let me try to clarify the situation and the next steps. > > During the NETMOD WG meeting in Yokohama, Kent, as a chair, did a hum > related to draft-ietf-netmod-opstate-reqs-00 > <http://datatracker.ietf.org/doc/draft-ietf-netmod-opstate-reqs/> > As explained during the previous operational state-related interim > meetings, we wanted to extract the requirements. > Kent carefully asked: "humm if in you are in favor of the definitions > of the requirements", meaning: have we correctly documented the > requirements? > draft-ietf-netmod-opstate-reqs-01 > <http://datatracker.ietf.org/doc/draft-ietf-netmod-opstate-reqs/> will > be published soon, with no changes to the requirements scope, but only > clarifying text and editorial changes. > Once published, a WGLC will follow, with hopefully a quick publication. > > Now, what is the next step regarding the solution? > As mentioned during the NETMOD meeting in Japan, there are currently 3 > proposals: > 1. openconfig draft-openconfig-netmod-opstate-01 > <http://datatracker.ietf.org/doc/draft-openconfig-netmod-opstate/> > 2. based on the data stores draft-kwatsen-netmod-opstate-00 > <http://datatracker.ietf.org/doc/draft-kwatsen-netmod-opstate/> > 3. based on the metadata draft-wilton-netmod-opstate-yang-01 > <http://datatracker.ietf.org/doc/draft-wilton-netmod-opstate-yang/> > > During the NETMOD WG meeting, Kent asked the sense of the room on > which solution the community favored. There was an advantage for > solution 2. > However, we want to make that the WG to make an informed decision. > > Kent and I have searching for independent people who could analyze the > different solutions, and provide the pros/cons of each solutions. Note > that some of this has already been done (Rob Wilton's presentation in > Yokohama, YANG Model Coordination Group email to the list, etc.) > Lou Berger and Acee Lindem have agreed to help with this, with a > tentative date of Jan 15 for an initial analysis. > They will start collecting the arguments. Please direct emails to both > of them ([email protected], [email protected]). Note that for discussions, > the WG mailing list is more appropriate. > > This process should ease the solution selection. > > Regards, Benoit > > > > > > > > > > > > > > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
