Joe, Thanks for re-sending the comments. A few clarifying points:
On Fri, Jun 06, 2014 at 05:33:57PM -0400, Joe Marcus Clarke wrote: [...] > Section 7.1. This is mainly an editorial, but in looking back at > things like NETCONF over BEEP, one goal might be to make sure the > transport chosen is both operator and implementor friendly in terms > of ease of adoption. I think we're leaving this broadly open because "easy to implement" will vary depending on your environment. PHP webserver based environments may prefer BEEP environments if you have the right tool chain, as an example. I'd probably prefer to just do it in SSH if I were writing it. But I think we're all generally aware that the client environment and ecosystem and the agent environment and ecosystems may be wildly different. Clients will be highly variable since they're user applications. Agents in many cases will have to co-exist with routing applications that have (near) real-time constraints. This disparity of environments will likely lead to some constraints on what a given vendor may care to deploy. Given the above, do you still think 7.1 needs additional clarification? > Section 7.5. Would a supervisory application work in this case? This seems like an implementation detail - and potentially a common one. However, I'm not sure if it's one we'd want to mandate in the architecture. > I > suppose it could if it shared the same ID, but that wouldn't work > for multiple applications. Likely a better approach would be to > allow the Client to accept some meta-instructions at the beginning > of a session as to what to do if the app goes away (as you state in > paragraph 4). I believe such details will hopefully fall-out very early on in the gap analysis work that is ahead of us. Perhaps even something like "Graceful restart" type semantics, if appropriate. -- Jeff _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
