## Agenda for the NETCONF 116 WG Session {#agenda-for-the-netconf-116-wg-session} https://datatracker.ietf.org/meeting/116/materials/agenda-116-netconf Session: Monday, March 27, 2023 Monday Session II (13:00-15:00 JST) 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/116/sessions/netconf.ics Available During Session: (pick one) In-room Tool: https://meetings.conf.meetecho.com/onsite116/?group=netconf Remote Tool: https://meetings.conf.meetecho.com/ietf116/?group=netconf Audio Only: https://mp3.conf.meetecho.com/ietf116/netconf/1.m3u Chat Only: https://zulip.ietf.org/#narrow/stream/netconf Available During and After Session: Notes: https://notes.ietf.org/notes-ietf-116-netconf Slides: https://datatracker.ietf.org/meeting/116/session/netconf Drafts (PDF): https://datatracker.ietf.org/meeting/116/agenda/netconf-drafts.pdf Drafts (TGZ): https://datatracker.ietf.org/meeting/116/agenda/netconf-drafts.tgz Available After Session: Recording: https://www.meetecho.com/ietf116/recordings#NETCONF Jabber Logs: https://www.ietf.org/jabber/logs/netconf Introduction Chairs (10 minutes) Session Intro & WG Status Quifang: Is there interest in the WG for working on netconf/restconf-next? Kent: For this work to start it would probably be initiated by yang-next in netmod, this would then trickle down to NETCONF WG. Doesn't make sense to publish anything until then. Mahesh: What are some of the areas of interest? Quifang: We already have some work, like list-pagination and transaction-id and issues like binary encoding and binary notif and some issues might need a netconf-bis. Kent: This is a good suggestion long overdue, but I want to remind the WG that this is a volunteer effort and if someone is looking for an interesting draft to work on there are issues on the netconf-next and restconf-next issue trackers. Mahesh: Some of the work can be brought forth without netconf-next. Chartered items: UDP-based Transport for Configured Subscriptions (5 min) https://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-notif-09 Discussion Leader: Alex Huang Feng Alex: Have received some feedback about observation-domain-id and message-id. Source IP should be used to ensure uniqueness. message-id is per observation-domain-id and not per subscription. o-d-id was decided to not change, but remove all IPFIX references and define o-d-id in distributed-notif, so in scope of yang-push. Rob: What are the actual definitions in the draft, how do they look like compared to IPFIX. Is it going to confuse the readers using the same names? Are they semantically equivalent? Alex: The definitions are similar. From your feedback we want to separate the concepts for IPFIX and yang-push. Rob: The definitions were different, that's why the concern were raised. Mahesh: Noticed a grouping called udp-transport-params but looking at the tcp-client-server drafts, would it make sense to have a similar grouping for in e.g. udp-client-server? Alex: Let's look into that. Benoit: In IPFIX, we have the notion of observation-domain-id, typically this is line card in which you have cache and exporting. Is this a high level goal for yang-push to use the same value here and in IPFIX for observation-domain-id? Alex: The observation-domain-id is the exporter process but not expected to be the same as the IPFIX one. Alex: No feedback on the issues from the list. Let's review the udp-client-server grouping. Can we have a WGLC at some point? Mahesh: One more revision before WGLC. Kent: Definitely one more revision if we should incorporate udp-client-server. Subscription to Distributed Notifications (5 min) https://datatracker.ietf.org/doc/html/draft-ietf-netconf-distributed-notif-05 Discussion Leader: Alex Huang Feng Alex: observation-domain-id is actually an integer, was defined as a string. It is bound to udp-notif, ask for WGLC at the same time. List Pagination (10 min) https://datatracker.ietf.org/doc/html/draft-ietf-netconf-list-pagination-01 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-list-pagination-nc-01 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-list-pagination-rc-01 Discussion Leader: Per Andersson Poll Question: SHOULD SNAPSHOT BE FURTHER BE DOCUMENTED IN LIST-PAGINATION? Poll Results: Few participants, no clear conclusion Kent: low participation. Possibly because not enough people understand the solution. Per: No real solution. We could show through an attribute perhaps if the underlying result set is a snapshot or not. Mahesh: Would definitely suggest you take it to the list. Kent: could you give an concrete example? Per: One could supply sort-by-locale together with sort-by for instance, and also report what locale was used when sorting together with the result set. Balazs (from chat): Ö might be after O in some locales but might be after Z in others Poll Question: SHOULD LOCALE BASED SORTING BE FURTHER DOCUMENTED IN LIST-PAGINATION? Poll Results: Working group is not interested Rob: I'm struggling to see the real use case for this, but I think it might be useful. I think the understanding where it really helps and use cases would really be beneficial. Mahesh: I would agree with Rob, I voted no mainly because of lack of understanding. A more concrete example about how useful it would be discussed on the mailing liste before we decid that it is not something that we should not pursue. NETCONF over TLS 1.3 (10 min) https://datatracker.ietf.org/doc/html/draft-ietf-netconf-over-tls13-02 Discussion Leader: Sean Turner Sean: Addressing LC comments Mahesh: We will watch the mailing list for a few days but then progress it Sean: Should we maybe do a LC because the title and scope changed? Rob: I have a large queue of documents to review, so giving it two weeks would be great. Sean: There is a work in tlswg for deprecating TLS 1.2 entirely, which will have big implications for this draft. Two weeks more is fine, we are not in a hurry. Transaction ID and Tracing Mechanisms (30 min) https://datatracker.ietf.org/doc/html/draft-ietf-netconf-transaction-id-00 https://datatracker.ietf.org/doc/html/draft-rogaglia-netconf-trace-ctx-extension-01 https://datatracker.ietf.org/doc/html/draft-quilbeuf-opsawg-configuration-tracing-00 Discussion Leader: Jan Lindblad, Roque Gagliano and Jean Quilbeuf Jean: Mainly cosmetic and editorial changes. The interesting part is how to leverage netconf-trace-ctx-extension. Jean: Open questions: * switch dependency from transaction-id to trace-ctx-extension, would simplify things. * Where to get client-id from Kent: The slide says that trace context can be used for RESTCONF as well. Jean: It is HTTP based so it works with RESTCONF. Roque: the W3C baggage might be a better place to put client-id than trace-ctx, not introduced yet but will be the next step in our work. Jan: Transaction-ID, next steps need some implementation experience so the standard is tested and reviewed. Roque: Trace-CTX, a key element for using OTLP (opentelemetry protocol) is to tap into the ecosystem of collectors etc that exists. Jan: Overview of netconf-transaction-id, opsawg-configuration-tracing, netconf-trace-ctx, netconf-private-candidates. Great overlap in use cases, not much overlap in functionality, but could be put in a coherent framework. All techniques can be used, and are useful, by themselves. Rob: Good to align. Try to avoid a fifth document for the framework. If the text in the four documents can have informative text on how to use together with other drafts that might be enough. If not, write a fifth overview document. Jan: I agree totally, but wanted to give some negotiating space. Mohamed (chat): I think that it makes sense to have one framework doc, but keep the solution I-Ds separate. The framework is helpful for those who will use the functionality. Mahesh: actually an archictecture document would help, but you can choose to wait for synchronized terms (between drafts) or start the fifth document. Rob: Thinking of the packaging work where we started with a problem statement definition and then an overview for the solution. But going forward we have sort of lost those in the process and will try to not have those. We have copied some of the base spec. The difference there is that the drafts there build upon each other more whereas I think these sit as a set. But I'm not wedded to any particular solution here. Kent: In between the two ideas being put forward, looking at the client-server set of drafts; they all have a few paragraphs preamble presenting the solution and how that draft is related to the others, the suite of drafts. Jan: That (kent's suggestion) would be ideal. Benoit: Don’t want to be blocked by the lack of architecture document, no issue with writing it after. Non-Chartered items: NETCONF Private Candidates (10 min) https://datatracker.ietf.org/doc/html/draft-jgc-netconf-privcand-00 Discussion Leader: James Cumming James: The -01 revision of the draft haven't been published yet but will be soon. Private candidates more relevant for NETCONF so no work is done to define it for RESTCONF. Kent: clarify the statement about private candidate is more relevant to NC. Poll Question: SHOULD PRIVATE CANDIDATE SUPPORT RESTCONF AS WELL? Poll Results: No conclusion Rob: Definitely makes sense to think about RESTCONF, but might be interesting (due to NMDA and datastore concept in RESTCONF) or not (RESTCONF being a simpler protocol). A way forward would be think about RESTCONF but maybe define it in a document later on. Having one document is easier to review, and perhaps split out protocol specific bits later on. James: Address the outstanding questions, discuss them on the list, and then ask for WG adoption. YANG model for NETCONF Event Notifications (5 min) https://datatracker.ietf.org/doc/html/draft-ahuang-netconf-notif-yang-01 Presented by: Thomas Graf Thomas: Asking for WG adoption. Should proceed quickly because the draft addresses missing YANG modelling for definitions from RFC 5277 and RFC 8639. Support of Hostname and Sequencing in YANG Notifications (5 min) https://datatracker.ietf.org/doc/html/draft-tgraf-netconf-notif-sequencing-00 Presented by: Thomas Graf Thomas: Extends NETCONF notification defined in RFC 5277 with fields sysName, publisherId, and sequenceNumber. Support of Network Observation Timestamping in YANG Notifications (5 min) https://datatracker.ietf.org/doc/html/draft-tgraf-yang-push-observation-time-00 Presented by: Thomas Graf Thomas: Extends YANG-Push streaming update notification defined in RFC 8641 with fields observation-time and state-changed-observation-time. Support of Versioning in YANG Notifications Subscription (5 min) https://datatracker.ietf.org/doc/html/draft-tgraf-netconf-yang-notifications-versioning-03 Presented by: Thomas Graf Thomas: Extends YANG-Push subscription and publishing mechanism defined in RFC 8641 by adding the ability to subscribe to a specific revision or latest-compatible-semversion and also by extending the YANG-Push subscription state change notification message so that the YANG-Push receiver lears beside the XPath and the subtree filter also the revision and revision-label. Rob: Good and important work, how to get data from device and into e.g. analytics. Joe: Maybe I need a concrete example, the drafts give two definitions for observed-time. I would love a concrete example, e.g. the device would put this timestamp for this event, this other timestamp for another event etc. Tomas: sync-on-start would give the original time two weeks ago Benoit: There are a lot of drafts, but there were specific questions per document about adoption. Maybe there are questions for the chairs here. Poll Question: HOW MANY PEOPLE HAVE READ ANY OF THE MESH DRAFTS? Poll Results: Almost half of the attendees had read at least one draft. Rob: Brilliant that operators propose solutions to problem they encounter. Poll Question: ARE PEOPLE INTERESTED IN THE MESH WORK? Poll Results: Yes, the WG is interested in this work Mahesh: We could start with the YANG module draft that adds a date-and-time header to the notification, but defer the rest of them to give the WG time to read the drafts. The adoption poll will be proposed on the mailing list. Incident Management for Network Services (10 min) https://datatracker.ietf.org/doc/html/draft-feng-opsawg-incident-management-00 Presented by: Qin Wu Qin: Asking for feedback for this opsawg draft. Mahesh: Would it be useful to look at the draft from the previous presentations to see if timestamps and trace could be used to do the correlation between events? Qin: That could be interesting to look at and we could take it to the list to discuss it. Rob: Have you had a look at the SAIN (service assurance) architecture, where signals from the network are aggregated into something meaningful that can be acted on? How does it relate to the dmlmo draft (draft-palmero-opsawg-dmlmo)? Machine learning might not be that effective, it feels a be over-hyped. Qin: Could reduce pressure on management systems. Thomas: Very valuable work. Good to build on top of existing alarm-eventing YANG model. I have been reviewing the draft and this aligns well with our work, adding additional metadata so the network device can be better identified and also adding better timestamping where the observation time of the network is being described. Oscar: Have you considered health operation for devices, instead of just reporting alarms for errors have you thought about reporting current status of a device? Qin: Good suggestion, thank you! OPEN MICROPHONE Rob: Have reviewed client-server drafts, one question that came up was how we handle keys built-in to the device, have been looking at system datastore draft. We should be able to use the keys without effectively copying them in.