>1) The use cases motivate doing the work. >2) The use cases tell us something about the threat/risk/benefit of the > environment, and inform the reviewer what assumptions have been made.
Hi, Michael, This sounds reasonable. I truly think the technical requirements here are valid. It is the texts of use case part needed to be enhanced. We will work on it in next update, making the use cases (maybe reduced to one or two in the main text, as you suggested) solid and mapping to our technical requirements well. Cheers, -------------- Sheng Jiang > >Sheng Jiang <shengji...@bupt.edu.cn> wrote: > > I actually agree your observation on the supportiveness of use case > > section. We were discussing to move use cases section into > > appendix. Overall, use cases here are not necessary or as a MUST. What > > we should focus on is the validity of technical requirements on Section > > 4. If yes, infrastructure would be used when it is ready and good > > enough to be used. > >1) The use cases motivate doing the work. >2) The use cases tell us something about the threat/risk/benefit of the > environment, and inform the reviewer what assumptions have been made. > >So moving them into an appendix just makes it harder to understand what >problem you are trying to solve. It also obscures that some of the use cases >are not really credible. > >Instead, I suggest: > a) pick a specific use case (firmware update?) and implement it. > b) talk about that implementation, and see if any of the proposed other > users are interested in the solution. > >Otherwise, my advice to the chairs is that there is no audience for this >innovation, and we should not go through the expense/effort of publishing it. > >-- >Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works > -= IPv6 IoT consulting =- *I*LIKE*TRAINS* > > > _______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima