Minutes IETF116: netconf: Mon 04:00
minutes-116-netconf-202303270400-00

Agenda for the NETCONF 116 WG Session

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

Session:

Monday, March 27, 2023
Monday Session II (13:00-15:00 JST)

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/116/sessions/netconf.ics

Available During Session: (pick one)

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

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

Available During and After Session:

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

Available After Session:

Recording: https://www.meetecho.com/ietf116/recordings#NETCONF
Jabber Logs: https://www.ietf.org/jabber/logs/netconf

Introduction

Chairs (10 minutes)
Session Intro & WG Status

Quifang: Is there interest in the WG for working on
netconf/restconf-next?
Kent: For this work to start it would probably be initiated by yang-next
in netmod, this would then trickle down to NETCONF WG. Doesn't make
sense to publish anything until then.
Mahesh: What are some of the areas of interest?
Quifang: We already have some work, like list-pagination and
transaction-id and issues like binary encoding and binary notif and some
issues might need a netconf-bis.
Kent: This is a good suggestion long overdue, but I want to remind the
WG that this is a volunteer effort and if someone is looking for an
interesting draft to work on there are issues on the netconf-next and
restconf-next issue trackers.
Mahesh: Some of the work can be brought forth without netconf-next.

Chartered items:

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

Alex: Have received some feedback about observation-domain-id and
message-id. Source IP should be used to ensure uniqueness. message-id is
per observation-domain-id and not per subscription. o-d-id was decided
to not change, but remove all IPFIX references and define o-d-id in
distributed-notif, so in scope of yang-push.
Rob: What are the actual definitions in the draft, how do they look like
compared to IPFIX. Is it going to confuse the readers using the same
names? Are they semantically equivalent?
Alex: The definitions are similar. From your feedback we want to
separate the concepts for IPFIX and yang-push.
Rob: The definitions were different, that's why the concern were raised.

Mahesh: Noticed a grouping called udp-transport-params but looking at
the tcp-client-server drafts, would it make sense to have a similar
grouping for in e.g. udp-client-server?
Alex: Let's look into that.
Benoit: In IPFIX, we have the notion of observation-domain-id, typically
this is line card in which you have cache and exporting. Is this a high
level goal for yang-push to use the same value here and in IPFIX for
observation-domain-id?
Alex: The observation-domain-id is the exporter process but not expected
to be the same as the IPFIX one.

Alex: No feedback on the issues from the list. Let's review the
udp-client-server grouping. Can we have a WGLC at some point?
Mahesh: One more revision before WGLC.
Kent: Definitely one more revision if we should incorporate
udp-client-server.

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

Discussion Leader: Alex Huang Feng

Alex: observation-domain-id is actually an integer, was defined as a
string. It is bound to udp-notif, ask for WGLC at the same time.

List Pagination (10 min)
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-list-pagination-01

https://datatracker.ietf.org/doc/html/draft-ietf-netconf-list-pagination-nc-01

https://datatracker.ietf.org/doc/html/draft-ietf-netconf-list-pagination-rc-01

Discussion Leader: Per Andersson

Poll Question: SHOULD SNAPSHOT BE FURTHER BE DOCUMENTED IN
LIST-PAGINATION?
Poll Results: Few participants, no clear conclusion

Kent: low participation. Possibly because not enough people understand
the solution.
Per: No real solution. We could show through an attribute perhaps if the
underlying result set is a snapshot or not.
Mahesh: Would definitely suggest you take it to the list.

Kent: could you give an concrete example?
Per: One could supply sort-by-locale together with sort-by for instance,
and also report what locale was used when sorting together with the
result set.
Balazs (from chat): Ö might be after O in some locales but might be
after Z in others

Poll Question: SHOULD LOCALE BASED SORTING BE FURTHER DOCUMENTED IN
LIST-PAGINATION?
Poll Results: Working group is not interested

Rob: I'm struggling to see the real use case for this, but I think it
might be useful. I think the understanding where it really helps and use
cases would really be beneficial.
Mahesh: I would agree with Rob, I voted no mainly because of lack of
understanding. A more concrete example about how useful it would be
discussed on the mailing liste before we decid that it is not something
that we should not pursue.

NETCONF over TLS 1.3 (10 min)
https://datatracker.ietf.org/doc/html/draft-ietf-netconf-over-tls13-02

Discussion Leader: Sean Turner

Sean: Addressing LC comments
Mahesh: We will watch the mailing list for a few days but then progress
it
Sean: Should we maybe do a LC because the title and scope changed?
Rob: I have a large queue of documents to review, so giving it two weeks
would be great.
Sean: There is a work in tlswg for deprecating TLS 1.2 entirely, which
will have big implications for this draft. Two weeks more is fine, we
are not in a hurry.

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

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

https://datatracker.ietf.org/doc/html/draft-quilbeuf-opsawg-configuration-tracing-00

Discussion Leader: Jan Lindblad, Roque Gagliano and Jean Quilbeuf

Jean: Mainly cosmetic and editorial changes. The interesting part is how
to leverage netconf-trace-ctx-extension.
Jean: Open questions:

• switch dependency from transaction-id to trace-ctx-extension, would
  simplify things.
• Where to get client-id from
  Kent: The slide says that trace context can be used for RESTCONF as
  well.
  Jean: It is HTTP based so it works with RESTCONF.
  Roque: the W3C baggage might be a better place to put client-id than
  trace-ctx, not introduced yet but will be the next step in our work.

Jan: Transaction-ID, next steps need some implementation experience so
the standard is tested and reviewed.
Roque: Trace-CTX, a key element for using OTLP (opentelemetry protocol)
is to tap into the ecosystem of collectors etc that exists.

