Return-Path: <0100019201e55722-a8d6d559-f80a-4ef0-9fb4-bbeaff4cf4fb-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 F102CC151527 for ; Tue, 17 Sep 2024 14:31:05 -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_MSPIKE_H2=-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 kfVJIs4l3WHk for ; Tue, 17 Sep 2024 14:31:02 -0700 (PDT) Received: from a8-88.smtp-out.amazonses.com (a8-88.smtp-out.amazonses.com [54.240.8.88]) (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 E2771C151095 for ; Tue, 17 Sep 2024 14:31:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1726608660; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=LZHji7PRLwHdNTu5s0bM2wR2M3fooj2hlX/WwXzlqkE=; b=lXIjixCvTtZO32HYAwCNC9qUNqhp/eyWpquTojSaXSs5ARuVIJG6mhk6FaeV2Cj0 6A1XyXK0PAqE5wIR3mkThXRJfxCxwoM1rwkn5vkL+IiET3MV1u8WKkjKlbV/iOMdOXN 0UdtUY8sQrkGZSEruxGZgXPPmFx8QEW0A03K+RIk= From: Kent Watsen Message-ID: <0100019201e55722-a8d6d559-f80a-4ef0-9fb4-bbeaff4cf4fb-000000@email.amazonses.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_910616C3-E5C8-4610-B069-6D62C718CA4B" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.400.31\)) Date: Tue, 17 Sep 2024 21:31:00 +0000 In-Reply-To: To: Andy Bierman References: <01000191fc9ebeef-cf02c2a8-6818-4683-841d-ea41fe0b0d76-000000@email.amazonses.com> <01000192017932af-055438cd-14e1-4829-9b3a-8aa82ffa86ee-000000@email.amazonses.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.8.88 Message-ID-Hash: AP7M6HMVJ2FNKKWM2Z2562R4NBE75AYW X-Message-ID-Hash: AP7M6HMVJ2FNKKWM2Z2562R4NBE75AYW X-MailFrom: 0100019201e55722-a8d6d559-f80a-4ef0-9fb4-bbeaff4cf4fb-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: Parthasarathy.R@fujitsu.com, "netmod@ietf.org" X-Mailman-Version: 3.3.9rc4 Precedence: list Subject: =?utf-8?q?=5Bnetmod=5D_Re=3A_Regarding_RFC_7950_Mandatory_validation?= List-Id: NETMOD WG list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --Apple-Mail=_910616C3-E5C8-4610-B069-6D62C718CA4B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Andy, > IMO the RFCs are clear. >=20 > 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. >=20 > https://datatracker.ietf.org/doc/html/rfc6241#section-7.2 >=20 > The server applies the config to its internal datastore. > At that point the config contents are part of a configuration data = tree. >=20 >=20 > https://datatracker.ietf.org/doc/html/rfc7950#section-8 >=20 > 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=E2=80=99re right. Validation is context dependent. =20 K. > Andy >=20 >=20 >> K. >>=20 >>=20 >>> Thanks & Regards, >>> Partha. >>> =20 >>> From: Kent Watsen > >>> Sent: Tuesday, September 17, 2024 2:26 AM >>> To: R, Parthasarathy > >>> Cc: netmod@ietf.org >>> Subject: Re: [netmod] Regarding RFC 7950 Mandatory validation >>> =20 >>> Hi Partha, >>> =20 >>>=20 >>>=20 >>> On Sep 6, 2024, at 1:13=E2=80=AFPM, Parthasarathy.R@fujitsu.com = > = wrote: >>> =20 >>> Hi, >>> I am a Software Engineer working in Fujitsu=E2=80=99s = 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 =E2=80=98mandatory=E2=80=99 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=E2=80=99s operation type as = =E2=80=98create=E2=80=99 or =E2=80=98merge=E2=80=99 or =E2=80=98delete=E2=80= =99 in the validation section of RFC. >>> =20 >>> 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. >>> =20 >>> Kindly confirm which interpretation holds good. Also, I would like = to understand, if, =E2=80=98mandatory=E2=80=99 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. >>> =20 >>> =20 >>> It=E2=80=99s more the latter, but please note that YANG doesn=E2=80=99= t validate what is in a message over-the-wire, so much as the contents = of the datastore (as Andy mentioned) after the over-the-wire = message has been processed. =20 >>> =20 >>> PS: If using NMDA (RFC8342), then it=E2=80=99s the = datastore that is subject to validation. >>> =20 >>> K. >>> =20 >>> =20 >>>=20 >>>=20 >>> Kindly help to clarify. >>> =20 >>> Thanks & Regards, >>> Partha. >>> _______________________________________________ >>> netmod mailing list -- netmod@ietf.org >>> To unsubscribe send an email to netmod-leave@ietf.org = --Apple-Mail=_910616C3-E5C8-4610-B069-6D62C718CA4B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
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.


<= /div>
The server applies the config to its internal = datastore.
At that point the config contents are part of a = configuration data tree.



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=E2=80=99re = right.  Validation is context dependent.  

K.




Andy


K.
=


Thanks & = Regards,
Partha.
 
From: Kent Watsen <kent@watsen.net>
Sent: Tuesday, September 17, 2024 2:26 AM
To: R, = Parthasarathy <Parthasarathy.R@fujitsu.com>
Cc:&= nbsp;netmod@ietf.org
Subject: Re: [netmod] Regarding RFC 7950 Mandatory = validation
&n= bsp;
Hi = Partha,
&n= bsp;


<= u>
On Sep = 6, 2024, at 1:13=E2=80=AFPM, Parthasarathy.R@fujitsu.com<Parthasarathy.R=3D40fujitsu.com@dmarc.ietf.org> = wrote:
&n= bsp;
Hi,
     &= nbsp;      I am a Software Engineer working in = Fujitsu=E2=80=99s 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 =E2=80=98mandatory=E2=80=99 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=E2=80=99s operation type as =E2=80=98create=E2=80=99 or = =E2=80=98merge=E2=80=99 or =E2=80=98delete=E2=80=99 in the validation = section of RFC.
 
     &= nbsp;      This ends up in two different = interpretations:

1.   &n= bsp;  All edit-config requests must = always include the mandatory attributes irrespective of the operation = type is create/merge

2.   &n= bsp;  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, = =E2=80=98mandatory=E2=80=99 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.
&n= bsp;
&n= bsp;
It=E2=80=99= s more the latter, but please note that YANG doesn=E2=80=99t 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.  
&n= bsp;
PS: If = using NMDA (RFC8342), then it=E2=80=99s the <intended> datastore = that is subject to validation.
&n= bsp;
K.=
&n= bsp;
&n= bsp;


<= u>
     &= nbsp;      Kindly help to clarify.
 
Thanks & = Regards,
Partha.
______________= _________________________________
netmod mailing list = -- netmod@ietf.or= g
To = unsubscribe send an email to netmod-leave@i= etf.org
=


= --Apple-Mail=_910616C3-E5C8-4610-B069-6D62C718CA4B--