Re: [i2rs] Ephemeral State Requirements discussion

["Susan Hares" <[e-mail]>]

Juergen: 

Thank you for the pointer,  I am assuming you are referring to section 8.3
on constraint enforcement (from RFC6020bis), and as a part of constraint
enforcement, the validation.  

I2RS ephemeral requirements 1-4 are: 
   Ephemeral-REQ-01: I2RS requires ephemeral configuration state; i.e. state
that does not persist
    across reboots. If state must be restored, it should be done solely
    by replay actions from the I2RS client via the I2RS agent.

   Ephemeral-REQ-02: Non-ephemeral state MUST NOT refer to  ephemeral state
for constraint purposes; 
   it SHALL be considered a validation error if it does.
   Ephemeral-REQ-03: Ephemeral state must be able to utilized temporary
operational state 
    (e.g. MPLS LSP-ID or a BGP IN-RIB) as a constraints. 
   Ephemeral-REQ-04: Ephemeral state MAY refer to non-ephemeral state 
   for purposes of implementing constraints.

I2RS uses the definition you do of constraint and validation.  For
discussion purposes, let us consider  "ephemeral state" in these
requirements as "ephemeral configuration state".   

What needs to be expanded for Ephemeral Configuration State is the second
paragraph of section 8.3.3 to include ephemeral state.  In the end, the
ephemeral configuration parsing of rpc payloads, <edit-config>, and
validation MUST obey all validation constraints.  What we are discussing is
"when" and "how" the I2RS constraint enforcement occurs, and "when" and
"how" validation occurs.   

Sue 
  

================
For reference of I2RS list

8.3.  NETCONF Constraint Enforcement Model

   For configuration data, there are three windows when constraints MUST
   be enforced:
   o  during parsing of RPC payloads - 
   o  during processing of the <edit-config> operation
   o  during validation
   Each of these scenarios is considered in the following sections.


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.



-----Original Message-----
From: Juergen Schoenwaelder [mailto:[e-mail]] 
Sent: Monday, June 06, 2016 4:04 PM
To: Susan Hares
Cc: 'Jeffrey Haas'; [e-mail]; 'Joel M. Halpern'
Subject: Re: [i2rs] Ephemeral State Requirements discussion

On Mon, Jun 06, 2016 at 03:07:13PM -0400, Susan Hares wrote:
> Juergen: 
> 
> Please start by defining validation for NETCONF configuration.  Then, 
> we can provide the additions for ephemeral configuration state that 
> are not in ephemeral requirements.  See the rest of the comments below.
>

The validation of NETCONF configurations modelled in YANG 1.0 is defined in
RFC 6020 and for configurations modelled in YANG 1.1 it is defined in
draft-ietf-netmod-rfc6020bis-12.

/js

PS: Our communication is not effective, I drop out for now.

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <http://www.jacobs-university.de/>