NETMOD WG Agenda for IETF 93 (Prague) Chairs: Tom Nadeau, Kent Watsen, and Juergen Schoenwaelder [AC] Aseem Choudhary [AL] Acee Lindem [BC] Benoit Claise [BF] Bill Fenner [CM] Carl Moberg [DB] Dean Bogdanovic [GH] Giles Heron [GP] Glen Parsons [JJ] Joel Jaeggli [JS] Juergen Schoenwaelder [JS2] Jason Sterne [KW] Kent Watsen [LL] Ladislav Lhotka [L.] Lucy ? [L.2] Loukas ? [MA] Michael Abrams [NS] Norm Strahle [RE] RFC Editor [RK] Radek Krejci [RW] Rob Wilton [PG] Pravin Gohite [S.] Sam ? [TN] Tom Nadeau [X.] Xien (from Huawei) MONDAY, July 20, 2015 1850-1950 Afternoon Session IV Grand Hilton Ballroom 60 minutes on NETMOD Models =========================== 5 min: Blue sheets, Note well, Scribes, Agenda Bashing (Chairs) Chartered items: 15 min: draft-ietf-netmod-routing-cfg-19 (Ladislav Lhotka) ---------------------------------------------------------- [LL] suggests the WG to focus on stabilizing and publishing the model [AL] agrees that the WG should focus on getting the spec published [BC] suggests that we hold the specification short of last call to get some early feedback from implementation experience [LL] comments that stabilizing the draft will also stabilize the namespace for the other (9 and counting) drafts that reference this draft and it's data definitions [AL] comments that there are some features (e.g. ECMP and recursive next hops) that are not in the specification yet [DB] comments that if we keep waiting for support for more advanced features, we will never be able to publish it [TN] comments that the more models we build that need this, the harder it will be to make changes, need to think of a different plan to approach this [LL] comments that the YANG versioning models as they are right now is hard to honor as the complex interdependencies grow [TN] comments that the IESG may need to go back and consider the complexity of the current situation [AL] comments that if we don't need IPv4 and IPv6 to reference routing instances, that would be a benefit, so RFC 7277 wouldn't need to change. 10 min: draft-ietf-netmod-syslog-model-04 (Pravin Gohite) --------------------------------------------------------- [CM] asks if there are any known implementations, Pravin doesn't know any [PG] suggests that we take the draft to WG last call [TN] asked Pravin to take the last call question to the mailing list 10 min: draft-ietf-netmod-acl-model-03 (Dean Bogdanovic) -------------------------------------------------------- [TN] commented that questions needs to be asked also on the mailing list [JS2] commented that we need more robust discussion on the mailing list as there are alternatives to the current proposals [JS2] wants to propose a separate container per address family [JS2] commented that there is value in operator input on this (e.g. the openconfig team or other operations people) [DB] commented that there was some input from operators during the Dallas meeting Non-Chartered items: 10 min: draft-asechoud-netmod-diffserv-model-03 (Aseem Choudhary) ----------------------------------------------------------------- [NS] says that there are still some fundamental issues to be worked out, e.g. different architectures represented in the same model [AC] comments that it's perhaps not so much the underlying architecture, but different use cases [??] (mic at back of room) isn't this a job for two models, a model where you express the limitations and a generic model [AC] comments that this can be approached using if-feature [TN] suggests to carry this question and discussion to the mailing list 5 min: draft-wilton-netmod-intf-ext-yang-00 (Rob Wilton) 5 min: draft-wilton-netmod-intf-vlan-yang-00 (Rob Wilton) ---------------------------------------------------------- [GP] comments that it is good that the draft is labeled as complementary to IEEE, but the content seems to suggest otherwise. [GP] comments that further interaction across e.g. IETF, MEF and IEEE would be good TUESDAY, July 21, 2015 1520-1720 Afternoon Session II Grand Hilton Ballroom 120 minutes on NETMOD Language ============================== 5 min: Blue sheets, Note well, Scribes, Agenda Bashing (Chairs) Chartered items: 20 min: draft-ietf-netmod-rfc6020bis-06 (Juergen Schoenwaelder) ---------------------------------------------------------------- [AB] comments that the assumption that 1.1 can import 1.0 needs to be clarified in terms of the validation rules applied to the modes. [JS] comments that Andy should provide examples on the mailing list to push this forward [LL] suggests that any trailing issues for 1.0 can be covered by 1.0 Errata [DB] Obsoleting 6020 will mean drafts based on 1.0 may need to be reworked. What should we do with draft models that are written as 1.0 currently? [DB] comments that he agrees with author to not obsolete 1.0. We have many models in 1.0 heading towards, or in last call [JS] comments that we need to distinguish between non-published modules and published modules. How painful is it really to "upgrade" modules that are not published? [TN] asks AD (Benoit) for additional clarification on whether to park existing pre-WG modules waiting for 1.1 and then bump them up. Bring to mailing list. [JS] how many changes will actually be required ? [JJ] we shouldn't have to go and update RFCs. We are not likely to revise a large set of drafts to reference 1.1. [GH] comments that he supports removing the term "NETCONF" from the title as there are several activities, e.g. I2RS working on YANG [AB] comments that taking "NETCONF" out of the title will not help since much of content refer NETCONF including examples [AB] should we really take NETCONF examples out of the doc ? That will hurt interoperability. [TN] how about we leave them in but clarify they are just NC examples and the doc isn't purely for NC [BC] what are we going to do with the current 6020 ? Leave it there ? Obsolete it ? - depends on if 6020 will remain active [JS] since amount of YANG modules is relatively small, there is a chance that all will move to 1.1, this means that we could retire 6020 [JS] We should carry forward the IANA considerations section into 6020bis [JJ] comments that the consideration is solely for IANA instructions, so not important that there are live (non-historical) documents with the considerations in them. [JJ] asks if conclusion is to remove IANA consideration text, and Tom comments that it sounds like we have agreement on that [AB] asks if we really should go through existing RFCs and update them, is there really value in that? [KW] comments that, to Andy's point, we can import 1.0 modules from 1.1 modules, which says that we may not require sweeping upgrades of existing documents [TN] if you don't have the ID it is 1.0 [L.] (RFC editor?) comments that in order to protect RFC editor resources, see if we can avoid multi-document updates [RE] (Lucy?) don't make changes in all these docs, if there turns out to be a transition issue then write a transition draft. [RW] asks if a YANG module can declare support for "don't care", i.e. valid as both 1.1 and 1.0? [DB] asks if the reference to "new modules" applies to all non-published drafts, or if published, perhaps late-version drafts, should also be updated [LL] comments that work on his drafts will be updated to 1.1 to leverage the new features [TN] checks the room for objections on the WGs insisting on YANG 1.1 to progress documents [TN] does anyone object to saying that all new modules must be 1.1 ? [AB] comments that this requirement will have significant impact on the tooling, as e.g. parsers and validators may not be ready for 1.1 [BF] comments that this comment is fine for IETF modules, but how about vendor modules that may reference e.g. interface-module. will vendor models need to update to yang 1.1 ? [BF] comments that he supports decision to require 1.1 to progress modules [GH] asks if 6087bis references 1.1, room answers yes, it has been updated [JS] note that you can pull in by revision so if you want an older version you can use it [JS] asks room who is in favor of online meetings vs normal mailing list traffic. Slightly higher interest in webex-meetings 15 min: draft-ietf-netmod-yang-json-04 (Ladislav Lhotka) -------------------------------------------------------- [JS] I support the proposal about Xpath (to rely on 6020bis) [JS] Comments that there might be a little hole to plug regarding the XPath expressions evaluated over I-JSON data [RK] I think we can use the RFC2119 text. [RK] Comments that the suggested text change regarding namespace encoding rules works better 15 min: draft-ietf-netmod-yang-metadata-01 (Ladislav Lhotka) ------------------------------------------------------------ [AB] the intent of the annotation statements (related to issue #1) means you can't write an extension statement that undoes anything that basic yang statements do. That is, that are limited to things that do not change or extend existing YANG statements. [JS] suggests that we may be mixing things up, compilers ignore non-compliant/supported keywords but the meaning of extensions is related to the protocol, not as part of the module statements. A client & server need to agree/negotiate whether an extension is supported [TN] wasn't Andy saying that an annotation can't undo functionality in the base yang spec [AB] What Juergen said is correct. The client should be able to skip over attributes it doesn't know (or if it is something defined like this then they can parse it but not use it). [AB] we don't return metadata that the client didn't explicitly request [LL] won't a client that doesn't understand ... (missed the rest) [JS] how do clients ask for certain annotations [AB] we add leaf params to the RPC (with-owners). In your case you would have to ask for the disabled nodes (by default they are hidden to a normal client). [LD] we need to know that both client & server understand the annotations [AB] we should charter conditional enablement [JS] Juergen comments that for finishing up this document we should document that there is no protocol negotiation and people should proceed with care [KW] (re annotate entire list): does this mean JSON can't annotate an entire list either ? [LL] correct [JS] comments (on issue #3, co-exist with data nodes) that he agrees with the author that annotations in separate modules should be a guideline in a guidelines document, and not enforced 5 min: draft-ietf-netmod-rfc6087bis-04 (Andy Bierman) ------------------------------------------------------ [BC] we may need a section with guidelines for external entities (e.g. SDOs, open source projects) around best practices to publish YANG models [DB] we need guidelines on how to encode examples in drafts, Andy needs more input on details Non-Chartered items: 15 min: YANG Model Coordination Group (Benoit Claise) ----------------------------------------------------- [MA] where do we submit a draft for a model where there isn't a clear WG? [TN] it is NETMOD if there really is no other place [BC] regardless of where it is done we need to right experts [L.2] asked if there was overlap between the IETF and ODL YANG modules [BC] responds that data is not normalized and correlated, so there may be duplicates. This is the type of data that we need. I will come back to you on this. [KW] number of models isn't always relevant. Some vendors have a single model that is very large. [??] What will we do about OpenDaylight models that aren't coming to IETF [BC] we shouldn't really do much. If ODL people want to submit models to IETF then great. Otherwise there isn't really an answer. We have interest in coordinating to avoid duplication [JS] the IETF is us, so if people want it to be worked through by IETF, they should bring it in and be ready to work on it [DB] regarding having different organizations producing different models for the same thing. The end user can chose which model they want to use. Community model, vendor model or IETF model. [??] if there is a model in ODL that someone wants to bring to the IETF, they should be encouraged to do so [TN] the IETF is not going to go out and mine models. There is no restriction on bringing a model to the IETF when there already exists an ODL model for the same thing (although it would be good to bring that ODL model to the IETF if that works instead of creating a new one when one exists). 15 min: draft-bogdanovic-netmod-yang-model-classification-03 (Dean Bogdanovic) ------------------------------------------------------------------------------ [DB] who read the draft? (about 10 people raised hands) [KW] in the zerotouch draft we present a southbound model to devices so they can bootstrap. How is that classified ? It isn't really a "service" but it sits in a controller (and is used to interface with a device). [CM] we do address that in the draft [X.] can a YANG model be classified both as a service model and a device model [CM] yes - that can be possible. The same data structure can be both a service model and a device model (e.g. topology). [??] how does topology model fit into this classification ? [DB] please take that to the list [??] we may have a disconnect. There is a disconnect here. Some devices have service-like objects. [MA] can the network service models also have the same mix of std, std-extensions and proprietary ? [DB] yes. Will be clarified in next draft. [S.] How does this draft overlap with the OpenConfig model-structure draft? [DB] They are different things. This one defines std vs proprietary. The OpenConfig is a layout of how models fit together (e.g. taxonomy, overall data model structure, etc.) 10 min: draft-mansfield-uml-to-yang-00 (Scott Mansfield) -------------------------------------------------------- [CM] here's my worry: my experience is that this is a difficult task combining different viewpoints. Maybe we should also look in the other direction. There is a UML output plugin in pyang. [JS] what is your end-goal ? Totally automated tool system to feed a UML model and spit out a YANG module ? Just a set of informal guidelines for humans to translate. I don't believe in the first one (tool). My experience is that UML models don't have all the information needed for a data model. [??] there is use in this. It is to share information models across data models. What metadata will be required to make the generation possible ? draft-bjorklund-netmod-openconfig-reply-00 (Benoit Claise) ---------------------------------------------------------- [JS] how to continue & conclude this discussion ? [TN] we will continue with interims until this is solved [S.] I find it odd to convert responses to a draft. 2nd point: all the concerns raised were also discussed in section 7. 3rd point: please put an alternate proposal on the table. [JS] it is quite common to have drafts for discussion. It captures discussions and arguments. It is an individual draft that anyone can create. [TN] using drafts almost like an issue tracker [JS] we included alternate proposals. [S.] for all the questions raised, in section #7 discusses all the concerns raised by the presentation [S.] if there is to be a meaningful proposal, we need to hear concrete proposals to move the discussion forward [TN] we encourage using the points in the presentation to move the discussion forward, there is nothing more to it. No resolution expected today.