Minutes IETF117: netconf: Thu 16:30
minutes-117-netconf-202307271630-00

Agenda for the NETCONF 117 WG Session

https://datatracker.ietf.org/meeting/117/materials/agenda-117-netconf

Session:

THURSDAY, July 27, 2023
Morning Session I (09:30-11:30 PDT, 16:30-18:30 UTC)

WG Chairs:

Mahesh Jethanandani (mjethanandani at gmail dot com)
Kent Watsen (kent plus ietf at watsen dot net)

Secretary:
Per Anderson (perander at cisco dot com)

Available Now:
ICS: https://datatracker.ietf.org/meeting/117/sessions/netconf.ics

Available During Session: (pick one)

In-room Tool:
https://meetings.conf.meetecho.com/onsite117/?group=netconf
Remote Tool: https://meetings.conf.meetecho.com/ietf117/?group=netconf

Audio Only: https://mp3.conf.meetecho.com/ietf117/netconf/1.m3u
Chat Only: https://zulip.ietf.org/#narrow/stream/netconf

Available During and After Session:

Notes: https://notes.ietf.org/notes-ietf-117-netconf
Slides: https://datatracker.ietf.org/meeting/117/session/netconf
Drafts (PDF):
https://datatracker.ietf.org/meeting/117/agenda/netconf-drafts.pdf
Drafts (TGZ):
https://datatracker.ietf.org/meeting/117/agenda/netconf-drafts.tgz

Available After Session:

Recording: https://www.meetecho.com/ietf117/recordings#NETCONF

Introduction

Chairs (10 minutes)
Session Intro & WG Status

Kent Watsen: For the client-server suite of drafts we still have one
outstanding issue. There is no item on the agenda, would now be an
appropriate time to discuss it?

Rob Wilton: I'm still behind your latest comments. The two aspects we
have discussed are if you have a mandatory set of particular fields or
required true on leafrefs, then you either optimize for the solution for
the case where it is either set in the running datastore or you have a
system datastore. We have a system datastore draft in NETMOD, but we
don't know exactly where that will end up. I don't want to block these
drafts depending on the outcome of that solution, I want to get them
finished. The one question I had was that I agreed with you that keeping
the mandatory on nodes is the answer, and the requirance is exactly the
same question. This was what came up in other discussions.

Kent Watsen: system discussion: if running must be validatable.
Validating mandatory true, trying to validate document in isolation,
that will fail, but if you are merging with system where those leafs are
defined then intended would be valid from the perspective of those leafs
existing, and the mandatory would succeed.

Rob Wilton: No views in the room. I'll follow up on the list if there
are any comments, otherwise we will proceed.

Kent Watsen: Feedback to the room: I am still responding to Rob's AD
review.

Chartered items:

UDP-based Transport for Configured Subscriptions (10 min)
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-udp-notif-10
Discussion Leader: Alex Huang Feng

Kent Watsen: I echo what Mahesh replied on the mailing list. I think the
request is to create a stand-alone UDP client grouping.
Alex Huang Feng: There is a slide for that.

Alex Huang Feng: The authors don't think it makes sense to include the
udp client server grouping in this draft. Request more feedback how to
implement this.
Mahesh Jethanandani: yes good to have both client and server grouping.
Keeping in mind that we also have QUIC, something that is planned to be
used for NETCONF in the future. Same for the DTLS container, would be
helpful to keep separate from client server grouping.
Kent Watsen: UDP server is a good thing to have. This is how the
client-server set of drafts started, only needed NETCONF server but also
did client, then RESTCONF etc etc. It turned out well. UDP client server
document should be a separate document. I can join the effort to define
a udp-client/server grouping.

Rob Wilton: sounds like a good idea. Could reach out to the QUIC folks
as well, that we are doing this. Might slow us down though.
Alex Huang Feng: The only concern is to slow down the draft.
Rob Wilton: We can start of with something and then bis it.
Alex Huang Feng: Make sense.

Subscription to Distributed Notifications (10 min)
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-distributed-notif-07

Discussion Leader: Alex Huang Feng

No comments.

Support of Versioning in YANG Notifications Subscription (10 min)
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-yang-notifications-versioning-01

Presented by: Thomas Graf

Alex Huang Feng: we have mainly changed the way we specify the versions
addressing that 1 xpath could implement more than one module.
Kent Watsen: To what extent did you interact with the original authors
of YANG-Push?
Thomas Graf: During the adoption call we discussed on mailing list, and
at the last IETF we had some in room discussion.
Quifang Ma: What if the server return an error during the subscription?

