============================================================= NETCONF Data Modeling Language WG (netmod) IETF #87, Berlin, Germany Thursday, August 1st, 2013, 17:00-18:30, Tiergarten 1/2 Minutes Nikolay Melnikov, Juergen Schoenwaelder ============================================================= WG Chairs: David Kessens Juergen Schoenwaelder WG URL: http://tools.ietf.org/wg/netmod/ Jabber: xmpp:netmod@jabber.ietf.org Agenda: 1) Administrivia (chairs) [ 5 min] - minutes scribe {volunteers welcome in advance!} - jabber scribe {volunteers welcome in advance!} - blue sheets - agenda bashing - status and milestones 2) Core interface data model (Martin) [10 min] - draft-ietf-netmod-iana-if-type-07 (WG last call until 2013-07-22) - draft-ietf-netmod-interfaces-cfg-12 (WG last call until 2013-07-22) - draft-ietf-netmod-ip-cfg-09 (I-D update pending) 3) Core routing data model (Martin, Ladislav) [15 min] - draft-ietf-netmod-iana-afn-safi-00 - draft-ietf-netmod-routing-cfg-10 4) Core system data model (Andy) [10 min] - draft-ietf-netmod-iana-timezones-00 (WG last call until 2013-07-22) - draft-ietf-netmod-system-mgmt-08 (WG last call until 2013-07-22) 5) SNMP configuration data model (Juergen) [15 min] - draft-ietf-netmod-snmp-cfg-02 (I-D update pending) 6) YANG data model for network topology (Jan) [15 min] - draft-clemm-netmod-yang-network-topo-00 Summary: The NETMOD working group has met for 1.5 hours on Thursday, August 1st, during the 87th IETF meeting. The meeting was attended by ~50 people. * Several documents are in WG last call and more reviews are needed. Some additional people were recruited during the meeting to perform reviews. * The routing documents are technically complete. Lada will work with authors of the I2RS working group to harmonize things with the information model defined by the I2RS working group but this must be completed the latest by the next IETF meeting in Vancouver; the NETMOD WG is not going to wait for the I2RS WG to complete its work. * Some minor issues need to be resolved on the SNMP configuration model. The next revision is expected to be complete and ready for WG last call. * A new individual draft was presented and discussed which defines a generic data model for presenting network topologies. This I-D is related to an information model submission to the I2RS WG. * The open mike discussion centered around the future role of the WG, if it is time to move data model work out of NETMOD into other working groups, how to provide guidelines to data model writers, and whether the YANG specification should be revised to make it less dependent on NETCONF concepts and whether new features should be added the YANG. Actors: - JS = Juergen Schoenwaelder - AB = Andy Bierman - MB = Martin Bjorklund (via Jabber) - LL = Ladislav Lhotka - DK = David Kessens - BC = Benoit Claise - KW = Kent Watsen - BL = Balazs Lengyel - BW = Bert Wijnen - DL = David Lamparter - JM = Jan Medved - DB = Dean Bogdanovic - AM = Adam Montville - JH = Jeff Haas - LF = Luyuan Fang - DW = David Waltermire (?) - DH = David Harrington Slides: http://www.ietf.org/proceedings/87/netmod.html Audio: http://www.ietf.org/audio/ietf87/ Meeting Notes (focusing on the open issues discussed): * WG status and milestones - BC states that it is good to see more and more YANG modules. However, more reviews are needed for existing chartered work in order to be able to finish it. Chris Elliott has volunteered to review NETMOD documents as well as Susan Hares. Authors of new drafts should also help to finish up existing chartered work since this will help their proposed work as well. - AB states that two of drafts in WG last call are just large YANG translations of IANA registries that no one cares about, since they were not touched in months. People lose interest in reviewing micro-incremental edits for many times. I checked the diffs. I have no comments and no objections. These drafts had a lot of reviews. Maybe we need to bring in more outsiders for more reviews. - DK states that complete silence during WG last call is scary, but saying something short and confirming is helpful. - BW offered to review the documents if he gets two weeks to do this. * Core interface data model - No comments were raised on these documents, no slides, no presentation. * Core routing data model http://www.ietf.org/proceedings/87/slides/slides-87-netmod-2.pdf - LL implemented the separation of operational state from configuration state following the interfaces data mode. However, YANG leafrefs cannot refer to config false nodes - this may require to create dummy configuration entries. LL considers this a crappy little rule (CLR). - AB states that the decision to have config true/false (even though perhaps not the correct design decision) is essential for NETCONF implementations and not just a CLR. - LL asks why do I have to create a dummy configuration entry? - AB explains that the configuration datastore is really distinct from operational state and hence must be complete and can only be further constrained by other configuration. AB believes this was a good decision. - LL says we just refer to a name, and if the system can find it, then it should be okay. - BL mentions that there was an instance required modifier proposal that could have solved this. - AB but this never made it into YANG. We also had originally three states (transient configuration) but this was taken out. These rules can't be easily changed and require to revise the YANG specification. - DL suggests to perhaps add another kind of reference that is treated a bit differently. - BL states that this is what he believes instance required was. - AB explains that the reason for this rule is to allow off-line validation. - LL suggests to discuss this further on the mailing list. - LL suggests that there is an inconsistency with the guidelines document (section 4.9 of RFC 6087) since we now move towards a design pattern with multiple top-level containers. - AB says that we need to consider updating the guidelines. - JS asks the question how we deal with the relationship to the routing information model developed by the I2RS working group. It would be nice to have consistency here. Shall we move ahead with what we have or shall we wait until the I2RS work becomes stable or something in between? - LL I think we should go ahead, as I2RS is just forming information models, so it will take them a few years, and we cannot wait for that long. Maybe we could change something later in this data model, but we have to do it anyway. - JM (co-author of the information model draft submitted to I2RS) has met with LL in order to find out where any differences are. There are lots of unknowns about the differences at this point in time. We need to compare item by item what the deltas are. - LL says that this likely can be done until the next IETF. - DK asks whether there is a reason why we have to wait for the next IETF? Can this be done earlier, using the mailing list? - JM says sure we can do that as well as the work proceeds. - BC says that I2RS milestone for the information model document is February 2014. Do you think it is feasible, and what is your plan. How long should we be waiting. I am in favor of being in sync (with I2RS). - JM says that February 2014 may still be feasible. - JS suggests that the maximum timeout for the delta analysis should be the Vancouver IETF. - LL expects to post a revised I-D of the routing data model before the Vancouver meeting. * Core system data model http://www.ietf.org/proceedings/87/slides/slides-87-netmod-0.pdf - AB reviews the changes and asks for more reviews. - DK believes that the changes to this draft were much more incremental compared to the interfaces draft. - AB agrees and repeats his suggestion that the WG may need to update the guidelines document (RFC 6087) at some point in time to reflect the current practice. * SNMP configuration data model http://www.ietf.org/proceedings/87/slides/slides-87-netmod-4.pdf - JS expects the next revision of the I-D to be complete from the author's point of view. * YANG data model for network topology http://www.ietf.org/proceedings/87/slides/slides-87-netmod-3.pdf - JM presents the basic concepts of the topology data model. - BL asks unidirectional point-to-point links were chosen to the topology. - JM responds that the idea was taken from l3 protocols. They represent topologies via unidirectional links and it turns out to be a very generic way of representing topologies. Links can have very different attributes in each direction. - BL raises some questions concerning broadcast links. - JM suggests to take this to the list and to work this out with routing experts. - DL is the purpose of this to report operational state about the current topology north-bound? If so, why is everything read-write? - JM yes and you raise a good point. - MB asks why did you model this as configuration data? - JM responds that this should be config false (read-only) data. - BL says that there are sometimes internal interfaces that are only connected to some of the nodes. There should be a way to represent how interfaces are interconnected. - JM we represent abstract nodes (or topology nodes), not necessarily real interfaces. - BL says that there should be a clarification how this mapping to real interfaces works. - JS asks how many people have read the document. About 5 people plus some unclear signs. - JM we hope to further develop this until Vancouver. - DL suggests to add some examples. - JM agrees and this comment was also raised in the I2RS working group. * Open mike - LL says that YANG is being used in other places but not specifically in combination with NETCONF. Several definitions in the YANG specification make use of NETCONF concepts. Should this WG review the YANG specification to make it less dependent on NETCONF? - DB supports this view as it will help using YANG for other purposes. - AB says that changing YANG needs to be done very carefully. It may be too early to do this and it seems YANG can already today be adopted to other protocols using extensions. Applying YANG to YANG-API / RESTCONF is mostly straight-forward as long as we talk about data nodes. - JM supports LLs suggestion. There also was an I2RS document detailing YANG extensions that would be likely needed. YANG is also being adopted by the open daylight project and we have tools to produce code withing a system that need extensions of YANG. - AM says that the SACM working group is looking at YANG and they might use YANG for network access control. I support YANG being more NETCONF independent. - AB sees YANG data models being submitted but how do we deal with them? Do we move the data models to other working groups while the NETMOD working group focuses on the maintenance of the YANG language? AB likes to see proposals being worked on. - ?? supports to move the writing of YANG data models to other working groups while NETMOD should focus on the maintenance of the YANG language. - JH says that this WG is becoming a victim of success and you have to maintain YANG. While moving work to other working groups, be aware that this working needs to help them getting the data modeling right. - MB agrees to the idea of revisiting YANG and that it makes sense to move data modeling work to other working groups. Maintenance of YANG should be done in NETMOD. - AB says that in the MIB development space, we achieved good results when we got language and modeling experts work together with domain experts. - AM says working together would be wonderful if this can be made to work. - LF asks whether we can agree that work on YANG belongs to this WG while work on subject specific data models belongs to other working groups but then to be reviewed here? - DK sees a consensus developing into that direction, but he is not sure there is agreement on the time-line. Might need input from the area directors. - LL observes that for some work items there are no working groups (e.g., route filters or stateless packet filters). - DW is working in the SACM working group and he finds good guidance on how to use YANG very useful. - BC is happy to see technology used in multiple WGs. We may need to provide guidance but there are also documents that do not have a home. It is unclear how we ensure that documents using YANG get sufficient review and yang-doctors may not be enough. - DK as a contributor believes it is likely too early to make a decision since people need to develop more expertise. As WG co-chair, do we need to make decisions about this today or is this more an informal discussion that will come up at the next IETF. - JM states that YANG is not yet decided by the I2RS working group. He considers this discussion an informal discussion to be continued. - LF sees two level of reviews. Expertise by the subject matter experts and a review beyond the language itself to ensure higher-level consistency beyond the language itself. - DH says that this area of the IETF has experience with organizing reviews. It is not this WG's decision what other WGs do or not. It is important to review WG charters and to provide input to the Area Directors (BC in this case) to influence how the IESG approves charters. While there are YANG guidelines, what is missing are guidelines how to design data models properly. RFC 5706 may be reviewed and perhaps some of its content applies to designer of YANG data models. - BC prefers to have information models in WG charters instead of data models. Design guidelines are clearly useful to have, in particular also with a view of code generation. - DB believes we should have a better understanding of how to decouple YANG from NETCONF so that we can take an informed decision in Vancouver. - BL says that there have been new requirements on YANG. Is there anything we do about them? - LF believes that the scope of YANG data models is bigger than what we did in the past with MIB modules. Concerning timing, we should discuss but decide better sooner than later. - LL believes that there a number of bugs or enhancements for YANG but we need to be very careful that we do not start boiling the ocean or rehash discussions we had before. - KW believes that maintaining and enhancing YANG should be the primary activity of this working group. KW is in favor of opening the YANG specification and adding new capabilities to YANG. - DH disagrees with KW. What is needed are more data models. Operators said at the IAB workshop that one reason to not use SNMP is that data models are incomplete. It is also important to not send the signal that YANG is unstable to the industry. - KW says that Juniper is interested in YANG for JunOS, but it is not fully able to express what Juniper needs. We are working around this with proprietary extensions. - MB says if we revise YANG (RFC 6020), we need to concentrate on things that cannot be done with YANG extensions.