Agenda for the NETCONF 123 WG Session ------------------------------------- https://datatracker.ietf.org/meeting/123/materials/agenda-123-netconf Session: Thursday, July 24, 2025 Thursday Session 1 Room Name: Tapices WG Chairs: Kent Watsen (kent plus ietf at watsen dot net) Per Andersson (per dot ietf at ionio dot se) WG Secretary: Mithun Thai Valaphil (mithun dot ietf at gmail dot com) Available Now: ICS: https://datatracker.ietf.org/meeting/123/sessions/netconf.ics Available During Session: (pick one) Onsite Tool: https://meetings.conf.meetecho.com/onsite123/?group=netconf Remote Tool: https://meetings.conf.meetecho.com/ietf123/?group=netconf Audio Only: https://mp3.conf.meetecho.com/ietf123/netconf/1.m3u Chat Only: https://zulip.ietf.org/#narrow/stream/netconf Available During and After Session: Notes: https://notes.ietf.org/notes-ietf-123-netconf Slides: https://datatracker.ietf.org/meeting/123/session/netconf Drafts (PDF): https://datatracker.ietf.org/meeting/123/agenda/netconf-drafts.pdf Drafts (TGZ): https://datatracker.ietf.org/meeting/123/agenda/netconf-drafts.tgz Available After Session: Recording: https://www.meetecho.com/ietf123/recordings#NETCONF Introduction Chairs (10 minutes) Session Intro & WG Status Mahesh Jethanandani: Some update on http-client-server doc. Mike Bishop has provided his comments on the three DISCUSS on the document. Please evaluate so we can close on the draft. Kent Watsen: Yes, I saw it and am still processing it. I will reply shortly. Thomas Graf: I have a comment on YANG library augmented-by. I've done a shepherd review, but not sure if the last call was concluded. Per Andersson: WG Last Call was not concluded, but there were various outstanding issues and there have been doc updates. But it should be concluded and those are on the to do list. Chartered items: NETCONF over QUIC (10 min) https://datatracker.ietf.org/doc/html/draft-ietf-netconf-over-quic-04 Discussion Leader: Weiqiang Cheng/Jinyou Dai/Per Andersson Mahesh Jethanandani: Not related directly to this draft, other than port allocation, but there are three issues that came up after the review of the port number draft (not this draft). TSV, Port expert review by Joe Touch, and Michael who provided TSVART review. I tried to reach out to Med to see if there is an update. He told me over Slack that we have resolved the port expert review and he has updated the draft to address Michael's comment. Per Andersson: I put it in the end if you want to discuss it more. Marc Blanchet: You're referring to Joe's review on the port number and not this one? Mahesh Jethanandani: Not this one. Per Andersson: One question Mahesh, we request a port which likely leans on the port number draft that will release that port.Has that been discussed? Mahesh Jethanandani: I believe that request was for port number 830? Per Andersson: It's 831 if I recall correctly in this draft and that is released. Mahesh Hethanandani: I didn't see anything IANA had any issue with respect port number request if that what you're referring to. No it hasn't come up yet. Is this an early allocation request that's there in the draft? Per Andersson: Yes. Marc Blanchet: One slight comment, we are running over QUIC so we only need a UDP port number. Mahesh Jethanandani: That's true. You shouldn't probably don't need TCP port number. Per Andersson: I tried reading up on this. You can run SSHv3 that runs over QUIC, so I would assume if you run Netconf over SSHv3 that would be on port 830 which is UDP. Not sure that Netconf over QUIC would make sense to run over the same port. Mahesh Jethanandani: Thank you for providing the context. You're saying Netconf over QUIC itself doesn't need a port number but if we choose to run Netconf over SSH3 we might make use of 830/UDP which is not in the scope of this draft. Per Andersson: I think that when running over QUIC, I think that you would want a port assigned. Mahesh Jethanandani: Is that early port allocation in the draft? Per Andersson: Yes. Mahesh Jethanandani: I don't see any issues with IANA, but I'm happy to go back and review. CHAIR ACTION: None YANG Groupings for QUIC clients and QUIC servers (10 min) https://datatracker.ietf.org/doc/html/draft-ietf-netconf-quic-client-server-02 Discussion Leader: Per Andersson Kent Watsen: I don't suggest using identities unless we expect to use inheritence property. Otherwise enums work well. That was point of contention while doing the suite of HTTP client-server drafts. Originally they were identities and later became enumerations. Kent Watsen: I like the idea of the underlying value to be in description statement instead of value statement. YANG data model is meant to be more human facing. Humans don't need to know what the underlying bit value is. Having it so prominantly put in value statement may not be necessary. Marc Blanchet: To your last point, we need to use a non-typical transport, so it doesn't make sense to have those in a standard one. So, yes for a union. Kent Watsen: The idea of a non-standard values being supported came up in the HTTP client-server draft where they were thinking non-standard version of http could be tested. I think that this is an open question as to what extent the standard module should support non standard values. Otherwise, pretty much everywhere we create an IANA registry we would always want a union to allow non-standard values to be represented. Per Andersson (as an author): I have to decide on how to go ahead. Thanks for the comments. CHAIR ACTION: None Extensible YANG model for YANG-Push Notifications (10 min) https://datatracker.ietf.org/doc/html/draft-ietf-netconf-notif-envelope-02 Discussion Leader: Alex Huang Feng (in-person) Ahmed Elhassany: Better to have one knob than many as it's easier to explain to someone who doesn't know yang-push. For the team who's actually doing the collection, having two types of messages arriving on the same channel is not a big of a problem because we cannot update our collector to handle this, we need 1 or 2 software engineers to do it and then it's easier for the tens of network engineers that have to deploy this. For a legacy collector, it could just drop the message with the new unknown header. Better to have a single knob. Makes it more deployable and understandable for the teams managing the YANG-Push subscriptions. Per Andersson: We might want to poll on this? Reshad Rahman: Alex and I chatted about this. At the interim, I did vote for the global switch, but when Andy sent his email, I had sympathy. Cannot assume that there is only one set of collectors. Changing from one to other this is disruptive. In this particular case, Thomas made a point that this is not really used and less of a problem. If the WG decides that because of that, a global switch makes sense I'm good with that with this specific case. But for other case where there would be wider deployments, it would be problematic. Alex Huang Feng: I myself don't have a preference. Open to the group to decide. Rob Wilton: We will only implement a global setting regardless of what is chosen. Have sympathy to the backwards compatibility issue raised by Reshad. Not sure how much deployment of Yang Push there is - I'm sure that Andy has customers, but they could augment a per-subscription option into the model. Network devices have too many knobs and options, we should try and simplify. Alex Huang Feng: Yes, I agree. Thomas Graf: We have implementations, Rob's implementation has a deviation so you cannot even turn it on. Other implementations only allow to have it turned on and you cannot not disable it. Holger Keller: We are trying to simplify things. Reshad is saying that there are many collection going on, and this is true in the SNMP world. We are moving to single collector. Kent Watsen: There may be a usecase 1.5, which would be to do it per-collector. In HTTP client-server draft there's a module that does mapping between subscription notification yang module to subscriptions and it's per collector. Diagram is correct it, makes sense from collector basis it would only receives one. I don't think that the configuration for that would be per subscription, it would be per collector. Alex Huang Feng: That setting is even lower than the per subscription. Kent Watsen: That's why I said it's usecase 1.5. Mahesh Jethanandani: Interesting in 1.5 option, I thought that we were just choosing between two. Are we now trying to decide between 3 options? Alex Huang Feng: I see that per subscription is already low enough. I don't want to go in to the per collector. I don't see that use case necessary. I would just implement, from operator perspective, one subsctiption per collector. Thomas Graf: The reason why we don't have the option 1.5, is because the encoding is being configured and defined on subscription level. Since you're changing on the structure of the header, it wouldn't work on the receiver level. Holger Keller: We also have to consider dynamic subscriptions, so the device doesn't know, so there is no collector on where you can put a knob. Per Andersson: Let's start a poll. Poll "Should we use a global switch for envelop use?" Results: 12 for, 1 against, 12 no-opinion. Mahesh Jethanandani: For those who voted no-opinion, is the opinion that they have no objection to the global option. Kent Watsen: I was a no-vote, because I agree with Andy that changing this would be too disruptive. And I'm thinking mostly about configured subscription and not dynamic subscription. Per Andersson: Thank you. Terminating the poll. Results are mostly in favor of global switch. Mahesh Jethanandani: Wanted to check that those saying no-opinion don't have an objection. Per Andersson: People who voted no, is that you don't know about problem? Or are you against using it or something else? Reshad Rahman: I voted no-opinion, meaning I don't mind, i.e., I don't object. Kent Watsen: We could do another poll - the object being the global switch? Per Andersson: Yes, we could. Second poll: "Do you object to using a global switch?", Yes: 0, No: 24, No opinion: 4. Per Andersson: No objections found. Alex Huang Feng: This was the latest issue that needed discussions. All points are addressed. There no open items and we request working group last call and go to next stages. There is a side meeting on Friday where implementations are being demoed. Per Andersson: The chairs have noted the request for the WG LC and will take it to the list after session. CHAIR ACTION: WGLC NETCONF and RESTCONF Private Candidate Datastores (10 min) https://datatracker.ietf.org/doc/html/draft-ietf-netconf-privcand-07 Discussion Leader: Robert Wills Kent Watsen: Wondering if implicit deletion is really needed. First off, it might be surprising to the client of the second datastore. If the node gets deleted because of a 'when' expression then in the other private candidate it still tries to configure the node that's presumably deleted. But that should be okay that it could go ahead and save the value but would still be deleted because the when expression would remove it. But whatever condition the when expression where to allow the node to become visible again then it might be desirable for the value that the other private candidate trying to provide to come through. Robert Wills: It is important that the private candidate is consistent with the schema. When you do the update in step 3, you are bringing in the changes that causes the 'when' to fail. So you're only choices are to remove the changes that the client made to X so that it doesn't conflict with 'when' condition or to flag that to client that X is in conflict. Kent Watsen: That makes sense. Rob Wilton: Does this implicit deletion straightaway? I think it happens at the end of the edit config sequence I suspect? Timing of this, we need to think carefuly as to when it's done but I don't think you can necessary know. Robert Wills: Do you mean it happens when edit-config request is in process or do you mean it could happen at the time of commit? Rob Wilton: I don't know. Robert Wills: We weren't certain either. To us it makes sense that by the time the edit request is being processed that the datastore is in consistent state. That makes more sense compared to being made consistent at commit time but invite feedback from WG on that. Rob Wilton: It's probably right that it happens during edit time. But I think we need to check carefully otherwise if you go different directions here to what servers are doing then it will cause pain. James Cumming: We think that it is edit time rather than commit time. Rob Wilton: I think you're probably right. Kent Watsen: Some systems allow the private candidate datastore to become inconsistent but it provides warning it's inconsistent. At the time of commit it enforces so you can't commit until private candidate datastore is completely consistent. Robert Wills: Does it include case about implicit deletion? Kent Watsen: No it's a general statement about the consistency of datastore in private candidates. Robert Wills: Thanks, that's a useful context. Wim: I haven't looked at the details, but what you are trying to do is a three way merge similar to GIT. If you have changes in running compared in your private candidate then this is a conflict and user has to be provided warnings. I agree that you should see this as a conflict. Robert Wills: Yes. One of the key underpinning of this question was knowing whether this deletion should happen straight away. Because if it should then yes it's a 3 way merge. Robert Wills: End of the questions. It's my first internet draft, grateful to the WG. Thanks for everyone's input. Per Andersson: Thank you. Happy to hear. Enjoy your work. CHAIR ACTION: None Augmented-by Addition to the YANG Library (10 min) https://datatracker.ietf.org/doc/html/draft-ietf-netconf-yang-library-augmentedby-08 Discussion Leader: Zhuoyau Lin Rob Wilton: Not sure if you are quite close to last WG call just yet. The reason is with the augmented-by we are restricting it such that it is only listing modules within the same module set. That's a significant restriction on how it's used by having that limitation. I have had discussions with Thomas, Per and Jan over the hackathon weekend and it ultimately comes down to 2 observations. One, it was pointed that the deviations already have this limitations in terms of any deviated model modules have to be listed in the same module set. Second one is how are people using modules sets today. If you have a single module set per schema then there's no issues - each module sets at the top level. You can just limit the augmented-by modules in each module set to those. You have different classes of augmented-by statements for the same module if it's in different module sets. That's okay. I think we're probably be okay using the same restrictions. This draft needs to be really clear on this point. May be in the introduction that this is a limitation to using to using this draft and make sure that everyone is aware of this limitation and can accept if it's being used. Zhuoyau Lin: Need support of implementers to tell us what are the possible restrictions. Thanks for the feedback and we will consider. Rob Wilton: Question to the chairs. Is it worth a poll? I don't know if the people know the issue well enough. Per Andersson: We're discussing it. Benoit Claise: We already address that in the operational consideration in the latest draft which says the restriction since it was already mentioned by Andy. We have that limitation already for deviation, so Rob what do you expect from this document. Rob Wilton: If the people here are willing to accept the limitations then I would say operational consideration is good. Introduction should also pull this out so it's clear to someone who's reading this document knows that the limitation is there. Per Andersson: Clarifying question, do you want to poll to ask if the WG wants to add this limitation to introduction or do you want to leave that to the authors? Rob Wilton: Question to the WG - Are we okay with the limitations that effectively means you're restricted to using single module set rather than a union when using augmented-by. Per Andersson: Like Benoit said this limitation already exists for deviations. Rob Wilton: The difference with deviations is it's easier to mitigate that so I think deviations don't have the same problem as this. The fact that the augmented-by can differ based on how you put the module sets together makes it a different class of problem. Benoit Claise: If you poll for that then we have to poll are we happy with limitations in deviations then we have a bigger problem. Rob Wilton: The limitations in deviations is already there in the RFC that's already published and it's easy to live with compared to augmented-by. Thomas: Will share a slide in the chat that shows node-sets and datastore schema's are currently being used in industry. [Slide 9 in https://datatracker.ietf.org/meeting/123/materials/slides-123-nmop-2-validate-configured-subscription-yang-push-publisher-implementations-00 shows how node-sets and datastore schema's are currently being used in 4 sample implementations.] Alex Huang Feng: May be put it in the core of the draft rather than in the operation consideration might ease this issue. I agree with Rob that just putting on the operational consideration poeple might miss this bit. Kent Watsen: To Rob, does this have any impact to yang packages from NETMOD? Rob Wilton: On yang packages we have taken out deviations. I would try hard not to introduce augmented-by because it puts dependency in the reverse direction. With packages where they're being built up and the same with same module sets where they're being built up and in yang where you can augment into other module's dependencies pointing from the module that's doing the augmenting into the augmented module by listing these in the reverse direction, that's where the problem comes out. Another suggestion is that you could list this at the schema level and not at the module set level and the problem would go away but that's a much bigger change to this draft and probably not necessary. So for packages I would try hard to not have similar extension. Ahmed Elhassany: Couple of points. The reverse dependency is strength and hardship in YANG. We would need to be able to know all the dependency - either direct or reverse to be able to validate the message. This is very important for us and I'm sad that yang package will not be able account for it. So for someone to be able to validate it, the yang library is the only way to have an understanding on what's coming from the router so we can validate it on the collection side. Yes augmented-by adds additional restriction but it's already being done with the deviations and it's already well described in the yang module itself. This is yang rule and its not inventing anything new. In the draft we're not adding anything new other than saying this is how we specify it. Lets not make exception for something that's already there. Rob Wilton: In terms of what this extension is doing, it's not giving you information. YANG library output already has all the information that you need both in terms of deviations and in terms of augments because you get the list of modules, you compile the schema and as you compile the schema you have all this information because the yang modules themselves say that they deviate another module or augment another module. So all this is doing is optimization to say you don't have to receive all the modules and compile the complete schema - it's giving a path to compile a subset of that schema and that's what causing the issue here. In terms of yang packages I hope you can do it quickly enough that it takes a second or two to take all of the schema and give you the same information without having to export it. Ahmed Elhassany: In a production scale with 1000s of routers, having to parse 5 yang modules to validate subscription rather than 1 big library is going to make huge difference on the collection side. Rob Wilton: But you can also hash the results so you don't have to do it. And yang packages is designed so you don't have to fetch the yang modules at all. You already know what the schema is going to be. James Cumming: Echo what Robert said that adding this information that is kind of reversing the nice benefit that augmentations have where you can augment into module without knowing anything about it. And that having to rework that and provide that information in the reverse direction is complex and not needed. Per Andersson: Lets run a poll. Poll: Does the WG accept the limitation that augmented-by only works per module-set? Yes - 14, No - 0, No opinion - 6 Rob Wilton: I voted no opinion because I don't know for certain that it's not an issue. I think it's okay for us, we're still checking that. I just want to get a read for everyone else to see if anyone else this an issue or not. Thomas Graf: We have reached out to all the implementers to get the same feedback. And if there would be something, we can still discuss. Per Andersson: Closing the poll. No one doesn't accept it in the polling. Thank you. Benoit Claise: What are the next steps for the draft? Per Andersson: There have been two suggestions in the room. Put more in the core or in the introduction, move it outside of the operational considerations. Benoit Claise: We have the limitation described in the YANG module and the Operational Considerations section. But you want this earlier in the document? Per Andersson: I think so, yeah. CHAIR ACTION: None Non-Chartered items: YANG Push Lite (20 min) https://datatracker.ietf.org/doc/html/draft-wilton-netconf-yang-push-lite-00 Discussion Leader: Rob Wilton Kent Watsen: You mentioned 2 timestamps. So the second timestamp is time when committed or when it's applied? Rob Wilton: Observation time is as close as possible to when the counters are read from the hardware when you fetch it from the components. While the first timestamp is when you gathered events across of all those subscriptions. Kent Watsen: Makes sense. Reshad Rahman: My preference is until we have a way to push our model outside of the RFCs, I personally prefer to have the model with the document. It's easier to review. Rob Wilton: The last point, it's solvable through build process and things like that. There is extra overhead in keeping them in sync and consistent. Thomas Graf: +1 on putting yang model outside of the yang document and the build process is great. The reason for yang-push lite was actually we want one document where everything was coming together but now I feel we're circling back again when you start separating the two. Rob Wilton: May be. But it's a long document and may be it's longer than it needs to be but there aren't many example yet so it's going to be quite weighty too. It's not same as today with lots of different thing. It's probably one document that describes the protocol and one document that defines the data model. The implementer would have to implement both. Alex Huang Feng: I have preference putting everything on single draft. Some protocols in other WG are putting differently, they are trying to sync up and sometimes they don't match. When you are reading and implementing, I struggle go back and forth between different documents. The configuration side is the last step of the implementation so anyway if someone don't want to implement it the protocol is there on the same document. Rob Wilton: The last point it's to do with the process between vendors and operators in terms of supporting the RFCs whether do you support this RFC. It's easier to say yes or no rather than yes with capabilities and caveats. So if the data model stays in the document I think it's likely we'd have some text to say this is optional to implement the config data model and probably dynamic subscriptions as well so it ends up muddying the waters little bit. Per Andersson: Have a clarifying question. You're talking about configuration model but also encoding YAML or this is for the configuration of subscriptions? Rob Wilton: I don't know. Definitely there'a desire to take the config data model out but it might be also some dynamic RPCs out possibly for configuring dynamic subcriptions and terminating them. I don't know whether it would also mean that the message format the yang-push would also be in a separate document. It's an issue that came up this week in terms of discussion. The config was the main driver. Mahesh Jethanandani: Doing presentation on how to move models outside outside of document. Looking for volunteers. Rob, are you signing up for the experiment? Rob Wilton: Thank you. But be aware that this document is sort of different from most of the IETF document where you have separate protocol and then you got a separate data model for setting up. Here the data model and the protocol are somewhat intertwined. Nils Warnke: I also find it easier to read and follow if it's a comprehensive document and also +1 for having that in a single document. Ahmed Elhassany: I hear two different reasons for either splitting or keeping the document in one document. One is consitency to develop it so it's easier to be more consistent when you have 1 document and end of the day it adaptation. For the vendors it's easier for them to say I support this and I don't support that. Isn't it too early to ask this question now and this is now and this work is still not yet adopted as a WG. Personal preference is to continue as one document and come back and ask again when it's closer to last call where the implementation from vendor is more major concern than now. Rob Wilton: Yes that's fair yes it's early time to ask the WG. I'm not sure if I wanted to do it close to the last call because I think it will change the structure of the document quite significantly in terms of how you write and how you reference which is why I'm asking for guidance now so we don't spend lot of work going in one direction and have to change it later down the line. Bharadwaja Meherrushi: It'll be easier if it was one document. Don't mind if there were cross references against documents if it explained clearly beforehand the order. I feel like the issue with yang push right now is the order is unclear. It would be easier from implementation perspective. Per Andersson: Lets do poll. Poll: Should the YANG module be in the same document? Yes - 22, No - 6, No opinion - 5 Balasz Lengyel: I think taking out the yang module is a good idea but just the yang module so no descriptions are around the yang module. We don't want two RFCs just take the yang model separately to make it more easy to develop. Rob Wilton: Are you saying 1 RFC but model in the github? Balasz Lengyel: Yes. Rob Wilton: Okay. Thank you. Mahesh Jethanandani: May be I'm giving you a bit too much because I would rather have this conversation in the ops area WG when we do this presentation. But what Balasz said is kind of the idea that it's a single draft with a reference to the model to some sort of control mechanism. James Cumming: Want to comment on the poll that may be some people are unclear about which yang model we're taking about specifically here. Because we've been talking about message formatting, configuration model dynamic configuration? Rob Wilton: We'll carry on with single yang model in the document. This is left as an open thing to consider down the line and particulary the one that happens in ops area in terms of taking yang models out of drafts altogether. Kent Watsen: If we were to take it out later, we would publish two RFCs simultaneously. Reshad Rahman: Do you have plans once you start implementing, have a hackathon? Ppl would love open source on the client side. Rob Wilton: It could be significant changes, will take up once things become firm. CHAIR ACTION: None CBOR Encoding for HTTPS-based Transport for YANG Notifications (10 min) https://datatracker.ietf.org/doc/html/draft-chittapragada-netconf-https-notif-cbor-02 Discussion Leaders: Bharadwaja Meherrushi C, Vartika T Rao, Siddharth Bhat, Hayyan Arshad (remote) Mahesh Jethanandani: Thanks for bringing this up along with implementation. One comment - can demo for this included along with yang push? In terms of preference for encoding, you'd have support for all 3 but preference is CBOR, JSON and XML. How does receiever indicated preference? Bharadwaja Meherrushi: Currently in our implementation it's user configurable. It's ideal to use CBOR for BW constrained networks. But it's based on the reference of the operator. Any encoding can be used. Alex Huang Feng: Second your comment on the missing IETF notification yang model. We did not fix that gap immediately. Just want to comment on that. Rob Wilton: Wasn't clear how client can choose whether it gets CBOR with named identifiers or CBOR with SID identifiers. It looked to me at the moment you just asked CBOR and it's left to server to decide what it sends. I think because processing those is quite different you may need negotiation stage way ahead whether it's CBOR with SIDs or CBOR with named identifiers. Bharadwaja Meherrushi: That's something we should consider about the negotiation part. For now we assume that there's a set of publishers sending CBOR named identifiers and set of publishers sending CBOR with SIDs and different ways to handle it. Haven't thought how to configure it yet. Per Andersson: Running out of time. Would like to have a quick poll to see if WG is intereted in working in this document. Poll - Does the WG have interest in working on this document? Yes - 22, No - 1 , No opinion - 0 Kent Watsen: Currently document status is standard. Is this better to be an informational document? Bharadwaja Meherrushi: Not sure, but likely at same level as https-notif since it extends the model. CHAIR ACTION: None