Re: [i2rs] YANG validation and opstate

["Joel M. Halpern" <[e-mail]>]

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.
Yours,
Joel

On 6/6/16 9:01 PM, Andy Bierman wrote:
>
>
> On Mon, Jun 6, 2016 at 5:46 PM, Joel M. Halpern <[e-mail]
> <mailto:[e-mail]>> 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 <[e-mail]
>         <mailto:[e-mail]>
>         <mailto:[e-mail] <mailto:[e-mail]>>> 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:[e-mail]
>         <mailto:[e-mail]>
>             <mailto:[e-mail]
>         <mailto:[e-mail]>>] *On Behalf Of *Andy Bierman
>             *Sent:* Sunday, June 05, 2016 5:43 PM
>             *To:* [e-mail] <mailto:[e-mail]>
>         <mailto:[e-mail] <mailto:[e-mail]>>
>             *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
>         [e-mail] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/i2rs
>
>