I2RS interim 5/27/2015 

1) I2RS Protocol requirements  [10:05 – 10:35] 
        presenter (Jeff Haas)    

Discussion on  All requirements including the following drafts [~10:35 to 11:00]   
http://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-requirements (WG adoption 5/26 to 6/9/2015)
http://datatracker.ietf.org/doc/draft-ietf-i2rs-pub-sub-requirements/ ( WG LC 5/26 to 6/9/2015) 
http://datatracker.ietf.org/doc/draft-ietf-i2rs-traceability/  WG LC 5/26 to 6/9/2015) 

   slides for previous presentations draft-ietf-i2rs-pub-sub-requirements, 
   and draft-ietf-i2rs-traceability are also on the web. 
Slide comments: 
slide 1: The draft-i2rs-ephemeral-state-reqs-00 was an attempt to move the protocol requirements discussion along a bit.
slide 2: This document provides concrete examples.  With examples we did not get anything specific. 
slide 3: Initial private discussion with pass commenters stirred initial discussion. 
            Martin Bjorkland created a writeable operational state which was much like the current
            ephemeral. I did not see hte draft (draft-bjorklund-netmod-operational-00) in my original reading for i2rs.
            This document explains what netmod/netconf people thought when they saw the I2RS 
            writeable configuration state. This draft (draft-bojorklund-netmod-operational-00) was in terms
            of writeable operational state.  Whether this is resonable attitude is up for debate. 
slide 4: This clarifies the Venn diagrams that were presented at IETF91 (Hawaii). 
              Ephemeral configuration may be a child of presistent configuration.
              The reverse is not permitted. Static state under ephemeral must be ephemeral.  
               Similarly, the Operational state whose parent is ephemeral, must also be ephemeral. 
               The state may go away if the system resets. 
Slide 5: Secondasry identity is a property of the I2RS ephemeral state that is stored in each
            of the ephemeral configuratino nodes. 
            Make it accessible to the user as a piece of meta-data.  A form of "read-only" data. 
            This is a new construct and does not exist at this time. 
            It is carried as a parameter to "edit-config".  It did not get any counter suggestions. 
Slide 6:  Priority is are most contentious issue.  New attribute of the of the NACM.  
             For new ephemeral nodes, it is simply assigned a prority for that node.  
             NACM varies by path.  If you are tyring to update an existing ephemeral node, the 
            update is permitted if the user's priroity is > (note the correction to the slide) than the
            existing priority. After the update, the node caries the new priority 
            Transacation/Commit will fail.
            How do we let the use know what the priority is.  Again, the suggestion is expose the data
            as meta-data. One of the bits of off-mail is to consider anchoring it to NACM group. 
            This is a property of the group that does not vary on a per node basis. 
            An NACM can pass to that [? group] level of the architecture.  Mostly the
            I2RS architecture simply ties it to the client. 
            The changes to my draft would be to move the node up the tree from 
            client node to the group node.
Overlay discussion (verbally only) 
            Kent Watsen suggested additional changes to Jeff's draft regarding the
            overlay models. I had not preceded with the overlay models in this document. 
            In the overlay model, there are two distinct datastores (actual or resembling a logical datastore),
            The biggest problem is when nodes shadow other nodes. If you have a piece of static 
            configuration or a piece of different ephemeral configuration being shadow from a different layer,
            what happens if something changes underneath the visible layer (top layer) goes away.
            Now, the top layer crashes.  The side effect may be configuaration that was valid is no
            longer valid. I not saying we should discard the use of the overlay model completely, if
            this is what the working group wants to go with. 
            This overlay is the most sane thing, we can find a way to describe the overlay model
            as disjoint.  In this way, overlay is not an issue anymore. Beyond that, the second major 
            obstacle is constraints. Right now the language which describes constraints [Xpath] 
            does not allow us to refer from one data store 

overlay proposal 

Priority and Sue's example: DDoS and Admin Route priority 

Brief in-depth discussion of pub/sub as Event Steam 

Notification of a change and Real-time Guarantees for Get of Data 


Entity Tag short discussion 

Summation on the What has to occur for I2RS Notifications: 

[45:26] Time/Agenda Check 


          [List Call 3: Statement #3 - We know what the requirements are, but have no specific proposal. 

Notification discussion: 

    [List call #4: Is reliable, but not perfectly reliable notifications a requirement for I2RS.] 

Secondary identity 
Secondary identity stored in Read-only Meta data: 

Topic change:
[Sue]: Any other questions? Please ask questions now or on the mail list.  We will be hammering out these points on the mail list based on our discussions today.  Please ask questions now or on the mail list. 

[presentation by Ran Chen: 



[Call Question 6:  The identities for I2RS client and agent are identities which the operator sets. 

[Ran continues presentation, as for additional feedback on the solution.] 
Jeff: Thank you Ran. 
[Sue]: This has helped clarify our requirements for identity. 

[Topic change] 
 Sue: Anything else?  Eric? 
Sue: Any other questions for Eric? 


2) Announcement of I2RS Design team for FB-RIB documents  [
    Review of draft draft-kini-i2rs-fb-Rib-info-model-00 (Sue Hares) [1:24-1:27]
      (Review of Yang models proposed : Generic and specific ) 

    Discussion during Sue's talk: 

 Meeting number: 646 31 150 
 Meeting password: jeff.is.wise 
1-877-668-4493 Call-in toll free number (US/Canada)
1-650-479-3208 Call-in toll number (US/Canada)
Access code: 646 391 150

meeting etherpad:
 Meeting blue sheets: 

Send SMS
Call from mobile
Add to Skype
You'll need Skype CreditFree via Skype