Thomas Graf: Are you referring to the notification or subscription?
Quifang Ma: at subscription, client requests a module with a revision
that the server does not support.
Thomas Graf: We are supporting the current way to subscribe, this is
optional. You can subscribe either to a specific revision or to a
revision label, backwards compatible with a revision label.
Quifang Ma: What if the client specifies a revision that the server does
not support?
Thomas Graf: This is missing from the draft.
Mahesh Jethanandani: In general error handling is needed.
Alex Clemm: I'll engage with this on mailing list.
Rob Wilton: We have discussed YANG Packages as an alternative way to
define schema. What would the answer be for YANG Packages? Would that
just be extra augmented fields to give a YANG package, schema reference
instead of or in addition to this, or would it be wise to make this a
choice statement and to give a choice between what would be returned.
The clarity or some thought about if you are expected to return both the
module list and YANG package references so you can do one or the either?

Thomas Graf: Interesting question. Also interesting is if it should be
on the subscription itself or only on subscribe state change
notifications?
Rob Wilton: When you establish the subscription, would be useful to
subscribe on a package or set of packages. The aim of YANG Packages is
to give an alternative to YANG library, basically becoming the schema of
the device. If you want to lock your subscription down to what schema
the subscription is expecting, that would be a good reference to bind
it. If the subscription differs from this reference, it would fail.
Thomas Graf: In the subscripion, instead of selecting a rev or
rev-label, it would then be only a package?
Rob Wilton: Yes, the package or the package rev-label.
Benoît Claise: Rob Wilton, what is the action for this draft, how we
should augment in the future? Do we have to wait for YANG Packages?
Rob Wilton: Don't delay this draft due to YANG Packages. But have some
text on how it would fit.

Transaction ID and Tracing Mechanisms (15 min)
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-transaction-id-01

https://datatracker.ietf.org/doc/html/draft-rogaglia-netconf-trace-ctx-extension-03

https://datatracker.ietf.org/doc/html/draft-rogaglia-netconf-restconf-trace-ctx-headers-00

Discussion Leader: Jan Lindblad and Roque Gagliano

transaction-id:

Kent Watsen: Would the RESTCONF server be stateful with Etag+Seq,
keeping the list of transactions from a particular client?
Jan Lindblad: Not from a particular client, but it would need to
remember the history for all transactions for a bit. The more the
better, the more savings can be done. It would be enough to keep a list
of the last hundred transactions for most purposes, all clients would be
able to get the history of what has changed.
Kent Watsen: About RESTCONF being unable to mark nodes that are not the
top nodes. Is that a HTTP limitation.
Jan Lindblad: You would need to add text to RFC 8040 for this to work.
Do we want to stay true to RESTCONF as much as possible, or do we want
to enable making as much savings as possible.
Rob Wilton: Is Etag+Seq an optimization? If we store more transactions,
the larger savings, if we store less, we get less savings? Could Seq be
an optional thing (i.e. disable by setting a history size of 0)?
Jan Lindblad: Exactly like that.
Rob Wilton: Originally I thought this was adding too much complexity,
but since it is optional this sounds reasonable.
Jan Lindblad: Do we want things to behave similarly in NETCONF and
RESTCONF, or do we want to save where we can?
Reshad Rahman: In one slide it was mentioned to tag individual nodes
with an extension to show whether they are versioned, and that is part
of the optimization?
Jan Lindblad: This is an orthogonal question, it's just if you want to
mark in YANG which nodes in your implementation will have this or not.

POLL: Should Transaction ID draft stay true to RESTCONF (RFC 8040)? (Yes
= Stay True, No= Allow Variance) Majority for allowing variance.

Jan Lindblad: This indicates it is worthwhile to spend time on the
Etag+Seq optimization.
Jan Lindblad: Would be interesting to ask the room or the list about
adding a YANG extension to allow versioned nodes in YANG tree.
Rob Wilton: could add this to an existing module. yang annotate
extension to modify existing nodes needed perhaps.
Kent Watsen: This is the node-tags work in netmod.
Balázs Lengyel: Don't understand Rob's comment, you could do this via
deviation. This extension is important, we have unbalanced trees and it
is important to track them separately.
Kent Watsen: I would also like to offer support for the extension.
(ON CHAT) Robert Wilton
As a contributor: From a quick scan, I think that node tags is solving a
different problem to what I described at the mic, and deviation
statements are limited to deviating data nodes, where as I was proposing
the ability to annotate an existing YANG schema tree (e.g., a YANG
module with additional extension statements, i.e., equivalently to them
having being defined in the original YANG module). Annotations could be
added to a grouping or a typedef, or status or a type statement, etc.

