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