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

From: Martin Bjorklund <[email-masked]>
Date: Fri, 01 Jul 2016 12:45:10 +0200 (CEST)

Hi,

Comments inline.

"Susan Hares" <[email-masked]> 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:[email-masked]] On Behalf Of Martin Bjorklund
> Sent: Wednesday, June 29, 2016 6:50 AM
> To: [email-masked]
> 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" <[email-masked]> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i2rs
>

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 1 Jul 2016 08:59:17 -0400

Martin: 

Pulling up some response up-front to highlight them.  These response are
also in the text below. 

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

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

The purpose was to allow the constraint checking to be tailored to the data
model.  The I2RS architecture (especially section 6 and 7) are accurate. 

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

New notification drafts: 
Draft-gonzalez-netconf-5277bis-02,
Draft-gonzalez-netconf-event-notifications,
draftvoit-netconf-restconf-notif-00.txt 

Changes queued for -13 based on this message: 

   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.

  Ephemeral-REQ-13: 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 to modify the same node of data are the focus.
  The requirement to support multi-headed control is
  required for collisions and the priority resolution of collisions.

 Awaiting responses on:  Ephemeral-REQ-03, Ephemeral-REQ-04, 
Ephemeral-REQ-09, Ephemeral-REQ-10, Ephemeral-REQ-15. 

Thank you for spending time reviewing these 15 requirements. 

Sue 

-----Original Message-----
From: Martin Bjorklund [mailto:[email-masked]] 
Sent: Friday, July 1, 2016 6:45 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [i2rs] FW: I-D Action: draft-ietf-i2rs-ephemeral-state-10.txt-

Hi,

Comments inline.

"Susan Hares" <[email-masked]> wrote:
> Summary:  Changes limited to /Yang/YANG/ change.  Other changes may 
> occur upon further details.
> 
> Sue
> 
> 
> >  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. 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) 
  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. 

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

>> For operational state listed in ephemeral constraints going quickly 
>> from TRUE to FALSE, please note that an event notification will be sent
to the

> Which draft do you mean?
Draft-gonzalez-netconf-event-notifications.

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

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

> 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.   We put these references in, and Juergen asked
for their removal as TMI (too much information).   
Please check with other netconf/netmod experts before we put-in/take-out
again.   

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

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

> defining a solutions.  If the NETCONF/NETMOD does not define a 
> solution - then the implementation should provide a solution.

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

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

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

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

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

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

> > Are you really sure you support priority requirements as specified in 
> > items Ephemeral-REQ-11 through Ephemeral-REQ-14?

> See above.
See answers above as well. 

> I believe this text refines the requirement to support multi-headed 
> control to only be required for collisions and priority resolution of
collisions.

OLD:

NEW:

> Rather than repeat that text here, perhaps you will review it and see 
> if you then understand this text.

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

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

> >                                 [response eth0 is up ] Message 1 
> > [install I2RS Static route associated with eth0 ] Message 2 [install 
> >  BGP I2RS route dependent on I2RS static route]

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

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.

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 01 Jul 2016 16:13:21 +0200 (CEST)

> Pulling up some response up-front to highlight them.  These response are

Trimming a bit, and replying inline.

> 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

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

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

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

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

>    as a constraint. Non-ephemeral state can be configuration state or

Ok.

> 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

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

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

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

> Sue:  This was part of an earlier version, but people felt we must indicate

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

> You are missing a key point.  Different I2RS agents have different

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

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

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

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

> resolution of collisions./ 

Ok.

> ephemeral configuration data store.   We simply state this MUST not happen. 

I think you just confirmed what I wrote :)

/martin

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 1 Jul 2016 15:50:27 -0400

Martin: 

Trimming a bit as well.  Starting with ephemeral-REQ-03. 

   Ephemeral-REQ-03: Ephemeral state may have constraints that refer

     to operational state, this includes potentially fast changing or

     short lived operational state nodes, such as MPLS LSP-ID or a BGP
IN-RIB.

Thanks for Acting the following for Ephemeral-REQ-04 

Old: 

Ephemeral-REQ-07: Ephemeral configuration state could override overlapping 

local configuration state, or vice-versa.  

Implementations MUST provide a mechanism to choose which takes precedence.  

/

New 

Ephemeral-REQ-07: Ephemeral configuration state could override overlapping 

local configuration state, or vice-versa.  

Implementations MUST provide a mechanism to choose which takes precedence.  

This mechanism MUST include local configuration

(policy) and MAY be provided via the I2RS protocol mechanisms.

Ephemeral-REQ-08:  Status: No change, discussion continuing  

