[netmod] Re: Regarding RFC 7950 Mandatory validation
Kent Watsen <kent@watsen.net> Tue, 17 September 2024 19:32 UTC
Return-Path: <01000192017932af-055438cd-14e1-4829-9b3a-8aa82ffa86ee-000000@amazonses.watsen.net>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF2C6C151097 for <netmod@ietfa.amsl.com>; Tue, 17 Sep 2024 12:32:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 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_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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] 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 J0t4EQ4cKyNG for <netmod@ietfa.amsl.com>; Tue, 17 Sep 2024 12:32:54 -0700 (PDT)
Received: from a48-90.smtp-out.amazonses.com (a48-90.smtp-out.amazonses.com [54.240.48.90]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 212E9C14F6BC for <netmod@ietf.org>; Tue, 17 Sep 2024 12:32:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1726601573; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=dsGBm0ZUKeUduSsSnZxjLMk46AhjKpbzIlIFcCQav5E=; b=elvVE+MnB4BeekYkOxCiYT2aMtUMonts2WMRMjPrq6yb8xzOzl75WY0nhyxM6mmj fVdrLhVIdJWPQNYz7RiTDZcysUFoWC03ZQkydoWSvFQvNOk4i1OZqZ4BUs18NScBV9m I5Gxc5McQLyQYh35DGfs1ziMuXXwBoCL0ldJMokw=
From: Kent Watsen <kent@watsen.net>
Message-ID: <01000192017932af-055438cd-14e1-4829-9b3a-8aa82ffa86ee-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_CA2091DC-5FA5-4C3B-B540-82829040DA10"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\))
Date: Tue, 17 Sep 2024 19:32:53 +0000
In-Reply-To: <OS3PR01MB584892B40019F7875D146379F1612@OS3PR01MB5848.jpnprd01.prod.outlook.com>
To: Parthasarathy.R@fujitsu.com
References: <OS3PR01MB5848ECB03174DF2A56B8B81BF19E2@OS3PR01MB5848.jpnprd01.prod.outlook.com> <01000191fc9ebeef-cf02c2a8-6818-4683-841d-ea41fe0b0d76-000000@email.amazonses.com> <OS3PR01MB584892B40019F7875D146379F1612@OS3PR01MB5848.jpnprd01.prod.outlook.com>
X-Mailer: Apple Mail (2.3774.400.31)
Feedback-ID: ::1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
X-SES-Outgoing: 2024.09.17-54.240.48.90
Message-ID-Hash: Z2HYXLZZ27CTQHD4F4XLES4I3RDT5VWA
X-Message-ID-Hash: Z2HYXLZZ27CTQHD4F4XLES4I3RDT5VWA
X-MailFrom: 01000192017932af-055438cd-14e1-4829-9b3a-8aa82ffa86ee-000000@amazonses.watsen.net
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-netmod.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: "netmod@ietf.org" <netmod@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [netmod] Re: Regarding RFC 7950 Mandatory validation
List-Id: NETMOD WG list <netmod.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/WfrBVLFFXbBWPGM_Vqb9saDVVOw>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Owner: <mailto:netmod-owner@ietf.org>
List-Post: <mailto:netmod@ietf.org>
List-Subscribe: <mailto:netmod-join@ietf.org>
List-Unsubscribe: <mailto:netmod-leave@ietf.org>
Hi Partha, > On Sep 17, 2024, at 3:33 AM, Parthasarathy.R@fujitsu.com wrote: > > Hi Andy and Kent, > Thanks a lot for your emails. Great. > > One clarification: > The RFC section 8.3.1 mentioning Payload Parsing is more of a validation over-the-wire, isn’t it? > > “When content arrives in RPC payloads, it MUST be well-formed XML, > following the hierarchy and content rules defined by the set of > models the server implements. > o If a leaf data value does not match the type constraints for the > leaf, including those defined in the type’s "range", "length", and > "pattern" properties, the server MUST reply with an > "invalid-value" <error-tag> in the <rpc-error>, and with the > error-app-tag (Section 7.5.4.2) and error-message > (Section 7.5.4.1) associated with the constraint, if any exist.” Try not to read this to mean that the over-the-wire message is fully-validated directly. Yes, the over-the-wire message must be valid XML but, beyond that, all implementations I’m aware of "validate the over-the-wire message" by 1) processing it to update a version of <running>and 2) validating the resulting version of <running>. > On a quicker look, for a leaf, the length, range etc can be easily deduced from the Yang schema without involving Datastore. The same way, I interpreted ‘mandatory’ check too can be done just with Yang schema without involving Datastore. The check is mandatory, but it happens indirectly via checking the updated <running> or <intended>, if implementing NMDA (RFC8342). > Somehow, I feel, the thing, ‘mandatory is mandatory only for create request and it is not for merge request’ is not explicitly mentioned in RFC based on operation-type (be it create/merge). Yes, you make a point, such nodes exist in the request message 99% of the time, but it is possible that they may alternatively be set via <system> defined configuration, or via a template. K. > Thanks & Regards, > Partha. > > From: Kent Watsen <kent@watsen.net <mailto:kent@watsen.net>> > Sent: Tuesday, September 17, 2024 2:26 AM > To: R, Parthasarathy <Parthasarathy.R@fujitsu.com <mailto:Parthasarathy.R@fujitsu.com>> > Cc: netmod@ietf.org <mailto:netmod@ietf.org> > Subject: Re: [netmod] Regarding RFC 7950 Mandatory validation > > Hi Partha, > > > > On Sep 6, 2024, at 1:13 PM, Parthasarathy.R@fujitsu.com <mailto:Parthasarathy.R@fujitsu.com><Parthasarathy.R=40fujitsu.com@dmarc.ietf.org <mailto:Parthasarathy.R=40fujitsu.com@dmarc.ietf.org>> wrote: > > Hi, > I am a Software Engineer working in Fujitsu’s NMS product supporting Netconf devices. I want a clarification in RFC 7950 on the behavior of constraint validation in an edit-config request enforced by ‘mandatory’ statement. I referred to section 8 in RFC 7950 regarding this and from what I see, all edit-config requests should include the mandatory leafs. There is no special behavior mentioned on edit-config’s operation type as ‘create’ or ‘merge’ or ‘delete’ in the validation section of RFC. > > This ends up in two different interpretations: > 1. All edit-config requests must always include the mandatory attributes irrespective of the operation type is create/merge > 2. Edit-config requests must include the mandatory attributes only if operation type is create and it can choose to skip if the attribute is already present in Datastore due to previous edit-configs. > > Kindly confirm which interpretation holds good. Also, I would like to understand, if, ‘mandatory’ check applies to the payload during Payload Parsing stage (mentioned in section 8.3.1 of RFC 7950) for every edit config and that all edit config operations must include the mandatory attributes into the payload, even if the operation is merge and the mandatory attribute exists in the candidate store. > > > It’s more the latter, but please note that YANG doesn’t validate what is in a message over-the-wire, so much as the contents of the <running> datastore (as Andy mentioned) after the over-the-wire message has been processed. > > PS: If using NMDA (RFC8342), then it’s the <intended> datastore that is subject to validation. > > K. > > > > > Kindly help to clarify. > > Thanks & Regards, > Partha. > _______________________________________________ > netmod mailing list -- netmod@ietf.org <mailto:netmod@ietf.org> > To unsubscribe send an email to netmod-leave@ietf.org <mailto:netmod-leave@ietf.org>
- [netmod] Re: Regarding RFC 7950 Mandatory validat… Kent Watsen
- [netmod] Regarding RFC 7950 Mandatory validation Parthasarathy.R@fujitsu.com
- [netmod] Re: Regarding RFC 7950 Mandatory validat… Andy Bierman
- [netmod] Re: Regarding RFC 7950 Mandatory validat… Kent Watsen
- [netmod] Re: Regarding RFC 7950 Mandatory validat… Andy Bierman
- [netmod] Re: Regarding RFC 7950 Mandatory validat… Kent Watsen
- [netmod] Re: Regarding RFC 7950 Mandatory validat… Kent Watsen
- [netmod] Re: Regarding RFC 7950 Mandatory validat… Andy Bierman