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

From: "Susan Hares" <[email-masked]>
Date: Tue, 21 Jun 2016 15:17:15 -0400

This begins a 2 WG LC last call on the text of
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 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Tuesday, June 21, 2016 2:57 PM
To: [email-masked]
Cc: [email-masked]
Subject: [i2rs] I-D Action: draft-ietf-i2rs-ephemeral-state-10.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Interface to the Routing System of the
IETF.

        Title           : I2RS Ephemeral State Requirements
        Authors         : Jeff Haas
                          Susan Hares
	Filename        : draft-ietf-i2rs-ephemeral-state-10.txt
	Pages           : 11
	Date            : 2016-06-21

Abstract:
   This document covers requests to the NETMOD and NETCONF Working
   Groups for functionality to support the ephemeral state requirements
   to implement the I2RS architecture.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-i2rs-ephemeral-state/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-i2rs-ephemeral-state-10

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-i2rs-ephemeral-state-10

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

---

From: "Susan Hares" <[email-masked]>
Date: Tue, 21 Jun 2016 16:29:18 -0400

WG there is an typo in section 7

   Ephemeral-REQ-11: The data nodes MAY store I2RS client identity and
   not the effective priority at the time the data node is stored.  Per
   SEC-REQ-07 in section 3.1 of
   [I-D.ietf-i2rs-protocol-security-requirements], an identifier must
   have just one priority.  Therefore, the data nodes MAY store I2RS
   client identity and not the effective priority of the I2RS client at
   the time the data node is stored.  The priority MAY be dynamically
   changed by AAA, but the exact actions are part of the protocol
   definition as long as collisions are handled as described in
   Ephemeral-REQ-10, Ephemeral-REQ-11, and Ephemeral-REQ-12.

The last line should be 

    Ephemeral-REQ-12, Ephemeral-REQ-13, and Ephemeral-REQ-14. 

Sue Hares 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Tuesday, June 21, 2016 3:17 PM
To: [email-masked]
Cc: 'Russ White'
Subject: [i2rs] FW: I-D Action: draft-ietf-i2rs-ephemeral-state-10.txt- 2
week WG LC (6/21 to 7/5/2016)

Sue Hares and Russ White 

-----Original Message-----

Abstract:

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 29 Jun 2016 12:49:46 +0200 (CEST)

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

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.

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?

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?

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

o  Ephemeral-REQ-09

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

o  Ephemeral-REQ-10

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

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

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?

o  Ephemeral-REQ-15

   I do not understand what this requirement means.

o  general

   s/Yang/YANG/g

/martin

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 30 Jun 2016 11:38:34 -0400

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)

Hi,

>   solution will make sure it is not even syntactially possible to

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 

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

>  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

> rather implementations are required to invent some vendor-specific

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. 

> 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

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

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

>   (BTW, the text should be rephrased; it now says "the requirement

   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. 

>  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 

> 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

---

From: Linda Dunbar <[email-masked]>
Date: Thu, 30 Jun 2016 21:10:35 +0000

I have reviewed the i2rs-ephemera-state draft. I think it is in good shape. 

Support, 

Linda 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Tuesday, June 21, 2016 2:17 PM
To: [email-masked]
Cc: 'Russ White'
Subject: [i2rs] FW: I-D Action: draft-ietf-i2rs-ephemeral-state-10.txt- 2 week WG LC (6/21 to 7/5/2016)

Sue Hares and Russ White 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, June 21, 2016 2:57 PM
To: [email-masked]
Cc: [email-masked]
Subject: [i2rs] I-D Action: draft-ietf-i2rs-ephemeral-state-10.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Interface to the Routing System of the IETF.

Abstract:

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.