[netmod] Re: Regarding RFC 7950 Mandatory validation
Kent Watsen <kent@watsen.net> Wed, 18 September 2024 14:25 UTC
Return-Path: <0100019205863e29-f3c98bb7-a37d-4b69-9366-201ea87c3cec-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 0C7FCC1D620D for <netmod@ietfa.amsl.com>; Wed, 18 Sep 2024 07:25:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.903
X-Spam-Level:
X-Spam-Status: No, score=-6.903 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_HI=-5, RCVD_IN_MSPIKE_H4=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, 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 9c0dV2H4W3AQ for <netmod@ietfa.amsl.com>; Wed, 18 Sep 2024 07:25:38 -0700 (PDT)
Received: from a48-94.smtp-out.amazonses.com (a48-94.smtp-out.amazonses.com [54.240.48.94]) (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 E053FC1D6FC3 for <netmod@ietf.org>; Wed, 18 Sep 2024 07:25:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1726669537; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=YTGWAiktpbHuX5v+Nht8IGfz6Uk2vrxy4QWPwaimkdY=; b=atarkxCeJwRZeJ4utGgHuHJmb52Kvcatu1tSw3idsp0BUSvHllxOYOlOEryw9y4V E8riuGAlJkFnbASs6596M1XEXsFMKORF4eG/sAivF+UMmI/J+b1QnwAZwl64Y6Qg0Dw Y8+vOYkZidxGkWTzmuIO2nZ2drN9g1r/iQAHsuVA=
From: Kent Watsen <kent@watsen.net>
Message-ID: <0100019205863e29-f3c98bb7-a37d-4b69-9366-201ea87c3cec-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_1E3F79BB-F78F-452E-9994-68068B9FD26D"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\))
Date: Wed, 18 Sep 2024 14:25:36 +0000
In-Reply-To: <OS3PR01MB5848E5599EBDE02D4C1D9168F1622@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> <01000192017932af-055438cd-14e1-4829-9b3a-8aa82ffa86ee-000000@email.amazonses.com> <CABCOCHR-Fu=+h19kzqJeC91hoWNEoifdfhENK-RKwF8RfFwrNQ@mail.gmail.com> <0100019201e55722-a8d6d559-f80a-4ef0-9fb4-bbeaff4cf4fb-000000@email.amazonses.com> <OS3PR01MB5848E5599EBDE02D4C1D9168F1622@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.18-54.240.48.94
Message-ID-Hash: MM6TOUJKETVPXJ6CHPFOT6G7DEB7UBYT
X-Message-ID-Hash: MM6TOUJKETVPXJ6CHPFOT6G7DEB7UBYT
X-MailFrom: 0100019205863e29-f3c98bb7-a37d-4b69-9366-201ea87c3cec-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/PM_1Mw04U1e7vir5EaOWR_rdSqg>
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, Your original question was mostly about <edit-config> and a little about rpc/action statements (i.e., the ref to Section 8.3.1). In any case, here are some more relevant excerpts: From Section 3 (Terminology): o mandatory node: A mandatory node is one of: * A leaf, choice, anydata, or anyxml node with a "mandatory" statement with the value "true". * A list or leaf-list node with a "min-elements" statement with a value greater than zero. * A container node without a "presence" statement and that has at least one mandatory node as a child. From Section 8.1 (Constraints on Data): o If the constraint is defined on configuration data, it MUST be true in a valid configuration data tree. o If the constraint is defined on RPC or action input parameters, it MUST be true in an invocation of the RPC or action operation. From Section 8.3 (NETCONF Constraint Enforcement Model): For configuration data, there are three windows when constraints MUST be enforced: o during parsing of RPC payloads o during processing of the <edit-config> operation o during validation From Section 7.14.2 (The "input” Statement): If a leaf in the input tree has a "mandatory" statement with the value "true", the leaf MUST be present in an RPC invocation. From Section 6.4.1 (XPath Context) o If the XPath expression is defined in a substatement to a data node that represents configuration, the accessible tree is the data in the datastore where the context node exists. The root node has all top-level configuration data nodes in all modules as children. o If the XPath expression is defined in a substatement to an "input" statement in an "rpc" or "action" statement, the accessible tree is the RPC or action operation instance, all state data in the server, and the running configuration datastore. The root node has top-level data nodes in all modules as children. Additionally, for an RPC, the root node also has the node representing the RPC operation being defined as a child. The node representing the operation being defined has the operation's input parameters as children. Hope that helps! Kent > On Sep 18, 2024, at 7:09 AM, Parthasarathy.R@fujitsu.com wrote: > > Hi Kent and Andy, > Thanks again for your emails. I am kind of confused on Kent’s reply now. > > “The 'edit-config' RPC input parameters have some constraints like mandatory parameters. > The 'config' payload constraints are not part of the RPC input parameter validation. > Only constraints defined on the RPC input parameters are checked here.“ > Does it mean, whatever mentioned in 8.3.1 of RFC 7950 are only applicable to RPC input and not applicable for <config> payload? All the points apply to config payload as well, isn’t it? When we have the yang and the input payload (assuming a create edit-config request), we can directly check if mandatory attribute is missing and report error during the payload parsing itself, instead of doing that in ‘processing’ and ‘validation’. It is a fail-fast implementation. I was thinking, that as the reason, RFC lists down various validations as part of Payload Parsing. > > From Andy’s reply below: > “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>.“ > I understand, all current implementations are not failing fast, and they always check the constraints (including the leaf’s ‘mandatory’) during ‘processing’ and ‘validation’ and not during ‘payload parsing’. This dilutes the purpose of a separate ‘Payload Parsing’ section at all in RFC, when everything is going to be done on ‘processing’/’validation’ > > In my humble opinion, we have to include a clause in ‘Payload Parsing’ section of RFC, mentioning, “If all mandatory leafs are not present, when the edit-config operation is ‘create’, then the server MUST reply with a "missing-element" <error-tag> in the <rpc-error>.”. This is only applicable for a create operation and not applicable for a merge or replace operation. > > Regards, > Partha. > > From: Kent Watsen <kent@watsen.net> > Sent: Wednesday, September 18, 2024 3:01 AM > To: Andy Bierman <andy@yumaworks.com> > Cc: R, Parthasarathy <Parthasarathy.R@fujitsu.com>; netmod@ietf.org > Subject: Re: [netmod] Regarding RFC 7950 Mandatory validation > > Hi Andy, > > > IMO the RFCs are clear. > > The 'edit-config' RPC input parameters have some constraints like mandatory parameters. > The 'config' payload constraints are not part of the RPC input parameter validation. > Only constraints defined on the RPC input parameters are checked here. > > https://datatracker.ietf.org/doc/html/rfc6241#section-7.2 > > The server applies the config to its internal datastore. > At that point the config contents are part of a configuration data tree. > > > https://datatracker.ietf.org/doc/html/rfc7950#section-8 > > o If the constraint is defined on configuration data, it MUST be > true in a valid configuration data tree. > ... > o If the constraint is defined on RPC or action input parameters, it > MUST be true in an invocation of the RPC or action operation. > > > You’re right. Validation is context dependent. > > K. > > > > > > Andy > > > 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