Ephemeral-REQ-09/Ephemeral-REQ-10: No change, discussion indicates minor
point. 

Ephemeral-REQ-11/12/13: No change 

Ephemeral-REQ-14: No change, do we have agreement? 

I’ll send version-13 out later todasy. 

Sue 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Martin Bjorklund
Sent: Friday, July 1, 2016 10:13 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [i2rs] FW: I-D Action: draft-ietf-i2rs-ephemeral-state-10.txt-

Trimming a bit, and replying inline -- starting with Ephemeral 

> > > > normal config, YANG has very detailed rules about when 

> > > > constraints are checked and what a server MUST do when a 

> > > > constraint becomes false.

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

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

I understand it is unclear to you.   This last proposal was from Robert
Wilton that resulted in this text which he understood. 

The previous text tried to make it clear to Juergen.  ... etc.   At some
point, I must just get it approved with the 

I2RS WG folks, and then try to get netmod key people, netmod chairs, netconf
chairs, and netconf key people  in a room to get a common definition. 

  Ephemeral-REQ-03: Ephemeral state may have constraints that refer to

   operational state, this includes potentially fast changing or short

   lived operational state nodes, such as MPLS LSP-ID or a BGP IN-RIB.

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

Yang 1.1 section 8.3.1, 8.3.2, 8.3.3.  

>> constraints check interfaces (real configuration) + checks on route 

>> overlay (Ephemeral 7) + Ephemeral (-15)

>>   4) bulk (r/w) with rpcs that are "high-speed" using only checks on 

>> 8.3.1 + ephemeral requirements (1-15)

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

An rpc has input/output parameters.   What do you call checking on the 

   rpcs:

      +---x rib-add

      |  +---w input

      |  |  +---w rib-name        string

      |  |  +---w rib-family      rib-family-def

      |  |  +---w ip-rpf-check?   boolean

      |  +--ro output

      |     +--ro result uint32

      |     +--ro reason? string

Rpc = yang1.1 section 17.14 

              +--------------+---------+-------------+

              | substatement | section | cardinality |

              +--------------+---------+-------------+

              | anydata      | 7.10    | 0..n        |

              | anyxml       | 7.11    | 0..n        |

              | choice       | 7.9     | 0..n        |

              | container    | 7.5     | 0..n        |

              | grouping     | 7.12    | 0..n        |

              | leaf         | 7.6     | 0..n        |

              | leaf-list    | 7.7     | 0..n        |

              | list         | 7.8     | 0..n        |

              | must         | 7.5.3   | 0..n        |

              | typedef      | 7.3     | 0..n        |

              | uses         | 7.13    | 0..n        |

              +--------------+---------+-------------+

>From section in rpc input: 

   If a leaf in the input tree has a "mandatory" statement with the
   value "true", the leaf MUST be present in an RPC invocation.
 
   If a leaf in the input tree has a default value, the server MUST use
   this value in the same cases as described in Section 7.6.1
<https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-14#section-7.6.1>
.  In these
   cases, the server MUST operationally behave as if the leaf was
   present in the RPC invocation with the default value as its value.
 
   If a leaf-list in the input tree has one or more default values, the
   server MUST use these values in the same cases as described in
   Section 7.7.2
<https://tools.ietf.org/html/draft-ietf-netmod-rfc6020bis-14#section-7.7.2>
.  In these cases, the server MUST operationally behave
   as if the leaf-list was present in the RPC invocation with the
   default values as its values.
 
   Since the input tree is not part of any datastore, all "config"
   statements for nodes in the input tree are ignored.

What do you call these requirements for input?  Constraints or something
else?  How do you define the validity of the grouping, choice, container,
leaf-list, list, etc. without enforcing some type of syntactical (section
8.3.1) constraint.  If you use a different term, where is it define in
section 7.14? If not, why is it not constraint. 

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

Yes, the constraints of the read format are expected to be syntactically
checked as netconf server receives it from I2RS agent.  The response from
the read is syntactically check at the I2RS client when the read response is
received.  The constraints of the write format are expected to be
syntactically checked when the netconf server receives it from I2RS agent.
If a rpc is used to add/delete/modify the data in the I2RS agent, then
section Yang 1.1 in section 17.4 has “constraints” or something on the input
and output parameters. 

> >> Every effort we have made to tie this down has resulted in cycles 

> >> of unproductive discussion.  Therefore, this portion will not be
re-opened.

[snip] 

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

I agree you are being reasonable.  I am trying to provide you with the
definition of constraints per yang 1.1 documentation and the ephemeral
requirements in this document. 

