Note takers:     - Susan Hares Please add your name to the list below: Attendees: Kent Watsen Eric Voit Juergen Schoenwaelder Balasz Lengyel Clyde Wildes Dan Romascanu Gary Wu Mehmet Ersue Susan Hares Mahesh Jethanandani Andy Bierman Amy Vezza Giles Alberto Gonzales Prieto Agenda: Agenda of the virtual interim meeting on May 18, 2016, 0800-10000800-1000 FREE FREE PDT - 5 min Chair introduction, scribe, agenda bashing The notes will be taken on: http://etherpad.tools.ietf.org:9000/p/netconf-may-18-2016-interim - 30 minutes. Discussion around how to split the server-model draft. [Kent Watsen] - 30 minutes. Discussion around key-chain model in the server-model draft. - 30 minutes. Discussion around the scope of each draft in the collection commonly known as YANG push. This includes updates to RFC 5277. - 20 minutes. Discussion around zero-touch draft as time permits. - 5 min AOB other topics 1) Agenda Bashing 2) Splitting the service-model into two drafts [Slides being presented by Kent Watsen] Added ietf-syslog into all proposal options from IETF95 as a separate draft 5 proposals for draft split Proposal 1: 4 Drafts: SSH & TLS Client & Server behavior all bundled together into a single draft. Restconf & Netconf in a single draft. Different draft for keychain. And Syslog as a draft. Proposal 2: Delta from (1) - SSH, TLS split into separate drafts. Could be expanded to include other transports Proposal 3: Delta from (2) - Split layer with the netconf/restconf Proposal 4: Every proposal gets its own draft Proposal 5: Groups client and servers Discussion: Balazs Lengyel : We see a use case for having systemwide tls config for a number of protocols. One would be LDAP, so the split looks good. Configure TLS 1 and use that for multiple protocols. Mahesh: Kent: The devices acting as TLSclient, and connecting to a TLS server - may have a specific certificate to authenticate that server. If the device acts as client, it would have a different set of certificates. There are client-server maps may be used in netconf/restconf authentication-maps. I am hoping to If you look at the keychain draft, there is a group/list of trust anchors stored in the keychain. These are use case specific certificates groups (or lists) - are being referenced both by the TLS server grouping (once by netconf, once by restconf) This simplifies anyone who is using both RESTCONF and NETCONF to reference the same certificate list(s) from the keychain model. Kent: Does that answer your question? Balazs: Mostly. Kent: Is there one proposal you prefer Balazs? Balazs: I am Ok with 1 or 2. Andy: I liked the first proposal. Typically if i am a developer working on the client side, I am not reading the server-side documentation. I would like 2 drafts. Clyde: is this a motivation to split the model along ssh and tls Andy: Are we concerned that 3 drafts would change? Is this the primary motivation. Clyde: I asked because I was looking at perspective of the security group. Kent: I do not think any of these proposals matter for the security directorate and reviewers. Clyde: Thank you. Kent: Proposal 2 splits TLS away from SSH. While each of those two drafts would contain both client and server models, each would be broken out into its own top-level section within the draft, thus making it easy for developers only looking for one to be able to ignore the other. Mahesh: Are we looking for minimum drafts? Eric: I think we should combined drafts as we see it done TLS and SSH are not combined. NETCONF/RESTCONF are often combined in 1 draft. Clyde: Currently call-home is embedded in the draft. Kent: Call-home is its own draft for both netcont/restconf. The server model draft does, in both the RESTCONF and NETCONF modules, define support for configuring call-home. Mahesh: Do we have any one proposal we can veto? Kent: 4 or 5 can be vetoed. Mahesh: Does anyone have objection to 4 or 5 being removed from consideration. Sue/Eric: No Mahesh: We have on the table proposal 1, 2 or 3. Clyde: Has there been a concern to combine the ietf-netconf-server and ietf-restconf-server? Kent: There is ietf-netconf-server-model. It has 5 models. Mahesh: ... therefore the netconf-server and restconf-server are one draft. Mahesh: does anyone have a objections to removing proposal 1. Kent: I think proposal 1 is weak. Juergen: 2 or 3 over 1. Mahesh: Let's debate 2 or 3. Who thinks proposal 2 is fine? Kent: It is the same amount of work for 2 or 3. Mahesh: The differences is netconf/restconf in one draft or two drafts. Juergen: Is there anything that will be shared between netconf and restconf? Kent: The key chain will be shared. Clyde: Is there anything common with call home? Mahesh: With the consideration of proposal 2 and 3 - is there anything common between netconf/restconf drafts? Kent: two gropings might be sharable: cert-maps and end-point container - that are shared between modules. Each of these are defined uniquely. These could be factored into a different draft. Mahesh: Actually .. the consensus on the call was for 2 on the call but there was a mixture of 2 and 3. Mehmet: We are not deciding. It must be taken to the mailing list. Mahesh: We'll take proposal #2 and 3 to the mailing list. Action item: Send the question of the selection of the proposal to the list. Summarize that the interim participants preferred 2 or 3. Topic 2: Discussion around the key-chain model Issue #2 - How complete do the SSL and TLS models need to be (slide 12-13) Discussion: Kent: Any thoughts? Mahesh: Juergen was asking if this needs to be vetted with the sec-dir to determine if it is complete? It does need the review for the sec-dir, but do we need additional review. Kent: We could take this as an action item to determine if sec-dir cares. Mahesh: Any other thoughts on this point? Action item: Review thie SSH/TLS with security directorate. Issue #3 - How to address the semi-configurable aspects of the keychain model? (see slides 14-15 Kent: Private keys are not accessible. NACM could specify this. My response is that if you did a get, you could utlize a rpc-warning to indicate what needs to be done. Mahesh: To summarize, in normal circumstances private keys will not be available outside the box. Kent: For keys in the TPM chips, they will not be available. Juergen: Why do you have load private key? Kent: The is not a way to load a private key other than to use the action statement. Juergen: If you would be secure, why would you load the private key. Kent: I know that private keys are loaded in some fashion. The action statement performs the load. Mahesh: What is the difference on a security basis write on a leaf or a action statement. Kent: I would hope based on NACM Juergen: By doing an action, you do not allow the loading by using an action. Kent: If it is in the model, then the key could be saved to other devices. If it is an action only, then the action could be Mahesh: Do you want to make it a write-only option? Kent: An action can be done against the running data store. If it is a write-only option, then it can be done with candidate data store. Whether the values were in the start-up data store. Mahesh: Are we looking for an action or a write-able leaf protected by NACM. It would not be mandatory TRUE due to the private keys in a TPM. A get-config would need a warning since it would not get private keys. Mehmet: I would suggest that we propose something and ask if there are objection. Kent: The proposal is in the current draft to have the private key as loadable by an action . Action item: Take to the mail list. Ask if the action Topic #3 - Yang Push Participating: Subscription model and 5277bis and (see slides http://etherpad.tools.ietf.org:9000/p/netconf-may-18-2016-interim/netconf-wg yang-push git used for issue tracking for each draft Mahesh: Is the attendance open? Eric: I welcome anyone and I'd be glad. Mahesh: Balazs wants to be invited Eric: We'll put an invite on the github Mehmet: You can put on the mail list that this is an editor's meeting. If you invite everyone then it becomes a general editor's meeitng. You can keep it private. Eric: This is what we will do. We do not have authors. The people will be editors if they contributors. Mehmet: You can always arrange an editor's call for a contributors call. 12:07-12:13 [missed a bit ] [slide 4] Eric: The RFC5227bis - do we split the draft into two pieces. We will want to have alternative transports beyond NETCONF. Kent: If the RFC5227bis is changing the NETCONF, then we need to [Slide 5] Eric: There is a base subscription draft. We are talking about what is the base subsription draft that can be run over a variety of transports (NETCONF, RESTCONF and others in the future) Over that point, we have additional features for Datastore push. Discussion: Mahesh: Is there a model for a proxy on behalf of multiple receivers? Eric: We have 3rd party subscribers. This is not a proxy. IoT make 3d party subscribers (described in appendix B). .... Mahesh: You talked about securing the channel, but are you using NACM to determine who can subscribe to any particular events. Eric: For data store push, you only have access to the events received on the stream you are logged into?? I do not know Access control with RFC5277 stream. It is not given how this maps mechanism in RFC Andy: NACM applies to the Event types. NACM allows gating by Event types. One of the issues I am concerned about is the performance and speed of this point. Access control on all content and trying to secure it will be a little slow. I suggested that (to speed up Alberto: (missed) Kent: The authorization should be to the subscription. It should not be worried on the data plane. Andy: The feature is the I2RS wants is the details in the features. I think that the tagging for non-secure transpors that will be included in this subscription. Eric: We have custoners wishing non-secure transport. Andy: People want in IoT -- x are looking to be extremely efficient. Kent: We need to support more than one transport (raw UDP, DTLS, TLS) and security consideration for the deployments in order to allow non-secure protocols. If you are using raw UDP, be sure you are using private network where the networking is providing the security. Eric: We are working through issues. No date for first draft, but perhaps a month off. Call-in-user-9: Where should we send issues regarding this draft? Eric: Send it to the mail list. The more people who discuss it the better we are doing. See the github repository. Mahesh: The closer you are to making a draft, the more input on the drafts? Kent: Is this the end of the drafts? We have a 1/2 hour. Balaz (call-in-user-9): Will this be part of the normal netconf data stream. Eric: I do not think we are going to add a datastore the netconf stream. We cannot change the current netconf stream to add more information. Balaz: The netconf data stream contains all notifications. Kent: The existing netconf stream is for control-plane. It is conceptually out of the question for things related to data stream. To address this in a back-wards compatible way, we need to create a "flag" that states that this notification does not go to a netconf stream. Balaz: The Yang push for all of data models would be very difficult. We mark some of the nodes as non-notifiable. I think this would make it work. Mahesh: Could this be made backward compatible by adding this to YANG models as flag, something similar to what Kent suggested above? Eric: I have not talked a marker to each yang model. We had assumed that only some objects would be subscribed to. We assumed that some objects would be notified on a slow basis. For example, a counter. Balaz: We have counters that are changing state or configuration. Eric: We talked about having a stream that focuses on a particular type of data. Balaz: We had an operational definition that said "no counters". How do you define what is a counter? Eric: I do not recall the operational - except counters? Andy: The think to look-out for is a feedback loop. A counter that causes notification to be sent - which in turn updates the streams. Eric: Defining on what goes in the streams is important in order. Alberto: If we have subtrees that only provide counters - as updates at time periods. Balaz: How do you identify what nodes are periodic updates versus others. Eric: This is part of hte stream definition. You would filter out these counters. As I point out in bullet 3, we need to define streams so that we Balaz: We are doing configuration mirroring in our management. It is difficult to synchronize the who configuration. It would be useful to have a replay mechanism for change notification. Eric: We do think that get gives your full configuration. We do have the ability to replay the configuration. Balaz: Suggest that if you have 20,000 configurations. It is difficult to pull. Eric: I see the need. The ability to store a set of streams so that external boxes can handle it. Knowing what needs to be supported, and knowing the replay Balaz: If we have multiple streams and each stream can determine if it needs replay. Eric: Being very careful on what you are archiving. Balaz: In RFC5277, it is not specified. Eric: I can introduce you to the call. Andy: The current yang push starts out with a full replay and then go from there. I think we do not have any input on drops. We are weak on this point. In NETCONF, we do not know if you missed the NETCONF. I agree with your comment that you missed. Kent: In some streams, you do not to worry about dropping (e.g. Counters). in some, we need reliable transports. Eric: Juergen made this point in the chat window. Having a sequence number is important. Andy: It is turned off by defeault. Eric: Balaz - good issue. Andy: I like the issue of the configuration change stream. It can be allocated accordingly. Different from a general notification. Eric: A full datastore to describe to is a "non-starter". Andy: The configuration can Balaz: Next issue. In some situations, you do not want these notifications. If a lot of things are changing in a short time. The notifications are expanded or notified. Let's say you have a node and a restart. Half of the data store changed. Can you provide a single notification, instead of a lot changes. Eric: If we had a notifiacation for susp Alberto: We had a suspension of change notification. After we change the suspension. Eric: We do have a sync parameter on the beginning of the notification. We need to figure out a suspend and resume. Andy: We have a suspend and resume on the server side. Eric: Andy: I am unclear what starts suspend Eric: If the subscription is overwhleming the client, then client asks for a suspend. We could allow for a suspension and resuming. Andy: I think the resource consumption (e.g. for suspend and resume). In NETCONF, the replay buffer is totally hidden. Eric: Maybe there is an OPS subscription model for multiple models. Andy: You have a subscription priority that gives a hint on which ones to quit first. Balazs: My issue is different. It is not that the node is out of resources. It is the case that the breathe of the change is so wide-spread that it needs a suspend and restart. Balazs: I am not sure I want to support notification on startup and candidate configuration. Eric: Balazs - this is a very useful. [Summary of Balazs' input] Balazs: 1) Implementing yang-push for every data bit e.g. counters will make it difficult for some of our nodes to implement yang-push. I propose to have a yang-extension "not-notifiable" that indicates that for a specific data-node datastore change notifications will not be sent. 2) If I have an on-change subscription and I loose some notifications it is much cheaper to somehow playback those notifications than to get the full datastore (or subtree). We would need a replay capability to get the lost notifications. 3) In some cases e.g. reload, upgrade, etc. there are so many changes that instead of sending them all, it would be better to : - the node suspends change notifications - the node sends a special notification change-notifications-lost. This would allow the client to re-synchronize, read the datastore with a get Balazs: - Why is XPath filtering mandatory it should be dependent on the xpath capablity - Why are notifications on candidate/startup datastore mandatory. I might have these datastores but still not support change notifications on them. (specially for startup) Mahesh: It would be useful for people to review the comments. Mehmet: When are we going to adopt the new drafts work? There was an agreement in BA (IETF 95) when we can adopt these drafts. We should set a deadline for final changes to drafts of 1 week. Eric: There is no need to waits for drafts. Mehmet: There is one question I have for BIS draft for NETCONF protocol. The authors of the orginal draft should be co-authors. Eric: Two authors are on the call. I see zero issues as them being authors. Mehmet: The minimum is that they should actively review. Mahesh: Anything else before we close the meeting. Mehmet: provide the meeting link.