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

"Tom-PT Taylor"<taylor@nortelnetworks.com> Tue, 23 April 2002 15:34 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23403 for <midcom-archive@odin.ietf.org>; Tue, 23 Apr 2002 11:34:24 -0400 (EDT)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA08807 for midcom-archive@odin.ietf.org; Tue, 23 Apr 2002 11:34:28 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08353; Tue, 23 Apr 2002 11:31:14 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA08321 for <midcom@ns.ietf.org>; Tue, 23 Apr 2002 11:31:11 -0400 (EDT)
Received: from zcars04e.ca.nortel.com (zcars04e.nortelnetworks.com [47.129.242.56]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23267 for <midcom@ietf.org>; Tue, 23 Apr 2002 11:31:06 -0400 (EDT)
Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04e.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g3NFR1U03137; Tue, 23 Apr 2002 11:27:01 -0400 (EDT)
Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <JCVJAB3C>; Tue, 23 Apr 2002 11:27:03 -0400
Message-ID: <4D79C746863DD51197690002A52CDA0001E8A356@zcard0kc.ca.nortel.com>
From: Tom-PT Taylor <taylor@nortelnetworks.com>
To: "'Joel M. Halpern'" <joel@stevecrocker.com>, midcom@ietf.org
Subject: RE: [midcom] Re: draft-taylor-midcom-diameter-eval-00.txt
Date: Tue, 23 Apr 2002 11:27:00 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1EADA.D09A6DDA"
Sender: midcom-admin@ietf.org
Errors-To: midcom-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <midcom.ietf.org>
X-BeenThere: midcom@ietf.org

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]
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