Agenda for the NETCONF 108 WG Session

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

Session:
Tuesday July 28th
UTC: 11:00-12:40

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/108/sessions/netconf.ics
MeetEcho: https://meetings.conf.meetecho.com/ietf108/?group=netconf
Jabber: xmpp:netconf@jabber.ietf.org?join

Available During and After Session:

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

Available After Session:

Recording: https://youtube.com/watch?v=stFFTCnDuzI
Jabber Logs: https://www.ietf.org/jabber/logs/netconf

Introduction

Session Intro & WG Status

Presenter: Chairs

Mahesh talking.
No comments.

Chartered items:

Status and Issues on Client-Server Suite of Drafts

Rob: Don’t like option 3 (where you end up with binary). Option 4 looks like a good choice (to solve this problem generically). Would people like to sometimes only have passwords encrypted?
Kent: The module and/or consuming models can define if-feature statements to disable the cleartext passwords. Kent will add “password-grouping” the crypto-types draft.

Rob: Having consuming models augment-in a “path” node when needed seems appropriate
Kent: Will keep model as is. Folks can object during WGLC.

Kent: Will update PSK ID per Henk’s email, will keep PSK “id” leaf as a “string” type, make non-mandatory, and fill on RFC reference. Does any one have any comments on the third issue?
No comments.

Kent: Does anyone have any comments before these drafts go to WGLC?
No comments.

An HTTPS-based Transport for Configured Subscriptions

https://tools.ietf.org/html/draft-ietf-netconf-https-notif-03
Presenter: Mahesh Jethanandani

Slide 5:
Reshad Rahman: Don’t understand what you mean by “without subscribed notifications”?
Mahesh: The appendix gives an example of how to use the grouping but not support everything under subscribed notifications.
Reshad: Okay, I will take a look.

Tim Carey: I thought that we were going to be able to use this draft in the context of the existing subscription notification mechanisms along with the IETF push framework?
Mahesh: Main body talk about YANG push and subscribed notifications?
Tim: When you say “not using subscribed notifications”, what does this mean?
Kent: Doesn’t have the bells and whistles of subscribed notifications. Instead, it is a very simple mechanism to configure a receiver.
Tim: Can use it will subscribed notifications, can use it will push, and can also use it with …
Mahesh: There is an example of how to use it with subscribed notifications, and also an example of how to use it without.
Kent: Could change the example to be a push example.

Hum: How many people have read this version of the document or a recent revision (noting that the authors are chairs and unable to vote). Result: Piano, interpretted as a reasonable number.

Rob: Does anyone object to this document being taken to WGLC now?
No objections.

Non-Chartered items:

UDP-based Transport for Configured Subscriptions

https://datatracker.ietf.org/doc/draft-unyte-netconf-udp-notif-00
Presenter: Pierre Francois

Tim: Is the implementation publicly available, and if so where.
Thomas: It is available as a closed source implementation. We are working on a open source implementation. It will be available soon.
Rob: A clarifying question. By UDP this is a lossy or a best effort mechanism. That data lost is just bad luck.
Thomas: That is correct. This for accounting purposes. You will have a id that tells you how many packets were dropped, but the data is lost and will not be retransmitted.

Benoit: This draft is about UDP export, IPFIX like or Netflow like export of YANG objects.
Thomas: Yes that is correct

Kent Hum: How many people have read this vesion draft of a previous version of the related drafts?
Hum result: Piano

Benoit: I think that this is an interesting ideal, as it was for IPFIX. At the time the IESG forced us to introduce a congestion control mechanism, something like SCTP, but the industry hasn’t implemented this part. Rob should check with the IESG whether this will be an issue and get blocked by IESG.
Rob: Yes, I need to check with the IESG
Tim: We probably need a more efficient model for IPFIX in YANG push, so I agree with this work in that regard. But is the work done in this draft and the next one such that it allows multiple round trips per protocol, that you can add on to Subscribed Notification. You have subscription, and then you have UDP based, HTTP based, like what we did with client-server drafts. Is the model designed that you can add a new transport and encoding as an addendum to the draft?
Pierre: It is the intention that you select the transport you want for a particular subscription.
Kent: And just to add to that, this draft is the UDP “notif” draft much like the draft that Mahesh presented is the TCP “notif” draft.
Tim: Yes, but it works on subscription to distributed notifications, that it has a caveat. That whether that subscription is UDP based or TCP based.
Thomas: Multiple processes are streaming this data. For that purpose a generator id is used. Optional, not requried.

Subscription to Distributed Notifications

https://datatracker.ietf.org/doc/draft-unyte-netconf-distributed-notif-00
Presenter: Thomas Graf

Kent: Are there any objections to adopting this work, along with the previous draft?
Mahesh: Should we ask for a hum?
Hum: “All in favour of adopting both drafts”
Hum result: Piano (Kent and Mahesh also support this work and cannot hum). Will get taken to the list.

Self-explanation Data Node Tag & Telemetry Data Export Capabilities

https://datatracker.ietf.org/doc/draft-tao-netconf-notif-node-tag-capabilities-02
https://datatracker.ietf.org/doc/draft-tao-netconf-data-export-capabilities-01
Presenter: Qin Wu / Liu Peng

Peng Liu presenting

Hum: Who has read the last two drafts?
Hum result: Piano.
Tim: I thought that were going to be a design team for capabilities?
Qin: Working with China mobile, also looking for other contributors?

Hum: All in favour of adopting these two drafts, please hum now.
Hum result: Piano.
Kent: Will take this to the list for an adoption poll.

Adaptive Subscription to YANG & Bulk Subscription to YANG Event Notifications

https://datatracker.ietf.org/doc/draft-wang-netconf-adaptive-subscription-02
https://datatracker.ietf.org/doc/draft-wang-netconf-bulk-subscribed-notifications-02
Presenter: Qin Wu / Liu Peng

Qin presenting
Kent: Does this work over any subscription (both dynamic and configured)
Qin: Yes. For dynamic subscription requires a new RPC
Kent: To what extent has this been implemented.
Qin: For adaptive subscription most of these parameters have been implemented. For bulk subscription, it is mostly in planning.
Hum: Who has read latest (or recent?) versions of the drafts.
Hum result: Piano
Kent: Is there any objections to adopting thse drafts?
Hum: If you support adopting these drafts then please hum now.
Hum result: Piano

Conveying a CSR in a SZTP Bootstrapping Request

https://tools.ietf.org/html/draft-kwatsen-netconf-sztp-csr-01
Presenter: Kent Watsen

Kent presenting
Hum (Mahesh): How many have read any version of this draft?
Hum result: Pianissimo
Hum: How many people believe this should be adopted as a WG item?
Hum result: Piano
Mahesh: Any objections?
Rob: No objection, I strongly support this work.
Kent: As a partipant, I support this work too, based on demand/requests received.