Agenda for the NETCONF 109 WG Session

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

Note takers:

Session:
Wednesday, November 18
UTC+07: 12:00-14:00

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

Available During Session:

ICS: https://datatracker.ietf.org/meeting/109/sessions/netconf.ics
MeetEcho: https://meetings.conf.meetecho.com/ietf109/?group=netconf
Jabber: xmpp:netconf@jabber.ietf.org?join

Available During and After Session:

CodiMD: https://codimd.ietf.org/notes-ietf-109-netconf
Slides (TGZ): https://datatracker.ietf.org/meeting/109/agenda/netconf-drafts.tgz
Slides (PDF): https://datatracker.ietf.org/meeting/109/agenda/netconf-drafts.pdf

Available After Session:

Recording: https://ietf109.conf.meetecho.com/index.php/Recordings#NETCONF
Jabber Logs: https://www.ietf.org/jabber/logs/netconf

Introduction

Chairs (10 minutes)
Session Intro & WG Status

Chartered items:

Status and Issues on Client-Server Suite of Drafts (10 min)
https://tools.ietf.org/html/draft-ietf-netconf-crypto-types-18
https://tools.ietf.org/html/draft-ietf-netconf-trust-anchors-13
https://tools.ietf.org/html/draft-ietf-netconf-keystore-20
https://tools.ietf.org/html/draft-ietf-netconf-tcp-client-server-08
https://tools.ietf.org/html/draft-ietf-netconf-ssh-client-server-22
https://tools.ietf.org/html/draft-ietf-netconf-tls-client-server-22
https://tools.ietf.org/html/draft-ietf-netconf-http-client-server-05
https://tools.ietf.org/html/draft-ietf-netconf-netconf-client-server-21
https://tools.ietf.org/html/draft-ietf-netconf-restconf-client-server-21
Discussion Leader: Kent Watsen

Kent presenting status updates since IETF 108

Conveying a CSR in a SZTP Bootstrapping Request (10 min)
https://tools.ietf.org/html/draft-ietf-netconf-sztp-csr-00
Discussion Leader: Kent Watsen

05:18 utc

[Chair Action: need to initiate WGLC]

An HTTPS-based Transport for Configured Subscriptions (10 min)
https://tools.ietf.org/html/draft-ietf-netconf-https-notif-05
Discussion Leader: Mahesh Jethanandani

05:24

Mahesh: Can Rob do a poll to ask if people are happy for this to go to wg last call?

12 raised hands out of 34, no opposed.
Rob: I think that we can take this to WG LC. Rob will work with Mahesh and Kent to check on the exact process.

[Chair Action: need to work with Rob to initiate WGLC]

UDP-based Transport for Configured Subscriptions (10 min)
https://tools.ietf.org/html/draft-ietf-netconf-udp-notif-01
Discussion Leader: Pierre Francois

05:30

Kent: IETF recomendation that both zero and max should be reserved fields
Mahesh: The question on the private space, is there a mechnaism to find out what encoding is supported.
Pierre: No, we could define a companion draft if required. People that we are interacting, care about the standard ones. Although choice was to allow vendors to use reserved bits.
Thomas: Just want to raise that this is a general problem. If yes, then it should be done in both HTTP and UDP notif. If not, then I think that it can be removed from this draft.
Andy: I would prefer to take the S bit out, and put GPB back into the protocol.
Pierre: I completely agree
Andy: Prefer the enumeration to go back.
Pierre: If I give a reference then it needs to be informative.
Andy: I still think that the S bit should be taken out.
Pierre: You might be right that it should be taken out, and private bits can be used, but then how does a vendor know what to do.
Rob: as a contributor, would it be specific enough, as GPB “encoding” doesn’t entirely define the serialization format, as “dictionaries” (?) may differ…
Pierre: For this draft, it does not matter. The clients should already know what the contents of the data would be. Thomas would you like to comment.
Thomas: I agree. Another option would be to have another bit: Other. Need feedback from AD. Can we list any non-standard encoding.
Kent: As a contributor, comment made about the HTTPS notif draft, it also needs to support private encodings, but this is already the case using HTTP media types, but private media types could be used. When subscribed notifications are being used and configured, there is a YANG identity called “encoding”, and there are sub-identities for JSON and XML, and other encodings can be defined as well.
Pierre: Another round of discussion.

