From owner-aaa-bof@merit.edu  Mon Apr  2 06:49:16 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA28161
	for <aaa-archive@odin.ietf.org>; Mon, 2 Apr 2001 06:49:16 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id C272F5DD9E; Mon,  2 Apr 2001 06:46:36 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id AD8275DDE2; Mon,  2 Apr 2001 06:46:36 -0400 (EDT)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by segue.merit.edu (Postfix) with ESMTP id 9C55A5DD9E
	for <aaa-wg@merit.edu>; Mon,  2 Apr 2001 06:46:34 -0400 (EDT)
Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f32AkXI13310
	for <aaa-wg@merit.edu>; Mon, 2 Apr 2001 12:46:33 +0200 (MEST)
Received: FROM esealnt743.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon Apr 02 12:46:32 2001 +0200
Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <HA3C7N8P>; Mon, 2 Apr 2001 12:46:31 +0200
Message-ID: <577066326047D41180AC00508B955DDA01D7FF4C@eestqnt104.es.eu.ericsson.se>
From: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>
To: "'Patrice Calhoun'" <pcalhoun@nasnfs.Eng.Sun.COM>,
        "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>
Cc: "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>
Subject: RE: [AAA-WG]: AAA Registration Keys for Mobile IP?
Date: Mon, 2 Apr 2001 12:46:21 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

See comments.

> > However, if the MN sends a MN-HA Key Request (section 7)
> > including a preferred SPI to be used between the MN and the 
> HA, how can it
> > be sent to the AAAH? It does not seem to exist any AVP for 
> that in the
> > Diameter Mobile-IP protocol. Can that subtype be used at 
> all within the AAA
> > infrastucture meaningfully?
> 
> hmmmm.... it doesn't appear to be used in Diameter. I am at a 
> bit of a loss.
> So, we can either create a new AVP, if we believe this is 
> useful, or eliminate
> the field from the Mobile IP extension. 

Well, I'm not sure, but I guess that creating a new AVP to
support the suggested SPI would be as useful (or useless) as
the ones suggested for use between other MIP entities, right?
I think we should add a new AVP, if you think that the other
"suggested" SPI attributes sent by the MN can be useful at all.

Martin



From owner-aaa-bof@merit.edu  Mon Apr  2 13:54:07 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA23238
	for <aaa-archive@odin.ietf.org>; Mon, 2 Apr 2001 13:54:07 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id E63015DD9D; Mon,  2 Apr 2001 13:53:50 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id CD5BD5DD93; Mon,  2 Apr 2001 13:53:49 -0400 (EDT)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id 4A8A65DD91
	for <aaa-wg@merit.edu>; Mon,  2 Apr 2001 13:53:48 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA19258;
	Mon, 2 Apr 2001 10:53:34 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA07420;
	Mon, 2 Apr 2001 10:53:33 -0700 (PDT)
Received: from darius (darius [10.6.84.105])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id KAA26018;
	Mon, 2 Apr 2001 10:53:26 -0700 (PDT)
Date: Mon, 2 Apr 2001 10:53:24 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Subject: RE: [AAA-WG]: AAA WG Interim meeting dates
To: Bernard Aboba <aboba@internaut.com>
Cc: "Aaa-Wg@Merit. Edu" <aaa-wg@merit.edu>
In-Reply-To: "Your message with ID" <OJEJKOMOEAKLMOILFCPJEEAJEFAA.aboba@internaut.com>
Message-ID: <Roam.SIMC.2.0.6.986234004.25905.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

I can make those dates, but I question whether the meeting is simply too far
off. We need to get these documents through WG last call as soon as possible.
I expect to have -02 by the end of the week. At that point, features are
frozen, but I am not sure that I will have received the updated state machine.

So if I do have the new state machine, I would propose a WG last call. A
future meeting could still be held, but only as a document reading party, and
changes would be limited to bug fixing, and grammar.

Having said that, I believe that having the interim meeting in a month an a
half is simply too far off :(

PatC
> As Bert Wijnen has recently noted, NANOG 22 and 
> OPS-NM Interim will be in Scottsdale Arizona, USA, 
> in the Doubltree Paradise Valley, as follows:
> 
>   May 20-22   NANOG 22, ends around 3pm on 22nd
> 
>   May 22-23  OPS-NM Interim, starts on 22nd 4pm 
>                     So we plan to meet 4-6pm, 8-10pm on 22nd
>                     9-1pm 23rd possibly 2-4pm 23rd too.
> 
> 
> It has been suggested that we might consider having the
> AAA Interim meeting at the same location, scheduled
> on May 18-19, 2001. 
> 
> How would this work?
> 





From owner-aaa-bof@merit.edu  Mon Apr  2 13:59:58 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA23499
	for <aaa-archive@odin.ietf.org>; Mon, 2 Apr 2001 13:59:57 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id B2B835DD91; Mon,  2 Apr 2001 13:59:38 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id A05065DD93; Mon,  2 Apr 2001 13:59:38 -0400 (EDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by segue.merit.edu (Postfix) with ESMTP id 309CF5DD91
	for <aaa-wg@merit.edu>; Mon,  2 Apr 2001 13:59:37 -0400 (EDT)
Received: from mira-sjc5-1.cisco.com (mira-sjc5-1.cisco.com [171.71.163.15])
	by sj-msg-core-3.cisco.com (8.9.3/8.9.1) with ESMTP id KAA18431;
	Mon, 2 Apr 2001 10:58:19 -0700 (PDT)
Received: from jtrostle-nt2 (dhcp-128-107-141-177.cisco.com [128.107.141.177])
	by mira-sjc5-1.cisco.com (Mirapoint)
	with SMTP id AAH01273;
	Mon, 2 Apr 2001 10:52:31 -0700 (PDT)
Message-Id: <4.1.20010402095558.015c97b0@mira-sjc5-1>
X-Sender: jtrostle@mira-sjc5-1
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Mon, 02 Apr 2001 09:56:20 -0700
To: "Bernard Aboba" <aboba@internaut.com>,
        "Aaa-Wg@Merit. Edu" <aaa-wg@merit.edu>
From: Jonathan Trostle <jtrostle@cisco.com>
Subject: RE: [AAA-WG]: AAA WG Interim meeting dates
In-Reply-To: <OJEJKOMOEAKLMOILFCPJEEAJEFAA.aboba@internaut.com>
References: <NDBBIHMPILAAGDHPCIOPAENKDFAA.gwz@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Probably can't make that date.

Jonathan


At 10:33 AM 4/2/01 -0700, Bernard Aboba wrote:
>As Bert Wijnen has recently noted, NANOG 22 and 
>OPS-NM Interim will be in Scottsdale Arizona, USA, 
>in the Doubltree Paradise Valley, as follows:
>
>  May 20-22   NANOG 22, ends around 3pm on 22nd
>
>  May 22-23  OPS-NM Interim, starts on 22nd 4pm 
>                    So we plan to meet 4-6pm, 8-10pm on 22nd
>                    9-1pm 23rd possibly 2-4pm 23rd too.
>
>
>It has been suggested that we might consider having the
>AAA Interim meeting at the same location, scheduled
>on May 18-19, 2001. 
>
>How would this work?
>




From owner-aaa-bof@merit.edu  Mon Apr  2 15:34:02 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA27067
	for <aaa-archive@odin.ietf.org>; Mon, 2 Apr 2001 15:34:00 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 693915DE2D; Mon,  2 Apr 2001 13:32:16 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 5864A5DE2B; Mon,  2 Apr 2001 13:32:16 -0400 (EDT)
Received: from gate.internaut.com (unknown [64.38.134.101])
	by segue.merit.edu (Postfix) with ESMTP id 5C1795DE27
	for <aaa-wg@merit.edu>; Mon,  2 Apr 2001 13:32:14 -0400 (EDT)
Received: from e1kj2 (e1kj2 [64.38.134.109])
	by gate.internaut.com (8.10.2/8.10.2) with SMTP id f32HMBN27147
	for <aaa-wg@merit.edu>; Mon, 2 Apr 2001 10:22:12 -0700
From: "Bernard Aboba" <aboba@internaut.com>
To: "Aaa-Wg@Merit. Edu" <aaa-wg@merit.edu>
Subject: RE: [AAA-WG]: AAA WG Interim meeting dates
Date: Mon, 2 Apr 2001 10:33:27 -0700
Message-ID: <OJEJKOMOEAKLMOILFCPJEEAJEFAA.aboba@internaut.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-reply-to: <NDBBIHMPILAAGDHPCIOPAENKDFAA.gwz@cisco.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

As Bert Wijnen has recently noted, NANOG 22 and 
OPS-NM Interim will be in Scottsdale Arizona, USA, 
in the Doubltree Paradise Valley, as follows:

  May 20-22   NANOG 22, ends around 3pm on 22nd

  May 22-23  OPS-NM Interim, starts on 22nd 4pm 
                    So we plan to meet 4-6pm, 8-10pm on 22nd
                    9-1pm 23rd possibly 2-4pm 23rd too.


It has been suggested that we might consider having the
AAA Interim meeting at the same location, scheduled
on May 18-19, 2001. 

How would this work?



From owner-aaa-bof@merit.edu  Mon Apr  2 16:19:28 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA29038
	for <aaa-archive@odin.ietf.org>; Mon, 2 Apr 2001 16:19:28 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 702CC5DEE5; Mon,  2 Apr 2001 16:13:58 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 524875DEA6; Mon,  2 Apr 2001 16:13:58 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id EC72D5DEE5
	for <aaa-wg@merit.edu>; Mon,  2 Apr 2001 16:12:45 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA21052;
	Mon, 2 Apr 2001 13:12:32 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA01231;
	Mon, 2 Apr 2001 13:12:31 -0700 (PDT)
Received: from darius (darius [10.6.84.105])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id NAA28161;
	Mon, 2 Apr 2001 13:12:25 -0700 (PDT)
Date: Mon, 2 Apr 2001 13:12:24 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Subject: RE: [diameter] Re: [AAA-WG]: Diameter Issues found @ Connectathon
To: Mark Jones <mjones@bridgewatersystems.com>
Cc: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>,
        David Spence <DSpence@Interlinknetworks.com>, aaa-wg@merit.edu,
        diameter@diameter.org
In-Reply-To: "Your message with ID" <004401c0b968$d9f25a90$2096a8c0@mjones.bridgewatersys.com>
Message-ID: <Roam.SIMC.2.0.6.986242344.2078.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> It seems obvious to me too but I see a loophole in the current drafts since
> the command specification in the extension documents contain "* [ AVP ]" to
> indicate that any other AVP may be present (including a mandatory
> vendor-specific AVP). I dislike conformance battles with other vendors so
> how about adding the following text to the Extension-Id AVP description to
> keep us honest:
> 
> "A Diameter peer that includes an Extension-Id AVP in the DRI SHALL support
> the functionality described in the associated extension using only the
> commands defined in the extension and without the addition of mandatory
> vendor-specific AVPs."

That sounds a little harsh, but what does the WG think about Mark's proposed
text?

PatC




From owner-aaa-bof@merit.edu  Mon Apr  2 16:49:08 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA00458
	for <aaa-archive@odin.ietf.org>; Mon, 2 Apr 2001 16:49:07 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 0AFE35DEBA; Mon,  2 Apr 2001 16:47:47 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id EBE7B5DEB2; Mon,  2 Apr 2001 16:47:46 -0400 (EDT)
Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103])
	by segue.merit.edu (Postfix) with ESMTP id 338E35DEAB
	for <aaa-wg@merit.edu>; Mon,  2 Apr 2001 16:47:45 -0400 (EDT)
Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate3.mot.com (motgate3 2.1) with ESMTP id NAA06280 for <aaa-wg@merit.edu>; Mon, 2 Apr 2001 13:42:20 -0700 (MST)]
Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id NAA12922 for <aaa-wg@merit.edu>; Mon, 2 Apr 2001 13:42:34 -0700 (MST)]
Received: by IL75EXM04 with Internet Mail Service (5.5.2653.19)
	id <2C0982X5>; Mon, 2 Apr 2001 15:47:43 -0500
Message-ID: <BB60654DFAA8D311B16400508B6F2538047C60F4@il27exm05.cig.mot.com>
From: Cain Brian-BCAIN1 <Brian.Cain@motorola.com>
To: aaa-wg@merit.edu
Subject: [AAA-WG]: Java API, draft-kempf-diameter-api-04.txt
Date: Mon, 2 Apr 2001 15:47:43 -0500 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

James, et al.

Here are some additional notes on the Java API...
 
>5.3.1.5   Instance Methods
>...
>   public int getStatusCode()
>
>   Return the message's status code
>

Do we really need this method now that we have the Result-Code AVP?

...
>      public java.util.Map getAVPMap()
>
>   Returns a Map of AVP objects for the message. Keys are the AVP names.

This is one of several places where strings are used as keys for lookups.
Since the AVP names probably aren't standardized, wouldn't it be a better
idea
to use the (Vendor-Id, AVP-code) pair as a key to prevent collisions?

...
>     public AAAMessage[]
>       synchronized send(int sessionId,InetAddress[] recipients)
>       throws AAAException
>
>  Send this message to the session identified by the session id, wait
>  for return messages, and return them as an array. The outgoing
...
>  Exceptions thrown:
>
>     AAAException - Thrown with one of the following error codes:
>                    FAILURE, SECURITY, UNKNOWN_CMD, MISSING_AVP,
>                    TIMED_OUT, CANNOT_SEND_MSG, NETWORK_ERROR,
>                    SESSION_INVALID.

Please excuse me if this is clearly stated somewhere in Base protocol... 
"wait for return messages": is this plural only because there could be
multiple
recipients? Or is it also possible to receive multiple responses for one
message?  

Also, in the case of n recipients, x fail, y succeed. If we throw an
exception,
none of the y valid responses will ever get to the API client, right? Is
this an
acceptable risk?

~~~~~
(from 5.2.6.4)
>     public static
>       AAAExtensionDescriptor registerExtension(int code,
>                                                java.lang.String name,
>                                                java.lang.String
vendorName)
...
>     public AAACommandDescriptor
>       registerCommand(int code,
>                       java.lang.String name,
>                       java.util.Collection mandatoryAVPNames)
>

 It would probably be desirable for those who use the API to not have to
write new
code in order to make the library aware of new commands. My point is that
extensions
and commands would be static enough to put in configuration files like the
AVPs. Though
the .INI format probably does not lend well to a command definition file; I
guess that's more encouragement to jump to something like XML/SMIng?

~~~~~
(from 5.2.1.3)
>  The following constants are used for AVPDescriptor flags:
>
>     public static final int EMPTY_FLAG              = 0x00000
>     public static final int MANDATORY_FLAG          = 0x00001
-     public static final int RESERVED_FLAG           = 0x00002
+     public static final int RESERVED_MASK           = 0x0FFEA
>     public static final int VENDOR_SPECIFIC_FLAG    = 0x00004
>     public static final int END_TO_END_ENCRYPT_FLAG = 0x00010

Instead of "public int flags" (and the static ints above), I would suggest
"isMandatory(), isVendorSpecific(), and isEncryptable()" methods for the
AVPDescriptor.  I think there is some value in separating the actual flags
sent over the wire from the characteristics of a dictionary entry.  AVP
could have the method "setEncryptedFlag(boolean)", and if it were necessary
to allow access to all of the flags, "setFlags(int)" could be added.

-Brian



From owner-aaa-bof@merit.edu  Mon Apr  2 17:42:54 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA02185
	for <aaa-archive@odin.ietf.org>; Mon, 2 Apr 2001 17:42:53 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id E51015DE18; Mon,  2 Apr 2001 17:41:33 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id C175A5DEA0; Mon,  2 Apr 2001 17:41:33 -0400 (EDT)
Received: from mx.databus.com (p101-44.acedsl.com [160.79.101.44])
	by segue.merit.edu (Postfix) with ESMTP id 15F2F5DE18
	for <aaa-wg@merit.edu>; Mon,  2 Apr 2001 17:41:32 -0400 (EDT)
Received: (from barney@localhost)
	by mx.databus.com (8.11.1/8.11.1) id f32LfV097379
	for aaa-wg@merit.edu; Mon, 2 Apr 2001 17:41:31 -0400 (EDT)
	(envelope-from barney)
Date: Mon, 2 Apr 2001 17:41:31 -0400
From: Barney Wolff <barney@databus.com>
To: aaa-wg@merit.edu
Subject: [AAA-WG]: name conflict
Message-ID: <20010402174131.B97234@mx.databus.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

See, we shoulda stuck with all caps.
Barney
----- Forwarded message from NewsScan <newsscan@newsscan.com> -----

DOUBLECLICK TARGETS TRADITIONAL ADVERTISERS
DoubleClick is launching a new research division with an eye toward 
attracting more traditional advertisers to the Internet. The new group, 
called Diameter, will seek to shift attention away from "click-through" 
rates and instead focus on measurement techniques for determining 
consumers' purchasing power and brand awareness. Diameters activities 
include surveying 40,000 U.S. adult Web users on their Internet activity to 
create demographic profiles, and tracking the online behavior of 1.5 
million users to create a "buying power" index. It also has designed a way 
to measure brand awareness that compares how often a user sees an ad with 
how aware they are of the advertiser's name. "People are looking for proof 
of what the Internet can deliver," says Diameter's general manager. "This 
is a step forward for new advertisers who have not gotten [online] yet to 
get onboard." (Financial Times 2 Apr 2001)
http://news.ft.com/news/industries/media



From owner-aaa-bof@merit.edu  Mon Apr  2 23:00:26 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA08919
	for <aaa-archive@odin.ietf.org>; Mon, 2 Apr 2001 23:00:26 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 9A62C5DE35; Sun,  1 Apr 2001 15:19:57 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 88CEF5DE2B; Sun,  1 Apr 2001 15:19:57 -0400 (EDT)
Received: from gate.internaut.com (unknown [64.38.134.101])
	by segue.merit.edu (Postfix) with ESMTP id A99C45DDE9
	for <aaa-wg@merit.edu>; Sun,  1 Apr 2001 15:19:55 -0400 (EDT)
Received: from e1kj2 (e1kj2 [64.38.134.109])
	by gate.internaut.com (8.10.2/8.10.2) with SMTP id f31J9wN23216
	for <aaa-wg@merit.edu>; Sun, 1 Apr 2001 12:09:58 -0700
From: "Bernard Aboba" <aboba@internaut.com>
To: "Aaa-Wg@Merit. Edu" <aaa-wg@merit.edu>
Subject: [AAA-WG]: 2nd REQUEST: IETF 50 meeting minutes and presentations...
Date: Sun, 1 Apr 2001 12:21:06 -0700
Message-ID: <OJEJKOMOEAKLMOILFCPJOEPDEEAA.aboba@internaut.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

We're in the process of assembling the minutes and presentations
from IETF 50.

So if you haven't already sent minutes or presentations to myself
and Dave, please do so now.

Thanks in advance! 



From owner-aaa-bof@merit.edu  Tue Apr  3 06:55:38 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA26005
	for <aaa-archive@odin.ietf.org>; Tue, 3 Apr 2001 06:55:38 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id EFC225DDAE; Tue,  3 Apr 2001 06:55:22 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id DE7665DDAD; Tue,  3 Apr 2001 06:55:22 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 7776C5DD9C
	for <aaa-wg@merit.edu>; Tue,  3 Apr 2001 06:55:21 -0400 (EDT)
Received: from gwzpc (shinjuku-equant-dynamic41.cisco.com [64.104.42.41]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id DAA02820; Tue, 3 Apr 2001 03:53:25 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Jonathan Trostle" <jtrostle@cisco.com>,
        "Bernard Aboba" <aboba@internaut.com>,
        "Aaa-Wg@Merit. Edu" <aaa-wg@merit.edu>
Subject: RE: [AAA-WG]: AAA WG Interim meeting dates
Date: Tue, 3 Apr 2001 03:53:24 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPOEFDDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <4.1.20010402095558.015c97b0@mira-sjc5-1>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Didn't get the original of this...

> Probably can't make that date.
> 
> Jonathan
> 
> 
> At 10:33 AM 4/2/01 -0700, Bernard Aboba wrote:
> >As Bert Wijnen has recently noted, NANOG 22 and 
> >OPS-NM Interim will be in Scottsdale Arizona, USA, 
> >in the Doubltree Paradise Valley, as follows:
> >
> >  May 20-22   NANOG 22, ends around 3pm on 22nd
> >
> >  May 22-23  OPS-NM Interim, starts on 22nd 4pm 
> >                    So we plan to meet 4-6pm, 8-10pm on 22nd
> >                    9-1pm 23rd possibly 2-4pm 23rd too.
> >
> >
> >It has been suggested that we might consider having the
> >AAA Interim meeting at the same location, scheduled
> >on May 18-19, 2001. 

I can't make the 18th and Outlook tells me the 18th is a Saturday :-(

> >
> >How would this work?
> >
> 
> 
> 



From owner-aaa-bof@merit.edu  Tue Apr  3 10:00:09 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01235
	for <aaa-archive@odin.ietf.org>; Tue, 3 Apr 2001 10:00:08 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 36AF25DE79; Tue,  3 Apr 2001 09:32:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 1B8765DE7C; Tue,  3 Apr 2001 09:32:29 -0400 (EDT)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id D3FD55DE79
	for <aaa-wg@merit.edu>; Tue,  3 Apr 2001 09:32:27 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA29795;
	Tue, 3 Apr 2001 06:32:15 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA27187;
	Tue, 3 Apr 2001 06:32:15 -0700 (PDT)
Received: from darius (darius [10.6.84.105])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id GAA07684;
	Tue, 3 Apr 2001 06:32:13 -0700 (PDT)
Date: Tue, 3 Apr 2001 06:32:11 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Subject: RE: [AAA-WG]: AAA WG Interim meeting dates
To: gwz@cisco.com
Cc: Jonathan Trostle <jtrostle@cisco.com>, Bernard Aboba <aboba@internaut.com>,
        "Aaa-Wg@Merit. Edu" <aaa-wg@merit.edu>
In-Reply-To: "Your message with ID" <NDBBIHMPILAAGDHPCIOPOEFDDGAA.gwz@cisco.com>
Message-ID: <Roam.SIMC.2.0.6.986304731.17701.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk


> > >It has been suggested that we might consider having the
> > >AAA Interim meeting at the same location, scheduled
> > >on May 18-19, 2001. 
> 
> I can't make the 18th and Outlook tells me the 18th is a Saturday :-(

No, it's a Friday, but the 19th *is* a Saturday. Perhaps trying to squeeze in
that week isn't really worth it. Could we please go back to the original dates
(and place)?

PatC




From owner-aaa-bof@merit.edu  Tue Apr  3 10:00:26 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01255
	for <aaa-archive@odin.ietf.org>; Tue, 3 Apr 2001 10:00:26 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id A740E5DD9C; Tue,  3 Apr 2001 09:26:18 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 949315DDB1; Tue,  3 Apr 2001 09:26:18 -0400 (EDT)
Received: from mail01.bridgewatersystems.com (mail01.bridgewatersystems.com [216.113.7.9])
	by segue.merit.edu (Postfix) with ESMTP id B6DC35DD9C
	for <aaa-wg@merit.edu>; Tue,  3 Apr 2001 09:26:16 -0400 (EDT)
Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2])
	by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id KAA22969;
	Tue, 3 Apr 2001 10:22:32 -0400
Received: from preston (cisconas245.bridgewatersys.com [192.168.150.245])
	by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.1) with SMTP id JAA17991;
	Tue, 3 Apr 2001 09:26:49 -0400 (EDT)
From: "Mark Jones" <mjones@bridgewatersystems.com>
To: "Fredrik Johansson" <fredrik.johansson@ipunplugged.com>,
        "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>
Cc: "David Spence" <DSpence@Interlinknetworks.com>, <aaa-wg@merit.edu>,
        <diameter@diameter.org>
Subject: RE: [diameter] Re: [AAA-WG]: Diameter Issues found @ Connectathon
Date: Tue, 3 Apr 2001 09:28:02 -0400
Message-ID: <NDBBJMCEELAEBHDMEKELGEPACBAA.mjones@bridgewatersystems.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-reply-to: <MJEMJBGGCLLDLFFAHLJKIEDGCJAA.fredrik.johansson@ipunplugged.com>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Fredrik,

> I don't like the proposed text. If a vendor would like to add a
> mandator avp
> it will not necessarily cause interoperability problems since the
> receiving
> node will responde with a MRI with a failed avp indicating what was not
> understood. It is then up to the sender to make the decision to
> try without
> that avp if it is willing to let the user have the service
> without the extra
> feature provided by the mandatory avp.
>

My text was not intended to prohibit what you suggest. A peer could still
send a message with vendor-specific AVPs, get back an MRI and re-send the
message containing only the AVPs described in the associated extension. In
this case, the sender does still "support the functionality described in the
associated extension using only the commands defined in the extension and
without the addition of mandatory vendor-specific AVPs". But in addition, it
supports a vendor enhanced version and tries that one first.

Does the following text help clarify my intentions?

   A Diameter peer that includes an Extension-Id AVP in the DRI SHALL
support
   the functionality described in the associated extension using only the
   commands defined in the extension and without the addition of mandatory
   vendor-specific AVPs. The same Diameter peer MAY suppport a
vendor-specific
   version of the functionality in addition to but not instead of that
described
   in the extension.

BTW, in your example, if the receiver did not understand AVPs from vendor
[x], it would not have advertised support for vendor [x] (using
Supported-Vendor-Id=[x]) in its DRI. This AVP should significantly reduce
the number of MRIs being sent.

Regards,
       Mark




From owner-aaa-bof@merit.edu  Tue Apr  3 10:19:28 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01914
	for <aaa-archive@odin.ietf.org>; Tue, 3 Apr 2001 10:19:28 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 7B8E75DDCD; Tue,  3 Apr 2001 10:15:45 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 3D7245DDC5; Tue,  3 Apr 2001 10:15:45 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id CE7785DE68
	for <aaa-wg@merit.edu>; Tue,  3 Apr 2001 10:15:37 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA01164;
	Tue, 3 Apr 2001 07:15:25 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA25373;
	Tue, 3 Apr 2001 07:15:24 -0700 (PDT)
Received: from darius (darius [10.6.84.105])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id HAA08024;
	Tue, 3 Apr 2001 07:15:22 -0700 (PDT)
Date: Tue, 3 Apr 2001 07:15:20 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Subject: RE: [diameter] Re: [AAA-WG]: Diameter Issues found @ Connectathon
To: Fredrik Johansson <fredrik.johansson@ipunplugged.com>
Cc: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>,
        Mark Jones <mjones@bridgewatersystems.com>,
        David Spence <DSpence@Interlinknetworks.com>, aaa-wg@merit.edu,
        diameter@diameter.org
In-Reply-To: "Your message with ID" <MJEMJBGGCLLDLFFAHLJKIEDGCJAA.fredrik.johansson@ipunplugged.com>
Message-ID: <Roam.SIMC.2.0.6.986307320.4134.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

My thoughts too, but remember that if you send a standards track command, with
a vendor-specific AVP marked Mandatory, you will ONLY interoperate with
yourself.

PatC
> I don't like the proposed text. If a vendor would like to add a mandator avp
> it will not necessarily cause interoperability problems since the receiving
> node will responde with a MRI with a failed avp indicating what was not
> understood. It is then up to the sender to make the decision to try without
> that avp if it is willing to let the user have the service without the extra
> feature provided by the mandatory avp.
> 
> /Fredrik
> 
> >-----Original Message-----
> >From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf
> >Of Patrice Calhoun
> >Sent: den 2 april 2001 22:12
> >To: Mark Jones
> >Cc: Patrice Calhoun; David Spence; aaa-wg@merit.edu;
> >diameter@diameter.org
> >Subject: RE: [diameter] Re: [AAA-WG]: Diameter Issues found @
> >Connectathon
> >
> >
> >> It seems obvious to me too but I see a loophole in the current
> >drafts since
> >> the command specification in the extension documents contain "*
> >[ AVP ]" to
> >> indicate that any other AVP may be present (including a mandatory
> >> vendor-specific AVP). I dislike conformance battles with other vendors so
> >> how about adding the following text to the Extension-Id AVP
> >description to
> >> keep us honest:
> >>
> >> "A Diameter peer that includes an Extension-Id AVP in the DRI
> >SHALL support
> >> the functionality described in the associated extension using only the
> >> commands defined in the extension and without the addition of mandatory
> >> vendor-specific AVPs."
> >
> >That sounds a little harsh, but what does the WG think about
> >Mark's proposed
> >text?
> >
> >PatC
> >
> 





From owner-aaa-bof@merit.edu  Tue Apr  3 10:26:26 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02172
	for <aaa-archive@odin.ietf.org>; Tue, 3 Apr 2001 10:26:26 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id A45B45DEDE; Tue,  3 Apr 2001 10:22:08 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 7A4235DEFF; Tue,  3 Apr 2001 10:22:08 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id B92015DEB7
	for <aaa-wg@merit.edu>; Tue,  3 Apr 2001 10:22:06 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA04198;
	Tue, 3 Apr 2001 07:21:58 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA26228;
	Tue, 3 Apr 2001 07:21:58 -0700 (PDT)
Received: from darius (darius [10.6.84.105])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id HAA08126;
	Tue, 3 Apr 2001 07:21:54 -0700 (PDT)
Date: Tue, 3 Apr 2001 07:21:53 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Subject: RE: [diameter] Re: [AAA-WG]: Diameter Issues found @ Connectathon
To: Mark Jones <mjones@bridgewatersystems.com>
Cc: Fredrik Johansson <fredrik.johansson@ipunplugged.com>,
        Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>,
        David Spence <DSpence@Interlinknetworks.com>, aaa-wg@merit.edu,
        diameter@diameter.org
In-Reply-To: "Your message with ID" <NDBBJMCEELAEBHDMEKELGEPACBAA.mjones@bridgewatersystems.com>
Message-ID: <Roam.SIMC.2.0.6.986307713.30859.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> My text was not intended to prohibit what you suggest. A peer could still
> send a message with vendor-specific AVPs, get back an MRI and re-send the
> message containing only the AVPs described in the associated extension. In
> this case, the sender does still "support the functionality described in the
> associated extension using only the commands defined in the extension and
> without the addition of mandatory vendor-specific AVPs". But in addition, it
> supports a vendor enhanced version and tries that one first.

But you specifically wanted text in the Extension-Id that would prevent a
manufacturer from advertising the extension in question if they did the above.


PatC




From owner-aaa-bof@merit.edu  Tue Apr  3 10:49:09 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA03069
	for <aaa-archive@odin.ietf.org>; Tue, 3 Apr 2001 10:49:09 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 109155DDC5; Tue,  3 Apr 2001 10:45:15 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 96E8A5DDC9; Tue,  3 Apr 2001 10:45:14 -0400 (EDT)
Received: from mail01.bridgewatersystems.com (mail01.bridgewatersystems.com [216.113.7.9])
	by segue.merit.edu (Postfix) with ESMTP id BB80C5DDB1
	for <aaa-wg@merit.edu>; Tue,  3 Apr 2001 10:45:08 -0400 (EDT)
Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2])
	by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id LAA24015;
	Tue, 3 Apr 2001 11:41:29 -0400
Received: from preston (cisconas245.bridgewatersys.com [192.168.150.245])
	by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.1) with SMTP id KAA21138;
	Tue, 3 Apr 2001 10:45:46 -0400 (EDT)
From: "Mark Jones" <mjones@bridgewatersystems.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>,
        "Mark Jones" <mjones@bridgewatersystems.com>
Cc: "Fredrik Johansson" <fredrik.johansson@ipunplugged.com>,
        "David Spence" <DSpence@Interlinknetworks.com>, <aaa-wg@merit.edu>,
        <diameter@diameter.org>
Subject: RE: [diameter] Re: [AAA-WG]: Diameter Issues found @ Connectathon
Date: Tue, 3 Apr 2001 10:47:00 -0400
Message-ID: <NDBBJMCEELAEBHDMEKELAEPCCBAA.mjones@bridgewatersystems.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-reply-to: <Roam.SIMC.2.0.6.986307713.30859.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

> But you specifically wanted text in the Extension-Id that would prevent a
> manufacturer from advertising the extension in question if they
> did the above.
>

No. The text I proposed was intended to prohibit advertising an extension id
if the sender ONLY supported the extension through the use of additional
mandatory vendor-specific AVPs.

For example, if a Diameter peer is capable of operating in two modes: basic
(using extension draft commands/AVPs only) and enhanced (using additional
mandatory vendor-specific AVPs) then it should be able to advertise support
of the extension. If is only supports the enhanced mode then it should not
advertise support for the extension.

Regards,
       Mark




From owner-aaa-bof@merit.edu  Tue Apr  3 10:59:21 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA03306
	for <aaa-archive@odin.ietf.org>; Tue, 3 Apr 2001 10:59:21 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 665475DE06; Tue,  3 Apr 2001 10:59:04 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 472FB5DE23; Tue,  3 Apr 2001 10:59:04 -0400 (EDT)
Received: from mailgw.local.ipunplugged.com (unknown [213.88.134.217])
	by segue.merit.edu (Postfix) with ESMTP id 930AB5DE06
	for <aaa-wg@merit.edu>; Tue,  3 Apr 2001 10:59:01 -0400 (EDT)
Received: from fredrikj (a25.local.ipunplugged.com [192.168.4.195])
	by mailgw.local.ipunplugged.com (8.9.3/8.9.3) with SMTP id RAA00653;
	Tue, 3 Apr 2001 17:00:25 +0200
From: "Fredrik Johansson" <fredrik.johansson@ipunplugged.com>
To: "Mark Jones" <mjones@bridgewatersystems.com>,
        "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>
Cc: "David Spence" <DSpence@Interlinknetworks.com>, <aaa-wg@merit.edu>,
        <diameter@diameter.org>
Subject: RE: [diameter] Re: [AAA-WG]: Diameter Issues found @ Connectathon
Date: Tue, 3 Apr 2001 17:00:54 +0200
Message-ID: <MJEMJBGGCLLDLFFAHLJKOEDOCJAA.fredrik.johansson@ipunplugged.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <NDBBJMCEELAEBHDMEKELAEPCCBAA.mjones@bridgewatersystems.com>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

but if it require the special avp to be present from certain users but not
all, what should be advertised then?

/Fredrik

>-----Original Message-----
>From: Mark Jones [mailto:mjones@bridgewatersystems.com]
>Sent: den 3 april 2001 16:47
>To: Patrice Calhoun; Mark Jones
>Cc: Fredrik Johansson; David Spence; aaa-wg@merit.edu;
>diameter@diameter.org
>Subject: RE: [diameter] Re: [AAA-WG]: Diameter Issues found @
>Connectathon
>
>
>> But you specifically wanted text in the Extension-Id that would prevent a
>> manufacturer from advertising the extension in question if they
>> did the above.
>>
>
>No. The text I proposed was intended to prohibit advertising an
>extension id
>if the sender ONLY supported the extension through the use of additional
>mandatory vendor-specific AVPs.
>
>For example, if a Diameter peer is capable of operating in two modes: basic
>(using extension draft commands/AVPs only) and enhanced (using additional
>mandatory vendor-specific AVPs) then it should be able to advertise support
>of the extension. If is only supports the enhanced mode then it should not
>advertise support for the extension.
>
>Regards,
>       Mark




From owner-aaa-bof@merit.edu  Tue Apr  3 11:24:37 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA04228
	for <aaa-archive@odin.ietf.org>; Tue, 3 Apr 2001 11:24:36 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 54DFF5DE7F; Tue,  3 Apr 2001 11:19:37 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id E92FE5DECF; Tue,  3 Apr 2001 11:19:33 -0400 (EDT)
Received: from mail01.bridgewatersystems.com (mail01.bridgewatersystems.com [216.113.7.9])
	by segue.merit.edu (Postfix) with ESMTP id B60D95DE81
	for <aaa-wg@merit.edu>; Tue,  3 Apr 2001 11:18:24 -0400 (EDT)
Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2])
	by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id MAA24601;
	Tue, 3 Apr 2001 12:14:46 -0400
Received: from preston (cisconas245.bridgewatersys.com [192.168.150.245])
	by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.1) with SMTP id LAA22467;
	Tue, 3 Apr 2001 11:19:03 -0400 (EDT)
From: "Mark Jones" <mjones@bridgewatersystems.com>
To: "Fredrik Johansson" <fredrik.johansson@ipunplugged.com>,
        "Mark Jones" <mjones@bridgewatersystems.com>,
        "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>
Cc: "David Spence" <DSpence@Interlinknetworks.com>, <aaa-wg@merit.edu>,
        <diameter@diameter.org>
Subject: RE: [diameter] Re: [AAA-WG]: Diameter Issues found @ Connectathon
Date: Tue, 3 Apr 2001 11:20:16 -0400
Message-ID: <NDBBJMCEELAEBHDMEKELIEPCCBAA.mjones@bridgewatersystems.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-reply-to: <MJEMJBGGCLLDLFFAHLJKOEDOCJAA.fredrik.johansson@ipunplugged.com>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

> but if it require the special avp to be present from certain users but not
> all, what should be advertised then?

If the device requires a MANDATORY vendor-specific AVP (="special AVP") in
order to support the functionality described in an extension (for a single
user or all users) then it SHALL not advertise support for the extension id.

Regards,
       Mark




From owner-aaa-bof@merit.edu  Tue Apr  3 11:28:07 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA04356
	for <aaa-archive@odin.ietf.org>; Tue, 3 Apr 2001 11:28:06 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 1FE1A5DDD7; Tue,  3 Apr 2001 11:27:33 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 06AD45DE07; Tue,  3 Apr 2001 11:27:33 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id B19875DDD7
	for <aaa-wg@merit.edu>; Tue,  3 Apr 2001 11:27:31 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA04976;
	Tue, 3 Apr 2001 08:25:24 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA06874;
	Tue, 3 Apr 2001 08:25:08 -0700 (PDT)
Received: from darius (darius [10.6.84.105])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id IAA08835;
	Tue, 3 Apr 2001 08:25:06 -0700 (PDT)
Date: Tue, 3 Apr 2001 08:25:05 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Subject: RE: [AAA-WG]: Base Session State Machine
To: Fredrik Johansson <fredrik.johansson@ipunplugged.com>
Cc: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>,
        AAA Listan <aaa-wg@merit.edu>
In-Reply-To: "Your message with ID" <MJEMJBGGCLLDLFFAHLJKKEDPCJAA.fredrik.johansson@ipunplugged.com>
Message-ID: <Roam.SIMC.2.0.6.986311505.23501.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk


> will you clarify that in the session state machine.
> 
> current version:
> Discon    STR Received                   Discon.    Closed
>                                          user/device
> 
> Suggestion:
> Discon    STR Received                   Discon.    Closed
>                                          user/device
>                                          Send STA

Actually, the correct state is the following (Disc. user/device was a cut and
paste error):

Discon    STR Received                   Send STA   Closed

PatC




From owner-aaa-bof@merit.edu  Tue Apr  3 11:28:30 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA04372
	for <aaa-archive@odin.ietf.org>; Tue, 3 Apr 2001 11:28:30 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 8649D5DE16; Tue,  3 Apr 2001 11:27:42 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 470A25DE19; Tue,  3 Apr 2001 11:27:42 -0400 (EDT)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id 1B6CA5DE16
	for <aaa-wg@merit.edu>; Tue,  3 Apr 2001 11:27:39 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA06349;
	Tue, 3 Apr 2001 08:27:34 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA07329;
	Tue, 3 Apr 2001 08:27:34 -0700 (PDT)
Received: from darius (darius [10.6.84.105])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id IAA08857;
	Tue, 3 Apr 2001 08:27:27 -0700 (PDT)
Date: Tue, 3 Apr 2001 08:27:26 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Subject: RE: [diameter] Re: [AAA-WG]: Diameter Issues found @ Connectathon
To: Mark Jones <mjones@bridgewatersystems.com>
Cc: Fredrik Johansson <fredrik.johansson@ipunplugged.com>,
        Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>,
        David Spence <DSpence@Interlinknetworks.com>, aaa-wg@merit.edu,
        diameter@diameter.org
In-Reply-To: "Your message with ID" <NDBBJMCEELAEBHDMEKELIEPCCBAA.mjones@bridgewatersystems.com>
Message-ID: <Roam.SIMC.2.0.6.986311646.20224.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> > but if it require the special avp to be present from certain users but not
> > all, what should be advertised then?
> 
> If the device requires a MANDATORY vendor-specific AVP (="special AVP") in
> order to support the functionality described in an extension (for a single
> user or all users) then it SHALL not advertise support for the extension id.

not the standards track extension id, but some other one allocated by the
manufacturer through IANA. Right?

PatC




From owner-aaa-bof@merit.edu  Tue Apr  3 11:47:17 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA04988
	for <aaa-archive@odin.ietf.org>; Tue, 3 Apr 2001 11:47:17 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 390005DDB9; Tue,  3 Apr 2001 03:35:44 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 11A175DE17; Tue,  3 Apr 2001 03:35:44 -0400 (EDT)
Received: from mailgw.local.ipunplugged.com (unknown [213.88.134.217])
	by segue.merit.edu (Postfix) with ESMTP id 784325DDB9
	for <aaa-wg@merit.edu>; Tue,  3 Apr 2001 03:35:41 -0400 (EDT)
Received: from fredrikj (a25.local.ipunplugged.com [192.168.4.195])
	by mailgw.local.ipunplugged.com (8.9.3/8.9.3) with SMTP id JAA25203;
	Tue, 3 Apr 2001 09:36:58 +0200
From: "Fredrik Johansson" <fredrik.johansson@ipunplugged.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>,
        "Mark Jones" <mjones@bridgewatersystems.com>
Cc: "David Spence" <DSpence@Interlinknetworks.com>, <aaa-wg@merit.edu>,
        <diameter@diameter.org>
Subject: RE: [diameter] Re: [AAA-WG]: Diameter Issues found @ Connectathon
Date: Tue, 3 Apr 2001 09:37:27 +0200
Message-ID: <MJEMJBGGCLLDLFFAHLJKIEDGCJAA.fredrik.johansson@ipunplugged.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <Roam.SIMC.2.0.6.986242344.2078.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

I don't like the proposed text. If a vendor would like to add a mandator avp
it will not necessarily cause interoperability problems since the receiving
node will responde with a MRI with a failed avp indicating what was not
understood. It is then up to the sender to make the decision to try without
that avp if it is willing to let the user have the service without the extra
feature provided by the mandatory avp.

/Fredrik

>-----Original Message-----
>From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf
>Of Patrice Calhoun
>Sent: den 2 april 2001 22:12
>To: Mark Jones
>Cc: Patrice Calhoun; David Spence; aaa-wg@merit.edu;
>diameter@diameter.org
>Subject: RE: [diameter] Re: [AAA-WG]: Diameter Issues found @
>Connectathon
>
>
>> It seems obvious to me too but I see a loophole in the current
>drafts since
>> the command specification in the extension documents contain "*
>[ AVP ]" to
>> indicate that any other AVP may be present (including a mandatory
>> vendor-specific AVP). I dislike conformance battles with other vendors so
>> how about adding the following text to the Extension-Id AVP
>description to
>> keep us honest:
>>
>> "A Diameter peer that includes an Extension-Id AVP in the DRI
>SHALL support
>> the functionality described in the associated extension using only the
>> commands defined in the extension and without the addition of mandatory
>> vendor-specific AVPs."
>
>That sounds a little harsh, but what does the WG think about
>Mark's proposed
>text?
>
>PatC
>




From owner-aaa-bof@merit.edu  Tue Apr  3 12:59:17 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA08055
	for <aaa-archive@odin.ietf.org>; Tue, 3 Apr 2001 12:59:17 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id E65B05DDDE; Tue,  3 Apr 2001 12:58:58 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id D3D275DDDC; Tue,  3 Apr 2001 12:58:58 -0400 (EDT)
Received: from mail01.bridgewatersystems.com (mail01.bridgewatersystems.com [216.113.7.9])
	by segue.merit.edu (Postfix) with ESMTP id E46F95DDC9
	for <aaa-wg@merit.edu>; Tue,  3 Apr 2001 12:58:56 -0400 (EDT)
Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2])
	by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id NAA25917;
	Tue, 3 Apr 2001 13:55:18 -0400
Received: from preston (cisconas247.bridgewatersys.com [192.168.150.247])
	by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.1) with SMTP id MAA26185;
	Tue, 3 Apr 2001 12:59:35 -0400 (EDT)
From: "Mark Jones" <mjones@bridgewatersystems.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>
Cc: "Fredrik Johansson" <fredrik.johansson@ipunplugged.com>,
        "David Spence" <DSpence@Interlinknetworks.com>, <aaa-wg@merit.edu>,
        <diameter@diameter.org>
Subject: RE: [diameter] Re: [AAA-WG]: Diameter Issues found @ Connectathon
Date: Tue, 3 Apr 2001 13:00:48 -0400
Message-ID: <NDBBJMCEELAEBHDMEKELIEPDCBAA.mjones@bridgewatersystems.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-reply-to: <Roam.SIMC.2.0.6.986316023.1216.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

> But my point was that if you don't advertise anything, you don't receive
> anything. So a kludged Mobile IP extension (as you describe above) would
> *still* have to be advertised via a new Extension-Id.
>

Agreed. But my point was that my kludged HA should not be advertising
support for the standards track Mobile IP extension draft. Instead it should
be advertising support for the vendor's "Kludged Mobile IP extension". Do we
agree on this?

Regards,
       Mark




From owner-aaa-bof@merit.edu  Tue Apr  3 13:45:14 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10017
	for <aaa-archive@odin.ietf.org>; Tue, 3 Apr 2001 13:45:14 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 684FB5DEE7; Tue,  3 Apr 2001 11:06:15 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 565095DEDD; Tue,  3 Apr 2001 11:06:15 -0400 (EDT)
Received: from mailgw.local.ipunplugged.com (unknown [213.88.134.217])
	by segue.merit.edu (Postfix) with ESMTP id 6F4395DE8B
	for <aaa-wg@merit.edu>; Tue,  3 Apr 2001 11:06:13 -0400 (EDT)
Received: from fredrikj (a25.local.ipunplugged.com [192.168.4.195])
	by mailgw.local.ipunplugged.com (8.9.3/8.9.3) with SMTP id RAA00849;
	Tue, 3 Apr 2001 17:07:36 +0200
From: "Fredrik Johansson" <fredrik.johansson@ipunplugged.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>
Cc: "AAA Listan" <aaa-wg@merit.edu>
Subject: RE: [AAA-WG]: Base Session State Machine
Date: Tue, 3 Apr 2001 17:08:06 +0200
Message-ID: <MJEMJBGGCLLDLFFAHLJKKEDPCJAA.fredrik.johansson@ipunplugged.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <Roam.SIMC.2.0.6.985972701.21680.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

>
>> 1. I guess that this state applies to Session-Timeout Expires on
>FA as well.
>>
>>       Open      Session-Timeout Expires on     send STR   Discon
>>                 NAS
>> Suggestion:
>> 	Open	    Session-Timeout Expires on	send STR	Discon
>> 		    access device
>
>I guess my NAS biases are now coming out :)
>
>I have changed NAS to Access Device.

Great :-)

>
>> 2. Is there a possible raise condition if the Session-Timeout in
>the NAS/FA
>> and the Session-Timeout in the home AAA server expires at the
>same time? The
>> AAA server will send a STI and go to disconnected when it
>receives the STR
>> from the NAS/FA it will disconnect and go to closed but it will
>never send a
>> STA, thus the NAS/FA will never receive a STA and will never go
>to closed.
>> Or is the STR only sent in response to a STI?
>
>If an STI is received, and STR MUST be sent. Therefore, the race condition
>here doesn't exist since the STR will be received. Furthermore, an STR MUST
>generate an STA, so again, no problem.
>

will you clarify that in the session state machine.

current version:
Discon    STR Received                   Discon.    Closed
                                         user/device

Suggestion:
Discon    STR Received                   Discon.    Closed
                                         user/device
                                         Send STA


/Fredrik

>PatC
>>
>> /Fredrik
>>
>>
>
>




From owner-aaa-bof@merit.edu  Tue Apr  3 13:52:22 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10305
	for <aaa-archive@odin.ietf.org>; Tue, 3 Apr 2001 13:52:22 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 383925DE23; Tue,  3 Apr 2001 13:50:18 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 1FDD15DE1A; Tue,  3 Apr 2001 13:50:18 -0400 (EDT)
Received: from mail01.bridgewatersystems.com (mail01.bridgewatersystems.com [216.113.7.9])
	by segue.merit.edu (Postfix) with ESMTP id 0CC675DE19
	for <aaa-wg@merit.edu>; Tue,  3 Apr 2001 13:50:16 -0400 (EDT)
Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2])
	by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id OAA26595;
	Tue, 3 Apr 2001 14:46:37 -0400
Received: from preston (cisconas247.bridgewatersys.com [192.168.150.247])
	by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.1) with SMTP id NAA27801;
	Tue, 3 Apr 2001 13:50:54 -0400 (EDT)
From: "Mark Jones" <mjones@bridgewatersystems.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>
Cc: "Fredrik Johansson" <fredrik.johansson@ipunplugged.com>,
        "David Spence" <DSpence@Interlinknetworks.com>, <aaa-wg@merit.edu>,
        <diameter@diameter.org>
Subject: RE: [diameter] Re: [AAA-WG]: Diameter Issues found @ Connectathon
Date: Tue, 3 Apr 2001 13:52:07 -0400
Message-ID: <NDBBJMCEELAEBHDMEKELEEPECBAA.mjones@bridgewatersystems.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-reply-to: <Roam.SIMC.2.0.6.986317249.5015.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

> That is *exactly* what I said earlier.
>

Sorry, Pat. I had misunderstood from your earlier email that you were
suggesting  standards track extensions were treated somehow differently from
vendor extension drafts in the use of the Extension-Id. On re-reading the
email, I think we were in violent agreement from that point on.

Getting back to the proposed text for the Extension-Id AVP description, let
me try to summarise my understanding with an example:

- Device A from Vendor X always sends the HAA with AVPs described in
standards track Mobile IP extension (id=4).

- Device B from Vendor Y always sends HAA with AVPs described in standards
track Mobile IP extension PLUS a mandatory vendor Y specific AVP as
described in "Y's Mobile IP Extension" (id=123).

- Device C from Vendor Z is capable of supporting two modes depending on the
capabilities of the peer as advertised in the DRI. 1) HAA with AVPs
described in standards track; 2) HAA with AVPs described in standards track
Mobile IP extension PLUS a mandatory vendor Y specific AVP.

So the DRIs from these clients contain:

- Device A: Extension-Id=4
- Device B: Extension-Id=123
- Device C: Supported-Vendor-Id=Y; Extension-Id=4; Extension-Id=123

Device B SHALL NOT send a DRI with Extension-Id=4.

The following text added to the description for the Extension-Id was
intended to re-enforce this:

"A Diameter peer that includes an Extension-Id AVP in the DRI SHALL support
the functionality described in the associated extension using only the
commands defined in the extension and without the addition of mandatory
vendor-specific AVPs."

Regards,
       Mark




From owner-aaa-bof@merit.edu  Tue Apr  3 14:10:21 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11195
	for <aaa-archive@odin.ietf.org>; Tue, 3 Apr 2001 14:10:21 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 83C0F5DDC2; Tue,  3 Apr 2001 12:40:38 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 6DA5E5DDC9; Tue,  3 Apr 2001 12:40:38 -0400 (EDT)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id 03F485DDC2
	for <aaa-wg@merit.edu>; Tue,  3 Apr 2001 12:40:37 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA09988;
	Tue, 3 Apr 2001 09:40:28 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA18390;
	Tue, 3 Apr 2001 09:40:27 -0700 (PDT)
Received: from darius (darius [10.6.84.105])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id JAA09768;
	Tue, 3 Apr 2001 09:40:25 -0700 (PDT)
Date: Tue, 3 Apr 2001 09:40:23 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Subject: RE: [diameter] Re: [AAA-WG]: Diameter Issues found @ Connectathon
To: Mark Jones <mjones@bridgewatersystems.com>
Cc: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>,
        Fredrik Johansson <fredrik.johansson@ipunplugged.com>,
        David Spence <DSpence@Interlinknetworks.com>, aaa-wg@merit.edu,
        diameter@diameter.org
In-Reply-To: "Your message with ID" <NDBBJMCEELAEBHDMEKELAEPDCBAA.mjones@bridgewatersystems.com>
Message-ID: <Roam.SIMC.2.0.6.986316023.1216.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> > not the standards track extension id, but some other one allocated by the
> > manufacturer through IANA. Right?
> >
> 
> Wrong, unless my assumptions about the standards track extensions are
> incorrect. I assume the standards track extensions represent the baseline
> functionality for interoperability in a given problem domain. If my
> FA/AAAF/AAAH/HA all claim to support the MobileIP extension I should be able
> to "authenticate, authorize and collect accounting information for services
> rendered to a mobile node" regardless of the which vendor provided each
> component.
> 
> If my HA claims to support the MobileIP extension but actually inserts a
> mandatory vendor-specific AVP in the HAA command then I have a problem. I
> complain to the HA vendor who insists his device is compliant with the
> MobileIP draft and directs my attention to the "* [AVP]" in the HAA command
> format which implies he can add his mandatory vendor-specific AVP if he
> chooses. Of course, he is willing to sell me another AAAH which does support
> his mandatory vendor-specific AVP in the HAA.

But my point was that if you don't advertise anything, you don't receive
anything. So a kludged Mobile IP extension (as you describe above) would
*still* have to be advertised via a new Extension-Id.

So, if a manufacturer had the plain vanilla Mobile IP extension, and the
Vendor Z one, two extension-ids would be required. If the peer did not
advertise the vendor specific extension id, then the plain one would be used
with the Diameter peer.

This is the way the protocol works, and is much better than try A, then if it
fails, try B. no?

PatC




From owner-aaa-bof@merit.edu  Tue Apr  3 14:33:58 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12264
	for <aaa-archive@odin.ietf.org>; Tue, 3 Apr 2001 14:33:58 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id A3E0C5E155; Tue,  3 Apr 2001 14:07:36 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id BB4EF5DF61; Tue,  3 Apr 2001 14:07:33 -0400 (EDT)
Received: from mailgw.local.ipunplugged.com (unknown [213.88.134.217])
	by segue.merit.edu (Postfix) with ESMTP id 336C55E0F8
	for <aaa-wg@merit.edu>; Tue,  3 Apr 2001 14:03:51 -0400 (EDT)
Received: from fredrikj (a25.local.ipunplugged.com [192.168.4.195])
	by mailgw.local.ipunplugged.com (8.9.3/8.9.3) with SMTP id UAA03560;
	Tue, 3 Apr 2001 20:05:12 +0200
From: "Fredrik Johansson" <fredrik.johansson@ipunplugged.com>
To: "Mark Jones" <mjones@bridgewatersystems.com>,
        "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>
Cc: "David Spence" <DSpence@Interlinknetworks.com>, <aaa-wg@merit.edu>,
        <diameter@diameter.org>
Subject: RE: [diameter] Re: [AAA-WG]: Diameter Issues found @ Connectathon
Date: Tue, 3 Apr 2001 20:05:42 +0200
Message-ID: <MJEMJBGGCLLDLFFAHLJKAEEICJAA.fredrik.johansson@ipunplugged.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <NDBBJMCEELAEBHDMEKELEEPECBAA.mjones@bridgewatersystems.com>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Then we're two that missunderstod Pat :-)

I agree that vendor C should be able to advertise both extensions, and then
it is up to C's policy to decide from which users it mandates the presens of
the mandatory vendor extension. But I can not read that from your suggested
text.

/Fredrik
>
>> That is *exactly* what I said earlier.
>>
>
>Sorry, Pat. I had misunderstood from your earlier email that you were
>suggesting  standards track extensions were treated somehow
>differently from
>vendor extension drafts in the use of the Extension-Id. On re-reading the
>email, I think we were in violent agreement from that point on.
>
>Getting back to the proposed text for the Extension-Id AVP description, let
>me try to summarise my understanding with an example:
>
>- Device A from Vendor X always sends the HAA with AVPs described in
>standards track Mobile IP extension (id=4).
>
>- Device B from Vendor Y always sends HAA with AVPs described in standards
>track Mobile IP extension PLUS a mandatory vendor Y specific AVP as
>described in "Y's Mobile IP Extension" (id=123).
>
>- Device C from Vendor Z is capable of supporting two modes
>depending on the
>capabilities of the peer as advertised in the DRI. 1) HAA with AVPs
>described in standards track; 2) HAA with AVPs described in standards track
>Mobile IP extension PLUS a mandatory vendor Y specific AVP.
>
>So the DRIs from these clients contain:
>
>- Device A: Extension-Id=4
>- Device B: Extension-Id=123
>- Device C: Supported-Vendor-Id=Y; Extension-Id=4; Extension-Id=123
>
>Device B SHALL NOT send a DRI with Extension-Id=4.
>
>The following text added to the description for the Extension-Id was
>intended to re-enforce this:
>
>"A Diameter peer that includes an Extension-Id AVP in the DRI SHALL support
>the functionality described in the associated extension using only the
>commands defined in the extension and without the addition of mandatory
>vendor-specific AVPs."
>
>Regards,
>       Mark
>




From owner-aaa-bof@merit.edu  Tue Apr  3 14:48:56 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12922
	for <aaa-archive@odin.ietf.org>; Tue, 3 Apr 2001 14:48:55 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id DFB7C5DE45; Tue,  3 Apr 2001 13:01:08 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id C541A5DE44; Tue,  3 Apr 2001 13:01:08 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id 8427C5DE2B
	for <aaa-wg@merit.edu>; Tue,  3 Apr 2001 13:01:07 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA28548;
	Tue, 3 Apr 2001 10:00:55 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA23614;
	Tue, 3 Apr 2001 10:00:53 -0700 (PDT)
Received: from darius (darius [10.6.84.105])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id KAA10114;
	Tue, 3 Apr 2001 10:00:50 -0700 (PDT)
Date: Tue, 3 Apr 2001 10:00:49 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Subject: RE: [diameter] Re: [AAA-WG]: Diameter Issues found @ Connectathon
To: Mark Jones <mjones@bridgewatersystems.com>
Cc: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>,
        Fredrik Johansson <fredrik.johansson@ipunplugged.com>,
        David Spence <DSpence@Interlinknetworks.com>, aaa-wg@merit.edu,
        diameter@diameter.org
In-Reply-To: "Your message with ID" <NDBBJMCEELAEBHDMEKELIEPDCBAA.mjones@bridgewatersystems.com>
Message-ID: <Roam.SIMC.2.0.6.986317249.5015.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk


> Agreed. But my point was that my kludged HA should not be advertising
> support for the standards track Mobile IP extension draft. Instead it should
> be advertising support for the vendor's "Kludged Mobile IP extension". Do we
> agree on this?

That is *exactly* what I said earlier.

PatC




From owner-aaa-bof@merit.edu  Tue Apr  3 16:19:30 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15585
	for <aaa-archive@odin.ietf.org>; Tue, 3 Apr 2001 16:19:30 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 8BB4B5DE02; Tue,  3 Apr 2001 16:16:56 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 874E55DE9C; Tue,  3 Apr 2001 16:16:51 -0400 (EDT)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id B2BE25DE02
	for <aaa-wg@merit.edu>; Tue,  3 Apr 2001 16:16:31 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA14027;
	Tue, 3 Apr 2001 13:16:27 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA23903;
	Tue, 3 Apr 2001 13:16:26 -0700 (PDT)
Received: from darius (darius [10.6.84.105])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id NAA13171;
	Tue, 3 Apr 2001 13:16:24 -0700 (PDT)
Date: Tue, 3 Apr 2001 13:16:22 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Subject: [AAA-WG]: Extensions & Framework (was: Diameter Issues found @ Connectathon)
To: Fredrik Johansson <fredrik.johansson@ipunplugged.com>
Cc: Mark Jones <mjones@bridgewatersystems.com>,
        Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>,
        David Spence <DSpence@Interlinknetworks.com>, aaa-wg@merit.edu,
        diameter@diameter.org
In-Reply-To: "Your message with ID" <MJEMJBGGCLLDLFFAHLJKAEEICJAA.fredrik.johansson@ipunplugged.com>
Message-ID: <Roam.SIMC.2.0.6.986328982.16858.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

ok, I believe that there seems to be concensus to add clarifying language to
the spec stating that advertising an extension *requires* that the messages
defined in the spec do not include AVPs marked as mandatory that weren't
specific in the said extension.

The biggest question is whether this really belongs in the Extension-Id
section, or a new section that describes extensions.

BTW, the best place for this would have been the framework document, but we
decided to kill this spec at the last IETF. In the process of doing this, I
will need to pull in the terminology, but was there anything else that needed
to be moved to the base?

PatC




From owner-aaa-bof@merit.edu  Tue Apr  3 16:24:06 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15650
	for <aaa-archive@odin.ietf.org>; Tue, 3 Apr 2001 16:24:06 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id DCDAF5DF43; Tue,  3 Apr 2001 16:17:20 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 228745DF37; Tue,  3 Apr 2001 16:17:18 -0400 (EDT)
Received: from mail01.bridgewatersystems.com (mail01.bridgewatersystems.com [216.113.7.9])
	by segue.merit.edu (Postfix) with ESMTP id DFA835DE9C
	for <aaa-wg@merit.edu>; Tue,  3 Apr 2001 16:17:05 -0400 (EDT)
Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2])
	by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id RAA28238;
	Tue, 3 Apr 2001 17:13:23 -0400
Received: from preston (cisconas247.bridgewatersys.com [192.168.150.247])
	by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.1) with SMTP id QAA02741;
	Tue, 3 Apr 2001 16:17:41 -0400 (EDT)
From: "Mark Jones" <mjones@bridgewatersystems.com>
To: "Fredrik Johansson" <fredrik.johansson@ipunplugged.com>,
        "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>
Cc: "David Spence" <DSpence@Interlinknetworks.com>, <aaa-wg@merit.edu>,
        <diameter@diameter.org>
Subject: RE: [diameter] Re: [AAA-WG]: Diameter Issues found @ Connectathon
Date: Tue, 3 Apr 2001 16:18:54 -0400
Message-ID: <NDBBJMCEELAEBHDMEKELMEPECBAA.mjones@bridgewatersystems.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-reply-to: <MJEMJBGGCLLDLFFAHLJKAEEICJAA.fredrik.johansson@ipunplugged.com>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

> Then we're two that missunderstod Pat :-)
>
> I agree that vendor C should be able to advertise both
> extensions, and then
> it is up to C's policy to decide from which users it mandates the
> presens of
> the mandatory vendor extension. But I can not read that from your
> suggested
> text.

Actually my text was meant to re-enforce the "Device B SHALL NOT send a DRI
with Extension-Id=4" part since that was the loophole I saw in the
extensions drafts. I just included Device C to confirm we were in synch on
the standards track vs vendor extensions affair.

If example I gave is clearer, I can tidy it up a little and we can include
that under the Extension-Id description?

Regards,
       Mark




From owner-aaa-bof@merit.edu  Tue Apr  3 16:56:55 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA16774
	for <aaa-archive@odin.ietf.org>; Tue, 3 Apr 2001 16:56:55 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id E17A85DE80; Tue,  3 Apr 2001 16:56:37 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id CE6C15DE9B; Tue,  3 Apr 2001 16:56:37 -0400 (EDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by segue.merit.edu (Postfix) with ESMTP id 30FC35DE80
	for <aaa-wg@merit.edu>; Tue,  3 Apr 2001 16:56:36 -0400 (EDT)
Received: from mira-sjc5-1.cisco.com (mira-sjc5-1.cisco.com [171.71.163.15])
	by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id NAA13647;
	Tue, 3 Apr 2001 13:56:37 -0700 (PDT)
Received: from jtrostle-nt2 (dhcp-128-107-141-177.cisco.com [128.107.141.177])
	by mira-sjc5-1.cisco.com (Mirapoint)
	with SMTP id AAP09681;
	Tue, 3 Apr 2001 13:56:28 -0700 (PDT)
Message-Id: <4.1.20010403125901.00cd7630@mira-sjc5-1>
X-Sender: jtrostle@mira-sjc5-1
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Tue, 03 Apr 2001 13:00:18 -0700
To: <gwz@cisco.com>, "Jonathan Trostle" <jtrostle@cisco.com>,
        "Bernard Aboba" <aboba@internaut.com>,
        "Aaa-Wg@Merit. Edu" <aaa-wg@merit.edu>
From: Jonathan Trostle <jtrostle@cisco.com>
Subject: RE: [AAA-WG]: AAA WG Interim meeting dates
In-Reply-To: <NDBBIHMPILAAGDHPCIOPOEFDDGAA.gwz@cisco.com>
References: <4.1.20010402095558.015c97b0@mira-sjc5-1>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Can't go to Scottsdale AZ on May 18th.

Jonathan

At 03:53 AM 4/3/01 -0700, Glen Zorn wrote:
>Didn't get the original of this...
>
>> Probably can't make that date.
>> 
>> Jonathan
>> 
>> 
>> At 10:33 AM 4/2/01 -0700, Bernard Aboba wrote:
>> >As Bert Wijnen has recently noted, NANOG 22 and 
>> >OPS-NM Interim will be in Scottsdale Arizona, USA, 
>> >in the Doubltree Paradise Valley, as follows:
>> >
>> >  May 20-22   NANOG 22, ends around 3pm on 22nd
>> >
>> >  May 22-23  OPS-NM Interim, starts on 22nd 4pm 
>> >                    So we plan to meet 4-6pm, 8-10pm on 22nd
>> >                    9-1pm 23rd possibly 2-4pm 23rd too.
>> >
>> >
>> >It has been suggested that we might consider having the
>> >AAA Interim meeting at the same location, scheduled
>> >on May 18-19, 2001. 
>
>I can't make the 18th and Outlook tells me the 18th is a Saturday :-(
>
>> >
>> >How would this work?
>> >
>> 
>> 
>> 
>




From owner-aaa-bof@merit.edu  Tue Apr  3 17:33:09 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17805
	for <aaa-archive@odin.ietf.org>; Tue, 3 Apr 2001 17:33:09 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 324F75DE91; Tue,  3 Apr 2001 12:32:51 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 1EEC05DE8E; Tue,  3 Apr 2001 12:32:51 -0400 (EDT)
Received: from mail01.bridgewatersystems.com (mail01.bridgewatersystems.com [216.113.7.9])
	by segue.merit.edu (Postfix) with ESMTP id 337255DDF8
	for <aaa-wg@merit.edu>; Tue,  3 Apr 2001 12:32:49 -0400 (EDT)
Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2])
	by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id NAA25617;
	Tue, 3 Apr 2001 13:29:09 -0400
Received: from preston (cisconas247.bridgewatersys.com [192.168.150.247])
	by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.1) with SMTP id MAA25496;
	Tue, 3 Apr 2001 12:33:26 -0400 (EDT)
From: "Mark Jones" <mjones@bridgewatersystems.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>
Cc: "Fredrik Johansson" <fredrik.johansson@ipunplugged.com>,
        "David Spence" <DSpence@Interlinknetworks.com>, <aaa-wg@merit.edu>,
        <diameter@diameter.org>
Subject: RE: [diameter] Re: [AAA-WG]: Diameter Issues found @ Connectathon
Date: Tue, 3 Apr 2001 12:34:39 -0400
Message-ID: <NDBBJMCEELAEBHDMEKELAEPDCBAA.mjones@bridgewatersystems.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-reply-to: <Roam.SIMC.2.0.6.986311646.20224.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

> not the standards track extension id, but some other one allocated by the
> manufacturer through IANA. Right?
>

Wrong, unless my assumptions about the standards track extensions are
incorrect. I assume the standards track extensions represent the baseline
functionality for interoperability in a given problem domain. If my
FA/AAAF/AAAH/HA all claim to support the MobileIP extension I should be able
to "authenticate, authorize and collect accounting information for services
rendered to a mobile node" regardless of the which vendor provided each
component.

If my HA claims to support the MobileIP extension but actually inserts a
mandatory vendor-specific AVP in the HAA command then I have a problem. I
complain to the HA vendor who insists his device is compliant with the
MobileIP draft and directs my attention to the "* [AVP]" in the HAA command
format which implies he can add his mandatory vendor-specific AVP if he
chooses. Of course, he is willing to sell me another AAAH which does support
his mandatory vendor-specific AVP in the HAA.

Regards,
       Mark




From owner-aaa-bof@merit.edu  Tue Apr  3 18:52:39 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA19508
	for <aaa-archive@odin.ietf.org>; Tue, 3 Apr 2001 18:52:39 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 9223C5DF38; Tue,  3 Apr 2001 18:50:02 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 6E4CE5DF41; Tue,  3 Apr 2001 18:50:02 -0400 (EDT)
Received: from forsete.erilab.com (forsete.erilab.com [208.224.156.105])
	by segue.merit.edu (Postfix) with ESMTP id BB8B15DF38
	for <aaa-wg@merit.edu>; Tue,  3 Apr 2001 18:50:00 -0400 (EDT)
Received: from erilab.com (eblcl50.erilab.com [192.168.174.190])
	by forsete.erilab.com (8.11.0/8.11.0) with ESMTP id f33Mo0o20955;
	Tue, 3 Apr 2001 15:50:00 -0700 (PDT)
Message-ID: <3ACA542B.B43FCF1F@erilab.com>
Date: Tue, 03 Apr 2001 15:52:27 -0700
From: Michael Chen <cchen@erilab.com>
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: aaa-wg@merit.edu
Cc: pcalhoun@eng.sun.com
Subject: [AAA-WG]: Route-Record question in MobileIP
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

I have a "Route-Record" question while MN registation in Foreign HA. I
assume that all the AAA servers are stateless in my example. Here is the
message flow which I guess will use in our 02 version.

FA(mno.net)   HA(mno.net)    AAAF(mno.net)   AAAP(xyz.com)
AAAH(abc.com)
-----------   -----------    -------------   -------------  ------------

   -------------AMR1--------------->
                                  ------AMR2------>
                                                     -----AMR3------>
                                                     <----HAR1-------
                                  <------HAR2------
                 <------HAR3-------
                  ------HAA1------>
                                  ------HAA2------>
                                                     -----HAA3----->
                                                     <----AMA1------
                                   <-----AMA2------
  <-------------AMA3----------------

    1. AMR1: send to it's own AAA server(local policy)
               User-Name=joe@abc.com
               Origin-FQDN=fa.mno.net
               Origin-Realm=mno.net
               Destination-Realm=abc.com
    2. AMR2: route on Destination-Realm, add Route-Record
               User-Name=joe@abc.com
               Origin-FQDN=fa.mno.net
               Origin-Realm=mno.net
               Destination-Realm=abc.com
               Route-Record=dia1.mno.net
    3. AMR3: route on Destination-Realm, add Route-Record
               User-Name=joe@abc.com
               Origin-FQDN=fa.mno.net
               Origin-Realm=mno.net
               Destination-Realm=abc.com
               Route-Record=dia1.mno.net
               Route-Record=dia2.xyz.net

********Here is the question, we have two options
    4A. HAR1: route on Destination-Realm, put original Route-Records in
Proxy-State, add Route-Record
               User-Name=joe@abc.com
               Origin-FQDN=dia3.abc.com
               Origin-Realm=abc.com
               Destination-Realm=mno.net
               Proxy-State
               Route-Record=dia3.abc.com
    4B. HAR1: route on Route-Record
               User-Name=joe@abc.com
               Origin-FQDN=dia3.abc.com
               Origin-Realm=abc.com
               Destination-Realm=mno.net
               Route-Record=dia1.mno.net
               Route-Record=dia2.xyz.net


HAR1 is a request, we use route-record to route the request message OR
we add route-record which will be used in reply message(HAA)?
4A is correct or 4B is correct?   Why?

-Michael





From owner-aaa-bof@merit.edu  Tue Apr  3 18:58:50 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA19696
	for <aaa-archive@odin.ietf.org>; Tue, 3 Apr 2001 18:58:49 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 2CA6F5DE9B; Tue,  3 Apr 2001 18:58:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 1A7B25DE93; Tue,  3 Apr 2001 18:58:29 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id C8FAB5DE13
	for <aaa-wg@merit.edu>; Tue,  3 Apr 2001 18:58:27 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA24258;
	Tue, 3 Apr 2001 15:58:26 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA25918;
	Tue, 3 Apr 2001 15:58:24 -0700 (PDT)
Received: from darius (darius [10.6.84.105])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id PAA16013;
	Tue, 3 Apr 2001 15:58:16 -0700 (PDT)
Date: Tue, 3 Apr 2001 15:58:15 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Subject: Re: [AAA-WG]: Route-Record question in MobileIP
To: Michael Chen <cchen@erilab.com>
Cc: aaa-wg@merit.edu, pcalhoun@eng.sun.com
In-Reply-To: "Your message with ID" <3ACA542B.B43FCF1F@erilab.com>
Message-ID: <Roam.SIMC.2.0.6.986338695.23844.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> HAR1 is a request, we use route-record to route the request message OR
> we add route-record which will be used in reply message(HAA)?
> 4A is correct or 4B is correct?   Why?

It really doesn't matter whether 4A or 4B is used, as this is an
implementation issue. Some AAAH simply update the command code on the AMR to
an HAR, and change some of the AVPs, while other implementations actually
create a brand new message. Both ways are valid, and these implementation
differences would result in the 4A and 4B examples you've described.

Of course, the Home Agent must be prepared to accept both, since even if 4A
was used, there could still be an additional proxy between the AAAH and the HA
(say the AAAF in a visited Home Agent).

In fact 4C (below) would also be valid:

    4B. HAR1: route on Route-Record
               User-Name=joe@abc.com
               Origin-FQDN=dia3.abc.com
               Origin-Realm=abc.com
               Destination-Realm=mno.net
               Route-Record=dia1.mno.net
               Route-Record=dia2.xyz.net
               Route-Record=dia3.abc.com

Hope this helps,

PatC




From owner-aaa-bof@merit.edu  Tue Apr  3 19:24:52 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA20212
	for <aaa-archive@odin.ietf.org>; Tue, 3 Apr 2001 19:24:52 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 9D9D25DE8B; Tue,  3 Apr 2001 19:24:34 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 8C7CC5DE85; Tue,  3 Apr 2001 19:24:34 -0400 (EDT)
Received: from forsete.erilab.com (forsete.erilab.com [208.224.156.105])
	by segue.merit.edu (Postfix) with ESMTP id 2FCFC5DE0A
	for <aaa-wg@merit.edu>; Tue,  3 Apr 2001 19:24:33 -0400 (EDT)
Received: from erilab.com (eblcl50.erilab.com [192.168.174.190])
	by forsete.erilab.com (8.11.0/8.11.0) with ESMTP id f33NOWo21004;
	Tue, 3 Apr 2001 16:24:32 -0700 (PDT)
Message-ID: <3ACA5C42.5C11D6CD@erilab.com>
Date: Tue, 03 Apr 2001 16:26:58 -0700
From: Michael Chen <cchen@erilab.com>
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>, aaa-wg@merit.edu
Subject: Re: [AAA-WG]: Route-Record question in MobileIP
References: <Roam.SIMC.2.0.6.986338695.23844.pcalhoun@nasnfs>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Pat,

  correct me if I am wrong.
  4C (below) would  NOT  be valid:  because AAAP would complain "loop detect"
before send HAR2
4C.      HAR1: route on Route-Record
               User-Name=joe@abc.com
               Origin-FQDN=dia3.abc.com
               Origin-Realm=abc.com
               Destination-Realm=mno.net
               Route-Record=dia1.mno.net
               Route-Record=dia2.xyz.net
               Route-Record=dia3.abc.com

According  to session 12.4.1 in base protocol
"A Diameter server that proxies a message or type Request, Query or
   Indication MUST append a Route-Record AVP, which includes its
   identity.  Diameter Servers that receive messages MUST validate the
   last Route-Record AVP in the message and ensure that the host
   identified in the AVP is the same as the sender of the message."
I would say only 4A is correct. In other words, 4B is not valid. Here is the
reason:

4B       HAR1: route on Route-Record
               User-Name=joe@abc.com
               Origin-FQDN=dia3.abc.com
               Origin-Realm=abc.com
               Destination-Realm=mno.net
               Route-Record=dia1.mno.net
               Route-Record=dia2.xyz.net
               NO Route-Record=dia3.abc.com

5.       HAR2: route on Route-Record
               User-Name=joe@abc.com
               Origin-FQDN=dia3.abc.com
               Origin-Realm=abc.com
               Destination-Realm=mno.net
               Route-Record=dia1.mno.net
               NO  Route-Record=dia2.xyz.net
               NO Route-Record=dia3.abc.com

HAR is a request not a reply so we should add route-record not remove the
route-record
but if we add route-record in the request, LOOP DECTECT happen.  To sum up, only
4A is correct.


FA(mno.net)   HA(mno.net)    AAAF(mno.net)  AAAP(xyz.com) AAAH(abc.com)
-----------   -----------    -------------   -------------  ------------

   -------------AMR1--------------->
                                  ------AMR2------>
                                                     -----AMR3------>
                                                     <----HAR1-------
                                  <------HAR2------
                 <------HAR3-------
...........message skip.....



Patrice Calhoun wrote:

> > HAR1 is a request, we use route-record to route the request message OR
> > we add route-record which will be used in reply message(HAA)?
> > 4A is correct or 4B is correct?   Why?
>
> It really doesn't matter whether 4A or 4B is used, as this is an
> implementation issue. Some AAAH simply update the command code on the AMR to
> an HAR, and change some of the AVPs, while other implementations actually
> create a brand new message. Both ways are valid, and these implementation
> differences would result in the 4A and 4B examples you've described.
>
> Of course, the Home Agent must be prepared to accept both, since even if 4A
> was used, there could still be an additional proxy between the AAAH and the HA
> (say the AAAF in a visited Home Agent).
>
> In fact 4C (below) would also be valid:
>
>     4B. HAR1: route on Route-Record
>                User-Name=joe@abc.com
>                Origin-FQDN=dia3.abc.com
>                Origin-Realm=abc.com
>                Destination-Realm=mno.net
>                Route-Record=dia1.mno.net
>                Route-Record=dia2.xyz.net
>                Route-Record=dia3.abc.com
>
> Hope this helps,
>
> PatC




From owner-aaa-bof@merit.edu  Tue Apr  3 21:16:34 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA21538
	for <aaa-archive@odin.ietf.org>; Tue, 3 Apr 2001 21:16:29 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 959A45DE4A; Tue,  3 Apr 2001 19:46:24 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 7F5225DE53; Tue,  3 Apr 2001 19:46:24 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id 063D35DE4A
	for <aaa-wg@merit.edu>; Tue,  3 Apr 2001 19:46:23 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA10737;
	Tue, 3 Apr 2001 16:46:21 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA07417;
	Tue, 3 Apr 2001 16:46:20 -0700 (PDT)
Received: from darius (darius [10.6.84.105])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id QAA16869;
	Tue, 3 Apr 2001 16:46:17 -0700 (PDT)
Date: Tue, 3 Apr 2001 16:46:16 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Subject: Re: [AAA-WG]: Route-Record question in MobileIP
To: Michael Chen <cchen@erilab.com>
Cc: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>, aaa-wg@merit.edu
In-Reply-To: "Your message with ID" <3ACA5C42.5C11D6CD@erilab.com>
Message-ID: <Roam.SIMC.2.0.6.986341576.32664.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Let me try again, as I am confused with the host names ( just did a cut and
paste, and it was obviously wrong).

What I meant to say is this. When the AAAH receives the AMR, it can either
create a new HAR (and have no Route-Record AVPs), or simply update the AMR to
an HAR (and append its own Route-Record AVP). When the HA receives the HAR,
processes it, and prepares the response, it will delete the AAAH's
Route-Record AVP, and forward the message. So there is no loop involved,
unless the HA did not remove the last Route-Record AVP, which would be bad
behavior.

PatC


>   correct me if I am wrong.
>   4C (below) would  NOT  be valid:  because AAAP would complain "loop detect"
> before send HAR2 4C.      HAR1: route on Route-Record
>                User-Name=joe@abc.com
>                Origin-FQDN=dia3.abc.com
>                Origin-Realm=abc.com
>                Destination-Realm=mno.net
>                Route-Record=dia1.mno.net
>                Route-Record=dia2.xyz.net
>                Route-Record=dia3.abc.com
> 
> According  to session 12.4.1 in base protocol
> "A Diameter server that proxies a message or type Request, Query or
>    Indication MUST append a Route-Record AVP, which includes its
>    identity.  Diameter Servers that receive messages MUST validate the
>    last Route-Record AVP in the message and ensure that the host
>    identified in the AVP is the same as the sender of the message."
> I would say only 4A is correct. In other words, 4B is not valid. Here is the
> reason:
> 
> 4B       HAR1: route on Route-Record
>                User-Name=joe@abc.com
>                Origin-FQDN=dia3.abc.com
>                Origin-Realm=abc.com
>                Destination-Realm=mno.net
>                Route-Record=dia1.mno.net
>                Route-Record=dia2.xyz.net
>                NO Route-Record=dia3.abc.com
> 
> 5.       HAR2: route on Route-Record
>                User-Name=joe@abc.com
>                Origin-FQDN=dia3.abc.com
>                Origin-Realm=abc.com
>                Destination-Realm=mno.net
>                Route-Record=dia1.mno.net
>                NO  Route-Record=dia2.xyz.net
>                NO Route-Record=dia3.abc.com
> 
> HAR is a request not a reply so we should add route-record not remove the
> route-record
> but if we add route-record in the request, LOOP DECTECT happen.  To sum up,
> only 4A is correct.
> 
> 
> FA(mno.net)   HA(mno.net)    AAAF(mno.net)  AAAP(xyz.com) AAAH(abc.com)
> -----------   -----------    -------------   -------------  ------------
> 
>    -------------AMR1--------------->
>                                   ------AMR2------>
>                                                      -----AMR3------>
>                                                      <----HAR1-------
>                                   <------HAR2------
>                  <------HAR3-------
> ...........message skip.....
> 
> 
> 
> Patrice Calhoun wrote:
> 
> > > HAR1 is a request, we use route-record to route the request message OR
> > > we add route-record which will be used in reply message(HAA)?
> > > 4A is correct or 4B is correct?   Why?
> >
> > It really doesn't matter whether 4A or 4B is used, as this is an
> > implementation issue. Some AAAH simply update the command code on the AMR to
> > an HAR, and change some of the AVPs, while other implementations actually
> > create a brand new message. Both ways are valid, and these implementation
> > differences would result in the 4A and 4B examples you've described.
> >
> > Of course, the Home Agent must be prepared to accept both, since even if 4A
> > was used, there could still be an additional proxy between the AAAH and the HA
> > (say the AAAF in a visited Home Agent).
> >
> > In fact 4C (below) would also be valid:
> >
> >     4B. HAR1: route on Route-Record
> >                User-Name=joe@abc.com
> >                Origin-FQDN=dia3.abc.com
> >                Origin-Realm=abc.com
> >                Destination-Realm=mno.net
> >                Route-Record=dia1.mno.net
> >                Route-Record=dia2.xyz.net
> >                Route-Record=dia3.abc.com
> >
> > Hope this helps,
> >
> > PatC
> 





From owner-aaa-bof@merit.edu  Wed Apr  4 08:08:58 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA14986
	for <aaa-archive@odin.ietf.org>; Wed, 4 Apr 2001 08:08:58 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 0C9D35DF66; Wed,  4 Apr 2001 08:07:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id E87D05DEFA; Wed,  4 Apr 2001 08:07:28 -0400 (EDT)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by segue.merit.edu (Postfix) with ESMTP id D87855E040
	for <aaa-wg@merit.edu>; Wed,  4 Apr 2001 08:07:01 -0400 (EDT)
Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f34C70s12365
	for <aaa-wg@merit.edu>; Wed, 4 Apr 2001 14:07:00 +0200 (MEST)
Received: FROM esealnt743.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Wed Apr 04 14:07:00 2001 +0200
Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <HA3C0SF6>; Wed, 4 Apr 2001 14:07:01 +0200
Message-ID: <577066326047D41180AC00508B955DDA01D7FF56@eestqnt104.es.eu.ericsson.se>
From: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>
To: "'Patrice Calhoun'" <pcalhoun@nasnfs.Eng.Sun.COM>,
        "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>
Cc: "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>
Subject: RE: [AAA-WG]: Comments on draft-ietf-aaa-diameter-mobileip-01.txt
Date: Wed, 4 Apr 2001 14:06:56 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Thanks for your answer.
See enclosed comments.

> > 1) I think that page 8 should be a new section about a 
> Mobile Node moving to
> > a Foreign Network.
> 
> I *could* but this is just another case of a Home Agent in a 
> visited network,
> so I find it difficult to find a clean separation point.

I simply thought it would help understanding the concepts, since
the section is quite long and contains a lot of stuff not so 
easy to read for new comers.

> > 
> > 4) Page 8, par.2, last sentence. I don't really understand 
> what you mean
> > there. I guess you meant that Home Agent and the requesting 
> Foreign Agent
> > are in different domain. The thing is that it is likely 
> that the Home Agent
> > and the MIP-Previous-FA-FQDN were in the same domain at the last
> > registration, right?
> 
> Of course, but this paragraph has to do with a third network. 
> Is the scenario
> what's confusing you, or the text?

It is the text, which suggests that the AAAH MUST verify whether or
not it will allow a HA to be kept in a Foreign Network different
than the actual FA, only if the MIP-Previous-FA-FQDN AVP and 
MIP-Home-Agent-Address AVP are in different domains. Since both
entities will most probably be from the same domain (in the case where
the FA and HA are in the foreign domain, which is recommended for route
optimization), then no check should be performed, according to your text, right? 
I guess that it is not what you really wanted to express, but rather when an AAAH
receives a MIP-Previous-FA-FQDN AVP, the AAAH deduces that the MN
has moved to a new domain, and then must check if a 
MIP-Home-Agent-Address AVP was present in that same network, in which case
it must take a decision whether or not to allow the HA to be used.

And also, I'm not sure whether the MUST is really necessary, or should simply
be left as a possible local policy?

> > 6) Section 1.4, the second paragraph suggests to release 
> the all resources
> > in the Home Diameter server upon the receipt of the STR 
> from the Home Agent.
> > I guess it should be clear that the referred Home Agent is 
> the "active" Home
> > Agent, since there might be 2 Home Agents at the same time 
> while roaming.
> > During handoffs between different FAs in different domains, 
> and let's say
> > that the Home Agent in the old Foreign domain can not be 
> maintained there,
> > then a new Home Agent has to be started in the Home Domain 
> or the new
> > Foreign domain and the AAAH needs to send a STI to the old 
> Home Agent, which
> > replies with a STR. In that case, the Home Diameter should 
> not release
> > resources, right?
> 
> I think that I view multiple bindings (to home agents) are 
> different Diameter
> sessions. Each would get their own Session-Id, and have their 
> own separate
> session state.
> 

I would really appreciate if you could give me a bit more details 
on what you mean here, because lately, I've been wondering about
how the Session-Id should be handled while moving between FAs within
the same domain, and different domains. 

> 
> You have plenty of comments on section 5.1, which was a mess. 
> My proposed
> cleaned up text is as following 
> 
> <proposed text>
> If the mobile node does not have a Mobile-Home registration key, then
> the AAAH is likely to be the only entity trusted that is available to
> the mobile node.  Thus, the AAAH has to generate the Mobile-Home
> registration key, and encode it for eventual consumption by the mobile
> node and home agent.
> 
> If the home agent is in the home domain, then AAAH can directly encode
> the Mobile-Home registration key into a MIP-HA-to-MN-Key AVP and
> include that AVP in the HAR message for delivery to the home agent.
> 

Why do you say "encode", since it is not encoded, right?

> If, on the other hand, the home agent is to be allocated in the
> visited domain, the AAAH does not transmit the HAR to the home agent,
> but instead transmits the HAR to the AAAF. When the AAAF 
> receives the HAR,
> it first allocates a home agent, and then issues the HAR for 
> that home agent.
> 
> The AAAH also has to arrange for the key to be delivered to 
> the mobile node.
> Unfortunately, the AAA server only knows about Diameter 
> messages and AVPs,
> and the mobile node only knows about Mobile IP messages and 
> extensions[4].
> For this purpose, AAAH encodes the Mobile-Home registration key into
> a MIP-MN-to-HA-Key AVP, using its security association with 
> the mobile node,
> which is added to the HAR message, and delivered either to a 
> local home
> agent, or to the AAAF in the case where the home agent is in 
> the visited
> network. The AAAH has to rely on the home agent (that also understands
> Diameter) to transfer the key into a Mobile IP Generalized 
> MN-HA Key Reply
> extension in the Registration Reply message. The home agent 
> can format the
> Reply message and extensions correctly for eventual delivery 
> to the mobile
> node. The resulting Registration Reply is added to the 
> MIP-Reg-Reply AVP
> and added to the AHA.
> 

HAA instead of AHA.

> After the HAA message is parsed by the AAAH, and transformed 
> into an AMA,
> the AMA message containing the MIP-Reg-Reply AVP will 
> eventually be received
> by the attendant (i.e., the foreign agent). The foreign agent 
> can then use
> that AVP to recreate a Registration Reply message, containing 
> the Generalized
> MN-HA Key Reply extension, for delivery to the mobile node.
> 
> In summary, the AAAH generates the Mobile-Home registration key and
> encodes it into a MIP-HA-to-MN-Key AVP and a MIP-MN-to-HA-Key 
> AVP. These
> AVPs are delivered to a home agent by including them in a HAR message
> sent from either AAAH or AAAF. The home agent decodes the key 
> for its own use.
> The home agent also copies the encoded registration key from the
> MIP-MN-to-HA-Key AVP into a Generalized MN-HA Key Reply 
> extension appended
> to the Mobile IP Registration Reply message. This 
> Registration Reply message
> MUST also include the Mobile-Home authentication extension, 
> created using
> the newly allocated Mobile-Home registration key. The home agent then
> encodes the Registration Reply message and extensions into a 
> MIP-Reg-Reply
> AVP included as part of the HAA message to be sent back to 
> the AAA server.
> </proposed text>

Yes, it seems to be OK. Thanks!

> 
> You also had many comments on section 5.2, which has now been greatly
> simplified to:
> 
> <proposed text>
> The Mobile-Foreign registration key is also generated by AAAH 
> (upon request),
> so that it can be encoded into a MIP-MN-to-FA-Key AVP, which 
> is added to the
> HAR, and copied by the home agent into a Generalized MN-FA Key Reply
> Extension [15] to the Mobile IP Registration Reply message. Most of
> the considerations for distributing the Mobile-Foreign 
> registration key
> are similar to the distribution of the Mobile-Home Registration Key.
> 
> If the MIP-FA-to-MN-Key AVP is present in the HAR, the home 
> agent MUST ensure
> that the same AVP is present in the AHA. The AAAH MUST ensure 

HAA instead of AHA.

> that this AVP
> is present in the AMA, which is sent to the foreign agent.
> </proposed text>
> 

I think this section should also mention that the FA needs to add 
the Mobile-Foreign Authentication extension to the MIP-Reg-Reply
message.

> 
> Similarly, section 5.3 was greatly simplified to:
> 
> <proposed text>
> If the home agent is in the home domain, then AAAH has to generate the
> Foreign-Home registration key.  Otherwise, it is generated by AAAF.
> 
> In either case, the AAA server encodes the registration key into a

Why do you say "encode", since it is not encoded, right?

> MIP-HA-to-FA-Key AVP and includes that AVP as part of the HAR message
> sent to the home agent, and waits for the HAA message to be returned.

Shouldn't the HA include a Foreign-Home Authentication Extension to
the MIP Registration Reply AVP?

> 
> If the MIP-FA-to-HA-Key AVP was present in the HAR, the same AVP MUST
> be present in the corresponding AHA, which is eventually 

HAA instead of AHA.

> transformed by
> the AAAH into an AMA message that is transmitted back to the 
> foreign agent.
> 
> Upon receipt of the AMA, the foreign agent recovers the Foreign-Home
> registration key, and uses this key to create a Mobile-Foreign
> authentication extension to the Registration Reply message.

I don't think the last paragraph is correct. I don't see the link
between the Foreign-Home key and the Mobile-Foreign Authentication
extension.

> </proposed text>
> 
> > 27)  Section 2.1, why is the Session-ID is required with 
> {}, but not with
> > [], like in other messages?
> 
> As per the base protocol, the Session-ID is ALWAYS mandatory 
> to be present.

I meant that it should be consistent in all the document, which means
using {} everywhere for the Session-ID AVP.

> > 29) I am wondering why the Destination-Realm AVP is 
> required in Answer
> > messages?
> 
> hmmmm.... noit quite sure, but it doesn't seem to hurt :)

Well, I wanted to ask why the Destination-FQDN AVP is not required
in the AMA? I think it should be in all answer/reply messages, since
the origin-FQDN seems to be required in Request/Query messages, right?


Thanks a lot!
Martin



From owner-aaa-bof@merit.edu  Wed Apr  4 09:50:45 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA19208
	for <aaa-archive@odin.ietf.org>; Wed, 4 Apr 2001 09:50:44 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id BC07A5DFC1; Wed,  4 Apr 2001 09:48:50 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9809B5DFC3; Wed,  4 Apr 2001 09:48:50 -0400 (EDT)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id D3A455DFC1
	for <aaa-wg@merit.edu>; Wed,  4 Apr 2001 09:48:48 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA29734;
	Wed, 4 Apr 2001 06:48:45 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA09181;
	Wed, 4 Apr 2001 06:48:45 -0700 (PDT)
Received: from darius (darius [10.6.84.105])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id GAA22475;
	Wed, 4 Apr 2001 06:48:43 -0700 (PDT)
Date: Wed, 4 Apr 2001 06:48:42 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Subject: Re: [AAA-WG]: Previous-FA-XXXX AVP
To: Fredrik Johansson <fredrik.johansson@ipunplugged.com>
Cc: AAA Listan <aaa-wg@merit.edu>
In-Reply-To: "Your message with ID" <MJEMJBGGCLLDLFFAHLJKAEFOCJAA.fredrik.johansson@ipunplugged.com>
Message-ID: <Roam.SIMC.2.0.6.986392122.24183.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> First of all, there is a typo in 4.5 Previous-FA-NAI AVP should be
> Previous-FA-FQDN AVP

Yes, this has been pointed out already, and fixed in the -02 candidate.

> Then we have another question. When trying to retreive the keys from the
> AAAF for the previous FA, should you really use the Mobile-Node-Address AVP
> as identifier? Isn't it possible that there are several mobile nodes with
> the same private address under the same AAAF? It would be better to use the
> NAI. This should be changed in 4.5, 4.6. 

Yes, you are correct.

> The same applies to accounting
> (section 7.0) where it seems like the mn address is used as identifier
> instead of the Nai.

Actually, the base protocols now defines the accounting messages, and they now
call for the User-Name. So the ACR and ACA definitions include the User-name,
so I think we are covered.

PatC




From owner-aaa-bof@merit.edu  Wed Apr  4 11:34:20 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23320
	for <aaa-archive@odin.ietf.org>; Wed, 4 Apr 2001 11:34:19 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 062395DF45; Wed,  4 Apr 2001 09:24:22 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id C80565DF42; Wed,  4 Apr 2001 09:24:21 -0400 (EDT)
Received: from mailgw.local.ipunplugged.com (unknown [213.88.134.217])
	by segue.merit.edu (Postfix) with ESMTP id 1A6D15DF34
	for <aaa-wg@merit.edu>; Wed,  4 Apr 2001 09:24:17 -0400 (EDT)
Received: from fredrikj (a25.local.ipunplugged.com [192.168.4.195])
	by mailgw.local.ipunplugged.com (8.9.3/8.9.3) with SMTP id PAA15994
	for <aaa-wg@merit.edu>; Wed, 4 Apr 2001 15:25:42 +0200
From: "Fredrik Johansson" <fredrik.johansson@ipunplugged.com>
To: "AAA Listan" <aaa-wg@merit.edu>
Subject: [AAA-WG]: Previous-FA-XXXX AVP
Date: Wed, 4 Apr 2001 15:26:12 +0200
Message-ID: <MJEMJBGGCLLDLFFAHLJKAEFOCJAA.fredrik.johansson@ipunplugged.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi,

First of all, there is a typo in 4.5 Previous-FA-NAI AVP should be
Previous-FA-FQDN AVP

Then we have another question. When trying to retreive the keys from the
AAAF for the previous FA, should you really use the Mobile-Node-Address AVP
as identifier? Isn't it possible that there are several mobile nodes with
the same private address under the same AAAF? It would be better to use the
NAI. This should be changed in 4.5, 4.6. The same applies to accounting
(section 7.0) where it seems like the mn address is used as identifier
instead of the Nai.

/Fredrik




From owner-aaa-bof@merit.edu  Wed Apr  4 12:07:11 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24359
	for <aaa-archive@odin.ietf.org>; Wed, 4 Apr 2001 12:07:11 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 05E695DE14; Wed,  4 Apr 2001 12:06:46 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id E096D5DE15; Wed,  4 Apr 2001 12:06:45 -0400 (EDT)
Received: from gate.internaut.com (unknown [64.38.134.101])
	by segue.merit.edu (Postfix) with ESMTP id BEE1C5DE14
	for <aaa-wg@merit.edu>; Wed,  4 Apr 2001 12:06:43 -0400 (EDT)
Received: from e1kj2 (e1kj2 [64.38.134.109])
	by gate.internaut.com (8.10.2/8.10.2) with SMTP id f34FtIN08232;
	Wed, 4 Apr 2001 08:55:18 -0700
From: "Bernard Aboba" <aboba@internaut.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>,
        "Fredrik Johansson" <fredrik.johansson@ipunplugged.com>
Cc: "Mark Jones" <mjones@bridgewatersystems.com>,
        "David Spence" <DSpence@Interlinknetworks.com>, <aaa-wg@merit.edu>,
        <diameter@diameter.org>
Subject: RE: [AAA-WG]: Extensions & Framework (was: Diameter Issues found @ Connectathon)
Date: Wed, 4 Apr 2001 09:06:48 -0700
Message-ID: <OJEJKOMOEAKLMOILFCPJCEDFEFAA.aboba@internaut.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <Roam.SIMC.2.0.6.986328982.16858.pcalhoun@nasnfs>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

I think that this makes sense:

	1. An extension is by definition a series of commands, plus
         the AVPs that relate to those commands, as described in
         the BNF.

      2. Advertising an extension also implies advertisement of
         the AVPs for that extension, as described in the BNF.

	3. You can send other AVPs in those commands, but only
         the ones included in the BNF may have the 'M' bit set.
         Additional AVPs MUST NOT have the 'M' bit set, including
         vendor-specific AVPs.

      4. This implies that if an AVP needs to be mandatory (such
         as security-related AVPs like filter-rules, filterid,
         tunnel AVPs, etc.) then either it is included in the
         base spec or an extension or its use is PROHIBITED.

I'd vote for having a section at the beginning of the base
document that describes the DIAMETER extensiblity model in
detail. This would include not only the extensions mechanism,
but also the model for adding AVPs (e.g. data modeling), and
new authentication mechanisms (EAP).

In terms of the framework document, I don't think that the
existing document is terribly useful. So it might just make
sense to add the required introductory text to the base
document and let the framework doc expire.


-----Original Message-----
From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf
Of Patrice Calhoun
Sent: Tuesday, April 03, 2001 1:16 PM
To: Fredrik Johansson
Cc: Mark Jones; Patrice Calhoun; David Spence; aaa-wg@merit.edu;
diameter@diameter.org
Subject: [AAA-WG]: Extensions & Framework (was: Diameter Issues found @
Connectathon)


ok, I believe that there seems to be concensus to add clarifying language to
the spec stating that advertising an extension *requires* that the messages
defined in the spec do not include AVPs marked as mandatory that weren't
specific in the said extension.

The biggest question is whether this really belongs in the Extension-Id
section, or a new section that describes extensions.

BTW, the best place for this would have been the framework document, but we
decided to kill this spec at the last IETF. In the process of doing this, I
will need to pull in the terminology, but was there anything else that
needed
to be moved to the base?

PatC






From owner-aaa-bof@merit.edu  Wed Apr  4 12:13:01 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24546
	for <aaa-archive@odin.ietf.org>; Wed, 4 Apr 2001 12:13:01 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 9365D5DE42; Wed,  4 Apr 2001 12:12:44 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 8050D5DE46; Wed,  4 Apr 2001 12:12:44 -0400 (EDT)
Received: from gate.internaut.com (unknown [64.38.134.101])
	by segue.merit.edu (Postfix) with ESMTP id AA21E5DE42
	for <aaa-wg@merit.edu>; Wed,  4 Apr 2001 12:12:42 -0400 (EDT)
Received: from e1kj2 (e1kj2 [64.38.134.109])
	by gate.internaut.com (8.10.2/8.10.2) with SMTP id f34G2PN08647;
	Wed, 4 Apr 2001 09:02:25 -0700
From: "Bernard Aboba" <aboba@internaut.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <gwz@cisco.com>
Cc: "Jonathan Trostle" <jtrostle@cisco.com>,
        "Aaa-Wg@Merit. Edu" <aaa-wg@merit.edu>
Subject: RE: [AAA-WG]: AAA WG Interim meeting dates
Date: Wed, 4 Apr 2001 09:13:56 -0700
Message-ID: <OJEJKOMOEAKLMOILFCPJGEDFEFAA.aboba@internaut.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <Roam.SIMC.2.0.6.986304731.17701.pcalhoun@nasnfs>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Unfortunately, the original dates (Monday, April 30 and Tuesday,
May 1, 2001) are no longer within the 30 day window.

May 5-11 is Networld+Interop. So unless people are up for meeting in Las
Vegas the weekend of May 12-13 the earliest we could do it would be the
week of May 14.

-----Original Message-----
From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf
Of Patrice Calhoun
Sent: Tuesday, April 03, 2001 6:32 AM
To: gwz@cisco.com
Cc: Jonathan Trostle; Bernard Aboba; Aaa-Wg@Merit. Edu
Subject: RE: [AAA-WG]: AAA WG Interim meeting dates



> > >It has been suggested that we might consider having the
> > >AAA Interim meeting at the same location, scheduled
> > >on May 18-19, 2001.
>
> I can't make the 18th and Outlook tells me the 18th is a Saturday :-(

No, it's a Friday, but the 19th *is* a Saturday. Perhaps trying to squeeze
in
that week isn't really worth it. Could we please go back to the original
dates
(and place)?

PatC






From owner-aaa-bof@merit.edu  Wed Apr  4 12:30:18 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25011
	for <aaa-archive@odin.ietf.org>; Wed, 4 Apr 2001 12:30:17 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 4E9215DE7C; Wed,  4 Apr 2001 12:15:46 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 3B4725DE75; Wed,  4 Apr 2001 12:15:46 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id C242F5DE43
	for <aaa-wg@merit.edu>; Wed,  4 Apr 2001 12:15:44 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA24269;
	Wed, 4 Apr 2001 09:15:33 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA04767;
	Wed, 4 Apr 2001 09:15:31 -0700 (PDT)
Received: from darius (darius [10.6.84.105])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id JAA24228;
	Wed, 4 Apr 2001 09:15:28 -0700 (PDT)
Date: Wed, 4 Apr 2001 09:15:27 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Subject: RE: [AAA-WG]: AAA WG Interim meeting dates
To: Bernard Aboba <aboba@internaut.com>
Cc: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>, gwz@cisco.com,
        Jonathan Trostle <jtrostle@cisco.com>,
        "Aaa-Wg@Merit. Edu" <aaa-wg@merit.edu>
In-Reply-To: "Your message with ID" <OJEJKOMOEAKLMOILFCPJGEDFEFAA.aboba@internaut.com>
Message-ID: <Roam.SIMC.2.0.6.986400927.15755.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Weekend meetings are out for me (sorry, but I travel too much, and weekends I
want to be home). The very fact that we lingered for so long is quite
upsetting. People claimed they could do May 3rd, and that was WELL within the
window when people sent those e-mails. Week of May 14th will work for me too,
but let's get this thing setup so we don't have to move it out further.

PatC
> Unfortunately, the original dates (Monday, April 30 and Tuesday,
> May 1, 2001) are no longer within the 30 day window.
> 
> May 5-11 is Networld+Interop. So unless people are up for meeting in Las
> Vegas the weekend of May 12-13 the earliest we could do it would be the
> week of May 14.
> 
> -----Original Message-----
> From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf
> Of Patrice Calhoun
> Sent: Tuesday, April 03, 2001 6:32 AM
> To: gwz@cisco.com
> Cc: Jonathan Trostle; Bernard Aboba; Aaa-Wg@Merit. Edu
> Subject: RE: [AAA-WG]: AAA WG Interim meeting dates
> 
> 
> 
> > > >It has been suggested that we might consider having the
> > > >AAA Interim meeting at the same location, scheduled
> > > >on May 18-19, 2001.
> >
> > I can't make the 18th and Outlook tells me the 18th is a Saturday :-(
> 
> No, it's a Friday, but the 19th *is* a Saturday. Perhaps trying to squeeze
> in
> that week isn't really worth it. Could we please go back to the original
> dates
> (and place)?
> 
> PatC
> 
> 
> 





From owner-aaa-bof@merit.edu  Wed Apr  4 13:55:27 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27451
	for <aaa-archive@odin.ietf.org>; Wed, 4 Apr 2001 13:55:27 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 1BB525DE2A; Wed,  4 Apr 2001 13:55:11 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 08F645DE28; Wed,  4 Apr 2001 13:55:10 -0400 (EDT)
Received: from rip.psg.com (rip.psg.com [147.28.0.39])
	by segue.merit.edu (Postfix) with ESMTP id 8B9A35DE1A
	for <aaa-wg@merit.edu>; Wed,  4 Apr 2001 13:55:09 -0400 (EDT)
Received: from randy by rip.psg.com with local (Exim 3.16 #1)
	id 14krUk-000743-00; Wed, 04 Apr 2001 10:55:02 -0700
From: Randy Bush <randy@psg.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: "Bernard Aboba" <aboba@internaut.com>
Cc: "Aaa-Wg@Merit. Edu" <aaa-wg@merit.edu>
Subject: RE: [AAA-WG]: AAA WG Interim meeting dates
References: <Roam.SIMC.2.0.6.986400927.15755.pcalhoun@nasnfs>
	<OJEJKOMOEAKLMOILFCPJKEEDEFAA.aboba@internaut.com>
Message-Id: <E14krUk-000743-00@rip.psg.com>
Date: Wed, 04 Apr 2001 10:55:02 -0700
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

> At this point, I would propose May 14-15, San Francisco Bay Area.

monday i am flying back from ghana.  sorry.

randy



From owner-aaa-bof@merit.edu  Wed Apr  4 15:15:17 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29283
	for <aaa-archive@odin.ietf.org>; Wed, 4 Apr 2001 15:15:17 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 92E675DE25; Wed,  4 Apr 2001 13:45:33 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 81EF65DE1A; Wed,  4 Apr 2001 13:45:33 -0400 (EDT)
Received: from gate.internaut.com (unknown [64.38.134.101])
	by segue.merit.edu (Postfix) with ESMTP id 90CCC5DDDA
	for <aaa-wg@merit.edu>; Wed,  4 Apr 2001 13:45:31 -0400 (EDT)
Received: from e1kj2 (e1kj2 [64.38.134.109])
	by gate.internaut.com (8.10.2/8.10.2) with SMTP id f34HZIN13390
	for <aaa-wg@merit.edu>; Wed, 4 Apr 2001 10:35:18 -0700
From: "Bernard Aboba" <aboba@internaut.com>
To: "Aaa-Wg@Merit. Edu" <aaa-wg@merit.edu>
Subject: RE: [AAA-WG]: AAA WG Interim meeting dates
Date: Wed, 4 Apr 2001 10:46:49 -0700
Message-ID: <OJEJKOMOEAKLMOILFCPJKEEDEFAA.aboba@internaut.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <Roam.SIMC.2.0.6.986400927.15755.pcalhoun@nasnfs>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

>Weekend meetings are out for me (sorry, but I travel too much, and weekends
I
>want to be home). The very fact that we lingered for so long is quite
>upsetting. People claimed they could do May 3rd, and that was WELL within
the
>window when people sent those e-mails. Week of May 14th will work for me
too,
>but let's get this thing setup so we don't have to move it out further.

There were quite a few people who could not make the earlier date (including
our AD), so it wasn't just a matter of letting it slip.

At this point, I would propose May 14-15, San Francisco Bay Area. This is
a Monday & Tuesday (avoids weekends).

What do people think?







From owner-aaa-bof@merit.edu  Wed Apr  4 15:23:40 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29409
	for <aaa-archive@odin.ietf.org>; Wed, 4 Apr 2001 15:23:39 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 389A65DE4B; Wed,  4 Apr 2001 15:23:06 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 1FB9A5DE4C; Wed,  4 Apr 2001 15:23:06 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id 47F975DE4B
	for <aaa-wg@merit.edu>; Wed,  4 Apr 2001 15:23:02 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA07601;
	Wed, 4 Apr 2001 12:22:48 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA18722;
	Wed, 4 Apr 2001 12:22:43 -0700 (PDT)
Received: from darius (darius [10.6.84.105])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id MAA27920;
	Wed, 4 Apr 2001 12:22:41 -0700 (PDT)
Date: Wed, 4 Apr 2001 12:22:40 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Subject: RE: [AAA-WG]: AAA WG Interim meeting dates
To: Bernard Aboba <aboba@internaut.com>
Cc: "Aaa-Wg@Merit. Edu" <aaa-wg@merit.edu>
In-Reply-To: "Your message with ID" <OJEJKOMOEAKLMOILFCPJKEEDEFAA.aboba@internaut.com>
Message-ID: <Roam.SIMC.2.0.6.986412160.16104.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

That works for me.

PatC
> >Weekend meetings are out for me (sorry, but I travel too much, and weekends
> I
> >want to be home). The very fact that we lingered for so long is quite
> >upsetting. People claimed they could do May 3rd, and that was WELL within
> the
> >window when people sent those e-mails. Week of May 14th will work for me
> too,
> >but let's get this thing setup so we don't have to move it out further.
> 
> There were quite a few people who could not make the earlier date (including
> our AD), so it wasn't just a matter of letting it slip.
> 
> At this point, I would propose May 14-15, San Francisco Bay Area. This is
> a Monday & Tuesday (avoids weekends).
> 
> What do people think?
> 
> 
> 
> 
> 





From owner-aaa-bof@merit.edu  Wed Apr  4 15:51:22 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29963
	for <aaa-archive@odin.ietf.org>; Wed, 4 Apr 2001 15:51:21 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id B6DB85DE2B; Wed,  4 Apr 2001 15:48:55 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id A22865DE1E; Wed,  4 Apr 2001 15:48:55 -0400 (EDT)
Received: from rip.psg.com (rip.psg.com [147.28.0.39])
	by segue.merit.edu (Postfix) with ESMTP id B5FE55DDFE
	for <aaa-wg@merit.edu>; Wed,  4 Apr 2001 15:48:53 -0400 (EDT)
Received: from randy by rip.psg.com with local (Exim 3.16 #1)
	id 14ktGh-000AII-00; Wed, 04 Apr 2001 12:48:39 -0700
From: Randy Bush <randy@psg.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Cc: Bernard Aboba <aboba@internaut.com>,
        "Aaa-Wg@Merit. Edu" <aaa-wg@merit.edu>
Subject: RE: [AAA-WG]: AAA WG Interim meeting dates
References: <E14krUk-000743-00@rip.psg.com>
	<Roam.SIMC.2.0.6.986412228.23068.pcalhoun@nasnfs>
Message-Id: <E14ktGh-000AII-00@rip.psg.com>
Date: Wed, 04 Apr 2001 12:48:39 -0700
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

> ok, here is a question. Do we need the AD for the first day of a document
> reading party??

no



From owner-aaa-bof@merit.edu  Wed Apr  4 17:04:05 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01761
	for <aaa-archive@odin.ietf.org>; Wed, 4 Apr 2001 17:04:04 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 0FA765DF00; Wed,  4 Apr 2001 17:00:59 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id F079F5DEE4; Wed,  4 Apr 2001 17:00:58 -0400 (EDT)
Received: from imr2.ericy.com (unknown [12.34.240.68])
	by segue.merit.edu (Postfix) with ESMTP id 874465DEF9
	for <aaa-wg@merit.edu>; Wed,  4 Apr 2001 17:00:54 -0400 (EDT)
Received: from mr4u3.ericy.com (mr4att.ericy.com [138.85.92.12])
	by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f34L0q821984;
	Wed, 4 Apr 2001 16:00:52 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179])
	by mr4u3.ericy.com (8.10.2/8.10.2) with ESMTP id f34L0q904356;
	Wed, 4 Apr 2001 16:00:52 -0500 (CDT)
Received: from pop.exu.ericsson.se (qpop [138.85.1.15]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id QAA13439; Wed, 4 Apr 2001 16:00:51 -0500 (CDT)
Received: from ericsson.com (busam53.berkeley.us.am.ericsson.se [138.85.159.203])
	by pop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id QAA18619;
	Wed, 4 Apr 2001 16:00:44 -0500 (CDT)
Message-ID: <3ACB8BC4.AAD770E2@ericsson.com>
Date: Wed, 04 Apr 2001 14:01:56 -0700
From: Tony Johansson <tony.johansson@ericsson.com>
Organization: Ericsson Inc
X-Mailer: Mozilla 4.73 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Bernard Aboba <aboba@internaut.com>
Cc: "Aaa-Wg@Merit. Edu" <aaa-wg@merit.edu>
Subject: Re: [AAA-WG]: AAA WG Interim meeting dates
References: <OJEJKOMOEAKLMOILFCPJKEEDEFAA.aboba@internaut.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

That works for me.

/Tony

Bernard Aboba wrote:

> >Weekend meetings are out for me (sorry, but I travel too much, and weekends
> I
> >want to be home). The very fact that we lingered for so long is quite
> >upsetting. People claimed they could do May 3rd, and that was WELL within
> the
> >window when people sent those e-mails. Week of May 14th will work for me
> too,
> >but let's get this thing setup so we don't have to move it out further.
>
> There were quite a few people who could not make the earlier date (including
> our AD), so it wasn't just a matter of letting it slip.
>
> At this point, I would propose May 14-15, San Francisco Bay Area. This is
> a Monday & Tuesday (avoids weekends).
>
> What do people think?




From owner-aaa-bof@merit.edu  Wed Apr  4 17:52:32 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA02680
	for <aaa-archive@odin.ietf.org>; Wed, 4 Apr 2001 17:52:32 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id B837A5DE4C; Wed,  4 Apr 2001 17:50:02 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id A4EB65DE3E; Wed,  4 Apr 2001 17:50:02 -0400 (EDT)
Received: from imr2.ericy.com (unknown [12.34.240.68])
	by segue.merit.edu (Postfix) with ESMTP id 2472A5DE2F
	for <aaa-wg@merit.edu>; Wed,  4 Apr 2001 17:50:01 -0400 (EDT)
Received: from mr4u3.ericy.com (mr4att.ericy.com [138.85.92.12])
	by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f34Lns808191;
	Wed, 4 Apr 2001 16:49:54 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179])
	by mr4u3.ericy.com (8.10.2/8.10.2) with ESMTP id f34Lnr905127;
	Wed, 4 Apr 2001 16:49:53 -0500 (CDT)
Received: from pop.exu.ericsson.se (qpop [138.85.1.15]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id QAA17085; Wed, 4 Apr 2001 16:49:45 -0500 (CDT)
Received: from ericsson.com (busam53.berkeley.us.am.ericsson.se [138.85.159.203])
	by pop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id QAA19371;
	Wed, 4 Apr 2001 16:49:38 -0500 (CDT)
Message-ID: <3ACB9739.C97470B2@ericsson.com>
Date: Wed, 04 Apr 2001 14:50:49 -0700
From: Tony Johansson <tony.johansson@ericsson.com>
Organization: Ericsson Inc
X-Mailer: Mozilla 4.73 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Cc: Fredrik Johansson <fredrik.johansson@ipunplugged.com>,
        AAA Listan <aaa-wg@merit.edu>, Martin.Julien@ece.ericsson.se
Subject: Re: [AAA-WG]: Previous-FA-XXXX AVP
References: <Roam.SIMC.2.0.6.986392122.24183.pcalhoun@nasnfs>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Pat and all,

Here is something more on the Previous-FA-XXXX AVP issue thread that I think is
missing...

Lets say the following scenario that a registered MN is moving from one FA to
another FA within the same foreign domain and in this scenario the new FA will
issue an AMR including the Previous-FA-XXXX AVP to request to get the FA-MN and
FA-HA keys, and the Authorization-Lifetime. But what about the Session-Id?

The new FA does not know about the existing Session-Id, which has been use
previously used during the initial registration, so the new FA will generate a new
one in its AMR to the AAAF.

This leads to a couple of questions:

1. How should the AAAF deal with the new Session-Id? The AAAH does not know about
new one in this case.

One way of solving this could be to let the AAAF over write the new session id and
add on the initial session id into the Session-Id AVP in the reply back to the new
FA together FA-MN and FA-HA keys, and the Authorization-Lifetime. Or maybe a new
AVP for the initial session id is needed...

2. Furthermore, the AAAH would not get any information in this case, so it would
not know that the FA has changed only the AAAF is aware of it. Thus, if the AAAH
wants to send an STI to terminate the session for some reason it would issue the
STI towards the wrong FA.

A solution to this could perhaps be that the AAAH initially gets the information
about responsible AAAF in the foreign network, so if the AAAH needs to send an STI
it would issue it towards the AAAF and the AAAF would be responsible to resolve it
and forward it to the right FA.

Another way would be to let the AAAF to issue an Indication to the AAAH to inform
that the MN has changed FA.

Does it make sense or have I miss something.

BR,

/Tony





From owner-aaa-bof@merit.edu  Wed Apr  4 18:15:16 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA03010
	for <aaa-archive@odin.ietf.org>; Wed, 4 Apr 2001 18:15:16 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id DDF8D5DE05; Wed,  4 Apr 2001 17:54:41 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id CD99F5DDCB; Wed,  4 Apr 2001 17:54:41 -0400 (EDT)
Received: from rip.psg.com (rip.psg.com [147.28.0.39])
	by segue.merit.edu (Postfix) with ESMTP id AAF925DDBB
	for <aaa-wg@merit.edu>; Wed,  4 Apr 2001 17:54:40 -0400 (EDT)
Received: from randy by rip.psg.com with local (Exim 3.16 #1)
	id 14kvEY-000Dfj-00; Wed, 04 Apr 2001 14:54:34 -0700
From: Randy Bush <randy@psg.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Cc: Bernard Aboba <aboba@internaut.com>,
        "Aaa-Wg@Merit. Edu" <aaa-wg@merit.edu>
Subject: RE: [AAA-WG]: AAA WG Interim meeting dates
References: <E14krUk-000743-00@rip.psg.com>
	<Roam.SIMC.2.0.6.986412228.23068.pcalhoun@nasnfs>
Message-Id: <E14kvEY-000Dfj-00@rip.psg.com>
Date: Wed, 04 Apr 2001 14:54:34 -0700
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

> ok, here is a question. Do we need the AD for the first day of a document
> reading party??

but i think the aaa wg needs to do a LOT more than review docs to get this
out the door.



From owner-aaa-bof@merit.edu  Wed Apr  4 18:57:10 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA03990
	for <aaa-archive@odin.ietf.org>; Wed, 4 Apr 2001 18:57:10 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id BEF605DED6; Wed,  4 Apr 2001 18:52:55 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 554BB5DFA0; Wed,  4 Apr 2001 18:52:49 -0400 (EDT)
Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210])
	by segue.merit.edu (Postfix) with ESMTP id 47C165DF34
	for <aaa-wg@merit.edu>; Wed,  4 Apr 2001 18:50:46 -0400 (EDT)
Received: from JSCHNIZL-W2K.cisco.com (jschnizl-isdn1.cisco.com [171.68.12.74]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id PAA27903; Wed, 4 Apr 2001 15:50:12 -0700 (PDT)
Message-Id: <4.3.2.7.2.20010404184524.00b87008@diablo.cisco.com>
X-Sender: jschnizl@diablo.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 04 Apr 2001 18:49:49 -0400
To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
From: John Schnizlein <jschnizl@cisco.com>
Subject: RE: [AAA-WG]: AAA WG Interim meeting dates
Cc: Randy Bush <randy@psg.com>, "Aaa-Wg" <aaa-wg@merit.edu>
In-Reply-To: <Roam.SIMC.2.0.6.986422119.29925.pcalhoun@nasnfs>
References: <"Your message with ID" <E14kvEY-000Dfj-00@rip.psg.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Maybe the number of issues is not as important as their toughness.
I found the security reaction in Minneapolis clear and tough:
proxies and security don't mix. Since forwarding AAA has been one
of the spectacular successes in functionality for RADIUS, this seems
to be a big issue. We worried about details of hop-by-hop versus
end-to-end, but it seems we have not cracked the nut that Steve
Bellovin laid on the table when persuaded to speak.

John

At 06:08 PM 4/4/2001, Patrice Calhoun wrote:
>> > ok, here is a question. Do we need the AD for the first day of a document
>> > reading party??
>> 
>> but i think the aaa wg needs to do a LOT more than review docs to get this
>> out the door.
>
>If that's the case, then I would appreciate a list of issues. So far, there
>don't seem to be many (modulo the two of three on the list at the moment).
>
>PatC




From owner-aaa-bof@merit.edu  Wed Apr  4 19:31:24 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA04514
	for <aaa-archive@odin.ietf.org>; Wed, 4 Apr 2001 19:31:24 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 8B0085DE34; Wed,  4 Apr 2001 16:48:39 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 6BE415DE3D; Wed,  4 Apr 2001 16:48:39 -0400 (EDT)
Received: from forsete.erilab.com (forsete.erilab.com [208.224.156.105])
	by segue.merit.edu (Postfix) with ESMTP id 988D65DE34
	for <aaa-wg@merit.edu>; Wed,  4 Apr 2001 16:48:37 -0400 (EDT)
Received: from erilab.com (eblcl50.erilab.com [192.168.174.190])
	by forsete.erilab.com (8.11.0/8.11.0) with ESMTP id f34Kmbo21917
	for <aaa-wg@merit.edu>; Wed, 4 Apr 2001 13:48:37 -0700 (PDT)
Message-ID: <3ACB890E.682C276A@erilab.com>
Date: Wed, 04 Apr 2001 13:50:22 -0700
From: Michael Chen <cchen@erilab.com>
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: aaa-wg@merit.edu
Subject: [AAA-WG]: Destination-Realm and Route-Record
References: <E14krUk-000743-00@rip.psg.com>
		<Roam.SIMC.2.0.6.986412228.23068.pcalhoun@nasnfs> <E14ktGh-000AII-00@rip.psg.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

In Base Protocol session 12.1 Figure 2
Why do we need Destination-Realm AVP in the REPLY message?
The REPLY message Must follow the Route-Records to route the Reply message,
isn't it?
In 12.4.7
"When present, the Destination-Realm AVP is used to perform message routing
decisions"
So how does AAA  route the message if we have BOTH Route-Record and
Destination-Ream AVPs?

-Michael





From owner-aaa-bof@merit.edu  Wed Apr  4 19:33:50 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA04547
	for <aaa-archive@odin.ietf.org>; Wed, 4 Apr 2001 19:33:50 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 78E2B5E105; Wed,  4 Apr 2001 19:00:14 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 5A9E25DF8C; Wed,  4 Apr 2001 19:00:14 -0400 (EDT)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id 37B2E5E105
	for <aaa-wg@merit.edu>; Wed,  4 Apr 2001 19:00:10 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA01147;
	Wed, 4 Apr 2001 16:00:03 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA16639;
	Wed, 4 Apr 2001 16:00:02 -0700 (PDT)
Received: from darius (darius [10.6.84.105])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id PAA01774;
	Wed, 4 Apr 2001 15:59:59 -0700 (PDT)
Date: Wed, 4 Apr 2001 15:59:58 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Subject: RE: [AAA-WG]: AAA WG Interim meeting dates
To: John Schnizlein <jschnizl@cisco.com>
Cc: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>, Randy Bush <randy@psg.com>,
        Aaa-Wg <aaa-wg@merit.edu>
In-Reply-To: "Your message with ID" <4.3.2.7.2.20010404184524.00b87008@diablo.cisco.com>
Message-ID: <Roam.SIMC.2.0.6.986425198.32000.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

umm.... are we meeting to redesign how AAA currently works in networks, hence
how a new protocol could be designed? Or do we have to live with what people
run in their networks?

What is needed is to get the specs out. I am not sure that meeting for two
days would convince Steve B. that proxies are good, nor could we convince
ourselves that the world will change tomorrow and proxies will go away.

PatC
> Maybe the number of issues is not as important as their toughness.
> I found the security reaction in Minneapolis clear and tough:
> proxies and security don't mix. Since forwarding AAA has been one
> of the spectacular successes in functionality for RADIUS, this seems
> to be a big issue. We worried about details of hop-by-hop versus
> end-to-end, but it seems we have not cracked the nut that Steve
> Bellovin laid on the table when persuaded to speak.
> 
> John
> 
> At 06:08 PM 4/4/2001, Patrice Calhoun wrote:
> >> > ok, here is a question. Do we need the AD for the first day of a
> document >> > reading party??
> >> 
> >> but i think the aaa wg needs to do a LOT more than review docs to get this
> >> out the door. >
> >If that's the case, then I would appreciate a list of issues. So far, there
> >don't seem to be many (modulo the two of three on the list at the moment).
> >
> >PatC
> 





From owner-aaa-bof@merit.edu  Wed Apr  4 19:43:27 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA04625
	for <aaa-archive@odin.ietf.org>; Wed, 4 Apr 2001 19:43:26 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 2A0CC5DF3C; Wed,  4 Apr 2001 19:41:45 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id CAD035DF3D; Wed,  4 Apr 2001 19:41:44 -0400 (EDT)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id E28705DF3C
	for <aaa-wg@merit.edu>; Wed,  4 Apr 2001 19:41:41 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA00608;
	Wed, 4 Apr 2001 16:41:40 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA16863;
	Wed, 4 Apr 2001 16:41:36 -0700 (PDT)
Received: from darius (darius [10.6.84.105])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id QAA02566;
	Wed, 4 Apr 2001 16:41:34 -0700 (PDT)
Date: Wed, 4 Apr 2001 16:41:33 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Subject: Re: [AAA-WG]: Destination-Realm and Route-Record
To: Michael Chen <cchen@erilab.com>
Cc: aaa-wg@merit.edu
In-Reply-To: "Your message with ID" <3ACB890E.682C276A@erilab.com>
Message-ID: <Roam.SIMC.2.0.6.986427693.2399.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> In Base Protocol session 12.1 Figure 2
> Why do we need Destination-Realm AVP in the REPLY message?
> The REPLY message Must follow the Route-Records to route the Reply message,
> isn't it?
> In 12.4.7
> "When present, the Destination-Realm AVP is used to perform message routing
> decisions"
> So how does AAA  route the message if we have BOTH Route-Record and
> Destination-Ream AVPs?

You are absolutely correct. The Destination-Realm AVP MUST NOT be present in
*-Reply or *-Answer messages. I will update the -02 candidate.

Thanks for the catch (and I still owe you a response to your other question),

PatC




From owner-aaa-bof@merit.edu  Wed Apr  4 20:01:03 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA04831
	for <aaa-archive@odin.ietf.org>; Wed, 4 Apr 2001 20:01:03 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 88FAB5DDBB; Wed,  4 Apr 2001 18:08:53 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 731D85DDCB; Wed,  4 Apr 2001 18:08:53 -0400 (EDT)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id 0FB8D5DDBB
	for <aaa-wg@merit.edu>; Wed,  4 Apr 2001 18:08:52 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA19710;
	Wed, 4 Apr 2001 15:08:44 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA05216;
	Wed, 4 Apr 2001 15:08:44 -0700 (PDT)
Received: from darius (darius [10.6.84.105])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id PAA00982;
	Wed, 4 Apr 2001 15:08:40 -0700 (PDT)
Date: Wed, 4 Apr 2001 15:08:39 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Subject: RE: [AAA-WG]: AAA WG Interim meeting dates
To: Randy Bush <randy@psg.com>
Cc: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>,
        Bernard Aboba <aboba@internaut.com>,
        "Aaa-Wg@Merit. Edu" <aaa-wg@merit.edu>
In-Reply-To: "Your message with ID" <E14kvEY-000Dfj-00@rip.psg.com>
Message-ID: <Roam.SIMC.2.0.6.986422119.29925.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> > ok, here is a question. Do we need the AD for the first day of a document
> > reading party??
> 
> but i think the aaa wg needs to do a LOT more than review docs to get this
> out the door.

If that's the case, then I would appreciate a list of issues. So far, there
don't seem to be many (modulo the two of three on the list at the moment).

PatC




From owner-aaa-bof@merit.edu  Wed Apr  4 20:20:22 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA05039
	for <aaa-archive@odin.ietf.org>; Wed, 4 Apr 2001 20:20:22 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 7DE3B5DEB1; Wed,  4 Apr 2001 20:18:37 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 5E2BA5DEAF; Wed,  4 Apr 2001 20:18:37 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id D0FF15DEAC
	for <aaa-wg@merit.edu>; Wed,  4 Apr 2001 20:18:35 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id RAA00377;
	Wed, 4 Apr 2001 17:18:22 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA09349;
	Wed, 4 Apr 2001 17:18:12 -0700 (PDT)
Received: from darius (darius [10.6.84.105])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id RAA03261;
	Wed, 4 Apr 2001 17:18:09 -0700 (PDT)
Date: Wed, 4 Apr 2001 17:18:08 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Subject: Re: [AAA-WG]: Previous-FA-XXXX AVP
To: Tony Johansson <tony.johansson@ericsson.com>
Cc: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>,
        Fredrik Johansson <fredrik.johansson@ipunplugged.com>,
        AAA Listan <aaa-wg@merit.edu>, Martin.Julien@ece.ericsson.se
In-Reply-To: "Your message with ID" <3ACB9739.C97470B2@ericsson.com>
Message-ID: <Roam.SIMC.2.0.6.986429888.17615.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> Here is something more on the Previous-FA-XXXX AVP issue thread that I think
> is missing...

ok.

> Lets say the following scenario that a registered MN is moving from one FA to
> another FA within the same foreign domain and in this scenario the new FA
> will issue an AMR including the Previous-FA-XXXX AVP to request to get the
> FA-MN and FA-HA keys, and the Authorization-Lifetime. But what about the
> Session-Id?
> 
> The new FA does not know about the existing Session-Id, which has been use
> previously used during the initial registration, so the new FA will generate
> a new one in its AMR to the AAAF.

This is a problem that has been plaguing (sp?) me for some time. Mobile IP is
vastly different from PPP, where the user's point of attachment changes over
time. If the AAAH is not notified of this change, then it cannot realistically
terminate the session properly.

Not to mention how to deal with accounting information.

> 
> This leads to a couple of questions:
> 
> 1. How should the AAAF deal with the new Session-Id? The AAAH does not know
> about new one in this case.
> 
> One way of solving this could be to let the AAAF over write the new session
> id and add on the initial session id into the Session-Id AVP in the reply
> back to the new FA together FA-MN and FA-HA keys, and the
> Authorization-Lifetime. Or maybe a new AVP for the initial session id is
> needed...

I think it would be much cleaner to have a new AVP, rather than the old one. 

> 
> 2. Furthermore, the AAAH would not get any information in this case, so it
> would not know that the FA has changed only the AAAF is aware of it. Thus,
> if the AAAH wants to send an STI to terminate the session for some reason it
> would issue the STI towards the wrong FA.
> 
> A solution to this could perhaps be that the AAAH initially gets the
> information about responsible AAAF in the foreign network, so if the AAAH
> needs to send an STI it would issue it towards the AAAF and the AAAF would
> be responsible to resolve it and forward it to the right FA.

hmmmm... I would MUCH prefer to NOT assume state on the AAAF. I believe that
it would be more appropriate to define a new message, of type -Ind, which is
sent by the AAAF to the AAAH to notify it of a location change.

However, this is new functionality, and we did agree to NOT include new
functionality, but only fix bugs. So, is this a bug, or a new functionality?

> Another way would be to let the AAAF to issue an Indication to the AAAH to
> inform that the MN has changed FA.

oops, great minds think alike :)

PatC




From owner-aaa-bof@merit.edu  Wed Apr  4 21:30:21 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA05623
	for <aaa-archive@odin.ietf.org>; Wed, 4 Apr 2001 21:30:20 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 0112D5DE37; Wed,  4 Apr 2001 15:24:43 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 92BE55DE40; Wed,  4 Apr 2001 15:24:04 -0400 (EDT)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id 84D6C5DE46
	for <aaa-wg@merit.edu>; Wed,  4 Apr 2001 15:24:00 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id MAA19830;
	Wed, 4 Apr 2001 12:23:52 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA18904;
	Wed, 4 Apr 2001 12:23:51 -0700 (PDT)
Received: from darius (darius [10.6.84.105])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id MAA27945;
	Wed, 4 Apr 2001 12:23:49 -0700 (PDT)
Date: Wed, 4 Apr 2001 12:23:48 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Subject: RE: [AAA-WG]: AAA WG Interim meeting dates
To: Randy Bush <randy@psg.com>
Cc: Bernard Aboba <aboba@internaut.com>,
        "Aaa-Wg@Merit. Edu" <aaa-wg@merit.edu>
In-Reply-To: "Your message with ID" <E14krUk-000743-00@rip.psg.com>
Message-ID: <Roam.SIMC.2.0.6.986412228.23068.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

ok, here is a question. Do we need the AD for the first day of a document
reading party??

PatC




From owner-aaa-bof@merit.edu  Thu Apr  5 02:30:14 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA24027
	for <aaa-archive@odin.ietf.org>; Thu, 5 Apr 2001 02:30:14 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 9D6F65E02C; Thu,  5 Apr 2001 01:03:40 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 7467B5E02D; Thu,  5 Apr 2001 01:03:40 -0400 (EDT)
Received: from rip.psg.com (rip.psg.com [147.28.0.39])
	by segue.merit.edu (Postfix) with ESMTP id EB0685E02C
	for <aaa-wg@merit.edu>; Thu,  5 Apr 2001 01:03:37 -0400 (EDT)
Received: from randy by rip.psg.com with local (Exim 3.16 #1)
	id 14l1vl-000PPb-00; Wed, 04 Apr 2001 22:03:37 -0700
From: Randy Bush <randy@psg.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Cc: AAA wg <aaa-wg@merit.edu>
Subject: RE: [AAA-WG]: AAA WG Interim meeting dates
References: <4.3.2.7.2.20010404184524.00b87008@diablo.cisco.com>
	<Roam.SIMC.2.0.6.986425198.32000.pcalhoun@nasnfs>
Message-Id: <E14l1vl-000PPb-00@rip.psg.com>
Date: Wed, 04 Apr 2001 22:03:37 -0700
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

> What is needed is to get the specs out. I am not sure that meeting for two
> days would convince Steve B. that proxies are good, nor could we convince
> ourselves that the world will change tomorrow and proxies will go away.

two days?  who says two days.  we're locking you in a room with nothing
but pizza and jolt until you come up with a solution that has reasonable
security and, if you insist, proxies.

kidding about jolt and pizza, would not do that to even a jim flemming.
but not kidding about security and proxies.

randy



From owner-aaa-bof@merit.edu  Thu Apr  5 02:45:40 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA24165
	for <aaa-archive@odin.ietf.org>; Thu, 5 Apr 2001 02:45:39 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id D9C595DF3A; Thu,  5 Apr 2001 02:19:08 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id BA2AE5DF81; Thu,  5 Apr 2001 02:15:29 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id BD2AA5DF72
	for <aaa-wg@merit.edu>; Thu,  5 Apr 2001 02:06:51 -0400 (EDT)
Received: from gwzpc (sjc-vpn-tmp53.cisco.com [10.21.64.53]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id XAA03991; Wed, 4 Apr 2001 23:04:56 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Bernard Aboba" <aboba@internaut.com>,
        "Aaa-Wg@Merit. Edu" <aaa-wg@merit.edu>
Subject: RE: [AAA-WG]: AAA WG Interim meeting dates
Date: Wed, 4 Apr 2001 23:04:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPOEHNDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <OJEJKOMOEAKLMOILFCPJKEEDEFAA.aboba@internaut.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Bernard Aboba [mailto:aboba@internaut.com] writes:

> >Weekend meetings are out for me (sorry, but I travel too much,
> and weekends
> I
> >want to be home). The very fact that we lingered for so long is quite
> >upsetting. People claimed they could do May 3rd, and that was WELL within
> the
> >window when people sent those e-mails. Week of May 14th will work for me
> too,
> >but let's get this thing setup so we don't have to move it out further.
>
> There were quite a few people who could not make the earlier date
> (including
> our AD), so it wasn't just a matter of letting it slip.
>
> At this point, I would propose May 14-15, San Francisco Bay Area. This is
> a Monday & Tuesday (avoids weekends).

Those dates are out for me.

>
> What do people think?
>
>
>
>
>
>




From owner-aaa-bof@merit.edu  Thu Apr  5 03:12:11 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA24513
	for <aaa-archive@odin.ietf.org>; Thu, 5 Apr 2001 03:12:11 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 9691E5DE3D; Thu,  5 Apr 2001 03:10:55 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 22E6E5DE40; Thu,  5 Apr 2001 03:10:55 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 807595DE3D
	for <aaa-wg@merit.edu>; Thu,  5 Apr 2001 03:10:46 -0400 (EDT)
Received: from gwzpc (sjc-vpn-tmp53.cisco.com [10.21.64.53]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id AAA17800; Thu, 5 Apr 2001 00:08:52 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Bernard Aboba" <aboba@internaut.com>,
        "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>
Cc: "Jari Arkko" <Jari.Arkko@lmf.ericsson.se>, <aaa-wg@merit.edu>
Subject: RE: [AAA-WG]: Extensibility model and IANA considerations
Date: Thu, 5 Apr 2001 00:08:08 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPAEIHDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <OJEJKOMOEAKLMOILFCPJCEMLEEAA.aboba@internaut.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Bernard Aboba [mailto:aboba@internaut.com] writes:

> >This discussion, though cogent, seems irrelevant.  Pat's
> assertion was that
> >the AVPs should be included (as optional) in the base because they were
> >needed by >1 extensions.  My argument is that they should not, for one
> >reason that they are _not_ optional for either of the extensions in
> >question.  It seems to me that the extensions would need to either modify
> >the base to state that the AVPs are mandatory or establish that
> while they
> >are technically optional, they are (non-explicitly) mandatory in their
> >contexts (wink, wink, nod, nod ;-).
>
> I think it makes sense to include AVPs in the base protocol that are
> used in more than one extension. However, as you point out, if they
> are mandatory in more than one extension, then they cannot be made
> optional in the base spec. If an AVP does not have the same status
> for all extensions, it seems to me that the base spec would
> need to specify the extensions for which the 'M' bit can be set.

But now (assuming that we do not, at this time, have knowledge of every
Diameter extension that will ever exist) we're back to updating the base
every time a new extension needs the 'M' bit set on an otherwise optional
AVP.

>
> >Yes, but more to the point of this discussion, what about AVPs that are
> >mandatory for some extensions (say, MIP & NASREQ) but optional (or even
> >superfluous) for others?
>
> I would propose that the base spec include a table specifying for each
> AVP and extension whether the 'M' bit may be set or not. Each new
> extension could also include such a table.

Ditto.

>
> >From a protocol POV, I'll admit that there is probably not a
> great reason.
> >However, fromm a specification POV, independently defined
> messages increase
> >the cohesion of the documents, while decreasing the coupling
> between them.
> >To use RFC 2867 as an example, in order to implement it a person needs to
> >understand RFCs 2865-2869, inclusive.  I would have _vastly_ preferred to
> >have defined the compulsory tunneling attributes independent of the base
> >RADIUS stuff, but the paucity of the RADIUS namespace prevented that.
>
> How did the paucity of attributes influence the design? In order to
> handle compulsory tunneling accounting, new accounting messages *were*
> defined, so this had some of the character of an "extension". Can you
> talk about the advantages and disadvantages of this approach?
>
> One thing that has occurred to me about RADIUS is that with new access
> types like VPN, the combination of NAS-Port-Type and the message in
> effect define an "extension": the semantics of the AVPs may change
> as a result. For example, if NAS-Port-Type = 802.11, there is no
> point sending a number of attributes that might make sense if
> NAS-Port-Type = Virtual.
>
> The nice thing about this is that these "extensions" can in effect
> be created without the need for any code changes, assuming that the
> RADIUS implementation has an extensible dictionary and supports
> conditional behavior. (For an example of conditional behavior in
> the ISC DHCP server, see Droms & Lemon's "DHCP Handbook").
>
> So if possible, I'd rather not move to a model in which DIAMETER
> server code updates are needed to support "extensions" that could
> have been implemented as dictionary additions under RADIUS. This
> seems like a step backward.
>
> >To put it another way, I would like to be able to take 2
> >documents and implement both the base protocol and _any_ given Diameter
> >extension, w/o needing to chase through a pile of essentially unrelated
> >stuff searching for the definition of the _one_ AVP I need from it.
>
> Well, I would say that it is ok to describe an AVP or messages in two
> places, if that would help, as long as the definition is the same. But
> creating new messages or AVPs that do the same thing as the old ones
> seems like a bad idea, because it requires unnecessary code changes.

I thought that we had decided that an extension by definition defines one or
more new messages.  Adding new AVPs (e.g., MIP-Acct-Octets-In and
NAS-Acct-Octets-In) instead of reusing a generic Acct-Octets-In AVP only
requires dictionary changes, no?

>
>
>




From owner-aaa-bof@merit.edu  Thu Apr  5 03:14:51 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA24542
	for <aaa-archive@odin.ietf.org>; Thu, 5 Apr 2001 03:14:51 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 264045DE40; Thu,  5 Apr 2001 03:14:33 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id F1F905DE4F; Thu,  5 Apr 2001 03:14:32 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 56F8D5DE46
	for <aaa-wg@merit.edu>; Thu,  5 Apr 2001 03:14:31 -0400 (EDT)
Received: from gwzpc (sjc-vpn-tmp53.cisco.com [10.21.64.53]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id AAA20486; Thu, 5 Apr 2001 00:12:41 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Bernard Aboba" <aboba@internaut.com>,
        "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>
Cc: "Jonathan Trostle" <jtrostle@cisco.com>,
        "Aaa-Wg@Merit. Edu" <aaa-wg@merit.edu>
Subject: RE: [AAA-WG]: AAA WG Interim meeting dates
Date: Thu, 5 Apr 2001 00:11:45 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPEEIHDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <OJEJKOMOEAKLMOILFCPJGEDFEFAA.aboba@internaut.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Bernard Aboba [mailto:aboba@internaut.com] writes:

> Unfortunately, the original dates (Monday, April 30 and Tuesday,
> May 1, 2001) are no longer within the 30 day window.
>
> May 5-11 is Networld+Interop. So unless people are up for meeting in Las
> Vegas the weekend of May 12-13 the earliest we could do it would be the
> week of May 14.

How many people go to N+I (out of the group that would participate in the
interim meeting)?  Of course, I don't think I can make May 5-11 anyway...

>
> -----Original Message-----
> From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf
> Of Patrice Calhoun
> Sent: Tuesday, April 03, 2001 6:32 AM
> To: gwz@cisco.com
> Cc: Jonathan Trostle; Bernard Aboba; Aaa-Wg@Merit. Edu
> Subject: RE: [AAA-WG]: AAA WG Interim meeting dates
>
>
>
> > > >It has been suggested that we might consider having the
> > > >AAA Interim meeting at the same location, scheduled
> > > >on May 18-19, 2001.
> >
> > I can't make the 18th and Outlook tells me the 18th is a Saturday :-(
>
> No, it's a Friday, but the 19th *is* a Saturday. Perhaps trying to squeeze
> in
> that week isn't really worth it. Could we please go back to the original
> dates
> (and place)?
>
> PatC
>
>
>
>




From owner-aaa-bof@merit.edu  Thu Apr  5 03:45:24 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA24821
	for <aaa-archive@odin.ietf.org>; Thu, 5 Apr 2001 03:45:24 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id C64F75DE46; Thu,  5 Apr 2001 03:31:57 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id AC7D05DE9D; Thu,  5 Apr 2001 03:31:57 -0400 (EDT)
Received: from mailgw.local.ipunplugged.com (unknown [213.88.134.217])
	by segue.merit.edu (Postfix) with ESMTP id 1846E5DE46
	for <aaa-wg@merit.edu>; Thu,  5 Apr 2001 03:31:55 -0400 (EDT)
Received: from fredrikj (a25.local.ipunplugged.com [192.168.4.195])
	by mailgw.local.ipunplugged.com (8.9.3/8.9.3) with SMTP id JAA28711;
	Thu, 5 Apr 2001 09:32:19 +0200
From: "Fredrik Johansson" <fredrik.johansson@ipunplugged.com>
To: "Bernard Aboba" <aboba@internaut.com>
Cc: "Aaa-Wg@Merit. Edu" <aaa-wg@merit.edu>
Subject: RE: [AAA-WG]: AAA WG Interim meeting dates
Date: Thu, 5 Apr 2001 09:32:50 +0200
Message-ID: <MJEMJBGGCLLDLFFAHLJKKEGNCJAA.fredrik.johansson@ipunplugged.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <3ACB8BC4.AAD770E2@ericsson.com>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

14-15 works for me

/Fredrik

>-----Original Message-----
>From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf
>Of Tony Johansson
>Sent: den 4 april 2001 23:02
>To: Bernard Aboba
>Cc: Aaa-Wg@Merit. Edu
>Subject: Re: [AAA-WG]: AAA WG Interim meeting dates
>
>
>That works for me.
>
>/Tony
>
>Bernard Aboba wrote:
>
>> >Weekend meetings are out for me (sorry, but I travel too much,
>and weekends
>> I
>> >want to be home). The very fact that we lingered for so long is quite
>> >upsetting. People claimed they could do May 3rd, and that was
>WELL within
>> the
>> >window when people sent those e-mails. Week of May 14th will work for me
>> too,
>> >but let's get this thing setup so we don't have to move it out further.
>>
>> There were quite a few people who could not make the earlier
>date (including
>> our AD), so it wasn't just a matter of letting it slip.
>>
>> At this point, I would propose May 14-15, San Francisco Bay Area. This is
>> a Monday & Tuesday (avoids weekends).
>>
>> What do people think?
>




From owner-aaa-bof@merit.edu  Thu Apr  5 04:34:17 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA25161
	for <aaa-archive@odin.ietf.org>; Thu, 5 Apr 2001 04:34:17 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 3A8EB5DE48; Thu,  5 Apr 2001 04:31:32 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 17CE25DE10; Thu,  5 Apr 2001 04:31:32 -0400 (EDT)
Received: from mailgw.local.ipunplugged.com (unknown [213.88.134.217])
	by segue.merit.edu (Postfix) with ESMTP id E6DC35DDB7
	for <aaa-wg@merit.edu>; Thu,  5 Apr 2001 04:31:29 -0400 (EDT)
Received: from fredrikj (a25.local.ipunplugged.com [192.168.4.195])
	by mailgw.local.ipunplugged.com (8.9.3/8.9.3) with SMTP id KAA29690;
	Thu, 5 Apr 2001 10:31:48 +0200
From: "Fredrik Johansson" <fredrik.johansson@ipunplugged.com>
To: "Bernard Aboba" <aboba@internaut.com>,
        "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>
Cc: "Mark Jones" <mjones@bridgewatersystems.com>,
        "David Spence" <DSpence@Interlinknetworks.com>, <aaa-wg@merit.edu>,
        <diameter@diameter.org>
Subject: RE: [AAA-WG]: Extensions & Framework (was: Diameter Issues found @ Connectathon)
Date: Thu, 5 Apr 2001 10:32:19 +0200
Message-ID: <MJEMJBGGCLLDLFFAHLJKMEGOCJAA.fredrik.johansson@ipunplugged.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <OJEJKOMOEAKLMOILFCPJCEDFEFAA.aboba@internaut.com>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

>
>I think that this makes sense:
>
>	1. An extension is by definition a series of commands, plus
>         the AVPs that relate to those commands, as described in
>         the BNF.
>
>      2. Advertising an extension also implies advertisement of
>         the AVPs for that extension, as described in the BNF.
>
>	3. You can send other AVPs in those commands, but only
>         the ones included in the BNF may have the 'M' bit set.
>         Additional AVPs MUST NOT have the 'M' bit set, including
>         vendor-specific AVPs.
>
>      4. This implies that if an AVP needs to be mandatory (such
>         as security-related AVPs like filter-rules, filterid,
>         tunnel AVPs, etc.) then either it is included in the
>         base spec or an extension or its use is PROHIBITED.

Ok, this works fine if the sender knows what the receiver is capable of, but
what about these scenarios:

1. A FA advertise support for MIP (4), AAAF advertise that it can handle
everything (*), AAAH believes that it can send the vendor specific
extension, but the FA can not interprete the AMA correctly.

In this case the result will be that the FA will reject the AMA with a MRI
saying what AVP that was not understood, i.e. the same as it would have been
if the AVP was mandatory but without extension id.

2. A FA advertise that it is capable of supporting extension 4 (MIP) and a
vendor specific ext (say 7). This is sent to AAAF. AAAF in its turn
advertise that it is capable of supporting MIP (4). So now it is not
possible for AAAH to send a AMA back with some vendor specific ext allthough
the FA would be able to interpret it.

The problem here is that there is no way to distinguish between capabilities
as a proxy and as a non-proxy server. This would be solved if AAAF could
advertise that it undertands MIP for local actions and everything for
proxying.

Allthough this only solves one of the problmes, I suggest that we add a new
<Proxy-Extension-Id AVP> saying that this is a capability that the sender
can handle as a proxy.

/Fredrik


>
>I'd vote for having a section at the beginning of the base
>document that describes the DIAMETER extensiblity model in
>detail. This would include not only the extensions mechanism,
>but also the model for adding AVPs (e.g. data modeling), and
>new authentication mechanisms (EAP).
>
>In terms of the framework document, I don't think that the
>existing document is terribly useful. So it might just make
>sense to add the required introductory text to the base
>document and let the framework doc expire.
>
>
>-----Original Message-----
>From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf
>Of Patrice Calhoun
>Sent: Tuesday, April 03, 2001 1:16 PM
>To: Fredrik Johansson
>Cc: Mark Jones; Patrice Calhoun; David Spence; aaa-wg@merit.edu;
>diameter@diameter.org
>Subject: [AAA-WG]: Extensions & Framework (was: Diameter Issues found @
>Connectathon)
>
>
>ok, I believe that there seems to be concensus to add clarifying
>language to
>the spec stating that advertising an extension *requires* that the messages
>defined in the spec do not include AVPs marked as mandatory that weren't
>specific in the said extension.
>
>The biggest question is whether this really belongs in the Extension-Id
>section, or a new section that describes extensions.
>
>BTW, the best place for this would have been the framework document, but we
>decided to kill this spec at the last IETF. In the process of doing this, I
>will need to pull in the terminology, but was there anything else that
>needed
>to be moved to the base?
>
>PatC
>
>
>




From owner-aaa-bof@merit.edu  Thu Apr  5 09:34:37 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA01664
	for <aaa-archive@odin.ietf.org>; Thu, 5 Apr 2001 09:34:37 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id D4E995DEBF; Thu,  5 Apr 2001 09:33:39 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id BD5C45DEC0; Thu,  5 Apr 2001 09:33:39 -0400 (EDT)
Received: from gate.internaut.com (unknown [64.38.134.101])
	by segue.merit.edu (Postfix) with ESMTP id 1217B5DEBF
	for <aaa-wg@merit.edu>; Thu,  5 Apr 2001 09:33:38 -0400 (EDT)
Received: from e1kj2 (e1kj2 [64.38.134.109])
	by gate.internaut.com (8.10.2/8.10.2) with SMTP id f35DNDN22355;
	Thu, 5 Apr 2001 06:23:13 -0700
From: "Bernard Aboba" <aboba@internaut.com>
To: "Fredrik Johansson" <fredrik.johansson@ipunplugged.com>,
        "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>,
        "Tony Johansson" <tony.johansson@ericsson.com>
Cc: "AAA Listan" <aaa-wg@merit.edu>, <Martin.Julien@ece.ericsson.se>
Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
Date: Thu, 5 Apr 2001 06:34:49 -0700
Message-ID: <OJEJKOMOEAKLMOILFCPJOEFMEFAA.aboba@internaut.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <MJEMJBGGCLLDLFFAHLJKMEHECJAA.fredrik.johansson@ipunplugged.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

>
>However, this is new functionality, and we did agree to NOT include new
>functionality, but only fix bugs. So, is this a bug, or a new
>functionality?
>

We are not accepting MAJOR new capabilities at this point,
such as data modeling, e2e security, etc.

It is also accurate to say that a good case needs to be made
for addition of new features. We want to prevent creeping
featurism -- if anything, we probably need to cut more features
than we add. 

However, if a good technical case can be made for a change, and
in particular, if an argument can be made that the change enables
the protocol to better satisfy the requirements -- then we should
make that change. 

Not only will this get us a better protocol -- but it will also
satisfy the requirement that a Proposed Standard represent consensus
of the AAA WG. 

So let's keep the bar high -- but not so high that noone can jump
over it. 



From owner-aaa-bof@merit.edu  Thu Apr  5 09:46:31 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA02079
	for <aaa-archive@odin.ietf.org>; Thu, 5 Apr 2001 09:46:31 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id A97575DE10; Thu,  5 Apr 2001 06:04:10 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9827D5DE08; Thu,  5 Apr 2001 06:04:10 -0400 (EDT)
Received: from mailgw.local.ipunplugged.com (unknown [213.88.134.217])
	by segue.merit.edu (Postfix) with ESMTP id 7CEB75DDDD
	for <aaa-wg@merit.edu>; Thu,  5 Apr 2001 06:04:08 -0400 (EDT)
Received: from fredrikj (c42.local.ipunplugged.com [192.168.4.241])
	by mailgw.local.ipunplugged.com (8.9.3/8.9.3) with SMTP id MAA31285;
	Thu, 5 Apr 2001 12:05:30 +0200
From: "Fredrik Johansson" <fredrik.johansson@ipunplugged.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>,
        "Tony Johansson" <tony.johansson@ericsson.com>
Cc: "AAA Listan" <aaa-wg@merit.edu>, <Martin.Julien@ece.ericsson.se>
Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
Date: Thu, 5 Apr 2001 12:06:00 +0200
Message-ID: <MJEMJBGGCLLDLFFAHLJKMEHECJAA.fredrik.johansson@ipunplugged.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <Roam.SIMC.2.0.6.986429888.17615.pcalhoun@nasnfs>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

>> Here is something more on the Previous-FA-XXXX AVP issue thread
>that I think
>> is missing...
>
>ok.
>
>> Lets say the following scenario that a registered MN is moving
>from one FA to
>> another FA within the same foreign domain and in this scenario the new FA
>> will issue an AMR including the Previous-FA-XXXX AVP to request
>to get the
>> FA-MN and FA-HA keys, and the Authorization-Lifetime. But what about the
>> Session-Id?
>>
>> The new FA does not know about the existing Session-Id, which
>has been use
>> previously used during the initial registration, so the new FA
>will generate
>> a new one in its AMR to the AAAF.
>
>This is a problem that has been plaguing (sp?) me for some time.
>Mobile IP is
>vastly different from PPP, where the user's point of attachment
>changes over
>time. If the AAAH is not notified of this change, then it cannot
>realistically
>terminate the session properly.
>
>Not to mention how to deal with accounting information.
>
>>
>> This leads to a couple of questions:
>>
>> 1. How should the AAAF deal with the new Session-Id? The AAAH
>does not know
>> about new one in this case.
>>
>> One way of solving this could be to let the AAAF over write the
>new session
>> id and add on the initial session id into the Session-Id AVP in the reply
>> back to the new FA together FA-MN and FA-HA keys, and the
>> Authorization-Lifetime. Or maybe a new AVP for the initial session id is
>> needed...
>
>I think it would be much cleaner to have a new AVP, rather than
>the old one.
>
>>
>> 2. Furthermore, the AAAH would not get any information in this
>case, so it
>> would not know that the FA has changed only the AAAF is aware of
>it. Thus,
>> if the AAAH wants to send an STI to terminate the session for
>some reason it
>> would issue the STI towards the wrong FA.
>>
>> A solution to this could perhaps be that the AAAH initially gets the
>> information about responsible AAAF in the foreign network, so if the AAAH
>> needs to send an STI it would issue it towards the AAAF and the
>AAAF would
>> be responsible to resolve it and forward it to the right FA.
>
>hmmmm... I would MUCH prefer to NOT assume state on the AAAF. I
>believe that
>it would be more appropriate to define a new message, of type
>-Ind, which is
>sent by the AAAF to the AAAH to notify it of a location change.

I agree, the AAAF should not have to keep state.
Another thing, I believe the AAAF need to terminate the accounting session
with the old FA. Perhaps some text is needed to explain this.

for example:
11.7  Session Termination

   The Diameter Base Protocol provides a set of messages that MUST be
   used by any peer to explicitly request that a previously
   authenticated and/or authorized session be terminated. Since the
   Session-Id is typically tied to a particular service (i.e. Mobile IP,
   NASREQ, etc), the session termination messages are used to request
   that the service tied to the Session Id be terminated. The access node
   must also terminate all accounting sessions associated with the
   session indicated by the Session Id. For example, when a MN moves
   from one FA to another it will re-register, thus a new session will be
   setup between the new FA and AAAH. AAAH MUST then send a STI
   to the old FA to terminate the MIP session and also cause the old FA
   to terminate any accounting sessions it has with its local AAA for this
   MN. In the case where both FAs are under the same administrative
   domain, the local AAA MUST send a STI to the old FA in order to
   terminate possible accounting sessions since new ones will be started
   with the new FA.


>
>However, this is new functionality, and we did agree to NOT include new
>functionality, but only fix bugs. So, is this a bug, or a new
>functionality?
>

Definitely a bug, the protocol is not working rigth without it. It makes
sure the information is where it is supposed to be.

/Fredrik

>> Another way would be to let the AAAF to issue an Indication to
>the AAAH to
>> inform that the MN has changed FA.
>
>oops, great minds think alike :)
>
>PatC




From owner-aaa-bof@merit.edu  Thu Apr  5 10:15:19 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02851
	for <aaa-archive@odin.ietf.org>; Thu, 5 Apr 2001 10:15:19 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id D8E705DE55; Thu,  5 Apr 2001 10:14:54 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id C61A45DDD1; Thu,  5 Apr 2001 10:14:54 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id 88E5C5DDC7
	for <aaa-wg@merit.edu>; Thu,  5 Apr 2001 10:14:53 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA07874;
	Thu, 5 Apr 2001 07:14:36 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA23585;
	Thu, 5 Apr 2001 07:14:34 -0700 (PDT)
Received: from darius (darius [10.6.84.105])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id HAA08796;
	Thu, 5 Apr 2001 07:14:32 -0700 (PDT)
Date: Thu, 5 Apr 2001 07:14:30 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Subject: [AAA-WG]: New Extension text in base protocol
To: Bernard Aboba <aboba@internaut.com>
Cc: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>,
        Fredrik Johansson <fredrik.johansson@ipunplugged.com>,
        Mark Jones <mjones@bridgewatersystems.com>,
        David Spence <DSpence@Interlinknetworks.com>, aaa-wg@merit.edu,
        diameter@diameter.org
In-Reply-To: "Your message with ID" <OJEJKOMOEAKLMOILFCPJCEDFEFAA.aboba@internaut.com>
Message-ID: <Roam.SIMC.2.0.6.986480070.19160.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

All,

Below is the proposed text that I have added to the -02 candidate that
describes what a Diameter extension is.

Please send any comments,

PatC
----


2.3  Diameter Extensions

   As previously mentioned, the Diameter base protocol does not operate
   on its own, but requires appplication-specific extensions, commonly
   referred to as Diameter extensions. A Diameter extension is a
   specification that defines one or more Diameter Command-Codes, the
   expected AVPs in an ABNF [31] grammar (see section 3.2), and MAY also
   define new AVPs.

   Every Diameter Extension specification MUST have an IANA assigned
   Extension-Id value (see section 6.1.3). This Extension-Id is
   advertised during the capabilities exchange phase (see section 6.0).
   Advertising support of a particular extension implies that the
   receiver support all of the Command Codes, and the AVPs specified in
   the associated ABNF, described in the specification.

   An implementation MAY add arbitrary AVPs to any command defined in an
   extension, including vendor-specific AVPs. However, such AVPs MUST
   NOT have the M(andatory) bit set. An implementation that adds AVPs
   not specified in a command's ABNF, and sets the AVP's M(andatory) bit
   MUST NOT advertise support of the extension.

   An implementation MAY support both a proprietary version of an
   extension by requesting an IANA extension identifier (see section
   17.3), while supporting the original extension. During the
   capabilities exchange, a Diameter node could know whether it should
   send the prorietary version, or the standards one, by inspecting the
   extensions advertised by the peer.




From owner-aaa-bof@merit.edu  Thu Apr  5 10:40:14 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA03529
	for <aaa-archive@odin.ietf.org>; Thu, 5 Apr 2001 10:40:14 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 927B95DE5E; Thu,  5 Apr 2001 10:39:59 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 649165DE73; Thu,  5 Apr 2001 10:39:59 -0400 (EDT)
Received: from mailgw.local.ipunplugged.com (unknown [213.88.134.217])
	by segue.merit.edu (Postfix) with ESMTP id 3FDC35DE5E
	for <aaa-wg@merit.edu>; Thu,  5 Apr 2001 10:39:57 -0400 (EDT)
Received: from fredrikj (c42.local.ipunplugged.com [192.168.4.241])
	by mailgw.local.ipunplugged.com (8.9.3/8.9.3) with SMTP id QAA03483;
	Thu, 5 Apr 2001 16:40:16 +0200
From: "Fredrik Johansson" <fredrik.johansson@ipunplugged.com>
To: "Mark Jones" <mjones@bridgewatersystems.com>,
        "Bernard Aboba" <aboba@internaut.com>,
        "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>
Cc: "David Spence" <DSpence@Interlinknetworks.com>, <aaa-wg@merit.edu>,
        <diameter@diameter.org>
Subject: RE: [AAA-WG]: Extensions & Framework (was: Diameter Issues found @ Connectathon)
Date: Thu, 5 Apr 2001 16:40:47 +0200
Message-ID: <MJEMJBGGCLLDLFFAHLJKIEHNCJAA.fredrik.johansson@ipunplugged.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <001301c0bddd$75476850$2096a8c0@mjones.bridgewatersys.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

>
>> >The problem here is that there is no way to distinguish between
>> capabilities
>> >as a proxy and as a non-proxy server. This would be solved if AAAF could
>> >advertise that it undertands MIP for local actions and everything for
>> >proxying.
>>
>
>But which extensions would you advertise for proxying? If 90% of your
>existing peers advertise support for an extension, do you advertise that
>extension to new peers when they connect?

For proxying I would advertise wildcard, i.e. I'm willing to receive any
extension and try to find a peer to proxy it to. If a do not find one, I'll
have to reply with a suitable error code.

>
>> Correct. As you point out, capabilities negotiation is really about
>> finding the sub-set of capabilities that is usable along the path
>> from the home server to the NAS, not just on the next hop.
>>
>
>Capabilities exchange in proxy scenarios is way beyond what can be
>accomplished with the humble DRI as defined in the current draft so I vote
>we avoid this particular rat-hole at this point. The DRIs only represent a
>capabilites snapshot anyway. For any Diameter peer in the role of routing
>proxy, the capabilities list is dynamic since a new peer may come online
>which supports additional extensions. Since DRIs are exchanged only on
>establishment of the transport connection, there is no way to inform
>existing peers of the additional capabilities.
>
>The Extension-Id AVP as currently defined in the draft advertises locally
>supported
>extensions. Lets keep this definition and leave capability
>exchange in proxy
>scenarios as the subject of some future Enhanced Capability Exchange
>extension.

So, do you allways assume that a proxy does not care what extensions it
forwards? Or do we say that a company having two sites can not use vendor
specific extensions between its sites unless the ISP it is useing supports
the same vendor specific extensions?

/Fredrik

>
>Regards,
>       Mark




From owner-aaa-bof@merit.edu  Thu Apr  5 10:50:16 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA03826
	for <aaa-archive@odin.ietf.org>; Thu, 5 Apr 2001 10:50:15 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id A9E5B5DECD; Thu,  5 Apr 2001 10:46:39 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 975AE5DECC; Thu,  5 Apr 2001 10:46:39 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id 31B2E5DDD1
	for <aaa-wg@merit.edu>; Thu,  5 Apr 2001 10:46:38 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA22031;
	Thu, 5 Apr 2001 07:46:27 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA28000;
	Thu, 5 Apr 2001 07:46:27 -0700 (PDT)
Received: from darius (darius [10.6.84.105])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id HAA09191;
	Thu, 5 Apr 2001 07:46:23 -0700 (PDT)
Date: Thu, 5 Apr 2001 07:46:21 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Subject: RE: [AAA-WG]: Extensions & Framework (was: Diameter Issues found @ Connectathon)
To: Fredrik Johansson <fredrik.johansson@ipunplugged.com>
Cc: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>,
        Bernard Aboba <aboba@internaut.com>,
        Mark Jones <mjones@bridgewatersystems.com>,
        David Spence <DSpence@Interlinknetworks.com>, aaa-wg@merit.edu,
        diameter@diameter.org
In-Reply-To: "Your message with ID" <MJEMJBGGCLLDLFFAHLJKGEHMCJAA.fredrik.johansson@ipunplugged.com>
Message-ID: <Roam.SIMC.2.0.6.986481981.14062.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> >
> >> >The problem here is that there is no way to distinguish between
> >> capabilities
> >> >as a proxy and as a non-proxy server. This would be solved if AAAF could
> >> >advertise that it undertands MIP for local actions and everything for
> >> >proxying.
> >>
> >> Correct. As you point out, capabilities negotiation is really about
> >> finding the sub-set of capabilities that is usable along the path
> >> from the home server to the NAS, not just on the next hop.
> >
> >Let's think this through carefully.
> >
> >If, as you state, a NAS has to know the capabilities of *all*
> >proxies towards
> >the home server, this will require a whole lot of messaging (a
> >traceroute like
> >message). This was *never* intended to be supported in Diameter.
> 
> Agree
> 
> >
> >The original intent of Diameter was to know the peer's capabilities, so a
> >message could be sent to it, and then it is responsible for
> >finding a next hop
> >for the message.
> >
> >btw, what we are trying to support here, is a NAS, with vendor proprietary
> >extensions, going through a set of proxies that don't understand the
> >extension, to a home that does. What, btw, are the chances of a
> >NAS and a home
> >server supporting a vendor proprietary extension, but not the
> >proxies in the
> >middle.
> >
> 
> Why would this be so unlikely? Two companies (or one company, two sites)
> using a ISP that does not support the company specific extension isn't that
> unlikely. Remember an access node might as well be a FA :-)

If that's the case, then I would expect the AAA server to ALSO support the
proprietary extension, right?

If this is confined within a domain, then it is easily rectified by ensuring
that all of the boxes are from the same manufacturer. We are talking about
cases here where there is a mix if vendors in a large inter-domain network.
The chances of both end diameter nodes being of the same manufacturer, while
the rest of the middle from another, is low (and doesn't seem like a problem
that really needs to be solved).

PatC




From owner-aaa-bof@merit.edu  Thu Apr  5 11:25:42 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05112
	for <aaa-archive@odin.ietf.org>; Thu, 5 Apr 2001 11:25:42 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id ED09A5DE73; Thu,  5 Apr 2001 11:25:05 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id D91FA5DDC8; Thu,  5 Apr 2001 11:25:05 -0400 (EDT)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id 9F72C5DDA2
	for <aaa-wg@merit.edu>; Thu,  5 Apr 2001 11:25:04 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA26241;
	Thu, 5 Apr 2001 08:24:50 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA03445;
	Thu, 5 Apr 2001 08:24:48 -0700 (PDT)
Received: from darius (darius [10.6.84.105])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id IAA09626;
	Thu, 5 Apr 2001 08:24:37 -0700 (PDT)
Date: Thu, 5 Apr 2001 08:24:35 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Subject: RE: [AAA-WG]: Extensions & Framework (was: Diameter Issues found @ Connectathon)
To: Mark Jones <mjones@bridgewatersystems.com>
Cc: Bernard Aboba <aboba@internaut.com>,
        Fredrik Johansson <fredrik.johansson@ipunplugged.com>,
        Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>,
        David Spence <DSpence@Interlinknetworks.com>, aaa-wg@merit.edu,
        diameter@diameter.org
In-Reply-To: "Your message with ID" <001301c0bddd$75476850$2096a8c0@mjones.bridgewatersys.com>
Message-ID: <Roam.SIMC.2.0.6.986484275.479.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> The Extension-Id AVP as currently defined in the draft advertises locally
> supported
> extensions. Lets keep this definition and leave capability exchange in proxy
> scenarios as the subject of some future Enhanced Capability Exchange
> extension.

It has occured to me that this functionality could be piggy backed on top of
the E2E messages defined in the strong crypto I-D, with relative ease.

PatC




From owner-aaa-bof@merit.edu  Thu Apr  5 11:30:11 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05297
	for <aaa-archive@odin.ietf.org>; Thu, 5 Apr 2001 11:30:11 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 43E9C5DF42; Thu,  5 Apr 2001 09:14:40 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 27CC75DEE4; Thu,  5 Apr 2001 09:14:40 -0400 (EDT)
Received: from gate.internaut.com (unknown [64.38.134.101])
	by segue.merit.edu (Postfix) with ESMTP id 2BAB25DF1E
	for <aaa-wg@merit.edu>; Thu,  5 Apr 2001 09:14:32 -0400 (EDT)
Received: from e1kj2 (e1kj2 [64.38.134.109])
	by gate.internaut.com (8.10.2/8.10.2) with SMTP id f35D44N21406;
	Thu, 5 Apr 2001 06:04:04 -0700
From: "Bernard Aboba" <aboba@internaut.com>
To: "Fredrik Johansson" <fredrik.johansson@ipunplugged.com>,
        "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>
Cc: "Mark Jones" <mjones@bridgewatersystems.com>,
        "David Spence" <DSpence@Interlinknetworks.com>, <aaa-wg@merit.edu>,
        <diameter@diameter.org>
Subject: RE: [AAA-WG]: Extensions & Framework (was: Diameter Issues found @ Connectathon)
Date: Thu, 5 Apr 2001 06:15:40 -0700
Message-ID: <OJEJKOMOEAKLMOILFCPJKEFMEFAA.aboba@internaut.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <MJEMJBGGCLLDLFFAHLJKMEGOCJAA.fredrik.johansson@ipunplugged.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

>The problem here is that there is no way to distinguish between
capabilities
>as a proxy and as a non-proxy server. This would be solved if AAAF could
>advertise that it undertands MIP for local actions and everything for
>proxying.

Correct. As you point out, capabilities negotiation is really about
finding the sub-set of capabilities that is usable along the path
from the home server to the NAS, not just on the next hop.




From owner-aaa-bof@merit.edu  Thu Apr  5 11:36:08 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05524
	for <aaa-archive@odin.ietf.org>; Thu, 5 Apr 2001 11:36:08 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 622525DDA2; Thu,  5 Apr 2001 11:30:42 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 4E91F5DE98; Thu,  5 Apr 2001 11:30:42 -0400 (EDT)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id 2F0E85DDA2
	for <aaa-wg@merit.edu>; Thu,  5 Apr 2001 11:30:41 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA02066
	for <aaa-wg@merit.edu>; Thu, 5 Apr 2001 08:30:40 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA04606
	for <aaa-wg@merit.edu>; Thu, 5 Apr 2001 08:30:40 -0700 (PDT)
Received: from darius (darius [10.6.84.105])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id IAA09698
	for <aaa-wg@merit.edu>; Thu, 5 Apr 2001 08:30:39 -0700 (PDT)
Date: Thu, 5 Apr 2001 08:30:37 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Subject: [AAA-WG]: Apparent new goal of the interim meeting
To: aaa-wg@merit.edu
Message-ID: <Roam.SIMC.2.0.6.986484637.22509.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

All,

I am sufficiently concerned that the AD has stated that one of the goals of
the interim meeting is to kill proxies. Proxies are universally used, and will
be required in the networks that I know of. Redirect mode is not an answer to
all problems.

I am really concerned with the obvious delays that would occur by killing this
feature, not to mention the lack of interest the market would have on a
protocol that doesn't meet its demands. Remember that the AAA WG had proxies
has a MUST in many access technologies, and the protocol meets the
requirements.

Is there actual WG concensus to killing proxies? Can the IESG decide that the
market is wrong, and the IETF will not support it?

PatC




From owner-aaa-bof@merit.edu  Thu Apr  5 11:37:31 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05592
	for <aaa-archive@odin.ietf.org>; Thu, 5 Apr 2001 11:37:30 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id BE3565DEB2; Thu,  5 Apr 2001 11:35:09 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id A7F1F5DECF; Thu,  5 Apr 2001 11:35:09 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id 6D44B5DEB2
	for <aaa-wg@merit.edu>; Thu,  5 Apr 2001 11:35:08 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA07521;
	Thu, 5 Apr 2001 08:26:49 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA03753;
	Thu, 5 Apr 2001 08:26:48 -0700 (PDT)
Received: from darius (darius [10.6.84.105])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id IAA09664;
	Thu, 5 Apr 2001 08:26:45 -0700 (PDT)
Date: Thu, 5 Apr 2001 08:26:44 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Subject: RE: [AAA-WG]: Extensibility model and IANA considerations
To: Randy Bush <randy@psg.com>
Cc: Glen Zorn <gwz@cisco.com>, aaa-wg@merit.edu
In-Reply-To: "Your message with ID" <E14lBb3-000GbP-00@rip.psg.com>
Message-ID: <Roam.SIMC.2.0.6.986484404.28190.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> > But now (assuming that we do not, at this time, have knowledge of every
> > Diameter extension that will ever exist) we're back to updating the base
> > every time a new extension needs the 'M' bit set on an otherwise optional
> > AVP.
> 
> this would seem to be the multiplicative intersection of two 'features',
> the base plus extensions approach, and mandatory extensions.

This is a non-issue. The new extension section in the base makes this much
clearer, and all that was required what non-protocol clarification text.

PatC




From owner-aaa-bof@merit.edu  Thu Apr  5 11:43:26 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05833
	for <aaa-archive@odin.ietf.org>; Thu, 5 Apr 2001 11:43:26 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id BB4985DDC8; Thu,  5 Apr 2001 11:39:33 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9EE655DE98; Thu,  5 Apr 2001 11:39:33 -0400 (EDT)
Received: from mail01.bridgewatersystems.com (mail01.bridgewatersystems.com [216.113.7.9])
	by segue.merit.edu (Postfix) with ESMTP id 32EED5DDC8
	for <aaa-wg@merit.edu>; Thu,  5 Apr 2001 11:39:27 -0400 (EDT)
Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2])
	by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id MAA11267;
	Thu, 5 Apr 2001 12:35:48 -0400
Received: from mjones (mjones.bridgewatersys.com [192.168.150.32])
	by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.1) with SMTP id LAA26567;
	Thu, 5 Apr 2001 11:40:06 -0400 (EDT)
From: "Mark Jones" <mjones@bridgewatersystems.com>
To: "Fredrik Johansson" <fredrik.johansson@ipunplugged.com>,
        "Bernard Aboba" <aboba@internaut.com>,
        "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>
Cc: "David Spence" <DSpence@Interlinknetworks.com>, <aaa-wg@merit.edu>,
        <diameter@diameter.org>
Subject: RE: [diameter] RE: [AAA-WG]: Extensions & Framework (was: Diameter Issues found @ Connectathon)
Date: Thu, 5 Apr 2001 11:41:11 -0400
Message-ID: <001b01c0bde6$d75df280$2096a8c0@mjones.bridgewatersys.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <MJEMJBGGCLLDLFFAHLJKIEHNCJAA.fredrik.johansson@ipunplugged.com>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

> For proxying I would advertise wildcard, i.e. I'm willing to receive any
> extension and try to find a peer to proxy it to. If a do not find
> one, I'll
> have to reply with a suitable error code.
>

I understand but that would be your policy and I may implement a different
one hoping to reduce the number of replies with errors. I don't think we
should dictate this policy in the base protocol so I'm happy with the text
in the current draft as is.

Regards,
       Mark




From owner-aaa-bof@merit.edu  Thu Apr  5 11:58:20 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06210
	for <aaa-archive@odin.ietf.org>; Thu, 5 Apr 2001 11:58:19 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 1BDDD5DE9A; Thu,  5 Apr 2001 11:58:03 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 0AAA95DDC1; Thu,  5 Apr 2001 11:58:03 -0400 (EDT)
Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210])
	by segue.merit.edu (Postfix) with ESMTP id D602E5DD97
	for <aaa-wg@merit.edu>; Thu,  5 Apr 2001 11:58:00 -0400 (EDT)
Received: from JSCHNIZL-W2K.cisco.com (jschnizl-isdn1.cisco.com [171.68.12.74]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id IAA24556; Thu, 5 Apr 2001 08:57:54 -0700 (PDT)
Message-Id: <4.3.2.7.2.20010405114325.033cef08@diablo.cisco.com>
X-Sender: jschnizl@diablo.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 05 Apr 2001 11:57:23 -0400
To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
From: John Schnizlein <jschnizl@cisco.com>
Subject: Re: [AAA-WG]: Apparent new goal of the interim meeting
Cc: aaa-wg@merit.edu
In-Reply-To: <Roam.SIMC.2.0.6.986484637.22509.pcalhoun@nasnfs>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Pat,

I heard the goal differently.

Since the IETF has adopted a strategy of not standardizing protocols
that have security flaws, the security problems with AAA proxies 
must be resolved before Diameter progresses. IESG is expected to
enforce the consensus of the IETF on this subject, and ADs focus 
attention to this obligation on their own areas so that they need
fewer reminders from the security ADs.

We in this WG know the value of forwarding AAA requests to an
authoritative domain largely through the success the less-structured
RADIUS proxy provided for outsourcing dial access. We expect this
feature to be at least as important for the other access methods.
On the last Friday in Minneapolis, I did not hear consensus on what
we described as end-to-end security for attributes, which is an
essential part of keeping corporate secrets while outsourcing access.
We need a resolution of the collision between the need for security
and the need for inter-domain AAA.

Without claiming any particular expertise in the area, let me suggest
that arbitrary chains of proxies are really not necessary. If there
were only two domains - one proxy hop - with everything else done
through redirects, we might be able to find a solution that the
security area would find acceptable. Is this possible?

John

At 11:30 AM 4/5/2001, Patrice Calhoun wrote:
>... Remember that the AAA WG had proxies has a MUST in many access 
>technologies, and the protocol meets the requirements.
>
>Is there actual WG concensus to killing proxies? Can the IESG decide 
>that the market is wrong, and the IETF will not support it?




From owner-aaa-bof@merit.edu  Thu Apr  5 12:00:10 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06280
	for <aaa-archive@odin.ietf.org>; Thu, 5 Apr 2001 12:00:09 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 5121D5DDC7; Thu,  5 Apr 2001 10:23:25 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 37A3A5DDD1; Thu,  5 Apr 2001 10:23:25 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id B6DC15DDC7
	for <aaa-wg@merit.edu>; Thu,  5 Apr 2001 10:23:23 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA11624;
	Thu, 5 Apr 2001 07:23:13 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA25205;
	Thu, 5 Apr 2001 07:23:12 -0700 (PDT)
Received: from darius (darius [10.6.84.105])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id HAA08876;
	Thu, 5 Apr 2001 07:23:09 -0700 (PDT)
Date: Thu, 5 Apr 2001 07:23:08 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Subject: RE: [AAA-WG]: Extensions & Framework (was: Diameter Issues found @ Connectathon)
To: Bernard Aboba <aboba@internaut.com>
Cc: Fredrik Johansson <fredrik.johansson@ipunplugged.com>,
        Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>,
        Mark Jones <mjones@bridgewatersystems.com>,
        David Spence <DSpence@Interlinknetworks.com>, aaa-wg@merit.edu,
        diameter@diameter.org
In-Reply-To: "Your message with ID" <OJEJKOMOEAKLMOILFCPJKEFMEFAA.aboba@internaut.com>
Message-ID: <Roam.SIMC.2.0.6.986480588.24720.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> >The problem here is that there is no way to distinguish between
> capabilities
> >as a proxy and as a non-proxy server. This would be solved if AAAF could
> >advertise that it undertands MIP for local actions and everything for
> >proxying.
> 
> Correct. As you point out, capabilities negotiation is really about
> finding the sub-set of capabilities that is usable along the path
> from the home server to the NAS, not just on the next hop.

Let's think this through carefully.

If, as you state, a NAS has to know the capabilities of *all* proxies towards
the home server, this will require a whole lot of messaging (a traceroute like
message). This was *never* intended to be supported in Diameter. 

The original intent of Diameter was to know the peer's capabilities, so a
message could be sent to it, and then it is responsible for finding a next hop
for the message.

btw, what we are trying to support here, is a NAS, with vendor proprietary
extensions, going through a set of proxies that don't understand the
extension, to a home that does. What, btw, are the chances of a NAS and a home
server supporting a vendor proprietary extension, but not the proxies in the
middle.

I would argue that this is not a problem that needs to be solved.

PatC




From owner-aaa-bof@merit.edu  Thu Apr  5 12:06:51 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06533
	for <aaa-archive@odin.ietf.org>; Thu, 5 Apr 2001 12:06:49 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 6A6FB5DDC1; Thu,  5 Apr 2001 12:05:35 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 4ACDE5DEA7; Thu,  5 Apr 2001 12:05:35 -0400 (EDT)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by segue.merit.edu (Postfix) with ESMTP id 000985DDC1
	for <aaa-wg@merit.edu>; Thu,  5 Apr 2001 12:05:32 -0400 (EDT)
Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f35G5Vs09236
	for <aaa-wg@merit.edu>; Thu, 5 Apr 2001 18:05:32 +0200 (MEST)
Received: FROM esealnt743.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Thu Apr 05 18:05:31 2001 +0200
Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <HA3DBAC5>; Thu, 5 Apr 2001 18:05:31 +0200
Message-ID: <577066326047D41180AC00508B955DDA01D7FF5D@eestqnt104.es.eu.ericsson.se>
From: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>
To: "'Patrice Calhoun'" <pcalhoun@nasnfs.Eng.Sun.COM>,
        Tony Johansson <tony.johansson@ericsson.com>
Cc: Fredrik Johansson <fredrik.johansson@ipunplugged.com>,
        AAA Listan <aaa-wg@merit.edu>,
        "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>
Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
Date: Thu, 5 Apr 2001 18:05:29 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> > 
> > This leads to a couple of questions:
> > 
> > 1. How should the AAAF deal with the new Session-Id? The 
> AAAH does not know
> > about new one in this case.
> > 
> > One way of solving this could be to let the AAAF over write 
> the new session
> > id and add on the initial session id into the Session-Id 
> AVP in the reply
> > back to the new FA together FA-MN and FA-HA keys, and the
> > Authorization-Lifetime. Or maybe a new AVP for the initial 
> session id is
> > needed...
> 
> I think it would be much cleaner to have a new AVP, rather 
> than the old one. 

Just to make sure, I guess you meant that 
the Session-Id that has been authorized by the AAAH should
remain the valid Session-Id for the active MIP session, right?
Let's call "authorized Session-Id", the Session-Id that has
been officially authorized previously by the AAAH.

Let's say that the MN moves to a new FA within
the same domain. When the AAAF receives a MIP Registration 
from a MN, the message includes a MIP-Previous-FA-FQDN AVP,
which identifies the previous FA. It also includes the 
User-Name AVP, which is supposed to be used for identifying
the FA-MN and FA-HA keys that need to be sent to MN. 
That authorized Session-ID would be sent back to 
the new FA in the AMA message from the AAAF, packaged in a new 
"MIP-Previous-Session-ID" AVP. The new Session-ID would be just
ignored? I guess that the "authorized"
Session-ID could be kept in the AAAF, along with the FA-XX keys.

Using that new AVP, it remains possible to support
roaming between FAs within the same domain without involving
unnecessarily the AAAH. Also, the accounting part is 
not impacted at all, since the Session-Id remains the same.
No accounting start and stop are required, neither re-authentication
and re-generation of keys. I think that is a very efficient and
clean way of supporting it.

About the STI to the old FA, why can't it be handled by the 
Mobile IP standard? I guess an STI should be sent to the Diameter 
client (FA) only if the session needs to be interrupted, or if you
prefer, prematurely terminated. However, there is no need of 
terminating the Accounting session.

But if we support roaming between FA the way described 
previously, then we still have the problems that the AAAF
does not seem to be that "stateless", there is a problem
of synchronizing data between the AAAF and the AAAH, 
especially in terms of active FA, and it is not obvious
that we would gain that much in performance compared to
complexity, if we start adding new messages and AVPs.

I would say that I like the previous suggestion, if we
would add that the AAAF does not keep any information
at all on the session, and that the AAAH remains the 
master of the session. That means that each Registration
needs to go to the AAAH (AMR), which performs the authentication
and overides the Session-Id with the authorized one, while
updating its reference to the actual FA and triggering a STI
to the previous FA. The key for the session would be the User-Name,
as already proposed for the AAAF. It seems to be more work, but it is
similar to the case with the HAA story, which means more generic
and less complexed traffic cases. In fact, moving from one
FA in one domain to another FA in another domain would also
work perfectly in that context. Even the keys could be 
transmitted that way, at the exception of the FA-HA, in the
case where the HA is in the foreign domain, which I don't 
really understand why we must comply to that???

I guess you understand that I now question to use of the 
MIP-Previous-FA-XX AVPs, since they don't seem to bring 
much information else than telling the FA that they used
to be connected to a former FA, for which the FA can not
do much about, beside knowing that if it was in the same
domain, then it should take care of sending himself the
MIP Registration to the HA, when it receives the required key
from the AAAF, right?

And as a note, I think that a "key" for a session in the AAAH
makes much more sense as a User-Name for the primary key, and as a
Session-ID for the secondary key. I guess that making the
User-Name mandatory in every message in a good thing.

> > 
> > 2. Furthermore, the AAAH would not get any information in 
> this case, so it
> > would not know that the FA has changed only the AAAF is 
> aware of it. Thus,
> > if the AAAH wants to send an STI to terminate the session 
> for some reason it
> > would issue the STI towards the wrong FA.
> > 
> > A solution to this could perhaps be that the AAAH initially gets the
> > information about responsible AAAF in the foreign network, 
> so if the AAAH
> > needs to send an STI it would issue it towards the AAAF and 
> the AAAF would
> > be responsible to resolve it and forward it to the right FA.
> 
> hmmmm... I would MUCH prefer to NOT assume state on the AAAF. 
> I believe that
> it would be more appropriate to define a new message, of type 
> -Ind, which is
> sent by the AAAF to the AAAH to notify it of a location change.
 
How can you achieve a stateless AAAF, when you need to keep at
least the FA-MN and FA-HA keys for the particular MIP session?
AFAIK, there is no way of pulling the data from the previous
FA, and transfer them to the new FA, right? That means that the
AAAF needs to keep a state. Then, what's the big deal with 
keeping the information about the FA as well and then the AAAH 
would only need to know the AAAF? The AAAF would become in charge
of forwarding it to the good FA.

> However, this is new functionality, and we did agree to NOT 
> include new
> functionality, but only fix bugs. So, is this a bug, or a new 
> functionality?
> 
> > Another way would be to let the AAAF to issue an Indication 
> to the AAAH to
> > inform that the MN has changed FA.
> 
> oops, great minds think alike :)
> 
> PatC
> 

Regards,
Martin



From owner-aaa-bof@merit.edu  Thu Apr  5 12:34:06 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07306
	for <aaa-archive@odin.ietf.org>; Thu, 5 Apr 2001 12:34:06 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 4BCEB5DF62; Thu,  5 Apr 2001 12:32:06 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 2134D5E03D; Thu,  5 Apr 2001 12:32:06 -0400 (EDT)
Received: from rip.psg.com (rip.psg.com [147.28.0.39])
	by segue.merit.edu (Postfix) with ESMTP id B586E5DF62
	for <aaa-wg@merit.edu>; Thu,  5 Apr 2001 12:32:04 -0400 (EDT)
Received: from randy by rip.psg.com with local (Exim 3.16 #1)
	id 14lCfy-000HCS-00; Thu, 05 Apr 2001 09:32:02 -0700
From: Randy Bush <randy@psg.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Cc: aaa-wg@merit.edu
Subject: Re: [AAA-WG]: Apparent new goal of the interim meeting
References: <Roam.SIMC.2.0.6.986484637.22509.pcalhoun@nasnfs>
Message-Id: <E14lCfy-000HCS-00@rip.psg.com>
Date: Thu, 05 Apr 2001 09:32:02 -0700
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

> I am sufficiently concerned that the AD has stated that one of the goals
> of the interim meeting is to kill proxies.

this particular AD did not say that.  what i said is that aaa will be
securable, proxies or not.

randy



From owner-aaa-bof@merit.edu  Thu Apr  5 12:36:44 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07376
	for <aaa-archive@odin.ietf.org>; Thu, 5 Apr 2001 12:36:43 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 49D055DEC6; Thu,  5 Apr 2001 12:36:27 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 307645DEC2; Thu,  5 Apr 2001 12:36:27 -0400 (EDT)
Received: from rip.psg.com (rip.psg.com [147.28.0.39])
	by segue.merit.edu (Postfix) with ESMTP id D85065DEC6
	for <aaa-wg@merit.edu>; Thu,  5 Apr 2001 12:36:25 -0400 (EDT)
Received: from randy by rip.psg.com with local (Exim 3.16 #1)
	id 14lCkA-000HDe-00; Thu, 05 Apr 2001 09:36:22 -0700
From: Randy Bush <randy@psg.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: John Schnizlein <jschnizl@cisco.com>
Cc: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>, aaa-wg@merit.edu
Subject: Re: [AAA-WG]: Apparent new goal of the interim meeting
References: <Roam.SIMC.2.0.6.986484637.22509.pcalhoun@nasnfs>
	<4.3.2.7.2.20010405114325.033cef08@diablo.cisco.com>
Message-Id: <E14lCkA-000HDe-00@rip.psg.com>
Date: Thu, 05 Apr 2001 09:36:22 -0700
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

> Since the IETF has adopted a strategy of not standardizing protocols
> that have security flaws, the security problems with AAA proxies 
> must be resolved before Diameter progresses. IESG is expected to
> enforce the consensus of the IETF on this subject, and ADs focus 
> attention to this obligation on their own areas so that they need
> fewer reminders from the security ADs.
> 
> We in this WG know the value of forwarding AAA requests to an
> authoritative domain largely through the success the less-structured
> RADIUS proxy provided for outsourcing dial access. We expect this
> feature to be at least as important for the other access methods.
> On the last Friday in Minneapolis, I did not hear consensus on what
> we described as end-to-end security for attributes, which is an
> essential part of keeping corporate secrets while outsourcing access.
> We need a resolution of the collision between the need for security
> and the need for inter-domain AAA.

bingo!

> Without claiming any particular expertise in the area, let me suggest
> that arbitrary chains of proxies are really not necessary. If there
> were only two domains - one proxy hop - with everything else done
> through redirects, we might be able to find a solution that the
> security area would find acceptable. Is this possible?

don't make me too hopeful.

randy



From owner-aaa-bof@merit.edu  Thu Apr  5 12:55:37 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06281
	for <aaa-archive@odin.ietf.org>; Thu, 5 Apr 2001 12:00:09 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 176015DED4; Thu,  5 Apr 2001 10:32:22 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 04DCC5DED3; Thu,  5 Apr 2001 10:32:22 -0400 (EDT)
Received: from mail01.bridgewatersystems.com (mail01.bridgewatersystems.com [216.113.7.9])
	by segue.merit.edu (Postfix) with ESMTP id 6BE9F5DEB4
	for <aaa-wg@merit.edu>; Thu,  5 Apr 2001 10:32:20 -0400 (EDT)
Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2])
	by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id LAA10530;
	Thu, 5 Apr 2001 11:28:37 -0400
Received: from mjones (mjones.bridgewatersys.com [192.168.150.32])
	by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.1) with SMTP id KAA23685;
	Thu, 5 Apr 2001 10:32:55 -0400 (EDT)
From: "Mark Jones" <mjones@bridgewatersystems.com>
To: "Bernard Aboba" <aboba@internaut.com>,
        "Fredrik Johansson" <fredrik.johansson@ipunplugged.com>,
        "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>
Cc: "David Spence" <DSpence@Interlinknetworks.com>, <aaa-wg@merit.edu>,
        <diameter@diameter.org>
Subject: RE: [AAA-WG]: Extensions & Framework (was: Diameter Issues found @ Connectathon)
Date: Thu, 5 Apr 2001 10:34:01 -0400
Message-ID: <001301c0bddd$75476850$2096a8c0@mjones.bridgewatersys.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <OJEJKOMOEAKLMOILFCPJKEFMEFAA.aboba@internaut.com>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

> >The problem here is that there is no way to distinguish between
> capabilities
> >as a proxy and as a non-proxy server. This would be solved if AAAF could
> >advertise that it undertands MIP for local actions and everything for
> >proxying.
>

But which extensions would you advertise for proxying? If 90% of your
existing peers advertise support for an extension, do you advertise that
extension to new peers when they connect?

> Correct. As you point out, capabilities negotiation is really about
> finding the sub-set of capabilities that is usable along the path
> from the home server to the NAS, not just on the next hop.
>

Capabilities exchange in proxy scenarios is way beyond what can be
accomplished with the humble DRI as defined in the current draft so I vote
we avoid this particular rat-hole at this point. The DRIs only represent a
capabilites snapshot anyway. For any Diameter peer in the role of routing
proxy, the capabilities list is dynamic since a new peer may come online
which supports additional extensions. Since DRIs are exchanged only on
establishment of the transport connection, there is no way to inform
existing peers of the additional capabilities.

The Extension-Id AVP as currently defined in the draft advertises locally
supported
extensions. Lets keep this definition and leave capability exchange in proxy
scenarios as the subject of some future Enhanced Capability Exchange
extension.

Regards,
       Mark




From owner-aaa-bof@merit.edu  Thu Apr  5 13:05:29 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08247
	for <aaa-archive@odin.ietf.org>; Thu, 5 Apr 2001 13:05:29 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 3A6EB5DF02; Thu,  5 Apr 2001 13:03:12 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 26E435DEE2; Thu,  5 Apr 2001 13:03:12 -0400 (EDT)
Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41])
	by segue.merit.edu (Postfix) with ESMTP id 273665DF02
	for <aaa-wg@merit.edu>; Thu,  5 Apr 2001 13:03:10 -0400 (EDT)
Received: from jariws1 ([212.54.18.47]) by fep01-app.kolumbus.fi
          (InterMail vM.5.01.02.00 201-253-122-103-20001017) with SMTP
          id <20010405170309.IWVR23426.fep01-app.kolumbus.fi@jariws1>;
          Thu, 5 Apr 2001 20:03:09 +0300
Message-ID: <006901c0bdf2$49f37080$8a1b6e0a@arenanet.fi>
From: "Jari Arkko" <jari.arkko@kolumbus.fi>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
References: <Roam.SIMC.2.0.6.986484637.22509.pcalhoun@nasnfs>
Subject: Re: [AAA-WG]: Apparent new goal of the interim meeting
Date: Thu, 5 Apr 2001 20:03:08 +0300
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit


> I am sufficiently concerned that the AD has stated that one of the goals of
> the interim meeting is to kill proxies. Proxies are universally used, and will
> be required in the networks that I know of. Redirect mode is not an answer to
> all problems.

Oh? I must have missed that statement. Was it on this list or
in Minneapolis? I though in Minneapolis we were discussing
whether we mandate e2e security or not, and some folks
including the AD I think stated that they do not want a protocol
that does not have e2e security. 

So, is the issue to-have-e2e-security-or-not, or is the
issue proxies-suck-even-if-e2e-security-is-in-place?

I'd be surprised if the issue was the latter one, one
would think e2e security would enable us to hide the
necessary information. If the issue is mandating e2e
security, then it's a different matter. I'd rather mandate
e2e security than forget about proxies...

Jari






From owner-aaa-bof@merit.edu  Thu Apr  5 13:17:45 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08650
	for <aaa-archive@odin.ietf.org>; Thu, 5 Apr 2001 13:17:44 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 88AE45DE88; Thu,  5 Apr 2001 11:22:59 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 7126B5DE9D; Thu,  5 Apr 2001 11:22:59 -0400 (EDT)
Received: from rip.psg.com (rip.psg.com [147.28.0.39])
	by segue.merit.edu (Postfix) with ESMTP id D87B45DE88
	for <aaa-wg@merit.edu>; Thu,  5 Apr 2001 11:22:56 -0400 (EDT)
Received: from randy by rip.psg.com with local (Exim 3.16 #1)
	id 14lBb3-000GbP-00; Thu, 05 Apr 2001 08:22:53 -0700
From: Randy Bush <randy@psg.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: "Glen Zorn" <gwz@cisco.com>
Cc: aaa-wg@merit.edu
Subject: RE: [AAA-WG]: Extensibility model and IANA considerations
References: <OJEJKOMOEAKLMOILFCPJCEMLEEAA.aboba@internaut.com>
	<NDBBIHMPILAAGDHPCIOPAEIHDGAA.gwz@cisco.com>
Message-Id: <E14lBb3-000GbP-00@rip.psg.com>
Date: Thu, 05 Apr 2001 08:22:53 -0700
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

> But now (assuming that we do not, at this time, have knowledge of every
> Diameter extension that will ever exist) we're back to updating the base
> every time a new extension needs the 'M' bit set on an otherwise optional
> AVP.

this would seem to be the multiplicative intersection of two 'features',
the base plus extensions approach, and mandatory extensions.

randy



From owner-aaa-bof@merit.edu  Thu Apr  5 13:34:31 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09108
	for <aaa-archive@odin.ietf.org>; Thu, 5 Apr 2001 13:34:30 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 41CC95DED2; Thu,  5 Apr 2001 13:30:32 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 2BA655DED1; Thu,  5 Apr 2001 13:30:32 -0400 (EDT)
Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210])
	by segue.merit.edu (Postfix) with ESMTP id 96A555DEB6
	for <aaa-wg@merit.edu>; Thu,  5 Apr 2001 13:30:30 -0400 (EDT)
Received: from JSCHNIZL-W2K.cisco.com (jschnizl-isdn1.cisco.com [171.68.12.74]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id KAA03815; Thu, 5 Apr 2001 10:30:21 -0700 (PDT)
Message-Id: <4.3.2.7.2.20010405131504.00bafa80@diablo.cisco.com>
X-Sender: jschnizl@diablo.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 05 Apr 2001 13:29:52 -0400
To: "Jari Arkko" <jari.arkko@kolumbus.fi>
From: John Schnizlein <jschnizl@cisco.com>
Subject: [AAA-WG]: e2e security and/or proxies
Cc: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
In-Reply-To: <006901c0bdf2$49f37080$8a1b6e0a@arenanet.fi>
References: <Roam.SIMC.2.0.6.986484637.22509.pcalhoun@nasnfs>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

At 01:03 PM 4/5/2001, Jari Arkko wrote:

>So, is the issue to-have-e2e-security-or-not, or is the
>issue proxies-suck-even-if-e2e-security-is-in-place?

What I took from the discussion in Minneapolis is that transport
security between AAA client and server is easily resolved.
What we call e2e is the challenge of trusting a proxy to forward
securely information that it may not be able to interpret.
Whose signature is valid for what is one of the knotty problems.
Another problem is where along a chain of proxies policy can change
the values of what attributes.

The security experts did not go quite as far as the AAA person who
offered the opinion that proxies suck [sic]. They said they have not
seen solutions to the difficult problems, and until they do they will
not agree that the IETF standardize the approach.

My view is that those who said they don't care about e2e don't intend
to trust anyone else's proxy, but would not mind if other organizations
trusted theirs. This "I'm OK; I don't know about you." trust model is 
the sort that raises a red flag with security experts.

John
(not a security expert, but learned to respect them)




From owner-aaa-bof@merit.edu  Thu Apr  5 14:15:22 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10267
	for <aaa-archive@odin.ietf.org>; Thu, 5 Apr 2001 14:15:22 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 5B2405DEB3; Thu,  5 Apr 2001 10:35:15 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 479A95DEB2; Thu,  5 Apr 2001 10:35:15 -0400 (EDT)
Received: from mailgw.local.ipunplugged.com (unknown [213.88.134.217])
	by segue.merit.edu (Postfix) with ESMTP id 57A2D5DE98
	for <aaa-wg@merit.edu>; Thu,  5 Apr 2001 10:35:13 -0400 (EDT)
Received: from fredrikj (c42.local.ipunplugged.com [192.168.4.241])
	by mailgw.local.ipunplugged.com (8.9.3/8.9.3) with SMTP id QAA03326;
	Thu, 5 Apr 2001 16:34:20 +0200
From: "Fredrik Johansson" <fredrik.johansson@ipunplugged.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>,
        "Bernard Aboba" <aboba@internaut.com>
Cc: "Mark Jones" <mjones@bridgewatersystems.com>,
        "David Spence" <DSpence@Interlinknetworks.com>, <aaa-wg@merit.edu>,
        <diameter@diameter.org>
Subject: RE: [AAA-WG]: Extensions & Framework (was: Diameter Issues found @ Connectathon)
Date: Thu, 5 Apr 2001 16:34:50 +0200
Message-ID: <MJEMJBGGCLLDLFFAHLJKGEHMCJAA.fredrik.johansson@ipunplugged.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <Roam.SIMC.2.0.6.986480588.24720.pcalhoun@nasnfs>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

>
>> >The problem here is that there is no way to distinguish between
>> capabilities
>> >as a proxy and as a non-proxy server. This would be solved if AAAF could
>> >advertise that it undertands MIP for local actions and everything for
>> >proxying.
>>
>> Correct. As you point out, capabilities negotiation is really about
>> finding the sub-set of capabilities that is usable along the path
>> from the home server to the NAS, not just on the next hop.
>
>Let's think this through carefully.
>
>If, as you state, a NAS has to know the capabilities of *all*
>proxies towards
>the home server, this will require a whole lot of messaging (a
>traceroute like
>message). This was *never* intended to be supported in Diameter.

Agree

>
>The original intent of Diameter was to know the peer's capabilities, so a
>message could be sent to it, and then it is responsible for
>finding a next hop
>for the message.
>
>btw, what we are trying to support here, is a NAS, with vendor proprietary
>extensions, going through a set of proxies that don't understand the
>extension, to a home that does. What, btw, are the chances of a
>NAS and a home
>server supporting a vendor proprietary extension, but not the
>proxies in the
>middle.
>

Why would this be so unlikely? Two companies (or one company, two sites)
using a ISP that does not support the company specific extension isn't that
unlikely. Remember an access node might as well be a FA :-)

/Fredrik

>I would argue that this is not a problem that needs to be solved.
>
>PatC




From owner-aaa-bof@merit.edu  Thu Apr  5 14:16:41 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10354
	for <aaa-archive@odin.ietf.org>; Thu, 5 Apr 2001 14:16:41 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id AEC145DE53; Thu,  5 Apr 2001 09:36:13 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 97BE15DE55; Thu,  5 Apr 2001 09:36:13 -0400 (EDT)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id 3713D5DE53
	for <aaa-wg@merit.edu>; Thu,  5 Apr 2001 09:36:12 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA28447;
	Thu, 5 Apr 2001 06:35:58 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA17014;
	Thu, 5 Apr 2001 06:35:37 -0700 (PDT)
Received: from darius (darius [10.6.84.105])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id GAA08377;
	Thu, 5 Apr 2001 06:35:18 -0700 (PDT)
Date: Thu, 5 Apr 2001 06:35:16 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
To: Bernard Aboba <aboba@internaut.com>
Cc: Fredrik Johansson <fredrik.johansson@ipunplugged.com>,
        Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>,
        Tony Johansson <tony.johansson@ericsson.com>,
        AAA Listan <aaa-wg@merit.edu>, Martin.Julien@ece.ericsson.se
In-Reply-To: "Your message with ID" <OJEJKOMOEAKLMOILFCPJOEFMEFAA.aboba@internaut.com>
Message-ID: <Roam.SIMC.2.0.6.986477716.24950.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

ok, I agree that the problem introduced by Tony needs to be fixed, but I
needed clarification on what we could/couldn't put it from now on. I will make
the necessary text changes to the -02 candidate.

PatC
> >
> >However, this is new functionality, and we did agree to NOT include new
> >functionality, but only fix bugs. So, is this a bug, or a new
> >functionality?
> >
> 
> We are not accepting MAJOR new capabilities at this point,
> such as data modeling, e2e security, etc.
> 
> It is also accurate to say that a good case needs to be made
> for addition of new features. We want to prevent creeping
> featurism -- if anything, we probably need to cut more features
> than we add. 
> 
> However, if a good technical case can be made for a change, and
> in particular, if an argument can be made that the change enables
> the protocol to better satisfy the requirements -- then we should
> make that change. 
> 
> Not only will this get us a better protocol -- but it will also
> satisfy the requirement that a Proposed Standard represent consensus
> of the AAA WG. 
> 
> So let's keep the bar high -- but not so high that noone can jump
> over it. 





From owner-aaa-bof@merit.edu  Thu Apr  5 14:19:00 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10440
	for <aaa-archive@odin.ietf.org>; Thu, 5 Apr 2001 14:19:00 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id BAA705DF1A; Thu,  5 Apr 2001 14:02:55 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id A86E85DF17; Thu,  5 Apr 2001 14:02:55 -0400 (EDT)
Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44])
	by segue.merit.edu (Postfix) with ESMTP id A54C75DF0E
	for <aaa-wg@merit.edu>; Thu,  5 Apr 2001 14:02:53 -0400 (EDT)
Received: from jariws1 ([212.54.18.47]) by fep02-app.kolumbus.fi
          (InterMail vM.5.01.02.00 201-253-122-103-20001017) with SMTP
          id <20010405180252.WXHB16926.fep02-app.kolumbus.fi@jariws1>;
          Thu, 5 Apr 2001 21:02:52 +0300
Message-ID: <009301c0bdfa$a1da8420$8a1b6e0a@arenanet.fi>
From: "Jari Arkko" <jari.arkko@kolumbus.fi>
To: "John Schnizlein" <jschnizl@cisco.com>
Cc: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
References: <Roam.SIMC.2.0.6.986484637.22509.pcalhoun@nasnfs> <4.3.2.7.2.20010405131504.00bafa80@diablo.cisco.com>
Subject: [AAA-WG]: Re: e2e security and/or proxies
Date: Thu, 5 Apr 2001 21:02:51 +0300
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit


John Schnizlein writes:

> Another problem is where along a chain of proxies policy can change
> the values of what attributes.

Yes, but doesn't draft-calhoun-diameter-strong-crypto-07.txt
solve these issues?

> Whose signature is valid for what is one of the knotty problems.

Do you have a specific concern in mind wrt the above spec?

Note that even if we are talking about global roaming networks etc
we still are within a constrained set of servers belonging to a PKI.
[It's not like the case with mobile IP security problem, with all nodes
of the whole internet having to be members of the same PKI.]

Jari






From owner-aaa-bof@merit.edu  Thu Apr  5 14:45:14 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10946
	for <aaa-archive@odin.ietf.org>; Thu, 5 Apr 2001 14:45:13 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 60A515DEA6; Thu,  5 Apr 2001 14:10:25 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 4DDC95DE9D; Thu,  5 Apr 2001 14:10:25 -0400 (EDT)
Received: from df-inet1.exchange.microsoft.com (df-inet1.exchange.microsoft.com [131.107.8.8])
	by segue.merit.edu (Postfix) with ESMTP id BE3175DD97
	for <Aaa-Wg@merit.edu>; Thu,  5 Apr 2001 14:10:23 -0400 (EDT)
Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by df-inet1.exchange.microsoft.com with Microsoft SMTPSVC(5.0.2195.2831);
	 Thu, 5 Apr 2001 11:11:09 -0700
Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Thu, 05 Apr 2001 10:11:28 -0700 (Pacific Daylight Time)
Received: from speak.platinum.corp.microsoft.com ([172.30.236.197]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2905);
	 Thu, 5 Apr 2001 11:11:28 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.0.4683.0
content-class: urn:content-classes:message
Subject: RE: [AAA-WG]: AAA WG Interim meeting dates
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Date: Thu, 5 Apr 2001 11:11:26 -0700
Message-ID: <CC2E64D4B3BAB646A87B5A3AE97090420FFD3387@speak.dogfood>
Thread-Topic: [AAA-WG]: AAA WG Interim meeting dates
Thread-Index: AcC9iZhiQ+jxN1OzTtC7JG0f3XtMeQAccMYw
From: "Christian Huitema" <huitema@exchange.microsoft.com>
To: "Bernard Aboba" <aboba@internaut.com>
Cc: <Aaa-Wg@merit.edu>
X-OriginalArrivalTime: 05 Apr 2001 18:11:28.0156 (UTC) FILETIME=[D56DD5C0:01C0BDFB]
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA10946

I have a somewhat fundamental issue with the Diameter. Why is the IETF
trying to invent yet another marshalling protocol, instead of using
existing technologies such as XML or ASN.1? Radius made some sense,
because it was very well scoped and very limited in complexity. The
Diameter specification is much more ambitious than Radius; it attempts
to define a fully capable marshalling protocol, using the RFC process
and the IANA as a substitute for an interface definition language. If I
am developing a specific application protocol, why should I base it on
Diameter rather than ASN.1 or XML?

The answer to that specific issue will probably be given by the market.
If the application developers are not convinced by Diameter, they will
probably simply use something else. In any case, there are quite a few
detailed problems in the specification.

1) Mandatory use of SLP or SLPv2 for "Diameter service discovery"

This creates a dependency on SLP for very little benefit, and possibly
some harmful consequences. Diameter is primarily meant to be used for
AAA applications; these applications require some tight control; in
practice, that control requires some form of explicit parametrization of
the device. The DNS SRV mechanism already provides a layer of
indirection between the name of the server and its actual
implementation; there is no need for an additional mechanism. In any
case, the decision to use a local discovery mechanism rather than a
configuration mechanism belongs in the application documents, not in the
base spec.

2) AVP header format

As specified, it seems impossible to encode an attribute in less than 96
bits. This is way less efficient than Radius. This seems particularly
ill-suited to mobile applications, in which bandwidth is at a premium.
Having a 64 header per attribute means that in most practical
applications there will not be any advantage to using the binary format
of Diameter compared to more modern technologies such as XML; there will
also be no particular advantage compared to classic technologies such as
ASN.1/BER. If that is the case, why bother with Diameter at all?

Why do we believe that we need 32 bits to encode attribute types? It is
certainly possible to encode the combination of length, flags and
attribute type in a single 32 bit word, at least in the common case of
attribute length lower than 255. A format like the following would
feature the same amount of information in half the space, still allowing
for more attribute types than the IANA can possibly handle; if the
length is larger than 254, the AVP length is set to 255 and an optional
length field is added. Four bits are reserved for type indication,
discussed later.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           AVP Code            |P|V|M|r|t t t t|  AVP Length   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                 Extended length (optional)                    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        Vendor-ID (opt)                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Data ...
      +-+-+-+-+-+-+-+-+



3) AVP Data Formats

In the spec, the data format is determined by the value of the AVP code.
This has an operational consequence: it becomes impossible to write a
monitoring utility or a logging utility without having a complete
dictionary. I suggest sticking a 4 bit "data type" field as a complement
to the AVP code

      1 - OctetString
      2 - Address
      3 - Integer32
      4 - Integer64
      5 - Unsigned32
      6 - Unsigned64
      7 - Float32
      8 - Float64
      9 - Float128
     10 - Grouped

By the way, it would probably be very practical to defined a "boolean"
type, of code zero, to encode a basic protocol flag.

4) Grouped attributes

In the case of the "grouped" attribute, we have a real problem of type
definition. Shall we require that all AVP codes in the group are present
in the dictionary, or can they be simply defined in the context of the
group? The latter does provide for much more flexibility, and is in line
with the practice of ASN.1 or XML.

Both ASN.1 and XML Schema Language provide way to define the structure
of grouping: order list, unordered set, array of elements. How do we do
this in Diameter?

Adding two categories for "XML text" and "ASN.1 BER" would actually make
a lot of sense.

5) Device-Reboot-Ind (DRI) Command

Having a mandatory Vendor-ID in the command creates a barrier to entry
for implementors: it requires that they first register with the IANA.
This should be optional. There is no reason to mandate the presence of a
vendor-id if no vendor extensions are used, a case which we hope should
be quite common.

6)  Extension-Id AVP in DRI command

The presence of an extension-id AVP is symptomatic of an unsolved
dilemma in the Diameter sprecification. Is Diameter a protocol framework
or a service specification? If it is a protocol framework, then the
extension is in fact the service; which server to use and which port
number to connect to will be determined by this service; negotiating the
extension at this point does not make any sense.

7) Host-IP-Address AVP in DRI command

What does that do in the presence of a NAT?

8) and many more issues, but we will need more time...

-- Christian Huitema




From owner-aaa-bof@merit.edu  Thu Apr  5 15:03:27 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11277
	for <aaa-archive@odin.ietf.org>; Thu, 5 Apr 2001 15:03:26 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 9D05C5DD97; Thu,  5 Apr 2001 15:00:18 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 86F255DE69; Thu,  5 Apr 2001 15:00:18 -0400 (EDT)
Received: from newman.frascone.com (frascone.com [216.62.83.25])
	by segue.merit.edu (Postfix) with SMTP id 3253C5DD97
	for <Aaa-Wg@Merit.Edu>; Thu,  5 Apr 2001 15:00:13 -0400 (EDT)
Received: (qmail 22446 invoked by uid 500); 5 Apr 2001 19:00:12 -0000
Date: Thu, 5 Apr 2001 14:00:11 -0500
From: David Frascone <dave@frascone.com>
To: Christian Huitema <huitema@exchange.microsoft.com>
Cc: Aaa-Wg@merit.edu
Subject: Re: [AAA-WG]: AAA WG Interim meeting dates
Message-ID: <20010405140011.N24201@newman.frascone.com>
Mail-Followup-To: Christian Huitema <huitema@exchange.microsoft.com>,
	Aaa-Wg@Merit.Edu
References: <CC2E64D4B3BAB646A87B5A3AE97090420FFD3387@speak.dogfood>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <CC2E64D4B3BAB646A87B5A3AE97090420FFD3387@speak.dogfood>; from huitema@exchange.microsoft.com on Thu, Apr 05, 2001 at 11:11:26AM -0700
X-encrypt-payload: no
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

On Thu, Apr 05, 2001 at 11:11:26AM -0700, Christian Huitema wrote:
> I have a somewhat fundamental issue with the Diameter. Why is the IETF
> trying to invent yet another marshalling protocol, instead of using
> existing technologies such as XML or ASN.1? Radius made some sense,
> because it was very well scoped and very limited in complexity. The
> Diameter specification is much more ambitious than Radius; it attempts
> to define a fully capable marshalling protocol, using the RFC process
> and the IANA as a substitute for an interface definition language. If I
> am developing a specific application protocol, why should I base it on
> Diameter rather than ASN.1 or XML?
> 
> The answer to that specific issue will probably be given by the market.
> If the application developers are not convinced by Diameter, they will
> probably simply use something else. In any case, there are quite a few
> detailed problems in the specification.
> 
> 1) Mandatory use of SLP or SLPv2 for "Diameter service discovery"
> 
> This creates a dependency on SLP for very little benefit, and possibly
> some harmful consequences. Diameter is primarily meant to be used for
> AAA applications; these applications require some tight control; in
> practice, that control requires some form of explicit parametrization of
> the device. The DNS SRV mechanism already provides a layer of
> indirection between the name of the server and its actual
> implementation; there is no need for an additional mechanism. In any
> case, the decision to use a local discovery mechanism rather than a
> configuration mechanism belongs in the application documents, not in the
> base spec.

I read the mandate as:  If discovery is necessary.  And, in a mobile
environment, there needs to be some way for the mobile to find an AAA server,
right?  

> 2) AVP header format
> 
> As specified, it seems impossible to encode an attribute in less than 96
> bits. This is way less efficient than Radius. This seems particularly
> ill-suited to mobile applications, in which bandwidth is at a premium.
> Having a 64 header per attribute means that in most practical
> applications there will not be any advantage to using the binary format
> of Diameter compared to more modern technologies such as XML; there will
> also be no particular advantage compared to classic technologies such as
> ASN.1/BER. If that is the case, why bother with Diameter at all?
> 
> Why do we believe that we need 32 bits to encode attribute types? It is
> certainly possible to encode the combination of length, flags and
> attribute type in a single 32 bit word, at least in the common case of
> attribute length lower than 255. A format like the following would
> feature the same amount of information in half the space, still allowing
> for more attribute types than the IANA can possibly handle; if the
> length is larger than 254, the AVP length is set to 255 and an optional
> length field is added. Four bits are reserved for type indication,
> discussed later.
> 
>        0                   1                   2                   3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |           AVP Code            |P|V|M|r|t t t t|  AVP Length   |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                 Extended length (optional)                    |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                        Vendor-ID (opt)                        |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |    Data ...
>       +-+-+-+-+-+-+-+-+

I have no fundamental problem with your new AVP header.  In fact, I like it.
(I'd make one small change, though, and instead of using 255 in the length
field, I'd grab one of those unused bits to signal that the extended length
was being used.)

My complaint, however, is your timing.  It seems that every time the protocol
goes into last call, someone stops lurking and wants to make a serious
fundamental change.  

Many working groups/standards bodies are waiting for the IETF AAA protocol.
This really should have been brought up some time ago.

> 3) AVP Data Formats
> 
> In the spec, the data format is determined by the value of the AVP code.
> This has an operational consequence: it becomes impossible to write a
> monitoring utility or a logging utility without having a complete
> dictionary. I suggest sticking a 4 bit "data type" field as a complement
> to the AVP code
> 
>       1 - OctetString
>       2 - Address
>       3 - Integer32
>       4 - Integer64
>       5 - Unsigned32
>       6 - Unsigned64
>       7 - Float32
>       8 - Float64
>       9 - Float128
>      10 - Grouped
> 
> By the way, it would probably be very practical to defined a "boolean"
> type, of code zero, to encode a basic protocol flag.

Since you can't interoperate with other implementations without a dictionary,
I see no need to send data definition "on the wire".

> 5) Device-Reboot-Ind (DRI) Command
> 
> Having a mandatory Vendor-ID in the command creates a barrier to entry
> for implementors: it requires that they first register with the IANA.
> This should be optional. There is no reason to mandate the presence of a
> vendor-id if no vendor extensions are used, a case which we hope should
> be quite common.

I agree with this comment.  I to prefer a vendor string over an IANA number.

I'm assuming it's easy for a company to get a vendor id, but what about 
someone testing a concept:  "Umm, can I get a "Dave's new Toy vendor id" ?


> 6)  Extension-Id AVP in DRI command
> 
> The presence of an extension-id AVP is symptomatic of an unsolved
> dilemma in the Diameter sprecification. Is Diameter a protocol framework
> or a service specification? If it is a protocol framework, then the
> extension is in fact the service; which server to use and which port
> number to connect to will be determined by this service; negotiating the
> extension at this point does not make any sense.

Sure it does.  Suppose you're trying to find a server to handle Mobile-Ip
authentication.  When you do your server discovery, there are 5 diameter servers
available, but only one handle Mobile-IP AAA.  By looking at the extensions, 
you'd know which one to use.

> 7) Host-IP-Address AVP in DRI command
> 
> What does that do in the presence of a NAT?

I'm sure, in the presence of NAT, that the Host-IP-Address would be the 
last routable proxy.  I don't think ANY protocol can be 100% NAT friendly.




From owner-aaa-bof@merit.edu  Thu Apr  5 16:00:25 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13011
	for <aaa-archive@odin.ietf.org>; Thu, 5 Apr 2001 16:00:25 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id C50D75DED1; Thu,  5 Apr 2001 15:04:17 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id B08365DECC; Thu,  5 Apr 2001 15:04:17 -0400 (EDT)
Received: from zcars04e.nortelnetworks.com (zcars04e.nortelnetworks.com [47.129.242.56])
	by segue.merit.edu (Postfix) with ESMTP id 6A4F55DE9D
	for <aaa-wg@merit.edu>; Thu,  5 Apr 2001 15:04:16 -0400 (EDT)
Received: from zbl6c012.corpeast.baynetworks.com by zcars04e.nortelnetworks.com;
          Thu, 5 Apr 2001 15:03:55 -0400
Received: from zbl6c008.corpeast.baynetworks.com ([132.245.205.58]) 
          by zbl6c012.corpeast.baynetworks.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) 
          id H9V0A17A; Thu, 5 Apr 2001 15:03:53 -0400
Received: from mitton.nortelnetworks.com (47.16.86.121 [47.16.86.121]) 
          by zbl6c008.corpeast.baynetworks.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) 
          id G0CX4BVR; Thu, 5 Apr 2001 15:03:53 -0400
Message-Id: <4.3.2.7.2.20010405150036.00c952d0@ZBL6C008.corpeast.baynetworks.com>
X-Sender: dmitton@ZBL6C008.corpeast.baynetworks.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 05 Apr 2001 15:05:27 -0400
To: Randy Bush <randy@psg.com>, John Schnizlein <jschnizl@cisco.com>
From: "David Mitton" <dmitton@nortelnetworks.com>
Subject: Re: [AAA-WG]: Apparent new goal of the interim meeting
Cc: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>, aaa-wg@merit.edu,
        aboba@internaut.com
In-Reply-To: <E14lCkA-000HDe-00@rip.psg.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Orig: <dmitton@nortelnetworks.com>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

At 4/5/01 12:36 PM -0400, Randy Bush wrote:
><snip>...


 > John Schnizlein wrote:
> > Without claiming any particular expertise in the area, let me suggest
> > that arbitrary chains of proxies are really not necessary. If there
> > were only two domains - one proxy hop - with everything else done
> > through redirects, we might be able to find a solution that the
> > security area would find acceptable. Is this possible?
>
>don't make me too hopeful.
>
>randy

I'm afraid I don't agree with you that arbitrary chains of proxies can be 
removed.  I don't think a lot of people in this WG do either.
I hesitate to call for feedback on this subject... but if we have to...

We do have to find a solution, even if some people are willing to live 
without it for practical reasons for awhile.  Otherwise I don't think we've 
really done anything with this protocol that isn't being done with RADIUS 
(with less overhead) today.

BTW: many people are running arbitrary chains of proxies with RADIUS.  Time 
for you to speak up.

         Dave.
---------------------------------------------------------------
David Mitton                                  ESN: 248-4570
Advisor, Nortel Networks                      978-288-4570 Direct
Wireless Solutions, IP Mobility
Billerica, MA 01821                    dmitton@nortelnetworks.com




From owner-aaa-bof@merit.edu  Thu Apr  5 18:07:42 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA15707
	for <aaa-archive@odin.ietf.org>; Thu, 5 Apr 2001 18:07:42 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 6811D5DDFC; Thu,  5 Apr 2001 18:04:04 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 55EAC5DDF3; Thu,  5 Apr 2001 18:04:04 -0400 (EDT)
Received: from ws2.piuha.net (ws2.piuha.net [195.165.196.2])
	by segue.merit.edu (Postfix) with ESMTP id 91CEB5DEC8
	for <Aaa-Wg@Merit.Edu>; Thu,  5 Apr 2001 18:04:02 -0400 (EDT)
Received: from kolumbus.fi (ws4.piuha.net [195.165.196.4])
	by ws2.piuha.net (Postfix) with ESMTP
	id A09A76A902; Fri,  6 Apr 2001 01:03:49 +0300 (EEST)
Message-ID: <3ACCEC5C.5030304@kolumbus.fi>
Date: Fri, 06 Apr 2001 01:06:20 +0300
From: Jari Arkko <jari.arkko@kolumbus.fi>
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.17-icclin i686; en-US; m18) Gecko/20001107 Netscape6/6.0
X-Accept-Language: en
MIME-Version: 1.0
To: Christian Huitema <huitema@exchange.microsoft.com>
Cc: Aaa-Wg@merit.edu
Subject: Re: [AAA-WG]: AAA WG Interim meeting dates
References: <CC2E64D4B3BAB646A87B5A3AE97090420FFD3387@speak.dogfood> <20010405140011.N24201@newman.frascone.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit


Without discussing your more general input, I'll just
jump into one detail:


>ill-suited to mobile applications, in which bandwidth is at a premium.
>Having a 64 header per attribute means that in most practical

It may be useful to note here that Diameter is being considered
for parts of the wireless _infrastructure_. That is, from (say)
base station to a home AAA server. There is plenty of bandwidth
available within that network even if it's quite different over
the actual wireless link. Usually, it's not the wireless phones
that are doing the accounting themselves, it's the network! In
conclusion I don't think this is an issue.

Jari




From owner-aaa-bof@merit.edu  Thu Apr  5 18:43:14 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA16073
	for <aaa-archive@odin.ietf.org>; Thu, 5 Apr 2001 18:43:14 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 4AA1D5DEDD; Thu,  5 Apr 2001 18:41:10 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 34ECB5DED9; Thu,  5 Apr 2001 18:41:10 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id DEEA45DEC2
	for <aaa-wg@merit.edu>; Thu,  5 Apr 2001 18:40:45 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA00362;
	Thu, 5 Apr 2001 15:40:40 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA14494;
	Thu, 5 Apr 2001 15:40:39 -0700 (PDT)
Received: from darius (darius [10.6.84.105])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id PAA16666;
	Thu, 5 Apr 2001 15:40:36 -0700 (PDT)
Date: Thu, 5 Apr 2001 15:40:34 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Subject: [AAA-WG]: Re: e2e security and/or proxies
To: John Schnizlein <jschnizl@cisco.com>
Cc: Jari Arkko <jari.arkko@kolumbus.fi>,
        Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>, aaa-wg@merit.edu
In-Reply-To: "Your message with ID" <4.3.2.7.2.20010405131504.00bafa80@diablo.cisco.com>
Message-ID: <Roam.SIMC.2.0.6.986510434.30319.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

All,

It appears I misinterpreted the AD's original comment, and his comment was not
to kill proxies, but make sure that they are secure.

I appologize for causing any confusion,

PatC




From owner-aaa-bof@merit.edu  Thu Apr  5 21:27:39 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA17515
	for <aaa-archive@odin.ietf.org>; Thu, 5 Apr 2001 21:27:38 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 026815DF32; Thu,  5 Apr 2001 21:26:11 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id E4C5E5DF31; Thu,  5 Apr 2001 21:26:10 -0400 (EDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by segue.merit.edu (Postfix) with ESMTP id 6836C5DE9D
	for <aaa-wg@merit.edu>; Thu,  5 Apr 2001 21:26:09 -0400 (EDT)
Received: from mira-sjc5-1.cisco.com (mira-sjc5-1.cisco.com [171.71.163.15])
	by sj-msg-core-3.cisco.com (8.9.3/8.9.1) with ESMTP id SAA18826;
	Thu, 5 Apr 2001 18:24:50 -0700 (PDT)
Received: from jtrostle-nt2 (jtrostle-dsl3.cisco.com [10.19.59.100])
	by mira-sjc5-1.cisco.com (Mirapoint)
	with SMTP id ABH11672;
	Thu, 5 Apr 2001 18:26:06 -0700 (PDT)
Message-Id: <4.1.20010405172804.015e55d0@mira-sjc5-1>
X-Sender: jtrostle@mira-sjc5-1
X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 
Date: Thu, 05 Apr 2001 17:29:58 -0700
To: "Bernard Aboba" <aboba@internaut.com>,
        "Aaa-Wg@Merit. Edu" <aaa-wg@merit.edu>
From: Jonathan Trostle <jtrostle@cisco.com>
Subject: RE: [AAA-WG]: AAA WG Interim meeting dates
In-Reply-To: <OJEJKOMOEAKLMOILFCPJKEEDEFAA.aboba@internaut.com>
References: <Roam.SIMC.2.0.6.986400927.15755.pcalhoun@nasnfs>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

I can probably make this date (or at least part of the meeting on these dates).

Jonathan

At 10:46 AM 4/4/01 -0700, Bernard Aboba wrote:
>>Weekend meetings are out for me (sorry, but I travel too much, and weekends
>I
>>want to be home). The very fact that we lingered for so long is quite
>>upsetting. People claimed they could do May 3rd, and that was WELL within
>the
>>window when people sent those e-mails. Week of May 14th will work for me
>too,
>>but let's get this thing setup so we don't have to move it out further.
>
>There were quite a few people who could not make the earlier date (including
>our AD), so it wasn't just a matter of letting it slip.
>
>At this point, I would propose May 14-15, San Francisco Bay Area. This is
>a Monday & Tuesday (avoids weekends).
>
>What do people think?
>
>
>
>
>




From owner-aaa-bof@merit.edu  Fri Apr  6 01:34:22 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA24911
	for <aaa-archive@odin.ietf.org>; Fri, 6 Apr 2001 01:34:22 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 05A985DEDC; Fri,  6 Apr 2001 01:33:33 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id E71075DED7; Fri,  6 Apr 2001 01:33:32 -0400 (EDT)
Received: from cisco.com (titans.cisco.com [161.44.216.10])
	by segue.merit.edu (Postfix) with ESMTP id A76E65DD90
	for <aaa-wg@merit.edu>; Fri,  6 Apr 2001 01:33:30 -0400 (EDT)
Received: from knox6039 (knox6039.cisco.com [161.44.216.39])
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id BAA10795;
	Fri, 6 Apr 2001 01:28:39 -0400 (EDT)
Date: Fri, 6 Apr 2001 01:28:58 -0400 (EDT)
From: Mark Eklund <meklund@cisco.com>
X-Sender: meklund@knox6039
To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Cc: Bernard Aboba <aboba@internaut.com>,
        Fredrik Johansson <fredrik.johansson@ipunplugged.com>,
        Mark Jones <mjones@bridgewatersystems.com>,
        David Spence <DSpence@Interlinknetworks.com>, aaa-wg@merit.edu,
        diameter@diameter.org
Subject: Re: [AAA-WG]: New Extension text in base protocol
In-Reply-To: <Roam.SIMC.2.0.6.986480070.19160.pcalhoun@nasnfs>
Message-ID: <Pine.GSO.4.05.10104060033570.22022-100000@knox6039>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Pat,

With the your new Diameter Extensions statements about the
mandatory avp, does the following still hold true in section 4.1
of draft-ietf-aaa-diameter-01.txt.

      Unless otherwise noted, AVPs will have the following default AVP
      Flags field settings:
         The 'M' bit MUST be set. The 'V' bit MUST NOT be set.

Also, is the following interpretation correct? Since
Service-Type and Idle-Timeount are not listed in the ABNF of
AA-Answer in draft-ietf-aaa-diameter-nasreq-01.txt, it would be
a violation of the protocol to advertise support of NASREQ and
set the mandatory bit in the above attributes in an AA-Answer.

-mark

On Thu, 5 Apr 2001, Patrice Calhoun wrote:

> All,
> 
> Below is the proposed text that I have added to the -02 candidate that
> describes what a Diameter extension is.
> 
> Please send any comments,
> 
> PatC
> ----
> 
> 
> 2.3  Diameter Extensions
> 
>    As previously mentioned, the Diameter base protocol does not operate
>    on its own, but requires appplication-specific extensions, commonly
>    referred to as Diameter extensions. A Diameter extension is a
>    specification that defines one or more Diameter Command-Codes, the
>    expected AVPs in an ABNF [31] grammar (see section 3.2), and MAY also
>    define new AVPs.
> 
>    Every Diameter Extension specification MUST have an IANA assigned
>    Extension-Id value (see section 6.1.3). This Extension-Id is
>    advertised during the capabilities exchange phase (see section 6.0).
>    Advertising support of a particular extension implies that the
>    receiver support all of the Command Codes, and the AVPs specified in
>    the associated ABNF, described in the specification.
> 
>    An implementation MAY add arbitrary AVPs to any command defined in an
>    extension, including vendor-specific AVPs. However, such AVPs MUST
>    NOT have the M(andatory) bit set. An implementation that adds AVPs
>    not specified in a command's ABNF, and sets the AVP's M(andatory) bit
>    MUST NOT advertise support of the extension.
> 
>    An implementation MAY support both a proprietary version of an
>    extension by requesting an IANA extension identifier (see section
>    17.3), while supporting the original extension. During the
>    capabilities exchange, a Diameter node could know whether it should
>    send the prorietary version, or the standards one, by inspecting the
>    extensions advertised by the peer.
> 
> 





From owner-aaa-bof@merit.edu  Fri Apr  6 02:49:14 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA05616
	for <aaa-archive@odin.ietf.org>; Fri, 6 Apr 2001 02:49:13 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 689115DDA0; Fri,  6 Apr 2001 02:47:31 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 465965DDFB; Fri,  6 Apr 2001 02:47:31 -0400 (EDT)
Received: from gate.internaut.com (unknown [64.38.134.101])
	by segue.merit.edu (Postfix) with ESMTP id 48C8E5DDA0
	for <aaa-wg@merit.edu>; Fri,  6 Apr 2001 02:47:29 -0400 (EDT)
Received: from e1kj2 (e1kj2 [64.38.134.109])
	by gate.internaut.com (8.10.2/8.10.2) with SMTP id f366auN10366;
	Thu, 5 Apr 2001 23:36:57 -0700
From: "Bernard Aboba" <aboba@internaut.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>,
        "Fredrik Johansson" <fredrik.johansson@ipunplugged.com>
Cc: "Mark Jones" <mjones@bridgewatersystems.com>,
        "David Spence" <DSpence@Interlinknetworks.com>, <aaa-wg@merit.edu>,
        <diameter@diameter.org>
Subject: RE: [AAA-WG]: Extensions & Framework (was: Diameter Issues found @ Connectathon)
Date: Thu, 5 Apr 2001 23:48:39 -0700
Message-ID: <OJEJKOMOEAKLMOILFCPJGEGNEFAA.aboba@internaut.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <Roam.SIMC.2.0.6.986481981.14062.pcalhoun@nasnfs>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

>If that's the case, then I would expect the AAA server to ALSO support the
>proprietary extension, right?

Remember, the proxy may be serving a large number of servers, all with 
different capabilities. I think that there may be some optimizations
that can be made for this case.

Let's say that dmitton@nortelnetworks.com has a dialup account with
a roaming association that handles many types of Internet access,
including Mobile IP, dialup, etc. However, Nortel's DIAMETER server
does not support the Mobile IP extension. 

Dave will connect to the FA which will talk to a proxy that is 
capable of doing anything, and therefore will advertise wildcard
capabilities. However, the request when proxied to Nortel will
result in an error because the required capabilities are not present.

One would hope that this same result would not be repeated on 
every attempt, but rather that the capabilities of the Nortel
server would be cached by the proxy for some TTL. Therefore on
the next attempt, the proxy would NOT advertise wildcard capabilites
for a request to a destination realm whose capabilities it has cached.
Instead, it will advertise the capabilities appropriate to that
particular destination realm. 

Does this make sense?

 



From owner-aaa-bof@merit.edu  Fri Apr  6 03:04:59 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA05763
	for <aaa-archive@odin.ietf.org>; Fri, 6 Apr 2001 03:04:58 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id C06325DE69; Fri,  6 Apr 2001 03:01:59 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id AF8D45DE1D; Fri,  6 Apr 2001 03:01:59 -0400 (EDT)
Received: from gate.internaut.com (unknown [64.38.134.101])
	by segue.merit.edu (Postfix) with ESMTP id 41A2F5DD99
	for <aaa-wg@merit.edu>; Fri,  6 Apr 2001 03:01:57 -0400 (EDT)
Received: from e1kj2 (e1kj2 [64.38.134.109])
	by gate.internaut.com (8.10.2/8.10.2) with SMTP id f366pZN11110;
	Thu, 5 Apr 2001 23:51:35 -0700
From: "Bernard Aboba" <aboba@internaut.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Subject: RE: [AAA-WG]: Apparent new goal of the interim meeting
Date: Fri, 6 Apr 2001 00:03:17 -0700
Message-ID: <OJEJKOMOEAKLMOILFCPJCEGOEFAA.aboba@internaut.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <Roam.SIMC.2.0.6.986484637.22509.pcalhoun@nasnfs>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

A few thoughts:

1. There are many networks that don't use any proxies at all. DIAMETER
supports those networks. So if the thought of a proxy makes you ill,
relax, DIAMETER does not force you to use them.

2. If your NAS needs some assistance in routing, then DIAMETER also has
something for you too. It's called re-direct.

3. If you are one of those that feels that you need a full-bodied,
policy enforcin', packet manglin' proxy, then guess what -- DIAMETER
supports that too.  In fact, it's got a strong crypto-extension so
powerful that it's barely indistiguishable from magic ;)

So my thought for the day is that we should document the above
(probably in the proxy draft), describe the choices and pros and
cons that are available, and leave it at that. With DIAMETER you've
got the tools necessary to design just about any AAA system you
could want. Of course, you can use that to shoot yourself in the
head, but hey, that's what powerful tools are for, right?

>the AD has stated that one of the goals of the interim meeting is to kill
proxies.

I am sad to say that I think we will have AAA proxies long after we've
all turned to dust. So I think it's a case of "you can't live with 'em,
you can't live without 'em."

I'd suggest that we all get over our profound disappointment at the
inelegance, kludginess and overall orneryness of proxies, and just
accept that they are necessary in some circumstances.



-----Original Message-----
From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf
Of Patrice Calhoun
Sent: Thursday, April 05, 2001 8:31 AM
To: aaa-wg@merit.edu
Subject: [AAA-WG]: Apparent new goal of the interim meeting


All,

I am sufficiently concerned that the AD has stated that one of the goals of
the interim meeting is to kill proxies. Proxies are universally used, and
will
be required in the networks that I know of. Redirect mode is not an answer
to
all problems.

I am really concerned with the obvious delays that would occur by killing
this
feature, not to mention the lack of interest the market would have on a
protocol that doesn't meet its demands. Remember that the AAA WG had proxies
has a MUST in many access technologies, and the protocol meets the
requirements.

Is there actual WG concensus to killing proxies? Can the IESG decide that
the
market is wrong, and the IETF will not support it?

PatC






From owner-aaa-bof@merit.edu  Fri Apr  6 03:15:55 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA05845
	for <aaa-archive@odin.ietf.org>; Fri, 6 Apr 2001 03:15:55 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 13B165DDFB; Fri,  6 Apr 2001 02:47:44 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id CFACB5DEC8; Fri,  6 Apr 2001 02:47:43 -0400 (EDT)
Received: from gate.internaut.com (unknown [64.38.134.101])
	by segue.merit.edu (Postfix) with ESMTP id 8AAE35DE9D
	for <aaa-wg@merit.edu>; Fri,  6 Apr 2001 02:47:35 -0400 (EDT)
Received: from e1kj2 (e1kj2 [64.38.134.109])
	by gate.internaut.com (8.10.2/8.10.2) with SMTP id f366b3N10370;
	Thu, 5 Apr 2001 23:37:04 -0700
From: "Bernard Aboba" <aboba@internaut.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>
Cc: "Fredrik Johansson" <fredrik.johansson@ipunplugged.com>,
        "Mark Jones" <mjones@bridgewatersystems.com>,
        "David Spence" <DSpence@Interlinknetworks.com>, <aaa-wg@merit.edu>,
        <diameter@diameter.org>
Subject: RE: [AAA-WG]: Extensions & Framework (was: Diameter Issues found @ Connectathon)
Date: Thu, 5 Apr 2001 23:48:46 -0700
Message-ID: <OJEJKOMOEAKLMOILFCPJIEGNEFAA.aboba@internaut.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <Roam.SIMC.2.0.6.986480588.24720.pcalhoun@nasnfs>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

>If, as you state, a NAS has to know the capabilities of *all* proxies
towards
>the home server, this will require a whole lot of messaging (a traceroute
like
>message). This was *never* intended to be supported in Diameter.

Agreed that the NAS is not the place to handle this. The DIAMETER model is
essentially one where the NAS acts as a "stub resolver" in many respects,
offloading more sophisticated issues of destination resolution, capabilities
caching, etc. to the proxy.

>btw, what we are trying to support here, is a NAS, with vendor proprietary
>extensions, going through a set of proxies that don't understand the
>extension, to a home that does.

Yes, this is a good model -- the proxy should not have to understand the
extension to respond appropriately, and I suspect that proxies that
display any sophistication in this regard will mostly do so to implement
policy (e.g. I'm a broker whose billing system can't handle Mobile IP yet).
However, doing realm-based capabilities caching doesn't require that
kind of knowledge on the proxy.

>What, btw, are the chances of a NAS and a home server supporting a
>vendor proprietary extension, but not the proxies in the
>middle.

Pretty high, I would think -- though I would argue that we should assume
that proxies do not have to understand extensions to do their job so
that it wouldn't matter. The reason that a proxy would announce non-wildcard
capabilities would most likely have to do with policy -- not implementation
of extensions, since in practice, a proxy shouldn't need to have any
additional
code to implement extensions.




From owner-aaa-bof@merit.edu  Fri Apr  6 04:00:34 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA06161
	for <aaa-archive@odin.ietf.org>; Fri, 6 Apr 2001 04:00:33 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 402525DD99; Fri,  6 Apr 2001 03:09:18 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 237AA5DDBC; Fri,  6 Apr 2001 03:09:18 -0400 (EDT)
Received: from gate.internaut.com (unknown [64.38.134.101])
	by segue.merit.edu (Postfix) with ESMTP id C0A3E5DD99
	for <aaa-wg@merit.edu>; Fri,  6 Apr 2001 03:09:01 -0400 (EDT)
Received: from e1kj2 (e1kj2 [64.38.134.109])
	by gate.internaut.com (8.10.2/8.10.2) with SMTP id f366wXN11444;
	Thu, 5 Apr 2001 23:58:33 -0700
From: "Bernard Aboba" <aboba@internaut.com>
To: "Jari Arkko" <jari.arkko@kolumbus.fi>,
        "John Schnizlein" <jschnizl@cisco.com>
Cc: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Subject: RE: [AAA-WG]: Re: e2e security and/or proxies
Date: Fri, 6 Apr 2001 00:10:15 -0700
Message-ID: <OJEJKOMOEAKLMOILFCPJMEGOEFAA.aboba@internaut.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <009301c0bdfa$a1da8420$8a1b6e0a@arenanet.fi>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

>> Another problem is where along a chain of proxies policy can change
>> the values of what attributes.

>Yes, but doesn't draft-calhoun-diameter-strong-crypto-07.txt
>solve these issues?

I certainly hope so.

Stephen -- any ETA for the next version of the strong crypto spec? (hint,
hint)




From owner-aaa-bof@merit.edu  Fri Apr  6 09:45:22 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA09033
	for <aaa-archive@odin.ietf.org>; Fri, 6 Apr 2001 09:45:21 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 14D555DDD4; Fri,  6 Apr 2001 08:44:06 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id E62A85DDBC; Fri,  6 Apr 2001 08:44:05 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id 675DB5DD94
	for <aaa-wg@merit.edu>; Fri,  6 Apr 2001 08:44:04 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id FAA18062;
	Fri, 6 Apr 2001 05:43:51 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id FAA19597;
	Fri, 6 Apr 2001 05:43:50 -0700 (PDT)
Received: from darius (darius [10.6.84.105])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id FAA22527;
	Fri, 6 Apr 2001 05:43:48 -0700 (PDT)
Date: Fri, 6 Apr 2001 05:43:46 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Subject: Re: [AAA-WG]: New Extension text in base protocol
To: Mark Eklund <meklund@cisco.com>
Cc: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>,
        Bernard Aboba <aboba@internaut.com>,
        Fredrik Johansson <fredrik.johansson@ipunplugged.com>,
        Mark Jones <mjones@bridgewatersystems.com>,
        David Spence <DSpence@Interlinknetworks.com>, aaa-wg@merit.edu,
        diameter@diameter.org
In-Reply-To: "Your message with ID" <Pine.GSO.4.05.10104060033570.22022-100000@knox6039>
Message-ID: <Roam.SIMC.2.0.6.986561026.25566.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> Pat,
> 
> With the your new Diameter Extensions statements about the
> mandatory avp, does the following still hold true in section 4.1
> of draft-ietf-aaa-diameter-01.txt.
> 
>       Unless otherwise noted, AVPs will have the following default AVP
>       Flags field settings:
>          The 'M' bit MUST be set. The 'V' bit MUST NOT be set.

Yes.

> 
> Also, is the following interpretation correct? Since
> Service-Type and Idle-Timeount are not listed in the ABNF of
> AA-Answer in draft-ietf-aaa-diameter-nasreq-01.txt, it would be
> a violation of the protocol to advertise support of NASREQ and
> set the mandatory bit in the above attributes in an AA-Answer.

ok, looks like I have a bit of work in that extension. The service-type and
idle-timeout SHOULD have been present. If you read the text in section 3.1.1,
it states that additional AVPs will have to be present that are defined in
section 2.0, 6.0 and 7.0. There is no easy way to make the ABNF because of the
fact that the AAR is used for framed, non-framed and tunneling access. It
sounds like we have a couple of options:

1. Define a new message for each framed, non-framed and tunneling. Although
this seems heavyweight, it is VERY simple to encode the ABNF, and makes the
protocol alot cleaner. It makes the set of AVPS that must be present very
predictable. This would be me preferred approach.

2. Have multiple sets of ABNF, one for each type.

3. Leave it as-is, with the pointer to the sections that contain the AVPs, and
an english representation of the ABNF rules (as it is right now).

Preferences?

PatC




From owner-aaa-bof@merit.edu  Fri Apr  6 09:52:40 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA09342
	for <aaa-archive@odin.ietf.org>; Fri, 6 Apr 2001 09:52:39 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id DA7325DF0A; Fri,  6 Apr 2001 09:49:25 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id C636D5DF09; Fri,  6 Apr 2001 09:49:25 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id 598955DDBC
	for <aaa-wg@merit.edu>; Fri,  6 Apr 2001 09:49:24 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA11050;
	Fri, 6 Apr 2001 06:49:07 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA05270;
	Fri, 6 Apr 2001 06:49:06 -0700 (PDT)
Received: from darius (darius [10.6.84.105])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id GAA22975;
	Fri, 6 Apr 2001 06:48:55 -0700 (PDT)
Date: Fri, 6 Apr 2001 06:48:54 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Subject: [AAA-WG]: Proposed NASREQ changes (was: New Extension text in base protocol)
To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Cc: Mark Eklund <meklund@cisco.com>, Bernard Aboba <aboba@internaut.com>,
        Fredrik Johansson <fredrik.johansson@ipunplugged.com>,
        Mark Jones <mjones@bridgewatersystems.com>,
        David Spence <DSpence@Interlinknetworks.com>, aaa-wg@merit.edu,
        diameter@diameter.org
In-Reply-To: "Your message with ID" <Roam.SIMC.2.0.6.986561026.25566.pcalhoun@nasnfs>
Message-ID: <Roam.SIMC.2.0.6.986564934.27596.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> ok, looks like I have a bit of work in that extension. The service-type and
> idle-timeout SHOULD have been present. If you read the text in section 3.1.1,
> it states that additional AVPs will have to be present that are defined in
> section 2.0, 6.0 and 7.0. There is no easy way to make the ABNF because of
> the fact that the AAR is used for framed, non-framed and tunneling access. It
> sounds like we have a couple of options:
> 
> 1. Define a new message for each framed, non-framed and tunneling. Although
> this seems heavyweight, it is VERY simple to encode the ABNF, and makes the
> protocol alot cleaner. It makes the set of AVPS that must be present very
> predictable. This would be me preferred approach.
> 
> 2. Have multiple sets of ABNF, one for each type.
> 
> 3. Leave it as-is, with the pointer to the sections that contain the AVPs,
> and an english representation of the ABNF rules (as it is right now).

All,

Just a little more on my proposed option 1 above. I realize that it is rather
late in the game to make such a change, but the more I think about it, the
more sense it seems to make.

First, the extension is heavily inspired on RADIUS, hence the single commands
for framed, non-framed and tunneling. Given that I tried to keep as much
RADIUS as possible, I decided to follow this logic. However, as any RADIUS
developer knows, the protocol does get kinda ugly when trying to figure out
what AVPs need to be present, based on the access method (ppp, telnet, etc).

In fact, each one of these are separate services. Providing telnet services is
vastly different from PPP access, but RADIUS tried to make it look the same by
having a single command code.

So my proposal would be for the base protocol to have the following command
codes defined:

Framed-Auth-Request/Framed-Auth-Answer/Framed-Auth-Ind
Non-Framed-Auth-Request/Non-Framed-Auth-Answer/Framed-Auth-Ind

Given that EAP does operate differently, I still would like to keep EAP as
separate command codes.

Unfortunately, I don't think that we can split up tunnling from framed,
because it is possible for the NAS to think PPP is being provided, but the
server returns tunneling attributes. So the above two would still make it
cleaner.

So, does the WG think that the above would lead to a cleaner ABNF definition,
and a better protocol, or should I leave it as-is?

PatC




From owner-aaa-bof@merit.edu  Fri Apr  6 10:05:35 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09692
	for <aaa-archive@odin.ietf.org>; Fri, 6 Apr 2001 10:05:35 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 99D425DF63; Fri,  6 Apr 2001 10:03:24 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 81F075DF64; Fri,  6 Apr 2001 10:03:24 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id 3B68D5DF63
	for <aaa-wg@merit.edu>; Fri,  6 Apr 2001 10:03:23 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA16833;
	Fri, 6 Apr 2001 07:03:12 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA07036;
	Fri, 6 Apr 2001 07:03:11 -0700 (PDT)
Received: from darius (darius [10.6.84.105])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id HAA23094;
	Fri, 6 Apr 2001 07:03:08 -0700 (PDT)
Date: Fri, 6 Apr 2001 07:03:06 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Subject: RE: [AAA-WG]: Extensions & Framework (was: Diameter Issues found @ Connectathon)
To: Bernard Aboba <aboba@internaut.com>
Cc: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>,
        Fredrik Johansson <fredrik.johansson@ipunplugged.com>,
        Mark Jones <mjones@bridgewatersystems.com>,
        David Spence <DSpence@Interlinknetworks.com>, aaa-wg@merit.edu,
        diameter@diameter.org
In-Reply-To: "Your message with ID" <OJEJKOMOEAKLMOILFCPJGEGNEFAA.aboba@internaut.com>
Message-ID: <Roam.SIMC.2.0.6.986565786.17414.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> >If that's the case, then I would expect the AAA server to ALSO support the
> >proprietary extension, right?
> 
> Remember, the proxy may be serving a large number of servers, all with 
> different capabilities. I think that there may be some optimizations
> that can be made for this case.

correct.

> 
> Let's say that dmitton@nortelnetworks.com has a dialup account with
> a roaming association that handles many types of Internet access,
> including Mobile IP, dialup, etc. However, Nortel's DIAMETER server
> does not support the Mobile IP extension. 
> 
> Dave will connect to the FA which will talk to a proxy that is 
> capable of doing anything, and therefore will advertise wildcard
> capabilities. However, the request when proxied to Nortel will
> result in an error because the required capabilities are not present.

correct.

> 
> One would hope that this same result would not be repeated on 
> every attempt, but rather that the capabilities of the Nortel
> server would be cached by the proxy for some TTL. Therefore on
> the next attempt, the proxy would NOT advertise wildcard capabilites
> for a request to a destination realm whose capabilities it has cached.
> Instead, it will advertise the capabilities appropriate to that
> particular destination realm. 

I don't understand what you mean by advertising on the next attempt.
Advertising is done when the link is brought up only. I believe what you meant
the say is that the proxy will cache the fact that the Nortel server doesn't
support Mobile IP, at least until the link goes down again.

Then you state that a proxy will NOT advertise services for a particular
realm. The protocol doesn't currently allow proxies to advertise services for
a particular realm. This was intentional. Doing so would be a HUGE protocol
effort, and not one that is really that worth while, IMHO.

Perhaps one day if this really becomes an issue, we can revise the protocol
accordingly.

PatC




From owner-aaa-bof@merit.edu  Fri Apr  6 10:12:27 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09846
	for <aaa-archive@odin.ietf.org>; Fri, 6 Apr 2001 10:12:26 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 848A95DDEC; Fri,  6 Apr 2001 10:12:09 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 71EE05DDDB; Fri,  6 Apr 2001 10:12:09 -0400 (EDT)
Received: from cisco.com (titans.cisco.com [161.44.216.10])
	by segue.merit.edu (Postfix) with ESMTP id 63C5A5DDBC
	for <aaa-wg@merit.edu>; Fri,  6 Apr 2001 10:12:07 -0400 (EDT)
Received: from knox6039 (knox6039.cisco.com [161.44.216.39])
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA13271;
	Fri, 6 Apr 2001 10:11:57 -0400 (EDT)
Date: Fri, 6 Apr 2001 10:12:16 -0400 (EDT)
From: Mark Eklund <meklund@cisco.com>
X-Sender: meklund@knox6039
To: aaa-wg@merit.edu, diameter@diameter.org
Subject: [AAA-WG]: Failed-AVP AVP
Message-ID: <Pine.GSO.4.21.0104061005190.22108-100000@knox6039>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=iso-8859-1
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id KAA09846

I've got a problem with the Failed-AVP AVP and a suggestion.

1. The documentation for a Result-Code AVP with a value of
   DIAMETER_MISSING_AVP states that 
         ..., a Failed-AVP AVP SHOULD be included in the message.
         The data portion of the Failed-AVP MUST only contain the AVP
         Code of the missing AVP.

   My question: Shouldn't the vendor ID be included somewhere?

2. Wouldn't it make more sense for the Failed-AVP AVP be of type
   grouped?  In this way, the vendor will be included and
   standard packet facilities can be used to access the AVP.

-mark
  




From owner-aaa-bof@merit.edu  Fri Apr  6 10:36:44 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10607
	for <aaa-archive@odin.ietf.org>; Fri, 6 Apr 2001 10:36:44 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 7F9015DEC8; Fri,  6 Apr 2001 10:34:44 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 6CE8A5DE64; Fri,  6 Apr 2001 10:34:44 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id 126AE5DDE7
	for <aaa-wg@merit.edu>; Fri,  6 Apr 2001 10:34:43 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA29897;
	Fri, 6 Apr 2001 07:34:39 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA10912;
	Fri, 6 Apr 2001 07:34:38 -0700 (PDT)
Received: from darius (darius [10.6.84.105])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id HAA23385;
	Fri, 6 Apr 2001 07:34:37 -0700 (PDT)
Date: Fri, 6 Apr 2001 07:34:35 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Subject: [AAA-WG]: Re: [diameter] Failed-AVP AVP
To: Mark Eklund <meklund@cisco.com>
Cc: aaa-wg@merit.edu, diameter@diameter.org
In-Reply-To: "Your message with ID" <Pine.GSO.4.21.0104061005190.22108-100000@knox6039>
Message-ID: <Roam.SIMC.2.0.6.986567675.28403.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=iso-8859-1
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id KAA10607

> I've got a problem with the Failed-AVP AVP and a suggestion.
> 
> 1. The documentation for a Result-Code AVP with a value of
>    DIAMETER_MISSING_AVP states that 
>          ..., a Failed-AVP AVP SHOULD be included in the message.
>          The data portion of the Failed-AVP MUST only contain the AVP
>          Code of the missing AVP.
> 
>    My question: Shouldn't the vendor ID be included somewhere?

Right. This problem was already fixed for command codes in the -02 candidate,
but not for Failed-AVPs. A new AVP was introduced, and I made modifications to
support Failed-AVPs as well. The new text reads (TBD will be fixed):

10.1.3  Failed-Vendor-Id AVP

The Failed-Command-Code-Vendor-Id AVP (AVP Code TBD) is of type
Unsigned32 and MUST be present if a vendor-specific Command-Code
or AVP caused the error.

> 2. Wouldn't it make more sense for the Failed-AVP AVP be of type
>    grouped?  In this way, the vendor will be included and
>    standard packet facilities can be used to access the AVP.

This would be useful if many different Failed-AVPs needed to be returned, but
I am not sure this would really happen. What does the WG think about this one??
 PatC




From owner-aaa-bof@merit.edu  Fri Apr  6 10:38:54 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10646
	for <aaa-archive@odin.ietf.org>; Fri, 6 Apr 2001 10:38:53 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 8C6725DDEF; Fri,  6 Apr 2001 10:38:40 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 75B015DDE7; Fri,  6 Apr 2001 10:38:40 -0400 (EDT)
Received: from mail01.bridgewatersystems.com (mail01.bridgewatersystems.com [216.113.7.9])
	by segue.merit.edu (Postfix) with ESMTP id 9C5495DDBC
	for <Aaa-Wg@merit.edu>; Fri,  6 Apr 2001 10:38:38 -0400 (EDT)
Received: from kansparc099.bridgewatersys.com (cactusgw.bridgewatersys.com [216.113.7.2])
	by mail01.bridgewatersystems.com (8.9.3/8.9.3) with ESMTP id LAA18725;
	Fri, 6 Apr 2001 11:35:00 -0400
Received: from mjones (mjones.bridgewatersys.com [192.168.150.32])
	by kansparc099.bridgewatersys.com (8.9.3+Sun/8.9.1) with SMTP id KAA27164;
	Fri, 6 Apr 2001 10:39:17 -0400 (EDT)
From: "Mark Jones" <mjones@bridgewatersystems.com>
To: "David Frascone" <dave@frascone.com>,
        "Christian Huitema" <huitema@exchange.microsoft.com>
Cc: <Aaa-Wg@merit.edu>
Subject: RE: [AAA-WG]: AAA WG Interim meeting dates
Date: Fri, 6 Apr 2001 10:40:26 -0400
Message-ID: <000e01c0bea7$84ecc820$2096a8c0@mjones.bridgewatersys.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <20010405140011.N24201@newman.frascone.com>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Importance: Normal
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

> > 5) Device-Reboot-Ind (DRI) Command
> >
> > Having a mandatory Vendor-ID in the command creates a barrier to entry
> > for implementors: it requires that they first register with the IANA.
> > This should be optional. There is no reason to mandate the presence of a
> > vendor-id if no vendor extensions are used, a case which we hope should
> > be quite common.
>

The Vendor-Id/Product-Name/Firmware-Revision AVPs also serve to identify the
peer regardless of whether it generates vendor-specific AVPs.

> I agree with this comment.  I to prefer a vendor string over an
> IANA number.
>

If the AVP was only intended to be human-readable, I would agree. If my
Diameter server has to interpret it, I prefer a well-known integer. For
vendor string to be equally machine-readable, one would have to ensure that
every Diameter peer produced by the same large corporation had the same
well-known value. Otherwise how many permutations could we have of "Sun
Microsystems Inc."?

> I'm assuming it's easy for a company to get a vendor id, but what about
> someone testing a concept:  "Umm, can I get a "Dave's new Toy vendor id" ?
>

So this oft repeated "barrier to entry" is for those implementing a Diameter
device/server who have yet to form a company and so would be ineligible for
an IANA code. You're looking for something akin to the Experimental branch
on the SNMP MIB. Is that right?

Would the following text help?

"A Vendor-Id value of zero in the DRI is reserved and indicates that the
Diameter peer is in the experimental or concept stage and that an IANA
Private Enterprise Number has yet to be obtained by the implementor."

Regards,
       Mark




From owner-aaa-bof@merit.edu  Fri Apr  6 10:42:20 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10752
	for <aaa-archive@odin.ietf.org>; Fri, 6 Apr 2001 10:42:20 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id CE61C5DDE7; Fri,  6 Apr 2001 10:42:04 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id BDAFB5DDDB; Fri,  6 Apr 2001 10:42:04 -0400 (EDT)
Received: from newman.frascone.com (frascone.com [216.62.83.25])
	by segue.merit.edu (Postfix) with SMTP id EF5115DDBC
	for <Aaa-Wg@merit.edu>; Fri,  6 Apr 2001 10:42:02 -0400 (EDT)
Received: (qmail 10918 invoked by uid 500); 6 Apr 2001 14:42:02 -0000
Date: Fri, 6 Apr 2001 09:42:02 -0500
From: David Frascone <dave@frascone.com>
To: Mark Jones <mjones@bridgewatersystems.com>
Cc: David Frascone <dave@frascone.com>,
        Christian Huitema <huitema@exchange.microsoft.com>, Aaa-Wg@merit.edu
Subject: Re: [AAA-WG]: AAA WG Interim meeting dates
Message-ID: <20010406094201.E1519@newman.frascone.com>
Mail-Followup-To: Mark Jones <mjones@bridgewatersystems.com>,
	David Frascone <dave@frascone.com>,
	Christian Huitema <huitema@exchange.microsoft.com>,
	Aaa-Wg@merit.edu
References: <20010405140011.N24201@newman.frascone.com> <000e01c0bea7$84ecc820$2096a8c0@mjones.bridgewatersys.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <000e01c0bea7$84ecc820$2096a8c0@mjones.bridgewatersys.com>; from mjones@bridgewatersystems.com on Fri, Apr 06, 2001 at 10:40:26AM -0400
X-encrypt-payload: no
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> Would the following text help?
> 
> "A Vendor-Id value of zero in the DRI is reserved and indicates that the
> Diameter peer is in the experimental or concept stage and that an IANA
> Private Enterprise Number has yet to be obtained by the implementor."
> 

Hey!  I like it!  Any other opinions?



From owner-aaa-bof@merit.edu  Fri Apr  6 10:56:53 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11186
	for <aaa-archive@odin.ietf.org>; Fri, 6 Apr 2001 10:56:53 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 3CE175DE04; Fri,  6 Apr 2001 10:56:33 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 2BAAC5DDFF; Fri,  6 Apr 2001 10:56:33 -0400 (EDT)
Received: from mailgw.local.ipunplugged.com (unknown [213.88.134.217])
	by segue.merit.edu (Postfix) with ESMTP id B33D85DDDB
	for <aaa-wg@merit.edu>; Fri,  6 Apr 2001 10:56:30 -0400 (EDT)
Received: from fredrikj (c42.local.ipunplugged.com [192.168.4.241])
	by mailgw.local.ipunplugged.com (8.9.3/8.9.3) with SMTP id QAA22729;
	Fri, 6 Apr 2001 16:57:49 +0200
From: "Fredrik Johansson" <fredrik.johansson@ipunplugged.com>
To: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>,
        "'Patrice Calhoun'" <pcalhoun@nasnfs.Eng.Sun.COM>,
        "Tony Johansson" <tony.johansson@ericsson.com>
Cc: "AAA Listan" <aaa-wg@merit.edu>
Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
Date: Fri, 6 Apr 2001 16:58:21 +0200
Message-ID: <MJEMJBGGCLLDLFFAHLJKAEJKCJAA.fredrik.johansson@ipunplugged.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <577066326047D41180AC00508B955DDA01D7FF5D@eestqnt104.es.eu.ericsson.se>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

>
>
>> >
>> > This leads to a couple of questions:
>> >
>> > 1. How should the AAAF deal with the new Session-Id? The
>> AAAH does not know
>> > about new one in this case.
>> >
>> > One way of solving this could be to let the AAAF over write
>> the new session
>> > id and add on the initial session id into the Session-Id
>> AVP in the reply
>> > back to the new FA together FA-MN and FA-HA keys, and the
>> > Authorization-Lifetime. Or maybe a new AVP for the initial
>> session id is
>> > needed...
>>
>> I think it would be much cleaner to have a new AVP, rather
>> than the old one.
>
>Just to make sure, I guess you meant that
>the Session-Id that has been authorized by the AAAH should
>remain the valid Session-Id for the active MIP session, right?
>Let's call "authorized Session-Id", the Session-Id that has
>been officially authorized previously by the AAAH.
>
>Let's say that the MN moves to a new FA within
>the same domain. When the AAAF receives a MIP Registration
>from a MN, the message includes a MIP-Previous-FA-FQDN AVP,
>which identifies the previous FA. It also includes the
>User-Name AVP, which is supposed to be used for identifying
>the FA-MN and FA-HA keys that need to be sent to MN.
>That authorized Session-ID would be sent back to
>the new FA in the AMA message from the AAAF, packaged in a new
>"MIP-Previous-Session-ID" AVP. The new Session-ID would be just
>ignored? I guess that the "authorized"
>Session-ID could be kept in the AAAF, along with the FA-XX keys.
>
>Using that new AVP, it remains possible to support
>roaming between FAs within the same domain without involving
>unnecessarily the AAAH. Also, the accounting part is
>not impacted at all, since the Session-Id remains the same.
>No accounting start and stop are required, neither re-authentication
>and re-generation of keys. I think that is a very efficient and
>clean way of supporting it.

Why don't you need to stop accounting? I agree that if you have accounting
based on bytes or packets it is ok to let the timer expire in the FA, but if
you have time based accounting you have to terminate the accounting session
with the old FA otherwise it will overlap with the new FA's accounting
session. It can also be solved in the server but I believe that it is more
complicated for the server to keep track of what overlaps what instead of
just terminating one session.

Another thing that needs some clarification, if there is a solution. How
will the HA know which SA to use. In the case where a mobile moves from one
Fa to another under the same administrative domain it may receive the
session keys for the old Fa from the AAAF. It will then proceed to send the
mip reg req to the HA. The HA will see that the message came from the new FA
and try to locate the SA shared with that FA. It will not find it since it
was established with the old FA. Eventhough the HA can see the address of
the old Fa in the previous-fa-XXXX it is not clear that it can establish a
SA with the new Fa because it has to use the same SPI as before and that one
might be busy. Or have I missed something here?

/Fredrik

>
>About the STI to the old FA, why can't it be handled by the
>Mobile IP standard? I guess an STI should be sent to the Diameter
>client (FA) only if the session needs to be interrupted, or if you
>prefer, prematurely terminated. However, there is no need of
>terminating the Accounting session.
>
>But if we support roaming between FA the way described
>previously, then we still have the problems that the AAAF
>does not seem to be that "stateless", there is a problem
>of synchronizing data between the AAAF and the AAAH,
>especially in terms of active FA, and it is not obvious
>that we would gain that much in performance compared to
>complexity, if we start adding new messages and AVPs.
>
>I would say that I like the previous suggestion, if we
>would add that the AAAF does not keep any information
>at all on the session, and that the AAAH remains the
>master of the session. That means that each Registration
>needs to go to the AAAH (AMR), which performs the authentication
>and overides the Session-Id with the authorized one, while
>updating its reference to the actual FA and triggering a STI
>to the previous FA. The key for the session would be the User-Name,
>as already proposed for the AAAF. It seems to be more work, but it is
>similar to the case with the HAA story, which means more generic
>and less complexed traffic cases. In fact, moving from one
>FA in one domain to another FA in another domain would also
>work perfectly in that context. Even the keys could be
>transmitted that way, at the exception of the FA-HA, in the
>case where the HA is in the foreign domain, which I don't
>really understand why we must comply to that???
>
>I guess you understand that I now question to use of the
>MIP-Previous-FA-XX AVPs, since they don't seem to bring
>much information else than telling the FA that they used
>to be connected to a former FA, for which the FA can not
>do much about, beside knowing that if it was in the same
>domain, then it should take care of sending himself the
>MIP Registration to the HA, when it receives the required key
>from the AAAF, right?
>
>And as a note, I think that a "key" for a session in the AAAH
>makes much more sense as a User-Name for the primary key, and as a
>Session-ID for the secondary key. I guess that making the
>User-Name mandatory in every message in a good thing.
>
>> >
>> > 2. Furthermore, the AAAH would not get any information in
>> this case, so it
>> > would not know that the FA has changed only the AAAF is
>> aware of it. Thus,
>> > if the AAAH wants to send an STI to terminate the session
>> for some reason it
>> > would issue the STI towards the wrong FA.
>> >
>> > A solution to this could perhaps be that the AAAH initially gets the
>> > information about responsible AAAF in the foreign network,
>> so if the AAAH
>> > needs to send an STI it would issue it towards the AAAF and
>> the AAAF would
>> > be responsible to resolve it and forward it to the right FA.
>>
>> hmmmm... I would MUCH prefer to NOT assume state on the AAAF.
>> I believe that
>> it would be more appropriate to define a new message, of type
>> -Ind, which is
>> sent by the AAAF to the AAAH to notify it of a location change.
>
>How can you achieve a stateless AAAF, when you need to keep at
>least the FA-MN and FA-HA keys for the particular MIP session?
>AFAIK, there is no way of pulling the data from the previous
>FA, and transfer them to the new FA, right? That means that the
>AAAF needs to keep a state. Then, what's the big deal with
>keeping the information about the FA as well and then the AAAH
>would only need to know the AAAF? The AAAF would become in charge
>of forwarding it to the good FA.
>
>> However, this is new functionality, and we did agree to NOT
>> include new
>> functionality, but only fix bugs. So, is this a bug, or a new
>> functionality?
>>
>> > Another way would be to let the AAAF to issue an Indication
>> to the AAAH to
>> > inform that the MN has changed FA.
>>
>> oops, great minds think alike :)
>>
>> PatC
>>
>
>Regards,
>Martin




From owner-aaa-bof@merit.edu  Fri Apr  6 11:35:19 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12340
	for <aaa-archive@odin.ietf.org>; Fri, 6 Apr 2001 11:35:18 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id AEECC5DEFC; Fri,  6 Apr 2001 11:32:59 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9CCAE5DEFB; Fri,  6 Apr 2001 11:32:59 -0400 (EDT)
Received: from gate.internaut.com (unknown [64.38.134.101])
	by segue.merit.edu (Postfix) with ESMTP id B5ED05DEF5
	for <aaa-wg@merit.edu>; Fri,  6 Apr 2001 11:32:57 -0400 (EDT)
Received: from e1kj2 (e1kj2 [64.38.134.109])
	by gate.internaut.com (8.10.2/8.10.2) with SMTP id f36FMYN05126
	for <aaa-wg@merit.edu>; Fri, 6 Apr 2001 08:22:35 -0700
From: "Bernard Aboba" <aboba@internaut.com>
To: "Aaa-Wg@Merit. Edu" <aaa-wg@merit.edu>
Subject: [AAA-WG]: Announcement: AAA WG Interim Meeting
Date: Fri, 6 Apr 2001 08:34:19 -0700
Message-ID: <OJEJKOMOEAKLMOILFCPJIEGPEFAA.aboba@internaut.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

The AAA WG will be having an Interim Meeting on
May 15-16, 2001. Location is San Jose, CA. 
For this meeting, a detailed reading of the
latest document version is essential, since
much of the meeting will be devoted to a
"document bug bashing" session. In addition
to this, the following topics will be 
discussed:

a. Heartbeat
b. Capabilities negotiation
c. Extensibility model and IANA considerations
d. Proxy behavior
e. RADIUS backward compatibility
f. State machine (if not resolved yet)

If you would like to attend the interim
meeting, please send mail to aboba@internaut.com
and I will mail the details to you as soon as
they are available.



From owner-aaa-bof@merit.edu  Fri Apr  6 11:49:54 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12690
	for <aaa-archive@odin.ietf.org>; Fri, 6 Apr 2001 11:49:54 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id A971A5DF23; Fri,  6 Apr 2001 11:48:16 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 974095DF22; Fri,  6 Apr 2001 11:48:16 -0400 (EDT)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id 57D9F5DDDB
	for <aaa-wg@merit.edu>; Fri,  6 Apr 2001 11:48:15 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA18963;
	Fri, 6 Apr 2001 08:48:08 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA25748;
	Fri, 6 Apr 2001 08:48:04 -0700 (PDT)
Received: from darius (darius [10.6.84.105])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id IAA24423;
	Fri, 6 Apr 2001 08:48:03 -0700 (PDT)
Date: Fri, 6 Apr 2001 08:48:01 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Subject: Re: [AAA-WG]: Announcement: AAA WG Interim Meeting
To: Bernard Aboba <aboba@internaut.com>
Cc: "Aaa-Wg@Merit. Edu" <aaa-wg@merit.edu>
In-Reply-To: "Your message with ID" <OJEJKOMOEAKLMOILFCPJIEGPEFAA.aboba@internaut.com>
Message-ID: <Roam.SIMC.2.0.6.986572081.20442.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk


> a. Heartbeat
> b. Capabilities negotiation
> c. Extensibility model and IANA considerations
> f. State machine (if not resolved yet)

Assuming (f) is resolved, why concentrated on the above? Are there particular
issues with the above that aren't covered in -02?

> d. Proxy behavior

If this has to do with the protocol, I am not sure that there are any pending
issues with the base spec.

If you meant to reference Dave's draft, it would be REALLY nice to know what
this draft needs to contain. Is it complete as-is?

> e. RADIUS backward compatibility

The implementor's guidelines I-D does need some work to cover the latest
protocol changes. I cannot have this done this week, but plan to have an
updated spec in by the end of the month.

PatC




From owner-aaa-bof@merit.edu  Fri Apr  6 13:08:57 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14652
	for <aaa-archive@odin.ietf.org>; Fri, 6 Apr 2001 13:08:57 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 959BE5DE1D; Fri,  6 Apr 2001 13:08:42 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 7EB605DDFF; Fri,  6 Apr 2001 13:08:42 -0400 (EDT)
Received: from ahab.tic.siemens.ca (ahab.tic.siemens.ca [64.26.131.130])
	by segue.merit.edu (Postfix) with ESMTP id 840035DDBC
	for <aaa-wg@merit.edu>; Fri,  6 Apr 2001 13:08:40 -0400 (EDT)
Received: (from mail@localhost)
	by ahab.tic.siemens.ca (8.9.3/8.9.3) id NAA10788
	for <aaa-wg@merit.edu>; Fri, 6 Apr 2001 13:09:03 -0400 (EDT)
Received: from mailman(172.21.24.8) by ahab.tic.siemens.ca via smap (V2.1)
	id xma010786; Fri, 6 Apr 01 13:08:49 -0400
Received: (from mail@localhost)
	by mailman.innovation.siemens.ca (8.9.3/8.9.3) id NAA23610
	for <aaa-wg@merit.edu>; Fri, 6 Apr 2001 13:08:21 -0400 (EDT)
Received: from ticsmtp1.innovation.siemens.ca(172.21.24.34) by mailman.innovation.siemens.ca via smap (V2.1)
	id xma023542; Fri, 6 Apr 01 13:07:07 -0400
Received: by ticsmtp1.innovation.siemens.ca with Internet Mail Service (5.5.2650.21)
	id <GHLJY87Z>; Fri, 6 Apr 2001 13:07:04 -0400
Message-ID: <E7BB0E796757D411BC9A00105ACB123E32F690@ticsmtp1.innovation.siemens.ca>
From: Yiwen Jiang <Yiwen.Jiang@tic.siemens.ca>
To: "Aaa-Wg@Merit. Edu" <aaa-wg@merit.edu>
Subject: [AAA-WG]: Origin-FQDN
Date: Fri, 6 Apr 2001 13:06:55 -0400 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Hi there,

I'm reading through the base I-D, and I noticed the mentioning of the
Origin-FQDN AVP. However, it is not listed in the AVP table under Section
4.5. 

Any reason why this is so?

Thanks.

Cheers,
Yiwen
---
Yiwen Jiang
Mobile IP Networking
Email: Yiwen.Jiang@tic.siemens.ca
Phone: (613)271-7710

Telecom Innovation Centre
505 March Road
Kanata, Ontario, Canada
K2K 2M5



From owner-aaa-bof@merit.edu  Fri Apr  6 13:15:13 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14811
	for <aaa-archive@odin.ietf.org>; Fri, 6 Apr 2001 13:15:13 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 5FFF35DE7E; Fri,  6 Apr 2001 13:14:49 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 500285DE6F; Fri,  6 Apr 2001 13:14:49 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id 173A45DE64
	for <aaa-wg@merit.edu>; Fri,  6 Apr 2001 13:14:48 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA14928;
	Fri, 6 Apr 2001 10:14:36 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA05478;
	Fri, 6 Apr 2001 10:14:35 -0700 (PDT)
Received: from darius (darius [10.6.84.105])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id KAA25701;
	Fri, 6 Apr 2001 10:14:00 -0700 (PDT)
Date: Fri, 6 Apr 2001 10:13:53 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Subject: Re: [AAA-WG]: Origin-FQDN
To: Yiwen Jiang <Yiwen.Jiang@tic.siemens.ca>
Cc: "Aaa-Wg@Merit. Edu" <aaa-wg@merit.edu>
In-Reply-To: "Your message with ID" <E7BB0E796757D411BC9A00105ACB123E32F690@ticsmtp1.innovation.siemens.ca>
Message-ID: <Roam.SIMC.2.0.6.986577233.6652.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Yiwen,

There was a cut and paste error in the -01 draft. -02 has already been fixed,
and will be available real soon.

PatC
> Hi there,
> 
> I'm reading through the base I-D, and I noticed the mentioning of the
> Origin-FQDN AVP. However, it is not listed in the AVP table under Section
> 4.5. 
> 
> Any reason why this is so?
> 
> Thanks.
> 
> Cheers,
> Yiwen
> ---
> Yiwen Jiang
> Mobile IP Networking
> Email: Yiwen.Jiang@tic.siemens.ca
> Phone: (613)271-7710
> 
> Telecom Innovation Centre
> 505 March Road
> Kanata, Ontario, Canada
> K2K 2M5
> 





From owner-aaa-bof@merit.edu  Fri Apr  6 13:37:24 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15260
	for <aaa-archive@odin.ietf.org>; Fri, 6 Apr 2001 13:37:24 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id EC34B5DF29; Fri,  6 Apr 2001 13:33:47 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id DA1145DF27; Fri,  6 Apr 2001 13:33:47 -0400 (EDT)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id AAA1E5DF26
	for <aaa-wg@merit.edu>; Fri,  6 Apr 2001 13:33:46 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA25252
	for <aaa-wg@merit.edu>; Fri, 6 Apr 2001 10:33:46 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA19515
	for <aaa-wg@merit.edu>; Fri, 6 Apr 2001 08:33:43 -0700 (PDT)
Received: from darius (darius [10.6.84.105])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id IAA24213
	for <aaa-wg@merit.edu>; Fri, 6 Apr 2001 08:33:33 -0700 (PDT)
Date: Fri, 6 Apr 2001 08:33:31 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Subject: [AAA-WG]: STI to new FA from AAAH
To: AAA Listan <aaa-wg@merit.edu>
In-Reply-To: "Your message with ID" <MJEMJBGGCLLDLFFAHLJKAEJKCJAA.fredrik.johansson@ipunplugged.com>
Message-ID: <Roam.SIMC.2.0.6.986571211.14785.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

All,

I have been thinking about this quite a bit, and it really isn't clear why
this is a AAA problem.

It seems like the easiest way for this to occur, would be for the AAAH to send
the STI to the HA, and have the HA issue some message to the FA asking for
disconnect. The Mobile IP WG is already looking at this problem, and as far as
I can tell, has even adopted Steven Glass' proposal as a WG work item.

So, if this problem is already solved in Mobile IP, do we *really* need to
complicate the Diameter protocol to *also* provide existing functionality?

So can we simply add text in the Mobile IP extension stating that the AAAH can
send the STI to the HA instead of the FA. The AAAF can send the message to the
FA. This way both of our bases are covered without any protocol changes.

Thanks,

PatC




From owner-aaa-bof@merit.edu  Fri Apr  6 13:45:03 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15403
	for <aaa-archive@odin.ietf.org>; Fri, 6 Apr 2001 13:45:03 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 4BB765DDEB; Fri,  6 Apr 2001 12:21:51 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 348725DDDB; Fri,  6 Apr 2001 12:21:51 -0400 (EDT)
Received: from gate.internaut.com (unknown [64.38.134.101])
	by segue.merit.edu (Postfix) with ESMTP id 1128E5DDBC
	for <Aaa-Wg@merit.edu>; Fri,  6 Apr 2001 12:21:49 -0400 (EDT)
Received: from e1kj2 (e1kj2 [64.38.134.109])
	by gate.internaut.com (8.10.2/8.10.2) with SMTP id f36GBJN07630;
	Fri, 6 Apr 2001 09:11:20 -0700
From: "Bernard Aboba" <aboba@internaut.com>
To: "David Frascone" <dave@frascone.com>,
        "Christian Huitema" <huitema@exchange.microsoft.com>
Cc: <Aaa-Wg@merit.edu>
Subject: RE: [AAA-WG]: AAA WG Interim meeting dates
Date: Fri, 6 Apr 2001 09:23:04 -0700
Message-ID: <OJEJKOMOEAKLMOILFCPJKEHAEFAA.aboba@internaut.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <20010405140011.N24201@newman.frascone.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

>I have no fundamental problem with your new AVP header.  In fact, I like
it.
>(I'd make one small change, though, and instead of using 255 in the length
>field, I'd grab one of those unused bits to signal that the extended length
>was being used.)

>My complaint, however, is your timing.  It seems that every time the
protocol
>goes into last call, someone stops lurking and wants to make a serious
>fundamental change.

As time goes on, the bar will be continually raised until we *will*
be rejecting many changes that are too big. But that time is
not yet here.

DIAMETER only became an official AAA WG document after the February Interim
meeting. As a AAA WG document it is only an -01. The document is not yet
in last call. At this point, we have only closed off addition of major
new capabilities. So Christian's comments are not yet outside the window.
Let's keep the argument centered around whether the proposed change
makes sense, not on whether it's "too late."

One of the criteria for accepting DIAMETER on the IETF standards
track was that change control be ceded to the IETF.
In practice, this means that we need to demonstrate during IESG review
that WG input has been incorporated where appropriate. So when
WG members suggest changes, I would like to keep discussion focused
on whether they make technical sense, rather than just rejecting
them on the basis that "the protocol cannot be changed." Arguing
about whether changes can be accepted will only slow down the
process.

The IETF standards process is considered valuable because
IETF work product is generally of high quality. This is the result
of having a lot of smart people working on the protocol and
incorporating their input. After the WG has finished, we then
have The Supreme Court (the IESG) read the protocol
in order to flush out any other issues. By nature this is not an
ultra-fast process -- but it can be made to work without excessive
delay *if* the WG does its homework up front.

Getting a document to the IESG is easy -- it's getting it
past the IESG that is hard. I would like to make sure that DIAMETER
not only receives AAA WG approval, but also passes IESG
review on the first try, if possible. If WG review discloses
significant issues, there is no reason to believe that
the IESG would not also discover those same problems. So
getting the document to the IESG quickly won't speed up
the process -- they'll just send it back to us for more work.

So in summary, the fastest way to get DIAMETER done is to quickly
incorporate WG input.

>Since you can't interoperate with other implementations without a
dictionary,
>I see no need to send data definition "on the wire".

The reason that a data dictionary is needed is that the AAA server has to
have a way to figure out how to format the AVP based on user input. If
you used ASN.1 instead, you'd still have to have a MIB to provide this
same information. So the information requirements don't really change.

Unlike the AAA server, the NAS needs to understand the semantics of the
AVPs, in order to carry out the requested action. This typically requires
code, not just a data definition. So defining the data "on the wire"
wouldn't significantly change the work required on the NAS.

Where defining data "on the wire" would help is in situations (such as
accounting) where arbitrary data structures sometimes need to be
communicated. DIAMETER can carry ASN.1, XML, or any other payload
within its AVPs, so that this is not precluded. At IETF 50, we
discussed these applications, and decided that we should accomodate
them by enabling transmission of "opaque AVPs". We also decided that we
wouldn't re-write the protocol to do this, since most of the data that is
transmitted in AAA is fairly simple -- so it makes sense to
"optimize for the common case."

>Sure it does.  Suppose you're trying to find a server to handle Mobile-Ip
>authentication.  When you do your server discovery, there are 5 diameter
servers
>available, but only one handle Mobile-IP AAA.  By looking at the
extensions,
>you'd know which one to use.

Except that in practice, capabilities negotiation is really an end-to-end
function and the current DRI mechanism doesn't really accomplish that. Say
I'm trying to reach a AAA server two hops away that has Mobile IP
capabilities.
How does knowledge of the capabilities propagate upstream?

Why not just assume that (aside from policy actions by proxies) that the
packet will be forwarded to the AAA server, who will reject it if the
appropriate capabilities are not available? This would enable end-to-end
capabilities negotiation without the need for the DRI message.




From owner-aaa-bof@merit.edu  Fri Apr  6 14:37:15 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16786
	for <aaa-archive@odin.ietf.org>; Fri, 6 Apr 2001 14:37:14 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 0E4EF5DE64; Fri,  6 Apr 2001 14:34:13 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id E96D65DDF4; Fri,  6 Apr 2001 14:34:12 -0400 (EDT)
Received: from mx.databus.com (p101-44.acedsl.com [160.79.101.44])
	by segue.merit.edu (Postfix) with ESMTP id 24CE55DDBC
	for <aaa-wg@merit.edu>; Fri,  6 Apr 2001 14:34:11 -0400 (EDT)
Received: (from barney@localhost)
	by mx.databus.com (8.11.3/8.11.3) id f36IVi305644;
	Fri, 6 Apr 2001 14:31:44 -0400 (EDT)
	(envelope-from barney)
Date: Fri, 6 Apr 2001 14:31:43 -0400
From: Barney Wolff <barney@databus.com>
To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Cc: Mark Eklund <meklund@cisco.com>, Bernard Aboba <aboba@internaut.com>,
        Fredrik Johansson <fredrik.johansson@ipunplugged.com>,
        Mark Jones <mjones@bridgewatersystems.com>,
        David Spence <DSpence@Interlinknetworks.com>, aaa-wg@merit.edu,
        diameter@diameter.org
Subject: Re: [AAA-WG]: Proposed NASREQ changes (was: New Extension text in base protocol)
Message-ID: <20010406143143.A5620@mx.databus.com>
References: <Roam.SIMC.2.0.6.986561026.25566.pcalhoun@nasnfs> <Roam.SIMC.2.0.6.986564934.27596.pcalhoun@nasnfs>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <Roam.SIMC.2.0.6.986564934.27596.pcalhoun@nasnfs>; from pcalhoun@nasnfs.Eng.Sun.COM on Fri, Apr 06, 2001 at 06:48:54AM -0700
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Pat, the real world intrudes.  It is perfectly possible today with
RADIUS for a user to log in non-framed and have the server say
that the service to be provided is framed.  Lots of people do that
to accomodate token cards, for example.

I have no problem with separate ABNF for the two cases, but it must
be possible to step up to framed at any reasonable point in the
dialog.

Barney

On Fri, Apr 06, 2001 at 06:48:54AM -0700, Patrice Calhoun wrote:
> 
> In fact, each one of these are separate services. Providing telnet services is
> vastly different from PPP access, but RADIUS tried to make it look the same by
> having a single command code.
> 
> So my proposal would be for the base protocol to have the following command
> codes defined:
> 
> Framed-Auth-Request/Framed-Auth-Answer/Framed-Auth-Ind
> Non-Framed-Auth-Request/Non-Framed-Auth-Answer/Framed-Auth-Ind
> 
> Given that EAP does operate differently, I still would like to keep EAP as
> separate command codes.



From owner-aaa-bof@merit.edu  Fri Apr  6 20:00:16 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA23432
	for <aaa-archive@odin.ietf.org>; Fri, 6 Apr 2001 20:00:16 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id F0BA75DF7C; Fri,  6 Apr 2001 14:37:34 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id D36FB5DDF4; Fri,  6 Apr 2001 14:37:34 -0400 (EDT)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id 581855DF7B
	for <aaa-wg@merit.edu>; Fri,  6 Apr 2001 14:37:33 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA16682;
	Fri, 6 Apr 2001 11:37:19 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA05615;
	Fri, 6 Apr 2001 11:37:18 -0700 (PDT)
Received: from darius (darius [10.6.84.105])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id LAA27817;
	Fri, 6 Apr 2001 11:37:13 -0700 (PDT)
Date: Fri, 6 Apr 2001 11:37:10 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Subject: Re: [AAA-WG]: Proposed NASREQ changes (was: New Extension text in base protocol)
To: Barney Wolff <barney@databus.com>
Cc: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>,
        Mark Eklund <meklund@cisco.com>, Bernard Aboba <aboba@internaut.com>,
        Fredrik Johansson <fredrik.johansson@ipunplugged.com>,
        Mark Jones <mjones@bridgewatersystems.com>,
        David Spence <DSpence@Interlinknetworks.com>, aaa-wg@merit.edu,
        diameter@diameter.org
In-Reply-To: "Your message with ID" <20010406143143.A5620@mx.databus.com>
Message-ID: <Roam.SIMC.2.0.6.986582230.26105.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

ok, then I retract my previous proposal :(

Thanks Barney,

PatC
> Pat, the real world intrudes.  It is perfectly possible today with
> RADIUS for a user to log in non-framed and have the server say
> that the service to be provided is framed.  Lots of people do that
> to accomodate token cards, for example.
> 
> I have no problem with separate ABNF for the two cases, but it must
> be possible to step up to framed at any reasonable point in the
> dialog.
> 
> Barney
> 
> On Fri, Apr 06, 2001 at 06:48:54AM -0700, Patrice Calhoun wrote:
> > 
> > In fact, each one of these are separate services. Providing telnet services is
> > vastly different from PPP access, but RADIUS tried to make it look the same by
> > having a single command code.
> > 
> > So my proposal would be for the base protocol to have the following command
> > codes defined:
> > 
> > Framed-Auth-Request/Framed-Auth-Answer/Framed-Auth-Ind
> > Non-Framed-Auth-Request/Non-Framed-Auth-Answer/Framed-Auth-Ind
> > 
> > Given that EAP does operate differently, I still would like to keep EAP as
> > separate command codes.





From owner-aaa-bof@merit.edu  Fri Apr  6 20:04:49 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA23459
	for <aaa-archive@odin.ietf.org>; Fri, 6 Apr 2001 20:04:14 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 7A5D75DEC9; Fri,  6 Apr 2001 20:01:15 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 68BDA5DE5F; Fri,  6 Apr 2001 20:01:15 -0400 (EDT)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id 160D85DDB3
	for <aaa-wg@merit.edu>; Fri,  6 Apr 2001 20:01:14 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id RAA28265
	for <aaa-wg@merit.edu>; Fri, 6 Apr 2001 17:01:13 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id RAA11611
	for <aaa-wg@merit.edu>; Fri, 6 Apr 2001 17:01:12 -0700 (PDT)
Received: from darius (darius [10.6.84.105])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id RAA02850
	for <aaa-wg@merit.edu>; Fri, 6 Apr 2001 17:01:06 -0700 (PDT)
Date: Fri, 6 Apr 2001 17:01:04 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Subject: [AAA-WG]: The AAA Web Page
To: aaa-wg@merit.edu
Message-ID: <Roam.SIMC.2.0.6.986601664.29229.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

All (and more importantly co-chairs),

Now that the Diameter base specification includes parts of the framework, and
the accounting extension, I believe it would be wise to ask that the
secretariat remove both of these documents from the web page to reduce
confusion.

Thanks,

PatC




From owner-aaa-bof@merit.edu  Fri Apr  6 20:15:22 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA23582
	for <aaa-archive@odin.ietf.org>; Fri, 6 Apr 2001 20:15:22 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id CE40D5DF54; Fri,  6 Apr 2001 17:38:35 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id B0EDA5DF50; Fri,  6 Apr 2001 17:38:35 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id 423055DF54
	for <aaa-wg@merit.edu>; Fri,  6 Apr 2001 17:38:34 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id OAA00588
	for <aaa-wg@merit.edu>; Fri, 6 Apr 2001 14:38:30 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA09829;
	Fri, 6 Apr 2001 14:37:41 -0700 (PDT)
Received: from darius (darius [10.6.84.105])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id OAA00187;
	Fri, 6 Apr 2001 14:37:33 -0700 (PDT)
Date: Fri, 6 Apr 2001 14:37:30 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Subject: [AAA-WG]: Christian's comments
To: aaa-wg@merit.edu
Cc: pcalhoun@eng.sun.com
In-Reply-To: "Your message with ID" <Roam.SIMC.2.0.6.986591596.2935.pcalhoun@nasnfs>
Message-ID: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Sorry for the latency.

Comments below

> I have a somewhat fundamental issue with the Diameter. Why is the IETF
> trying to invent yet another marshalling protocol, instead of using
> existing technologies such as XML or ASN.1? Radius made some sense,
> because it was very well scoped and very limited in complexity. The
> Diameter specification is much more ambitious than Radius; it attempts
> to define a fully capable marshalling protocol, using the RFC process
> and the IANA as a substitute for an interface definition language. If I
> am developing a specific application protocol, why should I base it on
> Diameter rather than ASN.1 or XML?

I understand that you were probably not following the WG's mailing list when
the protocol evaluation was under way, but there were plenty of binary vs.
ascii protocol wars at that time, and Diameter came out as the preferred
protocol.

I see now reason to re-open that can of worms.

> 
> The answer to that specific issue will probably be given by the market.
> If the application developers are not convinced by Diameter, they will
> probably simply use something else. 

correct.

> In any case, there are quite a few
> detailed problems in the specification.
> 
> 1) Mandatory use of SLP or SLPv2 for "Diameter service discovery"
> 
> This creates a dependency on SLP for very little benefit, and possibly
> some harmful consequences. Diameter is primarily meant to be used for
> AAA applications; these applications require some tight control; in
> practice, that control requires some form of explicit parametrization of
> the device. The DNS SRV mechanism already provides a layer of
> indirection between the name of the server and its actual
> implementation; there is no need for an additional mechanism. In any
> case, the decision to use a local discovery mechanism rather than a
> configuration mechanism belongs in the application documents, not in the
> base spec.

Note that SLP is only recommended as one of the server discovery approaches,
and only for intra-domain cases. If the WG feels that the use of SLP as a
service location protocol is innapropriate for AAA, we can make the necessary
changes.


> 
> 2) AVP header format
> 
> As specified, it seems impossible to encode an attribute in less than 96
> bits. This is way less efficient than Radius. This seems particularly
> ill-suited to mobile applications, in which bandwidth is at a premium.

only over the air, and Diameter *never* gets sent over the air. BTW, one of
the reasons for NOT using a text-based approach was for bloat :)

> Having a 64 header per attribute means that in most practical
> applications there will not be any advantage to using the binary format
> of Diameter compared to more modern technologies such as XML; there will
> also be no particular advantage compared to classic technologies such as
> ASN.1/BER. If that is the case, why bother with Diameter at all?

Again, see the archives. RADIUS compatibility (or interoperability) was also
ranked very high as a pritority, so we decided to maintain the RADIUS
philosophy.

> 
> Why do we believe that we need 32 bits to encode attribute types? It is
> certainly possible to encode the combination of length, flags and
> attribute type in a single 32 bit word, at least in the common case of
> attribute length lower than 255. 
Been there, done that in RADIUS, and 255 is way too restrictive. 

Again, I'd like to hear why the backbone is so contrained that the header
sizes will cause problems.

> A format like the following would
> feature the same amount of information in half the space, still allowing
> for more attribute types than the IANA can possibly handle; if the
> length is larger than 254, the AVP length is set to 255 and an optional
> length field is added. Four bits are reserved for type indication,
> discussed later.
> 
>        0                   1                   2                   3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |           AVP Code            |P|V|M|r|t t t t|  AVP Length   |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                 Extended length (optional)                    |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |                        Vendor-ID (opt)                        |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |    Data ...
>       +-+-+-+-+-+-+-+-+

I don't particularly like the fact that I need to look for an 8-bit length, to
find out that I have a 32-bit length. If the WG decides this is a valuable
approach, I will listen.

> 3) AVP Data Formats
> 
> In the spec, the data format is determined by the value of the AVP code.
> This has an operational consequence: it becomes impossible to write a
> monitoring utility or a logging utility without having a complete
> dictionary. I suggest sticking a 4 bit "data type" field as a complement
> to the AVP code
> 
>       1 - OctetString
>       2 - Address
>       3 - Integer32
>       4 - Integer64
>       5 - Unsigned32
>       6 - Unsigned64
>       7 - Float32
>       8 - Float64
>       9 - Float128
>      10 - Grouped

I don't have a particular problem with this proposal. What does the rest of
the WG think?

> By the way, it would probably be very practical to defined a "boolean"
> type, of code zero, to encode a basic protocol flag.

The SMIng folks didn't seem to think that boolean is a valuable type, so I
will let them speak for this one.

> 
> 4) Grouped attributes
> 
> In the case of the "grouped" attribute, we have a real problem of type
> definition. Shall we require that all AVP codes in the group are present
> in the dictionary, or can they be simply defined in the context of the
> group? The latter does provide for much more flexibility, and is in line
> with the practice of ASN.1 or XML.
> 
> Both ASN.1 and XML Schema Language provide way to define the structure
> of grouping: order list, unordered set, array of elements. How do we do
> this in Diameter?
> 
> Adding two categories for "XML text" and "ASN.1 BER" would actually make
> a lot of sense.

see archives.

> 
> 5) Device-Reboot-Ind (DRI) Command
> 
> Having a mandatory Vendor-ID in the command creates a barrier to entry
> for implementors: it requires that they first register with the IANA.
> This should be optional. There is no reason to mandate the presence of a
> vendor-id if no vendor extensions are used, a case which we hope should
> be quite common.

This was a concern at the bake-off, and we had proposed to make a change that
would not require IANA registration. However, members of the WG opposed that
idea as the process to get the vendor id is apparently painless.

> 
> 6)  Extension-Id AVP in DRI command
> 
> The presence of an extension-id AVP is symptomatic of an unsolved
> dilemma in the Diameter sprecification. Is Diameter a protocol framework
> or a service specification? If it is a protocol framework, then the
> extension is in fact the service; which server to use and which port
> number to connect to will be determined by this service; negotiating the
> extension at this point does not make any sense.

I believe that you are proposing the use of multiple ports (one per service)
instead of performing capabilities exchange via the Extension-Id. If this is
the case, I would argue that ports are much more limited than extension-id,
but again I will listen to the WG.

> 
> 7) Host-IP-Address AVP in DRI command
> 
> What does that do in the presence of a NAT?

Historically this was useful for RADIUS servers, so we kept it. However, we
can do away with this AVP if you believe that it isn't necessary. For those
interested, this is used to know the IP address of the NAS. This is NOT used
to send, or validate received packets. It this required when a home domain
contacts an operator about a NAS that may be mis-behaving (or for accounting
purposes).

> 
> 8) and many more issues, but we will need more time...

Looking forward to them.

PatC




From owner-aaa-bof@merit.edu  Sat Apr  7 00:30:28 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA27779
	for <aaa-archive@odin.ietf.org>; Sat, 7 Apr 2001 00:30:27 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 0E8075DE0B; Fri,  6 Apr 2001 19:45:51 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id F0B725DDE0; Fri,  6 Apr 2001 19:45:50 -0400 (EDT)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id 9C9115DDB3
	for <aaa-wg@merit.edu>; Fri,  6 Apr 2001 19:45:49 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA21237;
	Fri, 6 Apr 2001 16:45:49 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA08584;
	Fri, 6 Apr 2001 16:45:48 -0700 (PDT)
Received: from darius (darius [10.6.84.105])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id QAA02485;
	Fri, 6 Apr 2001 16:45:44 -0700 (PDT)
Date: Fri, 6 Apr 2001 16:45:42 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Subject: [AAA-WG]: Latest I-Ds are now available
To: aaa-wg@merit.edu, diameter@diameter.org
Message-ID: <Roam.SIMC.2.0.6.986600742.24282.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

All,

I have just sent the following IDs to the secretariat for publication:

draft-ietf-aaa-diameter-02.txt
	This I-D now includes Accounting, and portions of the framework
	document, which the WG has decided we will let expire. It also
	contains all of the changes that have been discussed on the list,
	include a new state machine. Comments on the state machine would be
	most appreciated.

	Still pending is the text in section 7.0 (Transport Failure Detection).
	I am currently working the details out with Allison Mankin, and expect
	to have this text fixed up in version 3 of the ID.

	I do not believe that there are any pending issues with the base,
	except for Bernard's recent end-to-end capabilities exchange e-mail,
	which has never been a requirement until recently discussed.

draft-ietf-aaa-diameter-mobileip-02.txt
	This I-D includes many changes that have been discussed on the
	list, including co-located mobile node support. Accounting AVPs
	from the base have been pulled into this version, as well as
	the Filter-Rule AVP. See the archives for the list of changes,
	as they are quite great (or a good diff may help :).

draft-ietf-aaa-diameter-nasreq-02.txt
	This I-D includes mostly changes to accounting, and some of the AVPs
	from the base protocol were pulled into this spec (as discussed on the
	list). Some new AVPs from the RADIUS tunneling I-D had never made it
	to this document, and were added.

Although the documents have been sent to the secretariat, it does take a few
days for them to be available on the ftp servers, so a preview of the files
can be found at www.diameter.org.

Comments are appreciated,

PatC




From owner-aaa-bof@merit.edu  Sat Apr  7 16:19:08 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17732
	for <aaa-archive@odin.ietf.org>; Sat, 7 Apr 2001 16:19:08 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 8D1825DDB5; Sat,  7 Apr 2001 14:38:20 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 7C5785DDB0; Sat,  7 Apr 2001 14:38:20 -0400 (EDT)
Received: from gate.internaut.com (unknown [64.38.134.101])
	by segue.merit.edu (Postfix) with ESMTP id 8013C5DDA7
	for <aaa-wg@merit.edu>; Sat,  7 Apr 2001 14:38:18 -0400 (EDT)
Received: from e1kj2 (e1kj2 [64.38.134.109])
	by gate.internaut.com (8.10.2/8.10.2) with SMTP id f37IRgN23630;
	Sat, 7 Apr 2001 11:27:42 -0700
From: "Bernard Aboba" <aboba@internaut.com>
To: "Mark Jones" <mjones@bridgewatersystems.com>,
        "Fredrik Johansson" <fredrik.johansson@ipunplugged.com>,
        "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>
Cc: "David Spence" <DSpence@Interlinknetworks.com>, <aaa-wg@merit.edu>,
        <diameter@diameter.org>
Subject: RE: [diameter] RE: [AAA-WG]: Extensions & Framework (was: Diameter Issues found @ Connectathon)
Date: Sat, 7 Apr 2001 11:39:35 -0700
Message-ID: <OJEJKOMOEAKLMOILFCPJEEJFEFAA.aboba@internaut.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <001b01c0bde6$d75df280$2096a8c0@mjones.bridgewatersys.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

>> For proxying I would advertise wildcard, i.e. I'm willing to receive any
>> extension and try to find a peer to proxy it to. If a do not find
>> one, I'll
>> have to reply with a suitable error code.
>

>I understand but that would be your policy and I may implement a different
>one hoping to reduce the number of replies with errors. I don't think we
>should dictate this policy in the base protocol so I'm happy with the text
>in the current draft as is.

If possible, I think it would be desirable to at least articulate the range
of acceptable behaviors. 



From owner-aaa-bof@merit.edu  Sat Apr  7 18:02:30 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18223
	for <aaa-archive@odin.ietf.org>; Sat, 7 Apr 2001 18:02:30 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 5FEDE5DDD9; Sat,  7 Apr 2001 14:35:36 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 500545DDB5; Sat,  7 Apr 2001 14:35:36 -0400 (EDT)
Received: from gate.internaut.com (unknown [64.38.134.101])
	by segue.merit.edu (Postfix) with ESMTP id 1DDD65DDA7
	for <aaa-wg@merit.edu>; Sat,  7 Apr 2001 14:35:34 -0400 (EDT)
Received: from e1kj2 (e1kj2 [64.38.134.109])
	by gate.internaut.com (8.10.2/8.10.2) with SMTP id f37IP1N23511;
	Sat, 7 Apr 2001 11:25:01 -0700
From: "Bernard Aboba" <aboba@internaut.com>
To: "Randy Bush" <randy@psg.com>, "Glen Zorn" <gwz@cisco.com>
Cc: <aaa-wg@merit.edu>
Subject: RE: [AAA-WG]: Extensibility model and IANA considerations
Date: Sat, 7 Apr 2001 11:36:54 -0700
Message-ID: <OJEJKOMOEAKLMOILFCPJAEJFEFAA.aboba@internaut.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <E14lBb3-000GbP-00@rip.psg.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

>> But now (assuming that we do not, at this time, have knowledge of every
>> Diameter extension that will ever exist) we're back to updating the base
>> every time a new extension needs the 'M' bit set on an otherwise optional
>> AVP.

>this would seem to be the multiplicative intersection of two 'features',
>the base plus extensions approach, and mandatory extensions.

This is the nightmare scenario. Let's not go there if at all possible.





From owner-aaa-bof@merit.edu  Sat Apr  7 20:10:11 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA18715
	for <aaa-archive@odin.ietf.org>; Sat, 7 Apr 2001 20:10:09 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 3217A5DD96; Sat,  7 Apr 2001 20:09:52 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 1C6015DDD5; Sat,  7 Apr 2001 20:09:52 -0400 (EDT)
Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240])
	by segue.merit.edu (Postfix) with ESMTP id 863275DD96
	for <aaa-wg@merit.edu>; Sat,  7 Apr 2001 20:09:50 -0400 (EDT)
Received: from mr4u3.ericy.com (mr4u3.ericy.com [208.237.135.127])
	by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f3809nm25234;
	Sat, 7 Apr 2001 19:09:49 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179])
	by mr4u3.ericy.com (8.10.2/8.10.2) with ESMTP id f3809mx20114;
	Sat, 7 Apr 2001 19:09:48 -0500 (CDT)
Received: from pop.exu.ericsson.se (qpop [138.85.1.15]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id TAA11542; Sat, 7 Apr 2001 19:09:47 -0500 (CDT)
Received: from ericsson.com (tsgw1c021.exu.ericsson.se [138.85.130.21])
	by pop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id TAA05371;
	Sat, 7 Apr 2001 19:09:40 -0500 (CDT)
Message-ID: <3ACFAC37.B06D5CDC@ericsson.com>
Date: Sat, 07 Apr 2001 17:09:27 -0700
From: Tony Johansson <tony.johansson@ericsson.com>
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Fredrik Johansson <fredrik.johansson@ipunplugged.com>
Cc: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>,
        "'Patrice Calhoun'" <pcalhoun@nasnfs.Eng.Sun.COM>,
        AAA Listan <aaa-wg@merit.edu>
Subject: Re: [AAA-WG]: Previous-FA-XXXX AVP
References: <MJEMJBGGCLLDLFFAHLJKAEJKCJAA.fredrik.johansson@ipunplugged.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit



Fredrik Johansson wrote:

> >
> >
> >> >
> >> > This leads to a couple of questions:
> >> >
> >> > 1. How should the AAAF deal with the new Session-Id? The
> >> AAAH does not know
> >> > about new one in this case.
> >> >
> >> > One way of solving this could be to let the AAAF over write
> >> the new session
> >> > id and add on the initial session id into the Session-Id
> >> AVP in the reply
> >> > back to the new FA together FA-MN and FA-HA keys, and the
> >> > Authorization-Lifetime. Or maybe a new AVP for the initial
> >> session id is
> >> > needed...
> >>
> >> I think it would be much cleaner to have a new AVP, rather
> >> than the old one.
> >
> >Just to make sure, I guess you meant that
> >the Session-Id that has been authorized by the AAAH should
> >remain the valid Session-Id for the active MIP session, right?
> >Let's call "authorized Session-Id", the Session-Id that has
> >been officially authorized previously by the AAAH.
> >
> >Let's say that the MN moves to a new FA within
> >the same domain. When the AAAF receives a MIP Registration
> >from a MN, the message includes a MIP-Previous-FA-FQDN AVP,
> >which identifies the previous FA. It also includes the
> >User-Name AVP, which is supposed to be used for identifying
> >the FA-MN and FA-HA keys that need to be sent to MN.
> >That authorized Session-ID would be sent back to
> >the new FA in the AMA message from the AAAF, packaged in a new
> >"MIP-Previous-Session-ID" AVP. The new Session-ID would be just
> >ignored? I guess that the "authorized"
> >Session-ID could be kept in the AAAF, along with the FA-XX keys.
> >
> >Using that new AVP, it remains possible to support
> >roaming between FAs within the same domain without involving
> >unnecessarily the AAAH. Also, the accounting part is
> >not impacted at all, since the Session-Id remains the same.
> >No accounting start and stop are required, neither re-authentication
> >and re-generation of keys. I think that is a very efficient and
> >clean way of supporting it.
>
> Why don't you need to stop accounting? I agree that if you have accounting
> based on bytes or packets it is ok to let the timer expire in the FA, but if
> you have time based accounting you have to terminate the accounting session
> with the old FA otherwise it will overlap with the new FA's accounting
> session. It can also be solved in the server but I believe that it is more
> complicated for the server to keep track of what overlaps what instead of
> just terminating one session.

But is their anything in the specs that really prevents you from sending STI to
the old FA.
If you don't what to handle overlaps in your AAAF implementation?

>
> Another thing that needs some clarification, if there is a solution. How
> will the HA know which SA to use. In the case where a mobile moves from one
> Fa to another under the same administrative domain it may receive the
> session keys for the old Fa from the AAAF. It will then proceed to send the
> mip reg req to the HA. The HA will see that the message came from the new FA
> and try to locate the SA shared with that FA. It will not find it since it
> was established with the old FA. Eventhough the HA can see the address of
> the old Fa in the previous-fa-XXXX it is not clear that it can establish a
> SA with the new Fa because it has to use the same SPI as before and that one
> might be busy. Or have I missed something here?

You also have the user NAI in the MIP registration request sent to the HA and
the user NAI is globally unique....

BR,

/Tony





From owner-aaa-bof@merit.edu  Sun Apr  8 01:46:11 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA27542
	for <aaa-archive@odin.ietf.org>; Sun, 8 Apr 2001 01:46:11 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id EAB165DD91; Sat,  7 Apr 2001 14:34:24 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id CF5345DDA7; Sat,  7 Apr 2001 14:34:24 -0400 (EDT)
Received: from gate.internaut.com (unknown [64.38.134.101])
	by segue.merit.edu (Postfix) with ESMTP id 0C1025DD91
	for <aaa-wg@merit.edu>; Sat,  7 Apr 2001 14:34:23 -0400 (EDT)
Received: from e1kj2 (e1kj2 [64.38.134.109])
	by gate.internaut.com (8.10.2/8.10.2) with SMTP id f37INiN23438;
	Sat, 7 Apr 2001 11:23:44 -0700
From: "Bernard Aboba" <aboba@internaut.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>,
        "Mark Jones" <mjones@bridgewatersystems.com>
Cc: "Fredrik Johansson" <fredrik.johansson@ipunplugged.com>,
        "David Spence" <DSpence@Interlinknetworks.com>, <aaa-wg@merit.edu>,
        <diameter@diameter.org>
Subject: RE: [AAA-WG]: Extensions & Framework (was: Diameter Issues found @ Connectathon)
Date: Sat, 7 Apr 2001 11:35:37 -0700
Message-ID: <OJEJKOMOEAKLMOILFCPJMEJEEFAA.aboba@internaut.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
In-Reply-To: <Roam.SIMC.2.0.6.986484275.479.pcalhoun@nasnfs>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

>> The Extension-Id AVP as currently defined in the draft advertises locally
>> supported
>> extensions. Lets keep this definition and leave capability exchange in
proxy
>> scenarios as the subject of some future Enhanced Capability Exchange
>> extension.

>It has occured to me that this functionality could be piggy backed on top
of
>the E2E messages defined in the strong crypto I-D, with relative ease.

In general, it's desirable to avoid adding features to the spec, if
possible.
So first, I'd like to understand how the existing spec handles these kind
of situations. It seems to me that we have the following functionality:

1. The DRI message can negotiate capabilities when a connection starts up.
   This is useful so that peers can know each other's capabilities right
   from the start.

2. Error messages in the case where a client sends a command to a server
   that does not support it. For example, if a proxy advertises wildcard
   capabilities, but the DIAMETER server can't do MOBILEIP, then a NAS
   needing to use the MOBILEIP extension will receive an error back, right?

So my question has to do with the pros and cons of the existing
functionality
and how it is supposed to work. I think we could use some more language in
the spec, describing the capabilities negotiation functionality in more
detail.

For example, whether the error message returned to the NAS should
include the Extension-Id AVP, and what the NAS should do with such
an error message.







From owner-aaa-bof@merit.edu  Mon Apr  9 09:00:11 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA05099
	for <aaa-archive@odin.ietf.org>; Mon, 9 Apr 2001 09:00:11 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id C9DD15DDDF; Mon,  9 Apr 2001 08:58:47 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id B844F5DDA4; Mon,  9 Apr 2001 08:58:47 -0400 (EDT)
Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27])
	by segue.merit.edu (Postfix) with ESMTP id D8FBE5DDD7
	for <aaa-wg@merit.edu>; Mon,  9 Apr 2001 08:58:44 -0400 (EDT)
Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])
	by mgw-x4.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f39CxR820113
	for <aaa-wg@merit.edu>; Mon, 9 Apr 2001 15:59:27 +0300 (EET DST)
Received: from esebh25nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T52d02ce78aac158f24078@esvir04nok.ntc.nokia.com> for <aaa-wg@merit.edu>;
 Mon, 9 Apr 2001 15:58:42 +0300
Received: by esebh25nok with Internet Mail Service (5.5.2652.78)
	id <H9SAYSSS>; Mon, 9 Apr 2001 15:56:19 +0300
Message-ID: <6D1A8E7871B9D211B3B00008C7490AA504E6259B@treis03nok>
From: henry.haverinen@nokia.com
To: aaa-wg@merit.edu
Subject: [AAA-WG]: EAP-generated key distribution
Date: Mon, 9 Apr 2001 15:56:14 +0300 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk


Hi all,

I'd like to propose standardizing key distribution
DIAMETER/RADIUS attributes for session keys generated with
the Extensible Authentication Protocol (EAP), RFC 2284.

Some EAP authentication types are able to generate a session key
as part of the authentication procedure. The AAA server could
pass the key to the NAS so the client and NAS could use the key
locally. Such keys are especially useful with IEEE 802.1X.

While RFC2869 (informational) describes RADIUS attributes for EAP,
and draft-ietf-aaa-diameter-nasreq-01.txt contains the
same for DIAMETER, neither includes an attribute for
the EAP-generated key. (RFC2548 describes Microsoft vendor-
specific RADIUS extensions to carry the key.)

I think we should standardize such an attribute in the IETF.
For DIAMETER, an AVP could be included in the Diameter NASREQ
draft.

Bernard asked me to post this message to the list. He also
mentioned that DIAMETER already has several key distribution
attributes, and perhaps one of the existing ones could be added
to the Base protocol, thus making it available for all uses, rather
than adding yet another attribute.

Regards,
Henry



From owner-aaa-bof@merit.edu  Mon Apr  9 09:51:54 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06876
	for <aaa-archive@odin.ietf.org>; Mon, 9 Apr 2001 09:51:54 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 1FA335DDE3; Mon,  9 Apr 2001 09:51:36 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 0E3185DDA4; Mon,  9 Apr 2001 09:51:36 -0400 (EDT)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by segue.merit.edu (Postfix) with ESMTP id C1EBD5DD98
	for <aaa-wg@merit.edu>; Mon,  9 Apr 2001 09:51:33 -0400 (EDT)
Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f39DpWs18292
	for <aaa-wg@merit.edu>; Mon, 9 Apr 2001 15:51:32 +0200 (MEST)
Received: FROM esealnt742.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Mon Apr 09 15:51:25 2001 +0200
Received: by esealnt742.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <G9XBH690>; Mon, 9 Apr 2001 15:47:01 +0200
Message-ID: <79D18F182376D311856D0008C791A93904E4614A@esealnt407>
From: =?iso-8859-1?Q?Tomas_Goldbeck-L=F6we_=28ERA=29?= <Tomas.Goldbeck-Lowe@era.ericsson.se>
To: "'Tony Johansson'" <tony.johansson@ericsson.com>,
        Fredrik Johansson <fredrik.johansson@ipunplugged.com>
Cc: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>,
        "'Patrice Calhoun'" <pcalhoun@nasnfs.Eng.Sun.COM>,
        AAA Listan <aaa-wg@merit.edu>
Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
Date: Mon, 9 Apr 2001 15:51:22 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> >
> > Another thing that needs some clarification, if there is a 
> solution. How
> > will the HA know which SA to use. In the case where a 
> mobile moves from one
> > Fa to another under the same administrative domain it may 
> receive the
> > session keys for the old Fa from the AAAF. It will then 
> proceed to send the
> > mip reg req to the HA. The HA will see that the message 
> came from the new FA
> > and try to locate the SA shared with that FA. It will not 
> find it since it
> > was established with the old FA. Eventhough the HA can see 
> the address of
> > the old Fa in the previous-fa-XXXX it is not clear that it 
> can establish a
> > SA with the new Fa because it has to use the same SPI as 
> before and that one
> > might be busy. Or have I missed something here?
> 
> You also have the user NAI in the MIP registration request 
> sent to the HA and
> the user NAI is globally unique....
> 

...but the SA between the HA and the FA doesn't necessarily have to be connected to the user NAI.
I agree with Fredrik that this is an issue.

Regards,
	--> Tomas




From owner-aaa-bof@merit.edu  Mon Apr  9 09:57:48 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07006
	for <aaa-archive@odin.ietf.org>; Mon, 9 Apr 2001 09:57:47 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 561005DDE4; Mon,  9 Apr 2001 09:57:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 42BAD5DDA4; Mon,  9 Apr 2001 09:57:29 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id D70315DD98
	for <aaa-wg@merit.edu>; Mon,  9 Apr 2001 09:57:27 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA14508;
	Mon, 9 Apr 2001 06:57:09 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA02260;
	Mon, 9 Apr 2001 06:57:10 -0700 (PDT)
Received: from darius (darius [10.6.84.105])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id GAA26291;
	Mon, 9 Apr 2001 06:57:06 -0700 (PDT)
Date: Mon, 9 Apr 2001 06:57:05 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Subject: RE: [AAA-WG]: Extensions & Framework (was: Diameter Issues found @ Connectathon)
To: Bernard Aboba <aboba@internaut.com>
Cc: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>,
        Mark Jones <mjones@bridgewatersystems.com>,
        Fredrik Johansson <fredrik.johansson@ipunplugged.com>,
        David Spence <DSpence@Interlinknetworks.com>, aaa-wg@merit.edu,
        diameter@diameter.org
In-Reply-To: "Your message with ID" <OJEJKOMOEAKLMOILFCPJMEJEEFAA.aboba@internaut.com>
Message-ID: <Roam.SIMC.2.0.6.986824625.20327.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> In general, it's desirable to avoid adding features to the spec, if
> possible.

agreed.

> So first, I'd like to understand how the existing spec handles these kind
> of situations. It seems to me that we have the following functionality:
> 
> 1. The DRI message can negotiate capabilities when a connection starts up.
>    This is useful so that peers can know each other's capabilities right
>    from the start.

This is correct, but keep in mind that a few Diameter messages are *not*
proxiable, and DRI is one of them.

> 
> 2. Error messages in the case where a client sends a command to a server
>    that does not support it. For example, if a proxy advertises wildcard
>    capabilities, but the DIAMETER server can't do MOBILEIP, then a NAS
>    needing to use the MOBILEIP extension will receive an error back, right?

Correct, and this is returned as a per-hop error. So if the home server
returns such an error stating that it cannot support the extension, the
downstream proxy will attempt to re-route the message to another server within
the home domain. Of course, this isn't much of a problem because home servers
typically do not advertise wildcards. If no servers in the home domain can
support Mobile IP, then an error would be returned to the NAS.

Of course, should a proxy also be a home server, and advertise wildcard, then
it would receive a Mobile IP message, return a per-hop error, and the same
procedure as above would be followed.

So in the first case, since the home servers explicitely advertise support for
Mobile IP, there is no problem. In the latter case, it would require a
downstream proxy to send it to more than one server before finding a server
that supports Mobile IP.

Again, the protocol supports the first case very well, and the second is also
supported, but not as efficiently. This is a drawback from advertising
wildcard, but it doesn't break the protocol.

> 
> So my question has to do with the pros and cons of the existing
> functionality
> and how it is supposed to work. I think we could use some more language in
> the spec, describing the capabilities negotiation functionality in more
> detail.
> 
> For example, whether the error message returned to the NAS should
> include the Extension-Id AVP, and what the NAS should do with such
> an error message.

This language is already there, and doesn't belong in the capabilities
exchange, but rather in the hop-by-hop errors section (and is present in
section 9.0). Please let me know if additional language is required in that
section.

PatC




From owner-aaa-bof@merit.edu  Mon Apr  9 10:42:19 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07969
	for <aaa-archive@odin.ietf.org>; Mon, 9 Apr 2001 10:42:19 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 0A71C5DD98; Mon,  9 Apr 2001 10:42:01 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id D9E695DDA4; Mon,  9 Apr 2001 10:42:00 -0400 (EDT)
Received: from internaut.com (unknown [64.38.134.99])
	by segue.merit.edu (Postfix) with ESMTP id AA4245DD98
	for <aaa-wg@merit.edu>; Mon,  9 Apr 2001 10:41:58 -0400 (EDT)
Received: from localhost (aboba@localhost)
	by internaut.com (8.9.3/8.9.3) with ESMTP id HAA56075;
	Mon, 9 Apr 2001 07:36:10 -0700 (PDT)
	(envelope-from aboba@internaut.com)
Date: Mon, 9 Apr 2001 07:36:10 -0700 (PDT)
From: Bernard Aboba <aboba@internaut.com>
To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Cc: Mark Jones <mjones@bridgewatersystems.com>,
        Fredrik Johansson <fredrik.johansson@ipunplugged.com>,
        David Spence <DSpence@Interlinknetworks.com>, aaa-wg@merit.edu,
        diameter@diameter.org
Subject: RE: [AAA-WG]: Extensions & Framework (was: Diameter Issues found @
 Connectathon)
In-Reply-To: <Roam.SIMC.2.0.6.986824625.20327.pcalhoun@nasnfs>
Message-ID: <Pine.BSF.4.21.0104090729160.56060-100000@internaut.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> Correct, and this is returned as a per-hop error. So if the home server
> returns such an error stating that it cannot support the extension, the
> downstream proxy will attempt to re-route the message to another server within
> the home domain. 

I presume that the proxy would have used the DRI message in setting up
connections with the servers within the home domain, right? So presumably,
wouldn't it know what the capabilities were? I guess this might happen if
a connection weren't already up, in which case the proxy would have to
bring one up with the home domain. 

> So in the first case, since the home servers explicitely advertise support for
> Mobile IP, there is no problem. In the latter case, it would require a
> downstream proxy to send it to more than one server before finding a server
> that supports Mobile IP.

And if there is no server that supports Mobile IP, then an error is passed
back from the proxy to the NAS, right? Question: given that the proxy has
now investigated the capabilities of the domain in question, wouldn't it
be able to respond right away to future requests? How long do the
negotiated capabilities remain in effect? For the life of the
connection? Is there some TTL associated with them?

Also, does it make sense for the proxy to pass back to the NAS the list of
extensions that *are* supported within the domain in question? In other
words, should it pass back an Extension-Id AVP along with the error
message?

> This language is already there, and doesn't belong in the capabilities
> exchange, but rather in the hop-by-hop errors section (and is present in
> section 9.0). Please let me know if additional language is required in that
> section.

This is a case where there needs to be a section giving an overview of how
the protocol functions so that the behavior is described. You can leave
the detailed descriptions in individual sections if you like, but having
an overview somewhere would be helpful.




From owner-aaa-bof@merit.edu  Mon Apr  9 10:45:22 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08133
	for <aaa-archive@odin.ietf.org>; Mon, 9 Apr 2001 10:45:21 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id BB56F5DDF8; Mon,  9 Apr 2001 10:19:18 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id A8B475DDE8; Mon,  9 Apr 2001 10:19:18 -0400 (EDT)
Received: from cisco.com (titans.cisco.com [161.44.216.10])
	by segue.merit.edu (Postfix) with ESMTP id 5F5C25DD98
	for <aaa-wg@merit.edu>; Mon,  9 Apr 2001 10:19:16 -0400 (EDT)
Received: from knox6039 (knox6039.cisco.com [161.44.216.39])
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id KAA05434;
	Mon, 9 Apr 2001 10:19:01 -0400 (EDT)
Date: Mon, 9 Apr 2001 10:19:22 -0400 (EDT)
From: Mark Eklund <meklund@cisco.com>
X-Sender: meklund@knox6039
To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Cc: aaa-wg@merit.edu, diameter@diameter.org
Subject: Re: [AAA-WG]: Re: [diameter] Failed-AVP AVP
In-Reply-To: <Roam.SIMC.2.0.6.986567675.28403.pcalhoun@nasnfs>
Message-ID: <Pine.GSO.4.21.0104090952040.28483-100000@knox6039>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=iso-8859-1
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id KAA08133

Pat,

On Fri, 6 Apr 2001, Patrice Calhoun wrote:

<text elided>

> > 2. Wouldn't it make more sense for the Failed-AVP AVP be of type
> >    grouped?  In this way, the vendor will be included and
> >    standard packet facilities can be used to access the AVP.
> 
> This would be useful if many different Failed-AVPs needed to be returned, but
> I am not sure this would really happen. What does the WG think about this one??
>  PatC
> 

I was thinking that Grouped would be better suited for this than
Octetstring even if there were always only one AVP.  Here are my
reasons:

1. You get the Vendor-Id for free.

2. The Vendor-Id is associated with only one AVP.  For example,
   currently, if you have two Failed-AVPs and Failed-Vendor-Id
   AVPs in a packet, are both Failed-AVPs vendor specific, the
   one before the Failed-Vendor-Id, or the one after the
   Failed-Vender-Id??
 
3. Sniffer tools like ethereal understand the type Grouped
   and can dump the AVP and its contents easily.

4. You can use existing APIs to create the grouped AVP.  With
   Octetstring, you have to do an endian conversion before
   sending it.

5. If you are returning a DIAMETER_INVALID_AVP_VALUE, the
   offending value can easily be included.

-mark





From owner-aaa-bof@merit.edu  Mon Apr  9 10:50:17 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08371
	for <aaa-archive@odin.ietf.org>; Mon, 9 Apr 2001 10:50:17 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 9096A5DE16; Mon,  9 Apr 2001 10:01:13 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 7DCFD5DE12; Mon,  9 Apr 2001 10:01:13 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id 1DAC85DE0F
	for <aaa-wg@merit.edu>; Mon,  9 Apr 2001 10:01:12 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA16063;
	Mon, 9 Apr 2001 07:00:59 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA02786;
	Mon, 9 Apr 2001 07:00:56 -0700 (PDT)
Received: from darius (darius [10.6.84.105])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id HAA26354;
	Mon, 9 Apr 2001 07:00:51 -0700 (PDT)
Date: Mon, 9 Apr 2001 07:00:50 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Subject: RE: [diameter] RE: [AAA-WG]: Extensions & Framework (was: Diameter Issues found @ Connectathon)
To: Bernard Aboba <aboba@internaut.com>
Cc: Mark Jones <mjones@bridgewatersystems.com>,
        Fredrik Johansson <fredrik.johansson@ipunplugged.com>,
        Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>,
        David Spence <DSpence@Interlinknetworks.com>, aaa-wg@merit.edu,
        diameter@diameter.org
In-Reply-To: "Your message with ID" <OJEJKOMOEAKLMOILFCPJEEJFEFAA.aboba@internaut.com>
Message-ID: <Roam.SIMC.2.0.6.986824850.13566.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> >> For proxying I would advertise wildcard, i.e. I'm willing to receive any
> >> extension and try to find a peer to proxy it to. If a do not find
> >> one, I'll
> >> have to reply with a suitable error code.
> >
> 
> >I understand but that would be your policy and I may implement a different
> >one hoping to reduce the number of replies with errors. I don't think we
> >should dictate this policy in the base protocol so I'm happy with the text
> >in the current draft as is.
> 
> If possible, I think it would be desirable to at least articulate the range
> of acceptable behaviors. 

ok, but a possible problem comes to mind with the above. It is not possible to
know whether a particular server is the "home" server for a given domain. So
when caching such information, how do you know whether you are caching what
the next hop server has told you, or what it received from an upstream server?

So caching has its own problems, since it is possible for the next hop server
to have lost contact with a set of servers in the home domain, and caching
information locally will ensure that these new servers will never get to
provide services through the caching server.

So, unless it is possible to know whether a server is a home server or not,
caching is probably a bad idea.

PatC




From owner-aaa-bof@merit.edu  Mon Apr  9 11:21:42 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09148
	for <aaa-archive@odin.ietf.org>; Mon, 9 Apr 2001 11:21:41 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 43A415DDA4; Mon,  9 Apr 2001 11:20:36 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 2CE325DDE8; Mon,  9 Apr 2001 11:20:36 -0400 (EDT)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by segue.merit.edu (Postfix) with ESMTP id B261B5DDA4
	for <aaa-wg@merit.edu>; Mon,  9 Apr 2001 11:20:33 -0400 (EDT)
Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f39FKWs06296
	for <aaa-wg@merit.edu>; Mon, 9 Apr 2001 17:20:32 +0200 (MEST)
Received: FROM esealnt743.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Mon Apr 09 17:20:31 2001 +0200
Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <HA3DDKJD>; Mon, 9 Apr 2001 17:20:31 +0200
Message-ID: <577066326047D41180AC00508B955DDA01D7FF67@eestqnt104.es.eu.ericsson.se>
From: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>
To: "'Fredrik Johansson'" <fredrik.johansson@ipunplugged.com>,
        Tony Johansson <tony.johansson@ericsson.com>
Cc: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>,
        "'Patrice Calhoun'" <pcalhoun@nasnfs.Eng.Sun.COM>,
        AAA Listan <aaa-wg@merit.edu>
Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
Date: Mon, 9 Apr 2001 17:20:28 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> >>
> >> Another thing that needs some clarification, if there is a 
> solution. How
> >> will the HA know which SA to use. In the case where a mobile
> >moves from one
> >> Fa to another under the same administrative domain it may 
> receive the
> >> session keys for the old Fa from the AAAF. It will then proceed
> >to send the
> >> mip reg req to the HA. The HA will see that the message came
> >from the new FA
> >> and try to locate the SA shared with that FA. It will not find
> >it since it
> >> was established with the old FA. Eventhough the HA can see 
> the address of
> >> the old Fa in the previous-fa-XXXX it is not clear that it can
> >establish a
> >> SA with the new Fa because it has to use the same SPI as before
> >and that one
> >> might be busy. Or have I missed something here?
> >
> >You also have the user NAI in the MIP registration request sent to
> >the HA and
> >the user NAI is globally unique....
> 
> Yes, but this is not the security association shared with the 
> mobile node
> but the one shared between the FA and HA, thus has nothing to 
> do with the
> user.

I think you are assuming that there exists only 1 mobility SA between 
a FA and a HA for all the MIP sessions, right? When a first AMA is received
in the AAAH from a MN, is the AAAH supposed to issue a new registration
FA-HA key, in the case the HA is in the home domain? The spec says "yes",
if it is required by the MN. However, how can the MN know about the 
mobility SA between the FA and the HA? I guess it can not, which means 
that it will ask for a new key, which should be transferred to the FA and
the HA from the AAAH. Is there a way for the HA to notify the AAAH that it does not need
a new key and a new SPI for its mobility SA with the FA, since it already has one? I guess
not, right? Then, it looks like your idea could be very interesting, but
I don't know how to deal with it using Diameter, unless the AAAH and AAAF
would keep a list of mobility SAs between each FA and HA.

> You can not guarantee that a security between the HA and the old FA is
> unique between the HA and the new FA. The same SPI must be 
> used in the first
> request in order for the HA to be able to distinguise between 
> different
> security contexts it shares with the FA. What we can do is to 
> have the new
> FA add a <MIP-Preferred-SPI Ext> in the first request from 
> the new FA to the
> HA, the HA can then use the <Previous-FA-XXXX Ext> together 
> with the old SPI
> to retreive the context and store it under the Preferred SPI 
> under the SA
> with the new FA.

I was wondering whether or not a mobility SA between a FA 
and a HA was based on a particular MIP session? My understanding
_IS_ that an existing SA is based on a MIP session. That means
that between a FA and a HA, there exists several mobility SAs 
depending on each MIP session. By MIP session, I mean an AAA 
authorized session for MIP. The SPI is already included in the 
key transferred between the AAAF and the new FA. I don't see
why a HA could not use the SPI stored under its MN User-Name 
state to retrieve the mobility SA between the new FA and itself?

Regards,
Martin



From owner-aaa-bof@merit.edu  Mon Apr  9 12:16:34 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10515
	for <aaa-archive@odin.ietf.org>; Mon, 9 Apr 2001 12:16:34 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id E6F4C5DE00; Mon,  9 Apr 2001 10:46:06 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id D0A365DDFF; Mon,  9 Apr 2001 10:46:06 -0400 (EDT)
Received: from internaut.com (unknown [64.38.134.99])
	by segue.merit.edu (Postfix) with ESMTP id CD2635DDF4
	for <aaa-wg@merit.edu>; Mon,  9 Apr 2001 10:46:04 -0400 (EDT)
Received: from localhost (aboba@localhost)
	by internaut.com (8.9.3/8.9.3) with ESMTP id HAA56082;
	Mon, 9 Apr 2001 07:40:13 -0700 (PDT)
	(envelope-from aboba@internaut.com)
Date: Mon, 9 Apr 2001 07:40:13 -0700 (PDT)
From: Bernard Aboba <aboba@internaut.com>
To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Cc: Mark Jones <mjones@bridgewatersystems.com>,
        Fredrik Johansson <fredrik.johansson@ipunplugged.com>,
        David Spence <DSpence@Interlinknetworks.com>, aaa-wg@merit.edu,
        diameter@diameter.org
Subject: RE: [diameter] RE: [AAA-WG]: Extensions & Framework (was: Diameter
 Issues found @ Connectathon)
In-Reply-To: <Roam.SIMC.2.0.6.986824850.13566.pcalhoun@nasnfs>
Message-ID: <Pine.BSF.4.21.0104090736430.56060-100000@internaut.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> So caching has its own problems, since it is possible for the next hop server
> to have lost contact with a set of servers in the home domain, and caching
> information locally will ensure that these new servers will never get to
> provide services through the caching server.

Yes. If you cache you also need a TTL. 

The question is whether multiple transmissions are necessary each time you
have message with inappropriate capabilities. You could send a lot of
unnecessary traffic that way. Since proxies are already presumably
maintaining routing tables, one wonders if those tables might also not
contain capabilities for the domains in question.





From owner-aaa-bof@merit.edu  Mon Apr  9 13:04:28 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11892
	for <aaa-archive@odin.ietf.org>; Mon, 9 Apr 2001 13:04:28 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 8AC955DE45; Mon,  9 Apr 2001 13:02:13 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 789B05DE44; Mon,  9 Apr 2001 13:02:13 -0400 (EDT)
Received: from cisco.com (titans.cisco.com [161.44.216.10])
	by segue.merit.edu (Postfix) with ESMTP id 620005DE14
	for <aaa-wg@merit.edu>; Mon,  9 Apr 2001 13:02:11 -0400 (EDT)
Received: from knox6039 (knox6039.cisco.com [161.44.216.39])
	by cisco.com (8.8.8-Cisco List Logging/8.8.8) with ESMTP id NAA06835;
	Mon, 9 Apr 2001 13:01:27 -0400 (EDT)
Date: Mon, 9 Apr 2001 13:01:49 -0400 (EDT)
From: Mark Eklund <meklund@cisco.com>
X-Sender: meklund@knox6039
To: diameter@diameter.org, aaa-wg@merit.edu
Subject: [AAA-WG]: Tunnel-Medium-Type Cut and past error?
In-Reply-To: <Roam.SIMC.2.0.6.986600742.24282.pcalhoun@nasnfs>
Message-ID: <Pine.GSO.4.21.0104091257160.29379-100000@knox6039>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Section 7.4.2 of draft-ietf-aaa-diameter-nasreq-02.txt States
that Tunnel-Medium-Type AVP is of type Unsigned32, but later
says that the value field is three octets.  Is this a cut and
paste error?

7.4.2  Tunnel-Medium-Type AVP

   The Tunnel-Medium-Type AVP (AVP Code 65) is of type Unsigned32 and
   contains the transport medium to use when creating a tunnel for
   those protocols (such as L2TP) that can operate over multiple transports.
   It MAY be used in an authorization request as a hint to the server
   that a specific medium is desired, but the server is not required
   to honor the hint in the corresponding response.

   The Value field is three octets and contains one of the values
   listed under "Address Family Numbers" in [10]. The value of most
   importance is (1) for IPv4 and (2) for IPv6.

-mark








From owner-aaa-bof@merit.edu  Mon Apr  9 13:30:30 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12568
	for <aaa-archive@odin.ietf.org>; Mon, 9 Apr 2001 13:30:29 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 4478C5DDE5; Mon,  9 Apr 2001 10:23:34 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 3423E5DD98; Mon,  9 Apr 2001 10:23:34 -0400 (EDT)
Received: from mailgw.local.ipunplugged.com (unknown [213.88.134.217])
	by segue.merit.edu (Postfix) with ESMTP id CFD0D5DDA4
	for <aaa-wg@merit.edu>; Mon,  9 Apr 2001 10:23:31 -0400 (EDT)
Received: from fredrikj (c42.local.ipunplugged.com [192.168.4.241])
	by mailgw.local.ipunplugged.com (8.9.3/8.9.3) with SMTP id QAA27703;
	Mon, 9 Apr 2001 16:24:39 +0200
From: "Fredrik Johansson" <fredrik.johansson@ipunplugged.com>
To: "Tony Johansson" <tony.johansson@ericsson.com>
Cc: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>,
        "'Patrice Calhoun'" <pcalhoun@nasnfs.Eng.Sun.COM>,
        "AAA Listan" <aaa-wg@merit.edu>
Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
Date: Mon, 9 Apr 2001 16:25:13 +0200
Message-ID: <MJEMJBGGCLLDLFFAHLJKCELJCJAA.fredrik.johansson@ipunplugged.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <3ACFAC37.B06D5CDC@ericsson.com>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

>> >
>> >
>> >> >
>> >> > This leads to a couple of questions:
>> >> >
>> >> > 1. How should the AAAF deal with the new Session-Id? The
>> >> AAAH does not know
>> >> > about new one in this case.
>> >> >
>> >> > One way of solving this could be to let the AAAF over write
>> >> the new session
>> >> > id and add on the initial session id into the Session-Id
>> >> AVP in the reply
>> >> > back to the new FA together FA-MN and FA-HA keys, and the
>> >> > Authorization-Lifetime. Or maybe a new AVP for the initial
>> >> session id is
>> >> > needed...
>> >>
>> >> I think it would be much cleaner to have a new AVP, rather
>> >> than the old one.
>> >
>> >Just to make sure, I guess you meant that
>> >the Session-Id that has been authorized by the AAAH should
>> >remain the valid Session-Id for the active MIP session, right?
>> >Let's call "authorized Session-Id", the Session-Id that has
>> >been officially authorized previously by the AAAH.
>> >
>> >Let's say that the MN moves to a new FA within
>> >the same domain. When the AAAF receives a MIP Registration
>> >from a MN, the message includes a MIP-Previous-FA-FQDN AVP,
>> >which identifies the previous FA. It also includes the
>> >User-Name AVP, which is supposed to be used for identifying
>> >the FA-MN and FA-HA keys that need to be sent to MN.
>> >That authorized Session-ID would be sent back to
>> >the new FA in the AMA message from the AAAF, packaged in a new
>> >"MIP-Previous-Session-ID" AVP. The new Session-ID would be just
>> >ignored? I guess that the "authorized"
>> >Session-ID could be kept in the AAAF, along with the FA-XX keys.
>> >
>> >Using that new AVP, it remains possible to support
>> >roaming between FAs within the same domain without involving
>> >unnecessarily the AAAH. Also, the accounting part is
>> >not impacted at all, since the Session-Id remains the same.
>> >No accounting start and stop are required, neither re-authentication
>> >and re-generation of keys. I think that is a very efficient and
>> >clean way of supporting it.
>>
>> Why don't you need to stop accounting? I agree that if you have
>accounting
>> based on bytes or packets it is ok to let the timer expire in
>the FA, but if
>> you have time based accounting you have to terminate the
>accounting session
>> with the old FA otherwise it will overlap with the new FA's accounting
>> session. It can also be solved in the server but I believe that
>it is more
>> complicated for the server to keep track of what overlaps what instead of
>> just terminating one session.
>
>But is their anything in the specs that really prevents you from
>sending STI to
>the old FA.
>If you don't what to handle overlaps in your AAAF implementation?
>
>>
>> Another thing that needs some clarification, if there is a solution. How
>> will the HA know which SA to use. In the case where a mobile
>moves from one
>> Fa to another under the same administrative domain it may receive the
>> session keys for the old Fa from the AAAF. It will then proceed
>to send the
>> mip reg req to the HA. The HA will see that the message came
>from the new FA
>> and try to locate the SA shared with that FA. It will not find
>it since it
>> was established with the old FA. Eventhough the HA can see the address of
>> the old Fa in the previous-fa-XXXX it is not clear that it can
>establish a
>> SA with the new Fa because it has to use the same SPI as before
>and that one
>> might be busy. Or have I missed something here?
>
>You also have the user NAI in the MIP registration request sent to
>the HA and
>the user NAI is globally unique....

Yes, but this is not the security association shared with the mobile node
but the one shared between the FA and HA, thus has nothing to do with the
user.

You can not guarantee that a security between the HA and the old FA is
unique between the HA and the new FA. The same SPI must be used in the first
request in order for the HA to be able to distinguise between different
security contexts it shares with the FA. What we can do is to have the new
FA add a <MIP-Preferred-SPI Ext> in the first request from the new FA to the
HA, the HA can then use the <Previous-FA-XXXX Ext> together with the old SPI
to retreive the context and store it under the Preferred SPI under the SA
with the new FA.

/Fredrik

>
>BR,
>
>/Tony
>
>




From owner-aaa-bof@merit.edu  Mon Apr  9 13:38:23 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12789
	for <aaa-archive@odin.ietf.org>; Mon, 9 Apr 2001 13:38:23 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id D572A5DDF1; Mon,  9 Apr 2001 13:38:04 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id C1ADC5DE02; Mon,  9 Apr 2001 13:38:04 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id 92D7A5DDF1
	for <aaa-wg@merit.edu>; Mon,  9 Apr 2001 13:38:03 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA13655;
	Mon, 9 Apr 2001 10:38:00 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA13643;
	Mon, 9 Apr 2001 10:38:00 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (esun1as-be.Central.Sun.COM [129.147.34.142])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id KAA01082;
	Mon, 9 Apr 2001 10:37:22 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Message-Id: <200104091737.KAA01082@nasnfs.Eng.Sun.COM>
Date: Mon, 9 Apr 2001 11:33:33 -0700
To: "Mark Eklund" <meklund@cisco.com>, <aaa-wg@merit.edu>,
        <diameter@diameter.org>
Reply-To: <pcalhoun@eng.sun.com>
Subject: [AAA-WG]: Re: [diameter] Tunnel-Medium-Type Cut and past error?
X-Mailer: Sun NetMail 2.3
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

hmmm.... I will fix this one up in -03.

Thanks for the catch.

btw, I will be out of town for the rest of the week, back on Friday, and then
out for a much needed vacation the following week. So, if I do not respond to
comments on the list for the next couple of weeks, I will get to them as soon
as I get back. You are not being ignored. :)

PatC

>Section 7.4.2 of draft-ietf-aaa-diameter-nasreq-02.txt States
>that Tunnel-Medium-Type AVP is of type Unsigned32, but later
>says that the value field is three octets.  Is this a cut and
>paste error?
>
>7.4.2  Tunnel-Medium-Type AVP
>
>   The Tunnel-Medium-Type AVP (AVP Code 65) is of type Unsigned32 and
>   contains the transport medium to use when creating a tunnel for
>   those protocols (such as L2TP) that can operate over multiple transports.
>   It MAY be used in an authorization request as a hint to the server
>   that a specific medium is desired, but the server is not required
>   to honor the hint in the corresponding response.
>
>   The Value field is three octets and contains one of the values
>   listed under "Address Family Numbers" in [10]. The value of most
>   importance is (1) for IPv4 and (2) for IPv6.
>
>-mark
>
>
>
>
>





From owner-aaa-bof@merit.edu  Mon Apr  9 13:48:57 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13025
	for <aaa-archive@odin.ietf.org>; Mon, 9 Apr 2001 13:48:57 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id CB61F5DE0C; Mon,  9 Apr 2001 13:46:07 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id B82E65DE09; Mon,  9 Apr 2001 13:46:07 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id 46DD05DDE6
	for <aaa-wg@merit.edu>; Mon,  9 Apr 2001 13:46:06 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA18011;
	Mon, 9 Apr 2001 10:45:51 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA15530;
	Mon, 9 Apr 2001 10:45:48 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (esun1as-be.Central.Sun.COM [129.147.34.142])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id KAA01276;
	Mon, 9 Apr 2001 10:44:55 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Message-Id: <200104091744.KAA01276@nasnfs.Eng.Sun.COM>
Date: Mon, 9 Apr 2001 11:41:22 -0700
To: "Bernard Aboba" <aboba@internaut.com>,
        "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>
Cc: <diameter@diameter.org>, <aaa-wg@merit.edu>,
        "David Spence" <DSpence@Interlinknetworks.com>,
        "Fredrik Johansson" <fredrik.johansson@ipunplugged.com>,
        "Mark Jones" <mjones@bridgewatersystems.com>
Reply-To: <pcalhoun@eng.sun.com>
Subject: RE: [diameter] RE: [AAA-WG]: Extensions & Framework (was: Diameter Issues found @ Connectathon)
X-Mailer: Sun NetMail 2.3
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit


>> So caching has its own problems, since it is possible for the next hop server
>> to have lost contact with a set of servers in the home domain, and caching
>> information locally will ensure that these new servers will never get to
>> provide services through the caching server.
>
>Yes. If you cache you also need a TTL. 
>
>The question is whether multiple transmissions are necessary each time you
>have message with inappropriate capabilities. You could send a lot of
>unnecessary traffic that way. Since proxies are already presumably
>maintaining routing tables, one wonders if those tables might also not
>contain capabilities for the domains in question.
>
Which only works if the next hop is the home domain. So perhaps a new AVP is
required so a server can state what it's home domain(s) are. This would allow
a server to know if the next hop is the home server, and it could then cache.

This would allow the protocol to operate when there is a more complex proxy
chain.

PatC




From owner-aaa-bof@merit.edu  Mon Apr  9 13:51:01 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13059
	for <aaa-archive@odin.ietf.org>; Mon, 9 Apr 2001 13:51:00 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id D80AB5DDE6; Mon,  9 Apr 2001 13:50:42 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id C07325DE03; Mon,  9 Apr 2001 13:50:42 -0400 (EDT)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id 310E35DDE6
	for <aaa-wg@merit.edu>; Mon,  9 Apr 2001 13:50:41 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA22904;
	Mon, 9 Apr 2001 10:50:32 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA16672;
	Mon, 9 Apr 2001 10:50:32 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (esun1as-be.Central.Sun.COM [129.147.34.142])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id KAA01365;
	Mon, 9 Apr 2001 10:49:35 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Message-Id: <200104091749.KAA01365@nasnfs.Eng.Sun.COM>
Date: Mon, 9 Apr 2001 11:46:05 -0700
To: "Bernard Aboba" <aboba@internaut.com>,
        "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>
Cc: <diameter@diameter.org>, <aaa-wg@merit.edu>,
        "David Spence" <DSpence@Interlinknetworks.com>,
        "Fredrik Johansson" <fredrik.johansson@ipunplugged.com>,
        "Mark Jones" <mjones@bridgewatersystems.com>
Reply-To: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Extensions & Framework (was: Diameter Issues found @ Connectathon)
X-Mailer: Sun NetMail 2.3
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit


>> Correct, and this is returned as a per-hop error. So if the home server
>> returns such an error stating that it cannot support the extension, the
>> downstream proxy will attempt to re-route the message to another server
>within
>> the home domain. 
>
>I presume that the proxy would have used the DRI message in setting up
>connections with the servers within the home domain, right? So presumably,
>wouldn't it know what the capabilities were? I guess this might happen if
>a connection weren't already up, in which case the proxy would have to
>bring one up with the home domain. 

I *think* I understand the confusion. A DRI is a non-proxiable message. It is
hop-by-hop. So it is only received/processed by the home domain if the next
hop *is* the home domain.

>
>> So in the first case, since the home servers explicitely advertise support
>for
>> Mobile IP, there is no problem. In the latter case, it would require a
>> downstream proxy to send it to more than one server before finding a server
>> that supports Mobile IP.
>
>And if there is no server that supports Mobile IP, then an error is passed
>back from the proxy to the NAS, right?

yes.

> Question: given that the proxy has
>now investigated the capabilities of the domain in question, wouldn't it
>be able to respond right away to future requests? How long do the
>negotiated capabilities remain in effect? For the life of the
>connection? Is there some TTL associated with them?

Again, this is *only* valid if the home server *is* the next hop. You cannot 
cache if there are many hops since you could cache invalid data (e.g. perhaps
the mobile ip server was temporarily down, so a proxy had to return an error
to the upstream proxy). A request 10 seconds later could be completed since
perhaps the server would be back online.

>
>Also, does it make sense for the proxy to pass back to the NAS the list of
>extensions that *are* supported within the domain in question? In other
>words, should it pass back an Extension-Id AVP along with the error
>message?

well we could, but we've never done that before, and extensions MAY be supported
by different servers. So how would you return the list? A concatenated list of
all servers in the home domain? Do you have an association with all servers in
the home domain.

I think that what you are describing here is not really worth the cost.

>
>> This language is already there, and doesn't belong in the capabilities
>> exchange, but rather in the hop-by-hop errors section (and is present in
>> section 9.0). Please let me know if additional language is required in that
>> section.
>
>This is a case where there needs to be a section giving an overview of how
>the protocol functions so that the behavior is described. You can leave
>the detailed descriptions in individual sections if you like, but having
>an overview somewhere would be helpful.

ok, I will add two new sections in the Protocol Overview section; end-to-end
and hop-by-hop behaviors.

PatC




From owner-aaa-bof@merit.edu  Mon Apr  9 15:23:09 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14667
	for <aaa-archive@odin.ietf.org>; Mon, 9 Apr 2001 15:23:08 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id D153B5DE0E; Mon,  9 Apr 2001 15:22:51 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id BEA115DE0A; Mon,  9 Apr 2001 15:22:51 -0400 (EDT)
Received: from balinese.baltimore.ie (pc215-8.indigo.ie [194.125.215.8])
	by segue.merit.edu (Postfix) with ESMTP id 9312F5DE03
	for <aaa-wg@merit.edu>; Mon,  9 Apr 2001 15:22:49 -0400 (EDT)
Received: by balinese.baltimore.ie; id UAA14797; Mon, 9 Apr 2001 20:22:48 +0100 (GMT/IST)
Received: from emeairlsw1.ie.baltimore.com(10.153.25.53) by balinese.baltimore.ie via smap (V4.2)
	id xma014794; Mon, 9 Apr 01 20:22:38 +0100
Received: from bobcat.baltimore.ie (bobcat.ie.baltimore.com) by emeairlsw1.baltimore.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T52d11d93300a99193515a@emeairlsw1.baltimore.com>;
 Mon, 9 Apr 2001 20:21:34 +0100
Received: from baltimore.ie (wks114-25.ie.baltimore.com [10.153.25.114])
	by bobcat.baltimore.ie (8.9.3/8.9.3) with ESMTP id UAA24378;
	Mon, 9 Apr 2001 20:25:03 +0100
Message-ID: <3AD20A38.FA7C89B4@baltimore.ie>
Date: Mon, 09 Apr 2001 20:15:04 +0100
From: Stephen Farrell <stephen.farrell@baltimore.ie>
Reply-To: stephen.farrell@baltimore.ie
Organization: Baltimore Technologies Ltd.
X-Mailer: Mozilla 4.72 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Bernard Aboba <aboba@internaut.com>
Cc: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>, aaa-wg@merit.edu
Subject: Re: [AAA-WG]: Re: e2e security and/or proxies
References: <OJEJKOMOEAKLMOILFCPJMEGOEFAA.aboba@internaut.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit


Bernard,

Taking the hint...within the next two weeks.

Stephen.

Bernard Aboba wrote:
> 
> >> Another problem is where along a chain of proxies policy can change
> >> the values of what attributes.
> 
> >Yes, but doesn't draft-calhoun-diameter-strong-crypto-07.txt
> >solve these issues?
> 
> I certainly hope so.
> 
> Stephen -- any ETA for the next version of the strong crypto spec? (hint,
> hint)

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:stephen.farrell@baltimore.ie
Ireland                             http://www.baltimore.com




From owner-aaa-bof@merit.edu  Mon Apr  9 16:45:23 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA16749
	for <aaa-archive@odin.ietf.org>; Mon, 9 Apr 2001 16:45:22 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 834915DEEA; Mon,  9 Apr 2001 16:20:18 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 3FC085DED7; Mon,  9 Apr 2001 16:19:26 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by segue.merit.edu (Postfix) with ESMTP id A31315DE83
	for <aaa-wg@merit.edu>; Mon,  9 Apr 2001 16:19:17 -0400 (EDT)
Received: from mira-sjcm-3.cisco.com (mira-sjcm-3.cisco.com [171.69.43.101])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id NAA06872;
	Mon, 9 Apr 2001 13:18:44 -0700 (PDT)
Received: from johnalw2k (dhcp-161-44-29-177.cisco.com [161.44.29.177])
	by mira-sjcm-3.cisco.com (Mirapoint)
	with SMTP id ABS13935;
	Mon, 9 Apr 2001 13:18:41 -0700 (PDT)
From: "John Alayari" <johnal@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>,
        <diameter@diameter.org>
Subject: [AAA-WG]: Peer State Machine, closed state
Date: Mon, 9 Apr 2001 13:17:45 -0700
Message-ID: <CNEGKCBENOKKPJPNCEODAEEMCCAA.johnal@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <Roam.SIMC.2.0.6.986600742.24282.pcalhoun@nasnfs>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Pat, 

This is my comment on the peer state machine in the -02 version:

The current state machine is:
-----------------------------
Closed           Start            I-Snd-Conn-Req   Wait-Conn-Ack
                 R-Rcv-Conn-Req   I-Snd-Conn-Ack   Wait-R-DRI 

Shouldn't it be? 
---------------
Closed           Start            I-Snd-Conn-Req   Wait-Conn-Ack
                 I-Rcv-Conn-Req   I-Snd-Conn-Ack   Wait-I-DRI
                 R-Rcv-Conn-Req   R-Snd-Conn-Ack   Wait-R-DRI

John





From owner-aaa-bof@merit.edu  Mon Apr  9 20:16:04 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20192
	for <aaa-archive@odin.ietf.org>; Mon, 9 Apr 2001 20:16:02 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 1500B5DF3B; Mon,  9 Apr 2001 20:15:00 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id D28325DF8B; Mon,  9 Apr 2001 20:12:07 -0400 (EDT)
Received: from imr2.ericy.com (unknown [12.34.240.68])
	by segue.merit.edu (Postfix) with ESMTP id 1D2E05DFEC
	for <aaa-wg@merit.edu>; Mon,  9 Apr 2001 19:50:19 -0400 (EDT)
Received: from mr3.exu.ericsson.se (mr3att.ericy.com [138.85.92.10])
	by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f39Nnj811269;
	Mon, 9 Apr 2001 18:49:45 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179])
	by mr3.exu.ericsson.se (8.10.2/8.10.2) with ESMTP id f39Nnjo19945;
	Mon, 9 Apr 2001 18:49:45 -0500 (CDT)
Received: from pop.exu.ericsson.se (qpop [138.85.1.15]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id SAA04748; Mon, 9 Apr 2001 18:49:40 -0500 (CDT)
Received: from ericsson.com (busam52.berkeley.us.am.ericsson.se [138.85.159.202])
	by pop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id SAA03030;
	Mon, 9 Apr 2001 18:49:32 -0500 (CDT)
Message-ID: <3AD24A7E.326636EC@ericsson.com>
Date: Mon, 09 Apr 2001 16:49:18 -0700
From: Tony Johansson <tony.johansson@ericsson.com>
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: aaa-wg@merit.edu
Cc: diameter@diameter.org, Connie.Tran@am1.ericsson.se
Subject: [AAA-WG]: Diameter interop testing event (bake off)
Content-Type: multipart/alternative;
 boundary="------------2CBF5CB4B43C5A0CDDFB52A1"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk


--------------2CBF5CB4B43C5A0CDDFB52A1
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

All,

Here is the official invitation to a new Diameter interoperability
testing event (bake off).


   * Location: Ericsson Research, 2100 Shattuck Ave, Berkeley,
     California.

   * Date: The first week of October (10/1/01-10/5/01).

   * No Fee, but the registration is binding.

Network info:
The interop test network is a 10/100baseT network that will only support
one or two drops from each test booth, so you will have to bring your
own 10/100baseT hubs / switches. Limited Internet connections will also
be available.

Test Suite:
We will put together a Diameter test suite and send it out to all the
participants later on.

How to register:
Please send a mailto:Connie.Tran@am1.ericsson.se with the following:
- Company name or organization.
- Names of paticipants.
- Primary contact person and phone number/e-mail.
- Any specific requirements needed (we can't guarantee specific
accomodations, but we will make an attempt).


BR,

/Tony


--------------2CBF5CB4B43C5A0CDDFB52A1
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
All,
<p>Here is the official invitation to a new Diameter interoperability testing
event (bake off).
<br>&nbsp;
<ul>
<li>
Location: Ericsson Research, 2100 Shattuck Ave, Berkeley, California.</li>
</ul>

<ul>
<li>
Date: The first week of October (10/1/01-10/5/01).</li>
</ul>

<ul>
<li>
No Fee, but the registration is binding.</li>
</ul>

<p><br>Network info:
<br>The interop test network is a 10/100baseT network that will only support
one or two drops from each test booth, so you will have to bring your own
10/100baseT hubs / switches. Limited Internet connections will also be
available.
<p>Test Suite:
<br>We will put together a Diameter test suite and send it out to all the
participants later on.
<p>How to register:
<br>Please send a <A HREF="mailto:Connie.Tran@am1.ericsson.se">mailto:Connie.Tran@am1.ericsson.se</A> with the following:
<br>- Company name or organization.
<br>- Names of paticipants.
<br>- Primary contact person and phone number/e-mail.
<br>- Any specific requirements needed (we can't guarantee specific accomodations,
but we will make an attempt).
<br>&nbsp;
<p>BR,
<p>/Tony
<br>&nbsp;</html>

--------------2CBF5CB4B43C5A0CDDFB52A1--




From owner-aaa-bof@merit.edu  Tue Apr 10 02:38:31 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA08819
	for <aaa-archive@odin.ietf.org>; Tue, 10 Apr 2001 02:38:31 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 128E75DE0A; Tue, 10 Apr 2001 02:38:14 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id EA7985DDFE; Tue, 10 Apr 2001 02:38:13 -0400 (EDT)
Received: from mailgw.local.ipunplugged.com (unknown [213.88.134.217])
	by segue.merit.edu (Postfix) with ESMTP id 82D655DDD2
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 02:38:11 -0400 (EDT)
Received: from fredrikj (c42.local.ipunplugged.com [192.168.4.241])
	by mailgw.local.ipunplugged.com (8.9.3/8.9.3) with SMTP id IAA06463;
	Tue, 10 Apr 2001 08:39:22 +0200
From: "Fredrik Johansson" <fredrik.johansson@ipunplugged.com>
To: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>,
        "Tony Johansson" <tony.johansson@ericsson.com>
Cc: "'Patrice Calhoun'" <pcalhoun@nasnfs.Eng.Sun.COM>,
        "AAA Listan" <aaa-wg@merit.edu>
Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
Date: Tue, 10 Apr 2001 08:39:57 +0200
Message-ID: <MJEMJBGGCLLDLFFAHLJKAEMKCJAA.fredrik.johansson@ipunplugged.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <577066326047D41180AC00508B955DDA01D7FF67@eestqnt104.es.eu.ericsson.se>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

>
>> >>
>> >> Another thing that needs some clarification, if there is a
>> solution. How
>> >> will the HA know which SA to use. In the case where a mobile
>> >moves from one
>> >> Fa to another under the same administrative domain it may
>> receive the
>> >> session keys for the old Fa from the AAAF. It will then proceed
>> >to send the
>> >> mip reg req to the HA. The HA will see that the message came
>> >from the new FA
>> >> and try to locate the SA shared with that FA. It will not find
>> >it since it
>> >> was established with the old FA. Eventhough the HA can see
>> the address of
>> >> the old Fa in the previous-fa-XXXX it is not clear that it can
>> >establish a
>> >> SA with the new Fa because it has to use the same SPI as before
>> >and that one
>> >> might be busy. Or have I missed something here?
>> >
>> >You also have the user NAI in the MIP registration request sent to
>> >the HA and
>> >the user NAI is globally unique....
>>
>> Yes, but this is not the security association shared with the
>> mobile node
>> but the one shared between the FA and HA, thus has nothing to
>> do with the
>> user.
>
>I think you are assuming that there exists only 1 mobility SA between
>a FA and a HA for all the MIP sessions, right?

YES, one mobility SA, ceveral security context within a mobility SA. See rfc
2002,

"Mobility Security Association
               A collection of security contexts, between a pair
               of nodes, which may be applied to Mobile IP protocol
               messages exchanged between them.  Each context indicates
               an authentication algorithm and mode (Section 5.1), a
               secret (a shared key, or appropriate public/private
               key pair), and a style of replay protection in use
               (Section 5.6)."

Each context is indexed with a unique SPI within that SA, if there exist a
SA between the HA and the old FA and one SA between the HA and the new FA
there might exist security context with the same SPI in both of these.

"Security Parameter Index (SPI)
               An index identifying a security context between a pair
               of nodes among the contexts available in the Mobility
               Security Association.  SPI values 0 through 255 are
               reserved and MUST NOT be used in any Mobility Security
               Association."

>When a first AMA is received

I guess you mean AMR :-)

>in the AAAH from a MN, is the AAAH supposed to issue a new registration
>FA-HA key, in the case the HA is in the home domain? The spec says "yes",
>if it is required by the MN. However, how can the MN know about the
>mobility SA between the FA and the HA? I guess it can not, which means
>that it will ask for a new key, which should be transferred to the FA and
>the HA from the AAAH. Is there a way for the HA to notify the AAAH
>that it does not need
>a new key and a new SPI for its mobility SA with the FA, since it
>already has one? I guess
>not, right? Then, it looks like your idea could be very interesting, but
>I don't know how to deal with it using Diameter, unless the AAAH and AAAF
>would keep a list of mobility SAs between each FA and HA.

In some way the AAAH must keep track of what SPIs it has assigned to the
home agent, if it does it per SA or make the SPI unique over all SA's in the
HA is up to the implementation

>
>> You can not guarantee that a security between the HA and the old FA is
>> unique between the HA and the new FA. The same SPI must be
>> used in the first
>> request in order for the HA to be able to distinguise between
>> different
>> security contexts it shares with the FA. What we can do is to
>> have the new
>> FA add a <MIP-Preferred-SPI Ext> in the first request from
>> the new FA to the
>> HA, the HA can then use the <Previous-FA-XXXX Ext> together
>> with the old SPI
>> to retreive the context and store it under the Preferred SPI
>> under the SA
>> with the new FA.
>
>I was wondering whether or not a mobility SA between a FA
>and a HA was based on a particular MIP session? My understanding
>_IS_ that an existing SA is based on a MIP session. That means
>that between a FA and a HA, there exists several mobility SAs
>depending on each MIP session.

No, there is only one SA between two nodes, but there are several security
context within each SA. Each security context can corresponde to a mip
session. It is the security context that has a lifetime, the SA can be
removed when the last security context is removed.

>By MIP session, I mean an AAA
>authorized session for MIP. The SPI is already included in the
>key transferred between the AAAF and the new FA. I don't see
>why a HA could not use the SPI stored under its MN User-Name
>state to retrieve the mobility SA between the new FA and itself?

Because the SA between the FA and HA does not realy have anything to do with
the Mn. It is something setup between the FA and HA. Thus when the HA will
look for the key to use it will do the lookup on the FA address.

/Fredrik

>
>Regards,
>Martin




From owner-aaa-bof@merit.edu  Tue Apr 10 04:25:32 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA09689
	for <aaa-archive@odin.ietf.org>; Tue, 10 Apr 2001 04:25:32 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 1660B5DE14; Tue, 10 Apr 2001 04:25:15 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 05AFF5DE11; Tue, 10 Apr 2001 04:25:14 -0400 (EDT)
Received: from mailgw.local.ipunplugged.com (unknown [213.88.134.217])
	by segue.merit.edu (Postfix) with ESMTP id F183F5DDB3
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 04:25:11 -0400 (EDT)
Received: from fredrikj (c42.local.ipunplugged.com [192.168.4.241])
	by mailgw.local.ipunplugged.com (8.9.3/8.9.3) with SMTP id KAA07981;
	Tue, 10 Apr 2001 10:26:26 +0200
From: "Fredrik Johansson" <fredrik.johansson@ipunplugged.com>
To: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>,
        "Tony Johansson" <tony.johansson@ericsson.com>
Cc: "'Patrice Calhoun'" <pcalhoun@nasnfs.Eng.Sun.COM>,
        "AAA Listan" <aaa-wg@merit.edu>
Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
Date: Tue, 10 Apr 2001 10:27:01 +0200
Message-ID: <MJEMJBGGCLLDLFFAHLJKGEMNCJAA.fredrik.johansson@ipunplugged.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <MJEMJBGGCLLDLFFAHLJKAEMKCJAA.fredrik.johansson@ipunplugged.com>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

After a closer look at the problem we have a suggestion on a solution.
If the AAAH always assigns a SPI that is unique in the HA for the FA-HA key,
and a SPI that is unique in the Mn for the MN-FA and MN-HA keys, the
security contexts will automatically be unique in every SA.

7.5 SPI Allocation
  To ensure that the SPI is unique for each pair of nodes,
  the AAAH SHOULD keep track of assigned SPIs per HA and MN.
  The SPI assigned to the MN-FA key MUST be allocated from the MN SPI pool,
  the SPI for the FA-HA key MUST be allocated from the HA SPI pool, and the
  SPI for the MN-HA key MUST be allocated from the MN SPI pool. Note that
  SPI values 0 through 255 are reserved and MUST NOT be used in any
  Mobility Security Association.

/Fredrik
>-----Original Message-----
>From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf
>Of Fredrik Johansson
>Sent: den 10 april 2001 08:40
>To: Martin Julien (ECE); Tony Johansson
>Cc: 'Patrice Calhoun'; AAA Listan
>Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
>
>
>>
>>> >>
>>> >> Another thing that needs some clarification, if there is a
>>> solution. How
>>> >> will the HA know which SA to use. In the case where a mobile
>>> >moves from one
>>> >> Fa to another under the same administrative domain it may
>>> receive the
>>> >> session keys for the old Fa from the AAAF. It will then proceed
>>> >to send the
>>> >> mip reg req to the HA. The HA will see that the message came
>>> >from the new FA
>>> >> and try to locate the SA shared with that FA. It will not find
>>> >it since it
>>> >> was established with the old FA. Eventhough the HA can see
>>> the address of
>>> >> the old Fa in the previous-fa-XXXX it is not clear that it can
>>> >establish a
>>> >> SA with the new Fa because it has to use the same SPI as before
>>> >and that one
>>> >> might be busy. Or have I missed something here?
>>> >
>>> >You also have the user NAI in the MIP registration request sent to
>>> >the HA and
>>> >the user NAI is globally unique....
>>>
>>> Yes, but this is not the security association shared with the
>>> mobile node
>>> but the one shared between the FA and HA, thus has nothing to
>>> do with the
>>> user.
>>
>>I think you are assuming that there exists only 1 mobility SA between
>>a FA and a HA for all the MIP sessions, right?
>
>YES, one mobility SA, ceveral security context within a mobility
>SA. See rfc
>2002,
>
>"Mobility Security Association
>               A collection of security contexts, between a pair
>               of nodes, which may be applied to Mobile IP protocol
>               messages exchanged between them.  Each context indicates
>               an authentication algorithm and mode (Section 5.1), a
>               secret (a shared key, or appropriate public/private
>               key pair), and a style of replay protection in use
>               (Section 5.6)."
>
>Each context is indexed with a unique SPI within that SA, if there exist a
>SA between the HA and the old FA and one SA between the HA and the new FA
>there might exist security context with the same SPI in both of these.
>
>"Security Parameter Index (SPI)
>               An index identifying a security context between a pair
>               of nodes among the contexts available in the Mobility
>               Security Association.  SPI values 0 through 255 are
>               reserved and MUST NOT be used in any Mobility Security
>               Association."
>
>>When a first AMA is received
>
>I guess you mean AMR :-)
>
>>in the AAAH from a MN, is the AAAH supposed to issue a new registration
>>FA-HA key, in the case the HA is in the home domain? The spec says "yes",
>>if it is required by the MN. However, how can the MN know about the
>>mobility SA between the FA and the HA? I guess it can not, which means
>>that it will ask for a new key, which should be transferred to the FA and
>>the HA from the AAAH. Is there a way for the HA to notify the AAAH
>>that it does not need
>>a new key and a new SPI for its mobility SA with the FA, since it
>>already has one? I guess
>>not, right? Then, it looks like your idea could be very interesting, but
>>I don't know how to deal with it using Diameter, unless the AAAH and AAAF
>>would keep a list of mobility SAs between each FA and HA.
>
>In some way the AAAH must keep track of what SPIs it has assigned to the
>home agent, if it does it per SA or make the SPI unique over all
>SA's in the
>HA is up to the implementation
>
>>
>>> You can not guarantee that a security between the HA and the old FA is
>>> unique between the HA and the new FA. The same SPI must be
>>> used in the first
>>> request in order for the HA to be able to distinguise between
>>> different
>>> security contexts it shares with the FA. What we can do is to
>>> have the new
>>> FA add a <MIP-Preferred-SPI Ext> in the first request from
>>> the new FA to the
>>> HA, the HA can then use the <Previous-FA-XXXX Ext> together
>>> with the old SPI
>>> to retreive the context and store it under the Preferred SPI
>>> under the SA
>>> with the new FA.
>>
>>I was wondering whether or not a mobility SA between a FA
>>and a HA was based on a particular MIP session? My understanding
>>_IS_ that an existing SA is based on a MIP session. That means
>>that between a FA and a HA, there exists several mobility SAs
>>depending on each MIP session.
>
>No, there is only one SA between two nodes, but there are several security
>context within each SA. Each security context can corresponde to a mip
>session. It is the security context that has a lifetime, the SA can be
>removed when the last security context is removed.
>
>>By MIP session, I mean an AAA
>>authorized session for MIP. The SPI is already included in the
>>key transferred between the AAAF and the new FA. I don't see
>>why a HA could not use the SPI stored under its MN User-Name
>>state to retrieve the mobility SA between the new FA and itself?
>
>Because the SA between the FA and HA does not realy have anything
>to do with
>the Mn. It is something setup between the FA and HA. Thus when the HA will
>look for the key to use it will do the lookup on the FA address.
>
>/Fredrik
>
>>
>>Regards,
>>Martin
>




From owner-aaa-bof@merit.edu  Tue Apr 10 05:13:06 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA09980
	for <aaa-archive@odin.ietf.org>; Tue, 10 Apr 2001 05:13:06 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id C523C5DDB3; Tue, 10 Apr 2001 05:12:48 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id B1DAA5DE11; Tue, 10 Apr 2001 05:12:48 -0400 (EDT)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by segue.merit.edu (Postfix) with ESMTP id D8A085DDB3
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 05:12:15 -0400 (EDT)
Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f3A9CEI08869
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 11:12:14 +0200 (MEST)
Received: FROM esealnt743.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Tue Apr 10 11:12:04 2001 +0200
Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <HA3DD7DD>; Tue, 10 Apr 2001 11:12:04 +0200
Message-ID: <577066326047D41180AC00508B955DDA01D7FF6C@eestqnt104.es.eu.ericsson.se>
From: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>
To: "'Fredrik Johansson'" <fredrik.johansson@ipunplugged.com>,
        "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>,
        Tony Johansson <tony.johansson@ericsson.com>
Cc: "'Patrice Calhoun'" <pcalhoun@nasnfs.Eng.Sun.COM>,
        AAA Listan <aaa-wg@merit.edu>
Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
Date: Tue, 10 Apr 2001 11:10:19 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Cool! I was about to send you something very similar to know
if it was what you meant in your previous mail. 
I agree with your solution. Thanks!

> -----Original Message-----
> From: Fredrik Johansson [mailto:fredrik.johansson@ipunplugged.com]
> Sent: Tuesday, April 10, 2001 10:27 AM
> To: Martin Julien (ECE); Tony Johansson
> Cc: 'Patrice Calhoun'; AAA Listan
> Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
> 
> 
> After a closer look at the problem we have a suggestion on a solution.
> If the AAAH always assigns a SPI that is unique in the HA for 
> the FA-HA key,
> and a SPI that is unique in the Mn for the MN-FA and MN-HA keys, the
> security contexts will automatically be unique in every SA.
> 
> 7.5 SPI Allocation
>   To ensure that the SPI is unique for each pair of nodes,
>   the AAAH SHOULD keep track of assigned SPIs per HA and MN.
>   The SPI assigned to the MN-FA key MUST be allocated from 
> the MN SPI pool,
>   the SPI for the FA-HA key MUST be allocated from the HA SPI 
> pool, and the
>   SPI for the MN-HA key MUST be allocated from the MN SPI 
> pool. Note that
>   SPI values 0 through 255 are reserved and MUST NOT be used in any
>   Mobility Security Association.
> 
> /Fredrik
> >-----Original Message-----
> >From: owner-aaa-bof@merit.edu 
> [mailto:owner-aaa-bof@merit.edu]On Behalf
> >Of Fredrik Johansson
> >Sent: den 10 april 2001 08:40
> >To: Martin Julien (ECE); Tony Johansson
> >Cc: 'Patrice Calhoun'; AAA Listan
> >Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
> >
> >
> >>
> >>> >>
> >>> >> Another thing that needs some clarification, if there is a
> >>> solution. How
> >>> >> will the HA know which SA to use. In the case where a mobile
> >>> >moves from one
> >>> >> Fa to another under the same administrative domain it may
> >>> receive the
> >>> >> session keys for the old Fa from the AAAF. It will then proceed
> >>> >to send the
> >>> >> mip reg req to the HA. The HA will see that the message came
> >>> >from the new FA
> >>> >> and try to locate the SA shared with that FA. It will not find
> >>> >it since it
> >>> >> was established with the old FA. Eventhough the HA can see
> >>> the address of
> >>> >> the old Fa in the previous-fa-XXXX it is not clear that it can
> >>> >establish a
> >>> >> SA with the new Fa because it has to use the same SPI as before
> >>> >and that one
> >>> >> might be busy. Or have I missed something here?
> >>> >
> >>> >You also have the user NAI in the MIP registration 
> request sent to
> >>> >the HA and
> >>> >the user NAI is globally unique....
> >>>
> >>> Yes, but this is not the security association shared with the
> >>> mobile node
> >>> but the one shared between the FA and HA, thus has nothing to
> >>> do with the
> >>> user.
> >>
> >>I think you are assuming that there exists only 1 mobility 
> SA between
> >>a FA and a HA for all the MIP sessions, right?
> >
> >YES, one mobility SA, ceveral security context within a mobility
> >SA. See rfc
> >2002,
> >
> >"Mobility Security Association
> >               A collection of security contexts, between a pair
> >               of nodes, which may be applied to Mobile IP protocol
> >               messages exchanged between them.  Each 
> context indicates
> >               an authentication algorithm and mode (Section 5.1), a
> >               secret (a shared key, or appropriate public/private
> >               key pair), and a style of replay protection in use
> >               (Section 5.6)."
> >
> >Each context is indexed with a unique SPI within that SA, if 
> there exist a
> >SA between the HA and the old FA and one SA between the HA 
> and the new FA
> >there might exist security context with the same SPI in both 
> of these.
> >
> >"Security Parameter Index (SPI)
> >               An index identifying a security context between a pair
> >               of nodes among the contexts available in the Mobility
> >               Security Association.  SPI values 0 through 255 are
> >               reserved and MUST NOT be used in any Mobility Security
> >               Association."
> >
> >>When a first AMA is received
> >
> >I guess you mean AMR :-)
> >
> >>in the AAAH from a MN, is the AAAH supposed to issue a new 
> registration
> >>FA-HA key, in the case the HA is in the home domain? The 
> spec says "yes",
> >>if it is required by the MN. However, how can the MN know about the
> >>mobility SA between the FA and the HA? I guess it can not, 
> which means
> >>that it will ask for a new key, which should be transferred 
> to the FA and
> >>the HA from the AAAH. Is there a way for the HA to notify the AAAH
> >>that it does not need
> >>a new key and a new SPI for its mobility SA with the FA, since it
> >>already has one? I guess
> >>not, right? Then, it looks like your idea could be very 
> interesting, but
> >>I don't know how to deal with it using Diameter, unless the 
> AAAH and AAAF
> >>would keep a list of mobility SAs between each FA and HA.
> >
> >In some way the AAAH must keep track of what SPIs it has 
> assigned to the
> >home agent, if it does it per SA or make the SPI unique over all
> >SA's in the
> >HA is up to the implementation
> >
> >>
> >>> You can not guarantee that a security between the HA and 
> the old FA is
> >>> unique between the HA and the new FA. The same SPI must be
> >>> used in the first
> >>> request in order for the HA to be able to distinguise between
> >>> different
> >>> security contexts it shares with the FA. What we can do is to
> >>> have the new
> >>> FA add a <MIP-Preferred-SPI Ext> in the first request from
> >>> the new FA to the
> >>> HA, the HA can then use the <Previous-FA-XXXX Ext> together
> >>> with the old SPI
> >>> to retreive the context and store it under the Preferred SPI
> >>> under the SA
> >>> with the new FA.
> >>
> >>I was wondering whether or not a mobility SA between a FA
> >>and a HA was based on a particular MIP session? My understanding
> >>_IS_ that an existing SA is based on a MIP session. That means
> >>that between a FA and a HA, there exists several mobility SAs
> >>depending on each MIP session.
> >
> >No, there is only one SA between two nodes, but there are 
> several security
> >context within each SA. Each security context can 
> corresponde to a mip
> >session. It is the security context that has a lifetime, the 
> SA can be
> >removed when the last security context is removed.
> >
> >>By MIP session, I mean an AAA
> >>authorized session for MIP. The SPI is already included in the
> >>key transferred between the AAAF and the new FA. I don't see
> >>why a HA could not use the SPI stored under its MN User-Name
> >>state to retrieve the mobility SA between the new FA and itself?
> >
> >Because the SA between the FA and HA does not realy have anything
> >to do with
> >the Mn. It is something setup between the FA and HA. Thus 
> when the HA will
> >look for the key to use it will do the lookup on the FA address.
> >
> >/Fredrik
> >
> >>
> >>Regards,
> >>Martin
> >
> 



From owner-aaa-bof@merit.edu  Tue Apr 10 08:15:11 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA12740
	for <aaa-archive@odin.ietf.org>; Tue, 10 Apr 2001 08:15:11 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 8E39C5DE1E; Tue, 10 Apr 2001 07:49:01 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 7CABA5DE11; Tue, 10 Apr 2001 07:49:01 -0400 (EDT)
Received: from mailgw.local.ipunplugged.com (unknown [213.88.134.217])
	by segue.merit.edu (Postfix) with ESMTP id 94CE95DE1C
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 07:48:58 -0400 (EDT)
Received: from fredrikj (a25.local.ipunplugged.com [192.168.4.195])
	by mailgw.local.ipunplugged.com (8.9.3/8.9.3) with SMTP id NAA11023;
	Tue, 10 Apr 2001 13:50:12 +0200
From: "Fredrik Johansson" <fredrik.johansson@ipunplugged.com>
To: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>,
        "'Tony Johansson'" <tony.johansson@ericsson.com>
Cc: "'Patrice Calhoun'" <pcalhoun@nasnfs.Eng.Sun.COM>,
        "'AAA Listan'" <aaa-wg@merit.edu>
Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
Date: Tue, 10 Apr 2001 13:50:47 +0200
Message-ID: <MJEMJBGGCLLDLFFAHLJKOENCCJAA.fredrik.johansson@ipunplugged.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <577066326047D41180AC00508B955DDA01D7FF6F@eestqnt104.es.eu.ericsson.se>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

true, or at least partly, I don't believe there is anything in the standard
that prevents it from being done, it's just a matter of describing it
clearly enough so that we all can be interoperable.

I'm in the process of reading the new drafts and will try to come up with
some clarifying text

/Fredrik

>-----Original Message-----
>From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf
>Of Martin Julien (ECE)
>Sent: den 10 april 2001 12:09
>To: Martin Julien (ECE); 'Fredrik Johansson'; 'Tony Johansson'
>Cc: 'Patrice Calhoun'; 'AAA Listan'
>Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
>
>
>It remains that the Session-ID and the Accounting issues
>related to a MN roaming between FAs are not resolved yet, right?
>
>> -----Original Message-----
>> From: Martin Julien (ECE)
>> Sent: Tuesday, April 10, 2001 11:10 AM
>> To: 'Fredrik Johansson'; Martin Julien (ECE); Tony Johansson
>> Cc: 'Patrice Calhoun'; AAA Listan
>> Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
>>
>>
>> Cool! I was about to send you something very similar to know
>> if it was what you meant in your previous mail.
>> I agree with your solution. Thanks!
>>
>> > -----Original Message-----
>> > From: Fredrik Johansson [mailto:fredrik.johansson@ipunplugged.com]
>> > Sent: Tuesday, April 10, 2001 10:27 AM
>> > To: Martin Julien (ECE); Tony Johansson
>> > Cc: 'Patrice Calhoun'; AAA Listan
>> > Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
>> >
>> >
>> > After a closer look at the problem we have a suggestion on
>> a solution.
>> > If the AAAH always assigns a SPI that is unique in the HA for
>> > the FA-HA key,
>> > and a SPI that is unique in the Mn for the MN-FA and MN-HA keys, the
>> > security contexts will automatically be unique in every SA.
>> >
>> > 7.5 SPI Allocation
>> >   To ensure that the SPI is unique for each pair of nodes,
>> >   the AAAH SHOULD keep track of assigned SPIs per HA and MN.
>> >   The SPI assigned to the MN-FA key MUST be allocated from
>> > the MN SPI pool,
>> >   the SPI for the FA-HA key MUST be allocated from the HA SPI
>> > pool, and the
>> >   SPI for the MN-HA key MUST be allocated from the MN SPI
>> > pool. Note that
>> >   SPI values 0 through 255 are reserved and MUST NOT be used in any
>> >   Mobility Security Association.
>> >
>> > /Fredrik
>> > >-----Original Message-----
>> > >From: owner-aaa-bof@merit.edu
>> > [mailto:owner-aaa-bof@merit.edu]On Behalf
>> > >Of Fredrik Johansson
>> > >Sent: den 10 april 2001 08:40
>> > >To: Martin Julien (ECE); Tony Johansson
>> > >Cc: 'Patrice Calhoun'; AAA Listan
>> > >Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
>> > >
>> > >
>> > >>
>> > >>> >>
>> > >>> >> Another thing that needs some clarification, if there is a
>> > >>> solution. How
>> > >>> >> will the HA know which SA to use. In the case where a mobile
>> > >>> >moves from one
>> > >>> >> Fa to another under the same administrative domain it may
>> > >>> receive the
>> > >>> >> session keys for the old Fa from the AAAF. It will
>> then proceed
>> > >>> >to send the
>> > >>> >> mip reg req to the HA. The HA will see that the message came
>> > >>> >from the new FA
>> > >>> >> and try to locate the SA shared with that FA. It
>> will not find
>> > >>> >it since it
>> > >>> >> was established with the old FA. Eventhough the HA can see
>> > >>> the address of
>> > >>> >> the old Fa in the previous-fa-XXXX it is not clear
>> that it can
>> > >>> >establish a
>> > >>> >> SA with the new Fa because it has to use the same
>> SPI as before
>> > >>> >and that one
>> > >>> >> might be busy. Or have I missed something here?
>> > >>> >
>> > >>> >You also have the user NAI in the MIP registration
>> > request sent to
>> > >>> >the HA and
>> > >>> >the user NAI is globally unique....
>> > >>>
>> > >>> Yes, but this is not the security association shared with the
>> > >>> mobile node
>> > >>> but the one shared between the FA and HA, thus has nothing to
>> > >>> do with the
>> > >>> user.
>> > >>
>> > >>I think you are assuming that there exists only 1 mobility
>> > SA between
>> > >>a FA and a HA for all the MIP sessions, right?
>> > >
>> > >YES, one mobility SA, ceveral security context within a mobility
>> > >SA. See rfc
>> > >2002,
>> > >
>> > >"Mobility Security Association
>> > >               A collection of security contexts, between a pair
>> > >               of nodes, which may be applied to Mobile IP protocol
>> > >               messages exchanged between them.  Each
>> > context indicates
>> > >               an authentication algorithm and mode
>> (Section 5.1), a
>> > >               secret (a shared key, or appropriate public/private
>> > >               key pair), and a style of replay protection in use
>> > >               (Section 5.6)."
>> > >
>> > >Each context is indexed with a unique SPI within that SA, if
>> > there exist a
>> > >SA between the HA and the old FA and one SA between the HA
>> > and the new FA
>> > >there might exist security context with the same SPI in both
>> > of these.
>> > >
>> > >"Security Parameter Index (SPI)
>> > >               An index identifying a security context
>> between a pair
>> > >               of nodes among the contexts available in
>> the Mobility
>> > >               Security Association.  SPI values 0 through 255 are
>> > >               reserved and MUST NOT be used in any
>> Mobility Security
>> > >               Association."
>> > >
>> > >>When a first AMA is received
>> > >
>> > >I guess you mean AMR :-)
>> > >
>> > >>in the AAAH from a MN, is the AAAH supposed to issue a new
>> > registration
>> > >>FA-HA key, in the case the HA is in the home domain? The
>> > spec says "yes",
>> > >>if it is required by the MN. However, how can the MN know
>> about the
>> > >>mobility SA between the FA and the HA? I guess it can not,
>> > which means
>> > >>that it will ask for a new key, which should be transferred
>> > to the FA and
>> > >>the HA from the AAAH. Is there a way for the HA to notify the AAAH
>> > >>that it does not need
>> > >>a new key and a new SPI for its mobility SA with the FA, since it
>> > >>already has one? I guess
>> > >>not, right? Then, it looks like your idea could be very
>> > interesting, but
>> > >>I don't know how to deal with it using Diameter, unless the
>> > AAAH and AAAF
>> > >>would keep a list of mobility SAs between each FA and HA.
>> > >
>> > >In some way the AAAH must keep track of what SPIs it has
>> > assigned to the
>> > >home agent, if it does it per SA or make the SPI unique over all
>> > >SA's in the
>> > >HA is up to the implementation
>> > >
>> > >>
>> > >>> You can not guarantee that a security between the HA and
>> > the old FA is
>> > >>> unique between the HA and the new FA. The same SPI must be
>> > >>> used in the first
>> > >>> request in order for the HA to be able to distinguise between
>> > >>> different
>> > >>> security contexts it shares with the FA. What we can do is to
>> > >>> have the new
>> > >>> FA add a <MIP-Preferred-SPI Ext> in the first request from
>> > >>> the new FA to the
>> > >>> HA, the HA can then use the <Previous-FA-XXXX Ext> together
>> > >>> with the old SPI
>> > >>> to retreive the context and store it under the Preferred SPI
>> > >>> under the SA
>> > >>> with the new FA.
>> > >>
>> > >>I was wondering whether or not a mobility SA between a FA
>> > >>and a HA was based on a particular MIP session? My understanding
>> > >>_IS_ that an existing SA is based on a MIP session. That means
>> > >>that between a FA and a HA, there exists several mobility SAs
>> > >>depending on each MIP session.
>> > >
>> > >No, there is only one SA between two nodes, but there are
>> > several security
>> > >context within each SA. Each security context can
>> > corresponde to a mip
>> > >session. It is the security context that has a lifetime, the
>> > SA can be
>> > >removed when the last security context is removed.
>> > >
>> > >>By MIP session, I mean an AAA
>> > >>authorized session for MIP. The SPI is already included in the
>> > >>key transferred between the AAAF and the new FA. I don't see
>> > >>why a HA could not use the SPI stored under its MN User-Name
>> > >>state to retrieve the mobility SA between the new FA and itself?
>> > >
>> > >Because the SA between the FA and HA does not realy have anything
>> > >to do with
>> > >the Mn. It is something setup between the FA and HA. Thus
>> > when the HA will
>> > >look for the key to use it will do the lookup on the FA address.
>> > >
>> > >/Fredrik
>> > >
>> > >>
>> > >>Regards,
>> > >>Martin
>> > >
>> >
>>




From owner-aaa-bof@merit.edu  Tue Apr 10 08:31:52 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA13026
	for <aaa-archive@odin.ietf.org>; Tue, 10 Apr 2001 08:31:52 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id CEC125DF13; Mon,  9 Apr 2001 17:42:36 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id A9E0D5DF21; Mon,  9 Apr 2001 17:42:36 -0400 (EDT)
Received: from zcars04e.nortelnetworks.com (h127s131a230n47.user.nortelnetworks.com [47.230.131.127])
	by segue.merit.edu (Postfix) with ESMTP id 4ED285DF13
	for <aaa-wg@merit.edu>; Mon,  9 Apr 2001 17:42:34 -0400 (EDT)
Received: from zcard00m.ca.nortel.com by zcars04e.nortelnetworks.com;
          Mon, 9 Apr 2001 17:41:03 -0400
Received: from zbl6c008.corpeast.baynetworks.com ([132.245.205.58]) 
          by zcard00m.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) 
          id 2M6K3GQH; Mon, 9 Apr 2001 17:41:03 -0400
Received: from mitton.nortelnetworks.com (47.16.86.121 [47.16.86.121]) 
          by zbl6c008.corpeast.baynetworks.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) 
          id G0CX41CM; Mon, 9 Apr 2001 17:40:59 -0400
Message-Id: <4.3.2.7.2.20010409174037.00b97f00@ZBL6C008.corpeast.baynetworks.com>
X-Sender: dmitton@ZBL6C008.corpeast.baynetworks.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 09 Apr 2001 17:42:32 -0400
To: John Alayari <johnal@cisco.com>,
        Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>,
        aaa-wg <aaa-wg@merit.edu>, diameter <diameter@diameter.org>
From: "David Mitton" <dmitton@nortelnetworks.com>
Subject: Re: [AAA-WG]: Peer State Machine, closed state
In-Reply-To: <CNEGKCBENOKKPJPNCEODAEEMCCAA.johnal@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Orig: <dmitton@nortelnetworks.com>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

No, you don't receive connects on the "I" socket.
Only on the "R" socket.

Another explanation; hopefully there is only one code path accepting 
incoming connections on the TBD Diameter port.

         Dave.

At 4/9/01 04:17 PM -0400, John Alayari wrote:

>Pat,
>
>This is my comment on the peer state machine in the -02 version:
>
>The current state machine is:
>-----------------------------
>Closed           Start            I-Snd-Conn-Req   Wait-Conn-Ack
>                  R-Rcv-Conn-Req   I-Snd-Conn-Ack   Wait-R-DRI
>
>Shouldn't it be?
>---------------
>Closed           Start            I-Snd-Conn-Req   Wait-Conn-Ack
>                  I-Rcv-Conn-Req   I-Snd-Conn-Ack   Wait-I-DRI
>                  R-Rcv-Conn-Req   R-Snd-Conn-Ack   Wait-R-DRI
>
>John
>

---------------------------------------------------------------
David Mitton                                  ESN: 248-4570
Advisor, Nortel Networks                      978-288-4570 Direct
Wireless Solutions, IP Mobility
Billerica, MA 01821                    dmitton@nortelnetworks.com




From owner-aaa-bof@merit.edu  Tue Apr 10 09:57:27 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15386
	for <aaa-archive@odin.ietf.org>; Tue, 10 Apr 2001 09:57:26 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id E96DA5DE11; Tue, 10 Apr 2001 09:57:06 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id D47155DE06; Tue, 10 Apr 2001 09:57:06 -0400 (EDT)
Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103])
	by segue.merit.edu (Postfix) with ESMTP id E32075DDDA
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 09:57:04 -0400 (EDT)
Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate3.mot.com (motgate3 2.1) with ESMTP id GAA09983 for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 06:51:32 -0700 (MST)]
Received: [from m-il06-r4.mot.com (m-il06-r4.mot.com [129.188.137.196]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id GAA29035 for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 06:51:44 -0700 (MST)]
Received: from [140.101.173.9] by m-il06-r4.mot.com with ESMTP for aaa-wg@merit.edu; Tue, 10 Apr 2001 06:57:02 -0700
Received: (from root@localhost)
	by zorglub.crm.mot.com (8.8.8/8.8.8/crm-1.6) id PAA28269
	for aaa-wg@merit.edu.DELIVER; Tue, 10 Apr 2001 15:56:59 +0200 (METDST)
Received: from crm.mot.com (riou@tif.crm.mot.com [140.101.173.76])
	by zorglub.crm.mot.com (8.8.8/8.8.8/crm-1.6) with ESMTP id PAA28239
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 15:56:58 +0200 (METDST)
Message-Id: <3AD3112A.D7B57076@crm.mot.com>
Date: Tue, 10 Apr 2001 15:56:58 +0200
From: Emmanuel Riou <Emmanuel.Riou@crm.mot.com>
Reply-To: Emmanuel.Riou@crm.mot.com
Organization: Centre de Recherche de Motorola - Paris
X-Mailer: Mozilla 4.74C-CRM-4.7_2.2 [en] (X11; U; Linux 2.2.16 i686)
X-Accept-Language: en
MIME-Version: 1.0
To: aaa-wg@merit.edu
Subject: [AAA-WG]: Diameter API
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 8bit


Hi all,

Concerning the Diameter API, I see a contradiction between the Message
Definition $4.2.4 and the Diameter header definition of the "Diameter
Base Protocol" draft:
In the struct message ( § 4.2.4 ), there is no Diameter message length
field.
It is not the only problem:
The current version of ethereal ( 0.8.16-1 ) is not in accordance with
the current definition of the Diameter header structure in the Diameter
API. Ethereal does not read the Diameter header as it should if the
diameter API was respected.

So, is there a problem with the message structure of the §4.2.4, or is
this Message Definition not applied yet?


Best Regards,

-- 
Riou Emmanuel
Motorola Labs - Centre de Recherche Motorola - Paris


I am new to this mailing list, sorry if this question has already been
posted.



From owner-aaa-bof@merit.edu  Tue Apr 10 10:45:16 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA16928
	for <aaa-archive@odin.ietf.org>; Tue, 10 Apr 2001 10:45:16 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 68C175DE10; Tue, 10 Apr 2001 06:10:51 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 5323F5DE11; Tue, 10 Apr 2001 06:10:51 -0400 (EDT)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by segue.merit.edu (Postfix) with ESMTP id EF5E95DE10
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 06:10:48 -0400 (EDT)
Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f3AAAls26843
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 12:10:47 +0200 (MEST)
Received: FROM esealnt743.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Tue Apr 10 12:10:47 2001 +0200
Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <HA3DD013>; Tue, 10 Apr 2001 12:10:46 +0200
Message-ID: <577066326047D41180AC00508B955DDA01D7FF6F@eestqnt104.es.eu.ericsson.se>
From: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>
To: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>,
        "'Fredrik Johansson'" <fredrik.johansson@ipunplugged.com>,
        "'Tony Johansson'" <tony.johansson@ericsson.com>
Cc: "'Patrice Calhoun'" <pcalhoun@nasnfs.Eng.Sun.COM>,
        "'AAA Listan'" <aaa-wg@merit.edu>
Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
Date: Tue, 10 Apr 2001 12:09:03 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

It remains that the Session-ID and the Accounting issues 
related to a MN roaming between FAs are not resolved yet, right?

> -----Original Message-----
> From: Martin Julien (ECE) 
> Sent: Tuesday, April 10, 2001 11:10 AM
> To: 'Fredrik Johansson'; Martin Julien (ECE); Tony Johansson
> Cc: 'Patrice Calhoun'; AAA Listan
> Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
> 
> 
> Cool! I was about to send you something very similar to know
> if it was what you meant in your previous mail. 
> I agree with your solution. Thanks!
> 
> > -----Original Message-----
> > From: Fredrik Johansson [mailto:fredrik.johansson@ipunplugged.com]
> > Sent: Tuesday, April 10, 2001 10:27 AM
> > To: Martin Julien (ECE); Tony Johansson
> > Cc: 'Patrice Calhoun'; AAA Listan
> > Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
> > 
> > 
> > After a closer look at the problem we have a suggestion on 
> a solution.
> > If the AAAH always assigns a SPI that is unique in the HA for 
> > the FA-HA key,
> > and a SPI that is unique in the Mn for the MN-FA and MN-HA keys, the
> > security contexts will automatically be unique in every SA.
> > 
> > 7.5 SPI Allocation
> >   To ensure that the SPI is unique for each pair of nodes,
> >   the AAAH SHOULD keep track of assigned SPIs per HA and MN.
> >   The SPI assigned to the MN-FA key MUST be allocated from 
> > the MN SPI pool,
> >   the SPI for the FA-HA key MUST be allocated from the HA SPI 
> > pool, and the
> >   SPI for the MN-HA key MUST be allocated from the MN SPI 
> > pool. Note that
> >   SPI values 0 through 255 are reserved and MUST NOT be used in any
> >   Mobility Security Association.
> > 
> > /Fredrik
> > >-----Original Message-----
> > >From: owner-aaa-bof@merit.edu 
> > [mailto:owner-aaa-bof@merit.edu]On Behalf
> > >Of Fredrik Johansson
> > >Sent: den 10 april 2001 08:40
> > >To: Martin Julien (ECE); Tony Johansson
> > >Cc: 'Patrice Calhoun'; AAA Listan
> > >Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
> > >
> > >
> > >>
> > >>> >>
> > >>> >> Another thing that needs some clarification, if there is a
> > >>> solution. How
> > >>> >> will the HA know which SA to use. In the case where a mobile
> > >>> >moves from one
> > >>> >> Fa to another under the same administrative domain it may
> > >>> receive the
> > >>> >> session keys for the old Fa from the AAAF. It will 
> then proceed
> > >>> >to send the
> > >>> >> mip reg req to the HA. The HA will see that the message came
> > >>> >from the new FA
> > >>> >> and try to locate the SA shared with that FA. It 
> will not find
> > >>> >it since it
> > >>> >> was established with the old FA. Eventhough the HA can see
> > >>> the address of
> > >>> >> the old Fa in the previous-fa-XXXX it is not clear 
> that it can
> > >>> >establish a
> > >>> >> SA with the new Fa because it has to use the same 
> SPI as before
> > >>> >and that one
> > >>> >> might be busy. Or have I missed something here?
> > >>> >
> > >>> >You also have the user NAI in the MIP registration 
> > request sent to
> > >>> >the HA and
> > >>> >the user NAI is globally unique....
> > >>>
> > >>> Yes, but this is not the security association shared with the
> > >>> mobile node
> > >>> but the one shared between the FA and HA, thus has nothing to
> > >>> do with the
> > >>> user.
> > >>
> > >>I think you are assuming that there exists only 1 mobility 
> > SA between
> > >>a FA and a HA for all the MIP sessions, right?
> > >
> > >YES, one mobility SA, ceveral security context within a mobility
> > >SA. See rfc
> > >2002,
> > >
> > >"Mobility Security Association
> > >               A collection of security contexts, between a pair
> > >               of nodes, which may be applied to Mobile IP protocol
> > >               messages exchanged between them.  Each 
> > context indicates
> > >               an authentication algorithm and mode 
> (Section 5.1), a
> > >               secret (a shared key, or appropriate public/private
> > >               key pair), and a style of replay protection in use
> > >               (Section 5.6)."
> > >
> > >Each context is indexed with a unique SPI within that SA, if 
> > there exist a
> > >SA between the HA and the old FA and one SA between the HA 
> > and the new FA
> > >there might exist security context with the same SPI in both 
> > of these.
> > >
> > >"Security Parameter Index (SPI)
> > >               An index identifying a security context 
> between a pair
> > >               of nodes among the contexts available in 
> the Mobility
> > >               Security Association.  SPI values 0 through 255 are
> > >               reserved and MUST NOT be used in any 
> Mobility Security
> > >               Association."
> > >
> > >>When a first AMA is received
> > >
> > >I guess you mean AMR :-)
> > >
> > >>in the AAAH from a MN, is the AAAH supposed to issue a new 
> > registration
> > >>FA-HA key, in the case the HA is in the home domain? The 
> > spec says "yes",
> > >>if it is required by the MN. However, how can the MN know 
> about the
> > >>mobility SA between the FA and the HA? I guess it can not, 
> > which means
> > >>that it will ask for a new key, which should be transferred 
> > to the FA and
> > >>the HA from the AAAH. Is there a way for the HA to notify the AAAH
> > >>that it does not need
> > >>a new key and a new SPI for its mobility SA with the FA, since it
> > >>already has one? I guess
> > >>not, right? Then, it looks like your idea could be very 
> > interesting, but
> > >>I don't know how to deal with it using Diameter, unless the 
> > AAAH and AAAF
> > >>would keep a list of mobility SAs between each FA and HA.
> > >
> > >In some way the AAAH must keep track of what SPIs it has 
> > assigned to the
> > >home agent, if it does it per SA or make the SPI unique over all
> > >SA's in the
> > >HA is up to the implementation
> > >
> > >>
> > >>> You can not guarantee that a security between the HA and 
> > the old FA is
> > >>> unique between the HA and the new FA. The same SPI must be
> > >>> used in the first
> > >>> request in order for the HA to be able to distinguise between
> > >>> different
> > >>> security contexts it shares with the FA. What we can do is to
> > >>> have the new
> > >>> FA add a <MIP-Preferred-SPI Ext> in the first request from
> > >>> the new FA to the
> > >>> HA, the HA can then use the <Previous-FA-XXXX Ext> together
> > >>> with the old SPI
> > >>> to retreive the context and store it under the Preferred SPI
> > >>> under the SA
> > >>> with the new FA.
> > >>
> > >>I was wondering whether or not a mobility SA between a FA
> > >>and a HA was based on a particular MIP session? My understanding
> > >>_IS_ that an existing SA is based on a MIP session. That means
> > >>that between a FA and a HA, there exists several mobility SAs
> > >>depending on each MIP session.
> > >
> > >No, there is only one SA between two nodes, but there are 
> > several security
> > >context within each SA. Each security context can 
> > corresponde to a mip
> > >session. It is the security context that has a lifetime, the 
> > SA can be
> > >removed when the last security context is removed.
> > >
> > >>By MIP session, I mean an AAA
> > >>authorized session for MIP. The SPI is already included in the
> > >>key transferred between the AAAF and the new FA. I don't see
> > >>why a HA could not use the SPI stored under its MN User-Name
> > >>state to retrieve the mobility SA between the new FA and itself?
> > >
> > >Because the SA between the FA and HA does not realy have anything
> > >to do with
> > >the Mn. It is something setup between the FA and HA. Thus 
> > when the HA will
> > >look for the key to use it will do the lookup on the FA address.
> > >
> > >/Fredrik
> > >
> > >>
> > >>Regards,
> > >>Martin
> > >
> > 
> 



From owner-aaa-bof@merit.edu  Tue Apr 10 11:14:44 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17823
	for <aaa-archive@odin.ietf.org>; Tue, 10 Apr 2001 11:14:43 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id D42DB5DDD1; Tue, 10 Apr 2001 11:14:26 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id B01405DE06; Tue, 10 Apr 2001 11:14:26 -0400 (EDT)
Received: from newman.frascone.com (frascone.com [216.62.83.25])
	by segue.merit.edu (Postfix) with SMTP id 494775DDD1
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 11:14:25 -0400 (EDT)
Received: (qmail 4674 invoked by uid 500); 10 Apr 2001 15:14:24 -0000
Date: Tue, 10 Apr 2001 10:14:24 -0500
From: David Frascone <dave@frascone.com>
To: Emmanuel Riou <Emmanuel.Riou@crm.mot.com>
Cc: aaa-wg@merit.edu
Subject: Re: [AAA-WG]: Diameter API
Message-ID: <20010410101423.D30243@newman.frascone.com>
Mail-Followup-To: Emmanuel Riou <Emmanuel.Riou@crm.mot.com>,
	aaa-wg@merit.edu
References: <3AD3112A.D7B57076@crm.mot.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.2.5i
In-Reply-To: <3AD3112A.D7B57076@crm.mot.com>; from Emmanuel.Riou@crm.mot.com on Tue, Apr 10, 2001 at 03:56:58PM +0200
X-encrypt-payload: no
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 8bit

On Tue, Apr 10, 2001 at 03:56:58PM +0200, Emmanuel Riou wrote:
> 
> Hi all,
> 
> Concerning the Diameter API, I see a contradiction between the Message
> Definition $4.2.4 and the Diameter header definition of the "Diameter
> Base Protocol" draft:
> In the struct message ( § 4.2.4 ), there is no Diameter message length
> field.

Read further into the document, where it talks about "information
hiding"  (Section 4.5.2).

> It is not the only problem:
> The current version of ethereal ( 0.8.16-1 ) is not in accordance with
> the current definition of the Diameter header structure in the Diameter
> API. Ethereal does not read the Diameter header as it should if the
> diameter API was respected.

The current version of ethereal (0.8.16) is up to date with the diameter
PROTOCOL specification, defined in draft-calhoun-diameter-18.  It will also
be modified to support any changes/extensions the aaa-wg comes up with.

Since the Diameter API is not a protocol, and it's structures are simply an
implementation suggestion, it was not used in the creation of the Ethereal
dissector.


I hope this helps clarify things.


-Dave



From owner-aaa-bof@merit.edu  Tue Apr 10 11:23:22 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA18068
	for <aaa-archive@odin.ietf.org>; Tue, 10 Apr 2001 11:23:21 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 606B35DDB7; Tue, 10 Apr 2001 11:23:05 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 4BCE85DDC7; Tue, 10 Apr 2001 11:23:05 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id 17CB65DDB7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 11:23:04 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id IAA00929;
	Tue, 10 Apr 2001 08:22:08 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA03305;
	Tue, 10 Apr 2001 08:22:41 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (eastapp2.East.Sun.COM [129.148.162.99])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id IAA17224;
	Tue, 10 Apr 2001 08:21:56 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Message-Id: <200104101521.IAA17224@nasnfs.Eng.Sun.COM>
Date: Tue, 10 Apr 2001 09:18:07 -0700
To: "Tony Johansson" <tony.johansson@ericsson.com>,
        "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>,
        "'Fredrik Johansson'" <fredrik.johansson@ipunplugged.com>
Cc: "AAA Listan" <aaa-wg@merit.edu>
Reply-To: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
X-Mailer: Sun NetMail 2.3
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Just to make sure, I *presume* that this proposed text is to belong in the
Mobile IP extension, right?

PatC

ps: for those that saw my "I will not be responding to e-mail this week", I 
happen to be in a city that has metricom service :)

>Cool! I was about to send you something very similar to know
>if it was what you meant in your previous mail. 
>I agree with your solution. Thanks!
>
>> -----Original Message-----
>> From: Fredrik Johansson [mailto:fredrik.johansson@ipunplugged.com]
>> Sent: Tuesday, April 10, 2001 10:27 AM
>> To: Martin Julien (ECE); Tony Johansson
>> Cc: 'Patrice Calhoun'; AAA Listan
>> Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
>> 
>> 
>> After a closer look at the problem we have a suggestion on a solution.
>> If the AAAH always assigns a SPI that is unique in the HA for 
>> the FA-HA key,
>> and a SPI that is unique in the Mn for the MN-FA and MN-HA keys, the
>> security contexts will automatically be unique in every SA.
>> 
>> 7.5 SPI Allocation
>>   To ensure that the SPI is unique for each pair of nodes,
>>   the AAAH SHOULD keep track of assigned SPIs per HA and MN.
>>   The SPI assigned to the MN-FA key MUST be allocated from 
>> the MN SPI pool,
>>   the SPI for the FA-HA key MUST be allocated from the HA SPI 
>> pool, and the
>>   SPI for the MN-HA key MUST be allocated from the MN SPI 
>> pool. Note that
>>   SPI values 0 through 255 are reserved and MUST NOT be used in any
>>   Mobility Security Association.
>> 
>> /Fredrik
>> >-----Original Message-----
>> >From: owner-aaa-bof@merit.edu 
>> [mailto:owner-aaa-bof@merit.edu]On Behalf
>> >Of Fredrik Johansson
>> >Sent: den 10 april 2001 08:40
>> >To: Martin Julien (ECE); Tony Johansson
>> >Cc: 'Patrice Calhoun'; AAA Listan
>> >Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
>> >
>> >
>> >>
>> >>> >>
>> >>> >> Another thing that needs some clarification, if there is a
>> >>> solution. How
>> >>> >> will the HA know which SA to use. In the case where a mobile
>> >>> >moves from one
>> >>> >> Fa to another under the same administrative domain it may
>> >>> receive the
>> >>> >> session keys for the old Fa from the AAAF. It will then proceed
>> >>> >to send the
>> >>> >> mip reg req to the HA. The HA will see that the message came
>> >>> >from the new FA
>> >>> >> and try to locate the SA shared with that FA. It will not find
>> >>> >it since it
>> >>> >> was established with the old FA. Eventhough the HA can see
>> >>> the address of
>> >>> >> the old Fa in the previous-fa-XXXX it is not clear that it can
>> >>> >establish a
>> >>> >> SA with the new Fa because it has to use the same SPI as before
>> >>> >and that one
>> >>> >> might be busy. Or have I missed something here?
>> >>> >
>> >>> >You also have the user NAI in the MIP registration 
>> request sent to
>> >>> >the HA and
>> >>> >the user NAI is globally unique....
>> >>>
>> >>> Yes, but this is not the security association shared with the
>> >>> mobile node
>> >>> but the one shared between the FA and HA, thus has nothing to
>> >>> do with the
>> >>> user.
>> >>
>> >>I think you are assuming that there exists only 1 mobility 
>> SA between
>> >>a FA and a HA for all the MIP sessions, right?
>> >
>> >YES, one mobility SA, ceveral security context within a mobility
>> >SA. See rfc
>> >2002,
>> >
>> >"Mobility Security Association
>> >               A collection of security contexts, between a pair
>> >               of nodes, which may be applied to Mobile IP protocol
>> >               messages exchanged between them.  Each 
>> context indicates
>> >               an authentication algorithm and mode (Section 5.1), a
>> >               secret (a shared key, or appropriate public/private
>> >               key pair), and a style of replay protection in use
>> >               (Section 5.6)."
>> >
>> >Each context is indexed with a unique SPI within that SA, if 
>> there exist a
>> >SA between the HA and the old FA and one SA between the HA 
>> and the new FA
>> >there might exist security context with the same SPI in both 
>> of these.
>> >
>> >"Security Parameter Index (SPI)
>> >               An index identifying a security context between a pair
>> >               of nodes among the contexts available in the Mobility
>> >               Security Association.  SPI values 0 through 255 are
>> >               reserved and MUST NOT be used in any Mobility Security
>> >               Association."
>> >
>> >>When a first AMA is received
>> >
>> >I guess you mean AMR :-)
>> >
>> >>in the AAAH from a MN, is the AAAH supposed to issue a new 
>> registration
>> >>FA-HA key, in the case the HA is in the home domain? The 
>> spec says "yes",
>> >>if it is required by the MN. However, how can the MN know about the
>> >>mobility SA between the FA and the HA? I guess it can not, 
>> which means
>> >>that it will ask for a new key, which should be transferred 
>> to the FA and
>> >>the HA from the AAAH. Is there a way for the HA to notify the AAAH
>> >>that it does not need
>> >>a new key and a new SPI for its mobility SA with the FA, since it
>> >>already has one? I guess
>> >>not, right? Then, it looks like your idea could be very 
>> interesting, but
>> >>I don't know how to deal with it using Diameter, unless the 
>> AAAH and AAAF
>> >>would keep a list of mobility SAs between each FA and HA.
>> >
>> >In some way the AAAH must keep track of what SPIs it has 
>> assigned to the
>> >home agent, if it does it per SA or make the SPI unique over all
>> >SA's in the
>> >HA is up to the implementation
>> >
>> >>
>> >>> You can not guarantee that a security between the HA and 
>> the old FA is
>> >>> unique between the HA and the new FA. The same SPI must be
>> >>> used in the first
>> >>> request in order for the HA to be able to distinguise between
>> >>> different
>> >>> security contexts it shares with the FA. What we can do is to
>> >>> have the new
>> >>> FA add a <MIP-Preferred-SPI Ext> in the first request from
>> >>> the new FA to the
>> >>> HA, the HA can then use the <Previous-FA-XXXX Ext> together
>> >>> with the old SPI
>> >>> to retreive the context and store it under the Preferred SPI
>> >>> under the SA
>> >>> with the new FA.
>> >>
>> >>I was wondering whether or not a mobility SA between a FA
>> >>and a HA was based on a particular MIP session? My understanding
>> >>_IS_ that an existing SA is based on a MIP session. That means
>> >>that between a FA and a HA, there exists several mobility SAs
>> >>depending on each MIP session.
>> >
>> >No, there is only one SA between two nodes, but there are 
>> several security
>> >context within each SA. Each security context can 
>> corresponde to a mip
>> >session. It is the security context that has a lifetime, the 
>> SA can be
>> >removed when the last security context is removed.
>> >
>> >>By MIP session, I mean an AAA
>> >>authorized session for MIP. The SPI is already included in the
>> >>key transferred between the AAAF and the new FA. I don't see
>> >>why a HA could not use the SPI stored under its MN User-Name
>> >>state to retrieve the mobility SA between the new FA and itself?
>> >
>> >Because the SA between the FA and HA does not realy have anything
>> >to do with
>> >the Mn. It is something setup between the FA and HA. Thus 
>> when the HA will
>> >look for the key to use it will do the lookup on the FA address.
>> >
>> >/Fredrik
>> >
>> >>
>> >>Regards,
>> >>Martin
>> >
>> 





From owner-aaa-bof@merit.edu  Tue Apr 10 11:28:33 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA18294
	for <aaa-archive@odin.ietf.org>; Tue, 10 Apr 2001 11:28:33 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 76B9D5DDC7; Tue, 10 Apr 2001 11:28:15 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 6027F5DDFE; Tue, 10 Apr 2001 11:28:15 -0400 (EDT)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id A37185DDC7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 11:28:13 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA03579;
	Tue, 10 Apr 2001 08:28:07 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA04217;
	Tue, 10 Apr 2001 08:28:06 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (eastapp2.East.Sun.COM [129.148.162.99])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id IAA17313;
	Tue, 10 Apr 2001 08:27:07 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Message-Id: <200104101527.IAA17313@nasnfs.Eng.Sun.COM>
Date: Tue, 10 Apr 2001 09:23:32 -0700
To: "Fredrik Johansson" <fredrik.johansson@ipunplugged.com>,
        "'Tony Johansson'" <tony.johansson@ericsson.com>,
        "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>
Cc: "'AAA Listan'" <aaa-wg@merit.edu>,
        "'Patrice Calhoun'" <pcalhoun@nasnfs.Eng.Sun.COM>
Reply-To: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
X-Mailer: Sun NetMail 2.3
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit


>true, or at least partly, I don't believe there is anything in the standard
>that prevents it from being done, it's just a matter of describing it
>clearly enough so that we all can be interoperable.
>
>I'm in the process of reading the new drafts and will try to come up with
>some clarifying text

The latest base protocol (-02) includes the following text:

11.7  Original-Session-Id AVP

   The Original-Session-Id AVP (AVP Code 261) is of type OctetString and
   MAY be sent in a message of type Response or Answer if the Home AAA
   server already has a session identifier for the user, and wishes to
   keep the existing Session-Id. All further messages from the Access
   Device for this session MUST use the session identifier in this AVP.
   This shouldn't be viewed as a new session, but rather renaming the
   old session.

PatC




From owner-aaa-bof@merit.edu  Tue Apr 10 11:37:39 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA18585
	for <aaa-archive@odin.ietf.org>; Tue, 10 Apr 2001 11:37:39 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id D08B45DEAE; Tue, 10 Apr 2001 11:36:21 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id B75805DEB0; Tue, 10 Apr 2001 11:36:21 -0400 (EDT)
Received: from fridge.docomo-usa.com (unknown [216.98.102.228])
	by segue.merit.edu (Postfix) with ESMTP id 460045DEAE
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 11:36:20 -0400 (EDT)
Received: from DCLNTAS1 (dhcp34.docomo-usa.com [172.21.96.34])
	by fridge.docomo-usa.com (8.11.3/8.11.3) with SMTP id f3AFgiq20023;
	Tue, 10 Apr 2001 08:42:44 -0700 (PDT)
From: "Alexander Hagen" <ahagen@dcl.docomo-usa.com>
Cc: <aaa-wg@merit.edu>, <diameter@diameter.org>
Subject: [AAA-WG]: Anybody care to provide a pointer to the UML model of Diameter
Date: Tue, 10 Apr 2001 08:36:33 -0700
Message-ID: <002401c0c1d4$05b9e3f0$226015ac@DCLNTAS1>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0)
In-Reply-To: <Roam.SIMC.2.0.6.986824625.20327.pcalhoun@nasnfs>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

At the 49th IETF a UML model was discussed and an obscure (i.e. not in
Google) URL provided. I am trying to make a collection of RFC related UML
models and would like to find it.

If anyone is interested in looking at the UML model collection once it is
finished (no promises) let me know and I will send you a pointer.



Alexander Hagen
Senior Research Engineer
Development and Prototyping
DoCoMo Communications Laboratories USA, Inc. (DoCoMo USA Labs)
  181 Metro Drive, Suite 300, San Jose, CA 95110, USA
  TEL :+1-408-573-1050 (Main)     FAX : +1-408-573-1090 (Main)
  TEL: +1-408-451-4706 (Direct)
E-mail: ahagen@dcl.docomo-usa.com
Web: http://www.docomo-usa.com






From owner-aaa-bof@merit.edu  Tue Apr 10 13:53:57 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA22241
	for <aaa-archive@odin.ietf.org>; Tue, 10 Apr 2001 13:53:57 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 7CD0C5E124; Tue, 10 Apr 2001 13:48:26 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 94F855DED0; Tue, 10 Apr 2001 13:47:42 -0400 (EDT)
Received: from imr2.ericy.com (unknown [12.34.240.68])
	by segue.merit.edu (Postfix) with ESMTP id C4D175DED4
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 13:41:28 -0400 (EDT)
Received: from mr4u3.ericy.com (mr4att.ericy.com [138.85.92.12])
	by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f3AHfR816231;
	Tue, 10 Apr 2001 12:41:27 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179])
	by mr4u3.ericy.com (8.10.2/8.10.2) with ESMTP id f3AHfRa11325;
	Tue, 10 Apr 2001 12:41:27 -0500 (CDT)
Received: from pop.exu.ericsson.se (qpop [138.85.1.15]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id MAA17327; Tue, 10 Apr 2001 12:41:26 -0500 (CDT)
Received: from ericsson.com (busam56.berkeley.us.am.ericsson.se [138.85.159.206])
	by pop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id MAA14180;
	Tue, 10 Apr 2001 12:41:19 -0500 (CDT)
Message-ID: <3AD345AF.22EE851B@ericsson.com>
Date: Tue, 10 Apr 2001 10:41:04 -0700
From: Tony Johansson <tony.johansson@ericsson.com>
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Fredrik Johansson <fredrik.johansson@ipunplugged.com>
Cc: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>,
        "'Patrice Calhoun'" <pcalhoun@nasnfs.Eng.Sun.COM>,
        AAA Listan <aaa-wg@merit.edu>
Subject: Re: [AAA-WG]: Previous-FA-XXXX AVP
References: <MJEMJBGGCLLDLFFAHLJKGEMNCJAA.fredrik.johansson@ipunplugged.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Fredrik,

I like this, it's better then to make use of the user NAI.

/Tony

Fredrik Johansson wrote:

> After a closer look at the problem we have a suggestion on a solution.
> If the AAAH always assigns a SPI that is unique in the HA for the FA-HA key,
> and a SPI that is unique in the Mn for the MN-FA and MN-HA keys, the
> security contexts will automatically be unique in every SA.
>
> 7.5 SPI Allocation
>   To ensure that the SPI is unique for each pair of nodes,
>   the AAAH SHOULD keep track of assigned SPIs per HA and MN.
>   The SPI assigned to the MN-FA key MUST be allocated from the MN SPI pool,
>   the SPI for the FA-HA key MUST be allocated from the HA SPI pool, and the
>   SPI for the MN-HA key MUST be allocated from the MN SPI pool. Note that
>   SPI values 0 through 255 are reserved and MUST NOT be used in any
>   Mobility Security Association.
>
> /Fredrik
> >-----Original Message-----
> >From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf
> >Of Fredrik Johansson
> >Sent: den 10 april 2001 08:40
> >To: Martin Julien (ECE); Tony Johansson
> >Cc: 'Patrice Calhoun'; AAA Listan
> >Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
> >
> >
> >>
> >>> >>
> >>> >> Another thing that needs some clarification, if there is a
> >>> solution. How
> >>> >> will the HA know which SA to use. In the case where a mobile
> >>> >moves from one
> >>> >> Fa to another under the same administrative domain it may
> >>> receive the
> >>> >> session keys for the old Fa from the AAAF. It will then proceed
> >>> >to send the
> >>> >> mip reg req to the HA. The HA will see that the message came
> >>> >from the new FA
> >>> >> and try to locate the SA shared with that FA. It will not find
> >>> >it since it
> >>> >> was established with the old FA. Eventhough the HA can see
> >>> the address of
> >>> >> the old Fa in the previous-fa-XXXX it is not clear that it can
> >>> >establish a
> >>> >> SA with the new Fa because it has to use the same SPI as before
> >>> >and that one
> >>> >> might be busy. Or have I missed something here?
> >>> >
> >>> >You also have the user NAI in the MIP registration request sent to
> >>> >the HA and
> >>> >the user NAI is globally unique....
> >>>
> >>> Yes, but this is not the security association shared with the
> >>> mobile node
> >>> but the one shared between the FA and HA, thus has nothing to
> >>> do with the
> >>> user.
> >>
> >>I think you are assuming that there exists only 1 mobility SA between
> >>a FA and a HA for all the MIP sessions, right?
> >
> >YES, one mobility SA, ceveral security context within a mobility
> >SA. See rfc
> >2002,
> >
> >"Mobility Security Association
> >               A collection of security contexts, between a pair
> >               of nodes, which may be applied to Mobile IP protocol
> >               messages exchanged between them.  Each context indicates
> >               an authentication algorithm and mode (Section 5.1), a
> >               secret (a shared key, or appropriate public/private
> >               key pair), and a style of replay protection in use
> >               (Section 5.6)."
> >
> >Each context is indexed with a unique SPI within that SA, if there exist a
> >SA between the HA and the old FA and one SA between the HA and the new FA
> >there might exist security context with the same SPI in both of these.
> >
> >"Security Parameter Index (SPI)
> >               An index identifying a security context between a pair
> >               of nodes among the contexts available in the Mobility
> >               Security Association.  SPI values 0 through 255 are
> >               reserved and MUST NOT be used in any Mobility Security
> >               Association."
> >
> >>When a first AMA is received
> >
> >I guess you mean AMR :-)
> >
> >>in the AAAH from a MN, is the AAAH supposed to issue a new registration
> >>FA-HA key, in the case the HA is in the home domain? The spec says "yes",
> >>if it is required by the MN. However, how can the MN know about the
> >>mobility SA between the FA and the HA? I guess it can not, which means
> >>that it will ask for a new key, which should be transferred to the FA and
> >>the HA from the AAAH. Is there a way for the HA to notify the AAAH
> >>that it does not need
> >>a new key and a new SPI for its mobility SA with the FA, since it
> >>already has one? I guess
> >>not, right? Then, it looks like your idea could be very interesting, but
> >>I don't know how to deal with it using Diameter, unless the AAAH and AAAF
> >>would keep a list of mobility SAs between each FA and HA.
> >
> >In some way the AAAH must keep track of what SPIs it has assigned to the
> >home agent, if it does it per SA or make the SPI unique over all
> >SA's in the
> >HA is up to the implementation
> >
> >>
> >>> You can not guarantee that a security between the HA and the old FA is
> >>> unique between the HA and the new FA. The same SPI must be
> >>> used in the first
> >>> request in order for the HA to be able to distinguise between
> >>> different
> >>> security contexts it shares with the FA. What we can do is to
> >>> have the new
> >>> FA add a <MIP-Preferred-SPI Ext> in the first request from
> >>> the new FA to the
> >>> HA, the HA can then use the <Previous-FA-XXXX Ext> together
> >>> with the old SPI
> >>> to retreive the context and store it under the Preferred SPI
> >>> under the SA
> >>> with the new FA.
> >>
> >>I was wondering whether or not a mobility SA between a FA
> >>and a HA was based on a particular MIP session? My understanding
> >>_IS_ that an existing SA is based on a MIP session. That means
> >>that between a FA and a HA, there exists several mobility SAs
> >>depending on each MIP session.
> >
> >No, there is only one SA between two nodes, but there are several security
> >context within each SA. Each security context can corresponde to a mip
> >session. It is the security context that has a lifetime, the SA can be
> >removed when the last security context is removed.
> >
> >>By MIP session, I mean an AAA
> >>authorized session for MIP. The SPI is already included in the
> >>key transferred between the AAAF and the new FA. I don't see
> >>why a HA could not use the SPI stored under its MN User-Name
> >>state to retrieve the mobility SA between the new FA and itself?
> >
> >Because the SA between the FA and HA does not realy have anything
> >to do with
> >the Mn. It is something setup between the FA and HA. Thus when the HA will
> >look for the key to use it will do the lookup on the FA address.
> >
> >/Fredrik
> >
> >>
> >>Regards,
> >>Martin
> >




From owner-aaa-bof@merit.edu  Tue Apr 10 18:02:36 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27019
	for <aaa-archive@odin.ietf.org>; Tue, 10 Apr 2001 18:02:36 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id AF1345E0A0; Tue, 10 Apr 2001 17:51:59 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 56FAD5DF16; Tue, 10 Apr 2001 17:35:22 -0400 (EDT)
Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110])
	by segue.merit.edu (Postfix) with ESMTP id BBC465DE7C
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 17:18:08 -0400 (EDT)
Received: from Interlinknetworks.com (unknown [198.108.5.3])
	by aaa.interlinknetworks.com (Postfix) with ESMTP
	id E528772; Tue, 10 Apr 2001 17:18:25 -0400 (EDT)
Message-ID: <3AD37888.86CACCEE@Interlinknetworks.com>
Date: Tue, 10 Apr 2001 17:18:00 -0400
From: David Spence <DSpence@Interlinknetworks.com>
Organization: Interlink Networks, Inc.
X-Mailer: Mozilla 4.76 [en] (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Alexander Hagen <ahagen@dcl.docomo-usa.com>
Cc: aaa-wg@merit.edu, diameter@diameter.org
Subject: Re: [AAA-WG]: Anybody care to provide a pointer to the UML model of 
 Diameter
References: <002401c0c1d4$05b9e3f0$226015ac@DCLNTAS1>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Here it is:

   http://www.interlinknetworks.com/otherdocs/nasmodel.html

Alexander Hagen wrote:
> 
> At the 49th IETF a UML model was discussed and an obscure (i.e. not in
> Google) URL provided. I am trying to make a collection of RFC related UML
> models and would like to find it.
> 
> If anyone is interested in looking at the UML model collection once it is
> finished (no promises) let me know and I will send you a pointer.
> 
> Alexander Hagen
> Senior Research Engineer
> Development and Prototyping
> DoCoMo Communications Laboratories USA, Inc. (DoCoMo USA Labs)
>   181 Metro Drive, Suite 300, San Jose, CA 95110, USA
>   TEL :+1-408-573-1050 (Main)     FAX : +1-408-573-1090 (Main)
>   TEL: +1-408-451-4706 (Direct)
> E-mail: ahagen@dcl.docomo-usa.com
> Web: http://www.docomo-usa.com

-- 
David Spence                            email: DSpence@Interlinknetworks.com
Interlink Networks, Inc.                phone: (734) 821-1203
775 Technology Drive, Suite 200         fax:   (734) 821-1235
Ann Arbor, MI 48108           
U.S.A.



From owner-aaa-bof@merit.edu  Tue Apr 10 19:59:29 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA28342
	for <aaa-archive@odin.ietf.org>; Tue, 10 Apr 2001 19:59:29 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id D7ACA5DF04; Tue, 10 Apr 2001 19:40:48 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 588555E11E; Tue, 10 Apr 2001 19:07:46 -0400 (EDT)
Received: from forsete.erilab.com (forsete.erilab.com [208.224.156.105])
	by segue.merit.edu (Postfix) with ESMTP id 28F745DE4C
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:37:54 -0400 (EDT)
Received: from erilab.com (eblcl50.erilab.com [192.168.174.190])
	by forsete.erilab.com (8.11.0/8.11.0) with ESMTP id f3AMbmo01409;
	Tue, 10 Apr 2001 15:37:48 -0700 (PDT)
Message-ID: <3AD38BB3.BC00773C@erilab.com>
Date: Tue, 10 Apr 2001 15:39:47 -0700
From: Michael Chen <cchen@erilab.com>
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Cc: aaa-wg@merit.edu
Subject: [AAA-WG]: Route-Record AVP in Indication message
References: <Roam.SIMC.2.0.6.986427693.2399.pcalhoun@nasnfs>
Content-Type: multipart/alternative;
 boundary="------------F7E145BA2833CB333CCD0C29"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk


--------------F7E145BA2833CB333CCD0C29
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

In base protocol 12.4.1
  "A Diameter server that proxies a message or type Request, Query or
   Indication MUST append a Route-Record AVP, which includes its
   identity.  Diameter Servers that receive messages MUST validate the
   last Route-Record AVP in the message and ensure that the host
   identified in the AVP is the same as the sender of the message."

My suggestin to add text, something like this:
The FIRST creater(AAA3 in my example) of an Indication Message MUST remove all
the Route-Rrecord AVPs before return to the sender of the request to avoid LOOP
DETECTION.
If it's correct, the Indication might not send the same route back as the request
message.
Well, if it's very obvious, just ignore this email.

Here is an example

 AAA1(a.com) AAA2(b.com)  AAA3(c.com)   AAA4(d.com)
----------  -----------  -----------   ------------

     ----------->
     route-record=aaa1.a.com

                 ------------->
                 route-record=aaa1.a.com
                 route-record=aaa2.b.com

                               -----link broken---

                 <-------------
                 route-record=aaa3.c.com
     <-------------
     route-record=aaa3.c.com
     route-record=aaa2.b.com






--------------F7E145BA2833CB333CCD0C29
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<tt>In base protocol 12.4.1</tt>
<br><tt>&nbsp; "A Diameter server that proxies a message or type Request,
Query or</tt>
<br><tt>&nbsp;&nbsp; Indication MUST append a Route-Record AVP, which includes
its</tt>
<br><tt>&nbsp;&nbsp; identity.&nbsp; Diameter Servers that receive messages
MUST validate the</tt>
<br><tt>&nbsp;&nbsp; last Route-Record AVP in the message and ensure that
the host</tt>
<br><tt>&nbsp;&nbsp; identified in the AVP is the same as the sender of
the message."</tt><tt></tt>
<p><tt>My suggestin to add text, something like this:</tt>
<br><tt>The FIRST creater(AAA3 in my example) of an Indication Message
MUST remove all the Route-Rrecord AVPs before return to the sender of the
request to avoid LOOP DETECTION.</tt>
<br><tt>If it's correct, the Indication might not send the same route back
as the request message.</tt>
<br><tt>Well, if it's very obvious, just ignore this email.</tt><tt></tt>
<p><tt>Here is an example</tt><tt></tt>
<p><tt>&nbsp;AAA1(a.com) AAA2(b.com)&nbsp; AAA3(c.com)&nbsp;&nbsp; AAA4(d.com)</tt>
<br><tt>----------&nbsp; -----------&nbsp; -----------&nbsp;&nbsp; ------------</tt><tt></tt>
<p><tt>&nbsp;&nbsp;&nbsp;&nbsp; -----------></tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp; route-record=aaa1.a.com</tt><tt></tt>
<p><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
-------------></tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
route-record=aaa1.a.com</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
route-record=aaa2.b.com</tt><tt></tt>
<p><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
-----link broken---</tt><tt></tt>
<p><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;-------------</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
route-record=aaa3.c.com</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp; &lt;-------------</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp; route-record=aaa3.c.com</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp; route-record=aaa2.b.com</tt>
<br><tt>&nbsp;</tt>
<br><tt></tt>&nbsp;
<br><tt></tt>&nbsp;
<br><tt></tt>&nbsp;
<br><tt></tt>&nbsp;</html>

--------------F7E145BA2833CB333CCD0C29--




From owner-aaa-bof@merit.edu  Tue Apr 10 20:10:13 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA28618
	for <aaa-archive@odin.ietf.org>; Tue, 10 Apr 2001 20:10:13 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Tue Apr 10 20:10:23 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA28634
	for <aaa-archive@odin.ietf.org>; Tue, 10 Apr 2001 20:10:23 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id AE8AA5E0AE; Tue, 10 Apr 2001 19:51:47 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 937025E0FA; Tue, 10 Apr 2001 19:30:49 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 1691D5E238
	for <Aaa-Wg@merit.edu>; Tue, 10 Apr 2001 19:00:04 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10316; Tue, 10 Apr 2001 15:59:01 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Mark Jones" <mjones@bridgewatersystems.com>,
        "David Frascone" <dave@frascone.com>,
        "Christian Huitema" <huitema@exchange.microsoft.com>
Cc: <Aaa-Wg@merit.edu>
Subject: RE: [AAA-WG]: AAA WG Interim meeting dates
Date: Tue, 10 Apr 2001 15:59:01 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPOEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <000e01c0bea7$84ecc820$2096a8c0@mjones.bridgewatersys.com>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Mark Jones [mailto:mjones@bridgewatersystems.com] writes:

> > > 5) Device-Reboot-Ind (DRI) Command
> > >
> > > Having a mandatory Vendor-ID in the command creates a barrier to entry
> > > for implementors: it requires that they first register with the IANA.
> > > This should be optional. There is no reason to mandate the
> presence of a
> > > vendor-id if no vendor extensions are used, a case which we
> hope should
> > > be quite common.

From a recent draft:

Vendor-ID
      In the event that the Command-Code field contains a vendor
      specific command, the four octet Vendor-ID field contains the IANA
      assigned "SMI Network Management Private Enterprise Codes" [2]
      value. If the Command-Code field contains an IETF standard
      Command, the Vendor-ID field MUST be set to zero (0).

There is no need for implementors to register w/IANA if they are
implementing a vanilla, standard Diameter peer.

> >
>
> The Vendor-Id/Product-Name/Firmware-Revision AVPs also serve to
> identify the
> peer regardless of whether it generates vendor-specific AVPs.
>
> > I agree with this comment.  I to prefer a vendor string over an
> > IANA number.
> >
>
> If the AVP was only intended to be human-readable, I would agree. If my
> Diameter server has to interpret it, I prefer a well-known integer. For
> vendor string to be equally machine-readable, one would have to
> ensure that
> every Diameter peer produced by the same large corporation had the same
> well-known value. Otherwise how many permutations could we have of "Sun
> Microsystems Inc."?
>
> > I'm assuming it's easy for a company to get a vendor id, but what about
> > someone testing a concept:  "Umm, can I get a "Dave's new Toy
> vendor id" ?

Pick an unused ID.

> >
>
> So this oft repeated "barrier to entry" is for those implementing
> a Diameter
> device/server who have yet to form a company and so would be
> ineligible for
> an IANA code. You're looking for something akin to the Experimental branch
> on the SNMP MIB. Is that right?
>
> Would the following text help?
>
> "A Vendor-Id value of zero in the DRI is reserved and indicates that the
> Diameter peer is in the experimental or concept stage and that an IANA
> Private Enterprise Number has yet to be obtained by the implementor."

Unfortunately, this contradicts the general approach to commands (see
above).

>
> Regards,
>        Mark
>
>
>




From owner-aaa-bof@merit.edu  Tue Apr 10 21:34:21 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA00463
	for <aaa-archive@odin.ietf.org>; Tue, 10 Apr 2001 21:34:21 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 82BE65E133; Tue, 10 Apr 2001 21:11:12 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id E0C105DFB5; Tue, 10 Apr 2001 20:57:39 -0400 (EDT)
Received: from forsete.erilab.com (forsete.erilab.com [208.224.156.105])
	by segue.merit.edu (Postfix) with ESMTP id D6A945DF07
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 20:34:48 -0400 (EDT)
Received: from erilab.com (eblcl50.erilab.com [192.168.174.190])
	by forsete.erilab.com (8.11.0/8.11.0) with ESMTP id f3B0Ymo01601;
	Tue, 10 Apr 2001 17:34:48 -0700 (PDT)
Message-ID: <3AD3A716.562C8C68@erilab.com>
Date: Tue, 10 Apr 2001 17:36:38 -0700
From: Michael Chen <cchen@erilab.com>
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: pcalhoun@eng.sun.com, aaa-wg@merit.edu
Subject: [AAA-WG]: Integrity-Check-Value AVP
References: <200104101527.IAA17313@nasnfs.Eng.Sun.COM>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

It seems that Integrity-Check-Value AVP has been removed from the draft
but this AVP still show up in some place in the draft, please clean it up.







From owner-aaa-bof@merit.edu  Tue Apr 10 22:21:19 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA01290
	for <aaa-archive@odin.ietf.org>; Tue, 10 Apr 2001 22:21:18 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Tue Apr 10 23:15:21 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA02622
	for <aaa-archive@odin.ietf.org>; Tue, 10 Apr 2001 23:15:21 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Wed Apr 11 01:25:47 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA06881
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 01:25:47 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Wed Apr 11 02:34:42 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA18106
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 02:34:42 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id A66D45DE7F; Tue, 10 Apr 2001 19:51:09 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 07EAA5DEE1; Tue, 10 Apr 2001 19:28:22 -0400 (EDT)
Received: from forsete.erilab.com (forsete.erilab.com [208.224.156.105])
	by segue.merit.edu (Postfix) with ESMTP id C3B0A5E21B
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:55:10 -0400 (EDT)
Received: from erilab.com (eblcl50.erilab.com [192.168.174.190])
	by forsete.erilab.com (8.11.0/8.11.0) with ESMTP id f3AMtAo01449;
	Tue, 10 Apr 2001 15:55:10 -0700 (PDT)
Message-ID: <3AD38FC4.3732BC9A@erilab.com>
Date: Tue, 10 Apr 2001 15:57:08 -0700
From: Michael Chen <cchen@erilab.com>
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: aaa-wg@merit.edu, pcalhoun@eng.sun.com
Subject: [AAA-WG]: Small copy paste errors fix request.
References: <3ACA542B.B43FCF1F@erilab.com>
Content-Type: multipart/alternative;
 boundary="------------BE658933C6F913B83A6E9066"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk


--------------BE658933C6F913B83A6E9066
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


In base protocol


1.
  section 12.1. Figure2.
    dia3--->dia2
        Route-Record=dia1.mno.net (missing)
        Route-Record=dia2.xyz.com

   dia2--->dia1
        Route-Record=dia1.mno.net (missing)

2.
  section 10.1.3
    "The Failed-Command-Code-Vendor-Id AVP (AVP Code 262)...."
    It should be Failed-Vendor-Id AVP

3.
  section 12.4.7
     "......type Answer of Reply......."
     It should be "or" instead of "of"




--------------BE658933C6F913B83A6E9066
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<tt></tt>&nbsp;
<br><tt>In base protocol</tt>
<br><tt></tt>&nbsp;<tt></tt>
<p><tt>1.</tt>
<br><tt>&nbsp; section 12.1. Figure2.</tt>
<br><tt>&nbsp;&nbsp;&nbsp; dia3--->dia2</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Route-Record=dia1.mno.net
(missing)</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Route-Record=dia2.xyz.com</tt><tt></tt>
<p><tt>&nbsp;&nbsp; dia2--->dia1</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Route-Record=dia1.mno.net
(missing)</tt><tt></tt>
<p><tt>2.</tt>
<br><tt>&nbsp; section 10.1.3</tt>
<br><tt>&nbsp;&nbsp;&nbsp; "The Failed-Command-Code-Vendor-Id AVP (AVP
Code 262)...."</tt>
<br><tt>&nbsp;&nbsp;&nbsp; It should be Failed-Vendor-Id AVP</tt><tt></tt>
<p><tt>3.</tt>
<br><tt>&nbsp; section 12.4.7</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp; "......type Answer of Reply......."</tt>
<br><tt>&nbsp;&nbsp;&nbsp;&nbsp; It should be "or" instead of "of"</tt>
<br><tt></tt>&nbsp;
<br><tt></tt>&nbsp;
<br>&nbsp;</html>

--------------BE658933C6F913B83A6E9066--




From owner-aaa-bof@merit.edu  Wed Apr 11 02:52:44 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA18192
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 02:52:44 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Wed Apr 11 03:20:18 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA18343
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 03:20:17 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Wed Apr 11 03:25:00 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA18386
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 03:25:00 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 4956F5DF70; Wed, 11 Apr 2001 03:23:36 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 4B8575DF69; Wed, 11 Apr 2001 03:23:07 -0400 (EDT)
Received: from mailgw.local.ipunplugged.com (unknown [213.88.134.217])
	by segue.merit.edu (Postfix) with ESMTP id 8C3CA5DF48
	for <aaa-wg@merit.edu>; Wed, 11 Apr 2001 03:21:32 -0400 (EDT)
Received: from fredrikj (a25.local.ipunplugged.com [192.168.4.195])
	by mailgw.local.ipunplugged.com (8.9.3/8.9.3) with SMTP id JAA24147;
	Wed, 11 Apr 2001 09:22:42 +0200
From: "Fredrik Johansson" <fredrik.johansson@ipunplugged.com>
To: <pcalhoun@eng.sun.com>, "Tony Johansson" <tony.johansson@ericsson.com>,
        "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>
Cc: "AAA Listan" <aaa-wg@merit.edu>
Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
Date: Wed, 11 Apr 2001 09:23:19 +0200
Message-ID: <MJEMJBGGCLLDLFFAHLJKIEOCCJAA.fredrik.johansson@ipunplugged.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <200104101521.IAA17224@nasnfs.Eng.Sun.COM>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

>
>Just to make sure, I *presume* that this proposed text is to belong in the
>Mobile IP extension, right?

Yes, that's correct

/Fredrik

>
>PatC
>
>ps: for those that saw my "I will not be responding to e-mail this 
>week", I 
>happen to be in a city that has metricom service :)
>
>>Cool! I was about to send you something very similar to know
>>if it was what you meant in your previous mail. 
>>I agree with your solution. Thanks!
>>
>>> -----Original Message-----
>>> From: Fredrik Johansson [mailto:fredrik.johansson@ipunplugged.com]
>>> Sent: Tuesday, April 10, 2001 10:27 AM
>>> To: Martin Julien (ECE); Tony Johansson
>>> Cc: 'Patrice Calhoun'; AAA Listan
>>> Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
>>> 
>>> 
>>> After a closer look at the problem we have a suggestion on a solution.
>>> If the AAAH always assigns a SPI that is unique in the HA for 
>>> the FA-HA key,
>>> and a SPI that is unique in the Mn for the MN-FA and MN-HA keys, the
>>> security contexts will automatically be unique in every SA.
>>> 
>>> 7.5 SPI Allocation
>>>   To ensure that the SPI is unique for each pair of nodes,
>>>   the AAAH SHOULD keep track of assigned SPIs per HA and MN.
>>>   The SPI assigned to the MN-FA key MUST be allocated from 
>>> the MN SPI pool,
>>>   the SPI for the FA-HA key MUST be allocated from the HA SPI 
>>> pool, and the
>>>   SPI for the MN-HA key MUST be allocated from the MN SPI 
>>> pool. Note that
>>>   SPI values 0 through 255 are reserved and MUST NOT be used in any
>>>   Mobility Security Association.
>>> 
>>> /Fredrik
>>> >-----Original Message-----
>>> >From: owner-aaa-bof@merit.edu 
>>> [mailto:owner-aaa-bof@merit.edu]On Behalf
>>> >Of Fredrik Johansson
>>> >Sent: den 10 april 2001 08:40
>>> >To: Martin Julien (ECE); Tony Johansson
>>> >Cc: 'Patrice Calhoun'; AAA Listan
>>> >Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
>>> >
>>> >
>>> >>
>>> >>> >>
>>> >>> >> Another thing that needs some clarification, if there is a
>>> >>> solution. How
>>> >>> >> will the HA know which SA to use. In the case where a mobile
>>> >>> >moves from one
>>> >>> >> Fa to another under the same administrative domain it may
>>> >>> receive the
>>> >>> >> session keys for the old Fa from the AAAF. It will then proceed
>>> >>> >to send the
>>> >>> >> mip reg req to the HA. The HA will see that the message came
>>> >>> >from the new FA
>>> >>> >> and try to locate the SA shared with that FA. It will not find
>>> >>> >it since it
>>> >>> >> was established with the old FA. Eventhough the HA can see
>>> >>> the address of
>>> >>> >> the old Fa in the previous-fa-XXXX it is not clear that it can
>>> >>> >establish a
>>> >>> >> SA with the new Fa because it has to use the same SPI as before
>>> >>> >and that one
>>> >>> >> might be busy. Or have I missed something here?
>>> >>> >
>>> >>> >You also have the user NAI in the MIP registration 
>>> request sent to
>>> >>> >the HA and
>>> >>> >the user NAI is globally unique....
>>> >>>
>>> >>> Yes, but this is not the security association shared with the
>>> >>> mobile node
>>> >>> but the one shared between the FA and HA, thus has nothing to
>>> >>> do with the
>>> >>> user.
>>> >>
>>> >>I think you are assuming that there exists only 1 mobility 
>>> SA between
>>> >>a FA and a HA for all the MIP sessions, right?
>>> >
>>> >YES, one mobility SA, ceveral security context within a mobility
>>> >SA. See rfc
>>> >2002,
>>> >
>>> >"Mobility Security Association
>>> >               A collection of security contexts, between a pair
>>> >               of nodes, which may be applied to Mobile IP protocol
>>> >               messages exchanged between them.  Each 
>>> context indicates
>>> >               an authentication algorithm and mode (Section 5.1), a
>>> >               secret (a shared key, or appropriate public/private
>>> >               key pair), and a style of replay protection in use
>>> >               (Section 5.6)."
>>> >
>>> >Each context is indexed with a unique SPI within that SA, if 
>>> there exist a
>>> >SA between the HA and the old FA and one SA between the HA 
>>> and the new FA
>>> >there might exist security context with the same SPI in both 
>>> of these.
>>> >
>>> >"Security Parameter Index (SPI)
>>> >               An index identifying a security context between a pair
>>> >               of nodes among the contexts available in the Mobility
>>> >               Security Association.  SPI values 0 through 255 are
>>> >               reserved and MUST NOT be used in any Mobility Security
>>> >               Association."
>>> >
>>> >>When a first AMA is received
>>> >
>>> >I guess you mean AMR :-)
>>> >
>>> >>in the AAAH from a MN, is the AAAH supposed to issue a new 
>>> registration
>>> >>FA-HA key, in the case the HA is in the home domain? The 
>>> spec says "yes",
>>> >>if it is required by the MN. However, how can the MN know about the
>>> >>mobility SA between the FA and the HA? I guess it can not, 
>>> which means
>>> >>that it will ask for a new key, which should be transferred 
>>> to the FA and
>>> >>the HA from the AAAH. Is there a way for the HA to notify the AAAH
>>> >>that it does not need
>>> >>a new key and a new SPI for its mobility SA with the FA, since it
>>> >>already has one? I guess
>>> >>not, right? Then, it looks like your idea could be very 
>>> interesting, but
>>> >>I don't know how to deal with it using Diameter, unless the 
>>> AAAH and AAAF
>>> >>would keep a list of mobility SAs between each FA and HA.
>>> >
>>> >In some way the AAAH must keep track of what SPIs it has 
>>> assigned to the
>>> >home agent, if it does it per SA or make the SPI unique over all
>>> >SA's in the
>>> >HA is up to the implementation
>>> >
>>> >>
>>> >>> You can not guarantee that a security between the HA and 
>>> the old FA is
>>> >>> unique between the HA and the new FA. The same SPI must be
>>> >>> used in the first
>>> >>> request in order for the HA to be able to distinguise between
>>> >>> different
>>> >>> security contexts it shares with the FA. What we can do is to
>>> >>> have the new
>>> >>> FA add a <MIP-Preferred-SPI Ext> in the first request from
>>> >>> the new FA to the
>>> >>> HA, the HA can then use the <Previous-FA-XXXX Ext> together
>>> >>> with the old SPI
>>> >>> to retreive the context and store it under the Preferred SPI
>>> >>> under the SA
>>> >>> with the new FA.
>>> >>
>>> >>I was wondering whether or not a mobility SA between a FA
>>> >>and a HA was based on a particular MIP session? My understanding
>>> >>_IS_ that an existing SA is based on a MIP session. That means
>>> >>that between a FA and a HA, there exists several mobility SAs
>>> >>depending on each MIP session.
>>> >
>>> >No, there is only one SA between two nodes, but there are 
>>> several security
>>> >context within each SA. Each security context can 
>>> corresponde to a mip
>>> >session. It is the security context that has a lifetime, the 
>>> SA can be
>>> >removed when the last security context is removed.
>>> >
>>> >>By MIP session, I mean an AAA
>>> >>authorized session for MIP. The SPI is already included in the
>>> >>key transferred between the AAAF and the new FA. I don't see
>>> >>why a HA could not use the SPI stored under its MN User-Name
>>> >>state to retrieve the mobility SA between the new FA and itself?
>>> >
>>> >Because the SA between the FA and HA does not realy have anything
>>> >to do with
>>> >the Mn. It is something setup between the FA and HA. Thus 
>>> when the HA will
>>> >look for the key to use it will do the lookup on the FA address.
>>> >
>>> >/Fredrik
>>> >
>>> >>
>>> >>Regards,
>>> >>Martin
>>> >
>>> 
>
>



From owner-aaa-bof@merit.edu  Wed Apr 11 03:28:01 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA18428
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 03:28:01 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 384C95E2AB; Tue, 10 Apr 2001 21:28:56 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 041255DE91; Tue, 10 Apr 2001 21:08:10 -0400 (EDT)
Received: from forsete.erilab.com (forsete.erilab.com [208.224.156.105])
	by segue.merit.edu (Postfix) with ESMTP id 67E835DF6E
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 20:53:22 -0400 (EDT)
Received: from erilab.com (eblcl50.erilab.com [192.168.174.190])
	by forsete.erilab.com (8.11.0/8.11.0) with ESMTP id f3B0rMo01640;
	Tue, 10 Apr 2001 17:53:22 -0700 (PDT)
Message-ID: <3AD3AB6E.38B9F21D@erilab.com>
Date: Tue, 10 Apr 2001 17:55:10 -0700
From: Michael Chen <cchen@erilab.com>
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>, aaa-wg@merit.edu
Subject: [AAA-WG]: Destination-FQDN AVP 
References: <Roam.SIMC.2.0.6.986427693.2399.pcalhoun@nasnfs> <3AD38BB3.BC00773C@erilab.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

In base protocol section 5.0

"When a Diameter entity receives a Diameter message of type Request,
   Query or Indication that includes a Destination-FQDN AVP, and the
   host specified in the AVP can be contacted directly, the message MUST

   be forwarded to the host in question. ..........."

As I know, there is NO Destination-FQDN AVP in the "Request" or "Query"
Message.
So I don't understand what you are trying to say. Am I missing something
here?










From owner-aaa-bof@merit.edu  Wed Apr 11 03:36:26 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA18478
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 03:36:25 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Wed Apr 11 04:00:02 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA18624
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 04:00:02 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Wed Apr 11 04:15:20 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA18712
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 04:15:20 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Wed Apr 11 04:34:31 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA18794
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 04:34:30 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Wed Apr 11 04:46:36 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA18854
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 04:46:36 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Wed Apr 11 05:00:29 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA18996
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 05:00:29 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Wed Apr 11 05:16:37 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA19152
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 05:16:36 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Wed Apr 11 05:30:16 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA19205
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 05:30:16 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Wed Apr 11 05:45:39 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA19313
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 05:45:38 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Wed Apr 11 06:02:56 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA19379
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 06:02:56 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Wed Apr 11 06:18:59 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA19529
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 06:18:58 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Wed Apr 11 06:34:03 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA19618
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 06:34:02 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Wed Apr 11 06:47:56 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA19741
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 06:47:56 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 76D685DF36; Tue, 10 Apr 2001 20:25:10 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 15B685DF31; Tue, 10 Apr 2001 20:10:41 -0400 (EDT)
Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240])
	by segue.merit.edu (Postfix) with ESMTP id C661B5DDBF
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 19:52:48 -0400 (EDT)
Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124])
	by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f3ANqkm19888;
	Tue, 10 Apr 2001 18:52:46 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179])
	by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f3ANqkj05386;
	Tue, 10 Apr 2001 18:52:46 -0500 (CDT)
Received: from pop.exu.ericsson.se (qpop [138.85.1.15]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id SAA08798; Tue, 10 Apr 2001 18:52:45 -0500 (CDT)
Received: from ericsson.com (busam56.berkeley.us.am.ericsson.se [138.85.159.206])
	by pop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id SAA19901;
	Tue, 10 Apr 2001 18:52:38 -0500 (CDT)
Message-ID: <3AD39CB5.4955B348@ericsson.com>
Date: Tue, 10 Apr 2001 16:52:21 -0700
From: Tony Johansson <tony.johansson@ericsson.com>
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: pcalhoun@eng.sun.com
Cc: Fredrik Johansson <fredrik.johansson@ipunplugged.com>,
        "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>,
        "'AAA Listan'" <aaa-wg@merit.edu>,
        "'Patrice Calhoun'" <pcalhoun@nasnfs.Eng.Sun.COM>
Subject: Re: [AAA-WG]: Previous-FA-XXXX AVP
References: <200104101527.IAA17313@nasnfs.Eng.Sun.COM>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit



Patrice Calhoun wrote:

> >true, or at least partly, I don't believe there is anything in the standard
> >that prevents it from being done, it's just a matter of describing it
> >clearly enough so that we all can be interoperable.
> >
> >I'm in the process of reading the new drafts and will try to come up with
> >some clarifying text
>
> The latest base protocol (-02) includes the following text:
>
> 11.7  Original-Session-Id AVP
>
>    The Original-Session-Id AVP (AVP Code 261) is of type OctetString and
>    MAY be sent in a message of type Response or Answer if the Home AAA
>    server already has a session identifier for the user, and wishes to
>    keep the existing Session-Id. All further messages from the Access
>    Device for this session MUST use the session identifier in this AVP.
>    This shouldn't be viewed as a new session, but rather renaming the
>    old session.

Maybe it just needs to be clarified that the Original-Session-Id AVP MAY be sent
in a message of type Response or Answer from a AAA (like the AAAF or the AAAH)
server that already has a valid session identifier for the user, and wishes to
keep the existing Session-Id.

BR,

/Tony





>
>
> PatC




From owner-aaa-bof@merit.edu  Wed Apr 11 06:49:34 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA19765
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 06:49:33 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Wed Apr 11 06:53:09 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA19886
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 06:53:09 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 265A25DD99; Wed, 11 Apr 2001 06:52:58 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 0F10B5DDA0; Wed, 11 Apr 2001 06:52:58 -0400 (EDT)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by segue.merit.edu (Postfix) with ESMTP id DE8445DD99
	for <aaa-wg@merit.edu>; Wed, 11 Apr 2001 06:52:55 -0400 (EDT)
Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f3BAqsI25166
	for <aaa-wg@merit.edu>; Wed, 11 Apr 2001 12:52:54 +0200 (MEST)
Received: FROM esealnt743.al.sw.ericsson.se BY esealnt461 ; Wed Apr 11 12:51:18 2001 +0200
Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <HA3DFH78>; Wed, 11 Apr 2001 12:52:53 +0200
Message-ID: <577066326047D41180AC00508B955DDA02C009A2@eestqnt104.es.eu.ericsson.se>
From: "Yolanda Garcia-Serrano (ECE)" <yolanda.garcia-serrano@ece.ericsson.se>
To: "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>
Subject: [AAA-WG]: Some editorial findings
Date: Wed, 11 Apr 2001 12:52:52 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA19886

Hi, Pat

Sorry for 'bothering' you with this e-mail, but maybe is useful for you to have these corrections to incorporate them
in base-03  They are just small spelling errors. See bottom of the e-mail for some other questions.

Section 1.3. Terminology 
	Integrity Check Value
		unforgeable -> unforgettable
	Proxy 
		úses -> uses
Section 2.0:
	Four extensions -> Three extensions (accounting is not one anymore)
Section 2.1: April 2001 -> September 2001
           Second paragraph: destionation -> destination
Section 2.3, first paragraph: appplication --> application
                  last paragraph: prorietary --> proprietary
Section 3.3.3 occured --> occurred
Section 6.0: last paragraph: explicitely --> explictly
Section 7.0: 3rd paragraph: jiterring --> jittering
                   4th paragraph: Secton --> Section
Section 7.3: Should it be Fallback instead of Failback??
Section 8.0: 3rd paragraph: occured --> occurred
                   5th paragraph: subsesquent --> subsequent
Section 8.1: signalled --> signaled
                  Wait-Conn-Ack/Elect: acknowlegement --> acknowledgement
Section 8.2: Rcv-Conn-Ack & Rcv-Conn-Nack: acknowlegement --> acknowledgement
                  Stop: signalled --> signaled
Section 9.0, first paragraph: signalled --> signaled
Section 9.1.1.1: alloted --> allotted
Section 9.1.1.4: satified --> satisfied
Section 10.0: 4th and 5th paragraphs: labelled --> labeled
Section 10.1.1: last paragraph: occurances --> occurrences
Section 10.2.4 and 10.2.5 --> They should be 10.2.3 and 10.2.4 respectively
Section 11.2: last paragraph: accounting is not an extension anymore
Section 12.2: point 1. "If the Destination-FQDN AVP is present...." refers to section 5.1, which should be 5.3 instead
Section 12.4.2: messges --> messages
Section 12.4.7: Answer or Reply --> Answer or Response
Section 17.3: 2nd paragraph: inteded --> intended
Section 19.0: RTT-Multiplier: valus --> value

- NASREQ extension 02: In the Table of Contents, update Section 8.0 'Accounting Considerations' to 'Accounting AVPs'


Some other issues:
==================

- A reply is the generic term to refer to Answers (corresponding to Requests) or
Responses (corresponding to Queries), right? Then, if possible, unify in the document
(e.g. section 3.0, section 12.4.7)

- Section 14: Extension-Id AVP is not needed anymore in the accounting messages as they belong to base stuff, right ?
 (not needed in ACR, ACA, ASI, API and Accounting AVP Table section 16.2)
- I've noticed section 1.4 from Accounting 01 has been dropped from base-02 draft. Was not useful?
- Same for Accounting-Authentication-Type AVP, which does not appear in base-02. Is it not needed anymore?

Regards
	/Yolanda



From owner-aaa-bof@merit.edu  Wed Apr 11 07:02:29 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA20204
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 07:02:28 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Wed Apr 11 07:16:43 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA20439
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 07:16:43 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Wed Apr 11 07:31:37 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA20809
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 07:31:37 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Wed Apr 11 07:47:50 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA21240
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 07:47:50 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Wed Apr 11 08:01:37 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA21583
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 08:01:37 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Wed Apr 11 08:17:36 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA21967
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 08:17:35 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Wed Apr 11 08:33:46 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA22457
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 08:33:46 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Wed Apr 11 08:46:28 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA22759
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 08:46:28 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Wed Apr 11 09:02:37 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA23160
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 09:02:36 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Wed Apr 11 09:04:13 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA23190
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 09:04:12 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id AF37E5DEB2; Wed, 11 Apr 2001 09:03:55 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9A2E05DE84; Wed, 11 Apr 2001 09:03:55 -0400 (EDT)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id 5D8585DEB0
	for <aaa-wg@merit.edu>; Wed, 11 Apr 2001 09:03:54 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA15905;
	Wed, 11 Apr 2001 06:03:52 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA02650;
	Wed, 11 Apr 2001 06:03:52 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (eastapp2.East.Sun.COM [129.148.162.99])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id GAA12450;
	Wed, 11 Apr 2001 06:03:26 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Message-Id: <200104111303.GAA12450@nasnfs.Eng.Sun.COM>
Date: Wed, 11 Apr 2001 08:59:10 -0700
To: "Michael Chen" <cchen@erilab.com>,
        "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>
Cc: <aaa-wg@merit.edu>
Reply-To: <pcalhoun@eng.sun.com>
Subject: [AAA-WG]: Re: Route-Record AVP in Indication message
X-Mailer: Sun NetMail 2.3
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit


>In base protocol 12.4.1
>  "A Diameter server that proxies a message or type Request, Query or
>   Indication MUST append a Route-Record AVP, which includes its
>   identity.  Diameter Servers that receive messages MUST validate the
>   last Route-Record AVP in the message and ensure that the host
>   identified in the AVP is the same as the sender of the message."
>
>My suggestin to add text, something like this:
>The FIRST creater(AAA3 in my example) of an Indication Message MUST remove all
>the Route-Rrecord AVPs before return to the sender of the request to avoid LOOP
>DETECTION.
>If it's correct, the Indication might not send the same route back as the
>request
>message.
>Well, if it's very obvious, just ignore this email.
>
>Here is an example
>
> AAA1(a.com) AAA2(b.com)  AAA3(c.com)   AAA4(d.com)
>----------  -----------  -----------   ------------
>
>     ----------->
>     route-record=aaa1.a.com
>
>                 ------------->
>                 route-record=aaa1.a.com
>                 route-record=aaa2.b.com
>
>                               -----link broken---
>
>                 <-------------
>                 route-record=aaa3.c.com
>     <-------------
>     route-record=aaa3.c.com
>     route-record=aaa2.b.com

Michael,

At first, I thought this was covered in the following text in section 12.4.2:

   A proxy server MUST only process messges of type Response or Answer
   whose last Route-Record AVP matches one of its addresses. Any
   responses that do not conform to this rule MUST be dropped. The last
   Route-Record AVP MUST be removed from the message before it is
   forwarded to the next hop, which is identified by the second to last
   Route-Record AVP.

and then realized this only applied to responses, and not indication messages.

However, since the DSI message you mention here is *not* a response to the
request that generated the message, it MUST NOT include the route-record AVPs
that were present in the request.

This just seems logical, but if you believe that some clarifying text is
required, then please let me know.

PatC




From owner-aaa-bof@merit.edu  Wed Apr 11 09:10:57 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA23363
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 09:10:57 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id E4AE65DDC4; Wed, 11 Apr 2001 09:10:46 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id CF4635DDBF; Wed, 11 Apr 2001 09:10:46 -0400 (EDT)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id 5A1FC5DDBE
	for <aaa-wg@merit.edu>; Wed, 11 Apr 2001 09:10:45 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA20382;
	Wed, 11 Apr 2001 06:10:43 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA03605;
	Wed, 11 Apr 2001 06:10:42 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (eastapp2.East.Sun.COM [129.148.162.99])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id GAA12506;
	Wed, 11 Apr 2001 06:10:05 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Message-Id: <200104111310.GAA12506@nasnfs.Eng.Sun.COM>
Date: Wed, 11 Apr 2001 09:06:03 -0700
To: "Tony Johansson" <tony.johansson@ericsson.com>
Cc: "'Patrice Calhoun'" <pcalhoun@nasnfs.Eng.Sun.COM>,
        "'AAA Listan'" <aaa-wg@merit.edu>,
        "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>,
        "Fredrik Johansson" <fredrik.johansson@ipunplugged.com>
Reply-To: <pcalhoun@eng.sun.com>
Subject: Re: [AAA-WG]: Previous-FA-XXXX AVP
X-Mailer: Sun NetMail 2.3
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

>> 11.7  Original-Session-Id AVP
>>
>>    The Original-Session-Id AVP (AVP Code 261) is of type OctetString and
>>    MAY be sent in a message of type Response or Answer if the Home AAA
>>    server already has a session identifier for the user, and wishes to
>>    keep the existing Session-Id. All further messages from the Access
>>    Device for this session MUST use the session identifier in this AVP.
>>    This shouldn't be viewed as a new session, but rather renaming the
>>    old session.
>
>Maybe it just needs to be clarified that the Original-Session-Id AVP MAY be
>sent
>in a message of type Response or Answer from a AAA (like the AAAF or the AAAH)
>server that already has a valid session identifier for the user, and wishes to
>keep the existing Session-Id.

Such text will be present in -03.

PatC




From owner-aaa-bof@merit.edu  Wed Apr 11 09:18:45 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA23499
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 09:18:45 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Wed Apr 11 09:20:13 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA23533
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 09:20:13 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 2AE665DE3D; Wed, 11 Apr 2001 09:16:53 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 135945DE3E; Wed, 11 Apr 2001 09:16:53 -0400 (EDT)
Received: from mailgw.local.ipunplugged.com (unknown [213.88.134.217])
	by segue.merit.edu (Postfix) with ESMTP id D93255DE3D
	for <aaa-wg@merit.edu>; Wed, 11 Apr 2001 09:16:50 -0400 (EDT)
Received: from fredrikj (c42.local.ipunplugged.com [192.168.4.241])
	by mailgw.local.ipunplugged.com (8.9.3/8.9.3) with SMTP id PAA30070
	for <aaa-wg@merit.edu>; Wed, 11 Apr 2001 15:18:12 +0200
From: "Fredrik Johansson" <fredrik.johansson@ipunplugged.com>
To: "AAA Listan" <aaa-wg@merit.edu>
Subject: [AAA-WG]: Comments on draft-ietf-aaa-diameter-mobileip-02.txt
Date: Wed, 11 Apr 2001 15:18:48 +0200
Message-ID: <MJEMJBGGCLLDLFFAHLJKCEONCJAA.fredrik.johansson@ipunplugged.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Sorry for the partly duplicate mail, slipped on the keyboard and managed to
send the previous mail before I was finished with it. Anyway, here is the
rest :-)


"This document is an individual contribution for consideration by the
   AAA Working Group of the Internet Engineering Task Force.  Comments
   should be submitted to the mobileip@nortelnetworks.com mailing list."

Not really true, is it? :-) especially not the email address

Section 1.2
"If AAAH does not know the address of the home agent (perhaps because
   it will be allocated by AAAF within the visited domain as described
   in section 1.3), then AAAH sends an AMA message back to AAAF which
   does not contain a MIP-Reg-Reply AVP."

It will send a HAR not an AMA.

In the ABNF for the AMR {Session-ID AVP} should be <Session-ID AVP>

Section 1.4

Maybe there should be a note that CHAP style authentication cannot be used
since the client will not receive a challenge. Or should this only be stated
in RFC 3012?

Section 2.1
"If the MIP-Previous-FA-FQDN AVP is found in the request, the Diameter
   client requests that the server return the registration key that was
   assigned to the previous Foreign Agent for use with the Mobile Node
   and Home Agent. The registration key is identified through the use of
   the MIP-Mobile-Node-Address AVP."

the key should be identified by the User-Name AVP

B.T.W. what should the result code be, what I'm thinking about is that
section 2.2 says

"An AMA message with the Result-Code AVP indicating success MUST also
   include the MIP-Reg-Reply AVP."

and if AAAF should be able to return the keys it has to do so without a
MIP-Reg-Reply AVP.


Section 5.5-6

Clarification needed. What should the reply code be? A note that the FA
should send the MIP-Reg-Request directly to the HA when it has received the
needed keys.

Section 5.7

"If the mobile node includes a Generalized MN-FA Key Request [15]
   extension with the AAA subtype in its Registration Request, the"

Should it be the Generalized MN-FA Key Request or will it change when the
AAA Registration Keys for Mobile IP is rewritten? what did we agree on? was
it Generalized Key Request with subtypes depending on what key?

Section 5.8.1
"The MIP-MN-AAA-SPI AVP (AVP Code 341) is of type Unsigned32 and
   indicates the algorithm by which the targeted AAA server (AAAH)
   should attempt to validate the Authenticator computed by the mobile
   node over the Registration Request data."

Pat, didn't we agree on rewriting this to conform with the way the SPI is
used in MIP, i.e. the SPI indicates a security context which contains Key,
Lifetime, Algorithm, Algorithm mode ...

Section 5.10
"The Filter-Rule AVP (AVP Code 400) is of type OctetString, encoded in
   the UTF-8 [29] format, and provides filter rules that need to be
   configured on the Foreign Agent for the user. One or more such AVPs
   MAY be present in an authorization response."

I believe that it should be possible to configure the home agent as well,
I'm not sure that the home agent would like to trust the FA to do the
filtering.


more on section 5.10

"If no rule matches, the packet is dropped if the last
   rule evaluated was a permit, and passed if the last rule was a deny."

This sounds kind of strange, shouldn't you allways drop the packet if no
match was found?

Section 6.0
typo in 3rd paragraph: generatied -> generated


section 6.1
"The AAAH
   has to rely on the home agent (that also understands Diameter) to
   transfer the key into a Mobile IP Generalized MN-HA Key Reply
   extension in the Registration Reply message."

Same as in 5.8.1, shouldn't it be Mobile IP Generalizeed Key Reply after the
key dist. draft is rewritten?

". The resulting Registration Reply is
   added to the MIP-Reg-Reply AVP and added to the AHA."

AHA should be AMA

"The foreign
   agent can then use that AVP to recreate a Registration Reply message,
   containing the Generalized MN-HA Key Reply extension, for delivery to
   the mobile node."

Generalized MN-HA Key Reply -> Generalized Key Reply with subtype MN-HA

section 6.2
"
   The Mobile-Foreign registration key is also generated by AAAH (upon
   request), so that it can be encoded into a MIP-MN-to-FA-Key AVP,
   which is added to the HAR, and copied by the home agent into a
   Generalized MN-FA Key Reply Extension [15] to the Mobile IP
   Registration Reply message. Most of the considerations for
   distributing the Mobile-Foreign registration key are similar to the
   distribution of the Mobile-Home Registration Key."

Generalized MN-FA Key Reply Extension -> Generalized Key Reply Extension
with subtype MN-FA

Section 6.3
"If the MIP-FA-to-HA-Key AVP was present in the HAR, the same AVP MUST
   be present in the corresponding AHA, which is eventually transformed
   by the AAAH into an AMA message that is transmitted back to the
   foreign agent."

AHA -> HAA

"Upon receipt of the AMA, the foreign agent recovers the Foreign-Home
   registration key, and uses this key to create a Mobile-Foreign
   authentication extension to the Registration Reply message."

Queue?!? Sounds like this should be under section 6.2 and it should be:
"Upon receipt of the AMA, the foreign agent recovers the Foreign-Mobile
 registration key, and uses this key to create a Mobile-foreign
 authentication extension to the Registration Reply message."

Section 7.1.1
"The MIP-MN-to-FA-Key AVP (AVP Code 325) is of type OctetString, and
   contains the Keying material described in the "Unsolicited MN-FA Key
   from AAA Subtype" in [15]. The FA SPI field of the data structure in
   [15] MUST be set to the same value as the MIP-Peer-SPI AVP within the
   FA-to-MN-Key AVP."

Change according to the new AAA keys for MIP draft (when there is a new
version :-))

Section 7.1.2
same as 7.1.1

Section 7.2

I believe that we should add AVPs in the Grouped AVP that indicates what
algorithm type/mode, replay protection, to use. As it is today, the MIP
agents can only assume that some default mode is used. This is in the same
way as we agreed that the MIP Key Reply extension should be extended in the
AAA Keys for MIP draft (or if it was in Charlies "generalized key draft")

Section 10.2

In the table it is indicated that all of Session-Time, Packet, and Octets
AVPs MUST be present in ACR and ACA. Is it really mandatory to allways
measure both time, packets and bytes. If you only do time based accounting,
why should you have to send the other two types? Or should you send them
with a value of zero?


/Fredrik




From owner-aaa-bof@merit.edu  Wed Apr 11 09:22:43 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA23581
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 09:22:42 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 20BA05DE48; Wed, 11 Apr 2001 09:20:02 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id F2FAC5DE4A; Wed, 11 Apr 2001 09:20:01 -0400 (EDT)
Received: from newman.frascone.com (frascone.com [216.62.83.25])
	by segue.merit.edu (Postfix) with SMTP id BEE5D5DE48
	for <aaa-wg@merit.edu>; Wed, 11 Apr 2001 09:19:55 -0400 (EDT)
Received: (qmail 16396 invoked by uid 500); 11 Apr 2001 13:19:55 -0000
Date: Wed, 11 Apr 2001 08:19:54 -0500
From: David Frascone <dave@frascone.com>
To: "Yolanda Garcia-Serrano (ECE)" <yolanda.garcia-serrano@ece.ericsson.se>
Cc: "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>
Subject: Re: [AAA-WG]: Some editorial findings
Message-ID: <20010411081954.B14053@newman.frascone.com>
Mail-Followup-To: "Yolanda Garcia-Serrano (ECE)" <yolanda.garcia-serrano@ece.ericsson.se>,
	"'aaa-wg@merit.edu'" <aaa-wg@merit.edu>
References: <577066326047D41180AC00508B955DDA02C009A2@eestqnt104.es.eu.ericsson.se>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <577066326047D41180AC00508B955DDA02C009A2@eestqnt104.es.eu.ericsson.se>; from yolanda.garcia-serrano@ece.ericsson.se on Wed, Apr 11, 2001 at 12:52:52PM +0200
X-encrypt-payload: no
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

On Wed, Apr 11, 2001 at 12:52:52PM +0200, Yolanda Garcia-Serrano (ECE) wrote:
> Hi, Pat
> 
> Sorry for 'bothering' you with this e-mail, but maybe is useful for you to have these corrections to incorporate them
> in base-03  They are just small spelling errors. See bottom of the e-mail for some other questions.
> 
> Section 1.3. Terminology 
> 	Integrity Check Value
> 		unforgeable -> unforgettable

	I'm pretty sure that here he wanted unforgeable.  However, I do not
	think "unforgeable" is a word.  Perhaps this sentance could be
	re-written.
	(Unforgettable is NOT an accurate replacement)





From owner-aaa-bof@merit.edu  Wed Apr 11 09:31:38 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA23815
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 09:31:38 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Wed Apr 11 09:45:16 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA24046
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 09:45:16 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 7B75E5DE5A; Wed, 11 Apr 2001 08:04:41 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 69E0C5DE06; Wed, 11 Apr 2001 08:04:41 -0400 (EDT)
Received: from mailgw.local.ipunplugged.com (unknown [213.88.134.217])
	by segue.merit.edu (Postfix) with ESMTP id 737F15DDD0
	for <aaa-wg@merit.edu>; Wed, 11 Apr 2001 08:04:39 -0400 (EDT)
Received: from fredrikj (c42.local.ipunplugged.com [192.168.4.241])
	by mailgw.local.ipunplugged.com (8.9.3/8.9.3) with SMTP id OAA28750
	for <aaa-wg@merit.edu>; Wed, 11 Apr 2001 14:05:56 +0200
From: "Fredrik Johansson" <fredrik.johansson@ipunplugged.com>
To: "AAA Listan" <aaa-wg@merit.edu>
Subject: [AAA-WG]: Comments on draft-ietf-aaa-diameter-mobileip-02.txt
Date: Wed, 11 Apr 2001 14:06:32 +0200
Message-ID: <MJEMJBGGCLLDLFFAHLJKGEOLCJAA.fredrik.johansson@ipunplugged.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Here are some comments and suggestions for the aaa-mip draft.

"This document is an individual contribution for consideration by the
   AAA Working Group of the Internet Engineering Task Force.  Comments
   should be submitted to the mobileip@nortelnetworks.com mailing list."

Not really true, is it? :-) especially not the email address

Section 1.2
"If AAAH does not know the address of the home agent (perhaps because
   it will be allocated by AAAF within the visited domain as described
   in section 1.3), then AAAH sends an AMA message back to AAAF which
   does not contain a MIP-Reg-Reply AVP."

It will send a HAR not an AMA.

Section 1.4

Maybe there should be a note that CHAP style authentication cannot be used
since the client will not receive a challenge.

Section 1.5
Should you really force the AAAF to keep session state?

Section 2.1
"If the MIP-Previous-FA-FQDN AVP is found in the request, the Diameter
   client requests that the server return the registration key that was
   assigned to the previous Foreign Agent for use with the Mobile Node
   and Home Agent. The registration key is identified through the use of
   the MIP-Mobile-Node-Address AVP."

the key should be identified by the User-Name AVP

B.T.W. what should the result code be, what I'm thinking about is that
section 2.2 says

"An AMA message with the Result-Code AVP indicating success MUST also
   include the MIP-Reg-Reply AVP."

and if AAAF should be able to return the keys it has to do so without a
MIP-Reg-Reply AVP.

Section 3.1 and Section 4.1 both have a error code of 4004 and 4002-4003 are
used in the base protocol.

Section 5.5-6

Clarification needed. What should the reply code be? A note that the FA
should send the MIP-Reg-Request directly to the HA when it has received the
needed keys.

Section 5.7

"If the mobile node includes a Generalized MN-FA Key Request [15]
   extension with the AAA subtype in its Registration Request, the"

Should it be the Generalized MN-FA Key Request or will it change when the
AAA Registration Keys for Mobile IP is rewritten?

Section 5.8.1
"The MIP-MN-AAA-SPI AVP (AVP Code 341) is of type Unsigned32 and
   indicates the algorithm by which the targeted AAA server (AAAH)
   should attempt to validate the Authenticator computed by the mobile
   node over the Registration Request data."

Pat, didn't we agree on rewriting this to conform with the way the SPI is
used in MIP, i.e. the SPI indicates a security context which contains Key,
Lifetime, Algorithm, Algorithm mode ...

Section 5.10
"The Filter-Rule AVP (AVP Code 400) is of type OctetString, encoded in
   the UTF-8 [29] format, and provides filter rules that need to be
   configured on the Foreign Agent for the user. One or more such AVPs
   MAY be present in an authorization response."

I believe that it should be possible to configure the home agent as well,
I'm not sure that the home agent would like to trust the FA to do the
filtering.


more on section 5.10

"If no rule matches, the packet is dropped if the last
   rule evaluated was a permit, and passed if the last rule was a deny."

This sounds kind of strange, shouldn't you allways drop the packet if no
match was found?

Section 6.0
typo in 3rd paragraph: generatied -> generated


section 6.1
"The AAAH
   has to rely on the home agent (that also understands Diameter) to
   transfer the key into a Mobile IP Generalized MN-HA Key Reply
   extension in the Registration Reply message."

Same as in 5.8.1, shouldn't it be Mobile IP Generalizeed Key Reply after the
key dist. draft is rewritten?

". The resulting Registration Reply is
   added to the MIP-Reg-Reply AVP and added to the AHA."

AHA should be AMA

"The foreign
   agent can then use that AVP to recreate a Registration Reply message,
   containing the Generalized MN-HA Key Reply extension, for delivery to
   the mobile node."

Generalized MN-HA Key Reply -> Generalized Key Reply with subtype MN-HA

section 6.2
"
   The Mobile-Foreign registration key is also generated by AAAH (upon
   request), so that it can be encoded into a MIP-MN-to-FA-Key AVP,
   which is added to the HAR, and copied by the home agent into a
   Generalized MN-FA Key Reply Extension [15] to the Mobile IP
   Registration Reply message. Most of the considerations for
   distributing the Mobile-Foreign registration key are similar to the
   distribution of the Mobile-Home Registration Key."

Generalized MN-FA Key Reply Extension -> Generalized Key Reply Extension
with subtype MN-FA







From owner-aaa-bof@merit.edu  Wed Apr 11 09:48:42 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA24102
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 09:48:42 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Wed Apr 11 10:02:43 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24324
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 10:02:43 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Wed Apr 11 10:17:45 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24596
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 10:17:45 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Wed Apr 11 10:24:30 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24768
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 10:24:29 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id B53BA5DDD4; Wed, 11 Apr 2001 10:24:19 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id A29AB5DDD3; Wed, 11 Apr 2001 10:24:19 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id 718C05DDBE
	for <aaa-wg@merit.edu>; Wed, 11 Apr 2001 10:24:18 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id HAA24712;
	Wed, 11 Apr 2001 07:22:58 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA21126;
	Wed, 11 Apr 2001 07:24:13 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (eastapp2.East.Sun.COM [129.148.162.99])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id HAA13167;
	Wed, 11 Apr 2001 07:23:52 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Message-Id: <200104111423.HAA13167@nasnfs.Eng.Sun.COM>
Date: Wed, 11 Apr 2001 10:19:34 -0700
To: "Michael Chen" <cchen@erilab.com>
Cc: <aaa-wg@merit.edu>
Reply-To: <pcalhoun@eng.sun.com>
Subject: [AAA-WG]: Re: Destination-FQDN AVP
X-Mailer: Sun NetMail 2.3
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit


>In base protocol section 5.0
>
>"When a Diameter entity receives a Diameter message of type Request,
>   Query or Indication that includes a Destination-FQDN AVP, and the
>   host specified in the AVP can be contacted directly, the message MUST
>
>   be forwarded to the host in question. ..........."
>
>As I know, there is NO Destination-FQDN AVP in the "Request" or "Query"
>Message.
>So I don't understand what you are trying to say. Am I missing something
>here?

Huh?

      <Session-Termination-Request>  ::= < Diameter Header: 275 >
                                         < Session-Id >
                                         { Origin-FQDN }
                                         { Origin-Realm }
                                         { User-Name }
                                         { Destination-Realm }
                                         { Destination-FQDN } <----
                                       * [ AVP ]
                                       * [ Proxy-State ]
                                       * [ Route-Record ]

PatC




From owner-aaa-bof@merit.edu  Wed Apr 11 10:34:33 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA24940
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 10:34:32 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Wed Apr 11 10:47:13 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA25218
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 10:47:13 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Wed Apr 11 11:01:32 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA25471
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 11:01:32 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Wed Apr 11 11:20:55 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA26007
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 11:20:54 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Wed Apr 11 11:41:06 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA26524
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 11:41:06 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id C95BF5DECA; Wed, 11 Apr 2001 11:39:08 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id B57155DE4E; Wed, 11 Apr 2001 11:39:08 -0400 (EDT)
Received: from mailgw.local.ipunplugged.com (unknown [213.88.134.217])
	by segue.merit.edu (Postfix) with ESMTP id 70E4D5DDDA
	for <aaa-wg@merit.edu>; Wed, 11 Apr 2001 11:39:06 -0400 (EDT)
Received: from fredrikj (c42.local.ipunplugged.com [192.168.4.241])
	by mailgw.local.ipunplugged.com (8.9.3/8.9.3) with SMTP id RAA00738
	for <aaa-wg@merit.edu>; Wed, 11 Apr 2001 17:40:27 +0200
From: "Fredrik Johansson" <fredrik.johansson@ipunplugged.com>
To: "AAA Listan" <aaa-wg@merit.edu>
Subject: [AAA-WG]: Comments on draft-ietf-aaa-diameter-02.txt
Date: Wed, 11 Apr 2001 17:41:04 +0200
Message-ID: <MJEMJBGGCLLDLFFAHLJKEEPCCJAA.fredrik.johansson@ipunplugged.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi,

Here are some comments on the new base protocol draft.

Section 1.0
last paragraph focussed -> focused


Section 2.0

"Four extensions to Diameter are defined by companion documents:
NASREQ [7], Mobile IP [10], Strong Security [11]. "

I can only see three :-) should Resource Management be added?

Section 2.3
"A Diameter extension is a
   specification that defines one or more Diameter Command-Codes, the
   expected AVPs in an ABNF [31] grammar (see section 3.2), and MAY also
   define new AVPs."

Does an extension really have to specify a Diameter Command-Code? So it's
not possible to define an extension which adds new AVPs to another
extension?

Section 5.0

Can't this section be incorporated in section 12 Message Routing?
B.T.W. why do we need both Origin-Realm and Origin-FQDN? Isn't this
redundant information?
Same applies to Destination-Realm and Destination-FQDN, or have I missed
some use here?

Section 8.0

"The stable states that a state machine may be in are Closed, I-Open
   and R-Open; all other states are intermediate. Note that I-Open and
   R-Open are equivalent except for whether the initiator or responder
   transport connection is used for communication."

If the two Open states are equivalent, why are not the transitions for these
states symetrical?

I-Open           Send-Message     I-Snd-Non-DRI    R-Open
should it really be R-Open or should it be I-Open

Section 9.0

The definition of downstream and upstream seems to be the oposite of how it
is used in this section

Section 10.0

A couple of questions on the table that I know should have come a long time
ago :-)

1. Why should you send a MRI on a unknown AVP but a DSI on an unknown
Command-code? Can it not be up to the sender to decide if it can send it
somewhere else or fix the problem in the case of an unknown AVP, i.e. you
could send a DSI it both cases. It's not up to the receiver to decide where
in the chain the problem occured.

2. Why have MRI at all, why not always let the previous node decide if it
can be fixed locally or if it should be forwarded another step down the
chain?



Section 12.1.1
There can be many servers to which a message can be proxied or redirected,
how should these be prioritised, or should you send to all of them :-)

          "3. REDIRECT - Diameter messages that fall within this
              category MUST have the identity of the home Diameter
              server(s) appended, and returned to the sender of the
              message. See section 12.3 for more information."

Is it really necessary to have the identity of the home Diameter server(s)?
Why not any next hop server?

12.3

"Successful routing table lookups will return one or more home
   Diameter servers that could satisfy the message. The home servers are
   encoded in one or more Redirect-Host AVPs, and the Command-Code field
   is set to Device-Status-Ind."

same here, why not just the next hop server instead of the home Diameter
servers?

Section 13.5
Session Records -> Accounting Records ?!?

Section 18
" - The fact that the Sender's IP Address is used in the
        construction of the Session-Id means that the introduction of
        Network Address Translation MAY cause two hosts to represent the
        same Session Identifier.  This area needs to be investigated
        further to be able to support Diameter hosts on a private
        network."

The Sender's IP Address is not used anymore, the FQDN is used instead so
this should not be an issue.

/Fredrik




From owner-aaa-bof@merit.edu  Wed Apr 11 11:52:23 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA26767
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 11:52:22 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Wed Apr 11 11:57:00 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA26907
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 11:57:00 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id D541C5DE15; Wed, 11 Apr 2001 11:48:45 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id C2ADB5DE04; Wed, 11 Apr 2001 11:48:45 -0400 (EDT)
Received: from gate.internaut.com (unknown [64.38.134.101])
	by segue.merit.edu (Postfix) with ESMTP id 4E0B35DF9D
	for <aaa-wg@merit.edu>; Wed, 11 Apr 2001 11:48:43 -0400 (EDT)
Received: from e1kj2 (e1kj2 [64.38.134.109])
	by gate.internaut.com (8.10.2/8.10.2) with SMTP id f3BFboN21808
	for <aaa-wg@merit.edu>; Wed, 11 Apr 2001 08:37:51 -0700
From: "Bernard Aboba" <aboba@internaut.com>
To: "Aaa-Wg@Merit. Edu" <aaa-wg@merit.edu>
Subject: [AAA-WG]: IETF 50 AAA WG minutes
Date: Wed, 11 Apr 2001 08:50:11 -0700
Message-ID: <OJEJKOMOEAKLMOILFCPJKEMPEFAA.aboba@internaut.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

The minutes of IETF 50 in Minneapolis are available below:

http://www.drizzle.com/~aboba/AAA/IETF50/minutes50.htm
http://www.drizzle.com/~aboba/AAA/IETF50/aaa-ietf50.zip



From owner-aaa-bof@merit.edu  Wed Apr 11 12:00:12 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA27007
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 12:00:12 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 4F9F75DE9F; Wed, 11 Apr 2001 09:33:32 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 3D4705DE9D; Wed, 11 Apr 2001 09:33:32 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id CEC785DE96
	for <aaa-wg@merit.edu>; Wed, 11 Apr 2001 09:33:30 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA01814;
	Wed, 11 Apr 2001 06:32:03 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA14537;
	Wed, 11 Apr 2001 06:33:18 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (eastapp2.East.Sun.COM [129.148.162.99])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id GAA12733;
	Wed, 11 Apr 2001 06:32:57 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Message-Id: <200104111332.GAA12733@nasnfs.Eng.Sun.COM>
Date: Wed, 11 Apr 2001 09:28:40 -0700
To: "Michael Chen" <cchen@erilab.com>, <aaa-wg@merit.edu>
Reply-To: <pcalhoun@eng.sun.com>
Subject: [AAA-WG]: Re: Integrity-Check-Value AVP
X-Mailer: Sun NetMail 2.3
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

>It seems that Integrity-Check-Value AVP has been removed from the draft
>but this AVP still show up in some place in the draft, please clean it up.
Ouch!

I was quite sure that I had cleaned this up properly, but obviously missed
some. I will have that fixed up in -03.

Thanks,

PatC




From owner-aaa-bof@merit.edu  Wed Apr 11 12:15:11 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA27413
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 12:15:11 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Wed Apr 11 12:31:56 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA27941
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 12:31:56 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 63B8B5DF12; Wed, 11 Apr 2001 12:25:04 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 47C985DF15; Wed, 11 Apr 2001 12:25:04 -0400 (EDT)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by segue.merit.edu (Postfix) with ESMTP id 177125DF12
	for <aaa-wg@merit.edu>; Wed, 11 Apr 2001 12:25:02 -0400 (EDT)
Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f3BGP0s24513
	for <aaa-wg@merit.edu>; Wed, 11 Apr 2001 18:25:00 +0200 (MEST)
Received: FROM esealnt743.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Wed Apr 11 18:24:59 2001 +0200
Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <HA3DFX9V>; Wed, 11 Apr 2001 18:24:59 +0200
Message-ID: <577066326047D41180AC00508B955DDA01D7FF7C@eestqnt104.es.eu.ericsson.se>
From: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>
To: "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>,
        "'pcalhoun@nasnfs.Eng.Sun.COM'" <pcalhoun@nasnfs.Eng.Sun.COM>
Cc: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>
Subject: [AAA-WG]: Few comments on draft-ietf-aaa-diameter-mobileip-02.txt
Date: Wed, 11 Apr 2001 18:24:56 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Hi,

Section 1.3, page 7: At the end of the first paragraph, it should be mentionned that the AAAF is responsible for allocating a HA.

page 8: "If a Home Agent was specified, and it belongs to a different domain than the Foreign Agent in the MIP-Previous-FA-FQDN AVP, the AAAH MUST verify whether it will permit this type of the service to the Mobile Node."

I still do not understand that.
It is the text, which suggests that the AAAH MUST verify whether or
not it will allow a HA to be kept in a Foreign Network different
than the actual FA, only if the MIP-Previous-FA-FQDN AVP and 
MIP-Home-Agent-Address AVP are in different domains. Since both
entities will most probably be from the same domain (in the case where
the FA and HA are in the foreign domain, which is recommended for route
optimization), then no check should be performed, according to your text, right? 
I guess that it is not what you really wanted to express, but rather when an AAAH
receives a MIP-Previous-FA-FQDN AVP, the AAAH deduces that the MN
has moved to a new domain, and then must check if a 
MIP-Home-Agent-Address AVP was present in that same network, in which case
it must take a decision whether or not to allow the HA to be used.

Page 9: "...the optional KDC session keys to the AAAF in foreign network 1."

I think that line does not fit in the text.

Page 9: "If the old Foreign Network does not permit the use of its Home Agent
   when the Mobile Node moves to a new foreign network, the Mobile Node
   MAY allocate a new Home Agent in its current network, as described
   above."

First, I guess it should say "...the AAAH or the AAAF MAY allocate..."

Second, what does it imply exactly? If the MN changes HA, then it means that it will also change Home address??? Does it make any sense to support that?

Section 2.1: To the list of information extracted from the Registration messages, maybe we should also add the MN-HA Key Request and the MN-FA Key Request?

It should also be mentionned that of the Home Agent Address is 0.0.0.0 or 255.255.255.255, then the corresponding AVP must not be present.

In the message, the Session-ID should be in < >. I guess the Destination-FQDN should be {}. The Integrity-Check AVP should be removed from all the messages in the document.

Section 2.2: "A successful AMA message MUST include the MIP-Home-Agent-Address AVP."

The MIP-Home-Mobile-Node-Address AVP and MIP-Reg-Reply AVP as well.

Section 2.3: "If the Home Agent is to be assigned in a foreign network, the HAR is issued by AAAF."

I guess it should be "...the HAR is issued by the AAAH and forwared by the AAAF."


That's it for now.
Martin



From owner-aaa-bof@merit.edu  Wed Apr 11 12:37:02 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA28121
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 12:37:02 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Wed Apr 11 13:01:24 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA28888
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 13:01:24 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Wed Apr 11 13:12:16 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA29116
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 13:12:15 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 58D405DE4C; Wed, 11 Apr 2001 12:02:07 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 43A955DE4B; Wed, 11 Apr 2001 12:02:07 -0400 (EDT)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by segue.merit.edu (Postfix) with ESMTP id F263A5DE3F
	for <aaa-wg@merit.edu>; Wed, 11 Apr 2001 12:02:04 -0400 (EDT)
Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f3BG20s16758
	for <aaa-wg@merit.edu>; Wed, 11 Apr 2001 18:02:00 +0200 (MEST)
Received: FROM esealnt743.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Wed Apr 11 18:01:59 2001 +0200
Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <HA3DFXHC>; Wed, 11 Apr 2001 18:01:59 +0200
Message-ID: <577066326047D41180AC00508B955DDA01D7FF7B@eestqnt104.es.eu.ericsson.se>
From: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>
To: "'pcalhoun@nasnfs.Eng.Sun.COM'" <pcalhoun@nasnfs.Eng.Sun.COM>,
        "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>
Subject: FW: [AAA-WG]: Message Forwarding and Routing Proposed text
Date: Wed, 11 Apr 2001 18:01:53 +0200
X-Message-Flag: Follow up
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C0C2A0.B9A491E0"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C0C2A0.B9A491E0
Content-Type: text/plain;
	charset="iso-8859-1"

Hi Pat,

From reading the Base-02, it is still not clear that the Destination-FQDN AVP must be present in every Responses, in order to route messages towards the Originating node, i.e. the last hop. I thought it was clear, as described in the enclosed e-mail from February. I think that we should not be counting on the Proxy-State AVP for providing that functionality.

Regards,
Martin


> -----Original Message-----
> From: Bob Kopacz [mailto:BKopacz@InterlinkNetworks.com] 
> Sent: Monday, February 12, 2001 11:57 PM
> To: David Spence; Pat Calhoun
> Cc: Aaa-Wg
> Subject: RE: [diameter] Re: [AAA-WG]: Message Forwarding and Routing
> Proposed text
> 
> 
> Hi Pat and Dave,
> 
> I put together a diagram which I think represents what
> you two are saying about how Diameter does routing.
> 
> It's more than 80 columns, so I'm sending it as an 
> attachment to avoid line-wrapping.  It's a simple .txt 
> file based on one of the diagrams in the base draft.
> 
> I hope it's right.
> 
> Bob K.
> 


------_=_NextPart_000_01C0C2A0.B9A491E0
Content-Type: text/plain;
	name="DiameterRoutingPicture.txt"
Content-Disposition: attachment;
	filename="DiameterRoutingPicture.txt"

The AVPs involved in Routing:
=============================

Host-Name           (FQDN) = ultimate originator of message, either NAS or home server.
Destination AVP     (FQDN) = ultimate destination of message
Route-Record        (FQDN) = FQDN of some proxy
Routing-Realm (NAI), or User-Name if Routing-Realm not present


Routing of Request/Response
=============================

              (Request)                   (Request)                  (Request)
        User-Name=joe@abc.com       User-Name=joe@abc.com       User-Name=joe@abc.com
        Host-Name=nas1.mno.net      Host-Name=nas1.mno.net      Host-Name=nas1.mno.net
        No Destination-AVP          No Destination-AVP          No Destination-AVP
                                  + Route-Record=dia1.mno.net   Route-Record=dia1.mno.net
                                                              + Route-Record=dia2.xyz.com

                  1                           2                          3
 +------+      ------>      +-------+      ------>      +------+      ------>      +------+
 |      |                   |       |                   |      |                   |      |
 | NAS1 +-------------------+  DIA1 +-------------------+ DIA2 +-------------------+ DIA3 |
 |      |                   |       |                   |      |                   |      |
 +------+      <------      +-------+      <------      +------+      <------      +------+
  mno.net         6           mno.net         5          xyz.com         4          abc.com

              (Response)                  (Response)                 (Response)
        User-Name=joe@abc.com       User-Name=joe@abc.com       User-Name=joe@abc.com
        Host-Name=dia3.abc.com      Host-Name=dia3.abc.com      Host-Name=dia3.abc.com
        DestinationAVP=nas1.mno.net DestinationAVP=nas1.mno.net DestinationAVP=nas1.mno.net
                                    Route-Record=dia1.mno.net   Route-Record=dia1.mno.net
                                                                Route-Record=dia2.xyz.com


1. NAS1->DIA1: route on realm portion of User-Name (=abc.com)
2. DIA1->DIA2: route on realm portion of User-Name (=abc.com), add Route-Record
3. DIA2->DIA3: route on realm portion of User-Name (=abc.com), add Route-Record

4. DIA2<-DIA3: route on Route-Record=dia2...
5. DIA1<-DIA2: route on Route-Record=dia1..., remove Route-Record.
6. NAS1<-DIA1: route on Dest-AVP=nas1...    , remove Route-Record.


Routing of Indication
======================


 +------+                   +-------+                   +------+                   +------+
 |      |                   |       |                   |      |                   |      |
 | NAS1 +-------------------+  DIA1 +-------------------+ DIA2 +-------------------+ DIA3 |
 |      |                   |       |                   |      |                   |      |
 +------+      <------      +-------+      <------      +------+      <------      +------+
  mno.net         3           mno.net         2          xyz.com         1          abc.com

             (Indication)                (Indication)                (Indication)
        User-Name=joe@abc.com       User-Name=joe@abc.com       User-Name=joe@abc.com
        Host-Name=dia3.abc.com      Host-Name=dia3.abc.com      Host-Name=dia3.abc.com
        DestinationAVP=nas1.mno.net DestinationAVP=nas1.mno.net DestinationAVP=nas1.mno.net
        Routing-Realm=NAS's realm   Routing-Realm=NAS's realm   Routing-Realm=NAS's realm
        Route-Record=dia2.xyz.com   Route-Record=dia2.xyz.com
        Route-Record=dia1.mno.net


1. DIA2<-DIA3: route on Routing-Realm=NAS's realm...
2. DIA1<-DIA2: route on Routing-Realm=NAS's realm...., add Route-Record
3. NAS1<-DIA1: route on Dest-AVP=nas1..., add Route-Record

Question: How does DIA3 know the NAS's realm, for the Routine-Realm AVP?




------_=_NextPart_000_01C0C2A0.B9A491E0--



From owner-aaa-bof@merit.edu  Wed Apr 11 13:34:37 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA29496
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 13:34:37 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Wed Apr 11 13:45:38 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA29686
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 13:45:38 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 19EAF5DF67; Wed, 11 Apr 2001 13:34:03 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id F40C55DF6C; Wed, 11 Apr 2001 13:34:02 -0400 (EDT)
Received: from forsete.erilab.com (forsete.erilab.com [208.224.156.105])
	by segue.merit.edu (Postfix) with ESMTP id 6F06A5DF67
	for <aaa-wg@merit.edu>; Wed, 11 Apr 2001 13:34:00 -0400 (EDT)
Received: from erilab.com (eblcl50.erilab.com [192.168.174.190])
	by forsete.erilab.com (8.11.0/8.11.0) with ESMTP id f3BHXxo02781;
	Wed, 11 Apr 2001 10:33:59 -0700 (PDT)
Message-ID: <3AD4959E.6C670F24@erilab.com>
Date: Wed, 11 Apr 2001 10:34:22 -0700
From: Michael Chen <cchen@erilab.com>
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: pcalhoun@eng.sun.com, aaa-wg@merit.edu
Subject: [AAA-WG]: Re: Route-Record AVP in Indication message
References: <200104111303.GAA12450@nasnfs.Eng.Sun.COM>
Content-Type: multipart/alternative;
 boundary="------------6EBE333340786FD8C58E620D"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk


--------------6EBE333340786FD8C58E620D
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

> > AAA1(a.com) AAA2(b.com)  AAA3(c.com)   AAA4(d.com)
> >----------  -----------  -----------   ------------
> >
> >     ----------->
> >     route-record=aaa1.a.com
> >
> >                 ------------->
> >                 route-record=aaa1.a.com
> >                 route-record=aaa2.b.com
> >
> >                               -----link broken---
> >
> >                 <-------------
> >                 route-record=aaa3.c.com
> >     <-------------
> >     route-record=aaa3.c.com
> >     route-record=aaa2.b.com
>
> However, since the DSI message you mention here is *not* a response to the
> request that generated the message, it MUST NOT include the route-record AVPs
> that were present in the request.

OK. The DSI message is NOT a response to the request.    That's say the
AAA3 use Destination-Realm to route the DSI message and send the
DSI "directly" to AAA1 instead of AAA2.   Here is the problem.  AAA2
would NEVER receive any RESPONSE after send out the request.


--------------6EBE333340786FD8C58E620D
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>

<blockquote TYPE=CITE><tt>> AAA1(a.com) AAA2(b.com)&nbsp; AAA3(c.com)&nbsp;&nbsp;
AAA4(d.com)</tt>
<br><tt>>----------&nbsp; -----------&nbsp; -----------&nbsp;&nbsp; ------------</tt>
<br><tt>></tt>
<br><tt>>&nbsp;&nbsp;&nbsp;&nbsp; -----------></tt>
<br><tt>>&nbsp;&nbsp;&nbsp;&nbsp; route-record=aaa1.a.com</tt>
<br><tt>></tt>
<br><tt>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
-------------></tt>
<br><tt>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
route-record=aaa1.a.com</tt>
<br><tt>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
route-record=aaa2.b.com</tt>
<br><tt>></tt>
<br><tt>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
-----link broken---</tt>
<br><tt>></tt>
<br><tt>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&lt;-------------</tt>
<br><tt>>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
route-record=aaa3.c.com</tt>
<br><tt>>&nbsp;&nbsp;&nbsp;&nbsp; &lt;-------------</tt>
<br><tt>>&nbsp;&nbsp;&nbsp;&nbsp; route-record=aaa3.c.com</tt>
<br><tt>>&nbsp;&nbsp;&nbsp;&nbsp; route-record=aaa2.b.com</tt><tt></tt>
<p><tt>However, since the DSI message you mention here is *not* a response
to the</tt>
<br><tt>request that generated the message, it MUST NOT include the route-record
AVPs</tt>
<br><tt>that were present in the request.</tt></blockquote>
<tt>OK. The DSI message is NOT a response to the request.&nbsp;&nbsp;&nbsp;
That's say the</tt>
<br><tt>AAA3 use Destination-Realm to route the DSI message and send the</tt>
<br><tt>DSI "directly" to AAA1 instead of AAA2.&nbsp;&nbsp; Here is the
problem.&nbsp; AAA2</tt>
<br><tt>would NEVER receive any RESPONSE after send out the request.</tt>
<br>&nbsp;</html>

--------------6EBE333340786FD8C58E620D--




From owner-aaa-bof@merit.edu  Wed Apr 11 14:00:04 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA29983
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 14:00:04 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Wed Apr 11 14:15:10 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA00386
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 14:15:10 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 8FA555DE98; Wed, 11 Apr 2001 11:53:59 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 7D4F75DE97; Wed, 11 Apr 2001 11:53:59 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by segue.merit.edu (Postfix) with ESMTP id 90C775DE3B
	for <aaa-wg@merit.edu>; Wed, 11 Apr 2001 11:53:57 -0400 (EDT)
Received: from mira-sjcm-3.cisco.com (mira-sjcm-3.cisco.com [171.69.43.101])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id IAA18910;
	Wed, 11 Apr 2001 08:53:57 -0700 (PDT)
Received: from johnalw2k (dhcp-161-44-29-177.cisco.com [161.44.29.177])
	by mira-sjcm-3.cisco.com (Mirapoint)
	with SMTP id ABU10471;
	Wed, 11 Apr 2001 08:53:53 -0700 (PDT)
From: "John Alayari" <johnal@cisco.com>
To: <pcalhoun@eng.sun.com>
Cc: <aaa-wg@merit.edu>
Subject: [AAA-WG]: redirect event
Date: Wed, 11 Apr 2001 08:52:55 -0700
Message-ID: <CNEGKCBENOKKPJPNCEODIEGBCCAA.johnal@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <200104111423.HAA13167@nasnfs.Eng.Sun.COM>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Pat,

In section 12.3.1 of base 02: 

"The Redirect-Host AVP (AVP Code 292) is of type Grouped and is found
   in Device-Status-Ind messages that include the DSI-Event AVP set to
   DIAMETER_REDIRECT_REQUEST"

Do you mean "DIAMETER_REDIRECT_INDICATION" ? or this is a new one?

John



From owner-aaa-bof@merit.edu  Wed Apr 11 14:16:35 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA00411
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 14:16:35 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Wed Apr 11 14:33:58 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA00617
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 14:33:58 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Wed Apr 11 14:48:41 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA00920
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 14:48:36 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Wed Apr 11 15:07:29 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA01287
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 15:07:28 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Wed Apr 11 15:10:08 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA01338
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 15:10:08 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 4C9C75DD94; Wed, 11 Apr 2001 15:09:57 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 37FDC5DDAF; Wed, 11 Apr 2001 15:09:57 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id C55155DD94
	for <aaa-wg@merit.edu>; Wed, 11 Apr 2001 15:09:55 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA19490;
	Wed, 11 Apr 2001 12:08:30 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA06564;
	Wed, 11 Apr 2001 12:09:50 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (eastapp2.East.Sun.COM [129.148.162.99])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id MAA18654;
	Wed, 11 Apr 2001 12:09:26 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Message-Id: <200104111909.MAA18654@nasnfs.Eng.Sun.COM>
Date: Wed, 11 Apr 2001 15:05:09 -0700
To: "Michael Chen" <cchen@erilab.com>, <aaa-wg@merit.edu>
Reply-To: <pcalhoun@eng.sun.com>
Subject: Re: [AAA-WG]: Re: Route-Record AVP in Indication message
X-Mailer: Sun NetMail 2.3
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit


>OK. The DSI message is NOT a response to the request.    That's say the
>AAA3 use Destination-Realm to route the DSI message and send the
>DSI "directly" to AAA1 instead of AAA2.   Here is the problem.  AAA2
>would NEVER receive any RESPONSE after send out the request.
>

The following text below states that AAA2 must keep all pending messages
in a queue. So, if these messages are queued, the appropriate responses
can be generated by AAA3, and they would include the correct routing AVPs.

7.3  Failover/Failback Procedures

   In the event that a transport failure is detected with a peer, it is
   necessary for all pending request, query and indication messages to
   be forwarded to an alternate server, if possible. This is commonly
   referred to as failover.

   In order for a Diameter node to perform failover procedures, it is
   necessary for the node to maintain a pending message queue for a
   given peer. When a response is received, the message is removed from
   the queue. The Hop-by-Hop Identifier field MAY be used to match the
   corresponding response with the queued request.

   [...]

PatC




From owner-aaa-bof@merit.edu  Wed Apr 11 15:30:57 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA01652
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 15:30:56 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Wed Apr 11 15:56:10 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA01953
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 15:56:09 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Wed Apr 11 16:16:26 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA02330
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 16:16:26 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Wed Apr 11 16:20:15 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA02426
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 16:20:15 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 8B6795DF76; Wed, 11 Apr 2001 14:46:05 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 6D2155DF84; Wed, 11 Apr 2001 14:46:05 -0400 (EDT)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id CD9D75DF76
	for <aaa-wg@merit.edu>; Wed, 11 Apr 2001 14:46:03 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06919;
	Wed, 11 Apr 2001 11:46:01 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA27612;
	Wed, 11 Apr 2001 11:46:00 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (eastapp2.East.Sun.COM [129.148.162.99])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id LAA18212;
	Wed, 11 Apr 2001 11:45:37 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Message-Id: <200104111845.LAA18212@nasnfs.Eng.Sun.COM>
Date: Wed, 11 Apr 2001 14:41:20 -0700
To: "John Alayari" <johnal@cisco.com>
Cc: <aaa-wg@merit.edu>
Reply-To: <pcalhoun@eng.sun.com>
Subject: Re: [AAA-WG]: redirect event
X-Mailer: Sun NetMail 2.3
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

A typo, and I will fix it in -03.

Thanks for the catch.

PatC
>Pat,
>
>In section 12.3.1 of base 02: 
>
>"The Redirect-Host AVP (AVP Code 292) is of type Grouped and is found
>   in Device-Status-Ind messages that include the DSI-Event AVP set to
>   DIAMETER_REDIRECT_REQUEST"
>
>Do you mean "DIAMETER_REDIRECT_INDICATION" ? or this is a new one?
>
>John
>





From owner-aaa-bof@merit.edu  Wed Apr 11 16:34:21 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA02872
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 16:34:21 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Wed Apr 11 17:00:49 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA03250
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 17:00:48 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Wed Apr 11 17:23:44 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA03566
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 17:23:44 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 78E9E5E186; Wed, 11 Apr 2001 17:16:07 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id B598B5E012; Wed, 11 Apr 2001 17:15:42 -0400 (EDT)
Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10])
	by segue.merit.edu (Postfix) with ESMTP id E1EE45DFEB
	for <aaa-wg@merit.edu>; Wed, 11 Apr 2001 17:09:35 -0400 (EDT)
Received: from mira-sjcm-3.cisco.com (mira-sjcm-3.cisco.com [171.69.43.101])
	by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id OAA24270;
	Wed, 11 Apr 2001 14:09:39 -0700 (PDT)
Received: from johnalw2k (dhcp-161-44-29-177.cisco.com [161.44.29.177])
	by mira-sjcm-3.cisco.com (Mirapoint)
	with SMTP id ABV08096;
	Wed, 11 Apr 2001 14:09:34 -0700 (PDT)
From: "John Alayari" <johnal@cisco.com>
To: <pcalhoun@eng.sun.com>
Cc: <aaa-wg@merit.edu>
Subject: RE: [AAA-WG]: Re: Accounting-status-Ind & interim data
Date: Wed, 11 Apr 2001 14:08:37 -0700
Message-ID: <CNEGKCBENOKKPJPNCEODAEGICCAA.johnal@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <200104111952.MAA19361@nasnfs.Eng.Sun.COM>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

In the case when the client is about to be disabled and the usage
information accumulated in the local interim data storage may be lost, the
server may get the latest accumulated data.

John.

-----Original Message-----
From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf
Of Patrice Calhoun
Sent: Wednesday, April 11, 2001 3:48 PM
To: John Alayari
Cc: aaa-wg@merit.edu
Subject: [AAA-WG]: Re: Accounting-status-Ind & interim data


>can we add accounting-Interim-interval AVP to Accounting-Status-Ind command
>(in section 14.3 of base). So interim data can be sent as well?

I suppose, but I would have to ask why. The message you refer to is used to
inform the AAA server that accounting is enabled, or disabled. So I don't
see
why an interim interval could be used in that particular message.

Could you please share your thoughts on when this would be used?

Thanks,

PatC





From owner-aaa-bof@merit.edu  Wed Apr 11 17:43:41 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA03908
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 17:43:36 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Wed Apr 11 17:45:26 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA03946
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 17:45:26 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id C157D5DEAF; Wed, 11 Apr 2001 15:48:48 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id AEFF35DEAD; Wed, 11 Apr 2001 15:48:48 -0400 (EDT)
Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88])
	by segue.merit.edu (Postfix) with ESMTP id DFA685DE86
	for <aaa-wg@merit.edu>; Wed, 11 Apr 2001 15:48:41 -0400 (EDT)
Received: from mira-sjcm-3.cisco.com (mira-sjcm-3.cisco.com [171.69.43.101])
	by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id MAA27893;
	Wed, 11 Apr 2001 12:49:05 -0700 (PDT)
Received: from johnalw2k (dhcp-161-44-29-177.cisco.com [161.44.29.177])
	by mira-sjcm-3.cisco.com (Mirapoint)
	with SMTP id ABV05851;
	Wed, 11 Apr 2001 12:48:40 -0700 (PDT)
From: "John Alayari" <johnal@cisco.com>
To: <pcalhoun@eng.sun.com>
Cc: <aaa-wg@merit.edu>
Subject: [AAA-WG]: Accounting-status-Ind & interim data
Date: Wed, 11 Apr 2001 12:47:42 -0700
Message-ID: <CNEGKCBENOKKPJPNCEODGEGGCCAA.johnal@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <200104111845.LAA18212@nasnfs.Eng.Sun.COM>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Pat,

can we add accounting-Interim-interval AVP to Accounting-Status-Ind command
(in section 14.3 of base). So interim data can be sent as well?

John.





From owner-aaa-bof@merit.edu  Wed Apr 11 17:49:04 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA03985
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 17:49:04 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 06A375DF58; Wed, 11 Apr 2001 15:53:04 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id E44735DF56; Wed, 11 Apr 2001 15:53:03 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id 57FBA5DEE1
	for <aaa-wg@merit.edu>; Wed, 11 Apr 2001 15:53:01 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA08978;
	Wed, 11 Apr 2001 12:51:37 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA16586;
	Wed, 11 Apr 2001 12:52:57 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (eastapp2.East.Sun.COM [129.148.162.99])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id MAA19361;
	Wed, 11 Apr 2001 12:52:23 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Message-Id: <200104111952.MAA19361@nasnfs.Eng.Sun.COM>
Date: Wed, 11 Apr 2001 15:48:16 -0700
To: "John Alayari" <johnal@cisco.com>
Cc: <aaa-wg@merit.edu>
Reply-To: <pcalhoun@eng.sun.com>
Subject: [AAA-WG]: Re: Accounting-status-Ind & interim data
X-Mailer: Sun NetMail 2.3
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

>can we add accounting-Interim-interval AVP to Accounting-Status-Ind command
>(in section 14.3 of base). So interim data can be sent as well?

I suppose, but I would have to ask why. The message you refer to is used to
inform the AAA server that accounting is enabled, or disabled. So I don't see
why an interim interval could be used in that particular message.

Could you please share your thoughts on when this would be used?

Thanks,

PatC




From owner-aaa-bof@merit.edu  Wed Apr 11 17:51:30 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA04008
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 17:51:30 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 8AA095DF2B; Wed, 11 Apr 2001 17:48:45 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id EBF655E134; Wed, 11 Apr 2001 17:39:27 -0400 (EDT)
Received: from zrtps06u.us.nortel.com (h52s48a140n47.user.nortelnetworks.com [47.140.48.52])
	by segue.merit.edu (Postfix) with ESMTP id 1DF055E122
	for <aaa-wg@merit.edu>; Wed, 11 Apr 2001 17:27:53 -0400 (EDT)
Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57])
	by zrtps06u.us.nortel.com (8.11.0/8.11.0) with ESMTP id f3BLQTq15955
	for <aaa-wg@merit.edu>; Wed, 11 Apr 2001 17:26:29 -0400 (EDT)
Received: from zcard00m.ca.nortel.com by zcars04f.ca.nortel.com;
          Wed, 11 Apr 2001 17:27:34 -0400
Received: from zbl6c008.corpeast.baynetworks.com ([132.245.205.58]) 
          by zcard00m.ca.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) 
          id 2M6KX0JQ; Wed, 11 Apr 2001 17:27:33 -0400
Received: from mitton.nortelnetworks.com (47.16.86.121 [47.16.86.121]) 
          by zbl6c008.corpeast.baynetworks.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) 
          id G0CX4F0L; Wed, 11 Apr 2001 17:27:33 -0400
Message-Id: <4.3.2.7.2.20010411172630.00bd5a60@ZBL6C008.corpeast.baynetworks.com>
X-Sender: dmitton@ZBL6C008.corpeast.baynetworks.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
X-Priority: 2 (High)
Date: Wed, 11 Apr 2001 17:29:02 -0400
To: AAA-WG <aaa-wg@merit.edu>
From: "David Mitton" <dmitton@nortelnetworks.com>
Subject: [AAA-WG]: Need presentations for proceedings by tomorrow (4/12)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Orig: <dmitton@nortelnetworks.com>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

I need all presentations given at the last meeting by tomorrow, Thursday 
April 12th, to be included in the proceedings.

If you sent yours in already, Thanks.

	Dave.
---------------------------------------------------------------
David Mitton                                  ESN: 248-4570
Advisor, Nortel Networks                      978-288-4570 Direct
Wireless Solutions, IP Mobility
Billerica, MA 01821                    dmitton@nortelnetworks.com




From owner-aaa-bof@merit.edu  Wed Apr 11 18:10:39 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA04231
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 18:10:39 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Wed Apr 11 20:16:09 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA05382
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 20:16:08 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Wed Apr 11 22:19:10 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA07226
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 22:19:10 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Wed Apr 11 22:45:27 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA08462
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 22:45:27 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Wed Apr 11 23:03:39 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA08562
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 23:03:39 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Wed Apr 11 23:36:26 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA09146
	for <aaa-archive@odin.ietf.org>; Wed, 11 Apr 2001 23:36:26 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 00:00:12 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA09369
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 00:00:12 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 00:22:48 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA09581
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 00:22:47 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 00:49:08 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA09866
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 00:49:07 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 01:04:18 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA09959
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 01:04:17 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 01:21:38 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA11334
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 01:21:38 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 487CA5DECF; Wed, 11 Apr 2001 23:50:33 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 1AECB5DEFC; Wed, 11 Apr 2001 23:50:33 -0400 (EDT)
Received: from fep02-app.kolumbus.fi (fep02-0.kolumbus.fi [193.229.0.44])
	by segue.merit.edu (Postfix) with ESMTP id 16FA75DECF
	for <aaa-wg@merit.edu>; Wed, 11 Apr 2001 23:50:31 -0400 (EDT)
Received: from jariws1 ([193.229.23.19]) by fep02-app.kolumbus.fi
          (InterMail vM.5.01.02.00 201-253-122-103-20001017) with SMTP
          id <20010412035030.KDJO16604.fep02-app.kolumbus.fi@jariws1>;
          Thu, 12 Apr 2001 06:50:30 +0300
Message-ID: <00ee01c0c309$9ced6720$8a1b6e0a@arenanet.fi>
From: "Jari Arkko" <jari.arkko@kolumbus.fi>
To: "John Alayari" <johnal@cisco.com>, <pcalhoun@eng.sun.com>
Cc: <aaa-wg@merit.edu>
References: <CNEGKCBENOKKPJPNCEODAEGICCAA.johnal@cisco.com>
Subject: Re: [AAA-WG]: Re: Accounting-status-Ind & interim data
Date: Thu, 12 Apr 2001 07:32:41 +0300
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit


> In the case when the client is about to be disabled and the usage
> information accumulated in the local interim data storage may be lost, the
> server may get the latest accumulated data.

I still have trouble understanding how the accounting-Interim-interval
AVP will help in this situation. That particular AVP is just for the authorization
or the accounting server to inform the client about how often it should
generate the interim records. Are you suggesting to send this AVP
with information about the planned outage at the client side so that the
server can use it for something?

Or are you thinking of sending the actual latest records? In that
case much more may be needed than this single AVP... and maybe
not even just one message, several, one for each session towards
that particular realm.

If the latter issue was your intention, there may also be other ways
of doing this. We could state something about the desired behaviour
of a Diameter client wrt existing client records when it is about to
stop accounting. For instance, we could say that Diameter clients
SHOULD try to send the latest interim records just before sending
the ASI.

By the way, it seems that the specification on who the ASI command
is really sent to is somewhat unclear. The text in 14.3 talks about the
"peer" but the AVPs such as the Destination-Realm in the message
might indicate more an end-to-end message... I' m not really sure
which one we even should prefer, because the peer variant is
a quick single message but not so useful, and the e2e variant could
be many messages but is on the other hand more useful.

Jari






From owner-aaa-bof@merit.edu  Thu Apr 12 01:23:25 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA11515
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 01:23:25 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 01:45:11 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA14064
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 01:45:11 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 02:06:07 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA23423
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 02:06:07 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 02:30:05 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA23877
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 02:30:04 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 02:51:25 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA23991
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 02:51:25 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 03:00:29 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA24045
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 03:00:29 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 78BF15E11A; Wed, 11 Apr 2001 17:27:23 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id BB6245DEE3; Wed, 11 Apr 2001 17:25:25 -0400 (EDT)
Received: from forsete.erilab.com (forsete.erilab.com [208.224.156.105])
	by segue.merit.edu (Postfix) with ESMTP id 80F0A5DEFE
	for <aaa-wg@merit.edu>; Wed, 11 Apr 2001 17:21:03 -0400 (EDT)
Received: from erilab.com (eblcl50.erilab.com [192.168.174.190])
	by forsete.erilab.com (8.11.0/8.11.0) with ESMTP id f3BLKvo03203;
	Wed, 11 Apr 2001 14:20:57 -0700 (PDT)
Message-ID: <3AD4CAB8.E69309F9@erilab.com>
Date: Wed, 11 Apr 2001 14:20:56 -0700
From: Michael Chen <cchen@erilab.com>
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: pcalhoun@eng.sun.com
Cc: aaa-wg@merit.edu
Subject: Re: [AAA-WG]: Re: Route-Record AVP in Indication message
References: <200104111909.MAA18654@nasnfs.Eng.Sun.COM>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Pat,

  I guess you misunderstood what I meant. Let me try it again.

Here is the request send to AAA4
AAA1->AAA2->AAA3---- link broken ---->AAA4

AAA3----send DSI---->AAA1

AAA3 must generate DSI and send it back to AAA1.
This DSI is NOT a response to the request so it MUST NOT include
the route-record AVPs that were present in the request.
AAA3 route the message base on Destination-Realm AVP and let's
say this DSI message routing result is  "directly" to AAA1 instead
of AAA2. My question is AAA2 keeping the pending request but AAA2
did NOT receive reply in this case.





Patrice Calhoun wrote:

DSI message you mention here is *not* a response to the
request that generated the message, it MUST NOT include the route-record AVPs
that were present in the request.

> >OK. The DSI message is NOT a response to the request.    That's say the
> >AAA3 use Destination-Realm to route the DSI message and send the
> >DSI "directly" to AAA1 instead of AAA2.   Here is the problem.  AAA2
> >would NEVER receive any RESPONSE after send out the request.
> >
>
> The following text below states that AAA2 must keep all pending messages
> in a queue. So, if these messages are queued, the appropriate responses
> can be generated by AAA3, and they would include the correct routing AVPs.
>

> AAA1(a.com) AAA2(b.com)  AAA3(c.com)   AAA4(d.com)
  >----------  -----------  -----------   ------------
  >
  >     ----------->
  >     route-record=aaa1.a.com
  >
  >                 ------------->
  >                 route-record=aaa1.a.com
  >                 route-record=aaa2.b.com
  >
  >                               -----link broken---
  >
  >                 <-------------
  >                 route-record=aaa3.c.com
  >     <-------------
  >     route-record=aaa3.c.com
  >     route-record=aaa2.b.com




From owner-aaa-bof@merit.edu  Thu Apr 12 03:15:11 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA24157
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 03:15:11 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 03:35:10 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA24290
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 03:35:09 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 03:49:17 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA24381
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 03:49:17 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id AD7315DF97; Wed, 11 Apr 2001 11:06:15 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9AA8C5DF96; Wed, 11 Apr 2001 11:06:15 -0400 (EDT)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id 2E1C15DDF3
	for <aaa-wg@merit.edu>; Wed, 11 Apr 2001 11:06:13 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA20311;
	Wed, 11 Apr 2001 08:06:10 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id IAA26042;
	Wed, 11 Apr 2001 08:06:06 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (eastapp2.East.Sun.COM [129.148.162.99])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id IAA13624;
	Wed, 11 Apr 2001 08:05:39 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Message-Id: <200104111505.IAA13624@nasnfs.Eng.Sun.COM>
Date: Wed, 11 Apr 2001 11:01:25 -0700
To: "Yolanda Garcia-Serrano (ECE)" <yolanda.garcia-serrano@ece.ericsson.se>,
        "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>
Reply-To: <pcalhoun@eng.sun.com>
Subject: Re: [AAA-WG]: Some editorial findings
X-Mailer: Sun NetMail 2.3
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit


>Hi, Pat
>
>Sorry for 'bothering' you with this e-mail, but maybe is useful for you to have
>these corrections to incorporate them
>in base-03  They are just small spelling errors. See bottom of the e-mail for
>some other questions.

Not a bother at all. I really appreciate these comments, and will make the
necessary changes in -03.

>
>Some other issues:
>==================
>
>- A reply is the generic term to refer to Answers (corresponding to Requests)
>or
>Responses (corresponding to Queries), right? Then, if possible, unify in the
>document
>(e.g. section 3.0, section 12.4.7)

You are correct.

>
>- Section 14: Extension-Id AVP is not needed anymore in the accounting messages
>as they belong to base stuff, right ?

The Accounting messages are used to identify the application that genereated
the accounting messages. It is necessary to validate if the Necessary AVPs
are present.

> (not needed in ACR, ACA, ASI, API and Accounting AVP Table section 16.2)
>- I've noticed section 1.4 from Accounting 01 has been dropped from base-02
>draft. Was not useful?

Correct. Since the usage AVPs have been moved to the relevant extension
documents, section 1.4.1 was moved to 1.4, and the old 1.4 was removed.

>- Same for Accounting-Authentication-Type AVP, which does not appear in base-02.
>Is it not needed anymore?

This is only useful for NASREQ services, so it was moved to the nasreq extension.

PatC




From owner-aaa-bof@merit.edu  Thu Apr 12 04:00:08 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA24429
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 04:00:07 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 04:18:54 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA24531
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 04:18:53 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 04:36:30 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA24678
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 04:36:30 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 05:00:10 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA24883
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 05:00:10 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 05:22:33 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA25088
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 05:22:28 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id EE8DE5DE4B; Wed, 11 Apr 2001 14:00:46 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9A68E5DDB4; Wed, 11 Apr 2001 14:00:46 -0400 (EDT)
Received: from forsete.erilab.com (forsete.erilab.com [208.224.156.105])
	by segue.merit.edu (Postfix) with ESMTP id 7862C5DDB4
	for <aaa-wg@merit.edu>; Wed, 11 Apr 2001 14:00:44 -0400 (EDT)
Received: from erilab.com (eblcl50.erilab.com [192.168.174.190])
	by forsete.erilab.com (8.11.0/8.11.0) with ESMTP id f3BI0ho02827;
	Wed, 11 Apr 2001 11:00:43 -0700 (PDT)
Message-ID: <3AD49BDF.52945F04@erilab.com>
Date: Wed, 11 Apr 2001 11:01:03 -0700
From: Michael Chen <cchen@erilab.com>
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: pcalhoun@eng.sun.com, aaa-wg@merit.edu
Cc: BKopacz@InterlinkNetworks.com
Subject: [AAA-WG]: Re: Destination-FQDN AVP
References: <200104111423.HAA13167@nasnfs.Eng.Sun.COM>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit


Between Diameter servers, we ONLY route message base on Route-Record or
Destination-Realm AVP.   Route message base on Destination-FQDN ONLY happan
in local messaage(between NAS and Diameter). In your reply, we do have
Destination-FQDN in STR message but we need route the message by
Destination-Realm.  Do you think so?   Well, if it's correct, we need modify
section 5.0.

Well, Fredrik pointed out "why do we need both Destiation-Realm and
Destination-FQDN? Isn't this redundant information?" I agree with him.
Destination-Realm just realm part of user name in the request and
Destination-Realm is just part of Destination-FQDN in the reply or Indication
message. Am I missing something here?


Patrice Calhoun wrote:

> >In base protocol section 5.0
> >
> >"When a Diameter entity receives a Diameter message of type Request,
> >   Query or Indication that includes a Destination-FQDN AVP, and the
> >   host specified in the AVP can be contacted directly, the message MUST
> >
> >   be forwarded to the host in question. ..........."
> >
> >As I know, there is NO Destination-FQDN AVP in the "Request" or "Query"
> >Message.
> >So I don't understand what you are trying to say. Am I missing something
> >here?
>
> Huh?
>
>       <Session-Termination-Request>  ::= < Diameter Header: 275 >
>                                          < Session-Id >
>                                          { Origin-FQDN }
>                                          { Origin-Realm }
>                                          { User-Name }
>                                          { Destination-Realm }
>                                          { Destination-FQDN } <----
>                                        * [ AVP ]
>                                        * [ Proxy-State ]
>                                        * [ Route-Record ]
>
> PatC




From owner-aaa-bof@merit.edu  Thu Apr 12 05:24:37 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA25102
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 05:24:37 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 05:32:09 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA25182
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 05:32:09 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id E03875DDC3; Thu, 12 Apr 2001 05:07:24 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id C085D5DEE0; Thu, 12 Apr 2001 05:07:24 -0400 (EDT)
Received: from mgw-x4.nokia.com (mgw-x4.nokia.com [131.228.20.27])
	by segue.merit.edu (Postfix) with ESMTP
	id 1070B5DDC3; Thu, 12 Apr 2001 05:07:21 -0400 (EDT)
Received: from esvir04nok.ntc.nokia.com (esvir04nokt.ntc.nokia.com [172.21.143.36])
	by mgw-x4.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f3C82o820109;
	Thu, 12 Apr 2001 11:02:50 +0300 (EET DST)
Received: from esebh25nok.ntc.nokia.com (unverified) by esvir04nok.ntc.nokia.com
 (Content Technologies SMTPRS 4.2.1) with ESMTP id <T52de905a71ac158f24078@esvir04nok.ntc.nokia.com>;
 Thu, 12 Apr 2001 11:02:00 +0300
Received: by esebh25nok with Internet Mail Service (5.5.2652.78)
	id <H9SA5V3V>; Thu, 12 Apr 2001 11:01:58 +0300
Message-ID: <6D1A8E7871B9D211B3B00008C7490AA504E625AD@treis03nok>
From: henry.haverinen@nokia.com
To: ietf-ppp@merit.edu, aboba@internaut.com, aaa-wg@merit.edu
Subject: [AAA-WG]: RE: Comments on draft-ietf-pppext-eap-srp-01.txt
Date: Thu, 12 Apr 2001 11:01:54 +0300
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2652.78)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk


> From: ext Bernard Aboba [mailto:aboba@internaut.com]

> In other words, according to RFC 2284, an EAP Success packet MUST
> NOT contain a type field or data. This is a result of the lack of
> ACK'ing, as described above. Given that EAP Success messages
> conforming to RFC 2284 do not contain data, existing implementations
> will typically not pass anything contained beyond the length field
> to the EAP method. There are also NAS devices that will not forward
> such packets on to the client.
> 
> My recommendation is to add an additional round-trip to the protocol
> and use the RFC 2284-defined EAP Success message. As much as I
> would love to fix RFC 2284 to permit this usage, I think
> that this would also require addressing the lack of ACKs for
> Success and Failure messages, which would create a backward
> compatiblity problem, so I can't see a way to make this work.

I guess this additional round-trip means that the last EAP-Response 
the client sends doesn't contain any actual data but it is just 
an acknowledgement.

Could we avoid the additional NAS-AAA-NAS round-trip by making the AAA
server 
indicate success already in the AAA message that contains the last
EAP-Request?
For example, the AAA server could include an attribute that tells the NAS
device
"if you recognize this attribute, you can consider the authentication
to be accepted". Hence, the NAS box could compose the EAP Success
packet to the client itself after getting the last EAP-Response fron the
client.

If the NAS doesn't recognize the new attribute, then things will still
work but an extra round-trip is required. So this fix would be backward
compatible.

Do you think this could work? It would be very nice to have some 
solution to avoid these extra roundtrips in EAP.

Regards,
Henry



From owner-aaa-bof@merit.edu  Thu Apr 12 05:46:24 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA25331
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 05:46:23 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 06:03:48 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA25542
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 06:03:47 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 06:16:25 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA25583
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 06:16:24 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id BAA5F5DE4A; Thu, 12 Apr 2001 05:20:16 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id A7A3F5DE58; Thu, 12 Apr 2001 05:20:16 -0400 (EDT)
Received: from mailgw.local.ipunplugged.com (unknown [213.88.134.217])
	by segue.merit.edu (Postfix) with ESMTP id 6F1695DE4A
	for <aaa-wg@merit.edu>; Thu, 12 Apr 2001 05:20:14 -0400 (EDT)
Received: from fredrikj (c42.local.ipunplugged.com [192.168.4.241])
	by mailgw.local.ipunplugged.com (8.9.3/8.9.3) with SMTP id KAA10569;
	Thu, 12 Apr 2001 10:03:43 +0200
From: "Fredrik Johansson" <fredrik.johansson@ipunplugged.com>
To: <pcalhoun@eng.sun.com>,
        "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>,
        "Tony Johansson" <tony.johansson@ericsson.com>
Cc: "AAA Listan" <aaa-wg@merit.edu>
Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
Date: Thu, 12 Apr 2001 10:04:20 +0200
Message-ID: <MJEMJBGGCLLDLFFAHLJKIEPMCJAA.fredrik.johansson@ipunplugged.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
In-Reply-To: <200104111436.HAA13276@nasnfs.Eng.Sun.COM>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

No, no additional AVPs is required. However, I believe some explanations
should be provided on how to treat the  request in different nodes. I'll
give you some text after the weekend that hopefully will give you some ideas
what I mean. Untill then I will enjoy a couple of days skiing :-)

/Fredrik

>-----Original Message-----
>From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf
>Of Patrice Calhoun
>Sent: den 11 april 2001 19:32
>To: Fredrik Johansson; Martin Julien (ECE); Tony Johansson
>Cc: AAA Listan
>Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
>
>
>and no additional protocol text (read AVPs) is required???
>
>PatC
>>>
>>>Just to make sure, I *presume* that this proposed text is to
>belong in the
>>>Mobile IP extension, right?
>>
>>Yes, that's correct
>>
>>/Fredrik
>>
>>>
>>>PatC
>>>
>>>ps: for those that saw my "I will not be responding to e-mail this
>>>week", I
>>>happen to be in a city that has metricom service :)
>>>
>>>>Cool! I was about to send you something very similar to know
>>>>if it was what you meant in your previous mail.
>>>>I agree with your solution. Thanks!
>>>>
>>>>> -----Original Message-----
>>>>> From: Fredrik Johansson [mailto:fredrik.johansson@ipunplugged.com]
>>>>> Sent: Tuesday, April 10, 2001 10:27 AM
>>>>> To: Martin Julien (ECE); Tony Johansson
>>>>> Cc: 'Patrice Calhoun'; AAA Listan
>>>>> Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
>>>>>
>>>>>
>>>>> After a closer look at the problem we have a suggestion on a solution.
>>>>> If the AAAH always assigns a SPI that is unique in the HA for
>>>>> the FA-HA key,
>>>>> and a SPI that is unique in the Mn for the MN-FA and MN-HA keys, the
>>>>> security contexts will automatically be unique in every SA.
>>>>>
>>>>> 7.5 SPI Allocation
>>>>>   To ensure that the SPI is unique for each pair of nodes,
>>>>>   the AAAH SHOULD keep track of assigned SPIs per HA and MN.
>>>>>   The SPI assigned to the MN-FA key MUST be allocated from
>>>>> the MN SPI pool,
>>>>>   the SPI for the FA-HA key MUST be allocated from the HA SPI
>>>>> pool, and the
>>>>>   SPI for the MN-HA key MUST be allocated from the MN SPI
>>>>> pool. Note that
>>>>>   SPI values 0 through 255 are reserved and MUST NOT be used in any
>>>>>   Mobility Security Association.
>>>>>
>>>>> /Fredrik
>>>>> >-----Original Message-----
>>>>> >From: owner-aaa-bof@merit.edu
>>>>> [mailto:owner-aaa-bof@merit.edu]On Behalf
>>>>> >Of Fredrik Johansson
>>>>> >Sent: den 10 april 2001 08:40
>>>>> >To: Martin Julien (ECE); Tony Johansson
>>>>> >Cc: 'Patrice Calhoun'; AAA Listan
>>>>> >Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
>>>>> >
>>>>> >
>>>>> >>
>>>>> >>> >>
>>>>> >>> >> Another thing that needs some clarification, if there is a
>>>>> >>> solution. How
>>>>> >>> >> will the HA know which SA to use. In the case where a mobile
>>>>> >>> >moves from one
>>>>> >>> >> Fa to another under the same administrative domain it may
>>>>> >>> receive the
>>>>> >>> >> session keys for the old Fa from the AAAF. It will then proceed
>>>>> >>> >to send the
>>>>> >>> >> mip reg req to the HA. The HA will see that the message came
>>>>> >>> >from the new FA
>>>>> >>> >> and try to locate the SA shared with that FA. It will not find
>>>>> >>> >it since it
>>>>> >>> >> was established with the old FA. Eventhough the HA can see
>>>>> >>> the address of
>>>>> >>> >> the old Fa in the previous-fa-XXXX it is not clear that it can
>>>>> >>> >establish a
>>>>> >>> >> SA with the new Fa because it has to use the same SPI as before
>>>>> >>> >and that one
>>>>> >>> >> might be busy. Or have I missed something here?
>>>>> >>> >
>>>>> >>> >You also have the user NAI in the MIP registration
>>>>> request sent to
>>>>> >>> >the HA and
>>>>> >>> >the user NAI is globally unique....
>>>>> >>>
>>>>> >>> Yes, but this is not the security association shared with the
>>>>> >>> mobile node
>>>>> >>> but the one shared between the FA and HA, thus has nothing to
>>>>> >>> do with the
>>>>> >>> user.
>>>>> >>
>>>>> >>I think you are assuming that there exists only 1 mobility
>>>>> SA between
>>>>> >>a FA and a HA for all the MIP sessions, right?
>>>>> >
>>>>> >YES, one mobility SA, ceveral security context within a mobility
>>>>> >SA. See rfc
>>>>> >2002,
>>>>> >
>>>>> >"Mobility Security Association
>>>>> >               A collection of security contexts, between a pair
>>>>> >               of nodes, which may be applied to Mobile IP protocol
>>>>> >               messages exchanged between them.  Each
>>>>> context indicates
>>>>> >               an authentication algorithm and mode (Section 5.1), a
>>>>> >               secret (a shared key, or appropriate public/private
>>>>> >               key pair), and a style of replay protection in use
>>>>> >               (Section 5.6)."
>>>>> >
>>>>> >Each context is indexed with a unique SPI within that SA, if
>>>>> there exist a
>>>>> >SA between the HA and the old FA and one SA between the HA
>>>>> and the new FA
>>>>> >there might exist security context with the same SPI in both
>>>>> of these.
>>>>> >
>>>>> >"Security Parameter Index (SPI)
>>>>> >               An index identifying a security context between a pair
>>>>> >               of nodes among the contexts available in the Mobility
>>>>> >               Security Association.  SPI values 0 through 255 are
>>>>> >               reserved and MUST NOT be used in any Mobility Security
>>>>> >               Association."
>>>>> >
>>>>> >>When a first AMA is received
>>>>> >
>>>>> >I guess you mean AMR :-)
>>>>> >
>>>>> >>in the AAAH from a MN, is the AAAH supposed to issue a new
>>>>> registration
>>>>> >>FA-HA key, in the case the HA is in the home domain? The
>>>>> spec says "yes",
>>>>> >>if it is required by the MN. However, how can the MN know about the
>>>>> >>mobility SA between the FA and the HA? I guess it can not,
>>>>> which means
>>>>> >>that it will ask for a new key, which should be transferred
>>>>> to the FA and
>>>>> >>the HA from the AAAH. Is there a way for the HA to notify the AAAH
>>>>> >>that it does not need
>>>>> >>a new key and a new SPI for its mobility SA with the FA, since it
>>>>> >>already has one? I guess
>>>>> >>not, right? Then, it looks like your idea could be very
>>>>> interesting, but
>>>>> >>I don't know how to deal with it using Diameter, unless the
>>>>> AAAH and AAAF
>>>>> >>would keep a list of mobility SAs between each FA and HA.
>>>>> >
>>>>> >In some way the AAAH must keep track of what SPIs it has
>>>>> assigned to the
>>>>> >home agent, if it does it per SA or make the SPI unique over all
>>>>> >SA's in the
>>>>> >HA is up to the implementation
>>>>> >
>>>>> >>
>>>>> >>> You can not guarantee that a security between the HA and
>>>>> the old FA is
>>>>> >>> unique between the HA and the new FA. The same SPI must be
>>>>> >>> used in the first
>>>>> >>> request in order for the HA to be able to distinguise between
>>>>> >>> different
>>>>> >>> security contexts it shares with the FA. What we can do is to
>>>>> >>> have the new
>>>>> >>> FA add a <MIP-Preferred-SPI Ext> in the first request from
>>>>> >>> the new FA to the
>>>>> >>> HA, the HA can then use the <Previous-FA-XXXX Ext> together
>>>>> >>> with the old SPI
>>>>> >>> to retreive the context and store it under the Preferred SPI
>>>>> >>> under the SA
>>>>> >>> with the new FA.
>>>>> >>
>>>>> >>I was wondering whether or not a mobility SA between a FA
>>>>> >>and a HA was based on a particular MIP session? My understanding
>>>>> >>_IS_ that an existing SA is based on a MIP session. That means
>>>>> >>that between a FA and a HA, there exists several mobility SAs
>>>>> >>depending on each MIP session.
>>>>> >
>>>>> >No, there is only one SA between two nodes, but there are
>>>>> several security
>>>>> >context within each SA. Each security context can
>>>>> corresponde to a mip
>>>>> >session. It is the security context that has a lifetime, the
>>>>> SA can be
>>>>> >removed when the last security context is removed.
>>>>> >
>>>>> >>By MIP session, I mean an AAA
>>>>> >>authorized session for MIP. The SPI is already included in the
>>>>> >>key transferred between the AAAF and the new FA. I don't see
>>>>> >>why a HA could not use the SPI stored under its MN User-Name
>>>>> >>state to retrieve the mobility SA between the new FA and itself?
>>>>> >
>>>>> >Because the SA between the FA and HA does not realy have anything
>>>>> >to do with
>>>>> >the Mn. It is something setup between the FA and HA. Thus
>>>>> when the HA will
>>>>> >look for the key to use it will do the lookup on the FA address.
>>>>> >
>>>>> >/Fredrik
>>>>> >
>>>>> >>
>>>>> >>Regards,
>>>>> >>Martin
>>>>> >
>>>>>
>>>
>>>
>
>




From owner-aaa-bof@merit.edu  Thu Apr 12 06:24:01 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA25611
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 06:24:00 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 06:46:27 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA25737
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 06:46:26 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 07:03:47 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA25877
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 07:03:47 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 07:20:07 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA26448
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 07:20:06 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 07:45:04 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA26860
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 07:45:04 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 08:02:26 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA27149
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 08:02:25 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 08:07:24 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA27327
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 08:07:24 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id BB5E85E057; Wed, 11 Apr 2001 20:55:22 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 6FDE35E0E1; Wed, 11 Apr 2001 20:33:47 -0400 (EDT)
Received: from forsete.erilab.com (forsete.erilab.com [208.224.156.105])
	by segue.merit.edu (Postfix) with ESMTP id 157B95E123
	for <aaa-wg@merit.edu>; Wed, 11 Apr 2001 20:06:36 -0400 (EDT)
Received: from erilab.com (eblcl50.erilab.com [192.168.174.190])
	by forsete.erilab.com (8.11.0/8.11.0) with ESMTP id f3C06Yo03414;
	Wed, 11 Apr 2001 17:06:34 -0700 (PDT)
Message-ID: <3AD4F17A.2BF4F221@erilab.com>
Date: Wed, 11 Apr 2001 17:06:18 -0700
From: Michael Chen <cchen@erilab.com>
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: pcalhoun@eng.sun.com
Cc: aaa-wg@merit.edu, kevin.purser@ericsson.com
Subject: [AAA-WG]: MIP-Feature-Vector AVP
References: <200104111909.MAA18654@nasnfs.Eng.Sun.COM>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

In Diameter MobileIP draft

 Section 5.7
 " If the mobile node requests a home agent in the foreign network by
   setting the home address field to all ones, and the AAAF authorizes
   the request, the AAAF MUST set the Home-Agent-In-Foreign-Network bit
   to one."

There are some text need clarify and some text is missing here.

1.  If the mobile node sets the home address field equal to 255.255.255.255
    in  its Registration Request, the Foreign Agent MUST set the Mobile-Node-
    Home-Address-Requested flag to one.  In addition, the FA MUST include the
    MIP_Mobile_Node_Address AVP set to all ones to inform the AAA to set the
    Home-Agent-In-Foreign-Network bit to one if it's policy allows.

2.   Just to be explicit, it could help to include text stating that the
Foreign Agent
      MUST NOT send the MIP_Mobile_Node_Address AVP set to
      0.0.0.0  if   the mobile node sets the home address field equal to
0.0.0.0  in
      its Registration Request.

3.   Also, to be explicit, the Foreign Agent MUST NOT send the
      MIP_Home_Agent_Address AVP set to either
      0.0.0.0  or 255.255.255.255 if   the mobile node sets the home agent
address
       field equal to 0.0.0.0  or 255.255.255.255 in  its Registration
Request.

4.   As a question, what would happen if the Mobile Node sends a registration
      request with both the home address and home agent address set to
255.255.255.255?
      Is this already disallowed by Mobile IP?  If not, something must be
specified in Diameter
      since these settings conflict- should the FA send immediately send back
a MIP-Reg-Reply
      indicating failure, or should the request go to the AAA which would then
respond to the FA
      with a DSI or AMA?




From owner-aaa-bof@merit.edu  Thu Apr 12 08:17:57 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA27625
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 08:17:56 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 08:33:33 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA28066
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 08:33:32 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 08:49:01 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA28451
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 08:49:01 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 09:01:42 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA28682
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 09:01:41 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 09:18:50 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA29190
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 09:18:49 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 09:33:48 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA29688
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 09:33:48 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 09:50:26 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA00152
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 09:50:26 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 10:02:36 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA00511
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 10:02:35 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 5F1895DD95; Thu, 12 Apr 2001 10:00:25 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id D16315DE5C; Thu, 12 Apr 2001 10:00:21 -0400 (EDT)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id A41BD5DE39
	for <aaa-wg@merit.edu>; Thu, 12 Apr 2001 10:00:14 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA23689;
	Thu, 12 Apr 2001 07:00:13 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA24727;
	Thu, 12 Apr 2001 07:00:12 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (eastapp2.East.Sun.COM [129.148.162.99])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id GAA05341;
	Thu, 12 Apr 2001 06:59:49 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Message-Id: <200104121359.GAA05341@nasnfs.Eng.Sun.COM>
Date: Thu, 12 Apr 2001 09:55:29 -0700
To: "Michael Chen" <cchen@erilab.com>
Cc: <aaa-wg@merit.edu>
Reply-To: <pcalhoun@eng.sun.com>
Subject: Re: [AAA-WG]: Re: Route-Record AVP in Indication message
X-Mailer: Sun NetMail 2.3
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit


>Pat,
>
>  I guess you misunderstood what I meant. Let me try it again.
>
>Here is the request send to AAA4
>AAA1->AAA2->AAA3---- link broken ---->AAA4
>
>AAA3----send DSI---->AAA1
>
>AAA3 must generate DSI and send it back to AAA1.

This is where you are wrong. DSI is in the Per-Hop Error Signaling section.
This means that AAA3 does not send a DSI to AAA1, but to AAA2. AAA2 must
take the message from its pending queue, take some local action, and if it
is unable to forward the message, it generates a DSI to AAA1. So, the message
from the queue is used to figure out where to send the DSI to, and it is 
used to figure out what Hop-by-Hop Identifier to put in the DSI message.


>This DSI is NOT a response to the request so it MUST NOT include
>the route-record AVPs that were present in the request.

Correct.

>AAA3 route the message base on Destination-Realm AVP and let's
>say this DSI message routing result is  "directly" to AAA1 instead
>of AAA2. My question is AAA2 keeping the pending request but AAA2
>did NOT receive reply in this case.

No, because as I state above, a DSI has a per-hop processing behavior.

PatC




From owner-aaa-bof@merit.edu  Thu Apr 12 10:15:10 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA00989
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 10:15:09 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 10:34:26 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01547
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 10:34:25 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 11:07:10 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02369
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 11:07:09 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 11:20:56 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02587
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 11:20:56 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 11:44:59 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03077
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 11:44:59 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 12:02:22 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03490
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 12:02:21 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 12:26:26 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03956
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 12:26:26 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 12:48:43 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04635
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 12:48:42 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 13:05:13 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA04991
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 13:05:13 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 13:30:05 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05538
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 13:30:05 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 13:54:22 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA06056
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 13:54:22 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 14:19:28 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06792
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 14:19:28 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 14:22:32 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06865
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 14:22:32 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id AB2075DED0; Thu, 12 Apr 2001 13:36:13 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 7744E5DED3; Thu, 12 Apr 2001 13:36:13 -0400 (EDT)
Received: from forsete.erilab.com (forsete.erilab.com [208.224.156.105])
	by segue.merit.edu (Postfix) with ESMTP id 4A8465DED0
	for <aaa-wg@merit.edu>; Thu, 12 Apr 2001 13:35:57 -0400 (EDT)
Received: from erilab.com (eblcl50.erilab.com [192.168.174.190])
	by forsete.erilab.com (8.11.0/8.11.0) with ESMTP id f3CHZto04511;
	Thu, 12 Apr 2001 10:35:55 -0700 (PDT)
Message-ID: <3AD5E700.C52D13F6@erilab.com>
Date: Thu, 12 Apr 2001 10:33:52 -0700
From: Michael Chen <cchen@erilab.com>
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: pcalhoun@eng.sun.com
Cc: aaa-wg@merit.edu
Subject: Re: [AAA-WG]: Re: Route-Record AVP in Indication message
References: <200104121359.GAA05341@nasnfs.Eng.Sun.COM>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit



Patrice Calhoun wrote:

> >Here is the request send to AAA4
> >AAA1->AAA2->AAA3---- link broken ---->AAA4
> >
> >AAA3----send DSI---->AAA1
> >
> >AAA3 must generate DSI and send it back to AAA1.
>
> This is where you are wrong. DSI is in the Per-Hop Error Signaling section.
> This means that AAA3 does not send a DSI to AAA1, but to AAA2. AAA2 must
> take the message from its pending queue, take some local action, and if it
> is unable to forward the message, it generates a DSI to AAA1. So, the message
> from the queue is used to figure out where to send the DSI to, and it is
> used to figure out what Hop-by-Hop Identifier to put in the DSI message.
>

Thanks for the reply.  DSI is Per-Hop Error Singnal so we don't use neither
Route-Record or Destination-Realm.
Just for curiosity, what if AAA2 is stateless?





From owner-aaa-bof@merit.edu  Thu Apr 12 14:33:33 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07156
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 14:33:33 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 8914F5DED7; Wed, 11 Apr 2001 10:36:53 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 744DC5DED6; Wed, 11 Apr 2001 10:36:53 -0400 (EDT)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id 2E0225DED5
	for <aaa-wg@merit.edu>; Wed, 11 Apr 2001 10:36:52 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id HAA25813;
	Wed, 11 Apr 2001 07:36:40 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id HAA22863;
	Wed, 11 Apr 2001 07:36:39 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (eastapp2.East.Sun.COM [129.148.162.99])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with ESMTP id HAA13276;
	Wed, 11 Apr 2001 07:36:05 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Message-Id: <200104111436.HAA13276@nasnfs.Eng.Sun.COM>
Date: Wed, 11 Apr 2001 10:31:57 -0700
To: "Fredrik Johansson" <fredrik.johansson@ipunplugged.com>,
        "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>,
        "Tony Johansson" <tony.johansson@ericsson.com>
Cc: "AAA Listan" <aaa-wg@merit.edu>
Reply-To: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
X-Mailer: Sun NetMail 2.3
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

and no additional protocol text (read AVPs) is required???

PatC
>>
>>Just to make sure, I *presume* that this proposed text is to belong in the
>>Mobile IP extension, right?
>
>Yes, that's correct
>
>/Fredrik
>
>>
>>PatC
>>
>>ps: for those that saw my "I will not be responding to e-mail this 
>>week", I 
>>happen to be in a city that has metricom service :)
>>
>>>Cool! I was about to send you something very similar to know
>>>if it was what you meant in your previous mail. 
>>>I agree with your solution. Thanks!
>>>
>>>> -----Original Message-----
>>>> From: Fredrik Johansson [mailto:fredrik.johansson@ipunplugged.com]
>>>> Sent: Tuesday, April 10, 2001 10:27 AM
>>>> To: Martin Julien (ECE); Tony Johansson
>>>> Cc: 'Patrice Calhoun'; AAA Listan
>>>> Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
>>>> 
>>>> 
>>>> After a closer look at the problem we have a suggestion on a solution.
>>>> If the AAAH always assigns a SPI that is unique in the HA for 
>>>> the FA-HA key,
>>>> and a SPI that is unique in the Mn for the MN-FA and MN-HA keys, the
>>>> security contexts will automatically be unique in every SA.
>>>> 
>>>> 7.5 SPI Allocation
>>>>   To ensure that the SPI is unique for each pair of nodes,
>>>>   the AAAH SHOULD keep track of assigned SPIs per HA and MN.
>>>>   The SPI assigned to the MN-FA key MUST be allocated from 
>>>> the MN SPI pool,
>>>>   the SPI for the FA-HA key MUST be allocated from the HA SPI 
>>>> pool, and the
>>>>   SPI for the MN-HA key MUST be allocated from the MN SPI 
>>>> pool. Note that
>>>>   SPI values 0 through 255 are reserved and MUST NOT be used in any
>>>>   Mobility Security Association.
>>>> 
>>>> /Fredrik
>>>> >-----Original Message-----
>>>> >From: owner-aaa-bof@merit.edu 
>>>> [mailto:owner-aaa-bof@merit.edu]On Behalf
>>>> >Of Fredrik Johansson
>>>> >Sent: den 10 april 2001 08:40
>>>> >To: Martin Julien (ECE); Tony Johansson
>>>> >Cc: 'Patrice Calhoun'; AAA Listan
>>>> >Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
>>>> >
>>>> >
>>>> >>
>>>> >>> >>
>>>> >>> >> Another thing that needs some clarification, if there is a
>>>> >>> solution. How
>>>> >>> >> will the HA know which SA to use. In the case where a mobile
>>>> >>> >moves from one
>>>> >>> >> Fa to another under the same administrative domain it may
>>>> >>> receive the
>>>> >>> >> session keys for the old Fa from the AAAF. It will then proceed
>>>> >>> >to send the
>>>> >>> >> mip reg req to the HA. The HA will see that the message came
>>>> >>> >from the new FA
>>>> >>> >> and try to locate the SA shared with that FA. It will not find
>>>> >>> >it since it
>>>> >>> >> was established with the old FA. Eventhough the HA can see
>>>> >>> the address of
>>>> >>> >> the old Fa in the previous-fa-XXXX it is not clear that it can
>>>> >>> >establish a
>>>> >>> >> SA with the new Fa because it has to use the same SPI as before
>>>> >>> >and that one
>>>> >>> >> might be busy. Or have I missed something here?
>>>> >>> >
>>>> >>> >You also have the user NAI in the MIP registration 
>>>> request sent to
>>>> >>> >the HA and
>>>> >>> >the user NAI is globally unique....
>>>> >>>
>>>> >>> Yes, but this is not the security association shared with the
>>>> >>> mobile node
>>>> >>> but the one shared between the FA and HA, thus has nothing to
>>>> >>> do with the
>>>> >>> user.
>>>> >>
>>>> >>I think you are assuming that there exists only 1 mobility 
>>>> SA between
>>>> >>a FA and a HA for all the MIP sessions, right?
>>>> >
>>>> >YES, one mobility SA, ceveral security context within a mobility
>>>> >SA. See rfc
>>>> >2002,
>>>> >
>>>> >"Mobility Security Association
>>>> >               A collection of security contexts, between a pair
>>>> >               of nodes, which may be applied to Mobile IP protocol
>>>> >               messages exchanged between them.  Each 
>>>> context indicates
>>>> >               an authentication algorithm and mode (Section 5.1), a
>>>> >               secret (a shared key, or appropriate public/private
>>>> >               key pair), and a style of replay protection in use
>>>> >               (Section 5.6)."
>>>> >
>>>> >Each context is indexed with a unique SPI within that SA, if 
>>>> there exist a
>>>> >SA between the HA and the old FA and one SA between the HA 
>>>> and the new FA
>>>> >there might exist security context with the same SPI in both 
>>>> of these.
>>>> >
>>>> >"Security Parameter Index (SPI)
>>>> >               An index identifying a security context between a pair
>>>> >               of nodes among the contexts available in the Mobility
>>>> >               Security Association.  SPI values 0 through 255 are
>>>> >               reserved and MUST NOT be used in any Mobility Security
>>>> >               Association."
>>>> >
>>>> >>When a first AMA is received
>>>> >
>>>> >I guess you mean AMR :-)
>>>> >
>>>> >>in the AAAH from a MN, is the AAAH supposed to issue a new 
>>>> registration
>>>> >>FA-HA key, in the case the HA is in the home domain? The 
>>>> spec says "yes",
>>>> >>if it is required by the MN. However, how can the MN know about the
>>>> >>mobility SA between the FA and the HA? I guess it can not, 
>>>> which means
>>>> >>that it will ask for a new key, which should be transferred 
>>>> to the FA and
>>>> >>the HA from the AAAH. Is there a way for the HA to notify the AAAH
>>>> >>that it does not need
>>>> >>a new key and a new SPI for its mobility SA with the FA, since it
>>>> >>already has one? I guess
>>>> >>not, right? Then, it looks like your idea could be very 
>>>> interesting, but
>>>> >>I don't know how to deal with it using Diameter, unless the 
>>>> AAAH and AAAF
>>>> >>would keep a list of mobility SAs between each FA and HA.
>>>> >
>>>> >In some way the AAAH must keep track of what SPIs it has 
>>>> assigned to the
>>>> >home agent, if it does it per SA or make the SPI unique over all
>>>> >SA's in the
>>>> >HA is up to the implementation
>>>> >
>>>> >>
>>>> >>> You can not guarantee that a security between the HA and 
>>>> the old FA is
>>>> >>> unique between the HA and the new FA. The same SPI must be
>>>> >>> used in the first
>>>> >>> request in order for the HA to be able to distinguise between
>>>> >>> different
>>>> >>> security contexts it shares with the FA. What we can do is to
>>>> >>> have the new
>>>> >>> FA add a <MIP-Preferred-SPI Ext> in the first request from
>>>> >>> the new FA to the
>>>> >>> HA, the HA can then use the <Previous-FA-XXXX Ext> together
>>>> >>> with the old SPI
>>>> >>> to retreive the context and store it under the Preferred SPI
>>>> >>> under the SA
>>>> >>> with the new FA.
>>>> >>
>>>> >>I was wondering whether or not a mobility SA between a FA
>>>> >>and a HA was based on a particular MIP session? My understanding
>>>> >>_IS_ that an existing SA is based on a MIP session. That means
>>>> >>that between a FA and a HA, there exists several mobility SAs
>>>> >>depending on each MIP session.
>>>> >
>>>> >No, there is only one SA between two nodes, but there are 
>>>> several security
>>>> >context within each SA. Each security context can 
>>>> corresponde to a mip
>>>> >session. It is the security context that has a lifetime, the 
>>>> SA can be
>>>> >removed when the last security context is removed.
>>>> >
>>>> >>By MIP session, I mean an AAA
>>>> >>authorized session for MIP. The SPI is already included in the
>>>> >>key transferred between the AAAF and the new FA. I don't see
>>>> >>why a HA could not use the SPI stored under its MN User-Name
>>>> >>state to retrieve the mobility SA between the new FA and itself?
>>>> >
>>>> >Because the SA between the FA and HA does not realy have anything
>>>> >to do with
>>>> >the Mn. It is something setup between the FA and HA. Thus 
>>>> when the HA will
>>>> >look for the key to use it will do the lookup on the FA address.
>>>> >
>>>> >/Fredrik
>>>> >
>>>> >>
>>>> >>Regards,
>>>> >>Martin
>>>> >
>>>> 
>>
>>





From owner-aaa-bof@merit.edu  Thu Apr 12 14:35:21 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA07187
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 14:35:21 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 15:02:54 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA07556
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 15:02:54 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 15:18:19 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08044
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 15:18:18 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 15:33:52 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08387
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 15:33:52 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 15:47:35 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08857
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 15:47:34 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 16:08:42 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09501
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 16:08:42 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 16:34:17 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA10286
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 16:34:17 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 16:47:25 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA10597
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 16:47:24 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 880AD5E043; Thu, 12 Apr 2001 10:46:30 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id F1EA45E004; Thu, 12 Apr 2001 10:46:10 -0400 (EDT)
Received: from gate.internaut.com (unknown [64.38.134.101])
	by segue.merit.edu (Postfix) with ESMTP id 37AC95E0AC
	for <aaa-wg@merit.edu>; Thu, 12 Apr 2001 10:45:01 -0400 (EDT)
Received: from e1kj2 (e1kj2 [64.38.134.109])
	by gate.internaut.com (8.10.2/8.10.2) with SMTP id f3CEY7N27460
	for <aaa-wg@merit.edu>; Thu, 12 Apr 2001 07:34:07 -0700
From: "Bernard Aboba" <aboba@internaut.com>
To: "Aaa-Wg@Merit. Edu" <aaa-wg@merit.edu>
Subject: [AAA-WG]: Potential AAA WG Interim date change
Date: Thu, 12 Apr 2001 07:46:36 -0700
Message-ID: <OJEJKOMOEAKLMOILFCPJMEOEEFAA.aboba@internaut.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

It has been proposed that the date of the AAA WG Interim meeting
be changed to May 21-22, 2001. This is because there is a conflicting
standards meeting during the week of May 14-18, 2001 (IEEE in
Orland, FL). Just wanted to provide warning for those of you who
might be on the verge of making reservations.

Intended location is the same -- San Jose, CA. 



From owner-aaa-bof@merit.edu  Thu Apr 12 16:48:55 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA10693
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 16:48:55 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 17:04:03 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA10984
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 17:04:02 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 17:09:11 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA11089
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 17:09:09 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id D0C495DECD; Thu, 12 Apr 2001 17:01:59 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id BDDD85DECC; Thu, 12 Apr 2001 17:01:59 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id 4CF9F5DEC8
	for <aaa-wg@merit.edu>; Thu, 12 Apr 2001 17:01:58 -0400 (EDT)
Received: from heliopolis.eng.sun.com ([152.70.1.39])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA18696
	for <aaa-wg@merit.edu>; Thu, 12 Apr 2001 13:59:25 -0700 (PDT)
Received: from srmtv29a (srmtv29a [152.70.1.41])
	by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id OAA16763
	for <aaa-wg@merit.edu>; Thu, 12 Apr 2001 14:00:44 -0700 (PDT)
Message-Id: <200104122100.OAA16763@heliopolis.eng.sun.com>
Date: Thu, 12 Apr 2001 14:00:44 -0700 (PDT)
From: James Kempf <James.Kempf@Sun.COM>
Reply-To: James Kempf <James.Kempf@Sun.COM>
Subject: [AAA-WG]: New API Draft
To: aaa-wg@merit.edu
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: W3Vas7P7xHfLKhhVdg9z6w==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

I've sent a new API draft to the IETF Secretariat, it is now labelled
as a working group draft. Because it is rather lengthy, I have not
posted it to the list and, since Pat is out of town, I have not
asked him to put it on the Diameter server. It should appear on
the drafts directory  shortly.

Changes from previous version:

- Minor changes in the C API addressing comments from people.

- Java API now reflects version 02 of the Diameter draft.

- There is now a server side API in Java, as well as a client side.

One thing that came up while I was doing the Java API is that Java
has no way to represent Unsigned64 or Float128. What I've done is 
define classes that identify these types as having been sent
on the wire, but simply pass through to Long and Double, respectively.
This means that it will not be possible to get an unsigned long
and that any floats over 64 bits will be flagged as errors, even
though they were sent as Float128. An alternative definition would
use BigInt and Decimal, which don't work like the normal numerical
types but do allow arbitrary precision numbers.

Any preferences?

		jak




From owner-aaa-bof@merit.edu  Thu Apr 12 17:18:43 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA11246
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 17:18:43 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 17:33:47 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA11529
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 17:33:46 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 17:56:34 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA11855
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 17:56:34 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 18:16:37 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA12210
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 18:16:37 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 18:33:34 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA12520
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 18:33:34 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 18:50:08 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA12839
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 18:50:08 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 19:15:17 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA13308
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 19:15:16 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 19:33:17 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA13498
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 19:33:17 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 19:48:49 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA13699
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 19:48:48 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 20:19:01 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA14081
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 20:19:01 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 20:36:29 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA14243
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 20:36:29 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 21:00:13 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA14487
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 21:00:12 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 21:16:26 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA14625
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 21:16:26 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 21:33:47 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA14934
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 21:33:47 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 21:48:54 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA15752
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 21:48:54 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 22:03:48 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA15906
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 22:03:47 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 22:18:43 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA16005
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 22:18:43 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 22:35:39 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA17052
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 22:35:38 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 23:00:12 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA17281
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 23:00:12 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 23:16:39 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA17446
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 23:16:38 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 23:33:27 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA17950
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 23:33:26 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Thu Apr 12 23:48:52 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA18143
	for <aaa-archive@odin.ietf.org>; Thu, 12 Apr 2001 23:48:51 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 00:04:00 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA18282
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 00:03:59 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 00:19:05 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA18344
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 00:19:05 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 00:37:32 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA18488
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 00:37:31 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 01:00:24 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA18564
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 01:00:23 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 01:18:53 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA19872
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 01:18:53 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 01:33:50 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA21717
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 01:33:50 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 01:48:52 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA23472
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 01:48:52 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 02:09:56 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA02500
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 02:09:56 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 02:33:21 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA02724
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 02:33:21 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 02:48:45 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA02909
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 02:48:45 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 03:06:51 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA03009
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 03:06:51 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 03:33:10 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA03111
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 03:33:10 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 03:47:46 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA03164
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 03:47:46 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 04:05:21 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA03252
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 04:05:21 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 04:30:02 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA03499
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 04:30:02 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 04:48:25 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA03609
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 04:48:25 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 05:06:10 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA03812
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 05:06:10 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 05:30:16 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA04010
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 05:30:15 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 05:47:53 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA04115
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 05:47:53 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 06:09:52 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA04308
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 06:09:52 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 06:31:38 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA04429
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 06:31:37 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 06:47:07 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA04567
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 06:47:07 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 07:03:14 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA04666
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 07:03:13 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 07:20:20 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA05169
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 07:20:20 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 07:45:32 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA05500
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 07:45:31 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 08:03:43 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA05865
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 08:03:43 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 08:18:45 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA06219
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 08:18:45 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 08:37:45 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA06587
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 08:37:45 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 09:00:20 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07078
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 09:00:19 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 09:16:28 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07476
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 09:16:28 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 09:32:34 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07819
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 09:32:34 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 09:48:46 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA08252
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 09:48:46 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 10:13:26 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09150
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 10:13:25 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 10:35:07 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09615
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 10:35:06 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 11:02:51 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10007
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 11:02:51 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 11:18:34 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10301
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 11:18:34 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 11:33:42 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10738
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 11:33:42 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 11:50:38 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10965
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 11:50:37 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 12:15:06 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA12084
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 12:15:05 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 12:31:35 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13291
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 12:31:35 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 12:46:39 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13572
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 12:46:38 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 13:08:43 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14330
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 13:08:42 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 13:28:47 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14705
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 13:28:47 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 6BD745DD8F; Fri, 13 Apr 2001 13:28:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 53C755DDE2; Fri, 13 Apr 2001 13:28:29 -0400 (EDT)
Received: from newman.frascone.com (unknown [216.62.83.25])
	by segue.merit.edu (Postfix) with SMTP id 7937E5DD8F
	for <aaa-wg@merit.edu>; Fri, 13 Apr 2001 13:28:26 -0400 (EDT)
Received: (qmail 5817 invoked by uid 500); 13 Apr 2001 16:58:21 -0000
Date: Fri, 13 Apr 2001 11:58:21 -0500
From: David Frascone <dave@frascone.com>
To: diameter@diameter.org, aaa-wg@merit.edu
Subject: [AAA-WG]: New ethereal available
Message-ID: <20010413115821.I3019@newman.frascone.com>
Mail-Followup-To: diameter@diameter.org, aaa-wg@merit.edu
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
X-encrypt-payload: no
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Ethereal 0.8.17a has been released.  The changes to the Diameter dissector
were:

o	Fixed time being displayed as a UINT32 instead of a time value.
o	Added extra identifier.  (Changed from single identifier to 
	hop-by-hop and end-to-end identifiers)

The distribution(s) can be found at http://www.ethereal.com



From owner-aaa-bof@merit.edu  Fri Apr 13 13:33:01 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14842
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 13:33:00 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 13:48:47 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15164
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 13:48:47 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 14:03:49 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15417
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 14:03:48 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 14:17:29 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15609
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 14:17:29 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 14:33:51 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA15832
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 14:33:51 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 14:50:09 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16094
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 14:50:09 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 15:15:10 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16412
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 15:15:09 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 15:31:52 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16672
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 15:31:52 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 15:48:54 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16829
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 15:48:53 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 16:05:11 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17028
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 16:05:10 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 16:30:10 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17363
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 16:30:10 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 16:55:15 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18326
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 16:55:15 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 17:19:15 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18719
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 17:19:15 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 17:36:08 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18959
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 17:36:08 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 18:00:13 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA19304
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 18:00:13 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 18:16:33 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA19483
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 18:16:33 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 18:33:45 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA19688
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 18:33:45 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 18:46:33 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA19887
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 18:46:32 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 19:01:40 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA20129
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 19:01:40 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 19:18:25 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA20415
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 19:18:24 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 19:33:46 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA20555
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 19:33:46 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 19:47:46 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA20711
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 19:47:46 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 20:03:44 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20852
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 20:03:43 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 20:16:36 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20938
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 20:16:36 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 20:33:00 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA21103
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 20:32:59 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 20:48:57 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA21177
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 20:48:57 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 21:04:33 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA21283
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 21:04:33 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 21:17:47 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA21364
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 21:17:46 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 21:32:43 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA21469
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 21:32:43 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 21:48:41 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA22558
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 21:48:41 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 22:03:45 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA22670
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 22:03:44 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 22:16:59 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA22765
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 22:16:59 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 22:28:07 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA22849
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 22:28:06 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id EAD195DDA5; Fri, 13 Apr 2001 22:27:48 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id D5DAA5DDB0; Fri, 13 Apr 2001 22:27:48 -0400 (EDT)
Received: from redmailwall2.attws.com (redmailwall2.attws.com [199.108.253.116])
	by segue.merit.edu (Postfix) with ESMTP id E36245DDA5
	for <aaa-wg@merit.edu>; Fri, 13 Apr 2001 22:27:46 -0400 (EDT)
Received: from viruswall.entp.attws.com (viruswall.entp.attws.com [155.176.34.36])
	by redmailwall2.attws.com (8.9.3/8.9.3) with ESMTP id TAA21055
	for <aaa-wg@merit.edu>; Fri, 13 Apr 2001 19:26:24 -0700 (PDT)
Received: from neastmail.neast.attws.com by viruswall.entp.attws.com (8.8.8+Sun/AT&T Wireless Services, Inc. V8 version 2)
	id TAA26878; Fri, 13 Apr 2001 19:27:44 -0700 (PDT)
Received: from ner-msgbh.wireless.attws.com (ner-msgbh.wireless.attws.com [135.216.177.192])
	by neastmail.neast.attws.com (8.8.8+Sun/8.8.8) with ESMTP id TAA15340
	for <aaa-wg@merit.edu>; Fri, 13 Apr 2001 19:27:43 -0700 (PDT)
Received: by ner-msgbh.wireless.attws.com with Internet Mail Service (5.5.2653.19)
	id <23R6XH0S>; Fri, 13 Apr 2001 22:27:42 -0400
Message-ID: <0D3BDFD96647D211B43A00805F15E58903AB68B8@NER-MSG03>
From: "Kobylarz, Thaddeus" <thaddeus.kobylarz@attws.com>
To: "Aaa-Wg@Merit. Edu" <aaa-wg@merit.edu>
Subject: [AAA-WG]: FW: Warning: could not send message for past 4 hours
Date: Fri, 13 Apr 2001 22:27:41 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_000_01C0C48A.7ADE16C0"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_000_01C0C48A.7ADE16C0
Content-Type: text/plain;
	charset="iso-8859-1"

Dave,
	I had to use the AAA exploder to get my presentation to you.  As you
can see by the attachment, there was a problem getting e-mail to you.
	If it is possible, please include the attachment in your Minneapolis
report.
	Thanks. Thad



-----Original Message-----
From: Mail Delivery Subsystem
[mailto:MAILER-DAEMON@redmailwall2.attws.com] 
Sent: Friday, April 13, 2001 4:01 AM
To: thaddeus.kobylarz@attws.com
Subject: Warning: could not send message for past 4 hours


    **********************************************
    **      THIS IS A WARNING MESSAGE ONLY      **
    **  YOU DO NOT NEED TO RESEND YOUR MESSAGE  **
    **********************************************

The original message was received at Thu, 12 Apr 2001 20:51:57 -0700 (PDT)
from [155.176.34.45]

   ----- The following addresses had transient non-fatal errors -----
<dmitton@nortelnetworks.com>

   ----- Transcript of session follows -----
<dmitton@nortelnetworks.com>... Deferred: Connection timed out with
ertpsms2.nortelnetworks.com.
Warning: message still undelivered after 4 hours
Will keep trying until message is 3 days old


------_=_NextPart_000_01C0C48A.7ADE16C0
Content-Type: application/octet-stream;
	name="ATT41684.TXT"
Content-Disposition: attachment;
	filename="ATT41684.TXT"

Reporting-MTA: dns; redmailwall2.attws.com
Arrival-Date: Thu, 12 Apr 2001 20:51:57 -0700 (PDT)

Final-Recipient: RFC822; dmitton@nortelnetworks.com
Action: delayed
Status: 4.4.1
Remote-MTA: DNS; ertpsms2.nortelnetworks.com
Last-Attempt-Date: Fri, 13 Apr 2001 01:01:11 -0700 (PDT)
Will-Retry-Until: Sun, 15 Apr 2001 20:51:57 -0700 (PDT)

------_=_NextPart_000_01C0C48A.7ADE16C0
Content-Type: message/rfc822

Message-ID: <0D3BDFD96647D211B43A00805F15E58903AB68B4@NER-MSG03>
From: "Kobylarz, Thaddeus" <thaddeus.kobylarz@attws.com>
To: 'David Mitton' <dmitton@nortelnetworks.com>
Subject: RE: [AAA-WG]: Need presentations for proceedings by tomorrow (4/1
	 2)
Date: Thu, 12 Apr 2001 23:53:14 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/mixed;
	boundary="----_=_NextPart_002_01C0C48A.7ADE16C0"


------_=_NextPart_002_01C0C48A.7ADE16C0
Content-Type: text/plain

Dave,
	I've attached a plain text copy of my presentation.  Apologies for
the delay.  I hope it didn't arrive too late for inclusion in the
proceedings.
	Thanks for your patience, Thad


-----Original Message-----
From: David Mitton [mailto:dmitton@nortelnetworks.com]
Sent: Wednesday, April 11, 2001 5:29 PM
To: AAA-WG
Subject: [AAA-WG]: Need presentations for proceedings by tomorrow (4/12)
Importance: High


I need all presentations given at the last meeting by tomorrow, Thursday 
April 12th, to be included in the proceedings.

If you sent yours in already, Thanks.

	Dave.
---------------------------------------------------------------
David Mitton                                  ESN: 248-4570
Advisor, Nortel Networks                      978-288-4570 Direct
Wireless Solutions, IP Mobility
Billerica, MA 01821                    dmitton@nortelnetworks.com




------_=_NextPart_002_01C0C48A.7ADE16C0
Content-Type: text/plain;
	name="3GPP_SA5_AAA_liaison.txt"
Content-Disposition: attachment;
	filename="3GPP_SA5_AAA_liaison.txt"
Content-Transfer-Encoding: quoted-printable


	3GPP TSG-SA5 (Telecom Management)				SA5#18(00)0127
	Meeting #18, Versailles, France February 26 - March 2, 2001

	Category:	Liaison
	From:		3GPP SA5
	To:		IETF AAA
	Cc:		SA2, 3GPP/IETF Liaison (Ileana Leuca)=20
	Title:		LS to clarify protocol requirement differences identified in 		=
	December 2000 AAA meeting presentation.
	SA5 Contact:	Thaddeus KOBYLARZ
			+1.973.539.3086
	Email: 		thaddeus.kobylarz@attws.com
	SA5 Chairman:	Albert YUHAN
	Email: 		Albert.Yuhan@Voicestream.com

	1. Introduction

	The 3GPP SA5 Charging Rapporteur group is currently engaged in =
preparing
	charging technical specifications for IP based wireless networks.  =
Because
	it is advantageous to re-use existing protocols, it is our desire to =
liase=20
	with the AAA in developing a protocol(s) suitable for conveying =
charging=20
	information in IP based wireless networks.=20

	A presentation relating to charging protocol requirements was made at =
your=20
	December 2000 meeting.  The presentation cited protocol requirements=20
	differences between the AAA document <draft-ietf-aaa-na-reqts-07.txt> =
and=20
	the 3G.IP document "Charging and Billing (C&B) Requirements" (Version=20
	1.0.0/2000-11-03).  The 3GPP SA5 Charging Rapporteur group has now =
taken=20
	ownership of the 3G.IP C&B requirements document.

	Following the December presentation, an e-mail correspondence was =
received=20
	that summarised the AAA members' comments.  (See the attachment.)  The =
3GPP
	SA5 Charging Rapporteur group reviewed this correspondence and this =
liaison=20
	provides a summary of their commentary.  A principal point of the =
commentary
	is to clarify certain potential ambiguities.

	Please present this liaison to the AAA members for their comments.  We =
look=20
	forward to and are grateful for your responses.


	2. Preamble to commentary

	There exist several underlying needs that prompted many of the 3G.IP =
protocol
	requirements.  Three salient charging needs are as follows:
		=B7 There exists zero tolerance for storage, processing, and =
communication
		errors.  That is, once obtained from the network, the charging=20
		information is to be thereafter unaltered.
		=B7 Prepaid services will be an important future revenue source.  =
This=20
		implies the need for the charging network to reliably and quickly=20
		determine (and respond) when a subscriber reaches a revenue limit.
		=B7 Rapid growth is anticipated for the wireless communication =
business. =20
		To accommodate this business growth, incremental charging network=20
		growth should be convenient and facile.  "Tear down" of the charging=20
		network, whenever its expansion is to take place, is unacceptable.


	3. Charging Rapporteur group commentary

	The following enumeration corresponds to the differences cited in the=20
	attachment:
	Difference 2. - There exists full agreement with the AAA response to =
this
	difference.  However, scenarios exist for which a node failure =
requires the
	attention and reaction of the application protocol.  Hence, failure=20
	information should be provided by the transport protocol for these =
scenarios.
	Difference 3. - Congestion and consequential re-routing can have a =
deleterious
	impact on prepaid services.  Knowledge of this activity cannot be =
exclusively
	within the transport protocol, but needs to brought to the attention =
of the=20
	charging application.
	Difference 5. - "Nodes" are considered to be logical entities (e.g.,=20
	application processes) by the 3GPP SA5 Charging Rapporteur group.  =
Because=20
	the AAA views nodes as hardware (e.g., servers), there may be a =
problematic=20
	issue for the requirements.  Please discuss this difference of these =
two
	perspectives, as it relates to your protocol development, to determine =
the
	consequences and reply about your conclusions.
	Difference 6. -  A study of DIAMETER will be made to determine if it=20
	adequately satisfies this requirement.  The results of this study will =
be
	communicated at a later date.
	Difference 7. -  There exists a dynamic aspect to expediting the =
delivery of
	charging information.  That is, the charging information will indicate =
whether
	it is to be expedited or can be treated as "batch" (non-severe time=20
	constraints).  Will the transport protocol be able to deal with this?
	Difference 8. -  The two perspectives of "nodes" appear to play a role =
here. =20
	This was intended to mean that multiple copies of an application =
exist. =20
	Hence, the application protocol must be able to carry address =
information to
	determine which application copy is to be the destination.
	Difference 9. -  The matter of negotiating to the most recent commonly =

	understood version is significant to this requirement.  Also, a study =
of=20
	DIAMETER will be made to determine if it adequately satisfies this=20
	requirement.  The results of this study will be communicated at a =
later date.
	Difference 12. -  A study of DIAMETER will be made to determine if it=20
	adequately satisfies this requirement.  The results of this study will =
be
	communicated at a later date.



 		ATTACHMENT

From: Bernard Aboba [mailto:aboba@internaut.com]
Sent: Wednesday, December 20, 2000 3:47 AM
To: Kobylarz, Thaddeus; 'Randy Bush'
Cc: 'David Mitton'; Molchan, John; Engelhart, Bob;
ileana.leuca@attws.com; mankin@ISI. EDU
Subject: RE: AAA presentation


Here are some thoughts on the requirements in your
presentation and how we plan to address them:

1. "The AAA protocol should be capable of communicating at various
time-outs, throughputs, and packet sizes."

We agree with you that this is an important issue. In fact,
we are forming a transport team to examine the aspect of AAA
transport behavior in more detail. In particular, we are
looking into expected behavior with TCP and SCTP with and
without the presence of various proxy types. As you may know,
SCTP adds additional timeout control, and TCP and SCTP have
been shown to self-clock, thus enabling these transports to
probe for the maximum available bandwidth. AAA can also leverage
path MTU discovery, and nagle algorithm to appropriate choose
the correct packet size.

2. "AAA protocol must support early detection of communication =
link/node
failures,  other network failures, and network reconfiguration for the
purpose of  re-routing.  (The purpose of this requirement is to support
successful recovery from errors.)"

We agree with you that this is an important issue and have asked
the transport team to investigate it further. As you may know,
SCTP offers enhanced failover capabilities as compared with TCP,
and we hope to leverage these capabilities.

3. "Congestion re-routing - should support early detection of =
congestion for
the purpose of  re-routing."

One of the issues that the transport team will investigate is
congestion avoidance behavior of TCP and SCTP transport with
and without proxies. The interaction of transport and application
layer failover is also a concern. We believe that we will be able
to address this concern in part by leveraging existing TCP and SCTP
congestion avoidance behavior, which has been proven to be
effective.

4. "Link/node recovery - must support the detection of link recovery =
for
instituting routing of accounting information."

We agree with you that this is a conern. As a result, we have asked the
transport team to address the failback issue. Solutions to this issue
have been included in the AAA solutions draft, and the transport team
will continue to look at this issue both at the transport and =
application
layer.

5. "New link/nodes - should support the detection of new link/nodes for
instituting routing of accounting information."

As you may know, the RSERPOOL WG in IETF is investigating the issue of
server pools within the transport area of IETF. Thus the AAA protocol
may be able to leverage this capability in order to address your
concern.

6. "Suggest adding - "must not prevent the determination of duplicated
accounting  information. However, the protocol may assist in the
determination of duplicated accounting information."
Also - "must permit the inclusion of error information and diagnostic
information, for signaling and user plane (payload) frames, and =
protocol
response codes, in the event of communication problems."

We agree with you that this is a concern, and believe that the DIAMETER
specification addresses this issue. Your comments are solicited.

7. Suggest adding - "must facilitate the determination of (near) real =
time
demand or batch response time latitude; e.g., via a multi-colored =
flag**.in
the protocol header (or trailer)."
Also - "should support scheduling and prioritization of accounting
information content transfer."

The AAA protocol offers considerable flexibility in addressing these
needs. It is amenable to use of Differentiated Services, as well
as potentially SCTP multi-plexing mechanisms. The Nagle algorithm also
makes it possible to support transport layer batching both within TCP
and SCTP. Thus we believe that the AAA protocol will be able to support
both real-time performance (e.g. TCP_NODELAY) as well as batching
behavior.

8. Connection multiplexing  - "should be able to support connection
multiplexing and load balancing."

As you may know, the RSERPOOL WG is addressing this very concern.
By supporting SCTP transport we will be able to leverage their work.
 9. Protocol  longevity - "must include version information and its =
automatic
detection for negotiating compatibility."

We agree that this is an important issue. The DIAMETER protocol already
includes support for some of these capabilities. Your comments are
solicited.

10. Payload  encoding - "must be able to support various payload =
encoding to
permit future growth."

DIAMETER AVPs provide extreme flexibility in transporting of opaque
payloads. We believe that it will be possible to satisfy this concern
within the specification.

11. Multiple payload structures - "must be able to support multiple =
payload
structures to permit future growth; e.g., ASN.1 and XML

Since DIAMETER AVPs provide the flexibility to transport diverse =
payloads,
we believe that the specification can address this concern.

12. No interfacing protocol layers - "should not require special =
protocol
layers to interface with an accounting application."

A DIAMETER API has been developed to allow applications to leverage
DIAMETER functionality in a convenient way. Your comments on this
specification are solicited.


------_=_NextPart_002_01C0C48A.7ADE16C0--

------_=_NextPart_000_01C0C48A.7ADE16C0
Content-Type: text/plain;
	name="3GPP_SA5_AAA_liaison.txt"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
	filename="3GPP_SA5_AAA_liaison.txt"
Content-Transfer-Encoding: quoted-printable


	3GPP TSG-SA5 (Telecom Management)				SA5#18(00)0127
	Meeting #18, Versailles, France February 26 - March 2, 2001

	Category:	Liaison
	From:		3GPP SA5
	To:		IETF AAA
	Cc:		SA2, 3GPP/IETF Liaison (Ileana Leuca)=20
	Title:		LS to clarify protocol requirement differences identified in 		=
	December 2000 AAA meeting presentation.
	SA5 Contact:	Thaddeus KOBYLARZ
			+1.973.539.3086
	Email: 		thaddeus.kobylarz@attws.com
	SA5 Chairman:	Albert YUHAN
	Email: 		Albert.Yuhan@Voicestream.com

	1. Introduction

	The 3GPP SA5 Charging Rapporteur group is currently engaged in =
preparing
	charging technical specifications for IP based wireless networks.  =
Because
	it is advantageous to re-use existing protocols, it is our desire to =
liase=20
	with the AAA in developing a protocol(s) suitable for conveying =
charging=20
	information in IP based wireless networks.=20

	A presentation relating to charging protocol requirements was made at =
your=20
	December 2000 meeting.  The presentation cited protocol requirements=20
	differences between the AAA document <draft-ietf-aaa-na-reqts-07.txt> =
and=20
	the 3G.IP document "Charging and Billing (C&B) Requirements" (Version=20
	1.0.0/2000-11-03).  The 3GPP SA5 Charging Rapporteur group has now =
taken=20
	ownership of the 3G.IP C&B requirements document.

	Following the December presentation, an e-mail correspondence was =
received=20
	that summarised the AAA members' comments.  (See the attachment.)  The =
3GPP
	SA5 Charging Rapporteur group reviewed this correspondence and this =
liaison=20
	provides a summary of their commentary.  A principal point of the =
commentary
	is to clarify certain potential ambiguities.

	Please present this liaison to the AAA members for their comments.  We =
look=20
	forward to and are grateful for your responses.


	2. Preamble to commentary

	There exist several underlying needs that prompted many of the 3G.IP =
protocol
	requirements.  Three salient charging needs are as follows:
		=B7 There exists zero tolerance for storage, processing, and =
communication
		errors.  That is, once obtained from the network, the charging=20
		information is to be thereafter unaltered.
		=B7 Prepaid services will be an important future revenue source.  =
This=20
		implies the need for the charging network to reliably and quickly=20
		determine (and respond) when a subscriber reaches a revenue limit.
		=B7 Rapid growth is anticipated for the wireless communication =
business. =20
		To accommodate this business growth, incremental charging network=20
		growth should be convenient and facile.  "Tear down" of the charging=20
		network, whenever its expansion is to take place, is unacceptable.


	3. Charging Rapporteur group commentary

	The following enumeration corresponds to the differences cited in the=20
	attachment:
	Difference 2. - There exists full agreement with the AAA response to =
this
	difference.  However, scenarios exist for which a node failure =
requires the
	attention and reaction of the application protocol.  Hence, failure=20
	information should be provided by the transport protocol for these =
scenarios.
	Difference 3. - Congestion and consequential re-routing can have a =
deleterious
	impact on prepaid services.  Knowledge of this activity cannot be =
exclusively
	within the transport protocol, but needs to brought to the attention =
of the=20
	charging application.
	Difference 5. - "Nodes" are considered to be logical entities (e.g.,=20
	application processes) by the 3GPP SA5 Charging Rapporteur group.  =
Because=20
	the AAA views nodes as hardware (e.g., servers), there may be a =
problematic=20
	issue for the requirements.  Please discuss this difference of these =
two
	perspectives, as it relates to your protocol development, to determine =
the
	consequences and reply about your conclusions.
	Difference 6. -  A study of DIAMETER will be made to determine if it=20
	adequately satisfies this requirement.  The results of this study will =
be
	communicated at a later date.
	Difference 7. -  There exists a dynamic aspect to expediting the =
delivery of
	charging information.  That is, the charging information will indicate =
whether
	it is to be expedited or can be treated as "batch" (non-severe time=20
	constraints).  Will the transport protocol be able to deal with this?
	Difference 8. -  The two perspectives of "nodes" appear to play a role =
here. =20
	This was intended to mean that multiple copies of an application =
exist. =20
	Hence, the application protocol must be able to carry address =
information to
	determine which application copy is to be the destination.
	Difference 9. -  The matter of negotiating to the most recent commonly =

	understood version is significant to this requirement.  Also, a study =
of=20
	DIAMETER will be made to determine if it adequately satisfies this=20
	requirement.  The results of this study will be communicated at a =
later date.
	Difference 12. -  A study of DIAMETER will be made to determine if it=20
	adequately satisfies this requirement.  The results of this study will =
be
	communicated at a later date.



 		ATTACHMENT

From: Bernard Aboba [mailto:aboba@internaut.com]
Sent: Wednesday, December 20, 2000 3:47 AM
To: Kobylarz, Thaddeus; 'Randy Bush'
Cc: 'David Mitton'; Molchan, John; Engelhart, Bob;
ileana.leuca@attws.com; mankin@ISI. EDU
Subject: RE: AAA presentation


Here are some thoughts on the requirements in your
presentation and how we plan to address them:

1. "The AAA protocol should be capable of communicating at various
time-outs, throughputs, and packet sizes."

We agree with you that this is an important issue. In fact,
we are forming a transport team to examine the aspect of AAA
transport behavior in more detail. In particular, we are
looking into expected behavior with TCP and SCTP with and
without the presence of various proxy types. As you may know,
SCTP adds additional timeout control, and TCP and SCTP have
been shown to self-clock, thus enabling these transports to
probe for the maximum available bandwidth. AAA can also leverage
path MTU discovery, and nagle algorithm to appropriate choose
the correct packet size.

2. "AAA protocol must support early detection of communication =
link/node
failures,  other network failures, and network reconfiguration for the
purpose of  re-routing.  (The purpose of this requirement is to support
successful recovery from errors.)"

We agree with you that this is an important issue and have asked
the transport team to investigate it further. As you may know,
SCTP offers enhanced failover capabilities as compared with TCP,
and we hope to leverage these capabilities.

3. "Congestion re-routing - should support early detection of =
congestion for
the purpose of  re-routing."

One of the issues that the transport team will investigate is
congestion avoidance behavior of TCP and SCTP transport with
and without proxies. The interaction of transport and application
layer failover is also a concern. We believe that we will be able
to address this concern in part by leveraging existing TCP and SCTP
congestion avoidance behavior, which has been proven to be
effective.

4. "Link/node recovery - must support the detection of link recovery =
for
instituting routing of accounting information."

We agree with you that this is a conern. As a result, we have asked the
transport team to address the failback issue. Solutions to this issue
have been included in the AAA solutions draft, and the transport team
will continue to look at this issue both at the transport and =
application
layer.

5. "New link/nodes - should support the detection of new link/nodes for
instituting routing of accounting information."

As you may know, the RSERPOOL WG in IETF is investigating the issue of
server pools within the transport area of IETF. Thus the AAA protocol
may be able to leverage this capability in order to address your
concern.

6. "Suggest adding - "must not prevent the determination of duplicated
accounting  information. However, the protocol may assist in the
determination of duplicated accounting information."
Also - "must permit the inclusion of error information and diagnostic
information, for signaling and user plane (payload) frames, and =
protocol
response codes, in the event of communication problems."

We agree with you that this is a concern, and believe that the DIAMETER
specification addresses this issue. Your comments are solicited.

7. Suggest adding - "must facilitate the determination of (near) real =
time
demand or batch response time latitude; e.g., via a multi-colored =
flag**.in
the protocol header (or trailer)."
Also - "should support scheduling and prioritization of accounting
information content transfer."

The AAA protocol offers considerable flexibility in addressing these
needs. It is amenable to use of Differentiated Services, as well
as potentially SCTP multi-plexing mechanisms. The Nagle algorithm also
makes it possible to support transport layer batching both within TCP
and SCTP. Thus we believe that the AAA protocol will be able to support
both real-time performance (e.g. TCP_NODELAY) as well as batching
behavior.

8. Connection multiplexing  - "should be able to support connection
multiplexing and load balancing."

As you may know, the RSERPOOL WG is addressing this very concern.
By supporting SCTP transport we will be able to leverage their work.
 9. Protocol  longevity - "must include version information and its =
automatic
detection for negotiating compatibility."

We agree that this is an important issue. The DIAMETER protocol already
includes support for some of these capabilities. Your comments are
solicited.

10. Payload  encoding - "must be able to support various payload =
encoding to
permit future growth."

DIAMETER AVPs provide extreme flexibility in transporting of opaque
payloads. We believe that it will be possible to satisfy this concern
within the specification.

11. Multiple payload structures - "must be able to support multiple =
payload
structures to permit future growth; e.g., ASN.1 and XML

Since DIAMETER AVPs provide the flexibility to transport diverse =
payloads,
we believe that the specification can address this concern.

12. No interfacing protocol layers - "should not require special =
protocol
layers to interface with an accounting application."

A DIAMETER API has been developed to allow applications to leverage
DIAMETER functionality in a convenient way. Your comments on this
specification are solicited.


------_=_NextPart_000_01C0C48A.7ADE16C0--



From owner-aaa-bof@merit.edu  Fri Apr 13 22:33:44 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA23827
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 22:33:43 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 22:48:53 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA23982
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 22:48:53 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 23:14:59 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA24224
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 23:14:59 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 23:31:30 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA24526
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 23:31:30 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Fri Apr 13 23:47:42 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA24791
	for <aaa-archive@odin.ietf.org>; Fri, 13 Apr 2001 23:47:42 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 00:04:09 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA24978
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 00:04:09 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 00:18:12 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA25038
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 00:18:11 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 00:33:00 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA25328
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 00:32:59 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 00:48:48 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA25370
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 00:48:48 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 01:03:07 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA25415
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 01:03:07 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 01:19:00 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA26818
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 01:19:00 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 01:31:44 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA28414
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 01:31:44 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 01:48:49 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA00433
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 01:48:49 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 02:03:39 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA06284
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 02:03:39 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 02:18:42 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA09239
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 02:18:42 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 02:31:32 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA09321
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 02:31:32 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 02:48:57 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA09388
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 02:48:57 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 03:02:03 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA09433
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 03:02:03 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 03:19:25 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA09570
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 03:19:24 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 03:33:47 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA09700
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 03:33:47 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 03:49:00 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA09821
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 03:48:59 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 04:03:52 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA09884
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 04:03:52 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 04:17:08 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA09993
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 04:17:07 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 04:32:49 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA10079
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 04:32:49 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 04:50:56 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA10173
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 04:50:55 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 05:15:07 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA10303
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 05:15:07 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 05:31:31 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA10385
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 05:31:30 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 05:46:37 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA10470
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 05:46:37 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 06:01:42 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA10529
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 06:01:42 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 06:18:46 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA10595
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 06:18:45 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 06:33:09 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA10752
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 06:33:08 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 06:48:48 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA10826
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 06:48:48 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 07:03:47 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA10964
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 07:03:46 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 07:18:53 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA11057
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 07:18:53 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 07:33:58 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA11125
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 07:33:58 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 07:48:57 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA11224
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 07:48:57 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 08:03:46 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA11460
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 08:03:46 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 08:19:05 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA11602
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 08:19:04 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 08:31:27 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA11744
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 08:31:27 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 08:47:56 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA11879
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 08:47:56 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 09:02:47 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA11949
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 09:02:47 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 09:18:41 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA12022
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 09:18:40 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 09:31:58 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA12082
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 09:31:58 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 09:47:34 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA12130
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 09:47:34 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 10:01:42 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12329
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 10:01:42 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 10:18:33 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12683
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 10:18:32 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 10:32:53 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12799
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 10:32:53 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 10:48:51 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12903
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 10:48:51 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 11:01:11 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13005
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 11:01:11 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 11:18:48 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13092
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 11:18:48 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 11:32:31 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13145
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 11:32:27 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 11:47:14 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13281
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 11:47:13 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 12:02:51 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13368
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 12:02:50 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 12:17:56 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13451
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 12:17:56 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 12:32:41 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13600
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 12:32:41 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 12:48:39 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13679
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 12:48:39 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 13:03:54 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13744
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 13:03:54 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 13:18:53 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13821
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 13:18:53 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 13:33:47 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13887
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 13:33:46 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 13:48:49 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13936
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 13:48:49 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 14:03:47 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14019
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 14:03:47 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 14:30:06 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14108
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 14:30:06 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 14:48:47 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14158
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 14:48:46 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 15:03:27 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14205
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 15:03:27 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 15:16:39 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14247
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 15:16:39 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 15:33:47 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14315
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 15:33:47 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 15:47:06 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14378
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 15:47:05 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 16:01:41 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14432
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 16:01:41 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 16:17:33 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14507
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 16:17:33 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 16:32:50 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14562
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 16:32:50 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 17:00:05 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14684
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 17:00:04 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 17:16:38 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14761
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 17:16:38 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 17:32:34 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14817
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 17:32:34 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 17:48:29 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14854
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 17:48:29 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 18:02:07 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14909
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 18:02:07 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 18:17:46 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA14972
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 18:17:46 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 18:33:46 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA15036
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 18:33:46 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 18:46:36 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA15077
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 18:46:36 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 19:03:48 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15143
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 19:03:48 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 19:18:36 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15207
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 19:18:30 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 19:32:57 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15271
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 19:32:57 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 19:46:26 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA15322
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 19:46:26 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 20:02:54 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA15391
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 20:02:54 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 20:17:55 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA15443
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 20:17:55 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 20:31:42 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA15489
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 20:31:42 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 20:48:03 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA15553
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 20:48:03 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 21:04:16 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA15615
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 21:04:16 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 21:16:15 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA15657
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 21:16:15 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 21:31:42 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA15713
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 21:31:41 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 21:46:31 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA16704
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 21:46:30 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 22:04:32 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA16757
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 22:04:31 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 22:18:07 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA16795
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 22:18:07 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 22:31:36 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA17587
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 22:31:36 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 22:47:08 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA17814
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 22:47:08 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 23:03:04 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA17861
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 23:03:04 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 23:16:29 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA17911
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 23:16:28 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 23:33:02 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA18301
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 23:33:01 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sat Apr 14 23:47:25 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA18435
	for <aaa-archive@odin.ietf.org>; Sat, 14 Apr 2001 23:47:25 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 00:01:46 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA18492
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 00:01:45 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 00:18:42 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA18535
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 00:18:41 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 00:33:47 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA18628
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 00:33:46 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 00:48:26 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA18680
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 00:48:26 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 01:03:49 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA18755
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 01:03:48 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 01:18:14 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA20390
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 01:18:14 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 01:31:41 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA22340
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 01:31:41 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 01:47:50 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA24306
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 01:47:50 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 02:01:43 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA28024
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 02:01:42 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 02:18:47 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA02552
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 02:18:47 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 02:33:46 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA02637
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 02:33:46 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 02:47:29 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA02673
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 02:47:28 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 03:01:32 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA02743
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 03:01:32 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 03:18:23 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA01856
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 03:18:23 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 03:33:35 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA03931
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 03:33:34 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 03:48:22 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA06090
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 03:48:22 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 04:01:33 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA07638
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 04:01:32 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 04:17:36 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA07668
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 04:17:36 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 04:32:39 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA07766
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 04:32:39 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 04:48:44 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA07801
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 04:48:44 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 05:03:29 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA07840
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 05:03:28 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 05:16:40 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA07912
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 05:16:39 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 05:30:26 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA07958
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 05:30:26 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 05:46:38 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA08018
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 05:46:38 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 06:01:38 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08058
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 06:01:38 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 06:16:35 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08093
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 06:16:35 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 06:32:30 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08136
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 06:32:30 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 06:48:50 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08172
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 06:48:50 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 07:03:29 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA08213
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 07:03:29 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 07:16:40 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA08302
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 07:16:40 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 07:32:57 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA08426
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 07:32:57 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 07:48:49 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA08525
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 07:48:49 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 08:02:57 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA08661
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 08:02:57 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 08:17:55 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA08736
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 08:17:55 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 08:31:41 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA08867
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 08:31:40 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 08:47:26 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA08940
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 08:47:25 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 09:03:51 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA09073
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 09:03:50 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 09:18:47 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA09167
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 09:18:47 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 09:31:47 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA09254
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 09:31:47 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 09:47:30 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA09372
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 09:47:30 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 10:02:49 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09454
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 10:02:48 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 10:16:38 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09571
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 10:16:37 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 10:33:50 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09681
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 10:33:50 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 10:48:14 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09795
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 10:48:14 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 11:03:03 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09904
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 11:03:03 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 11:16:38 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10049
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 11:16:37 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 11:31:41 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10150
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 11:31:40 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 11:45:44 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10241
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 11:45:44 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 12:01:40 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10328
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 12:01:40 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 12:16:33 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10406
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 12:16:32 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 12:31:18 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10443
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 12:31:17 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 12:46:36 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10540
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 12:46:35 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 13:01:38 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10709
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 13:01:38 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 13:16:36 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10825
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 13:16:35 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 13:32:35 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10901
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 13:32:34 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 13:46:35 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10953
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 13:46:34 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 14:01:40 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11013
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 14:01:40 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 14:16:36 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11105
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 14:16:36 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 14:31:29 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11177
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 14:31:29 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 14:46:33 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11225
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 14:46:33 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 15:01:38 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11294
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 15:01:38 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 15:16:22 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11347
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 15:16:22 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 15:31:40 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11396
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 15:31:39 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 15:46:28 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11434
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 15:46:28 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 16:00:32 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11476
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 16:00:31 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 16:15:20 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11532
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 16:15:20 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 16:30:25 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11566
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 16:30:24 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 16:46:46 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11606
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 16:46:46 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 17:03:51 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA11698
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 17:03:51 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 17:18:49 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA11790
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 17:18:49 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 17:31:43 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA11881
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 17:31:43 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 17:47:30 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA11962
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 17:47:30 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 18:02:55 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA12074
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 18:02:55 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 18:18:31 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA12196
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 18:18:31 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 18:33:26 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA12273
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 18:33:26 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 18:46:33 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA12362
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 18:46:33 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 19:02:25 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA12418
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 19:02:25 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 19:16:29 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA12548
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 19:16:28 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 19:33:26 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA12621
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 19:33:26 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 19:48:47 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA12720
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 19:48:46 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 978BB5E0BF; Tue, 10 Apr 2001 19:51:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9B03E5E0AE; Tue, 10 Apr 2001 19:30:34 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 731BD5E0B7
	for <aaa-wg@merit.edu>; Tue, 10 Apr 2001 18:58:56 -0400 (EDT)
Received: from gwzpc (rtp-dial-1-204.cisco.com [10.83.97.204]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA10084; Tue, 10 Apr 2001 15:58:53 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>, <aaa-wg@merit.edu>
Cc: <pcalhoun@eng.sun.com>
Subject: RE: [AAA-WG]: Christian's comments
Date: Tue, 10 Apr 2001 15:58:53 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEMIDGAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <Roam.SIMC.2.0.6.986593050.23947.pcalhoun@nasnfs>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> Sorry for the latency.

Ditto.

>
> Comments below
>
> > I have a somewhat fundamental issue with the Diameter. Why is the IETF
> > trying to invent yet another marshalling protocol, instead of using
> > existing technologies such as XML or ASN.1? Radius made some sense,
> > because it was very well scoped and very limited in complexity. The
> > Diameter specification is much more ambitious than Radius; it attempts
> > to define a fully capable marshalling protocol, using the RFC process
> > and the IANA as a substitute for an interface definition language. If I
> > am developing a specific application protocol, why should I base it on
> > Diameter rather than ASN.1 or XML?
>
> I understand that you were probably not following the WG's
> mailing list when
> the protocol evaluation was under way, but there were plenty of binary vs.
> ascii protocol wars at that time, and Diameter came out as the preferred
> protocol.

In actual point of fact, virtually all of Christian's comments (with the
possible exception of his characterization of Diameter as "yet another
marshalling protocol", possibly because it is _such_ a gross
oversimplification) have been discussed at length and resolved over the last
4 years.

>
> I see now reason to re-open that can of worms.

Nor any of the others.

<text deleted>




From owner-aaa-bof@merit.edu  Sun Apr 15 21:41:40 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA14457
	for <aaa-archive@odin.ietf.org>; Sun, 15 Apr 2001 21:41:37 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id EDC185DDD2; Sun, 15 Apr 2001 21:40:50 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id D8DB65DDDE; Sun, 15 Apr 2001 21:40:50 -0400 (EDT)
Received: from aaa.interlinknetworks.com (interlink.merit.edu [198.108.95.110])
	by segue.merit.edu (Postfix) with ESMTP id 745BD5DDD2
	for <aaa-wg@merit.edu>; Sun, 15 Apr 2001 21:40:49 -0400 (EDT)
Received: from phoenix (pm703-39.dialip.mich.net [204.39.231.145])
	by aaa.interlinknetworks.com (Postfix) with SMTP
	id 10D6879; Sun, 15 Apr 2001 21:40:48 -0400 (EDT)
From: "Bob Kopacz" <BKopacz@InterlinkNetworks.com>
To: "Pat Calhoun" <Pat.Calhoun@Eng.Sun.COM>
Cc: "aaa-wg" <aaa-wg@merit.edu>
Subject: [AAA-WG]: draft-ietf-aaa-diameter-02.txt / Proxy-State
Date: Sun, 15 Apr 2001 21:39:16 -0400
Message-ID: <NEBBKEONLKEDJCMHGHPIIEHOCBAA.BKopacz@InterlinkNetworks.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6600
Importance: Normal
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Pat,

Here is a problem and a proposed solution:


The Problem:
------------
Proxy-State (AVP Code 33) is one of the attributes inherited from
RADIUS.

However, in Radius this attribute is of type OctetString, while in
Diameter it is of type Grouped.

The problem comes when defining the dictionary entry for
Proxy-State, in a AAA server which supports both Radius and Diameter
peers.  Whether the dictionary types Proxy-State as STRING or
GROUPED, one of the protocols is going to be confused.


Proposed Solution: 
------------------
The Diameter Proxy-Info AVP corresponds to what Radius calls
Proxy-State.  They are both of type OctetString and represent opaque
state data.

My thought would be to swap the current roles of Proxy-State and
Proxy-Info.

That is, keep the two-member grouped AVP of proxy stuff, but make
Proxy-State the second member of the group, and make Proxy-Info the
Grouped AVP.  Proxy-Info retains its AVP code of 284, and
Proxy-State retains its AVP code of 33.  In the documents, swap all
occurrences of Proxy-State with Proxy-Info and vice versa.  Sections
12.4.4-12.4.6 would become:

| 12.4.4  Proxy-Info AVP
|
| The Proxy-Info AVP (AVP Code = 284) is of type Grouped.  The Grouped
| Data field has the following ABNF grammar:
|
|    Proxy-Info   = Proxy-Address Proxy-State
|       Proxy-Address = ; See Section 12.4.5
|       Proxy-State   = ; See Section 12.4.6
|
| The Proxy-Address AVP Data field contains one of the IP addresses of
| the system that created the AVP. This assists hosts in determining
| whether a Proxy-Info AVP is intended for the local host. The Proxy-
| State AVP contains state information, and MUST be treated as opaque
| data.
|
|    +---------------------------------------------------------------+
|    |                 AVP Header (AVP Code = 284)                   |
|    +---------------------------------------------------------------+
|    |                      Proxy-Address AVP                        |
|    +---------------------------------------------------------------+
|    |                        Proxy-State AVP                        |
|    +---------------------------------------------------------------+
|
|
| 12.4.5  Proxy-Address AVP
|
| The Proxy-Address AVP (AVP Code = 280) is of type Address.  Its use
| is described in Section 12.4.4.
|
|
| 12.4.6  Proxy-State AVP
|
| The Proxy-State AVP (AVP Code = 33) is of type OctetString.  Its use
| is described in Section 12.4.4.




From owner-aaa-bof@merit.edu  Mon Apr 16 12:54:09 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA08275
	for <aaa-archive@odin.ietf.org>; Mon, 16 Apr 2001 12:54:09 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id CB00E5DE14; Mon, 16 Apr 2001 12:50:55 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id AF1195DDE7; Mon, 16 Apr 2001 12:50:55 -0400 (EDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by segue.merit.edu (Postfix) with ESMTP id 042B95DE14
	for <aaa-wg@merit.edu>; Mon, 16 Apr 2001 12:50:54 -0400 (EDT)
Received: from mira-sjcm-3.cisco.com (mira-sjcm-3.cisco.com [171.69.43.101])
	by sj-msg-core-3.cisco.com (8.9.3/8.9.1) with ESMTP id JAA29277;
	Mon, 16 Apr 2001 09:49:32 -0700 (PDT)
Received: from johnalw2k (dhcp-161-44-29-177.cisco.com [161.44.29.177])
	by mira-sjcm-3.cisco.com (Mirapoint)
	with SMTP id ACH02485;
	Mon, 16 Apr 2001 09:50:50 -0700 (PDT)
From: "John Alayari" <johnal@cisco.com>
To: "Jari Arkko" <jari.arkko@kolumbus.fi>, <pcalhoun@eng.sun.com>
Cc: <aaa-wg@merit.edu>
Subject: [AAA-WG]: RE: [AAA-WAG]: Re: Accounting-status-Ind & interim data
Date: Mon, 16 Apr 2001 09:49:51 -0700
Message-ID: <CNEGKCBENOKKPJPNCEODKEHJCCAA.johnal@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <00ee01c0c309$9ced6720$8a1b6e0a@arenanet.fi>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Jari,

I am concerned about the losing accounting interim data since the last
transfer in the client. I believe, they should be transferred to the server
just before the ASI command. I am proposing a solution in my next email.

John.

-----Original Message-----
From: Jari Arkko [mailto:jari.arkko@kolumbus.fi]
Sent: Wednesday, April 11, 2001 9:33 PM
To: John Alayari; pcalhoun@eng.sun.com
Cc: aaa-wg@merit.edu
Subject: Re: [AAA-WG]: Re: Accounting-status-Ind & interim data



>> In the case when the client is about to be disabled and the usage
>> information accumulated in the local interim data storage may be lost,
the
>> server may get the latest accumulated data.

>I still have trouble understanding how the accounting-Interim-interval
>AVP will help in this situation. That particular AVP is just for the
authorization
>or the accounting server to inform the client about how often it should
>generate the interim records. Are you suggesting to send this AVP
>with information about the planned outage at the client side so that the
>server can use it for something?

>Or are you thinking of sending the actual latest records? In that
>case much more may be needed than this single AVP... and maybe
>not even just one message, several, one for each session towards
>that particular realm.

>If the latter issue was your intention, there may also be other ways
>of doing this. We could state something about the desired behavior
>of a Diameter client wrt existing client records when it is about to
>stop accounting. For instance, we could say that Diameter clients
>SHOULD try to send the latest interim records just before sending
the ASI.

By the way, it seems that the specification on who the ASI command
is really sent to is somewhat unclear. The text in 14.3 talks about the
"peer" but the AVPs such as the Destination-Realm in the message
might indicate more an end-to-end message... I' m not really sure
which one we even should prefer, because the peer variant is
a quick single message but not so useful, and the e2e variant could
be many messages but is on the other hand more useful.

Jari






From owner-aaa-bof@merit.edu  Mon Apr 16 15:05:08 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA11685
	for <aaa-archive@odin.ietf.org>; Mon, 16 Apr 2001 15:05:08 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 1295D5DE40; Mon, 16 Apr 2001 15:03:35 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id F0C7A5DE3D; Mon, 16 Apr 2001 15:03:34 -0400 (EDT)
Received: from mx.databus.com (p101-44.acedsl.com [160.79.101.44])
	by segue.merit.edu (Postfix) with ESMTP id 4D7225DE2B
	for <aaa-wg@merit.edu>; Mon, 16 Apr 2001 15:03:33 -0400 (EDT)
Received: (from barney@localhost)
	by mx.databus.com (8.11.3/8.11.3) id f3GJ32w49641;
	Mon, 16 Apr 2001 15:03:02 -0400 (EDT)
	(envelope-from barney)
Date: Mon, 16 Apr 2001 15:03:02 -0400
From: Barney Wolff <barney@databus.com>
To: John Alayari <johnal@cisco.com>
Cc: aaa-wg@merit.edu
Subject: Re: [AAA-WG]: RE: Accounting-status-Ind & interim data
Message-ID: <20010416150302.A49597@mx.databus.com>
References: <200104111952.MAA19361@nasnfs.Eng.Sun.COM> <CNEGKCBENOKKPJPNCEODCEHLCCAA.johnal@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0.1i
In-Reply-To: <CNEGKCBENOKKPJPNCEODCEHLCCAA.johnal@cisco.com>; from johnal@cisco.com on Mon, Apr 16, 2001 at 11:30:52AM -0700
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Um, we decided to forgo batched accounting, after discussion.
I respectfully suggest that we not bring it back.

Real-world, accounting would only be turned off as part of a
controlled shutdown of the access server.  That should generate
stops for each session without requiring special handling on
either side.  In my experience, uncontrolled shutdowns or restarts
are rather more common than controlled ones, even on equipment
from highly-regarded vendors. :)  So the value of a We-Who-Are-
About-To-Die-Salute-You command is limited, and any effort to
optimize it misguided.

Barney Wolff

On Mon, Apr 16, 2001 at 11:30:52AM -0700, John Alayari wrote:
> The current draft of the Diameter base protocol has the following command:
> 
> "14.3  Accounting-Status-Ind (ASI) Command
> 
>    The Accounting-Status-Ind command, indicated by the Command-Code
>    field set to 279, is sent by a Diameter node in order to inform its
>    peer of whether Accounting messages will be sent in the future. A
>    Diameter node that is about to be taken out of service SHOULD issue
>    an Accounting-Status-Ind message, with the Accounting-State AVP set
>    to DISABLED. A Diameter node that detected that it is able to issue
>    Accounting messages MUST issue an Accounting-Status-Ind message, with
>    the Accounting-State AVP set to ENABLED."
> 
> The issues is that the accounting usage information accumulated since the
> last transfer interval for each session, will be LOST and never get sent to
> the server.
> 
> I am proposing a solution for this to AAA WAG for discussion and hopefully
> we come up a good solution for this.
> 
> A NEW command say, Multi-Accounting-Request can be introduced that
> carries the AVPs such as origin-FQDN after the command header followed by
> one or more NEW AVPs (say Multi-Session-Record) of type Grouped.  This AVP
> carries stop records for all active sessions in the NAS to the server.
> This command should be sent to the server before the ASI command.
> 
> Please let me know what you think.
> 
> Thanks.
> 
> John Alayari.
> 
> 



From owner-aaa-bof@merit.edu  Mon Apr 16 15:31:42 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12195
	for <aaa-archive@odin.ietf.org>; Mon, 16 Apr 2001 15:31:42 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 7A69A5DE1F; Mon, 16 Apr 2001 14:31:56 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 646715DE23; Mon, 16 Apr 2001 14:31:56 -0400 (EDT)
Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11])
	by segue.merit.edu (Postfix) with ESMTP id 6C3A15DE1F
	for <aaa-wg@merit.edu>; Mon, 16 Apr 2001 14:31:54 -0400 (EDT)
Received: from mira-sjcm-3.cisco.com (mira-sjcm-3.cisco.com [171.69.43.101])
	by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id LAA11491
	for <aaa-wg@merit.edu>; Mon, 16 Apr 2001 11:31:53 -0700 (PDT)
Received: from johnalw2k (dhcp-161-44-29-177.cisco.com [161.44.29.177])
	by mira-sjcm-3.cisco.com (Mirapoint)
	with SMTP id ACH05395;
	Mon, 16 Apr 2001 11:31:52 -0700 (PDT)
From: "John Alayari" <johnal@cisco.com>
To: <aaa-wg@merit.edu>
Subject: [AAA-WG]: RE: Accounting-status-Ind & interim data
Date: Mon, 16 Apr 2001 11:30:52 -0700
Message-ID: <CNEGKCBENOKKPJPNCEODCEHLCCAA.johnal@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
In-Reply-To: <200104111952.MAA19361@nasnfs.Eng.Sun.COM>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

The current draft of the Diameter base protocol has the following command:

"14.3  Accounting-Status-Ind (ASI) Command

   The Accounting-Status-Ind command, indicated by the Command-Code
   field set to 279, is sent by a Diameter node in order to inform its
   peer of whether Accounting messages will be sent in the future. A
   Diameter node that is about to be taken out of service SHOULD issue
   an Accounting-Status-Ind message, with the Accounting-State AVP set
   to DISABLED. A Diameter node that detected that it is able to issue
   Accounting messages MUST issue an Accounting-Status-Ind message, with
   the Accounting-State AVP set to ENABLED."

The issues is that the accounting usage information accumulated since the
last transfer interval for each session, will be LOST and never get sent to
the server.

I am proposing a solution for this to AAA WAG for discussion and hopefully
we come up a good solution for this.

A NEW command say, Multi-Accounting-Request can be introduced that
carries the AVPs such as origin-FQDN after the command header followed by
one or more NEW AVPs (say Multi-Session-Record) of type Grouped.  This AVP
carries stop records for all active sessions in the NAS to the server.
This command should be sent to the server before the ASI command.

Please let me know what you think.

Thanks.

John Alayari.




From owner-aaa-bof@merit.edu  Mon Apr 16 16:07:43 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA12952
	for <aaa-archive@odin.ietf.org>; Mon, 16 Apr 2001 16:07:43 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 645255DDFE; Mon, 16 Apr 2001 16:04:41 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 528465DDFB; Mon, 16 Apr 2001 16:04:41 -0400 (EDT)
Received: from fep01-app.kolumbus.fi (fep01-0.kolumbus.fi [193.229.0.41])
	by segue.merit.edu (Postfix) with ESMTP id 4CCD75DDD0
	for <aaa-wg@merit.edu>; Mon, 16 Apr 2001 16:04:39 -0400 (EDT)
Received: from jariws1 ([193.229.23.128]) by fep01-app.kolumbus.fi
          (InterMail vM.5.01.02.00 201-253-122-103-20001017) with SMTP
          id <20010416200438.EFJD1819.fep01-app.kolumbus.fi@jariws1>;
          Mon, 16 Apr 2001 23:04:38 +0300
Message-ID: <003f01c0c6b6$ba61e820$8a1b6e0a@arenanet.fi>
From: "Jari Arkko" <jari.arkko@kolumbus.fi>
To: "Barney Wolff" <barney@databus.com>, "John Alayari" <johnal@cisco.com>
Cc: <aaa-wg@merit.edu>
References: <200104111952.MAA19361@nasnfs.Eng.Sun.COM> <CNEGKCBENOKKPJPNCEODCEHLCCAA.johnal@cisco.com> <20010416150302.A49597@mx.databus.com>
Subject: Re: [AAA-WG]: RE: Accounting-status-Ind & interim data
Date: Mon, 16 Apr 2001 23:49:27 +0300
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

>Um, we decided to forgo batched accounting, after discussion.

Correct. Let's not go there, and let's not bring up the 
issues such as proxying the batches in this discussion...

> Real-world, accounting would only be turned off as part of a
> controlled shutdown of the access server.  That should generate
> stops for each session without requiring special handling on
> either side.  In my experience, uncontrolled shutdowns or restarts
> are rather more common than controlled ones, even on equipment
> from highly-regarded vendors. :)  So the value of a We-Who-Are-
> About-To-Die-Salute-You command is limited, and any effort to
> optimize it misguided.

One thing we could perhaps do is to add language to the
diameter spec stating that if one is having a controlled
shutdown, then one SHOULD send the latest interim (or stop?)
records before ASI and before shutting down. Note that this could only
be a SHOULD, we can never require this to be always happening,
the client could easily be having serious trouble such as a 
power failure which does not allow it to send all records.

I do not propose adding the records to the ASI itself, let's keep that
part simple.

Jari






From owner-aaa-bof@merit.edu  Tue Apr 17 00:51:13 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA19622
	for <aaa-archive@odin.ietf.org>; Tue, 17 Apr 2001 00:51:13 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 2AADD5DE0F; Tue, 17 Apr 2001 00:48:53 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 088225DE23; Tue, 17 Apr 2001 00:48:53 -0400 (EDT)
Received: from redmailwall2.attws.com (redmailwall2.attws.com [199.108.253.116])
	by segue.merit.edu (Postfix) with ESMTP id 4FE3F5DE0F
	for <aaa-wg@merit.edu>; Tue, 17 Apr 2001 00:48:51 -0400 (EDT)
Received: from viruswall1.entp.attws.com ([155.176.34.45])
	by redmailwall2.attws.com (8.9.3/8.9.3) with ESMTP id VAA05637;
	Mon, 16 Apr 2001 21:47:07 -0700 (PDT)
Received: from neastmail.neast.attws.com by viruswall1.entp.attws.com (8.8.8+Sun/AT&T Wireless Services, Inc. V8 version 2)
	id VAA02585; Mon, 16 Apr 2001 21:45:57 -0700 (PDT)
Received: from ner-msgbh.wireless.attws.com (ner-msgbh.wireless.attws.com [135.216.177.192])
	by neastmail.neast.attws.com (8.8.8+Sun/8.8.8) with ESMTP id VAA24277;
	Mon, 16 Apr 2001 21:45:55 -0700 (PDT)
Received: by ner-msgbh.wireless.attws.com with Internet Mail Service (5.5.2653.19)
	id <23R6X64C>; Tue, 17 Apr 2001 00:45:54 -0400
Message-ID: <0D3BDFD96647D211B43A00805F15E58903AB68C0@NER-MSG03>
From: "Kobylarz, Thaddeus" <thaddeus.kobylarz@attws.com>
To: "'Jari Arkko'" <jari.arkko@kolumbus.fi>, Barney Wolff <barney@databus.com>,
        John Alayari <johnal@cisco.com>
Cc: aaa-wg@merit.edu, Bob Engelhart <BEngelha@attws-wr.swest.attws.com>,
        Chuck Adams <CAdams@attws-hq1.nwest.attws.com>,
        "Daly, Brian" <brian.daly@attws.com>, ileana.leuca@attws.com,
        John Molchan <JMolchan@attws-hq1.nwest.attws.com>,
        Luisa Marchetto <LMarchet@attws-hq1.nwest.attws.com>
Subject: RE: [AAA-WG]: RE: Accounting-status-Ind & interim data
Date: Tue, 17 Apr 2001 00:45:44 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

John,
	The proposal for a choice of FTP or TFTP for "batch" has not
received objections by the SA5 Charging group.  Do you see any problems with
this proposal?
Thad

-----Original Message-----
From: Jari Arkko [mailto:jari.arkko@kolumbus.fi]
Sent: Monday, April 16, 2001 4:49 PM
To: Barney Wolff; John Alayari
Cc: aaa-wg@merit.edu
Subject: Re: [AAA-WG]: RE: Accounting-status-Ind & interim data


>Um, we decided to forgo batched accounting, after discussion.

Correct. Let's not go there, and let's not bring up the 
issues such as proxying the batches in this discussion...

> Real-world, accounting would only be turned off as part of a
> controlled shutdown of the access server.  That should generate
> stops for each session without requiring special handling on
> either side.  In my experience, uncontrolled shutdowns or restarts
> are rather more common than controlled ones, even on equipment
> from highly-regarded vendors. :)  So the value of a We-Who-Are-
> About-To-Die-Salute-You command is limited, and any effort to
> optimize it misguided.

One thing we could perhaps do is to add language to the
diameter spec stating that if one is having a controlled
shutdown, then one SHOULD send the latest interim (or stop?)
records before ASI and before shutting down. Note that this could only
be a SHOULD, we can never require this to be always happening,
the client could easily be having serious trouble such as a 
power failure which does not allow it to send all records.

I do not propose adding the records to the ASI itself, let's keep that
part simple.

Jari






From owner-aaa-bof@merit.edu  Tue Apr 17 02:33:49 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA03745
	for <aaa-archive@odin.ietf.org>; Tue, 17 Apr 2001 02:33:48 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id CDE305DD8E; Tue, 17 Apr 2001 02:30:20 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id ADE0F5DE06; Tue, 17 Apr 2001 02:30:20 -0400 (EDT)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by segue.merit.edu (Postfix) with ESMTP id DD6325DD8E
	for <aaa-wg@merit.edu>; Tue, 17 Apr 2001 02:30:17 -0400 (EDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f3H6U9s23688;
	Tue, 17 Apr 2001 08:30:09 +0200 (MEST)
Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.27.159])
	by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f3H6U2K09636;
	Tue, 17 Apr 2001 09:30:02 +0300 (EET DST)
Message-ID: <3ADBE2EA.DE95DDBB@lmf.ericsson.se>
Date: Tue, 17 Apr 2001 09:30:02 +0300
From: Jari Arkko <Jari.Arkko@lmf.ericsson.se>
Organization: Oy L M Ericsson Ab
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: "Kobylarz, Thaddeus" <thaddeus.kobylarz@attws.com>
Cc: "'Jari Arkko'" <jari.arkko@kolumbus.fi>, Barney Wolff <barney@databus.com>,
        John Alayari <johnal@cisco.com>, aaa-wg@merit.edu,
        Bob Engelhart <BEngelha@attws-wr.swest.attws.com>,
        Chuck Adams <CAdams@attws-hq1.nwest.attws.com>,
        "Daly, Brian" <brian.daly@attws.com>, ileana.leuca@attws.com,
        John Molchan <JMolchan@attws-hq1.nwest.attws.com>,
        Luisa Marchetto <LMarchet@attws-hq1.nwest.attws.com>
Subject: Re: [AAA-WG]: RE: Accounting-status-Ind & interim data
References: <0D3BDFD96647D211B43A00805F15E58903AB68C0@NER-MSG03>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit


>The proposal for a choice of FTP or TFTP for "batch" has not
>received objections by the SA5 Charging group.  Do you see
>any problems with
>this proposal?

Perhaps I should clarify a little bit the background of
the batch discussion. After extensive discussions, it
was earlier decided that it is not necessary to support batch
mode in Diameter at the _message level_. However, the
protocol still supports batching at the _transport level_,
i.e. from the network point of view you will still
get the same behaviour. Main issues in the decision
to handle batching in this manner were the observation
that the transport layer can do this, and the difficulties
in handling Diameter-level batches in a reasonable manner
through proxies. In other words, cryptographic operations
and protocol acknowledgements get complicated when parts
of the batch end up in one direction while the rest goes
to another.

The current discussion is about the use of batches to
send data from a dying Diameter client. My proposal for
handling this situation is specifying that the client
SHOULD send the data before the i'm-dying message if
it still can. This sending takes place through normal
diameter mechanisms, and is also batchable at the transport
level. 

In the latest IETF meeting, we discussed the prioritizing
of accounting records which was a 3GPP requirement. I
made the proposal that a priority attribute added
to the records would be sufficient for a node to decide
how fast a particular record should be treated; real-time
records would go directly to the processing and sent
further to the next transport from the proxy, and batch
records could wait until there is time and bandwidth available
for processing them.

Regarding the use FTP or TFTP, they are widely used
for batching. Issues that you may want to think about
include the following:

- Making sure there is some application or IP level
  security involved so that the transport is secured.

- The proxying of batches is an equivalently hard problem
  for FTP and TFTP as it is for Diameter. If the 3GPP
  architecture includes proxies, specify rules on how
  batches are handled in them.

- How the batching is iniated and controlled.

- I understand that real-time is also a main requirement
  in the 3GPP. In order to add batching, your basic choices
  are to use the real-time protocol (Diameter?) also
  for batching i.e. rely on the transport layer batching,
  or to use another batch protocol (e.g. ftp). You may
  want to have clear requirements on why to do one or the
  other. In fact I'm not even sure what the difference
  in characteristics would be on the two alternatives.

Jari



From owner-aaa-bof@merit.edu  Tue Apr 17 08:08:51 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA05887
	for <aaa-archive@odin.ietf.org>; Tue, 17 Apr 2001 08:08:51 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 6EFF25DDDB; Tue, 17 Apr 2001 08:08:33 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 563A35DDE0; Tue, 17 Apr 2001 08:08:33 -0400 (EDT)
Received: from mailgw.local.ipunplugged.com (unknown [213.88.134.217])
	by segue.merit.edu (Postfix) with ESMTP id DC8B35DDDB
	for <aaa-wg@merit.edu>; Tue, 17 Apr 2001 08:08:26 -0400 (EDT)
Received: from fredrikj (c42.local.ipunplugged.com [192.168.4.241])
	by mailgw.local.ipunplugged.com (8.9.3/8.9.3) with SMTP id OAA08182;
	Tue, 17 Apr 2001 14:09:31 +0200
From: "Fredrik Johansson" <fredrik.johansson@ipunplugged.com>
To: <pcalhoun@eng.sun.com>,
        "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>,
        "Tony Johansson" <tony.johansson@ericsson.com>
Cc: "AAA Listan" <aaa-wg@merit.edu>
Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
Date: Tue, 17 Apr 2001 14:10:13 +0200
Message-ID: <MJEMJBGGCLLDLFFAHLJKEECHCKAA.fredrik.johansson@ipunplugged.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <MJEMJBGGCLLDLFFAHLJKIEPMCJAA.fredrik.johansson@ipunplugged.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Pat,

here is the suggested text as promised.

11.7  Session Movement

   When a user moves between different access devices it may be desirable
   to keep the Session Id unchanged. It is therefore possible for a
   server to send the original Session Id back to the requester in the
   Original-Session-Id AVP. If the AAA server already has a
sessionidentifier

11.7.1  Original-Session-Id AVP

   The Original-Session-Id AVP (AVP Code 261) is of type OctetString and
   MAY be sent in a message of type Response or Answer if the Home AAA
   server already has a session identifier for the user, and wishes to
   keep the existing Session-Id. All further messages from the Access
   Device for this session MUST use the session identifier in this AVP.
   This shouldn't be viewed as a new session, but rather renaming the
   old session.

11.8  Session Termination

   The Diameter Base Protocol provides a set of messages that MUST be
   used by any peer to explicitly request that a previously
   authenticated and/or authorized session be terminated. Since the
   Session-Id is typically tied to a particular service (i.e. Mobile IP,
   NASREQ, etc), the session termination messages are used to request
   that the service tied to the Session Id be terminated.


>-----Original Message-----
>From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf
>Of Fredrik Johansson
>Sent: den 12 april 2001 10:04
>To: pcalhoun@eng.sun.com; Martin Julien (ECE); Tony Johansson
>Cc: AAA Listan
>Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
>
>
>No, no additional AVPs is required. However, I believe some explanations
>should be provided on how to treat the  request in different nodes. I'll
>give you some text after the weekend that hopefully will give you
>some ideas
>what I mean. Untill then I will enjoy a couple of days skiing :-)
>
>/Fredrik
>
>>-----Original Message-----
>>From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf
>>Of Patrice Calhoun
>>Sent: den 11 april 2001 19:32
>>To: Fredrik Johansson; Martin Julien (ECE); Tony Johansson
>>Cc: AAA Listan
>>Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
>>
>>
>>and no additional protocol text (read AVPs) is required???
>>
>>PatC
>>>>
>>>>Just to make sure, I *presume* that this proposed text is to
>>belong in the
>>>>Mobile IP extension, right?
>>>
>>>Yes, that's correct
>>>
>>>/Fredrik
>>>
>>>>
>>>>PatC
>>>>
>>>>ps: for those that saw my "I will not be responding to e-mail this
>>>>week", I
>>>>happen to be in a city that has metricom service :)
>>>>
>>>>>Cool! I was about to send you something very similar to know
>>>>>if it was what you meant in your previous mail.
>>>>>I agree with your solution. Thanks!
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Fredrik Johansson [mailto:fredrik.johansson@ipunplugged.com]
>>>>>> Sent: Tuesday, April 10, 2001 10:27 AM
>>>>>> To: Martin Julien (ECE); Tony Johansson
>>>>>> Cc: 'Patrice Calhoun'; AAA Listan
>>>>>> Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
>>>>>>
>>>>>>
>>>>>> After a closer look at the problem we have a suggestion on a
>solution.
>>>>>> If the AAAH always assigns a SPI that is unique in the HA for
>>>>>> the FA-HA key,
>>>>>> and a SPI that is unique in the Mn for the MN-FA and MN-HA keys, the
>>>>>> security contexts will automatically be unique in every SA.
>>>>>>
>>>>>> 7.5 SPI Allocation
>>>>>>   To ensure that the SPI is unique for each pair of nodes,
>>>>>>   the AAAH SHOULD keep track of assigned SPIs per HA and MN.
>>>>>>   The SPI assigned to the MN-FA key MUST be allocated from
>>>>>> the MN SPI pool,
>>>>>>   the SPI for the FA-HA key MUST be allocated from the HA SPI
>>>>>> pool, and the
>>>>>>   SPI for the MN-HA key MUST be allocated from the MN SPI
>>>>>> pool. Note that
>>>>>>   SPI values 0 through 255 are reserved and MUST NOT be used in any
>>>>>>   Mobility Security Association.
>>>>>>
>>>>>> /Fredrik
>>>>>> >-----Original Message-----
>>>>>> >From: owner-aaa-bof@merit.edu
>>>>>> [mailto:owner-aaa-bof@merit.edu]On Behalf
>>>>>> >Of Fredrik Johansson
>>>>>> >Sent: den 10 april 2001 08:40
>>>>>> >To: Martin Julien (ECE); Tony Johansson
>>>>>> >Cc: 'Patrice Calhoun'; AAA Listan
>>>>>> >Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
>>>>>> >
>>>>>> >
>>>>>> >>
>>>>>> >>> >>
>>>>>> >>> >> Another thing that needs some clarification, if there is a
>>>>>> >>> solution. How
>>>>>> >>> >> will the HA know which SA to use. In the case where a mobile
>>>>>> >>> >moves from one
>>>>>> >>> >> Fa to another under the same administrative domain it may
>>>>>> >>> receive the
>>>>>> >>> >> session keys for the old Fa from the AAAF. It will
>then proceed
>>>>>> >>> >to send the
>>>>>> >>> >> mip reg req to the HA. The HA will see that the message came
>>>>>> >>> >from the new FA
>>>>>> >>> >> and try to locate the SA shared with that FA. It will not find
>>>>>> >>> >it since it
>>>>>> >>> >> was established with the old FA. Eventhough the HA can see
>>>>>> >>> the address of
>>>>>> >>> >> the old Fa in the previous-fa-XXXX it is not clear that it can
>>>>>> >>> >establish a
>>>>>> >>> >> SA with the new Fa because it has to use the same SPI
>as before
>>>>>> >>> >and that one
>>>>>> >>> >> might be busy. Or have I missed something here?
>>>>>> >>> >
>>>>>> >>> >You also have the user NAI in the MIP registration
>>>>>> request sent to
>>>>>> >>> >the HA and
>>>>>> >>> >the user NAI is globally unique....
>>>>>> >>>
>>>>>> >>> Yes, but this is not the security association shared with the
>>>>>> >>> mobile node
>>>>>> >>> but the one shared between the FA and HA, thus has nothing to
>>>>>> >>> do with the
>>>>>> >>> user.
>>>>>> >>
>>>>>> >>I think you are assuming that there exists only 1 mobility
>>>>>> SA between
>>>>>> >>a FA and a HA for all the MIP sessions, right?
>>>>>> >
>>>>>> >YES, one mobility SA, ceveral security context within a mobility
>>>>>> >SA. See rfc
>>>>>> >2002,
>>>>>> >
>>>>>> >"Mobility Security Association
>>>>>> >               A collection of security contexts, between a pair
>>>>>> >               of nodes, which may be applied to Mobile IP protocol
>>>>>> >               messages exchanged between them.  Each
>>>>>> context indicates
>>>>>> >               an authentication algorithm and mode (Section 5.1), a
>>>>>> >               secret (a shared key, or appropriate public/private
>>>>>> >               key pair), and a style of replay protection in use
>>>>>> >               (Section 5.6)."
>>>>>> >
>>>>>> >Each context is indexed with a unique SPI within that SA, if
>>>>>> there exist a
>>>>>> >SA between the HA and the old FA and one SA between the HA
>>>>>> and the new FA
>>>>>> >there might exist security context with the same SPI in both
>>>>>> of these.
>>>>>> >
>>>>>> >"Security Parameter Index (SPI)
>>>>>> >               An index identifying a security context
>between a pair
>>>>>> >               of nodes among the contexts available in the Mobility
>>>>>> >               Security Association.  SPI values 0 through 255 are
>>>>>> >               reserved and MUST NOT be used in any
>Mobility Security
>>>>>> >               Association."
>>>>>> >
>>>>>> >>When a first AMA is received
>>>>>> >
>>>>>> >I guess you mean AMR :-)
>>>>>> >
>>>>>> >>in the AAAH from a MN, is the AAAH supposed to issue a new
>>>>>> registration
>>>>>> >>FA-HA key, in the case the HA is in the home domain? The
>>>>>> spec says "yes",
>>>>>> >>if it is required by the MN. However, how can the MN know about the
>>>>>> >>mobility SA between the FA and the HA? I guess it can not,
>>>>>> which means
>>>>>> >>that it will ask for a new key, which should be transferred
>>>>>> to the FA and
>>>>>> >>the HA from the AAAH. Is there a way for the HA to notify the AAAH
>>>>>> >>that it does not need
>>>>>> >>a new key and a new SPI for its mobility SA with the FA, since it
>>>>>> >>already has one? I guess
>>>>>> >>not, right? Then, it looks like your idea could be very
>>>>>> interesting, but
>>>>>> >>I don't know how to deal with it using Diameter, unless the
>>>>>> AAAH and AAAF
>>>>>> >>would keep a list of mobility SAs between each FA and HA.
>>>>>> >
>>>>>> >In some way the AAAH must keep track of what SPIs it has
>>>>>> assigned to the
>>>>>> >home agent, if it does it per SA or make the SPI unique over all
>>>>>> >SA's in the
>>>>>> >HA is up to the implementation
>>>>>> >
>>>>>> >>
>>>>>> >>> You can not guarantee that a security between the HA and
>>>>>> the old FA is
>>>>>> >>> unique between the HA and the new FA. The same SPI must be
>>>>>> >>> used in the first
>>>>>> >>> request in order for the HA to be able to distinguise between
>>>>>> >>> different
>>>>>> >>> security contexts it shares with the FA. What we can do is to
>>>>>> >>> have the new
>>>>>> >>> FA add a <MIP-Preferred-SPI Ext> in the first request from
>>>>>> >>> the new FA to the
>>>>>> >>> HA, the HA can then use the <Previous-FA-XXXX Ext> together
>>>>>> >>> with the old SPI
>>>>>> >>> to retreive the context and store it under the Preferred SPI
>>>>>> >>> under the SA
>>>>>> >>> with the new FA.
>>>>>> >>
>>>>>> >>I was wondering whether or not a mobility SA between a FA
>>>>>> >>and a HA was based on a particular MIP session? My understanding
>>>>>> >>_IS_ that an existing SA is based on a MIP session. That means
>>>>>> >>that between a FA and a HA, there exists several mobility SAs
>>>>>> >>depending on each MIP session.
>>>>>> >
>>>>>> >No, there is only one SA between two nodes, but there are
>>>>>> several security
>>>>>> >context within each SA. Each security context can
>>>>>> corresponde to a mip
>>>>>> >session. It is the security context that has a lifetime, the
>>>>>> SA can be
>>>>>> >removed when the last security context is removed.
>>>>>> >
>>>>>> >>By MIP session, I mean an AAA
>>>>>> >>authorized session for MIP. The SPI is already included in the
>>>>>> >>key transferred between the AAAF and the new FA. I don't see
>>>>>> >>why a HA could not use the SPI stored under its MN User-Name
>>>>>> >>state to retrieve the mobility SA between the new FA and itself?
>>>>>> >
>>>>>> >Because the SA between the FA and HA does not realy have anything
>>>>>> >to do with
>>>>>> >the Mn. It is something setup between the FA and HA. Thus
>>>>>> when the HA will
>>>>>> >look for the key to use it will do the lookup on the FA address.
>>>>>> >
>>>>>> >/Fredrik
>>>>>> >
>>>>>> >>
>>>>>> >>Regards,
>>>>>> >>Martin
>>>>>> >
>>>>>>
>>>>
>>>>
>>
>>
>




From owner-aaa-bof@merit.edu  Tue Apr 17 09:15:18 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06922
	for <aaa-archive@odin.ietf.org>; Tue, 17 Apr 2001 09:15:17 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 3B22E5DDF3; Tue, 17 Apr 2001 08:59:18 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 298A05DDEF; Tue, 17 Apr 2001 08:59:18 -0400 (EDT)
Received: from mailgw.local.ipunplugged.com (unknown [213.88.134.217])
	by segue.merit.edu (Postfix) with ESMTP id 0693C5DDEC
	for <aaa-wg@merit.edu>; Tue, 17 Apr 2001 08:59:16 -0400 (EDT)
Received: from fredrikj (c42.local.ipunplugged.com [192.168.4.241])
	by mailgw.local.ipunplugged.com (8.9.3/8.9.3) with SMTP id PAA09189;
	Tue, 17 Apr 2001 15:00:19 +0200
From: "Fredrik Johansson" <fredrik.johansson@ipunplugged.com>
To: <pcalhoun@eng.sun.com>,
        "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>,
        "Tony Johansson" <tony.johansson@ericsson.com>
Cc: "AAA Listan" <aaa-wg@merit.edu>
Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
Date: Tue, 17 Apr 2001 15:01:01 +0200
Message-ID: <MJEMJBGGCLLDLFFAHLJKMECJCKAA.fredrik.johansson@ipunplugged.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <MJEMJBGGCLLDLFFAHLJKEECHCKAA.fredrik.johansson@ipunplugged.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Ok, let's see if I can write the entire message this time before sending it
:-)
There might be a problem with the possiblity to reuse the old session id,
and
that is that there can only be one session per user. I don't know if this
limitation
is to harsh.

/Fredrik

11.7  Session Movement

   When a user moves between different access devices it may be desirable
   to keep the Session Id unchanged. It is therefore possible for a
   server to send the original Session Id back to the client in the
   Original-Session-Id AVP. An old session is identified by the User Name
   Nai.

11.7.1  Original-Session-Id AVP

   The Original-Session-Id AVP (AVP Code 261) is of type OctetString and
   MAY be sent in a message of type Response or Answer if the AAA
   server already has a session identifier for the user, and wishes to
   keep the existing Session-Id. All further messages from the Access
   Device for this session MUST use the session identifier in this AVP.
   This shouldn't be viewed as a new session, but rather renaming the
   old session. Any message not using the Session Id in this AVP will be
   treated as an unrecognized Session Id.

11.8  Session Termination

   The Diameter Base Protocol provides a set of messages that MUST be
   used by any peer to explicitly request that a previously
   authenticated and/or authorized session be terminated. Since the
   Session-Id is typically tied to a particular service (i.e. Mobile IP,
   NASREQ, etc), the session termination messages are used to request
   that the service tied to the Session Id be terminated.



>>-----Original Message-----
>>From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf
>>Of Fredrik Johansson
>>Sent: den 12 april 2001 10:04
>>To: pcalhoun@eng.sun.com; Martin Julien (ECE); Tony Johansson
>>Cc: AAA Listan
>>Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
>>
>>
>>No, no additional AVPs is required. However, I believe some explanations
>>should be provided on how to treat the  request in different nodes. I'll
>>give you some text after the weekend that hopefully will give you
>>some ideas
>>what I mean. Untill then I will enjoy a couple of days skiing :-)
>>
>>/Fredrik
>>
>>>-----Original Message-----
>>>From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf
>>>Of Patrice Calhoun
>>>Sent: den 11 april 2001 19:32
>>>To: Fredrik Johansson; Martin Julien (ECE); Tony Johansson
>>>Cc: AAA Listan
>>>Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
>>>
>>>
>>>and no additional protocol text (read AVPs) is required???
>>>
>>>PatC
>>>>>
>>>>>Just to make sure, I *presume* that this proposed text is to
>>>belong in the
>>>>>Mobile IP extension, right?
>>>>
>>>>Yes, that's correct
>>>>
>>>>/Fredrik
>>>>
>>>>>
>>>>>PatC
>>>>>
>>>>>ps: for those that saw my "I will not be responding to e-mail this
>>>>>week", I
>>>>>happen to be in a city that has metricom service :)
>>>>>
>>>>>>Cool! I was about to send you something very similar to know
>>>>>>if it was what you meant in your previous mail.
>>>>>>I agree with your solution. Thanks!
>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Fredrik Johansson [mailto:fredrik.johansson@ipunplugged.com]
>>>>>>> Sent: Tuesday, April 10, 2001 10:27 AM
>>>>>>> To: Martin Julien (ECE); Tony Johansson
>>>>>>> Cc: 'Patrice Calhoun'; AAA Listan
>>>>>>> Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
>>>>>>>
>>>>>>>
>>>>>>> After a closer look at the problem we have a suggestion on a
>>solution.
>>>>>>> If the AAAH always assigns a SPI that is unique in the HA for
>>>>>>> the FA-HA key,
>>>>>>> and a SPI that is unique in the Mn for the MN-FA and MN-HA keys, the
>>>>>>> security contexts will automatically be unique in every SA.
>>>>>>>
>>>>>>> 7.5 SPI Allocation
>>>>>>>   To ensure that the SPI is unique for each pair of nodes,
>>>>>>>   the AAAH SHOULD keep track of assigned SPIs per HA and MN.
>>>>>>>   The SPI assigned to the MN-FA key MUST be allocated from
>>>>>>> the MN SPI pool,
>>>>>>>   the SPI for the FA-HA key MUST be allocated from the HA SPI
>>>>>>> pool, and the
>>>>>>>   SPI for the MN-HA key MUST be allocated from the MN SPI
>>>>>>> pool. Note that
>>>>>>>   SPI values 0 through 255 are reserved and MUST NOT be used in any
>>>>>>>   Mobility Security Association.
>>>>>>>
>>>>>>> /Fredrik
>>>>>>> >-----Original Message-----
>>>>>>> >From: owner-aaa-bof@merit.edu
>>>>>>> [mailto:owner-aaa-bof@merit.edu]On Behalf
>>>>>>> >Of Fredrik Johansson
>>>>>>> >Sent: den 10 april 2001 08:40
>>>>>>> >To: Martin Julien (ECE); Tony Johansson
>>>>>>> >Cc: 'Patrice Calhoun'; AAA Listan
>>>>>>> >Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
>>>>>>> >
>>>>>>> >
>>>>>>> >>
>>>>>>> >>> >>
>>>>>>> >>> >> Another thing that needs some clarification, if there is a
>>>>>>> >>> solution. How
>>>>>>> >>> >> will the HA know which SA to use. In the case where a mobile
>>>>>>> >>> >moves from one
>>>>>>> >>> >> Fa to another under the same administrative domain it may
>>>>>>> >>> receive the
>>>>>>> >>> >> session keys for the old Fa from the AAAF. It will
>>then proceed
>>>>>>> >>> >to send the
>>>>>>> >>> >> mip reg req to the HA. The HA will see that the message came
>>>>>>> >>> >from the new FA
>>>>>>> >>> >> and try to locate the SA shared with that FA. It
>will not find
>>>>>>> >>> >it since it
>>>>>>> >>> >> was established with the old FA. Eventhough the HA can see
>>>>>>> >>> the address of
>>>>>>> >>> >> the old Fa in the previous-fa-XXXX it is not clear
>that it can
>>>>>>> >>> >establish a
>>>>>>> >>> >> SA with the new Fa because it has to use the same SPI
>>as before
>>>>>>> >>> >and that one
>>>>>>> >>> >> might be busy. Or have I missed something here?
>>>>>>> >>> >
>>>>>>> >>> >You also have the user NAI in the MIP registration
>>>>>>> request sent to
>>>>>>> >>> >the HA and
>>>>>>> >>> >the user NAI is globally unique....
>>>>>>> >>>
>>>>>>> >>> Yes, but this is not the security association shared with the
>>>>>>> >>> mobile node
>>>>>>> >>> but the one shared between the FA and HA, thus has nothing to
>>>>>>> >>> do with the
>>>>>>> >>> user.
>>>>>>> >>
>>>>>>> >>I think you are assuming that there exists only 1 mobility
>>>>>>> SA between
>>>>>>> >>a FA and a HA for all the MIP sessions, right?
>>>>>>> >
>>>>>>> >YES, one mobility SA, ceveral security context within a mobility
>>>>>>> >SA. See rfc
>>>>>>> >2002,
>>>>>>> >
>>>>>>> >"Mobility Security Association
>>>>>>> >               A collection of security contexts, between a pair
>>>>>>> >               of nodes, which may be applied to Mobile IP protocol
>>>>>>> >               messages exchanged between them.  Each
>>>>>>> context indicates
>>>>>>> >               an authentication algorithm and mode
>(Section 5.1), a
>>>>>>> >               secret (a shared key, or appropriate public/private
>>>>>>> >               key pair), and a style of replay protection in use
>>>>>>> >               (Section 5.6)."
>>>>>>> >
>>>>>>> >Each context is indexed with a unique SPI within that SA, if
>>>>>>> there exist a
>>>>>>> >SA between the HA and the old FA and one SA between the HA
>>>>>>> and the new FA
>>>>>>> >there might exist security context with the same SPI in both
>>>>>>> of these.
>>>>>>> >
>>>>>>> >"Security Parameter Index (SPI)
>>>>>>> >               An index identifying a security context
>>between a pair
>>>>>>> >               of nodes among the contexts available in
>the Mobility
>>>>>>> >               Security Association.  SPI values 0 through 255 are
>>>>>>> >               reserved and MUST NOT be used in any
>>Mobility Security
>>>>>>> >               Association."
>>>>>>> >
>>>>>>> >>When a first AMA is received
>>>>>>> >
>>>>>>> >I guess you mean AMR :-)
>>>>>>> >
>>>>>>> >>in the AAAH from a MN, is the AAAH supposed to issue a new
>>>>>>> registration
>>>>>>> >>FA-HA key, in the case the HA is in the home domain? The
>>>>>>> spec says "yes",
>>>>>>> >>if it is required by the MN. However, how can the MN know
>about the
>>>>>>> >>mobility SA between the FA and the HA? I guess it can not,
>>>>>>> which means
>>>>>>> >>that it will ask for a new key, which should be transferred
>>>>>>> to the FA and
>>>>>>> >>the HA from the AAAH. Is there a way for the HA to notify the AAAH
>>>>>>> >>that it does not need
>>>>>>> >>a new key and a new SPI for its mobility SA with the FA, since it
>>>>>>> >>already has one? I guess
>>>>>>> >>not, right? Then, it looks like your idea could be very
>>>>>>> interesting, but
>>>>>>> >>I don't know how to deal with it using Diameter, unless the
>>>>>>> AAAH and AAAF
>>>>>>> >>would keep a list of mobility SAs between each FA and HA.
>>>>>>> >
>>>>>>> >In some way the AAAH must keep track of what SPIs it has
>>>>>>> assigned to the
>>>>>>> >home agent, if it does it per SA or make the SPI unique over all
>>>>>>> >SA's in the
>>>>>>> >HA is up to the implementation
>>>>>>> >
>>>>>>> >>
>>>>>>> >>> You can not guarantee that a security between the HA and
>>>>>>> the old FA is
>>>>>>> >>> unique between the HA and the new FA. The same SPI must be
>>>>>>> >>> used in the first
>>>>>>> >>> request in order for the HA to be able to distinguise between
>>>>>>> >>> different
>>>>>>> >>> security contexts it shares with the FA. What we can do is to
>>>>>>> >>> have the new
>>>>>>> >>> FA add a <MIP-Preferred-SPI Ext> in the first request from
>>>>>>> >>> the new FA to the
>>>>>>> >>> HA, the HA can then use the <Previous-FA-XXXX Ext> together
>>>>>>> >>> with the old SPI
>>>>>>> >>> to retreive the context and store it under the Preferred SPI
>>>>>>> >>> under the SA
>>>>>>> >>> with the new FA.
>>>>>>> >>
>>>>>>> >>I was wondering whether or not a mobility SA between a FA
>>>>>>> >>and a HA was based on a particular MIP session? My understanding
>>>>>>> >>_IS_ that an existing SA is based on a MIP session. That means
>>>>>>> >>that between a FA and a HA, there exists several mobility SAs
>>>>>>> >>depending on each MIP session.
>>>>>>> >
>>>>>>> >No, there is only one SA between two nodes, but there are
>>>>>>> several security
>>>>>>> >context within each SA. Each security context can
>>>>>>> corresponde to a mip
>>>>>>> >session. It is the security context that has a lifetime, the
>>>>>>> SA can be
>>>>>>> >removed when the last security context is removed.
>>>>>>> >
>>>>>>> >>By MIP session, I mean an AAA
>>>>>>> >>authorized session for MIP. The SPI is already included in the
>>>>>>> >>key transferred between the AAAF and the new FA. I don't see
>>>>>>> >>why a HA could not use the SPI stored under its MN User-Name
>>>>>>> >>state to retrieve the mobility SA between the new FA and itself?
>>>>>>> >
>>>>>>> >Because the SA between the FA and HA does not realy have anything
>>>>>>> >to do with
>>>>>>> >the Mn. It is something setup between the FA and HA. Thus
>>>>>>> when the HA will
>>>>>>> >look for the key to use it will do the lookup on the FA address.
>>>>>>> >
>>>>>>> >/Fredrik
>>>>>>> >
>>>>>>> >>
>>>>>>> >>Regards,
>>>>>>> >>Martin
>>>>>>> >
>>>>>>>
>>>>>
>>>>>
>>>
>>>
>>
>




From owner-aaa-bof@merit.edu  Tue Apr 17 10:15:07 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08228
	for <aaa-archive@odin.ietf.org>; Tue, 17 Apr 2001 10:15:06 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 169515DDAC; Tue, 17 Apr 2001 10:14:42 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 02F565DDAB; Tue, 17 Apr 2001 10:14:41 -0400 (EDT)
Received: from redmailwall2.attws.com (redmailwall2.attws.com [199.108.253.116])
	by segue.merit.edu (Postfix) with ESMTP id 2BEF95DD94
	for <aaa-wg@merit.edu>; Tue, 17 Apr 2001 10:14:40 -0400 (EDT)
Received: from viruswall1.entp.attws.com ([155.176.34.45])
	by redmailwall2.attws.com (8.9.3/8.9.3) with ESMTP id HAA24164;
	Tue, 17 Apr 2001 07:12:52 -0700 (PDT)
Received: from neastmail.neast.attws.com by viruswall1.entp.attws.com (8.8.8+Sun/AT&T Wireless Services, Inc. V8 version 2)
	id HAA18989; Tue, 17 Apr 2001 07:14:15 -0700 (PDT)
Received: from ner-msgbh.wireless.attws.com (ner-msgbh.wireless.attws.com [135.216.177.192])
	by neastmail.neast.attws.com (8.8.8+Sun/8.8.8) with ESMTP id HAA08113;
	Tue, 17 Apr 2001 07:14:12 -0700 (PDT)
Received: by ner-msgbh.wireless.attws.com with Internet Mail Service (5.5.2653.19)
	id <23R6X0RB>; Tue, 17 Apr 2001 10:14:11 -0400
Message-ID: <0D3BDFD96647D211B43A00805F15E58903AB68C2@NER-MSG03>
From: "Kobylarz, Thaddeus" <thaddeus.kobylarz@attws.com>
To: "'Jari Arkko'" <Jari.Arkko@lmf.ericsson.se>
Cc: "'Jari Arkko'" <jari.arkko@kolumbus.fi>, Barney Wolff <barney@databus.com>,
        John Alayari <johnal@cisco.com>, aaa-wg@merit.edu,
        "Engelhart, Bob" <BEngelha@attws-wr.swest.attws.com>,
        "Adams, Chuck" <CAdams@attws-wr.swest.attws.com>,
        "Daly, Brian" <brian.daly@attws.com>, ileana.leuca@attws.com,
        "Molchan, John" <JMolchan@attws-wr.swest.attws.com>,
        "Marchetto, Luisa" <LMarchet@attws-wr.swest.attws.com>
Subject: RE: [AAA-WG]: RE: Accounting-status-Ind & interim data
Date: Tue, 17 Apr 2001 10:14:10 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Jari,
	Thanks for your input, especially the idea of doing batching at the
transport level by conveying a priority flag.  This appears to be simpler
than the switching from Diameter to FTP or TFTP.  I will to take these
thoughts and caveats to the 3GPP Charging folks.
	I'll keep you informed of their responses and look forward to your
future comments.
Thad

-----Original Message-----
From: Jari Arkko [mailto:Jari.Arkko@lmf.ericsson.se]
Sent: Tuesday, April 17, 2001 2:30 AM
To: Kobylarz, Thaddeus
Cc: 'Jari Arkko'; Barney Wolff; John Alayari; aaa-wg@merit.edu; Bob
Engelhart; Chuck Adams; Daly, Brian; ileana.leuca@attws.com; John
Molchan; Luisa Marchetto
Subject: Re: [AAA-WG]: RE: Accounting-status-Ind & interim data



>The proposal for a choice of FTP or TFTP for "batch" has not
>received objections by the SA5 Charging group.  Do you see
>any problems with
>this proposal?

Perhaps I should clarify a little bit the background of
the batch discussion. After extensive discussions, it
was earlier decided that it is not necessary to support batch
mode in Diameter at the _message level_. However, the
protocol still supports batching at the _transport level_,
i.e. from the network point of view you will still
get the same behaviour. Main issues in the decision
to handle batching in this manner were the observation
that the transport layer can do this, and the difficulties
in handling Diameter-level batches in a reasonable manner
through proxies. In other words, cryptographic operations
and protocol acknowledgements get complicated when parts
of the batch end up in one direction while the rest goes
to another.

The current discussion is about the use of batches to
send data from a dying Diameter client. My proposal for
handling this situation is specifying that the client
SHOULD send the data before the i'm-dying message if
it still can. This sending takes place through normal
diameter mechanisms, and is also batchable at the transport
level. 

In the latest IETF meeting, we discussed the prioritizing
of accounting records which was a 3GPP requirement. I
made the proposal that a priority attribute added
to the records would be sufficient for a node to decide
how fast a particular record should be treated; real-time
records would go directly to the processing and sent
further to the next transport from the proxy, and batch
records could wait until there is time and bandwidth available
for processing them.

Regarding the use FTP or TFTP, they are widely used
for batching. Issues that you may want to think about
include the following:

- Making sure there is some application or IP level
  security involved so that the transport is secured.

- The proxying of batches is an equivalently hard problem
  for FTP and TFTP as it is for Diameter. If the 3GPP
  architecture includes proxies, specify rules on how
  batches are handled in them.

- How the batching is iniated and controlled.

- I understand that real-time is also a main requirement
  in the 3GPP. In order to add batching, your basic choices
  are to use the real-time protocol (Diameter?) also
  for batching i.e. rely on the transport layer batching,
  or to use another batch protocol (e.g. ftp). You may
  want to have clear requirements on why to do one or the
  other. In fact I'm not even sure what the difference
  in characteristics would be on the two alternatives.

Jari



From owner-aaa-bof@merit.edu  Tue Apr 17 10:28:46 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08544
	for <aaa-archive@odin.ietf.org>; Tue, 17 Apr 2001 10:28:43 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 530AE5DDE8; Tue, 17 Apr 2001 10:28:23 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 401715DD95; Tue, 17 Apr 2001 10:28:23 -0400 (EDT)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by segue.merit.edu (Postfix) with ESMTP id 0288E5DDAB
	for <aaa-wg@merit.edu>; Tue, 17 Apr 2001 10:28:20 -0400 (EDT)
Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f3HESJP19344
	for <aaa-wg@merit.edu>; Tue, 17 Apr 2001 16:28:19 +0200 (MEST)
Received: FROM esealnt743.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Tue Apr 17 16:28:14 2001 +0200
Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <HA3DJCGK>; Tue, 17 Apr 2001 16:28:14 +0200
Message-ID: <577066326047D41180AC00508B955DDA01D7FF81@eestqnt104.es.eu.ericsson.se>
From: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>
To: "'Fredrik Johansson'" <fredrik.johansson@ipunplugged.com>,
        pcalhoun@eng.sun.com,
        "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>,
        Tony Johansson <tony.johansson@ericsson.com>
Cc: AAA Listan <aaa-wg@merit.edu>
Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
Date: Tue, 17 Apr 2001 16:28:03 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Hej Fredrik,

If the Session-ID would be generated and handled by the MN, I guess it would be a lot easier. At least, we could propose a way of generating a Session-ID in the FA, such as the concatenation of the User-Name and the Care-Of address (FA), which would lead to a predictable Session-ID. In the case where the MN would move to a new FA, then the new FA would need to generate a Session-ID based on the User-Name and the MIP-Previous-FA-XXXX. Would that make any sense? Then, I guess we could have several different MIP sessions for the same User, as long as it is using different MNs. To support more than one session per MN, I guess the MN would need to include additional info about that.

We are having the same kind of problems WRT SIP, I believe.

Martin

> -----Original Message-----
> From: Fredrik Johansson [mailto:fredrik.johansson@ipunplugged.com]
> Sent: Tuesday, April 17, 2001 3:01 PM
> To: pcalhoun@eng.sun.com; Martin Julien (ECE); Tony Johansson
> Cc: AAA Listan
> Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
> 
> 
> Ok, let's see if I can write the entire message this time 
> before sending it
> :-)
> There might be a problem with the possiblity to reuse the old 
> session id,
> and
> that is that there can only be one session per user. I don't 
> know if this
> limitation
> is to harsh.
> 
> /Fredrik
> 
> 11.7  Session Movement
> 
>    When a user moves between different access devices it may 
> be desirable
>    to keep the Session Id unchanged. It is therefore possible for a
>    server to send the original Session Id back to the client in the
>    Original-Session-Id AVP. An old session is identified by 
> the User Name
>    Nai.
> 
> 11.7.1  Original-Session-Id AVP
> 
>    The Original-Session-Id AVP (AVP Code 261) is of type 
> OctetString and
>    MAY be sent in a message of type Response or Answer if the AAA
>    server already has a session identifier for the user, and wishes to
>    keep the existing Session-Id. All further messages from the Access
>    Device for this session MUST use the session identifier in 
> this AVP.
>    This shouldn't be viewed as a new session, but rather renaming the
>    old session. Any message not using the Session Id in this 
> AVP will be
>    treated as an unrecognized Session Id.
> 
> 11.8  Session Termination
> 
>    The Diameter Base Protocol provides a set of messages that MUST be
>    used by any peer to explicitly request that a previously
>    authenticated and/or authorized session be terminated. Since the
>    Session-Id is typically tied to a particular service (i.e. 
> Mobile IP,
>    NASREQ, etc), the session termination messages are used to request
>    that the service tied to the Session Id be terminated.
> 
> 
> 
> >>-----Original Message-----
> >>From: owner-aaa-bof@merit.edu 
> [mailto:owner-aaa-bof@merit.edu]On Behalf
> >>Of Fredrik Johansson
> >>Sent: den 12 april 2001 10:04
> >>To: pcalhoun@eng.sun.com; Martin Julien (ECE); Tony Johansson
> >>Cc: AAA Listan
> >>Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
> >>
> >>
> >>No, no additional AVPs is required. However, I believe some 
> explanations
> >>should be provided on how to treat the  request in 
> different nodes. I'll
> >>give you some text after the weekend that hopefully will give you
> >>some ideas
> >>what I mean. Untill then I will enjoy a couple of days skiing :-)
> >>
> >>/Fredrik
> >>
> >>>-----Original Message-----
> >>>From: owner-aaa-bof@merit.edu 
> [mailto:owner-aaa-bof@merit.edu]On Behalf
> >>>Of Patrice Calhoun
> >>>Sent: den 11 april 2001 19:32
> >>>To: Fredrik Johansson; Martin Julien (ECE); Tony Johansson
> >>>Cc: AAA Listan
> >>>Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
> >>>
> >>>
> >>>and no additional protocol text (read AVPs) is required???
> >>>
> >>>PatC
> >>>>>
> >>>>>Just to make sure, I *presume* that this proposed text is to
> >>>belong in the
> >>>>>Mobile IP extension, right?
> >>>>
> >>>>Yes, that's correct
> >>>>
> >>>>/Fredrik
> >>>>
> >>>>>
> >>>>>PatC
> >>>>>
> >>>>>ps: for those that saw my "I will not be responding to 
> e-mail this
> >>>>>week", I
> >>>>>happen to be in a city that has metricom service :)
> >>>>>
> >>>>>>Cool! I was about to send you something very similar to know
> >>>>>>if it was what you meant in your previous mail.
> >>>>>>I agree with your solution. Thanks!
> >>>>>>
> >>>>>>> -----Original Message-----
> >>>>>>> From: Fredrik Johansson 
> [mailto:fredrik.johansson@ipunplugged.com]
> >>>>>>> Sent: Tuesday, April 10, 2001 10:27 AM
> >>>>>>> To: Martin Julien (ECE); Tony Johansson
> >>>>>>> Cc: 'Patrice Calhoun'; AAA Listan
> >>>>>>> Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
> >>>>>>>
> >>>>>>>
> >>>>>>> After a closer look at the problem we have a suggestion on a
> >>solution.
> >>>>>>> If the AAAH always assigns a SPI that is unique in the HA for
> >>>>>>> the FA-HA key,
> >>>>>>> and a SPI that is unique in the Mn for the MN-FA and 
> MN-HA keys, the
> >>>>>>> security contexts will automatically be unique in every SA.
> >>>>>>>
> >>>>>>> 7.5 SPI Allocation
> >>>>>>>   To ensure that the SPI is unique for each pair of nodes,
> >>>>>>>   the AAAH SHOULD keep track of assigned SPIs per HA and MN.
> >>>>>>>   The SPI assigned to the MN-FA key MUST be allocated from
> >>>>>>> the MN SPI pool,
> >>>>>>>   the SPI for the FA-HA key MUST be allocated from the HA SPI
> >>>>>>> pool, and the
> >>>>>>>   SPI for the MN-HA key MUST be allocated from the MN SPI
> >>>>>>> pool. Note that
> >>>>>>>   SPI values 0 through 255 are reserved and MUST NOT 
> be used in any
> >>>>>>>   Mobility Security Association.
> >>>>>>>
> >>>>>>> /Fredrik
> >>>>>>> >-----Original Message-----
> >>>>>>> >From: owner-aaa-bof@merit.edu
> >>>>>>> [mailto:owner-aaa-bof@merit.edu]On Behalf
> >>>>>>> >Of Fredrik Johansson
> >>>>>>> >Sent: den 10 april 2001 08:40
> >>>>>>> >To: Martin Julien (ECE); Tony Johansson
> >>>>>>> >Cc: 'Patrice Calhoun'; AAA Listan
> >>>>>>> >Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
> >>>>>>> >
> >>>>>>> >
> >>>>>>> >>
> >>>>>>> >>> >>
> >>>>>>> >>> >> Another thing that needs some clarification, 
> if there is a
> >>>>>>> >>> solution. How
> >>>>>>> >>> >> will the HA know which SA to use. In the case 
> where a mobile
> >>>>>>> >>> >moves from one
> >>>>>>> >>> >> Fa to another under the same administrative 
> domain it may
> >>>>>>> >>> receive the
> >>>>>>> >>> >> session keys for the old Fa from the AAAF. It will
> >>then proceed
> >>>>>>> >>> >to send the
> >>>>>>> >>> >> mip reg req to the HA. The HA will see that 
> the message came
> >>>>>>> >>> >from the new FA
> >>>>>>> >>> >> and try to locate the SA shared with that FA. It
> >will not find
> >>>>>>> >>> >it since it
> >>>>>>> >>> >> was established with the old FA. Eventhough 
> the HA can see
> >>>>>>> >>> the address of
> >>>>>>> >>> >> the old Fa in the previous-fa-XXXX it is not clear
> >that it can
> >>>>>>> >>> >establish a
> >>>>>>> >>> >> SA with the new Fa because it has to use the same SPI
> >>as before
> >>>>>>> >>> >and that one
> >>>>>>> >>> >> might be busy. Or have I missed something here?
> >>>>>>> >>> >
> >>>>>>> >>> >You also have the user NAI in the MIP registration
> >>>>>>> request sent to
> >>>>>>> >>> >the HA and
> >>>>>>> >>> >the user NAI is globally unique....
> >>>>>>> >>>
> >>>>>>> >>> Yes, but this is not the security association 
> shared with the
> >>>>>>> >>> mobile node
> >>>>>>> >>> but the one shared between the FA and HA, thus 
> has nothing to
> >>>>>>> >>> do with the
> >>>>>>> >>> user.
> >>>>>>> >>
> >>>>>>> >>I think you are assuming that there exists only 1 mobility
> >>>>>>> SA between
> >>>>>>> >>a FA and a HA for all the MIP sessions, right?
> >>>>>>> >
> >>>>>>> >YES, one mobility SA, ceveral security context 
> within a mobility
> >>>>>>> >SA. See rfc
> >>>>>>> >2002,
> >>>>>>> >
> >>>>>>> >"Mobility Security Association
> >>>>>>> >               A collection of security contexts, 
> between a pair
> >>>>>>> >               of nodes, which may be applied to 
> Mobile IP protocol
> >>>>>>> >               messages exchanged between them.  Each
> >>>>>>> context indicates
> >>>>>>> >               an authentication algorithm and mode
> >(Section 5.1), a
> >>>>>>> >               secret (a shared key, or appropriate 
> public/private
> >>>>>>> >               key pair), and a style of replay 
> protection in use
> >>>>>>> >               (Section 5.6)."
> >>>>>>> >
> >>>>>>> >Each context is indexed with a unique SPI within that SA, if
> >>>>>>> there exist a
> >>>>>>> >SA between the HA and the old FA and one SA between the HA
> >>>>>>> and the new FA
> >>>>>>> >there might exist security context with the same SPI in both
> >>>>>>> of these.
> >>>>>>> >
> >>>>>>> >"Security Parameter Index (SPI)
> >>>>>>> >               An index identifying a security context
> >>between a pair
> >>>>>>> >               of nodes among the contexts available in
> >the Mobility
> >>>>>>> >               Security Association.  SPI values 0 
> through 255 are
> >>>>>>> >               reserved and MUST NOT be used in any
> >>Mobility Security
> >>>>>>> >               Association."
> >>>>>>> >
> >>>>>>> >>When a first AMA is received
> >>>>>>> >
> >>>>>>> >I guess you mean AMR :-)
> >>>>>>> >
> >>>>>>> >>in the AAAH from a MN, is the AAAH supposed to issue a new
> >>>>>>> registration
> >>>>>>> >>FA-HA key, in the case the HA is in the home domain? The
> >>>>>>> spec says "yes",
> >>>>>>> >>if it is required by the MN. However, how can the MN know
> >about the
> >>>>>>> >>mobility SA between the FA and the HA? I guess it can not,
> >>>>>>> which means
> >>>>>>> >>that it will ask for a new key, which should be transferred
> >>>>>>> to the FA and
> >>>>>>> >>the HA from the AAAH. Is there a way for the HA to 
> notify the AAAH
> >>>>>>> >>that it does not need
> >>>>>>> >>a new key and a new SPI for its mobility SA with 
> the FA, since it
> >>>>>>> >>already has one? I guess
> >>>>>>> >>not, right? Then, it looks like your idea could be very
> >>>>>>> interesting, but
> >>>>>>> >>I don't know how to deal with it using Diameter, unless the
> >>>>>>> AAAH and AAAF
> >>>>>>> >>would keep a list of mobility SAs between each FA and HA.
> >>>>>>> >
> >>>>>>> >In some way the AAAH must keep track of what SPIs it has
> >>>>>>> assigned to the
> >>>>>>> >home agent, if it does it per SA or make the SPI 
> unique over all
> >>>>>>> >SA's in the
> >>>>>>> >HA is up to the implementation
> >>>>>>> >
> >>>>>>> >>
> >>>>>>> >>> You can not guarantee that a security between the HA and
> >>>>>>> the old FA is
> >>>>>>> >>> unique between the HA and the new FA. The same SPI must be
> >>>>>>> >>> used in the first
> >>>>>>> >>> request in order for the HA to be able to 
> distinguise between
> >>>>>>> >>> different
> >>>>>>> >>> security contexts it shares with the FA. What we 
> can do is to
> >>>>>>> >>> have the new
> >>>>>>> >>> FA add a <MIP-Preferred-SPI Ext> in the first request from
> >>>>>>> >>> the new FA to the
> >>>>>>> >>> HA, the HA can then use the <Previous-FA-XXXX 
> Ext> together
> >>>>>>> >>> with the old SPI
> >>>>>>> >>> to retreive the context and store it under the 
> Preferred SPI
> >>>>>>> >>> under the SA
> >>>>>>> >>> with the new FA.
> >>>>>>> >>
> >>>>>>> >>I was wondering whether or not a mobility SA between a FA
> >>>>>>> >>and a HA was based on a particular MIP session? My 
> understanding
> >>>>>>> >>_IS_ that an existing SA is based on a MIP session. 
> That means
> >>>>>>> >>that between a FA and a HA, there exists several 
> mobility SAs
> >>>>>>> >>depending on each MIP session.
> >>>>>>> >
> >>>>>>> >No, there is only one SA between two nodes, but there are
> >>>>>>> several security
> >>>>>>> >context within each SA. Each security context can
> >>>>>>> corresponde to a mip
> >>>>>>> >session. It is the security context that has a lifetime, the
> >>>>>>> SA can be
> >>>>>>> >removed when the last security context is removed.
> >>>>>>> >
> >>>>>>> >>By MIP session, I mean an AAA
> >>>>>>> >>authorized session for MIP. The SPI is already 
> included in the
> >>>>>>> >>key transferred between the AAAF and the new FA. I don't see
> >>>>>>> >>why a HA could not use the SPI stored under its MN User-Name
> >>>>>>> >>state to retrieve the mobility SA between the new 
> FA and itself?
> >>>>>>> >
> >>>>>>> >Because the SA between the FA and HA does not realy 
> have anything
> >>>>>>> >to do with
> >>>>>>> >the Mn. It is something setup between the FA and HA. Thus
> >>>>>>> when the HA will
> >>>>>>> >look for the key to use it will do the lookup on the 
> FA address.
> >>>>>>> >
> >>>>>>> >/Fredrik
> >>>>>>> >
> >>>>>>> >>
> >>>>>>> >>Regards,
> >>>>>>> >>Martin
> >>>>>>> >
> >>>>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >>
> >
> 



From owner-aaa-bof@merit.edu  Tue Apr 17 10:52:55 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09162
	for <aaa-archive@odin.ietf.org>; Tue, 17 Apr 2001 10:52:54 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id C915A5DE08; Tue, 17 Apr 2001 10:51:38 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id B52BD5DDF4; Tue, 17 Apr 2001 10:51:38 -0400 (EDT)
Received: from mailgw.local.ipunplugged.com (unknown [213.88.134.217])
	by segue.merit.edu (Postfix) with ESMTP id 1CB3B5DE02
	for <aaa-wg@merit.edu>; Tue, 17 Apr 2001 10:51:36 -0400 (EDT)
Received: from fredrikj (c42.local.ipunplugged.com [192.168.4.241])
	by mailgw.local.ipunplugged.com (8.9.3/8.9.3) with SMTP id QAA11495;
	Tue, 17 Apr 2001 16:52:41 +0200
From: "Fredrik Johansson" <fredrik.johansson@ipunplugged.com>
To: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>,
        <pcalhoun@eng.sun.com>, "Tony Johansson" <tony.johansson@ericsson.com>
Cc: "AAA Listan" <aaa-wg@merit.edu>
Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
Date: Tue, 17 Apr 2001 16:53:23 +0200
Message-ID: <MJEMJBGGCLLDLFFAHLJKEECNCKAA.fredrik.johansson@ipunplugged.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <577066326047D41180AC00508B955DDA01D7FF81@eestqnt104.es.eu.ericsson.se>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Martin,

How would generating a session id from User-Name and MIP-Previous-FA-XXXX
help you to have several MIP sessions for the same user if the have
different MNs? The user may still use the same User-Name on all of its MNs,
thus causing the same session id to be created.

So, I don't believe it will solve the problem. If it is a problem that you
cannot have several session with the same nai, isn't that one of the
problems with radius that there is no way to limit a user from login in
from several places at the same time using the same user name and password?

/Fredrik

>
>Hej Fredrik,
>
>If the Session-ID would be generated and handled by the MN, I
>guess it would be a lot easier. At least, we could propose a way
>of generating a Session-ID in the FA, such as the concatenation of
>the User-Name and the Care-Of address (FA), which would lead to a
>predictable Session-ID. In the case where the MN would move to a
>new FA, then the new FA would need to generate a Session-ID based
>on the User-Name and the MIP-Previous-FA-XXXX. Would that make any
>sense? Then, I guess we could have several different MIP sessions
>for the same User, as long as it is using different MNs. To
>support more than one session per MN, I guess the MN would need to
>include additional info about that.
>
>We are having the same kind of problems WRT SIP, I believe.
>
>Martin
>
>> -----Original Message-----
>> From: Fredrik Johansson [mailto:fredrik.johansson@ipunplugged.com]
>> Sent: Tuesday, April 17, 2001 3:01 PM
>> To: pcalhoun@eng.sun.com; Martin Julien (ECE); Tony Johansson
>> Cc: AAA Listan
>> Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
>>
>>
>> Ok, let's see if I can write the entire message this time
>> before sending it
>> :-)
>> There might be a problem with the possiblity to reuse the old
>> session id,
>> and
>> that is that there can only be one session per user. I don't
>> know if this
>> limitation
>> is to harsh.
>>
>> /Fredrik
>>
>> 11.7  Session Movement
>>
>>    When a user moves between different access devices it may
>> be desirable
>>    to keep the Session Id unchanged. It is therefore possible for a
>>    server to send the original Session Id back to the client in the
>>    Original-Session-Id AVP. An old session is identified by
>> the User Name
>>    Nai.
>>
>> 11.7.1  Original-Session-Id AVP
>>
>>    The Original-Session-Id AVP (AVP Code 261) is of type
>> OctetString and
>>    MAY be sent in a message of type Response or Answer if the AAA
>>    server already has a session identifier for the user, and wishes to
>>    keep the existing Session-Id. All further messages from the Access
>>    Device for this session MUST use the session identifier in
>> this AVP.
>>    This shouldn't be viewed as a new session, but rather renaming the
>>    old session. Any message not using the Session Id in this
>> AVP will be
>>    treated as an unrecognized Session Id.
>>
>> 11.8  Session Termination
>>
>>    The Diameter Base Protocol provides a set of messages that MUST be
>>    used by any peer to explicitly request that a previously
>>    authenticated and/or authorized session be terminated. Since the
>>    Session-Id is typically tied to a particular service (i.e.
>> Mobile IP,
>>    NASREQ, etc), the session termination messages are used to request
>>    that the service tied to the Session Id be terminated.
>>
>>
>>
>> >>-----Original Message-----
>> >>From: owner-aaa-bof@merit.edu
>> [mailto:owner-aaa-bof@merit.edu]On Behalf
>> >>Of Fredrik Johansson
>> >>Sent: den 12 april 2001 10:04
>> >>To: pcalhoun@eng.sun.com; Martin Julien (ECE); Tony Johansson
>> >>Cc: AAA Listan
>> >>Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
>> >>
>> >>
>> >>No, no additional AVPs is required. However, I believe some
>> explanations
>> >>should be provided on how to treat the  request in
>> different nodes. I'll
>> >>give you some text after the weekend that hopefully will give you
>> >>some ideas
>> >>what I mean. Untill then I will enjoy a couple of days skiing :-)
>> >>
>> >>/Fredrik
>> >>
>> >>>-----Original Message-----
>> >>>From: owner-aaa-bof@merit.edu
>> [mailto:owner-aaa-bof@merit.edu]On Behalf
>> >>>Of Patrice Calhoun
>> >>>Sent: den 11 april 2001 19:32
>> >>>To: Fredrik Johansson; Martin Julien (ECE); Tony Johansson
>> >>>Cc: AAA Listan
>> >>>Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
>> >>>
>> >>>
>> >>>and no additional protocol text (read AVPs) is required???
>> >>>
>> >>>PatC
>> >>>>>
>> >>>>>Just to make sure, I *presume* that this proposed text is to
>> >>>belong in the
>> >>>>>Mobile IP extension, right?
>> >>>>
>> >>>>Yes, that's correct
>> >>>>
>> >>>>/Fredrik
>> >>>>
>> >>>>>
>> >>>>>PatC
>> >>>>>
>> >>>>>ps: for those that saw my "I will not be responding to
>> e-mail this
>> >>>>>week", I
>> >>>>>happen to be in a city that has metricom service :)
>> >>>>>
>> >>>>>>Cool! I was about to send you something very similar to know
>> >>>>>>if it was what you meant in your previous mail.
>> >>>>>>I agree with your solution. Thanks!
>> >>>>>>
>> >>>>>>> -----Original Message-----
>> >>>>>>> From: Fredrik Johansson
>> [mailto:fredrik.johansson@ipunplugged.com]
>> >>>>>>> Sent: Tuesday, April 10, 2001 10:27 AM
>> >>>>>>> To: Martin Julien (ECE); Tony Johansson
>> >>>>>>> Cc: 'Patrice Calhoun'; AAA Listan
>> >>>>>>> Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> After a closer look at the problem we have a suggestion on a
>> >>solution.
>> >>>>>>> If the AAAH always assigns a SPI that is unique in the HA for
>> >>>>>>> the FA-HA key,
>> >>>>>>> and a SPI that is unique in the Mn for the MN-FA and
>> MN-HA keys, the
>> >>>>>>> security contexts will automatically be unique in every SA.
>> >>>>>>>
>> >>>>>>> 7.5 SPI Allocation
>> >>>>>>>   To ensure that the SPI is unique for each pair of nodes,
>> >>>>>>>   the AAAH SHOULD keep track of assigned SPIs per HA and MN.
>> >>>>>>>   The SPI assigned to the MN-FA key MUST be allocated from
>> >>>>>>> the MN SPI pool,
>> >>>>>>>   the SPI for the FA-HA key MUST be allocated from the HA SPI
>> >>>>>>> pool, and the
>> >>>>>>>   SPI for the MN-HA key MUST be allocated from the MN SPI
>> >>>>>>> pool. Note that
>> >>>>>>>   SPI values 0 through 255 are reserved and MUST NOT
>> be used in any
>> >>>>>>>   Mobility Security Association.
>> >>>>>>>
>> >>>>>>> /Fredrik
>> >>>>>>> >-----Original Message-----
>> >>>>>>> >From: owner-aaa-bof@merit.edu
>> >>>>>>> [mailto:owner-aaa-bof@merit.edu]On Behalf
>> >>>>>>> >Of Fredrik Johansson
>> >>>>>>> >Sent: den 10 april 2001 08:40
>> >>>>>>> >To: Martin Julien (ECE); Tony Johansson
>> >>>>>>> >Cc: 'Patrice Calhoun'; AAA Listan
>> >>>>>>> >Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
>> >>>>>>> >
>> >>>>>>> >
>> >>>>>>> >>
>> >>>>>>> >>> >>
>> >>>>>>> >>> >> Another thing that needs some clarification,
>> if there is a
>> >>>>>>> >>> solution. How
>> >>>>>>> >>> >> will the HA know which SA to use. In the case
>> where a mobile
>> >>>>>>> >>> >moves from one
>> >>>>>>> >>> >> Fa to another under the same administrative
>> domain it may
>> >>>>>>> >>> receive the
>> >>>>>>> >>> >> session keys for the old Fa from the AAAF. It will
>> >>then proceed
>> >>>>>>> >>> >to send the
>> >>>>>>> >>> >> mip reg req to the HA. The HA will see that
>> the message came
>> >>>>>>> >>> >from the new FA
>> >>>>>>> >>> >> and try to locate the SA shared with that FA. It
>> >will not find
>> >>>>>>> >>> >it since it
>> >>>>>>> >>> >> was established with the old FA. Eventhough
>> the HA can see
>> >>>>>>> >>> the address of
>> >>>>>>> >>> >> the old Fa in the previous-fa-XXXX it is not clear
>> >that it can
>> >>>>>>> >>> >establish a
>> >>>>>>> >>> >> SA with the new Fa because it has to use the same SPI
>> >>as before
>> >>>>>>> >>> >and that one
>> >>>>>>> >>> >> might be busy. Or have I missed something here?
>> >>>>>>> >>> >
>> >>>>>>> >>> >You also have the user NAI in the MIP registration
>> >>>>>>> request sent to
>> >>>>>>> >>> >the HA and
>> >>>>>>> >>> >the user NAI is globally unique....
>> >>>>>>> >>>
>> >>>>>>> >>> Yes, but this is not the security association
>> shared with the
>> >>>>>>> >>> mobile node
>> >>>>>>> >>> but the one shared between the FA and HA, thus
>> has nothing to
>> >>>>>>> >>> do with the
>> >>>>>>> >>> user.
>> >>>>>>> >>
>> >>>>>>> >>I think you are assuming that there exists only 1 mobility
>> >>>>>>> SA between
>> >>>>>>> >>a FA and a HA for all the MIP sessions, right?
>> >>>>>>> >
>> >>>>>>> >YES, one mobility SA, ceveral security context
>> within a mobility
>> >>>>>>> >SA. See rfc
>> >>>>>>> >2002,
>> >>>>>>> >
>> >>>>>>> >"Mobility Security Association
>> >>>>>>> >               A collection of security contexts,
>> between a pair
>> >>>>>>> >               of nodes, which may be applied to
>> Mobile IP protocol
>> >>>>>>> >               messages exchanged between them.  Each
>> >>>>>>> context indicates
>> >>>>>>> >               an authentication algorithm and mode
>> >(Section 5.1), a
>> >>>>>>> >               secret (a shared key, or appropriate
>> public/private
>> >>>>>>> >               key pair), and a style of replay
>> protection in use
>> >>>>>>> >               (Section 5.6)."
>> >>>>>>> >
>> >>>>>>> >Each context is indexed with a unique SPI within that SA, if
>> >>>>>>> there exist a
>> >>>>>>> >SA between the HA and the old FA and one SA between the HA
>> >>>>>>> and the new FA
>> >>>>>>> >there might exist security context with the same SPI in both
>> >>>>>>> of these.
>> >>>>>>> >
>> >>>>>>> >"Security Parameter Index (SPI)
>> >>>>>>> >               An index identifying a security context
>> >>between a pair
>> >>>>>>> >               of nodes among the contexts available in
>> >the Mobility
>> >>>>>>> >               Security Association.  SPI values 0
>> through 255 are
>> >>>>>>> >               reserved and MUST NOT be used in any
>> >>Mobility Security
>> >>>>>>> >               Association."
>> >>>>>>> >
>> >>>>>>> >>When a first AMA is received
>> >>>>>>> >
>> >>>>>>> >I guess you mean AMR :-)
>> >>>>>>> >
>> >>>>>>> >>in the AAAH from a MN, is the AAAH supposed to issue a new
>> >>>>>>> registration
>> >>>>>>> >>FA-HA key, in the case the HA is in the home domain? The
>> >>>>>>> spec says "yes",
>> >>>>>>> >>if it is required by the MN. However, how can the MN know
>> >about the
>> >>>>>>> >>mobility SA between the FA and the HA? I guess it can not,
>> >>>>>>> which means
>> >>>>>>> >>that it will ask for a new key, which should be transferred
>> >>>>>>> to the FA and
>> >>>>>>> >>the HA from the AAAH. Is there a way for the HA to
>> notify the AAAH
>> >>>>>>> >>that it does not need
>> >>>>>>> >>a new key and a new SPI for its mobility SA with
>> the FA, since it
>> >>>>>>> >>already has one? I guess
>> >>>>>>> >>not, right? Then, it looks like your idea could be very
>> >>>>>>> interesting, but
>> >>>>>>> >>I don't know how to deal with it using Diameter, unless the
>> >>>>>>> AAAH and AAAF
>> >>>>>>> >>would keep a list of mobility SAs between each FA and HA.
>> >>>>>>> >
>> >>>>>>> >In some way the AAAH must keep track of what SPIs it has
>> >>>>>>> assigned to the
>> >>>>>>> >home agent, if it does it per SA or make the SPI
>> unique over all
>> >>>>>>> >SA's in the
>> >>>>>>> >HA is up to the implementation
>> >>>>>>> >
>> >>>>>>> >>
>> >>>>>>> >>> You can not guarantee that a security between the HA and
>> >>>>>>> the old FA is
>> >>>>>>> >>> unique between the HA and the new FA. The same SPI must be
>> >>>>>>> >>> used in the first
>> >>>>>>> >>> request in order for the HA to be able to
>> distinguise between
>> >>>>>>> >>> different
>> >>>>>>> >>> security contexts it shares with the FA. What we
>> can do is to
>> >>>>>>> >>> have the new
>> >>>>>>> >>> FA add a <MIP-Preferred-SPI Ext> in the first request from
>> >>>>>>> >>> the new FA to the
>> >>>>>>> >>> HA, the HA can then use the <Previous-FA-XXXX
>> Ext> together
>> >>>>>>> >>> with the old SPI
>> >>>>>>> >>> to retreive the context and store it under the
>> Preferred SPI
>> >>>>>>> >>> under the SA
>> >>>>>>> >>> with the new FA.
>> >>>>>>> >>
>> >>>>>>> >>I was wondering whether or not a mobility SA between a FA
>> >>>>>>> >>and a HA was based on a particular MIP session? My
>> understanding
>> >>>>>>> >>_IS_ that an existing SA is based on a MIP session.
>> That means
>> >>>>>>> >>that between a FA and a HA, there exists several
>> mobility SAs
>> >>>>>>> >>depending on each MIP session.
>> >>>>>>> >
>> >>>>>>> >No, there is only one SA between two nodes, but there are
>> >>>>>>> several security
>> >>>>>>> >context within each SA. Each security context can
>> >>>>>>> corresponde to a mip
>> >>>>>>> >session. It is the security context that has a lifetime, the
>> >>>>>>> SA can be
>> >>>>>>> >removed when the last security context is removed.
>> >>>>>>> >
>> >>>>>>> >>By MIP session, I mean an AAA
>> >>>>>>> >>authorized session for MIP. The SPI is already
>> included in the
>> >>>>>>> >>key transferred between the AAAF and the new FA. I don't see
>> >>>>>>> >>why a HA could not use the SPI stored under its MN User-Name
>> >>>>>>> >>state to retrieve the mobility SA between the new
>> FA and itself?
>> >>>>>>> >
>> >>>>>>> >Because the SA between the FA and HA does not realy
>> have anything
>> >>>>>>> >to do with
>> >>>>>>> >the Mn. It is something setup between the FA and HA. Thus
>> >>>>>>> when the HA will
>> >>>>>>> >look for the key to use it will do the lookup on the
>> FA address.
>> >>>>>>> >
>> >>>>>>> >/Fredrik
>> >>>>>>> >
>> >>>>>>> >>
>> >>>>>>> >>Regards,
>> >>>>>>> >>Martin
>> >>>>>>> >
>> >>>>>>>
>> >>>>>
>> >>>>>
>> >>>
>> >>>
>> >>
>> >
>>




From owner-aaa-bof@merit.edu  Tue Apr 17 10:53:51 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09208
	for <aaa-archive@odin.ietf.org>; Tue, 17 Apr 2001 10:53:50 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 269065DDAB; Tue, 17 Apr 2001 10:53:25 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 128F25DD94; Tue, 17 Apr 2001 10:53:25 -0400 (EDT)
Received: from mailgw.local.ipunplugged.com (unknown [213.88.134.217])
	by segue.merit.edu (Postfix) with ESMTP id 898C95DDF4
	for <aaa-wg@merit.edu>; Tue, 17 Apr 2001 10:53:22 -0400 (EDT)
Received: from fredrikj (c42.local.ipunplugged.com [192.168.4.241])
	by mailgw.local.ipunplugged.com (8.9.3/8.9.3) with SMTP id QAA11539;
	Tue, 17 Apr 2001 16:54:30 +0200
From: "Fredrik Johansson" <fredrik.johansson@ipunplugged.com>
To: <pcalhoun@eng.sun.com>, <Martin.Julien@ece.ericsson.se>,
        "Tony Johansson" <tony.johansson@ericsson.com>
Cc: "AAA Listan" <aaa-wg@merit.edu>
Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
Date: Tue, 17 Apr 2001 16:55:12 +0200
Message-ID: <MJEMJBGGCLLDLFFAHLJKIECNCKAA.fredrik.johansson@ipunplugged.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <MJEMJBGGCLLDLFFAHLJKMECJCKAA.fredrik.johansson@ipunplugged.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi,

Here's some additional text that tries to describe the problem,
that might provide some hints on what can be included in the
MIP extension draft.


7.5 SPI Allocation

  To ensure that the SPI is unique for each pair of nodes,
  the AAAH SHOULD keep track of assigned SPIs per HA and MN.
  The SPI assigned to the MN-FA key MUST be allocated from
  the MN SPI pool, the SPI for the FA-HA key MUST be
  allocated from the HA SPI pool, and the SPI for the MN-HA
  key MUST be allocated from the MN SPI pool. Note that SPI
  values 0 through 255 are reserved and MUST NOT be used in
  any Mobility Security Association.

7.6 Retreiving Mobility Session Keys from AAAF

  In the case that a user moves between two FAs under the
  same administrative domain it may be possible for the AAAF
  to distribute the mobility session keys for the old FA to
  the new FA. To do this the client will send an AMR to the
  AAAF with the Previous-FA-FQDN or Previous-FA-Address AVP.
  AAAF will retreive the keys based on the User-Name NAI and
  the information about the previous FA and send them back
  to the client in an AMA. The AMA will also include the
  MIP Registration Request AVP to indicate to the client that
  it need to forward the request directly to the HA in order
  to update the mobile ip tunnel.

7.6.1 Home Agent Behaviour

  The HA will use the SPI to understand what key to use when
  authenticating the received registration request. Since the
  request is received from a new FA but with the SPI used with
  the old FA the HA will not find the Security Context. Thus
  the search sequence of the HA must be extended to handle this
  scenario. If the HA failes to find a Security Context when it
  looks in the Mobility Security Association it shares
  with the sending node, it MUST look for a Previous-FA-FQDN or
  Previous-FA-Address extension in the request. If one is
  available it must look for the Security Context under the
  previous FA mobility SA and copy it to the new SA.


/Fredrik

>-----Original Message-----
>From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf
>Of Fredrik Johansson
>Sent: den 17 april 2001 15:01
>To: pcalhoun@eng.sun.com; Martin Julien (ECE); Tony Johansson
>Cc: AAA Listan
>Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
>
>
>Ok, let's see if I can write the entire message this time before sending it
>:-)
>There might be a problem with the possiblity to reuse the old session id,
>and
>that is that there can only be one session per user. I don't know if this
>limitation
>is to harsh.
>
>/Fredrik
>
>11.7  Session Movement
>
>   When a user moves between different access devices it may be desirable
>   to keep the Session Id unchanged. It is therefore possible for a
>   server to send the original Session Id back to the client in the
>   Original-Session-Id AVP. An old session is identified by the User Name
>   Nai.
>
>11.7.1  Original-Session-Id AVP
>
>   The Original-Session-Id AVP (AVP Code 261) is of type OctetString and
>   MAY be sent in a message of type Response or Answer if the AAA
>   server already has a session identifier for the user, and wishes to
>   keep the existing Session-Id. All further messages from the Access
>   Device for this session MUST use the session identifier in this AVP.
>   This shouldn't be viewed as a new session, but rather renaming the
>   old session. Any message not using the Session Id in this AVP will be
>   treated as an unrecognized Session Id.
>
>11.8  Session Termination
>
>   The Diameter Base Protocol provides a set of messages that MUST be
>   used by any peer to explicitly request that a previously
>   authenticated and/or authorized session be terminated. Since the
>   Session-Id is typically tied to a particular service (i.e. Mobile IP,
>   NASREQ, etc), the session termination messages are used to request
>   that the service tied to the Session Id be terminated.
>
>
>
>>>-----Original Message-----
>>>From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf
>>>Of Fredrik Johansson
>>>Sent: den 12 april 2001 10:04
>>>To: pcalhoun@eng.sun.com; Martin Julien (ECE); Tony Johansson
>>>Cc: AAA Listan
>>>Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
>>>
>>>
>>>No, no additional AVPs is required. However, I believe some explanations
>>>should be provided on how to treat the  request in different nodes. I'll
>>>give you some text after the weekend that hopefully will give you
>>>some ideas
>>>what I mean. Untill then I will enjoy a couple of days skiing :-)
>>>
>>>/Fredrik
>>>
>>>>-----Original Message-----
>>>>From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf
>>>>Of Patrice Calhoun
>>>>Sent: den 11 april 2001 19:32
>>>>To: Fredrik Johansson; Martin Julien (ECE); Tony Johansson
>>>>Cc: AAA Listan
>>>>Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
>>>>
>>>>
>>>>and no additional protocol text (read AVPs) is required???
>>>>
>>>>PatC
>>>>>>
>>>>>>Just to make sure, I *presume* that this proposed text is to
>>>>belong in the
>>>>>>Mobile IP extension, right?
>>>>>
>>>>>Yes, that's correct
>>>>>
>>>>>/Fredrik
>>>>>
>>>>>>
>>>>>>PatC
>>>>>>
>>>>>>ps: for those that saw my "I will not be responding to e-mail this
>>>>>>week", I
>>>>>>happen to be in a city that has metricom service :)
>>>>>>
>>>>>>>Cool! I was about to send you something very similar to know
>>>>>>>if it was what you meant in your previous mail.
>>>>>>>I agree with your solution. Thanks!
>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Fredrik Johansson [mailto:fredrik.johansson@ipunplugged.com]
>>>>>>>> Sent: Tuesday, April 10, 2001 10:27 AM
>>>>>>>> To: Martin Julien (ECE); Tony Johansson
>>>>>>>> Cc: 'Patrice Calhoun'; AAA Listan
>>>>>>>> Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
>>>>>>>>
>>>>>>>>
>>>>>>>> After a closer look at the problem we have a suggestion on a
>>>solution.
>>>>>>>> If the AAAH always assigns a SPI that is unique in the HA for
>>>>>>>> the FA-HA key,
>>>>>>>> and a SPI that is unique in the Mn for the MN-FA and MN-HA
>keys, the
>>>>>>>> security contexts will automatically be unique in every SA.
>>>>>>>>
>>>>>>>> 7.5 SPI Allocation
>>>>>>>>   To ensure that the SPI is unique for each pair of nodes,
>>>>>>>>   the AAAH SHOULD keep track of assigned SPIs per HA and MN.
>>>>>>>>   The SPI assigned to the MN-FA key MUST be allocated from
>>>>>>>> the MN SPI pool,
>>>>>>>>   the SPI for the FA-HA key MUST be allocated from the HA SPI
>>>>>>>> pool, and the
>>>>>>>>   SPI for the MN-HA key MUST be allocated from the MN SPI
>>>>>>>> pool. Note that
>>>>>>>>   SPI values 0 through 255 are reserved and MUST NOT be used in any
>>>>>>>>   Mobility Security Association.
>>>>>>>>
>>>>>>>> /Fredrik
>>>>>>>> >-----Original Message-----
>>>>>>>> >From: owner-aaa-bof@merit.edu
>>>>>>>> [mailto:owner-aaa-bof@merit.edu]On Behalf
>>>>>>>> >Of Fredrik Johansson
>>>>>>>> >Sent: den 10 april 2001 08:40
>>>>>>>> >To: Martin Julien (ECE); Tony Johansson
>>>>>>>> >Cc: 'Patrice Calhoun'; AAA Listan
>>>>>>>> >Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
>>>>>>>> >
>>>>>>>> >
>>>>>>>> >>
>>>>>>>> >>> >>
>>>>>>>> >>> >> Another thing that needs some clarification, if there is a
>>>>>>>> >>> solution. How
>>>>>>>> >>> >> will the HA know which SA to use. In the case where a mobile
>>>>>>>> >>> >moves from one
>>>>>>>> >>> >> Fa to another under the same administrative domain it may
>>>>>>>> >>> receive the
>>>>>>>> >>> >> session keys for the old Fa from the AAAF. It will
>>>then proceed
>>>>>>>> >>> >to send the
>>>>>>>> >>> >> mip reg req to the HA. The HA will see that the message came
>>>>>>>> >>> >from the new FA
>>>>>>>> >>> >> and try to locate the SA shared with that FA. It
>>will not find
>>>>>>>> >>> >it since it
>>>>>>>> >>> >> was established with the old FA. Eventhough the HA can see
>>>>>>>> >>> the address of
>>>>>>>> >>> >> the old Fa in the previous-fa-XXXX it is not clear
>>that it can
>>>>>>>> >>> >establish a
>>>>>>>> >>> >> SA with the new Fa because it has to use the same SPI
>>>as before
>>>>>>>> >>> >and that one
>>>>>>>> >>> >> might be busy. Or have I missed something here?
>>>>>>>> >>> >
>>>>>>>> >>> >You also have the user NAI in the MIP registration
>>>>>>>> request sent to
>>>>>>>> >>> >the HA and
>>>>>>>> >>> >the user NAI is globally unique....
>>>>>>>> >>>
>>>>>>>> >>> Yes, but this is not the security association shared with the
>>>>>>>> >>> mobile node
>>>>>>>> >>> but the one shared between the FA and HA, thus has nothing to
>>>>>>>> >>> do with the
>>>>>>>> >>> user.
>>>>>>>> >>
>>>>>>>> >>I think you are assuming that there exists only 1 mobility
>>>>>>>> SA between
>>>>>>>> >>a FA and a HA for all the MIP sessions, right?
>>>>>>>> >
>>>>>>>> >YES, one mobility SA, ceveral security context within a mobility
>>>>>>>> >SA. See rfc
>>>>>>>> >2002,
>>>>>>>> >
>>>>>>>> >"Mobility Security Association
>>>>>>>> >               A collection of security contexts, between a pair
>>>>>>>> >               of nodes, which may be applied to Mobile
>IP protocol
>>>>>>>> >               messages exchanged between them.  Each
>>>>>>>> context indicates
>>>>>>>> >               an authentication algorithm and mode
>>(Section 5.1), a
>>>>>>>> >               secret (a shared key, or appropriate public/private
>>>>>>>> >               key pair), and a style of replay protection in use
>>>>>>>> >               (Section 5.6)."
>>>>>>>> >
>>>>>>>> >Each context is indexed with a unique SPI within that SA, if
>>>>>>>> there exist a
>>>>>>>> >SA between the HA and the old FA and one SA between the HA
>>>>>>>> and the new FA
>>>>>>>> >there might exist security context with the same SPI in both
>>>>>>>> of these.
>>>>>>>> >
>>>>>>>> >"Security Parameter Index (SPI)
>>>>>>>> >               An index identifying a security context
>>>between a pair
>>>>>>>> >               of nodes among the contexts available in
>>the Mobility
>>>>>>>> >               Security Association.  SPI values 0 through 255 are
>>>>>>>> >               reserved and MUST NOT be used in any
>>>Mobility Security
>>>>>>>> >               Association."
>>>>>>>> >
>>>>>>>> >>When a first AMA is received
>>>>>>>> >
>>>>>>>> >I guess you mean AMR :-)
>>>>>>>> >
>>>>>>>> >>in the AAAH from a MN, is the AAAH supposed to issue a new
>>>>>>>> registration
>>>>>>>> >>FA-HA key, in the case the HA is in the home domain? The
>>>>>>>> spec says "yes",
>>>>>>>> >>if it is required by the MN. However, how can the MN know
>>about the
>>>>>>>> >>mobility SA between the FA and the HA? I guess it can not,
>>>>>>>> which means
>>>>>>>> >>that it will ask for a new key, which should be transferred
>>>>>>>> to the FA and
>>>>>>>> >>the HA from the AAAH. Is there a way for the HA to
>notify the AAAH
>>>>>>>> >>that it does not need
>>>>>>>> >>a new key and a new SPI for its mobility SA with the FA, since it
>>>>>>>> >>already has one? I guess
>>>>>>>> >>not, right? Then, it looks like your idea could be very
>>>>>>>> interesting, but
>>>>>>>> >>I don't know how to deal with it using Diameter, unless the
>>>>>>>> AAAH and AAAF
>>>>>>>> >>would keep a list of mobility SAs between each FA and HA.
>>>>>>>> >
>>>>>>>> >In some way the AAAH must keep track of what SPIs it has
>>>>>>>> assigned to the
>>>>>>>> >home agent, if it does it per SA or make the SPI unique over all
>>>>>>>> >SA's in the
>>>>>>>> >HA is up to the implementation
>>>>>>>> >
>>>>>>>> >>
>>>>>>>> >>> You can not guarantee that a security between the HA and
>>>>>>>> the old FA is
>>>>>>>> >>> unique between the HA and the new FA. The same SPI must be
>>>>>>>> >>> used in the first
>>>>>>>> >>> request in order for the HA to be able to distinguise between
>>>>>>>> >>> different
>>>>>>>> >>> security contexts it shares with the FA. What we can do is to
>>>>>>>> >>> have the new
>>>>>>>> >>> FA add a <MIP-Preferred-SPI Ext> in the first request from
>>>>>>>> >>> the new FA to the
>>>>>>>> >>> HA, the HA can then use the <Previous-FA-XXXX Ext> together
>>>>>>>> >>> with the old SPI
>>>>>>>> >>> to retreive the context and store it under the Preferred SPI
>>>>>>>> >>> under the SA
>>>>>>>> >>> with the new FA.
>>>>>>>> >>
>>>>>>>> >>I was wondering whether or not a mobility SA between a FA
>>>>>>>> >>and a HA was based on a particular MIP session? My understanding
>>>>>>>> >>_IS_ that an existing SA is based on a MIP session. That means
>>>>>>>> >>that between a FA and a HA, there exists several mobility SAs
>>>>>>>> >>depending on each MIP session.
>>>>>>>> >
>>>>>>>> >No, there is only one SA between two nodes, but there are
>>>>>>>> several security
>>>>>>>> >context within each SA. Each security context can
>>>>>>>> corresponde to a mip
>>>>>>>> >session. It is the security context that has a lifetime, the
>>>>>>>> SA can be
>>>>>>>> >removed when the last security context is removed.
>>>>>>>> >
>>>>>>>> >>By MIP session, I mean an AAA
>>>>>>>> >>authorized session for MIP. The SPI is already included in the
>>>>>>>> >>key transferred between the AAAF and the new FA. I don't see
>>>>>>>> >>why a HA could not use the SPI stored under its MN User-Name
>>>>>>>> >>state to retrieve the mobility SA between the new FA and itself?
>>>>>>>> >
>>>>>>>> >Because the SA between the FA and HA does not realy have anything
>>>>>>>> >to do with
>>>>>>>> >the Mn. It is something setup between the FA and HA. Thus
>>>>>>>> when the HA will
>>>>>>>> >look for the key to use it will do the lookup on the FA address.
>>>>>>>> >
>>>>>>>> >/Fredrik
>>>>>>>> >
>>>>>>>> >>
>>>>>>>> >>Regards,
>>>>>>>> >>Martin
>>>>>>>> >
>>>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>
>>
>




From owner-aaa-bof@merit.edu  Tue Apr 17 15:08:13 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13729
	for <aaa-archive@odin.ietf.org>; Tue, 17 Apr 2001 15:08:13 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id D335D5DE00; Tue, 17 Apr 2001 15:07:48 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id BB9045DDB4; Tue, 17 Apr 2001 15:07:48 -0400 (EDT)
Received: from hindon.hss.co.in (unknown [202.54.26.202])
	by segue.merit.edu (Postfix) with ESMTP id 8212E5DD8C
	for <aaa-wg@merit.edu>; Tue, 17 Apr 2001 15:07:44 -0400 (EDT)
Received: from sandesh.hss.hns.com (localhost [127.0.0.1])
	by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f3HJ91826364
	for <aaa-wg@merit.edu>; Wed, 18 Apr 2001 00:39:02 +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id 65256A31.0067C9E6 ; Wed, 18 Apr 2001 00:23:38 +0530
X-Lotus-FromDomain: HSS
From: sargupta@hss.hns.com
To: aaa-wg@merit.edu
Message-ID: <65256A31.0067BE89.00@sandesh.hss.hns.com>
Date: Tue, 17 Apr 2001 19:58:35 +0530
Subject: [AAA-WG]: Accounting software
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-aaa-bof@merit.edu
Precedence: bulk



Hi,
   Do we have any free softwares implementing Radius especially the accounting
feature.

Regards
sarika





From owner-aaa-bof@merit.edu  Tue Apr 17 15:20:38 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13988
	for <aaa-archive@odin.ietf.org>; Tue, 17 Apr 2001 15:20:33 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id EDED05DE25; Tue, 17 Apr 2001 15:17:54 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id DA7775DE27; Tue, 17 Apr 2001 15:17:54 -0400 (EDT)
Received: from DTV3.DeltaTel.RU (dtv3.deltatel.ru [194.8.169.65])
	by segue.merit.edu (Postfix) with SMTP id 51BBC5DE25
	for <aaa-wg@merit.edu>; Tue, 17 Apr 2001 15:17:32 -0400 (EDT)
Received: from SMTP.DeltaTel.RU ([172.16.6.6]) by DTV5.DeltaTel.RU with ESMTP;
          Tue, 17 Apr 2001 23:12:39 GMT
Message-ID: <3ADC97D3.3E890F02@SMTP.DeltaTel.RU>
Date: Tue, 17 Apr 2001 23:21:55 +0400
From: "Ruslan R. Laishev" <Laishev@SMTP.DeltaTel.RU>
Organization: StarLet Group
X-Mailer: Mozilla 4.08 [en] (WinNT; U)
MIME-Version: 1.0
To: sargupta@hss.hns.com
Cc: aaa-wg@merit.edu
Subject: Re: [AAA-WG]: Accounting software
References: <65256A31.0067BE89.00@sandesh.hss.hns.com>
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 7bit
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

http://ing.ctit.utwente.nl/WU5/D5.1/Technology/radius/

sargupta@hss.hns.com wrote:
> 
> Hi,
>    Do we have any free softwares implementing Radius especially the accounting
> feature.
> 
> Regards
> sarika

-- 
Cheers, Ruslan.
+---------------pure personal opinion-----------------------+
    RADIUS Server for OpenVMS project - www.radiusvms.com
      vms-isps@dls.net - Forum for ISP running OpenVMS
  Mobile: +7 (901) 971-3222, AIM nickname:"VMS hardworker"



From owner-aaa-bof@merit.edu  Tue Apr 17 18:54:45 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA17617
	for <aaa-archive@odin.ietf.org>; Tue, 17 Apr 2001 18:54:44 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id DEB145DDF9; Tue, 17 Apr 2001 18:54:28 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id BED435DD9E; Tue, 17 Apr 2001 18:54:28 -0400 (EDT)
Received: from motgate.mot.com (motgate.mot.com [129.188.136.100])
	by segue.merit.edu (Postfix) with ESMTP id 5FA1A5DD9D
	for <aaa-wg@merit.edu>; Tue, 17 Apr 2001 18:54:27 -0400 (EDT)
Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate.mot.com (motgate 2.1) with ESMTP id PAA09916 for <aaa-wg@merit.edu>; Tue, 17 Apr 2001 15:54:26 -0700 (MST)]
Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id PAA28128 for <aaa-wg@merit.edu>; Tue, 17 Apr 2001 15:48:58 -0700 (MST)]
Received: by IL75EXM04 with Internet Mail Service (5.5.2653.19)
	id <25PX84VT>; Tue, 17 Apr 2001 17:54:25 -0500
Message-ID: <35DBB8B7AC89D4118E98009027B1009B0ECE81@IL27EXM10.cig.mot.com>
From: Cain Brian-BCAIN1 <Brian.Cain@motorola.com>
To: "'James Kempf'" <James.Kempf@Sun.COM>, aaa-wg@merit.edu
Subject: RE: [AAA-WG]: New API Draft -- Initial impression
Date: Tue, 17 Apr 2001 17:54:24 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Initial impression from a quick skim through the new draft.

> -----Original Message-----
> From: James Kempf [mailto:James.Kempf@Sun.COM]
> Subject: [AAA-WG]: New API Draft
> 
> ...
> 
> One thing that came up while I was doing the Java API is that Java
> has no way to represent Unsigned64 or Float128. What I've done is 
> define classes that identify these types as having been sent
> on the wire, but simply pass through to Long and Double, respectively.
> This means that it will not be possible to get an unsigned long
> and that any floats over 64 bits will be flagged as errors, even
> though they were sent as Float128. An alternative definition would
> use BigInt and Decimal, which don't work like the normal numerical
> types but do allow arbitrary precision numbers.

BigInteger and BigDecimal, for sure.  Worst case I can see that would result
is some additional overhead, and as a software developer, I count on Moore's
Law to crank out several more clock cycles by the time there's a finished
product.

~~~~~~~~
From AAACommandDescriptor:
>4.3.4.3 Fields
>
>   The following fields indicate the kind of command, and correspond to
>   flag settings described in Section 3.0 of [1]:
>
-      static public byte INDICATION = 0
+      public static final byte INDICATION = 0
-      static public byte REQUEST    = 1
+      public static final byte REQUEST    = 0x04
-      static public byte ANSWER     = 2
+      public static final byte ANSWER     = 0x01
-      static public byte QUERY      = 3
+      public static final byte QUERY      = 0x06
-      static public byte REPLY      = 4
+      public static final byte REPLY      = 0x03

Changed to directly correspond to Section 3.0.  I'm not opposed to using an
enumeration, but if it stays I think there should be a slight adjustment to
the wording of "correspond to flag settings...", because this enumeration
really only corresponds to the names of the flags, not their values.  I
can't see which method in AAACommandDescriptor would use these, though.  How
about this addition to 4.3.4.4?

>4.3.4.4 Instance Methods
>
>      public String getName()
>
>   Return the command's name.
+
+     public byte getCommandType()
+
+   Returns the command's type (one of INDICATION, REQUEST, ANSWER, QUERY,
REPLY defined above).
+

From AVPDescriptor (4.3.3.5):
-      public boolean isEndToEndEncrypted()
+      public boolean isEndToEndEncryptable()
>
-   Return true if this AVP is encrypted end-to-end.
+   Returns true if this AVP is encrypted end-to-end.




From owner-aaa-bof@merit.edu  Tue Apr 17 19:22:41 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA17983
	for <aaa-archive@odin.ietf.org>; Tue, 17 Apr 2001 19:22:40 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id D52055DE2A; Tue, 17 Apr 2001 19:20:33 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id C45275DE10; Tue, 17 Apr 2001 19:20:33 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id 136A95DE06
	for <aaa-wg@merit.edu>; Tue, 17 Apr 2001 19:20:32 -0400 (EDT)
Received: from heliopolis.eng.sun.com ([152.70.1.39])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id QAA06226;
	Tue, 17 Apr 2001 16:20:28 -0700 (PDT)
Received: from srmtv29a (srmtv29a [152.70.1.41])
	by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id QAA16202;
	Tue, 17 Apr 2001 16:20:22 -0700 (PDT)
Message-Id: <200104172320.QAA16202@heliopolis.eng.sun.com>
Date: Tue, 17 Apr 2001 16:20:22 -0700 (PDT)
From: James Kempf <James.Kempf@sun.com>
Reply-To: James Kempf <James.Kempf@sun.com>
Subject: RE: [AAA-WG]: New API Draft -- Initial impression
To: James.Kempf@sun.com, aaa-wg@merit.edu, Brian.Cain@motorola.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: 84RyVyuyzyQcHOuQc17bRg==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

OK, thanx Brian. I will fold your comments into the next draft.

		jak
		
>From: Cain Brian-BCAIN1 <Brian.Cain@motorola.com>
>To: "'James Kempf'" <James.Kempf@sun.com>, aaa-wg@merit.edu
>Subject: RE: [AAA-WG]: New API Draft -- Initial impression
>Date: Tue, 17 Apr 2001 17:54:24 -0500
>
>Initial impression from a quick skim through the new draft.
>
>> -----Original Message-----
>> From: James Kempf [mailto:James.Kempf@Sun.COM]
>> Subject: [AAA-WG]: New API Draft
>> 
>> ...
>> 
>> One thing that came up while I was doing the Java API is that Java
>> has no way to represent Unsigned64 or Float128. What I've done is 
>> define classes that identify these types as having been sent
>> on the wire, but simply pass through to Long and Double, respectively.
>> This means that it will not be possible to get an unsigned long
>> and that any floats over 64 bits will be flagged as errors, even
>> though they were sent as Float128. An alternative definition would
>> use BigInt and Decimal, which don't work like the normal numerical
>> types but do allow arbitrary precision numbers.
>
>BigInteger and BigDecimal, for sure.  Worst case I can see that would result
>is some additional overhead, and as a software developer, I count on Moore's
>Law to crank out several more clock cycles by the time there's a finished
>product.
>
>~~~~~~~~
>>From AAACommandDescriptor:
>>4.3.4.3 Fields
>>
>>   The following fields indicate the kind of command, and correspond to
>>   flag settings described in Section 3.0 of [1]:
>>
>-      static public byte INDICATION = 0
>+      public static final byte INDICATION = 0
>-      static public byte REQUEST    = 1
>+      public static final byte REQUEST    = 0x04
>-      static public byte ANSWER     = 2
>+      public static final byte ANSWER     = 0x01
>-      static public byte QUERY      = 3
>+      public static final byte QUERY      = 0x06
>-      static public byte REPLY      = 4
>+      public static final byte REPLY      = 0x03
>
>Changed to directly correspond to Section 3.0.  I'm not opposed to using an
>enumeration, but if it stays I think there should be a slight adjustment to
>the wording of "correspond to flag settings...", because this enumeration
>really only corresponds to the names of the flags, not their values.  I
>can't see which method in AAACommandDescriptor would use these, though.  How
>about this addition to 4.3.4.4?
>
>>4.3.4.4 Instance Methods
>>
>>      public String getName()
>>
>>   Return the command's name.
>+
>+     public byte getCommandType()
>+
>+   Returns the command's type (one of INDICATION, REQUEST, ANSWER, QUERY,
>REPLY defined above).
>+
>
>>From AVPDescriptor (4.3.3.5):
>-      public boolean isEndToEndEncrypted()
>+      public boolean isEndToEndEncryptable()
>>
>-   Return true if this AVP is encrypted end-to-end.
>+   Returns true if this AVP is encrypted end-to-end.
>




From owner-aaa-bof@merit.edu  Tue Apr 17 19:45:16 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA18397
	for <aaa-archive@odin.ietf.org>; Tue, 17 Apr 2001 19:45:16 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 851675DDB4; Tue, 17 Apr 2001 15:09:30 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 6F8135DD9E; Tue, 17 Apr 2001 15:09:30 -0400 (EDT)
Received: from newman.frascone.com (unknown [216.62.83.25])
	by segue.merit.edu (Postfix) with SMTP id ECEB85DD8C
	for <aaa-wg@merit.edu>; Tue, 17 Apr 2001 15:09:28 -0400 (EDT)
Received: (qmail 2674 invoked by uid 500); 17 Apr 2001 19:09:41 -0000
Date: Tue, 17 Apr 2001 14:09:41 -0500
From: David Frascone <dave@frascone.com>
To: aaa-wg@merit.edu
Subject: Re: [AAA-WG]: Accounting software
Message-ID: <20010417140940.C12832@newman.frascone.com>
Mail-Followup-To: aaa-wg@merit.edu
References: <65256A31.0067BE89.00@sandesh.hss.hns.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <65256A31.0067BE89.00@sandesh.hss.hns.com>; from sargupta@hss.hns.com on Tue, Apr 17, 2001 at 07:58:35PM +0530
X-encrypt-payload: no
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

You can probably still find the old livingston code.  It just wrote the
data to disk, IIRC.

On Tue, Apr 17, 2001 at 07:58:35PM +0530, sargupta@hss.hns.com wrote:
> 
> 
> Hi,
>    Do we have any free softwares implementing Radius especially the accounting
> feature.
> 
> Regards
> sarika
> 
> 
> 



From owner-aaa-bof@merit.edu  Wed Apr 18 03:39:20 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA07656
	for <aaa-archive@odin.ietf.org>; Wed, 18 Apr 2001 03:39:19 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id AD96F5DD93; Wed, 18 Apr 2001 03:38:59 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 981685DDA7; Wed, 18 Apr 2001 03:38:59 -0400 (EDT)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by segue.merit.edu (Postfix) with ESMTP id 096875DD93
	for <aaa-wg@merit.edu>; Wed, 18 Apr 2001 03:38:57 -0400 (EDT)
Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f3I7ctS21882
	for <aaa-wg@merit.edu>; Wed, 18 Apr 2001 09:38:55 +0200 (MEST)
Received: FROM esealnt743.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Wed Apr 18 09:38:53 2001 +0200
Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <HA3DJPAT>; Wed, 18 Apr 2001 09:36:05 +0200
Message-ID: <577066326047D41180AC00508B955DDA01D7FF84@eestqnt104.es.eu.ericsson.se>
From: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>
To: "'Fredrik Johansson'" <fredrik.johansson@ipunplugged.com>,
        "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>,
        pcalhoun@eng.sun.com, Tony Johansson <tony.johansson@ericsson.com>
Cc: AAA Listan <aaa-wg@merit.edu>
Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
Date: Wed, 18 Apr 2001 09:32:43 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Ok, let me try again.

More than one session need to be supported for each MIP user, which 
means that a user might want to register several MNs on the network at once.
That would lead to several separate MIP sessions in the Home server. AFAIK,
each MIP session can be uniquely identified by using both its Home Agent address
and its Home address. We could also add the User-Name, to easily link all
sessions for a particular user. That means that each MIP session would be
keyed on User-Name, Home Agent and Home Address. That takes into account
private addresses as well.

Then a first MN registers with a User-Name. Since it is the first
registration in a foreign domain, then no MIP-Previous-FA-XXXX is present,
neither Home Agent nor Home address. Then the FA creates a new Session-ID,
which is sent to the AAAF, which forwards it to the Home server, since 
it is the MN's first registration. Then the MN is registered successfully.

Then the MN moves to a new FA within the same domain. The MN will send the
User-Name, the Home Agent and Home address, along with the MIP-Previous-FA-XXXX.
Then the new FA will send the AMR to the AAAF, which will check if there is 
any existing session linked to a similar registration, based on the 
User-Name, the Home Agent and Home address. Since there is, the AAAF returns
the Original-Session-ID, along with the FA keys.

I guess that the same could apply when the node moves to a third domain, in
which case it would be the Home server that would be responsible of returning
the Original-Session-ID and FA keys. The same for moving to its Home domain.

If there is a second MN that registers for the same user, then it would 
register without a Home Agent and Home Address. Or if it does, I guess 
that the Home address should be already defined as unique for that 
particular MN, right? That means that a new session would be created 
by the new FA, which would trigger a new session in the Home server.
That new session would be uniquely identifiable by the User-Name,
the Home Agent and the Home address of the MN.

If ever we need to control
the number of allowed sessions per user, the Home server can reject the
AMR when it receives a new registration request from a new MN.

Does that make a bit more sense?

Martin

> -----Original Message-----
> From: Fredrik Johansson [mailto:fredrik.johansson@ipunplugged.com]
> Sent: Tuesday, April 17, 2001 4:53 PM
> To: Martin Julien (ECE); pcalhoun@eng.sun.com; Tony Johansson
> Cc: AAA Listan
> Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
> 
> 
> Hi Martin,
> 
> How would generating a session id from User-Name and 
> MIP-Previous-FA-XXXX
> help you to have several MIP sessions for the same user if the have
> different MNs? The user may still use the same User-Name on 
> all of its MNs,
> thus causing the same session id to be created.
> 
> So, I don't believe it will solve the problem. If it is a 
> problem that you
> cannot have several session with the same nai, isn't that one of the
> problems with radius that there is no way to limit a user 
> from login in
> from several places at the same time using the same user name 
> and password?
> 
> /Fredrik
> 
> >
> >Hej Fredrik,
> >
> >If the Session-ID would be generated and handled by the MN, I
> >guess it would be a lot easier. At least, we could propose a way
> >of generating a Session-ID in the FA, such as the concatenation of
> >the User-Name and the Care-Of address (FA), which would lead to a
> >predictable Session-ID. In the case where the MN would move to a
> >new FA, then the new FA would need to generate a Session-ID based
> >on the User-Name and the MIP-Previous-FA-XXXX. Would that make any
> >sense? Then, I guess we could have several different MIP sessions
> >for the same User, as long as it is using different MNs. To
> >support more than one session per MN, I guess the MN would need to
> >include additional info about that.
> >
> >We are having the same kind of problems WRT SIP, I believe.
> >
> >Martin
> >
> >> -----Original Message-----
> >> From: Fredrik Johansson [mailto:fredrik.johansson@ipunplugged.com]
> >> Sent: Tuesday, April 17, 2001 3:01 PM
> >> To: pcalhoun@eng.sun.com; Martin Julien (ECE); Tony Johansson
> >> Cc: AAA Listan
> >> Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
> >>
> >>
> >> Ok, let's see if I can write the entire message this time
> >> before sending it
> >> :-)
> >> There might be a problem with the possiblity to reuse the old
> >> session id,
> >> and
> >> that is that there can only be one session per user. I don't
> >> know if this
> >> limitation
> >> is to harsh.
> >>
> >> /Fredrik
> >>
> >> 11.7  Session Movement
> >>
> >>    When a user moves between different access devices it may
> >> be desirable
> >>    to keep the Session Id unchanged. It is therefore possible for a
> >>    server to send the original Session Id back to the client in the
> >>    Original-Session-Id AVP. An old session is identified by
> >> the User Name
> >>    Nai.
> >>
> >> 11.7.1  Original-Session-Id AVP
> >>
> >>    The Original-Session-Id AVP (AVP Code 261) is of type
> >> OctetString and
> >>    MAY be sent in a message of type Response or Answer if the AAA
> >>    server already has a session identifier for the user, 
> and wishes to
> >>    keep the existing Session-Id. All further messages from 
> the Access
> >>    Device for this session MUST use the session identifier in
> >> this AVP.
> >>    This shouldn't be viewed as a new session, but rather 
> renaming the
> >>    old session. Any message not using the Session Id in this
> >> AVP will be
> >>    treated as an unrecognized Session Id.
> >>
> >> 11.8  Session Termination
> >>
> >>    The Diameter Base Protocol provides a set of messages 
> that MUST be
> >>    used by any peer to explicitly request that a previously
> >>    authenticated and/or authorized session be terminated. Since the
> >>    Session-Id is typically tied to a particular service (i.e.
> >> Mobile IP,
> >>    NASREQ, etc), the session termination messages are used 
> to request
> >>    that the service tied to the Session Id be terminated.
> >>
> >>
> >>
> >> >>-----Original Message-----
> >> >>From: owner-aaa-bof@merit.edu
> >> [mailto:owner-aaa-bof@merit.edu]On Behalf
> >> >>Of Fredrik Johansson
> >> >>Sent: den 12 april 2001 10:04
> >> >>To: pcalhoun@eng.sun.com; Martin Julien (ECE); Tony Johansson
> >> >>Cc: AAA Listan
> >> >>Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
> >> >>
> >> >>
> >> >>No, no additional AVPs is required. However, I believe some
> >> explanations
> >> >>should be provided on how to treat the  request in
> >> different nodes. I'll
> >> >>give you some text after the weekend that hopefully will give you
> >> >>some ideas
> >> >>what I mean. Untill then I will enjoy a couple of days skiing :-)
> >> >>
> >> >>/Fredrik
> >> >>
> >> >>>-----Original Message-----
> >> >>>From: owner-aaa-bof@merit.edu
> >> [mailto:owner-aaa-bof@merit.edu]On Behalf
> >> >>>Of Patrice Calhoun
> >> >>>Sent: den 11 april 2001 19:32
> >> >>>To: Fredrik Johansson; Martin Julien (ECE); Tony Johansson
> >> >>>Cc: AAA Listan
> >> >>>Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
> >> >>>
> >> >>>
> >> >>>and no additional protocol text (read AVPs) is required???
> >> >>>
> >> >>>PatC
> >> >>>>>
> >> >>>>>Just to make sure, I *presume* that this proposed text is to
> >> >>>belong in the
> >> >>>>>Mobile IP extension, right?
> >> >>>>
> >> >>>>Yes, that's correct
> >> >>>>
> >> >>>>/Fredrik
> >> >>>>
> >> >>>>>
> >> >>>>>PatC
> >> >>>>>
> >> >>>>>ps: for those that saw my "I will not be responding to
> >> e-mail this
> >> >>>>>week", I
> >> >>>>>happen to be in a city that has metricom service :)
> >> >>>>>
> >> >>>>>>Cool! I was about to send you something very similar to know
> >> >>>>>>if it was what you meant in your previous mail.
> >> >>>>>>I agree with your solution. Thanks!
> >> >>>>>>
> >> >>>>>>> -----Original Message-----
> >> >>>>>>> From: Fredrik Johansson
> >> [mailto:fredrik.johansson@ipunplugged.com]
> >> >>>>>>> Sent: Tuesday, April 10, 2001 10:27 AM
> >> >>>>>>> To: Martin Julien (ECE); Tony Johansson
> >> >>>>>>> Cc: 'Patrice Calhoun'; AAA Listan
> >> >>>>>>> Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
> >> >>>>>>>
> >> >>>>>>>
> >> >>>>>>> After a closer look at the problem we have a 
> suggestion on a
> >> >>solution.
> >> >>>>>>> If the AAAH always assigns a SPI that is unique in 
> the HA for
> >> >>>>>>> the FA-HA key,
> >> >>>>>>> and a SPI that is unique in the Mn for the MN-FA and
> >> MN-HA keys, the
> >> >>>>>>> security contexts will automatically be unique in every SA.
> >> >>>>>>>
> >> >>>>>>> 7.5 SPI Allocation
> >> >>>>>>>   To ensure that the SPI is unique for each pair of nodes,
> >> >>>>>>>   the AAAH SHOULD keep track of assigned SPIs per 
> HA and MN.
> >> >>>>>>>   The SPI assigned to the MN-FA key MUST be allocated from
> >> >>>>>>> the MN SPI pool,
> >> >>>>>>>   the SPI for the FA-HA key MUST be allocated from 
> the HA SPI
> >> >>>>>>> pool, and the
> >> >>>>>>>   SPI for the MN-HA key MUST be allocated from the MN SPI
> >> >>>>>>> pool. Note that
> >> >>>>>>>   SPI values 0 through 255 are reserved and MUST NOT
> >> be used in any
> >> >>>>>>>   Mobility Security Association.
> >> >>>>>>>
> >> >>>>>>> /Fredrik
> >> >>>>>>> >-----Original Message-----
> >> >>>>>>> >From: owner-aaa-bof@merit.edu
> >> >>>>>>> [mailto:owner-aaa-bof@merit.edu]On Behalf
> >> >>>>>>> >Of Fredrik Johansson
> >> >>>>>>> >Sent: den 10 april 2001 08:40
> >> >>>>>>> >To: Martin Julien (ECE); Tony Johansson
> >> >>>>>>> >Cc: 'Patrice Calhoun'; AAA Listan
> >> >>>>>>> >Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
> >> >>>>>>> >
> >> >>>>>>> >
> >> >>>>>>> >>
> >> >>>>>>> >>> >>
> >> >>>>>>> >>> >> Another thing that needs some clarification,
> >> if there is a
> >> >>>>>>> >>> solution. How
> >> >>>>>>> >>> >> will the HA know which SA to use. In the case
> >> where a mobile
> >> >>>>>>> >>> >moves from one
> >> >>>>>>> >>> >> Fa to another under the same administrative
> >> domain it may
> >> >>>>>>> >>> receive the
> >> >>>>>>> >>> >> session keys for the old Fa from the AAAF. It will
> >> >>then proceed
> >> >>>>>>> >>> >to send the
> >> >>>>>>> >>> >> mip reg req to the HA. The HA will see that
> >> the message came
> >> >>>>>>> >>> >from the new FA
> >> >>>>>>> >>> >> and try to locate the SA shared with that FA. It
> >> >will not find
> >> >>>>>>> >>> >it since it
> >> >>>>>>> >>> >> was established with the old FA. Eventhough
> >> the HA can see
> >> >>>>>>> >>> the address of
> >> >>>>>>> >>> >> the old Fa in the previous-fa-XXXX it is not clear
> >> >that it can
> >> >>>>>>> >>> >establish a
> >> >>>>>>> >>> >> SA with the new Fa because it has to use 
> the same SPI
> >> >>as before
> >> >>>>>>> >>> >and that one
> >> >>>>>>> >>> >> might be busy. Or have I missed something here?
> >> >>>>>>> >>> >
> >> >>>>>>> >>> >You also have the user NAI in the MIP registration
> >> >>>>>>> request sent to
> >> >>>>>>> >>> >the HA and
> >> >>>>>>> >>> >the user NAI is globally unique....
> >> >>>>>>> >>>
> >> >>>>>>> >>> Yes, but this is not the security association
> >> shared with the
> >> >>>>>>> >>> mobile node
> >> >>>>>>> >>> but the one shared between the FA and HA, thus
> >> has nothing to
> >> >>>>>>> >>> do with the
> >> >>>>>>> >>> user.
> >> >>>>>>> >>
> >> >>>>>>> >>I think you are assuming that there exists only 
> 1 mobility
> >> >>>>>>> SA between
> >> >>>>>>> >>a FA and a HA for all the MIP sessions, right?
> >> >>>>>>> >
> >> >>>>>>> >YES, one mobility SA, ceveral security context
> >> within a mobility
> >> >>>>>>> >SA. See rfc
> >> >>>>>>> >2002,
> >> >>>>>>> >
> >> >>>>>>> >"Mobility Security Association
> >> >>>>>>> >               A collection of security contexts,
> >> between a pair
> >> >>>>>>> >               of nodes, which may be applied to
> >> Mobile IP protocol
> >> >>>>>>> >               messages exchanged between them.  Each
> >> >>>>>>> context indicates
> >> >>>>>>> >               an authentication algorithm and mode
> >> >(Section 5.1), a
> >> >>>>>>> >               secret (a shared key, or appropriate
> >> public/private
> >> >>>>>>> >               key pair), and a style of replay
> >> protection in use
> >> >>>>>>> >               (Section 5.6)."
> >> >>>>>>> >
> >> >>>>>>> >Each context is indexed with a unique SPI within 
> that SA, if
> >> >>>>>>> there exist a
> >> >>>>>>> >SA between the HA and the old FA and one SA between the HA
> >> >>>>>>> and the new FA
> >> >>>>>>> >there might exist security context with the same 
> SPI in both
> >> >>>>>>> of these.
> >> >>>>>>> >
> >> >>>>>>> >"Security Parameter Index (SPI)
> >> >>>>>>> >               An index identifying a security context
> >> >>between a pair
> >> >>>>>>> >               of nodes among the contexts available in
> >> >the Mobility
> >> >>>>>>> >               Security Association.  SPI values 0
> >> through 255 are
> >> >>>>>>> >               reserved and MUST NOT be used in any
> >> >>Mobility Security
> >> >>>>>>> >               Association."
> >> >>>>>>> >
> >> >>>>>>> >>When a first AMA is received
> >> >>>>>>> >
> >> >>>>>>> >I guess you mean AMR :-)
> >> >>>>>>> >
> >> >>>>>>> >>in the AAAH from a MN, is the AAAH supposed to 
> issue a new
> >> >>>>>>> registration
> >> >>>>>>> >>FA-HA key, in the case the HA is in the home domain? The
> >> >>>>>>> spec says "yes",
> >> >>>>>>> >>if it is required by the MN. However, how can the MN know
> >> >about the
> >> >>>>>>> >>mobility SA between the FA and the HA? I guess 
> it can not,
> >> >>>>>>> which means
> >> >>>>>>> >>that it will ask for a new key, which should be 
> transferred
> >> >>>>>>> to the FA and
> >> >>>>>>> >>the HA from the AAAH. Is there a way for the HA to
> >> notify the AAAH
> >> >>>>>>> >>that it does not need
> >> >>>>>>> >>a new key and a new SPI for its mobility SA with
> >> the FA, since it
> >> >>>>>>> >>already has one? I guess
> >> >>>>>>> >>not, right? Then, it looks like your idea could be very
> >> >>>>>>> interesting, but
> >> >>>>>>> >>I don't know how to deal with it using Diameter, 
> unless the
> >> >>>>>>> AAAH and AAAF
> >> >>>>>>> >>would keep a list of mobility SAs between each FA and HA.
> >> >>>>>>> >
> >> >>>>>>> >In some way the AAAH must keep track of what SPIs it has
> >> >>>>>>> assigned to the
> >> >>>>>>> >home agent, if it does it per SA or make the SPI
> >> unique over all
> >> >>>>>>> >SA's in the
> >> >>>>>>> >HA is up to the implementation
> >> >>>>>>> >
> >> >>>>>>> >>
> >> >>>>>>> >>> You can not guarantee that a security between 
> the HA and
> >> >>>>>>> the old FA is
> >> >>>>>>> >>> unique between the HA and the new FA. The same 
> SPI must be
> >> >>>>>>> >>> used in the first
> >> >>>>>>> >>> request in order for the HA to be able to
> >> distinguise between
> >> >>>>>>> >>> different
> >> >>>>>>> >>> security contexts it shares with the FA. What we
> >> can do is to
> >> >>>>>>> >>> have the new
> >> >>>>>>> >>> FA add a <MIP-Preferred-SPI Ext> in the first 
> request from
> >> >>>>>>> >>> the new FA to the
> >> >>>>>>> >>> HA, the HA can then use the <Previous-FA-XXXX
> >> Ext> together
> >> >>>>>>> >>> with the old SPI
> >> >>>>>>> >>> to retreive the context and store it under the
> >> Preferred SPI
> >> >>>>>>> >>> under the SA
> >> >>>>>>> >>> with the new FA.
> >> >>>>>>> >>
> >> >>>>>>> >>I was wondering whether or not a mobility SA between a FA
> >> >>>>>>> >>and a HA was based on a particular MIP session? My
> >> understanding
> >> >>>>>>> >>_IS_ that an existing SA is based on a MIP session.
> >> That means
> >> >>>>>>> >>that between a FA and a HA, there exists several
> >> mobility SAs
> >> >>>>>>> >>depending on each MIP session.
> >> >>>>>>> >
> >> >>>>>>> >No, there is only one SA between two nodes, but there are
> >> >>>>>>> several security
> >> >>>>>>> >context within each SA. Each security context can
> >> >>>>>>> corresponde to a mip
> >> >>>>>>> >session. It is the security context that has a 
> lifetime, the
> >> >>>>>>> SA can be
> >> >>>>>>> >removed when the last security context is removed.
> >> >>>>>>> >
> >> >>>>>>> >>By MIP session, I mean an AAA
> >> >>>>>>> >>authorized session for MIP. The SPI is already
> >> included in the
> >> >>>>>>> >>key transferred between the AAAF and the new FA. 
> I don't see
> >> >>>>>>> >>why a HA could not use the SPI stored under its 
> MN User-Name
> >> >>>>>>> >>state to retrieve the mobility SA between the new
> >> FA and itself?
> >> >>>>>>> >
> >> >>>>>>> >Because the SA between the FA and HA does not realy
> >> have anything
> >> >>>>>>> >to do with
> >> >>>>>>> >the Mn. It is something setup between the FA and HA. Thus
> >> >>>>>>> when the HA will
> >> >>>>>>> >look for the key to use it will do the lookup on the
> >> FA address.
> >> >>>>>>> >
> >> >>>>>>> >/Fredrik
> >> >>>>>>> >
> >> >>>>>>> >>
> >> >>>>>>> >>Regards,
> >> >>>>>>> >>Martin
> >> >>>>>>> >
> >> >>>>>>>
> >> >>>>>
> >> >>>>>
> >> >>>
> >> >>>
> >> >>
> >> >
> >>
> 



From owner-aaa-bof@merit.edu  Wed Apr 18 04:45:12 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA08177
	for <aaa-archive@odin.ietf.org>; Wed, 18 Apr 2001 04:45:11 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id CC2995DEC2; Wed, 18 Apr 2001 04:43:57 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id A72E65DE4C; Wed, 18 Apr 2001 04:43:57 -0400 (EDT)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by segue.merit.edu (Postfix) with ESMTP id C944C5DEC1
	for <aaa-wg@merit.edu>; Wed, 18 Apr 2001 04:43:54 -0400 (EDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f3I8hrS09148
	for <aaa-wg@merit.edu>; Wed, 18 Apr 2001 10:43:53 +0200 (MEST)
Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.27.159])
	by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f3I8hpK17159
	for <aaa-wg@merit.edu>; Wed, 18 Apr 2001 11:43:51 +0300 (EET DST)
Message-ID: <3ADD53C7.D9206765@lmf.ericsson.se>
Date: Wed, 18 Apr 2001 11:43:51 +0300
From: Jari Arkko <Jari.Arkko@lmf.ericsson.se>
Organization: Oy L M Ericsson Ab
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: aaa-wg@merit.edu
Subject: [AAA-WG]: separated authorization and accounting servers? (resend, sorry if you 
 get this
 	 twice...)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit


Hello,

We've been trying to figure out if the current
version of the Diameter specs allow accounting
and other traffic to be directed to different
servers. Traditionally, we've had this feature
in RADIUS. It might even be conceivable that there
be uses of accounting where there is no authentication
or authorization at all on a node that gives a service.

But can we do this? We haven't figured out if the
specifications say anything about this. Section 13.1
talks about authorization server directed model, but
I would classify the "direction" as optional information.
Section 13.2 says servers that receive a succesfull
authentication response must collect accounting information.
But must they send it too? And can there be other nodes
that would not perform authentication/authorization but
who still produce accounting information (e.g. for
trend analysis purposes)? Section 11 talks about user
sessions and their life-cycle. But it doesn't seem to
state anything about this issue in particular.

Do we allow two proxies to be configured for a client
node, one for the authentication and authorization, and
the second one for accounting?

And whatever we say, why are we saying so?

Jari



From owner-aaa-bof@merit.edu  Wed Apr 18 06:39:14 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA08960
	for <aaa-archive@odin.ietf.org>; Wed, 18 Apr 2001 06:39:13 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 82FC25DD96; Wed, 18 Apr 2001 06:38:55 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 529995DD9A; Wed, 18 Apr 2001 06:38:55 -0400 (EDT)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by segue.merit.edu (Postfix) with ESMTP id 679D05DD96
	for <aaa-wg@merit.edu>; Wed, 18 Apr 2001 06:38:53 -0400 (EDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id f3IAcoS02072;
	Wed, 18 Apr 2001 12:38:51 +0200 (MEST)
Received: from lmf.ericsson.se (lmf4ws450.lmf.ericsson.se [131.160.27.159])
	by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f3IAcnK23741;
	Wed, 18 Apr 2001 13:38:50 +0300 (EET DST)
Message-ID: <3ADD6EBA.9A9215C7@lmf.ericsson.se>
Date: Wed, 18 Apr 2001 13:38:50 +0300
From: Jari Arkko <Jari.Arkko@lmf.ericsson.se>
Organization: Oy L M Ericsson Ab
X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.6 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: aaa-wg@merit.edu
Cc: jarkko@piuha.net
Subject: [AAA-WG]: IANA considerations
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit


I just read the IANA considerations section of the
base protocol. It seems OK, but there is one part
that worries me: currently, we allow new extension
IDs for only services that are _Standards Track RFCs_.
Given that the extension number space is 32 bits
wide, and that various new services might pop up
that require specific new functionality in the
form of an extension, why are we requiring this
much? Wouldn't allocation through Designated
Expert be sufficient? Or do we expect all new services
stay solely within the business of adding new AVPs?

Also, I'm not sure I understand the purpose of
the Diameter shall not be extended - statement
in 17.3. Surely we can imagine situations that
even Diameter base protocol will be extended.
Hopefully not soon, but we have even reserved
mechanisms for this in the form of version numbers
in the header etc.

Jari



From owner-aaa-bof@merit.edu  Wed Apr 18 07:24:10 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA09194
	for <aaa-archive@odin.ietf.org>; Wed, 18 Apr 2001 07:24:09 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id ECD045DD9A; Wed, 18 Apr 2001 07:23:50 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id D8A555DDA2; Wed, 18 Apr 2001 07:23:50 -0400 (EDT)
Received: from mailgw.local.ipunplugged.com (unknown [213.88.134.217])
	by segue.merit.edu (Postfix) with ESMTP id 6EDEE5DD9A
	for <aaa-wg@merit.edu>; Wed, 18 Apr 2001 07:23:47 -0400 (EDT)
Received: from fredrikj (c35.local.ipunplugged.com [192.168.4.234])
	by mailgw.local.ipunplugged.com (8.9.3/8.9.3) with SMTP id NAA28352;
	Wed, 18 Apr 2001 13:24:47 +0200
From: "Fredrik Johansson" <fredrik.johansson@ipunplugged.com>
To: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>,
        <pcalhoun@eng.sun.com>, "Tony Johansson" <tony.johansson@ericsson.com>
Cc: "AAA Listan" <aaa-wg@merit.edu>
Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
Date: Wed, 18 Apr 2001 13:25:30 +0200
Message-ID: <MJEMJBGGCLLDLFFAHLJKCEDLCKAA.fredrik.johansson@ipunplugged.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <577066326047D41180AC00508B955DDA01D7FF84@eestqnt104.es.eu.ericsson.se>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Looks like it would work, the only question is what happens when a second MN
tries to register with the same Nai, home address and home agent address?

/Fredrik

>
>Ok, let me try again.
>
>More than one session need to be supported for each MIP user, which
>means that a user might want to register several MNs on the
>network at once.
>That would lead to several separate MIP sessions in the Home server. AFAIK,
>each MIP session can be uniquely identified by using both its Home
>Agent address
>and its Home address. We could also add the User-Name, to easily link all
>sessions for a particular user. That means that each MIP session would be
>keyed on User-Name, Home Agent and Home Address. That takes into account
>private addresses as well.
>
>Then a first MN registers with a User-Name. Since it is the first
>registration in a foreign domain, then no MIP-Previous-FA-XXXX is present,
>neither Home Agent nor Home address. Then the FA creates a new Session-ID,
>which is sent to the AAAF, which forwards it to the Home server, since
>it is the MN's first registration. Then the MN is registered successfully.
>
>Then the MN moves to a new FA within the same domain. The MN will send the
>User-Name, the Home Agent and Home address, along with the
>MIP-Previous-FA-XXXX.
>Then the new FA will send the AMR to the AAAF, which will check if
>there is
>any existing session linked to a similar registration, based on the
>User-Name, the Home Agent and Home address. Since there is, the
>AAAF returns
>the Original-Session-ID, along with the FA keys.
>
>I guess that the same could apply when the node moves to a third domain, in
>which case it would be the Home server that would be responsible
>of returning
>the Original-Session-ID and FA keys. The same for moving to its
>Home domain.
>
>If there is a second MN that registers for the same user, then it would
>register without a Home Agent and Home Address. Or if it does, I guess
>that the Home address should be already defined as unique for that
>particular MN, right? That means that a new session would be created
>by the new FA, which would trigger a new session in the Home server.
>That new session would be uniquely identifiable by the User-Name,
>the Home Agent and the Home address of the MN.
>
>If ever we need to control
>the number of allowed sessions per user, the Home server can reject the
>AMR when it receives a new registration request from a new MN.
>
>Does that make a bit more sense?
>
>Martin
>
>> -----Original Message-----
>> From: Fredrik Johansson [mailto:fredrik.johansson@ipunplugged.com]
>> Sent: Tuesday, April 17, 2001 4:53 PM
>> To: Martin Julien (ECE); pcalhoun@eng.sun.com; Tony Johansson
>> Cc: AAA Listan
>> Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
>>
>>
>> Hi Martin,
>>
>> How would generating a session id from User-Name and
>> MIP-Previous-FA-XXXX
>> help you to have several MIP sessions for the same user if the have
>> different MNs? The user may still use the same User-Name on
>> all of its MNs,
>> thus causing the same session id to be created.
>>
>> So, I don't believe it will solve the problem. If it is a
>> problem that you
>> cannot have several session with the same nai, isn't that one of the
>> problems with radius that there is no way to limit a user
>> from login in
>> from several places at the same time using the same user name
>> and password?
>>
>> /Fredrik
>>
>> >
>> >Hej Fredrik,
>> >
>> >If the Session-ID would be generated and handled by the MN, I
>> >guess it would be a lot easier. At least, we could propose a way
>> >of generating a Session-ID in the FA, such as the concatenation of
>> >the User-Name and the Care-Of address (FA), which would lead to a
>> >predictable Session-ID. In the case where the MN would move to a
>> >new FA, then the new FA would need to generate a Session-ID based
>> >on the User-Name and the MIP-Previous-FA-XXXX. Would that make any
>> >sense? Then, I guess we could have several different MIP sessions
>> >for the same User, as long as it is using different MNs. To
>> >support more than one session per MN, I guess the MN would need to
>> >include additional info about that.
>> >
>> >We are having the same kind of problems WRT SIP, I believe.
>> >
>> >Martin
>> >
>> >> -----Original Message-----
>> >> From: Fredrik Johansson [mailto:fredrik.johansson@ipunplugged.com]
>> >> Sent: Tuesday, April 17, 2001 3:01 PM
>> >> To: pcalhoun@eng.sun.com; Martin Julien (ECE); Tony Johansson
>> >> Cc: AAA Listan
>> >> Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
>> >>
>> >>
>> >> Ok, let's see if I can write the entire message this time
>> >> before sending it
>> >> :-)
>> >> There might be a problem with the possiblity to reuse the old
>> >> session id,
>> >> and
>> >> that is that there can only be one session per user. I don't
>> >> know if this
>> >> limitation
>> >> is to harsh.
>> >>
>> >> /Fredrik
>> >>
>> >> 11.7  Session Movement
>> >>
>> >>    When a user moves between different access devices it may
>> >> be desirable
>> >>    to keep the Session Id unchanged. It is therefore possible for a
>> >>    server to send the original Session Id back to the client in the
>> >>    Original-Session-Id AVP. An old session is identified by
>> >> the User Name
>> >>    Nai.
>> >>
>> >> 11.7.1  Original-Session-Id AVP
>> >>
>> >>    The Original-Session-Id AVP (AVP Code 261) is of type
>> >> OctetString and
>> >>    MAY be sent in a message of type Response or Answer if the AAA
>> >>    server already has a session identifier for the user,
>> and wishes to
>> >>    keep the existing Session-Id. All further messages from
>> the Access
>> >>    Device for this session MUST use the session identifier in
>> >> this AVP.
>> >>    This shouldn't be viewed as a new session, but rather
>> renaming the
>> >>    old session. Any message not using the Session Id in this
>> >> AVP will be
>> >>    treated as an unrecognized Session Id.
>> >>
>> >> 11.8  Session Termination
>> >>
>> >>    The Diameter Base Protocol provides a set of messages
>> that MUST be
>> >>    used by any peer to explicitly request that a previously
>> >>    authenticated and/or authorized session be terminated. Since the
>> >>    Session-Id is typically tied to a particular service (i.e.
>> >> Mobile IP,
>> >>    NASREQ, etc), the session termination messages are used
>> to request
>> >>    that the service tied to the Session Id be terminated.
>> >>
>> >>
>> >>
>> >> >>-----Original Message-----
>> >> >>From: owner-aaa-bof@merit.edu
>> >> [mailto:owner-aaa-bof@merit.edu]On Behalf
>> >> >>Of Fredrik Johansson
>> >> >>Sent: den 12 april 2001 10:04
>> >> >>To: pcalhoun@eng.sun.com; Martin Julien (ECE); Tony Johansson
>> >> >>Cc: AAA Listan
>> >> >>Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
>> >> >>
>> >> >>
>> >> >>No, no additional AVPs is required. However, I believe some
>> >> explanations
>> >> >>should be provided on how to treat the  request in
>> >> different nodes. I'll
>> >> >>give you some text after the weekend that hopefully will give you
>> >> >>some ideas
>> >> >>what I mean. Untill then I will enjoy a couple of days skiing :-)
>> >> >>
>> >> >>/Fredrik
>> >> >>
>> >> >>>-----Original Message-----
>> >> >>>From: owner-aaa-bof@merit.edu
>> >> [mailto:owner-aaa-bof@merit.edu]On Behalf
>> >> >>>Of Patrice Calhoun
>> >> >>>Sent: den 11 april 2001 19:32
>> >> >>>To: Fredrik Johansson; Martin Julien (ECE); Tony Johansson
>> >> >>>Cc: AAA Listan
>> >> >>>Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
>> >> >>>
>> >> >>>
>> >> >>>and no additional protocol text (read AVPs) is required???
>> >> >>>
>> >> >>>PatC
>> >> >>>>>
>> >> >>>>>Just to make sure, I *presume* that this proposed text is to
>> >> >>>belong in the
>> >> >>>>>Mobile IP extension, right?
>> >> >>>>
>> >> >>>>Yes, that's correct
>> >> >>>>
>> >> >>>>/Fredrik
>> >> >>>>
>> >> >>>>>
>> >> >>>>>PatC
>> >> >>>>>
>> >> >>>>>ps: for those that saw my "I will not be responding to
>> >> e-mail this
>> >> >>>>>week", I
>> >> >>>>>happen to be in a city that has metricom service :)
>> >> >>>>>
>> >> >>>>>>Cool! I was about to send you something very similar to know
>> >> >>>>>>if it was what you meant in your previous mail.
>> >> >>>>>>I agree with your solution. Thanks!
>> >> >>>>>>
>> >> >>>>>>> -----Original Message-----
>> >> >>>>>>> From: Fredrik Johansson
>> >> [mailto:fredrik.johansson@ipunplugged.com]
>> >> >>>>>>> Sent: Tuesday, April 10, 2001 10:27 AM
>> >> >>>>>>> To: Martin Julien (ECE); Tony Johansson
>> >> >>>>>>> Cc: 'Patrice Calhoun'; AAA Listan
>> >> >>>>>>> Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>>> After a closer look at the problem we have a
>> suggestion on a
>> >> >>solution.
>> >> >>>>>>> If the AAAH always assigns a SPI that is unique in
>> the HA for
>> >> >>>>>>> the FA-HA key,
>> >> >>>>>>> and a SPI that is unique in the Mn for the MN-FA and
>> >> MN-HA keys, the
>> >> >>>>>>> security contexts will automatically be unique in every SA.
>> >> >>>>>>>
>> >> >>>>>>> 7.5 SPI Allocation
>> >> >>>>>>>   To ensure that the SPI is unique for each pair of nodes,
>> >> >>>>>>>   the AAAH SHOULD keep track of assigned SPIs per
>> HA and MN.
>> >> >>>>>>>   The SPI assigned to the MN-FA key MUST be allocated from
>> >> >>>>>>> the MN SPI pool,
>> >> >>>>>>>   the SPI for the FA-HA key MUST be allocated from
>> the HA SPI
>> >> >>>>>>> pool, and the
>> >> >>>>>>>   SPI for the MN-HA key MUST be allocated from the MN SPI
>> >> >>>>>>> pool. Note that
>> >> >>>>>>>   SPI values 0 through 255 are reserved and MUST NOT
>> >> be used in any
>> >> >>>>>>>   Mobility Security Association.
>> >> >>>>>>>
>> >> >>>>>>> /Fredrik
>> >> >>>>>>> >-----Original Message-----
>> >> >>>>>>> >From: owner-aaa-bof@merit.edu
>> >> >>>>>>> [mailto:owner-aaa-bof@merit.edu]On Behalf
>> >> >>>>>>> >Of Fredrik Johansson
>> >> >>>>>>> >Sent: den 10 april 2001 08:40
>> >> >>>>>>> >To: Martin Julien (ECE); Tony Johansson
>> >> >>>>>>> >Cc: 'Patrice Calhoun'; AAA Listan
>> >> >>>>>>> >Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
>> >> >>>>>>> >
>> >> >>>>>>> >
>> >> >>>>>>> >>
>> >> >>>>>>> >>> >>
>> >> >>>>>>> >>> >> Another thing that needs some clarification,
>> >> if there is a
>> >> >>>>>>> >>> solution. How
>> >> >>>>>>> >>> >> will the HA know which SA to use. In the case
>> >> where a mobile
>> >> >>>>>>> >>> >moves from one
>> >> >>>>>>> >>> >> Fa to another under the same administrative
>> >> domain it may
>> >> >>>>>>> >>> receive the
>> >> >>>>>>> >>> >> session keys for the old Fa from the AAAF. It will
>> >> >>then proceed
>> >> >>>>>>> >>> >to send the
>> >> >>>>>>> >>> >> mip reg req to the HA. The HA will see that
>> >> the message came
>> >> >>>>>>> >>> >from the new FA
>> >> >>>>>>> >>> >> and try to locate the SA shared with that FA. It
>> >> >will not find
>> >> >>>>>>> >>> >it since it
>> >> >>>>>>> >>> >> was established with the old FA. Eventhough
>> >> the HA can see
>> >> >>>>>>> >>> the address of
>> >> >>>>>>> >>> >> the old Fa in the previous-fa-XXXX it is not clear
>> >> >that it can
>> >> >>>>>>> >>> >establish a
>> >> >>>>>>> >>> >> SA with the new Fa because it has to use
>> the same SPI
>> >> >>as before
>> >> >>>>>>> >>> >and that one
>> >> >>>>>>> >>> >> might be busy. Or have I missed something here?
>> >> >>>>>>> >>> >
>> >> >>>>>>> >>> >You also have the user NAI in the MIP registration
>> >> >>>>>>> request sent to
>> >> >>>>>>> >>> >the HA and
>> >> >>>>>>> >>> >the user NAI is globally unique....
>> >> >>>>>>> >>>
>> >> >>>>>>> >>> Yes, but this is not the security association
>> >> shared with the
>> >> >>>>>>> >>> mobile node
>> >> >>>>>>> >>> but the one shared between the FA and HA, thus
>> >> has nothing to
>> >> >>>>>>> >>> do with the
>> >> >>>>>>> >>> user.
>> >> >>>>>>> >>
>> >> >>>>>>> >>I think you are assuming that there exists only
>> 1 mobility
>> >> >>>>>>> SA between
>> >> >>>>>>> >>a FA and a HA for all the MIP sessions, right?
>> >> >>>>>>> >
>> >> >>>>>>> >YES, one mobility SA, ceveral security context
>> >> within a mobility
>> >> >>>>>>> >SA. See rfc
>> >> >>>>>>> >2002,
>> >> >>>>>>> >
>> >> >>>>>>> >"Mobility Security Association
>> >> >>>>>>> >               A collection of security contexts,
>> >> between a pair
>> >> >>>>>>> >               of nodes, which may be applied to
>> >> Mobile IP protocol
>> >> >>>>>>> >               messages exchanged between them.  Each
>> >> >>>>>>> context indicates
>> >> >>>>>>> >               an authentication algorithm and mode
>> >> >(Section 5.1), a
>> >> >>>>>>> >               secret (a shared key, or appropriate
>> >> public/private
>> >> >>>>>>> >               key pair), and a style of replay
>> >> protection in use
>> >> >>>>>>> >               (Section 5.6)."
>> >> >>>>>>> >
>> >> >>>>>>> >Each context is indexed with a unique SPI within
>> that SA, if
>> >> >>>>>>> there exist a
>> >> >>>>>>> >SA between the HA and the old FA and one SA between the HA
>> >> >>>>>>> and the new FA
>> >> >>>>>>> >there might exist security context with the same
>> SPI in both
>> >> >>>>>>> of these.
>> >> >>>>>>> >
>> >> >>>>>>> >"Security Parameter Index (SPI)
>> >> >>>>>>> >               An index identifying a security context
>> >> >>between a pair
>> >> >>>>>>> >               of nodes among the contexts available in
>> >> >the Mobility
>> >> >>>>>>> >               Security Association.  SPI values 0
>> >> through 255 are
>> >> >>>>>>> >               reserved and MUST NOT be used in any
>> >> >>Mobility Security
>> >> >>>>>>> >               Association."
>> >> >>>>>>> >
>> >> >>>>>>> >>When a first AMA is received
>> >> >>>>>>> >
>> >> >>>>>>> >I guess you mean AMR :-)
>> >> >>>>>>> >
>> >> >>>>>>> >>in the AAAH from a MN, is the AAAH supposed to
>> issue a new
>> >> >>>>>>> registration
>> >> >>>>>>> >>FA-HA key, in the case the HA is in the home domain? The
>> >> >>>>>>> spec says "yes",
>> >> >>>>>>> >>if it is required by the MN. However, how can the MN know
>> >> >about the
>> >> >>>>>>> >>mobility SA between the FA and the HA? I guess
>> it can not,
>> >> >>>>>>> which means
>> >> >>>>>>> >>that it will ask for a new key, which should be
>> transferred
>> >> >>>>>>> to the FA and
>> >> >>>>>>> >>the HA from the AAAH. Is there a way for the HA to
>> >> notify the AAAH
>> >> >>>>>>> >>that it does not need
>> >> >>>>>>> >>a new key and a new SPI for its mobility SA with
>> >> the FA, since it
>> >> >>>>>>> >>already has one? I guess
>> >> >>>>>>> >>not, right? Then, it looks like your idea could be very
>> >> >>>>>>> interesting, but
>> >> >>>>>>> >>I don't know how to deal with it using Diameter,
>> unless the
>> >> >>>>>>> AAAH and AAAF
>> >> >>>>>>> >>would keep a list of mobility SAs between each FA and HA.
>> >> >>>>>>> >
>> >> >>>>>>> >In some way the AAAH must keep track of what SPIs it has
>> >> >>>>>>> assigned to the
>> >> >>>>>>> >home agent, if it does it per SA or make the SPI
>> >> unique over all
>> >> >>>>>>> >SA's in the
>> >> >>>>>>> >HA is up to the implementation
>> >> >>>>>>> >
>> >> >>>>>>> >>
>> >> >>>>>>> >>> You can not guarantee that a security between
>> the HA and
>> >> >>>>>>> the old FA is
>> >> >>>>>>> >>> unique between the HA and the new FA. The same
>> SPI must be
>> >> >>>>>>> >>> used in the first
>> >> >>>>>>> >>> request in order for the HA to be able to
>> >> distinguise between
>> >> >>>>>>> >>> different
>> >> >>>>>>> >>> security contexts it shares with the FA. What we
>> >> can do is to
>> >> >>>>>>> >>> have the new
>> >> >>>>>>> >>> FA add a <MIP-Preferred-SPI Ext> in the first
>> request from
>> >> >>>>>>> >>> the new FA to the
>> >> >>>>>>> >>> HA, the HA can then use the <Previous-FA-XXXX
>> >> Ext> together
>> >> >>>>>>> >>> with the old SPI
>> >> >>>>>>> >>> to retreive the context and store it under the
>> >> Preferred SPI
>> >> >>>>>>> >>> under the SA
>> >> >>>>>>> >>> with the new FA.
>> >> >>>>>>> >>
>> >> >>>>>>> >>I was wondering whether or not a mobility SA between a FA
>> >> >>>>>>> >>and a HA was based on a particular MIP session? My
>> >> understanding
>> >> >>>>>>> >>_IS_ that an existing SA is based on a MIP session.
>> >> That means
>> >> >>>>>>> >>that between a FA and a HA, there exists several
>> >> mobility SAs
>> >> >>>>>>> >>depending on each MIP session.
>> >> >>>>>>> >
>> >> >>>>>>> >No, there is only one SA between two nodes, but there are
>> >> >>>>>>> several security
>> >> >>>>>>> >context within each SA. Each security context can
>> >> >>>>>>> corresponde to a mip
>> >> >>>>>>> >session. It is the security context that has a
>> lifetime, the
>> >> >>>>>>> SA can be
>> >> >>>>>>> >removed when the last security context is removed.
>> >> >>>>>>> >
>> >> >>>>>>> >>By MIP session, I mean an AAA
>> >> >>>>>>> >>authorized session for MIP. The SPI is already
>> >> included in the
>> >> >>>>>>> >>key transferred between the AAAF and the new FA.
>> I don't see
>> >> >>>>>>> >>why a HA could not use the SPI stored under its
>> MN User-Name
>> >> >>>>>>> >>state to retrieve the mobility SA between the new
>> >> FA and itself?
>> >> >>>>>>> >
>> >> >>>>>>> >Because the SA between the FA and HA does not realy
>> >> have anything
>> >> >>>>>>> >to do with
>> >> >>>>>>> >the Mn. It is something setup between the FA and HA. Thus
>> >> >>>>>>> when the HA will
>> >> >>>>>>> >look for the key to use it will do the lookup on the
>> >> FA address.
>> >> >>>>>>> >
>> >> >>>>>>> >/Fredrik
>> >> >>>>>>> >
>> >> >>>>>>> >>
>> >> >>>>>>> >>Regards,
>> >> >>>>>>> >>Martin
>> >> >>>>>>> >
>> >> >>>>>>>
>> >> >>>>>
>> >> >>>>>
>> >> >>>
>> >> >>>
>> >> >>
>> >> >
>> >>
>>




From owner-aaa-bof@merit.edu  Wed Apr 18 08:54:40 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA10269
	for <aaa-archive@odin.ietf.org>; Wed, 18 Apr 2001 08:54:39 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 27A945DD9D; Wed, 18 Apr 2001 08:54:18 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 1275B5DDA2; Wed, 18 Apr 2001 08:54:18 -0400 (EDT)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by segue.merit.edu (Postfix) with ESMTP id BAE2A5DD9D
	for <aaa-wg@merit.edu>; Wed, 18 Apr 2001 08:54:15 -0400 (EDT)
Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f3ICsEP16863
	for <aaa-wg@merit.edu>; Wed, 18 Apr 2001 14:54:14 +0200 (MEST)
Received: FROM esealnt743.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Wed Apr 18 14:52:27 2001 +0200
Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <HA3DJ076>; Wed, 18 Apr 2001 14:54:09 +0200
Message-ID: <577066326047D41180AC00508B955DDA01D7FF89@eestqnt104.es.eu.ericsson.se>
From: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>
To: "'Fredrik Johansson'" <fredrik.johansson@ipunplugged.com>,
        "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>,
        pcalhoun@eng.sun.com, Tony Johansson <tony.johansson@ericsson.com>
Cc: AAA Listan <aaa-wg@merit.edu>
Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
Date: Wed, 18 Apr 2001 14:52:23 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

In the case where the MN is roaming within a foreign domain,
a Registration is sent and an AMR is be sent to the AAAF. Then the
AAAF returns the keys to the new FA without authenticating
the MN. That seems to be a "problem". However, if it would reach 
the Home server, then the MN could be authenticated based on
the MIP-MN-AAA-Auth AVP, which could decide if it is a valid
request for reporting a roaming situation.

Then, should we define a new MIP-MN-AAAF-Auth AVP?, or should every 
registration reach the Home server each time?

Martin

> -----Original Message-----
> From: Fredrik Johansson [mailto:fredrik.johansson@ipunplugged.com]
> Sent: Wednesday, April 18, 2001 1:26 PM
> To: Martin Julien (ECE); pcalhoun@eng.sun.com; Tony Johansson
> Cc: AAA Listan
> Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
> 
> 
> Looks like it would work, the only question is what happens 
> when a second MN
> tries to register with the same Nai, home address and home 
> agent address?
> 
> /Fredrik
> 
> >
> >Ok, let me try again.
> >
> >More than one session need to be supported for each MIP user, which
> >means that a user might want to register several MNs on the
> >network at once.
> >That would lead to several separate MIP sessions in the Home 
> server. AFAIK,
> >each MIP session can be uniquely identified by using both its Home
> >Agent address
> >and its Home address. We could also add the User-Name, to 
> easily link all
> >sessions for a particular user. That means that each MIP 
> session would be
> >keyed on User-Name, Home Agent and Home Address. That takes 
> into account
> >private addresses as well.
> >
> >Then a first MN registers with a User-Name. Since it is the first
> >registration in a foreign domain, then no 
> MIP-Previous-FA-XXXX is present,
> >neither Home Agent nor Home address. Then the FA creates a 
> new Session-ID,
> >which is sent to the AAAF, which forwards it to the Home 
> server, since
> >it is the MN's first registration. Then the MN is registered 
> successfully.
> >
> >Then the MN moves to a new FA within the same domain. The MN 
> will send the
> >User-Name, the Home Agent and Home address, along with the
> >MIP-Previous-FA-XXXX.
> >Then the new FA will send the AMR to the AAAF, which will check if
> >there is
> >any existing session linked to a similar registration, based on the
> >User-Name, the Home Agent and Home address. Since there is, the
> >AAAF returns
> >the Original-Session-ID, along with the FA keys.
> >
> >I guess that the same could apply when the node moves to a 
> third domain, in
> >which case it would be the Home server that would be responsible
> >of returning
> >the Original-Session-ID and FA keys. The same for moving to its
> >Home domain.
> >
> >If there is a second MN that registers for the same user, 
> then it would
> >register without a Home Agent and Home Address. Or if it 
> does, I guess
> >that the Home address should be already defined as unique for that
> >particular MN, right? That means that a new session would be created
> >by the new FA, which would trigger a new session in the Home server.
> >That new session would be uniquely identifiable by the User-Name,
> >the Home Agent and the Home address of the MN.
> >
> >If ever we need to control
> >the number of allowed sessions per user, the Home server can 
> reject the
> >AMR when it receives a new registration request from a new MN.
> >
> >Does that make a bit more sense?
> >
> >Martin
> >
> >> -----Original Message-----
> >> From: Fredrik Johansson [mailto:fredrik.johansson@ipunplugged.com]
> >> Sent: Tuesday, April 17, 2001 4:53 PM
> >> To: Martin Julien (ECE); pcalhoun@eng.sun.com; Tony Johansson
> >> Cc: AAA Listan
> >> Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
> >>
> >>
> >> Hi Martin,
> >>
> >> How would generating a session id from User-Name and
> >> MIP-Previous-FA-XXXX
> >> help you to have several MIP sessions for the same user if the have
> >> different MNs? The user may still use the same User-Name on
> >> all of its MNs,
> >> thus causing the same session id to be created.
> >>
> >> So, I don't believe it will solve the problem. If it is a
> >> problem that you
> >> cannot have several session with the same nai, isn't that 
> one of the
> >> problems with radius that there is no way to limit a user
> >> from login in
> >> from several places at the same time using the same user name
> >> and password?
> >>
> >> /Fredrik
> >>
> >> >
> >> >Hej Fredrik,
> >> >
> >> >If the Session-ID would be generated and handled by the MN, I
> >> >guess it would be a lot easier. At least, we could propose a way
> >> >of generating a Session-ID in the FA, such as the concatenation of
> >> >the User-Name and the Care-Of address (FA), which would lead to a
> >> >predictable Session-ID. In the case where the MN would move to a
> >> >new FA, then the new FA would need to generate a Session-ID based
> >> >on the User-Name and the MIP-Previous-FA-XXXX. Would that make any
> >> >sense? Then, I guess we could have several different MIP sessions
> >> >for the same User, as long as it is using different MNs. To
> >> >support more than one session per MN, I guess the MN would need to
> >> >include additional info about that.
> >> >
> >> >We are having the same kind of problems WRT SIP, I believe.
> >> >
> >> >Martin
> >> >
> >> >> -----Original Message-----
> >> >> From: Fredrik Johansson 
> [mailto:fredrik.johansson@ipunplugged.com]
> >> >> Sent: Tuesday, April 17, 2001 3:01 PM
> >> >> To: pcalhoun@eng.sun.com; Martin Julien (ECE); Tony Johansson
> >> >> Cc: AAA Listan
> >> >> Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
> >> >>
> >> >>
> >> >> Ok, let's see if I can write the entire message this time
> >> >> before sending it
> >> >> :-)
> >> >> There might be a problem with the possiblity to reuse the old
> >> >> session id,
> >> >> and
> >> >> that is that there can only be one session per user. I don't
> >> >> know if this
> >> >> limitation
> >> >> is to harsh.
> >> >>
> >> >> /Fredrik
> >> >>
> >> >> 11.7  Session Movement
> >> >>
> >> >>    When a user moves between different access devices it may
> >> >> be desirable
> >> >>    to keep the Session Id unchanged. It is therefore 
> possible for a
> >> >>    server to send the original Session Id back to the 
> client in the
> >> >>    Original-Session-Id AVP. An old session is identified by
> >> >> the User Name
> >> >>    Nai.
> >> >>
> >> >> 11.7.1  Original-Session-Id AVP
> >> >>
> >> >>    The Original-Session-Id AVP (AVP Code 261) is of type
> >> >> OctetString and
> >> >>    MAY be sent in a message of type Response or Answer 
> if the AAA
> >> >>    server already has a session identifier for the user,
> >> and wishes to
> >> >>    keep the existing Session-Id. All further messages from
> >> the Access
> >> >>    Device for this session MUST use the session identifier in
> >> >> this AVP.
> >> >>    This shouldn't be viewed as a new session, but rather
> >> renaming the
> >> >>    old session. Any message not using the Session Id in this
> >> >> AVP will be
> >> >>    treated as an unrecognized Session Id.
> >> >>
> >> >> 11.8  Session Termination
> >> >>
> >> >>    The Diameter Base Protocol provides a set of messages
> >> that MUST be
> >> >>    used by any peer to explicitly request that a previously
> >> >>    authenticated and/or authorized session be 
> terminated. Since the
> >> >>    Session-Id is typically tied to a particular service (i.e.
> >> >> Mobile IP,
> >> >>    NASREQ, etc), the session termination messages are used
> >> to request
> >> >>    that the service tied to the Session Id be terminated.
> >> >>
> >> >>
> >> >>
> >> >> >>-----Original Message-----
> >> >> >>From: owner-aaa-bof@merit.edu
> >> >> [mailto:owner-aaa-bof@merit.edu]On Behalf
> >> >> >>Of Fredrik Johansson
> >> >> >>Sent: den 12 april 2001 10:04
> >> >> >>To: pcalhoun@eng.sun.com; Martin Julien (ECE); Tony Johansson
> >> >> >>Cc: AAA Listan
> >> >> >>Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
> >> >> >>
> >> >> >>
> >> >> >>No, no additional AVPs is required. However, I believe some
> >> >> explanations
> >> >> >>should be provided on how to treat the  request in
> >> >> different nodes. I'll
> >> >> >>give you some text after the weekend that hopefully 
> will give you
> >> >> >>some ideas
> >> >> >>what I mean. Untill then I will enjoy a couple of 
> days skiing :-)
> >> >> >>
> >> >> >>/Fredrik
> >> >> >>
> >> >> >>>-----Original Message-----
> >> >> >>>From: owner-aaa-bof@merit.edu
> >> >> [mailto:owner-aaa-bof@merit.edu]On Behalf
> >> >> >>>Of Patrice Calhoun
> >> >> >>>Sent: den 11 april 2001 19:32
> >> >> >>>To: Fredrik Johansson; Martin Julien (ECE); Tony Johansson
> >> >> >>>Cc: AAA Listan
> >> >> >>>Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
> >> >> >>>
> >> >> >>>
> >> >> >>>and no additional protocol text (read AVPs) is required???
> >> >> >>>
> >> >> >>>PatC
> >> >> >>>>>
> >> >> >>>>>Just to make sure, I *presume* that this proposed 
> text is to
> >> >> >>>belong in the
> >> >> >>>>>Mobile IP extension, right?
> >> >> >>>>
> >> >> >>>>Yes, that's correct
> >> >> >>>>
> >> >> >>>>/Fredrik
> >> >> >>>>
> >> >> >>>>>
> >> >> >>>>>PatC
> >> >> >>>>>
> >> >> >>>>>ps: for those that saw my "I will not be responding to
> >> >> e-mail this
> >> >> >>>>>week", I
> >> >> >>>>>happen to be in a city that has metricom service :)
> >> >> >>>>>
> >> >> >>>>>>Cool! I was about to send you something very 
> similar to know
> >> >> >>>>>>if it was what you meant in your previous mail.
> >> >> >>>>>>I agree with your solution. Thanks!
> >> >> >>>>>>
> >> >> >>>>>>> -----Original Message-----
> >> >> >>>>>>> From: Fredrik Johansson
> >> >> [mailto:fredrik.johansson@ipunplugged.com]
> >> >> >>>>>>> Sent: Tuesday, April 10, 2001 10:27 AM
> >> >> >>>>>>> To: Martin Julien (ECE); Tony Johansson
> >> >> >>>>>>> Cc: 'Patrice Calhoun'; AAA Listan
> >> >> >>>>>>> Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
> >> >> >>>>>>>
> >> >> >>>>>>>
> >> >> >>>>>>> After a closer look at the problem we have a
> >> suggestion on a
> >> >> >>solution.
> >> >> >>>>>>> If the AAAH always assigns a SPI that is unique in
> >> the HA for
> >> >> >>>>>>> the FA-HA key,
> >> >> >>>>>>> and a SPI that is unique in the Mn for the MN-FA and
> >> >> MN-HA keys, the
> >> >> >>>>>>> security contexts will automatically be unique 
> in every SA.
> >> >> >>>>>>>
> >> >> >>>>>>> 7.5 SPI Allocation
> >> >> >>>>>>>   To ensure that the SPI is unique for each 
> pair of nodes,
> >> >> >>>>>>>   the AAAH SHOULD keep track of assigned SPIs per
> >> HA and MN.
> >> >> >>>>>>>   The SPI assigned to the MN-FA key MUST be 
> allocated from
> >> >> >>>>>>> the MN SPI pool,
> >> >> >>>>>>>   the SPI for the FA-HA key MUST be allocated from
> >> the HA SPI
> >> >> >>>>>>> pool, and the
> >> >> >>>>>>>   SPI for the MN-HA key MUST be allocated from 
> the MN SPI
> >> >> >>>>>>> pool. Note that
> >> >> >>>>>>>   SPI values 0 through 255 are reserved and MUST NOT
> >> >> be used in any
> >> >> >>>>>>>   Mobility Security Association.
> >> >> >>>>>>>
> >> >> >>>>>>> /Fredrik
> >> >> >>>>>>> >-----Original Message-----
> >> >> >>>>>>> >From: owner-aaa-bof@merit.edu
> >> >> >>>>>>> [mailto:owner-aaa-bof@merit.edu]On Behalf
> >> >> >>>>>>> >Of Fredrik Johansson
> >> >> >>>>>>> >Sent: den 10 april 2001 08:40
> >> >> >>>>>>> >To: Martin Julien (ECE); Tony Johansson
> >> >> >>>>>>> >Cc: 'Patrice Calhoun'; AAA Listan
> >> >> >>>>>>> >Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
> >> >> >>>>>>> >
> >> >> >>>>>>> >
> >> >> >>>>>>> >>
> >> >> >>>>>>> >>> >>
> >> >> >>>>>>> >>> >> Another thing that needs some clarification,
> >> >> if there is a
> >> >> >>>>>>> >>> solution. How
> >> >> >>>>>>> >>> >> will the HA know which SA to use. In the case
> >> >> where a mobile
> >> >> >>>>>>> >>> >moves from one
> >> >> >>>>>>> >>> >> Fa to another under the same administrative
> >> >> domain it may
> >> >> >>>>>>> >>> receive the
> >> >> >>>>>>> >>> >> session keys for the old Fa from the 
> AAAF. It will
> >> >> >>then proceed
> >> >> >>>>>>> >>> >to send the
> >> >> >>>>>>> >>> >> mip reg req to the HA. The HA will see that
> >> >> the message came
> >> >> >>>>>>> >>> >from the new FA
> >> >> >>>>>>> >>> >> and try to locate the SA shared with that FA. It
> >> >> >will not find
> >> >> >>>>>>> >>> >it since it
> >> >> >>>>>>> >>> >> was established with the old FA. Eventhough
> >> >> the HA can see
> >> >> >>>>>>> >>> the address of
> >> >> >>>>>>> >>> >> the old Fa in the previous-fa-XXXX it is 
> not clear
> >> >> >that it can
> >> >> >>>>>>> >>> >establish a
> >> >> >>>>>>> >>> >> SA with the new Fa because it has to use
> >> the same SPI
> >> >> >>as before
> >> >> >>>>>>> >>> >and that one
> >> >> >>>>>>> >>> >> might be busy. Or have I missed something here?
> >> >> >>>>>>> >>> >
> >> >> >>>>>>> >>> >You also have the user NAI in the MIP registration
> >> >> >>>>>>> request sent to
> >> >> >>>>>>> >>> >the HA and
> >> >> >>>>>>> >>> >the user NAI is globally unique....
> >> >> >>>>>>> >>>
> >> >> >>>>>>> >>> Yes, but this is not the security association
> >> >> shared with the
> >> >> >>>>>>> >>> mobile node
> >> >> >>>>>>> >>> but the one shared between the FA and HA, thus
> >> >> has nothing to
> >> >> >>>>>>> >>> do with the
> >> >> >>>>>>> >>> user.
> >> >> >>>>>>> >>
> >> >> >>>>>>> >>I think you are assuming that there exists only
> >> 1 mobility
> >> >> >>>>>>> SA between
> >> >> >>>>>>> >>a FA and a HA for all the MIP sessions, right?
> >> >> >>>>>>> >
> >> >> >>>>>>> >YES, one mobility SA, ceveral security context
> >> >> within a mobility
> >> >> >>>>>>> >SA. See rfc
> >> >> >>>>>>> >2002,
> >> >> >>>>>>> >
> >> >> >>>>>>> >"Mobility Security Association
> >> >> >>>>>>> >               A collection of security contexts,
> >> >> between a pair
> >> >> >>>>>>> >               of nodes, which may be applied to
> >> >> Mobile IP protocol
> >> >> >>>>>>> >               messages exchanged between them.  Each
> >> >> >>>>>>> context indicates
> >> >> >>>>>>> >               an authentication algorithm and mode
> >> >> >(Section 5.1), a
> >> >> >>>>>>> >               secret (a shared key, or appropriate
> >> >> public/private
> >> >> >>>>>>> >               key pair), and a style of replay
> >> >> protection in use
> >> >> >>>>>>> >               (Section 5.6)."
> >> >> >>>>>>> >
> >> >> >>>>>>> >Each context is indexed with a unique SPI within
> >> that SA, if
> >> >> >>>>>>> there exist a
> >> >> >>>>>>> >SA between the HA and the old FA and one SA 
> between the HA
> >> >> >>>>>>> and the new FA
> >> >> >>>>>>> >there might exist security context with the same
> >> SPI in both
> >> >> >>>>>>> of these.
> >> >> >>>>>>> >
> >> >> >>>>>>> >"Security Parameter Index (SPI)
> >> >> >>>>>>> >               An index identifying a security context
> >> >> >>between a pair
> >> >> >>>>>>> >               of nodes among the contexts available in
> >> >> >the Mobility
> >> >> >>>>>>> >               Security Association.  SPI values 0
> >> >> through 255 are
> >> >> >>>>>>> >               reserved and MUST NOT be used in any
> >> >> >>Mobility Security
> >> >> >>>>>>> >               Association."
> >> >> >>>>>>> >
> >> >> >>>>>>> >>When a first AMA is received
> >> >> >>>>>>> >
> >> >> >>>>>>> >I guess you mean AMR :-)
> >> >> >>>>>>> >
> >> >> >>>>>>> >>in the AAAH from a MN, is the AAAH supposed to
> >> issue a new
> >> >> >>>>>>> registration
> >> >> >>>>>>> >>FA-HA key, in the case the HA is in the home 
> domain? The
> >> >> >>>>>>> spec says "yes",
> >> >> >>>>>>> >>if it is required by the MN. However, how can 
> the MN know
> >> >> >about the
> >> >> >>>>>>> >>mobility SA between the FA and the HA? I guess
> >> it can not,
> >> >> >>>>>>> which means
> >> >> >>>>>>> >>that it will ask for a new key, which should be
> >> transferred
> >> >> >>>>>>> to the FA and
> >> >> >>>>>>> >>the HA from the AAAH. Is there a way for the HA to
> >> >> notify the AAAH
> >> >> >>>>>>> >>that it does not need
> >> >> >>>>>>> >>a new key and a new SPI for its mobility SA with
> >> >> the FA, since it
> >> >> >>>>>>> >>already has one? I guess
> >> >> >>>>>>> >>not, right? Then, it looks like your idea 
> could be very
> >> >> >>>>>>> interesting, but
> >> >> >>>>>>> >>I don't know how to deal with it using Diameter,
> >> unless the
> >> >> >>>>>>> AAAH and AAAF
> >> >> >>>>>>> >>would keep a list of mobility SAs between 
> each FA and HA.
> >> >> >>>>>>> >
> >> >> >>>>>>> >In some way the AAAH must keep track of what 
> SPIs it has
> >> >> >>>>>>> assigned to the
> >> >> >>>>>>> >home agent, if it does it per SA or make the SPI
> >> >> unique over all
> >> >> >>>>>>> >SA's in the
> >> >> >>>>>>> >HA is up to the implementation
> >> >> >>>>>>> >
> >> >> >>>>>>> >>
> >> >> >>>>>>> >>> You can not guarantee that a security between
> >> the HA and
> >> >> >>>>>>> the old FA is
> >> >> >>>>>>> >>> unique between the HA and the new FA. The same
> >> SPI must be
> >> >> >>>>>>> >>> used in the first
> >> >> >>>>>>> >>> request in order for the HA to be able to
> >> >> distinguise between
> >> >> >>>>>>> >>> different
> >> >> >>>>>>> >>> security contexts it shares with the FA. What we
> >> >> can do is to
> >> >> >>>>>>> >>> have the new
> >> >> >>>>>>> >>> FA add a <MIP-Preferred-SPI Ext> in the first
> >> request from
> >> >> >>>>>>> >>> the new FA to the
> >> >> >>>>>>> >>> HA, the HA can then use the <Previous-FA-XXXX
> >> >> Ext> together
> >> >> >>>>>>> >>> with the old SPI
> >> >> >>>>>>> >>> to retreive the context and store it under the
> >> >> Preferred SPI
> >> >> >>>>>>> >>> under the SA
> >> >> >>>>>>> >>> with the new FA.
> >> >> >>>>>>> >>
> >> >> >>>>>>> >>I was wondering whether or not a mobility SA 
> between a FA
> >> >> >>>>>>> >>and a HA was based on a particular MIP session? My
> >> >> understanding
> >> >> >>>>>>> >>_IS_ that an existing SA is based on a MIP session.
> >> >> That means
> >> >> >>>>>>> >>that between a FA and a HA, there exists several
> >> >> mobility SAs
> >> >> >>>>>>> >>depending on each MIP session.
> >> >> >>>>>>> >
> >> >> >>>>>>> >No, there is only one SA between two nodes, 
> but there are
> >> >> >>>>>>> several security
> >> >> >>>>>>> >context within each SA. Each security context can
> >> >> >>>>>>> corresponde to a mip
> >> >> >>>>>>> >session. It is the security context that has a
> >> lifetime, the
> >> >> >>>>>>> SA can be
> >> >> >>>>>>> >removed when the last security context is removed.
> >> >> >>>>>>> >
> >> >> >>>>>>> >>By MIP session, I mean an AAA
> >> >> >>>>>>> >>authorized session for MIP. The SPI is already
> >> >> included in the
> >> >> >>>>>>> >>key transferred between the AAAF and the new FA.
> >> I don't see
> >> >> >>>>>>> >>why a HA could not use the SPI stored under its
> >> MN User-Name
> >> >> >>>>>>> >>state to retrieve the mobility SA between the new
> >> >> FA and itself?
> >> >> >>>>>>> >
> >> >> >>>>>>> >Because the SA between the FA and HA does not realy
> >> >> have anything
> >> >> >>>>>>> >to do with
> >> >> >>>>>>> >the Mn. It is something setup between the FA 
> and HA. Thus
> >> >> >>>>>>> when the HA will
> >> >> >>>>>>> >look for the key to use it will do the lookup on the
> >> >> FA address.
> >> >> >>>>>>> >
> >> >> >>>>>>> >/Fredrik
> >> >> >>>>>>> >
> >> >> >>>>>>> >>
> >> >> >>>>>>> >>Regards,
> >> >> >>>>>>> >>Martin
> >> >> >>>>>>> >
> >> >> >>>>>>>
> >> >> >>>>>
> >> >> >>>>>
> >> >> >>>
> >> >> >>>
> >> >> >>
> >> >> >
> >> >>
> >>
> 



From owner-aaa-bof@merit.edu  Wed Apr 18 12:20:24 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13745
	for <aaa-archive@odin.ietf.org>; Wed, 18 Apr 2001 12:20:23 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id D88365DEC6; Wed, 18 Apr 2001 12:14:16 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id B36065DF08; Wed, 18 Apr 2001 12:14:16 -0400 (EDT)
Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152])
	by segue.merit.edu (Postfix) with ESMTP id 9A2565DEC6
	for <aaa-wg@merit.edu>; Wed, 18 Apr 2001 12:13:31 -0400 (EDT)
Received: from mira-sjcm-3.cisco.com (mira-sjcm-3.cisco.com [171.69.43.101])
	by sj-msg-core-3.cisco.com (8.9.3/8.9.1) with ESMTP id JAA08020;
	Wed, 18 Apr 2001 09:12:09 -0700 (PDT)
Received: from johnalw2k (dhcp-161-44-29-177.cisco.com [161.44.29.177])
	by mira-sjcm-3.cisco.com (Mirapoint)
	with SMTP id ACM00087;
	Wed, 18 Apr 2001 09:13:28 -0700 (PDT)
From: "John Alayari" <johnal@cisco.com>
To: "Jari Arkko" <Jari.Arkko@lmf.ericsson.se>, <aaa-wg@merit.edu>
Subject: RE: [AAA-WG]: separated authorization and accounting servers? (resend, sorry if you  get this 	 twice...)
Date: Wed, 18 Apr 2001 09:12:28 -0700
Message-ID: <CNEGKCBENOKKPJPNCEODKEJECCAA.johnal@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-reply-to: <3ADD53C7.D9206765@lmf.ericsson.se>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Jari,
I totally agree. The base spec should allow separation of
Authentication/Authorization from Accounting on both client and server side.
And section 13.1 should be reworded to support this. Let me give an example
that shows why we need that:

In the following example, client 1 is the session controller (e.g. SIP
server) and
the client 2 is bearer of data. Please note that, there may be multiple
nodes acting as client for the same session. Server 1 does the
authorization/and authentication function and server 2 does the accounting
only.

The authorization-server directed model here mean that the accounting
policies(accounting records timeliness, etc.) in server 1 are transferred to
client 2 in step 4. and that is communicated to server 2 in step 5.



            ------                   ------
1)Orig Msg |Client|  2)Access Req.  |Server|
 --------->|  1   |---------------->|  1   |
           |      |<----------------|      |
            ------   3)Access Resp.   ------
              |
              | 4) Access/Auth-indication
              |
              V
            ------                   ------
6)Data     |Client| 5)Acct Req.     |Server|
<--------->|  2   |---------------->|  2   |
           |      |<----------------|      |
            ------  6)Acct Resp.     ------

John.

-----Original Message-----
From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf
Of Jari Arkko
Sent: Wednesday, April 18, 2001 1:44 AM
To: aaa-wg@merit.edu
Subject: [AAA-WG]: separated authorization and accounting servers?
(resend, sorry if you get this twice...)



Hello,

We've been trying to figure out if the current
version of the Diameter specs allow accounting
and other traffic to be directed to different
servers. Traditionally, we've had this feature
in RADIUS. It might even be conceivable that there
be uses of accounting where there is no authentication
or authorization at all on a node that gives a service.

But can we do this? We haven't figured out if the
specifications say anything about this. Section 13.1
talks about authorization server directed model, but
I would classify the "direction" as optional information.
Section 13.2 says servers that receive a succesfull
authentication response must collect accounting information.
But must they send it too? And can there be other nodes
that would not perform authentication/authorization but
who still produce accounting information (e.g. for
trend analysis purposes)? Section 11 talks about user
sessions and their life-cycle. But it doesn't seem to
state anything about this issue in particular.

Do we allow two proxies to be configured for a client
node, one for the authentication and authorization, and
the second one for accounting?

And whatever we say, why are we saying so?

Jari




From owner-aaa-bof@merit.edu  Wed Apr 18 12:25:26 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13817
	for <aaa-archive@odin.ietf.org>; Wed, 18 Apr 2001 12:25:26 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id E98EF5DDD6; Wed, 18 Apr 2001 11:41:59 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id D76475DDA7; Wed, 18 Apr 2001 11:41:59 -0400 (EDT)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id 373515DD9B
	for <aaa-wg@merit.edu>; Wed, 18 Apr 2001 11:41:58 -0400 (EDT)
Received: from heliopolis.eng.sun.com ([152.70.1.39])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id IAA16957;
	Wed, 18 Apr 2001 08:41:54 -0700 (PDT)
Received: from srmtv29a (srmtv29a [152.70.1.41])
	by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id IAA12410;
	Wed, 18 Apr 2001 08:41:51 -0700 (PDT)
Message-Id: <200104181541.IAA12410@heliopolis.eng.sun.com>
Date: Wed, 18 Apr 2001 08:41:51 -0700 (PDT)
From: James Kempf <James.Kempf@Sun.COM>
Reply-To: James Kempf <James.Kempf@Sun.COM>
Subject: Re: [AAA-WG]: separated authorization and accounting servers? (resend, sorry if you  get this   twice...)
To: aaa-wg@merit.edu, Jari.Arkko@lmf.ericsson.se
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: FYfX3E8r4ByIaGx6C7pF6w==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Jari,

Certainly in the API there is support for a client to have multiple
sessions open with different servers. This would allow accounting
transactions with a different server than authorization.

		jak

>Delivered-To: aaa-wg-outgoing@merit.edu
>Date: Wed, 18 Apr 2001 11:43:51 +0300
>From: Jari Arkko <Jari.Arkko@lmf.ericsson.se>
>To: aaa-wg@merit.edu
>Subject: [AAA-WG]: separated authorization and accounting servers? (resend, 
sorry if you  get this twice...)
>
>
>Hello,
>
>We've been trying to figure out if the current
>version of the Diameter specs allow accounting
>and other traffic to be directed to different
>servers. Traditionally, we've had this feature
>in RADIUS. It might even be conceivable that there
>be uses of accounting where there is no authentication
>or authorization at all on a node that gives a service.
>
>But can we do this? We haven't figured out if the
>specifications say anything about this. Section 13.1
>talks about authorization server directed model, but
>I would classify the "direction" as optional information.
>Section 13.2 says servers that receive a succesfull
>authentication response must collect accounting information.
>But must they send it too? And can there be other nodes
>that would not perform authentication/authorization but
>who still produce accounting information (e.g. for
>trend analysis purposes)? Section 11 talks about user
>sessions and their life-cycle. But it doesn't seem to
>state anything about this issue in particular.
>
>Do we allow two proxies to be configured for a client
>node, one for the authentication and authorization, and
>the second one for accounting?
>
>And whatever we say, why are we saying so?
>
>Jari
>




From owner-aaa-bof@merit.edu  Wed Apr 18 17:45:17 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA18472
	for <aaa-archive@odin.ietf.org>; Wed, 18 Apr 2001 17:45:17 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 4F3E75DE56; Wed, 18 Apr 2001 11:34:18 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 3B9EC5DE54; Wed, 18 Apr 2001 11:34:18 -0400 (EDT)
Received: from motgate4.mot.com (motgate4.mot.com [144.189.100.102])
	by segue.merit.edu (Postfix) with ESMTP id 763205DE3A
	for <aaa-wg@merit.edu>; Wed, 18 Apr 2001 11:34:16 -0400 (EDT)
Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate4.mot.com (motgate4 2.1) with ESMTP id IAA27700 for <aaa-wg@merit.edu>; Wed, 18 Apr 2001 08:34:15 -0700 (MST)]
Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id IAA25880 for <aaa-wg@merit.edu>; Wed, 18 Apr 2001 08:34:15 -0700 (MST)]
Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2653.19)
	id <JAVA27PM>; Wed, 18 Apr 2001 10:34:15 -0500
Message-ID: <35DBB8B7AC89D4118E98009027B1009B0ECE82@IL27EXM10.cig.mot.com>
From: Cain Brian-BCAIN1 <Brian.Cain@motorola.com>
To: "'James Kempf'" <James.Kempf@sun.com>, aaa-wg@merit.edu
Subject: RE: [AAA-WG]: New API Draft -- Initial impression (addendum)
Date: Wed, 18 Apr 2001 10:34:09 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Oops.  I sent that last message prematurely.  Here's an addendum.

>From AVPDescriptor (4.3.3.5):
>-      public boolean isEndToEndEncrypted()
>+      public boolean isEndToEndEncryptable()
>
>-   Return true if this AVP is encrypted end-to-end.
>+   Returns true if this AVP may be encrypted end-to-end.
>

This change is in reference to the "MAY Encr" column in section 4.5 of the base protocol.

The above change would also require the following change to AVP:

>4.3.2.4 Instance Methods
>
+      public boolean isEndToEndEncrypted()
+
+   Returns true if this AVP is encrypted end-to-end.
+
>      public AVPDescriptor getDescriptor()
>
>   Return the AVP's descriptor.

(and possibly the following change)

>4.3.2.3 Constructor
>
>      public AVP(AVPDescriptor descriptor,
+                 boolean encryptedPayload,
>                 java.lang.Object data)
>
>   Create a new AVP object.
>
>   Parameters are:
>
>      descriptor - An AVPDescriptor object describing the AVP.
>
+      encryptedPayload - True if the data is/will be encrypted (this sets the AVP header's 'P' flag).

For outgoing messages, the API's users will want to know whether or not it's legal for them to encrypt their data, so the descriptor that they get back from the dictionary should have this information.  For incoming messages (and for the API to be able to construct proper outgoing messages), the API's users will want to know whether the data sent was actually encrypted.

-Brian



From owner-aaa-bof@merit.edu  Thu Apr 19 03:19:49 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA08142
	for <aaa-archive@odin.ietf.org>; Thu, 19 Apr 2001 03:19:49 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 091FF5DDA9; Thu, 19 Apr 2001 03:17:02 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id BBBB15DD91; Thu, 19 Apr 2001 03:17:01 -0400 (EDT)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by segue.merit.edu (Postfix) with ESMTP id DF9485DDA9
	for <aaa-wg@merit.edu>; Thu, 19 Apr 2001 03:16:43 -0400 (EDT)
Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f3J7GfO02051
	for <aaa-wg@merit.edu>; Thu, 19 Apr 2001 09:16:41 +0200 (MEST)
Received: FROM esealnt743.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Thu Apr 19 09:16:40 2001 +0200
Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <HA3DKVKT>; Thu, 19 Apr 2001 09:16:39 +0200
Message-ID: <577066326047D41180AC00508B955DDA01D7FF8C@eestqnt104.es.eu.ericsson.se>
From: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>
To: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>,
        "'Fredrik Johansson'" <fredrik.johansson@ipunplugged.com>,
        "'pcalhoun@eng.sun.com'" <pcalhoun@eng.sun.com>,
        "'Tony Johansson'" <tony.johansson@ericsson.com>
Cc: "'AAA Listan'" <aaa-wg@merit.edu>
Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
Date: Thu, 19 Apr 2001 09:16:36 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Hi Fredrik,

I realized that in my previous e-mail, I had diverged from my original thoughts while writing it, which seems now to be a better understanding of the problem than my previous suggestion.

So the question was: "What happens when a second MN tries to register with the same Nai, home address and home agent address?"

If the other MN registers within the same foreign network, I would say that the MN would reach the AAAF, which would return the FA-MN and FA-HA keys to the new FA. That security issue should be left to the configuration of the AAAF to trust or not the new FA. Then, the new FA would forward the registration request to the HA, which would fail, since the MN does not have the good MN-HA key. So my question is now: "What should the HA do when it rejects a registration?" For sure, it should not cancel the registration until a proper de-registration is ordered by the MN, or the absence of re-registration at the specified period of time.

If the registration occurs in a different (3rd) domain, then the keys are returned by the Home server, and the same process occurs.

I'm not sure, but at the first glance, it seems that the HA remains the only one, with the AAAH, controlling if the MN is legitimate or not.

Martin

> -----Original Message-----
> From: Martin Julien (ECE) 
> Sent: Wednesday, April 18, 2001 2:52 PM
> To: 'Fredrik Johansson'; Martin Julien (ECE); 
> pcalhoun@eng.sun.com; Tony
> Johansson
> Cc: AAA Listan
> Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
> 
> 
> In the case where the MN is roaming within a foreign domain,
> a Registration is sent and an AMR is be sent to the AAAF. Then the
> AAAF returns the keys to the new FA without authenticating
> the MN. That seems to be a "problem". However, if it would reach 
> the Home server, then the MN could be authenticated based on
> the MIP-MN-AAA-Auth AVP, which could decide if it is a valid
> request for reporting a roaming situation.
> 
> Then, should we define a new MIP-MN-AAAF-Auth AVP?, or should every 
> registration reach the Home server each time?
> 
> Martin
> 
> > -----Original Message-----
> > From: Fredrik Johansson [mailto:fredrik.johansson@ipunplugged.com]
> > Sent: Wednesday, April 18, 2001 1:26 PM
> > To: Martin Julien (ECE); pcalhoun@eng.sun.com; Tony Johansson
> > Cc: AAA Listan
> > Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
> > 
> > 
> > Looks like it would work, the only question is what happens 
> > when a second MN
> > tries to register with the same Nai, home address and home 
> > agent address?
> > 
> > /Fredrik
> > 
> > >
> > >Ok, let me try again.
> > >
> > >More than one session need to be supported for each MIP user, which
> > >means that a user might want to register several MNs on the
> > >network at once.
> > >That would lead to several separate MIP sessions in the Home 
> > server. AFAIK,
> > >each MIP session can be uniquely identified by using both its Home
> > >Agent address
> > >and its Home address. We could also add the User-Name, to 
> > easily link all
> > >sessions for a particular user. That means that each MIP 
> > session would be
> > >keyed on User-Name, Home Agent and Home Address. That takes 
> > into account
> > >private addresses as well.
> > >
> > >Then a first MN registers with a User-Name. Since it is the first
> > >registration in a foreign domain, then no 
> > MIP-Previous-FA-XXXX is present,
> > >neither Home Agent nor Home address. Then the FA creates a 
> > new Session-ID,
> > >which is sent to the AAAF, which forwards it to the Home 
> > server, since
> > >it is the MN's first registration. Then the MN is registered 
> > successfully.
> > >
> > >Then the MN moves to a new FA within the same domain. The MN 
> > will send the
> > >User-Name, the Home Agent and Home address, along with the
> > >MIP-Previous-FA-XXXX.
> > >Then the new FA will send the AMR to the AAAF, which will check if
> > >there is
> > >any existing session linked to a similar registration, based on the
> > >User-Name, the Home Agent and Home address. Since there is, the
> > >AAAF returns
> > >the Original-Session-ID, along with the FA keys.
> > >
> > >I guess that the same could apply when the node moves to a 
> > third domain, in
> > >which case it would be the Home server that would be responsible
> > >of returning
> > >the Original-Session-ID and FA keys. The same for moving to its
> > >Home domain.
> > >
> > >If there is a second MN that registers for the same user, 
> > then it would
> > >register without a Home Agent and Home Address. Or if it 
> > does, I guess
> > >that the Home address should be already defined as unique for that
> > >particular MN, right? That means that a new session would 
> be created
> > >by the new FA, which would trigger a new session in the 
> Home server.
> > >That new session would be uniquely identifiable by the User-Name,
> > >the Home Agent and the Home address of the MN.
> > >
> > >If ever we need to control
> > >the number of allowed sessions per user, the Home server can 
> > reject the
> > >AMR when it receives a new registration request from a new MN.
> > >
> > >Does that make a bit more sense?
> > >
> > >Martin
> > >
> > >> -----Original Message-----
> > >> From: Fredrik Johansson 
> [mailto:fredrik.johansson@ipunplugged.com]
> > >> Sent: Tuesday, April 17, 2001 4:53 PM
> > >> To: Martin Julien (ECE); pcalhoun@eng.sun.com; Tony Johansson
> > >> Cc: AAA Listan
> > >> Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
> > >>
> > >>
> > >> Hi Martin,
> > >>
> > >> How would generating a session id from User-Name and
> > >> MIP-Previous-FA-XXXX
> > >> help you to have several MIP sessions for the same user 
> if the have
> > >> different MNs? The user may still use the same User-Name on
> > >> all of its MNs,
> > >> thus causing the same session id to be created.
> > >>
> > >> So, I don't believe it will solve the problem. If it is a
> > >> problem that you
> > >> cannot have several session with the same nai, isn't that 
> > one of the
> > >> problems with radius that there is no way to limit a user
> > >> from login in
> > >> from several places at the same time using the same user name
> > >> and password?
> > >>
> > >> /Fredrik
> > >>
> > >> >
> > >> >Hej Fredrik,
> > >> >
> > >> >If the Session-ID would be generated and handled by the MN, I
> > >> >guess it would be a lot easier. At least, we could propose a way
> > >> >of generating a Session-ID in the FA, such as the 
> concatenation of
> > >> >the User-Name and the Care-Of address (FA), which would 
> lead to a
> > >> >predictable Session-ID. In the case where the MN would move to a
> > >> >new FA, then the new FA would need to generate a 
> Session-ID based
> > >> >on the User-Name and the MIP-Previous-FA-XXXX. Would 
> that make any
> > >> >sense? Then, I guess we could have several different 
> MIP sessions
> > >> >for the same User, as long as it is using different MNs. To
> > >> >support more than one session per MN, I guess the MN 
> would need to
> > >> >include additional info about that.
> > >> >
> > >> >We are having the same kind of problems WRT SIP, I believe.
> > >> >
> > >> >Martin
> > >> >
> > >> >> -----Original Message-----
> > >> >> From: Fredrik Johansson 
> > [mailto:fredrik.johansson@ipunplugged.com]
> > >> >> Sent: Tuesday, April 17, 2001 3:01 PM
> > >> >> To: pcalhoun@eng.sun.com; Martin Julien (ECE); Tony Johansson
> > >> >> Cc: AAA Listan
> > >> >> Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
> > >> >>
> > >> >>
> > >> >> Ok, let's see if I can write the entire message this time
> > >> >> before sending it
> > >> >> :-)
> > >> >> There might be a problem with the possiblity to reuse the old
> > >> >> session id,
> > >> >> and
> > >> >> that is that there can only be one session per user. I don't
> > >> >> know if this
> > >> >> limitation
> > >> >> is to harsh.
> > >> >>
> > >> >> /Fredrik
> > >> >>
> > >> >> 11.7  Session Movement
> > >> >>
> > >> >>    When a user moves between different access devices it may
> > >> >> be desirable
> > >> >>    to keep the Session Id unchanged. It is therefore 
> > possible for a
> > >> >>    server to send the original Session Id back to the 
> > client in the
> > >> >>    Original-Session-Id AVP. An old session is identified by
> > >> >> the User Name
> > >> >>    Nai.
> > >> >>
> > >> >> 11.7.1  Original-Session-Id AVP
> > >> >>
> > >> >>    The Original-Session-Id AVP (AVP Code 261) is of type
> > >> >> OctetString and
> > >> >>    MAY be sent in a message of type Response or Answer 
> > if the AAA
> > >> >>    server already has a session identifier for the user,
> > >> and wishes to
> > >> >>    keep the existing Session-Id. All further messages from
> > >> the Access
> > >> >>    Device for this session MUST use the session identifier in
> > >> >> this AVP.
> > >> >>    This shouldn't be viewed as a new session, but rather
> > >> renaming the
> > >> >>    old session. Any message not using the Session Id in this
> > >> >> AVP will be
> > >> >>    treated as an unrecognized Session Id.
> > >> >>
> > >> >> 11.8  Session Termination
> > >> >>
> > >> >>    The Diameter Base Protocol provides a set of messages
> > >> that MUST be
> > >> >>    used by any peer to explicitly request that a previously
> > >> >>    authenticated and/or authorized session be 
> > terminated. Since the
> > >> >>    Session-Id is typically tied to a particular service (i.e.
> > >> >> Mobile IP,
> > >> >>    NASREQ, etc), the session termination messages are used
> > >> to request
> > >> >>    that the service tied to the Session Id be terminated.
> > >> >>
> > >> >>
> > >> >>
> > >> >> >>-----Original Message-----
> > >> >> >>From: owner-aaa-bof@merit.edu
> > >> >> [mailto:owner-aaa-bof@merit.edu]On Behalf
> > >> >> >>Of Fredrik Johansson
> > >> >> >>Sent: den 12 april 2001 10:04
> > >> >> >>To: pcalhoun@eng.sun.com; Martin Julien (ECE); Tony 
> Johansson
> > >> >> >>Cc: AAA Listan
> > >> >> >>Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
> > >> >> >>
> > >> >> >>
> > >> >> >>No, no additional AVPs is required. However, I believe some
> > >> >> explanations
> > >> >> >>should be provided on how to treat the  request in
> > >> >> different nodes. I'll
> > >> >> >>give you some text after the weekend that hopefully 
> > will give you
> > >> >> >>some ideas
> > >> >> >>what I mean. Untill then I will enjoy a couple of 
> > days skiing :-)
> > >> >> >>
> > >> >> >>/Fredrik
> > >> >> >>
> > >> >> >>>-----Original Message-----
> > >> >> >>>From: owner-aaa-bof@merit.edu
> > >> >> [mailto:owner-aaa-bof@merit.edu]On Behalf
> > >> >> >>>Of Patrice Calhoun
> > >> >> >>>Sent: den 11 april 2001 19:32
> > >> >> >>>To: Fredrik Johansson; Martin Julien (ECE); Tony Johansson
> > >> >> >>>Cc: AAA Listan
> > >> >> >>>Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
> > >> >> >>>
> > >> >> >>>
> > >> >> >>>and no additional protocol text (read AVPs) is required???
> > >> >> >>>
> > >> >> >>>PatC
> > >> >> >>>>>
> > >> >> >>>>>Just to make sure, I *presume* that this proposed 
> > text is to
> > >> >> >>>belong in the
> > >> >> >>>>>Mobile IP extension, right?
> > >> >> >>>>
> > >> >> >>>>Yes, that's correct
> > >> >> >>>>
> > >> >> >>>>/Fredrik
> > >> >> >>>>
> > >> >> >>>>>
> > >> >> >>>>>PatC
> > >> >> >>>>>
> > >> >> >>>>>ps: for those that saw my "I will not be responding to
> > >> >> e-mail this
> > >> >> >>>>>week", I
> > >> >> >>>>>happen to be in a city that has metricom service :)
> > >> >> >>>>>
> > >> >> >>>>>>Cool! I was about to send you something very 
> > similar to know
> > >> >> >>>>>>if it was what you meant in your previous mail.
> > >> >> >>>>>>I agree with your solution. Thanks!
> > >> >> >>>>>>
> > >> >> >>>>>>> -----Original Message-----
> > >> >> >>>>>>> From: Fredrik Johansson
> > >> >> [mailto:fredrik.johansson@ipunplugged.com]
> > >> >> >>>>>>> Sent: Tuesday, April 10, 2001 10:27 AM
> > >> >> >>>>>>> To: Martin Julien (ECE); Tony Johansson
> > >> >> >>>>>>> Cc: 'Patrice Calhoun'; AAA Listan
> > >> >> >>>>>>> Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
> > >> >> >>>>>>>
> > >> >> >>>>>>>
> > >> >> >>>>>>> After a closer look at the problem we have a
> > >> suggestion on a
> > >> >> >>solution.
> > >> >> >>>>>>> If the AAAH always assigns a SPI that is unique in
> > >> the HA for
> > >> >> >>>>>>> the FA-HA key,
> > >> >> >>>>>>> and a SPI that is unique in the Mn for the MN-FA and
> > >> >> MN-HA keys, the
> > >> >> >>>>>>> security contexts will automatically be unique 
> > in every SA.
> > >> >> >>>>>>>
> > >> >> >>>>>>> 7.5 SPI Allocation
> > >> >> >>>>>>>   To ensure that the SPI is unique for each 
> > pair of nodes,
> > >> >> >>>>>>>   the AAAH SHOULD keep track of assigned SPIs per
> > >> HA and MN.
> > >> >> >>>>>>>   The SPI assigned to the MN-FA key MUST be 
> > allocated from
> > >> >> >>>>>>> the MN SPI pool,
> > >> >> >>>>>>>   the SPI for the FA-HA key MUST be allocated from
> > >> the HA SPI
> > >> >> >>>>>>> pool, and the
> > >> >> >>>>>>>   SPI for the MN-HA key MUST be allocated from 
> > the MN SPI
> > >> >> >>>>>>> pool. Note that
> > >> >> >>>>>>>   SPI values 0 through 255 are reserved and MUST NOT
> > >> >> be used in any
> > >> >> >>>>>>>   Mobility Security Association.
> > >> >> >>>>>>>
> > >> >> >>>>>>> /Fredrik
> > >> >> >>>>>>> >-----Original Message-----
> > >> >> >>>>>>> >From: owner-aaa-bof@merit.edu
> > >> >> >>>>>>> [mailto:owner-aaa-bof@merit.edu]On Behalf
> > >> >> >>>>>>> >Of Fredrik Johansson
> > >> >> >>>>>>> >Sent: den 10 april 2001 08:40
> > >> >> >>>>>>> >To: Martin Julien (ECE); Tony Johansson
> > >> >> >>>>>>> >Cc: 'Patrice Calhoun'; AAA Listan
> > >> >> >>>>>>> >Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
> > >> >> >>>>>>> >
> > >> >> >>>>>>> >
> > >> >> >>>>>>> >>
> > >> >> >>>>>>> >>> >>
> > >> >> >>>>>>> >>> >> Another thing that needs some clarification,
> > >> >> if there is a
> > >> >> >>>>>>> >>> solution. How
> > >> >> >>>>>>> >>> >> will the HA know which SA to use. In the case
> > >> >> where a mobile
> > >> >> >>>>>>> >>> >moves from one
> > >> >> >>>>>>> >>> >> Fa to another under the same administrative
> > >> >> domain it may
> > >> >> >>>>>>> >>> receive the
> > >> >> >>>>>>> >>> >> session keys for the old Fa from the 
> > AAAF. It will
> > >> >> >>then proceed
> > >> >> >>>>>>> >>> >to send the
> > >> >> >>>>>>> >>> >> mip reg req to the HA. The HA will see that
> > >> >> the message came
> > >> >> >>>>>>> >>> >from the new FA
> > >> >> >>>>>>> >>> >> and try to locate the SA shared with 
> that FA. It
> > >> >> >will not find
> > >> >> >>>>>>> >>> >it since it
> > >> >> >>>>>>> >>> >> was established with the old FA. Eventhough
> > >> >> the HA can see
> > >> >> >>>>>>> >>> the address of
> > >> >> >>>>>>> >>> >> the old Fa in the previous-fa-XXXX it is 
> > not clear
> > >> >> >that it can
> > >> >> >>>>>>> >>> >establish a
> > >> >> >>>>>>> >>> >> SA with the new Fa because it has to use
> > >> the same SPI
> > >> >> >>as before
> > >> >> >>>>>>> >>> >and that one
> > >> >> >>>>>>> >>> >> might be busy. Or have I missed something here?
> > >> >> >>>>>>> >>> >
> > >> >> >>>>>>> >>> >You also have the user NAI in the MIP 
> registration
> > >> >> >>>>>>> request sent to
> > >> >> >>>>>>> >>> >the HA and
> > >> >> >>>>>>> >>> >the user NAI is globally unique....
> > >> >> >>>>>>> >>>
> > >> >> >>>>>>> >>> Yes, but this is not the security association
> > >> >> shared with the
> > >> >> >>>>>>> >>> mobile node
> > >> >> >>>>>>> >>> but the one shared between the FA and HA, thus
> > >> >> has nothing to
> > >> >> >>>>>>> >>> do with the
> > >> >> >>>>>>> >>> user.
> > >> >> >>>>>>> >>
> > >> >> >>>>>>> >>I think you are assuming that there exists only
> > >> 1 mobility
> > >> >> >>>>>>> SA between
> > >> >> >>>>>>> >>a FA and a HA for all the MIP sessions, right?
> > >> >> >>>>>>> >
> > >> >> >>>>>>> >YES, one mobility SA, ceveral security context
> > >> >> within a mobility
> > >> >> >>>>>>> >SA. See rfc
> > >> >> >>>>>>> >2002,
> > >> >> >>>>>>> >
> > >> >> >>>>>>> >"Mobility Security Association
> > >> >> >>>>>>> >               A collection of security contexts,
> > >> >> between a pair
> > >> >> >>>>>>> >               of nodes, which may be applied to
> > >> >> Mobile IP protocol
> > >> >> >>>>>>> >               messages exchanged between them.  Each
> > >> >> >>>>>>> context indicates
> > >> >> >>>>>>> >               an authentication algorithm and mode
> > >> >> >(Section 5.1), a
> > >> >> >>>>>>> >               secret (a shared key, or appropriate
> > >> >> public/private
> > >> >> >>>>>>> >               key pair), and a style of replay
> > >> >> protection in use
> > >> >> >>>>>>> >               (Section 5.6)."
> > >> >> >>>>>>> >
> > >> >> >>>>>>> >Each context is indexed with a unique SPI within
> > >> that SA, if
> > >> >> >>>>>>> there exist a
> > >> >> >>>>>>> >SA between the HA and the old FA and one SA 
> > between the HA
> > >> >> >>>>>>> and the new FA
> > >> >> >>>>>>> >there might exist security context with the same
> > >> SPI in both
> > >> >> >>>>>>> of these.
> > >> >> >>>>>>> >
> > >> >> >>>>>>> >"Security Parameter Index (SPI)
> > >> >> >>>>>>> >               An index identifying a 
> security context
> > >> >> >>between a pair
> > >> >> >>>>>>> >               of nodes among the contexts 
> available in
> > >> >> >the Mobility
> > >> >> >>>>>>> >               Security Association.  SPI values 0
> > >> >> through 255 are
> > >> >> >>>>>>> >               reserved and MUST NOT be used in any
> > >> >> >>Mobility Security
> > >> >> >>>>>>> >               Association."
> > >> >> >>>>>>> >
> > >> >> >>>>>>> >>When a first AMA is received
> > >> >> >>>>>>> >
> > >> >> >>>>>>> >I guess you mean AMR :-)
> > >> >> >>>>>>> >
> > >> >> >>>>>>> >>in the AAAH from a MN, is the AAAH supposed to
> > >> issue a new
> > >> >> >>>>>>> registration
> > >> >> >>>>>>> >>FA-HA key, in the case the HA is in the home 
> > domain? The
> > >> >> >>>>>>> spec says "yes",
> > >> >> >>>>>>> >>if it is required by the MN. However, how can 
> > the MN know
> > >> >> >about the
> > >> >> >>>>>>> >>mobility SA between the FA and the HA? I guess
> > >> it can not,
> > >> >> >>>>>>> which means
> > >> >> >>>>>>> >>that it will ask for a new key, which should be
> > >> transferred
> > >> >> >>>>>>> to the FA and
> > >> >> >>>>>>> >>the HA from the AAAH. Is there a way for the HA to
> > >> >> notify the AAAH
> > >> >> >>>>>>> >>that it does not need
> > >> >> >>>>>>> >>a new key and a new SPI for its mobility SA with
> > >> >> the FA, since it
> > >> >> >>>>>>> >>already has one? I guess
> > >> >> >>>>>>> >>not, right? Then, it looks like your idea 
> > could be very
> > >> >> >>>>>>> interesting, but
> > >> >> >>>>>>> >>I don't know how to deal with it using Diameter,
> > >> unless the
> > >> >> >>>>>>> AAAH and AAAF
> > >> >> >>>>>>> >>would keep a list of mobility SAs between 
> > each FA and HA.
> > >> >> >>>>>>> >
> > >> >> >>>>>>> >In some way the AAAH must keep track of what 
> > SPIs it has
> > >> >> >>>>>>> assigned to the
> > >> >> >>>>>>> >home agent, if it does it per SA or make the SPI
> > >> >> unique over all
> > >> >> >>>>>>> >SA's in the
> > >> >> >>>>>>> >HA is up to the implementation
> > >> >> >>>>>>> >
> > >> >> >>>>>>> >>
> > >> >> >>>>>>> >>> You can not guarantee that a security between
> > >> the HA and
> > >> >> >>>>>>> the old FA is
> > >> >> >>>>>>> >>> unique between the HA and the new FA. The same
> > >> SPI must be
> > >> >> >>>>>>> >>> used in the first
> > >> >> >>>>>>> >>> request in order for the HA to be able to
> > >> >> distinguise between
> > >> >> >>>>>>> >>> different
> > >> >> >>>>>>> >>> security contexts it shares with the FA. What we
> > >> >> can do is to
> > >> >> >>>>>>> >>> have the new
> > >> >> >>>>>>> >>> FA add a <MIP-Preferred-SPI Ext> in the first
> > >> request from
> > >> >> >>>>>>> >>> the new FA to the
> > >> >> >>>>>>> >>> HA, the HA can then use the <Previous-FA-XXXX
> > >> >> Ext> together
> > >> >> >>>>>>> >>> with the old SPI
> > >> >> >>>>>>> >>> to retreive the context and store it under the
> > >> >> Preferred SPI
> > >> >> >>>>>>> >>> under the SA
> > >> >> >>>>>>> >>> with the new FA.
> > >> >> >>>>>>> >>
> > >> >> >>>>>>> >>I was wondering whether or not a mobility SA 
> > between a FA
> > >> >> >>>>>>> >>and a HA was based on a particular MIP session? My
> > >> >> understanding
> > >> >> >>>>>>> >>_IS_ that an existing SA is based on a MIP session.
> > >> >> That means
> > >> >> >>>>>>> >>that between a FA and a HA, there exists several
> > >> >> mobility SAs
> > >> >> >>>>>>> >>depending on each MIP session.
> > >> >> >>>>>>> >
> > >> >> >>>>>>> >No, there is only one SA between two nodes, 
> > but there are
> > >> >> >>>>>>> several security
> > >> >> >>>>>>> >context within each SA. Each security context can
> > >> >> >>>>>>> corresponde to a mip
> > >> >> >>>>>>> >session. It is the security context that has a
> > >> lifetime, the
> > >> >> >>>>>>> SA can be
> > >> >> >>>>>>> >removed when the last security context is removed.
> > >> >> >>>>>>> >
> > >> >> >>>>>>> >>By MIP session, I mean an AAA
> > >> >> >>>>>>> >>authorized session for MIP. The SPI is already
> > >> >> included in the
> > >> >> >>>>>>> >>key transferred between the AAAF and the new FA.
> > >> I don't see
> > >> >> >>>>>>> >>why a HA could not use the SPI stored under its
> > >> MN User-Name
> > >> >> >>>>>>> >>state to retrieve the mobility SA between the new
> > >> >> FA and itself?
> > >> >> >>>>>>> >
> > >> >> >>>>>>> >Because the SA between the FA and HA does not realy
> > >> >> have anything
> > >> >> >>>>>>> >to do with
> > >> >> >>>>>>> >the Mn. It is something setup between the FA 
> > and HA. Thus
> > >> >> >>>>>>> when the HA will
> > >> >> >>>>>>> >look for the key to use it will do the lookup on the
> > >> >> FA address.
> > >> >> >>>>>>> >
> > >> >> >>>>>>> >/Fredrik
> > >> >> >>>>>>> >
> > >> >> >>>>>>> >>
> > >> >> >>>>>>> >>Regards,
> > >> >> >>>>>>> >>Martin
> > >> >> >>>>>>> >
> > >> >> >>>>>>>
> > >> >> >>>>>
> > >> >> >>>>>
> > >> >> >>>
> > >> >> >>>
> > >> >> >>
> > >> >> >
> > >> >>
> > >>
> > 
> 



From owner-aaa-bof@merit.edu  Thu Apr 19 04:06:26 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA08468
	for <aaa-archive@odin.ietf.org>; Thu, 19 Apr 2001 04:06:25 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 965985DD91; Thu, 19 Apr 2001 04:06:04 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 7EAF55DDAD; Thu, 19 Apr 2001 04:06:04 -0400 (EDT)
Received: from mailgw.local.ipunplugged.com (unknown [213.88.134.217])
	by segue.merit.edu (Postfix) with ESMTP id 6C7B15DD91
	for <aaa-wg@merit.edu>; Thu, 19 Apr 2001 04:05:58 -0400 (EDT)
Received: from fredrikj (c35.local.ipunplugged.com [192.168.4.234])
	by mailgw.local.ipunplugged.com (8.9.3/8.9.3) with SMTP id KAA11216;
	Thu, 19 Apr 2001 10:07:03 +0200
From: "Fredrik Johansson" <fredrik.johansson@ipunplugged.com>
To: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>,
        <pcalhoun@eng.sun.com>,
        "'Tony Johansson'" <tony.johansson@ericsson.com>
Cc: "'AAA Listan'" <aaa-wg@merit.edu>
Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
Date: Thu, 19 Apr 2001 10:07:46 +0200
Message-ID: <MJEMJBGGCLLDLFFAHLJKCEEHCKAA.fredrik.johansson@ipunplugged.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <577066326047D41180AC00508B955DDA01D7FF8C@eestqnt104.es.eu.ericsson.se>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

>
>Hi Fredrik,
>
>I realized that in my previous e-mail, I had diverged from my
>original thoughts while writing it, which seems now to be a better
>understanding of the problem than my previous suggestion.
>
>So the question was: "What happens when a second MN tries to
>register with the same Nai, home address and home agent address?"
>
>If the other MN registers within the same foreign network, I would
>say that the MN would reach the AAAF, which would return the FA-MN
>and FA-HA keys to the new FA.

No, the AAAF will not return any keys since it will not receive any
Previous-FA-XXXX AVP. The request will continue to AAAH which will have
a session with the same Nai, Home Address, and Home agent address. It may
decide to send the reply back with new keys and the Original-Session-Id AVP,
thus no new session is created.

I believe that in the absence of a Previous-FA-XXXX AVP the AAAH should take
the request as a new one, i.e. assign it a new home address, home agent
address...

/Fredrik

>That security issue should be left
>to the configuration of the AAAF to trust or not the new FA. Then,
>the new FA would forward the registration request to the HA, which
>would fail, since the MN does not have the good MN-HA key. So my
>question is now: "What should the HA do when it rejects a
>registration?" For sure, it should not cancel the registration
>until a proper de-registration is ordered by the MN, or the
>absence of re-registration at the specified period of time.
>
>If the registration occurs in a different (3rd) domain, then the
>keys are returned by the Home server, and the same process occurs.
>

Same as above

>I'm not sure, but at the first glance, it seems that the HA
>remains the only one, with the AAAH, controlling if the MN is
>legitimate or not.
>
>Martin
>
>> -----Original Message-----
>> From: Martin Julien (ECE)
>> Sent: Wednesday, April 18, 2001 2:52 PM
>> To: 'Fredrik Johansson'; Martin Julien (ECE);
>> pcalhoun@eng.sun.com; Tony
>> Johansson
>> Cc: AAA Listan
>> Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
>>
>>
>> In the case where the MN is roaming within a foreign domain,
>> a Registration is sent and an AMR is be sent to the AAAF. Then the
>> AAAF returns the keys to the new FA without authenticating
>> the MN. That seems to be a "problem". However, if it would reach
>> the Home server, then the MN could be authenticated based on
>> the MIP-MN-AAA-Auth AVP, which could decide if it is a valid
>> request for reporting a roaming situation.
>>
>> Then, should we define a new MIP-MN-AAAF-Auth AVP?, or should every
>> registration reach the Home server each time?
>>
>> Martin
>>
>> > -----Original Message-----
>> > From: Fredrik Johansson [mailto:fredrik.johansson@ipunplugged.com]
>> > Sent: Wednesday, April 18, 2001 1:26 PM
>> > To: Martin Julien (ECE); pcalhoun@eng.sun.com; Tony Johansson
>> > Cc: AAA Listan
>> > Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
>> >
>> >
>> > Looks like it would work, the only question is what happens
>> > when a second MN
>> > tries to register with the same Nai, home address and home
>> > agent address?
>> >
>> > /Fredrik
>> >
>> > >
>> > >Ok, let me try again.
>> > >
>> > >More than one session need to be supported for each MIP user, which
>> > >means that a user might want to register several MNs on the
>> > >network at once.
>> > >That would lead to several separate MIP sessions in the Home
>> > server. AFAIK,
>> > >each MIP session can be uniquely identified by using both its Home
>> > >Agent address
>> > >and its Home address. We could also add the User-Name, to
>> > easily link all
>> > >sessions for a particular user. That means that each MIP
>> > session would be
>> > >keyed on User-Name, Home Agent and Home Address. That takes
>> > into account
>> > >private addresses as well.
>> > >
>> > >Then a first MN registers with a User-Name. Since it is the first
>> > >registration in a foreign domain, then no
>> > MIP-Previous-FA-XXXX is present,
>> > >neither Home Agent nor Home address. Then the FA creates a
>> > new Session-ID,
>> > >which is sent to the AAAF, which forwards it to the Home
>> > server, since
>> > >it is the MN's first registration. Then the MN is registered
>> > successfully.
>> > >
>> > >Then the MN moves to a new FA within the same domain. The MN
>> > will send the
>> > >User-Name, the Home Agent and Home address, along with the
>> > >MIP-Previous-FA-XXXX.
>> > >Then the new FA will send the AMR to the AAAF, which will check if
>> > >there is
>> > >any existing session linked to a similar registration, based on the
>> > >User-Name, the Home Agent and Home address. Since there is, the
>> > >AAAF returns
>> > >the Original-Session-ID, along with the FA keys.
>> > >
>> > >I guess that the same could apply when the node moves to a
>> > third domain, in
>> > >which case it would be the Home server that would be responsible
>> > >of returning
>> > >the Original-Session-ID and FA keys. The same for moving to its
>> > >Home domain.
>> > >
>> > >If there is a second MN that registers for the same user,
>> > then it would
>> > >register without a Home Agent and Home Address. Or if it
>> > does, I guess
>> > >that the Home address should be already defined as unique for that
>> > >particular MN, right? That means that a new session would
>> be created
>> > >by the new FA, which would trigger a new session in the
>> Home server.
>> > >That new session would be uniquely identifiable by the User-Name,
>> > >the Home Agent and the Home address of the MN.
>> > >
>> > >If ever we need to control
>> > >the number of allowed sessions per user, the Home server can
>> > reject the
>> > >AMR when it receives a new registration request from a new MN.
>> > >
>> > >Does that make a bit more sense?
>> > >
>> > >Martin
>> > >
>> > >> -----Original Message-----
>> > >> From: Fredrik Johansson
>> [mailto:fredrik.johansson@ipunplugged.com]
>> > >> Sent: Tuesday, April 17, 2001 4:53 PM
>> > >> To: Martin Julien (ECE); pcalhoun@eng.sun.com; Tony Johansson
>> > >> Cc: AAA Listan
>> > >> Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
>> > >>
>> > >>
>> > >> Hi Martin,
>> > >>
>> > >> How would generating a session id from User-Name and
>> > >> MIP-Previous-FA-XXXX
>> > >> help you to have several MIP sessions for the same user
>> if the have
>> > >> different MNs? The user may still use the same User-Name on
>> > >> all of its MNs,
>> > >> thus causing the same session id to be created.
>> > >>
>> > >> So, I don't believe it will solve the problem. If it is a
>> > >> problem that you
>> > >> cannot have several session with the same nai, isn't that
>> > one of the
>> > >> problems with radius that there is no way to limit a user
>> > >> from login in
>> > >> from several places at the same time using the same user name
>> > >> and password?
>> > >>
>> > >> /Fredrik
>> > >>
>> > >> >
>> > >> >Hej Fredrik,
>> > >> >
>> > >> >If the Session-ID would be generated and handled by the MN, I
>> > >> >guess it would be a lot easier. At least, we could propose a way
>> > >> >of generating a Session-ID in the FA, such as the
>> concatenation of
>> > >> >the User-Name and the Care-Of address (FA), which would
>> lead to a
>> > >> >predictable Session-ID. In the case where the MN would move to a
>> > >> >new FA, then the new FA would need to generate a
>> Session-ID based
>> > >> >on the User-Name and the MIP-Previous-FA-XXXX. Would
>> that make any
>> > >> >sense? Then, I guess we could have several different
>> MIP sessions
>> > >> >for the same User, as long as it is using different MNs. To
>> > >> >support more than one session per MN, I guess the MN
>> would need to
>> > >> >include additional info about that.
>> > >> >
>> > >> >We are having the same kind of problems WRT SIP, I believe.
>> > >> >
>> > >> >Martin
>> > >> >
>> > >> >> -----Original Message-----
>> > >> >> From: Fredrik Johansson
>> > [mailto:fredrik.johansson@ipunplugged.com]
>> > >> >> Sent: Tuesday, April 17, 2001 3:01 PM
>> > >> >> To: pcalhoun@eng.sun.com; Martin Julien (ECE); Tony Johansson
>> > >> >> Cc: AAA Listan
>> > >> >> Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
>> > >> >>
>> > >> >>
>> > >> >> Ok, let's see if I can write the entire message this time
>> > >> >> before sending it
>> > >> >> :-)
>> > >> >> There might be a problem with the possiblity to reuse the old
>> > >> >> session id,
>> > >> >> and
>> > >> >> that is that there can only be one session per user. I don't
>> > >> >> know if this
>> > >> >> limitation
>> > >> >> is to harsh.
>> > >> >>
>> > >> >> /Fredrik
>> > >> >>
>> > >> >> 11.7  Session Movement
>> > >> >>
>> > >> >>    When a user moves between different access devices it may
>> > >> >> be desirable
>> > >> >>    to keep the Session Id unchanged. It is therefore
>> > possible for a
>> > >> >>    server to send the original Session Id back to the
>> > client in the
>> > >> >>    Original-Session-Id AVP. An old session is identified by
>> > >> >> the User Name
>> > >> >>    Nai.
>> > >> >>
>> > >> >> 11.7.1  Original-Session-Id AVP
>> > >> >>
>> > >> >>    The Original-Session-Id AVP (AVP Code 261) is of type
>> > >> >> OctetString and
>> > >> >>    MAY be sent in a message of type Response or Answer
>> > if the AAA
>> > >> >>    server already has a session identifier for the user,
>> > >> and wishes to
>> > >> >>    keep the existing Session-Id. All further messages from
>> > >> the Access
>> > >> >>    Device for this session MUST use the session identifier in
>> > >> >> this AVP.
>> > >> >>    This shouldn't be viewed as a new session, but rather
>> > >> renaming the
>> > >> >>    old session. Any message not using the Session Id in this
>> > >> >> AVP will be
>> > >> >>    treated as an unrecognized Session Id.
>> > >> >>
>> > >> >> 11.8  Session Termination
>> > >> >>
>> > >> >>    The Diameter Base Protocol provides a set of messages
>> > >> that MUST be
>> > >> >>    used by any peer to explicitly request that a previously
>> > >> >>    authenticated and/or authorized session be
>> > terminated. Since the
>> > >> >>    Session-Id is typically tied to a particular service (i.e.
>> > >> >> Mobile IP,
>> > >> >>    NASREQ, etc), the session termination messages are used
>> > >> to request
>> > >> >>    that the service tied to the Session Id be terminated.
>> > >> >>
>> > >> >>
>> > >> >>
>> > >> >> >>-----Original Message-----
>> > >> >> >>From: owner-aaa-bof@merit.edu
>> > >> >> [mailto:owner-aaa-bof@merit.edu]On Behalf
>> > >> >> >>Of Fredrik Johansson
>> > >> >> >>Sent: den 12 april 2001 10:04
>> > >> >> >>To: pcalhoun@eng.sun.com; Martin Julien (ECE); Tony
>> Johansson
>> > >> >> >>Cc: AAA Listan
>> > >> >> >>Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
>> > >> >> >>
>> > >> >> >>
>> > >> >> >>No, no additional AVPs is required. However, I believe some
>> > >> >> explanations
>> > >> >> >>should be provided on how to treat the  request in
>> > >> >> different nodes. I'll
>> > >> >> >>give you some text after the weekend that hopefully
>> > will give you
>> > >> >> >>some ideas
>> > >> >> >>what I mean. Untill then I will enjoy a couple of
>> > days skiing :-)
>> > >> >> >>
>> > >> >> >>/Fredrik
>> > >> >> >>
>> > >> >> >>>-----Original Message-----
>> > >> >> >>>From: owner-aaa-bof@merit.edu
>> > >> >> [mailto:owner-aaa-bof@merit.edu]On Behalf
>> > >> >> >>>Of Patrice Calhoun
>> > >> >> >>>Sent: den 11 april 2001 19:32
>> > >> >> >>>To: Fredrik Johansson; Martin Julien (ECE); Tony Johansson
>> > >> >> >>>Cc: AAA Listan
>> > >> >> >>>Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
>> > >> >> >>>
>> > >> >> >>>
>> > >> >> >>>and no additional protocol text (read AVPs) is required???
>> > >> >> >>>
>> > >> >> >>>PatC
>> > >> >> >>>>>
>> > >> >> >>>>>Just to make sure, I *presume* that this proposed
>> > text is to
>> > >> >> >>>belong in the
>> > >> >> >>>>>Mobile IP extension, right?
>> > >> >> >>>>
>> > >> >> >>>>Yes, that's correct
>> > >> >> >>>>
>> > >> >> >>>>/Fredrik
>> > >> >> >>>>
>> > >> >> >>>>>
>> > >> >> >>>>>PatC
>> > >> >> >>>>>
>> > >> >> >>>>>ps: for those that saw my "I will not be responding to
>> > >> >> e-mail this
>> > >> >> >>>>>week", I
>> > >> >> >>>>>happen to be in a city that has metricom service :)
>> > >> >> >>>>>
>> > >> >> >>>>>>Cool! I was about to send you something very
>> > similar to know
>> > >> >> >>>>>>if it was what you meant in your previous mail.
>> > >> >> >>>>>>I agree with your solution. Thanks!
>> > >> >> >>>>>>
>> > >> >> >>>>>>> -----Original Message-----
>> > >> >> >>>>>>> From: Fredrik Johansson
>> > >> >> [mailto:fredrik.johansson@ipunplugged.com]
>> > >> >> >>>>>>> Sent: Tuesday, April 10, 2001 10:27 AM
>> > >> >> >>>>>>> To: Martin Julien (ECE); Tony Johansson
>> > >> >> >>>>>>> Cc: 'Patrice Calhoun'; AAA Listan
>> > >> >> >>>>>>> Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
>> > >> >> >>>>>>>
>> > >> >> >>>>>>>
>> > >> >> >>>>>>> After a closer look at the problem we have a
>> > >> suggestion on a
>> > >> >> >>solution.
>> > >> >> >>>>>>> If the AAAH always assigns a SPI that is unique in
>> > >> the HA for
>> > >> >> >>>>>>> the FA-HA key,
>> > >> >> >>>>>>> and a SPI that is unique in the Mn for the MN-FA and
>> > >> >> MN-HA keys, the
>> > >> >> >>>>>>> security contexts will automatically be unique
>> > in every SA.
>> > >> >> >>>>>>>
>> > >> >> >>>>>>> 7.5 SPI Allocation
>> > >> >> >>>>>>>   To ensure that the SPI is unique for each
>> > pair of nodes,
>> > >> >> >>>>>>>   the AAAH SHOULD keep track of assigned SPIs per
>> > >> HA and MN.
>> > >> >> >>>>>>>   The SPI assigned to the MN-FA key MUST be
>> > allocated from
>> > >> >> >>>>>>> the MN SPI pool,
>> > >> >> >>>>>>>   the SPI for the FA-HA key MUST be allocated from
>> > >> the HA SPI
>> > >> >> >>>>>>> pool, and the
>> > >> >> >>>>>>>   SPI for the MN-HA key MUST be allocated from
>> > the MN SPI
>> > >> >> >>>>>>> pool. Note that
>> > >> >> >>>>>>>   SPI values 0 through 255 are reserved and MUST NOT
>> > >> >> be used in any
>> > >> >> >>>>>>>   Mobility Security Association.
>> > >> >> >>>>>>>
>> > >> >> >>>>>>> /Fredrik
>> > >> >> >>>>>>> >-----Original Message-----
>> > >> >> >>>>>>> >From: owner-aaa-bof@merit.edu
>> > >> >> >>>>>>> [mailto:owner-aaa-bof@merit.edu]On Behalf
>> > >> >> >>>>>>> >Of Fredrik Johansson
>> > >> >> >>>>>>> >Sent: den 10 april 2001 08:40
>> > >> >> >>>>>>> >To: Martin Julien (ECE); Tony Johansson
>> > >> >> >>>>>>> >Cc: 'Patrice Calhoun'; AAA Listan
>> > >> >> >>>>>>> >Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
>> > >> >> >>>>>>> >
>> > >> >> >>>>>>> >
>> > >> >> >>>>>>> >>
>> > >> >> >>>>>>> >>> >>
>> > >> >> >>>>>>> >>> >> Another thing that needs some clarification,
>> > >> >> if there is a
>> > >> >> >>>>>>> >>> solution. How
>> > >> >> >>>>>>> >>> >> will the HA know which SA to use. In the case
>> > >> >> where a mobile
>> > >> >> >>>>>>> >>> >moves from one
>> > >> >> >>>>>>> >>> >> Fa to another under the same administrative
>> > >> >> domain it may
>> > >> >> >>>>>>> >>> receive the
>> > >> >> >>>>>>> >>> >> session keys for the old Fa from the
>> > AAAF. It will
>> > >> >> >>then proceed
>> > >> >> >>>>>>> >>> >to send the
>> > >> >> >>>>>>> >>> >> mip reg req to the HA. The HA will see that
>> > >> >> the message came
>> > >> >> >>>>>>> >>> >from the new FA
>> > >> >> >>>>>>> >>> >> and try to locate the SA shared with
>> that FA. It
>> > >> >> >will not find
>> > >> >> >>>>>>> >>> >it since it
>> > >> >> >>>>>>> >>> >> was established with the old FA. Eventhough
>> > >> >> the HA can see
>> > >> >> >>>>>>> >>> the address of
>> > >> >> >>>>>>> >>> >> the old Fa in the previous-fa-XXXX it is
>> > not clear
>> > >> >> >that it can
>> > >> >> >>>>>>> >>> >establish a
>> > >> >> >>>>>>> >>> >> SA with the new Fa because it has to use
>> > >> the same SPI
>> > >> >> >>as before
>> > >> >> >>>>>>> >>> >and that one
>> > >> >> >>>>>>> >>> >> might be busy. Or have I missed something here?
>> > >> >> >>>>>>> >>> >
>> > >> >> >>>>>>> >>> >You also have the user NAI in the MIP
>> registration
>> > >> >> >>>>>>> request sent to
>> > >> >> >>>>>>> >>> >the HA and
>> > >> >> >>>>>>> >>> >the user NAI is globally unique....
>> > >> >> >>>>>>> >>>
>> > >> >> >>>>>>> >>> Yes, but this is not the security association
>> > >> >> shared with the
>> > >> >> >>>>>>> >>> mobile node
>> > >> >> >>>>>>> >>> but the one shared between the FA and HA, thus
>> > >> >> has nothing to
>> > >> >> >>>>>>> >>> do with the
>> > >> >> >>>>>>> >>> user.
>> > >> >> >>>>>>> >>
>> > >> >> >>>>>>> >>I think you are assuming that there exists only
>> > >> 1 mobility
>> > >> >> >>>>>>> SA between
>> > >> >> >>>>>>> >>a FA and a HA for all the MIP sessions, right?
>> > >> >> >>>>>>> >
>> > >> >> >>>>>>> >YES, one mobility SA, ceveral security context
>> > >> >> within a mobility
>> > >> >> >>>>>>> >SA. See rfc
>> > >> >> >>>>>>> >2002,
>> > >> >> >>>>>>> >
>> > >> >> >>>>>>> >"Mobility Security Association
>> > >> >> >>>>>>> >               A collection of security contexts,
>> > >> >> between a pair
>> > >> >> >>>>>>> >               of nodes, which may be applied to
>> > >> >> Mobile IP protocol
>> > >> >> >>>>>>> >               messages exchanged between them.  Each
>> > >> >> >>>>>>> context indicates
>> > >> >> >>>>>>> >               an authentication algorithm and mode
>> > >> >> >(Section 5.1), a
>> > >> >> >>>>>>> >               secret (a shared key, or appropriate
>> > >> >> public/private
>> > >> >> >>>>>>> >               key pair), and a style of replay
>> > >> >> protection in use
>> > >> >> >>>>>>> >               (Section 5.6)."
>> > >> >> >>>>>>> >
>> > >> >> >>>>>>> >Each context is indexed with a unique SPI within
>> > >> that SA, if
>> > >> >> >>>>>>> there exist a
>> > >> >> >>>>>>> >SA between the HA and the old FA and one SA
>> > between the HA
>> > >> >> >>>>>>> and the new FA
>> > >> >> >>>>>>> >there might exist security context with the same
>> > >> SPI in both
>> > >> >> >>>>>>> of these.
>> > >> >> >>>>>>> >
>> > >> >> >>>>>>> >"Security Parameter Index (SPI)
>> > >> >> >>>>>>> >               An index identifying a
>> security context
>> > >> >> >>between a pair
>> > >> >> >>>>>>> >               of nodes among the contexts
>> available in
>> > >> >> >the Mobility
>> > >> >> >>>>>>> >               Security Association.  SPI values 0
>> > >> >> through 255 are
>> > >> >> >>>>>>> >               reserved and MUST NOT be used in any
>> > >> >> >>Mobility Security
>> > >> >> >>>>>>> >               Association."
>> > >> >> >>>>>>> >
>> > >> >> >>>>>>> >>When a first AMA is received
>> > >> >> >>>>>>> >
>> > >> >> >>>>>>> >I guess you mean AMR :-)
>> > >> >> >>>>>>> >
>> > >> >> >>>>>>> >>in the AAAH from a MN, is the AAAH supposed to
>> > >> issue a new
>> > >> >> >>>>>>> registration
>> > >> >> >>>>>>> >>FA-HA key, in the case the HA is in the home
>> > domain? The
>> > >> >> >>>>>>> spec says "yes",
>> > >> >> >>>>>>> >>if it is required by the MN. However, how can
>> > the MN know
>> > >> >> >about the
>> > >> >> >>>>>>> >>mobility SA between the FA and the HA? I guess
>> > >> it can not,
>> > >> >> >>>>>>> which means
>> > >> >> >>>>>>> >>that it will ask for a new key, which should be
>> > >> transferred
>> > >> >> >>>>>>> to the FA and
>> > >> >> >>>>>>> >>the HA from the AAAH. Is there a way for the HA to
>> > >> >> notify the AAAH
>> > >> >> >>>>>>> >>that it does not need
>> > >> >> >>>>>>> >>a new key and a new SPI for its mobility SA with
>> > >> >> the FA, since it
>> > >> >> >>>>>>> >>already has one? I guess
>> > >> >> >>>>>>> >>not, right? Then, it looks like your idea
>> > could be very
>> > >> >> >>>>>>> interesting, but
>> > >> >> >>>>>>> >>I don't know how to deal with it using Diameter,
>> > >> unless the
>> > >> >> >>>>>>> AAAH and AAAF
>> > >> >> >>>>>>> >>would keep a list of mobility SAs between
>> > each FA and HA.
>> > >> >> >>>>>>> >
>> > >> >> >>>>>>> >In some way the AAAH must keep track of what
>> > SPIs it has
>> > >> >> >>>>>>> assigned to the
>> > >> >> >>>>>>> >home agent, if it does it per SA or make the SPI
>> > >> >> unique over all
>> > >> >> >>>>>>> >SA's in the
>> > >> >> >>>>>>> >HA is up to the implementation
>> > >> >> >>>>>>> >
>> > >> >> >>>>>>> >>
>> > >> >> >>>>>>> >>> You can not guarantee that a security between
>> > >> the HA and
>> > >> >> >>>>>>> the old FA is
>> > >> >> >>>>>>> >>> unique between the HA and the new FA. The same
>> > >> SPI must be
>> > >> >> >>>>>>> >>> used in the first
>> > >> >> >>>>>>> >>> request in order for the HA to be able to
>> > >> >> distinguise between
>> > >> >> >>>>>>> >>> different
>> > >> >> >>>>>>> >>> security contexts it shares with the FA. What we
>> > >> >> can do is to
>> > >> >> >>>>>>> >>> have the new
>> > >> >> >>>>>>> >>> FA add a <MIP-Preferred-SPI Ext> in the first
>> > >> request from
>> > >> >> >>>>>>> >>> the new FA to the
>> > >> >> >>>>>>> >>> HA, the HA can then use the <Previous-FA-XXXX
>> > >> >> Ext> together
>> > >> >> >>>>>>> >>> with the old SPI
>> > >> >> >>>>>>> >>> to retreive the context and store it under the
>> > >> >> Preferred SPI
>> > >> >> >>>>>>> >>> under the SA
>> > >> >> >>>>>>> >>> with the new FA.
>> > >> >> >>>>>>> >>
>> > >> >> >>>>>>> >>I was wondering whether or not a mobility SA
>> > between a FA
>> > >> >> >>>>>>> >>and a HA was based on a particular MIP session? My
>> > >> >> understanding
>> > >> >> >>>>>>> >>_IS_ that an existing SA is based on a MIP session.
>> > >> >> That means
>> > >> >> >>>>>>> >>that between a FA and a HA, there exists several
>> > >> >> mobility SAs
>> > >> >> >>>>>>> >>depending on each MIP session.
>> > >> >> >>>>>>> >
>> > >> >> >>>>>>> >No, there is only one SA between two nodes,
>> > but there are
>> > >> >> >>>>>>> several security
>> > >> >> >>>>>>> >context within each SA. Each security context can
>> > >> >> >>>>>>> corresponde to a mip
>> > >> >> >>>>>>> >session. It is the security context that has a
>> > >> lifetime, the
>> > >> >> >>>>>>> SA can be
>> > >> >> >>>>>>> >removed when the last security context is removed.
>> > >> >> >>>>>>> >
>> > >> >> >>>>>>> >>By MIP session, I mean an AAA
>> > >> >> >>>>>>> >>authorized session for MIP. The SPI is already
>> > >> >> included in the
>> > >> >> >>>>>>> >>key transferred between the AAAF and the new FA.
>> > >> I don't see
>> > >> >> >>>>>>> >>why a HA could not use the SPI stored under its
>> > >> MN User-Name
>> > >> >> >>>>>>> >>state to retrieve the mobility SA between the new
>> > >> >> FA and itself?
>> > >> >> >>>>>>> >
>> > >> >> >>>>>>> >Because the SA between the FA and HA does not realy
>> > >> >> have anything
>> > >> >> >>>>>>> >to do with
>> > >> >> >>>>>>> >the Mn. It is something setup between the FA
>> > and HA. Thus
>> > >> >> >>>>>>> when the HA will
>> > >> >> >>>>>>> >look for the key to use it will do the lookup on the
>> > >> >> FA address.
>> > >> >> >>>>>>> >
>> > >> >> >>>>>>> >/Fredrik
>> > >> >> >>>>>>> >
>> > >> >> >>>>>>> >>
>> > >> >> >>>>>>> >>Regards,
>> > >> >> >>>>>>> >>Martin
>> > >> >> >>>>>>> >
>> > >> >> >>>>>>>
>> > >> >> >>>>>
>> > >> >> >>>>>
>> > >> >> >>>
>> > >> >> >>>
>> > >> >> >>
>> > >> >> >
>> > >> >>
>> > >>
>> >
>>




From owner-aaa-bof@merit.edu  Thu Apr 19 06:03:58 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA09544
	for <aaa-archive@odin.ietf.org>; Thu, 19 Apr 2001 06:03:57 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id D78C25DDAD; Thu, 19 Apr 2001 06:01:05 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id C165D5DDC5; Thu, 19 Apr 2001 06:01:05 -0400 (EDT)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by segue.merit.edu (Postfix) with ESMTP id ABC255DDAD
	for <aaa-wg@merit.edu>; Thu, 19 Apr 2001 06:01:02 -0400 (EDT)
Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f3JA11O21026
	for <aaa-wg@merit.edu>; Thu, 19 Apr 2001 12:01:01 +0200 (MEST)
Received: FROM esealnt743.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Thu Apr 19 12:00:55 2001 +0200
Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <HA3DK8W2>; Thu, 19 Apr 2001 12:00:55 +0200
Message-ID: <577066326047D41180AC00508B955DDA01D7FF91@eestqnt104.es.eu.ericsson.se>
From: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>
To: "'Fredrik Johansson'" <fredrik.johansson@ipunplugged.com>,
        "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>,
        pcalhoun@eng.sun.com, "'Tony Johansson'" <tony.johansson@ericsson.com>
Cc: "'AAA Listan'" <aaa-wg@merit.edu>
Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
Date: Thu, 19 Apr 2001 12:00:52 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> >So the question was: "What happens when a second MN tries to
> >register with the same Nai, home address and home agent address?"
> >
> >If the other MN registers within the same foreign network, I would
> >say that the MN would reach the AAAF, which would return the FA-MN
> >and FA-HA keys to the new FA.
> 
> No, the AAAF will not return any keys since it will not receive any
> Previous-FA-XXXX AVP. The request will continue to AAAH which 
> will have
> a session with the same Nai, Home Address, and Home agent 
> address. It may
> decide to send the reply back with new keys and the 
> Original-Session-Id AVP,
> thus no new session is created.

I don't see why it is required to have the Previous-FA-XXXX AVP if 
you already have the Nai, home address and home agent address to
identify uniquely a session? What more would you get by receiving 
it in the AAAF? When you receive an AMR in the AAAF, you know that 
the MN has either moved to a new FA, or it is requesting a new set 
of keys, or it is a fresh first registration, right?

> I believe that in the absence of a Previous-FA-XXXX AVP the 
> AAAH should take
> the request as a new one, i.e. assign it a new home address, 
> home agent
> address...

I think that if the AAAF can not find any information locally 
related to the MN based on the Nai, home address and home agent 
address, then the AMR should be forwarded to the AAAH. Of course,
unless a new set of keys is also required by the MN, which means
that the AMR obviously needs to be forwarded to the AAAH.

The FA should forward the MIP registration directly to the HA 
only if the AMA does not include a MIP-Reg-Reply.

I think we should also consider the case where a fraudulent user
would seized the User-Name, the Home address and the Home Agent 
address and would try to override the "truly authorized" registration
of the "true" user. I guess that the Previous-FA-XXXX AVP could also
be hijacked easily.

What do you think?

> /Fredrik
> 
> >That security issue should be left
> >to the configuration of the AAAF to trust or not the new FA. Then,
> >the new FA would forward the registration request to the HA, which
> >would fail, since the MN does not have the good MN-HA key. So my
> >question is now: "What should the HA do when it rejects a
> >registration?" For sure, it should not cancel the registration
> >until a proper de-registration is ordered by the MN, or the
> >absence of re-registration at the specified period of time.
> >
> >If the registration occurs in a different (3rd) domain, then the
> >keys are returned by the Home server, and the same process occurs.
> >
> 
> Same as above
> 
> >I'm not sure, but at the first glance, it seems that the HA
> >remains the only one, with the AAAH, controlling if the MN is
> >legitimate or not.
> >
> >Martin
> >
> >> -----Original Message-----
> >> From: Martin Julien (ECE)
> >> Sent: Wednesday, April 18, 2001 2:52 PM
> >> To: 'Fredrik Johansson'; Martin Julien (ECE);
> >> pcalhoun@eng.sun.com; Tony
> >> Johansson
> >> Cc: AAA Listan
> >> Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
> >>
> >>
> >> In the case where the MN is roaming within a foreign domain,
> >> a Registration is sent and an AMR is be sent to the AAAF. Then the
> >> AAAF returns the keys to the new FA without authenticating
> >> the MN. That seems to be a "problem". However, if it would reach
> >> the Home server, then the MN could be authenticated based on
> >> the MIP-MN-AAA-Auth AVP, which could decide if it is a valid
> >> request for reporting a roaming situation.
> >>
> >> Then, should we define a new MIP-MN-AAAF-Auth AVP?, or should every
> >> registration reach the Home server each time?
> >>
> >> Martin
> >>
> >> > -----Original Message-----
> >> > From: Fredrik Johansson 
> [mailto:fredrik.johansson@ipunplugged.com]
> >> > Sent: Wednesday, April 18, 2001 1:26 PM
> >> > To: Martin Julien (ECE); pcalhoun@eng.sun.com; Tony Johansson
> >> > Cc: AAA Listan
> >> > Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
> >> >
> >> >
> >> > Looks like it would work, the only question is what happens
> >> > when a second MN
> >> > tries to register with the same Nai, home address and home
> >> > agent address?
> >> >
> >> > /Fredrik



From owner-aaa-bof@merit.edu  Thu Apr 19 10:57:36 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12074
	for <aaa-archive@odin.ietf.org>; Thu, 19 Apr 2001 10:57:36 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 5E4A55DE7B; Thu, 19 Apr 2001 10:55:14 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 3ECE85DEE4; Thu, 19 Apr 2001 10:55:14 -0400 (EDT)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by segue.merit.edu (Postfix) with ESMTP id 9F63D5DE7B
	for <aaa-wg@merit.edu>; Thu, 19 Apr 2001 10:54:05 -0400 (EDT)
Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f3JEs3N07233
	for <aaa-wg@merit.edu>; Thu, 19 Apr 2001 16:54:03 +0200 (MEST)
Received: FROM esealnt743.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Apr 19 16:54:04 2001 +0200
Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <HA3DLMFV>; Thu, 19 Apr 2001 16:54:02 +0200
Message-ID: <577066326047D41180AC00508B955DDA01D7FF95@eestqnt104.es.eu.ericsson.se>
From: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>
To: "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>
Cc: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>
Subject: [AAA-WG]: Msg Header Identifiers??
Date: Thu, 19 Apr 2001 16:43:10 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Hi,

Should messages received with an un-expected Hop-by-Hop 
or End-to-End Identifier in the header be discarded?, 
or should a DSI or MRI be sent? I think it SHOULD be locally
logged, and MUST be discarded. What do you think?

Should duplicates be also discarded? I would assume that
a duplicate message detected based on the Hop-By-Hop Identifier
should be discarded, while a duplicate message detected based
on the End-to-End Identifier is not so obvious to me.

The introduction of the End-to-End Identifier was to detect
when a Diameter client was re-sending a pending request, since
it was impatient. Now that we have the DSI-Event "STILL_WORKING",
and the Max-Wait-Time AVP, do we still need the End-to-End 
Identifier? 

Anyway, the thing is that if a duplicate detected based on the 
End-to-End Identifier is received in the Home server while it is still 
processing the previous request, should the Home server send an
MRI with a new Result-Code to "Duplicate Message-Still Working"?
That would make sure that the Diameter nodes on the way to the Home
server do not retry to re-send once more the duplicate message
as well. The "Duplicate Message-Still Working" would be an End-to-End
error of type Permanent.

/Martin



From owner-aaa-bof@merit.edu  Thu Apr 19 11:03:08 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12238
	for <aaa-archive@odin.ietf.org>; Thu, 19 Apr 2001 11:03:07 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id CBF0D5DEB9; Thu, 19 Apr 2001 10:18:24 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id B7F385DE95; Thu, 19 Apr 2001 10:18:24 -0400 (EDT)
Received: from zcars04f.ca.nortel.com (zcars04f.nortelnetworks.com [47.129.242.57])
	by segue.merit.edu (Postfix) with ESMTP id 4DC725DE4E
	for <aaa-wg@merit.edu>; Thu, 19 Apr 2001 10:18:23 -0400 (EDT)
Received: from zbl6c012.corpeast.baynetworks.com by zcars04f.ca.nortel.com;
          Thu, 19 Apr 2001 10:16:51 -0400
Received: from zbl6c016.corpeast.baynetworks.com ([132.245.205.66]) 
          by zbl6c012.corpeast.baynetworks.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) 
          id JC4S6DG3; Thu, 19 Apr 2001 10:16:48 -0400
Received: from mitton.nortelnetworks.com (47.16.86.121 [47.16.86.121]) 
          by zbl6c016.corpeast.baynetworks.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) 
          id HJCW52W1; Thu, 19 Apr 2001 10:16:48 -0400
Message-Id: <4.3.2.7.2.20010419101127.00b01f00@ZBL6C016.corpeast.baynetworks.com>
X-Sender: dmitton@ZBL6C016.corpeast.baynetworks.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Thu, 19 Apr 2001 10:18:37 -0400
To: John Alayari <johnal@cisco.com>, Jari Arkko <Jari.Arkko@lmf.ericsson.se>,
        aaa-wg <aaa-wg@merit.edu>
From: "David Mitton" <dmitton@nortelnetworks.com>
Subject: RE: [AAA-WG]: separated authorization and accounting servers
In-Reply-To: <CNEGKCBENOKKPJPNCEODKEJECCAA.johnal@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Orig: <dmitton@nortelnetworks.com>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Yes,
   you can devise all sorts of scenarios where separated Accounting and 
Authentication make sense.  Some people do it RADIUS.

However,
         Accounting messages are essential to session state keeping 
Authorization servers, and since we have not added any Session Terminate 
Report messages, I think Accounting should be Mandatory back to the Auth 
servers.

If you want to split off the stream at a proxy, or devise NASes that copy 
the stream to multiple targets, that's fine with me.

I'm also really having trouble digesting your example in real terms.
The splitting of functions between your client 1 and 2 seems rather 
awkward.  How many systems are keeping session state?  Whom actually 
implements the session service?

         Dave.

At 4/18/01 12:12 PM -0400, John Alayari wrote:

>Jari,
>I totally agree. The base spec should allow separation of
>Authentication/Authorization from Accounting on both client and server side.
>And section 13.1 should be reworded to support this. Let me give an example
>that shows why we need that:
>
>In the following example, client 1 is the session controller (e.g. SIP
>server) and
>the client 2 is bearer of data. Please note that, there may be multiple
>nodes acting as client for the same session. Server 1 does the
>authorization/and authentication function and server 2 does the accounting
>only.
>
>The authorization-server directed model here mean that the accounting
>policies(accounting records timeliness, etc.) in server 1 are transferred to
>client 2 in step 4. and that is communicated to server 2 in step 5.
>
>
>             ------                   ------
>1)Orig Msg |Client|  2)Access Req.  |Server|
>  --------->|  1   |---------------->|  1   |
>            |      |<----------------|      |
>             ------   3)Access Resp.   ------
>               |
>               | 4) Access/Auth-indication
>               |
>               V
>             ------                   ------
>6)Data     |Client| 5)Acct Req.     |Server|
><--------->|  2   |---------------->|  2   |
>            |      |<----------------|      |
>             ------  6)Acct Resp.     ------
>
>John.
>
>-----Original Message-----
>From: owner-aaa-bof@merit.edu 
>[<mailto:owner-aaa-bof@merit.edu>mailto:owner-aaa-bof@merit.edu]On Behalf
>Of Jari Arkko
>Sent: Wednesday, April 18, 2001 1:44 AM
>To: aaa-wg@merit.edu
>Subject: [AAA-WG]: separated authorization and accounting servers?
>(resend, sorry if you get this twice...)
>
>
>Hello,
>
>We've been trying to figure out if the current
>version of the Diameter specs allow accounting
>and other traffic to be directed to different
>servers. Traditionally, we've had this feature
>in RADIUS. It might even be conceivable that there
>be uses of accounting where there is no authentication
>or authorization at all on a node that gives a service.
>
>But can we do this? We haven't figured out if the
>specifications say anything about this. Section 13.1
>talks about authorization server directed model, but
>I would classify the "direction" as optional information.
>Section 13.2 says servers that receive a succesfull
>authentication response must collect accounting information.
>But must they send it too? And can there be other nodes
>that would not perform authentication/authorization but
>who still produce accounting information (e.g. for
>trend analysis purposes)? Section 11 talks about user
>sessions and their life-cycle. But it doesn't seem to
>state anything about this issue in particular.
>
>Do we allow two proxies to be configured for a client
>node, one for the authentication and authorization, and
>the second one for accounting?
>
>And whatever we say, why are we saying so?
>
>Jari

---------------------------------------------------------------
David Mitton                                  ESN: 248-4570
Advisor, Nortel Networks                      978-288-4570 Direct
Wireless Solutions, IP Mobility
Billerica, MA 01821                    dmitton@nortelnetworks.com




From owner-aaa-bof@merit.edu  Thu Apr 19 19:40:44 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA19815
	for <aaa-archive@odin.ietf.org>; Thu, 19 Apr 2001 19:40:44 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 4D94B5DEC4; Thu, 19 Apr 2001 19:37:26 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 35AE35DE8A; Thu, 19 Apr 2001 19:37:26 -0400 (EDT)
Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240])
	by segue.merit.edu (Postfix) with ESMTP id 604BF5DEC3
	for <aaa-wg@merit.edu>; Thu, 19 Apr 2001 19:37:23 -0400 (EDT)
Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124])
	by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f3JNbOB17883;
	Thu, 19 Apr 2001 18:37:24 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179])
	by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id f3JNbMH00562;
	Thu, 19 Apr 2001 18:37:22 -0500 (CDT)
Received: from pop.exu.ericsson.se (qpop [138.85.1.15]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id SAA22620; Thu, 19 Apr 2001 18:37:22 -0500 (CDT)
Received: from ericsson.com (busam62.berkeley.us.am.ericsson.se [138.85.159.212])
	by pop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id SAA14259;
	Thu, 19 Apr 2001 18:37:10 -0500 (CDT)
Message-ID: <3ADF766B.BE853B44@ericsson.com>
Date: Thu, 19 Apr 2001 16:36:11 -0700
From: Tony Johansson <tony.johansson@ericsson.com>
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>
Cc: "'Fredrik Johansson'" <fredrik.johansson@ipunplugged.com>,
        pcalhoun@eng.sun.com, "'AAA Listan'" <aaa-wg@merit.edu>
Subject: Re: [AAA-WG]: Previous-FA-XXXX AVP
References: <577066326047D41180AC00508B955DDA01D7FF91@eestqnt104.es.eu.ericsson.se>
Content-Type: multipart/alternative;
 boundary="------------74DE8F35694DCF841E2D843B"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk


--------------74DE8F35694DCF841E2D843B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hi,

Please see my comments embedded....

BR,

/Tony

"Martin Julien (ECE)" wrote:

> > >So the question was: "What happens when a second MN tries to
> > >register with the same Nai, home address and home agent address?"
> > >
> > >If the other MN registers within the same foreign network, I would
> > >say that the MN would reach the AAAF, which would return the FA-MN
> > >and FA-HA keys to the new FA.
> >
> > No, the AAAF will not return any keys since it will not receive any
> > Previous-FA-XXXX AVP. The request will continue to AAAH which
> > will have
> > a session with the same Nai, Home Address, and Home agent
> > address. It may
> > decide to send the reply back with new keys and the
> > Original-Session-Id AVP,
> > thus no new session is created.
>
> I don't see why it is required to have the Previous-FA-XXXX AVP if
> you already have the Nai, home address and home agent address to
> identify uniquely a session? What more would you get by receiving
> it in the AAAF? When you receive an AMR in the AAAF, you know that
> the MN has either moved to a new FA, or it is requesting a new set
> of keys, or it is a fresh first registration, right?

I agree it seems to work without the Previous-FA-XXXX AVP in most cases.
However, here is one scenario where I think it is needed.

Let's say that you have a hierarchical AAA architecture with two sub-domains
within a large network domain. In each sub-domain you have a AAA and FAs and
these two AAAs are connected to a broker/proxy AAA. The broker/proxy AAA is
used every time the AAAs in the sub-domains can't resolve it on their own.
So let's say that a user that belongs to another network domain has been
registered via an FA in one of the sub-domains to an HA in its home network.
Let's now assume that this user does a handoff to another FA in the other
sub-domain, which means the new AAAF will issue the AMR toward the
broker/proxy AAA. With the Previous-FA-XXXX AVP, the broker/proxy would be
able to proxy (1) or redirect (2) the AAAF to get the existing keys from the
old AAAF. Without the Previous-FA-XXXX AVP, you would be forced to store
more info in the broker/proxy AAA to achieve this functionality, otherwise
you would be forced to proxy the message back to the MN's AAAH (3). Does
this make sense?


    (Please view in a fixed-width font such as Courier.)

+----------------------------------------------+
|                                              |
|             mydomain.com                     | home.com
|                                              |
|                            +--------+        | +------+
|         +------------------+ AAAB   +--->(3) | |AAAH  |
|         |                  |        |        | |      |
|         |                  +--+-----+        | +------+
|         |                     |   ^          |
|         V                     V   |          |
|        (1)                   (2)  |          |     +---+
|                                   |          |     |HA |
| +------------------+    +---------|--------+ |     +---+
| |                  |    |         |        | |
| |                  |    |         |        | |
| |sub1.mydomain.com |    | sub2.mydomain.com| |
| |                  |    |         |        | |
| |                  |    |        ++------+ | |
| |      +-------+   |    |        |AAAF   | | |
| |      | AAAF  |   |    |        |       | | |
| |      |       |   |    |        +-------+ | |
| |      +-------+   |    |          ^       | |
| |                  |    |          |       | |
| |    +--+          |    |        +-++      | |
| |    |FA|          |    |        |FA|      | |
| |    +--+          |    |        +--+      | |
| |                  |    +---------^--------+ |
| +------------------+              |          |
|                                 +-+-+        |
|             ----------------->  |MN |        |
|                                 +---+        |
|                                              |
+----------------------------------------------+




>
>
> > I believe that in the absence of a Previous-FA-XXXX AVP the
> > AAAH should take
> > the request as a new one, i.e. assign it a new home address,
> > home agent
> > address...
>
> I think that if the AAAF can not find any information locally
> related to the MN based on the Nai, home address and home agent
> address, then the AMR should be forwarded to the AAAH. Of course,
> unless a new set of keys is also required by the MN, which means
> that the AMR obviously needs to be forwarded to the AAAH.
>
> The FA should forward the MIP registration directly to the HA
> only if the AMA does not include a MIP-Reg-Reply.
>
> I think we should also consider the case where a fraudulent user
> would seized the User-Name, the Home address and the Home Agent
> address and would try to override the "truly authorized" registration
> of the "true" user. I guess that the Previous-FA-XXXX AVP could also
> be hijacked easily.
>
> What do you think?
>
> > /Fredrik
> >
> > >That security issue should be left
> > >to the configuration of the AAAF to trust or not the new FA. Then,
> > >the new FA would forward the registration request to the HA, which
> > >would fail, since the MN does not have the good MN-HA key. So my
> > >question is now: "What should the HA do when it rejects a
> > >registration?" For sure, it should not cancel the registration
> > >until a proper de-registration is ordered by the MN, or the
> > >absence of re-registration at the specified period of time.
> > >
> > >If the registration occurs in a different (3rd) domain, then the
> > >keys are returned by the Home server, and the same process occurs.
> > >
> >
> > Same as above
> >
> > >I'm not sure, but at the first glance, it seems that the HA
> > >remains the only one, with the AAAH, controlling if the MN is
> > >legitimate or not.
> > >
> > >Martin
> > >
> > >> -----Original Message-----
> > >> From: Martin Julien (ECE)
> > >> Sent: Wednesday, April 18, 2001 2:52 PM
> > >> To: 'Fredrik Johansson'; Martin Julien (ECE);
> > >> pcalhoun@eng.sun.com; Tony
> > >> Johansson
> > >> Cc: AAA Listan
> > >> Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
> > >>
> > >>
> > >> In the case where the MN is roaming within a foreign domain,
> > >> a Registration is sent and an AMR is be sent to the AAAF. Then the
> > >> AAAF returns the keys to the new FA without authenticating
> > >> the MN. That seems to be a "problem". However, if it would reach
> > >> the Home server, then the MN could be authenticated based on
> > >> the MIP-MN-AAA-Auth AVP, which could decide if it is a valid
> > >> request for reporting a roaming situation.
> > >>
> > >> Then, should we define a new MIP-MN-AAAF-Auth AVP?, or should every
> > >> registration reach the Home server each time?
> > >>
> > >> Martin
> > >>
> > >> > -----Original Message-----
> > >> > From: Fredrik Johansson
> > [mailto:fredrik.johansson@ipunplugged.com]
> > >> > Sent: Wednesday, April 18, 2001 1:26 PM
> > >> > To: Martin Julien (ECE); pcalhoun@eng.sun.com; Tony Johansson
> > >> > Cc: AAA Listan
> > >> > Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
> > >> >
> > >> >
> > >> > Looks like it would work, the only question is what happens
> > >> > when a second MN
> > >> > tries to register with the same Nai, home address and home
> > >> > agent address?
> > >> >
> > >> > /Fredrik

--------------74DE8F35694DCF841E2D843B
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hi,
<p>Please see my comments embedded....
<p>BR,
<p>/Tony
<p>"Martin Julien (ECE)" wrote:
<blockquote TYPE=CITE>> >So the question was: "What happens when a second
MN tries to
<br>> >register with the same Nai, home address and home agent address?"
<br>> >
<br>> >If the other MN registers within the same foreign network, I would
<br>> >say that the MN would reach the AAAF, which would return the FA-MN
<br>> >and FA-HA keys to the new FA.
<br>>
<br>> No, the AAAF will not return any keys since it will not receive any
<br>> Previous-FA-XXXX AVP. The request will continue to AAAH which
<br>> will have
<br>> a session with the same Nai, Home Address, and Home agent
<br>> address. It may
<br>> decide to send the reply back with new keys and the
<br>> Original-Session-Id AVP,
<br>> thus no new session is created.
<p>I don't see why it is required to have the Previous-FA-XXXX AVP if
<br>you already have the Nai, home address and home agent address to
<br>identify uniquely a session? What more would you get by receiving
<br>it in the AAAF? When you receive an AMR in the AAAF, you know that
<br>the MN has either moved to a new FA, or it is requesting a new set
<br>of keys, or it is a fresh first registration, right?</blockquote>
I agree it seems to work without the Previous-FA-XXXX AVP in most cases.
However, here is one scenario where I think it is needed.
<p>Let's say that you have a hierarchical AAA architecture with two sub-domains
within a large network domain. In each sub-domain you have a AAA and FAs
and these two AAAs are connected to a broker/proxy AAA. The broker/proxy
AAA is used every time the AAAs in the sub-domains can't resolve it on
their own. So let's say that a user that belongs to another network domain
has been registered via an FA in one of the sub-domains to an HA in its
home network. Let's now assume that this user does a handoff to another
FA in the other sub-domain, which means the new AAAF will issue the AMR
toward the broker/proxy AAA. With the Previous-FA-XXXX AVP, the broker/proxy
would be able to proxy (1) or redirect (2) the AAAF to get the existing
keys from the old AAAF. Without the Previous-FA-XXXX AVP, you would be
forced to store more info in the broker/proxy AAA to achieve this functionality,
otherwise you would be forced to proxy the message back to the MN's AAAH
(3). Does this make sense?
<br>&nbsp;
<p>&nbsp;&nbsp;&nbsp; (Please view in a fixed-width font such as Courier.)
<p><tt>+----------------------------------------------+</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
mydomain.com&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
| home.com</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+--------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | +------+</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +------------------+
AAAB&nbsp;&nbsp; +--->(3) | |AAAH&nbsp; |</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
| |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+--+-----+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | +------+</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; ^&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; V&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
V&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; (1)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
(2)&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;
+---+</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;
|HA |</tt>
<br><tt>| +------------------+&nbsp;&nbsp;&nbsp; +---------|--------+ |&nbsp;&nbsp;&nbsp;&nbsp;
+---+</tt>
<br><tt>| |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
| |</tt>
<br><tt>| |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
| |</tt>
<br><tt>| |sub1.mydomain.com |&nbsp;&nbsp;&nbsp; | sub2.mydomain.com| |</tt>
<br><tt>| |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
| |</tt>
<br><tt>| |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ++------+
| |</tt>
<br><tt>| |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-------+&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |AAAF&nbsp;&nbsp; | | |</tt>
<br><tt>| |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | AAAF&nbsp; |&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
| | |</tt>
<br><tt>| |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+-------+ | |</tt>
<br><tt>| |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-------+&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ^&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
| |</tt>
<br><tt>| |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | |</tt>
<br><tt>| |&nbsp;&nbsp;&nbsp; +--+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +-++&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
| |</tt>
<br><tt>| |&nbsp;&nbsp;&nbsp; |FA|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |FA|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
| |</tt>
<br><tt>| |&nbsp;&nbsp;&nbsp; +--+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +--+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
| |</tt>
<br><tt>| |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp; +---------^--------+ |</tt>
<br><tt>| +------------------+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+-+-+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
----------------->&nbsp; |MN |&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
+---+&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; |</tt>
<br><tt>|&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
|</tt>
<br><tt>+----------------------------------------------+</tt>
<br>&nbsp;
<br>&nbsp;
<br>&nbsp;
<blockquote TYPE=CITE>&nbsp;
<p>> I believe that in the absence of a Previous-FA-XXXX AVP the
<br>> AAAH should take
<br>> the request as a new one, i.e. assign it a new home address,
<br>> home agent
<br>> address...
<p>I think that if the AAAF can not find any information locally
<br>related to the MN based on the Nai, home address and home agent
<br>address, then the AMR should be forwarded to the AAAH. Of course,
<br>unless a new set of keys is also required by the MN, which means
<br>that the AMR obviously needs to be forwarded to the AAAH.
<p>The FA should forward the MIP registration directly to the HA
<br>only if the AMA does not include a MIP-Reg-Reply.
<p>I think we should also consider the case where a fraudulent user
<br>would seized the User-Name, the Home address and the Home Agent
<br>address and would try to override the "truly authorized" registration
<br>of the "true" user. I guess that the Previous-FA-XXXX AVP could also
<br>be hijacked easily.
<p>What do you think?
<p>> /Fredrik
<br>>
<br>> >That security issue should be left
<br>> >to the configuration of the AAAF to trust or not the new FA. Then,
<br>> >the new FA would forward the registration request to the HA, which
<br>> >would fail, since the MN does not have the good MN-HA key. So my
<br>> >question is now: "What should the HA do when it rejects a
<br>> >registration?" For sure, it should not cancel the registration
<br>> >until a proper de-registration is ordered by the MN, or the
<br>> >absence of re-registration at the specified period of time.
<br>> >
<br>> >If the registration occurs in a different (3rd) domain, then the
<br>> >keys are returned by the Home server, and the same process occurs.
<br>> >
<br>>
<br>> Same as above
<br>>
<br>> >I'm not sure, but at the first glance, it seems that the HA
<br>> >remains the only one, with the AAAH, controlling if the MN is
<br>> >legitimate or not.
<br>> >
<br>> >Martin
<br>> >
<br>> >> -----Original Message-----
<br>> >> From: Martin Julien (ECE)
<br>> >> Sent: Wednesday, April 18, 2001 2:52 PM
<br>> >> To: 'Fredrik Johansson'; Martin Julien (ECE);
<br>> >> pcalhoun@eng.sun.com; Tony
<br>> >> Johansson
<br>> >> Cc: AAA Listan
<br>> >> Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
<br>> >>
<br>> >>
<br>> >> In the case where the MN is roaming within a foreign domain,
<br>> >> a Registration is sent and an AMR is be sent to the AAAF. Then
the
<br>> >> AAAF returns the keys to the new FA without authenticating
<br>> >> the MN. That seems to be a "problem". However, if it would reach
<br>> >> the Home server, then the MN could be authenticated based on
<br>> >> the MIP-MN-AAA-Auth AVP, which could decide if it is a valid
<br>> >> request for reporting a roaming situation.
<br>> >>
<br>> >> Then, should we define a new MIP-MN-AAAF-Auth AVP?, or should
every
<br>> >> registration reach the Home server each time?
<br>> >>
<br>> >> Martin
<br>> >>
<br>> >> > -----Original Message-----
<br>> >> > From: Fredrik Johansson
<br>> [<a href="mailto:fredrik.johansson@ipunplugged.com">mailto:fredrik.johansson@ipunplugged.com</a>]
<br>> >> > Sent: Wednesday, April 18, 2001 1:26 PM
<br>> >> > To: Martin Julien (ECE); pcalhoun@eng.sun.com; Tony Johansson
<br>> >> > Cc: AAA Listan
<br>> >> > Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
<br>> >> >
<br>> >> >
<br>> >> > Looks like it would work, the only question is what happens
<br>> >> > when a second MN
<br>> >> > tries to register with the same Nai, home address and home
<br>> >> > agent address?
<br>> >> >
<br>> >> > /Fredrik</blockquote>
</html>

--------------74DE8F35694DCF841E2D843B--




From owner-aaa-bof@merit.edu  Fri Apr 20 03:28:57 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA08437
	for <aaa-archive@odin.ietf.org>; Fri, 20 Apr 2001 03:28:56 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id A08565E003; Fri, 20 Apr 2001 03:23:56 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 794BD5DFE1; Fri, 20 Apr 2001 03:23:49 -0400 (EDT)
Received: from mailgw.local.ipunplugged.com (unknown [213.88.134.217])
	by segue.merit.edu (Postfix) with ESMTP id AC4F35DE85
	for <aaa-wg@merit.edu>; Fri, 20 Apr 2001 03:16:13 -0400 (EDT)
Received: from fredrikj (c35.local.ipunplugged.com [192.168.4.234])
	by mailgw.local.ipunplugged.com (8.9.3/8.9.3) with SMTP id JAA28075;
	Fri, 20 Apr 2001 09:17:00 +0200
From: "Fredrik Johansson" <fredrik.johansson@ipunplugged.com>
To: "Tony Johansson" <tony.johansson@ericsson.com>,
        "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>
Cc: <pcalhoun@eng.sun.com>, "'AAA Listan'" <aaa-wg@merit.edu>
Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
Date: Fri, 20 Apr 2001 09:17:46 +0200
Message-ID: <MJEMJBGGCLLDLFFAHLJKAEFKCKAA.fredrik.johansson@ipunplugged.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <3ADF766B.BE853B44@ericsson.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi,
Please see my comments embedded....
BR,
/Tony
"Martin Julien (ECE)" wrote:
> >So the question was: "What happens when a second MN tries to
> >register with the same Nai, home address and home agent address?"
> >
> >If the other MN registers within the same foreign network, I would
> >say that the MN would reach the AAAF, which would return the FA-MN
> >and FA-HA keys to the new FA.
>
> No, the AAAF will not return any keys since it will not receive any
> Previous-FA-XXXX AVP. The request will continue to AAAH which
> will have
> a session with the same Nai, Home Address, and Home agent
> address. It may
> decide to send the reply back with new keys and the
> Original-Session-Id AVP,
> thus no new session is created.
I don't see why it is required to have the Previous-FA-XXXX AVP if
you already have the Nai, home address and home agent address to
identify uniquely a session? What more would you get by receiving
it in the AAAF? When you receive an AMR in the AAAF, you know that
the MN has either moved to a new FA, or it is requesting a new set
of keys, or it is a fresh first registration, right?
I agree it seems to work without the Previous-FA-XXXX AVP in most cases.
However, here is one scenario where I think it is needed.
Let's say that you have a hierarchical AAA architecture with two sub-domains
within a large network domain. In each sub-domain you have a AAA and FAs and
these two AAAs are connected to a broker/proxy AAA. The broker/proxy AAA is
used every time the AAAs in the sub-domains can't resolve it on their own.
So let's say that a user that belongs to another network domain has been
registered via an FA in one of the sub-domains to an HA in its home network.
Let's now assume that this user does a handoff to another FA in the other
sub-domain, which means the new AAAF will issue the AMR toward the
broker/proxy AAA. With the Previous-FA-XXXX AVP, the broker/proxy would be
able to proxy (1) or redirect (2) the AAAF to get the existing keys from the
old AAAF. Without the Previous-FA-XXXX AVP, you would be forced to store
more info in the broker/proxy AAA to achieve this functionality, otherwise
you would be forced to proxy the message back to the MN's AAAH (3). Does
this make sense?

    (Please view in a fixed-width font such as Courier.)
+----------------------------------------------+
|                                              |
|             mydomain.com                     | home.com
|                                              |
|                            +--------+        | +------+
|         +------------------+ AAAB   +--->(3) | |AAAH  |
|         |                  |        |        | |      |
|         |                  +--+-----+        | +------+
|         |                     |   ^          |
|         V                     V   |          |
|        (1)                   (2)  |          |     +---+
|                                   |          |     |HA |
| +------------------+    +---------|--------+ |     +---+
| |                  |    |         |        | |
| |                  |    |         |        | |
| |sub1.mydomain.com |    | sub2.mydomain.com| |
| |                  |    |         |        | |
| |                  |    |        ++------+ | |
| |      +-------+   |    |        |AAAF   | | |
| |      | AAAF  |   |    |        |       | | |
| |      |       |   |    |        +-------+ | |
| |      +-------+   |    |          ^       | |
| |                  |    |          |       | |
| |    +--+          |    |        +-++      | |
| |    |FA|          |    |        |FA|      | |
| |    +--+          |    |        +--+      | |
| |                  |    +---------^--------+ |
| +------------------+              |          |
|                                 +-+-+        |
|             ----------------->  |MN |        |
|                                 +---+        |
|                                              |
+----------------------------------------------+




> I believe that in the absence of a Previous-FA-XXXX AVP the
> AAAH should take
> the request as a new one, i.e. assign it a new home address,
> home agent
> address...
I think that if the AAAF can not find any information locally
related to the MN based on the Nai, home address and home agent
address, then the AMR should be forwarded to the AAAH. Of course,
unless a new set of keys is also required by the MN, which means
that the AMR obviously needs to be forwarded to the AAAH.
The FA should forward the MIP registration directly to the HA
only if the AMA does not include a MIP-Reg-Reply.
I think we should also consider the case where a fraudulent user
would seized the User-Name, the Home address and the Home Agent
address and would try to override the "truly authorized" registration
of the "true" user. I guess that the Previous-FA-XXXX AVP could also
be hijacked easily.
What do you think?

[Fredrik Johansson]

That is true, and you can not protect a stupid user from himself.
My idea of sending the registration request back in the AMA was so
that the client should not have to keep state, but I guess it has to
anyway incase the transport fails. So the absence of a Reg Reply is
good enough.

/Fredrik

>
> >That security issue should be left
> >to the configuration of the AAAF to trust or not the new FA. Then,
> >the new FA would forward the registration request to the HA, which
> >would fail, since the MN does not have the good MN-HA key. So my
> >question is now: "What should the HA do when it rejects a
> >registration?" For sure, it should not cancel the registration
> >until a proper de-registration is ordered by the MN, or the
> >absence of re-registration at the specified period of time.
> >
> >If the registration occurs in a different (3rd) domain, then the
> >keys are returned by the Home server, and the same process occurs.
> >
>
> Same as above
>
> >I'm not sure, but at the first glance, it seems that the HA
> >remains the only one, with the AAAH, controlling if the MN is
> >legitimate or not.
> >
> >Martin
> >
> >> -----Original Message-----
> >> From: Martin Julien (ECE)
> >> Sent: Wednesday, April 18, 2001 2:52 PM
> >> To: 'Fredrik Johansson'; Martin Julien (ECE);
> >> pcalhoun@eng.sun.com; Tony
> >> Johansson
> >> Cc: AAA Listan
> >> Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
> >>
> >>
> >> In the case where the MN is roaming within a foreign domain,
> >> a Registration is sent and an AMR is be sent to the AAAF. Then the
> >> AAAF returns the keys to the new FA without authenticating
> >> the MN. That seems to be a "problem". However, if it would reach
> >> the Home server, then the MN could be authenticated based on
> >> the MIP-MN-AAA-Auth AVP, which could decide if it is a valid
> >> request for reporting a roaming situation.
> >>
> >> Then, should we define a new MIP-MN-AAAF-Auth AVP?, or should every
> >> registration reach the Home server each time?
> >>
> >> Martin
> >>
> >> > -----Original Message-----
> >> > From: Fredrik Johansson
> [mailto:fredrik.johansson@ipunplugged.com]
> >> > Sent: Wednesday, April 18, 2001 1:26 PM
> >> > To: Martin Julien (ECE); pcalhoun@eng.sun.com; Tony Johansson
> >> > Cc: AAA Listan
> >> > Subject: RE: [AAA-WG]: Previous-FA-XXXX AVP
> >> >
> >> >
> >> > Looks like it would work, the only question is what happens
> >> > when a second MN
> >> > tries to register with the same Nai, home address and home
> >> > agent address?
> >> >
> >> > /Fredrik




From owner-aaa-bof@merit.edu  Fri Apr 20 18:00:16 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18630
	for <aaa-archive@odin.ietf.org>; Fri, 20 Apr 2001 18:00:16 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 13AB15DE7A; Fri, 20 Apr 2001 17:29:49 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id F28095DE7C; Fri, 20 Apr 2001 17:29:48 -0400 (EDT)
Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10])
	by segue.merit.edu (Postfix) with ESMTP id B44395DE7A
	for <aaa-wg@merit.edu>; Fri, 20 Apr 2001 17:29:47 -0400 (EDT)
Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (motgate2 2.1) with ESMTP id OAA01336 for <aaa-wg@merit.edu>; Fri, 20 Apr 2001 14:29:47 -0700 (MST)]
Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id OAA17608 for <aaa-wg@merit.edu>; Fri, 20 Apr 2001 14:29:46 -0700 (MST)]
Received: by IL75EXM04 with Internet Mail Service (5.5.2653.19)
	id <JK1JWT32>; Fri, 20 Apr 2001 16:29:14 -0500
Message-ID: <35DBB8B7AC89D4118E98009027B1009B0ECE8E@IL27EXM10.cig.mot.com>
From: Cain Brian-BCAIN1 <Brian.Cain@motorola.com>
To: "'James Kempf'" <James.Kempf@sun.com>,
        "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>
Cc: Thomas Panagiotis-PTHOMAS1 <panos.thomas@motorola.com>
Subject: [AAA-WG]: API, latest draft
Date: Fri, 20 Apr 2001 16:29:15 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

James, et al.,

	Comments below.

>4.3.2.4 Instance Methods
>
-      public AVPDescriptor findCommand(java.lang.String name)
+      public AAACommandDescriptor findCommand(java.lang.String name)
>
>   Return an AAACommandDescriptor for the command matching the name, or
>   null if none.

copy/paste error.

>4.2.2.4 Instance Methods
>
-      AAAMessage getMessage()
+      AAAMessage getStatusMessage()
>
>   Return the AAAMessage object containing the status message.

The method name 'getMessage' conflicts w/Throwable's getMessage().  Any name
other than 'getMessage' will do.

>        startSession(InetAddress host,AAACommandDictionary dictionary)
>
>   Open a new AAA session. The session is established with the indicated
>   host, and the command dictionary is used to drive command parsing and
>   checking.  This method performs the necessary Diameter messaging for
>   the state machine described in Section 8.0 of [1] in order to bring
>   up a Diameter connection, in addition to standard network sockets
>   bring up

Can we be certain Diameter messaging for a given session would be confined
to one dictionary?  Wouldn't all of the dictionaries be mutually exclusive
(i.e. a given command would show up in one and only one dictionary),
anyways?  It seems like the command dictionaries would lend themselves well
as global variables (global to the library, that is).  Even if each session
confines itself to a particular extension's dictionary, they would still use
the Base protocol's dictionary.  And it would probably be necessary to have
the other dictionaries in order to distinguish between a case where the
library should reject a message with response "EXTENSION_NOT_SUPPORTED" or
"UNKNOWN_COMMAND".  

>4.3.4.4 Instance Methods
...
>      public java.util.Map getAVPDictionary()
>
>   Return a dictionary with String AVP names as keys and AVPDescriptor
>   objects as values for AVPs in the command. If any of the AVPs is
>   Grouped, then the value is a Map containing the descriptors for the
>   AVPs in the Grouped.

I see.  So, AVP lookups are no longer "standalone".  In order to get an
AVPDescriptor, we must first have a command in mind.  I like this.

(from 4.3.6.4)
>      public AAACommandDescriptor
>        registerCommand(long code,
>                        long vendorCode,
>                        java.lang.String name,
>                        java.util.Map AVPDictionary,
>                        java.util.Map disallowedAVPDictionary)

Hmm..This is the only place I could see an AVP dictionary being input into
the library.  I saw no mention of a property for the AVP dictionary file.
I've got a couple of issues with this.  First, there is no correlation
between AVP code and type.  This is the bare minimum requirement for an AVP
dictionary.  Okay, I take that back, the library could put the
responsibility of casting the data to the appropriate type on the API user.
(I see that as pretty unsatisfactory).  That much aside, I really prefer
configuration files for AVP and Command dictionaries over methods.  I think
that having both serves only confusion.  In place of methods like
"registerXxxxx()", a hierarchy of files could be established to register
Extensions, Commands, and AVPs.

What would you think of making a (loose) analogy between AAA Extension and
java package, AAA Command and java class?  You know, how java and javac use
directories as package "grouping symbols", and .class files as individual
classes.  I'm thinking of something like this:

file /etc/aaa.conf:
~~~~~~~~~~~~~~~~
Extension NASREQ    = yes
Extension Mobile_IP = no

Vendor motorola = /etc/aaa/motorola/mot_aaa.conf
Vendor sun      = /etc/aaa/sun/sun_aaa.conf
~~~~~~~~~~~~~~~~
Extensions could be explicitly supported or not, but by default they would
not be.  (NB: I'm not trying to suggest a particular file syntax w/this
example)

file /etc/aaa/NASREQ.xml:
~~~~~~~~~~~~~~~
>XML description of commands 
 defined by NASREQ extension<
~~~~~~~~~~~~~~~

file /etc/aaa/NASREQ.avp.conf:
~~~~~~~~~~~~~~~
AVP "Fancy-New-AVP":
  Type = Float128
  Code = 0x3443
  ...
~~~~~~~~~~~~~~~
(again, not suggesting syntax here, there's no reason why this couldn't be
in XML, too)

file /etc/aaa/motorola/mot_aaa.conf:
~~~~~~~~~~~~~~~
Commands = /etc/aaa/motorola/commands.xml
AVPs     = /etc/aaa/motorola/mot_avp.conf

>add'l vendor-specific info, e.g. 
 constants like "Luna.Location", etc.<
~~~~~~~~~~~~~~~


Property org.ietf.aaa.configFile = "/etc/aaa.conf"

I may be reinventing the wheel a bit with the above suggestion, but the
point that I'm most adamant about is that there should be configuration
files, and they should be the sole way of notifying the library of the type
of AVPs, and the syntax of Commands, etc.  If it's necessary to be able to
update the dictionaries at runtime without restarting the server, the
AAASessionManager could have a reloadConfigFiles() method.

>6.0 References
...
>
>[7]  http://www.diameter.org/diameter.xml
>

FYI - not there (yet?).  I'd be happy to help w/the DTD, if work is still in
progress.  I imagine this is outside the scope of the Java API?  Who's
writing the DTD?

-Brian

--
Brian Cain



From owner-aaa-bof@merit.edu  Fri Apr 20 18:17:36 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18978
	for <aaa-archive@odin.ietf.org>; Fri, 20 Apr 2001 18:17:36 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id D0DE65DE6B; Fri, 20 Apr 2001 18:15:12 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id BB93B5DE68; Fri, 20 Apr 2001 18:15:12 -0400 (EDT)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id 4591F5DE3E
	for <aaa-wg@merit.edu>; Fri, 20 Apr 2001 18:15:11 -0400 (EDT)
Received: from heliopolis.eng.sun.com ([152.70.1.39])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA05240;
	Fri, 20 Apr 2001 15:03:34 -0700 (PDT)
Received: from srmtv29a (srmtv29a [152.70.1.41])
	by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id PAA12317;
	Fri, 20 Apr 2001 15:03:32 -0700 (PDT)
Message-Id: <200104202203.PAA12317@heliopolis.eng.sun.com>
Date: Fri, 20 Apr 2001 15:03:32 -0700 (PDT)
From: James Kempf <James.Kempf@Sun.COM>
Reply-To: James Kempf <James.Kempf@Sun.COM>
Subject: [AAA-WG]: Re: API, latest draft
To: aaa-wg@merit.edu, Brian.Cain@motorola.com
Cc: panos.thomas@motorola.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: 1CAz6R1HLtmjTCTUfWr9eg==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Hi Brian,

Thanx for your comments.

>>        startSession(InetAddress host,AAACommandDictionary dictionary)
>>
>>   Open a new AAA session. The session is established with the indicated
>>   host, and the command dictionary is used to drive command parsing and
>>   checking.  This method performs the necessary Diameter messaging for
>>   the state machine described in Section 8.0 of [1] in order to bring
>>   up a Diameter connection, in addition to standard network sockets
>>   bring up
>
>Can we be certain Diameter messaging for a given session would be confined
>to one dictionary?  Wouldn't all of the dictionaries be mutually exclusive
>(i.e. a given command would show up in one and only one dictionary),
>anyways?  It seems like the command dictionaries would lend themselves well
>as global variables (global to the library, that is).  Even if each session
>confines itself to a particular extension's dictionary, they would still use
>the Base protocol's dictionary.  And it would probably be necessary to have
>the other dictionaries in order to distinguish between a case where the
>library should reject a message with response "EXTENSION_NOT_SUPPORTED" or
>"UNKNOWN_COMMAND".  
>

I agree that all sessions will need to use the base protocol's dictionary.

So it sounds like the issue is the following. If a command shows up
for a given session but the command is known in a dictionary of
another session, this design will return an UNKNOWN_COMMAND when
it should return an EXTENSION_NOT_SUPPORTED, is that it? 

The intent of including the dictionary in this fashion was to allow
Diameter applications to running in the same virtual machine
to handle separate applications, and so that they could define
their commands in separate configuration files. I'm not strongly
tied to this design, but I had thought it might be simpler from
the application's perspective. It sounds like you would rather
simply have a global command dictionary?

>(from 4.3.6.4)
>>      public AAACommandDescriptor
>>        registerCommand(long code,
>>                        long vendorCode,
>>                        java.lang.String name,
>>                        java.util.Map AVPDictionary,
>>                        java.util.Map disallowedAVPDictionary)
>
>Hmm..This is the only place I could see an AVP dictionary being input into
>the library.  I saw no mention of a property for the AVP dictionary file.

Typically, the AVP dictionary is defined as part of the command definition
configuration file. I believe there has been agreement by the group
that AVPs are standardized as part of extensions, not separately. Thus,
it seems to make sense to include them as part of the commands.

In addition, the API has to provide a way for programmatic definition
of commands, separate from parsing the command definition file. This
method is defined for the latter. The Java code implementing an
extension that wants to build up a dictionary would do it by
building up the AVP dictionary programmaticaly, then building up
the command, etc.

>I've got a couple of issues with this.  First, there is no correlation
>between AVP code and type.  This is the bare minimum requirement for an AVP

I guess I don't understand. The AVPs and AVPDescriptors are indexed by name, and 
the AVPDescriptor object contains a type indicator (AVPDescriptor.getType()). 
Would you rather have them indexed by code?

>dictionary.  Okay, I take that back, the library could put the
>responsibility of casting the data to the appropriate type on the API user.

It is true that the return type from the AVP.getData() method is
Object, but there are only possible 9 data types, and that
can easily be handled by a typecase. 

We could have individual AVP types with different getData() return
type methods, but then you would have to run the typecase when
you extract the AVP from the Map. This seems like one area where
dynamic type checking is advantageous.

>(I see that as pretty unsatisfactory).  That much aside, I really prefer
>configuration files for AVP and Command dictionaries over methods.  I think
>that having both serves only confusion.  In place of methods like
>"registerXxxxx()", a hierarchy of files could be established to register
>Extensions, Commands, and AVPs.
>

I agree that configuration files are preferable, but I think we need
to keep open the possibility of programmatic update. In addition,
the library implementation itself can use the programmatic interface when 
parsing the configuration files.

>What would you think of making a (loose) analogy between AAA Extension and
>java package, AAA Command and java class?  You know, how java and javac use
>directories as package "grouping symbols", and .class files as individual
>classes.  I'm thinking of something like this:
>
>file /etc/aaa.conf:
>~~~~~~~~~~~~~~~~
>Extension NASREQ    = yes
>Extension Mobile_IP = no
>
>Vendor motorola = /etc/aaa/motorola/mot_aaa.conf
>Vendor sun      = /etc/aaa/sun/sun_aaa.conf
>~~~~~~~~~~~~~~~~
>Extensions could be explicitly supported or not, but by default they would
>not be.  (NB: I'm not trying to suggest a particular file syntax w/this
>example)
>
>file /etc/aaa/NASREQ.xml:
>~~~~~~~~~~~~~~~
>>XML description of commands 
> defined by NASREQ extension<
>~~~~~~~~~~~~~~~
>
>file /etc/aaa/NASREQ.avp.conf:
>~~~~~~~~~~~~~~~
>AVP "Fancy-New-AVP":
>  Type = Float128
>  Code = 0x3443
>  ...
>~~~~~~~~~~~~~~~
>(again, not suggesting syntax here, there's no reason why this couldn't be
>in XML, too)
>
>file /etc/aaa/motorola/mot_aaa.conf:
>~~~~~~~~~~~~~~~
>Commands = /etc/aaa/motorola/commands.xml
>AVPs     = /etc/aaa/motorola/mot_avp.conf
>
>>add'l vendor-specific info, e.g. 
> constants like "Luna.Location", etc.<
>~~~~~~~~~~~~~~~
>
>
>Property org.ietf.aaa.configFile = "/etc/aaa.conf"
>
>I may be reinventing the wheel a bit with the above suggestion, but the
>point that I'm most adamant about is that there should be configuration
>files, and they should be the sole way of notifying the library of the type
>of AVPs, and the syntax of Commands, etc.  If it's necessary to be able to
>update the dictionaries at runtime without restarting the server, the
>AAASessionManager could have a reloadConfigFiles() method.
>

I believe Erik already has some syntax for this in the DTD. I'd rather not
tie people down to having to map extensions into packages and
commands into classes. I can think of cases where an extension might
span a bunch of packages.

>>6.0 References
>...
>>
>>[7]  http://www.diameter.org/diameter.xml
>>
>
>FYI - not there (yet?).  I'd be happy to help w/the DTD, if work is still in
>progress.  I imagine this is outside the scope of the Java API?  Who's
>writing the DTD?
>

I guess Pat didn't post it before he went on vacation. I will talk to
him when he gets back next week. If you would like to help writing the DTD,
send email to Erik Guttman (erik.guttman@sun.com).

		jak




From owner-aaa-bof@merit.edu  Sat Apr 21 05:34:29 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA08934
	for <aaa-archive@odin.ietf.org>; Sat, 21 Apr 2001 05:34:28 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 2576F5DDDE; Sat, 21 Apr 2001 05:33:22 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id F03915DE01; Sat, 21 Apr 2001 05:33:21 -0400 (EDT)
Received: from hindon.hss.co.in (unknown [202.54.26.202])
	by segue.merit.edu (Postfix) with ESMTP id 452E65DDDE
	for <aaa-wg@merit.edu>; Sat, 21 Apr 2001 05:33:19 -0400 (EDT)
Received: from sandesh.hss.hns.com (localhost [127.0.0.1])
	by hindon.hss.co.in (8.10.0/8.10.0) with SMTP id f3L7bNX26707;
	Sat, 21 Apr 2001 13:07:23 +0530 (IST)
Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3  (733.2 10-16-1998))  id 65256A35.00287358 ; Sat, 21 Apr 2001 12:51:49 +0530
X-Lotus-FromDomain: HSS
From: sargupta@hss.hns.com
To: "Ruslan R. Laishev" <Laishev@SMTP.DeltaTel.RU>
Cc: aaa-wg@merit.edu
Message-ID: <65256A35.002872B2.00@sandesh.hss.hns.com>
Date: Sat, 21 Apr 2001 12:59:07 +0530
Subject: Re: [AAA-WG]: Accounting software
Mime-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Disposition: inline
Sender: owner-aaa-bof@merit.edu
Precedence: bulk



Hi,
   To be precise do we have any software implementing Radius Client. All the
vendors on this site provide the server code.

Regards
sarika




"Ruslan R. Laishev" <Laishev@SMTP.DeltaTel.RU> on 04/18/2001 12:51:55 AM

To:   Sarika Gupta/HSS@HSS
cc:   aaa-wg@merit.edu

Subject:  Re: [AAA-WG]: Accounting software




http://ing.ctit.utwente.nl/WU5/D5.1/Technology/radius/

sargupta@hss.hns.com wrote:
>
> Hi,
>    Do we have any free softwares implementing Radius especially the accounting
> feature.
>
> Regards
> sarika

--
Cheers, Ruslan.
+---------------pure personal opinion-----------------------+
    RADIUS Server for OpenVMS project - www.radiusvms.com
      vms-isps@dls.net - Forum for ISP running OpenVMS
  Mobile: +7 (901) 971-3222, AIM nickname:"VMS hardworker"







From owner-aaa-bof@merit.edu  Mon Apr 23 05:15:20 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA02805
	for <aaa-archive@odin.ietf.org>; Mon, 23 Apr 2001 05:15:20 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 887DE5DE4B; Mon, 23 Apr 2001 05:11:14 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 7239F5DE41; Mon, 23 Apr 2001 05:11:14 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id 0F2385DD93
	for <aaa-wg@merit.edu>; Mon, 23 Apr 2001 05:11:11 -0400 (EDT)
Received: from ehdb03-home.Germany.Sun.COM ([129.157.142.202])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id CAA08984
	for <aaa-wg@merit.edu>; Mon, 23 Apr 2001 02:11:07 -0700 (PDT)
Received: from qwer (qwer [129.157.142.111])
	by ehdb03-home.Germany.Sun.COM (8.8.8+Sun/8.8.8/ENSMAIL,v2.1p1) with SMTP id LAA08293;
	Mon, 23 Apr 2001 11:11:03 +0200 (MET DST)
Message-Id: <200104230911.LAA08293@ehdb03-home.Germany.Sun.COM>
Date: Mon, 23 Apr 2001 11:11:03 +0200 (MEST)
From: Erik Guttman Sun Frankfurt Staff Engineer <Erik.Guttman@Sun.COM>
Reply-To: Erik Guttman Sun Frankfurt Staff Engineer <Erik.Guttman@Sun.COM>
Subject: Re: [AAA-WG]: New Extension text in base protocol
To: pcalhoun@nasnfs.eng.sun.com
Cc: aaa-wg@merit.edu
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: +0KS2IESD7Cj1BnE9QMEgg==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4 SunOS 5.8 sun4m sparc 
Sender: owner-aaa-bof@merit.edu
Precedence: bulk


Pat,

> Below is the proposed text that I have added to the -02 candidate that
> describes what a Diameter extension is.
> 
> Please send any comments,

These comments concern only the new text's *style* not *content.*

> 2.3  Diameter Extensions
> 
>    As previously mentioned, the Diameter base protocol does not operate
>    on its own, but requires appplication-specific extensions, commonly
>    referred to as Diameter extensions. A Diameter extension is a

commonly referred to
->
referred to in this document as

>    17.3), while supporting the original extension. During the
>    capabilities exchange, a Diameter node could know whether it should
>    send

could know whether it should send
->
can determine whether to exchange messages using

>    the prorietary version, or the standards one, by inspecting the

the proprietary version, or the standards one, by
->
the proprietary or standard version of the extension by

Erik

._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._.
E r i k   G u t t m a n         SHORT msgs: 01728655497@d2-message.de
Sr Staff Engineer, Sun Microsystems       Email: erik.guttman@sun.com
Altrotstrasse 31, D-69190 Walldorf Germany   Mobile: +49 172 865 5497




From owner-aaa-bof@merit.edu  Mon Apr 23 05:45:18 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA02933
	for <aaa-archive@odin.ietf.org>; Mon, 23 Apr 2001 05:45:16 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 75C765DDA1; Mon, 23 Apr 2001 05:02:28 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 5A9945DE5B; Mon, 23 Apr 2001 05:02:28 -0400 (EDT)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by segue.merit.edu (Postfix) with ESMTP id 8F9045DDA1
	for <aaa-wg@merit.edu>; Mon, 23 Apr 2001 05:02:25 -0400 (EDT)
Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f3N92OO07437
	for <aaa-wg@merit.edu>; Mon, 23 Apr 2001 11:02:24 +0200 (MEST)
Received: FROM esealnt743.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Mon Apr 23 11:02:23 2001 +0200
Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <HA3D3FJ1>; Mon, 23 Apr 2001 11:02:22 +0200
Message-ID: <577066326047D41180AC00508B955DDA02C009B3@eestqnt104.es.eu.ericsson.se>
From: "Yolanda Garcia-Serrano (ECE)" <yolanda.garcia-serrano@ece.ericsson.se>
To: "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>
Subject: [AAA-WG]: Date: Mon, 23 Apr 2001 11:02:13 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Date: Mon, 23 Apr 2001 05:02:28 -0400 (EDT)

  
Hi, Pat and al. 
Here goes some questions/proposals for message forwarding and routing sections (5, and 12) of
base 02:

First of all: Why splitting the issue in two separate sections, 5.0 and 12.0. They are very closely
related, aren't there? To understand the hole thing, one should go to both sections, so I suggest to merge them. 
In that way, it would be clearer. E.g. it is weird to see Destination-FQDN and Destination-Realm AVP stated
one in section 5.3, and the other in 12.4.7

Section 5.0 Message Forwarding.-
-----------------------------------
Replace NAS by Diameter client or access-device

2nd paragraph:
   When a Diameter entity receives a Diameter message of type Request,
   Query or Indication that includes a Destination-FQDN AVP, and the
   host specified in the AVP can be contacted directly, the message MUST
   be forwarded to the host in question.
and 4th paragraph:
   Proxies receiving messages that contain the Destination-FQDN AVP MUST
   verify whether they are able to forward Diameter messages to the host
   specified in the AVP, and if so, MUST forward the message to the host
   in question. Otherwise, the message routing procedures described in
   section 12.0 MUST be followed.
both try to say the same thing, but last one is much clearer, as it includes what to do in case
Destination-FQDN AVP is not present. So, could we get rid of 2nd paragraph?

Regarding Responses, Answers, and Replys, I've looking carefully to the draft, and it seems consufing:
In section 3.0, when talking about the flags, there are following message types: Request, Query, Indication, 
Reply and Answer. But in section 3.3.2 is stated Query/Response. So it is confusing.
I understand the term "response" refers to the generic one, and it includes both
Reply and Answer, isn't it?. Is it possible to make this clear in the spec, so that all this terms are
coherently used? 
Furthermore, why is needed any distinction between them? If there is no strong argument maybe we can get
rid of Request/Query and Response/Reply/Answer difference, and simply talk about Requests and
Responses through all the spec.

Last paragraph in section 5.0 refers to mandatory AVPs for all messages
   This section defines the Diameter AVPs that MUST be added in all
   messages originated by a Diameter node (including nodes creating
   Response and Answer messages).
but Destination-FQDN is used in Indication, Reply and Answers only, so, it should not belong to this
chapter, or better, this last paragraph in section 5.0 can be removed, as it adds no information, but 
it can lead to confusion about this Destination-FQDN AVP.

Section 5.3 Destination-FQDN AVP
   The Destination-FQDN AVP (AVP Code 293) is of type OctetString,
   encoded in the UTF-8 [24] format, and contains the Fully Qualified
   Domain Name (FQDN) of the intended recipient of the message. This AVP
   MUST be present in all unsolicited server initiated messages. The
   value of the Destination-FQDN AVP is set to the value of the Origin-
   FQDN AVP found in a message from the intended target host.
Should instead, state: "This AVP MUST be present in all unsolicited server initiated 
messages, all reply and all answer messages." See example in section 12.1 and AVP tables
16.1 and 16.2.

Section 12.0 Message Routing
-----------------------------------

Section 12.1 Realm-based message routing
   Diameter request, query and indication message routing is done
   through the use of the realm portion of the Network Access Identifier
   (NAI) or via a realm encoded in an AVP (e.g. Origin-Realm,
   Destination-Realm), and an associated realm routing table (see
   section 12.1.1).

   When an NAI is used, the realm portion of the user@realm is used to
   perform the realm lookup. Diameter servers have a list of locally
   supported realms, and MAY have a list of externally supported realms.
   When a request, query or indication message is received that includes
   a realm that is not locally supported, the message is proxied to the
   Diameter entity configured in the "route" table.
NAI is not used to route, is it? It should state instead :
      Diameter request, query and indication message routing is done through 
      the use of Destination-FQDN or Destination-Realm and an associated realm 
     routing table (see section 12.1.1).

   When an NAI is used, the realm portion of the user@realm MUST be copied in
   Destination-Realm AVP, which is used to perform the realm lookup. Diameter servers 
   have a list of locally supported realms, and MAY have a list of externally 
   supported realms.
   When a request, query or indication message is received that includes
   a realm that is not locally supported, the message is proxied to the
   Diameter entity configured in the "route" table.


Example DIA1, DIA2, DIA3, on figure 2:
          (Origin-FQDN=dia1.mno.net)   (Origin-FQDN=dia1.mno.net)
          (Origin-Realm=mno.net)       (Origin-Realm=mno.net)
          (Destination-Realm=abc.com)  (Destination-Realm=abc.com)
          (Route-Record=dia1.mno.net)  (Route-Record=dia1.mno.net)
                                       (Route-Record=dia2.xyz.com)
      +------+      ------>      +------+      ------>      +------+
      |      |     (Request)     |      |      (Request)    |      |
      | DIA1 +-------------------+ DIA2 +-------------------+ DIA3 |
      |      |                   |      |                   |      |
      +------+      <------      +------+      <------      +------+
      mno.net      (Response)    xyz.com      (Response)     abc.com
          (Origin-Realm=abc.com)       (Origin-Realm=abc.com)
      (Destination-FQDN=dia1.mno.net)  (Destination-FQDN=dia1.mno.net)
                                       (Route-Record=dia2.xyz.com)

Route-Record=dia1.mno.net is missing in Responses from DIA3 to DIA2 and DIA2 to DIA1 (this
has already been posted in the list).
Is it not missing as well Origin-FQDN = dia3.abc.com in Responses from DIA3 to DIA2 and DIA2 to
DIA1, as Origin-FQDN is MANDATORY in ALL Diameter messages?
I miss as well how the Response is routed back to the Diameter client (which is not present in the drawing,
and it will made it clearer, as DI1 is not the originator of the message, but the first proxy). With Destination-FQDN
set to DIA1, how the response can reach the client ?
The following figure, may help (in case Client belong to same domain than DIA1):

(Origin-FQDN=client.mno.net)   (Origin-FQDN=client.mno.net)     (Origin-FQDN=client.mno.net)
(Origin-Realm=mno.net)         (Origin-Realm=mno.net)           (Origin-Realm=mno.net)
(Destination-Realm=abc.com)    (Destination-Realm=abc.com)      (Destination-Realm=abc.com)
                               (Route-Record=dia1.mno.net)      (Route-Record=dia1.mno.net)
                                                                (Route-Record=dia2.xyz.com)
  +------+  -------->  +------+    ------>     +------+    ------>    +------+
  | DIA  | (Request)   |      |   (Request)    |      |  (Request)    |      |
  |Client|-------------| DIA1 +----------------+ DIA2 +---------------+ DIA3 |
  |      |             |      |                |      |               |      |
  +------|  <--------  +------+   <-------     +------+   <-------    +------+
  mno.net  (Response)   mno.net  (Response)     xyz.com   (Response)   abc.com
    (Origin-FQDN=dia3.abc.com)    (Origin-FQDN=dia3.abc.com)        (Origin-FQDN=dia3.abc.com)
    (Origin-Realm=abc.com)        (Origin-Realm=abc.com)            (Origin-Realm=abc.com)
(Destin-FQDN=client.mno.net)      (Destin-FQDN=client.mno.net)      (Destin-FQDN=client.mno.net)
                                  (Route-Record=dia1.xyz.com)       (Route-Record=dia2.xyz.com)
                                                                    (Route-Record=dia1.xyz.com)


Section 12.2Proxy and Redirect Server handling of requests

   When a message of type request, query or indication is received by a
   proxy or redirect server, and it is determined that the request
   cannot be locally handled, the next hop for the request is determined
   in the following order:
      1. If the Destination-FQDN AVP is present, and the host specified
         in the AVP can be directly contacted, the message is forwarded
         to the host (see section 5.3 for more information), or
      2. If the Destination-Realm AVP is present, a routing table lookup
         is performed using the domain specific in the AVP.
Could be explicitly said in 2.  and 12.4.7 that Destination-Realm AVP is mandatory for all Request, Query
and Indication messages ?

   A message that does not contain any of the above AVPs MUST NOT be
   routed.  If the message in question cannot be handled locally, a
   Message-Reject-Ind is sent with the Result-Code AVP set to an
   appropriate error condition.
This paragraph can be removed, if it is said than Destination-Realm AVP is mandatory.

Section 12.4  Proxy Server
   Maintaining transaction state implies that a server keeps a copy of a
   request, which is then used when the corresponding response is
   received.  This could be done to apply local policies to the message,
   or simply for auditing purposes. Maintaining session state implies
   that a server keeps track of all "active" users. An active user is
   one that has been authorized for a particular service, and the server
   has not received any indication that the user has relinquished
   access.

Say instead:  Maintaining transaction state implies that a server keeps a 
      copy of a request or query which is then used when the corresponding response is
   received.


   A stateless proxy is one that does not maintain session state, but
   MUST maintain transaction state. Transaction state SHOULD be released
   after a request's corresponding response has been forwarded towards
   the recipient, and has been acknowledged by the underlying transport.
Isn't it strange to call a proxy which keeps transaction state "stateless"? Maybe the paragraph can be
reworded to explain that what is considered "stateless" is a proxy that mantains the minimum information
about the forwarded messages (e.g. it stores Hop-by-Hop identifier and restore it after receiving the
corresponding Responses, it may add Proxy-State AVP ...).

Section 12.4.1  Proxying Requests
Could we title it Proxying Requests, Querys and Indications, instead ?
Spelling: A Diameter server that proxies a message of type Request, Query or ...

Section 12.4.2  Proxying Responses
   A proxy server MUST only process messages of type Response or Answer
   whose last Route-Record AVP matches one of its addresses.
Say instead: A proxy server MUST only process messages of type Reply or Answer
   whose last Route-Record AVP matches one of its identities. (IP addreses are
not used for this application routing, but  FQDN/realm).

Section 12.6  Hiding Network Topology
   Stateful proxies forwarding requests to servers outside of their
   administrative domain MAY hide the internal network topology. Servers
   perform this by removing all Route-Record AVPs in the message, and
   maintains the Route-Record AVPs to add to the corresponding response.
   Such stateful servers MUST still add their own Route-Record AVP to
   the request prior to forwarding.
Why the paragraph refers only to stateful proxies? I think it could also apply to stateless ones, if
we consider a proxy server including a Proxy-State as stateless.


Section 12.7  Loop Detection
   When a Diameter Proxy or Redirect server receives a message of type
   Request, Query or Indication, it MUST examine all Route-Record AVPs
   in the message to determine whether such an AVP already exists with
   the local server's identity. If an AVP with the local host's identity
   is found in the request, it is an indication that the message is
   being looped through the same set of proxies. When such an event
   occurs, the Diameter server that detects the loop returns a response
   with the Result-Code AVP set to DIAMETER_LOOP_DETECTED.

Instead of returning a response (this is impossible for Indications), I think it should say "the Diameter
server that detects the loop issues a Message-Reject-Ind message with the 
Result-Code AVP set to DIAMETER_LOOP_DETECTED."

Last one: Has it sense try to detect loops also for Reply/Answer messages? Say a loop is not properly
detected in an upstream Diameter message. Then, the same loop is going to happen for its corresponding
downstream response. So, maybe it would be more robust try to detect it as well for responses.
If you agree, it should be mentioned in this section.


BR
	/Yolanda Garcia




From owner-aaa-bof@merit.edu  Mon Apr 23 06:52:41 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA03275
	for <aaa-archive@odin.ietf.org>; Mon, 23 Apr 2001 06:52:41 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id BB9685DDAF; Mon, 23 Apr 2001 06:52:14 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id AAB195DD96; Mon, 23 Apr 2001 06:52:14 -0400 (EDT)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by segue.merit.edu (Postfix) with ESMTP id AB7095DD8C
	for <aaa-wg@merit.edu>; Mon, 23 Apr 2001 06:52:12 -0400 (EDT)
Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f3NAqBN21904
	for <aaa-wg@merit.edu>; Mon, 23 Apr 2001 12:52:11 +0200 (MEST)
Received: FROM esealnt743.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Mon Apr 23 12:52:10 2001 +0200
Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <HA3D3MSL>; Mon, 23 Apr 2001 12:52:09 +0200
Message-ID: <577066326047D41180AC00508B955DDA01D7FFA6@eestqnt104.es.eu.ericsson.se>
From: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>
To: "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>,
        "'pcalhoun@eng.sun.com'" <pcalhoun@eng.sun.com>
Cc: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>
Subject: [AAA-WG]: Comments on sections 9-10 of draft-ietf-aaa-diameter-02.txt
Date: Mon, 23 Apr 2001 12:52:02 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Hi Pat,

Some comments on sections 9 and 10 of the draft-ietf-aaa-diameter-02.txt document.

1) I would like to see the content of section 9 and 10 in the same section.
The way they are structured, it would be very easy to merge them and have
a nice introduction to error handling common to both.

2) In 9.1, the message format should also include [Session-ID]. And should the 
DSI-Event be in mandatory in the message, i.e. {}???

3) In 16.1, the Command AVP table says that the Destination-Realm AVP should
be included in the DSI message. So my question is whether or not the routing
table should be used for sending the DSI?, or should the reply IP address and
port be used instead? In fact, if the routing table is used, I guess that the
Destination-FQDN should be used instead, since the Route-Record AVP contains
the FQDN of the proxy, right? The FQDN routing would be more consistent with
the protocol I think.

4) In 16.1, the AVP Session-ID should be 0-1 in the DSI column.

5) In 9.1.1.2, replace "Redirect Notification" by "Redirect Event".

6) In 9.1.1.4, replace DIAMETER_INVALID_RECORD_ROUTE by DIAMETER_INVALID_ROUTE_RECORD.
Also, I think that this event should be in the Transient section, since the
permanent section defines events for which messages can be forwarded to another
node without any modification to its content, which I don't think can be possible
in this case.

7) In 9.1.1.4, replace DIAMETER_ERROR_TOO_BUSY by DIAMETER_TOO_BUSY.

8) In 9.1.1.4, what would be the difference between sending DIAMETER_TOO_BUSY
and DIAMETER_CANNOT_PROCESS_IN_TIME? I don't really see the point of making
a distinction between them.

9) In 10.1, [Error-Message] should be added. It should also appear in 16.1 as
0-1 in the MRI column.

10) In 10.1, [Failed-Vendor-Id] should be added.

11) In 10.1, the * [Destination-Realm], I guess that the * should be 
removed.

12) In 10.1, the {Destination-FQDN} should be added. In 16.1, it should
say 1 instead of 0+. BTW, what does it mean for the STR to have several
Destination-FQDN (as indicated by the 0+ in section 16.1).

13) In 10.1, the [Failed-AVP] should have *. In 16.1, it should be 0+.

14) In 10.1.1, the reference to the table should be to section 16.1,
instead of 14.0.

15) In 10.1.3, is it the Failed-Command-Code AVP or the Failed-Vendor-Id AVP?

16) There is no section 10.2.3, which means that section 10.2.4 should be 10.2.3.
The same applies for 10.2.5

17) In 10.2.4, I think that the DIAMETER_NO_END_2_END_SECURITY error should
be better named DIAMETER_END_2_END_SECURITY, since it indicates that e2e is
used, which is the problem.

18) In 10.2.5, under the description of the DIAMETER_LOOP_DETECTED error,
it says that no further attempts should be done until it is fixed. What is 
the intention behind that? How should it be handled?

19) In 10.4, I guess it should NOT be mandatory
in the MRI, since the Origin should be the default sender of the Result-Code.
It should be only be set if the Result-Code is modified by a node on the way.
16.1 should be modified to reflect 0-1 instead of 1.

20) In 10.4, the reference to the NAI should be replaced by the "FQDN".

Hope this helps,
Martin




From owner-aaa-bof@merit.edu  Mon Apr 23 11:01:54 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA05244
	for <aaa-archive@odin.ietf.org>; Mon, 23 Apr 2001 11:01:54 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 91ECD5DDE9; Mon, 23 Apr 2001 06:54:08 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 800DC5DD96; Mon, 23 Apr 2001 06:54:08 -0400 (EDT)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by segue.merit.edu (Postfix) with ESMTP id 73D0B5DD8C
	for <aaa-wg@merit.edu>; Mon, 23 Apr 2001 06:54:06 -0400 (EDT)
Received: from esealnt461 (esealnt461.al.sw.ericsson.se [153.88.251.61])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f3NAs5N23595
	for <aaa-wg@merit.edu>; Mon, 23 Apr 2001 12:54:05 +0200 (MEST)
Received: FROM esealnt743.al.sw.ericsson.se BY esealnt461 ; Mon Apr 23 12:54:04 2001 +0200
Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <HA3D3MV5>; Mon, 23 Apr 2001 12:54:03 +0200
Message-ID: <577066326047D41180AC00508B955DDA02C009B4@eestqnt104.es.eu.ericsson.se>
From: "Yolanda Garcia-Serrano (ECE)" <yolanda.garcia-serrano@ece.ericsson.se>
To: pcalhoun@nasnfs.eng.sun.com, "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>
Subject: [AAA-WG]: Another routing detail
Date: Mon, 23 Apr 2001 12:53:57 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA05244

Hi, again

I've forgotten one issue in my last e-mail about routing. Here goes:

Section 16.1:
I think Destination-FQDN and Destination-Realm should be 1 for DWR message.

BR
	/Yolanda García



From owner-aaa-bof@merit.edu  Mon Apr 23 12:46:34 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06797
	for <aaa-archive@odin.ietf.org>; Mon, 23 Apr 2001 12:46:34 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 515775DE03; Mon, 23 Apr 2001 11:46:33 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 3A83D5DE0B; Mon, 23 Apr 2001 11:46:33 -0400 (EDT)
Received: from zsc4s001.baynetworks.com (unknown [134.177.3.62])
	by segue.merit.edu (Postfix) with ESMTP id B9B0A5DE03
	for <aaa-wg@merit.edu>; Mon, 23 Apr 2001 11:46:31 -0400 (EDT)
Received: from zsc4c000.us.nortel.com by zsc4s001.baynetworks.com;
          Mon, 23 Apr 2001 08:39:23 -0700
Received: from zbl6c016.corpeast.baynetworks.com ([132.245.205.66]) 
          by zsc4c000.us.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) 
          id JH6J859R; Mon, 23 Apr 2001 08:46:00 -0700
Received: from mitton.nortelnetworks.com (47.16.86.121 [47.16.86.121]) 
          by zbl6c016.corpeast.baynetworks.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) 
          id HJCW5KKT; Mon, 23 Apr 2001 11:45:55 -0400
Message-Id: <4.3.2.7.2.20010423112356.00df5e80@ZBL6C016.corpeast.baynetworks.com>
X-Sender: dmitton@ZBL6C016.corpeast.baynetworks.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 23 Apr 2001 11:44:53 -0400
To: aaa-wg <aaa-wg@merit.edu>
From: "David Mitton" <dmitton@nortelnetworks.com>
Subject: [AAA-WG]: AAA WG Interim Meeting Announcment
Cc: aboba@internaut.com, Randy Bush <randy@psg.com>,
        "Wijnen, Bert (Bert)" <bwijnen@lucent.com>, scoya@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Orig: <dmitton@nortelnetworks.com>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

AAA Working Group Interim Meeting
Thurs & Friday, May 23-24th, Santa Clara, CA

The meeting will be held at the Nortel Networks facility (previously 
Synoptics/Bay Networks) 4401 Great America Parkway, Santa Clara, CA 95054.

The meeting will be in the "Orientation Room", Building SC1, on the first 
floor.

The facility is 4 miles north of San Jose Airport
and 25 miles south of San Francisco Airport off US 101.
(be aware that traffic on 101 will jam during rush hours)

The campus is next to Great America amusement park and the Santa Clara 
convention center.  There are a number of hotels of various levels near 
by.  Some are in walking distance.

If you have any questions, email me dmitton@nortelnetworks.com
(if no response within 24hrs, try dave@mitton.com)

- Dave.

-------------------
Driving Directions

 From San Francisco International Airport
- 101 South, 25 miles
- Exit Great America Parkway, turn left onto Great America Parkway, 1/4 mile
- Nortel Networks - SC1 is located at the corner of Great America Parkway & 
Mission College Blvd

 From San Jose International Airport
- 101 North, 4 miles
- Exit Great America Parkway, turn right onto Great America Parkway, 1/4 mile
- Nortel Networks - SC1 is located at the corner of Great America Parkway & 
Mission College Blvd



---------------------------------------------------------------
David Mitton                                  ESN: 248-4570
Advisor, Nortel Networks                      978-288-4570 Direct
Wireless Solutions, IP Mobility
Billerica, MA 01821                    dmitton@nortelnetworks.com




From owner-aaa-bof@merit.edu  Mon Apr 23 14:05:09 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08744
	for <aaa-archive@odin.ietf.org>; Mon, 23 Apr 2001 14:05:09 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 6A1EB5DE85; Mon, 23 Apr 2001 14:03:08 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 57CD45DE84; Mon, 23 Apr 2001 14:03:08 -0400 (EDT)
Received: from motgate.mot.com (motgate.mot.com [129.188.136.100])
	by segue.merit.edu (Postfix) with ESMTP id EA4925DDA2
	for <aaa-wg@merit.edu>; Mon, 23 Apr 2001 14:03:06 -0400 (EDT)
Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate.mot.com (motgate 2.1) with ESMTP id LAA19943 for <aaa-wg@merit.edu>; Mon, 23 Apr 2001 11:03:06 -0700 (MST)]
Received: [from il35exm01.cig.mot.com (IL35EXM01.cig.mot.com [160.19.16.101]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id LAA01635 for <aaa-wg@merit.edu>; Mon, 23 Apr 2001 11:03:06 -0700 (MST)]
Received: by IL35EXM01.cig.mot.com with Internet Mail Service (5.5.2653.19)
	id <2RXQR3CY>; Mon, 23 Apr 2001 13:03:05 -0500
Message-ID: <35DBB8B7AC89D4118E98009027B1009B0ECE96@IL27EXM10.cig.mot.com>
From: Cain Brian-BCAIN1 <Brian.Cain@motorola.com>
To: "'James Kempf'" <James.Kempf@Sun.COM>,
        "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>
Subject: [AAA-WG]: RE: API, latest draft
Date: Mon, 23 Apr 2001 13:03:05 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

James,

	Inlined comments below.

...
> >the Base protocol's dictionary.  And it would probably be 
> necessary to have
> >the other dictionaries in order to distinguish between a 
> case where the
> >library should reject a message with response 
> "EXTENSION_NOT_SUPPORTED" or
> >"UNKNOWN_COMMAND".  
> >
> 
> I agree that all sessions will need to use the base 
> protocol's dictionary.
> 
> So it sounds like the issue is the following. If a command shows up
> for a given session but the command is known in a dictionary of
> another session, this design will return an UNKNOWN_COMMAND when
> it should return an EXTENSION_NOT_SUPPORTED, is that it? 

Perhaps.  It would certainly depend on the implementation of the API (despite the passed in Dictionary, the implementation could always make all of the dictionaries global, and still conform to the API).  

> The intent of including the dictionary in this fashion was to allow
> Diameter applications to running in the same virtual machine
> to handle separate applications, and so that they could define
> their commands in separate configuration files. I'm not strongly
> tied to this design, but I had thought it might be simpler from
> the application's perspective. It sounds like you would rather
> simply have a global command dictionary?

I'm not opposed to having separate configuration files, or separate command dictionaries, as long as the library knows about all of them, and is told about them only once.  If we could setup all of the dictionaries at initialization time (while still allowing for runtime updates to the dictionaries), it would probably be even simpler for the application.  

Would it be possible to use some term other than "session" for methods like startSession(), etc.?  The overloading of this term is responsible for quite a bit of confusion (on my part), I seem to always get this confused with the "User" sessions described in 11.0 of the Base draft.  

Each application would probably confine itself to messaging regarding one extension, which I think is why we can get away with one dictionary, right?  I guess I'm assuming that only one extension could be present in one dictionary, which may not be the case?  I was just trying to think of a situation where one dictionary would not suffice.  Also, I just figured that since AAAExtensionDescriptor has a copy of all the registered extensions (and their registered commands & AVPs), the library already has access to all the dictionaries it needs.

I don't think that the library would be able to determine which session an incoming command belongs to without parsing it first.  Of course, to parse it, the library would need a dictionary, but they would all be associated with their particular session, right?

> >(from 4.3.6.4)
> >>      public AAACommandDescriptor
> >>        registerCommand(long code,
> >>                        long vendorCode,
> >>                        java.lang.String name,
> >>                        java.util.Map AVPDictionary,
> >>                        java.util.Map disallowedAVPDictionary)
> >
> >Hmm..This is the only place I could see an AVP dictionary 
> being input into
> >the library.  I saw no mention of a property for the AVP 
> dictionary file.
> 
> Typically, the AVP dictionary is defined as part of the 
> command definition
> configuration file. I believe there has been agreement by the group

Okay, this answers several questions, including the AVP code->type resolution issue below.  

> that AVPs are standardized as part of extensions, not 
> separately. Thus,
> it seems to make sense to include them as part of the commands.
> 
> In addition, the API has to provide a way for programmatic definition
> of commands, separate from parsing the command definition file. This
> method is defined for the latter. The Java code implementing an
> extension that wants to build up a dictionary would do it by
> building up the AVP dictionary programmaticaly, then building up
> the command, etc.

I guess I didn't consider that as an option.  You're right, there could be good reasons for someone to not want a static configuration file.

> >I've got a couple of issues with this.  First, there is no 
> correlation
> >between AVP code and type.  This is the bare minimum 
> requirement for an AVP
> 
> I guess I don't understand. The AVPs and AVPDescriptors are 
> indexed by name, and 
> the AVPDescriptor object contains a type indicator 
> (AVPDescriptor.getType()). 
> Would you rather have them indexed by code?

You have answered my question on this already, but I'll clarify what I was trying to get across.  From the library's perspective, there must be some fundamental correlation between an AVP and its code.  Its code is the only key that the library should really care about (all others are a usability bonus), as this will be a required component of parsing AVPs (and Commands, for that matter).  As you can see above, I thought that there were distinct AVP and command dictionary files, and the AVP dictionary had been omitted, so I saw no way for the library to get the information that it needed to resolve an AVP from its code.  The issue is moot now.

...
> >(I see that as pretty unsatisfactory).  That much aside, I 
> really prefer
> >configuration files for AVP and Command dictionaries over 
> methods.  I think
> >that having both serves only confusion.  In place of methods like
> >"registerXxxxx()", a hierarchy of files could be established 
> to register
> >Extensions, Commands, and AVPs.
> >
> 
> I agree that configuration files are preferable, but I think we need
> to keep open the possibility of programmatic update. In addition,
> the library implementation itself can use the programmatic 
> interface when 
> parsing the configuration files.

Okay, sure.  I was thinking "if we don't need both, we can eliminate one", but if we need both, then we need both.

-Brian



From owner-aaa-bof@merit.edu  Mon Apr 23 14:22:15 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09224
	for <aaa-archive@odin.ietf.org>; Mon, 23 Apr 2001 14:22:15 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 5805E5DD93; Mon, 23 Apr 2001 14:21:50 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 44C555DD9A; Mon, 23 Apr 2001 14:21:50 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id BCA655DD93
	for <aaa-wg@merit.edu>; Mon, 23 Apr 2001 14:21:48 -0400 (EDT)
Received: from heliopolis.eng.sun.com ([152.70.1.39])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA02192;
	Mon, 23 Apr 2001 11:21:45 -0700 (PDT)
Received: from srmtv29a (srmtv29a [152.70.1.41])
	by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id LAA26389;
	Mon, 23 Apr 2001 11:21:44 -0700 (PDT)
Message-Id: <200104231821.LAA26389@heliopolis.eng.sun.com>
Date: Mon, 23 Apr 2001 11:21:44 -0700 (PDT)
From: James Kempf <James.Kempf@Sun.COM>
Reply-To: James Kempf <James.Kempf@Sun.COM>
Subject: [AAA-WG]: RE: API, latest draft
To: James.Kempf@Sun.COM, aaa-wg@merit.edu, Brian.Cain@motorola.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: fHcvr19xsIxjdsw10VCohw==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Hi Brian,

Again, thanx for your comments, they have been most helpful in refining
the design.

>I'm not opposed to having separate configuration files, or separate command 
dictionaries, as long as the library knows about all of them, and is told about 
them only once.  If we could setup all of the dictionaries at initialization 
time (while still allowing for runtime updates to the dictionaries), it would 
probably be even simpler for the application.  

I think it would probably be easier in that case to just have a single
command file. The whole point of having separate files is so that
separate applications that don't know about each other can set up
their command sets. This purpose would be defeated by requiring all
the command sets to be registered at initialization time.

>
>Would it be possible to use some term other than "session" for methods like 
startSession(), etc.?  The overloading of this term is responsible for quite a 
bit of confusion (on my part), I seem to always get this confused with the 
"User" sessions described in 11.0 of the Base draft. 

The sessions managed by the session manager *are* exactly
the user sessions in Chapter 11.0 of the Base draft. The only difference is
that they are being identified in the VM by a small integer identifer rather
than a session name. In fact, in the latest draft of the API, there is even a 
method,  SessionManager.getNetworkSessionId(), that is used to get the Section 
11.2 network session identifier corresponding to a Diameter User session.

>
>Each application would probably confine itself to messaging regarding one 
extension, which I think is why we can get away with one dictionary, right?  I 
guess I'm assuming that only one extension could be present in one dictionary, 
which may not be the case?  I was just trying to think of a situation where one 
dictionary would not suffice.  Also, I just figured that since 
AAAExtensionDescriptor has a copy of all the registered extensions (and their 
registered commands & AVPs), the library already has access to all the 
dictionaries it needs.
>
>I don't think that the library would be able to determine which session an 
incoming command belongs to without parsing it first.  Of course, to parse it, 
the library would need a dictionary, but they would all be associated with their 
particular session, right?

Let's just go back to a single dictionary. It's simpler.


>You have answered my question on this already, but I'll clarify what I was 
trying to get across.  From the library's perspective, there must be some 
fundamental correlation between an AVP and its code.  Its code is the only key 
that the library should really care about (all others are a usability bonus), as 
this will be a required component of parsing AVPs (and Commands, for that 
matter).  As you can see above, I thought that there were distinct AVP and 
command dictionary files, and the AVP dictionary had been omitted, so I saw no 
way for the library to get the information that it needed to resolve an AVP from 
its code.  The issue is moot now.

But I still think you have made a point. The spec currently requires
the AVPDescriptor dictionary for a command to be indexed by the
AVP name. As you have pointed out, it would be better to index
it by code, so that it can be retrieved with a single hash when
parsing a command. The command dictionary is already defined so
that it can be indexed by code (actually, the interface is a method
so it can be indexed however you want, but by code would probably
be the most efficient).

		jak




From owner-aaa-bof@merit.edu  Mon Apr 23 14:38:48 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09778
	for <aaa-archive@odin.ietf.org>; Mon, 23 Apr 2001 14:38:47 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id D13FA5DE16; Mon, 23 Apr 2001 14:37:27 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id BAE585DEBD; Mon, 23 Apr 2001 14:37:27 -0400 (EDT)
Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10])
	by segue.merit.edu (Postfix) with ESMTP id 4CF945DE16
	for <aaa-wg@merit.edu>; Mon, 23 Apr 2001 14:37:26 -0400 (EDT)
Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate2.mot.com (motgate2 2.1) with ESMTP id LAA20024 for <aaa-wg@merit.edu>; Mon, 23 Apr 2001 11:37:25 -0700 (MST)]
Received: [from il75exm04.cig.mot.com ([136.182.110.113]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id LAA15489 for <aaa-wg@merit.edu>; Mon, 23 Apr 2001 11:31:48 -0700 (MST)]
Received: by IL75EXM04 with Internet Mail Service (5.5.2653.19)
	id <JK1JXKTB>; Mon, 23 Apr 2001 13:37:24 -0500
Message-ID: <35DBB8B7AC89D4118E98009027B1009B0ECE97@IL27EXM10.cig.mot.com>
From: Cain Brian-BCAIN1 <Brian.Cain@motorola.com>
To: "'James Kempf'" <James.Kempf@Sun.COM>, aaa-wg@merit.edu
Subject: [AAA-WG]: RE: API, latest draft
Date: Mon, 23 Apr 2001 13:37:24 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-aaa-bof@merit.edu
Precedence: bulk


> >I'm not opposed to having separate configuration files, or 
> separate command 
> dictionaries, as long as the library knows about all of them, 
> and is told about 
> them only once.  If we could setup all of the dictionaries at 
> initialization 
> time (while still allowing for runtime updates to the 
> dictionaries), it would 
> probably be even simpler for the application.  
> 
> I think it would probably be easier in that case to just have a single
> command file. The whole point of having separate files is so that
> separate applications that don't know about each other can set up
> their command sets. This purpose would be defeated by requiring all
> the command sets to be registered at initialization time.

Alrighty, sounds good to me.

> >
> >Would it be possible to use some term other than "session" 
> for methods like 
> startSession(), etc.?  The overloading of this term is 
> responsible for quite a 
> bit of confusion (on my part), I seem to always get this 
> confused with the 
> "User" sessions described in 11.0 of the Base draft. 
> 
> The sessions managed by the session manager *are* exactly
> the user sessions in Chapter 11.0 of the Base draft. The only 
> difference is
> that they are being identified in the VM by a small integer 
> identifer rather
> than a session name. In fact, in the latest draft of the API, 
> there is even a 
> method,  SessionManager.getNetworkSessionId(), that is used 
> to get the Section 
> 11.2 network session identifier corresponding to a Diameter 
> User session.

Okay.  I got confused because I was trying to think of a case where you
would call startSession() infrequently (and thus would provide similar
dictionaries infrequently).  I assumed that maybe session was being used in
the sense of "Session == Transport Connection".  I'm back on track now.

...
> 
> >You have answered my question on this already, but I'll 
> clarify what I was 
> trying to get across.  From the library's perspective, there 
> must be some 
> fundamental correlation between an AVP and its code.  Its 
> code is the only key 
> that the library should really care about (all others are a 
> usability bonus), as 
> this will be a required component of parsing AVPs (and 
> Commands, for that 
> matter).  As you can see above, I thought that there were 
> distinct AVP and 
> command dictionary files, and the AVP dictionary had been 
> omitted, so I saw no 
> way for the library to get the information that it needed to 
> resolve an AVP from 
> its code.  The issue is moot now.
> 
> But I still think you have made a point. The spec currently requires
> the AVPDescriptor dictionary for a command to be indexed by the
> AVP name. As you have pointed out, it would be better to index
> it by code, so that it can be retrieved with a single hash when
> parsing a command. The command dictionary is already defined so
> that it can be indexed by code (actually, the interface is a method
> so it can be indexed however you want, but by code would probably
> be the most efficient).

Ok, sounds good.

-Brian



From owner-aaa-bof@merit.edu  Mon Apr 23 14:45:04 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10138
	for <aaa-archive@odin.ietf.org>; Mon, 23 Apr 2001 14:45:04 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 466BC5DEA4; Mon, 23 Apr 2001 14:44:04 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 2ED6D5DF1E; Mon, 23 Apr 2001 14:44:04 -0400 (EDT)
Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10])
	by segue.merit.edu (Postfix) with ESMTP id 203095DEA4
	for <aaa-wg@merit.edu>; Mon, 23 Apr 2001 14:44:01 -0400 (EDT)
Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (motgate2 2.1) with ESMTP id LAA24333 for <aaa-wg@merit.edu>; Mon, 23 Apr 2001 11:43:59 -0700 (MST)]
Received: [from il35exm01.cig.mot.com (IL35EXM01.cig.mot.com [160.19.16.101]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id LAA05964 for <aaa-wg@merit.edu>; Mon, 23 Apr 2001 11:43:59 -0700 (MST)]
Received: by IL35EXM01.cig.mot.com with Internet Mail Service (5.5.2653.19)
	id <2RXQRPCG>; Mon, 23 Apr 2001 13:43:59 -0500
Message-ID: <35DBB8B7AC89D4118E98009027B1009B0ECE99@IL27EXM10.cig.mot.com>
From: Cain Brian-BCAIN1 <Brian.Cain@motorola.com>
To: "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>
Subject: [AAA-WG]: Peer State Machine typo?
Date: Mon, 23 Apr 2001 13:43:58 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

This is being sent on behalf of Panos Thomas (Panos.Thomas@motorola.com).  Panos seems to be having trouble getting his messages through to the list.  Are there any current issues w/the list?  Is Pat the maintainer?


-----Original Message-----
From: Thomas Panagiotis-PTHOMAS1 
Sent: Friday, April 20, 2001 1:24 PM
To: Cain Brian-BCAIN1
Subject: FW: Peer State Machine typo?


I sent it again. Let's see if it'll get though this time.


-----Original Message-----
From: Thomas Panagiotis-PTHOMAS1 
Sent: 20 April 2001 13:05
To: 'aaa-wg@merit.edu'
Subject: Peer State Machine typo?


Hi,

I apologize if this has already been discussed on the list.

Shouldn't, 

     8.0 Peer State Machine
     ...
     I-Open  Send-Message       I-Snd-Non-DRI     R-Open
             I-Rcv-Non-DRI      Process           I-Open
             R-WatchDog-Timer   R-Snd-DWR         R-Open
             R-Rcv-DWA          Process-DWA       R-Open
             Stop               I-Disc            Closed
             I-Peer-Disc        I-Disc            Closed
             I-Rcv-DRI          Error             Closed
             R-Rcv-Conn-Req     R-Snd-Conn-Nack   I-Open

be,

 --> I-Open  Send-Message       I-Snd-Non-DRI     I-Open  <--
             I-Rcv-Non-DRI      Process           I-Open
 -->         I-WatchDog-Timer   I-Snd-DWR         I-Open  <--
 -->         I-Rcv-DWA          Process-DWA       I-Open  <--
             Stop               I-Disc            Closed
             I-Peer-Disc        I-Disc            Closed
             I-Rcv-DRI          Error             Closed
 -->         I-Rcv-Conn-Req     I-Snd-Conn-Nack   I-Open  <--

Thanks!

-Panos



From owner-aaa-bof@merit.edu  Mon Apr 23 16:10:19 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11907
	for <aaa-archive@odin.ietf.org>; Mon, 23 Apr 2001 16:10:18 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id B54515DDD9; Mon, 23 Apr 2001 16:09:52 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id A311C5DDAB; Mon, 23 Apr 2001 16:09:52 -0400 (EDT)
Received: from zsc4s001.baynetworks.com (unknown [134.177.3.62])
	by segue.merit.edu (Postfix) with ESMTP id 9C9245DDA7
	for <aaa-wg@merit.edu>; Mon, 23 Apr 2001 16:09:46 -0400 (EDT)
Received: from zsc4c000.us.nortel.com by zsc4s001.baynetworks.com;
          Mon, 23 Apr 2001 13:02:01 -0700
Received: from zbl6c016.corpeast.baynetworks.com ([132.245.205.66]) 
          by zsc4c000.us.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) 
          id JH6J9DQZ; Mon, 23 Apr 2001 13:08:46 -0700
Received: from mitton.nortelnetworks.com (47.16.86.121 [47.16.86.121]) 
          by zbl6c016.corpeast.baynetworks.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) 
          id HJCW5KRP; Mon, 23 Apr 2001 16:08:45 -0400
Message-Id: <4.3.2.7.2.20010423160721.049e4ee0@ZBL6C016.corpeast.baynetworks.com>
X-Sender: dmitton@ZBL6C016.corpeast.baynetworks.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Mon, 23 Apr 2001 16:10:30 -0400
To: aaa-wg <aaa-wg@merit.edu>
From: "David Mitton" <dmitton@nortelnetworks.com>
Subject: [AAA-WG]: AAA WG Interim Meeting Announcement (correction)
Cc: aboba@internaut.com, Randy Bush <randy@psg.com>,
        "Wijnen, Bert (Bert)" <bwijnen@lucent.com>, scoya@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Orig: <dmitton@nortelnetworks.com>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

[the dates in the earlier msg were inconsistent]

AAA Working Group Interim Meeting
Thurs & Friday, May 24-25th, Santa Clara, CA

The meeting will be held at the Nortel Networks facility (previously 
Synoptics/Bay Networks) 4401 Great America Parkway, Santa Clara, CA 95054.

An agenda will be issued at a later time.  The goal of the meeting is a 
complete review/edit of the base Diameter drafts for WG and IETF Last Call.

The meeting will be in the "Orientation Room", Building SC1, on the first 
floor.

The facility is 4 miles north of San Jose Airport
and 25 miles south of San Francisco Airport off US 101.
(be aware that traffic on 101 will jam during rush hours)

The campus is next to Great America amusement park and the Santa Clara 
convention center.  There are a number of hotels of various levels near 
by.  Some are in walking distance.

If you have any questions, email me dmitton@nortelnetworks.com
(if no response within 24hrs, try dave@mitton.com)

- Dave.

-------------------
Driving Directions

 From San Francisco International Airport
- 101 South, 25 miles
- Exit Great America Parkway, turn left onto Great America Parkway, 1/4 mile
- Nortel Networks - SC1 is located at the corner of Great America Parkway & 
Mission College Blvd

 From San Jose International Airport
- 101 North, 4 miles
- Exit Great America Parkway, turn right onto Great America Parkway, 1/4 mile
- Nortel Networks - SC1 is located at the corner of Great America Parkway & 
Mission College Blvd


---------------------------------------------------------------
David Mitton                                  ESN: 248-4570
Advisor, Nortel Networks                      978-288-4570 Direct
Wireless Solutions, IP Mobility
Billerica, MA 01821                    dmitton@nortelnetworks.com




From owner-aaa-bof@merit.edu  Mon Apr 23 17:17:40 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13019
	for <aaa-archive@odin.ietf.org>; Mon, 23 Apr 2001 17:17:40 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id B14A95DDAB; Mon, 23 Apr 2001 16:28:45 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 987945DDA7; Mon, 23 Apr 2001 16:28:45 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id B2CE65DE17
	for <aaa-wg@merit.edu>; Mon, 23 Apr 2001 16:28:42 -0400 (EDT)
Received: from gwzpc (sjc-vpn-597.cisco.com [10.21.66.85]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id NAA06864; Mon, 23 Apr 2001 13:19:47 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "David Mitton" <dmitton@nortelnetworks.com>, "aaa-wg" <aaa-wg@merit.edu>
Cc: <aboba@internaut.com>, "Randy Bush" <randy@psg.com>,
        "Wijnen, Bert (Bert)" <bwijnen@lucent.com>, <scoya@ietf.org>
Subject: RE: [AAA-WG]: AAA WG Interim Meeting Announcment
Date: Mon, 23 Apr 2001 13:19:30 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPIEFGDHAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <4.3.2.7.2.20010423112356.00df5e80@ZBL6C016.corpeast.baynetworks.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

David Mitton [mailto:dmitton@nortelnetworks.com] writes:

> AAA Working Group Interim Meeting
> Thurs & Friday, May 23-24th, Santa Clara, CA

The Thursday and Friday of that week are the 24th & 25th.  Which is it, Th &
F or 23 & 24?

>
> The meeting will be held at the Nortel Networks facility (previously
> Synoptics/Bay Networks) 4401 Great America Parkway, Santa Clara, CA 95054.
>
> The meeting will be in the "Orientation Room", Building SC1, on the first
> floor.
>
> The facility is 4 miles north of San Jose Airport
> and 25 miles south of San Francisco Airport off US 101.
> (be aware that traffic on 101 will jam during rush hours)
>
> The campus is next to Great America amusement park and the Santa Clara
> convention center.  There are a number of hotels of various levels near
> by.  Some are in walking distance.
>
> If you have any questions, email me dmitton@nortelnetworks.com
> (if no response within 24hrs, try dave@mitton.com)
>
> - Dave.
>
> -------------------
> Driving Directions
>
>  From San Francisco International Airport
> - 101 South, 25 miles
> - Exit Great America Parkway, turn left onto Great America
> Parkway, 1/4 mile
> - Nortel Networks - SC1 is located at the corner of Great America
> Parkway &
> Mission College Blvd
>
>  From San Jose International Airport
> - 101 North, 4 miles
> - Exit Great America Parkway, turn right onto Great America
> Parkway, 1/4 mile
> - Nortel Networks - SC1 is located at the corner of Great America
> Parkway &
> Mission College Blvd
>
>
>
> ---------------------------------------------------------------
> David Mitton                                  ESN: 248-4570
> Advisor, Nortel Networks                      978-288-4570 Direct
> Wireless Solutions, IP Mobility
> Billerica, MA 01821                    dmitton@nortelnetworks.com
>
>
>




From owner-aaa-bof@merit.edu  Tue Apr 24 00:15:29 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA19297
	for <aaa-archive@odin.ietf.org>; Tue, 24 Apr 2001 00:15:29 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id F0DA85DD9C; Tue, 24 Apr 2001 00:14:51 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id D86835DD9F; Tue, 24 Apr 2001 00:14:51 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 560C85DD9C
	for <aaa-wg@merit.edu>; Tue, 24 Apr 2001 00:14:50 -0400 (EDT)
Received: from gwzpc (sjc-vpn-519.cisco.com [10.21.66.7]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id VAA08297; Mon, 23 Apr 2001 21:12:09 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "David Mitton" <dmitton@nortelnetworks.com>, "aaa-wg" <aaa-wg@merit.edu>
Cc: <aboba@internaut.com>, "Randy Bush" <randy@psg.com>,
        "Wijnen, Bert (Bert)" <bwijnen@lucent.com>, <scoya@ietf.org>
Subject: RE: [AAA-WG]: AAA WG Interim Meeting Announcement (correction)
Date: Mon, 23 Apr 2001 21:08:30 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPGEGADHAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <4.3.2.7.2.20010423160721.049e4ee0@ZBL6C016.corpeast.baynetworks.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Are you aware that that is Memorial Day week-end?

> -----Original Message-----
> From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf
> Of David Mitton
> Sent: Monday, April 23, 2001 1:11 PM
> To: aaa-wg
> Cc: aboba@internaut.com; Randy Bush; Wijnen, Bert (Bert); scoya@ietf.org
> Subject: [AAA-WG]: AAA WG Interim Meeting Announcement (correction)
>
>
> [the dates in the earlier msg were inconsistent]
>
> AAA Working Group Interim Meeting
> Thurs & Friday, May 24-25th, Santa Clara, CA
>
> The meeting will be held at the Nortel Networks facility (previously
> Synoptics/Bay Networks) 4401 Great America Parkway, Santa Clara, CA 95054.
>
> An agenda will be issued at a later time.  The goal of the meeting is a
> complete review/edit of the base Diameter drafts for WG and IETF
> Last Call.
>
> The meeting will be in the "Orientation Room", Building SC1, on the first
> floor.
>
> The facility is 4 miles north of San Jose Airport
> and 25 miles south of San Francisco Airport off US 101.
> (be aware that traffic on 101 will jam during rush hours)
>
> The campus is next to Great America amusement park and the Santa Clara
> convention center.  There are a number of hotels of various levels near
> by.  Some are in walking distance.
>
> If you have any questions, email me dmitton@nortelnetworks.com
> (if no response within 24hrs, try dave@mitton.com)
>
> - Dave.
>
> -------------------
> Driving Directions
>
>  From San Francisco International Airport
> - 101 South, 25 miles
> - Exit Great America Parkway, turn left onto Great America
> Parkway, 1/4 mile
> - Nortel Networks - SC1 is located at the corner of Great America
> Parkway &
> Mission College Blvd
>
>  From San Jose International Airport
> - 101 North, 4 miles
> - Exit Great America Parkway, turn right onto Great America
> Parkway, 1/4 mile
> - Nortel Networks - SC1 is located at the corner of Great America
> Parkway &
> Mission College Blvd
>
>
> ---------------------------------------------------------------
> David Mitton                                  ESN: 248-4570
> Advisor, Nortel Networks                      978-288-4570 Direct
> Wireless Solutions, IP Mobility
> Billerica, MA 01821                    dmitton@nortelnetworks.com
>
>
>




From owner-aaa-bof@merit.edu  Tue Apr 24 03:17:21 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA04435
	for <aaa-archive@odin.ietf.org>; Tue, 24 Apr 2001 03:17:21 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 4D7D65DE37; Tue, 24 Apr 2001 03:11:27 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 266FE5DD9F; Tue, 24 Apr 2001 03:11:27 -0400 (EDT)
Received: from mailgw.local.ipunplugged.com (unknown [213.88.134.217])
	by segue.merit.edu (Postfix) with ESMTP id D30075DE5B
	for <aaa-wg@merit.edu>; Tue, 24 Apr 2001 03:11:18 -0400 (EDT)
Received: from fredrikj (c35.local.ipunplugged.com [192.168.4.234])
	by mailgw.local.ipunplugged.com (8.9.3/8.9.3) with SMTP id JAA27969;
	Tue, 24 Apr 2001 09:11:33 +0200
From: "Fredrik Johansson" <fredrik.johansson@ipunplugged.com>
To: "David Mitton" <dmitton@nortelnetworks.com>, "aaa-wg" <aaa-wg@merit.edu>
Cc: <aboba@internaut.com>, "Randy Bush" <randy@psg.com>,
        "Wijnen, Bert (Bert)" <bwijnen@lucent.com>, <scoya@ietf.org>
Subject: RE: [AAA-WG]: AAA WG Interim Meeting Announcement (correction)
Date: Tue, 24 Apr 2001 09:12:17 +0200
Message-ID: <MJEMJBGGCLLDLFFAHLJKIEHMCMAA.fredrik.johansson@ipunplugged.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <4.3.2.7.2.20010423160721.049e4ee0@ZBL6C016.corpeast.baynetworks.com>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

what time will the meeting start? Or will that be out when the agenda is
presented?

/Fredrik

>-----Original Message-----
>From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf
>Of David Mitton
>Sent: den 23 april 2001 22:11
>To: aaa-wg
>Cc: aboba@internaut.com; Randy Bush; Wijnen, Bert (Bert); scoya@ietf.org
>Subject: [AAA-WG]: AAA WG Interim Meeting Announcement (correction)
>
>
>[the dates in the earlier msg were inconsistent]
>
>AAA Working Group Interim Meeting
>Thurs & Friday, May 24-25th, Santa Clara, CA
>
>The meeting will be held at the Nortel Networks facility (previously
>Synoptics/Bay Networks) 4401 Great America Parkway, Santa Clara, CA 95054.
>
>An agenda will be issued at a later time.  The goal of the meeting is a
>complete review/edit of the base Diameter drafts for WG and IETF Last Call.
>
>The meeting will be in the "Orientation Room", Building SC1, on the first
>floor.
>
>The facility is 4 miles north of San Jose Airport
>and 25 miles south of San Francisco Airport off US 101.
>(be aware that traffic on 101 will jam during rush hours)
>
>The campus is next to Great America amusement park and the Santa Clara
>convention center.  There are a number of hotels of various levels near
>by.  Some are in walking distance.
>
>If you have any questions, email me dmitton@nortelnetworks.com
>(if no response within 24hrs, try dave@mitton.com)
>
>- Dave.
>
>-------------------
>Driving Directions
>
> From San Francisco International Airport
>- 101 South, 25 miles
>- Exit Great America Parkway, turn left onto Great America
>Parkway, 1/4 mile
>- Nortel Networks - SC1 is located at the corner of Great America
>Parkway &
>Mission College Blvd
>
> From San Jose International Airport
>- 101 North, 4 miles
>- Exit Great America Parkway, turn right onto Great America
>Parkway, 1/4 mile
>- Nortel Networks - SC1 is located at the corner of Great America
>Parkway &
>Mission College Blvd
>
>
>---------------------------------------------------------------
>David Mitton                                  ESN: 248-4570
>Advisor, Nortel Networks                      978-288-4570 Direct
>Wireless Solutions, IP Mobility
>Billerica, MA 01821                    dmitton@nortelnetworks.com
>




From owner-aaa-bof@merit.edu  Tue Apr 24 09:52:12 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07883
	for <aaa-archive@odin.ietf.org>; Tue, 24 Apr 2001 09:52:12 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id D155C5DEF8; Tue, 24 Apr 2001 09:46:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id BAAD05DEFC; Tue, 24 Apr 2001 09:46:29 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id 45B785DEF8
	for <aaa-wg@merit.edu>; Tue, 24 Apr 2001 09:46:28 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA03400;
	Tue, 24 Apr 2001 06:45:42 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA00859;
	Tue, 24 Apr 2001 06:45:40 -0700 (PDT)
Received: from darius (darius [152.70.40.121])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id GAA22867;
	Tue, 24 Apr 2001 06:45:39 -0700 (PDT)
Date: Tue, 24 Apr 2001 06:45:40 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Subject: RE: [AAA-WG]: AAA WG Interim Meeting Announcement (correction)
To: gwz@cisco.com
Cc: David Mitton <dmitton@nortelnetworks.com>, aaa-wg <aaa-wg@merit.edu>,
        aboba@internaut.com, Randy Bush <randy@psg.com>,
        "Wijnen, Bert (Bert)" <bwijnen@lucent.com>, scoya@ietf.org
In-Reply-To: "Your message with ID" <NDBBIHMPILAAGDHPCIOPGEGADHAA.gwz@cisco.com>
Message-ID: <Roam.SIMC.2.0.6.988119940.30448.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Thanks for that info Glen.

My wife informs me that I am supposed to be in Big Sur, leaving Friday. Is
there *any way* that we can move the meeting to Wed/Thurs?

PatC
> Are you aware that that is Memorial Day week-end?
> 
> > -----Original Message-----
> > From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf
> > Of David Mitton
> > Sent: Monday, April 23, 2001 1:11 PM
> > To: aaa-wg
> > Cc: aboba@internaut.com; Randy Bush; Wijnen, Bert (Bert); scoya@ietf.org
> > Subject: [AAA-WG]: AAA WG Interim Meeting Announcement (correction)
> >
> >
> > [the dates in the earlier msg were inconsistent]
> >
> > AAA Working Group Interim Meeting
> > Thurs & Friday, May 24-25th, Santa Clara, CA
> >
> > The meeting will be held at the Nortel Networks facility (previously
> > Synoptics/Bay Networks) 4401 Great America Parkway, Santa Clara, CA 95054.
> >
> > An agenda will be issued at a later time.  The goal of the meeting is a
> > complete review/edit of the base Diameter drafts for WG and IETF
> > Last Call.
> >
> > The meeting will be in the "Orientation Room", Building SC1, on the first
> > floor.
> >
> > The facility is 4 miles north of San Jose Airport
> > and 25 miles south of San Francisco Airport off US 101.
> > (be aware that traffic on 101 will jam during rush hours)
> >
> > The campus is next to Great America amusement park and the Santa Clara
> > convention center.  There are a number of hotels of various levels near
> > by.  Some are in walking distance.
> >
> > If you have any questions, email me dmitton@nortelnetworks.com
> > (if no response within 24hrs, try dave@mitton.com)
> >
> > - Dave.
> >
> > -------------------
> > Driving Directions
> >
> >  From San Francisco International Airport
> > - 101 South, 25 miles
> > - Exit Great America Parkway, turn left onto Great America
> > Parkway, 1/4 mile
> > - Nortel Networks - SC1 is located at the corner of Great America
> > Parkway &
> > Mission College Blvd
> >
> >  From San Jose International Airport
> > - 101 North, 4 miles
> > - Exit Great America Parkway, turn right onto Great America
> > Parkway, 1/4 mile
> > - Nortel Networks - SC1 is located at the corner of Great America
> > Parkway &
> > Mission College Blvd
> >
> >
> > ---------------------------------------------------------------
> > David Mitton                                  ESN: 248-4570
> > Advisor, Nortel Networks                      978-288-4570 Direct
> > Wireless Solutions, IP Mobility
> > Billerica, MA 01821                    dmitton@nortelnetworks.com
> >
> >
> >
> 
> 





From owner-aaa-bof@merit.edu  Tue Apr 24 10:06:04 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08037
	for <aaa-archive@odin.ietf.org>; Tue, 24 Apr 2001 10:06:03 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id D7C665DF87; Tue, 24 Apr 2001 10:01:07 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id C171B5DF90; Tue, 24 Apr 2001 10:01:07 -0400 (EDT)
Received: from rip.psg.com (rip.psg.com [147.28.0.39])
	by segue.merit.edu (Postfix) with ESMTP id 913BD5DF87
	for <aaa-wg@merit.edu>; Tue, 24 Apr 2001 10:01:06 -0400 (EDT)
Received: from randy by rip.psg.com with local (Exim 3.16 #1)
	id 14s3Fw-0004iO-00; Tue, 24 Apr 2001 06:53:28 -0700
From: Randy Bush <randy@psg.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Cc: gwz@cisco.com, David Mitton <dmitton@nortelnetworks.com>,
        aaa-wg <aaa-wg@merit.edu>, aboba@internaut.com,
        "Wijnen, Bert (Bert)" <bwijnen@lucent.com>, scoya@ietf.org
Subject: RE: [AAA-WG]: AAA WG Interim Meeting Announcement (correction)
References: <NDBBIHMPILAAGDHPCIOPGEGADHAA.gwz@cisco.com>
	<Roam.SIMC.2.0.6.988119940.30448.pcalhoun@nasnfs>
Message-Id: <E14s3Fw-0004iO-00@rip.psg.com>
Date: Tue, 24 Apr 2001 06:53:28 -0700
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

how about mon/tue?  the ops/nm interim is wed.

randy



From owner-aaa-bof@merit.edu  Tue Apr 24 12:37:45 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10296
	for <aaa-archive@odin.ietf.org>; Tue, 24 Apr 2001 12:37:44 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id B69E15DE34; Tue, 24 Apr 2001 12:37:28 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id A31C85DE33; Tue, 24 Apr 2001 12:37:28 -0400 (EDT)
Received: from zsc4s001.baynetworks.com (unknown [134.177.3.62])
	by segue.merit.edu (Postfix) with ESMTP id 4E0805DDB9
	for <aaa-wg@merit.edu>; Tue, 24 Apr 2001 12:37:27 -0400 (EDT)
Received: from zsc4c000.us.nortel.com by zsc4s001.baynetworks.com;
          Tue, 24 Apr 2001 09:29:30 -0700
Received: from zbl6c016.corpeast.baynetworks.com ([132.245.205.66]) 
          by zsc4c000.us.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) 
          id JQSM087K; Tue, 24 Apr 2001 09:36:06 -0700
Received: from mitton.nortelnetworks.com (47.16.86.121 [47.16.86.121]) 
          by zbl6c016.corpeast.baynetworks.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) 
          id JRCMHFCQ; Tue, 24 Apr 2001 12:35:58 -0400
Message-Id: <4.3.2.7.2.20010424123639.00c967f0@ZBL6C016.corpeast.baynetworks.com>
X-Sender: dmitton@ZBL6C016.corpeast.baynetworks.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 24 Apr 2001 12:37:42 -0400
To: mankin@isi.edu, Randy Bush <randy@psg.com>
From: "David Mitton" <dmitton@nortelnetworks.com>
Subject: Re: [AAA-WG]: AAA WG Interim Meeting Announcement (correction)
Cc: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>, gwz@cisco.com,
        "David Mitton" <dmitton@nortelnetworks.com>, aaa-wg <aaa-wg@merit.edu>,
        aboba@internaut.com, "Wijnen, Bert (Bert)" <bwijnen@lucent.com>,
        scoya@ietf.org
In-Reply-To: <10104241426.AA08481@maia.east.isi.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Orig: <dmitton@nortelnetworks.com>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

I would be happy with those dates too.

Bernard??

         Dave.

At 4/24/01 10:26 AM -0400, Allison Mankin wrote:
>Mon/Tue May 21-22 would be good.  Another point is that Randy and
>I have a commitment May 24 near San Jose.

---------------------------------------------------------------
David Mitton                                  ESN: 248-4570
Advisor, Nortel Networks                      978-288-4570 Direct
Wireless Solutions, IP Mobility
Billerica, MA 01821                    dmitton@nortelnetworks.com




From owner-aaa-bof@merit.edu  Tue Apr 24 13:01:26 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10587
	for <aaa-archive@odin.ietf.org>; Tue, 24 Apr 2001 13:01:26 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id CE9165DF0E; Tue, 24 Apr 2001 09:57:08 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id BB4035DEE8; Tue, 24 Apr 2001 09:57:08 -0400 (EDT)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id 4093F5DE49
	for <aaa-wg@merit.edu>; Tue, 24 Apr 2001 09:57:07 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA05270;
	Tue, 24 Apr 2001 06:56:27 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA02433;
	Tue, 24 Apr 2001 06:56:25 -0700 (PDT)
Received: from darius (darius [152.70.40.121])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id GAA22968;
	Tue, 24 Apr 2001 06:56:23 -0700 (PDT)
Date: Tue, 24 Apr 2001 06:56:24 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Subject: RE: [AAA-WG]: AAA WG Interim Meeting Announcement (correction)
To: Randy Bush <randy@psg.com>
Cc: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>, gwz@cisco.com,
        David Mitton <dmitton@nortelnetworks.com>, aaa-wg <aaa-wg@merit.edu>,
        aboba@internaut.com, "Wijnen, Bert (Bert)" <bwijnen@lucent.com>,
        scoya@ietf.org
In-Reply-To: "Your message with ID" <E14s3Fw-0004iO-00@rip.psg.com>
Message-ID: <Roam.SIMC.2.0.6.988120584.10035.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> how about mon/tue?  the ops/nm interim is wed.

That works too.

PatC




From owner-aaa-bof@merit.edu  Tue Apr 24 14:07:39 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA11661
	for <aaa-archive@odin.ietf.org>; Tue, 24 Apr 2001 14:07:38 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 27AB35DDD6; Tue, 24 Apr 2001 14:05:10 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 144105DE3C; Tue, 24 Apr 2001 14:05:10 -0400 (EDT)
Received: from motgate.mot.com (motgate.mot.com [129.188.136.100])
	by segue.merit.edu (Postfix) with ESMTP id A037D5DDD6
	for <aaa-wg@merit.edu>; Tue, 24 Apr 2001 14:05:08 -0400 (EDT)
Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate.mot.com (motgate 2.1) with ESMTP id LAA22698 for <aaa-wg@merit.edu>; Tue, 24 Apr 2001 11:05:08 -0700 (MST)]
Received: [from il35exm01.cig.mot.com (IL35EXM01.cig.mot.com [160.19.16.101]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id LAA04156 for <aaa-wg@merit.edu>; Tue, 24 Apr 2001 11:05:07 -0700 (MST)]
Received: by IL35EXM01.cig.mot.com with Internet Mail Service (5.5.2653.19)
	id <2RXQSDDF>; Tue, 24 Apr 2001 13:05:07 -0500
Message-ID: <35DBB8B7AC89D4118E98009027B1009B0ECE9D@IL27EXM10.cig.mot.com>
From: Cain Brian-BCAIN1 <Brian.Cain@motorola.com>
To: "'James Kempf'" <James.Kempf@Sun.COM>, aaa-wg@merit.edu
Subject: [AAA-WG]: RE: API, latest draft
Date: Tue, 24 Apr 2001 13:04:59 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

James, et. al,

from AAASessionManager, section 4.4.1:
>      public int getSessionCode(InetAddress host)
>
>   Return the session code corresponding to the host. If no session is
>   currently active with the host, return NO_SESSION_CODE

It is possible (and VERY likely) for several AAA sessions to exist with one AAA peer.  Ergo, an IP is an insufficient key for session lookups.  Alternative: return ALL sessions associated w/given peer.  (This presumes that the API's internal session code is one-to-one w/AAA Session Identifier).

~~~

AAAClientSessionManager:
>      public static
>      registerUnsolictedExceptionHandler(UnsolicitedExceptionHandler handler)
>
>   Register a handler for exceptions that occur during input of unsolicited
>   messages, for example, parse errors. This handler is global for all
>   sessions and all client application code in this executing instance of the
>   Java virtual machine.

How about "registerUnsolicitedMessageExceptionHandler()"?  Yes, it is a bit long; but still, no one solicits an exception, right?  If the method name stays, fix the typo: "registerUnsolictedExceptionHandler" -> "registerUnsolicitedExceptionHandler".

Naming aside, I think parse errors should not be listed as an example for an exceptional condition that can be handled.  A parse error seems like a protocol issue that should be handled internal to the library.  If the protocol calls for an MRI to be sent, the library should do it, and not rely on the UnsolicitedExceptionHandler to take this action.  If it's the case that the handler is called in addition to library handling, that's better, but I still have to wonder why anyone would want to know about messages that have parse errors.  (The above goes the same for solicited messages, too, for that matter).


~~~

Section numbering:
>     4.2   Errors and Exceptions
>       4.2.1 Class AAAException
>       4.2.2 Class AAAMessageException
>     4.3 Library Management and Dictionary Management
>       4.3.1 Class AAA
>       4.3.2 Class AAACommandDictionary
>       4.3.3 Class AVPDescriptor
>       4.3.4 Class AAACommandDescriptor
-       4.2.5 Class AAAExtension
+       4.3.5 Class AAAExtension

Duplicate '4.3's:
-     4.3 Messages and AVPs
+     4.4 Messages and AVPs
-       4.3.1 Class AAAMessage
+       4.4.1 Class AAAMessage
-       4.3.2 Class AVP
+       4.4.2 Class AVP
-       4.3.3 Class EncapsulatingAVP
+       4.4.3 Class EncapsulatingAVP
(... etc ... continue shifting sections below....)
>     4.4 Session Management
>       4.4.1 Class AAASessionManager
>       4.4.2 Class AAAClientSessionManager
>       4.4.3 Class AAAServerSessionManager
>       4.4.4 Class UnsolicitedExceptionHandler
>       4.4.5 Class AAAMessageListener


--
-Brian
Brian.Cain@motorola.com



From owner-aaa-bof@merit.edu  Tue Apr 24 14:52:16 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12598
	for <aaa-archive@odin.ietf.org>; Tue, 24 Apr 2001 14:52:15 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 51A235DEFD; Tue, 24 Apr 2001 14:49:40 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 37A435DEFC; Tue, 24 Apr 2001 14:49:40 -0400 (EDT)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id 52CB75DDC5
	for <aaa-wg@merit.edu>; Tue, 24 Apr 2001 14:49:38 -0400 (EDT)
Received: from heliopolis.eng.sun.com ([152.70.1.39])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA06431;
	Tue, 24 Apr 2001 11:48:59 -0700 (PDT)
Received: from srmtv29a (srmtv29a [152.70.1.41])
	by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id LAA25676;
	Tue, 24 Apr 2001 11:48:57 -0700 (PDT)
Message-Id: <200104241848.LAA25676@heliopolis.eng.sun.com>
Date: Tue, 24 Apr 2001 11:48:58 -0700 (PDT)
From: James Kempf <James.Kempf@sun.com>
Reply-To: James Kempf <James.Kempf@sun.com>
Subject: [AAA-WG]: RE: API, latest draft
To: James.Kempf@sun.com, aaa-wg@merit.edu, Brian.Cain@motorola.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: 0JcIm+MeTKgoxFQvgoz91Q==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Hi Brian,

>
>from AAASessionManager, section 4.4.1:
>>      public int getSessionCode(InetAddress host)
>>
>>   Return the session code corresponding to the host. If no session is
>>   currently active with the host, return NO_SESSION_CODE
>
>It is possible (and VERY likely) for several AAA sessions to exist with one AAA 
peer.  Ergo, an IP is an insufficient key for session lookups.  Alternative: 
return ALL sessions associated w/given peer.  (This presumes that the API's 
internal session code is one-to-one w/AAA Session Identifier).

I guess I am having some trouble seeing what value there would be 
in getting back all the session identifiers. How would the application
decide which to use?

The original idea behind this method was that there would be one session
active for a particular AAA peer IP address at any one time in an active virtual
machine. If, as you say, there should be more than one session, perhaps
one session per application, then I think we ought to simply drop
this method. An application is then responsible for opening a separate session,
and keeping track of the session id, each application gets a separate
session.

>
>~~~
>
>AAAClientSessionManager:
>>      public static
>>      registerUnsolictedExceptionHandler(UnsolicitedExceptionHandler handler)
>>
>>   Register a handler for exceptions that occur during input of unsolicited
>>   messages, for example, parse errors. This handler is global for all
>>   sessions and all client application code in this executing instance of the
>>   Java virtual machine.
>
>How about "registerUnsolicitedMessageExceptionHandler()"?  Yes, it is a bit 
long; but still, no one solicits an exception, right?  If the method name stays, 
fix the typo: "registerUnsolictedExceptionHandler" -> 
"registerUnsolicitedExceptionHandler".

OK.

>
>Naming aside, I think parse errors should not be listed as an example for an 
exceptional condition that can be handled.  A parse error seems like a protocol 
issue that should be handled internal to the library.  If the protocol calls for 
an MRI to be sent, the library should do it, and not rely on the 
UnsolicitedExceptionHandler to take this action.  If it's the case that the 
handler is called in addition to library handling, that's better, but I still 
have to wonder why anyone would want to know about messages that have parse 
errors.  (The above goes the same for solicited messages, too, for that matter).

Suppose a Diameter client gets an unsolicited message that is improperly
formatted. The message parsing code detects this and throws
an exception. Where should the exception be handled?

One possible way it could be handled is to simply write an error report
to a log file (and J2EE 1.4 has some new support for logging,  I'm
told). However, if the application is a GUI application, the application
code may want to inform the user that something is wrong with their
Diameter connection so the user can take immediate action. 

This method lets the application code decide how to handle such errors.

I'm not sure I understand your comment about an MRI being sent. I don't
see any Diameter messaging being done via UnsolicitedMessageExceptionHandler, 
I think it is only for reporting the error.  

With regard to why somebody should know about messages with parse errors,
presumably because it means the Diameter peer implementation is faulty.
But maybe that wasn't such a good example, perhaps you could suggest something
better.

		jak




From owner-aaa-bof@merit.edu  Tue Apr 24 16:03:44 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14141
	for <aaa-archive@odin.ietf.org>; Tue, 24 Apr 2001 16:03:43 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 4474B5DE92; Tue, 24 Apr 2001 12:49:30 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 32BE55DE6E; Tue, 24 Apr 2001 12:49:30 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id 5DDAE5DDB9
	for <aaa-wg@merit.edu>; Tue, 24 Apr 2001 12:49:28 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA09219;
	Tue, 24 Apr 2001 09:49:15 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA04469;
	Tue, 24 Apr 2001 09:49:03 -0700 (PDT)
Received: from darius (darius [152.70.40.121])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id JAA24980;
	Tue, 24 Apr 2001 09:48:59 -0700 (PDT)
Date: Tue, 24 Apr 2001 09:48:57 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Subject: Session-Id creation (was: [AAA-WG]: Previous-FA-XXXX AVP)
To: Fredrik Johansson <fredrik.johansson@ipunplugged.com>
Cc: Tony Johansson <tony.johansson@ericsson.com>,
        "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>,
        Pat.Calhoun@Sun.COM, "'AAA Listan'" <aaa-wg@merit.edu>
In-Reply-To: "Your message with ID" <MJEMJBGGCLLDLFFAHLJKAEFKCKAA.fredrik.johansson@ipunplugged.com>
Message-ID: <Roam.SIMC.2.0.6.988130937.13340.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

All,

I am now just starting to catch up with the mailing list threads, and I read
the one on how to create a session id with great interest.

The protocol, as far as I understand it, is that a session identifier would be
created using (NAI+Home Address+Home Agent Address). I have the following
comments on this proposal:

1. Assuming that a user logs on at 10am, logs out at 11, then logs in again at
1pm, there is no way to recognize that these would be different sessions,
based on the session-id. For this reason, RADIUS requires that session-ids be
unique, and Diameter goes further by stating that they must be globally
unique. The proposal fails this test.

2. This requires that the base protocol's session-id creation be dependent
upon the mobile ip extension, which is bad. The MIP extension is an extension,
and MUST NOT require base protocol changes.

3. In most cases, a mobile will NOT have a fixed Home address, or even Home
Agent. So the Session-Id would always be the NAI followed by 64bits set to
zero. Not very unique (see above). So, for this to work, it would require that
the session id change once the user has been authenticated, and authorized.
This really does require some base protocol changes.

So for the above reasons, I would prefer that the base protocot NOT change
only to satisfy the MIP extension. NASREQ must be able to be used, without MIP.
 PatC




From owner-aaa-bof@merit.edu  Tue Apr 24 17:34:15 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15803
	for <aaa-archive@odin.ietf.org>; Tue, 24 Apr 2001 17:34:14 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id B92B35DE0B; Tue, 24 Apr 2001 17:30:42 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id A72315DDB9; Tue, 24 Apr 2001 17:30:42 -0400 (EDT)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id 5A5C65DDA7
	for <aaa-wg@merit.edu>; Tue, 24 Apr 2001 17:30:41 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA19627;
	Tue, 24 Apr 2001 14:30:36 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id OAA12158;
	Tue, 24 Apr 2001 14:30:34 -0700 (PDT)
Received: from darius (darius [152.70.40.121])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id OAA28710;
	Tue, 24 Apr 2001 14:30:31 -0700 (PDT)
Date: Tue, 24 Apr 2001 14:30:34 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Subject: [AAA-WG]: Re: Comments on sections 9-10 of draft-ietf-aaa-diameter-02.txt
To: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>
Cc: "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>,
        "'pcalhoun@eng.sun.com'" <Pat.Calhoun@Sun.COM>
In-Reply-To: "Your message with ID" <577066326047D41180AC00508B955DDA01D7FFA6@eestqnt104.es.eu.ericsson.se>
Message-ID: <Roam.SIMC.2.0.6.988147834.20378.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> 1) I would like to see the content of section 9 and 10 in the same section.
> The way they are structured, it would be very easy to merge them and have
> a nice introduction to error handling common to both.

hmmm... anyone else?

> 
> 2) In 9.1, the message format should also include [Session-ID]. And should
> the  DSI-Event be in mandatory in the message, i.e. {}???

correct on both points.

> 3) In 16.1, the Command AVP table says that the Destination-Realm AVP should
> be included in the DSI message. So my question is whether or not the routing
> table should be used for sending the DSI?, or should the reply IP address and
> port be used instead? In fact, if the routing table is used, I guess that the
> Destination-FQDN should be used instead, since the Route-Record AVP contains
> the FQDN of the proxy, right? The FQDN routing would be more consistent with
> the protocol I think.

The DSI message MUST NOT include the Destination-FQDN AVP. This was a
cut-and-paste error. The message is hop-by-hop, as is the DRI, and is not
subjected to being proxied.

> 
> 4) In 16.1, the AVP Session-ID should be 0-1 in the DSI column.

correct.

> 
> 5) In 9.1.1.2, replace "Redirect Notification" by "Redirect Event".

ok

> 
> 6) In 9.1.1.4, replace DIAMETER_INVALID_RECORD_ROUTE by
> DIAMETER_INVALID_ROUTE_RECORD. Also, I think that this event should be in
> the Transient section, since the permanent section defines events for which
> messages can be forwarded to another node without any modification to its
> content, which I don't think can be possible in this case.

Well, how would the routes be modified? One is simply supposed to attached the
routes from the request into the response, so I don't understand what an
implementation could do to correct this error.

> 
> 7) In 9.1.1.4, replace DIAMETER_ERROR_TOO_BUSY by DIAMETER_TOO_BUSY.

ok

> 
> 8) In 9.1.1.4, what would be the difference between sending DIAMETER_TOO_BUSY
> and  I don't really see the point of making
> a distinction between them.

DIAMETER_TOO_BUSY - I cannot do this right now.
DIAMETER_CANNOT_PROCESS_IN_TIME - I've been working on it, and the timer
expired.

However, in reading the text, I see that the second use of the latter can be
confused with the too busy event. So, I will take that sentence and move it to
the too busy event.

> 
> 9) In 10.1, [Error-Message] should be added. It should also appear in 16.1 as
> 0-1 in the MRI column.

ok

> 
> 10) In 10.1, [Failed-Vendor-Id] should be added.

ok

> 
> 11) In 10.1, the * [Destination-Realm], I guess that the * should be 
> removed.

right.

> 
> 12) In 10.1, the {Destination-FQDN} should be added. In 16.1, it should
> say 1 instead of 0+. BTW, what does it mean for the STR to have several
> Destination-FQDN (as indicated by the 0+ in section 16.1).

done, and STR should be 0-1, not 0+.

> 
> 13) In 10.1, the [Failed-AVP] should have *. In 16.1, it should be 0+.

Right, which re-enforces the previous comment that this really needs to be a
Grouped-AVP. I will also make this correction, otherwise multiple AVP, of
different vendors, would cause problems.

> 
> 14) In 10.1.1, the reference to the table should be to section 16.1,
> instead of 14.0.

correct.

> 
> 15) In 10.1.3, is it the Failed-Command-Code AVP or the Failed-Vendor-Id AVP?
See my comment in section 13.


>  16) There is no section 10.2.3, which means that section 10.2.4 should be
> 10.2.3. The same applies for 10.2.5

correct.

> 
> 17) In 10.2.4, I think that the DIAMETER_NO_END_2_END_SECURITY error should
> be better named DIAMETER_END_2_END_SECURITY, since it indicates that e2e is
> used, which is the problem.

correct.

> 
> 18) In 10.2.5, under the description of the DIAMETER_LOOP_DETECTED error,
> it says that no further attempts should be done until it is fixed. What is 
> the intention behind that? How should it be handled?

There are two fixes, one which entails that the request be sent to another
peer, which is not what the text intended here. What I meant was once the loop
was corrected. The loop most likely would exist due to some configuration
error, but the code would obviously not know when that would occur, so perhaps
that needs to be removed.

> 
> 19) In 10.4, I guess it should NOT be mandatory
> in the MRI, since the Origin should be the default sender of the Result-Code.
> It should be only be set if the Result-Code is modified by a node on the way.

That is what the text reads.

> 16.1 should be modified to reflect 0-1 instead of 1.

Only the node that created the MRI needs to worry about these rules, and
therefore it should be a 1. Intermediate proxies wouldn't add another
Result-Code AVP, and therefore this rule wouldn't apply.

> 
> 20) In 10.4, the reference to the NAI should be replaced by the "FQDN".

thanks.

> 
> Hope this helps,
More than you can imagine! I really appreciate the close read, and comments.


PatC




From owner-aaa-bof@merit.edu  Tue Apr 24 18:23:49 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA16743
	for <aaa-archive@odin.ietf.org>; Tue, 24 Apr 2001 18:23:49 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 8E0815DE87; Tue, 24 Apr 2001 18:22:23 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 7C35C5DE86; Tue, 24 Apr 2001 18:22:23 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id 314215DE15
	for <aaa-wg@merit.edu>; Tue, 24 Apr 2001 18:22:22 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA19552;
	Tue, 24 Apr 2001 15:22:19 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA02000;
	Tue, 24 Apr 2001 15:22:17 -0700 (PDT)
Received: from darius (darius [152.70.40.121])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id PAA29237;
	Tue, 24 Apr 2001 15:22:16 -0700 (PDT)
Date: Tue, 24 Apr 2001 15:22:19 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Subject: Re: [AAA-WG]: Peer State Machine typo?
To: Cain Brian-BCAIN1 <Brian.Cain@motorola.com>
Cc: "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>
In-Reply-To: "Your message with ID" <35DBB8B7AC89D4118E98009027B1009B0ECE99@IL27EXM10.cig.mot.com>
Message-ID: <Roam.SIMC.2.0.6.988150939.22339.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

>  --> I-Open  Send-Message       I-Snd-Non-DRI     I-Open  <--
>              I-Rcv-Non-DRI      Process           I-Open
>  -->         I-WatchDog-Timer   I-Snd-DWR         I-Open  <--
>  -->         I-Rcv-DWA          Process-DWA       I-Open  <--
>              Stop               I-Disc            Closed
>              I-Peer-Disc        I-Disc            Closed
>              I-Rcv-DRI          Error             Closed

So far, yes these are cut and paste errors.

>  -->         I-Rcv-Conn-Req     I-Snd-Conn-Nack   I-Open  <--

No, this one was correct. It handles the case where a connection is already
established, and a new incoming connection is received.

> 
> Thanks!
> 
> -Panos
> 





From owner-aaa-bof@merit.edu  Tue Apr 24 18:55:30 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA17165
	for <aaa-archive@odin.ietf.org>; Tue, 24 Apr 2001 18:55:29 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 5B8875DD91; Tue, 24 Apr 2001 18:55:13 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 46C795DDA3; Tue, 24 Apr 2001 18:55:13 -0400 (EDT)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id 90A765DD91
	for <aaa-wg@merit.edu>; Tue, 24 Apr 2001 18:55:11 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id PAA27745;
	Tue, 24 Apr 2001 15:55:07 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id PAA12825;
	Tue, 24 Apr 2001 15:55:07 -0700 (PDT)
Received: from darius (darius [152.70.40.121])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id PAA29569;
	Tue, 24 Apr 2001 15:55:04 -0700 (PDT)
Date: Tue, 24 Apr 2001 15:55:07 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Subject: Re: [AAA-WG]: Date: Mon, 23 Apr 2001 11:02:13 +0200
To: "Yolanda Garcia-Serrano (ECE)" <yolanda.garcia-serrano@ece.ericsson.se>
Cc: "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>
In-Reply-To: "Your message with ID" <577066326047D41180AC00508B955DDA02C009B3@eestqnt104.es.eu.ericsson.se>
Message-ID: <Roam.SIMC.2.0.6.988152907.11281.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> Here goes some questions/proposals for message forwarding and routing
> sections (5, and 12) of base 02:
> 
> First of all: Why splitting the issue in two separate sections, 5.0 and
> 12.0. They are very closely related, aren't there? 

Related, but different. A message that is processed according to section 5.0
will not be processed. There are messages that are subjected to such rules,
such as the DRI and the DSI.

> To understand the hole
> thing, one should go to both sections, so I suggest to merge them.  In that
> way, it would be clearer. E.g. it is weird to see Destination-FQDN and
> Destination-Realm AVP stated one in section 5.3, and the other in 12.4.7

So the Destination-FQDN is used in the message forwarding code, while the
Destination-Realm is used for forwarding purposes.

I will not object to merging them, but I would need to have more people that
think that this is needed.

> 
> Section 5.0 Message Forwarding.-
> -----------------------------------
> Replace NAS by Diameter client or access-device

ok

> 
> 2nd paragraph:
>    When a Diameter entity receives a Diameter message of type Request,
>    Query or Indication that includes a Destination-FQDN AVP, and the
>    host specified in the AVP can be contacted directly, the message MUST
>    be forwarded to the host in question.
> and 4th paragraph:
>    Proxies receiving messages that contain the Destination-FQDN AVP MUST
>    verify whether they are able to forward Diameter messages to the host
>    specified in the AVP, and if so, MUST forward the message to the host
>    in question. Otherwise, the message routing procedures described in
>    section 12.0 MUST be followed.
> both try to say the same thing, but last one is much clearer, as it includes
> what to do in case Destination-FQDN AVP is not present. So, could we get rid
> of 2nd paragraph?

You are correct. Removing the 2nd paragraph is a good idea since the 4th
paragraph was more specific.

> 
> Regarding Responses, Answers, and Replys, I've looking carefully to the
> draft, and it seems consufing: In section 3.0, when talking about the flags,
> there are following message types: Request, Query, Indication,  Reply and
> Answer. But in section 3.3.2 is stated Query/Response. So it is confusing. I
> understand the term "response" refers to the generic one, and it includes
> both Reply and Answer, isn't it?. Is it possible to make this clear in the
> spec, so that all this terms are coherently used? 

There was an unfortunate mistake in the draft from some text I pulled in from
a contribution, and I missed that one :(

Reply->Response

> Furthermore, why is needed any distinction between them? If there is no
> strong argument maybe we can get rid of Request/Query and
> Response/Reply/Answer difference, and simply talk about Requests and
> Responses through all the spec.

We could, but there were cases where Queries exist, and these are a particular
type of message. See the Resource-Management (non WG document) as an example.

> 
> Last paragraph in section 5.0 refers to mandatory AVPs for all messages
>    This section defines the Diameter AVPs that MUST be added in all
>    messages originated by a Diameter node (including nodes creating
>    Response and Answer messages).
> but Destination-FQDN is used in Indication, Reply and Answers only, so, it
> should not belong to this chapter, or better, this last paragraph in section
> 5.0 can be removed, as it adds no information, but  it can lead to confusion
> about this Destination-FQDN AVP.

The Destination-FQDN CAN in fact be present in request or queries. This is
useful in messages that require multiple round trips, or when e2e security is
used, and the message has a specific target.


> 
> Section 5.3 Destination-FQDN AVP
>    The Destination-FQDN AVP (AVP Code 293) is of type OctetString,
>    encoded in the UTF-8 [24] format, and contains the Fully Qualified
>    Domain Name (FQDN) of the intended recipient of the message. This AVP
>    MUST be present in all unsolicited server initiated messages. The
>    value of the Destination-FQDN AVP is set to the value of the Origin-
>    FQDN AVP found in a message from the intended target host.

> Should instead, state: "This AVP MUST be present in all unsolicited server
> initiated  messages, all reply and all answer messages." See example in
> section 12.1 

I could modify the figure to include the AVP in the request, but it is not
mandatory to be present when the client doesn't care which server handles the
request.

> and AVP tables 16.1 and 16.2.

Table 16.1 shows the AVP as 0-1 in the STR, which is a request.

> 
> Section 12.0 Message Routing
> -----------------------------------
> 
> Section 12.1 Realm-based message routing
>    Diameter request, query and indication message routing is done
>    through the use of the realm portion of the Network Access Identifier
>    (NAI) or via a realm encoded in an AVP (e.g. Origin-Realm,
>    Destination-Realm), and an associated realm routing table (see
>    section 12.1.1).
> 
>    When an NAI is used, the realm portion of the user@realm is used to
>    perform the realm lookup. Diameter servers have a list of locally
>    supported realms, and MAY have a list of externally supported realms.
>    When a request, query or indication message is received that includes
>    a realm that is not locally supported, the message is proxied to the
>    Diameter entity configured in the "route" table.
> NAI is not used to route, is it? It should state instead :
>       Diameter request, query and indication message routing is done through 
>       the use of Destination-FQDN or Destination-Realm and an associated
> realm 
>      routing table (see section 12.1.1).

no. I believe that you are confused with the Destination-FQDN and the
Destination-Realm. The FQDN is used for hop-by-hop forwarding. It is only used
when the next hop is known. So the realm table doesn't need to be consulted,
but instead the peer table. This of this as similar to interfaces and routes.

> 
>    When an NAI is used, the realm portion of the user@realm MUST be copied in
>    Destination-Realm AVP, which is used to perform the realm lookup.
> Diameter servers 
>    have a list of locally supported realms, and MAY have a list of
> externally 
>    supported realms.
>    When a request, query or indication message is received that includes
>    a realm that is not locally supported, the message is proxied to the
>    Diameter entity configured in the "route" table.
> 
> 
> Example DIA1, DIA2, DIA3, on figure 2:
>           (Origin-FQDN=dia1.mno.net)   (Origin-FQDN=dia1.mno.net)
>           (Origin-Realm=mno.net)       (Origin-Realm=mno.net)
>           (Destination-Realm=abc.com)  (Destination-Realm=abc.com)
>           (Route-Record=dia1.mno.net)  (Route-Record=dia1.mno.net)
>                                        (Route-Record=dia2.xyz.com)
>       +------+      ------>      +------+      ------>      +------+
>       |      |     (Request)     |      |      (Request)    |      |
>       | DIA1 +-------------------+ DIA2 +-------------------+ DIA3 |
>       |      |                   |      |                   |      |
>       +------+      <------      +------+      <------      +------+
>       mno.net      (Response)    xyz.com      (Response)     abc.com
>           (Origin-Realm=abc.com)       (Origin-Realm=abc.com)
>       (Destination-FQDN=dia1.mno.net)  (Destination-FQDN=dia1.mno.net)
>                                        (Route-Record=dia2.xyz.com)
> 
> Route-Record=dia1.mno.net is missing in Responses from DIA3 to DIA2 and DIA2
> to DIA1 (this has already been posted in the list).

That is now fixed.

> Is it not missing as well Origin-FQDN = dia3.abc.com in Responses from DIA3
> to DIA2 and DIA2 to DIA1, as Origin-FQDN is MANDATORY in ALL Diameter
> messages? 

oops.

> I miss as well how the Response is routed back to the Diameter
> client (which is not present in the drawing, and it will made it clearer, as
> DI1 is not the originator of the message, but the first proxy). With
> Destination-FQDN set to DIA1, how the response can reach the client ?

DIA1 *is* the client. The client's FQDN is in the Destination-FQDN AVP.

> The following figure, may help (in case Client belong to same domain than
> DIA1):
> 
> (Origin-FQDN=client.mno.net)   (Origin-FQDN=client.mno.net)    
> (Origin-FQDN=client.mno.net) (Origin-Realm=mno.net)        
> (Origin-Realm=mno.net)           (Origin-Realm=mno.net)
> (Destination-Realm=abc.com)    (Destination-Realm=abc.com)     
> (Destination-Realm=abc.com)
>                                (Route-Record=dia1.mno.net)     
> (Route-Record=dia1.mno.net)
>                                                                
> (Route-Record=dia2.xyz.com)
>   +------+  -------->  +------+    ------>     +------+    ------>   
> +------+
>   | DIA  | (Request)   |      |   (Request)    |      |  (Request)    |     
> |
>   |Client|-------------| DIA1 +----------------+ DIA2 +---------------+ DIA3
> |
>   |      |             |      |                |      |               |     
> |
>   +------|  <--------  +------+   <-------     +------+   <-------   
> +------+
>   mno.net  (Response)   mno.net  (Response)     xyz.com   (Response)  
> abc.com
>     (Origin-FQDN=dia3.abc.com)    (Origin-FQDN=dia3.abc.com)       
> (Origin-FQDN=dia3.abc.com)
>     (Origin-Realm=abc.com)        (Origin-Realm=abc.com)           
> (Origin-Realm=abc.com) (Destin-FQDN=client.mno.net)     
> (Destin-FQDN=client.mno.net)      (Destin-FQDN=client.mno.net)
>                                   (Route-Record=dia1.xyz.com)      
> (Route-Record=dia2.xyz.com)
>                                                                    
> (Route-Record=dia1.xyz.com)
> 
> 
> Section 12.2Proxy and Redirect Server handling of requests
> 
>    When a message of type request, query or indication is received by a
>    proxy or redirect server, and it is determined that the request
>    cannot be locally handled, the next hop for the request is determined
>    in the following order:
>       1. If the Destination-FQDN AVP is present, and the host specified
>          in the AVP can be directly contacted, the message is forwarded
>          to the host (see section 5.3 for more information), or
>       2. If the Destination-Realm AVP is present, a routing table lookup
>          is performed using the domain specific in the AVP.
> Could be explicitly said in 2.  and 12.4.7 that Destination-Realm AVP is
> mandatory for all Request, Query and Indication messages ?

No because the presence of the Destionation-Realm implies that the message is
routable. There are many cases where that is not the case (again, DRI, DSI and
the watchdog messages are examples).

> 
>    A message that does not contain any of the above AVPs MUST NOT be
>    routed.  If the message in question cannot be handled locally, a
>    Message-Reject-Ind is sent with the Result-Code AVP set to an
>    appropriate error condition.
> This paragraph can be removed, if it is said than Destination-Realm AVP is
> mandatory.


see above.
> 
> Section 12.4  Proxy Server
>    Maintaining transaction state implies that a server keeps a copy of a
>    request, which is then used when the corresponding response is
>    received.  This could be done to apply local policies to the message,
>    or simply for auditing purposes. Maintaining session state implies
>    that a server keeps track of all "active" users. An active user is
>    one that has been authorized for a particular service, and the server
>    has not received any indication that the user has relinquished
>    access.
> 
> Say instead:  Maintaining transaction state implies that a server keeps a 
>       copy of a request or query which is then used when the corresponding
> response is
>    received.

You are proposing just removing text?

> 
> 
>    A stateless proxy is one that does not maintain session state, but
>    MUST maintain transaction state. Transaction state SHOULD be released
>    after a request's corresponding response has been forwarded towards
>    the recipient, and has been acknowledged by the underlying transport.
> Isn't it strange to call a proxy which keeps transaction state "stateless"?

Yes perhaps, but a minimal amount of state is unavoidable :(

> Maybe the paragraph can be reworded to explain that what is considered
> "stateless" is a proxy that mantains the minimum information about the
> forwarded messages (e.g. it stores Hop-by-Hop identifier and restore it
> after receiving the corresponding Responses, it may add Proxy-State AVP ...).

You mean in addition to 

"
A stateless proxy is one that does not maintain session state, but MUST
maintain transaction state. Transaction state SHOULD be released after a
request's corresponding response has been forwarded towards the recipient,
and has been acknowledged by the underlying transport."

?

>  Section 12.4.1  Proxying Requests
> Could we title it Proxying Requests, Querys and Indications, instead ?

ok

> Spelling: A Diameter server that proxies a message of type Request, Query or
> ...
> 

thanks.

> Section 12.4.2  Proxying Responses
>    A proxy server MUST only process messages of type Response or Answer
>    whose last Route-Record AVP matches one of its addresses.
> Say instead: A proxy server MUST only process messages of type Reply or
> Answer
>    whose last Route-Record AVP matches one of its identities. (IP addreses
> are not used for this application routing, but  FQDN/realm).

correct.

>  > Section 12.6  Hiding Network Topology >    Stateful proxies forwarding
requests to servers outside of their >    administrative domain MAY hide the
internal network topology. Servers >    perform this by removing all
Route-Record AVPs in the message, and >    maintains the Route-Record AVPs to
add to the corresponding response. >    Such stateful servers MUST still add
their own Route-Record AVP to >    the request prior to forwarding. > Why the
paragraph refers only to stateful proxies? I think it could also > apply to
stateless ones, if we consider a proxy server including a > Proxy-State as
stateless.

ouch, don't know how the above occured.

In any case, you are correct, stateless servers could do this as well.


 >  >  > Section 12.7  Loop Detection >    When a Diameter Proxy or
Redirect server receives a message of type >    Request, Query or Indication,
it MUST examine all Route-Record AVPs >    in the message to determine whether
such an AVP already exists with >    the local server's identity. If an AVP
with the local host's identity >    is found in the request, it is an
indication that the message is >    being looped through the same set of
proxies. When such an event >    occurs, the Diameter server that detects the
loop returns a response >    with the Result-Code AVP set to
DIAMETER_LOOP_DETECTED. >  > Instead of returning a response (this is
impossible for Indications), I > think it should say "the Diameter server that
detects the loop issues a > Message-Reject-Ind message with the  Result-Code
AVP set to > DIAMETER_LOOP_DETECTED."

Correct.

 >  > Last one: Has it sense try to
detect loops also for Reply/Answer messages? > Say a loop is not properly
detected in an upstream Diameter message. Then, > the same loop is going to
happen for its corresponding downstream response. > So, maybe it would be more
robust try to detect it as well for responses. If > you agree, it should be
mentioned in this section.

Since the reverse path MUST be the same as the forwarding path, this is not
possible. If a loop exists, the packet would have never made it to the home to
begin with.


Thanks for the great comments!

PatC




From owner-aaa-bof@merit.edu  Tue Apr 24 19:07:42 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA17334
	for <aaa-archive@odin.ietf.org>; Tue, 24 Apr 2001 19:07:42 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 46E335DE54; Tue, 24 Apr 2001 19:05:06 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 355515DE46; Tue, 24 Apr 2001 19:05:06 -0400 (EDT)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id C44A25DDB9
	for <aaa-wg@merit.edu>; Tue, 24 Apr 2001 19:05:04 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA05026;
	Tue, 24 Apr 2001 16:04:23 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA16499;
	Tue, 24 Apr 2001 16:04:22 -0700 (PDT)
Received: from darius (darius [152.70.40.121])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id QAA29668;
	Tue, 24 Apr 2001 16:04:19 -0700 (PDT)
Date: Tue, 24 Apr 2001 16:04:18 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Subject: Re: [diameter] Re: [AAA-WG]: Peer State Machine, closed state
To: Jeanette Heidenberg <lmfjean@lmf.ericsson.se>
Cc: David Mitton <dmitton@nortelnetworks.com>, John Alayari <johnal@cisco.com>,
        Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>,
        aaa-wg <aaa-wg@merit.edu>, diameter <diameter@diameter.org>
In-Reply-To: "Your message with ID" <Pine.GSO.4.10.10104191552390.28006-100000@turqws51>
Message-ID: <Roam.SIMC.2.0.6.988153458.7164.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> 
> I'd like to repeat John's question, because I think only half of it was
> answered. 
> 
> The current state machine is:
> -----------------------------
> Closed           Start            I-Snd-Conn-Req   Wait-Conn-Ack
>                  R-Rcv-Conn-Req   I-Snd-Conn-Ack   Wait-R-DRI
> 
> Shouldn't it be?
> ---------------
> Closed           Start            I-Snd-Conn-Req   Wait-Conn-Ack
>                  R-Rcv-Conn-Req   R-Snd-Conn-Ack   Wait-R-DRI

Yes it should.

PatC




From owner-aaa-bof@merit.edu  Tue Apr 24 19:46:28 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA17959
	for <aaa-archive@odin.ietf.org>; Tue, 24 Apr 2001 19:46:28 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 300A85DEFA; Tue, 24 Apr 2001 19:14:48 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 119225DEF9; Tue, 24 Apr 2001 19:14:48 -0400 (EDT)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id 610135DEF7
	for <aaa-wg@merit.edu>; Tue, 24 Apr 2001 19:14:45 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA12108;
	Tue, 24 Apr 2001 16:14:42 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA19668;
	Tue, 24 Apr 2001 16:14:41 -0700 (PDT)
Received: from darius (darius [152.70.40.121])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id QAA29792;
	Tue, 24 Apr 2001 16:14:40 -0700 (PDT)
Date: Tue, 24 Apr 2001 16:14:42 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Subject: Re: [AAA-WG]: separated authorization and accounting servers?
To: Jari Arkko <Jari.Arkko@lmf.ericsson.se>
Cc: aaa-wg@merit.edu
In-Reply-To: "Your message with ID" <3ADD53C7.D9206765@lmf.ericsson.se>
Message-ID: <Roam.SIMC.2.0.6.988154082.27720.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> 
> Hello,
> 
> We've been trying to figure out if the current
> version of the Diameter specs allow accounting
> and other traffic to be directed to different
> servers. Traditionally, we've had this feature
> in RADIUS. It might even be conceivable that there
> be uses of accounting where there is no authentication
> or authorization at all on a node that gives a service.

It used to when Accounting was a separate extension, but although I fought
hard to keep it an extension, WG comments was that Accounting MUST be in the
base protocol.

So, this is no longer possible, other than by manual configuration.

Unless we re-introduce the extension-Id for accounting in the base...

> But can we do this? We haven't figured out if the
> specifications say anything about this. Section 13.1
> talks about authorization server directed model, but
> I would classify the "direction" as optional information.
> Section 13.2 says servers that receive a succesfull
> authentication response must collect accounting information.
> But must they send it too? And can there be other nodes
> that would not perform authentication/authorization but
> who still produce accounting information (e.g. for
> trend analysis purposes)? Section 11 talks about user
> sessions and their life-cycle. But it doesn't seem to
> state anything about this issue in particular.

Not sure that I follow you here. Only the access device generates accounting
messages. Is this not clear in the draft? If not, it certainly needs to be
fixed.

> 
> Do we allow two proxies to be configured for a client
> node, one for the authentication and authorization, and
> the second one for accounting?

It used to be possible, and is in RADIUS, but no longer in -02 due to the
changes I noted above.

PatC




From owner-aaa-bof@merit.edu  Tue Apr 24 20:45:10 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA18762
	for <aaa-archive@odin.ietf.org>; Tue, 24 Apr 2001 20:45:09 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 991335DDA3; Tue, 24 Apr 2001 19:27:13 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 859385DDAD; Tue, 24 Apr 2001 19:27:13 -0400 (EDT)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id 3D7DA5DDA3
	for <aaa-wg@merit.edu>; Tue, 24 Apr 2001 19:27:12 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id QAA19464;
	Tue, 24 Apr 2001 16:26:31 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id QAA23014;
	Tue, 24 Apr 2001 16:26:30 -0700 (PDT)
Received: from darius (darius [152.70.40.121])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id QAA29964;
	Tue, 24 Apr 2001 16:26:29 -0700 (PDT)
Date: Tue, 24 Apr 2001 16:26:31 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Subject: RE: [AAA-WG]: separated authorization and accounting servers
To: David Mitton <dmitton@nortelnetworks.com>
Cc: John Alayari <johnal@cisco.com>, Jari Arkko <Jari.Arkko@lmf.ericsson.se>,
        aaa-wg <aaa-wg@merit.edu>
In-Reply-To: "Your message with ID" <4.3.2.7.2.20010419101127.00b01f00@ZBL6C016.corpeast.baynetworks.com>
Message-ID: <Roam.SIMC.2.0.6.988154791.2644.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> Yes,
>    you can devise all sorts of scenarios where separated Accounting and 
> Authentication make sense.  Some people do it RADIUS.
> 
> However,
>          Accounting messages are essential to session state keeping 
> Authorization servers, and since we have not added any Session Terminate 
> Report messages, I think Accounting should be Mandatory back to the Auth 
> servers.

Huh? The base protocol defines the STR message, which does just that. I really
want to avoid re-using accounting messages to maintain state information.

PatC




From owner-aaa-bof@merit.edu  Wed Apr 25 00:00:31 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA23312
	for <aaa-archive@odin.ietf.org>; Wed, 25 Apr 2001 00:00:26 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id B08815DDC0; Tue, 24 Apr 2001 10:24:58 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9D97C5DDB9; Tue, 24 Apr 2001 10:24:58 -0400 (EDT)
Received: from east.isi.edu (east.isi.edu [38.245.76.2])
	by segue.merit.edu (Postfix) with ESMTP id 201715DD9F
	for <aaa-wg@merit.edu>; Tue, 24 Apr 2001 10:24:57 -0400 (EDT)
Received: from maia.east.isi.edu (maia.east.isi.edu [38.245.76.14])
	by east.isi.edu (8.9.2/8.9.2) with SMTP id KAA09752;
	Tue, 24 Apr 2001 10:21:26 -0400 (EDT)
Posted-Date: Tue, 24 Apr 2001 10:26:22 -0400
Message-Id: <10104241426.AA08481@maia.east.isi.edu>
Received: from LOCALHOST.east.isi.edu by maia.east.isi.edu (4.1/4.0.3-6)
	id <AA08481>; Tue, 24 Apr 01 10:26:23 EDT
To: Randy Bush <randy@psg.com>
Cc: Patrice Calhoun <pcalhoun@nasnfs.eng.sun.com>, gwz@cisco.com,
        David Mitton <dmitton@nortelnetworks.com>, aaa-wg <aaa-wg@merit.edu>,
        aboba@internaut.com, "Wijnen,     Bert (Bert)" <bwijnen@lucent.com>,
        scoya@ietf.org
Reply-To: mankin@isi.edu
Subject: Re: [AAA-WG]: AAA WG Interim Meeting Announcement (correction) 
In-Reply-To: Your message of Tue, 24 Apr 2001 06:53:28 -0700.
             <E14s3Fw-0004iO-00@rip.psg.com> 
Date: Tue, 24 Apr 2001 10:26:22 -0400
From: Allison Mankin <mankin@isi.edu>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Mon/Tue May 21-22 would be good.  Another point is that Randy and
I have a commitment May 24 near San Jose.



From owner-aaa-bof@merit.edu  Wed Apr 25 03:19:59 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA08716
	for <aaa-archive@odin.ietf.org>; Wed, 25 Apr 2001 03:19:58 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 3A8315DE35; Wed, 25 Apr 2001 03:16:48 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9EA5D5DDB0; Wed, 25 Apr 2001 03:16:47 -0400 (EDT)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by segue.merit.edu (Postfix) with ESMTP id F330D5DDB0
	for <aaa-wg@merit.edu>; Wed, 25 Apr 2001 03:16:31 -0400 (EDT)
Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f3P7GUO10815
	for <aaa-wg@merit.edu>; Wed, 25 Apr 2001 09:16:31 +0200 (MEST)
Received: FROM esealnt743.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Wed Apr 25 09:16:27 2001 +0200
Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <HA3DQZ6M>; Wed, 25 Apr 2001 09:16:25 +0200
Message-ID: <577066326047D41180AC00508B955DDA01D7FFB6@eestqnt104.es.eu.ericsson.se>
From: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>
To: "'Patrice Calhoun'" <pcalhoun@nasnfs.Eng.Sun.COM>,
        "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>
Cc: "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>,
        "'pcalhoun@eng.sun.com'" <Pat.Calhoun@Sun.COM>
Subject: [AAA-WG]: RE: Comments on sections 9-10 of draft-ietf-aaa-diameter-02.txt
Date: Wed, 25 Apr 2001 09:16:18 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Hi Pat,

Thanks for your answers.
See my comments enclosed.

BR,
Martin

> > 3) In 16.1, the Command AVP table says that the 
> Destination-Realm AVP should
> > be included in the DSI message. So my question is whether 
> or not the routing
> > table should be used for sending the DSI?, or should the 
> reply IP address and
> > port be used instead? In fact, if the routing table is 
> used, I guess that the
> > Destination-FQDN should be used instead, since the 
> Route-Record AVP contains
> > the FQDN of the proxy, right? The FQDN routing would be 
> more consistent with
> > the protocol I think.
> 
> The DSI message MUST NOT include the Destination-FQDN AVP. This was a
> cut-and-paste error. The message is hop-by-hop, as is the 
> DRI, and is not
> subjected to being proxied.

My point was that we do not need the Destination-Realm AVP, since it
is a message sent only to the next downstream hop. Then, it is 
precisely the role of the Destination-FQDN AVP to direct a message
to a next hop server, since it is used for routing only if it can
be contacted directly from a Diameter node, right? Anyway, the thing
is that it was not clear if any Destination-XXXX AVP at all were 
required?

> > 6) In 9.1.1.4, replace DIAMETER_INVALID_RECORD_ROUTE by
> > DIAMETER_INVALID_ROUTE_RECORD. Also, I think that this 
> event should be in
> > the Transient section, since the permanent section defines 
> events for which
> > messages can be forwarded to another node without any 
> modification to its
> > content, which I don't think can be possible in this case.
> 
> Well, how would the routes be modified? One is simply 
> supposed to attached the
> routes from the request into the response, so I don't 
> understand what an
> implementation could do to correct this error.

If I understand correctly, this check is only performed
for request/query/indication messages, since it is the
responsibility of the previous hop to add the route-record
and the one of the actual node to validate the information.
For answer/response messages, the only check that is required
is to check if the route-recoud matches the local node.

So, I don't know either what the implementation can do about
it?, and I don't understand neither why the downstream server
should try to re-route the message to another node, as it
is suggested in the DSI-permanent DSI-event. I guess you are
suggesting to re-try other upstream servers until one understand 
the match between the Route-Record and the sending IP address?
That would mean that one of the upstream servers is badly
configured. Maybe that would make sense?

The change of name was due to the fact that Record-Route
should be Route-Record instead, just as described by the AVP.

> > 19) In 10.4, I guess it should NOT be mandatory
> > in the MRI, since the Origin should be the default sender 
> of the Result-Code.
> > It should be only be set if the Result-Code is modified by 
> a node on the way.
> 
> That is what the text reads.

Yes, but the message format in 10.1 makes it required {}. It 
should then be [] instead.

> > 16.1 should be modified to reflect 0-1 instead of 1.
> 
> Only the node that created the MRI needs to worry about these 
> rules, and
> therefore it should be a 1. Intermediate proxies wouldn't add another
> Result-Code AVP, and therefore this rule wouldn't apply.

Same as before, if it is not modified by any proxy servers on the
way, then I guess this AVP should not be included in the message, right?




From owner-aaa-bof@merit.edu  Wed Apr 25 05:26:57 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA09699
	for <aaa-archive@odin.ietf.org>; Wed, 25 Apr 2001 05:26:57 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 6E8735DDE0; Wed, 25 Apr 2001 05:26:41 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 5D3965DDC6; Wed, 25 Apr 2001 05:26:41 -0400 (EDT)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by segue.merit.edu (Postfix) with ESMTP id 31BCD5DDB1
	for <aaa-wg@merit.edu>; Wed, 25 Apr 2001 05:26:39 -0400 (EDT)
Received: from esealnt406.al.sw.ericsson.se (ESEALNT406.al.sw.ericsson.se [153.88.251.29])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f3P9QcO11360
	for <aaa-wg@merit.edu>; Wed, 25 Apr 2001 11:26:38 +0200 (MEST)
Received: FROM esealnt743.al.sw.ericsson.se BY esealnt406.al.sw.ericsson.se ; Wed Apr 25 11:26:36 2001 +0200
Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <HA3DRBRR>; Wed, 25 Apr 2001 11:26:35 +0200
Message-ID: <577066326047D41180AC00508B955DDA01D7FFBC@eestqnt104.es.eu.ericsson.se>
From: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>
To: "'Patrice Calhoun'" <pcalhoun@nasnfs.Eng.Sun.COM>,
        "Yolanda Garcia-Serrano (ECE)" <yolanda.garcia-serrano@ece.ericsson.se>
Cc: "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>,
        "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>
Subject: RE: [AAA-WG]: Date: Mon, 23 Apr 2001 11:02:13 +0200
Date: Wed, 25 Apr 2001 11:26:33 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Hi Pat,

Some comments on this.

Regards,
Martin

> > Furthermore, why is needed any distinction between them? If 
> there is no
> > strong argument maybe we can get rid of Request/Query and
> > Response/Reply/Answer difference, and simply talk about Requests and
> > Responses through all the spec.
> 
> We could, but there were cases where Queries exist, and these 
> are a particular
> type of message. See the Resource-Management (non WG 
> document) as an example.

What do you mean by a particular type of request? Is it only a 
nomenclature issue?, or is it because a query message can be
handled differently than a request or indication message? Is it
a question of priorities in terms of tasks?, or importance
with regards to discarding the message or not answering it?

> > Last paragraph in section 5.0 refers to mandatory AVPs for 
> all messages
> >    This section defines the Diameter AVPs that MUST be added in all
> >    messages originated by a Diameter node (including nodes creating
> >    Response and Answer messages).
> > but Destination-FQDN is used in Indication, Reply and 
> Answers only, so, it
> > should not belong to this chapter, or better, this last 
> paragraph in section
> > 5.0 can be removed, as it adds no information, but  it can 
> lead to confusion
> > about this Destination-FQDN AVP.
> 
> The Destination-FQDN CAN in fact be present in request or 
> queries. This is
> useful in messages that require multiple round trips, or when 
> e2e security is
> used, and the message has a specific target.

The confusion comes from "...that MUST be added in all messages 
originated by a Diameter node". I guess you meant "unsolicited 
server initiated messages" from Diameter nodes, right? Like you're
saying, they also may be included in request from clients, but
not necessarily, which means that MUST NOT be in all messages.
I think it is a question of wording.

Also, I would agree that the Destination-FQDN AVP MUST be part 
of all answer/response messages, since the Origin-FQDN is part
of every upstream message, and it makes sense that the Home server uses
it within the answer/response messages. Also, it should always be used
for the last hop to the client, as you seem to agree from the section
12.1.

> > I miss as well how the Response is routed back to the Diameter
> > client (which is not present in the drawing, and it will 
> made it clearer, as
> > DI1 is not the originator of the message, but the first proxy). With
> > Destination-FQDN set to DIA1, how the response can reach 
> the client ?
> 
> DIA1 *is* the client. The client's FQDN is in the 
> Destination-FQDN AVP.

If you agree that DIA1 is the client, then why is it including
a Route-Record AVP? I think that the Origin-FQDN AVP should be
enough for the answer to include a Destination-FQDN for routing
back to the client.

From this example, you seem to agree that every answer/response
should also ALWAYS include a Destination-FQDN AVP, right?




From owner-aaa-bof@merit.edu  Wed Apr 25 09:33:58 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA14916
	for <aaa-archive@odin.ietf.org>; Wed, 25 Apr 2001 09:33:58 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 2134E5DE33; Wed, 25 Apr 2001 09:31:15 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 0F4575DE32; Wed, 25 Apr 2001 09:31:15 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id A1AA05DE23
	for <aaa-wg@merit.edu>; Wed, 25 Apr 2001 09:31:13 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA26875;
	Wed, 25 Apr 2001 06:31:06 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA21073;
	Wed, 25 Apr 2001 06:31:05 -0700 (PDT)
Received: from srmtv29a (srmtv29a [152.70.1.41])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id GAA04311;
	Wed, 25 Apr 2001 06:31:04 -0700 (PDT)
Date: Wed, 25 Apr 2001 06:31:04 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Subject: [AAA-WG]: RE: Comments on sections 9-10 of draft-ietf-aaa-diameter-02.txt
To: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>
Cc: "'Patrice Calhoun'" <pcalhoun@nasnfs.Eng.Sun.COM>,
        "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>,
        "'pcalhoun@eng.sun.com'" <Pat.Calhoun@sun.com>
In-Reply-To: "Your message with ID" <577066326047D41180AC00508B955DDA01D7FFB6@eestqnt104.es.eu.ericsson.se>
Message-ID: <Roam.SIMC.2.0.6.988205464.17974.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> > > 3) In 16.1, the Command AVP table says that the 
> > Destination-Realm AVP should
> > > be included in the DSI message. So my question is whether 
> > or not the routing
> > > table should be used for sending the DSI?, or should the 
> > reply IP address and
> > > port be used instead? In fact, if the routing table is 
> > used, I guess that the
> > > Destination-FQDN should be used instead, since the 
> > Route-Record AVP contains
> > > the FQDN of the proxy, right? The FQDN routing would be 
> > more consistent with
> > > the protocol I think.
> > 
> > The DSI message MUST NOT include the Destination-FQDN AVP. This was a
> > cut-and-paste error. The message is hop-by-hop, as is the 
> > DRI, and is not
> > subjected to being proxied.
> 
> My point was that we do not need the Destination-Realm AVP, since it
> is a message sent only to the next downstream hop. Then, it is 
> precisely the role of the Destination-FQDN AVP to direct a message
> to a next hop server, since it is used for routing only if it can
> be contacted directly from a Diameter node, right? Anyway, the thing
> is that it was not clear if any Destination-XXXX AVP at all were 
> required?

OOps. I meant to say Destination-Realm, not Destination-FQDN. You are correct
that the *-FQDN is used for hop-by-hop forwarding. The Destination-Realm MUST
NOT be present. However, since this message is NOT proxiable, it is
questionable whether the Destionation-FQDN is really needed at all, since a
Diameter node will create and forward the message to its peer.

However, the presence of the Destination-FQDN could be useful for
implementations when they want to figure out whether they should consume the
message locally or not. That said, a DSI is always consumed locally.

So, I suppose it doesn't really need to be present in the packet.


> 
> > > 6) In 9.1.1.4, replace DIAMETER_INVALID_RECORD_ROUTE by
> > > DIAMETER_INVALID_ROUTE_RECORD. Also, I think that this 
> > event should be in
> > > the Transient section, since the permanent section defines 
> > events for which
> > > messages can be forwarded to another node without any 
> > modification to its
> > > content, which I don't think can be possible in this case.
> > 
> > Well, how would the routes be modified? One is simply 
> > supposed to attached the
> > routes from the request into the response, so I don't 
> > understand what an
> > implementation could do to correct this error.
> 
> If I understand correctly, this check is only performed
> for request/query/indication messages, since it is the
> responsibility of the previous hop to add the route-record
> and the one of the actual node to validate the information.
> For answer/response messages, the only check that is required
> is to check if the route-recoud matches the local node.

hmmm... again I misread the question... sorry, my brain was apparently not
fully functional yesterday :(

> 
> So, I don't know either what the implementation can do about
> it?, and I don't understand neither why the downstream server
> should try to re-route the message to another node, as it
> is suggested in the DSI-permanent DSI-event. I guess you are
> suggesting to re-try other upstream servers until one understand 
> the match between the Route-Record and the sending IP address?
> That would mean that one of the upstream servers is badly
> configured. Maybe that would make sense?

That is correct. When receiving such an error, another server could be tried.
I will clean up the text to make this more obvious to the reader.

> 
> The change of name was due to the fact that Record-Route
> should be Route-Record instead, just as described by the AVP.

Right, I had missed that one in -02 :(

> 
> > > 19) In 10.4, I guess it should NOT be mandatory
> > > in the MRI, since the Origin should be the default sender 
> > of the Result-Code.
> > > It should be only be set if the Result-Code is modified by 
> > a node on the way.
> > 
> > That is what the text reads.
> 
> Yes, but the message format in 10.1 makes it required {}. It 
> should then be [] instead.

Sorry, could you please provide more info. I seem to be missing the problem
(see above on my issue with my non-functional brain :(

> 
> > > 16.1 should be modified to reflect 0-1 instead of 1.
> > 
> > Only the node that created the MRI needs to worry about these 
> > rules, and
> > therefore it should be a 1. Intermediate proxies wouldn't add another
> > Result-Code AVP, and therefore this rule wouldn't apply.
> 
> Same as before, if it is not modified by any proxy servers on the
> way, then I guess this AVP should not be included in the message, right?
> 

Again, I am confused. You seem to imply that a proxy that receives the MRI
must add the Result-Code AVP, when in fact they should only worry about
proxying the message.

Is there text anywhere that caused this confusion? 

PatC




From owner-aaa-bof@merit.edu  Wed Apr 25 09:58:08 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA16026
	for <aaa-archive@odin.ietf.org>; Wed, 25 Apr 2001 09:58:07 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id A6E595DE36; Wed, 25 Apr 2001 09:57:33 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 954735DE26; Wed, 25 Apr 2001 09:57:33 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id 4583E5DE23
	for <aaa-wg@merit.edu>; Wed, 25 Apr 2001 09:57:32 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA06898;
	Wed, 25 Apr 2001 06:57:27 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA29656;
	Wed, 25 Apr 2001 06:57:25 -0700 (PDT)
Received: from srmtv29a (srmtv29a [152.70.1.41])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id GAA04513;
	Wed, 25 Apr 2001 06:57:17 -0700 (PDT)
Date: Wed, 25 Apr 2001 06:57:18 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Subject: RE: [AAA-WG]: Date: Mon, 23 Apr 2001 11:02:13 +0200
To: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>
Cc: "'Patrice Calhoun'" <pcalhoun@nasnfs.Eng.Sun.COM>,
        "Yolanda Garcia-Serrano (ECE)" <yolanda.garcia-serrano@ece.ericsson.se>,
        "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>
In-Reply-To: "Your message with ID" <577066326047D41180AC00508B955DDA01D7FFBC@eestqnt104.es.eu.ericsson.se>
Message-ID: <Roam.SIMC.2.0.6.988207038.668.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> > > Furthermore, why is needed any distinction between them? If 
> > there is no
> > > strong argument maybe we can get rid of Request/Query and
> > > Response/Reply/Answer difference, and simply talk about Requests and
> > > Responses through all the spec.
> > 
> > We could, but there were cases where Queries exist, and these 
> > are a particular
> > type of message. See the Resource-Management (non WG 
> > document) as an example.
> 
> What do you mean by a particular type of request? Is it only a 
> nomenclature issue?, or is it because a query message can be
> handled differently than a request or indication message? Is it
> a question of priorities in terms of tasks?, or importance
> with regards to discarding the message or not answering it?

I am beginning to agree with you. I believe that we could just do away with
the Query, and re-use the Request messages for everything. Does anyone have
any objections? In any case, there aren't any WG documents that actually use
Query, just the Resource-Management extension, which is currently a personal
contribution.

> 
> > > Last paragraph in section 5.0 refers to mandatory AVPs for 
> > all messages
> > >    This section defines the Diameter AVPs that MUST be added in all
> > >    messages originated by a Diameter node (including nodes creating
> > >    Response and Answer messages).
> > > but Destination-FQDN is used in Indication, Reply and 
> > Answers only, so, it
> > > should not belong to this chapter, or better, this last 
> > paragraph in section
> > > 5.0 can be removed, as it adds no information, but  it can 
> > lead to confusion
> > > about this Destination-FQDN AVP.
> > 
> > The Destination-FQDN CAN in fact be present in request or 
> > queries. This is
> > useful in messages that require multiple round trips, or when 
> > e2e security is
> > used, and the message has a specific target.
> 
> The confusion comes from "...that MUST be added in all messages 
> originated by a Diameter node". I guess you meant "unsolicited 
> server initiated messages" from Diameter nodes, right? Like you're
> saying, they also may be included in request from clients, but
> not necessarily, which means that MUST NOT be in all messages.
> I think it is a question of wording.

You are correct. I will clean this text up for the -03 version.

> 
> Also, I would agree that the Destination-FQDN AVP MUST be part 
> of all answer/response messages, since the Origin-FQDN is part
> of every upstream message, and it makes sense that the Home server uses
> it within the answer/response messages. Also, it should always be used
> for the last hop to the client, as you seem to agree from the section
> 12.1.

Correct.

> 
> > > I miss as well how the Response is routed back to the Diameter
> > > client (which is not present in the drawing, and it will 
> > made it clearer, as
> > > DI1 is not the originator of the message, but the first proxy). With
> > > Destination-FQDN set to DIA1, how the response can reach 
> > the client ?
> > 
> > DIA1 *is* the client. The client's FQDN is in the 
> > Destination-FQDN AVP.
> 
> If you agree that DIA1 is the client, then why is it including
> a Route-Record AVP? I think that the Origin-FQDN AVP should be
> enough for the answer to include a Destination-FQDN for routing
> back to the client.

Correct. I will fix that as well.

PatC




From owner-aaa-bof@merit.edu  Wed Apr 25 10:33:44 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA17674
	for <aaa-archive@odin.ietf.org>; Wed, 25 Apr 2001 10:33:44 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 6020D5DE5C; Wed, 25 Apr 2001 10:03:54 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 50C305DE3C; Wed, 25 Apr 2001 10:03:54 -0400 (EDT)
Received: from ahab.tic.siemens.ca (ahab.tic.siemens.ca [64.26.131.130])
	by segue.merit.edu (Postfix) with ESMTP id 7BBFD5DE15
	for <aaa-wg@merit.edu>; Wed, 25 Apr 2001 10:03:52 -0400 (EDT)
Received: (from mail@localhost)
	by ahab.tic.siemens.ca (8.9.3/8.9.3) id KAA29121
	for <aaa-wg@merit.edu>; Wed, 25 Apr 2001 10:04:10 -0400 (EDT)
Received: from mailman(172.21.24.8) by ahab.tic.siemens.ca via smap (V2.1)
	id xma029119; Wed, 25 Apr 01 10:03:50 -0400
Received: (from mail@localhost)
	by mailman.innovation.siemens.ca (8.9.3/8.9.3) id KAA05319
	for <aaa-wg@merit.edu>; Wed, 25 Apr 2001 10:03:26 -0400 (EDT)
Received: from ticsmtp1.innovation.siemens.ca(172.21.24.34) by mailman.innovation.siemens.ca via smap (V2.1)
	id xma005215; Wed, 25 Apr 01 10:02:39 -0400
Received: by ticsmtp1.innovation.siemens.ca with Internet Mail Service (5.5.2650.21)
	id <2XDRFWCH>; Wed, 25 Apr 2001 10:02:30 -0400
Message-ID: <E7BB0E796757D411BC9A00105ACB123E32F6D7@ticsmtp1.innovation.siemens.ca>
From: Yiwen Jiang <Yiwen.Jiang@tic.siemens.ca>
To: "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>
Subject: RE: [AAA-WG]: AAA WG Interim Meeting Announcement (correction)
Date: Wed, 25 Apr 2001 10:02:27 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Hi there,

Having seen the emails on change of interim meeting dates, I was just
wondering when the "official" announcement will be out, so that I can book
my tickets? Or have we settled for the 21-22nd for good now? 

Thank you very much.

Cheers,
Yiwen
---
Yiwen Jiang
Mobile IP Networking
Email: Yiwen.Jiang@tic.siemens.ca
Phone: (613)271-7710

Telecom Innovation Centre
505 March Road
Kanata, Ontario, Canada
K2K 2M5



From owner-aaa-bof@merit.edu  Wed Apr 25 11:16:41 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19276
	for <aaa-archive@odin.ietf.org>; Wed, 25 Apr 2001 11:16:40 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 32FD45DDFF; Wed, 25 Apr 2001 09:42:47 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 20FEA5DDF8; Wed, 25 Apr 2001 09:42:47 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id A54625DDCE
	for <aaa-wg@merit.edu>; Wed, 25 Apr 2001 09:42:45 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA01436;
	Wed, 25 Apr 2001 06:42:35 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA23915;
	Wed, 25 Apr 2001 06:42:35 -0700 (PDT)
Received: from srmtv29a (srmtv29a [152.70.1.41])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id GAA04404;
	Wed, 25 Apr 2001 06:42:34 -0700 (PDT)
Date: Wed, 25 Apr 2001 06:42:35 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Subject: RE: [AAA-WG]: Date: Mon, 23 Apr 2001 11:02:13 +0200
To: "Yolanda Garcia-Serrano (ECE)" <yolanda.garcia-serrano@ece.ericsson.se>
Cc: "'Patrice Calhoun'" <pcalhoun@nasnfs.Eng.Sun.COM>,
        "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>
In-Reply-To: "Your message with ID" <577066326047D41180AC00508B955DDA02C009BB@eestqnt104.es.eu.ericsson.se>
Message-ID: <Roam.SIMC.2.0.6.988206155.23900.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> > > To understand the hole
> > > thing, one should go to both sections, so I suggest to 
> > merge them.  In that
> > > way, it would be clearer. E.g. it is weird to see 
> > Destination-FQDN and
> > > Destination-Realm AVP stated one in section 5.3, and the 
> > other in 12.4.7
> > 
> > So the Destination-FQDN is used in the message forwarding 
> > code, while the
> > Destination-Realm is used for forwarding purposes.
> > 
> Does this means that Destination-FQDN is used just to forward
> the message to last hop when being in Home domain, and that
> Destination-Realm is used for routing ?

That is correct. 

> I don't see the difference between "message forwarding code"
> and "forwarding purposes".

ok, let me try again (and perhaps if others are confused, it means additional
text is required in the spec).

You essentially have two separate tables; peers and routes.

The peers table is a list of all known peers that you communicate with. For
each one of these peers, you invoke the peer state machine. When a packet is
received that has a Destination-FQDN, you look at that AVP to see if the peer
in the AVP is in your table, and if so, you forward the message directly to
that peer.

The routes table contains a list of realms, and all peers that support that
realm. You could also have a default realm, but this is really an
implementation detail. When a packet is received, and the peer in the
Destination-FQDN AVP is unknown, the realm in the Destination-Realm AVP is
looked up in the routes table, and the packet is routed. of course, if no
route is found, a DSI even is returned with the appropriate error set, and
hope that the downstream server will forward the request to another server
that can support the request.

Back to forwarding. You may ask why there are two separate procedures. Well,
it is quite simple. If the Destination-Realm AVP was always used, then when a
route is found, the message would be sent to one of the many peers that
support the realm, when in fact the message had a very specific target host.

That is the main difference, and why you need separate lookup procedures.

> > > Section 5.3 Destination-FQDN AVP
> > 
> > > Should instead, state: "This AVP MUST be present in all 
> > unsolicited server
> > > initiated  messages, all reply and all answer messages." 
> > See example in
> > > section 12.1 
> > 
> > I could modify the figure to include the AVP in the request, 
> > but it is not
> > mandatory to be present when the client doesn't care which 
> > server handles the
> > request.
> > 
> 
> I just wanted the text to clearly state that Destination-FQDN MUST be 
> present as well in Answer and Response messages (nothing about
> Requests), no just only in Indications.

ok, sorry I missed your point ( but reading above, I see it was actually quite
clear the first time around :(

> > > I miss as well how the Response is routed back to the Diameter
> > > client (which is not present in the drawing, and it will 
> > made it clearer, as
> > > DI1 is not the originator of the message, but the first proxy). With
> > > Destination-FQDN set to DIA1, how the response can reach 
> > the client ?
> > 
> > DIA1 *is* the client. The client's FQDN is in the 
> > Destination-FQDN AVP.
> 
> I don't understand that DIA1 is the client, as the text says: "Figure 2
> depicts an example where DIA1 receives a request to authenticate user ...
> DIA1 looks up "abs.com" in its local realm route and ....
> So, DIA1 is the first proxy in the chain, but not the client, as it receives
> a RQ from someone else, right?

ok, looks like some of the text surrounding the figure needs to be modified to
match the figure.

> > > Section 12.2Proxy and Redirect Server handling of requests
> > 
> > No because the presence of the Destionation-Realm implies 
> > that the message is
> > routable. There are many cases where that is not the case 
> > (again, DRI, DSI and
> > the watchdog messages are examples).
> 
> Then, in table 16.1 for DRI and DSI, Destination-Realm should be 0 ?

correct.

> > > Section 12.4  Proxy Server
> > > 
> > > Say instead:  Maintaining transaction state implies that a 
> > server keeps a 
> > >       copy of a request or query which is then used when 
> > the corresponding
> > > response is
> > >    received.
> > 
> > You are proposing just removing text?
> 
> No, just add "query" to the sentence.

Ah, ok.

> > >    A stateless proxy is one that does not maintain session 
> > state, but
> > >    MUST maintain transaction state. Transaction state 
> > SHOULD be released
> > >    after a request's corresponding response has been 
> > forwarded towards
> > >    the recipient, and has been acknowledged by the 
> > underlying transport.
> > > Isn't it strange to call a proxy which keeps transaction 
> > state "stateless"?
> > 
> > Yes perhaps, but a minimal amount of state is unavoidable :(
> 
> This was exactly my point.
> 
> 
> > You mean in addition to 
> > 
> > " A stateless proxy is one that does not maintain session 
> > state, but MUST
> > maintain transaction state. Transaction state SHOULD be 
> > released after a
> > request's corresponding response has been forwarded towards 
> > the recipient,
> > and has been acknowledged by the underlying transport."
> > 
> > ?
> 
> I was suggesting to add something as "A stateless proxy is also the one that
> upon receipt of a Request/Query keeps the Hop-by-Hop identifier, and restore
> it to its original value after receiving the corresponding Answer/Response.
> Furthermore, a stateless proxy MAY also add a Proxy-State AVP for
> Request/Query and MUST remove it when receiving a message targeted to the
> Diameter local server.

ok, just add additional clarification. That sounds reasonable.

PatC




From owner-aaa-bof@merit.edu  Wed Apr 25 13:15:29 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA23157
	for <aaa-archive@odin.ietf.org>; Wed, 25 Apr 2001 13:15:28 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id CB9E15DDAE; Tue, 24 Apr 2001 13:53:04 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id AF8A35DDAD; Tue, 24 Apr 2001 13:53:04 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 524A95DD91
	for <aaa-wg@merit.edu>; Tue, 24 Apr 2001 13:53:02 -0400 (EDT)
Received: from gwzpc (sjc-vpn-476.cisco.com [10.21.65.220]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id KAA10473; Tue, 24 Apr 2001 10:44:07 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Randy Bush" <randy@psg.com>,
        "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>
Cc: "David Mitton" <dmitton@nortelnetworks.com>, "aaa-wg" <aaa-wg@merit.edu>,
        <aboba@internaut.com>, "Wijnen, Bert (Bert)" <bwijnen@lucent.com>,
        <scoya@ietf.org>
Subject: RE: [AAA-WG]: AAA WG Interim Meeting Announcement (correction)
Date: Tue, 24 Apr 2001 10:43:04 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPAEGHDHAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
In-Reply-To: <E14s3Fw-0004iO-00@rip.psg.com>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Randy Bush [mailto:randy@psg.com] writes:

> how about mon/tue?  the ops/nm interim is wed.

I thought that that was the original proposal?  Anyway, works for me.

> 
> randy
> 



From owner-aaa-bof@merit.edu  Wed Apr 25 16:15:16 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA29821
	for <aaa-archive@odin.ietf.org>; Wed, 25 Apr 2001 16:15:16 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 6C38F5DDDC; Wed, 25 Apr 2001 16:14:52 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 5B1165DDCF; Wed, 25 Apr 2001 16:14:52 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id CA4C35DDA6
	for <aaa-wg@merit.edu>; Wed, 25 Apr 2001 16:14:50 -0400 (EDT)
Received: from gwzpc (sjc-vpn-534.cisco.com [10.21.66.22]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id NAA28501; Wed, 25 Apr 2001 13:14:46 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Yiwen Jiang" <Yiwen.Jiang@tic.siemens.ca>
Cc: "AAA WG" <aaa-wg@merit.edu>
Subject: RE: [AAA-WG]: AAA WG Interim Meeting Announcement (correction)
Date: Wed, 25 Apr 2001 13:01:35 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPEEHMDHAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <E7BB0E796757D411BC9A00105ACB123E32F6D7@ticsmtp1.innovation.siemens.ca>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Importance: Normal
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Yiwen Jiang [mailto:Yiwen.Jiang@tic.siemens.ca] writes:

> Hi there,
>
> Having seen the emails on change of interim meeting dates, I was just
> wondering when the "official" announcement will be out, so that I can book
> my tickets?

I have already made reservations.  I must know if things are changing by
5:00 PM Pacific Time on Friday or pay a major penalty.  Can we have a
decision, please?

> Or have we settled for the 21-22nd for good now?
>
> Thank you very much.
>
> Cheers,
> Yiwen
> ---
> Yiwen Jiang
> Mobile IP Networking
> Email: Yiwen.Jiang@tic.siemens.ca
> Phone: (613)271-7710
>
> Telecom Innovation Centre
> 505 March Road
> Kanata, Ontario, Canada
> K2K 2M5
>
>




From owner-aaa-bof@merit.edu  Wed Apr 25 17:00:22 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01028
	for <aaa-archive@odin.ietf.org>; Wed, 25 Apr 2001 17:00:21 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 85C6D5DE13; Wed, 25 Apr 2001 04:31:19 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 684885DDB1; Wed, 25 Apr 2001 04:31:19 -0400 (EDT)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110])
	by segue.merit.edu (Postfix) with ESMTP id 4151D5DDA6
	for <aaa-wg@merit.edu>; Wed, 25 Apr 2001 04:31:17 -0400 (EDT)
Received: from esealnt409.al.sw.ericsson.se (ESEALNT409.al.sw.ericsson.se [153.88.251.32])
	by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with SMTP id f3P8VGO17936
	for <aaa-wg@merit.edu>; Wed, 25 Apr 2001 10:31:16 +0200 (MEST)
Received: FROM esealnt743.al.sw.ericsson.se BY esealnt409.al.sw.ericsson.se ; Wed Apr 25 10:31:16 2001 +0200
Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <HA3DQ91P>; Wed, 25 Apr 2001 10:31:14 +0200
Message-ID: <577066326047D41180AC00508B955DDA02C009BB@eestqnt104.es.eu.ericsson.se>
From: "Yolanda Garcia-Serrano (ECE)" <yolanda.garcia-serrano@ece.ericsson.se>
To: "'Patrice Calhoun'" <pcalhoun@nasnfs.Eng.Sun.COM>
Cc: "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>
Subject: RE: [AAA-WG]: Date: Mon, 23 Apr 2001 11:02:13 +0200
Date: Wed, 25 Apr 2001 10:31:08 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id RAA01028

Hi, Pat
Thanks a lot for your answers.
See inlined still some doubts/comments.

BR
	/Yolanda García


> > To understand the hole
> > thing, one should go to both sections, so I suggest to 
> merge them.  In that
> > way, it would be clearer. E.g. it is weird to see 
> Destination-FQDN and
> > Destination-Realm AVP stated one in section 5.3, and the 
> other in 12.4.7
> 
> So the Destination-FQDN is used in the message forwarding 
> code, while the
> Destination-Realm is used for forwarding purposes.
> 
Does this means that Destination-FQDN is used just to forward
the message to last hop when being in Home domain, and that
Destination-Realm is used for routing ?
I don't see the difference between "message forwarding code"
and "forwarding purposes".



> > Section 5.3 Destination-FQDN AVP
> 
> > Should instead, state: "This AVP MUST be present in all 
> unsolicited server
> > initiated  messages, all reply and all answer messages." 
> See example in
> > section 12.1 
> 
> I could modify the figure to include the AVP in the request, 
> but it is not
> mandatory to be present when the client doesn't care which 
> server handles the
> request.
> 

I just wanted the text to clearly state that Destination-FQDN MUST be 
present as well in Answer and Response messages (nothing about
Requests), no just only in Indications.



> > I miss as well how the Response is routed back to the Diameter
> > client (which is not present in the drawing, and it will 
> made it clearer, as
> > DI1 is not the originator of the message, but the first proxy). With
> > Destination-FQDN set to DIA1, how the response can reach 
> the client ?
> 
> DIA1 *is* the client. The client's FQDN is in the 
> Destination-FQDN AVP.

I don't understand that DIA1 is the client, as the text says: "Figure 2
depicts an example where DIA1 receives a request to authenticate user ...
DIA1 looks up "abs.com" in its local realm route and ....
So, DIA1 is the first proxy in the chain, but not the client, as it receives
a RQ from someone else, right?



> > Section 12.2Proxy and Redirect Server handling of requests
> 
> No because the presence of the Destionation-Realm implies 
> that the message is
> routable. There are many cases where that is not the case 
> (again, DRI, DSI and
> the watchdog messages are examples).

Then, in table 16.1 for DRI and DSI, Destination-Realm should be 0 ?


> > Section 12.4  Proxy Server
> > 
> > Say instead:  Maintaining transaction state implies that a 
> server keeps a 
> >       copy of a request or query which is then used when 
> the corresponding
> > response is
> >    received.
> 
> You are proposing just removing text?

No, just add "query" to the sentence.


> >    A stateless proxy is one that does not maintain session 
> state, but
> >    MUST maintain transaction state. Transaction state 
> SHOULD be released
> >    after a request's corresponding response has been 
> forwarded towards
> >    the recipient, and has been acknowledged by the 
> underlying transport.
> > Isn't it strange to call a proxy which keeps transaction 
> state "stateless"?
> 
> Yes perhaps, but a minimal amount of state is unavoidable :(

This was exactly my point.


> You mean in addition to 
> 
> " A stateless proxy is one that does not maintain session 
> state, but MUST
> maintain transaction state. Transaction state SHOULD be 
> released after a
> request's corresponding response has been forwarded towards 
> the recipient,
> and has been acknowledged by the underlying transport."
> 
> ?

I was suggesting to add something as "A stateless proxy is also the one that
upon receipt of a Request/Query keeps the Hop-by-Hop identifier, and restore
it to its original value after receiving the corresponding Answer/Response.
Furthermore, a stateless proxy MAY also add a Proxy-State AVP for Request/Query
and MUST remove it when receiving a message targeted to the Diameter local server.

 
> Thanks for the great comments!
> PatC

It's nice try to modestly contribute to reach a better spec.
Thanks to you.
Yolanda



From owner-aaa-bof@merit.edu  Wed Apr 25 17:04:19 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01125
	for <aaa-archive@odin.ietf.org>; Wed, 25 Apr 2001 17:04:18 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 495CA5DEA1; Wed, 25 Apr 2001 17:02:11 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 37ED55DEA0; Wed, 25 Apr 2001 17:02:11 -0400 (EDT)
Received: from ws2.piuha.net (ws2.piuha.net [195.165.196.2])
	by segue.merit.edu (Postfix) with ESMTP id AB0FD5DE90
	for <aaa-wg@merit.edu>; Wed, 25 Apr 2001 17:02:09 -0400 (EDT)
Received: from kolumbus.fi (ws4.piuha.net [195.165.196.4])
	by ws2.piuha.net (Postfix) with ESMTP
	id C3E646A905; Thu, 26 Apr 2001 00:01:57 +0300 (EEST)
Message-ID: <3AE73BFB.3020604@kolumbus.fi>
Date: Thu, 26 Apr 2001 00:04:59 +0300
From: Jari Arkko <jari.arkko@kolumbus.fi>
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.3-ipsec i686; en-US; m18) Gecko/20001107 Netscape6/6.0
X-Accept-Language: en
MIME-Version: 1.0
To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Cc: Jari Arkko <Jari.Arkko@lmf.ericsson.se>, aaa-wg@merit.edu
Subject: Re: [AAA-WG]: separated authorization and accounting servers?
References: <Roam.SIMC.2.0.6.988154082.27720.pcalhoun@nasnfs>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit



Patrice Calhoun wrote:

> It used to when Accounting was a separate extension, but although I fought
> hard to keep it an extension, WG comments was that Accounting MUST be in the
> base protocol.
> 
> So, this is no longer possible, other than by manual configuration.
> 
> Unless we re-introduce the extension-Id for accounting in the base...

It isn't clear to me why the extension id or the RFC structure makes a 
difference,
but manual configuration is still possible? I think this covers the need 
we had,
a network server is configured with the address of the main AA server, plus
the accounting server.

> 
>> But can we do this? We haven't figured out if the
>> specifications say anything about this. Section 13.1
>> talks about authorization server directed model, but
>> I would classify the "direction" as optional information.
>> Section 13.2 says servers that receive a succesfull
>> authentication response must collect accounting information.
>> But must they send it too? And can there be other nodes
>> that would not perform authentication/authorization but
>> who still produce accounting information (e.g. for
>> trend analysis purposes)? Section 11 talks about user
>> sessions and their life-cycle. But it doesn't seem to
>> state anything about this issue in particular.
> 
> 
> Not sure that I follow you here. Only the access device generates accounting
> messages. Is this not clear in the draft? If not, it certainly needs to be
> fixed.

Well, consider the case of some random node using Diameter accounting to
produce accounting data for e.g. statistics purposes. Can we do that?

> 
>> Do we allow two proxies to be configured for a client
>> node, one for the authentication and authorization, and
>> the second one for accounting?
> 
> 
> It used to be possible, and is in RADIUS, but no longer in -02 due to the
> changes I noted above.

Now I lost you! Again, I'm not sure why the extension id makes a difference
here. Yet you seemed to say first that by manual configuration this is 
possible.
Either the manual config is possible or not, but I don't think the fact 
that the
next node is a proxy shouldn't make a difference.

Jari




From owner-aaa-bof@merit.edu  Wed Apr 25 17:11:10 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01246
	for <aaa-archive@odin.ietf.org>; Wed, 25 Apr 2001 17:11:10 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 1E4D75DDC6; Wed, 25 Apr 2001 17:10:54 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 0915A5DDCF; Wed, 25 Apr 2001 17:10:54 -0400 (EDT)
Received: from zrc2s03g.us.nortel.com (unknown [47.103.122.66])
	by segue.merit.edu (Postfix) with ESMTP id 979D55DDC6
	for <aaa-wg@merit.edu>; Wed, 25 Apr 2001 17:10:52 -0400 (EDT)
Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id QAA22694
	for <aaa-wg@merit.edu>; Wed, 25 Apr 2001 16:11:16 -0500 (CDT)
Received: from zsc4c000.us.nortel.com by smtprch1.nortel.com;
          Wed, 25 Apr 2001 16:10:45 -0500
Received: from zbl6c016.corpeast.baynetworks.com ([132.245.205.66]) 
          by zsc4c000.us.nortel.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) 
          id J4QL9A5N; Wed, 25 Apr 2001 14:10:26 -0700
Received: from mitton.nortelnetworks.com (47.16.86.121 [47.16.86.121]) 
          by zbl6c016.corpeast.baynetworks.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) 
          id JRCMHGDD; Wed, 25 Apr 2001 17:10:24 -0400
Message-Id: <4.3.2.7.2.20010425153906.0465f360@ZBL6C016.corpeast.baynetworks.com>
X-Sender: dmitton@ZBL6C016.corpeast.baynetworks.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 25 Apr 2001 17:12:09 -0400
To: aaa-wg <aaa-wg@merit.edu>
From: "David Mitton" <dmitton@nortelnetworks.com>
Subject: [AAA-WG]: AAA WG Interim Meeting Announcement (Final Answer)
Cc: aboba@internaut.com, Randy Bush <randy@psg.com>,
        "Wijnen, Bert (Bert)" <bwijnen@lucent.com>, scoya@ietf.org
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

[the dates have been changed from the earlier announcements to avoid 
various problems ;^) - Yes, we know this is the same time as Nanog]

----------------------------------------
AAA Working Group Interim Meeting
Monday & Tuesday, May 21-22th, Santa Clara, CA

-----------------------------------------------
The meeting will be held at the Nortel Networks facility (previously Bay 
Networks) 4401 Great America Parkway, Santa Clara, CA 95054.

An agenda will be issued at a later time.  The goal of the meeting is a 
complete review/edit of the base Diameter drafts for WG and IETF Last 
Call.  Drafts not dealing with the primary functions will not be 
pursued.  The meeting will run 9-5 each day, or until we finish.

The meeting will be in the "Orientation Room", Building SC1, on the first 
floor. [still working on confirmation for current dates]

The facility is 4 miles north of San Jose Airport
and 25 miles south of San Francisco Airport off US 101.
(be aware that traffic on 101 will jam during rush hours)

The campus is next to Great America amusement park and the Santa Clara 
Convention Center.  There are a number of hotels of various levels near 
by.  Some are in walking distance.

If you have any questions, email me dmitton@nortelnetworks.com
(if no response within 24hrs, try dave@mitton.com)

- Dave.

-------------------
Driving Directions

 From San Francisco International Airport
- 101 South, 25 miles
- Exit Great America Parkway, turn left onto Great America Parkway, 1/4 mile
- Nortel Networks - SC1 is located at the corner of Great America Parkway & 
Mission College Blvd

 From San Jose International Airport
- 101 North, 4 miles
- Exit Great America Parkway, turn right onto Great America Parkway, 1/4 mile
- Nortel Networks - SC1 is located at the corner of Great America Parkway & 
Mission College Blvd

---------------------------------------------------------------
David Mitton                                  ESN: 248-4570
Advisor, Nortel Networks                      978-288-4570 Direct
Wireless Solutions, IP Mobility
Billerica, MA 01821                    dmitton@nortelnetworks.com




From owner-aaa-bof@merit.edu  Wed Apr 25 17:26:19 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01656
	for <aaa-archive@odin.ietf.org>; Wed, 25 Apr 2001 17:26:19 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 38B855DF1E; Wed, 25 Apr 2001 17:24:33 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 20F895DF1C; Wed, 25 Apr 2001 17:24:33 -0400 (EDT)
Received: from zcars0m9.nortelnetworks.com (h157s242a129n47.user.nortelnetworks.com [47.129.242.157])
	by segue.merit.edu (Postfix) with SMTP id 23AE35DF16
	for <aaa-wg@merit.edu>; Wed, 25 Apr 2001 17:24:30 -0400 (EDT)
Received: from zcars04f.ca.nortel.com by zcars0m9.nortelnetworks.com (SMI-8.6/SMI-SVR4)
	id RAA13975; Wed, 25 Apr 2001 17:24:23 -0400
Received: from zbl6c012.corpeast.baynetworks.com by zcars04f.ca.nortel.com;
          Wed, 25 Apr 2001 17:24:17 -0400
Received: from zbl6c016.corpeast.baynetworks.com ([132.245.205.66]) 
          by zbl6c012.corpeast.baynetworks.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) 
          id J4QCLHW3; Wed, 25 Apr 2001 17:24:16 -0400
Received: from mitton.nortelnetworks.com (47.16.86.121 [47.16.86.121]) 
          by zbl6c016.corpeast.baynetworks.com 
          with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) 
          id JRCMHGDQ; Wed, 25 Apr 2001 17:24:14 -0400
Message-Id: <4.3.2.7.2.20010425172240.00cbb6a0@ZBL6C016.corpeast.baynetworks.com>
X-Sender: dmitton@ZBL6C016.corpeast.baynetworks.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Wed, 25 Apr 2001 17:25:57 -0400
To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>,
        "David Mitton" <dmitton@nortelnetworks.com>
From: "David Mitton" <dmitton@nortelnetworks.com>
Subject: RE: [AAA-WG]: separated authorization and accounting servers
Cc: John Alayari <johnal@cisco.com>, Jari Arkko <Jari.Arkko@lmf.ericsson.se>,
        aaa-wg <aaa-wg@merit.edu>
In-Reply-To: <Roam.SIMC.2.0.6.988154791.2644.pcalhoun@nasnfs>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
X-Orig: <dmitton@nortelnetworks.com>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

At 4/24/01 07:26 PM -0400, Patrice Calhoun wrote:

> > Yes,
> >    you can devise all sorts of scenarios where separated Accounting and
> > Authentication make sense.  Some people do it RADIUS.
> >
> > However,
> >          Accounting messages are essential to session state keeping
> > Authorization servers, and since we have not added any Session Terminate
> > Report messages, I think Accounting should be Mandatory back to the Auth
> > servers.
>
>Huh? The base protocol defines the STR message, which does just that. I 
>really
>want to avoid re-using accounting messages to maintain state information.
>
>PatC

You're right.
Hmm... somehow I'm confused.  I'll go off and sort out my confusionination.


I do agree with a separate point Jari makes in a later message, there will 
be people that will want to implement Accounting for accounting's sake, 
independent of the Auth/Auth stream.   Perhaps we need to call out that as 
a different "application".

Dave.
---------------------------------------------------------------
David Mitton                                  ESN: 248-4570
Advisor, Nortel Networks                      978-288-4570 Direct
Wireless Solutions, IP Mobility
Billerica, MA 01821                    dmitton@nortelnetworks.com




From owner-aaa-bof@merit.edu  Wed Apr 25 18:46:37 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA03259
	for <aaa-archive@odin.ietf.org>; Wed, 25 Apr 2001 18:46:37 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 89A465DE2C; Wed, 25 Apr 2001 18:44:26 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 7230D5DDDF; Wed, 25 Apr 2001 18:44:26 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 304B75DDBB
	for <aaa-wg@merit.edu>; Wed, 25 Apr 2001 18:43:57 -0400 (EDT)
Received: from gwzpc (sjc-vpn-tmp217.cisco.com [10.21.64.217]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id PAA07115; Wed, 25 Apr 2001 15:35:01 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "David Mitton" <dmitton@nortelnetworks.com>, "aaa-wg" <aaa-wg@merit.edu>
Cc: <aboba@internaut.com>, "Randy Bush" <randy@psg.com>,
        "Wijnen, Bert (Bert)" <bwijnen@lucent.com>, <scoya@ietf.org>
Subject: RE: [AAA-WG]: AAA WG Interim Meeting Announcement (Final Answer)
Date: Wed, 25 Apr 2001 15:34:58 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPOEHPDHAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <4.3.2.7.2.20010425153906.0465f360@ZBL6C016.corpeast.baynetworks.com>
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Is this _final_?

> -----Original Message-----
> From: owner-aaa-bof@merit.edu [mailto:owner-aaa-bof@merit.edu]On Behalf
> Of David Mitton
> Sent: Wednesday, April 25, 2001 2:12 PM
> To: aaa-wg
> Cc: aboba@internaut.com; Randy Bush; Wijnen, Bert (Bert); scoya@ietf.org
> Subject: [AAA-WG]: AAA WG Interim Meeting Announcement (Final Answer)
>
>
> [the dates have been changed from the earlier announcements to avoid
> various problems ;^) - Yes, we know this is the same time as Nanog]
>
> ----------------------------------------
> AAA Working Group Interim Meeting
> Monday & Tuesday, May 21-22th, Santa Clara, CA
>
> -----------------------------------------------
> The meeting will be held at the Nortel Networks facility (previously Bay
> Networks) 4401 Great America Parkway, Santa Clara, CA 95054.
>
> An agenda will be issued at a later time.  The goal of the meeting is a
> complete review/edit of the base Diameter drafts for WG and IETF Last
> Call.  Drafts not dealing with the primary functions will not be
> pursued.  The meeting will run 9-5 each day, or until we finish.
>
> The meeting will be in the "Orientation Room", Building SC1, on the first
> floor. [still working on confirmation for current dates]
>
> The facility is 4 miles north of San Jose Airport
> and 25 miles south of San Francisco Airport off US 101.
> (be aware that traffic on 101 will jam during rush hours)
>
> The campus is next to Great America amusement park and the Santa Clara
> Convention Center.  There are a number of hotels of various levels near
> by.  Some are in walking distance.
>
> If you have any questions, email me dmitton@nortelnetworks.com
> (if no response within 24hrs, try dave@mitton.com)
>
> - Dave.
>
> -------------------
> Driving Directions
>
>  From San Francisco International Airport
> - 101 South, 25 miles
> - Exit Great America Parkway, turn left onto Great America
> Parkway, 1/4 mile
> - Nortel Networks - SC1 is located at the corner of Great America
> Parkway &
> Mission College Blvd
>
>  From San Jose International Airport
> - 101 North, 4 miles
> - Exit Great America Parkway, turn right onto Great America
> Parkway, 1/4 mile
> - Nortel Networks - SC1 is located at the corner of Great America
> Parkway &
> Mission College Blvd
>
> ---------------------------------------------------------------
> David Mitton                                  ESN: 248-4570
> Advisor, Nortel Networks                      978-288-4570 Direct
> Wireless Solutions, IP Mobility
> Billerica, MA 01821                    dmitton@nortelnetworks.com
>
>
>




From owner-aaa-bof@merit.edu  Thu Apr 26 09:54:48 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA03863
	for <aaa-archive@odin.ietf.org>; Thu, 26 Apr 2001 09:54:48 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id C28D65DE42; Thu, 26 Apr 2001 09:53:32 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id B16725DE39; Thu, 26 Apr 2001 09:53:32 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id 3D9AD5DDF1
	for <aaa-wg@merit.edu>; Thu, 26 Apr 2001 09:53:31 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id GAA18241;
	Thu, 26 Apr 2001 06:53:21 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA29380;
	Thu, 26 Apr 2001 06:53:20 -0700 (PDT)
Received: from darius (darius [152.70.40.121])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id GAA28591;
	Thu, 26 Apr 2001 06:53:19 -0700 (PDT)
Date: Thu, 26 Apr 2001 06:53:22 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Subject: Re: [AAA-WG]: separated authorization and accounting servers?
To: Jari Arkko <jari.arkko@kolumbus.fi>
Cc: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>,
        Jari Arkko <Jari.Arkko@lmf.ericsson.se>, aaa-wg@merit.edu
In-Reply-To: "Your message with ID" <3AE73BFB.3020604@kolumbus.fi>
Message-ID: <Roam.SIMC.2.0.6.988293202.6386.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> 
> 
> Patrice Calhoun wrote:
> 
> > It used to when Accounting was a separate extension, but although I fought
> > hard to keep it an extension, WG comments was that Accounting MUST be in the
> > base protocol.
> > 
> > So, this is no longer possible, other than by manual configuration.
> > 
> > Unless we re-introduce the extension-Id for accounting in the base...
> 
> It isn't clear to me why the extension id or the RFC structure makes a 
> difference,

If an extension id is assigned to accounting, then it is part of the
capabilities exchange. Servers can specify that they wish to receive
accounting packets, while others do not. This can force accounting to go to
particular servers.

> but manual configuration is still possible? I think this covers the need 
> we had,
> a network server is configured with the address of the main AA server, plus
> the accounting server.

yes, manual configuration is still possible, but I would have thought we'd be
able to do better than RADIUS. I still think that making it part of the
exchange it the right way to go, but the base doesn't have an extension
identifier :(

> 
> > 
> >> But can we do this? We haven't figured out if the
> >> specifications say anything about this. Section 13.1
> >> talks about authorization server directed model, but
> >> I would classify the "direction" as optional information.
> >> Section 13.2 says servers that receive a succesfull
> >> authentication response must collect accounting information.
> >> But must they send it too? And can there be other nodes
> >> that would not perform authentication/authorization but
> >> who still produce accounting information (e.g. for
> >> trend analysis purposes)? Section 11 talks about user
> >> sessions and their life-cycle. But it doesn't seem to
> >> state anything about this issue in particular.
> > 
> > 
> > Not sure that I follow you here. Only the access device generates accounting
> > messages. Is this not clear in the draft? If not, it certainly needs to be
> > fixed.
> 
> Well, consider the case of some random node using Diameter accounting to
> produce accounting data for e.g. statistics purposes. Can we do that?

sure. Accounting does not have to following authorization. However, a policy
on a server MAY require that authorization be successful prior to accepting
accounting records for a particular extension.

> 
> > 
> >> Do we allow two proxies to be configured for a client
> >> node, one for the authentication and authorization, and
> >> the second one for accounting?
> > 
> > 
> > It used to be possible, and is in RADIUS, but no longer in -02 due to the
> > changes I noted above.
> 
> Now I lost you! Again, I'm not sure why the extension id makes a difference
> here. Yet you seemed to say first that by manual configuration this is 
> possible.
> Either the manual config is possible or not, but I don't think the fact 
> that the
> next node is a proxy shouldn't make a difference.

see above.

PatC




From owner-aaa-bof@merit.edu  Thu Apr 26 09:56:52 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA03966
	for <aaa-archive@odin.ietf.org>; Thu, 26 Apr 2001 09:56:51 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 9D6F55DDD2; Thu, 26 Apr 2001 09:56:32 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 862605DDE1; Thu, 26 Apr 2001 09:56:32 -0400 (EDT)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id 455CF5DDD2
	for <aaa-wg@merit.edu>; Thu, 26 Apr 2001 09:56:31 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id GAA08150;
	Thu, 26 Apr 2001 06:55:50 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id GAA29764;
	Thu, 26 Apr 2001 06:55:49 -0700 (PDT)
Received: from darius (darius [152.70.40.121])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id GAA28601;
	Thu, 26 Apr 2001 06:55:43 -0700 (PDT)
Date: Thu, 26 Apr 2001 06:55:46 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Subject: RE: [AAA-WG]: separated authorization and accounting servers
To: David Mitton <dmitton@nortelnetworks.com>
Cc: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>,
        John Alayari <johnal@cisco.com>,
        Jari Arkko <Jari.Arkko@lmf.ericsson.se>, aaa-wg <aaa-wg@merit.edu>
In-Reply-To: "Your message with ID" <4.3.2.7.2.20010425172240.00cbb6a0@ZBL6C016.corpeast.baynetworks.com>
Message-ID: <Roam.SIMC.2.0.6.988293346.20649.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk


> I do agree with a separate point Jari makes in a later message, there will 
> be people that will want to implement Accounting for accounting's sake, 
> independent of the Auth/Auth stream.   Perhaps we need to call out that as 
> a different "application".
> 

Why does this sound like I'll be spliting the base back into two documents...
:(

PatC




From owner-aaa-bof@merit.edu  Thu Apr 26 10:20:24 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA04922
	for <aaa-archive@odin.ietf.org>; Thu, 26 Apr 2001 10:20:24 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 24BB15DE6B; Thu, 26 Apr 2001 10:18:33 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 1235A5DE67; Thu, 26 Apr 2001 10:18:33 -0400 (EDT)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116])
	by segue.merit.edu (Postfix) with ESMTP id 14BA45DE0E
	for <aaa-wg@merit.edu>; Thu, 26 Apr 2001 10:18:31 -0400 (EDT)
Received: from esealnt462.al.sw.ericsson.se (ESEALNT462.al.sw.ericsson.se [153.88.251.62])
	by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with SMTP id f3QEITN01158
	for <aaa-wg@merit.edu>; Thu, 26 Apr 2001 16:18:30 +0200 (MEST)
Received: FROM esealnt743.al.sw.ericsson.se BY esealnt462.al.sw.ericsson.se ; Thu Apr 26 16:18:09 2001 +0200
Received: by ESEALNT743.al.sw.ericsson.se with Internet Mail Service (5.5.2653.19)
	id <HA3DS88M>; Thu, 26 Apr 2001 16:18:10 +0200
Message-ID: <3DFC2DB418B2D211A1950008C7A4E1EA0D042F66@eestqnt102>
From: "Victor Manuel Avila Gonzalez (ECE)" <victor-manuel.avila-gonzalez@ece.ericsson.se>
To: "'Patrice Calhoun'" <pcalhoun@nasnfs.Eng.Sun.COM>
Cc: aaa-wg@merit.edu
Subject: RE: [AAA-WG]: separated authorization and accounting servers?
Date: Thu, 26 Apr 2001 16:18:08 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

See below

-----Original Message-----
From: Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM]
Sent: jueves 26 de abril de 2001 15:53
To: Jari Arkko
Cc: Patrice Calhoun; Jari Arkko; aaa-wg@merit.edu
Subject: Re: [AAA-WG]: separated authorization and accounting servers?


> 
> 
> Patrice Calhoun wrote:
> 
> > It used to when Accounting was a separate extension, but although I fought
> > hard to keep it an extension, WG comments was that Accounting MUST be in the
> > base protocol.
> > 
> > So, this is no longer possible, other than by manual configuration.
> > 
> > Unless we re-introduce the extension-Id for accounting in the base...
> 
> It isn't clear to me why the extension id or the RFC structure makes a 
> difference,

If an extension id is assigned to accounting, then it is part of the
capabilities exchange. Servers can specify that they wish to receive
accounting packets, while others do not. This can force accounting to go to
particular servers.

> but manual configuration is still possible? I think this covers the need 
> we had,
> a network server is configured with the address of the main AA server, plus
> the accounting server.

yes, manual configuration is still possible, but I would have thought we'd be
able to do better than RADIUS. I still think that making it part of the
exchange it the right way to go, but the base doesn't have an extension
identifier :(

> 
> > 
> >> But can we do this? We haven't figured out if the
> >> specifications say anything about this. Section 13.1
> >> talks about authorization server directed model, but
> >> I would classify the "direction" as optional information.
> >> Section 13.2 says servers that receive a succesfull
> >> authentication response must collect accounting information.
> >> But must they send it too? And can there be other nodes
> >> that would not perform authentication/authorization but
> >> who still produce accounting information (e.g. for
> >> trend analysis purposes)? Section 11 talks about user
> >> sessions and their life-cycle. But it doesn't seem to
> >> state anything about this issue in particular.
> > 
> > 
> > Not sure that I follow you here. Only the access device generates accounting
> > messages. Is this not clear in the draft? If not, it certainly needs to be
> > fixed.
> 
> Well, consider the case of some random node using Diameter accounting to
> produce accounting data for e.g. statistics purposes. Can we do that?

sure. Accounting does not have to following authorization. However, a policy
on a server MAY require that authorization be successful prior to accepting
accounting records for a particular extension.



___________________________________________________________________________
	Then, what does it mean the sentence in section 13.1??

"This accounting protocol is based on an authorization-server directed model"

	And how to understand the session state machine in section 11.1 where the action to move the state idle to pending ( I understand that this should be the first step when initiating a dialogue ) is  " send serv. specific auth req" ????


____________________________________________________________________________




> 
> > 
> >> Do we allow two proxies to be configured for a client
> >> node, one for the authentication and authorization, and
> >> the second one for accounting?
> > 
> > 
> > It used to be possible, and is in RADIUS, but no longer in -02 due to the
> > changes I noted above.
> 
> Now I lost you! Again, I'm not sure why the extension id makes a difference
> here. Yet you seemed to say first that by manual configuration this is 
> possible.
> Either the manual config is possible or not, but I don't think the fact 
> that the
> next node is a proxy shouldn't make a difference.

see above.

PatC




From owner-aaa-bof@merit.edu  Thu Apr 26 12:14:33 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10302
	for <aaa-archive@odin.ietf.org>; Thu, 26 Apr 2001 12:14:32 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id E69C35DDE5; Thu, 26 Apr 2001 12:14:16 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id D530C5DD99; Thu, 26 Apr 2001 12:14:16 -0400 (EDT)
Received: from zrc2s03g.us.nortel.com (unknown [47.103.122.66])
	by segue.merit.edu (Postfix) with ESMTP id 3C9E85DD97
	for <aaa-wg@merit.edu>; Thu, 26 Apr 2001 12:14:15 -0400 (EDT)
Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id LAA00212
	for <aaa-wg@merit.edu>; Thu, 26 Apr 2001 11:14:37 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch1.nortel.com;
          Thu, 26 Apr 2001 11:14:10 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <JCX5248K>; Thu, 26 Apr 2001 11:13:55 -0500
Message-ID: <85AA7486A2C1D411BCA20000F8073E4355CA38@crchy271.us.nortel.com>
From: "Rambabu Tummala" <tummala@nortelnetworks.com>
To: aaa-wg@merit.edu
Subject: [AAA-WG]: Comments on draft-ietf-aaa-diameter-mobileip-02.txt
Date: Thu, 26 Apr 2001 11:13:48 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0CE6B.E06C7280"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0CE6B.E06C7280
Content-Type: text/plain;
	charset="iso-8859-1"

Pat,

The AMA message is missing AVPs Destination-Realm AVP and Destination-FQDN
AVP.  These have to be atleast optional in the AMA message.  
If Destination-Realm AVP is not present in the AMA, how would the message be
routed back to the AAAF from AAAH.  
If Destination-FQDN AVP is present, the message can easily delivered to the
originating FA by AAAF.
AAAH has the information from the AMR message it received.

The same comments apply to HAA also.

-Regards,
Rambabu Tummala
Nortel Networks
ESN 444-8970
External (972)684-8970


------_=_NextPart_001_01C0CE6B.E06C7280
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.59">
<TITLE>Comments on draft-ietf-aaa-diameter-mobileip-02.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2 FACE=3D"Arial">Pat,</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The AMA message is missing AVPs</FONT> =
<FONT FACE=3D"Times New Roman">Destination-Realm AVP and =
Destination-FQDN AVP.&nbsp; These have to be atleast optional in the =
AMA message.&nbsp; </FONT></P>

<P><FONT FACE=3D"Times New Roman">If Destination-Realm AVP is not =
present in the AMA, how would the message be routed back to the AAAF =
from AAAH.&nbsp; </FONT>
<BR><FONT FACE=3D"Times New Roman">If Destination-FQDN AVP is present, =
the message can easily delivered to the originating FA by AAAF.</FONT>
<BR><FONT FACE=3D"Times New Roman">AAAH has the information from the =
AMR message it received.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">The same comments apply to HAA =
also.</FONT>
</P>

<P><FONT SIZE=3D2 FACE=3D"Arial">-Regards,</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Bookman Old Style">Rambabu Tummala</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Bookman Old Style">Nortel Networks</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Bookman Old Style">ESN 444-8970</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Bookman Old Style">External =
(972)684-8970</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0CE6B.E06C7280--



From owner-aaa-bof@merit.edu  Thu Apr 26 12:45:37 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11844
	for <aaa-archive@odin.ietf.org>; Thu, 26 Apr 2001 12:45:37 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 9E9605DE6E; Thu, 26 Apr 2001 12:44:46 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 8CD6E5DE3D; Thu, 26 Apr 2001 12:44:46 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id 1E6EA5DDF6
	for <aaa-wg@merit.edu>; Thu, 26 Apr 2001 12:44:45 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id JAA09249;
	Thu, 26 Apr 2001 09:44:31 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA25311;
	Thu, 26 Apr 2001 09:44:30 -0700 (PDT)
Received: from darius (darius [152.70.40.121])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id JAA00481;
	Thu, 26 Apr 2001 09:44:29 -0700 (PDT)
Date: Thu, 26 Apr 2001 09:44:33 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Subject: Re: [AAA-WG]: Comments on draft-ietf-aaa-diameter-mobileip-02.txt
To: Fredrik Johansson <fredrik.johansson@ipunplugged.com>
Cc: AAA Listan <aaa-wg@merit.edu>
In-Reply-To: "Your message with ID" <MJEMJBGGCLLDLFFAHLJKCEONCJAA.fredrik.johansson@ipunplugged.com>
Message-ID: <Roam.SIMC.2.0.6.988303473.16375.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

and here is the rest....

> "Upon receipt of the AMA, the foreign agent recovers the Foreign-Home
>    registration key, and uses this key to create a Mobile-Foreign
>    authentication extension to the Registration Reply message."
> 
> Queue?!? Sounds like this should be under section 6.2 and it should be:
> "Upon receipt of the AMA, the foreign agent recovers the Foreign-Mobile
>  registration key, and uses this key to create a Mobile-foreign
>  authentication extension to the Registration Reply message."

It is in the right section, but it should read:

"Upon receipt of the AMA, the foreign agent recovers the Foreign-Home
 registration key, and uses this key to create a Foreign-Home
 authentication extension to the Registration Reply message."

> 
> Section 7.1.1
> "The MIP-MN-to-FA-Key AVP (AVP Code 325) is of type OctetString, and
>    contains the Keying material described in the "Unsolicited MN-FA Key
>    from AAA Subtype" in [15]. The FA SPI field of the data structure in
>    [15] MUST be set to the same value as the MIP-Peer-SPI AVP within the
>    FA-to-MN-Key AVP."
> 
> Change according to the new AAA keys for MIP draft (when there is a new
> version :-))
> 
> Section 7.1.2
> same as 7.1.1

ok

> 
> Section 7.2
> 
> I believe that we should add AVPs in the Grouped AVP that indicates what
> algorithm type/mode, replay protection, to use. As it is today, the MIP
> agents can only assume that some default mode is used. This is in the same
> way as we agreed that the MIP Key Reply extension should be extended in the
> AAA Keys for MIP draft (or if it was in Charlies "generalized key draft")

You are correct.

> 
> Section 10.2
> 
> In the table it is indicated that all of Session-Time, Packet, and Octets
> AVPs MUST be present in ACR and ACA. Is it really mandatory to allways
> measure both time, packets and bytes. If you only do time based accounting,
> why should you have to send the other two types? Or should you send them
> with a value of zero?

Well, I don't see how it hurts to send them all, and the billing package uses
the information that it wants to generate the bills. 

PatC




From owner-aaa-bof@merit.edu  Thu Apr 26 13:35:51 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA13606
	for <aaa-archive@odin.ietf.org>; Thu, 26 Apr 2001 13:35:50 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 2AF635DE7C; Thu, 26 Apr 2001 13:08:11 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 19F305DE5B; Thu, 26 Apr 2001 13:08:11 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id C7A3A5DE29
	for <aaa-wg@merit.edu>; Thu, 26 Apr 2001 13:08:09 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA22083;
	Thu, 26 Apr 2001 10:07:06 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA04600;
	Thu, 26 Apr 2001 10:05:41 -0700 (PDT)
Received: from darius (darius [152.70.40.121])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id KAA00815;
	Thu, 26 Apr 2001 10:05:39 -0700 (PDT)
Date: Thu, 26 Apr 2001 10:05:43 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Subject: Re: [AAA-WG]: Comments on draft-ietf-aaa-diameter-mobileip-02.txt
To: Rambabu Tummala <tummala@nortelnetworks.com>
Cc: aaa-wg@merit.edu
In-Reply-To: "Your message with ID" <85AA7486A2C1D411BCA20000F8073E4355CA38@crchy271.us.nortel.com>
Message-ID: <Roam.SIMC.2.0.6.988304743.22973.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> The AMA message is missing AVPs Destination-Realm AVP and Destination-FQDN
> AVP.  These have to be atleast optional in the AMA message.  
> If Destination-Realm AVP is not present in the AMA, how would the message be
> routed back to the AAAF from AAAH.  
> If Destination-FQDN AVP is present, the message can easily delivered to the
> originating FA by AAAF.
> AAAH has the information from the AMR message it received.
> 
> The same comments apply to HAA also.

You are correct. Furthermore, the Destination-FQDN MUST also be optional in
the HAR, since the HAR may be directed at a particular Home Agent.

PatC




From owner-aaa-bof@merit.edu  Thu Apr 26 13:48:33 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14159
	for <aaa-archive@odin.ietf.org>; Thu, 26 Apr 2001 13:48:32 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 756115DEE9; Thu, 26 Apr 2001 13:43:48 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 01D0C5DEE2; Thu, 26 Apr 2001 13:43:42 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id 8E4835DEE5
	for <aaa-wg@merit.edu>; Thu, 26 Apr 2001 13:42:25 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA11121;
	Thu, 26 Apr 2001 10:40:40 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA11898;
	Thu, 26 Apr 2001 10:35:32 -0700 (PDT)
Received: from darius (darius [152.70.40.121])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id KAA06249;
	Thu, 26 Apr 2001 10:35:31 -0700 (PDT)
Date: Thu, 26 Apr 2001 10:35:35 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Subject: Re: [AAA-WG]: Re: Route-Record AVP in Indication message
To: Michael Chen <cchen@erilab.com>
Cc: Pat.Calhoun@Sun.COM, aaa-wg@merit.edu
In-Reply-To: "Your message with ID" <3AD5E700.C52D13F6@erilab.com>
Message-ID: <Roam.SIMC.2.0.6.988306535.29774.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> 
> 
> Patrice Calhoun wrote:
> 
> > >Here is the request send to AAA4
> > >AAA1->AAA2->AAA3---- link broken ---->AAA4
> > >
> > >AAA3----send DSI---->AAA1
> > >
> > >AAA3 must generate DSI and send it back to AAA1.
> >
> > This is where you are wrong. DSI is in the Per-Hop Error Signaling section.
> > This means that AAA3 does not send a DSI to AAA1, but to AAA2. AAA2 must
> > take the message from its pending queue, take some local action, and if it
> > is unable to forward the message, it generates a DSI to AAA1. So, the message
> > from the queue is used to figure out where to send the DSI to, and it is
> > used to figure out what Hop-by-Hop Identifier to put in the DSI message.
> >
> 
> Thanks for the reply.  DSI is Per-Hop Error Singnal so we don't use neither
> Route-Record or Destination-Realm.
> Just for curiosity, what if AAA2 is stateless?

I think perhaps we will have to use terms other than stateful and stateless.
The text reads that it is mandatory that transaction state be maintained. So a
stateless server is not *really* stateless.

Any suggestions on terminology?

PatC




From owner-aaa-bof@merit.edu  Thu Apr 26 13:50:05 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA14215
	for <aaa-archive@odin.ietf.org>; Thu, 26 Apr 2001 13:50:05 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 9B4D75DE20; Thu, 26 Apr 2001 13:27:42 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 870B55DDD1; Thu, 26 Apr 2001 13:27:42 -0400 (EDT)
Received: from saturn.sun.com (saturn.Sun.COM [192.9.25.2])
	by segue.merit.edu (Postfix) with ESMTP id 3A2FD5DDF5
	for <aaa-wg@merit.edu>; Thu, 26 Apr 2001 13:27:22 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id KAA23369;
	Thu, 26 Apr 2001 10:27:17 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA09817;
	Thu, 26 Apr 2001 10:27:17 -0700 (PDT)
Received: from darius (darius [152.70.40.121])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id KAA06055;
	Thu, 26 Apr 2001 10:27:14 -0700 (PDT)
Date: Thu, 26 Apr 2001 10:27:18 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Subject: Re: [AAA-WG]: Another routing detail
To: "Yolanda Garcia-Serrano (ECE)" <yolanda.garcia-serrano@ece.ericsson.se>
Cc: pcalhoun@nasnfs.Eng.Sun.COM, "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>
In-Reply-To: "Your message with ID" <577066326047D41180AC00508B955DDA02C009B4@eestqnt104.es.eu.ericsson.se>
Message-ID: <Roam.SIMC.2.0.6.988306038.4878.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> Hi, again
> 
> I've forgotten one issue in my last e-mail about routing. Here goes:
> 
> Section 16.1:
> I think Destination-FQDN and Destination-Realm should be 1 for DWR message.


The Destination-FQDN MAY be present, but not the Destination-Realm since this
is not a routable message.

PatC




From owner-aaa-bof@merit.edu  Thu Apr 26 14:04:32 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14686
	for <aaa-archive@odin.ietf.org>; Thu, 26 Apr 2001 14:04:32 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 68E145DE74; Thu, 26 Apr 2001 14:02:41 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 56EBB5DE72; Thu, 26 Apr 2001 14:02:41 -0400 (EDT)
Received: from saturn.sun.com (saturn.Sun.COM [192.9.25.2])
	by segue.merit.edu (Postfix) with ESMTP id 1C6905DDF5
	for <aaa-wg@merit.edu>; Thu, 26 Apr 2001 14:02:40 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by saturn.sun.com (8.9.3+Sun/8.9.3) with ESMTP id LAA27439;
	Thu, 26 Apr 2001 11:02:37 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA19140;
	Thu, 26 Apr 2001 11:02:37 -0700 (PDT)
Received: from darius (darius [152.70.40.121])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id LAA06520;
	Thu, 26 Apr 2001 11:02:35 -0700 (PDT)
Date: Thu, 26 Apr 2001 11:02:39 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Subject: Re: [AAA-WG]: Msg Header Identifiers??
To: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>
Cc: "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>
In-Reply-To: "Your message with ID" <577066326047D41180AC00508B955DDA01D7FF95@eestqnt104.es.eu.ericsson.se>
Message-ID: <Roam.SIMC.2.0.6.988308159.12497.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> Hi,
> 
> Should messages received with an un-expected Hop-by-Hop 
> or End-to-End Identifier in the header be discarded?, 
> or should a DSI or MRI be sent? I think it SHOULD be locally
> logged, and MUST be discarded. What do you think?

I presume you mean messages of type Response or Answer, and I believe you are
correct. 

> 
> Should duplicates be also discarded? I would assume that
> a duplicate message detected based on the Hop-By-Hop Identifier
> should be discarded, while a duplicate message detected based
> on the End-to-End Identifier is not so obvious to me.

For Request, Query or Indication messages, I don't think so. Perhaps there is
a problem in the proxy chain that caused a message to take two paths. For
responses or answer, yes it can be discarded.

> 
> The introduction of the End-to-End Identifier was to detect
> when a Diameter client was re-sending a pending request, since
> it was impatient. Now that we have the DSI-Event "STILL_WORKING",
> and the Max-Wait-Time AVP, do we still need the End-to-End 
> Identifier? 

A home server may want to minimize processing unnecessary packets, and the E2E
ID would allow it to queue recently sent responses. Of course, the
Record-Route AVPs and Proxy-State (now Proxy-Info) should have to change.

> 
> Anyway, the thing is that if a duplicate detected based on the 
> End-to-End Identifier is received in the Home server while it is still 
> processing the previous request, should the Home server send an
> MRI with a new Result-Code to "Duplicate Message-Still Working"?
see above on home servers being able to queue recent responses.

> That would make sure that the Diameter nodes on the way to the Home
> server do not retry to re-send once more the duplicate message
> as well. The "Duplicate Message-Still Working" would be an End-to-End
> error of type Permanent.
I am not sure that we can guarantee that a dup message will never occur, and
we need to handle such cases when failures in the network occur.

PatC




From owner-aaa-bof@merit.edu  Thu Apr 26 14:58:50 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16063
	for <aaa-archive@odin.ietf.org>; Thu, 26 Apr 2001 14:58:49 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 3727D5DE96; Thu, 26 Apr 2001 14:52:47 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 189585DE8F; Thu, 26 Apr 2001 14:52:47 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id F3E1F5DEA0
	for <aaa-wg@merit.edu>; Thu, 26 Apr 2001 14:50:41 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id LAA24911;
	Thu, 26 Apr 2001 11:49:54 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id LAA21453;
	Thu, 26 Apr 2001 11:49:52 -0700 (PDT)
Received: from darius (darius [152.70.40.121])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id LAA07053;
	Thu, 26 Apr 2001 11:49:48 -0700 (PDT)
Date: Thu, 26 Apr 2001 11:49:52 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Subject: RE: [AAA-WG]: separated authorization and accounting servers
To: gwz@cisco.com
Cc: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>,
        David Mitton <dmitton@nortelnetworks.com>,
        John Alayari <johnal@cisco.com>,
        Jari Arkko <Jari.Arkko@lmf.ericsson.se>, aaa-wg <aaa-wg@merit.edu>
In-Reply-To: "Your message with ID" <NDBBIHMPILAAGDHPCIOPEEIMDHAA.gwz@cisco.com>
Message-ID: <Roam.SIMC.2.0.6.988310992.23852.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:
> 
> > > I do agree with a separate point Jari makes in a later message,
> > there will
> > > be people that will want to implement Accounting for accounting's sake,
> > > independent of the Auth/Auth stream.   Perhaps we need to call
> > out that as
> > > a different "application".
> > >
> >
> > Why does this sound like I'll be spliting the base back into two
> > documents...
> > :(
> 
> Changing the format of the documents doesn't solve the problem.

When accounting was separate, it had its own extension. When an accounting
message was en-route towards the home domain, a specific accounting server
could advertise itself in the home network, and we could guarantee that all
accounting messages would be sent to that particular server.

As it stands right now, accounting messages would be sent to *any* server in
the home domain, unless the proxies were (manually) configured for a specific
Accounting server, which is how RADIUS works today.

Perhaps this is enough.

PatC




From owner-aaa-bof@merit.edu  Thu Apr 26 14:59:38 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA16091
	for <aaa-archive@odin.ietf.org>; Thu, 26 Apr 2001 14:59:37 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 5523D5DE5D; Thu, 26 Apr 2001 14:52:51 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id D31575DECE; Thu, 26 Apr 2001 14:52:50 -0400 (EDT)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17])
	by segue.merit.edu (Postfix) with ESMTP id 197185DE5D
	for <aaa-wg@merit.edu>; Thu, 26 Apr 2001 14:49:17 -0400 (EDT)
Received: from gwzpc (sjc-vpn-tmp203.cisco.com [10.21.64.203]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id LAA28512; Thu, 26 Apr 2001 11:46:06 -0700 (PDT)
Reply-To: <gwz@cisco.com>
From: "Glen Zorn" <gwz@cisco.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>,
        "David Mitton" <dmitton@nortelnetworks.com>
Cc: "John Alayari" <johnal@cisco.com>,
        "Jari Arkko" <Jari.Arkko@lmf.ericsson.se>, "aaa-wg" <aaa-wg@merit.edu>
Subject: RE: [AAA-WG]: separated authorization and accounting servers
Date: Thu, 26 Apr 2001 11:41:49 -0700
Message-ID: <NDBBIHMPILAAGDHPCIOPEEIMDHAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <Roam.SIMC.2.0.6.988293346.20649.pcalhoun@nasnfs>
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Importance: Normal
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM] writes:

> > I do agree with a separate point Jari makes in a later message,
> there will
> > be people that will want to implement Accounting for accounting's sake,
> > independent of the Auth/Auth stream.   Perhaps we need to call
> out that as
> > a different "application".
> >
>
> Why does this sound like I'll be spliting the base back into two
> documents...
> :(

Changing the format of the documents doesn't solve the problem.

>
> PatC
>
>
>




From owner-aaa-bof@merit.edu  Thu Apr 26 15:33:17 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17153
	for <aaa-archive@odin.ietf.org>; Thu, 26 Apr 2001 15:33:16 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 8C7D45DDF6; Thu, 26 Apr 2001 13:52:18 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 7301F5DE0A; Thu, 26 Apr 2001 13:52:18 -0400 (EDT)
Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240])
	by segue.merit.edu (Postfix) with ESMTP id C850B5DDF6
	for <aaa-wg@merit.edu>; Thu, 26 Apr 2001 13:52:16 -0400 (EDT)
Received: from mr6.exu.ericsson.se. (mr6u3.ericy.com [208.237.135.123])
	by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id f3QHqJ808715;
	Thu, 26 Apr 2001 12:52:19 -0500 (CDT)
Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179])
	by mr6.exu.ericsson.se. (8.11.3/8.11.3) with ESMTP id f3QHqFn03726;
	Thu, 26 Apr 2001 12:52:15 -0500 (CDT)
Received: from pop.exu.ericsson.se (qpop [138.85.1.15]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id MAA24367; Thu, 26 Apr 2001 12:52:15 -0500 (CDT)
Received: from ericsson.com (busam59.berkeley.us.am.ericsson.se [138.85.159.209])
	by pop.exu.ericsson.se (8.9.1/8.9.1) with ESMTP id MAA16255;
	Thu, 26 Apr 2001 12:52:05 -0500 (CDT)
Message-ID: <3AE85FFB.A6075370@ericsson.com>
Date: Thu, 26 Apr 2001 10:50:51 -0700
From: Tony Johansson <tony.johansson@ericsson.com>
X-Mailer: Mozilla 4.75 [en] (Win98; U)
X-Accept-Language: en
MIME-Version: 1.0
To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Cc: Rambabu Tummala <tummala@nortelnetworks.com>, aaa-wg@merit.edu
Subject: Re: [AAA-WG]: Comments on draft-ietf-aaa-diameter-mobileip-02.txt
References: <Roam.SIMC.2.0.6.988304743.22973.pcalhoun@nasnfs>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit

Hi Pat and Rambabu,

Please see comments embedded...

BR,

/Tony

Patrice Calhoun wrote:

> > The AMA message is missing AVPs Destination-Realm AVP and Destination-FQDN
> > AVP.  These have to be atleast optional in the AMA message.
> > If Destination-Realm AVP is not present in the AMA, how would the message be
> > routed back to the AAAF from AAAH.

You use the Route-Record and not on the Destination-Realm AVP to route the AMA
back from the AAAH to the AAAF. So why should the Destination-Realm AVP be present
in the AMA?!

>
> > If Destination-FQDN AVP is present, the message can easily delivered to the
> > originating FA by AAAF.
> > AAAH has the information from the AMR message it received.

I agree.

>
> >
> > The same comments apply to HAA also.
>
> You are correct. Furthermore, the Destination-FQDN MUST also be optional in
> the HAR, since the HAR may be directed at a particular Home Agent.

I don't understand. Why do we need Destination-FQDN in the HAR message?

>
>
> PatC




From owner-aaa-bof@merit.edu  Thu Apr 26 15:54:37 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17566
	for <aaa-archive@odin.ietf.org>; Thu, 26 Apr 2001 15:54:37 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 870765DEA8; Thu, 26 Apr 2001 14:06:52 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 762B45DDED; Thu, 26 Apr 2001 14:06:52 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id 215905DEAA
	for <aaa-wg@merit.edu>; Thu, 26 Apr 2001 14:06:36 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA19788;
	Thu, 26 Apr 2001 11:06:29 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA15784;
	Thu, 26 Apr 2001 10:49:50 -0700 (PDT)
Received: from darius (darius [152.70.40.121])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id KAA06394;
	Thu, 26 Apr 2001 10:49:48 -0700 (PDT)
Date: Thu, 26 Apr 2001 10:49:52 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Subject: Re: [AAA-WG]: draft-ietf-aaa-diameter-02.txt / Proxy-State
To: Bob Kopacz <BKopacz@InterlinkNetworks.com>
Cc: Pat Calhoun <Pat.Calhoun@eng.sun.com>, aaa-wg <aaa-wg@merit.edu>
In-Reply-To: "Your message with ID" <NEBBKEONLKEDJCMHGHPIIEHOCBAA.BKopacz@InterlinkNetworks.com>
Message-ID: <Roam.SIMC.2.0.6.988307392.25583.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> Hi Pat,
> 
> Here is a problem and a proposed solution:
> 

[solution delete]

Bob,

Thanks for the proposal. It has been included in -03. I agree that this
minimal change will eliminate alot of problems with dual RADIUS/Diameter
implementations.

Thanks,

PatC




From owner-aaa-bof@merit.edu  Thu Apr 26 16:09:17 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18053
	for <aaa-archive@odin.ietf.org>; Thu, 26 Apr 2001 16:09:17 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id EDECB5DD92; Thu, 26 Apr 2001 14:31:47 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id BD1B75DDED; Thu, 26 Apr 2001 14:31:46 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id 6FFB15DD92
	for <aaa-wg@merit.edu>; Thu, 26 Apr 2001 14:31:40 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA24540;
	Thu, 26 Apr 2001 11:25:05 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA17762;
	Thu, 26 Apr 2001 10:57:28 -0700 (PDT)
Received: from darius (darius [152.70.40.121])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id KAA06455;
	Thu, 26 Apr 2001 10:57:25 -0700 (PDT)
Date: Thu, 26 Apr 2001 10:57:29 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Subject: Re: [AAA-WG]: Comments on draft-ietf-aaa-diameter-mobileip-02.txt
To: Tony Johansson <tony.johansson@ericsson.com>
Cc: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>,
        Rambabu Tummala <tummala@nortelnetworks.com>, aaa-wg@merit.edu
In-Reply-To: "Your message with ID" <3AE85FFB.A6075370@ericsson.com>
Message-ID: <Roam.SIMC.2.0.6.988307849.29318.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> > > The AMA message is missing AVPs Destination-Realm AVP and
Destination-FQDN > > > AVP.  These have to be atleast optional in the AMA
message. > > > If Destination-Realm AVP is not present in the AMA, how would
the message be > > > routed back to the AAAF from AAAH.
> 
> You use the Route-Record and not on the Destination-Realm AVP to route the
> AMA back from the AAAH to the AAAF. So why should the Destination-Realm AVP
> be present in the AMA?!

oops, you are correct. The Destination-Realm is not necessary, but the *-FQDN
is. Sorry I didn't really respond to that message.

> 
> >
> > > If Destination-FQDN AVP is present, the message can easily delivered to the
> > > originating FA by AAAF.
> > > AAAH has the information from the AMR message it received.
> 
> I agree.
> 
> >
> > >
> > > The same comments apply to HAA also.
> >
> > You are correct. Furthermore, the Destination-FQDN MUST also be optional in
> > the HAR, since the HAR may be directed at a particular Home Agent.
> 
> I don't understand. Why do we need Destination-FQDN in the HAR message?

Let us assume that the first time around a Home Agent is assigned in a visited
network. The next time around (i.e. re-registration), you want to make sure
that the HAR is sent to the proper Home Agent, right? So the Destination-FQDN
would provide that feature.

PatC




From owner-aaa-bof@merit.edu  Thu Apr 26 16:33:27 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18896
	for <aaa-archive@odin.ietf.org>; Thu, 26 Apr 2001 16:33:22 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 7A77B5DE41; Thu, 26 Apr 2001 16:30:38 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id C62295DE7B; Thu, 26 Apr 2001 16:30:26 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id D4E1A5DE78
	for <aaa-wg@merit.edu>; Thu, 26 Apr 2001 16:29:37 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA11735
	for <aaa-wg@merit.edu>; Thu, 26 Apr 2001 13:29:20 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA13266
	for <aaa-wg@merit.edu>; Thu, 26 Apr 2001 13:29:15 -0700 (PDT)
Received: from darius (darius [152.70.40.121])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id NAA13747
	for <aaa-wg@merit.edu>; Thu, 26 Apr 2001 13:29:13 -0700 (PDT)
Date: Thu, 26 Apr 2001 13:29:16 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Subject: [AAA-WG]: A resolution to the Accounting problem
To: aaa-wg@merit.edu
Message-ID: <Roam.SIMC.2.0.6.988316956.10485.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Problem:

People have been asking recently how does a server specify that it wishes to
receive accounting messages? This used to be possible when the Accounting
stuff was in a separate extension, but it no longer is possible in -02 because
accounting is part of the base.

Solution:

The authentication and authorization part of the protocol advertises its
supported extensions via the Extension-Id AVP in the DRI message. However,
each extension has AVPs that it specifies needs to be present in accounting
messages. So in any case, you have different accounting messages (well, the
AVPs are different) based on the application.

So, could we not simply create a new AVP that is exchanged in the DRI, called
the Accounting-Extension-Id? It would use the same address space as the
existing Extension-Id AVP, but this would be ONLY for accounting purposes.
This way a server could advertise that it wishes to receive both auth and acct
messages for MIP ONLY, or perhaps only NASREQ and MIP acct messages, etc.

This seems very flexible, and an even better solution to the old approach
(read split acct from base) that would not allow a peer to advertise that it
only wanted accounting messages for a particular application.

Thoughts?

PatC




From owner-aaa-bof@merit.edu  Thu Apr 26 16:35:00 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA19063
	for <aaa-archive@odin.ietf.org>; Thu, 26 Apr 2001 16:34:59 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 2A5FD5DF62; Thu, 26 Apr 2001 16:32:47 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 95BA25DF55; Thu, 26 Apr 2001 16:32:45 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id B301B5DEBB
	for <aaa-wg@merit.edu>; Thu, 26 Apr 2001 16:32:07 -0400 (EDT)
Received: from engmail3.Eng.Sun.COM ([129.144.170.5])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA12909;
	Thu, 26 Apr 2001 13:31:13 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail3.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id NAA13728;
	Thu, 26 Apr 2001 13:31:12 -0700 (PDT)
Received: from darius (darius [152.70.40.121])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id NAA13773;
	Thu, 26 Apr 2001 13:31:09 -0700 (PDT)
Date: Thu, 26 Apr 2001 13:31:13 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Subject: RE: [AAA-WG]: Comments on draft-ietf-aaa-diameter-mobileip-02.txt
To: Rambabu Tummala <tummala@nortelnetworks.com>
Cc: "'Tony Johansson'" <tony.johansson@ericsson.com>,
        Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>, aaa-wg@merit.edu
In-Reply-To: "Your message with ID" <85AA7486A2C1D411BCA20000F8073E4355CA39@crchy271.us.nortel.com>
Message-ID: <Roam.SIMC.2.0.6.988317073.1437.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> Patrice Calhoun wrote:
> 
> > > > The AMA message is missing AVPs Destination-Realm AVP and
> Destination-FQDN
> > > > AVP.  These have to be atleast optional in the AMA message.
> > > > If Destination-Realm AVP is not present in the AMA, how would the
> message be
> > > > routed back to the AAAF from AAAH.
> 
> > You use the Route-Record and not on the Destination-Realm AVP to route the
> AMA
> > back from the AAAH to the AAAF. So why should the Destination-Realm AVP be
> present
> > in the AMA?!
> I am not sure what happens to Route-Record AVP, if the AMR travels through
> multiple proxy servers.  I think having Destination-Realm AVP and
> Destination-FQDN are cleanest way to do it.

The base protocol is pretty clear in that responses and answers are proxied
using the Route-Record AVP, not the Destination-Realm AVP.

PatC




From owner-aaa-bof@merit.edu  Thu Apr 26 17:00:01 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21491
	for <aaa-archive@odin.ietf.org>; Thu, 26 Apr 2001 17:00:00 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 56AE65DD97; Thu, 26 Apr 2001 12:27:05 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 467B95DD99; Thu, 26 Apr 2001 12:27:05 -0400 (EDT)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id D51F05DD97
	for <aaa-wg@merit.edu>; Thu, 26 Apr 2001 12:27:03 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA19511;
	Thu, 26 Apr 2001 09:27:00 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA21120;
	Thu, 26 Apr 2001 09:26:59 -0700 (PDT)
Received: from darius (darius [152.70.40.121])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id JAA00150;
	Thu, 26 Apr 2001 09:26:57 -0700 (PDT)
Date: Thu, 26 Apr 2001 09:26:59 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Subject: Re: [AAA-WG]: Comments on draft-ietf-aaa-diameter-mobileip-02.txt
To: Fredrik Johansson <fredrik.johansson@ipunplugged.com>
Cc: AAA Listan <aaa-wg@merit.edu>
In-Reply-To: "Your message with ID" <MJEMJBGGCLLDLFFAHLJKGEOLCJAA.fredrik.johansson@ipunplugged.com>
Message-ID: <Roam.SIMC.2.0.6.988302419.26179.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> Section 1.2
> "If AAAH does not know the address of the home agent (perhaps because
>    it will be allocated by AAAF within the visited domain as described
>    in section 1.3), then AAAH sends an AMA message back to AAAF which
>    does not contain a MIP-Reg-Reply AVP."
> 
> It will send a HAR not an AMA.

Actually the paragraph should read:

"If the AAAH does not know the address of the home agent (perhaps because it
will be allocated by AAAF within the visited domain as described in
section 1.3), then AAAH sends an HAR message to AAAF which contains a
MIP-Reg-Request AVP."

> 
> Section 1.4
> 
> Maybe there should be a note that CHAP style authentication cannot be used
> since the client will not receive a challenge.

Why can't the Home Agent issue Challenges in its advertisements?

> 
> Section 1.5
> Should you really force the AAAF to keep session state?

I see the issue, and can enforce that only the HA can receive an STR. However,
this will NOT permit the AAAF to issue a disconnect. How would a Foreign Agent
terminate service?

> B.T.W. what should the result code be, what I'm thinking about is that
> section 2.2 says
> 
> "An AMA message with the Result-Code AVP indicating success MUST also
>    include the MIP-Reg-Reply AVP."
> 
> and if AAAF should be able to return the keys it has to do so without a
> MIP-Reg-Reply AVP.

ok, so would a request for keys include a MIP-Reg-Request? If not, then the
fix is simple, otherwise it is quite a bit more difficult. The reality is that
you do not know whether the request will be sent to the AAAH or not.

(Is it possible that transfering keys can be done outside of AAA? Perhaps
context transfer, or via the FA blob that MIP was looking at some time back?)

> 
> Section 3.1 and Section 4.1 both have a error code of 4004 and 4002-4003 are
> used in the base protocol.

DSI Events and Result-Codes do not share the same address space, so there is
no conflict.

> 
> Section 5.5-6
> 
> Clarification needed. What should the reply code be? A note that the FA
> should send the MIP-Reg-Request directly to the HA when it has received the
> needed keys.

I believe this is the same question as above. See my previous question.

> 
> Section 5.7
> 
> "If the mobile node includes a Generalized MN-FA Key Request [15]
>    extension with the AAA subtype in its Registration Request, the"
> 
> Should it be the Generalized MN-FA Key Request or will it change when the
> AAA Registration Keys for Mobile IP is rewritten?

The name will be the same, I believe.

However, I will look at this once more when I am done with the other draft.

> 
> Section 5.8.1
> "The MIP-MN-AAA-SPI AVP (AVP Code 341) is of type Unsigned32 and
>    indicates the algorithm by which the targeted AAA server (AAAH)
>    should attempt to validate the Authenticator computed by the mobile
>    node over the Registration Request data."
> 
> Pat, didn't we agree on rewriting this to conform with the way the SPI is
> used in MIP, i.e. the SPI indicates a security context which contains Key,
> Lifetime, Algorithm, Algorithm mode ...

No, I *thought* our agreement was in relation to the MIP AAA Keys draft, which
would now include all of this information. no?

> 
> Section 5.10
> "The Filter-Rule AVP (AVP Code 400) is of type OctetString, encoded in
>    the UTF-8 [29] format, and provides filter rules that need to be
>    configured on the Foreign Agent for the user. One or more such AVPs
>    MAY be present in an authorization response."
> 
> I believe that it should be possible to configure the home agent as well,
> I'm not sure that the home agent would like to trust the FA to do the
> filtering.

right.

> 
> 
> more on section 5.10
> 
> "If no rule matches, the packet is dropped if the last
>    rule evaluated was a permit, and passed if the last rule was a deny."
> 
> This sounds kind of strange, shouldn't you allways drop the packet if no
> match was found?

Please query Barney Wolff in a separate thread on this one. 

> section 6.1
> "The AAAH
>    has to rely on the home agent (that also understands Diameter) to
>    transfer the key into a Mobile IP Generalized MN-HA Key Reply
>    extension in the Registration Reply message."
> 
> Same as in 5.8.1, shouldn't it be Mobile IP Generalizeed Key Reply after the
> key dist. draft is rewritten?

Let's wait and see what the outcome of the MIP AAA Keys changes result.

> "The foreign
>    agent can then use that AVP to recreate a Registration Reply message,
>    containing the Generalized MN-HA Key Reply extension, for delivery to
>    the mobile node."
> 
> Generalized MN-HA Key Reply -> Generalized Key Reply with subtype MN-HA

see above.

> 
> section 6.2
> "
>    The Mobile-Foreign registration key is also generated by AAAH (upon
>    request), so that it can be encoded into a MIP-MN-to-FA-Key AVP,
>    which is added to the HAR, and copied by the home agent into a
>    Generalized MN-FA Key Reply Extension [15] to the Mobile IP
>    Registration Reply message. Most of the considerations for
>    distributing the Mobile-Foreign registration key are similar to the
>    distribution of the Mobile-Home Registration Key."
> 
> Generalized MN-FA Key Reply Extension -> Generalized Key Reply Extension
> with subtype MN-FA

ditto.

Thanks for the comments!

PatC




From owner-aaa-bof@merit.edu  Thu Apr 26 17:01:23 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21537
	for <aaa-archive@odin.ietf.org>; Thu, 26 Apr 2001 17:01:23 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 92B205DEB7; Thu, 26 Apr 2001 13:32:49 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 7BC555DEF9; Thu, 26 Apr 2001 13:32:49 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id 030AE5DEB7
	for <aaa-wg@merit.edu>; Thu, 26 Apr 2001 13:32:48 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id KAA09429;
	Thu, 26 Apr 2001 10:32:44 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id KAA11060;
	Thu, 26 Apr 2001 10:32:41 -0700 (PDT)
Received: from darius (darius [152.70.40.121])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id KAA06221;
	Thu, 26 Apr 2001 10:32:31 -0700 (PDT)
Date: Thu, 26 Apr 2001 10:32:35 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Subject: Re: [AAA-WG]: IANA considerations
To: Jari Arkko <Jari.Arkko@lmf.ericsson.se>
Cc: aaa-wg@merit.edu, jarkko@piuha.net
In-Reply-To: "Your message with ID" <3ADD6EBA.9A9215C7@lmf.ericsson.se>
Message-ID: <Roam.SIMC.2.0.6.988306355.16832.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> 
> I just read the IANA considerations section of the
> base protocol. It seems OK, but there is one part
> that worries me: currently, we allow new extension
> IDs for only services that are _Standards Track RFCs_.
> Given that the extension number space is 32 bits
> wide, and that various new services might pop up
> that require specific new functionality in the
> form of an extension, why are we requiring this
> much? Wouldn't allocation through Designated
> Expert be sufficient? Or do we expect all new services
> stay solely within the business of adding new AVPs?

You are correct, and it has been changed to Designated Expert.

> 
> Also, I'm not sure I understand the purpose of
> the Diameter shall not be extended - statement
> in 17.3. Surely we can imagine situations that
> even Diameter base protocol will be extended.
> Hopefully not soon, but we have even reserved
> mechanisms for this in the form of version numbers
> in the header etc.

The text was intended to state that if someone wants to create an extension,
the only limitation is that it must not break (or require modificaitons) to
the base protocol).

This was intended to limit the applicability of Diameter. Otherwise, it could
be used as a floor wax and desert topping :)

PatC




From owner-aaa-bof@merit.edu  Thu Apr 26 17:05:45 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21624
	for <aaa-archive@odin.ietf.org>; Thu, 26 Apr 2001 17:05:44 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 0901B5DD99; Thu, 26 Apr 2001 12:58:30 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id DF2835DDED; Thu, 26 Apr 2001 12:58:29 -0400 (EDT)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id 7A5CA5DD99
	for <aaa-wg@merit.edu>; Thu, 26 Apr 2001 12:58:28 -0400 (EDT)
Received: from engmail2.Eng.Sun.COM ([129.146.1.25])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id JAA17263;
	Thu, 26 Apr 2001 09:58:25 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail2.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id JAA28240;
	Thu, 26 Apr 2001 09:58:25 -0700 (PDT)
Received: from darius (darius [152.70.40.121])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id JAA00670;
	Thu, 26 Apr 2001 09:58:24 -0700 (PDT)
Date: Thu, 26 Apr 2001 09:58:28 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Subject: Re: [AAA-WG]: Comments on draft-ietf-aaa-diameter-02.txt
To: Fredrik Johansson <fredrik.johansson@ipunplugged.com>
Cc: AAA Listan <aaa-wg@merit.edu>
In-Reply-To: "Your message with ID" <MJEMJBGGCLLDLFFAHLJKEEPCCJAA.fredrik.johansson@ipunplugged.com>
Message-ID: <Roam.SIMC.2.0.6.988304308.18532.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> Section 2.0
> 
> "Four extensions to Diameter are defined by companion documents:
> NASREQ [7], Mobile IP [10], Strong Security [11]. "
> 
> I can only see three :-) 

:(

should Resource Management be added?

No since this is not a WG document, I don't want to list it in the base
protocol.
 
> 
> Section 2.3
> "A Diameter extension is a
>    specification that defines one or more Diameter Command-Codes, the
>    expected AVPs in an ABNF [31] grammar (see section 3.2), and MAY also
>    define new AVPs."
> 
> Does an extension really have to specify a Diameter Command-Code? So it's
> not possible to define an extension which adds new AVPs to another
> extension?

That was the agreement on the mailing list, if memory serves. You can still
write an I-D that defines ONLY AVPs, but it is NOT a protocol extension.


> 
> Section 5.0
> 
> Can't this section be incorporated in section 12 Message Routing?

Seems like this is the second time this comes up. Anyone else?

> B.T.W. why do we need both Origin-Realm and Origin-FQDN? Isn't this
> redundant information?
> Same applies to Destination-Realm and Destination-FQDN, or have I missed
> some use here?

Unless you want to write the algorithm to extract the realm from the FQDN,
then no. Further, this reduces the amount of work at each proxy that would
otherwise have to extract domains from AVPs. This is just so much more
convenient.

> 
> Section 8.0
> 
> "The stable states that a state machine may be in are Closed, I-Open
>    and R-Open; all other states are intermediate. Note that I-Open and
>    R-Open are equivalent except for whether the initiator or responder
>    transport connection is used for communication."
> 
> If the two Open states are equivalent, why are not the transitions for these
> states symetrical?

Sorry, I appear to be a little slow because I don't *quite* catch what you
mean without lots of personal interpretation. Please re-phrase.

> 
> I-Open           Send-Message     I-Snd-Non-DRI    R-Open
> should it really be R-Open or should it be I-Open

I-Open, and it has been fixed.

> 
> Section 9.0
> 
> The definition of downstream and upstream seems to be the oposite of how it
> is used in this section

This has been brought up, and will be fixed in -03.

> 
> Section 10.0
> 
> A couple of questions on the table that I know should have come a long time
> ago :-)
> 
> 1. Why should you send a MRI on a unknown AVP but a DSI on an unknown
> Command-code? 

Because the former is a protocol error, while the latter is simply that the
command is not locally supported, and the proxy can forward the request to
another peer, if possible.

> Can it not be up to the sender to decide if it can send it
> somewhere else or fix the problem in the case of an unknown AVP, i.e. you
> could send a DSI it both cases. It's not up to the receiver to decide where
> in the chain the problem occured.

But a DSI for the former would force the proxy to start stripping AVPs, which
the originator of the message MAY believe is important. 

> 
> 2. Why have MRI at all, why not always let the previous node decide if it
> can be fixed locally or if it should be forwarded another step down the
> chain?

There are some errors that proxies should not bother attempting to fix, IMHO.

> Section 12.1.1
> There can be many servers to which a message can be proxied or redirected,
> how should these be prioritised, or should you send to all of them :-)
> 
>           "3. REDIRECT - Diameter messages that fall within this
>               category MUST have the identity of the home Diameter
>               server(s) appended, and returned to the sender of the
>               message. See section 12.3 for more information."
> 
> Is it really necessary to have the identity of the home Diameter server(s)?
> Why not any next hop server?

Because a redirect implies that the message is being sent directly to the peer
that can handle the request, no?

> 
> 12.3
> 
> "Successful routing table lookups will return one or more home
>    Diameter servers that could satisfy the message. The home servers are
>    encoded in one or more Redirect-Host AVPs, and the Command-Code field
>    is set to Device-Status-Ind."
> 
> same here, why not just the next hop server instead of the home Diameter
> servers?


See above. Perhaps redirects can be used in other cases, but I would prefer to
restrict its usage to simplify the text. If you want to abuse redirect servers
in your implementation, I cannot stop you :)

> 
> Section 13.5
> Session Records -> Accounting Records ?!?

that would make sense.

> 
> Section 18
> " - The fact that the Sender's IP Address is used in the
>         construction of the Session-Id means that the introduction of
>         Network Address Translation MAY cause two hosts to represent the
>         same Session Identifier.  This area needs to be investigated
>         further to be able to support Diameter hosts on a private
>         network."
> 
> The Sender's IP Address is not used anymore, the FQDN is used instead so
> this should not be an issue.

ok. should we also just delete the open issue on time AVPs, since this problem
would exist with any protocol that uses NTP time?

PatC




From owner-aaa-bof@merit.edu  Thu Apr 26 17:09:37 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21723
	for <aaa-archive@odin.ietf.org>; Thu, 26 Apr 2001 17:09:36 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 8478A5E090; Thu, 26 Apr 2001 15:28:50 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 6E3105E08F; Thu, 26 Apr 2001 15:28:50 -0400 (EDT)
Received: from zrc2s03g.us.nortel.com (unknown [47.103.122.66])
	by segue.merit.edu (Postfix) with ESMTP id 5C7C55E08D
	for <aaa-wg@merit.edu>; Thu, 26 Apr 2001 15:28:47 -0400 (EDT)
Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id OAA26999
	for <aaa-wg@merit.edu>; Thu, 26 Apr 2001 14:29:13 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch1.nortel.com;
          Thu, 26 Apr 2001 14:28:46 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <JCX525WA>; Thu, 26 Apr 2001 14:28:31 -0500
Message-ID: <85AA7486A2C1D411BCA20000F8073E4355CA39@crchy271.us.nortel.com>
From: "Rambabu Tummala" <tummala@nortelnetworks.com>
To: "'Tony Johansson'" <tony.johansson@ericsson.com>,
        Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Cc: aaa-wg@merit.edu
Subject: RE: [AAA-WG]: Comments on draft-ietf-aaa-diameter-mobileip-02.txt
Date: Thu, 26 Apr 2001 14:28:27 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0CE87.118C2D40"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0CE87.118C2D40
Content-Type: text/plain;
	charset="iso-8859-1"

Tony and Pat,

Comments below.

Rambabu Tummala
Nortel Networks
ESN 444-8970
External (972)684-8970


-----Original Message-----
From: Tony Johansson [mailto:tony.johansson@ericsson.com]
Sent: Thursday, April 26, 2001 12:51 PM
To: Patrice Calhoun
Cc: Tummala, Rambabu [RICH1:IP35:EXCH]; aaa-wg@merit.edu
Subject: Re: [AAA-WG]: Comments on
draft-ietf-aaa-diameter-mobileip-02.txt


Hi Pat and Rambabu,

Please see comments embedded...

BR,

/Tony

Patrice Calhoun wrote:

> > > The AMA message is missing AVPs Destination-Realm AVP and
Destination-FQDN
> > > AVP.  These have to be atleast optional in the AMA message.
> > > If Destination-Realm AVP is not present in the AMA, how would the
message be
> > > routed back to the AAAF from AAAH.

> You use the Route-Record and not on the Destination-Realm AVP to route the
AMA
> back from the AAAH to the AAAF. So why should the Destination-Realm AVP be
present
> in the AMA?!
I am not sure what happens to Route-Record AVP, if the AMR travels through
multiple proxy servers.  I think having Destination-Realm AVP and
Destination-FQDN are cleanest way to do it.
>
> > > If Destination-FQDN AVP is present, the message can easily delivered
to the
> > > originating FA by AAAF.
> > > AAAH has the information from the AMR message it received.

> I agree.

>
> >
> > The same comments apply to HAA also.
>
> You are correct. Furthermore, the Destination-FQDN MUST also be optional
in
> the HAR, since the HAR may be directed at a particular Home Agent.

Good point.  I agree with you.

> I don't understand. Why do we need Destination-FQDN in the HAR message?

If the home agent is allocated in the visiting network, you are trying to
send HAR to a particular HA.


>
>
> PatC


------_=_NextPart_001_01C0CE87.118C2D40
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.59">
<TITLE>RE: [AAA-WG]: Comments on =
draft-ietf-aaa-diameter-mobileip-02.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>Tony and Pat,</FONT>
</P>

<P><FONT SIZE=3D2>Comments below.</FONT>
</P>

<P><FONT SIZE=3D2>Rambabu Tummala</FONT>
<BR><FONT SIZE=3D2>Nortel Networks</FONT>
<BR><FONT SIZE=3D2>ESN 444-8970</FONT>
<BR><FONT SIZE=3D2>External (972)684-8970</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Tony Johansson [<A =
HREF=3D"mailto:tony.johansson@ericsson.com">mailto:tony.johansson@ericss=
on.com</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, April 26, 2001 12:51 PM</FONT>
<BR><FONT SIZE=3D2>To: Patrice Calhoun</FONT>
<BR><FONT SIZE=3D2>Cc: Tummala, Rambabu [RICH1:IP35:EXCH]; =
aaa-wg@merit.edu</FONT>
<BR><FONT SIZE=3D2>Subject: Re: [AAA-WG]: Comments on</FONT>
<BR><FONT SIZE=3D2>draft-ietf-aaa-diameter-mobileip-02.txt</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>Hi Pat and Rambabu,</FONT>
</P>

<P><FONT SIZE=3D2>Please see comments embedded...</FONT>
</P>

<P><FONT SIZE=3D2>BR,</FONT>
</P>

<P><FONT SIZE=3D2>/Tony</FONT>
</P>

<P><FONT SIZE=3D2>Patrice Calhoun wrote:</FONT>
</P>

<P><FONT SIZE=3D2>&gt; &gt; &gt; The AMA message is missing AVPs =
Destination-Realm AVP and Destination-FQDN</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; AVP.&nbsp; These have to be atleast =
optional in the AMA message.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; If Destination-Realm AVP is not =
present in the AMA, how would the message be</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; routed back to the AAAF from =
AAAH.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; You use the Route-Record and not on the =
Destination-Realm AVP to route the AMA</FONT>
<BR><FONT SIZE=3D2>&gt; back from the AAAH to the AAAF. So why should =
the Destination-Realm AVP be present</FONT>
<BR><FONT SIZE=3D2>&gt; in the AMA?!</FONT>
<BR><FONT SIZE=3D2>I am not sure what happens to Route-Record AVP, if =
the AMR travels through multiple proxy servers.&nbsp; I think having =
Destination-Realm AVP and Destination-FQDN are cleanest way to do =
it.</FONT></P>

<P><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; If Destination-FQDN AVP is present, =
the message can easily delivered to the</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; originating FA by AAAF.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; AAAH has the information from the AMR =
message it received.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; I agree.</FONT>
</P>

<P><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt;</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; The same comments apply to HAA =
also.</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; You are correct. Furthermore, the =
Destination-FQDN MUST also be optional in</FONT>
<BR><FONT SIZE=3D2>&gt; the HAR, since the HAR may be directed at a =
particular Home Agent.</FONT>
</P>

<P><FONT SIZE=3D2>Good point.&nbsp; I agree with you.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; I don't understand. Why do we need =
Destination-FQDN in the HAR message?</FONT>
</P>

<P><FONT SIZE=3D2>If the home agent is allocated in the visiting =
network, you are trying to send HAR to a particular HA.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt;</FONT>
<BR><FONT SIZE=3D2>&gt; PatC</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0CE87.118C2D40--



From owner-aaa-bof@merit.edu  Thu Apr 26 17:12:22 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA21768
	for <aaa-archive@odin.ietf.org>; Thu, 26 Apr 2001 17:12:22 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 821DB5DE99; Thu, 26 Apr 2001 15:56:25 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 5C72B5DEAD; Thu, 26 Apr 2001 15:56:25 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id ADEBB5DE99
	for <aaa-wg@merit.edu>; Thu, 26 Apr 2001 15:56:20 -0400 (EDT)
Received: from engmail1.Eng.Sun.COM ([129.146.1.13])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id MAA26020;
	Thu, 26 Apr 2001 12:56:08 -0700 (PDT)
Received: from nasnfs.Eng.Sun.COM (nasnfs.Eng.Sun.COM [10.6.84.20])
	by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id MAA14469;
	Thu, 26 Apr 2001 12:56:07 -0700 (PDT)
Received: from darius (darius [152.70.40.121])
	by nasnfs.Eng.Sun.COM (8.9.3+Sun/8.9.1) with SMTP id MAA12828;
	Thu, 26 Apr 2001 12:56:06 -0700 (PDT)
Date: Thu, 26 Apr 2001 12:56:09 -0700 (PDT)
From: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Reply-To: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>
Subject: [AAA-WG]: Re: Few comments on draft-ietf-aaa-diameter-mobileip-02.txt
To: "Martin Julien (ECE)" <Martin.Julien@ece.ericsson.se>
Cc: "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>,
        "'pcalhoun@nasnfs.Eng.Sun.COM'" <pcalhoun@nasnfs.Eng.Sun.COM>
In-Reply-To: "Your message with ID" <577066326047D41180AC00508B955DDA01D7FF7C@eestqnt104.es.eu.ericsson.se>
Message-ID: <Roam.SIMC.2.0.6.988314969.32752.pcalhoun@nasnfs>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

> Hi,
> 
> Section 1.3, page 7: At the end of the first paragraph, it should be
> mentionned that the AAAF is responsible for allocating a HA.

ok.

> 
> page 8: "If a Home Agent was specified, and it belongs to a different domain
> than the Foreign Agent in the MIP-Previous-FA-FQDN AVP, the AAAH MUST verify
> whether it will permit this type of the service to the Mobile Node."
> 
> I still do not understand that.
> It is the text, which suggests that the AAAH MUST verify whether or
> not it will allow a HA to be kept in a Foreign Network different
> than the actual FA, only if the MIP-Previous-FA-FQDN AVP and 
> MIP-Home-Agent-Address AVP are in different domains. Since both
> entities will most probably be from the same domain (in the case where
> the FA and HA are in the foreign domain, which is recommended for route
> optimization), then no check should be performed, according to your text,
> right?  I guess that it is not what you really wanted to express, but rather
> when an AAAH receives a MIP-Previous-FA-FQDN AVP, the AAAH deduces that the
> MN has moved to a new domain, and then must check if a 
> MIP-Home-Agent-Address AVP was present in that same network, in which case
> it must take a decision whether or not to allow the HA to be used.

ok, the new text reads:

"... If a AAAH deduces that the Mobile Node has moved to a new domain, it must 
check whether the Mobile can still use the previously assigned Home Agent."

> 
> Page 9: "...the optional KDC session keys to the AAAF in foreign network 1."
> 
> I think that line does not fit in the text.

Right, it now reads:

"If the Mobile Node is allowed to keep the Home Agent the AAAH then sends
a HAR, which contains the Mobile IP Registration Request message data
encapsulated in the MIP-Reg-Request AVP and the MIP-Home-Agent-Address AVP
with Home Agent address, as well as any optional KDC session keys,
to the AAAF in foreign network 1."

> 
> Page 9: "If the old Foreign Network does not permit the use of its Home Agent
>    when the Mobile Node moves to a new foreign network, the Mobile Node
>    MAY allocate a new Home Agent in its current network, as described
>    above."
> 
> First, I guess it should say "...the AAAH or the AAAF MAY allocate..."
> 
> Second, what does it imply exactly? If the MN changes HA, then it means that
> it will also change Home address??? Does it make any sense to support that?

Yup, this is broken. An error must be sent back to the mobile, and it would
have to re-register, and request a new home agent.

Here is the new proposed text:

"If the old Foreign Network does not permit the use of its Home Agent
when the Mobile Node moves to a new foreign network, the AAAH or AAAF
MUST return an AMA with the Result-Code AVP set to
DIAMETER_ERROR_HA_NOT_AVAILABLE. Upon receipt of this error, the Foreign
Agent MUST issue a Mobile IP Registration Reply to the Mobile Node with
an appropriate error. The Mobile Node MAY attempt to request that a new
Home Agent and Address be allocated. When the AAAH transmits such an
error, it MUST issue a Diameter Session-Termination-Indication message
to the AAAF overseeing the Home Agent to enable it to release any resources."

> 
> Section 2.1: To the list of information extracted from the Registration
> messages, maybe we should also add the MN-HA Key Request and the MN-FA Key
> Request?

correct.

> 
> It should also be mentionned that of the Home Agent Address is 0.0.0.0 or
> 255.255.255.255, then the corresponding AVP must not be present.

done.

> 
> In the message, the Session-ID should be in < >. 
yes.

> I guess the
> Destination-FQDN should be {}. 
no, but it should be [], as it is optional.

> The Integrity-Check AVP should be removed
> from all the messages in the document.
right.

> 
> Section 2.2: "A successful AMA message MUST include the
> MIP-Home-Agent-Address AVP."
> 
> The MIP-Home-Mobile-Node-Address AVP and MIP-Reg-Reply AVP as well.

Correct.

> 
> Section 2.3: "If the Home Agent is to be assigned in a foreign network, the
> HAR is issued by AAAF."
> 
> I guess it should be "...the HAR is issued by the AAAH and forwared by the
> AAAF."

check.

Thanks for the input!

PatC




From owner-aaa-bof@merit.edu  Thu Apr 26 17:21:15 2001
Received: from segue.merit.edu (segue.merit.edu [198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA22831
	for <aaa-archive@odin.ietf.org>; Thu, 26 Apr 2001 17:21:15 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 3A30C5E00C; Thu, 26 Apr 2001 17:18:57 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 27B425E00B; Thu, 26 Apr 2001 17:18:57 -0400 (EDT)
Received: from ahab.tic.siemens.ca (ahab.tic.siemens.ca [64.26.131.130])
	by segue.merit.edu (Postfix) with ESMTP id 255415DE67
	for <aaa-wg@merit.edu>; Thu, 26 Apr 2001 17:18:55 -0400 (EDT)
Received: (from mail@localhost)
	by ahab.tic.siemens.ca (8.9.3/8.9.3) id RAA18416
	for <aaa-wg@merit.edu>; Thu, 26 Apr 2001 17:19:10 -0400 (EDT)
Received: from mailman(172.21.24.8) by ahab.tic.siemens.ca via smap (V2.1)
	id xma018414; Thu, 26 Apr 01 17:18:42 -0400
Received: (from mail@localhost)
	by mailman.innovation.siemens.ca (8.9.3/8.9.3) id RAA18670
	for <aaa-wg@merit.edu>; Thu, 26 Apr 2001 17:18:24 -0400 (EDT)
Received: from ticsmtp1.innovation.siemens.ca(172.21.24.34) by mailman.innovation.siemens.ca via smap (V2.1)
	id xma018628; Thu, 26 Apr 01 17:17:32 -0400
Received: by ticsmtp1.innovation.siemens.ca with Internet Mail Service (5.5.2650.21)
	id <2XDRFXFB>; Thu, 26 Apr 2001 17:17:23 -0400
Message-ID: <E7BB0E796757D411BC9A00105ACB123E32F6E4@ticsmtp1.innovation.siemens.ca>
From: Yiwen Jiang <Yiwen.Jiang@tic.siemens.ca>
To: "'aaa-wg@merit.edu'" <aaa-wg@merit.edu>
Subject: [AAA-WG]: questions on the Diameter base protocol
Date: Thu, 26 Apr 2001 17:17:22 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Hi Pat,

Sorry to bother you, but I was reading through the -02 I-D, and notice the
following... I don't think these are mentioned in the mails that have been
floating around, but I could be wrong..

- Section 10.0 (pg40) End-to-End Error Signaling lists five error conditions
in detail, but the first paragraph under 10.0 talks about having six
different types of error conditions. Is this a counting error, or is there
actually one more error that is not listed?
- Section 10.1.1 (pg42), MRI definition, should [Failed-AVP] have a '*' in
its front? Since in the second paragraph, it says there can be more than one
Failed-AVP AVPs.
- Section 11.2 (pg48), last paragraph says that session Id is done by the
client in most of the cases, but also said that "the Session-Id MUST be
globally unique at any given time" (3rd paragraph, same section). But there
can be more than one client requesting session connections at the same time,
right? If so, how can the clients guarantee the uniqueness of the session
id? Is there any subsequent session-id selection exchange happening once the
server discovers a duplicated session id suggested by the client?

Another stupid question I have, is regarding the peer connection
establishment: What if peer B receives a DRI message from peer A which does
not specify any extensions that are supported by peer B? (For example, say
peer A supports only NASREQ extension, and B supports only Mobile-IP
extension.) Does peer B send a MRI message back to peer A? If so, it is not
listed under section 10.1 for MRI descriptions (as far as I can see) What is
the correct behaviour for this situation, and where would I find it
described in the I-D? 

Thank you very much for your time and clarification...


Cheers,
Yiwen
---
Yiwen Jiang
Mobile IP Networking
Email: Yiwen.Jiang@tic.siemens.ca
Phone: (613)271-7710

Telecom Innovation Centre
505 March Road
Kanata, Ontario, Canada
K2K 2M5



From owner-aaa-bof@merit.edu  Fri Apr 27 05:19:00 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA19780
	for <aaa-archive@odin.ietf.org>; Fri, 27 Apr 2001 05:18:59 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 083725DDED; Fri, 27 Apr 2001 04:59:22 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id EB13E5DDC8; Fri, 27 Apr 2001 04:59:21 -0400 (EDT)
Received: from mailgw.local.ipunplugged.com (unknown [213.88.134.217])
	by segue.merit.edu (Postfix) with ESMTP id 785295DDB8
	for <aaa-wg@merit.edu>; Fri, 27 Apr 2001 04:59:19 -0400 (EDT)
Received: from fredrikj (c35.local.ipunplugged.com [192.168.4.234])
	by mailgw.local.ipunplugged.com (8.9.3/8.9.3) with SMTP id KAA21814;
	Fri, 27 Apr 2001 10:51:31 +0200
From: "Fredrik Johansson" <fredrik.johansson@ipunplugged.com>
To: "Patrice Calhoun" <pcalhoun@nasnfs.Eng.Sun.COM>,
        "Tony Johansson" <tony.johansson@ericsson.com>
Cc: "Rambabu Tummala" <tummala@nortelnetworks.com>, <aaa-wg@merit.edu>
Subject: RE: [AAA-WG]: Comments on draft-ietf-aaa-diameter-mobileip-02.txt
Date: Fri, 27 Apr 2001 10:52:18 +0200
Message-ID: <MJEMJBGGCLLDLFFAHLJKAEMDCMAA.fredrik.johansson@ipunplugged.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
In-Reply-To: <Roam.SIMC.2.0.6.988307849.29318.pcalhoun@nasnfs>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Importance: Normal
Sender: owner-aaa-bof@merit.edu
Precedence: bulk
Content-Transfer-Encoding: 7bit



>
>> > > The AMA message is missing AVPs Destination-Realm AVP and
>Destination-FQDN > > > AVP.  These have to be atleast optional in the AMA
>message. > > > If Destination-Realm AVP is not present in the AMA,
>how would
>the message be > > > routed back to the AAAF from AAAH.
>>
>> You use the Route-Record and not on the Destination-Realm AVP to
>route the
>> AMA back from the AAAH to the AAAF. So why should the
>Destination-Realm AVP
>> be present in the AMA?!
>
>oops, you are correct. The Destination-Realm is not necessary, but
>the *-FQDN
>is. Sorry I didn't really respond to that message.
>
>>
>> >
>> > > If Destination-FQDN AVP is present, the message can easily
>delivered to the
>> > > originating FA by AAAF.
>> > > AAAH has the information from the AMR message it received.
>>
>> I agree.
>>
>> >
>> > >
>> > > The same comments apply to HAA also.
>> >
>> > You are correct. Furthermore, the Destination-FQDN MUST also
>be optional in
>> > the HAR, since the HAR may be directed at a particular Home Agent.
>>
>> I don't understand. Why do we need Destination-FQDN in the HAR message?
>
>Let us assume that the first time around a Home Agent is assigned
>in a visited
>network. The next time around (i.e. re-registration), you want to make sure
>that the HAR is sent to the proper Home Agent, right? So the
>Destination-FQDN
>would provide that feature.

I Agree, the FQDN is needed to find a specific HA when one is assigned in
the
foreign network. However, I have another question.

How will the AAAH find the way to the AAAF when it sends the first HAR?
The Origin-FQDN in the AMR points to the FA, should the HAR be sent to the
first route record (which ought to be the AAAFs)? If so, I believe it needs
to be
clearified in the draft.
Or is it not necessary to send the HAR to the same AAAF that received the
AMR,
i.e. you can set the Destination-Realm to the one of the Origin-Realm in the
AMR.

/Fredrik
>
>PatC
>




From owner-aaa-bof@merit.edu  Fri Apr 27 08:49:53 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA26794
	for <aaa-archive@odin.ietf.org>; Fri, 27 Apr 2001 08:49:53 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id AC8C15DE39; Fri, 27 Apr 2001 08:45:57 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 9C6525DE2F; Fri, 27 Apr 2001 08:45:57 -0400 (EDT)
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by segue.merit.edu (Postfix) with SMTP id 180325DD8E
	for <aaa-wg@merit.edu>; Fri, 27 Apr 2001 08:45:56 -0400 (EDT)
Received: (qmail 9987 invoked by uid 500); 27 Apr 2001 12:36:04 -0000
Date: Fri, 27 Apr 2001 05:36:04 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: Fredrik Johansson <fredrik.johansson@ipunplugged.com>
Cc: Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>,
        Tony Johansson <tony.johansson@ericsson.com>,
        Rambabu Tummala <tummala@nortelnetworks.com>, aaa-wg@merit.edu
Subject: Re: [AAA-WG]: Comments on draft-ietf-aaa-diameter-mobileip-02.txt
Message-ID: <20010427053604.S2738@charizard.diameter.org>
Mail-Followup-To: Fredrik Johansson <fredrik.johansson@ipunplugged.com>,
	Patrice Calhoun <pcalhoun@nasnfs.Eng.Sun.COM>,
	Tony Johansson <tony.johansson@ericsson.com>,
	Rambabu Tummala <tummala@nortelnetworks.com>, aaa-wg@merit.edu
References: <Roam.SIMC.2.0.6.988307849.29318.pcalhoun@nasnfs> <MJEMJBGGCLLDLFFAHLJKAEMDCMAA.fredrik.johansson@ipunplugged.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <MJEMJBGGCLLDLFFAHLJKAEMDCMAA.fredrik.johansson@ipunplugged.com>; from fredrik.johansson@ipunplugged.com on Fri, Apr 27, 2001 at 10:52:18AM +0200
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

On Fri, Apr 27, 2001 at 10:52:18AM +0200, Fredrik Johansson wrote:
> 
> I Agree, the FQDN is needed to find a specific HA when one is assigned in
> the
> foreign network. However, I have another question.

ok.

> 
> How will the AAAH find the way to the AAAF when it sends the first HAR?
> The Origin-FQDN in the AMR points to the FA, should the HAR be sent to the
> first route record (which ought to be the AAAFs)? If so, I believe it needs
> to be
> clearified in the draft.
> Or is it not necessary to send the HAR to the same AAAF that received the
> AMR,
> i.e. you can set the Destination-Realm to the one of the Origin-Realm in the
> AMR.

The message needs to be forwarded to an AAAF in the foreign domain. It could
be the same AAAF that forwarded the AMR, or it could be another one. It
really doesn't matter.

I will look in the draft to see if any possible clarifications can be made.

PatC



From owner-aaa-bof@merit.edu  Fri Apr 27 10:25:38 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01196
	for <aaa-archive@odin.ietf.org>; Fri, 27 Apr 2001 10:25:37 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id A74E15DD8E; Fri, 27 Apr 2001 10:25:17 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 92D685DDD3; Fri, 27 Apr 2001 10:25:17 -0400 (EDT)
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by segue.merit.edu (Postfix) with SMTP id C348F5DD8E
	for <aaa-wg@merit.edu>; Fri, 27 Apr 2001 10:25:15 -0400 (EDT)
Received: (qmail 10397 invoked by uid 500); 27 Apr 2001 14:15:24 -0000
Date: Fri, 27 Apr 2001 07:15:24 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: Yiwen Jiang <Yiwen.Jiang@tic.siemens.ca>, aaa-wg@merit.edu
Cc: "'pcalhoun@diameter.org'" <pcalhoun@diameter.org>
Subject: Re: FW: [AAA-WG]: questions on the Diameter base protocol
Message-ID: <20010427071523.U2738@charizard.diameter.org>
Mail-Followup-To: Yiwen Jiang <Yiwen.Jiang@tic.siemens.ca>,
	aaa-wg@merit.edu, "'pcalhoun@diameter.org'" <pcalhoun@diameter.org>
References: <E7BB0E796757D411BC9A00105ACB123E32F6E7@ticsmtp1.innovation.siemens.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <E7BB0E796757D411BC9A00105ACB123E32F6E7@ticsmtp1.innovation.siemens.ca>; from Yiwen.Jiang@tic.siemens.ca on Fri, Apr 27, 2001 at 09:13:20AM -0400
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

On Fri, Apr 27, 2001 at 09:13:20AM -0400, Yiwen Jiang wrote:
> Sorry to bother you, but I was reading through the -02 I-D, and notice the
> following... I don't think these are mentioned in the mails that have been
> floating around, but I could be wrong..

No bother at all. This is what I am here for (oh, and do some occasional work
for Sun :)

> - Section 10.0 (pg40) End-to-End Error Signaling lists five error conditions
> in detail, but the first paragraph under 10.0 talks about having six
> different types of error conditions. Is this a counting error, or is there
> actually one more error that is not listed?

I really need to go through the I-D, and get rid of all counters. This has 
bit me in the backside a few times. I will have this fixed up in -03.

> - Section 10.1.1 (pg42), MRI definition, should [Failed-AVP] have a '*' in
> its front? Since in the second paragraph, it says there can be more than one
> Failed-AVP AVPs.

Yes.

> - Section 11.2 (pg48), last paragraph says that session Id is done by the
> client in most of the cases, but also said that "the Session-Id MUST be
> globally unique at any given time" (3rd paragraph, same section). But there
> can be more than one client requesting session connections at the same time,
> right? If so, how can the clients guarantee the uniqueness of the session
> id? Is there any subsequent session-id selection exchange happening once the
> server discovers a duplicated session id suggested by the client?

If a session-id is constructed the way that the base protocol suggests, then
duplicate session identifiers would not occur. Perhaps I am mis-interpreting
your question, so if I haven't answered it, please try again.

> 
> Another stupid question I have, is regarding the peer connection
> establishment: What if peer B receives a DRI message from peer A which does
> not specify any extensions that are supported by peer B? (For example, say
> peer A supports only NASREQ extension, and B supports only Mobile-IP
> extension.) Does peer B send a MRI message back to peer A? If so, it is not
> listed under section 10.1 for MRI descriptions (as far as I can see) What is
> the correct behaviour for this situation, and where would I find it
> described in the I-D? 

As -02 stands, it *could* be because Peer A is simply asking for accounting
messages, which do not have an extension. However, if the proposal that I
sent out yesterday goes through, which introduced a new AVP in the
capabilities exchange, specifically for accounting, then this error could
occur. Perhaps then some text would be required in the base spec that
states that the expected behavior should be.

> 
> Thank you very much for your time and clarification...

Not a problem. Thanks for the comments.

PatC



From owner-aaa-bof@merit.edu  Fri Apr 27 10:53:16 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA03065
	for <aaa-archive@odin.ietf.org>; Fri, 27 Apr 2001 10:53:15 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 8E95B5DF2B; Fri, 27 Apr 2001 10:49:55 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 7BA885DF1B; Fri, 27 Apr 2001 10:49:55 -0400 (EDT)
Received: from ahab.tic.siemens.ca (ahab.tic.siemens.ca [64.26.131.130])
	by segue.merit.edu (Postfix) with ESMTP id 943635DF23
	for <aaa-wg@merit.edu>; Fri, 27 Apr 2001 10:49:53 -0400 (EDT)
Received: (from mail@localhost)
	by ahab.tic.siemens.ca (8.9.3/8.9.3) id KAA01632;
	Fri, 27 Apr 2001 10:50:09 -0400 (EDT)
Received: from mailman(172.21.24.8) by ahab.tic.siemens.ca via smap (V2.1)
	id xma001622; Fri, 27 Apr 01 10:49:43 -0400
Received: (from mail@localhost)
	by mailman.innovation.siemens.ca (8.9.3/8.9.3) id KAA16185;
	Fri, 27 Apr 2001 10:49:22 -0400 (EDT)
Received: from ticsmtp1.innovation.siemens.ca(172.21.24.34) by mailman.innovation.siemens.ca via smap (V2.1)
	id xma016107; Fri, 27 Apr 01 10:48:59 -0400
Received: by ticsmtp1.innovation.siemens.ca with Internet Mail Service (5.5.2650.21)
	id <2XDRFXRZ>; Fri, 27 Apr 2001 10:48:49 -0400
Message-ID: <E7BB0E796757D411BC9A00105ACB123E32F6EA@ticsmtp1.innovation.siemens.ca>
From: Yiwen Jiang <Yiwen.Jiang@tic.siemens.ca>
To: "'Pat Calhoun'" <pcalhoun@diameter.org>, aaa-wg@merit.edu
Subject: RE: FW: [AAA-WG]: questions on the Diameter base protocol
Date: Fri, 27 Apr 2001 10:48:48 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Hi Pat,

> If a session-id is constructed the way that the base protocol 
> suggests, then
> duplicate session identifiers would not occur. Perhaps I am 
> mis-interpreting
> your question, so if I haven't answered it, please try again.
I re-read the section, and understand now. Thanks.

> > Another stupid question I have, is regarding the peer connection
> > establishment: What if peer B receives a DRI message from 
> peer A which does
> > not specify any extensions that are supported by peer B? 
> (For example, say
> > peer A supports only NASREQ extension, and B supports only Mobile-IP
> > extension.) Does peer B send a MRI message back to peer A? 
> If so, it is not
> > listed under section 10.1 for MRI descriptions (as far as I 
> can see) What is
> > the correct behaviour for this situation, and where would I find it
> > described in the I-D? 
> 
> As -02 stands, it *could* be because Peer A is simply asking 
> for accounting
> messages, which do not have an extension. However, if the 
> proposal that I
> sent out yesterday goes through, which introduced a new AVP in the
> capabilities exchange, specifically for accounting, then this 
> error could
> occur. Perhaps then some text would be required in the base spec that
> states that the expected behavior should be.
Hmm.. I'm not sure if it is only the case with accounting extension...

Say I have a peer A that supports only the NASREQ extension, and peer B
supports only the mobile-ip extension (Not accounting related at all). If
for some reason, peer A wishes to establish a peer connection with B. And
during the capability exchange using DRI message, they both find out that
there is no common extension supported by both peer. What do A and B do? Do
they send MRI message to each other about this? If so, there is no
mentioning of such message/AVP in the description of the MRI section 10.1.
If not, what do they do?

Thanks!



From owner-aaa-bof@merit.edu  Fri Apr 27 12:31:36 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07835
	for <aaa-archive@odin.ietf.org>; Fri, 27 Apr 2001 12:31:36 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 927255DEAD; Fri, 27 Apr 2001 12:23:04 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 216225DED2; Fri, 27 Apr 2001 12:21:30 -0400 (EDT)
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by segue.merit.edu (Postfix) with SMTP id E1FAB5DED4
	for <aaa-wg@merit.edu>; Fri, 27 Apr 2001 12:16:11 -0400 (EDT)
Received: (qmail 10790 invoked by uid 500); 27 Apr 2001 16:06:20 -0000
Date: Fri, 27 Apr 2001 09:06:20 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: Yiwen Jiang <Yiwen.Jiang@tic.siemens.ca>
Cc: "'Pat Calhoun'" <pcalhoun@diameter.org>, aaa-wg@merit.edu
Subject: Re: FW: [AAA-WG]: questions on the Diameter base protocol
Message-ID: <20010427090620.X2738@charizard.diameter.org>
Mail-Followup-To: Yiwen Jiang <Yiwen.Jiang@tic.siemens.ca>,
	'Pat Calhoun' <pcalhoun@diameter.org>, aaa-wg@merit.edu
References: <E7BB0E796757D411BC9A00105ACB123E32F6EA@ticsmtp1.innovation.siemens.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <E7BB0E796757D411BC9A00105ACB123E32F6EA@ticsmtp1.innovation.siemens.ca>; from Yiwen.Jiang@tic.siemens.ca on Fri, Apr 27, 2001 at 10:48:48AM -0400
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

On Fri, Apr 27, 2001 at 10:48:48AM -0400, Yiwen Jiang wrote:
> Say I have a peer A that supports only the NASREQ extension, and peer B
> supports only the mobile-ip extension (Not accounting related at all). If
> for some reason, peer A wishes to establish a peer connection with B. And
> during the capability exchange using DRI message, they both find out that
> there is no common extension supported by both peer. What do A and B do? Do
> they send MRI message to each other about this? If so, there is no
> mentioning of such message/AVP in the description of the MRI section 10.1.
> If not, what do they do?

I agree that such text must be added to the draft to ensure that consistent
behavior will occur.

PatC



From owner-aaa-bof@merit.edu  Fri Apr 27 14:01:38 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09918
	for <aaa-archive@odin.ietf.org>; Fri, 27 Apr 2001 14:01:38 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id C04DF5DEBC; Fri, 27 Apr 2001 12:21:16 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id BAD5A5DE98; Fri, 27 Apr 2001 12:15:55 -0400 (EDT)
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by segue.merit.edu (Postfix) with SMTP id 970E95E2FF
	for <aaa-wg@merit.edu>; Fri, 27 Apr 2001 12:13:28 -0400 (EDT)
Received: (qmail 10768 invoked by uid 500); 27 Apr 2001 16:03:37 -0000
Date: Fri, 27 Apr 2001 09:03:36 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: Rambabu Tummala <tummala@nortelnetworks.com>
Cc: "'Patrice Calhoun'" <pcalhoun@nasnfs.Eng.Sun.COM>,
        "'Tony Johansson'" <tony.johansson@ericsson.com>, aaa-wg@merit.edu
Subject: Re: [AAA-WG]: Comments on draft-ietf-aaa-diameter-mobileip-02.txt
Message-ID: <20010427090336.W2738@charizard.diameter.org>
Mail-Followup-To: Rambabu Tummala <tummala@nortelnetworks.com>,
	'Patrice Calhoun' <pcalhoun@nasnfs.Eng.Sun.COM>,
	'Tony Johansson' <tony.johansson@ericsson.com>, aaa-wg@merit.edu
References: <85AA7486A2C1D411BCA20000F8073E4355CA3A@crchy271.us.nortel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <85AA7486A2C1D411BCA20000F8073E4355CA3A@crchy271.us.nortel.com>; from tummala@nortelnetworks.com on Fri, Apr 27, 2001 at 10:26:11AM -0500
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

On Fri, Apr 27, 2001 at 10:26:11AM -0500, Rambabu Tummala wrote:
> > The base protocol is pretty clear in that responses and answers are
> proxied
> > using the Route-Record AVP, not the Destination-Realm AVP.
> 
> I agree it is compliant with base protocol specification.  I guess my
> question then would be how does the response reach the originator of the
> requestor if one of the proxies fail before the response goes through.  
> 
> I guess, I would like to see the text in section 12.4.2 of
> draft-ietf-aaa-diameter-02.txt change from "MUST" to "Should".
> 
> If we remove this restriction it gives flexibility to the protocol.

I agree, and a previous version of the base protocol did in fact allow
for the reverse path to be different from the forwarding path. However,
concensus on the mailing list was that this was not really a feature that
was required, since it introduced too much complexity. 

So the way it currently works is that if a response isn't received because
of a network or host failure, the original request will be resent either
by the NAS, or by a proxy, as specified in the failover text in the base
draft.

> 
> May be there are reasons behind specifying this way. Please enlighten me.

As I mentioned above, the WG believed that the complexity introduced by
supporting such a feature didn't warrant supporting this feature. Furthermore,
there are proxies that maintain state, and not knowing whether a response
will traverse a particular proxy makes this very difficult.

Hope this helps,

PatC



From owner-aaa-bof@merit.edu  Fri Apr 27 16:32:19 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15208
	for <aaa-archive@odin.ietf.org>; Fri, 27 Apr 2001 16:32:19 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id E06925E062; Fri, 27 Apr 2001 12:44:30 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 1461A5E154; Fri, 27 Apr 2001 12:38:00 -0400 (EDT)
Received: from zrc2s03g.us.nortel.com (unknown [47.103.122.66])
	by segue.merit.edu (Postfix) with ESMTP id A68135E0FE
	for <aaa-wg@merit.edu>; Fri, 27 Apr 2001 12:37:07 -0400 (EDT)
Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id LAA18551
	for <aaa-wg@merit.edu>; Fri, 27 Apr 2001 11:37:35 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch1.nortel.com;
          Fri, 27 Apr 2001 11:37:05 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <JCX5JNZ2>; Fri, 27 Apr 2001 11:36:50 -0500
Message-ID: <85AA7486A2C1D411BCA20000F8073E4355CA3B@crchy271.us.nortel.com>
From: "Rambabu Tummala" <tummala@nortelnetworks.com>
To: "'Pat Calhoun'" <pcalhoun@diameter.org>
Cc: "'Patrice Calhoun'" <pcalhoun@nasnfs.Eng.Sun.COM>, aaa-wg@merit.edu
Subject: RE: [AAA-WG]: Comments on draft-ietf-aaa-diameter-mobileip-02.txt
Date: Fri, 27 Apr 2001 11:36:49 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0CF38.41DB1950"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0CF38.41DB1950
Content-Type: text/plain;
	charset="iso-8859-1"

Pat,
Thanks for the explanation.

Rambabu Tummala
Nortel Networks
ESN 444-8970
External (972)684-8970


-----Original Message-----
From: Pat Calhoun [mailto:pcalhoun@diameter.org]
Sent: Friday, April 27, 2001 11:04 AM
To: Tummala, Rambabu [RICH1:IP35:EXCH]
Cc: 'Patrice Calhoun'; 'Tony Johansson'; aaa-wg@merit.edu
Subject: Re: [AAA-WG]: Comments on
draft-ietf-aaa-diameter-mobileip-02.txt


On Fri, Apr 27, 2001 at 10:26:11AM -0500, Rambabu Tummala wrote:
> > The base protocol is pretty clear in that responses and answers are
> proxied
> > using the Route-Record AVP, not the Destination-Realm AVP.
> 
> I agree it is compliant with base protocol specification.  I guess my
> question then would be how does the response reach the originator of the
> requestor if one of the proxies fail before the response goes through.  
> 
> I guess, I would like to see the text in section 12.4.2 of
> draft-ietf-aaa-diameter-02.txt change from "MUST" to "Should".
> 
> If we remove this restriction it gives flexibility to the protocol.

I agree, and a previous version of the base protocol did in fact allow
for the reverse path to be different from the forwarding path. However,
concensus on the mailing list was that this was not really a feature that
was required, since it introduced too much complexity. 

So the way it currently works is that if a response isn't received because
of a network or host failure, the original request will be resent either
by the NAS, or by a proxy, as specified in the failover text in the base
draft.

> 
> May be there are reasons behind specifying this way. Please enlighten me.

As I mentioned above, the WG believed that the complexity introduced by
supporting such a feature didn't warrant supporting this feature.
Furthermore,
there are proxies that maintain state, and not knowing whether a response
will traverse a particular proxy makes this very difficult.

Hope this helps,

PatC


------_=_NextPart_001_01C0CF38.41DB1950
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.59">
<TITLE>RE: [AAA-WG]: Comments on draft-ietf-aaa-diameter-mobileip-02.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Pat,</FONT>
<BR><FONT SIZE=2>Thanks for the explanation.</FONT>
</P>

<P><FONT SIZE=2>Rambabu Tummala</FONT>
<BR><FONT SIZE=2>Nortel Networks</FONT>
<BR><FONT SIZE=2>ESN 444-8970</FONT>
<BR><FONT SIZE=2>External (972)684-8970</FONT>
</P>
<BR>

<P><FONT SIZE=2>-----Original Message-----</FONT>
<BR><FONT SIZE=2>From: Pat Calhoun [<A HREF="mailto:pcalhoun@diameter.org">mailto:pcalhoun@diameter.org</A>]</FONT>
<BR><FONT SIZE=2>Sent: Friday, April 27, 2001 11:04 AM</FONT>
<BR><FONT SIZE=2>To: Tummala, Rambabu [RICH1:IP35:EXCH]</FONT>
<BR><FONT SIZE=2>Cc: 'Patrice Calhoun'; 'Tony Johansson'; aaa-wg@merit.edu</FONT>
<BR><FONT SIZE=2>Subject: Re: [AAA-WG]: Comments on</FONT>
<BR><FONT SIZE=2>draft-ietf-aaa-diameter-mobileip-02.txt</FONT>
</P>
<BR>

<P><FONT SIZE=2>On Fri, Apr 27, 2001 at 10:26:11AM -0500, Rambabu Tummala wrote:</FONT>
<BR><FONT SIZE=2>&gt; &gt; The base protocol is pretty clear in that responses and answers are</FONT>
<BR><FONT SIZE=2>&gt; proxied</FONT>
<BR><FONT SIZE=2>&gt; &gt; using the Route-Record AVP, not the Destination-Realm AVP.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I agree it is compliant with base protocol specification.&nbsp; I guess my</FONT>
<BR><FONT SIZE=2>&gt; question then would be how does the response reach the originator of the</FONT>
<BR><FONT SIZE=2>&gt; requestor if one of the proxies fail before the response goes through.&nbsp; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; I guess, I would like to see the text in section 12.4.2 of</FONT>
<BR><FONT SIZE=2>&gt; draft-ietf-aaa-diameter-02.txt change from &quot;MUST&quot; to &quot;Should&quot;.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; If we remove this restriction it gives flexibility to the protocol.</FONT>
</P>

<P><FONT SIZE=2>I agree, and a previous version of the base protocol did in fact allow</FONT>
<BR><FONT SIZE=2>for the reverse path to be different from the forwarding path. However,</FONT>
<BR><FONT SIZE=2>concensus on the mailing list was that this was not really a feature that</FONT>
<BR><FONT SIZE=2>was required, since it introduced too much complexity. </FONT>
</P>

<P><FONT SIZE=2>So the way it currently works is that if a response isn't received because</FONT>
<BR><FONT SIZE=2>of a network or host failure, the original request will be resent either</FONT>
<BR><FONT SIZE=2>by the NAS, or by a proxy, as specified in the failover text in the base</FONT>
<BR><FONT SIZE=2>draft.</FONT>
</P>

<P><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; May be there are reasons behind specifying this way. Please enlighten me.</FONT>
</P>

<P><FONT SIZE=2>As I mentioned above, the WG believed that the complexity introduced by</FONT>
<BR><FONT SIZE=2>supporting such a feature didn't warrant supporting this feature. Furthermore,</FONT>
<BR><FONT SIZE=2>there are proxies that maintain state, and not knowing whether a response</FONT>
<BR><FONT SIZE=2>will traverse a particular proxy makes this very difficult.</FONT>
</P>

<P><FONT SIZE=2>Hope this helps,</FONT>
</P>

<P><FONT SIZE=2>PatC</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0CF38.41DB1950--



From owner-aaa-bof@merit.edu  Fri Apr 27 16:45:07 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15418
	for <aaa-archive@odin.ietf.org>; Fri, 27 Apr 2001 16:45:07 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 935FC5DDD3; Fri, 27 Apr 2001 11:27:50 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 34A7A5DFC5; Fri, 27 Apr 2001 11:27:50 -0400 (EDT)
Received: from zrc2s03g.us.nortel.com (unknown [47.103.122.66])
	by segue.merit.edu (Postfix) with ESMTP id 5698E5DDD3
	for <aaa-wg@merit.edu>; Fri, 27 Apr 2001 11:26:39 -0400 (EDT)
Received: from smtprch2.nortel.com (erchg0k.us.nortel.com [47.113.64.104])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id KAA26947
	for <aaa-wg@merit.edu>; Fri, 27 Apr 2001 10:27:06 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch2.nortel.com;
          Fri, 27 Apr 2001 10:20:48 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <JCX5JLL3>; Fri, 27 Apr 2001 10:26:11 -0500
Message-ID: <85AA7486A2C1D411BCA20000F8073E4355CA3A@crchy271.us.nortel.com>
From: "Rambabu Tummala" <tummala@nortelnetworks.com>
To: "'Patrice Calhoun'" <pcalhoun@nasnfs.Eng.Sun.COM>
Cc: "'Tony Johansson'" <tony.johansson@ericsson.com>, aaa-wg@merit.edu
Subject: RE: [AAA-WG]: Comments on draft-ietf-aaa-diameter-mobileip-02.txt
Date: Fri, 27 Apr 2001 10:26:11 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0CF2E.63776C30"
X-Orig: <tummala@americasm01.nt.com>
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0CF2E.63776C30
Content-Type: text/plain;
	charset="iso-8859-1"

some questions below.

Rambabu Tummala
Nortel Networks
ESN 444-8970
External (972)684-8970


-----Original Message-----
From: Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM]
Sent: Thursday, April 26, 2001 3:31 PM
To: Tummala, Rambabu [RICH1:IP35:EXCH]
Cc: 'Tony Johansson'; Patrice Calhoun; aaa-wg@merit.edu
Subject: RE: [AAA-WG]: Comments on
draft-ietf-aaa-diameter-mobileip-02.txt


> Patrice Calhoun wrote:
> 
> > > > The AMA message is missing AVPs Destination-Realm AVP and
> Destination-FQDN
> > > > AVP.  These have to be atleast optional in the AMA message.
> > > > If Destination-Realm AVP is not present in the AMA, how would the
> message be
> > > > routed back to the AAAF from AAAH.
> 
> > You use the Route-Record and not on the Destination-Realm AVP to route
the
> AMA
> > back from the AAAH to the AAAF. So why should the Destination-Realm AVP
be
> present
> > in the AMA?!
> I am not sure what happens to Route-Record AVP, if the AMR travels through
> multiple proxy servers.  I think having Destination-Realm AVP and
> Destination-FQDN are cleanest way to do it.

> The base protocol is pretty clear in that responses and answers are
proxied
> using the Route-Record AVP, not the Destination-Realm AVP.

I agree it is compliant with base protocol specification.  I guess my
question then would be how does the response reach the originator of the
requestor if one of the proxies fail before the response goes through.  

I guess, I would like to see the text in section 12.4.2 of
draft-ietf-aaa-diameter-02.txt change from "MUST" to "Should".

If we remove this restriction it gives flexibility to the protocol.

May be there are reasons behind specifying this way. Please enlighten me.


>PatC


------_=_NextPart_001_01C0CF2E.63776C30
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Diso-8859-1">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2654.59">
<TITLE>RE: [AAA-WG]: Comments on =
draft-ietf-aaa-diameter-mobileip-02.txt</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>some questions below.</FONT>
</P>

<P><FONT SIZE=3D2>Rambabu Tummala</FONT>
<BR><FONT SIZE=3D2>Nortel Networks</FONT>
<BR><FONT SIZE=3D2>ESN 444-8970</FONT>
<BR><FONT SIZE=3D2>External (972)684-8970</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>-----Original Message-----</FONT>
<BR><FONT SIZE=3D2>From: Patrice Calhoun [<A =
HREF=3D"mailto:pcalhoun@nasnfs.Eng.Sun.COM">mailto:pcalhoun@nasnfs.Eng.S=
un.COM</A>]</FONT>
<BR><FONT SIZE=3D2>Sent: Thursday, April 26, 2001 3:31 PM</FONT>
<BR><FONT SIZE=3D2>To: Tummala, Rambabu [RICH1:IP35:EXCH]</FONT>
<BR><FONT SIZE=3D2>Cc: 'Tony Johansson'; Patrice Calhoun; =
aaa-wg@merit.edu</FONT>
<BR><FONT SIZE=3D2>Subject: RE: [AAA-WG]: Comments on</FONT>
<BR><FONT SIZE=3D2>draft-ietf-aaa-diameter-mobileip-02.txt</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt; Patrice Calhoun wrote:</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; The AMA message is missing AVPs =
Destination-Realm AVP and</FONT>
<BR><FONT SIZE=3D2>&gt; Destination-FQDN</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; AVP.&nbsp; These have to be =
atleast optional in the AMA message.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; If Destination-Realm AVP is not =
present in the AMA, how would the</FONT>
<BR><FONT SIZE=3D2>&gt; message be</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt; &gt; routed back to the AAAF from =
AAAH.</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; You use the Route-Record and not on the =
Destination-Realm AVP to route the</FONT>
<BR><FONT SIZE=3D2>&gt; AMA</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; back from the AAAH to the AAAF. So why =
should the Destination-Realm AVP be</FONT>
<BR><FONT SIZE=3D2>&gt; present</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; in the AMA?!</FONT>
<BR><FONT SIZE=3D2>&gt; I am not sure what happens to Route-Record AVP, =
if the AMR travels through</FONT>
<BR><FONT SIZE=3D2>&gt; multiple proxy servers.&nbsp; I think having =
Destination-Realm AVP and</FONT>
<BR><FONT SIZE=3D2>&gt; Destination-FQDN are cleanest way to do =
it.</FONT>
</P>

<P><FONT SIZE=3D2>&gt; The base protocol is pretty clear in that =
responses and answers are proxied</FONT>
<BR><FONT SIZE=3D2>&gt; using the Route-Record AVP, not the =
Destination-Realm AVP.</FONT>
</P>

<P><FONT SIZE=3D2>I agree it is compliant with base protocol =
specification.&nbsp; I guess my question then would be how does the =
response reach the originator of the requestor if one of the proxies =
fail before the response goes through.&nbsp; </FONT></P>

<P><FONT SIZE=3D2>I guess, I would like to see the text in section =
12.4.2 of draft-ietf-aaa-diameter-02.txt change from &quot;MUST&quot; =
to &quot;Should&quot;.</FONT></P>

<P><FONT SIZE=3D2>If we remove this restriction it gives flexibility to =
the protocol.</FONT>
</P>

<P><FONT SIZE=3D2>May be there are reasons behind specifying this way. =
Please enlighten me.</FONT>
</P>
<BR>

<P><FONT SIZE=3D2>&gt;PatC</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0CF2E.63776C30--



From owner-aaa-bof@merit.edu  Sat Apr 28 04:00:20 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA11596
	for <aaa-archive@odin.ietf.org>; Sat, 28 Apr 2001 04:00:20 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 6EE1D5DF1D; Thu, 26 Apr 2001 17:56:25 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 8AB005DF1A; Thu, 26 Apr 2001 17:56:23 -0400 (EDT)
Received: from zrc2s03g.us.nortel.com (unknown [47.103.122.66])
	by segue.merit.edu (Postfix) with ESMTP id 9A8275DFE9
	for <aaa-wg@merit.edu>; Thu, 26 Apr 2001 17:51:50 -0400 (EDT)
Received: from smtprch1.nortel.com (erchg0j.us.nortel.com [47.113.64.103])
	by zrc2s03g.us.nortel.com (8.9.3+Sun/8.9.1) with ESMTP id QAA06944
	for <aaa-wg@merit.edu>; Thu, 26 Apr 2001 16:52:16 -0500 (CDT)
Received: from zrchb200.us.nortel.com by smtprch1.nortel.com;
          Thu, 26 Apr 2001 16:51:50 -0500
Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2653.19) 
          id <JCX5204R>; Thu, 26 Apr 2001 16:51:35 -0500
Message-ID: <FB4781AB3309D5118DCD00508BF93CA22D8D3E@zrc2c001.us.nortel.com>
From: "Haseeb Akhtar" <haseeb@nortelnetworks.com>
To: "'Patrice Calhoun'" <pcalhoun@nasnfs.Eng.Sun.COM>, aaa-wg@merit.edu
Subject: RE: [AAA-WG]: A resolution to the Accounting problem
Date: Thu, 26 Apr 2001 16:51:35 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative;
              boundary="----_=_NextPart_001_01C0CE9B.105B1030"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C0CE9B.105B1030
Content-Type: text/plain;
	charset="iso-8859-1"

Ditto here.

Haseeb

> -----Original Message-----
> From: Patrice Calhoun [mailto:pcalhoun@nasnfs.Eng.Sun.COM]
> Sent: Thursday, April 26, 2001 3:29 PM
> To: aaa-wg@merit.edu
> Subject: [AAA-WG]: A resolution to the Accounting problem
> 
> 
> Problem:
> 
> People have been asking recently how does a server specify 
> that it wishes to
> receive accounting messages? This used to be possible when 
> the Accounting
> stuff was in a separate extension, but it no longer is 
> possible in -02 because
> accounting is part of the base.
> 
> Solution:
> 
> The authentication and authorization part of the protocol 
> advertises its
> supported extensions via the Extension-Id AVP in the DRI 
> message. However,
> each extension has AVPs that it specifies needs to be present 
> in accounting
> messages. So in any case, you have different accounting 
> messages (well, the
> AVPs are different) based on the application.
> 
> So, could we not simply create a new AVP that is exchanged in 
> the DRI, called
> the Accounting-Extension-Id? It would use the same address 
> space as the
> existing Extension-Id AVP, but this would be ONLY for 
> accounting purposes.
> This way a server could advertise that it wishes to receive 
> both auth and acct
> messages for MIP ONLY, or perhaps only NASREQ and MIP acct 
> messages, etc.
> 
> This seems very flexible, and an even better solution to the 
> old approach
> (read split acct from base) that would not allow a peer to 
> advertise that it
> only wanted accounting messages for a particular application.
> 
> Thoughts?
> 
> PatC
> 
> 
> 

------_=_NextPart_001_01C0CE9B.105B1030
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2654.59">
<TITLE>RE: [AAA-WG]: A resolution to the Accounting problem</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Ditto here.</FONT>
</P>

<P><FONT SIZE=2>Haseeb</FONT>
</P>

<P><FONT SIZE=2>&gt; -----Original Message-----</FONT>
<BR><FONT SIZE=2>&gt; From: Patrice Calhoun [<A HREF="mailto:pcalhoun@nasnfs.Eng.Sun.COM">mailto:pcalhoun@nasnfs.Eng.Sun.COM</A>]</FONT>
<BR><FONT SIZE=2>&gt; Sent: Thursday, April 26, 2001 3:29 PM</FONT>
<BR><FONT SIZE=2>&gt; To: aaa-wg@merit.edu</FONT>
<BR><FONT SIZE=2>&gt; Subject: [AAA-WG]: A resolution to the Accounting problem</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Problem:</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; People have been asking recently how does a server specify </FONT>
<BR><FONT SIZE=2>&gt; that it wishes to</FONT>
<BR><FONT SIZE=2>&gt; receive accounting messages? This used to be possible when </FONT>
<BR><FONT SIZE=2>&gt; the Accounting</FONT>
<BR><FONT SIZE=2>&gt; stuff was in a separate extension, but it no longer is </FONT>
<BR><FONT SIZE=2>&gt; possible in -02 because</FONT>
<BR><FONT SIZE=2>&gt; accounting is part of the base.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Solution:</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; The authentication and authorization part of the protocol </FONT>
<BR><FONT SIZE=2>&gt; advertises its</FONT>
<BR><FONT SIZE=2>&gt; supported extensions via the Extension-Id AVP in the DRI </FONT>
<BR><FONT SIZE=2>&gt; message. However,</FONT>
<BR><FONT SIZE=2>&gt; each extension has AVPs that it specifies needs to be present </FONT>
<BR><FONT SIZE=2>&gt; in accounting</FONT>
<BR><FONT SIZE=2>&gt; messages. So in any case, you have different accounting </FONT>
<BR><FONT SIZE=2>&gt; messages (well, the</FONT>
<BR><FONT SIZE=2>&gt; AVPs are different) based on the application.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; So, could we not simply create a new AVP that is exchanged in </FONT>
<BR><FONT SIZE=2>&gt; the DRI, called</FONT>
<BR><FONT SIZE=2>&gt; the Accounting-Extension-Id? It would use the same address </FONT>
<BR><FONT SIZE=2>&gt; space as the</FONT>
<BR><FONT SIZE=2>&gt; existing Extension-Id AVP, but this would be ONLY for </FONT>
<BR><FONT SIZE=2>&gt; accounting purposes.</FONT>
<BR><FONT SIZE=2>&gt; This way a server could advertise that it wishes to receive </FONT>
<BR><FONT SIZE=2>&gt; both auth and acct</FONT>
<BR><FONT SIZE=2>&gt; messages for MIP ONLY, or perhaps only NASREQ and MIP acct </FONT>
<BR><FONT SIZE=2>&gt; messages, etc.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; This seems very flexible, and an even better solution to the </FONT>
<BR><FONT SIZE=2>&gt; old approach</FONT>
<BR><FONT SIZE=2>&gt; (read split acct from base) that would not allow a peer to </FONT>
<BR><FONT SIZE=2>&gt; advertise that it</FONT>
<BR><FONT SIZE=2>&gt; only wanted accounting messages for a particular application.</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; Thoughts?</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; PatC</FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
<BR><FONT SIZE=2>&gt; </FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C0CE9B.105B1030--



From owner-aaa-bof@merit.edu  Mon Apr 30 13:05:27 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19097
	for <aaa-archive@odin.ietf.org>; Mon, 30 Apr 2001 13:05:27 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 7755C5DED2; Mon, 30 Apr 2001 13:03:46 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 634EB5DED4; Mon, 30 Apr 2001 13:03:46 -0400 (EDT)
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by segue.merit.edu (Postfix) with SMTP id 918AE5DED2
	for <aaa-wg@merit.edu>; Mon, 30 Apr 2001 13:03:44 -0400 (EDT)
Received: (qmail 4736 invoked by uid 500); 30 Apr 2001 16:53:43 -0000
Date: Mon, 30 Apr 2001 09:53:43 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: aaa-wg@merit.edu
Subject: [AAA-WG]: Session Movement
Message-ID: <20010430095343.D3397@charizard.diameter.org>
Mail-Followup-To: aaa-wg@merit.edu
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-md5;
	protocol="application/pgp-signature"; boundary="tqI+Z3u+9OQ7kwn0"
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Sender: owner-aaa-bof@merit.edu
Precedence: bulk


--tqI+Z3u+9OQ7kwn0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

All,

A week or so ago, the following text was proposed, and I am now just getting
around to making spec changes, and some questions arose:

> 11.7  Session Movement
>
>  When a user moves between different access devices it may be desirable
>  to keep the Session Id unchanged. It is therefore possible for a
>  server to send the original Session Id back to the requester in the
>  Original-Session-Id AVP. If the AAA server already has a
>  sessionidentifier

how about the following???

"11.7  Session Movement

There are applications that over the course of a session a user MAY
receive service from different access servers. While the service is
relocated, it MAY be desirable for the AAA infrastructure to view this
as a persistent session, as opposed to a new session each time a user is
relocated. In order to support these applications, when an AAA server
identifies that a request is the continuation of an existing session,
it MUST include the original session identifier in the Original-Session-Id
AVP in the corresponding response message to the access device."

WARNING!!!!!!

This is really unchartered territory, and we really need to think this one
through. Let's assume, for the moment, that a user's device crashes, and
the mobile re-connects to a new FA. In this case, the AAAF, or AAAH, *could*
believe this is the continuation of an old session.=20

If one is billed by time, this is a problem.

So, I think that additional text is required on when this should be done.


[...]

> 11.8  Session Termination
>
>  The Diameter Base Protocol provides a set of messages that MUST be
>  used by any peer to explicitly request that a previously
>  authenticated and/or authorized session be terminated. Since the
>  Session-Id is typically tied to a particular service (i.e. Mobile IP,
>  NASREQ, etc), the session termination messages are used to request
>  that the service tied to the Session Id be terminated.

Did you add 11.8 in your e-mail to help me locate where the text should be
added? It appears to be exactly the same as what's in the draft.

PatC

--tqI+Z3u+9OQ7kwn0
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE67ZiWvcrGpbaK4X8RAmF+AJ9/rnEhZTtrPBrflcuz3mjemVLKoQCdHAYT
3fkllkDBist3iZxybOH5ums=
=KqwG
-----END PGP SIGNATURE-----

--tqI+Z3u+9OQ7kwn0--



From owner-aaa-bof@merit.edu  Mon Apr 30 13:21:53 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19713
	for <aaa-archive@odin.ietf.org>; Mon, 30 Apr 2001 13:21:52 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 39B395DEC7; Mon, 30 Apr 2001 13:19:53 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 236435DEC6; Mon, 30 Apr 2001 13:19:53 -0400 (EDT)
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by segue.merit.edu (Postfix) with SMTP id 69F8F5DEC0
	for <aaa-wg@merit.edu>; Mon, 30 Apr 2001 13:19:51 -0400 (EDT)
Received: (qmail 4788 invoked by uid 500); 30 Apr 2001 17:09:50 -0000
Date: Mon, 30 Apr 2001 10:09:50 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: aaa-wg@merit.edu
Subject: [AAA-WG]: SPI Allocation
Message-ID: <20010430100950.F3397@charizard.diameter.org>
Mail-Followup-To: aaa-wg@merit.edu
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-md5;
	protocol="application/pgp-signature"; boundary="84ND8YJRMFlzkrP4"
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Sender: owner-aaa-bof@merit.edu
Precedence: bulk


--84ND8YJRMFlzkrP4
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

> 7.5 SPI Allocation
>
>  To ensure that the SPI is unique for each pair of nodes,
>  the AAAH SHOULD keep track of assigned SPIs per HA and MN.
>  The SPI assigned to the MN-FA key MUST be allocated from
>  the MN SPI pool, the SPI for the FA-HA key MUST be
>  allocated from the HA SPI pool, and the SPI for the MN-HA
>  key MUST be allocated from the MN SPI pool. Note that SPI
>  values 0 through 255 are reserved and MUST NOT be used in
>  any Mobility Security Association.

Keep in mind that the above text requires that the AAAH maintains
SPI state for all devices, and there will be plenty of devices.

Furthermore, this doesn't scale well when there are many AAAHs
in the network providing services to the HAs. The AAAHs would have
to replicate their SPI state information. There has got to be a
better way....

I believe that if the MN provides what it prefers, and the FA does
the same, then the AAAH would provide the "desired" SPIs to the HA,
which has the option of sending back an error to the AAAH if the
SPI in question doesn't work. So the AAAH could try again.

Also, some text on the randomness of SPI values would be a good
addition to the extension.


> 7.6 Retreiving Mobility Session Keys from AAAF
>
>  In the case that a user moves between two FAs under the
>  same administrative domain it may be possible for the AAAF
>  to distribute the mobility session keys for the old FA to
>  the new FA. To do this the client will send an AMR to the
>  AAAF with the Previous-FA-FQDN or Previous-FA-Address AVP.
>  AAAF will retreive the keys based on the User-Name NAI and
>  the information about the previous FA and send them back
>  to the client in an AMA. The AMA will also include the
>  MIP Registration Request AVP to indicate to the client that
>  it need to forward the request directly to the HA in order
>  to update the mobile ip tunnel.

If a Registration Request is included, then I would MUCH prefer
that we simply do away with retrieving local keys, and always
require a full round trip. This would really simplify the AAAF,
and reduce the amount of state on that box.

However, if and when optimized solutions are developed in Mobile IP
to handle local mobility (e.g. LMMs), then this problem isn't that
bad because the higher level agents could be the ones that communicate
with the Diameter infrastructure, reducing the cases where AAA is=20
involved.

Also, if and when Context Transfer occurs, the AAA session identifier
(and other interesting AAA stuff) could be transfered. So I am wondering
that given the work ongoing in other Working Groups, how much of it
does AAA have to handle? I would much prefer to eliminate features that
are difficult to handle.

> 7.6.1 Home Agent Behaviour

>  The HA will use the SPI to understand what key to use when
>  authenticating the received registration request. Since the
>  request is received from a new FA but with the SPI used with
>  the old FA the HA will not find the Security Context. Thus
>  the search sequence of the HA must be extended to handle this
>  scenario. If the HA failes to find a Security Context when it
>  looks in the Mobility Security Association it shares
>  with the sending node, it MUST look for a Previous-FA-FQDN or
>  Previous-FA-Address extension in the request. If one is
>  available it must look for the Security Context under the
>  previous FA mobility SA and copy it to the new SA.

ok, something similar to the above is probably a good idea.

PatC


--84ND8YJRMFlzkrP4
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE67ZxdvcrGpbaK4X8RAjwCAKCIv2V0a86F5jiV9scNlXmP+Vnq0QCeL40o
z909lUWX4wxzPgRvKyh/UKE=
=meBa
-----END PGP SIGNATURE-----

--84ND8YJRMFlzkrP4--



From owner-aaa-bof@merit.edu  Mon Apr 30 13:29:42 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19954
	for <aaa-archive@odin.ietf.org>; Mon, 30 Apr 2001 13:29:42 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 2D45A5DDC9; Mon, 30 Apr 2001 13:29:22 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 1BCAE5DDC0; Mon, 30 Apr 2001 13:29:22 -0400 (EDT)
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by segue.merit.edu (Postfix) with SMTP id 9A22B5DDC9
	for <aaa-wg@merit.edu>; Mon, 30 Apr 2001 13:29:20 -0400 (EDT)
Received: (qmail 4850 invoked by uid 500); 30 Apr 2001 17:19:19 -0000
Date: Mon, 30 Apr 2001 10:19:19 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: aaa-wg@merit.edu
Subject: [AAA-WG]: Downloading keys from AAAF
Message-ID: <20010430101919.G3397@charizard.diameter.org>
Mail-Followup-To: aaa-wg@merit.edu
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-md5;
	protocol="application/pgp-signature"; boundary="/QKKmeG/X/bPShih"
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Sender: owner-aaa-bof@merit.edu
Precedence: bulk


--/QKKmeG/X/bPShih
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

> In the case where the MN is roaming within a foreign domain,
> a Registration is sent and an AMR is be sent to the AAAF. Then the
> AAAF returns the keys to the new FA without authenticating
> the MN. That seems to be a "problem". However, if it would reach=20
> the Home server, then the MN could be authenticated based on
> the MIP-MN-AAA-Auth AVP, which could decide if it is a valid
> request for reporting a roaming situation.

This in itself is not a problem.

When the keys are downloaded from the AAAF to the FA, which btw is in
the same administrative domain, the FA would authenticate the mobile's
Registration Request, via the MN-FA auth ext. So, if the mobile was a
malicious one, the authentication would fail.

However, if the AAAF maintains state, and believes that the request from
the FA means that the mobile has moved, and updates its state information,
then this is a serious problem.

This comes back to my post earlier today, where this information SHOULD
be handled via a context transfer, and this functionality should be
removed from Diameter.

PatC
--/QKKmeG/X/bPShih
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE67Z6WvcrGpbaK4X8RAmJ3AKCJP1j2ExmKybhhjkT2GeGlV6bN2gCgjNkY
C6qZJ0BUk/Oahkw2N9kyvOI=
=0wYO
-----END PGP SIGNATURE-----

--/QKKmeG/X/bPShih--



From owner-aaa-bof@merit.edu  Mon Apr 30 14:02:45 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20813
	for <aaa-archive@odin.ietf.org>; Mon, 30 Apr 2001 14:02:45 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 26E2E5DDC0; Mon, 30 Apr 2001 13:43:29 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 146005DDF8; Mon, 30 Apr 2001 13:43:29 -0400 (EDT)
Received: from charizard.diameter.org (c900656-a.plstn1.sfba.home.com [24.20.167.220])
	by segue.merit.edu (Postfix) with SMTP id 93C925DDC0
	for <aaa-wg@merit.edu>; Mon, 30 Apr 2001 13:43:27 -0400 (EDT)
Received: (qmail 4931 invoked by uid 500); 30 Apr 2001 17:33:26 -0000
Date: Mon, 30 Apr 2001 10:33:26 -0700
From: Pat Calhoun <pcalhoun@diameter.org>
To: aaa-wg@merit.edu
Subject: [AAA-WG]: Mobile IP Extension Unresolved Issues
Message-ID: <20010430103326.H3397@charizard.diameter.org>
Mail-Followup-To: aaa-wg@merit.edu
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-md5;
	protocol="application/pgp-signature"; boundary="/Zw+/jwnNHcBRYYu"
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
Sender: owner-aaa-bof@merit.edu
Precedence: bulk


--/Zw+/jwnNHcBRYYu
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

All,

While re-reading the Previous-FA-xxxx thread, and from my posts earlier tod=
ay,
it is obvious that there are some unresolved problems in the Mobile IP
extension that really need to be handled prior to sending out the next
revision of the spec, and this MUST happen prior to the interim meeting.

Here is a quick proposal, and I would like to setup a conference call by
all interested parties for next Tuesday at 9am Pacific. I will send out
the necessary conference info. Ideally, though, I would prefer to have this
call setup for tomorrow, but I realize that I have to provide adequate
preparation time for people to drop what they are doing, and get on this ca=
ll.

Could people interested in this call please respond back directly, and then=
 I
can see if we can move this ahead.

So my proposal is as follows:

When a mobile is handed off to a new Foreign Agent, the FA would use the
Context Transfer protocol (or the MIP FA blob) to authenticate the MN-FA
auth extension. This does NOT require *any* AAA involvement, and reduces the
complexity of the protocol.

btw, if we are to do this, then we could also easily include the Session-Id
in the context transfer, or the FA blob.

Then, while it is forwarding the Registration Request to the Home Agent,
it also sends an HAR to the AAAF (which will make its way to the AAAH). This
message DOES NOT include a Registration Reply, and has something in the
message that identifies itself as an update of FA only. The AAAH would
update its table, and return a successful AMA to the AAAF, and FA.=20

So this updating of the AAAH does not add any latency to the registration
process and reduces the complexity of the protocol.

Note that the only caveat here is that we are relying on context transfer,
which is just starting its requirements, or on the FA blob, which is not a
MIP WG document.

Comments?

PatC
--/Zw+/jwnNHcBRYYu
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE67aHkvcrGpbaK4X8RAhCXAJ98j8dQUZ+v92ApbwADh6aLSU5KgQCfYkju
0WVQxKGooeNHqzSg5KCE7TU=
=nN0/
-----END PGP SIGNATURE-----

--/Zw+/jwnNHcBRYYu--



From owner-aaa-bof@merit.edu  Mon Apr 30 16:09:00 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA24530
	for <aaa-archive@odin.ietf.org>; Mon, 30 Apr 2001 16:09:00 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 242285DF07; Mon, 30 Apr 2001 16:06:48 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 13EF85DF06; Mon, 30 Apr 2001 16:06:48 -0400 (EDT)
Received: from motgate.mot.com (motgate.mot.com [129.188.136.100])
	by segue.merit.edu (Postfix) with ESMTP id D72665DED8
	for <aaa-wg@merit.edu>; Mon, 30 Apr 2001 16:06:46 -0400 (EDT)
Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate.mot.com (motgate 2.1) with ESMTP id NAA25683 for <aaa-wg@merit.edu>; Mon, 30 Apr 2001 13:06:46 -0700 (MST)]
Received: [from il35exm01.cig.mot.com (IL35EXM01.cig.mot.com [160.19.16.101]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id NAA20103 for <aaa-wg@merit.edu>; Mon, 30 Apr 2001 13:01:01 -0700 (MST)]
Received: by IL35EXM01.cig.mot.com with Internet Mail Service (5.5.2653.19)
	id <2RXQVDPL>; Mon, 30 Apr 2001 15:06:45 -0500
Message-ID: <35DBB8B7AC89D4118E98009027B1009B0ECEB3@IL27EXM10.cig.mot.com>
From: Cain Brian-BCAIN1 <Brian.Cain@motorola.com>
To: "'Jonathan Wood'" <Jonathan.Wood@Sun.COM>, aaa-wg@merit.edu
Subject: RE: [AAA-WG]: Diameter/SCTP and watchdogs
Date: Mon, 30 Apr 2001 15:06:45 -0500
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Johnathan,

	While I do agree that it's wasteful to include redundant redundancy, wouldn't this require different peer state machines for TCP and SCTP?  Couldn't there be some other way to reduce the overhead for SCTP?  What about negotiating the frequency of the watchdog messages in a DRI or something similar?  That way, an entity could configure infrequent (perhaps the maximum value of some well-known time data structure) watchdog messages for their reliable (sctp) links and more frequent watchdog messages for their less-reliable (tcp) counterparts.

-Brian
> -----Original Message-----
> From: Jonathan Wood [mailto:Jonathan.Wood@Sun.COM]
> Sent: Monday, April 30, 2001 2:45 PM
> To: aaa-wg@merit.edu
> Subject: [AAA-WG]: Diameter/SCTP and watchdogs
> 
> 
> 
> Section 7 of the base protocol draft describes watchdogs
> to detect peer failure.
> 
> SCTP already has this functionality built in, so when
> using SCTP, diameter doesn't need to do it too. To this
> end I suggest that we add some text stating section
> 7 is needed only when transporting diamter over TCP.
> 
> Jonathan
> 
> 



From owner-aaa-bof@merit.edu  Mon Apr 30 16:18:59 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA24798
	for <aaa-archive@odin.ietf.org>; Mon, 30 Apr 2001 16:18:58 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 4C5075DE4F; Mon, 30 Apr 2001 16:15:20 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 3ADB95DE4E; Mon, 30 Apr 2001 16:15:20 -0400 (EDT)
Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1])
	by segue.merit.edu (Postfix) with ESMTP id BD6555DE0D
	for <aaa-wg@merit.edu>; Mon, 30 Apr 2001 16:15:18 -0400 (EDT)
Received: from heliopolis.eng.sun.com ([152.70.1.39])
	by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id NAA15133
	for <aaa-wg@merit.edu>; Mon, 30 Apr 2001 13:15:17 -0700 (PDT)
Received: from srmtv29a (srmtv29a [152.70.1.41])
	by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id NAA09577
	for <aaa-wg@merit.edu>; Mon, 30 Apr 2001 13:15:16 -0700 (PDT)
Message-Id: <200104302015.NAA09577@heliopolis.eng.sun.com>
Date: Mon, 30 Apr 2001 13:15:16 -0700 (PDT)
From: Jonathan Wood <Jonathan.Wood@Sun.COM>
Reply-To: Jonathan Wood <Jonathan.Wood@Sun.COM>
Subject: [AAA-WG]: Diamter/SCTP: preventing head-of-the-line blocking
To: aaa-wg@merit.edu
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: g9btVGBSjzubF8T+Isnhzg==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
Sender: owner-aaa-bof@merit.edu
Precedence: bulk


While SCTP has built in support for preventing head-
of-the-line blocking, there is currently no provision
in the diameter spec to utilize this functionality.
This means that Diameter/SCTP at present has the
same head-of-the-line blocking problems as Diamter/
vanilla TCP.

We can easily use SCTP streams to fix this. I propose
the following:

Each diameter node should stripe its messages across
the range of SCTP streams that it and its peer have
agreed upon. (A lost message in one stream will not
cause any other streams to block.) A trivial and
effective implementation of this simply increments
a counter for the stream ID to send on. When the
counter reaches the maximum number of streams for
the association, it resets to 0.

Diameter peers must be able to accept messages on
any stream. Note that streams are used *solely* to
prevent head-of-the-line blocking. All identifying
information is carried within the diamter payload.

SCTP peers can allocate up to 65535 streams for an
association. The cost for idle streams may or may not
be zero, and the cost for non-idle streams is always
greater than 0. So administrators may wish to limit
the number of possible streams on their diameter nodes
according to the resources (i.e. memory, CPU power, etc.)
of a particular node.

Stream IDs do not need to be preserved by proxies. For
example, consider the following case, where B serves
as a proxy between A and C:

A --------------------- B -------------------- C
     1000 streams            2000 streams

  msg 1: str id 0          msg 1: str id 0
  msg 2: str id 1          msg 2: str id 1
   ...                      ...
  msg 1000: str id 999     msg 1000: str id 999
  msg 1001: str id 0       msg 1001: str id 1000

The striping acts sort of like a hash table. It is
possible, yet unlikely, that two messages will end
up in the same stream, and even less likely that
there will be message loss resulting in blocking when
this happens. If it does turn out to be a problem, local
administrators can increase the number of streams on
their nodes to improve performance.

Questions / comments?

Jonathan

  




From owner-aaa-bof@merit.edu  Mon Apr 30 16:34:20 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA25120
	for <aaa-archive@odin.ietf.org>; Mon, 30 Apr 2001 16:34:20 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 3F9AD5DE5C; Mon, 30 Apr 2001 16:30:41 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 2F1545DE58; Mon, 30 Apr 2001 16:30:41 -0400 (EDT)
Received: from patan.sun.com (patan.Sun.COM [192.18.98.43])
	by segue.merit.edu (Postfix) with ESMTP id 79ED05DE56
	for <aaa-wg@merit.edu>; Mon, 30 Apr 2001 16:30:39 -0400 (EDT)
Received: from heliopolis.eng.sun.com ([152.70.1.39])
	by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA13668;
	Mon, 30 Apr 2001 13:30:31 -0700 (PDT)
Received: from srmtv29a (srmtv29a [152.70.1.41])
	by heliopolis.eng.sun.com (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with SMTP id NAA10086;
	Mon, 30 Apr 2001 13:30:29 -0700 (PDT)
Message-Id: <200104302030.NAA10086@heliopolis.eng.sun.com>
Date: Mon, 30 Apr 2001 13:30:29 -0700 (PDT)
From: Jonathan Wood <Jonathan.Wood@Sun.COM>
Reply-To: Jonathan Wood <Jonathan.Wood@Sun.COM>
Subject: RE: [AAA-WG]: Diameter/SCTP and watchdogs
To: aaa-wg@merit.edu, Brian.Cain@motorola.com
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: plCjChLhzSSaHzG7t3yufg==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.4.2 SunOS 5.8 sun4u sparc 
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

>
>Johnathan,
>
>	While I do agree that it's wasteful to include redundant redundancy, 
wouldn't this require different peer state machines for TCP and SCTP?  Couldn't

Hmm would they? If you never turn on the watchdog timer, you never
get watchdog events, and the state-machine code can be the same.

> there be some other way to reduce the overhead for SCTP?  What about 
negotiating the frequency of the watchdog messages in a DRI or something 
similar?  That way, an entity could configure infrequent (perhaps the maximum 
value of some well-known time data structure) watchdog messages for their 
reliable (sctp) links and more frequent watchdog messages for their 
less-reliable (tcp) counterparts.

This is one possibility. But there is more than just redundancy
on the network at stake here. Incorporated with the watchdog
functionality is the whole bundle of RTT measurement and RTO
calculation, which can be pretty subtle (how many papers have
been written on this subject? :) and is, I believe, something
best left to the transport layer. It would be nice to not
have to do this at all in Diameter (another argument for moving
to SCTP exculsively).

Now that I think about it, could we rely on TCP keepalives
for analagous functionality in TCP and get rid of this
altogether?

Jonathan

>
>-Brian
>> -----Original Message-----
>> From: Jonathan Wood [mailto:Jonathan.Wood@Sun.COM]
>> Sent: Monday, April 30, 2001 2:45 PM
>> To: aaa-wg@merit.edu
>> Subject: [AAA-WG]: Diameter/SCTP and watchdogs
>> 
>> 
>> 
>> Section 7 of the base protocol draft describes watchdogs
>> to detect peer failure.
>> 
>> SCTP already has this functionality built in, so when
>> using SCTP, diameter doesn't need to do it too. To this
>> end I suggest that we add some text stating section
>> 7 is needed only when transporting diamter over TCP.
>> 
>> Jonathan
>> 
>> 




From owner-aaa-bof@merit.edu  Mon Apr 30 16:38:38 2001
Received: from segue.merit.edu ([198.108.1.41])
	by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA25236
	for <aaa-archive@odin.ietf.org>; Mon, 30 Apr 2001 16:38:37 -0400 (EDT)
Received: by segue.merit.edu (Postfix)
	id 3438C5DE91; Mon, 30 Apr 2001 16:31:40 -0400 (EDT)
Delivered-To: aaa-wg-outgoing@merit.edu
Received: by segue.merit.edu (Postfix, from userid 56)
	id 207565DE8F; Mon, 30 Apr 2001 16:31:40 -0400 (EDT)
Received: from ahab.tic.siemens.ca (ahab.tic.siemens.ca [64.26.131.130])
	by segue.merit.edu (Postfix) with ESMTP id 214205DE7D
	for <aaa-wg@merit.edu>; Mon, 30 Apr 2001 16:31:38 -0400 (EDT)
Received: (from mail@localhost)
	by ahab.tic.siemens.ca (8.9.3/8.9.3) id QAA08116;
	Mon, 30 Apr 2001 16:31:20 -0400 (EDT)
Received: from mailman(172.21.24.8) by ahab.tic.siemens.ca via smap (V2.1)
	id xma008114; Mon, 30 Apr 01 16:30:50 -0400
Received: (from mail@localhost)
	by mailman.innovation.siemens.ca (8.9.3/8.9.3) id QAA26335;
	Mon, 30 Apr 2001 16:30:31 -0400 (EDT)
Received: from ticsmtp1.innovation.siemens.ca(172.21.24.34) by mailman.innovation.siemens.ca via smap (V2.1)
	id xma026246; Mon, 30 Apr 01 16:29:54 -0400
Received: by ticsmtp1.innovation.siemens.ca with Internet Mail Service (5.5.2650.21)
	id <2XDRFY5K>; Mon, 30 Apr 2001 16:29:39 -0400
Message-ID: <E7BB0E796757D411BC9A00105ACB123E32F6FD@ticsmtp1.innovation.siemens.ca>
From: Yiwen Jiang <Yiwen.Jiang@tic.siemens.ca>
To: "'Jonathan Wood'" <Jonathan.Wood@Sun.COM>, aaa-wg@merit.edu
Cc: "'Pat Calhoun'" <pcalhoun@diameter.org>
Subject: RE: [AAA-WG]: Diamter/SCTP: preventing head-of-the-line blocking
Date: Mon, 30 Apr 2001 16:29:38 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-aaa-bof@merit.edu
Precedence: bulk

Hi there,

I have a question that has been bugging me from the very beginning regarding
SCTP... 

There is really no stable SCTP implementation out there avaiable for us to
do development on (kernel or user land implementation). In addition, it is
my impression that the RFC is still not that stable (e.g. the recently
discovered Adler32 checksum weakness), why is SCTP a mandate for the
Diameter base protocol? Sure it provides us many desirable features, but if
there is no publicly available implementation out there, how can we support
this? Or is the current mandate only to look at using future possibilities
at a theorotical level?

Cheers,
Yiwen
---
Yiwen Jiang
Mobile IP Networking
Email: Yiwen.Jiang@tic.siemens.ca
Phone: (613)271-7710

Telecom Innovation Centre
505 March Road
Kanata, Ontario, Canada
K2K 2M5


> -----Original Message-----
> From: Jonathan Wood [mailto:Jonathan.Wood@Sun.COM]
> Sent: Monday, April 30, 2001 4:15 PM
> To: aaa-wg@merit.edu
> Subject: [AAA-WG]: Diamter/SCTP: preventing head-of-the-line blocking
> 
> 
> 
> While SCTP has built in support for preventing head-
> of-the-line blocking, there is currently no provision
> in the diameter spec to utilize this functionality.
> This means that Diameter/SCTP at present has the
> same head-of-the-line blocking problems as Diamter/
> vanilla TCP.
> 
> We can easily use SCTP streams to fix this. I propose
> the following:
> 
> Each diameter node should stripe its messages across
> the range of SCTP streams that it and its peer have
> agreed upon. (A lost message in one stream will not
> cause any other streams to block.) A trivial and
> effective implementation of this simply increments
> a counter for the stream ID to send on. When the
> counter reaches the maximum number of streams for
> the association, it resets to 0.
> 
> Diameter peers must be able to accept messages on
> any stream. Note that streams are used *solely* to
> prevent head-of-the-line blocking. All identifying
> information is carried within the diamter payload.
> 
> SCTP peers can allocate up to 65535 streams for an
> association. The cost for idle streams may or may not
> be zero, and the cost for non-idle streams is always
> greater than 0. So administrators may wish to limit
> the number of possible streams on their diameter nodes
> according to the resources (i.e. memory, CPU power, etc.)
> of a particular node.
> 
> Stream IDs do not need to be preserved by proxies. For
> example, consider the following case, where B serves
> as a proxy between A and C:
> 
> A --------------------- B -------------------- C
>      1000 streams            2000 streams
> 
>   msg 1: str id 0          msg 1: str id 0
>   msg 2: str id 1          msg 2: str id 1
>    ...                      ...
>   msg 1000: str id 999     msg 1000: str id 999
>   msg 1001: str id 0       msg 1001: str id 1000
> 
> The striping acts sort of like a hash table. It is
> possible, yet unlikely, that two messages will end
> up in the same stream, and even less likely that
> there will be message loss resulting in blocking when
> this happens. If it does turn out to be a problem, local
> administrators can increase the number of streams on
> their nodes to improve performance.
> 
> Questions / comments?
> 
> Jonathan
> 
>   
> 
>