[netmod] Re: Regarding RFC 7950 Mandatory validation

[Andy Bierman <[e-mail]>]

On Wed, Sep 18, 2024 at 4:10 AM [e-mail] <
[e-mail]> 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.
>


The Payload parsing refers to the RPC input parameters defined in the
edit-config operation.
There are 2 such constraints in this operation:

- mandatory choice config-target
- mandatory choice edit-content

The config parameter is not a representation of a datastore and not subject
to datastore validation
as part of the payload parsing.

Also, the <candidate> can be changed with many edit-config steps.
The combined result is only required to be valid when the <commit> applies
the changes to <running>.



>
>
> Regards,
>
> Partha.
>


Andy


>
>
> *From:* Kent Watsen <[e-mail]>
> *Sent:* Wednesday, September 18, 2024 3:01 AM
> *To:* Andy Bierman <[e-mail]>
> *Cc:* R, Parthasarathy <[e-mail]>; [e-mail]
> *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 <[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]
>
>
>
>
>