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