All, I have compiled Martin and Robert’s updates into the attached file, and below is the diff. As far as I can tell, these updates are all well and good. Thank you Martin and Robert.
Given that it’s a holiday in the States, please send any final corrections by Monday, Nov 30th. Kent # diff minutes-94-netmod-new.txt minutes-94-netmod.txt 190,191c190,191 < [TC] Why did you chose to use intended/applied approach rather than using datastores? < [RS] 1. No such thing as an applied datastore today. This solution allows us to use YANG today. 2. Our solution allows for a single path that is not dependent on the datastore. --- > [TC] Why did you chose to use intended/applied approach? > [RS] This allows us to use YANG today. 194c194 < [AS] There is a section in our draft that addresses some of these questions. --- > [AS] There is a section i a draft that addresses this. 203,204c203,204 < [RS] No changes to existing YANG models - that does not seem to be practical. There are vendor extensions anyway. < [RW] if models are standardised in IETF, they should work in all cases. --- > [RW] no changes to existing YANG models - that does not seem to be > practical. There are vendor extensions anyway. > [RW] Wilton if models are standardised in IETF, they should work in all > cases. 206,208c206,207 < [RS] Would be nice to poll for who has read the solutions drafts? < [KW] [Show of hands] About half the room have read the three drafts. < [KW] Who would favor solution 1. Humm. 2. Humm (most). 3. Humm --- > [RW] would be nice to poil for who has read the solutions drafts? > [KW] who would favor solution 1. Humm. 2. Humm (most). 3. Humm 210,212c209,211 < [RS] Didn't we do that already? We seem not to going anywhere forward with this discussion. We did clarify wording, but that is mostly it. It is nothing for operator to help with configuring a network. Is it a perfection problem here? Can we produce something practically useful? < [CM] There are large installations based on existing YANG and NETCONF specifications. < [RS] I take that into account. I have none in my network though that use existing model. I am not saying that we should throw away the existing solution in favor of the future solution. --- > [Rw] Didn't we do that already? We seem not to going anywhere forward with > this discussion. We did clarify wording, but that is mostly it. It is noting > for operator to help with configuring a network. Is it a perfection problem > here? Can we produce something practically useful? > [CM] There are large installations based on existing YANG specifications. > [RW] I take that into account. I have none in my network though that use > existing model. I am not saying that we should throw away the existing > solution in favor of the future solution. 214c213 < [CH] We are not forcing to implement some particular data store technology. This is more of a way of thinking of it. --- > [CH] We are not forcing to implement some particular data store technology. > This is more of a way of thinking of it. 232d230 < [KW] [Humm] It's important. 314,317c312,315 < [RS] if we want to simplify things, we need to remove choice completely. I am not proposing that we do this. < [MB] I agree. < [RS] you need to track which branch gets used. It does not explicitly show in the tree. And for those who do not like they could not implement it. < [MB] The data model designer needs to use these constructs carefully. "choice" is often used in very small trees only. --- > [RS] if we want to simplify things, we need to remove choice completely. > [MB] L that is likely a good idea. > [RS] you need to track which branch gets used. It does not explicitly does > not show in the tree. And for those who do not like they could not implement > it. > [MB] maybe it is only applicable to very small trees only. 401c399 < [RW] This is more of a label of the interface type. --- > [RS] Wilton this is more of a label of the interface type. 403,404c401,402 < [RW] augmentation needs to be in the same module as the identity definition. < [MB] that is a side effect of allowing mandatory augments. --- > [RS] augmentation needs to be in the same ?? > [MB] that is a side effect of allowing mandatory augments? 406,410c404,407 < [KW] [Support indicated]. OK, good. Will confirm on the WG mailing list. < [DR] waiting for IEEE 802.1Q WG chair - what is that < [MJ] Glen thinks that the extension of VLAN YANG model should be happening there < [RW] Concern is overlap with the 802.1Q YANG model for bridges. But this model doesn't overlap because it it only defines an interface based model for classification. < [DR] do you have any mail exchanges for this? Maybe this could be raised in IEEE plenary. Please forward me any emails on this discussion. --- > [DR] waiting for IEEE 802.1Q WG chair - what is that? > [MJ] Glen thinks that the extension of VLAN YANG model should be happening > there. > [RS] this is related to overlapping of the bridging model implementation? > [DR] do you have any mail exchanges for this? Maybe this could be raised in > IEEE plenary. Please forward me any emails on this discussion From: Robert Wilton <rwil...@cisco.com<mailto:rwil...@cisco.com>> Date: Tuesday, November 24, 2015 at 11:59 AM To: Kent Watsen <kwat...@juniper.net<mailto:kwat...@juniper.net>>, "netmod@ietf.org<mailto:netmod@ietf.org>" <netmod@ietf.org<mailto:netmod@ietf.org>> Subject: Re: [netmod] draft netmod 94 minutes posted Hi Kent, I've some minor modifications of some of the minutes, mainly just to clarify who was asking some of the questions/comments (mostly between Rob Shakir and myself), but also some other minor clarifications when I was listening back to the audio. [Before] 10 min: draft-ietf-openconfig-netmod-opstate-01 (Anees Shaikh or [RS] Shakir) Rob Shakir presenting. [LL] Would it be possible to have multiple management interfaces (NETCONF, RESTONF, other) - is the intended configuration supposed to be private per transport protocol? [RS] Would think no. There is one intended configuration per device. [LL] this may have some locking implications. [TC] Why did you chose to use intended/applied approach? [RS] This allows us to use YANG today. [KW] there were 3 solutions drafts. [TC] we are doing the same thing in BBF, and would like to mimic the solution agreed here. [AS] There is a section i a draft that addresses this. [LB] I am confused on the process for the requirements. You said you will make consensus call for requirements today? [KW] we will do a consensus call on solutions. I believe there is consensus on requirements. [LB] on a list there was a discussion on planning to poll for consensus but that did not seem to happen. [KW] confirming consensus on requirements now by humming - consensus achieved. [After] 10 min: draft-ietf-openconfig-netmod-opstate-01 (Anees Shaikh or [RS] Shakir) Rob Shakir presenting. [LL] Would it be possible to have multiple management interfaces (NETCONF, RESTONF, other) - is the intended configuration supposed to be private per transport protocol? [RS] Would think no. There is one intended configuration per device. [LL] this may have some locking implications. [TC] Why did you chose to use intended/applied approach rather than using datastores? [RS] 1. No such thing as an applied datastore today. This solution allows us to use YANG today. 2. Our solution allows for a single path that is not dependent on the datastore. [KW] there were 3 solutions drafts. [TC] we are doing the same thing in BBF, and would like to mimic the solution agreed here. [AS] There is a section in our draft that addresses some of these questions. [LB] I am confused on the process for the requirements. You said you will make consensus call for requirements today? [KW] we will do a consensus call on solutions. I believe there is consensus on requirements. [LB] on a list there was a discussion on planning to poll for consensus but that did not seem to happen. [KW] confirming consensus on requirements now by humming - consensus achieved. [Before] 10 min: other solutions for the opstate-reqs (Robert Wilton) Robert Wilton presenting. [RW] no changes to existing YANG models - that does not seem to be practical. There are vendor extensions anyway. [RW] Wilton if models are standardised in IETF, they should work in all cases. [KW] we would like to know which of those solutions should progress forward. [Rw] would be nice to poil for who has read the solutions drafts? [KW] who would favor solution 1. Humm. 2. Humm (most). 3. Humm [KW] Does anyone object to solution 2? Please go to mike? [Rw] Didn't we do that already? We seem not to going anywhere forward with this discussion. We did clarify wording, but that is mostly it. It is noting for operator to help with configuring a network. Is it a perfection problem here? Can we produce something practically useful? [CM] There are large installations based on existing YANG specifications. [RW] I take that into account. I have none in my network though that use existing model. I am not saying that we should throw away the existing solution in favor of the future solution. [CM] There is a technology shift. [CH] We are not forcing to implement some particular data store technology. This is more of a way of thinking of it. [After] 10 min: other solutions for the opstate-reqs (Robert Wilton) Robert Wilton presenting. [RS] No changes to existing YANG models - that does not seem to be practical. There are vendor extensions anyway. [RW] if models are standardised in IETF, they should work in all cases. [KW] we would like to know which of those solutions should progress forward. [RS] Would be nice to poll for who has read the solutions drafts? [KW] [Show of hands] About half the room have read the three drafts. [KW] Who would favor solution 1. Humm. 2. Humm (most). 3. Humm [KW] Does anyone object to solution 2? Please go to mike? [RS] Didn't we do that already? We seem not to going anywhere forward with this discussion. We did clarify wording, but that is mostly it. It is nothing for operator to help with configuring a network. Is it a perfection problem here? Can we produce something practically useful? [CM] There are large installations based on existing YANG and NETCONF specifications. [RS] I take that into account. I have none in my network though that use existing model. I am not saying that we should throw away the existing solution in favor of the future solution. [CM] There is a technology shift. [CH] We are not forcing to implement some particular data store technology. This is more of a way of thinking of it. [Before] 10 min: draft-openconfig-netmod-model-catalog-00 (Anees Shaikh) Anees Shaikh presenting. ... [KW] Maybe IETF tools could host this too. [KW] please hum if this is important work. [After] 10 min: draft-openconfig-netmod-model-catalog-00 (Anees Shaikh) Anees Shaikh presenting. ... [KW] please hum if this is important work. [KW] [Humm] It's important. [Before] 5 min: draft-wilton-netmod-intf-ext-yang-01 (Robert Wilton) Moved from morning session. Robert Wilton presenting. [LL] I think this is really necessary to do, and that is one of the reasons why derive functionality was introduced. [IF] aift types served purposes for SNMP MIBs. I do not propose to obsolete these types. We likely need a tree of identities that could be used. [RS] Wilton this is more of a label of the interface type. [MB] This seems to be a nice idea. Defining these identities that define the properties of interface seems useful, and then derive the actual interface identities from those interface technology type identities. Maybe property identities could be a separate model. [RS] augmentation needs to be in the same ?? [MB] that is a side effect of allowing mandatory augments? [KW] who has read the draft ~10. Who supports the interface extension being adopted? [DR] waiting for IEEE 802.1Q WG chair - what is that? [MJ] Glen thinks that the extension of VLAN YANG model should be happening there. [RS] this is related to overlapping of the bridging model implementation? [DR] do you have any mail exchanges for this? Maybe this could be raised in IEEE plenary. Please forward me any emails on this discussion. [After] 5 min: draft-wilton-netmod-intf-ext-yang-01 (Robert Wilton) Moved from morning session. Robert Wilton presenting. [LL] I think this is really necessary to do, and that is one of the reasons why derive functionality was introduced. [IF] aift types served purposes for SNMP MIBs. I do not propose to obsolete these types. We likely need a tree of identities that could be used. [RW] This is more of a label of the interface type. [MB] This seems to be a nice idea. Defining these identities that define the properties of interface seems useful, and then derive the actual interface identities from those interface technology type identities. Maybe property identities could be a separate model. [RW] augmentation needs to be in the same module as the identity definition. [MB] that is a side effect of allowing mandatory augments. [KW] who has read the draft ~10. Who supports the interface extension being adopted? [KW] [Support indicated]. OK, good. Will confirm on the WG mailing list. [DR] waiting for IEEE 802.1Q WG chair - what is that? [MJ] Glen thinks that the extension of VLAN YANG model should be happening there. [RW] Concern is overlap with the 802.1Q YANG model for bridges. But this model doesn't overlap because it it only defines an interface based model for classification. [DR] do you have any mail exchanges for this? Maybe this could be raised in IEEE plenary. Please forward me any emails on this discussion. Thanks, Rob On 17/11/2015 18:32, Kent Watsen wrote: All, The minutes for the two NETMOD sessions have been posted: https://www.ietf.org/proceedings/94/minutes/minutes-94-netmod Please provide comments/corrections on these draft minutes by Wed, Nov 25th. PS: huge thanks to Ignas and Andrew for putting these together! Thanks, Kent _______________________________________________ netmod mailing list netmod@ietf.org<mailto:netmod@ietf.org>https://www.ietf.org/mailman/listinfo/netmod
IETF-94 netmod minutes Session 1 - 2015-11-04 0900-1130: Room 301 - Audio stream - netmod chatroom           NETMOD WG Agenda for IETF 94 (Yokohama) Chairs: Kent Watsen, Tom Nadeau, and Juergen Schoenwaelder         [AL] Acee Lindum [AC] Alex Clemm [AA] Alia Atlas [AS] Anees Shaikh [BC] Benoit Claise [BR] Ber Wijnen [CH] Chris Hopps [CM] Carl Moberg [DB] Dean Bogdonavic [DR] Dan Romascanu [DS] David Sinicrope [GG] Gert Grammel [IF] Ian Farrer [IC] Ing-Wher Chen (Helen) [JH] Jeff Haas [JS] Juergen Schoenwaelder [JS] Jason Sterne [KP] Keyur Patel [LB] Lou Berger [LL] Lada L [MJ] Mahesh Jethanandani [MB] Martin Bjorklund [QW] Qin Wu [RT] Rick Taylor [RW] Robert Wilton [RS] [RS] Shakir [SH] Sue Hares [TC] Timothy Carey [WH] Wes Hardaker           WEDNESDAY, November 4, 2015 0900-1130 (Morning Session I) Pacifico Yokohama Room 301 2.5 hours on NETMOD Models =============================           5 min: Blue sheets, Note well, Scribes, Agenda Bashing (Chairs) Chartered items: 15 min: draft-ietf-netmod-routing-cfg-20 (Ladislav Lhotka) ---------------------------------------------------------- Lada presenting. Overview of changes since last meeting. Remaining open issue is interface and routing instance relationship. [LL] yesterday YANG DT met and discussed whether we would be able to converge on this topic. Network instance draft covers that. I2RS could also augment this to meet their requirements. Same interface in two separate instances, one for ipv4, another for ipv6 is one of those problems. We do not want to do a solution specific only to I2RS though. [BC] do I understand correctly that the mentioned issue will be solved within a week? [LB] there is a need for some alignment on the two work streams, it will take some time to achieve that. 5 min: draft-ietf-netmod-acl-model-05 (Dean Bogdanovic) ------------------------------------------------------- No questions Non-Chartered items: 15 min: YANG Model Coordination Group (Benoit Claise) Benoit presenting on YANG model coordination group. [AS] Dependency may be a simple augment, or more complex - that is not the same. [BC] Yes, this is indication of potential impact. [CM] This is done based on the YANG catalog draft. It provides a central entry point to query for model metadata. To resolve the dependencies across the models. In long term this will track across multiple SDOs and timelines. [TC] I am working in BBF on YANG. Tools are good but they are just tools. The process is important. We do not know how to engage with the IETF. Please give us the procedures how we could engage and meet your goal. 15 min: IETF YANG Models Update (Qin Wu) Qin presenting. [AS] terminology comment/question - base and extension model are used in different ways in different places. An example of BGP - base model defines core functionality and then there may be vendor extensions as an extension model. [JS] maybe we could consolidate that with classification draft to have a single place for terminology definitions? [QW] yes. [DB] QoS model DT is moving towards DSCP based model. QoS model is moving to CoS model from diffserv to cover L2. [SH] As TRILL chair: TRILL YANG models were created before LIME model. Yesterday we discussed trying to get a combined OAM model both in IETF and IEEE. It seems to be stuck between the differences of BFD and CFM. I would like to see a single OAM model. Otherwise we will take parts from LIME and put it into TRILL. I would expect your help with this. For the BGP part, I hope routing coordination group will work to cover that. [AL] A comment - I don't think those are mutually exclusive [context in slides]. [JH] Thank you for the work. Tools for relationships are very helpful. Models that have overlapping parts need to be refactored into common models. We need to find a way to look for that overlap since it can't be automated. 15 min: Routing YANG Design Team Update (Acee Lindem or Lou Berger) Lou Berger presenting. [RS] The impact of not changing the interfaces is annoying here. Interface config is now outside of the logical element, and that does not make sense now. [LB] I agree with Rob. As a DT we decided not to disrupt the way hiow interfaces are defined. [JH] I agree and disagree with you. There are things that need to be done from resource allocation perspective and statistics. There are different views for different partitions, and there needs to be a mapping of those to customers. [LB] we think that we have a solution for that and this solution will change interfaces definition. We have another solution with id=0 that will show all interfaces. Physical interfaces are bound to logical instances, and logical interfaces are bound to VRFs. That allows for the separation equivalent to subinterfaces. [JH] my recommendation is to leave interfaces alone and provide a shadow view in the context of the instance. [LB] we need to talk about offline. [MB] Is there a separate NETCONF interface per logican network element? [LB] hey will have separate datastores. If you are in LNE=0, then you have a full view into datastores of all element, otherwise into a LNE-specific datastore only. You can always access yourself via id=0. [MB] would it make more sense to see only the interfaces [DB] the base idea that everything is treated as LNE. You have to separate the management domains per LNE. [LB] This is good discussion but we do not have time. Please discuss offline. [AS] 9 months ago we started discussing routing instances question and we still did not conclude. [AL] We focused on having the structure and not necessary the complete list. [SH] please add ephemeral state to the list of open issues. [CH] we will present this in rtgwg too. The id=0 seems to be confusing, this seems to be similar to fork(). [KW] are the next steps to update the document and seek more comments? [LB] the plan is to leave the DT and move to the standards process. 10 min: draft-bogdanovic-netmod-yang-model-classification-05 (Dean Bogdanovic) Carl Moberg presenting. [DR] Yesterday there as a discussion in sacm? WG to discourage the use of YANG models. [CM] There is a document explaining the data and informational models. [DR] what is important is to explain what not to do. [JS] I can see how L3SM model fits into service model definition. L2VPN model seem more of a device type model. [DB} you need to see L2VPN both from device level configuration and network level configuration, broader than a single element configuration. [JS] in the scenario with one NB orchestrator controlling service level and that maps to device level. [CM] That is a good feedback, yes, there is a need for separate network wide and device wide models. [JH] vendor specific extensions are good. But there may be collisions. [DR] you should also add a service specific models for SP extensions. [KW]are there objections to adopting this as WG document? No objections. 10 min: draft-faq-netmod-cpe-yang-profile-00 ([IF] Farrer) Ian Farrer presenting. [Unknown/Tsinghua University] This may need some guidelines or recommendations on how to use those models as there are overlaps. Which is optional and how they can be combined. [IF] that is an interesting case. Yes, there is a possibility for conflicts. I don;t believe you can do much about this. [KP] there are different classes and flavors of CPEs, would be good to clarify what kind of profile you are targeting. [IF] yes, CPE is a generic term, and used rather freely. We need more input from other operators and that would help in clarifying what we are talking about. [JH] Such gap analysis would be valuable, an example of OAM. After that is done, please feed back to LIME WG, this is a good use case for them. [RS] BBF gives a device profile for CPE. Is this a language translation exercise? [IF] No. We as an operator looked into the language to be selected from the perspective of having the minimum number of translations required. [RS] having the commonality across the different types of nodes - would that be important to address? [IF] yes. [RS] Then likely from the routing DT perspective we should coordinate. [TC] (BBF) Is there any interest in utilising YANG for managing different classes of CPEs? How could TR-069 modes be applicable in this context here? There is a proof of concept development started to look into applicability of YANG. [IF] I do not have that much insight into BBF. We had some discussions but not enough. Would be good to get more contacts. [BC] I mentioned L3SM trying to come with a catalog. The tracking aspect of document maybe is not the right place to do here, but looks interesting. [IF] This is more about the requirement. [RT] This seems to be the right approach. A guideline of what is relevant and what to implement seems useful. [DB] Why do you need this draft if you have device model draft, or vice versa? [BC]  There are plenty of missing YANG models missing [IF] We can discuss if this is parallel. [LB] Both documents bring value. Ex for CPE, this is how you use the generic models.This can specify which control plane models need to be included as an example. [KW] there seems to be much support. Do you think this document should progress a bit before adoption? [IF] What I would like to understand whether this overlaps with routing DT work. CPEs seem to be somewhat different class of equipment. [JH] This is valuable. It could be extended to list a set of features that could be supported, and that may impact YANG language itself to express that. This may be a useful exercise, but I am not certain whether IETF is the right organization to host such a document. [IF] This depends on how BBF approach evolves. We as an operator use YANG, and would prefer to do this here than in BBF. [LB] Doing it in IETF is good as you may find broader impact. Some CPE functions may be outside of scope of device model. We need to understand the differentiation between device and service model. This is not necessary known at the moment. If device model does not suit your needs for device level configuration then that needs to be fixed. [IF] yes. [LB] If CPE is small platform that has no logical systems then you always will have LNE id=0; [AA] there is also other interest including from BBF whether modelling for CPE is useful, would suggest to reach to them. [AA] this type of approach seems to be really useful for understanding of what is needed for this particular use case. CPE itself is beyond the scope of routing. [MB]  individual draft from Andy Bierman about package. You may want to have a look at the list of modules that need to be implemented. ?? [DS] as BBF/IETF liaison manager we can discuss offline how to coordinate interworking with BBF. 5 min : draft-ietf-netmod-acl-model-05 (Dean Bogdanovic) Dean Bogdonavic presenting. [BC] Is time range suitable place to discuss in SUPA WG? [DB] yes. [TC] There is work on modelling events in LMAP by Juergne Schoenwaelder. You may want to look at that. [DB] We will submit updated document. 10 min: ietf-netmod-opstate-reqs-00 (Kent Watsen) Kent Watsen presenting. [RS] what is non-derived state? [KW] that would be the intended and applied configurations. [DB] When configuration has been applied but still not running on the wire, there is a delta time between. What is that state then? [KW] that would be applied. [CH] Is that actually config? [KW] yes. [KW] we will update the draft. [LB] at what point do we talk about the consensus? [KW] After the opstate drafts discussion. 10 min: draft-ietf-openconfig-netmod-opstate-01 (Anees Shaikh or [RS] Shakir) Rob Shakir presenting. [LL] Would it be possible to have multiple management interfaces (NETCONF, RESTONF, other) - is the intended configuration supposed to be private per transport protocol? [RS] Would think no. There is one intended configuration per device. [LL] this may have some locking implications. [TC] Why did you chose to use intended/applied approach rather than using datastores? [RS] 1. No such thing as an applied datastore today. This solution allows us to use YANG today. 2. Our solution allows for a single path that is not dependent on the datastore. [KW] there were 3 solutions drafts. [TC] we are doing the same thing in BBF, and would like to mimic the solution agreed here. [AS] There is a section in our draft that addresses some of these questions. [LB] I am confused on the process for the requirements. You said you will make consensus call for requirements today? [KW] we will do a consensus call on solutions. I believe there is consensus on requirements. [LB] on a list there was a discussion on planning to poll for consensus but that did not seem to happen. [KW] confirming consensus on requirements now by humming - consensus achieved. 10 min: other solutions for the opstate-reqs (Robert Wilton) Robert Wilton presenting. [RS] No changes to existing YANG models - that does not seem to be practical. There are vendor extensions anyway. [RW] if models are standardised in IETF, they should work in all cases. [KW] we would like to know which of those solutions should progress forward. [RS] Would be nice to poll for who has read the solutions drafts? [KW] [Show of hands] About half the room have read the three drafts. [KW] Who would favor solution 1. Humm. 2. Humm (most). 3. Humm [KW] Does anyone object to solution 2? Please go to mike? [RS] Didn't we do that already? We seem not to going anywhere forward with this discussion. We did clarify wording, but that is mostly it. It is nothing for operator to help with configuring a network. Is it a perfection problem here? Can we produce something practically useful? [CM] There are large installations based on existing YANG and NETCONF specifications. [RS] I take that into account. I have none in my network though that use existing model. I am not saying that we should throw away the existing solution in favor of the future solution. [CM] There is a technology shift. [CH] We are not forcing to implement some particular data store technology. This is more of a way of thinking of it. 10 min: draft-openconfig-netmod-model-catalog-00  (Anees Shaikh) Anees Shaikh presenting. [KW] What do you expect for next steps? [AS] To continue with using it and see whether the schema is complete. [KW] would you see it being adopted as a wg document? [AS] yes. [JH] This is metadata that can go into model itself. This is alos organization-specific view of things, IETF may have one, BBF may have a different view. Not certain whether one repository would work. [AS] local catalogs can reflect the data that individual organizations need to have. Some metadata should be part of the schema. Jeff some metadata is common, some is specific. [WH] catalogs traditionally have been implemented and maintained by vendors, [IF] A may not have enough resources to maintain it. You should consider the additional load on [IF] A. This is an opportunity for some external entity, maybe opensource, to take care of. [AS] yes, there are many options. [LB] we should come with technical solution first. [IF] A aspects can be addressed later. [AS] I am happy with this approach. [KW] Maybe IETF tools could host this too. [KW] please hum if this is important work. [KW] [Humm] It's important. 15 min: draft-entitydt-netmod-entity-00 (Martin Bjorklund) Moved to afternoon session. 5 min: draft-wilton-netmod-intf-ext-yang-01 (Robert Wilton) Moved to afternoon session. 5 min: draft-wilton-netmod-intf-vlan-yang-01 (Robert Wilton) Moved to afternoon session. 5 min: draft-dharini-netmod-dwdm-if-yang-00 (Gert Grammel) [GG] Grammel presenting. [LB] is this netmod, or ccamp? [GG] some confusion here in the document name.  [BC] If there is a YANG model on specific technology, it should go into specific WG, if there is no specific WG, it should be in netmod. [LB] are there any language issues in this document? I am surprised to see this presented again and not in CCAMP. [GG] this is depending on generic interface model. We can talk offline. [KW] end of this part of meeting. ================== Morning Session Ends ================== ==================== Afternoon Session Begins ==================== Session 2015-11-04 1300-1500: Rooms 411/412 - Audio stream - netmod chatroom WEDNESDAY, November 4, 2015 01300-1500 (Afternoon Session 2) Pacifico Yokohama Rooms 411/412 2 hours on NETMOD Language =============================           5 min: Blue sheets, Note well, Scribes, Agenda Bashing (Chairs)           Chartered items: 30 min: draft-ietf-netmod-rfc6020bis-08 (Martin Bjorklund)             Martin Bjorklund presenting. [LL] Option B does not make sense. It makes sure that the default values do not become invalid. It should be removed by the if-feature. It is good to ignore the default values. I propose the C option. Others add unneeded complications. [BR] When the feature is not there then the default does not make sense. What would be the default when the if-feature is not there? [MB] there would be no default then. [KW] BR makes sense. [MB] Are you suggesting more than one default depending on if-feature? [KW] yes. [MB] this is complicated. [KW] need to see use cases. [WH] there are two corner cases. if default feature is not there, and what if the feature is one or another, then there could be different default values. [MB] Yes, this gets complicated. [MB] We need to continue this discussion on the list. [LL] [RS] Wiltonâs draft already uses this augment feature. My proposal would be to change must not to should not, and be aware of why this is necessary. We cannot check what the all safe uses are. There are use cases where you may need this functionality. [MB] yes. [LL] things may break when people use convoluted when expressions. However, this is not default and nneeds to be enabled specifically. Vendors can use this to enforce some checks. [RS] Wilton. 6087bis has proposed ..... [MB] yes there is some text in 6087bis that discusses the concerns. [LL] Is this new keyword really required? [MB] when you don;t have a key statement, then there is no restriction on values. All the list values that are contained there are unique. This would need to be relaxed. [AS] when you retrieve them, the server potentially needs to behave differently, as the values may be the same? [MB] the different keyword would allow to have the same values in the list. The client would know that the values may be the same. [AS] the server could just return one of the values. [MB] is this a good idea to support, and then process thing - how to do that, is it a fix to the current spec. Kent/contributor I wonder whether we need to have a separate keyword. The issue may be from the data driven client. This would be YANG 1.1, so the compl[IF] t client would have to support this. [MB] changing the semantics of leaf-list seems somewhat awkward to me if you don't have a keyword for this. [LL] maybe it is worth mentioning that the COMI protocol uses the maps in maps mechanism, and generally people use YANG features in a way that we did not initially expect. Perhaps it could be done in RESTONF with no changes, but I don;t see this in NETCONF. [RS] this is a nice feature, a kind of list in a list. It would be good to have this in the specification. [LL] the current text talks about NETCONF server behaviour, and there can be two interpretations on this. I would propose this whether it is applicable to the generic behaviour. This seems to be a bing change, and not certain whether this makes sense for all protocols. [WH] (Belasz on Jabber) the current interactions are too complicated, we need to simplify it. [RS] if we want to simplify things, we need to remove choice completely. I am not proposing that we do this. [MB] I agree. [RS] you need to track which branch gets used. It does not explicitly show in the tree. And for those who do not like they could not implement it. [MB] The data model designer needs to use these constructs carefully. "choice" is often used in very small trees only. 10 min: ietf-netmod-rfc6087bis-05    (Andy Bierman) Kent Watson presenting. No comments and questions. 5 min: draft-ietf-netmod-yang-json-06 (Ladislav Lhotka) Ladislav Lhotka presenting. [MB] encoding of anyxml - we had that before we had anydata. The current document says that implementation can do whatever, and that is not interoperable. Would it make sense to say that anyxml is encoded as a stream? Not the nicest encoding but that would be interoperable. [LL] anyxml is a container for arbitrary data exchange. The only restriction that the data does not break the syntax. anyxml is for encoding arbitrary xmd data. It can be interpreted in different ways - whether it is xml for netconf, or ... [MB] if anyxml means something more than just transparent xml, maybe we need to change the definition. we have anyxml and anydata. [LL] anydata is for data that can be modelled. anyxml would be good that does not follow YANG rules. [MB] then it could be used as a special type. [LL] it is similar problem as interpreting RESTCONF definitions. (jabber - Andy) string would not be needed if anydata would not be used in the first place. [LL] these seem to be marginal issues on the anydata and anyxml yet they happen over many IETF meetings.  10 min: draft-ietf-netmod-yang-metadata-02 (Ladislav Lhotka) Ladislav Lhotka presenting. [MB] if we enforce annotations, should they be a more generic ones? Should there be a more generic XML encoding? [LL] we have two encodings so far. Every implementation supporting any of those should also support this additional encoding. [MB] clients should ignore the unknown attributes. [JS] - jabber encoding issues are encoding and protocol concern. [LL] we need to discuss this on the list.  [MB] annotations are supposed to be used as last modified, or last used. Option C here would make a part of data model. [MB] I do not think option C is practical. Regarding option B - all the problems with when and if-feature? would be applicable here too. Would be better to use description statements. [KW] one approach could be YANG patch. But for that you need to reference a specific model. Option B .. [LL] it seems to be difficult to do .... . [LL] Any objections to go with option A? Non-Chartered items: 15 min: voit-netmod-peer-mount-requirements-03 (Alex Clemm) Alex Clemm presenting. [JS] when you are relocating some of the models, isn't there a problem with leaf refs with absolute paths? [AC] good point. Authoritative owner of the model provides a view, and the underlying model itself does not change. But that is a valid issue. [LL] are you dealing here with two different concepts - an alternative way of combining schemas, more like a pull type, and another one is a combination of data trees from different remote sources. I think these two cases should be separated. I would like to have the ability to combine schemas, but peer mount involves lot of nasty issues, similar like NFS mount does. Would be better to separate and focus on local issues first. [AC] there are issues with the remote mount. Should we provide only a view, of also a configuration operation. The focus is to provide just a view, and then you avoid the dealing with transactions and locking. Alias mount is a subset of remote mount, and it makes sense to start with it. There are important use cases for local mount. Regarding schema extension - not so certain whether I would like to take it there. Initial purpose was just to provide a view by mounting a subtree, but you still have the authoritative validated information living elsewhere, you just access a copy of it via other path. [MB] is alias mount read-only? [AC] yes, it focuses on retrieval. [MB] that seems useful in the context of operational state requirements where the operational state is in a different store from the config. [AC] the concept applies to any operation, but initial focus was on retrieval as we had use cases for that. There are also notifications that need to be addressed. [KW] next steps - it would be good to focus on schema combination and put a draft that focuses only on that. 10 min: draft-mansfield-uml-to-yang-01 (Scott Mansfield) Scott Mansfield presenting. No comments and questions. 10 min: betts-netmod-framework-data-schema-uml-02 (Scott Mansfield) Scott Mansfield presenting. [KW] I am curious about people interested in this work - please hum. A few. 10 min: draft-chen-netmod-enterprise-yang-namespace-00 (Ing-Wher Chen) Helen (Ing-Wher Chen) presenting. [KW] not certain about the rules for changing the name space URNs. Have you checked that? [IC]. Yes. We are proposing a shortcut for doing that. [KW] and the advantage would be that those may be misleading? [MB] It should follow the rules of registering the urn. Maybe we need to define something generic that could contain specific ones beneath? [IC] alternative pattern could be urn followed by reversed DNS name? [KW] please take to the list. 15 min: draft-entitydt-netmod-entity-00 (Martin Bjorklund) Moved from morning session. Martin Bjorklund presenting. [MB] how many have read the document? very few. [KW] this seems to be important work but too few people have read it. [DB] This is important work. SFPs are hardware, and to find out what SFPs are in the platform would be very useful. Not certain where this work could be done. [DR] an observation on the logical part. Entity MIB was also updated. [BC] we have to do this anyway, and we knew that for some time. 5 min: draft-wilton-netmod-intf-ext-yang-01 (Robert Wilton) Moved from morning session. Robert Wilton presenting. [LL] I think this is really necessary to do, and that is one of the reasons why derive functionality was introduced. [IF] aift types served purposes for SNMP MIBs. I do not propose to obsolete these types. We likely need a tree of identities that could be used. [RW] This is more of a label of the interface type. [MB] This seems to be a nice idea. Defining these identities that define the properties of interface seems useful, and then derive the actual interface identities from those interface technology type identities. Maybe property identities could be a separate model. [RW] augmentation needs to be in the same module as the identity definition. [MB] that is a side effect of allowing mandatory augments. [KW] who has read the draft ~10. Who supports the interface extension being adopted? [KW] [Support indicated]. OK, good. Will confirm on the WG mailing list. [DR] waiting for IEEE 802.1Q WG chair - what is that [MJ] Glen thinks that the extension of VLAN YANG model should be happening there [RW] Concern is overlap with the 802.1Q YANG model for bridges. But this model doesn't overlap because it it only defines an interface based model for classification. [DR] do you have any mail exchanges for this? Maybe this could be raised in IEEE plenary. Please forward me any emails on this discussion. 5 min: draft-wilton-netmod-intf-vlan-yang-01 (Robert Wilton) Moved from morning session. No comments and questions. ==================== Afternoon Session Ends ====================
_______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
