> 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] 
> <mailto:[email protected]>> wrote:
> 
>> On Aug 13, 2015:4:03 PM, at 4:03 PM, Andy Bierman <[email protected] 
>> <mailto:[email protected]>> wrote:
>> 
>> 
>> 
>> On Thu, Aug 13, 2015 at 12:41 PM, Nadeau Thomas <[email protected] 
>> <mailto:[email protected]>> wrote:
>> 
>> 
>> 
>>> On Aug 7, 2015:12:09 PM, at 12:09 PM, Benoit Claise <[email protected] 
>>> <mailto:[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 
>>>> <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 277
>>>> Toll-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 list
>>>> [email protected] <mailto:[email protected]>
>>>> https://www.ietf.org/mailman/listinfo/netmod 
>>>> <https://www.ietf.org/mailman/listinfo/netmod>
>>> 
>>> _______________________________________________
>>> netmod mailing list
>>> [email protected] <mailto:[email protected]>
>>> https://www.ietf.org/mailman/listinfo/netmod 
>>> <https://www.ietf.org/mailman/listinfo/netmod>
>> 
>> 
>> _______________________________________________
>> netmod mailing list
>> [email protected] <mailto:[email protected]>
>> https://www.ietf.org/mailman/listinfo/netmod 
>> <https://www.ietf.org/mailman/listinfo/netmod>
>> 
>> 
> 
> 

_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to