============================================================= NETCONF Data Modeling Language WG (netmod) IETF #80, Prague, Czech Republic TUESDAY, March 29, 2011, 1710-1830, Room Grand Ballroom 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 - RFC editor queue: - draft-ietf-netmod-arch-10 (waiting for draft-ietf-netconf-with-defaults) - Published RFCs: - RFC 6020 (draft-ietf-netmod-yang) - RFC 6021 (draft-ietf-netmod-yang-types) - RFC 6087 (draft-ietf-netmod-yang-usage) - RFC 6110 (draft-ietf-netmod-dsdl-map) 2) Core system data model (TBD) [ 10 min ] 3) Core interface data model (Martin) [ 20 min ] - draft-bjorklund-netmod-interfaces-cfg-00 4) Core routing data model (Ladislav) [ 20 min ] - draft-lhotka-netmod-routing-cfg-00 5) SMIv2 translation to YANG (Juergen) [ 10 min ] - draft-schoenw-netmod-smi-yang-02 6) Related work (chairs) [ 5 min ] Related work in NETMOD: - draft-bjorklund-netmod-snmp-cfg-00 - draft-chen-netmod-yang-ext-00 - draft-linowski-netmod-yang-abstract-04 Related work in other WGs: - draft-ietf-netconf-access-control-03 - draft-ietf-netconf-system-notifications-03 - draft-ietf-ipfix-configuration-model-09 Open mike {please identify issues in advance} Summary: During the NETMOD WG meeting at the 80th IETF, the WG discussed a proposal for a core interfaces data model and a proposal for a core routing data model. Both documents were adopted as WG documents (subject to confirmation on the mailing list). An proposal for a core system data model is lacking but two volunteers have been identified to work on this chartered work item. Open issues related to the translation of SMIv2 modules into YANG modules were identified and discussed. The next revision of this document will be posted as a WG document. Actors: DK - David Kessens JS - Juergen Schoenwaelder AB - Andy Bierman MB - Martin Bjorklund BW - Bert Wijnen DR - Dan Romascanu WH - Wes Hardaker LL - Ladislav Lhotka SL - Simon Leinen Slides: https://datatracker.ietf.org/meeting/80/materials.html Audio: http://www.ietf.org/audio/ietf80/ Meeting Notes: * Core system data model It remains somewhat unclear what the exact scope of this effort is. In order to get concrete discussions going, it is necessary to produce a strawman proposal. AB and MB volunteered to create an initial proposal for the core system data model within a month. The chairs need to work with potential editors on defining new realistic milestones (delivery to the IESG). * Core interface data model MB presented his slides. The following captures the discussions. - MB: The current draft pushes the configuration of interface layers to extension modules - DR: Generic layering for VLANs needed in the interface table, this should not be done in proprietary ways - JS: Configuration of software interfaces is not generic since different parameters are needed, based on the interface type; the representation of the resulting interface layering is generic - MB: Should we add an object reporting operational status? - AB: Suggest to leave all the the operational status objects out, except perhaps for oper-status - MB: Do we need an interface alias, similar to ifAlias? - JS: ifAlias is often used for descriptions, customer information, contact information, ... and it is persistent - SL: ifAlias contents configured via CLI 'description' - DR: The ifName value comes from the vendor; the ifAlias is for the operator to use - There seemed to be a slight preference to provide a mechanism to configure an ifAlias - MB: Is a 'testing' configuration status of an interface needed? Is a 'testing' state saved across reboots? - SL: An interface is not configured to be 'testing' mode, so this is not realistic - MB: Should the interface type be an identityref or should we use the established IANAifType? - LL: We have a similar issue with address family numbers in the routing data model - WH: A lot of code uses these numbers today so we better use the same numbers. - AB: I agree with Wes that ifType numbers are used in lots of code - MB: What is the set of generic config objects? Right now there is only the mtu. - DR: Keep the mtu configurable - AB: What about address/subnet-mask? Do we include IP interface configuration? - DK: IP is core to the IETF - AB: IP == IPv4 and IPv6 support? - JS: Yes, IP always implies IPv4 and IPv6 - ??: Why just IP? Why not other address types? - JS: Apparently IP is core to the Internet The chairs asked the room whether the document should become a working group document. About 6 people had read this draft (out of 15?) and more than 6 agreed to make this a WG draft. The chairs need to work with the editors on defining new realistic milestones (delivery to the IESG). * Core routing data model LL presented his slides. The following captures the discussions. - LL: Should name of main routing table be fixed? Should the kernel routing table be mandatory - MB: These are hard problems to solve, I do not know the answer right now - LL: Would be nice to have XPATH support for YANG types. Would be nice to allow circular imports to support leafrefs from A to B and B to A. - AB: Circular imports can be avoided by moving things around - DR: Once a WG document is available, I will send it to the routing area list to request cross area review. The chairs asked the room whether the document should become a working group document. About 6 people had read this draft and about 6 people agreed to make this a WG draft. The chairs need to work with the editors on defining new realistic milestones (delivery to the IESG). * SMIv2 translation to YANG JS presented his slides. The following captures the discussions. - JS: Translation of DISPLAY-HINTs into pattern? The room seemed to be with a MAY create pattern without detailing the algorithm used - JS: Name ambiguities: foo OID ::= { baz 1 } bar OID ::= { baz 1 } How to translate to containers? Note that order can change. - BW: How frequent is this? - JS: Hard to tell, but very surprising if it happens - MB: But the result is still valid YANG, no? - JS: Yes, valid YANG but not necessarily matching an implementation anymore. Need to work more on this issue. - JS: There are enum/bits ambiguities since the SMIv2 allows to change labels while YANG does not allow to change enums - BW: How often is this done? - DK: Not used often; do not need perfection here - MB: Reordering is common; 2 different labels to the same identifier and then reorder - JS: OBJECT-IDENTITY will be translated to containers and identities and containers MAY be pruned if they do not contain anything other than containers - JS: How to determine whether an OCTET STRING should be represented as a string or a binary remains unsolved. The current approach does not work if a DISPLAY-HINT is added during a revision of an SMIv2 module - AB: I do not like the use of a union and quoted strings because a NETCONF server does not need to look for quote - JS: Text will be added that certain SMIv2 constructs can be translated into the smiv2 YANG extensions. It is not clear, however, whether his is a MUST/SHOULD/MAY. - MB: I prefer a MAY The next revision of this document will be posted as a WG document. The chairs need to work with the editor on defining new realistic milestones (delivery to the IESG).