Re: RE: SNMPv3 as MIDCOM protocol: Opinions?

> => well, this is kind of the whole point. The architecture currently
> specified acts in the way you described, of course. And I have nothing
> against it, on the contrary! I'm just saying that there are other
> policy-oriented architectures, following the framework defined by the "rap"
> group (and used by the "diffserv" and "ipsp" groups) which would reach the
> same "fundamental goals" for managing middleboxes, using a dynamic policy
> protocol in-between. And I believe we should not exclude such architectures.

Those architectures certainly are not excluded by the
current midcom framework.  We did have to constrain the
problem space, however, lest we become one of those working
groups who never produces anything (which is where we're
currently headed, BTW).

> => well, if you're making the assumption that a stateless SIP proxy should
> be the "midcom agent" and should directly interact with the middlebox,
> you're absolutely right. 

We don't make that assumption.  We assume that any endpoint
or other device can make a request of a middlebox.  By
restricting it to a single agent we'd either have something
that didn't work for telephony applications (the ones
driving the work, incidentally), or something that wouldn't
scale at all.  In the latter case we'd effectively be moving
the midcom protocol to running from the endpoint to an agent
and a policy protocol between the agent and the middlebox,
and I gather that's what you're arguing for.  That's not a
good architecture in an environment in which you've
potentially got tens of thousands of endpoints.  

If you're going to propose architectural changes you've got
to be specific about what you want to do and why it's an
improvement over what we've got now.  The rap work would not
apply, I think, because the policy decisions are being
driven up by network events.  We're trying to make requests
of the network based on application events.  We're also
trying to restore end-to-end function in the face of funky
disruptive devices.  I don't think you've made a
particularly compelling argument for changing our
architecture, and unless you can do so we really do need to
move on.

Melinda