Minutes IETF114: netconf: Mon 10:00
minutes-114-netconf-202207251000-00

Introduction

started at 10:03

Chairs (10 minutes)
Session Intro & WG Status

Chartered items:

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

Kent: You have the dtls container and right underneath it the
dtls-enable flag. Converting the dtls container into a presence
container would achieve the same objective.
Alex: Okay.
Benoit: I was reading your slide about secure networks, and the section
on Security Considerations, could you add a reference to RFC 8799, which
explains the distinction between the controlled domains and something
that is on the wire.
Alex: Okay.
Rob: Quick question on the version change. What is the meaning of the
version flag change? What version would you expect to ship in the RFC?
Alex: We would like to have the RFC have the last version in the draft.
Would like the collector to collect the already implemented versions of
the draft.
Rob: So a IANA maintained registry to maintain these versions? How is
that managed?
Alex: Right now there is no IANA section in the draft.
Rob: Having an IANA considerations section to define a version registry
may be helpful.

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

Discussion Leader: Alex Huang Feng

Mahesh: As a contributor, and this applies more to the DTLS draft, did
you get to discuss with Sean regarding the DTLS container?
Alex: Not yet, hope to sync up this week.
Mahesh: Also needs to get to SECDIR review, please let me know when it
is ready.
Alex: I will do so.

commence 10:19

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

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

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

Discussion Leader: Qin Wu

started 10:22

Qin: Looking forwarding for more comments.
Balazs: Interesting and important work, but some comments:
Balazs: 1. Not required, but server doesn't necessarily have a stable
ordering. Theoritically, every ms you could change the order of your
list. You should address it.
Balazs: 2. In some cases, sorting is very complicated, e.g., for
different European languages. Specially, if you think of sorting
alphabetically in these languages.
Balazs: 3. How does this work if the Xpath selects two lists that are
active.
Qin: Good comments, we will try and figure out how to address this.
John: Thank you for this work. Would suggest preferring using keywords
that are already familiar to implementors and operators. Specifically,
suggest order-by instead of sort-by use order-by, and for direction use
descending and ascending. Will admit I have mixed feelings about
keywords that have mixed meanings.
Rob: Is there a potential performance issue here? I.e., is it necessary
to filter and sort multiple times, whenever a next "page" of results is
returned? Do you refilter and resort? For a large list, this could
specially be a performance problem.
Jeff: Balazs and Rob hit two of the points I was going to talk about.
Stability of sort orders, if you are using offset, and the list keeps on
changing, then the offset becomes meaningless. Might be better to keep
the last key displayed rather than an offset.
Jeff: Regarding Rob's point, rather than having a queries running over
and over, perhaps be able to request that a stable snapshot is taken and
then walk the data. Problem here is that the data set could be very
large, and you might not have enough persistent storage to do this, so
you can't make this a mandatory thing.

Non-Chartered items:

Transaction ID Mechanism for NETCONF (10 min)
https://datatracker.ietf.org/doc/html/draft-lindblad-netconf-transaction-id-02

Discussion Leader: Jan Lindblad

started 10:42

Rob (contributor): Is the fractional timestamp expected to be unique.
Jan: Yes.
Balazs: Not acceptable to have the same timestamp for two different
transactions, doesn't help. Having the order of the transactions is a
nice feature.
Jan: Some of this functionality is already defined in RFC 8040. Not sure
how useful this would be in RESTCONF.
John O'Brien: The device and/or manager might not necessarily have a
good time stamp. Do you think that these considerations have been
addressed by this draft.
Jan: Time is a complicated topic. Only define one operation of these
timestamps which is equality.
Kent (contributor): Second resolution seems okay for common use-cases
(test is anything changed > 1-sec). Clients in < 1-sec environments
should using Etag (not last-modified).
Jan: I tend to agree.
Rob (contributor): Could use logical timestamps, i.e., a sequence
number, to guarantee ordering and uniqueness.
Jan: Should be using etags, which are more robust.
Rob: Okay, perhaps useful to ensure that the text is clear about
timestamp limitations.

