[netconf] Re: YANG Push (RFC 8641) on-change example

[Andy Bierman <[e-mail]>]

On Wed, May 22, 2024 at 3:36 AM Rob Wilton (rwilton) <rwilton=
[e-mail]> wrote:

> Hi,
>
>
>
> The YANG Push RFC provides the following example for an on-change update.
>
> According to the text accompanying the figure 2 in section 3.7, the
> example is for:
>
>
> “   Figure 1 provides an example of a notification message for a
>
>    subscription tracking the operational status of a single Ethernet
>
>    interface (per [RFC8343 <https://www.rfc-editor.org/rfc/rfc8343>]).  This notification message is encoded XML
>
>    [W3C.REC-xml-20081126 <https://www.rfc-editor.org/rfc/rfc8641#ref-W3C.REC-xml-20081126>] over …”
>
>
I agree that a replace on the ancestor node is not correct.
I cannot find any details on the example filter that was provided to set up
this subscription.

Thanks for bringing up two of the critical problems with YANG Push that
need to get fixed.

1) The arbitrarily complex XPath and subtree filtering mechanisms are NOT
interoperable since NO SERVER
actually supports that.  A much more restricted filter is actually
supported by the industry,
except restricted differently for every server.

A much more useful filter would be based on a subset of instances of a
single object.
Since multiple subscriptions are allowed, there is no need to pile all
objects into a single filter anyway.

2) The YANG Patch reporting mechanism is difficult to use and there are no
clear guidelines on how
an on-change update is constructed.  Arbitrarily complex edit lists are not
useful to telemetry applications
that just want a new representation of the object subset when it changes at
all.

E.g., a server may accept only container and list objects for the target.
The server may not be able to push a single leaf as the target. (This
example is the RFC is not very good).

New example:

The client monitors /interfaces-state.
The server reports the /interfaces-state/interface child node changes.

Let's say 10 counters change per interface.
An edit list with 10 replace operations is complex to generate and complex
to use.
Instead, the server reports 1 replace operation on
/interfaces-state/interface[name='foo'].
Maybe there is 1 replace interface per update or maybe multiple interfaces.
The client should expect either case.
The server should never report a replace on /interfaces-state unless every
interface is included.

IMO the periodic updates (which do not use YANG Patch) are much more usable
by the client.
YANG Push should be changed so the client can request this format for
on-change updates.


Andy


The example notification is given as:
>
>   <notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
>
>    <eventTime>2017-10-25T08:22:33.44Z</eventTime>
>
>    <push-change-update
>
>         xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push">
>
>      <id>89</id>
>
>      <datastore-changes>
>
>        <yang-patch>
>
>          <patch-id>0</patch-id>
>
>          <edit>
>
>            <edit-id>edit1</edit-id>
>
>            <operation>replace</operation>
>
>            <target>/ietf-interfaces:interfaces</target>
>
>            <value>
>
>              <interfaces
>
>                   xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">
>
>                <interface>
>
>                  <name>eth0</name>
>
>                  <oper-status>down</oper-status>
>
>                </interface>
>
>              </interfaces>
>
>            </value>
>
>          </edit>
>
>        </yang-patch>
>
>      </datastore-changes>
>
>    </push-change-update>
>
>   </notification>
>
>
>
> But I would expect a receiver to interpret this replace operation as replacing the entire operational state for all interfaces with a single eth0 interface entry reporting just the oper-status as down.  Is my interpretation correct?
>
> Instead, I think that the notification target should have identified only the oper-status leaf on the specific interface.  I.e., the generated notification should instead be:
>
>   <notification xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
>
>    <eventTime>2017-10-25T08:22:33.44Z</eventTime>
>
>    <push-change-update
>
>         xmlns="urn:ietf:params:xml:ns:yang:ietf-yang-push">
>
>      <id>89</id>
>
>      <datastore-changes>
>
>        <yang-patch>
>
>          <patch-id>0</patch-id>
>
>          <edit>
>
>            <edit-id>edit1</edit-id>
>
>            <operation>replace</operation>
>
>            <target>/ietf-interfaces:interfaces/interface=eth0/oper-status</target>
>
>            <value>
>
>              <oper-status xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces">down</oper-status>
>
>            </value>
>
>          </edit>
>
>        </yang-patch>
>
>      </datastore-changes>
>
>    </push-change-update>
>
>   </notification>
>
>
> If folks agree, then I can file an errata.
>
> Regards,
> Rob
>
>
> _______________________________________________
> netconf mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>