On Wed, Jun 03, 2015 at 08:49:41PM -0400, Susan Hares wrote: > The minutes for the I2RS meeting are at: > > > > www.ietf.org/proceedings/interim/2015/05/27/i2rs/minutes/minutes-interim-201 > 5-i2rs-8 > > > > These minute provide a lengthy of issues in the requirements. From these > minutes, there are the following 6 conclusions on the protocol requirements > that Jeff stated: > > > > 1) There will be no consideration of an overlay model unless a fully > formed proposal is presented. > > Jeff and I appreciate Ken Watsen's comments on the list, but we have > had lots of suggestions regarding an overlay proposal - but no full > proposal. At this time, the WG will only consider full proposals > and not suggestions toward a proposal.
For the record: I am highly concerned about solutions that require (i) separate data models for ephemeral state and (ii) data model specific merge logic. While this may work for I2RS, this approach does not scale or has a very high cost of scaling to other ephemeral state editing needs. > 2) Jeff's document provides details on ephemeral state requirements > that have not changed. These requirements include: > > a. Highly reliable notifications (but not perfectly reliable > notifications) > > b. High bandwidth, asynchronous interface, with real-time guarantees on > getting data, > > c. Node identification of clients that write by client identity, > secondary identity, and priority. Data models will determine what is the > "node" unit. For example, the I2RS RIB node unit is the route. I am concerned about adding protocol mechanisms that are specific to a certain data model. It is unclear what a "node" unit it, terms like 'highly reliable notifications' and 'high bandwidth, asynchronous interface, with real-time guarantees' are somewhat unclear - how do we determine we have met any of these requirements? > d. There is one priority per client. > > e. Priority is kept in the NACM at the client level [rather than path > level (5/27 meeting) or group level (list discussion). Why does this mapping of username to priority have to be maintained in NACM? > 3) Joel suggests that large data write may be best done in netconf with > guarantees > > a. I2RS will be focused on highly asynchronous interfaces with less > than full routing tables. > > b. A client whose large data is interrupted by a notification has a > difficult time determine when the notification happened in the stream - so > the I2RS client must ask the agent again. > > c. Logging for traceability is different than event notification. Except c), I do not understand this. What are these 'guarantees' 3) is about? > 5) Secondary identity data is read-only meta-data that is stored in the > agent associated with a data model node that is being created or updated > (write-access) in the data store. Ehem, what is read-only data that is created or written? Did you want to say that the identity meta-data is immutable once a data node has been created? And if so, has priority the same property: Is priority of a data node is determined at creation time and then immutable? > 6) I2RS Client and Agent Identities are mutually authenticated by > Authentication server (AAA), > > The values of identities are originally set by operators. > I am not sure how agent identity authentication via AAA works. Can someone point me to the right direction if I assume a secure transport such as SSH or TLS? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <http://www.jacobs-university.de/> _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
