Re: [i2rs] FW: I-D Action: draft-ietf-i2rs-ephemeral-state-10.txt- 2 week WG LC (6/21 to 7/5/2016)

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

Martin: 

Thank you for the comments.  Please see the responses inline. 

One bit of background may help in Ephemeral-REQ-11 through Ephemeral-REQ-14.
While NETCONF/RESTCONF is specified in this version the ephemeral
requirements, other protocols may be included in the future (PROTOBUF, etc).
At that point, this document would be expanded to include these other
protocols. 

Summary:  Changes limited to /Yang/YANG/ change.  Other changes may occur
upon further details. 

Sue 


-----Original Message-----
From: i2rs [mailto:[e-mail]] On Behalf Of Martin Bjorklund
Sent: Wednesday, June 29, 2016 6:50 AM
To: [e-mail]
Subject: Re: [i2rs] FW: I-D Action: draft-ietf-i2rs-ephemeral-state-10.txt-
2 week WG LC (6/21 to 7/5/2016)

"Susan Hares" <[e-mail]> wrote:
> This begins a 2 WG LC last call on the text of 
> draft-ietf-i2rs-ephemeral-state-10.txt.

Hi,

I have reviewed draft-ietf-i2rs-ephemeral-state-11, and here are my
comments.


>o  Ephemeral-REQ-02
>
> I suggest you remove the text:
>
 >   it SHALL be considered a validation error if it does.
>
 > The requirement is clear as it is without this.  And maybe the
>   solution will make sure it is not even syntactially possible to
 >  define such constraints.

Sue: Since the I2RS debate requested this be added for clarity and 
 you have stated the requirement is clear - it will be left in the
requirements. 
It would be wonderful if the solution prevented this syntax. 

Summary: No change here 

>o  Ephemeral-REQ-03
>
 > I think you need to define what you mean with "constraint".  For
  > normal config, YANG has very detailed rules about when constraints
 >are checked and what a server MUST do when a constraint becomes
  > false.

 >  Since this requirement says that constraints can refer to fast
 > changing state, you need to say what should happen if such a
  > constraint suddenly becomes false due.

For the I2RS state which is ephemeral configuration state, the 
constraints may have all of 8.3 in yang 1.1 or part of the yang 1.1
constraint. 
The final definition of the ephemeral configuration state
depends on the design of operational state modules. 
Every effort we have made to tie this down has resulted in cycles of 
unproductive discussion.  Therefore, this portion will not be re-opened. 

For operational state listed in ephemeral constraints going quickly from
TRUE to FALSE, please note that an event notification will be sent to the 
I2RS Client.   See the event-notification draft for specifics. 

Summary: No change here. 

> o  Ephemeral-REQ-04
>  The requirement says that ephemeral state can refer to
> non-ephemeral state in constraints.  Does the term "non-ephemeral
> state" include configuration?  If so, does this mean that if an
> operator tries to delete some config, the existance of some
>  ephemeral state may reject the config change request?

Sue: Please refer to the sentence in the top of this section: 
  In requirements Ephemeral-REQ-01 to Ephemeral-05, Ephemeral state is
   defined as potentially including both ephemeral configured state and
   operational state.

Non-ephemeral state can be configuration or operational state (e.g. MPLS
LSP-ID
or BGP RIB).    

If the operator deletes some "local configuration" (in I2RS terms), and the
I2RS 
Ephemeral state depends on the local configuration - the I2RS agent will 
Provide a notification that the ephemeral configuration state or the 
Operational state defined in an ephemeral model is no longer valid.  
The I2RS client must handle this one. 

Summary: No change 


o  Ephemeral-REQ-07

 >This requirement says:
>
>    "Implementations MUST provide a mechanism..."
>
>  Does this mean that this mechanism should not be standardized;
> rather implementations are required to invent some vendor-specific
> mechanism?

Sue:  Previous netconf/netmod reviewers have cautioned the I2RS WG on
defining a solutions.  If the NETCONF/NETMOD does not 
define a solution - then the implementation should provide a solution. 
Of course, a standardized solution would be preferred. 