Rob: Don’t want to make it unnecessarily complicated, nor should referencing GPB be a problem, the key is that interoperability is possible.
Pierre: Remove S-bit and reserve few R-bits.
Rob: Reserve values
Pierre: Can leave a value.
Rob: Could use an IANA registry that would allow these to be specified in future documents if required.
Rob: Thinks that it’s is okay with IESG for a referenced protocol to NOT be an IETF standard. Will need to verify to be sure.

[No Chair Actions]

Subscription to Distributed Notifications (10 min)
https://tools.ietf.org/html/draft-ietf-netconf-distributed-notif-01
Discussion Leader: Thomas Graf

05:53

Rob: tend to regard an npu and a cpu as different, but in some cases they could be the same.
Thomas: exactly, not just about naming, but also being able to model it down to chissis, linecards, etc.
Mahesh: How can you tell if a linecard can be removed and re-inserted, or changed.
Thomas: We would like more feedback on how to model this.
Mahesh: Would you say that you have a problem today, regardless of whether ietf-hardware is the right model.
Thomas: Yes, exactly, if that is a problem that needs to be solved. The question is whether or not it needs to be mapped down to a network process. I’m not against it, and I support that idea.

[No Chair Actions]

Non-Chartered items:

Telemetry Data Export Capabilities (10 min)
https://tools.ietf.org/html/draft-tao-netconf-data-export-capabilities-01
Discussion Leader: Peng Liu

06:02

Kent: Chairs did a suitability poll before, which had an objection from Andy. Has that been addressed?
Peng: Qin can help answer this.
Qin: We discussed the issue, and all the issues have been resolved in the latest version.
Kent: Maybe the current update addresses the issue, but it hasn’t been discussed on the list, and I think that this needs to happen, or maybe Andy can say now?
Andy: I don’t think that all this extra complexity is needed and the RPCs already have extensive mechanisms to provide these hints.
Qin: We clarified your issue in the first bullet. We could use RPC to return an error to report what is wrong. But if it can be defined up front then we can avoid the negotiations.
Andy: I don’t see where that is happening. Either I send one request and get the hints, or otherwise I get back the capabilities. In both cases, one request and one response.
Qin: The idea is to advertise the capabilities from the server. Hence don’t need the RPC.

Rob: I think that the model is designed to allow the information to be available up front, off the box. The model currently allows clients to specify a single transport, encoding, etc. But probably needs to allow a server to advertise which different trasports, encodings are supported.
Qin: We could allow the device to advertise different transport capabilities.

[No Chair Actions]

Adaptive Subscription to YANG Notification (10 min)
https://tools.ietf.org/html/draft-wang-netconf-adaptive-subscription-02
Discussion Leader: Qin Wu

06:16
Kent: Andy had objected before, Andy can you comment on whether your objection has been addressed.
Andy: I haven’t read the latest draft, don’t really have any objections, but not our focus. Have implemented YANG push, but haven’t focussed on periodic. More work to do on-change but better.
Kent: As a contributor, I’m surprised, some values don’t change very freqently.
Andy: Can request a r
Rob: This seems quite complicated. Would having higher/lower priorities be a simpler approach.
Qin: Whether you a higher connection rate or lower connection rate then don’t lose any data.
Thomas: I was thinking of Robert’s comment and I think the same. Could have a range, and the publisher decides on rate.
Qin: The publisher has a choice to switch between the data. That is what has been proposed.
Mahesh: We are running behind on time, please take this to the mailing list.

[No Chair Actions]

Transaction ID Mechanism for NETCONF (10 min)
https://tools.ietf.org/html/draft-lindblad-netconf-transaction-id-00
Discussion Leader: Jan Lindblad

06:30

Kent: Traditional approach is to use a lock, get-config then edit-config.
Jan: Yes, but that would take a long time, e.g. serveral minutes, and hence that is not what we see in real networks.
[Rob: I missed 10 mins of comments due to a power outage.]
Kent: this solution SHOULD mimic RESTCONF’s, as server-implementations typically build their RC/NC stacks on top of each other; anything else will cause complication and confusion.
Jan: Yes, this is the same idea as ETags.
Mahesh: Could this be tagged at a transaction level. Yes, I understand from an optimization perspective this be a bit more coarse grained, but you are now down to a single transaction to see what has changed.

[No Chair Actions]

List Pagination Mechanisms for NETCONF and RESTCONF (20 min)
Discussion Leader: Kent Watsen and Qin Wu

06:43

Kent raised a number of discussion topics, none of which generated any discussion, and thus he said that he’d take them to the list.

[No Chair Actions]

Remaining 10 min.

done at 07:02