IETF Logo Mail Archive

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

Thomas.Graf@swisscom.com Thu, 23 May 2024 11:27 UTC

Return-Path: <Thomas.Graf@swisscom.com>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AD05C1519A3; Thu, 23 May 2024 04:27:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.396
X-Spam-Level:
X-Spam-Status: No, score=-4.396 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=swisscom.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AbClkhVRZyuN; Thu, 23 May 2024 04:27:19 -0700 (PDT)
Received: from mail.swisscom.com (mailout120.swisscom.com [138.188.166.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E81A7C15198F; Thu, 23 May 2024 04:27:17 -0700 (PDT)
Received: by mail.swisscom.com; Thu, 23 May 2024 13:27:14 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=swisscom.com; s=iscm; t=1716463635; bh=WbqASyFN+XKYs83+iGXYd0mxVswgyCxDC1LT8YMYUSY=; h=From:To:Subject:Date:References:In-Reply-To; b=NEFWxYtfEXiDsNnKyRH6NbpI5al0Gvpp41G6cJz7sjMnU+9xJNFoYNFJBzbeKXLRq 7tsNfoLIsiZtBYdOpmPFUCIvy3hgYP+edcOFRo3Jg34Da8RtiBre+eyODHYM8FRvMr aQKcg4keiYa2p/gkkMc9BSZ6oCjyX8uJaX4gXsQyqwM53R/BOcIJ1B9eWZzxKOKtdS 4PKe9w3J5W4gsigW/RPqHJIFgWDtAyMUJla0FmiUP2TYXkAUi/uMyt2PjR0Gi8LORe gWbb9QXnpWB7Ia6FmEabmtawLpDfNHEMIbAf4DlwjhacQKfMBJQG8E9850b93b1rse Sm8HGq5zt4BsQ==
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="----=_Part_414676_1474500417.1716463634526"
X-Mailer: Totemo_TrustMail_(Notification)
From: Thomas.Graf@swisscom.com
To: rwilton=40cisco.com@dmarc.ietf.org, netconf@ietf.org, rfc8641@ietf.org
Thread-Topic: YANG Push (RFC 8641) on-change example
Thread-Index: AQHarDF2QJLBz9OOAUepJH0mg0VgFrGkpNQw
Date: Thu, 23 May 2024 11:27:11 +0000
Message-ID: <4b7dc46ba8a846b9a06869a9c3ea4ea3@swisscom.com>
References: <LV8PR11MB8536A7CE5D17C1282D256DBAB5EB2@LV8PR11MB8536.namprd11.prod.outlook.com>
In-Reply-To: <LV8PR11MB8536A7CE5D17C1282D256DBAB5EB2@LV8PR11MB8536.namprd11.prod.outlook.com>
Accept-Language: en-US, de-CH
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_ActionId=437454b3-9555-4dcd-9313-f823bf57da0f;MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_ContentBits=0;MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Enabled=true;MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Method=Standard;MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_Name=C2 Internal;MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_SetDate=2024-05-23T10:47:29Z;MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_SiteId=364e5b87-c1c7-420d-9bee-c35d19b557a1;
x-originating-ip: [10.45.10.202]
X-CFilter-Loop: Reflected
X-Trustmail: processed
Message-ID-Hash: THTZ26QIOPYHVXGHY3HF5CXSUPFEPBXW
X-Message-ID-Hash: THTZ26QIOPYHVXGHY3HF5CXSUPFEPBXW
X-MailFrom: Thomas.Graf@swisscom.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-netconf.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [netconf] Re: YANG Push (RFC 8641) on-change example
List-Id: NETCONF WG list <netconf.ietf.org>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Owner: <mailto:netconf-owner@ietf.org>
List-Post: <mailto:netconf@ietf.org>
List-Subscribe: <mailto:netconf-join@ietf.org>
List-Unsubscribe: <mailto:netconf-leave@ietf.org>

Dear Rob,

I agree with your assessment. The example should be updated as you described.

The "target" is in fact a "filter" as described in https://datatracker.ietf.org/doc/html/rfc8072#section-2.1  and the "value" described in https://datatracker.ietf.org/doc/html/rfc8072#section-2.4 what should be changed.

Best wishes
Thomas

From: Rob Wilton (rwilton) <rwilton=40cisco.com@dmarc.ietf.org>
Sent: Wednesday, May 22, 2024 12:35 PM
To: netconf@ietf.org; rfc8641@ietf.org
Subject: [netconf] YANG Push (RFC 8641) on-change example


Be aware: This is an external email.


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 ..."

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

v2.40.3 | Report a Bug | By Email | System Status