============================================================= NETCONF Data Modeling Language WG (netmod) IETF #85, Atlanta, USA Tuesday, November 6th, 2012, 17:00-18:30, Room Salon B Minutes Lisandro Granville, 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-04 - draft-ietf-netmod-interfaces-cfg-07 - draft-ietf-netmod-ip-cfg-06 3) Core routing data model (Ladislav) [ 10 min ] - draft-ietf-netmod-routing-cfg-05 4) Core system data model (Andy) [ 15 min ] - draft-ietf-netmod-iana-timezones-00 - draft-ietf-netmod-system-mgmt-03 5) SNMP configuration data model (Martin) [ 10 min ] - draft-ietf-netmod-snmp-cfg-00 6) Access Control List (ACL) data model (Alex, Andy, Lisa) [ 10 min ] - draft-huang-netmod-acl-01.txt 7) Modeling JSON text with YANG (Ladislav) [ 5 min ] - draft-lhotka-netmod-yang-json-00 8) Operational state (Martin, Ladislav, Andy, ...) [ 20 min ] - draft-bjorklund-netmod-operational-00 - draft-bierman-netconf-get2-02 9) Open mike [ 5 min ] {please identify issues in advance} Summary: The NETMOD working group has met for 1.5 hours on Tuesday, November 6th, during the 85th IETF meeting. The meeting was attended by ~45 people. * The naming issue of the interfaces data model got resolved. There will be updated versions of draft-ietf-netmod-interfaces-cfg and draft-ietf-netmod-ip-cfg shortly after the meeting, ready for a second WG last call. * The routing data model has a few pending edits. Once a new revision is available, this document will be sent to the second WG last call. * The system data model needs some input from RADIUS experts. Once a new revision is available, the document will go to 1st WG last call. * A substantial review of some parts of the document has been provided just before the WG meeting. The editors will update the document to address the comments. This document needs further review by people familiar with SNMP implementations before it can be last called. * A proposal for a set of ACL data models was presented. While this work seems substantial and timely, the WG has to first finish the chartered work before it can consider to take on new work. The authors were encouraged to further refine the data models to make sure the models cover a number of popular firewall / packet filter implementations. The remaining agenda items had to be skipped because the WG did run out of time. Actors: - DR = Dan Romascanu - JS = Juergen Schoenwaelder - AB = Andy Bierman - MB = Martin Bjorklund - LL = Ladislav Lhotka - DK = David Kessens - BC = Benoit Claise - WH = Wes Hardaker - RV = Ruediger Volk - KW = Kent Watsen - LH = Lisa Huang - DL = David Lamparter - PS = Phil Shafer - RV = Ruediger Volk - JJ = Joel Jaeggli - RS = Robert Story - AC = Alex Clemm Slides: http://www.ietf.org/proceedings/85/netmod.html Audio: http://www.ietf.org/audio/ietf85/ Meeting Notes (focusing on the open issues discussed): * Interface and IP configuration [MB] WH: There should be a mechanism to obtain all the available locations from a generic management point of view. MB: When you plug a cable, you need to know where the socket is. MB: We tried to limit the amount of work and not do a physical containment hierarchy as part of this effort. DL: MTU is not well-defined enough. What exactly does it count, the size of the frames or payload? MB: We have to look into the details, please post to the mailing list. PS: This is an issue to address since Junos and IOS devices apparently differ here and that has caused problems in the past. AB: I believe you need to use NETCONF capabilities instead of features since features are designed to be used with if-feature. MB: The feature statement allows that because it doesn’t say the contrary. AB: I strongly disagree YANG allows that. Add a leaf instead. LL: Add a pseudo config false leaf conditional of the feature? PS: I do not recall a requirement that a feature must be referenced by an if-feature statement. AB: We should not redesign YANG now. I think features are just there to make objects conditional. This sounds more like a NETCONF capability. MB: Do we really want to add a dummy leaf? AB: It is not a dummy leaf because it could be referenced in must expressions. PS: But to use it in expression, it has to have a value, which makes it worse, no? PS: It seems using a feature is the least cost solution for the problem at hand. AB: There were proposals to have custom RPCs to help a generic manager to find suitable names. MB: Location would be still needed as input to those RPCs. AB: Industry will not change the way it uses interface names. AB: I like to move forward with the current draft or fix it today. DK: The chairs want to close this issue today as well. LL: I support the proposal that Martin just presented. DK: Is the proposed solution appropriate? MB: That is no change to the data model and addition of examples how to use the data model. DK: Most agreed, no strong objections. JS: Should the server announce that it is capable to support arbitrary names? JS: Most agreed, no strong objections. JS: How should the server advertise support for arbitrary names? AB: A capability would work. MB: I prefer a feature. WH: You could also make it another YANG module... MB: Yes, theoretically, but nobody really wants to do that. JS: Who believes we should use features to announce support for arbitrary names? JS: Some prefer features, no strong objections. MB: Document will be ready by this week to discuss over the list. PS: MTU needs to be defined clearly and be explicit about framing overhead. DL: There can be a difference between IP MTUs and link-layer MTUs. DK: I do not want to move this to the mailing list. Can we solve it here? RV: Is the question what is the most useful thing to do or to stay consistent with what the MIB definition does. Having the MTU change if VLANs are enabled is confusing for configuration. DL: There needs to be a decision whether the MTU report the upper layer MTU or the interface layer MTU. JS: One possible solution might be that the interface MTU is really the frame size while the IP MTU is part of the IP configuration data model. DL: I agree with that. This still leaves the question whether the value is 1500 or 1514. JS: I think it should be layer two. DL: Well, the payload size is always 1500 on Ethernet, regardless of whether there is a VLAN header or not. DK: Martin, did you have enough input from the working group? MB: Will propose a solution on the mailing list. * Core Routing Data Model [LL] RV: Is there any feedback from people active in IRS? LL: Yes, there was a review by Bruno Rijsman. He requested further generalization to support MPLS and 802.1d forwarding. BC: How far is the IRS gap analysis? MB: I don’t know since I am involved since last week. DK: Let’s not look too much to other WGs. Let’s finish our work! KW: I have seen an enable leaf - are we setting a precedent to have enable leaf? Or should we make that a meta data attribute? JS: We are doing what YANG allows us to do today. LL: Attributes may be problematic with a JSON encoding. LL: Lets postpone this for now. MB: I agree, we have to work with what we have today. PS: Should we add support for meta data? AB: I agree we should have better support for meta data. AB: Whether we do it right now or later is another issue. DK: Are we ready for last call and have it published? DK: Many people in favor, no strong objections. * Core System Data Model [AB] AB: Removed data source leafs in favor of a future generic solution for tracking data sources. AB: Adding a leaf to identify the RADIUS authentication type? AB: Should this be an ordered list or is this really just one? MB: This is the RADIUS client configuration, so a simple leaf may be sufficient. JS: Is a leaf sufficient? Do the authentication types not need additional information to work? DL: Why is there RADIUS in this data model at all? AB: This is the configuration of the RADIUS client to authenticate towards a RADIUS server. PS: How do you plan to integrate TACACS and all the rest? AB: We will need help there, this is actually MB's container. JS: I think it would be important to consult with RADIUS experts. DL: Perhaps easier to drop RADIUS since we have also TACACS and we might move faster with the base draft by removing this. JJ: AAA is a core functionality of core router platforms, without it we are pretty much stuck. DK: The goal of this data model is to cover 80-90% of the devices and it remains a judgment call what this is. DL: This is a good answer and I agree. AB: We keep it in for now and we try to get a new I-D out soon. * SNMP Configuration Data model [MB] MB: We tried to remove referential integrity restrictions from the current draft to make it possible to represent incomplete SNMP configurations, enabling a two-way mapping. Wes, did you find concrete places that we missed? WH: I need to check again. WH: I think the VACM mapping enforces referential integrity restrictions. JS: Wes, please take a look and let us know where there are issues. RS: You have objects to configure some transports but some other transports have been left out. Would be nice to cover all SNMP transports. MB: Ethernet? RS: SNMP over TCP for sure, perhaps also SNMP over SSH. WH: You spell out transport details for TLS/DTLS but not for other transports (e.g., listening endpoints). * YANG Data Model for Access Control List Configuration [LH] WH: There are a large number of vendors with different ways how they filter packets and apply access control rules. For example, Linux iptables can be fairly complex. AB: Having an 80-90% solution may be feasible that vendors can augment. I believe we should work this out now rather than doing this in five years from now. A programmatic interface for ACLs is a core component, even though it will be hard to find out what the 80-90% are. BC: I still have customers that do expect scripts to just insert a line into an ACL and it takes forever. This work solves a big problem. WH: The challenge is to have a structure in place that can be extended. DL: Try to minimize the scope, e.g. only doing matching but not any actions. We need to do some divide and conquer to be successful. AC: This is intended to establish a framework, not to be complete. WH: This problem is big enough to warrant a separate working group since it is necessary to attract more people with the right expertise. DK: I see support and also some hesitation. This looks like lots of work. Should we host this effort? BC: Wes, can you provide a list of people that can be contacted to check whether this is going into the right direction or not? WH: There have been BOFs in the past, in particular there has been an IPsec data model (coming out of the IPsec working group). WH: We need to make sure that whatever data model comes out of this must be applicable to simple but also more complex systems. PS: I suggest we first list the features of popular implementations in order to define the scope of such work. DK: It seems people find this important work but we do not seem to be ready to pick this up as a work item.