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

[Martin Bjorklund <[e-mail]>]

Hi,

Comments inline.


"Susan Hares" <[e-mail]> wrote:
> 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. 

This explanation helps to understand this requirement.  You obviously
have some ideas what "constraint" means, and that it means different
things for config and state.  This should go into the document, but
see below.

> Every effort we have made to tie this down has resulted in cycles of 
> unproductive discussion.  Therefore, this portion will not be re-opened. 

If you specify a requirement, isn't it fair to expect that the
requirement is clear and well-understood?  Since the requirement is
there, you obvsiously have some *behavior* in mind (I am not talking
about a solution).  Just stating that "ephemeral state may have
constraints" w/o a definition of what 'constraint' means doesn't help
much.

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

Which draft do you mean?

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

I am well aware of this definition.

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

I suggest this is made explicit in the document; it is not clear from
the current defintion.

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

Again, this explanation really helps!  It should go into the
document.  OR, if this is explained in another document, a pointer to
that text would be great.

Clarifacation question: does this mean that the ephemeral state in
question is removed and a notification is sent, or that the ephemeral
state is still present, but not used, and a notification is sent?


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

I agree that this document shouldn't specify a solution.  This
document's role is to define requirements for a solution (not for
implementations).  Maybe simply:

OLD:

   Implementations MUST provide a mechanism to choose which takes
   precedence.

NEW:

   It MUST be possible to choose which takes precedence.


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

I understand that.

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

This doesn't make any sense to me.  This is a requirement to YANG, and
I do not understand how to interpret this requirement.  My questions
were simple:

  Can I have "ephemeral, read-only, configuration"?  Can I have
  "ephemeral, write, status"?

If we don't understand the requirement, it will be difficult to
propose a solution.  All I'm asking for is clarification of the
requirement.

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

Sure, by using std YANG features and/or protocol capabilities.

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

NETCONF the protocol supports notifications; it is not involved in the
semantics for when/how these notifications are generated.

I think this requirement probably should not be directed to NETCONF.

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

If I'm not mistaken, Andy said the same thing re capabilities.

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

See above.

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

Ok, this makes it clearer.  Maybe you can do:

OLD:

  The requirement to support multi-headed control is
  required for collisions and the priority resolution of collisions.

NEW:

 Multi-headed control is required for collisions and the 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. 

Terse is fine, as long as it is clear.  Pointers to other documents
are also fine, they help the readers to understand what you had in
mind.


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

Actually, you *did* change this in -12, to the better!


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

Well, I think that this follows from the requirements on
'constraints', so this requirement is at best redundant.

The text is also not very clear.  For example it talks about "not
insert errors".  What is an "error" that could be inserted?  What you
probably mean is that all constraints MUST be true.


/martin




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