What I am stating is unreasonable is that the process of getting the
definition of “constraints” has been enmeshed in the opstate debate which
has gone on for 2 years.  IHMO – that is an unreasonably long period of time
for opstate debate to go on without quick resolution.   Hopefully, my
answers will steer clear of the opstate debate. 

>> to the I2RS Client.   See the event-notification draft for specifics. 

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

You are missing a piece that the architecture specifies.  I2RS ephemeral
state may refer to operational state that rapidly changes (e.g. LSP-ID).  If
this causes the I2RS ephemeral state to become invalid, the I2RS agent needs
to notify the I2RS client via the notification process.    See the
notification examples from the ietf-i2rs-rib-data-model. 

notifications:
      +---n nexthop-resolution-status-change
      |  +--ro nexthop
      |  |  +--ro nexthop-id?           uint32
      |  |  +--ro sharing-flag?         boolean
      |  |  +--ro (nexthop-type)?
      |  |     +--:(nexthop-base)
      |  |     |  ...
      |  |     +--:(nexthop-chain) {nexthop-chain}?
      |  |     |  ...
      |  |     +--:(nexthop-replicates) {nexthop-replicates}?
      |  |     |  ...
      |  |     +--:(nexthop-protection) {nexthop-protection}?
      |  |     |  ...
      |  |     +--:(nexthop-load-balance) {nexthop-load-balance}?
      |  |        ...
      |  +--ro nexthop-state nexthop-state-def
      +---n route-change
         +--ro rib-name                 string
         +--ro rib-family               rib-family-def
         +--ro route-index              uint64
         +--ro match
         |  +--ro (route-type)?
         |     +--:(ipv4)
         |     |  ...
         |     +--:(ipv6)
         |     |  ...
         |     +--:(mpls-route)
         |     |  ...
         |     +--:(mac-route)
         |     |  ...
         |     +--:(interface-route)
         |        ...
         +--ro route-installed-state route-installed-state-def
         +--ro route-state         route-state-def
         +--ro route-change-reason route-reason-def

In Ephemeral-REQ-03, we are simply indicating that these notifications may
occur rapidly if the operational state changes cause the operational state
or the ephemeral configuration state (see the above example for i2rs-rib
data model).   The intent of this notification is to indicate load on the
notification functions.   The new designs for notification in
NETCONF/RESTCONF are trying to handle this rapid form of events. 

Snip ….. 

>    Ephemeral-REQ-04: Ephemeral state MUST be able to refer to 

> non-ephemeral state

Ok.

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

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

Yes – we were told if we went further, it was encroaching on the solution
space.  Do you want I2RS opinions on MUST and WHEN. 

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

The I2RS chairs have had email discussions online and offlist.   It is in
these email discussions.  

again.

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

YES!!!!

> >question

> is removed and a notification is sent, or that the ephemeral state is 

> still present, but not used, and a notification is sent?

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

The removal of data is model dependent, but the requirement to notify the
I2RS client if a constraint becomes false is mandatory. 

For example, the installed state in the i2RS RIB below can go to inactive
with a reason of interface down. 

      +---n route-change
         +--ro rib-name                 string
         +--ro rib-family               rib-family-def
         +--ro route-index              uint64
         +--ro match
         |  +--ro (route-type)?
         |     +--:(ipv4)
         |     |  ...
         |     +--:(ipv6)
         |     |  ...
         |     +--:(mpls-route)
         |     |  ...
         |     +--:(mac-route)
         |     |  ...
         |     +--:(interface-route)
         |        ...
         +--ro route-installed-state route-installed-state-def
         +--ro route-state         route-state-def
         +--ro route-change-reason route-reason-def

> > Sue:  Previous netconf/netmod reviewers have cautioned the I2RS WG 

> > on defining a solutions.  If the NETCONF/NETMOD does not define a 

> >document's role is to define requirements for a solution (not for
implementations).

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

No, our understanding is that this text would allow the NETCONF to specify a
solution,  and if it did not – for implementations to create a solution.  If
this is not what you think this requirement means, then I’ve got to go back
to refining the text. 

How about: 

Old:

Implementations MUST provide a mechanism to choose which takes  precedence.

New: 

Implementations MUST provide a mechanism to choose which takes precedence.

If a standard mechanism to choose precedence exists, then the implementation
MUST implement the standard mechanism. 

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

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

> Martin - I apologize, but I keep getting request to change to 

> different answers based on different "yang experts" opinion.

> permissions.

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

What is “data mode”?  It is not defined in yang 1.1.  

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

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

OK – the history is I had ephemeral state/non-ephemeral state (ephemeral
configuration state and operational state) and read/write, but this did not
seem to allow rpcs.   

