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

Thank you.  I did not intend to imply that you had not done your homework.
A small explanation of peer-to-peer approach taken by Diameter would go a 
long way to addressing my concerns.  If that included some coverage of the 
way Diameter views control (which might be absent completely due to the 
lack of coverage of state persistence that you mentioned) that would 
probably be helpful.

There is an awkward balance to be achieved between avoiding saying too much 
on the one hand, as otherwise we have a multiple volume tome, while still 
saying enough that those who are not experts in the individual protocols 
have enough information to form reasoned judgements.

Yours,
Joel

At 11:27 AM 4/23/2002 -0400, Tom-PT Taylor wrote:

>I'll be happy to elaborate on all aspects.  I was under the impression 
>that I had to keep things brief so the evaluation would lend itself easily 
>to incorporation in Mary's summary.  But I assure you, I did my homework 
>before checking off the requirements, and I'll prove it in a recycle of 
>the document.
>
>On a fundamental point: Diameter calls itself a peer-to-peer protocol.
>
>-----Original Message-----
>From: Joel M. Halpern 
>[<mailto:joel@stevecrocker.com>mailto:joel@stevecrocker.com]
>Sent: Tuesday, April 23, 2002 11:02 AM
>To: midcom@ietf.org
>Subject: [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>https://www1.ietf.org/mailman/listinfo/midcom 
>

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