Skip to main content

Minutes IETF119: netconf

Meeting Minutes Network Configuration (netconf) WG
Date and time 2024-03-19 03:00
Title Minutes IETF119: netconf
State Active
Other versions plain text
Last updated 2024-05-02

Agenda for the NETCONF 119 WG 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:

Available During Session: (pick one)

   In-room Tool:
   Remote Tool:
   Audio Only:
   Chat Only:

Available During and After Session:

   Drafts (PDF):
   Drafts (TGZ):

Available After Session:



   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)
   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

Per Anderson: I can clarify.  That is exactly correct, Robert, it changes

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)
   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

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)
   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

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

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

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

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
   Discussion Leader: Jan Lindblad

Kent Watsen: asked Jan to present because it is important for WG documents to

   External Trace ID for Configuration Tracing (5 min)
   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)
   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

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)
   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

Wim Henderickx: It should be consistent, I agree with that. It is a bit late

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)
   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

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

(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

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)
   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)
   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

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

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

Kent Watsen: Thank you everyone for attending, good meeting, and have a good
rest of week!

5 Minutes Remaining