Agenda for the NETCONF 119 WG Session ------------------------------------- https://datatracker.ietf.org/meeting/119/materials/agenda-119-netconf Session: TUESDAY, March 19, 2024 Morning Session II (13:00-15:00 , 03:00-05:00 UTC) WG Chairs: Kent Watsen (kent plus ietf at watsen dot net) Per Andersson (per dot ietf at ionio dot se) Available Now: ICS: https://datatracker.ietf.org/meeting/119/sessions/netconf.ics Available During Session: (pick one) In-room Tool: https://meetings.conf.meetecho.com/onsite119/?group=netconf Remote Tool: https://meetings.conf.meetecho.com/ietf119/?group=netconf Audio Only: https://mp3.conf.meetecho.com/ietf119/netconf/1.m3u Chat Only: https://zulip.ietf.org/#narrow/stream/netconf Available During and After Session: Notes: https://notes.ietf.org/notes-ietf-119-netconf Slides: https://datatracker.ietf.org/meeting/119/session/netconf Drafts (PDF): https://datatracker.ietf.org/meeting/119/agenda/netconf-drafts.pdf Drafts (TGZ): https://datatracker.ietf.org/meeting/119/agenda/netconf-drafts.tgz Available After Session: Recording: https://www.meetecho.com/ietf119/recordings#NETCONF Introduction Chairs (10 minutes) Session Intro & WG Status Mahesh Jethanandani: Thanks Rob for your service as an AD, a true service for the community! Mahesh Jethanandani: Discussing vision as AD. Looking into increasing adoption of YANG and what is possibly missing for greater adoption. Chartered items: List Pagination for YANG-driven Protocols (10 min) https://datatracker.ietf.org/doc/html/draft-ietf-netconf-list-pagination-03 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-list-pagination-nc-03 https://datatracker.ietf.org/doc/html/draft-ietf-netconf-list-pagination-rc-03 Discussion Leader: Qin Wu Rob Wilton: Just a clarifying question. For the locale, what impact would it actually have? So for two two examples showing it being returned directly, what does the server do with that information? If you change the sorting mechanism, Per Anderson: I can clarify. That is exactly correct, Robert, it changes colating? Rob Wilton: And is that optional to support or mandatory to support? Per Anderson: it's mandatory Rob Wilton: okay Per Anderson: it's not mandatory to take it it, but it is mandaory to report it. Rob Wilson: okay. And what is the differnce between the UTF-8 and the non UTF-8? Per Anderson: nothing Rob Wilson: okay Per Anderson: because on my system, the OS reports with UTF-8, it's a Linux system, so it reports the locale with ".UTF-8" afterwards but, in the draft, it says that they are the same, which happens to supprt both, so they are equal, with or without the ".UTF-8" suffix. Rob Wilson: okay, thanks NETCONF Private Candidates (10 min) https://datatracker.ietf.org/doc/html/draft-ietf-netconf-privcand-02 Discussion Leader: James Cumming Kent Watsen (as a chair): This WG only needs to care about NETCONF and RESTCONF, no need to care about CORECONF. I only mentioned it, I think in parentheses, assuming it would apply to CORECONF but, I think Carsten replied (James: he did), so it's really a side conversation, not for this working group. James Cumming: exacly, we just want to understand applicability and if we need to take it to the other working group. Rob Wilton (as a contributor) Will a client know how a server will behave? James Cumming: the way the draft is written currently, it will behave in a single way, it will behave as if it were in a manual-update mode always, however a server may choose, as an implementation option, to run an update itself separately, but not based on how that client would have triggered that at all. The client, we felt from a reworking of the text, doesn't need to be aware of that particular activity; the resultant changes it would be aware of. So, for examples, and this ties into ?garbled word?, let's say you make a change in one of the candidates, and the system has chosen to run an update, for whatever reason (e.g., trigger, schedule, etc.), those elements in that update scenario would get still marked, potentially, in conflict dependant on how we rework this piece of text, so a commit from any client would stil fail and be identified as this is a problem, so you still would not be committing other people's change's without knowledge. Rob Wilton: would you get behavior change in that case? James Cumming: no, the get behavior would not change in the case Rob Wilton: For the auto-update case James Cumming: the GET behavior wouldn't change in any case. The candidate that stands, is what will be returned by a GET Rob Wilton: Er, what I'm trying to think in my head, is that I know that servers have flexibilty to choose what modes to operate in, and if that is going to be lost here... James Cumming: and what you say which modes? Rob Wilton: whether auto-updates of updates are done manualy. Because it impacts clients, becuase the clients have to interact with the server, probebly should know what behavior the server will interact in James Cumming: we've definetively taken that into account with the rewording. It is clear that there are different approches to doing this. We think the text covers both of those implementations, coupled with the automatic resolution piece, that will come in -03, without having to explicitly set it in another mode and then have to advertise that. Again, we have a negotiation thing , which is beyond what the client needs to know about, so you will still know it happens, the client will still see updates, or failed updates, depending on what what situation it is in. Rob Wilton: okay, I need to read it Kent Watsen: so what are thoughts for next steps? James Cumming: next steps are to put -03 out fairly quickly after the meeting and then see how that conclusion goes, espesially in the RESTONF area, which is a piece we nned to get right. And then, after that point, we'll consider if we're in a Last Call situation. Mahesh Jethanandani: and also the YANG model? James Cumming: the YANG models need to go in, absolutely, I think that they are going to be fairly staightforwoard additions to the existing ?garbled? so they won't be contentious. Transaction ID Mechanism for NETCONF (5 min) https://datatracker.ietf.org/doc/html/draft-ietf-netconf-transaction-id-03 Discussion Leader: Jan Lindblad POLL: Have you read the transaction-id draft? YES: 11, NO: 7 Kent Watsen: not much room response, too ealy to poll for consensus. You did say that there was one more issue to resolve with reagerds to private candidate? Jan Lindblad: nothing to resolve, but there is an area of potential overlap Kent Watsen: okay we'll work through that and encourage people to read the drafts before IETF 120. Kent Watsen: ideally the draft would be adopted with private-candidate and a couple others? Jan Lindblad: it's alread adopted Kent Watsen: i meant moving to WGLC Mahesh Jethanandani: did you have a question on the transaction-id? James Cumming: just a quick clarification on this slide, I believe the draft includes both operation and intended datastores for the GET side of things, is that right? Jan Lindblad: yes, but yo don't have any transaction ids for the operational parts, James Cumming: and there is nothing in the draft expliclictly restricting its use on "config false". I know that it's not the primary aim. but technically... Jan Lindblad: there is no transaction-ids for the "config false" data, so while you can use the operations, they won't give you anyting new James Cumming: sure, but there is nothing saying that they couldn't be added in the future Jan Lindblad: the WG could consider but it would be a lot of work. It is not not something that you change just two sentences and then it would be fine. James Cumming: thanks Kent Watsen: James, is there a reason why you are asking? James Cumming: with relation to the GET side of things, I can see some use-cases where you may want to get things that have not changed. So lets say you had something in intended and that expanded verions changed. Jan Lindblad: I agree that there are potentional use-cases for the operational case, and the 'config false" case as well, but I did not cover that in the protocol. Rob Wilton: based on what James said, does this affect :intended, because that is a configuration datastore Jan Lindblad: yes, I think so. It doesn't mention it explicitly but the mechanisms work the same Rob Wilton: that one might be worth clarifying Coexistance of transaction-id + private-candidate (5 min) Discussion Leader: Jan Lindblad Balazs Lengyel: just to the last two slides, this would bring privcand in line with what others do in e.g. 3gpp. it only contains the delta. operators could then work independently separate parts of the configuration. Kent Watsen: I'll take that as a show of support. James Cumming: Thanks Jan for the pre-visabilty of the discussion. We have looked up what is a conflict and want to make it more descriptive. (change of value, change of attributes). Plan is to be much more descriptive there. James Cumming: regarding the "implementation slide" and Balazs's comment, the rest of NETCONF/NMDA describes candidate being a full copy of the configauration, and that is the appproach we wanted to stick with the privcand draft. However, the implemantion of a server is very open, so maybe the draft doesn't have to be too proscriptive. Kent Watsen: I agree with that Balazs Lengyel: I don't think the implementation is ths critical, but the scope of the potential conflicts. If I'm only working on the Right back branch, I can declare the Left branch I don't care, i.e., any conflicts are not important for me James Cumming: and that is the case Kent Watsen: So transaction-id could be used to resolve conflicts. James Cumming: Yes, and other mechanism could be used. Kent Watsen: let's take that to the list, as to whether we wish to support other mechanisms besides transaction-id. NETCONF Extension to support Trace Context propagation (5 min) RESTCONF Extension to support Trace Context Headers https://datatracker.ietf.org/doc/html/draft-netconf-trace-ctx-extension-00 https://datatracker.ietf.org/doc/html/draft-netconf-restconf-trace-ctx-headers-00 Discussion Leader: Jan Lindblad Kent Watsen: asked Jan to present because it is important for WG documents to present. External Trace ID for Configuration Tracing (5 min) https://datatracker.ietf.org/doc/html/draft-ietf-netconf-configuration-tracing-00 Discussion Leader: Jean Quilbeuf Kent Watsen: Please bring the discussion to the mailing list to have more discussion there. YANG Groupings for UDP Clients and UDP Servers (10 min) https://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-client-server-01 Discussion Leader: Alex Huang Feng Kent Watsen: Your client remote address is ip-address-no-zone? Shouldn't it be possible to define a hostname? Alex Huang Feng: That is in the next slide actually! It was defined as hostname, as in tcp-client-server. Feedback from main downstream user udp-notif draft, was that it was not necessary with hostname but ip-address-no-zone was a more conservative choice. Not against changing but how do they impact the other ones? Request feedback on this. Kent Watsen: udp-notif is not the only consumer of this draft,. Thank you for writing this draft. This draft probably saved the day in IESG review of https-notif, the concern was lack of support of QUIC. Because this draft existed I was able to create a QUIC grouping that basically puts together the TLS plus the UDP grouping, that will probably allow the https-notif draft to pass IESG ballot hopefully today. We shouldn't be thinking of these drafts to have a single consumer anyway; the entire spirit of the client-server suite of drafts is that they are usable by many other contexts. They are used by many other working groups. Alex Huang Feng: I also have a question about the local addresses, should this draft also support local addresses as the tcp-client-server draft does? It was raised by Med during WG adoption. Kent Watsen: As you see in the tcp-client grouping they are with features so it is optional for a server to support them or not. It is useful in some security contexts where they want to specify a pinhole in a firewall, if they can know the source address then it actually enables a much more specific firewall rule to be constructed. And I see Thomas nodding his head, thank you for the support from the operators. Alex Huang Feng: Ok, I will take this direction going forward. Kent Watsen: About dual-stack support I think you are referring to multiple interfaces? Alex Huang Feng: Yes Kent Watsen: There was a general comment many years ago discussed about VRFs. And it was decided to not support VRFs in the core TCP model, because they were complex and they could be augmented in as needed. I don't know if that applies to your comment or question about dual stacks, but it is probably a similar statement. Maybe others in the room has comments? I would propose to model after tcp-client-server, it did exit the IESG review where TCP experts reviewed it without concern about dual stack or VRF support. Rob Wilton: Consistency is a good thing, a sensible thing to do. Your argument say that you had the issue similarly with VRF, you could do that a separate way. Keep it simple. If it ends up wrong we can correct it then. UDP-based Transport for Configured Subscriptions (10 min) https://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-notif-12 Discussion Leader: Alex Huang Feng Thomas Graf: We have three draft documents udp-notif, distributed-notif, and also udp-client-server. It would the right point in time to do a final review on all the three drafts, getting feedback from the WG and maybe before the next IETF do a Last Call. Right now we have several network vendors working on implementation of these drafts. Mahesh Jethanandani: I think the idea for the chairs, although I can't speak for them, is to send these three drafts as a cluster. Kent Watsen: There is a sense of urgency to get these through, that is why we have been going pretty fast already. Your experience with the IETF is a short tenure, and if you think this is slow it is not this is fast! Kent Watsen: What is the encoding for the payload? Alex Huang Feng: For the payload of the udp-notif? Kent Watsen: Yes, are you passing XML, JSON, CBOR? Alex Huang Feng: So it is YANG encoding, we have two media types: public and private. With private, you can encode whatever you want, with public you have XML, JSON, and CBOR so far within the draft. Kent Watsen: A binary encoding is important to be supported for UDP and also for https-notif, but for https-notif the media type is negotiable so CBOR could also be conveyed using https-notif. Wim Henderickx: The discussion on dual-stack in my view, I interpreted it as IPv4 and IPv6 configured on the same interface. In my view I don't see it associated with a VRF necessarily, it is really a single interface with at least one IPv4 and one IPv6 address. It could be more IPv6 addresses potentially, because you typically have link-local addresses and stuff like that. At least for me that should be a default configuration because if you want to support a server with both IPv4 and IPv6, I don't want to end up creating two interfaces. I want to have one interface on the server and have it addressable by both IPv4 and IPv6. Mahesh Jethanandani: This means that the address is a list, and not necessarily a leaf. Kent Watsen: Right, not a singleton at least. You said a list, but a list can be more than two and we only need at most two. Wim Henderickx: For IPv6 it can be more than one by the way, because you typicall have a link-local address and then you have a global unique. I think it should be at least one for both, but it should be a list in general I think. Kent Watsen: Thank you for bringing that, I am not sure what that means for tcp-client-server. Wim Henderickx: It should be consistent, I agree with that. It is a bit late maybe. Mahesh Jethanandani: Consistency vs Correctness. With the udp-client-server I don't know if we can make that change? Alex Huang Feng: Sure, we are still on the draft status. But it would be nice with consistency with tcp-client-server. Rob Wilton: It should not be an issue. The AD at the time, which will not be me, will have to make a call weather if it will return as a one week LC review of that change in this WG is sufficient. If it needs to be fixed, let's fix it; we will have some discussion if it needs to be fixed or not. Kent Watsen: Let's take contact details and discuss it on the list. Alex Huang Feng: Request more feedback on the draft. Should we also remove the dependency on the udp-client-server draft, since it can be more specific ones for the udp-notif. Non-Chartered items: YANG model for NETCONF Event Notifications (10 min) https://datatracker.ietf.org/doc/html/draft-ahuang-netconf-notif-yang-04 Discussion Leader: Alex Huang Feng Ahmed Elhassany: First question: I have checked the code for libnetconf2 and they also redefine this XML Schema as YANG. Are you aware of this implementation? Alex Huang Feng: No. Ahmed Elhassany: They took a different approach, using a container instead of sx:structure. It would be interesting to see what the difference is there. Second question: A followup from the last IETF about validation. I have two concerns. In the example you show, you don't define any leaf except time but all content appear in the message. Maybe other people are more familiar with how sx:structure works, but I don't see the schema allowing for other values to be added, it just appears like that. Is that because sx:structure allows for YANG data by default or something else? Alex Huang Feng: The notifications were defined without this sx:structure. For example, RFC 7950 defines a notification with eventTime and then the content. The content of this notification is defined when you use the statement "notification". What I'm defining is the missing piece, the timestamp eventTime. I'm defining the type "notification" from YANG, I'm not defining a new container. Ahmed Elhassany: I see, but there is a container because it handles payload. It seems to be wrongly defined. YangKit has specific code for parsing this module. Is that required by all implementations or just this is how YangKit choose to implement. I'm unsure how pyang will use it. Alex Huang Feng: For YangKit we are just giving the YANG module as input to validate the message. Ahmed Elhassany: But there is specific code for parsing that. Alex Huang Feng: For notifications yes. Rob Wilton: Your comment about sx:structure is it the fact that it augments into that structure? If so the RFC that defines sx:structure, you can also augment use an "augment structure" from that RFC. For me it is really useful to define YANG definition for this message. We should just adopt it and progress it within the WG. Kent Watsen: We just finished the IPR poll two weeks ago, will kick off the adoption call maybe next week. (chat) Ahmed Elhassany: The alternative approach for encoding RFC5277 done by libnetconf2 using containers https://github.com/CESNET/libnetconf2/blob/master/tests/data/modules/notifications.yin (chat) Alex Huang Feng: I tried some time ago, defining the yang as a container, but since the content of the Notification is specified when you are defining the notification from the yang using the "notification" statement, this need to be as a structure because I am defining the "type" notification in YANG Kent Watsen: As a chair: This encoding question changes the scope from the adoption perspective, but it is still in the spirit of what is trying to be achieved and can be worked out as a WG document. Augmented-by Addition into the IETF-YANG-Library (10 min) https://datatracker.ietf.org/doc/html/draft-lincla-netconf-yang-library-augmentation-01 Discussion Leader: Zhuoyao Lin Kent Watsen: How long are we supposed to support legacy clients and servers that don't support NMDA? I.e. modules-state is for legacy compatibility. Both the keystore and trust-store drafts have the ability for built-in trust-anchors and built-in keys; basically "config true" nodes that are "config false" values, which would be reported in the 'operational' datastore. This means that, if you want to have built-in keys you are basically required to be an NMDA compatible server. Benoit Claise: Looking in the industry, it is mixed with NMDA support. We can do the right thing and say that you have to support NMDA if you want to use this, or we could say that we update the old yang-library but for how long. We could go either way in this draft. Kent Watsen: We have allowed for a transition peried for how many years? It is not short, it has been a while. Now is the time to get NMDA deployed. We should not allow non-NMDA servers to run forever now. Benoit Claise: There is two YANG models, technology specific (for which NMDA is default) or like this one where it is about discovery. I don't know, we could go either way. Rob Wilton: Pragmatic to include it since it is not expensive, why not do it? Perhaps this is not where we put a stake in the ground to stop the transition to NMDA. Rob Wilton: I'm concerned to get the augment out from other module sets, it might go past a boundary that is not a good idea to go past. So that needs consideration if that is a good idea or not. Another thought I've had is that another of the versioning drafts also augments into yang-library, the version string. I'm wondering if doing a bis of yang-library would be a cleaner way to get these two in, instead of augmenting them in. If we do progress with this work, we should consider that as an option. James Cumming: Agree we should continue to support modules-state. Should we start moving away from non-NMDA? This should be discussed in NETCONF-next, moving from a minor to a major version might be a good boundary to make this change. Maybe circular to augment in augmented-by into yang-library, better to update yang-library? Zhuoyao Lin: Yes we publish a module to augment it, not itself. James Cumming: My suggestion is that it might be better to publish an updated yang-library instead. Kent Watsen: That is a really interesting point. It would be circular I believe, the yang-library would augment itself. (chat) Mahesh Jethanandani: To the question of non-NMDA compliant, I would agree with Rob in that I do not know we want to be prescriptive about it. Isn't there a requirement to move the leaf from deprecated to obsolete before we say that module-state does not need to be implemented/supported? List Pagination Snapshots for YANG-driven Protocols (10 min) https://datatracker.ietf.org/doc/html/draft-awwhl-netconf-list-pagination-snapshot-00 Discussion Leader: Per Andersson Kent Watsen: I have a question to the WG. We separated from list-pagination because of complexity and unclear. Is there any support for this work? Joe Clarke: Is there any value added for operators? There might be more to this feature that add value for operators. Rob Wilton: My concern is what is the cost to implent this? There is not a single database representing the 'operational' datastore, seems complicated to take a snapshot of different sources. Cost of memory for large datasets. How to sync these things? It is the same when YANG-Push asks for initial-sync, how do you synchronize these things. Kent Watsen: Because it would be a separate draft, servers could choose to implement or not. Furthermore it could have features so servers could choose what to implement. Specific lists could support snapshots. You may have a federated database, some of your data could have native snapshot support but other might not. Servers could opt-in to support the parts they choose. Implementations would choose to do it only if the demand was there. Maybe Per can express how much complexity it is to publish this draft? Is it a very complex topic to get it published? Should we spend WG time on it? Per Andersson: To be totally honest, there is a reason it is put in a different draft. Quifang asked the last IETF and then all these questions presented came up. These questions are mostly not on server implementation, but how a client would handle it. So most of the server implementation problems, e.g. performance, size are glanced over really quick in a few bullet points. It mostly discusses how a client should handle the lifecycle of a snapshot. It is interesting of course, but as has been stated in the room it might not time for it now. Kent Watsen: It is tough because both Per and I are co-authors and co-chairs, so we might need to defer to the AD. Per Andersson: To conclude, this was raised from the WG to work on it but there has not been much interest to work on it. If there is interest, we'll bring it to the list and drum up interest on working on this there. Mahesh Jethanandani: It is a -00 draft so let it simmer. Per Andersson: We encourage participation in this work. Rob Wilton: Maybe freeze this draft and see how the list pagination work goes and then maybe bring it back and see if it is interesting then. NETCONF-next and RESTCONF-next (10 min) Discussion Leader: Per Andersson Mahesh Jethanandani: Reiterating Per's points, this is for the WG by the WG so participation must come from the WG to make progress. If there is a desire to even have NETCONF-next and RESTCONF-next. Per, in terms of the issues that we have are they labeled in the categories you listed? So people can select what they want to work on? Per Andersson: Not every issue is classified yet. That is also work that needs to be done by the design teams. Kent Watsen: You mentioned these three categories. The third category, requiring YANG-next. YANG-next will probably be mentioned in NETMOD WG, but everyone needs to be aware that this is a large effort. We can do the minor protocol upgrades in the meanwhile to resolve minor issues that can be solved in a backwards-compatible way; while waiting for the YANG-next work to become ready, and then we will move forward with major protocol updates for NETCONF and RESTCONF. Marc Blanchet: I'm not involved in NETCONF WG in general, but I'm involved in another project where we will need NETCONF over QUIC. Is there anything coming in the pipeline with that? Mahesh Jethanandani: There is a draft created in another WG, the authors were encouraged to bring it to the NETCONF WG but it never happened. If there is interest, someone need to pickup that draft and bring it to the NETCONF WG. Rob Wilton: Can you explain why you need it? What are the benefits that it offers? Marc Blanchet: We need it for IP in deep space, where you have delays like minutes or hours. Therefore QUIC with a few configure options, you could enable QUIC connections over long delays. Then we are looking at having the whole suite of solutions including Network Management. NETCONF over TCP won't work in anyway, TCP is out of the question in deep space. Validate Configured Subscription YANG-Push Publisher Implementations (5 min) Discussion Leader: Thomas Graf Kent Watsen: Concluding remark, since 2019 we have only published three documents. But there are maybe ten drafts that are up for publication soon. Welcome to your AD-ship, we hope to give you an entertaining first year! Mahesh Jethanandani: A lot of these drafts, as Tomas will tell you, fill holes that had to be filled to get YANG-Push to a workable solution. I'm happy that that work is going on and I'm happy to progress these drafts as soon as possible. Kent Watsen: Thank you everyone for attending, good meeting, and have a good rest of week! 5 Minutes Remaining