On Wed, Sep 9, 2015 at 1:16 PM, Benoit Claise <[email protected]> wrote:
> Dear all, > > There is a lot of passionate debates around YANG these days, which shows > how important YANG became. > > After the last IETF meeting, the openconfig group requested a call with me. > During that call, these operators re-explained their problem to me. > > Let me decompose this into three parts, and again set the stage for this > interim meeting tomorrow. > > 1. The problem statement. > When a group of operators come to the IETF with a problem, we should take > this seriously and embrace it. In other words, nobody can dispute the > operators problem statement. > > 2. The requirements. > If there are still clarifications needed around the requirements in > draft-openconfig-netmod-opstate-01 section 4, or around the requirement > that the YANG models need some sort of hierarchy > (draft-openconfig-netmod-model-structure), like for the routing models, ... > tomorrow interim meeting is your chance, or between now and then on the > mailing list. > > My concern with the problem statement and the requirements in sec. 4 is that they focus on very large systems, yet these problems do not exist on small systems. YANG is being considered in the CORE WG. If and when the CoMI charter addition is approved then YANG will need to support constrained devices. Common modules like ietf-interfaces need to scale well. IMO the authors of RFC 7223 did a great job of not imposing any requirements that assume use-cases or platform resources. All common modules need to be designed the same way. I have yet to hear a number wrt/ how many seconds or minutes does it usually take for intended config to become active config? What percentage of all devices that use YANG have this problem? How fast is the data expected to change while the client is polling it? The solution should not impact systems that do not have these problems that appear to be related to the very large or complex configurations. Andy > 3. The solution: > There are actually 3 different solutions for the operational state. > 3.1 draft-openconfig-netmod-opstate-01, whose version 00 has already been > presented/discussed > 3.2 draft-kwatsen-netmod-opstate, not yet presented > 3.3 draft-wilton-netmod-opstate-yang, not yet presented > Come prepared, and have read those drafts in advance. > This interim meeting should be about comparing solutions around the > operational state solutions. > > We also need understand whether solving those requirements within the > context of NETCONF/RESTCONF (draft-kwatsen-netmod-opstate or > draft-wilton-netmod-opstate-yang) is satisfactory. > > Regards, Benoit (OPS AD) > > Dear all, > > Let me set the stage for this future interim. > > First of (and let me repeat), I'm happy that the operators gathered and > collectively worked on YANG models and related requirements. > > The previous two interim meetings in June on the openconfig issues ( > draft-openconfig-netmod-opstate-01 > <http://datatracker.ietf.org/doc/draft-openconfig-netmod-opstate/> and > draft-openconfig-netmod-model-structure-00 > <http://datatracker.ietf.org/doc/draft-openconfig-netmod-model-structure/>) > were successful in the sense that the requirements are now understood. > > Unfortunately, some key players were not in Prague and we could not > finalize the discussion. > How to represent the operational state is one important guidance from RFC > 6087bis that we must be providing to all existing and future YANG models > (and not only in the IETF). > > We need to bring closure on that topic, and this is the plan for that > interim meeting in September. > > http://datatracker.ietf.org/doc/draft-openconfig-netmod-opstate/ has been > updated. Please comment on this version. > Also, any alternate proposals must be prepared for that interim in > September. They must be prepared with the same level of rigour as > draft-openconfig-netmod-opstate., i.e. must have the same level of details. > > In the meeting in September, the goal is to take a decision. > > Regards, Benoit (OPS AD) > > 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 [email protected]https://www.ietf.org/mailman/listinfo/netmod > > > > > _______________________________________________ > 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
