I'm new to this IETF thing, but from my other experiences - silence means "I don't care". "Yes" means "yes".
"Do nothing ... for now" is a perfectly good response to a proposal that isn't generating the expected interest. -- Ashesh > On Aug 13, 2015, at 1:44 PM, Nadeau Thomas <[email protected]> wrote: > > >> On Aug 13, 2015:4:32 PM, at 4:32 PM, Andy Bierman <[email protected]> wrote: >> >> >> >> 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). > > That is how we do the Yang 1.1 design team work right? The mini-team > makes a recommendation and if no one objects, it goes forward. Seems > like the same thing to me. The point is that ample time has been given > for anyone to object. There is still time now too - but we are limiting that > time so that the WG can move forward with or without this proposal. > >> There has not been a debate. > > There have been several interim meetings and this was discussed > at now two full meetings. There have been ample opportunities for debate. > >> There have been proposals, >> and some people not even agreeing with the the problems. > > That was not the outcome of the last interim meeting. If others > do not agree, then they need to speak up. > > —Tom > > >> 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 >>>>>>> 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 277 >>>>>>> Toll-free calling restrictions >>>>>>> >>>>>>> Add this meeting to your calendar. >>>>>>> >>>>>>> Can't join the meeting? Contact support. >>>>>>> >>>>>>> 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 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 > > _______________________________________________ > 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
