Minutes IETF119: netconf
minutes-119-netconf-00

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: Thanks Rob for your service as an AD, a true service for the community!

Mahesh: 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 ?garbled last word? 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 failry
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 somwthing 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: 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: 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. Mahesh(from chat): 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