RE: RE: SNMPv3 as MIDCOM protocol: Opinions?

Please, see inline comments below.

-----Original Message-----
From: Melinda Shore [mailto:[email protected]]
Sent: Thursday, December 05, 2002 2:00 PM
To: Moisand, Jerome
Cc: 'Harrington, David'; Martin Stiemerling; [email protected];
[email protected]
Subject: Re: [midcom] RE: SNMPv3 as MIDCOM protocol: Opinions? 


> Well, to start with, please look again to my recent e-mail about the three
> types of policy management architecture I listed. Correct me if I'm wrong,
> but only one of them appears to be envisioned in the existing midcom
> requirements/proposed-architecture. 

Policy management is orthogonal to the midcom protocol.  We
assume that there's a policy component but we're not
specifying it.  What's envisioned is that there is one, but
the questions of where it's located, what policy decisions
are negotiated, and specifically what it will look like are
completely outside the scope of the current set of
deliverables.

=> 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.


> <<The Midcom protocol must allow a middlebox to communicate with more
>    than one Midcom agent simultaneously.>>
> 
> I see this as a fairly major issue, I don't believe we should restrict
> ourselves, and exclude policy management architectures which have been
> promoted by IETF in the context of the "rap" effort for several years. 

I doubt very much that you'd have luck finding *one*
participant who thinks it sufficient to have a middlebox
that's only capable of communicating with one agent.  In the
context of VoIP applications, as well as many others, it is
absolutely mandatory that more than one agent be able to
send requests to a middlebox.

=> 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. Which is precisely the reason for which I do like
the architecture being proposed as one possible legitimate construct. 
=> But I fear this assumption is too restrictive. Why should the SIP proxy
be the component speaking with the middlebox? You may have more complex
software architectures, where multiple SIP proxies will speak to a single
policy decision point (aka policy server), which is in charge of a given set
of middleboxes. Or stateful SIP proxies also acting as policy servers. Etc.
The "rap" framework explains pretty well how to make this scale and be very
resilient (e.g. strong transaction semantics, plus strong failover
properties). Then we have only one middlebox agent speaking to a given
middlebox at a given point in time. And I don't see anything wrong about
that. As one possible architecture among others.

=> again, I apologize for possibly being disruptive and making such
statements quite late in the process, but well, I can't help it!  ;-)