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

"Susan Hares" <[e-mail]> wrote:
> Martin: 
> 
> Pulling up some response up-front to highlight them.  These response are
> also in the text below. 

Trimming a bit, and replying inline.

> -----Original Message-----
> From: Martin Bjorklund [mailto:[e-mail]] 
> Sent: Friday, July 1, 2016 6:45 AM
> To: [e-mail]
> Cc: [e-mail]; [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)
> 
> 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.
> 
> With respect, we have gone 4 rounds with different NETCONF experts.   Each
> with a different suggestion to put in/take out.

Please don't misunderstand me, but also with respect, I simply state
my opinion.  I think the text is not clear, even if it has gone 4
rounds with different NETCONF experts.


> However, since you have
> asked: 
> 
> There are 4 classes of I2RS ephemeral configuration state checking we have
> defined so far: 
>   1) normal (r/w) of drafts (draft-ietf-i2rs-rib-data-model)  - check 8.3.1,
> 8.3.2, 8.3.3 + ephemeral requirements (1-15) 

There are no 8.3.x sections in draft-ietf-i2rs-rib-data-model-05.  Did
you mean some other document?


>   2) bulk (r/w) within rpcs (see draft-ietf-i2rs-rib-data-model) -
> constraints check interfaces (real configuration) + checks on route overlay
> (Ephemeral 7) + Ephemeral (-15)
>   3) bulk (r/w) with lots of data learned from other routing protocols
> (draft-ietf-i2rs-l3-network-topology) + checks on static configured
> protocols 
>   4) bulk (r/w) with rpcs that are "high-speed" using only checks on 8.3.1 +
> ephemeral requirements (1-15)
> 
> We desire to be able to define additional data constraints per data model.
> These additional constraints can go in rpcs. 

I'm sorry, but you are confusing me completely.  How can a constraint
go into an rpc?  Now I'm _really_ curious to understand your
definition of constraints.

And what does the r/w label above mean?  Are constraints checked
during read operations?


> >> 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.
> 
>  The I2RS architecture and these I2rs ephemeral requirements have been
> around for 2 years. 
> From the I2RS perspective, these constraints have not changed. We have added
> data models. 
> However, every time we try to put in constraints - it hits some
> netconf/netmod experts idea of operational versus
> Ephemeral configuration state.  We have tried enlisting friendly editing,
> only to find 
> Some other netconf/netmod expert objects to it. Perhaps after the
> netconf/netmod experts agree on 
> Operational state we can make some significant forward progress.  

I have not mentioned "Operational vs ephemeral configuration state".
I am just trying to understand what you mean when you talk about
"constraint".   The requirements are very specific that "constraints"
MUST be able to refer to fast-changing operational data.  I don't
think it is too much to ask for to get a definition of what a
"constraint" is.

> >> 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?
> Draft-gonzalez-netconf-event-notifications.

I'm sorry, but what does this draft have to do with the constraints
that refer to fast-changing operational data?


> > > 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.
> I suspect you mean definition. 
> 
> How about: 
>    Ephemeral-REQ-04: Ephemeral state MUST be able to refer to non-ephemeral
> state 
>    as a constraint. Non-ephemeral state can be configuration state or
> operational state. 

Ok.

> >> 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.
> See section 6.3 of RFC7921.

Hmm, section 6.3.1 says that "must" and "when" statements should be
considered, but not how to do it.


> We put these references in, and Juergen asked
> for their removal as TMI (too much information). 

I checked all previous versions of this document, and I did not find
such a reference in any one of them.  Could you specify what you mean?


> Please check with other netconf/netmod experts before we put-in/take-out
> again.

Are you saying that if one person provides some feeback, another
person must not provide conflicting feeback?



> >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?
> Clarification question:   It is possible any time the ephemeral state goes
> from active to inactive (see draft-ietf-i2rs-rib-data-model), or if state is
> removed (see draft-ietf-i2rs-rib-data-model)   

That's not what I asked though.  My question is if the ephemeral state
is removed when the constraint becomes false.


> >> Summary: No change
> Summary:   
>   Ephemeral-REQ-04: Ephemeral state MUST be able to refer to non-ephemeral
> state 
>    as a constraint. Non-ephemeral state can be configuration state or
> operational state. 
>    
>  
> > 
> > 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.
> 
> Sue:  This was part of an earlier version, but people felt we must indicate
> what chooses. 

