[midcom] Re: draft-taylor-midcom-diameter-eval-00.txt

I found this evaluation to be very sketchy.  I will try to ask some 
specific questions:

It is not at all clear to me whether the midcom agents is intended to be a 
diameter client, or server.  My understanding (and please feel free to 
correct me if I am wrong in this regard) is that Diameter, like Radius, is 
a client / server where the client sends requests to the server and 
receives responses.  Even if there are some additional reverse direction 
messages for special cases, this seems to be the predominant mode.  The 
midcom protocol predominant mode is an invocation be a midcom agent 
requesting a behavior of a middlebox.  This would lead one to the odd 
situation of expecting the midcom agent to be a diameter client, and a 
middlebox to be a diameter server.

There is a reference to AVP grouping to address the aggregation 
requirement.  As I am not particularly familiar with the Diameter details, 
it would be helpful if you mentioned whether this grouping is ad hoc (in 
which case it address the requirement thoroughly) or is defined via a 
schema / RFC / ...

On a number of the requirements, somewhat more elaboration of the Diameter 
behavior would be helpful.  Even once I know which side is the client and 
which the server, I suspect that issues of state maintenance, overlapping 
control, and related items which you feel are addressed easily could be 
described a little better.

Yours,
Joel M. Halpern

_______________________________________________
midcom mailing list
midcom@ietf.org
https://www1.ietf.org/mailman/listinfo/midcom