>o  Ephemeral-REQ-08
>
 > I understand "ephemeral" and "read/write".  But what does
 > "status/configuration" mean in this context?  Can I have
 >  "ephemeral, read-only, configuration"?  Can I have
 > "ephemeral, write, status"?
>
> Ephemeral-REQ-08: Yang MUST have a way to indicate in a data model
> that schema nodes have the following properties: ephemeral, writable/
>  not-writable, and status/configuration.

Here we are indicating that Ephemeral state may be Ephemeral configuration
state or 
Operational state.  Every time we have not used "ephemeral", "read/write", 
"status/configuration"  - we have bumped into someone's operational data
model. 
Unless the netmod group has a finalized version of operational state, it
will 
Remain this way. 

o  Ephemeral-REQ-09

>   This requirement is fine, but why is it labeled *changes* to
> NETCONF?  NETCONF already supports this requirement.

Do you really support the following: 

   1.  Support for communication mechanisms to enable an I2RS client to
       determine that an I2RS agent supports the mechanisms needed for
     I2RS operation.

   2.  The ephemeral state must support notification of write conflicts
      using the priority requirements defined in section 7 below in
      requirements Ephemeral-REQ-11 through Ephemeral-REQ-14).

This is not what other netconf/netmod people have indicated. 

Summary: Need response on -09 and -10 before changing.

>o  Ephemeral-REQ-10
>
>   This requirement is fine, but why is it labeled *changes* to
> RESTCONF?  RESTCONF already supports this requirement.

Are you really sure you support priority requirements as 
specified in items Ephemeral-REQ-11 through Ephemeral-REQ-14? 
Not what other people have said.  Does not hurt if you do? 

Summary: Need response on -09 and -10 before changing. 

>o  Ephemeral-REQ-13
>
 >  I do not understand what this requirement means.
>
>   (BTW, the text should be rephrased; it now says "the requirement
> ... is required ...")

   Ephemeral-REQ-13: The requirement to support multi-headed control is
   required for collisions and the priority resolution of collisions.
   Multi-headed control is not tied to ephemeral state.  I2RS is not
   mandating how AAA supports priority.  Mechanisms which prevent
   collisions of two clients trying the same node of data are the focus.

I believe this text refines the requirement to support multi-headed control
to only be required for collisions and priority resolution of collisions. 
Perhaps you understood the English in a different manner. 

This text is terse, and assumes you understand the I2RS architecture. 
Rather than repeat that text here, perhaps you will review it and see if you
then understand this text. 
We have been terse based on feedback from netconf/netmod reviewers. 

>o  Ephemeral-REQ-14
>
> If this is not a new requirement, does it need to be part of this
>  document?
> If the answer is yes, are there other things from the architecture
> document that should be listed here, e.g., details about priority
>  interaction w/ local config?

Again, we were cautioned in our early discussions not to define the solution
or to assume a solution in I2RS requirements. 

Summary: No change 

>o  Ephemeral-REQ-15
> I do not understand what this requirement means.

Example: 

I2RS client                I2RS Agent 
===========          =============
Message 0 [query to see if eth0 is up] 
                                 [response eth0 is up ] 
Message 1 [install I2RS Static route associated with eth0 ]  
Message 2 [install BGP I2RS route dependent on I2RS static route]
                                [Message 1-reply success]
                                [Message 2-reply success]

Message 1 and Message 2 are individual actions but linked.  However, 
Message 2 will not work if the I2RS static route has not be installed. 

I2RS does not include roll-back or atomicity of Message 1 and Message 2. 
It requires that the I2RS client know the status of each action. 

None of these multiple message sequences should allow the 
I2RS agent to insert errors into the Ephemeral Configuration state or 
Ephemeral operational state. 

Does this example help? 

Summary: No changes 

o  general

   s/Yang/YANG/g

Thank you - I will change this after other revisions have been suggested. 


/martin

_______________________________________________
i2rs mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/i2rs