trace-ctx & nc-rc-trace-ctx-headers:

POLL: Have you read either of the two trace ctx drafts? (Raise hand =
Read, Do not raise hand = Have not read either of the drafts) Majority
had not read either of the drafts. about 3/4 of the participants
answered the poll.

Rob Wilton: If anyone has read the drafts they would participate in the
poll, otherwise not.
Kent Watsen: Is it even reasonable to poll for adoption?
Mahesh Jethanandani: Give a little more time for people to read them and
wait with call for adoption.

Non-Chartered items:

External Transaction ID for Configuration Tracing (15 min)
https://datatracker.ietf.org/doc/html/draft-quilbeuf-opsawg-configuration-tracing-02

Discussion Leader: Jean Quilbeuf

POLL: HAVE YOU READ THE EXTERNAL TRANSACTION ID DRAFT (RAISE HAND = YES,
DO NOT RAISE HAND = HAVE NOT READ THE DRAFT)? Majority had not read
either of the drafts. about 3/4 of the participants answered the poll.

Kent Watsen: Same result as last poll. The working group has general
interest in tracing, but the poll results are not indicating that.
Mahesh Jethanandani: Perhaps more time is needed? That might result in
more comments on the draft.
Rob Wilton: Interesting draft, have not had time to read it. What is the
level of complexity? Is it worth the cost implementing this? Are there
alternatives?
Jean Quilbeuf: Basically the implementation Jan Lindblad and Roque
Gagliano are doing are similar, it would be the same complexity as that.
When your server receives these headers you need to populate the YANG
model based on these headers and whatever local system you use to track
your configuration changes, not a huge implementation effort on the
server side.
Benoît Claise: There are four different documents on tracing, at the
last IETF Jan Lindblad presented an overview of the four different
drafts and how they are complementary. Jean Quilbeuf now referenced
Roque Gagliano and Jan Lindblad in passing. Perhaps it is a good idea to
present such an overview again. On the adoption call it would not be
this small solution, but instead these together.
Kent Watsen, Rob Wilton: Agree
Jan Lindblad: I asked the chairs if such an overview was wanted without
response. Regarding implementation one important aspect is how much
reuse thire is in technology, W3C already have lists of implementations
and this is widely used. From that standpoint, this is an inexpensive
solution since it already uses a lot of available open source and
commercial tools.
Rob Wilton: Regarding implementation, not thinking about code and
libraries; but what information is stored, is it an extra table, how
much metadata is stored, can the metadata be shared efficiently or not?

Jan Lindblad: Compared to the rest of the configuration happening, this
metadata is very lightweight.

Kent Watsen: Benoît Claise had a suggestion for an overview presentation
and also requesting a joint adoption.
Mahesh Jethanandani: I agree, having that overview presented again at
the next IETF would help the adoption process.

Kent Watsen: Can we bring up the same overview again, now?
Jan Lindblad: Sure.

NETCONF Private Candidates (10 min)
https://datatracker.ietf.org/doc/html/draft-jgc-netconf-privcand-02
Discussion Leader: James Cumming

Kent Watsen: The reason we don't discuss multiple hello messages is
because we don't have support for it. There is only one in the
beginning.
Jamus Cumming: Absolutely, but none of the drafts specify that.
Kent Watsen: The intent is that there should be only one, and that it is
not stated is a problem. We have, as a working group, moved from hello
to yang-library.
James Cumming: If you start with capability base:1.0 and continue with
base:1.1, what do you do?
Balázs Lengyel: The protocol capabilities is not part of yang-library,
perhaps netconf-monitoring with notification could be done? But it is a
new problem.
James Cumming: Perhaps a separate problem altogether from privcand which
should be handled separately.
Quifang Ma: I notice privcand is destroyed on session close. Why not
when a commit is finished?
James Cumming: Because your session might still be open, and you might
want to do edits to it. You could destroy it and reopen it, but it is
more work. The update mechanism also has a default, so it follows the
resolution rules for the implementation. But you are right, an
alternative could be to destroy it and recreate it. This would be the
same behavior as closing your session and create a new session.
Quifang Ma: Will this carry extra complexity?
James Cumming: We have defined it for NMDA servers an non-NMDA servers.
With NMDA capable servers you don't need to do anything. With non-NMDA
capapble servers you need to send a capability to signal support.
Quifang Ma: Do you allow privcand to co-exist with the shared candidate?

