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

Reply via email to