============================================================= NETCONF Data Modeling Language WG (netmod) IETF #84, Vancouver, Canada Tuesday, July 31st, 2012, 17:00-18:30, Room Regency B Minutes Dan Romascanu, 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) [ 15 min ] - draft-ietf-netmod-iana-if-type-04 - draft-ietf-netmod-interfaces-cfg-05 - draft-ietf-netmod-ip-cfg-05 3) Core routing data model (Ladislav) [ 15 min ] - draft-ietf-netmod-routing-cfg-04 4) Core system data model (Andy) [ 20 min ] - draft-ietf-netmod-iana-timezones-00 - draft-ietf-netmod-system-mgmt-02 5) SNMP configuration model (Martin) [ 20 min ] - draft-ietf-netmod-snmp-cfg-00 6) Modeling JSON text with YANG [ 10 min ] - draft-lhotka-yang-json-01 7) Open mike [ 5 min ] {please identify issues in advance} Summary: Several documents are through their 1st WG last call and there has been useful feedback. Based on the comments, we expect revised drafts by the end of August / beginning of September. The DHCP definitions will be moved to a separate DHCP data model document. More reviews of the routing data model will be provided by routing experts. Additional reviews have been requested for the SNMP configuration data model. The JSON mapping of YANG will not be adopted now since the WG needs to focus on finishing the currently chartered working group items before considering to recharter. Actors: - DR = Dan Romascanu - JS = Juergen Schoenwaelder - AB = Andy Bierman - MB = Martin Bjorklund - LL = Ladislav Lhotka - DK = David Kessens - AM = Andrew McGregor - BL = Balazs Lengyel - BC = Benoit Claise - WH = Wes Hardaker - CE = Chris Elliot - RV = Ruediger Volk - BF = Bill Fenner - KW = Kent Watsen - JH = Jeff Haas Slides: https://datatracker.ietf.org/meeting/84/materials.html Audio: http://www.ietf.org/audio/ietf84/ Meeting Notes (focusing on the open issues discussed): * Interfaces and IP Configuration (MB) ** Operational state data / interface layering It was agreed to add operational state objects indicating the interface layering. Four people in favor on the mailing list and nobody against adding additional objects. ** Vendor specific interface types LL: This approach has the same problems as using identities in general, expressions may not work properly, better use vendor enumeration as well AB: Since this is intended for multiple naming authorities, we have to use an identity since this is the only thing giving us a qname. MB: We could also leave this out and let the vendor do whatever he needs. AB: Or make it a flat string. MB: If we define it, the right thing would be to use an identity. There does not seem much support for adding this, so we will leave it out. ** Add configuration parameters to get IP addresses via DHCP LL: This really belongs to a DHCP data model, even if it would be a feature. BL: If we cover DHCP, then there is likely more than just enable/disable. AB: Does this only show up in the configuration source? MB: We would also add a configuration-source leaf. AB: DHCP is managed somewhere else, outside of our scope. MB: If we do not do it here, why do we do it in the systems data model? AB: I would rather make the data model complete, even if we do another data model later. RV: What other features do we expect to see provisioned via DHCP? JS: DHCP is not just enable/disable, I prefer to have a separate DHCP model. CE: I like to be consistent. If we take DHCP out, take it out everywhere. I like to see a commitment to do a DHCP model. DK: For 80-90% of simple systems, simply enabled/disabled can be enough. MB: What about an rpc dhcp-renew? WH: Do it right, take it out of here or fully specify it somewhere else. BF: Keep this. It might make sense to have something minimal now. WH: Create a minimal DHCP module now, be prepared to revise that later. DK: I see lots of "yes" for this proposal. KW: Allow for extensions. JH: Start simple, make sure namespaces are properly established. DK: Having a mini module in place is for me convincing. MB: Should we put it in a separate document? LL: If we expect this to be documented further, make it a separate document. DK: You can take it later out. JS: We started interfaces, then did IP, now starting DHCP. I like to finish some of the documents. MB: A separate document that can take its time. DK: But DHCP is needed to be useful. DR: If this is standards track, make it a separate document, although updating can also work. MB: A separate document with a single leaf enabled? CE: I would take out the little thing from the system data model as well. DK: The room was in favor of putting DHCP stuff into a separate document. * Routing Configuration (LL) ** Negative RPC responses MB: The text concerning negative responses is still not in sync. LL: Can we agree that the error is 'data-missing'? MB: Remove the text from the main text, the YANG definition should be authoritative. LL: But then do the same with the system model. AB: The active route RPC definition says that if there is no active route, a data-missing is returned. Why is having no route an error? The error really implies something is wrong with the request. Return an empty list instead. ** Change of the route attribute last-modified to age BF: With age, you have to take into account propagation delays and transmission delays. It is kind of easier to have the absolute last-modified time. RV: But this assumes that you maintain absolute time in sync with other boxes. LL: The encoding of data-and-time is longer than an age. CE: The age is always going to be changing, making comparisons more difficult. JH: Would be nice to do things such as I want to see all routes that have changed since a certain point in time. JS: Why did you change it? Because the IP-FORWARD-MIB uses an age? LL: Yes and because age is more compact. JS: SNMP was based on the assumption that a box may not have a notion of wall clock time. LL: Will revert this back to an absolute date-and-time. ** Route attribute names AB: We are setting precedence for hundreds of YANG writers to come. Using the same name for siblings is likely a bad pattern. AB: Local name collisions map badly to the CLI. LL: These siblings never show up together in a valid configuration. ** Further discussion BC: Do we have feedback from the IRS people whether this module solves any of their problems? JS: We met the IRS people today and we recruited one of them as a reviewer. JH: I am one of the routing guys, you made significant progress, now there is a basic reference model. JS: Expect another revision (end of August) and hopefully we are done then. * System Configuration (AB) ** Where to put the configuration-source? JS: The configuration-source defines the order in which different configuration sources are considered? Is adding this not sufficient for the DHCP issue we had with the IP data model? MB: This grouping does not enable DHCP, it only specifies the order. So it must be paired with a second object. MB: It could be made implicit, but I am not sure this is a good idea. ** DHCP NTP configuration LL: If you run DHCP on multiple interfaces, which information do you use to configure NTP? AB: I do not know yet. CE: Since you expect that there might be additional configuration sources in the future, I suggest to move DHCP to a separate module and use that as a template for any future configuration sources. AB: The authors will meet and come up with a proposal and new revision. JS: So likely next revision is then ready for WG last call. * SNMP Configuration (MB) MB: Bugs in the xpath expressions are clear and will be fixed. WH volunteered to review the (D)TLS and TSM definitions. In general, more reviews needed. * Modeling JSON with YANG (LL) This work will not be adapted as a WG work item at this point in time since this would require a charter change. Before revising the charter, the WG needs to finish the work the WG is chartered to do.