On Mon, Jun 6, 2016 at 5:46 PM, Joel M. Halpern <[email protected]> wrote:
> When we started on the I2RS work, the explicit request from the operators > was to make this as simple as practical and as efficient as practical. > > In regard to constraints on what they could do, the specific request was > "let us shoot ourselves in the foot." That is, if some change will break > the network, so be it. it is the operators problem. If the change only > causes the box to reboot, that is less dangerous. So it seems to fall > within "let me shoot my foot." > > I expect that there are some forms of validation that need to take place > just to attempt to apply the RPC. But everything beyond that was requested > to be not performed. Whether we can actually achieve that is a different > question. > It does strike me that we can also go back and ask the operators again > what they meant, if you think it is likely we misunderstood. > > In my example "when IPv4" is ignored so IPv6 parameters are accepted as valid. Does this mean the server faithfully applies the wrong parameters that make no sense whatsoever? Probably not. It means the client developer and operator have no idea what a server implementation is SUPPOSED to accept as a valid edit. (Which diminishes the standards value of I2RS) My original point was that extra flags for I2RS like "I ignore all leafrefs" are worthless. It is better to declare that validation is not part of the ephemeral datastore. It is an implementation detail whether accepted data in that datastore ever gets used. Yours, > Joel > Andy > > On 6/6/16 8:26 PM, Andy Bierman wrote: > >> 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] >> <mailto:[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] >> <mailto:[email protected]>] *On Behalf Of *Andy Bierman >> *Sent:* Sunday, June 05, 2016 5:43 PM >> *To:* [email protected] <mailto:[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 >> >>
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