Jan: Overview of netconf-transaction-id, opsawg-configuration-tracing,
netconf-trace-ctx, netconf-private-candidates. Great overlap in use
cases, not much overlap in functionality, but could be put in a coherent
framework. All techniques can be used, and are useful, by themselves.

Rob: Good to align. Try to avoid a fifth document for the framework. If
the text in the four documents can have informative text on how to use
together with other drafts that might be enough. If not, write a fifth
overview document.
Jan: I agree totally, but wanted to give some negotiating space.
Mohamed (chat): I think that it makes sense to have one framework doc,
but keep the solution I-Ds separate. The framework is helpful for those
who will use the functionality.
Mahesh: actually an archictecture document would help, but you can
choose to wait for synchronized terms (between drafts) or start the
fifth document.
Rob: Thinking of the packaging work where we started with a problem
statement definition and then an overview for the solution. But going
forward we have sort of lost those in the process and will try to not
have those. We have copied some of the base spec. The difference there
is that the drafts there build upon each other more whereas I think
these sit as a set. But I'm not wedded to any particular solution here.

Kent: In between the two ideas being put forward, looking at the
client-server set of drafts; they all have a few paragraphs preamble
presenting the solution and how that draft is related to the others, the
suite of drafts.
Jan: That (kent's suggestion) would be ideal.
Benoit: Don’t want to be blocked by the lack of architecture document,
no issue with writing it after.

Non-Chartered items:

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

James: The -01 revision of the draft haven't been published yet but will
be soon. Private candidates more relevant for NETCONF so no work is done
to define it for RESTCONF.
Kent: clarify the statement about private candidate is more relevant to
NC.

Poll Question: SHOULD PRIVATE CANDIDATE SUPPORT RESTCONF AS WELL?
Poll Results: No conclusion

Rob: Definitely makes sense to think about RESTCONF, but might be
interesting (due to NMDA and datastore concept in RESTCONF) or not
(RESTCONF being a simpler protocol). A way forward would be think about
RESTCONF but maybe define it in a document later on. Having one document
is easier to review, and perhaps split out protocol specific bits later
on.
James: Address the outstanding questions, discuss them on the list, and
then ask for WG adoption.

YANG model for NETCONF Event Notifications (5 min)
https://datatracker.ietf.org/doc/html/draft-ahuang-netconf-notif-yang-01

Presented by: Thomas Graf

Thomas: Asking for WG adoption. Should proceed quickly because the draft
addresses missing YANG modelling for definitions from RFC 5277 and RFC
8639.

Support of Hostname and Sequencing in YANG Notifications (5 min)
https://datatracker.ietf.org/doc/html/draft-tgraf-netconf-notif-sequencing-00

Presented by: Thomas Graf

Thomas: Extends NETCONF notification defined in RFC 5277 with fields
sysName, publisherId, and sequenceNumber.

Support of Network Observation Timestamping in YANG Notifications (5
min)
https://datatracker.ietf.org/doc/html/draft-tgraf-yang-push-observation-time-00

Presented by: Thomas Graf

Thomas: Extends YANG-Push streaming update notification defined in RFC
8641 with fields observation-time and state-changed-observation-time.

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

Presented by: Thomas Graf

Thomas: Extends YANG-Push subscription and publishing mechanism defined
in RFC 8641 by adding the ability to subscribe to a specific revision or
latest-compatible-semversion and also by extending the YANG-Push
subscription state change notification message so that the YANG-Push
receiver lears beside the XPath and the subtree filter also the revision
and revision-label.

Rob: Good and important work, how to get data from device and into e.g.
analytics.
Joe: Maybe I need a concrete example, the drafts give two definitions
for observed-time. I would love a concrete example, e.g. the device
would put this timestamp for this event, this other timestamp for
another event etc.
Tomas: sync-on-start would give the original time two weeks ago
Benoit: There are a lot of drafts, but there were specific questions per
document about adoption. Maybe there are questions for the chairs here.

Poll Question: HOW MANY PEOPLE HAVE READ ANY OF THE MESH DRAFTS?
Poll Results: Almost half of the attendees had read at least one draft.

Rob: Brilliant that operators propose solutions to problem they
encounter.

Poll Question: ARE PEOPLE INTERESTED IN THE MESH WORK?
Poll Results: Yes, the WG is interested in this work

Mahesh: We could start with the YANG module draft that adds a
date-and-time header to the notification, but defer the rest of them to
give the WG time to read the drafts. The adoption poll will be proposed
on the mailing list.

Incident Management for Network Services (10 min)
https://datatracker.ietf.org/doc/html/draft-feng-opsawg-incident-management-00

Presented by: Qin Wu

Qin: Asking for feedback for this opsawg draft.
Mahesh: Would it be useful to look at the draft from the previous
presentations to see if timestamps and trace could be used to do the
correlation between events?
Qin: That could be interesting to look at and we could take it to the
list to discuss it.
Rob: Have you had a look at the SAIN (service assurance) architecture,
where signals from the network are aggregated into something meaningful
that can be acted on? How does it relate to the dmlmo draft
(draft-palmero-opsawg-dmlmo)? Machine learning might not be that
effective, it feels a be over-hyped.
Qin: Could reduce pressure on management systems.
Thomas: Very valuable work. Good to build on top of existing
alarm-eventing YANG model. I have been reviewing the draft and this
aligns well with our work, adding additional metadata so the network
device can be better identified and also adding better timestamping
where the observation time of the network is being described.
Oscar: Have you considered health operation for devices, instead of just
reporting alarms for errors have you thought about reporting current
status of a device?
Qin: Good suggestion, thank you!

OPEN MICROPHONE

Rob: Have reviewed client-server drafts, one question that came up was
how we handle keys built-in to the device, have been looking at system
datastore draft. We should be able to use the keys without effectively
copying them in.