Hi, I am still a little confused on the intent of the partial YANG validation. It seems trivial to adapt the NETCONF or RESTCONF validation points to I2RS. The only difference is that I2RS data can have constraints pointing at config=false nodes, so this is more complicated and expensive to implement than NETCONF or RESTCONF.
The argument for partial validation I have heard is "We only support 1 client and we know the client already checks the data, so we know the data is valid." This is not arguing that there will be invalid data in the datastore. It is arguing that the client can be trusted to be correct and bug-free so why bother spending server resources duplicating the validation. Typically in NM standards we assume more than 1 client is allowed in the design and a client cannot be trusted. A client could be malicious or buggy. Either way, if the server crashes or allows a security breach it's still the server vendor's fault. I2RS seems like an implementation detail (not a standard) if vendors plan on writing both client and server code and not intending to support any 3rd party implementations. Andy On Mon, Jun 6, 2016 at 4:25 PM, Susan Hares <[email protected]> wrote: > Andy: > > > > I’m not sure the context you are referring to as “I2RS agent pick which > Yang statements they will implement”. > > > > From the context, I guess you are investigating Ephemeral Configuration > State. If “the server MAY do YANG validation > > on the ephemeral datastore”, and then check it in operational state – this > clearly works. However, I’m struggling to fit the normal Ephemeral > Configuration State validation into section 8.3 of RFC6020bis. There are > three steps in constraint enforcement (section 8.3 of RFC6020bis). > > o during parsing of RPC payloads - > > o during processing of the <edit-config> operation > > o during validation > > > > Currently section 8.3.3 says: > > > > “8.3.3. Validation > > > > When datastore processing is complete, the final contents MUST obey > all validation constraints. This validation processing is performed at > differing times according to the datastore. > > > > If the datastore is "running" or "startup", these constraints MUST be > enforced at the end of the <edit-config> or <copy-config> operation. If > the datastore is "candidate", the constraint enforcement is delayed until a > <commit> > > or <validate> operation.” > > > > My understanding is we are discussing how constraint enforcement works in > Ephemeral Configuration State. > > You need to define where the ephemeral constraints MUST Be enforced. It > would seem reasonable to enforces at the end of <edit-config> or > <copy-config>, or by the end of an rpc operation defined in a data model. > > > > Since RESTCONF uses PUTS/PATCH within a HTTP exchange, then the constraint > enforcement must be at the end of that http operation. > > > > Sue > > > > > > > > *From:* i2rs [mailto:[email protected]] *On Behalf Of *Andy Bierman > *Sent:* Sunday, June 05, 2016 5:43 PM > *To:* [email protected] > *Subject:* [i2rs] YANG validation and opstate > > > > Hi, > > > > I don't really agree with idea that I2RS agents pick which > > YANG statements they will implement, but I think there is > > a way to handle this correctly in the datastore framework. > > > > The proposed enumeration for server validation > > capabilities (e.g., full, XPath, leafref) is not really needed. > > This enum is too course-grained to be useful. > > > > IMO it is better to say the server MAY do YANG validation > > on the ephemeral datastore. Whether or not the server uses > > data from the ephemeral datastore is left as an implementation detail. > > The server could use invalid input parameters or ignore them > > or reject them in the first place. > > > > The client needs to check operational state to know if/when the > > ephemeral data was applied to the system. > > > > > > > > Andy > > >
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
