## Agenda for the NETCONF 118 WG Session {#agenda-for-the-netconf-118-wg-session} https://datatracker.ietf.org/meeting/118/materials/agenda-118-netconf Session: TUESDAY, November 7, 2023 Morning Session I (09:30-11:30 CET, 08:30-10:30 UTC) WG Chairs: Mahesh Jethanandani (mjethanandani at gmail dot com) Kent Watsen (kent plus ietf at watsen dot net) Secretary: Per Anderson (perander at cisco dot com) Available Now: ICS: https://datatracker.ietf.org/meeting/118/sessions/netconf.ics Available During Session: (pick one) In-room Tool: https://meetings.conf.meetecho.com/onsite118/?group=netconf Remote Tool: https://meetings.conf.meetecho.com/ietf118/?group=netconf Audio Only: https://mp3.conf.meetecho.com/ietf118/netconf/1.m3u Chat Only: https://zulip.ietf.org/#narrow/stream/netconf Available During and After Session: Notes: https://notes.ietf.org/notes-ietf-118-netconf Slides: https://datatracker.ietf.org/meeting/118/session/netconf Drafts (PDF): https://datatracker.ietf.org/meeting/118/agenda/netconf-drafts.pdf Drafts (TGZ): https://datatracker.ietf.org/meeting/118/agenda/netconf-drafts.tgz Available After Session: Recording: https://www.meetecho.com/ietf118/recordings#NETCONF Introduction Chairs (10 minutes) Session Intro & WG Status Mahesh and Kent: Status of ongoing work: * https-notif draft has been in IESG review for some time, it had some IANA considerations that are now worked through thanks Rob (Wilton, AD) for that. There are some DISCUSSES that needs to be addressed that will be started after this meeting. * client-server suite of drafts, there are 9 drafts but we hope to be able to finish 3 of them. There is a BBF Liaison statement where they request also the tcp and tls drafts, we will prioritize them and try to get those through first. We need to compose a response, which we will do that with our AD. They are quite stable and deployed in at least two applications. Rob Wilton: We can't guarantee what the IESG review will result in. But we can say that they are quite stable, from a WG perspective they are done. * tls-1.3 draft is submitted for IESG review. * drafts udp-notif, distributed-notif, transaction-id, list-pagination, private-candidate, versioning-in-yang-notif are all work in progress and will be presented in this session. Per A wants to start the discussion for netconf-next and restconf-next, perhaps gather together a side meeting. We will discuss this in the end of the session. Chartered items: NETCONF Private Candidates (10 min) https://datatracker.ietf.org/doc/html/draft-ietf-netconf-privcand-01 Discussion Leader: Robert Wills Mahesh J: even though you separate transaction-id from privcand, can it be a SHOULD or MAY for existing implementations. can the conflict resolution still be used? Rob Wills: It might require a bit more thought. Will be discussing with Jan Lindblad and send the outcome to the list. Kent W: Can you explain the RESTCONF support? Rob Wills: privcand is not useful in RESTCONF, because it only lasts during the session/request. behavioral change is if the privcand capability is advertised then candidate is committed to running if NETCONF sessions have changed the candidate the RESTCONF request will commit this to running. this means that if privcand capability is used the RESTCONF session can't commit other sessions' changes. Kent W: So RESTCONF is not supported then? If so need to rework. NETCONF sessions typically don't close because of RESTCONF session commits. Management systems typically have long lived NETCONF sessions, order of days or weeks. I would like RESTCONF to be able to use privcand. Mahesh J: Any RESTCONF edits will conflict with wathever the NETCONF session is doing. Kent W: The commit for NETCONF happens when the session is closed, but many NETCONF sessions don't close the sessions. Rob Wilton: A NETCONF session does a commit, and that will commit the candidate at that point in time. Mahesh J: So it isn't really tied to the closing of the NETCONF session? Kent W: Still open issue with RESTCONF support, privcand should be supported for RESTCONf as well. Rob Wilton: The NETCONF issue is moot, it just means your privcand will be open a longer period of time. Kent W: Actually a misunderstanding, it is not at session close but at commit. Rob Wilton: Then you create a new privcand? James C: Doesn't cause an issue for long lived NETCONF sessions, doesn't cause any issue with management systems. privcand is less useful for RESTCONF since the session only lasts during the request. Kent W: NETCONF looks brilliant; would like to see RESTCONF support, would like to see some ability to use it. Rob Wilton: for RESTCONF you could create a privcand with a random id, how to stop any other session to edit it? would be nice with more RESTCONF support beyond a single request. Kent W: could be tied to the RESTCONF authenticated username Jan L: valuable work, too many modes. reducing number of modes would enable easier implementation. one mode (auto-update), you need to keep running in the db at all times which means calculating deltas for auto-update continuously. privcand can be implemented as snapshots of running or deltas towards running. if running is big this becomes a scaling problem. i would like privcand to work in large scale systems. a lot of things in transaction-id could be valuable for privcand as well, perhaps a separate draft for conflict resolution. Rob Wills: auto-update is defined as continuous rebase in the draft. the WG should look at the modes and if they can be reduced and how it can be made to work in large scale. would be nice to define conflict resolution together with transaction-id. Quifang Ma: Not all of my comments are resolved, e.g. RPC call update but YANG model doesn't update it. Rob Wills: correct, we will work on defining a YANG module. Kent W: Next steps? Rob Wills: Take comments from session and on list and discuss there for a new revision of the draft. Transaction ID Mechanisms for NETCONF (10 min) https://datatracker.ietf.org/doc/html/draft-ietf-netconf-transaction-id-02 Discussion Leader: Jan Lindblad Transaction-ID Per Andersson: RESTCONF ETag and transaction-id support between protocols, e.g. HTTP ETag is defined as US-ASCII but transaction-id identifier is UTF-8. Furthermore HTTP Etag is unique per encoding if strong (consequences for matching), if instead weak need to prepend with W/. See https://mailarchive.ietf.org/arch/msg/netconf/HH8sIjx7vuLd42T71PuuUP-P4Bw/ Jan L: Very good point, we need to update the exact format for these tags to better conform with the HTTP documents. It doesn't change the solution. POLL: Ready for WCLG YES: 13, NO: 0, ?: 38 Rob Wilton: I note that it is another poll with a large "no opinion", might be a large portion of the room that don't know. Jan L: the document is approaching LC, it is stable and now is a good time to read and give feedback. Rob Wilton: would be good to resolve overlap of transaction-id and privcand before WGLC Trace Context No comments. List Pagination for YANG-driven Protocols (10 min) https://datatracker.ietf.org/doc/html/draft-ietf-netconf-list-pagination-02 Discussion Leader: Per Andersson POLL: Should cursor based pagination be opt-in? Yes: 14 No: 2 Quifang Ma: How does a client know when to use snapshot? Per A: Up to the user. Might be missing how to reuse the snapshot for subsequent requests. Kent W: Depending on size of the data for "config false", the user might want snapshot. UDP-based Transport for Configured Subscriptions (10 min) https://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-notif-11 Discussion Leader: Alex Huang Feng Mahesh J: (chair) we have sent request to transport directorate and waiting for request. Mahesh J: (contributor) is the recommendation to adapt to the MTU? Alex HF: If there is risk for packet loss you should not use udp-notif. you can set the MTU depending on your network capabilities. Mahesh J: the SHOULD is pretty strong recommendation Alex HF: with YANG-Push the message is variable. we reference the RFC 8085 UDP Usage Guidelines Mahesh J: Either you state that you want to support it or limit the size of the packets. Alex HF: ok, it should be supported but the packets should be small. Rob Wilton: when UDP is being used, IESG reviews often require congestion control. maybe suggest that this should only be used when it can be guarenteed to be no congestion or the device receiving is close by so it doesn't matter. there needs to be some text for this. Alex HF: there is text for it. Rob Wilton: Hopefully that is enough. Kent W: it is just counters, so it isn't a big deal to lose a thing. with yang-push message is variable, perhaps there could be guidance for when to use https notif and udp notif, e.g. suggest use https generally but use udp for high troughput, if messages are below MTU size in the network use udp. Alex HF: don't like going that far in recommendations, it should really be up to the user. ok with having a statement use https notif if the package is big, but wouldn't go that far. Kent W: Agreed. Subscription to Distributed Notifications (5 min) https://datatracker.ietf.org/doc/html/draft-ietf-netconf-distributed-notif-08 Discussion Leader: Thomas Graf Kent W: This work depends on udp-notif which depends on udf-client-server which is not yet adopted. We could progress this but it would be stuck in MISSREF in RFC Editor. Thomas G: We should discuss this when that draft is presented. Support of Versioning in YANG Notifications Subscription (5 min) https://datatracker.ietf.org/doc/html/draft-ietf-netconf-yang-notifications-versioning-03 Discussion Leader: Thomas Graf SIDE MEETING: YANG @ Kafka Nov 7th at 15:30 in Palmovka 1/2 Non-Chartered items: Support of Hostname and Sequencing in YANG Notifications (5 min) https://datatracker.ietf.org/doc/html/draft-tgraf-netconf-notif-sequencing-02 Discussion Leader: Thomas Graf Thomas G: Requesting WG adoption Jan L: How do you foresee that the hostname (where it is generated) should be known for the consumer at the very end? Thomas G: We aligned with the BMP Protocol, it should be known in the management configuration since it needs to be configured on the host. Mahesh J: Is there any reason why this draft is separated from the yang-push-observation-time draft? Thomas G: Here we extend the notification header with generated timestamp, in the other draft we update the yang-push statement with observed timestamp. POLL: Have you read the notif-sequencing draft? YES: 6, NO: 13, ?: 38 Mahesh J: Not many have read it, continue the discussion on the mailing list. YANG model for NETCONF Event Notifications (10 min) https://datatracker.ietf.org/doc/html/draft-ahuang-netconf-notif-yang-03 Discussion Leader: Alex Huang Feng Mahesh J: (chair) you had a slide comparing NC messages. there is a time definition in a WG document. We can't have two documents defining the same thing. Have you talked with the authors of draft-ietf-netconf-notification-messages. Can this be used for you also? Alex HF: They define a whole new structure to bundle notificitaions in the same message. I only implement the gap missing. notif-messages should depend on my draft. Rob Wilton: CBOR-SID was blocked in IESG review, should now be resolved. Is probably worth allocating a CBOR-SID range for this and generate a SID file. Alex HF: have asked CORE WG chairs for guidelines, there are none. Need guidelines for subsequent work e.g. YANG-Push how to define notifications and allocate CBOR SIDs. Rob Wilton: The CBOR-SID should have guidelines for allocating SIDs for existing RFCs. Maybe you want to optimize the SID allocation so this and yang-push SIDs are close together. Alex HF: To actually use CBOR-SID you would need the entire SID range for all YANG dependencies. I don't mind doing it, but the WG should push other drafts to allocate CBOR-SID. Rob Wilton: If an RFC with a YANG file defines a SID, the depending RFC/YANG are allocated automatically. Kent W: Thank you for your contribution. Very welcome when people write drafts to fill gaps. Thomas Graf: The industry has implemented proprietary YANG-Push implementations. They are aware of missing definitions and this work should be progressed very quickly. Kent W: As a chair I would like to fast track this adoption as well. Ahmed Elhassany: You can validate messages. Why use structs for this? Is new tooling needed? Alex HF: We are tryng to use yangkit, they have support for this header. Notification is defined as a keyword, that is why using structs is needed instead of a simple container. The push-update is defined as a type, and this notification type is not defined. Ahmed Elhassany: Must be some implementation section on how you would validate the messages with the structure you define. Kent W: I have software that rewrites the structure to container internally, then validates it. Cheap but it works. Ahmed Elhassany: We need it documented how to perform this validation. YANG Grouping for UDP Clients and UDP Servers (10 min) https://datatracker.ietf.org/doc/html/draft-ahuang-netconf-udp-client-server-00 Discussion Leader: Alex Huang Feng Kent W: (contributor and co-author) the draft only need udp client/server groupings, not defining tls/dtls in this draft since they are defined in the tls-server-client draft. Alex HF: I implemented it because it was suggested in a mail from Mahesh. Mahesh J: Probably must have suggested it because one grouping needs to be used inside. Kent W: Not needed since you can use and stack the tls/dtls where needed. Alex HF: If the WG agrees, I'll remove it from this draft. Kent W: That makes this draft even smaller and quicker to get through Thomas Graf: By moving out that to another draft, we're creating another dependency. The industry is moving forward and looking forward to the adoption of YANG-Push, so we welcome this being fast tracked. Benoit Claise: always other goals with groupings. Since there are dependencies that can't move if this is not done. Can we put a deadline and progress if the client/server drafts are not done by then? Because we need those dependencies now. Kent W: The chairs are in agreement that this work should be fast tracked since it is a dependency for an existing WG document. YANG push Integration into Apache Kafka (10 min) https://github.com/network-analytics/draft-daisy-kafka-yang-integration/blob/main/INF690\_presentation.pdf https://github.com/network-analytics/draft-daisy-kafka-yang-integration/blob/main/Zhuoyao\_final\_thesis.pdf Discussion Leader: Zhuoyao Lin Rob Wilton: one concern with adding augmentation list into yang-library is that this could be duplicate information, alreaday specified in yang modules but now another mechanism with the same data. this can become out-of-sync now and you have to trust what you are going to use; I guess the answer is to always depend on the YANG module being correct. a possible down-side of doing this. Benoit Claise: not different from a deviation, it's actually a timing issue, if you want to use yang-push and ipfix, do we want to loose the time to get the full schema. issue is real-time timing for telemetry. this is a small cost to solve that problem. Rob Wilton: in YANG packages we are taking deviations out to remove this sort of duplication, i.e. going the other way. Jan L: This information is already available elsewhere, but it could be an ok trade-off to have it available precomputed for some clients. (CHAT) Benoît Claise: draft-lincla-netconf-yang-library-augmentation-00.txt Mapping YANG Data to Label-Set Time Series (5 min) https://datatracker.ietf.org/doc/html/draft-kll-yang-label-tsdb-00 Discussion Leader: Jan Lindblad (on behalf of Kristian Larsson) Philatelist, YANG-based collection and aggregation framework integrating Telemetry data and Time Series Databases (5 min) https://datatracker.ietf.org/doc/draft-lindblad-tlm-philatelist-00 Discussion Leader: Jan Lindblad Thomas Graf: Amazing! What you just desribed, and looking through your draft: this is probably what a network operator does to make it work end to end. A few comments: On slide 5 you write transport format, one clause would be nice there preserving semantics. Today we are loosing semantics already at the transport. In Section 3.2 in your draft document, you describe how subscriptions need to be established and managed. In the Data Mesh architecture we need SLAs and SLOs when we are subscribing on something, we need guarantees that we get the data and not loosing data because we are streaming data. In section 3.3 you describe, you describe them streams and flows. there is already terminology, in kafka e.g. topics and subjects. right now you are describing when you flatten the data, you need to change the paths etc. We are in contact with TSDB vendors to support YANG, but until that exists this is what an operator needs to do to make end to end work. Jan L: thanks! I wrote this draft just to have make this conversation happen and I am very happy that you bring this up! this work is given me impostor syndrome, there are people in the room that have worked a decade with telemetry collection for every week I worked with it, it is very intimidating to stand here and present but I very much welcome the feedback and collaboration. Ahmed Elhassany: This is very important. We are hacking around TSDB to support YANG and the semantics, this is not about drawing graphs but providing insights. Need a more ideal solution than a mapping to services. There is a lot of interest with TSDB vendors to support YANG, let's make it a two-way conversation and not just do a mapping to their work. End of presentations. Per A raised if there is interest in work for starting looking at restconf-next and netconf-next. Per A: Now when a lot of work is getting finalized the WG could have time to look at restconf-next and netconf-next. A first step would be to categorize the open issues to see what can be done without yang-next, without a new protocol version, what is already done, what is uninteresting? About a quarter of the room showed interest. Per will book a side meeting and announce it on the mailing list. 15 Minutes Remaining