On Mon, Jun 6, 2016 at 6:04 PM, Joel M. Halpern <[email protected]> wrote:
> I think that works for me. > > What I read you as saying is that we could simply define that any and all > validation of I2RS operations is a local matter and up to the server. > > This would remove any need for flags or marking, and also remove any need > for indicating a mode of operation. > > If that is what you meant, it works for me. > I think clue-full client developers will understand how this will assist their foot-shooting efforts. YANG already has the deviation-stmt so the server can say "I ignore this leafref and that must-stmt". Yours, > Joel > > Andy > On 6/6/16 9:01 PM, Andy Bierman wrote: > >> >> >> On Mon, Jun 6, 2016 at 5:46 PM, Joel M. Halpern <[email protected] >> <mailto:[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]> >> <mailto:[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]> >> <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]> >> <mailto:[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] <mailto:[email protected]> >> https://www.ietf.org/mailman/listinfo/i2rs >> >> >>
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