Ok, so I assume the current text that this should be up to the
implementation rather than a standardized solution is correct.


> Summary: No change 
> 
> 
> >>  >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.  
> 
> Martin - I apologize, but I keep getting request to change to different
> answers based on different "yang experts" opinion.  
> I respect your expertise and your questions 
> 
> > My questions were simple:
> > Can I have "ephemeral, read-only, configuration"? 
> You are missing a key point.  Different I2RS agents have different
> permissions. 

I do understand this, but the requirement is for YANG to provide a
mechanism to specify these parameters *in the data model*.

> For I2RS agent 1, you can have ephemeral, read-only configuration because
> Agent 1 does not have permission to write this section of the data models.
> For I2RS agent 2 (who has permission to read this portion of the data
> model), the data will be ephemera, configuration, read/write.    
> 
> This is part of the normal case of the I2RS client-I2RS agent. 
> 
> >  Can I have "ephemeral, write, status"?
> It is possible if you allow a remote client permission to clear counters
> prior to sending. 
> This is possible if the I2RS data model allows read and clear.  

Sure, and there are already similar constructs, e.g., RFC 7317
defines an RPC to set the current date and time, even though the
current-datetime is config false.  This is possible even in YANG 1.0.


> > 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.
> I am glad to walk through this section with you.  
> 
> Summary: Still waiting on answers to determine if change is needed. 
> 
> > > 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.
> 
> Ok.  How easy is it for the I2RS client to request this of the NETCONF
> server or 
> RESTCONF server?  This requirement underscores that it must not only be
> possible, but 
> Easy for the client to query. 

I'd say that it is easy; YANG 1.1 even provides a way for the client
to cache the server's capabilities in order to not have to re-check
all capabilities every time.

Howabout:

OLD:

  The conceptual changes to NETCONF

NEW:

  The requirements to NETCONF are:


But in the light of the other issues, this one is really minor.

> >>    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.
> 
> People woho have been working in netconf are actively supporting changes to
> event notifications for netconf  (draft-gonzalez-netconf-4277bis-02,
> draft-gonzalez-netconf-evnet-notifications-00) or restconf
> (draft-voit-netconf-restconf-notif-00).  Where else would you suggest the
> write conflict is provided?  Early reports to I2RS during protocol selection
> claimed this was the place to work.  

I think it will be in the definition of ephemeral state.  Such a
solution would specify under which circumstances certain notifications
are generated.


> >> This is not what other netconf/netmod people have indicated. 
> 
> > If I'm not mistaken, Andy said the same thing re capabilities.
> Andy did same the same thing on #1.  However, the emphasis is going from
> "possible" to "easy".  
> 
> > Summary: Need response on -09 and -10 before changing.
> 
> Summary:  Awaiting confirmation on "write-conflict" prior to any change. 
> 
> > > >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.
> See answers above as well. 
> 
> > >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.
> 
> Summary: 
> Will change to: 
> /Multi-headed control is required for collisions and the priority
> resolution of collisions./ 

Ok.


> > >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!
> 
> Yes.  I'm glad you liked it. 
> 
> > >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.
> Perhaps this is true, however this text is the result of 4 weeks of debate.
> The compromise for all participants was to place this requirement.  If you
> feel it is redundant, you are aligning with some of the people in the
> debate. 
> 
> > 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.
> 
> No - we mean that multiple messages MUST not insert an error.  Andy Bierman
> states if we allow less than the current constraints (8.3.1, 8.3.2, 8.3.3 in
> netconf) and the current netconf constraints we could have a error in the
> ephemeral configuration data store.   We simply state this MUST not happen. 

I think you just confirmed what I wrote :)



/martin



> For some models using the high-speed update with minimal checking, the I2RS
> is willing to provide self-checks of the data.   If you mix this type (type
> 4 above) and the normal type, perhaps you could get an error.  The
> self-checking would then detect it, invalidate all the "invalid" data and
> send a notification to the I2RS client that the data has been invalidated.
> This is not what we are focusing on here. 
> 
> 
> > /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
> > 
>