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, [email protected] 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 <[email protected]>
> Sent: Wednesday, September 18, 2024 3:01 AM
> To: Andy Bierman <[email protected]>
> Cc: R, Parthasarathy <[email protected]>; [email protected]
> 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 <[email protected] <mailto:[email protected]>>
> Sent: Tuesday, September 17, 2024 2:26 AM
> To: R, Parthasarathy <[email protected]
> <mailto:[email protected]>>
> Cc: [email protected] <mailto:[email protected]>
> Subject: Re: [netmod] Regarding RFC 7950 Mandatory validation
>
> Hi Partha,
>
>
>
> On Sep 6, 2024, at 1:13 PM, [email protected]
> <mailto:[email protected]><[email protected]
> <mailto:[email protected]>> 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 -- [email protected] <mailto:[email protected]>
> To unsubscribe send an email to [email protected]
> <mailto:[email protected]>
>
>
_______________________________________________
netmod mailing list -- [email protected]
To unsubscribe send an email to [email protected]
