Hi, Re 2(a) and (b):
Are changes to RFC 5277 being proposed to make notifications highly reliable, or is there an assumption that implementations will just provide adequate memory to buffer notifications? Real time guarantees on getting data sounds like RAI work is needed? Are any changes needed to RESTCONF or NETCONF to support this requirement? Or is there just an expectation that implementations will be fast. IMO, the standard should be silent on response times and packets per second issues. Unless a certain speed is required for interoperability, then it seems inappropriate to mention in an RFC. Andy On Wed, Jun 3, 2015 at 5:49 PM, Susan Hares <[email protected]> wrote: > The minutes for the I2RS meeting are at: > > > > www.ietf.org/proceedings/interim/2015/05/27/i2rs/minutes/minutes-interim-2015-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. > > > > 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. > > 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). > > > > 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. > > > > 4) Secondary identity data is meta-data that is stored in the agent. > Agent does not do anything with the meta-data. The client has to do one edit > per secondary at a time. > > > > 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. > > > > > > 6) I2RS Client and Agent Identities are mutually authenticated by > Authentication server (AAA), > > The values of identities are originally set by operators. > > > > > > Does anyone have any concerns regarding these requirements? > > > > Sue Hares > > > > > _______________________________________________ > i2rs mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2rs > _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
