Introduction Chairs (10 minutes) Session Intro & WG Status Chartered items:appleds Network Telemetry with BMP and YANG Push @ IETF 110 Hackathon (5 min) https://github.com/IETF-Hackathon/ietf110-project-presentations/blob/main/ietf-110-hackathon-bmp-yang.pdf https://tools.ietf.org/html/draft-ietf-netconf-udp-notif-01 https://tools.ietf.org/html/draft-ietf-netconf-distributed-notif-01 Discussion Leader: Thomas Graf Kent: Performance was much better, was that latency or throughput. Thomas: Focus on throughput not latency. Hard to compare with gRPC. About 10 or 20 times faster than gRPC. Want to add HTTPS notif with UDP notif. Kent: Would get HTTPs is likely to be slower than gRPC. Thomas: Encoding is JSON, will change ... Kent: It is possible for CBOR to be encoded as well. Status and Issues on Client-Server Suite of Drafts (10 min) https://tools.ietf.org/html/draft-ietf-netconf-crypto-types-9000 https://tools.ietf.org/html/draft-ietf-netconf-trust-anchors-14 https://tools.ietf.org/html/draft-ietf-netconf-keystore-21 https://tools.ietf.org/html/draft-ietf-netconf-tcp-client-server-09 https://tools.ietf.org/html/draft-ietf-netconf-ssh-client-server-23 https://tools.ietf.org/html/draft-ietf-netconf-tls-client-server-23 https://tools.ietf.org/html/draft-ietf-netconf-http-client-server-06 https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-server-22 https://tools.ietf.org/html/draft-ietf-netconf-restconf-client-server-22 Discussion Leader: Kent Watsen Rob: If crypto types requires changes due to SECDIR review, then will that impact the other drafts? Kent: Yes, potentially, but we plan to ask the AD to hold the drafts in their queue before sending them to the IESG as a batch. Kent: Should we move the next tranche of drafts to WGLC together or two batches. Mahesh: Two batches might be better. Rob: Agrees with Mahesh An HTTPS-based Transport for Configured Subscriptions (10 min) https://tools.ietf.org/html/draft-ietf-netconf-https-notif-08 Discussion Leader: Mahesh Jethanandani Rob: What other codes might need to be defined? Mahesh: I don't think that any more need to be documented in the draft. Kent: We would not define any. HTTP is a published standard, and an implementation can respond with any of the published responses, including 401. Publisher which is an HTTP client, and would be able to handle the responses. Expectation other responses. Rob: What is a publisher expected to do handling these codes? Are they expected to have a handler for those codes, or are they expected to be handled in a standard fashion. Mahesh: The draft is not expecting any special handlers for the codes the publisher is expected to recieve. Kent: Http status codes are grouped into categories. 5xx are server errors. Perhaps the backend server database is full, so returns a 500x error. Are you suggesting that those errors be documented by this draft? Rob: Worth specifying behaviour if some specific action needs to be taken, otherwise not. Kent: As an author, makes sense to define how 500x errors are handling (i.e., no buffering is required.) Rob: That makes sense. Non-Chartered items: Telemetry Data Export capability (10 min) https://tools.ietf.org/html/draft-tao-netconf-data-export-capabilities-03 Discussion Leader: Peng Liu Tim Carey: Looked at multiple transport/encodings? Also some outstanding issues related to online discussion. Where those issues resolved? Qin: For the second issue, we have already addressed to handle multiple transport/encodings. For Issue 2, advertising the capabilities increases the likelyhood of success. Tim: But did you directly respond to Andy, who raised questions/concerns. Qin: No, we haven't gone back publicly, but have updated the document. Mahesh: We can check with Andy. Tim: Wanted to check concerns were. Mahesh: What is the scenario, where the publisher wants to choose which transport. Qin: Allows clients can choose which transport Kent: Mentioned establish subscription ... Qin: Will discuss with Thomas, don't really want to define two way messages for this. Kent: Any new notif would want to follow the approach of the notif draft. ??? Would that be an overlap on what is being described here? Qin: No. ??? Kent: Does this mean that http-notif should not define the capabilities, and instead point to this draft? Qin: Maybe. Your mechanism provides receiver discovery. Kent: We are in WGLC in that draft. As a contributor, it makes sense for each notif transport to define its own mechanism. Tim: Follow up on Kent's question. What is the value of this draft, if the other drafts define their own mechanisms? Kent: ??? With https, uses the same mechanism to get the capabilities. Intuiting is to allow each transport to define its own mechanism. Mahesh: What is a new transport draft comes along, does it need to define a new capabilty? Qin: Yes, we support UDP notif and HTTP notif. Rob: Capabilities ??? Kent: If RFC 8639, for each subscription, ... which ever draft that defines a transport, it can choose whether that leaf is configurable. This was discussed by the authors, statically configuring XML vs JSON was less helpful that a dynamic response. HTTPS notif draft does not define the identity in a way that enabled that when statement. Also note, that there other capabilities, e.g., bundled messages. Rob: Concern is that we defining capabilities in an adhoc fashion, and perhaps need to take a holistic view of how to handle capabilities, rather than doing it individually for each protocol. Mahesh: Benoit agrees to have discovered capability. Benoit: Important to have discovered capabilities. Solving the next step of network management, will require a more holisitic view. Kent: Dynamic discovery is better than static discovery? Is that right, Benoit? Benoit: This is correct. Adaptive Subscription to YANG Notification (10 min) https://tools.ietf.org/html/draft-tao-netconf-data-export-capabilities-03 Discussion Leader: Qiufang Ma Kent: Are you assuming that the receiver would have a secondary connect to the publisher, so that it can then sent these message? Qiufang: Allows ... Kent: By dynamic subscription, receiver is already connected, then it makes sense to send these over the existing channel, but when the subscription is configured then a separate connection will be required. Qin: For dynamic, we won't have a second connection, but for configured, I agree with you. Kent: ??? Qin: For server, it automatically switches the data rate. Send a notification that the collect rate has changed. Do you think that additional capabilities are need? Kent: Not necessarily, just wanted to check that my understanding is correct. Qin: Didn't see an issue. Mahesh: With a chairs hat on, Authors suggested having converstaion with Thomas, would recommend that the authors post their questions/discussions to the mailing list so that other parties can contribute. Qin: That makes sense. With System Capability for NETCONF (10 min) https://tools.ietf.org/html/draft-ma-netconf-with-system-01 Discussion Leader: Qiufang Ma Balazs: We already have an RFC about factory default configuration, that should be included in the initialization usecase. I don't find the report-all, explicit mode to be inituitive in this case, that should be use for reporting rather than initializating. Although, not popular in our circles, there are other organizations that do write configuration into running. Qin: In reply to Rob. The question is how would the client know that System configuraiton has changed, and the RPC is necessary. Rob: A client could have a subscription on the system datastore. Tim: If that is the case, then what is the value of System rather than just reading operational. I'm missing what a system datastore will provide. Qiufang: ... Tim: Why wouldn't I just use a subscription ... I missed documenting the rest of this discussion that I was participating in. Kent: I think that the same issue was discussed/envisaged with dynamic datastores. I think that system datastore would have to be viewed in that way as well. Kent: As chair, there has been discussion on adoption of the drafts. At the moment, the chairs thin that further discussion on the list is required first. Qin: We will discuss on the list. Kent: It would be good if we could have discussion of issues on the list for each of these drafts. NETCONF Next and RESTCONF Next (30 min) Discussion Leader: Mahesh Jethanandani Kent: Would/should we wait for YANG Next? Mahesh: At least one item to do with YANG Next. Rob: Benoit: Plenty of features. Lots of things that we can be doing. Are these features coming from operators? Mahesh: Agreed, that getting operator feedback would be good. If there are any operators, it would be good to get their input. Kent: Don't know of any pain points that are being expressed by operators. Have certain work in flight, and other work in progress, they are updating existing NETCONF/RESTCONF RFCs. Hope that we can continue doing that. Rob: There is a NETCONF over QUIC, but this probably does not make use of the features of QUIC. Kent: Might require allocating a new port for running over QUIC. Tim: A couple of the standards bodies: We come up against questions about the utilation of YANG with gRPC and GPB. I don't know if that fits into RESTCONF, or whether that is a separate protocol. Particularly as we get into telemetry or control plane, and want to use YANG as a way of conveying the data model, then encoding gRPC and GPB becomes more relevant. Not clear whether that is a new binding for an existing protocol or a new protocol. Mahesh: Summarize: Agree with Benoit to get more operator input. Also agree with Rob that we should consider the impact of QUIC, and we might want to come back and look at what it takes for NETCONF and RESTCONF. Remaining 25 min.