IETF Logo Mail Archive

[netconf] Re: Adoption call for notif-yang-04

Thomas.Graf@swisscom.com Sat, 15 June 2024 07:06 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 B599BC151061 for <netconf@ietfa.amsl.com>; Sat, 15 Jun 2024 00:06:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.104
X-Spam-Level:
X-Spam-Status: No, score=-7.104 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_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 85Fv35mx_7jg for <netconf@ietfa.amsl.com>; Sat, 15 Jun 2024 00:06:40 -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 8CA65C14F74A for <netconf@ietf.org>; Sat, 15 Jun 2024 00:06:38 -0700 (PDT)
Received: by mail.swisscom.com; Sat, 15 Jun 2024 09:06:18 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=swisscom.com; s=iscm; t=1718435179; bh=Lwe0ALR7BN9nODWlRLzb/VJKls+fxECs1OOIu6ufGx0=; h=From:To:CC:Subject:Date:References:In-Reply-To; b=SDSfBdcIysZ5T9Nr4jeIgRLUJjnBP5lq+D9WOTUf2ehJhBozGxzaUW0RC89nFVDVa CIznNexKnwPpuyEnHhskdlPckRKX4jlSZbdKJ8nJx4oi8+erXmCXZO4YXZaQK5BM+V NIByH8+Noa/HZINi/3NShv99eKPhmharqNfRErZVy/qoGcDJjdPD+hXKVgPq9PamOc u4KnPvKrVhyVC7O13Vrj7G2Am63nVLUnWzQYkq9AMnzY1KgpnHmCBTAxe+5c6oN777 uIrofajfStGUabQLT27DHUpG2wkEuvR0P6Ij0y5h6xp5jbHwwT7Va2axk1i0WqK7qu 04f/C+JwfCq/Q==
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="----=_Part_769426_741542254.1718435178266"
X-Mailer: Totemo_TrustMail_(Notification)
From: Thomas.Graf@swisscom.com
To: andy@yumaworks.com
Thread-Topic: [netconf] Re: Adoption call for notif-yang-04
Thread-Index: AQHava9UMs7k3Hn3w0iS+UJlAtAhgbHGBSaAgAEPqWCAADZ3AIABFhZA
Date: Sat, 15 Jun 2024 07:06:15 +0000
Message-ID: <99df25f91a384512826144b32e3dca92@swisscom.com>
References: <0100018eb57a21d8-26b38f41-a625-4d44-9248-09b349fd4212-000000@email.amazonses.com> <0100019012711c3f-d2317fe0-30c0-4207-bb1f-855190e3ea3f-000000@email.amazonses.com> <CABCOCHT-ThmSn-ikhHpfNfH8duV2hbkPVLoo+qLc4MAanjK=dg@mail.gmail.com> <dfc88ec7e3514cfeba7c981828f80ce5@swisscom.com> <CABCOCHTEVtBfJiwJE6NK6rmd-GcUBuRK7BVmybhVp9jC5j-rwQ@mail.gmail.com>
In-Reply-To: <CABCOCHTEVtBfJiwJE6NK6rmd-GcUBuRK7BVmybhVp9jC5j-rwQ@mail.gmail.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=82d66b90-d661-4589-a625-d2fbe0ca0cb8;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-06-15T06:36:33Z;MSIP_Label_2e1fccfb-80ca-4fe1-a574-1516544edb53_SiteId=364e5b87-c1c7-420d-9bee-c35d19b557a1;
x-originating-ip: [138.188.161.184]
X-CFilter-Loop: Reflected
X-Trustmail: processed
Message-ID-Hash: METYMAB3M7EOLWHFBQ5UN4KGTJYDSHGL
X-Message-ID-Hash: METYMAB3M7EOLWHFBQ5UN4KGTJYDSHGL
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
CC: netconf@ietf.org
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [netconf] Re: Adoption call for notif-yang-04
List-Id: NETCONF WG list <netconf.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/--qqUdUB3jMgomRkUMHZmBjAVOA>
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 Andy,


  *   There seems to be some desire to consume YANG modules as needed, based on PUSH updates received.

  *   Normally, a YANG-aware application consumes the entire YANG library from the server, using the correct

  *   revisions, features, and deviations.  (The augments get added without any special handling).

That does not scale. Zhuoyao researched how long that takes with todays major network vendor operating systems. The outcome was

Augmented-by Addition into the IETF-YANG-Library
https://datatracker.ietf.org/doc/html/draft-lincla-netconf-yang-library-augmentedby
https://datatracker.ietf.org/meeting/119/materials/slides-119-netconf-augmented-by-addition-into-the-ietf-yang-library-01.pdf

She is working on running code for the upcoming IETF hackathon
https://wiki.ietf.org/en/meeting/120/hackathon


  *   In our implementation, the southbound layer (YANG Push collector) is fully YANG-aware.

We are aiming the same. You will see that in the upcoming -01 version of draft-ietf-nmop-yang-message-broker-integration your input on discover capabilities based on RFC 9196 is taken into consideration.

An Architecture for YANG-Push to Message Broker Integration
https://datatracker.ietf.org/doc/html/draft-ietf-nmop-yang-message-broker-integration


  *   The northbound layer (subscriber) needs no YANG knowledge at all.

Not quiet correct. But I think I know what you mean. Lets rephrase. The YANG schema needs to be preserved. The northbound layer, the message broker consumer (https://datatracker.ietf.org/doc/html/draft-ietf-nmop-yang-message-broker-integration-00#name-yang-message_broker-consume) does not need to understand anything about RFC 5277, RFC 8639, RFC 8641 only about RFC 7950, RFC 7951 and RFC 9254.

Now if you follow the discussion between Kent an me https://mailarchive.ietf.org/arch/msg/netconf/P_tjkRedoLaB1SecaMLrrhDCsik/

You understand that a YANG Message_Broker Consumer (https://datatracker.ietf.org/doc/html/draft-ietf-nmop-yang-message-broker-integration-00#name-yang-message_broker-consume) you call it the northbound layer needs to be aware of https://datatracker.ietf.org/doc/html/rfc5277#section-4 and https://datatracker.ietf.org/doc/html/rfc8040#section-6.4 as well.

We should not go into an argue wherever this is implementable or not, we should argue wherever it is important to have a clear separation between the YANG-Push transport and the messaging. Would you agree this is important?


  *   The application subscribes to YANG data, not YANG Push updates.

  *   No YANG Push complexity is passed on to the application at all.

If you agree with my assessment above, I think you just agreed that this clear separation between YANG-Push transport and the messaging is important.

Unfortunately https://www.rfc-editor.org/rfc/rfc3535#section-3 doesn't specify this as a strong requirement. However between the lines you can deduct some of it.

That’s why I brought this into:

https://datatracker.ietf.org/doc/html/draft-boucadair-nmop-rfc3535-20years-later-02#section-4.4
https://datatracker.ietf.org/doc/html/draft-boucadair-nmop-rfc3535-20years-later-02#section-4.7

Your help would be appreciated.

Best wishes
Thomas

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