James Cumming: Yes, we are not restricting that from happening; an
implementation could but the draft does not.
Quifang Ma: Is a shared candidate required?
James Cumming: shared candidate is not required. It is up to the client
to select if they want to work in a shared candidate or a private
candidate. Different clients could choose different techniques.
Quifang Ma: Is there any NBC for legacy clients?
James Cumming: No there should not be any NBC for legacy clients. For
NMDA capable clients you have support, for non NMDA capapble clients you
turn your session into a privcand session at the beginning of the
session and it stays that way. That is one of the reasons why the
support was there for 99% of the clients, in the non-NMDA way you target
candidate as you did before but it is the private candidate instead of
the shared candidate.

Rob Wilton: Minor comment on the hello handling. Decouple the hello
issue and raise it on the NETCONF issue tracker.
Kent Watsen: yang-library is not doing protocol capability exchange. But
RFC 8040 has it in state monitoring module.
James Cumming: It was relevant when we started working. You should be
able to send another capability.
Kent Watsen: As a response to Quifang Ma's question you said that it
should be possible for an implementation to disable the shared
candidate. I don't know how that can be done.
James Cumming: You should be able to use both shared and private
candidate, via locking for instance, but it is up to the implementation.

Kent Watsen: The shared candidate is enabled by default, implicitly.
There is no way to indicate that it is active, the presumption is that
it is always active.
James Cumming: An implementation could lock the shared candidate.
Rob Wilton: A capability could signal if a client can use both shared
and private candidates, or what level of support there is.
James Cumming: If the WG feels that this is a concern that we should
specify it. Our view was that we should leave it as it is today, and not
change how it works today. If a particular implementation wants to do
something that restricts the use of these approaches it is up to them,
instead of putting it in the draft.
Rob Wilton: Maybe you say to all candidates that you move forward with a
private candidate that is what everyone is going to get, and that is
actually the best behaviour anyway, so we don't support shared candidate
going forward. Is there a way to signal to the client that private
candidate is the one that will be used.
James Cumming: In a non-NMDA session with privcand, candidate means
private candidate. The client inits this with capability exchange at
setup.
Rob Wilton: Maybe have an error message that shared candidate is not
supported?
James Cumming: Is this draft the right place to add NETCONF support for
totally disabling shared candidate? What we have said is that you need
the shared candidate and the private candidate capabilities. Perhaps
this is a way to disable shared candidate entirely which we should talk
about.

Olga Havel: Did you encounter any scenarios or use cases where you
needed to keep the candidate between the sessions? If there is a problem
with the session and you need to reconnect?
James Cumming: For shared candidate this is done. For privcand the
candidate is destroyed between sessions. If the WG feels that this is
should be looked at we can do it, but the authors didn't think so.

POLL: Have you read (any version of) the Private Candidate Draft (Raise
Hand = Have Read, Do not Raise Hand = Have not read the draft)? Even
split of reading draft or not, but with low participation.

Kent Watsen: A bit concerned about the have-you-read-the-draft polls,
low participation and might be too few that have read the drafts to be
able to progress the drafts.

James Cumming: encourage wider WG participation on conflict resolution.

POLL: Does this version of the draft form a good basis for adoption
(Raise Hand = Yes, it does; Do not Raise Hand = No, it does not)?
Majority thinks it is a good basis for adoption.

Kent Watsen: The general interest of this work exists.
Rob Wilton: Two people have concerns. If you object to the adoption,
please bring your concern to the microphone or the mailing list.

Balazs Lengyel: The most difficult thing is how to merge or notify users
of private candidate about updates.
James Cumming: in auto mode conflict resolution absolutely, in manual
mode it should not be a problem.

Rob Wilton: Should we adopt this even with your concern?
Balazs Lengyel: I would like to see more work about how to merge and
rebase notification, before we adopt it. The problem is interesting but
there is a risk that we can't solve this properly.

Balázs Lengyel: If an operator knows one part of the big configuration,
will they be able to understand that someone else is working on another
part and that this part is distinct and pose no problem?

James Cumming: a conflict is where you are touching something that is
identical or referencing the same thing as someone else is editing. User
A is editing the user list and user B is editing bgp route policy, both
commit and they are not in conflict and the system would not raise a
conflict and say that you need to resolve this. However, if both edit
the same policy and try to commit it, the system would stop and say
there is collision and you need to update; the users have the update
resolution methods available the users choose to resolve the solution.

