On 6/10/14, 1:41 PM, Jeffrey Haas wrote:
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?
Yeah, this makes sense.
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.
Maybe, but I worry about Client A and Client B not being able to write
to each others state. If Client B is a supervisory app, wouldn't it
need to act as Client A?
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.
That could be.
Joe
-- Jeff
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
