[netmod] Re: Regarding RFC 7950 Mandatory validation

[Andy Bierman <[e-mail]>]

On Tue, Sep 17, 2024 at 12:32 PM Kent Watsen <[e-mail]> wrote:

> Hi Partha,
>
> On Sep 17, 2024, at 3:33 AM, [e-mail] 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.
>
>


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.


Andy



K.
>
>
> Thanks & Regards,
> Partha.
>
> *From:* Kent Watsen <[e-mail]>
> *Sent:* Tuesday, September 17, 2024 2:26 AM
> *To:* R, Parthasarathy <[e-mail]>
> *Cc:* [e-mail]
> *Subject:* Re: [netmod] Regarding RFC 7950 Mandatory validation
>
> Hi Partha,
>
>
>
> On Sep 6, 2024, at 1:13 PM, [e-mail]<
> Parthasarathy.R=[e-mail]> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
>
>