Subject: [i2rs] YANG validation and opstate

From: Andy Bierman <[email-masked]>
Date: Sun, 5 Jun 2016 14:42:30 -0700

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

---

From: Nadeau Thomas <[email-masked]>
Date: Mon, 6 Jun 2016 07:18:52 -0400

I personally like it, and will refer people to the wiki.  Its far quicker/easier than finding a random RFC. 
One suggestion might be to make the parts that do overlap, refer back to the RFC from the wiki in order to
keep the document more dynamic in case there are errata changes in the future and to keep from
having to maintain 2 copies of the same information.

	—Tom

> On Jun 5, 2016:5:42 PM, at 5:42 PM, Andy Bierman <[email-masked]> wrote:
> 
> Hi,
> 
> _______________________________________________
> i2rs mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2rs

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 6 Jun 2016 19:25:04 -0400

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-masked]] On Behalf Of Andy Bierman
Sent: Sunday, June 05, 2016 5:43 PM
To: [email-masked]
Subject: [i2rs] YANG validation and opstate

Hi,

 

Andy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 6 Jun 2016 17:26:04 -0700

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-masked]> wrote:

> 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).
>
>    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>
>
> 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-masked]] *On Behalf Of *Andy Bierman
> *Sent:* Sunday, June 05, 2016 5:43 PM
> *To:* [email-masked]
> *Subject:* [i2rs] YANG validation and opstate
>
>
>
> Hi,
>
>
>

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 6 Jun 2016 20:46:19 -0400

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.

Yours,
Joel

On 6/6/16 8:26 PM, Andy Bierman wrote:
> This is not arguing that there will be invalid data in the datastore.
> It is arguing
> On Mon, Jun 6, 2016 at 4:25 PM, Susan Hares <[email-masked]
> <mailto:[email-masked]>> 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-masked]
>     <mailto:[email-masked]>] *On Behalf Of *Andy Bierman
>     *To:* [email-masked] <mailto:[email-masked]>
>     *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____
>
>     __ __
>
>
>
>

---

From: Andy Bierman <[email-masked]>
Date: Mon, 6 Jun 2016 18:01:23 -0700

On Mon, Jun 6, 2016 at 5:46 PM, Joel M. Halpern <[email-masked]> 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.
>
> "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."
>
> 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.
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,

Andy

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 6 Jun 2016 21:04:24 -0400

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 <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     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.
>
>
>         <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>
>             Andy: ____
>
>             __ __
>
>         <mailto:[email-masked]>
>             <mailto:[email-masked]
>         <mailto:[email-masked]>>] *On Behalf Of *Andy Bierman
>         <mailto:[email-masked] <mailto:[email-masked]>>
>         [email-masked] <mailto:[email-masked]>

---

From: Andy Bierman <[email-masked]>
Date: Mon, 6 Jun 2016 18:38:01 -0700

On Mon, Jun 6, 2016 at 6:04 PM, Joel M. Halpern <[email-masked]> wrote:

> 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.
>

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,

Andy