How does this text work for you: 

Ephemeral-REQ-08:In addition to config true/false, there MUST be a way to
indicate that YANG schema nodes represent ephemeral state. 

It is desirable to allow for, and have to way to indicate, config false YANG
schema nodes that are writable operational state.

> > >   1.  Support for communication mechanisms to enable an I2RS 

> > > client to

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

>>  The requirements to NETCONF are:

This was the previous version.  Juergen wanted it changed to configuration.
If it is minor, lets leae it. 

> > > NETCONF the protocol supports notifications; it is not involved in 

> People woho have been working in netconf are actively supporting 

> changes to event notifications for netconf  

> (draft-gonzalez-netconf-4277bis-02,

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

Sue: This did not provide a clean definition of ephemeral state agreeable to
Juergen.  We left it in the rather length ephemeral-REQ-11 to
ephemeral-REQ-14. 

> Andy did same the same thing on #1.  However, the emphasis is going 

> from "possible" to "easy".

> > > Are you really sure you support priority requirements as specified 

> > > in items Ephemeral-REQ-11 through Ephemeral-REQ-14?

> > control to only be required for collisions and priority resolution 

> > of

> > Rather than repeat that text here, perhaps you will review it and 

> > see if you then understand this text.

> are also fine, they help the readers to understand what you had in mind.

Ok.

> > > [install I2RS Static route associated with eth0 ] Message 2 

> > > [install  BGP I2RS route dependent on I2RS static route]

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

> > > None of these multiple message sequences should allow the I2RS 

> > > agent to insert errors into the Ephemeral Configuration state or 

> > 'constraints', so

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

> > insert

> errors".  What is an "error" that could be inserted?  What you 

> 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

> ephemeral configuration data store.   We simply state this MUST not
happen. 

Ø  I think you just confirmed what I wrote :)

Sue: Yes, I did.  Andy seem to desire to say it in this fashion.  

/martin

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

> >  <mailto:[email-masked]> [email-masked]

> >  <https://www.ietf.org/mailman/listinfo/i2rs>

i2rs mailing list

 <mailto:[email-masked]> [email-masked]

 <https://www.ietf.org/mailman/listinfo/i2rs>
https://www.ietf.org/mailman/listinfo/i2rs

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 1 Jul 2016 16:12:27 -0400

Version-13 has been uploaded with changes. 

In it ephemeral-REQ-08 is: 

   Ephemeral-REQ-08:In addition to config true/false, there MUST be a

   way to indicate that YANG schema nodes represent ephemeral state.  It

   is desirable to allow for, and have to way to indicate, config false

   YANG schema nodes that are writable operational state.

Is this text clearer? 

Sue 

From: i2rs [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Friday, July 1, 2016 3:50 PM
To: 'Martin Bjorklund'
Cc: [email-masked]; [email-masked]
Subject: Re: [i2rs] FW: I-D Action: draft-ietf-i2rs-ephemeral-state-10.txt-
2 week WG LC (6/21 to 7/5/2016)

Martin: 

Old: 

/

New 

Sue 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Martin Bjorklund
Sent: Friday, July 1, 2016 10:13 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [i2rs] FW: I-D Action: draft-ietf-i2rs-ephemeral-state-10.txt-

 

 

into an rpc?  

   rpcs:

      +---x rib-add

      |  +---w input

      |  +--ro output

      |     +--ro result uint32

      |     +--ro reason? string

              | anyxml       | 7.11    | 0..n        |

              | choice       | 7.9     | 0..n        |

              | leaf         | 7.6     | 0..n        |

              | list         | 7.8     | 0..n        |

              | must         | 7.5.3   | 0..n        |

              | typedef      | 7.3     | 0..n        |

              | uses         | 7.13    | 0..n        |

 

read operations?

re-opened.

[snip] 

notifications:

Snip ….. 

Ok.

(too much information).

again.

YES!!!!

      +---n route-change
         +--ro rib-name                 string

implementations).

How about: 

Old:

New: 

 

models.

 

Ok.

installed.

 

/martin

invalidated.

i2rs mailing list

---

From: "Joel M. Halpern" <[email-masked]>
Date: Wed, 6 Jul 2016 10:03:03 -0400

I realize I am late responding.  My apologies.
This document appears done and right to me.  I support sending it for 
publication.

Yours,
Joel

On 6/21/16 3:17 PM, Susan Hares wrote:
> draft-ietf-i2rs-ephemeral-state-10.txt.   There are 15 requirement for I2RS
> ephemeral state, and 2 requirements for ephemeral state utilized by pub/sub
> documents.
>
> Sue Hares and Russ White