Thanks from Chairs on Published RFCs RFC6536bis adopted Good progress on Subscriptions Client / Server models progressed Chartered items: 1. Zero Touch Provisioning for NETCONF Call Home - K. Watsen (15 min.) https://tools.ietf.org/html/draft-ietf-netconf-zerotouch-13 Kent: Issues with Amima still exist Kent: Three artifacts: Zero Touch, Owner Certificate, Ownership voucher Kent: developed Unit test developed for removable storage Kent: 3 Open Issues: (1) DHCP Artifact Size Ian (last name): how big is a UDP packet as you can't support fragmentation: 576 bytes for IPv4. IPv6 has more space. Should we have a single object which can support both? Likely no as there isn't room for signing with no fragmentation, even for IPv6. Ian and Kent to work this off-line. (2) Artifact Signing Strategy Kent recommendation: PKCS only, to keep it local (3) Naming issues - to be worked on the list Kent: Goal is to provide a WG last call version within 3 to 4 weeks. Keystore and TLS/SSH Client/Server Models : K. Watsen (15 min) Kent: Quite a few updates provided on the drafts ------------------------- 2. Keystore Model https://tools.ietf.org/html/draft-ietf-netconf-keystore-01 Issue: Should private key be a Union? (relevent to both SSH & TLS) Martin B: Solution will not work because if key is denied, then NACM will not allow through the necessary information? Kent: There are two items provided. NACM only eliminates one of these. Private key will be part of elements delivered from Manufacturer, but we also want to provide an RPC for this. Martin: What shows you that it will be a private key? Kent: You will see a list reference the certficate. Kent & Martin to work the issue off-line. 3. SSH/TLS Client Server Models https://tools.ietf.org/html/draft-ietf-netconf-ssh-client-server-02 https://tools.ietf.org/html/draft-ietf-netconf-tls-client-server-02 Kent :Should RC/NC client be a grouping? (instead of containers) for the simplest case, it is ok to use the proposed grouping. Will take it to the list Kent: Will complete call home reference implementation that would test the server model. Mehmet: Should we wait on the implementations? How long? Kent: For syslog, which would test the client model, it will be a few weeks to syslog WG LC. Mehmet: I do not think we should wait for implementations. 4. NETCONF/RESTCONF Client Server Models https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-server-02 https://tools.ietf.org/html/draft-ietf-netconf-restconf-client-server-02 NETCONF Notification Drafts - Eric Voit (20 min) ----------------------------------- 5. Subscribing to YANG datastore push updates https://tools.ietf.org/html/draft-ietf-netconf-yang-push-05 6. Subscribing for Notifications https://tools.ietf.org/html/draft-ietf-netconf-subscribed-notifications-00 7. NETCONF Support for Event Notifications https://tools.ietf.org/html/draft-ietf-netconf-netconf-event-notifications-01 8. RESTCONF & HTTP Transport for Event Notifications https://tools.ietf.org/html/draft-ietf-netconf-restconf-notif-02 9. YANG Notification Headers and Bundles https://tools.ietf.org/html/draft-voit-netmod-yang-notifications2-00 Discussion: Eric: Drafts should be in good shape. Three of the four drafts are close to WG LC. [Slides] Open item for the mailer alias is whether people are ok with Subscription ID as an identifier only relevant to a single receiver? Andy: To Clarify, who decided that the access control at run time or start-up. If we change NACM on the fly, we'll suspend your subscription. Eric: Nothing requires that must do the NACM changes on the fly. Less desirable but compliant mechanisms could be the termination and restablishment of a subscription when a relevant access-control change is made to subscribed elements. David Wolfire()?: Can we state that behavior of this NACM causes potential security risk. Eric: Perhaps security consideration can be enhanced. We believe this is the consideration section. We know of two implementations, although they are focusing on different parts of the specifications. 1) Martin - we believe we responded to all your previous comments within the current drafts with the exception of notif-netconf which still needs to be updated. 2) Same issues as for push data. on Subscribed notifications: Mehmet: No comments? Do want adoption? Mahesh: I'm interested. Martin: This yang notification and bundles be useful. Martin: You have to say something about the association for the transport. It is transport agnostic, but you will still need to determine the bindings. Eric: We are not going to hold up the other drafts for the new headers. Instead, we can build the transport binding drafts so that this new information should be able to be passed identically to a regular notification. As the draft progresses, we can see if this is the case, but I don't know why this wouldn't work. Bhushan Padhiar:Bundling is very useful. If I have 5 types of notification, it should be able to be bundled with the most important items first. Eric: Prioritized grouping of bundled record types is not something we have chatted about yet. Please contact me offline. Bhushan: What is the priority of bundling? Eric: You could have a process that set members of bundles. The priority with a severity high could go in 1 bundle. That way you could dequeue each bundle independently via HTTP2 and not worry about head-of-line blocking. Bhushan: Once the notification is received, is it deleted? Eric: We do have a yang model for random access in the draft. [xx]: My vision is caching notifications so that they can be downloaded again. Eric: You will always cache/log notifications, but the question is whether you want YANG model based random access into this cache. Mehmet: Based on these comments, you will discuss this on the list. Eric: Yes. As NETCONF seems interested my next steps will be to socialize elements of the draft on the mailing list. 10. NETCONF Access Control Model - A. Bierman (5 min) https://tools.ietf.org/html/draft-bierman-netconf-rfc6536bis-01 Andy: Latest draft is update of security section. I think it is ready for WG LC. Mehmet: Should we go to last call? Any objections? Seeing none, we will go to WG last call. Charter Discussion: 1. Draft charter update for NETCONF WG - Co-Chairs (10 min) Benoit: NETMOD will do Yang network modeling. NETCONF is the protocol. Mehmet: The charter have the notifications from Eric. (missed something) We will talk on the I2RS in a few minutes. Phil: There was reference to XML in the charter. Mehmet: This was removed. Benoit: I sent out the charter a few days. Mehmet: Some textual change from Benoit are editorial. Mehmet: No other comments on charter proposal from the room. Note: Charter indicates that DS concept on NETCONF/RESTconf is a standard document. I2RS changes will be done NETCONF/RESTCONF. 2. NETCONF/NETMOD/I2RS Joint discussion on re-chartering - All (15 min) 3. Impact of DS concept on NETCONF/RESTCONF - M. Bjorklund (10 min) Mehmet:This is a standards document. Martin: New datastores to address the need to split of operational datastore differences from config structures. There are implications of this decision on the structure of Datastore operations for NETCONF & RESTCONF. Martin: operation can be used to retrieve contents from any datastore. Mahesh: What happens to the semantics in the short term Martin: Nothing Phil: Will continue to work Martin: get-config will move forward Phil: We should look to deprecate get-config (this looks to be an open issue) Alex: Do we need operations which can get the values from multilpe datastores to compare values? Martin: Could be useful Andy: What about breaking existing operations? We have trees developed which are not well aligned to the newly proposed operations. Don't just remove the old operations. Martin: Add this as a new capability so that old operations are not impacted Andy: Good. Robert Wilton: This could be a new capability rather than a new version, and this would move things more quickly. Mehmet: We currently have been talking about -bis. But this is flexible. Answer this on the Mailing list. Proposal is clear. We need a discussion on the mail list. Provide 2 individual documents. Maybe you can describe your proposal on the list. Lada: Is the base URL changed? Martin: No it doesn't change, it is a new resource. The old mechanisms are not touched for the base protocol. Benoit: Will this be a recommendation to be new capabilities which will deprecate previous capabilities Mahesh: Vote in room - people are in favor of proceeding, nobody against. Martin: will proceed with individual drafts. 4. NETCONF Changes to Support I2RS Protocol - Sue Hares (5 min) https://tools.ietf.org/html/draft-hares-netconf-i2rs-netconf-01 Susan: Kick-starting Ideas on Capability Control Plane Datastore [Slide] Susan: Write collisions are an issue for NETCONF, but not RESTCONF Susan: Issue is how do you do cross datastore validation. Issue is to be addressed in future discussions including in discussions in I2RS tomorrow. Kent: Guidelines for Dynamic Datastores. It is ok to say that you can say you only can access a Datastore via RESTCONF rather than NETCONF Lou Berger: We in the routing area are trying to make everything agnostic Susan: We are just saying that we make it possible for an implementation must only support RESTCONF, and not NETCONF. Susan: Come tomorrow for more on I2RS 5. RESTCONF Changes to Support I2RS Protocol - Sue Hares (5 min) https://tools.ietf.org/html/draft-hares-netconf-i2rs-restconf-01 Non-Chartered items: 1. gRPC in Network Management - A. Shaikh (unavailable, present. Benoit filling in) (5 min) Benoit: come to the RTGWG to review the GRPC and GMNI documents tomorrow. Mahesh: Do we want to do this in the Ops area? Jeff: GRPC has been implemented in major Routing vendors. We want to make sure this is handled in a common way Eric: The same set of people working the solutions for functionality like Get, Set, Subscription, Encoding (CBOR) would be useful. Jeff: Yes, this is the intent - to have the same people. ___ (Huawei): We can contribute under the gprc input. 2. Accounting in NETCONF and RESTCONF - Mahesh Jethanandani (5 min) https://tools.ietf.org/html/draft-mahesh-netconf-accounting-01 Mahesh: reviewed accounting attributes across several accounting protocols. Benoit: This is good that we have common attributes. You should send this draft to Radius related WG. Dean: Using accounting for service assurance. RADUIS people will need to look at this for desired functionality Mahesh: Has looked to AAA providers to get input for functions such as these. Intentionally made this protocol agnostic for functions like this. Benoit: With this, we can make elements of AAA transport agnostic. What is the benefit for using our WG's transports? Mahesh: We can get over limitations such as packet size maximums by doing the modeling and extracting from transport. Benoit: Must speak with AAA people. Alex: For accounting model, what are you accounting for? Mahesh: This is for NETCONF operations accounting. Mehemet: What is your intent? Mahesh: Work on it, and later ask for WG adoption. Vote: 3 votes for doing this is NETCONF, 1 vote against. Kent's reason for against: Would be a distraction from current work Tim: Why would you want to replace existing accounting mechanisms with this? Why do we need a new record mechanism? Mahesh: Existing stuff was CLI based, this is optimized for other elements such as NACM. Tim: Why not just expand existing Diameter or mechanism? Mahesh: Reasons like "number of packets received on the interface" might be an extension which might not be easy to do with existing mechanisms Joe Clark on Jabber (as read by Lada): I think this draft complements traceability work from I2RS (vote in favor) Mehmet: What is your intent? Do you want WG 3. NETCONF Proxy - Z. Wang (5min) draft-wangzheng-netconf-proxy-00 Motivation: Good for when NETCONF client does not have direct network access to NETCONF server. It would be good to have a gateway. Dean Bogdanovic: Why can't an EMS get to a Network Element? Michael Wang: Perhaps there is no direct connectivity from this domain Martin: How do we authenticate between proxy and server? Michael: Not all clients will use the same credential information Mahesh: Whose username/password or credentials are used for the proxied connection? Does storing this mean others can have access? Michael: Yes, this storage will have this exposure Kent: For VNF scenarios this is an important problem. We do see Gateway devices. No so sure Cloud center scenario Kent: Would love to see this work with all protocols. With SSH we can do this without having a transport specific proxy. Not the case with TLS. Not sure if this should be examined at the transport level or application level protocol. Dean: I have not seen such segmented management networks. Typically this is not an issue. Mahesh: (mirroring Kent's point) Need to address credential issues if done at the application level.