> NetMod Minutes For IETF 102 > Session 1: > TUESDAY, July 17, 2018 > 1330-1530 Afternoon Session I > Place du Canada > Audio stream: http://ietf102streaming.dnsalias.net/ietf/ietf1025.m3u > Session 2: > FRIDAY, July 20, 2018 > 0930-1130 Morning Session I > Laurier > Audio stream: http://ietf102streaming.dnsalias.net/ietf/ietf1023.m3u > Etherpad: http://etherpad.tools.ietf.org:9000/p/notes-ietf-102-netmod?useMonospaceFont=true > Meetecho: http://www.meetecho.com/ietf102/netmod > Jabber: xmpp:netmod@jabber.ietf.org?join > Available post session: > Recording: https://www.ietf.org/audio/ietf102/ > YouTube: https://www.youtube.com/watch?v=gk-KniK3XpQ https://www.youtube.com/watch?v=9uLRz1_3l1Y > TUESDAY, July 17, 2018 > 1330-1530 Afternoon Session I > Place du Canada > Audio stream: http://ietf102streaming.dnsalias.net/ietf/ietf1025.m3u > Presentation Start Time Duration Information > 1 13:30 10 Title: Intro, Charter & WG Status > Presenter: Chairs > Draft: N/A Joel Jaeggli presenting > 2 13:40 15 Title: Interface Extensions > Presenter: Rob Wilton > Draft: https://tools.ietf.org/html/draft-ietf-netmod-intf-ext-yang > https://tools.ietf.org/html/draft-ietf-netmod-sub-intf-vlan-model Rob presenting Lada (Ladislav Lhotka): These are very good drafts, but IEEE models are difficult to implement for simple devices. Is there an options or liason to provide review of their modules? Rob: It's too late as their models are quite mature. IEEE have their own configuration model already for those devices. I would have liked to see them reusing like the sub-interface constructs and things that doesn't actually necessarily work with their model. And I've given examples of how to use sub-interfaces with the LTL TPM model. That allows you to do transparent bridging. Lada: Really need something simpler (from IEEE) Scott Mansfield: Issue of YANG coordination is being taken serriously by IEEE and already working with ITU. .1Q document is "done" there are other modules proceeding in IEEE. There are opportinities for collaboration: monthly meetings, etc. IEEE is using YANG Catalog. Put comments there. there is also meeting of a yang group in the IEEE the last Wednesday of every month and there is an ITU call last the third Monday of every month Lou Berger: Scott, what do you think about Lada's liaison suggestion. Scott: Liasons are useful but better to raise on an individual level Rob: there are 2 fundamental issues, IEEE and IETF being done in parallel Scott: talking now would be good, future models should be more module Lou: does this issue is enough of an an that it rises to the level of having a coordination for next meeting Scott: Suggest coordination with a subgroup would be worthwhile Rob: there is already some discussion taking place Lou: We (chairs) will follow up offline Rob: I will draft a liaison that can be used to inform IEEE of status. > 3 13:55 10 Title: YANG Module Tags > Presenter: Chris Hopps > Draft: https://tools.ietf.org/html/draft-ietf-netmod-module-tags Chris presenting Joel: who has read it (this or prev): a healthy number Joel: who thinks it's ready: a good percentage who have read Joel: who thinks it is not ready: none Joel: We will take it to the list > 4 14:05 20 Title: YANG Data Extensions > Presenter: Kent Watsen > Draft: https://tools.ietf.org/html/draft-ietf-netmod-yang-data-ext Lada: It¡¯s really something that's needed and it's very convenient that you can define some scheme of independent of encoding. But concern as proposing it at a standard implying that it is a normal way of using YANG, when it really isn't. Slippery slope, if we want to do this, then should continue to RFC 8040. Kent: Your concerns apply to RFC 8040. Lada: In restconf RFC8040, there are some rational way. This seem to be making it more official. Lou: Why do you think that it isn't a standard before (in RFC 8040) Lada: Because it make the community more aware of it. Kent: Your concern really is about extensions, would it help if there was an applicability statement. Lada: If it a proposed standard then expect folks would use it. Lou: Is it that you don't like extensions of the specific YANG data extension? Lada: I don't like an extensions that change yang semantics. Question of scope about what is being done in extensions. As soon as we change what it is in RFC 7950 then it is a problem. Lou: Since this is already an extension in RFC 8040. Perhaps it would be good to do a draft to explain how extensions should be allowed. Lada: Now have YANG data augment, which wasn't in RFC 8040. Undermines the value of YANG in a standard. Rob: Would you be happy if this was done as part of a Yang 1.2 or Yang 2.0, or do you object to idea of YANG data? Lada: I would be happy if it was done in the a new YANG specification. Could be done in a small draft (to define yang independent of data stores.) Kent: To clarify, if a new version of YANG, then it could be a top level statement. Lada: I'd prefer YANG be generic and be usable to model data without being tied to datatores/restconf/netconf How to proceed: #1 define both "yang-data" and "augment-yang-data" (a few) #2 only define "augment-yang-data" (no one) #3 un-adopt draft (almost same to #1) Joel: who can not live with #1 (no one) option 1 selected: mostly because no one said that they could not live with it Lada: I can use #1 even though I don't like it WRT slide 6: Some felt it could be legal, most felt that it should not be legal Rob/Lou: would be good to define a statement (draft?) that clarifies our [mis-]use of the extension statement here. > 5 14:25 65 Title: YANG Model Versioning Design Team > Presenter: Rob Wilton > Draft: https://tools.ietf.org/html/draft-verdt-netmod-yang-versioning-reqs Rob presenting Chris Hopps: Fan of using namespace to indicate non-backwards compatable revisions, but Req1.2 states the namespace must be the same. Rob Wilton: It depends on how well people are play to the code to the clients, and whether people are using fixed paths. Tim Carey: About rq1.2: As a client, I don't know that this is not backward-compatible, that data node I'm using right. Rob Wilton: (Rq 1.2 ) It's not the intention to be saying the clients can find out that there's something's changing in non-backward compatible way. Italo Busi: What about clinets that are upgraded talking to an old server? One use case could be a hierarchical controller talking with multiple domain controllers, some of which are not updgraded to support the new model version. Rob: Thinks that this is a request to what is being offered instead (of not having forever backwards compatibility) Igor Bryskin: If you have a model that is not backwards compatible. There are cases where one client can talk with multiple servers: if there is no common ground you have an issue. Balazs Lengyel: (responding to Igor/Italo) You can just obsolete or deprecated something nodes. I think a client has to check the revision of all modules before really working. Alex Clemm: Why limit data nodes, or also includes rpcs, notifications, etc.? Rob Wilton: Could be more generically stated as "schame nodes" Kent Watsen(contributor): existing clients *today* clients or some future existing clients Rob Wilton: Mean today clients Kent: Okay, so this speaks to the migration/transition strategy Chris Hopps: This is a requirement that actually pops out, because of you saying that you need to be able to have multiple modules without different namespace names. Rob Wilton: Yes. Chris Hopps: We're creating problems that didn't exist before. You can have multiple modules if they have different namespaces Lou B: If you have an idea, it's worth discussing Chris Hoops: I'm just I'm making comments Gert Grammel: Want definition of what is/is not backwards compatible Rob: Using RFC definition Vladimir Vassilev: Be careful of over engineering and overly complex solutions Chris H: Stating that the namespace cannot change limits solution space Balazs L: Disagrees, chaning namespace causes too many other changes Chris H: Maybe restate Req1.[1/2] to indicate goal without suggesting a solution Lada L: The option of changing the name of whom are already here. It is not a not good way to do this. If we want to change module names that we can. Lou B:How many people are comfortable w/ req as modified by today's discussion (Req1.2, and flexibility): a reasonable number Lou B: How many people are uncomfortable: one (already stated issue at mic) Lou B: Home many think that we should not be talking about this? no one Lou: We will poll the list soon Kent (contributor): Any requirement needs to be added to support yang-data? Rob/Lou: Sounds more like a yang-data problem Lou: What's the best way for folks to bring ideas to the Design Team? Rob: Just drop an email (netmod-ver-dt@ietf.org) > Adjourn 15:30 > Session 2: > FRIDAY, July 20, 2018 > 0930-1130 Morning Session I > Laurier > Audio stream: http://ietf102streaming.dnsalias.net/ietf/ietf1023.m3u > Presentation Start Time Duration Information > 1 9:30 5 Title: Intro > Presenter: Chairs > Draft: N/A > 6 9:35 15 Title: Comparison of NMDA datastores > Presenter: Alex Clemm > Draft: https://tools.ietf.org/html/draft-clemm-netmod-nmda-diff Alex presenting Qin: Compare different datastore or same datastore at different time. When will start? Alex: There is no time option and state aspect. RPC is performed when it be requested. Rob: Agree with Qin's comment that the doc should mention what happens when the schema differs between two datastore. You might want to have an option to exclude nodes that are present in the schema in one datastore but not the other. It would also be useful to have an option to decide whether on original metadata is part of the operation. Lada:Support! And one use case could be connected with restconf transactions document - emerging the staging repository into . Balazs Lengyel: Will the patch always use create or merge. Just have one way to parse the difference (e.g. don't sometimes report as creates, other times as deletes). Alex: There is a choice here or where it is just reporting the difference Balazs: Agree that it is enough to just know the difference. Reshad Rahman: Question about why the draft has moved from NETCONF WG to NETMOD WG. Alex: The recommendation of the chairs was to move from NETCONF WG to NETMOD WG. Kent: It is closely related to NMDA work, so it seemed to make sense to move it here. Lou: how many think we should be working on this problem? (a really good number) Lou: How many have read this document. £¨Also a really good number£© Lou: How many think we should adopt this document (also a really good number) Kent: How many think we should NOT adopt (None) We will confirm on list > 7 9:50 15 Title: YANG Instance Data Files > Presenter: Balazs Lengyel > Draft: https://tools.ietf.org/html/draft-lengyel-netmod-yang-instance-data Balazs presenting Open Issue 1 : Shall we recommend as a general practice: Servers SHOULD document their capabilities using instance data? Rob: I prefer there is not in this document. Suggest to keep this draft more abstract in terms of how to define the instance data. Kent: How to publish the instance document? Joel: I think we need a method there. I don¡¯t think it need to be done in this draft, but this problem should be solved in a particular way. Jugern (On Jabber):This is misplaced a file format specification in a file format specification. Lada: This should not be in this document because this data format is quite generic and can be used for any number of other proposes. Tim: Some other drafts talk about factory datastore, is there different? Balazs : This is about getting information before you actually have the network nodes available. Rob: The factory datastore is the default configuration where the device comes up. Balazs: This give the way for ¡°factory datastore¡± but doesn¡¯t prescribe that. Tim: Just want to figure out that what the connection of ¡°instance data¡± and ¡°factory datastore¡±. Rob: I don't think you get the interoperability if you need to publish this data. Lou: It's OK to have a draft to introduce that you implementation like report some information, but how to report it should outside the document. Adrian: it's not directly related but this could intersect with mud in the future, should take a look at that work. Balazs: Support defining a separated document to introduce how to report capability? (a few) Open issue 2 : Should we use yang-data-ext to define the instance data module? Kent: Any data is not a part of datastore. Lada: Lada: Without yang data extension, it just defined some schema, so if a server decides to implement it, I don¡¯t see anything wrong. Xufeng Liu:You not try to redefine the datastore, right? -- Balazs: No. Balazs:Support using yang-data-ext: (a reasonable number / few) Against using yang-data-ext: (very few) Joel: (To Lada) You cannot define the metadata that one might want to include your instance data. some solution for augmenting to be able to say I want to add this metadata. I think we need for something for that. open issue 2(second bullet): Shall we add a datastore parameter for config=true data? Rob: I think if the dates approach was included, it would be an optional thing. And you least need a flag to say it is configuration data or operation data. I think you need more indication as what the data is. Lou:It seems like we're mixing some concepts which are really the data representation focused on build a representation and the other concepts items that are focused on how we are moving that representation or restoring that representation. open issue 3: Allow mulitple instance-data-sets in one file? Lada: In your document it said that this data is stored in the file then the file name should encode the version. I think this is a really bad practice. Lou: How many people think this document should be adopted now -- current version? (a few) How many people would like to see an updated based on today's discussion and then adoption? (less) How many people oppose this document? (none) Chairs will discuss off-line then send something to the list > 8 10:05 15 Title: Handling Long Lines in Artwork in Drafts > Presenter: Qin Wu / Kent Watsen > Draft: https://tools.ietf.org/html/draft-kwatsen-netmod-artwork-folding Qin presenting.. Rob: Maybe also be used in yang tree. Igor Bryskin:Auto extraction better Lou:How many people think this should be done in this WG (a good nulmber)? Dean Bogdanovic: Opsawg WG may be a better pleace. Adrian Farrel: if a graphical artworks cannot fit the 68 character width, folding it would be it even worse Kent: the draf says that it is NOT RECOMMENDED to use this solution for graphical artwork, you would like this to be changed to a MUST NOT use Adrian: yes > 9 10:20 15 Title: Generalized Network Control Automation YANG Model > Presenter: Xufeng Liu / Igor Bryskin > Draft: https://tools.ietf.org/html/draft-bryskin-netconf-automation-yang Xufeng Presenting... Interesting in this work (a few) Not interesting in this work (a few) Andy like the idea but not all the solutions.(Jabber) Tim:We know we have the problem but I think there is a finite state document. Suggest you guys get together and see if you can come in with a decent solution. Lou: Do you discuss with the author of FSM? Xufeng: Not yet. Lou:You need spend some more time with FSM document to figuring out where there's overlap or there's not. Igors: Implement or experimanet? If it can implement, it more valuable to do. > 10 10:35 10 Title: YANG model for finite state machine > Presenter: Nicola Sambo > Draft: https://tools.ietf.org/html/draft-sambo-netmod-yang-fsm-03 Nicola Sambo remote presenting.. Lou: Do you think it need to discuss with ECA draft? Nicola: Yes, ECA is more generic. > 11 10:45 15 Title: Yang data model for Terminal Access Controller Access Control System > Presenter: Bo Wu / Zitao Wang > Draft: https://tools.ietf.org/html/draft-zheng-netmod-tacacs-yang Michael presenting.. Joel: Back when I was ops-AD: We started work to document how tacacs+ is implemented today in the industry, we are not looking to add more to that draft (extensions would go in new drafts). This work would seem fit in OPSAWG. Ignas: Current tacacs+ works not looking to add more feature. A module for tacacs+ seems to be needed. If you talk about system, those two protocols can be selected by the choice. So it may be a good idea to try to work on AAA system framework and then have tacacs and radius put into that. > Adjourn 11:00