Session Intro & WG Status
Discussion Leader: Mahesh Jethanandani
Mahesh: Will let Rob lead the discussion on consensus regarding the receiver capability mechanism at the end of this presentation, since we (the chairs) are also the authors of the draft.
Rob: I had a slightly modified suggestion (for slide 4). The routing YANG model has for AFI a IANA maintained registry that is also maintained as a YANG module. But I am not suggesting that we follow that. Merely that there is another option to consider.
Mahesh: Making it a IANA module takes away the ability for implementations to define their own vendor specific capabilities.
Rob: On the question of receiver capability mechanism, I personally do not see an issue with the currently defined mechanism defined in the draft. It is light-weight and works without the need for the receiver to be a NC/RC server. Are there any objections to keeping the current mechanism defined in the draft?
Note: No objections were observed in the meeting.
Discussion Leader: Qiufang Ma
Mahesh: Noted that draft defines identities called 'encoding-format' the definition of which seems to overlap with the proposed definitions in https-notif draft. Might want to consider using those definitions instead of defining new ones. Also, what is the difference between the identity 'compression-mode' and 'encoding-format' from an receivers perspective. Can it be treated as yet another 'encoding-format'?
Tim: A notification can be a gzip compressed file of a JSON encoded message. As such both a 'encoding-format' and 'compression-mode' might be needed. But separate from that we had some comments and questions raised in the last meeting that we were going to resolve on the list. Andy had raised some objections about the complexity of the draft. For my own benefit, did you resolve that objection that was raised on the list.
Qiufang: We did clarify, but did not close the loop with Andy.
Tim: So that verification is still outstanding? With Andy? To your solution?
Qiufang: So we will check with Andy.
Mahesh: Tim, thanks for that clarification. What is the difference between 'event' and 'on-change' identity?
Discussion Leader: Benoît Claise
Kent: All the three non-chartered drafts augment the system-capabilities module. There seems to be a lot of interest in this area and the WG wants to support this effort. Can this be looked at more holistically?
Beñoit: Happy that we have progressed from YANG module capabilities to telemetry capabilities. So we might want to think about this more holistically. Particularly about intent based networking.
Discussion Leader: Peng Liu
Mahesh: What does it mean to have adaptive subscription model on a 'on-change' notification. Isn't on-change notification essentially a real-time event? Should it not be sent right away?
Qin: We are riding on top of the two YANG-push notifications, which includes the on-change notification. We defined another mode. We do not change the existing mode.
Mahesh: If I understand you, the on-change notification will not be sent right away but will be modulated by the timer set by this draft for when to send the notification.
Alex: Yes, would agree that a on-change notification should not be limited by the adaptive mechanism described in this draft. However, it can be used for dampening of on-change notifications.
Rob: The solutions seems overtly complex. You are inserting and evaluating a XPath in the middle that needs to be evaluated. Maybe a simpler process would be to assing a QoS policy or priority value to a subscription, and have the device automatically downgrade the subscription.
Qin: With your proposal we cannot respond to a rapid change in resource.
Rob: My concern with this solution is that you are putting a arbitrarily complex XPath expression for evaluation. It seems a complicated way of doing it.