Balazs Lengyel: If you edit the same data nodes, this can be complicated
and clear. But if you have references e.g. in a must statement, maybe a
two step reference to something common, it could be tricky.

POLL: Do you agree with the Conflict detection and resolution proposed
in the draft (Raise Hand = Yes, agree; Do not Raise Hand = Do not
agree)? 7/2

Mahesh Jethanandani: The poll indicates lack of understanding or what
the conflict resolution should be like and might need more discussion on
list.

James Cumming: Some work to be done on the notification feedback, but
don't know about conflict resolution.

(ON CHAT) Joe Clarke
My mic isn't working, but I feel this has a lot of value, especially
with other work like tracing and txid whereby we can have more meta-doc
on why a config change was made. This pushes some of the git semantics
to the server, which I like. I agree with Balazs that conflict
resolution is critical, and I'd like to see an ability to squash the
private on commit (or maybe you could use delete-config for that).
I'll tske these to the list.

Severin Dellsperger: I question these polls, how many have read these
drafts with about 10 participants? Then do you agree or not, with 20
participants. How can you agree if you have not read it? Is it better to
take it on the mailing list?

Kent Watsen: Everything is revalidated on the mailing list anyway. Those
who have agreed, know the sentiment and have seen presentations but
perhaps didn't read this draft revision.

Kent Watsen: You had a few specific comments. Update the draft first and
then we can ask for adoption on the list.

James Cumming: The privcand formed part of the tracing mechanisms
originally. When adopting them all together, maybe privcand isn't part
of that.

Kent Watsen: Good point, I thought so as well. However, transaction-id
is the way to detect a conflict or could be.

James Cumming: It is not apparently, but that would require changes to
both client and servers to support it; which today would just work.

Overview of tracing mechanisms
Discussion Leader: Jan Lindblad

Kent Watsen: Just to clarify, the trace-ctx and config-trace should be
worked on together?
Jan Lindblad: yes. trace-ctx is now two different drafts. transaction-id
is already adopted.
Kent Watsen: Strong connections, mostly complimentary. All these would
be optional to implement?
Jan Lindblad: Yes, they would be. But they form a whole and terminology
and behavior should be aligned.
Kent Watsen: Before we asked if WG members had read the drafts, with
tepid results. Then asked if privcand was a good base for adoption,
rough to do because how can you support it if you have not read it. It
can be difficult to progress the work. We should poll for adoption.
Mahesh Jethanandani: The four drafts could be combined together in a
design team.
Jan Lindblad: More or less we are doing that already.
Rob Wilton: Sounds like some of these drafts are tangentilly related,
like privcand.
Jan Lindblad: Yes true for privcand
Rob Wilton: Are we trying to adopt the five drafts together or a subset
of these drafts?
Jan Lindblad: It makes sense to adopt them together. But if it slows
things down, we can do it individually.
Rob Wilton: Is YANG txid mapping and M.E.L.T. process complementary or
is it two different solutions to the same problem?
Jan Lindblad: [The drafts referenced] One is NETCONF the other
RESTCONF.

Mahesh Jethanandani: One of them is in OPSAWG. Should it be moved here?

Rob Wilton: All of this work should be done here.
Mahesh Jethanandani: A note to the author then.

POLL: Do you believe the suite of drafts should be used as a basis for
WG adoption? (Raise=Yes, Not Raise=No) Unanimous support to use as a
basis for adoption

Kent Watsen: We will repeat the adoption poll on the list. Thanks Jan
for presenting the overview again.

NETCONF WG Open Mic:

Alex Huang Feng: I just published a draft for NETCONF notificiations to
use JSON and CBOR encodings. Also asked if requesting CBOR SID range
should be managed by this WG or by CoRE WG?
Rob Wilton: Regarding SID range, IANA was going to allocate a mega block
for IETF. And any WG that publishes YANG models would get a subset of
that block.
Alex Huang Feng: That also means that we should ask for these via drafts
or ask IANA?
Rob Wilton: I need to reread the SID draft. Can you look at the SID
draft and ask on the CoRE list how the SIDs get assigned? During
development you could redo the ranges, but when it gets standardized
SIDs are allocated but I don't know if it specifies that and puts the
burden on the authors to do that or if there is some process in the IANA
machinery. But there is tooling in the YANG catalog to allocate these.
Alex Huang Feng: I'll send a mail to CoRE.
Kent Watsen: Any question about SIDs should go to the CoRE WG, not to
NETCONF WG.