On Thu, Aug 13, 2015 at 1:14 PM, Nadeau Thomas <[email protected]> wrote:
> > On Aug 13, 2015:4:03 PM, at 4:03 PM, Andy Bierman <[email protected]> > wrote: > > > > On Thu, Aug 13, 2015 at 12:41 PM, Nadeau Thomas <[email protected]> > wrote: > >> >> >> >> On Aug 7, 2015:12:09 PM, at 12:09 PM, Benoit Claise <[email protected]> >> wrote: >> >> Dear all, >> >> During the YANG Model Coordination Group webex call today, we discussed >> this oper status and structure open issues. We're ready to help >> facilitate the discussion between the different proposals >> We could compare the pros/cons of the different solutions from our point >> of view. >> >> To allow us some preparation time, alternate proposals should be posted >> a week before the NETMOD interim meeting, i.e. Sept 3rd. >> >> The YANG Model Coordination Group >> >> Speaking as Co-chair: >> >> Just to clarify a bit on this. The purpose of the next Interim meeting is >> to close on the issues around the Open Config proposal. We meant to do this >> in Praha, but we could not get the right people to attend the meeting to >> have the right discussion. We need to close on this issue as soon as >> possible, as this is possibly blocking a lot of other WG-related work; >> therefore, if no alternative proposals are posted to discuss ahead of the >> interim meeting, then the original proposal will become the solution to >> move forward with in the WG. Alternatives must be complete proposals, not >> bullet points of complaints or such things - they must be a solution or >> they will not be allowed onto the agenda. As Benoit declared above, these >> must be posted ahead of the meeting and will be put on the agenda for the >> meeting to present/discuss/debate as well as to give everyone ample time to >> read and understand the document/s. >> >> > > Are you proposing that all existing RFCs with YANG modules in them be > changed to "obsolete", and new modules published that move the data > under a container named "device" (from some TBD module)? If not, then > what is the proposal for data root placement for existing RFC modules? > > Are you also proposing that all YANG modules with config in them must > define that config in a grouping, and all config must appear in a > container named "config"? Also, that all config data must be replicated > (i.e., use that grouping) under a config false container named <state>? > This will be done even though in 90% of all servers, it doesn't take very > long for intended config to become the active config? If not, then what > is the exact proposal for usage within IETF modules? > > Everyone should understand the impact of these changes. > Silence should not mean "I read the openconfig proposals and > approve of these changes". Only emails to this list that state as much > should mean that. > > > Andy, > > Yes, people should read and understand the proposal. If they don’t like it > please come up with a > viable alternative. If the alternative is to do nothing, then propose that > and we will see what the consensus > is. If the proposal is to constructively alter parts of their proposal, > thats great too. After we get consensus on > the general approach, I will manage things issue-by-issue as we are doing > with other major initiatives in > NETMOD. What we will not do is continue to go round and round about > points of their proposal without > coming to any conclusions. We’ve had several interim meetings where they > have taken the time to > discuss and educate everyone that is interested in how their approach > works and why. To-date, there > are no alternatives being proposed resulting from those discussions - just > more debate/discussion. > What the management is declaring is that the time has come to move forward > on this, one way or > another. > It seems somewhat irregular to declare that silence means agreement to an individual submission (no WG charter, no WG draft). There has not been a debate. There have been proposals, and some people not even agreeing with the the problems. There has been no response why: (1) YANG config=true|false is not good enough to filter, and why extra NP containers called <config> and <state> are even needed (2) YANG constraints written for config=true are not intended to be applied to config=false, yet that is exactly what is proposed with the replicated config under a <state> container (3) Why a new operation called <get-operational> cannot be used to retrieve the actual value in use for /foo There is no guessing required to map 1 path to another. There is no additional cost for the 90% of devices that do not take a long time to apply intended config I agree with Lada that consensus should be gauged by mailing list statements (count the number of non-authors that approve or oppose). This discussion should take place on the mailing list, not another virtual interim that is outside normal business hours for most of us. > —Tom > Andy > > > > > > > Thanks, >> >> —Tom >> >> >> > > Andy > > >> >> Hello,NETMOD Working Group invites you to join this WebEx meeting. *NETMOD >> Interm meeting on OpenConfig*Thursday, September 10, 2015 11:00 >> am | Eastern Daylight Time (New York, GMT-04:00) | 1 hr *Join WebEx >> meeting* >> <https://ietf.webex.com/ietf/j.php?MTID=m54c7bcbed84a08dc78fba128d500f8c0>Meeting >> number:645 732 277 Meeting password:1234 *Join by phone**1-877-668-4493* >> Call-in >> toll free number (US/Canada)*1-650-479-3208* Call-in toll number >> (US/Canada)Access code: 645 732 277Toll-free calling restrictions >> <http://www.webex.com/pdf/tollfree_restrictions.pdf> Add this meeting >> <https://ietf.webex.com/ietf/j.php?MTID=m17086d6b9810a2722c5dc8c64ec795b9> >> to your calendar. Can't join the meeting? Contact support. >> <https://ietf.webex.com/ietf/mc> IMPORTANT NOTICE: Please note that this >> WebEx service allows audio and other information sent during the session to >> be recorded, which may be discoverable in a legal matter. By joining this >> session, you automatically consent to such recordings. If you do not >> consent to being recorded, discuss your concerns with the host or do not >> join the session. >> >> _______________________________________________ >> netmod mailing >> [email protected]https://www.ietf.org/mailman/listinfo/netmod >> >> >> _______________________________________________ >> netmod mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/netmod >> >> >> >> _______________________________________________ >> netmod mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/netmod >> >> > >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
