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

Kent Watsen <kent+ietf@watsen.net> Thu, 13 June 2024 15:21 UTC

Return-Path: <0100019012301ba8-cbf266f3-b215-4454-879e-193606dfd926-000000@amazonses.watsen.net>
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 69367C180B64 for <netconf@ietfa.amsl.com>; Thu, 13 Jun 2024 08:21:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.904
X-Spam-Level:
X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=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 (1024-bit key) header.d=amazonses.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 Pwjh92aCJCnT for <netconf@ietfa.amsl.com>; Thu, 13 Jun 2024 08:21:02 -0700 (PDT)
Received: from a8-96.smtp-out.amazonses.com (a8-96.smtp-out.amazonses.com [54.240.8.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B5C1C1840CB for <netconf@ietf.org>; Thu, 13 Jun 2024 08:21:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1718292061; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=F/Kr2bTnimE0tJ5W1x/k3UorLwOoYU2t3il0jNxt0Qc=; b=VAYBbWnuvV//z30X8cWxzN5IuUsn/Xf5/c38bjAMqng6dDs44N3wHnK2p87GxxEA DcokqCyO7kZSPEJuUqXndafska6mUVU4xXL9F4G67iu8Dx5HsKo9SPSBrkoSdslN2SW iwqrrOLCOz9GZOfsvDReoSR+wpR/VodPesb9ORGU=
From: Kent Watsen <kent+ietf@watsen.net>
Message-ID: <0100019012301ba8-cbf266f3-b215-4454-879e-193606dfd926-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_21960285-0A12-4DB4-81DC-4FA98D531D2D"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\))
Date: Thu, 13 Jun 2024 15:21:01 +0000
In-Reply-To: <0e02c89bdb8d445db0a3f83b30b01887@swisscom.com>
To: Thomas.Graf@swisscom.com
References: <0100018eb57a21d8-26b38f41-a625-4d44-9248-09b349fd4212-000000@email.amazonses.com> <DU2PR02MB10160110D4C72D682BA884802880E2@DU2PR02MB10160.eurprd02.prod.outlook.com> <CABCOCHT4Yy8gUKxmR9__ZcAEULiK8g-S7-B6EaLO8s0nk0FjTg@mail.gmail.com> <0100018f07521d0a-17e021b3-295a-4c50-8316-58632d7a7107-000000@email.amazonses.com> <CACvbXWGS_Er8bK0u4suNs0oHD7B6avObk8uu6bET_-7xWHcdbQ@mail.gmail.com> <355358f23f374b8dba8a20c00fea03f4@swisscom.com> <CABCOCHRVEQBocBAspUHJFE0vp8AkO1KCimPdUV9+H0kpg1TgYA@mail.gmail.com> <0100018f64a85d1c-f98eabaf-771e-473d-a1c3-40b8f9b51dc4-000000@email.amazonses.com> <0e02c89bdb8d445db0a3f83b30b01887@swisscom.com>
X-Mailer: Apple Mail (2.3774.400.31)
Feedback-ID: ::1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
X-SES-Outgoing: 2024.06.13-54.240.8.96
Message-ID-Hash: WAPV2ELSIUDCCS3BFNNR7MAIKTR3YI7C
X-Message-ID-Hash: WAPV2ELSIUDCCS3BFNNR7MAIKTR3YI7C
X-MailFrom: 0100019012301ba8-cbf266f3-b215-4454-879e-193606dfd926-000000@amazonses.watsen.net
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" <netconf@ietf.org>, pierre.francois@insa-lyon.fr
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/yO6OikSHb34Tcb5K_UjcLPIhFuA>
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>

Hi Thomas,

> On May 19, 2024, at 5:46 AM, Thomas.Graf@swisscom.com wrote:
> 
> Dear Kent,
>  
> Code I’ve written in the past manually-validates the envelope and then, separately, validates the payload via the YANG “notification” definition.
>  
> I would phrase "manually-validates" differently. I think you have excluded from validation because it can't be validated. That’s what we have seen during IETF 117 hackathon when using yanglint.

The word “manual” was out of place.   What I meant was that the code validates in two-steps: first the envelop is validated using generic schema, then the payload is validated using the specific schema.


> To my best knowledge there is no IETF document where this is written. Correct?

This is possibly true.  I know that there has been discussion, with regards to “anydata” statements, that the schema could be conveyed out of band, which seems similar...


> I find reading that YANG-Push is based on notifications in https://datatracker.ietf.org/doc/html/rfc8639#section-1.4 and notifications can be encoded in JSON according to https://www.rfc-editor.org/rfc/rfc7951#section-1 for an implementer rather misleading. Would you agree?

I don’t understand.  Can you say some more?  Also, what remediation do you have in mind?

Kent


> 
> Best wishes
> Thomas
>  
> From: Kent Watsen <kent+ietf@watsen.net> 
> Sent: Saturday, May 11, 2024 12:38 AM
> To: Andy Bierman <andy@yumaworks.com>
> Cc: Graf Thomas, INI-NET-VNC-HCS <Thomas.Graf@swisscom.com>; Per Andersson <per.ietf@ionio.se>; BOUCADAIR Mohamed IMT/OLN <mohamed.boucadair@orange.com>; netconf@ietf.org; Alex Huang Feng <alex.huang-feng@insa-lyon.fr>; Benoit Claise <benoit.claise@huawei.com>; pierre.francois@insa-lyon.fr
> Subject: Re: [netconf] Adoption call for notif-yang-04
>  
> Be aware: This is an external email.
>  
>  
> 
> 
> On May 10, 2024, at 1:43 PM, Andy Bierman <andy@yumaworks.com <mailto:andy@yumaworks.com>> wrote:
>  
> It is quite rigid and XML-specific:
>  
>    <notification>
>        <eventTime>...</eventTime>
>        < **event element**  />
>    </notification>
>  
> <snip/>
> YANG is incapable of representing this XSD correctly (no SubstitutionGroup).
>  
> True, not even an “anydata” helps.  If the goal is to be able to validate the entire “notification” message, I don’t see how that’s possible.   
>  
> Code I’ve written in the past manually-validates the envelope and then, separately, validates the payload via the YANG “notification” definition.
>  
> K.
>