============================================================= NETCONF Data Modeling Language WG (netmod) IETF #79, Beijing, China TUESDAY, November 09, 2010, 1300-1500, Room Valley Ballroom A Minutes Andy Bierman, 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 2) Work items from previous charter [chairs][ 10 min ] RFC editor queue: - draft-ietf-netmod-arch-10 (waiting for draft-ietf-netconf-with-defaults) - draft-ietf-netmod-dsdl-map-10 - draft-ietf-netmod-yang-usage-11 Published RFCs: - RFC 6020 (draft-ietf-netmod-yang) - RFC 6021 (draft-ietf-netmod-yang-types) 3) New work items For each draft: if applicable, current status, delta from previous draft, open issues, and discussion. 3.1 Core system data model Possible starting point: - draft-bierman-netconf-system-monitoring-00.txt Status: new submission (Andy Bierman) 3.2 Core interface data model Martin Bjorklund is working on a concrete proposal for a base data model 3.3 Core routing data model that can be augmented with routing protocol specifics Ladislav Lhotka is looking at RPSL 3.4 SMIv2 translation to YANG Possible starting point: - draft-schoenw-netmod-smi-yang-00.txt Status: expired, but possible work item for new charter Earlier presented slides: http://www.ietf.org/proceedings/78/slides/netmod-1.pdf http://www.ietf.org/proceedings/75/slides/netmod-0.pdf (Juergen Schoenwaelder) 4) Other (non WG) Internet-Drafts, for feedback and discussion [chairs, we will only spend time on these items if we have time] - draft-bjorklund-netmod-snmp-cfg-00 Status: new submission - draft-chen-netmod-yang-ext-00 Status: new submission - draft-linowski-netmod-yang-abstract-04.txt Status: AD sponsored (Bernd Linowski) 5) I/O with other WGs (NETCONF/IPFIX/others ?), activities this week [chairs] 6) A.O.B. and open mike [N.N.] {please identify issues in advance} Summary: The NETMOD working group was rechartered in October. During the WG meeting at the 79th IETF, the WG discussed some proposals of what the chartered core data models should include, how generic or specific they should be, how they should be structured, whether they should support network-wide data models etc. Some interested people are planning to meet later during the IETF week to produce perhaps consolidated input for the WG to review. Some open issues for the SMIv2 to YANG translation were presented and closed. The individual I-D was accepted as the basis of the WG document (to be confirmed on the WG list). Actors: DK - David Kessens JS - Juergen Schoenwaelder AB - Andy Bierman MS - Martin Swaney MB - Martin Bjorklund BW - Bert Wijnen P? - Peter ? DR - Dan Romascanu WH - Wes Hardaker LL - Ladislav Lhotka RV - Ruediger Volk ME - Mehmet Ersue Slides: https://datatracker.ietf.org/meeting/79/materials.html Audio: http://www.ietf.org/audio/ietf79/ietf79-ch6-tue-noon.mp3 Meeting Notes: * Andy Bierman - originally posted to NETCONF WG - notifications used and system container not used - 4 people have read it - no discussion of details - need to agree on requirements - need more volunteers; maybe meet offline during the week to get a more concrete proposals on the table MB: Move user objects from nacm document to system draft? AB: The term "system" is overly generic and we do not know what this is. AB: I was thinking about configuring the system's time. Or is SNMP's system group the target? BW: My understanding is that NETCONF only works on NETCONF specific objects, while NETMOD works on the overall system related objects JS: Believes that NETCONF agreed to move user / account objects out of nacm into NETMOD. DK: The first draft in this area should include a section spelling out requirements (not a separate requirements document but more an initial section discussing the requirements addressed). AB: What is supposed to be in the system group? AB: Being able to configure time is valuable and system time is a system property. User configuration involves the question whether these are NETCONF users or more general users. P?: The question "what time is it" is not well defined. DR: I believe basic system information is very important to identify which entities they are talking to. Concerning users, this does not seem to be a NETCONF only property. * Martin Bjorklund (structure of the root space) JS shows on the projector a proposal by MB (via Jabber) on how to structure the root space: system { info { ... } // general system information accounts { user { ... } } radius { ... } // radius client configuration resolver { order { } dns { } local { } } dhcp { } // dhcp client configuration } interfaces { ... } services { ... } network { ... } mib { ... } JS: Should there be structure yes or no? WH: User tables are difficult, consider the derivation of a user identity from an X.509 certificate. The notion of a single user table on the system might be limiting considering RADIUS. WH: A user table will be referenced from many other modules and this will be challenging to get right. WH: I do not like the term "system" since it is too ambiguous and open ended. WH: Always consider where the biggest pain of operators is. They likely worry about routing configuration much more than user configuration. Are we solving the wrong problem? JS: The key is to get basic structures right so that they can be augmented. JS: It is important to get basic objects like user objects in place since they will be needed by other modules; if we do not provide the basic infrastructure, things will look very unorganized soon. DK: The goal of the WG is to provide the basic object infrastructure. This does not preclude that people work on other things concurrently. And, for example, configuration of DNS should be done by a DNS working group and collaboration is needed. WH: IP interface configuration is probably another thing to look at which is of value. Basic system infrastructure is also needed but likely won't push NETCONF deployments. LL: I prefer a more flat containment model, start with a set of very basic and less controversial objects first. Since we can have multiple root in YANG, we likely do not need too much structure. DR: What is the basic information to identify the managed element? That information should probably be included. Things such as DNS or RADIUS information should probably separate modules. DK: This work is pretty much about everything a device needs to be configured and runnable. AB: What are nodes that are not in /system? If we can't come up with them, then /system is useless. DK: The WG has some freedom how things are organized into modules. The implementation of the chartered item can be done using multiple modules. AB: It would be useful to have data organization figured out instead of doing it ad-hoc. * Martin Bjorklund (interface structure) No concrete proposal received so far so we skip this point. * Ladislav Lhotka (routing data model) LL: Looked at route filters - they are complicated to configure; is this in scope for the chartered basic routing module? LL: Approached the problem from a network-wide perspective, not so much from a device perspective. RV: We have our own system for defining network-wide policies and translating them into vendor/device specific config. I am not sure device focus is that important. DK: Routing is a big issue (many routing protocols out there) but to me, filtering is a separate issue, but not really core of the charter at this point in time. AB: We need to provide complete solution to compel implementers, we ought to have a plan; it is questionable to have working groups like IPFIX simply pointing to MIB objects due to a lack of infrastructure. DK: I believe a route filtering module will likely need some infrastructure as well. WH: We should have a development where we go through a potentially large list of objects and prioritize work on them. MS: For interoperability, even mundane objects need to be common across servers. P?: Vendors use different routing policy languages today and the development of a complete common model every vendor can implement will likely take long. * Martin Swaney (UNUM NETMOD model) Martin Swaney presented his slides. See the slides for the details. AB: What is a 'Relation'? MS: Think of a 'Relation' as the predicate of an RDF triple. DR: The core part is very similar to the ENTITY-MIB and I consider this a core of the SMI family of MIB modules. The slides you showed could be considered in scope wrt. the charter. AB: Configuration models are hierarchical and not relational. The SMIv2 approach was the wrong approach, flat meshed tables are not a good fit for config. ME: We need to understand the requirements to see whether work fits our goals. There needs to be documents and time for review. There are also other solutions like the TMF SID on the table. LL: Is the working group limiting itself to the view of CLIs or is the working group taking network-wide config into account? This model is enabling network-wide config of routing protocols. AB: We need network-wide models and device models to work together as part of the standard; we should not leave network-to-device translation as an implementation detail. ME: Inheritance is not in the scope of the YANG charter. Are you aware of ? Try it out. DK: We need to look at requirements first but we also need examples to help figure out what solution looks like to develop a better understanding of the requirements. AB: CLI perspective is a series of commands sent to a device to change its behavior; UML is a view from a larger abstraction, kind of non-serialized view of the entire system and relationship between conceptual components DR: We should not forget to do the basic things, what this working group is chartered for: to allow basic communication and basic communication parameters. * Juergen Schoenwaelder Juergen Schoenwaelder presented his slides. See the slides for the details. Issue #1: flatten or keep nested MIB structure LL: Do all containers live in the same namespace? JS: An SMIv2 module translates to a YANG namespace. AB: I am not sure why the verbose version is needed. JS: If someone would add an object below xxxMIB, then this changes the output of the translation. AB: If you concluded we need these layers for robustness, then I trust you that you are right. JS: The translation is config false because MIB modules do not distinguish between config data and operational state data. MB: We need the non-flat structure so that re-translations are always generating the same structure. AB: Do we keep artifacts from the SMI everywhere? JS: Yes, there is no way to do better. Issue #2: import from translated namespaces JS: The IPFIX YANG module refers to an ifIndex. Will it be allowed to import from a translated module? If so, does this require publication of the translated module? AB: I prefer that modules exist or else YANG compilers will be required to parse SMIv2 and convert it to YANG on the fly. BW: I tend to agree with AB. DK: I think we need to decide this on a case by case basis. MB: If they do need to exist, does this mean we have to publish some 100 MIB modules. Do they have to be RFCs or is a repository good enough? LL: Recommendation to IPFIX could be to create their own module according to their needs and be prepared to redo it later. DK: If it works, it works. Sometimes it is OK to use old stuff if it does the job. MS: Should they not use ifName instead of ifIndex? JS: They use ifIndex numbers in IPFIX to identify interfaces because they like compact numbers. AB: I assume it was the IPFIX intent to refer to the ifTable. DK: This is why I believe this is a judgement call to be taken on a case by case basis. AB: I support this as a WG document now, it will be important to my company since management people want to access all data via NETCONF. DK: How many people have read the document (the last or the version before)? 5-6 people DK: Adopt as WG document? 6 for; 0 against * Non-WG drafts: - draft-bjorklund-netmod-snmp-cfg-00 - draft-check-netmod-ext-00 - draft-linowski-netmod-abstract-04 * I/O with other WGs: - draft-ietf-ipfix-configuration-model-08 - draft-ietf-dnsop-name-server-management-reqs-04 - draft-dickenson-dnsop-nameserver-control-01 * open mike: DR: Volunteers for the YANG doctors team are welcome.