Charles: The text around etags has some wiggle room on expected server
behaviour when match fails, was that intentional?
Jan: Please point out the section so I'm clear. But you are right that
we should only be comparing the transaction ids. However there are cases
where other changes (outside the payload of the edit-config), perhaps
that is what I was trying to say.
Charles (update to above): Section 3.5, Conditional Transactions, "By
supplying the latest txid values known to the client in its change
requests (edit-config etc.), it can request the server to reject the
transaction in case any relevant changes have occurred at the server
that the client is not yet aware of." Why not very specifically say if
and only iff txid or last modified values do not match?
Charles: how to the client determine if the server failed its request
due to the Etag?
Jan: there is a specific error-tag for that.

Mahesh: Is there interest in the work and should it be adopted?
Poll results: A unanimous support for the draft.
Mahesh: Trend appears to be failrly positive. We will take to the
mailing list.

Using NETCONF over QUIC connection (15 min)
https://datatracker.ietf.org/doc/html/draft-dai-netconf-quic-netconf-over-quic-02

Discussion Leader: Huaimo Chen and Jinyou Dai
started 11:03

Anthony: Is QUIC reliable enough for the NETCONF use case?
Jinyou: good question, we'll have to check on that.
Mahesh (contributor): Are the changes only with IANA Considersations, or
are there protocol-level changes that we need to think about?
Jinyou: The intent is only to change the transport, the protocol should
stay the same.
Rob (contributor): Thanks for bringing this.
- Unclear whether separate streams will be that helpful, need to
understand how YANG push and notificaiton sessions work.
- Not sure that running RPCs in parallel will necessarily be helpful,
adds complexity, and can be done with separate sessions anyway.
- Not sure whether the quic session setup will necessarily be that
helpful.
- Perhaps consider for NETCONF-next vs RESTCONF-next
Jinyou - will ask the author to consider.
Mahesh - we'll skip a hum on this draft.

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

Discussion Leader: Sean Turner

started around 11:20

Rob (contributor): Thanks for bringing this. Useful work, helpful for
the world to move to later/more secure versions of TLS.
Poll on adoption this work:

• Strong support for adoption, no votes against.
  Mahesh: We have overwhelimg response but will take it to the list to
  confirm the adoption.

RESTCONF-next and NETCONF-next discussion

start 11:25

• Some issues tracked against NETCONF/RESTCONF next, also an updated
  version

Rob:

• Lots of things that could be considered:

  • QUIC protocol
  • use JSON for NETCONF
  • Private candidate datastore
  • Binary encodings.

• Do other folks have a view. Is there any interest in this work?

Jeff Hass:

• Would be interested in binary formats.
• Interest in streaming telemetry.
• Would be nice to see CBOR used.
• What happens to YANG as a language (e.g., currently it is using
  pattern statements are checking against strings). What happens to IP
  addresses.

Mahesh:

• Quite a few issues, useful to understand how much interest in doing
  this work. Should we do a poll.
• The clean-up to RFC 7950 to extractor

Kent:

• Do we need to do binary, COAP protocol?

Rob:

• I was thinking more about the payload(data) being binary more so
  than the headers

Paolo Lucente NTT:

• If we can isolate ourself from protobuf it would be good.

Kent:

• We did discuss a binary-notifications as part of YANG push. Would
  that solve the 80% of the work?

Jeff:

• For streaming telemetry it is definitely a key use case.
• But it shoudn't matter, we should be able to support binary in both
  cases.

Kent:

• It may be a great simplification to only focus on telemetry, givem
  it is a separate draft.

Jeff:

• Think about much overhead there is from printing the tags in an XML
  document.

Mahesh: Before a poll, wanted to discuss cleanup of hello message and
capabilities. Tied that to is the work of YANG library and versioning
stream mechanism. Is there a sense that this cleanup is needed, or is it
a nice to have.

Rob (contributor): was discussed with YANG-packages and vesioning work.
If a mew protocol version, the message should be greatly
simplified.

Thomas: Regarding notification message header, also adding xpaths and
versioning aspect. So if you make this binary that would be very
helpful.

Poll: Some support for updating the protocols, but also some votes
against.

Benoit: I didn't really understand the question, we need to do these, so
I voted yes!

Balazs: Could be done as additions rather than a new version of the
protocol.

Mahesh: Generally favorable, but question is there are any specific
efforts we can do now.

Kent: Anyone can submit an I-D for moving work forward now (before the
YANG-next work comes)

Rob: There were some votes against doing this work. If the folks who
votes against could provide comments that would be hepful.

Jan: comment in chat: It might be helpful to do separate polls for the
individual enhancements.

Mahesh: We will take this to the mailing list, WRT if there are items
that can be worked on now.

done 11:46