On Wed, Jun 08, 2016 at 12:10:09PM -0400, Susan Hares wrote: > > Therefore, the result of I2RS WG spending 2 years writing requirements for > the ephemeral data store that both option 2 documents "do not match" the > I2RS ephemeral requirements set. [4] lumps ephemeral with operational > state.
I tried to bring [4] to the attention of I2RS; nobody ever claimed that [4] is a final solution. I did ask concrete questions on the I2RS list concerning I2RS requirements and what the various terms used in the description of I2RS requirements actually mean. The outcome were some changes (I think) but there are also requirements I still find unclear (but where we keep going in circles). That said, I do not think '[4] lumps ephemeral with operational state' is a fair statement either. Anyway, as Lou explained, the subject of this thread is to decide on the general direction and once we have agreement on the direction, I am sure there will be further work on the details of the architectural solutions on the table. And yes, this is then the time to settle what an I2RS ephemeral datastore is and how it integrates conceptually and architecturally with the rest. /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
