From dime-bounces@ietf.org Fri Aug 04 05:07:31 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G8veU-00071G-JQ; Fri, 04 Aug 2006 05:07:30 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G8veT-00071B-5P
	for dime@ietf.org; Fri, 04 Aug 2006 05:07:29 -0400
Received: from jaguar.hughesbpo.net ([61.246.186.17] helo=jaguar.hss.hns.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8veR-0007AD-7k
	for dime@ietf.org; Fri, 04 Aug 2006 05:07:29 -0400
Received: from jaguar.hss.hns.com (localhost [127.0.0.1])
	by jaguar.hss.hns.com (8.13.6/8.12.10) with ESMTP id k7498v9t001171
	for <dime@ietf.org>; Fri, 4 Aug 2006 14:38:57 +0530 (IST)
Received: from ultra.hss.co.in (ultra.hss.hns.com [192.168.100.5])
	by jaguar.hss.hns.com (8.13.6/8.13.6) with ESMTP id k7498sAR001144
	for <dime@ietf.org>; Fri, 4 Aug 2006 14:38:56 +0530 (IST)
Received: from sandesh.hss.hns.com (localhost [127.0.0.1])
	by ultra.hss.co.in (8.10.0/8.10.0) with ESMTP id k74985N15790
	for <dime@ietf.org>; Fri, 4 Aug 2006 14:38:15 +0530 (IST)
To: dime@ietf.org
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004
Message-ID: <OFAA01C6F0.7613E7BC-ON652571C0.0031D20F-652571C0.00321635@flextronicssoftware.com>
From: Manish Sharma <manish.sharma@flextronicssoftware.com>
Date: Fri, 4 Aug 2006 14:40:10 +0530
X-MIMETrack: Serialize by Router on Sandesh/HSS(Release 6.0|September 26,
	2002) at 04/08/2006 02:37:15 PM,
	Serialize complete at 04/08/2006 02:37:15 PM
X-Spam-Score: 0.6 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
Subject: [Dime] STR/STA and ASR/ASA
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0251848355=="
Errors-To: dime-bounces@ietf.org

This is a multipart message in MIME format.
--===============0251848355==
Content-Type: multipart/alternative;
	boundary="=_alternative 00321631652571C0_="

This is a multipart message in MIME format.
--=_alternative 00321631652571C0_=
Content-Type: text/plain; charset="US-ASCII"

Hi All,
I have a small query regarding STR/STA and ASR/ASA commands. I was reading 
the diameter RFC 3588 and found that they have written that these commands 
are used only in Auth Session State machine. As in Accounting also we 
create sessions so why not we should add these in Accounting state machine 
also ? 

According to me above commands should be part of Accounting also. 


Regards
Manish Sharma


***********************  FSS-Unclassified   ***********************
--=_alternative 00321631652571C0_=
Content-Type: text/html; charset="US-ASCII"


<br><font size=2 face="sans-serif">Hi All,</font>
<br><font size=2 face="sans-serif">I have a small query regarding STR/STA
and ASR/ASA commands. I was reading the diameter RFC 3588 and found that
they have written that these commands are used only in Auth Session State
machine. As in Accounting also we create sessions so why not we should
add these in Accounting state machine also ? </font>
<br>
<br><font size=2 face="sans-serif">According to me above commands should
be part of Accounting also. </font>
<br>
<br>
<br><font size=2 face="sans-serif">Regards</font>
<br><font size=2 face="sans-serif">Manish Sharma</font>
<br><font size=2 face="sans-serif"><br>
<br>
*********************** &nbsp;FSS-Unclassified &nbsp; ***********************</font>
--=_alternative 00321631652571C0_=--


--===============0251848355==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0251848355==--




From dime-bounces@ietf.org Fri Aug 04 05:30:30 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G8w0j-0005I3-QA; Fri, 04 Aug 2006 05:30:29 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G8w0i-0005Hy-Eg
	for dime@ietf.org; Fri, 04 Aug 2006 05:30:28 -0400
Received: from [59.145.147.70] (helo=ricky.india.internal.net)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G8w0g-0002Z8-GJ
	for dime@ietf.org; Fri, 04 Aug 2006 05:30:28 -0400
X-Anti-Virus: Cyberoam Anti-Virus for SMTP;
	Kaspersky 5.5.3/RELEASE, bases: 04082006 #199772; status: clean
Received: from [172.16.3.44] ([172.16.3.44])
	by ricky.india.internal.net (8.12.10/8.11.6) with ESMTP id
	k749SjBI005108; Fri, 4 Aug 2006 14:58:45 +0530
Message-ID: <44D31496.3010509@intellinet-india.com>
Date: Fri, 04 Aug 2006 15:04:14 +0530
From: Dhirananda <dsenapati@intellinet-india.com>
User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Manish Sharma <manish.sharma@flextronicssoftware.com>
Subject: Re: [Dime] STR/STA and ASR/ASA
References: <OFAA01C6F0.7613E7BC-ON652571C0.0031D20F-652571C0.00321635@flextronicssoftware.com>
In-Reply-To: <OFAA01C6F0.7613E7BC-ON652571C0.0031D20F-652571C0.00321635@flextronicssoftware.com>
X-SpamTest-Info: Profile: Formal (480/060802)
X-SpamTest-Info: Profile: Detect Hard (4/030526)
X-SpamTest-Info: Profile: SysLog
X-SpamTest-Status: Not detected
X-SpamTest-Version: SMTP-Filter Version 2.0.0 [0124], KAS/Release
X-Spam-Score: 3.0 (+++)
X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0526752724=="
Errors-To: dime-bounces@ietf.org

This is a multi-part message in MIME format.
--===============0526752724==
Content-Type: multipart/alternative;
	boundary="------------020309060709030703050005"

This is a multi-part message in MIME format.
--------------020309060709030703050005
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi Manish,
 As mentioned in the Section 9.5 of RFC -3588
 Accounting sessions are terminated by Accounting-Record-Type AVP.
This AVP contain value STOP_RECORD to terminate the accounting session.
As Accounting service is a one-time event, meaning that the start and 
stop of the event are simultaneous it should not be terminated with 
separate STR .

Regards,

Dhirananda

Manish Sharma wrote:

>
> Hi All,
> I have a small query regarding STR/STA and ASR/ASA commands. I was 
> reading the diameter RFC 3588 and found that they have written that 
> these commands are used only in Auth Session State machine. As in 
> Accounting also we create sessions so why not we should add these in 
> Accounting state machine also ?
>
> According to me above commands should be part of Accounting also.
>
>
> Regards
> Manish Sharma
>
>
> ***********************  FSS-Unclassified   ***********************
>
>------------------------------------------------------------------------
>
>_______________________________________________
>DiME mailing list
>DiME@ietf.org
>https://www1.ietf.org/mailman/listinfo/dime
>  
>


--------------020309060709030703050005
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<font color="#000099">Hi Manish,<br>
&nbsp;As mentioned in the Section 9.5 of RFC -3588 <br>
&nbsp;Accounting sessions are terminated by Accounting-Record-Type AVP.<br>
This AVP contain value STOP_RECORD to terminate the accounting session.<br>
As Accounting service is a one-time event, meaning that the start and
stop of the event are simultaneous it should not be terminated with
separate STR .<br>
<br>
Regards,<br>
<br>
Dhirananda</font><br>
<br>
Manish Sharma wrote:
<blockquote
 cite="midOFAA01C6F0.7613E7BC-ON652571C0.0031D20F-652571C0.00321635@flextronicssoftware.com"
 type="cite"><br>
  <font face="sans-serif" size="2">Hi All,</font>
  <br>
  <font face="sans-serif" size="2">I have a small query regarding
STR/STA
and ASR/ASA commands. I was reading the diameter RFC 3588 and found
that
they have written that these commands are used only in Auth Session
State
machine. As in Accounting also we create sessions so why not we should
add these in Accounting state machine also ? </font>
  <br>
  <br>
  <font face="sans-serif" size="2">According to me above commands
should
be part of Accounting also. </font>
  <br>
  <br>
  <br>
  <font face="sans-serif" size="2">Regards</font>
  <br>
  <font face="sans-serif" size="2">Manish Sharma</font>
  <br>
  <font face="sans-serif" size="2"><br>
  <br>
*********************** &nbsp;FSS-Unclassified &nbsp; ***********************</font>
  <pre wrap="">
<hr size="4" width="90%">
_______________________________________________
DiME mailing list
<a class="moz-txt-link-abbreviated" href="mailto:DiME@ietf.org">DiME@ietf.org</a>
<a class="moz-txt-link-freetext" href="https://www1.ietf.org/mailman/listinfo/dime">https://www1.ietf.org/mailman/listinfo/dime</a>
  </pre>
</blockquote>
<br>
</body>
</html>

--------------020309060709030703050005--



--===============0526752724==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0526752724==--





From dime-bounces@ietf.org Fri Aug 04 11:32:37 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G91fB-0004FI-Gh; Fri, 04 Aug 2006 11:32:37 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G91fA-0004FC-C6
	for dime@ietf.org; Fri, 04 Aug 2006 11:32:36 -0400
Received: from imx11.toshiba.co.jp ([61.202.160.20])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G91f9-0006Hh-HC
	for dime@ietf.org; Fri, 04 Aug 2006 11:32:36 -0400
Received: from wall11.toshiba.co.jp (wall11 [133.199.90.149])
	by imx11.toshiba.co.jp  with ESMTP id k74FWIsv013577;
	Sat, 5 Aug 2006 00:32:18 +0900 (JST)
Received: (from root@localhost) by wall11.toshiba.co.jp  id k74FWIhg027157;
	Sat, 5 Aug 2006 00:32:18 +0900 (JST)
Received: from ovp11.toshiba.co.jp [133.199.90.148] 
	by wall11.toshiba.co.jp with SMTP id AAA27153;
	Sat, 5 Aug 2006 00:32:18 +0900
Received: from mx.toshiba.co.jp (localhost [127.0.0.1])
	by ovp11.toshiba.co.jp  with ESMTP id k74FWHLH013795;
	Sat, 5 Aug 2006 00:32:17 +0900 (JST)
Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k74FWHIW010290;
	Sat, 5 Aug 2006 00:32:17 +0900 (JST)
Received: from steelhead ([172.30.24.104])
	by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built
	Apr 28
	2004)) with ESMTPSA id <0J3H006HVCHIQJK0@mail.po.toshiba.co.jp>; Sat,
	05 Aug 2006 00:32:17 +0900 (JST)
Received: from ohba by steelhead with local (Exim 4.62)
	(envelope-from <yohba@tari.toshiba.com>)	id 1G91eR-0003PY-PT; Fri,
	04 Aug 2006 08:31:51 -0700
Date: Fri, 04 Aug 2006 11:31:51 -0400
From: Yoshihiro Ohba <yohba@tari.toshiba.com>
Subject: Re: [Dime] Summary of 3588bis Issues Status
In-reply-to: <000201c6b174$7eb0b370$6291460a@china.huawei.com>
To: Tony Zhang <zhangtao_hw@huawei.com>
Message-id: <20060804153151.GM5883@steelhead>
MIME-version: 1.0
Content-type: text/plain; charset=euc-jp
Content-disposition: inline
References: <BAA65A575825454CBB0103267553FCCC39CCAB@esebe199.NOE.Nokia.com>
	<000201c6b174$7eb0b370$6291460a@china.huawei.com>
User-Agent: Mutt/1.5.11+cvs20060403
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by ovp11.toshiba.co.jp id
	k74FWHLH013795
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 65bc4909d78e8b10349def623cf7a1d1
Cc: dime@ietf.org, Marco.STURA@vodafone.com
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

On Thu, Jul 27, 2006 at 08:02:12PM +0800, Tony Zhang wrote:
> Hi John:
> 	When I read proxy agent definition in RFC3588:
>    Proxies that wish to limit resources MUST maintain session state.
>    All proxies MUST maintain transaction state.
>    Since enforcing policies requires an understanding of the service
>    being provided, Proxies MUST only advertise the Diameter application=
s
>    they support.
>=20
> Maybe almost the stateful proxy is more.
>=20
> If With respect to the App ID =3D 0 issue, we assumed that
> proxies are stateless.
> I think use app Id =3D 0,the routing for some environment is not effect=
ive.
> Tolga already give one network environment.

On the other hand, use of App ID =3D 0 does not completely solve the
routing issue with stateful proxies, especially when there are
multiple candidate next hop stateful proxies.  In this case whatever
application id is used, it is not guaranteed that all messages that
belong to the same session to go through the same stateful proxy.  I
believe source routing is needed to solve the routing problem with
stateful proxies.

Yoshihiro Ohba



>=20
> Thanks!
> Tony.
> -----Original Message-----
> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20
> Sent: Thursday, July 27, 2006 7:30 AM
> To: zhangtao_hw@huawei.com; Marco.STURA@vodafone.com; asveren@ulticom.c=
om; vfajardo@tari.toshiba.com
> Cc: dime@ietf.org
> Subject: RE: [Dime] Summary of 3588bis Issues Status
>=20
> Tony,
>=20
> During the initial work on Diameter, it was hoped that proxies would
> be a rare occurance.  We assumed all proxies will be stateless.
>=20
> If someone needs stateful proxies, I'd like to understand what the prob=
lem
> stateful proxies are trying to solve is, and why the current solution
> is insufficient.  Wit respect to the App ID =3D 0 issue, we assumed tha=
t
> proxies are stateless.
>=20
> John
> >-----Original Message-----
> >From: ext Tony Zhang [mailto:zhangtao_hw@huawei.com]=20
> >Sent: 24 July, 2006 02:00
> >To: STURA, Marco, VF-IT; Tolga Asveren; Victor Fajardo
> >Cc: dime@ietf.org
> >Subject: Re: [Dime] Summary of 3588bis Issues Status
> >
> >Hi Marco:
> >
> >    I also agree the generic problem of "How can a proxy stay=20
> >>on the path during a session", but i think this problem is=20
> >address the stateful proxy agent,acutal maybe still have=20
> >stateless proxy agent.so the routing problem still in here.
> >    I still think the routing is common part,independent on=20
> >start ,end ,interim session message.
> >
> >Regards
> >Tony
> >----- Original Message -----
> >From: "STURA, Marco, VF-IT" <Marco.STURA@vodafone.com>
> >To: "Tony Zhang" <zhangtao_hw@huawei.com>; "Tolga Asveren"=20
> ><asveren@ulticom.com>; "Victor Fajardo" <vfajardo@tari.toshiba.com>
> >Cc: <dime@ietf.org>
> >Sent: Friday, July 21, 2006 3:18 PM
> >Subject: RE: [Dime] Summary of 3588bis Issues Status
> >
> >
> >Hi Tony,
> >
> >Server initiated requests can only be sent in the context of=20
> >existing sessions and routing must be done on the basis of=20
> >Destination-Host to ensure that the request hits the correct=20
> >client, so app id is not enough.
> >
> >The routing problem you are discussing has to do with how a=20
> >proxy can stay on the path during a session so that a server=20
> >can send a request, say ASR or RAR, to Destination-Host via P1=20
> >to C1. As also suggested by Tolga
> >
> >>I think it can be deducted to the generic problem of "How can=20
> >a proxy stay >on the path during a session", so I believe this=20
> >is the question to answer >(which we already discussed to some=20
> >extent in the context of strict-routing >draft review)
> >
> >So I think your issue can be discussed in that context, app id=20
> >0 for common messages I think is fine.
> >
> >Regards
> >Marco
> >
> >-----Original Message-----
> >From: Tony Zhang [mailto:zhangtao_hw@huawei.com]=20
> >Sent: venerd=8F=AB=C0 21 luglio 2006 5.43
> >To: STURA, Marco, VF-IT; Tolga Asveren; Victor Fajardo
> >Cc: dime@ietf.org
> >Subject: Re: [Dime] Summary of 3588bis Issues Status
> >
> >Hi Macro:
> >
> >[MSt] I think you assume P1 and P2 advertise supports for App=20
> >x/y and App z respectively but I would rather consider this=20
> >configuration an academic use case since typically you have=20
> >only one logical Proxy as a interconnect point for a given=20
> >realm in real deployments as a central point for policy=20
> >enforcement. However, let see whether a server initiated=20
> >message using Destination-Host and app id 0 based routing works.
> >
> >S1 sends ASR to C3 (C3 diameter identity in Destination-Host=20
> >AVP) app id 0. In the realm-based routing table R1 will=20
> >certainly find a match for realm A and app id 0, say for=20
> >instance the match is for P1. ASR is routed to P1, which=20
> >doesn't have C3 in its peer table and then answers with=20
> >DIAMETER_UNABLE_TO_DELIVER. R1 attempts then to deliver the=20
> >message via the alternative entry for Realm A, hence P2. P2=20
> >now deliver the message to C3. So, app-id 0 works at the end=20
> >if Destination-Host based routing is used and, actually, is to=20
> >be used for certain server initiated messages as also defined=20
> >in RFC 3588 in section 6.1.=20
> >
> >[Tony]Because the Application Id 0,not advertisement in=20
> >CER/CEA,so it means each realm will use the peet table select=20
> >next hop,almost peer table have many peer can select,also=20
> >include peer of receive the request. so it can happen loop=20
> >routing.(maybe can add one process avoid this,when routing=20
> >should input peer name of receive the request.).the other=20
> >problem,after retry many peer ,then we find correct route,it=20
> >consume long time,maybe the client already timer expire.also=20
> >application id use for effectively routing,but for above the=20
> >case ,it is not like this.
> >
> >sorry about i discuss this again,after 2004's dicuss,it is=20
> >likely many people confusion.if this time have same conlusion=20
> >maybe still have same problem.
> >
> >Thanks!
> >Tony
> >
> >----- Original Message -----=20
> >From: "STURA, Marco, VF-IT" <Marco.STURA@vodafone.com>
> >To: "Tolga Asveren" <asveren@ulticom.com>; "Victor Fajardo"=20
> ><vfajardo@tari.toshiba.com>
> >Cc: <dime@ietf.org>
> >Sent: Wednesday, July 19, 2006 5:11 PM
> >Subject: RE: [Dime] Summary of 3588bis Issues Status
> >
> >
> >See in line.
> >
> >Regards
> >Marco
> >
> >-----Original Message-----
> >From: Tolga Asveren [mailto:asveren@ulticom.com]=20
> >Sent: marted=8F=AB=C0 18 luglio 2006 18.52
> >To: STURA, Marco, VF-IT; Victor Fajardo
> >Cc: dime@ietf.org
> >Subject: RE: [Dime] Summary of 3588bis Issues Status
> >
> >[.. snip ..]
> >> I agree with your example above regarding destination-host. It is
> >> required in the case of ASR (and perhaps some other message) though =
I
> >> guess I was stating a case which is a little bit different than your
> >> example above. I was thinking of the following case:
> >>
> >> clients[1,2,3...x] <--- relay1 <---- relay2 <---- server
> >>
> >> in this case relay2 will not be able to route using=20
> >dest-host. This is
> >> where dest-realm and app id becomes important. In this case=20
> >app id of 0
> >> might not work as well ... or maybe I'm wrong.
> >>
> >> [MSt] In this case R1 would advertise it self as a relay (i.e.
> >> 0xffffffff) it won't advertise app id x or y or z. So, any app id
> >> would be routed to R1 by R2.
> >[TOLGA] Let me try to further refine the scenario:
> >              *****************************
> >              *  Realm A                  *
> >              *                           *
> >              *           +---------+     *
> >              *        +--+C1 App=3DX |     *
> >              * +----+ |  +---------+     *
> >         +----*-+ P1 +-+  +---------+     *
> >+---+  +-+--+ * +----+----+C2 App=3DY |     *
> >|S1 +--+ R1 | *           +---------+     *
> >+---+  +-+--+ *                           *
> >         |    * +----+                    *
> >         +----*-+ P2 +----+---------+     *
> >              * +----+    |C3 App=3DZ |     *
> >              *           +---------+     *
> >              *                           *
> >              *****************************
> >In this case, R1 wouldn't have enough knowledge to route the message
> >properly to the correct proxy just by looking to the App-Id in=20
> >the message
> >header, if App-Id is populated with "0".
> >
> >[MSt] I think you assume P1 and P2 advertise supports for App=20
> >x/y and App z respectively but I would rather consider this=20
> >configuration an academic use case since typically you have=20
> >only one logical Proxy as a interconnect point for a given=20
> >realm in real deployments as a central point for policy=20
> >enforcement. However, let see whether a server initiated=20
> >message using Destination-Host and app id 0 based routing works.
> >
> >S1 sends ASR to C3 (C3 diameter identity in Destination-Host=20
> >AVP) app id 0. In the realm-based routing table R1 will=20
> >certainly find a match for realm A and app id 0, say for=20
> >instance the match is for P1. ASR is routed to P1, which=20
> >doesn't have C3 in its peer table and then answers with=20
> >DIAMETER_UNABLE_TO_DELIVER. R1 attempts then to deliver the=20
> >message via the alternative entry for Realm A, hence P2. P2=20
> >now deliver the message to C3. So, app-id 0 works at the end=20
> >if Destination-Host based routing is used and, actually, is to=20
> >be used for certain server initiated messages as also defined=20
> >in RFC 3588 in section 6.1.=20
> >
> >
> >_______________________________________________
> >DiME mailing list
> >DiME@ietf.org
> >https://www1.ietf.org/mailman/listinfo/dime
> >
> >
>=20
>=20
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www1.ietf.org/mailman/listinfo/dime
>=20
>=20

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



From dime-bounces@ietf.org Fri Aug 04 12:27:05 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G92Vt-0006N0-KD; Fri, 04 Aug 2006 12:27:05 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G92Vq-00068T-Mj
	for dime@ietf.org; Fri, 04 Aug 2006 12:27:02 -0400
Received: from bw.ulticom.com ([208.255.120.38])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G92JO-0000Zj-EI
	for dime@ietf.org; Fri, 04 Aug 2006 12:14:13 -0400
Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP
	id 957E510D77; Fri,  4 Aug 2006 12:14:09 -0400 (EDT)
Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55])
	by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k74GE6o7024307;
	Fri, 4 Aug 2006 12:14:07 -0400 (EDT)
From: "Tolga Asveren" <asveren@ulticom.com>
To: "Yoshihiro Ohba" <yohba@tari.toshiba.com>,
	"Tony Zhang" <zhangtao_hw@huawei.com>
Subject: RE: [Dime] Summary of 3588bis Issues Status
Date: Fri, 4 Aug 2006 11:50:30 -0400
Message-ID: <GBEBKGPKHGPAOFCLBNAMCEMNEGAA.asveren@ulticom.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
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 V6.00.2800.1506
Importance: Normal
In-Reply-To: <20060804153151.GM5883@steelhead>
Received-SPF: none
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 249cd1efd3d5e0d09114abe826a41235
Cc: dime@ietf.org, Marco.STURA@vodafone.com
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

Please see comments for below.

   thanks,
   tolga

> -----Original Message-----
> From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com]
> Sent: Friday, August 04, 2006 11:32 AM
> To: Tony Zhang
> Cc: john.loughney@nokia.com; Marco.STURA@vodafone.com;
> asveren@ulticom.com; vfajardo@tari.toshiba.com; dime@ietf.org
> Subject: Re: [Dime] Summary of 3588bis Issues Status
>
>
> On Thu, Jul 27, 2006 at 08:02:12PM +0800, Tony Zhang wrote:
> > Hi John:
> > 	When I read proxy agent definition in RFC3588:
> >    Proxies that wish to limit resources MUST maintain session state.
> >    All proxies MUST maintain transaction state.
> >    Since enforcing policies requires an understanding of the service
> >    being provided, Proxies MUST only advertise the Diameter applications
> >    they support.
> >
> > Maybe almost the stateful proxy is more.
> >
> > If With respect to the App ID = 0 issue, we assumed that
> > proxies are stateless.
> > I think use app Id = 0,the routing for some environment is not
> effective.
> > Tolga already give one network environment.
>
> On the other hand, use of App ID = 0 does not completely solve the
> routing issue with stateful proxies, especially when there are
> multiple candidate next hop stateful proxies.  In this case whatever
> application id is used, it is not guaranteed that all messages that
> belong to the same session to go through the same stateful proxy.  I
> believe source routing is needed to solve the routing problem with
> stateful proxies.
[TOLGA]Although there may be cases where strict-routing may be useful (an
issue for another thread), this shouldn't be an argument in favor of AppId=0
IMHO. There are a variety of very real-life and useful configurations, which
work with AppId!=0 fine just following the routing procedures defined in
RFC3588, e.g. a load-balancer in front of backend servers for a specific
application, such a node advertises support only for a specific application,
or a policy enforcer again for a specific application. The point is, once an
intermediarey node wants to do something for a specific
application -regardless of whether it keeps state or not-, appId=0  creates
problems.

That being said, I understand the issue  about backward-compatibility, just
let's be aware that there are certain technical drawbacks associated with
AppId=0.
>
> Yoshihiro Ohba
>
>
>
> >
> > Thanks!
> > Tony.
> > -----Original Message-----
> > From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
> > Sent: Thursday, July 27, 2006 7:30 AM
> > To: zhangtao_hw@huawei.com; Marco.STURA@vodafone.com;
> asveren@ulticom.com; vfajardo@tari.toshiba.com
> > Cc: dime@ietf.org
> > Subject: RE: [Dime] Summary of 3588bis Issues Status
> >
> > Tony,
> >
> > During the initial work on Diameter, it was hoped that proxies would
> > be a rare occurance.  We assumed all proxies will be stateless.
> >
> > If someone needs stateful proxies, I'd like to understand what
> the problem
> > stateful proxies are trying to solve is, and why the current solution
> > is insufficient.  Wit respect to the App ID = 0 issue, we assumed that
> > proxies are stateless.
> >
> > John
> > >-----Original Message-----
> > >From: ext Tony Zhang [mailto:zhangtao_hw@huawei.com]
> > >Sent: 24 July, 2006 02:00
> > >To: STURA, Marco, VF-IT; Tolga Asveren; Victor Fajardo
> > >Cc: dime@ietf.org
> > >Subject: Re: [Dime] Summary of 3588bis Issues Status
> > >
> > >Hi Marco:
> > >
> > >    I also agree the generic problem of "How can a proxy stay
> > >>on the path during a session", but i think this problem is
> > >address the stateful proxy agent,acutal maybe still have
> > >stateless proxy agent.so the routing problem still in here.
> > >    I still think the routing is common part,independent on
> > >start ,end ,interim session message.
> > >
> > >Regards
> > >Tony
> > >----- Original Message -----
> > >From: "STURA, Marco, VF-IT" <Marco.STURA@vodafone.com>
> > >To: "Tony Zhang" <zhangtao_hw@huawei.com>; "Tolga Asveren"
> > ><asveren@ulticom.com>; "Victor Fajardo" <vfajardo@tari.toshiba.com>
> > >Cc: <dime@ietf.org>
> > >Sent: Friday, July 21, 2006 3:18 PM
> > >Subject: RE: [Dime] Summary of 3588bis Issues Status
> > >
> > >
> > >Hi Tony,
> > >
> > >Server initiated requests can only be sent in the context of
> > >existing sessions and routing must be done on the basis of
> > >Destination-Host to ensure that the request hits the correct
> > >client, so app id is not enough.
> > >
> > >The routing problem you are discussing has to do with how a
> > >proxy can stay on the path during a session so that a server
> > >can send a request, say ASR or RAR, to Destination-Host via P1
> > >to C1. As also suggested by Tolga
> > >
> > >>I think it can be deducted to the generic problem of "How can
> > >a proxy stay >on the path during a session", so I believe this
> > >is the question to answer >(which we already discussed to some
> > >extent in the context of strict-routing >draft review)
> > >
> > >So I think your issue can be discussed in that context, app id
> > >0 for common messages I think is fine.
> > >
> > >Regards
> > >Marco
> > >
> > >-----Original Message-----
> > >From: Tony Zhang [mailto:zhangtao_hw@huawei.com]
> > >Sent: venerd?_ 21 luglio 2006 5.43
> > >To: STURA, Marco, VF-IT; Tolga Asveren; Victor Fajardo
> > >Cc: dime@ietf.org
> > >Subject: Re: [Dime] Summary of 3588bis Issues Status
> > >
> > >Hi Macro:
> > >
> > >[MSt] I think you assume P1 and P2 advertise supports for App
> > >x/y and App z respectively but I would rather consider this
> > >configuration an academic use case since typically you have
> > >only one logical Proxy as a interconnect point for a given
> > >realm in real deployments as a central point for policy
> > >enforcement. However, let see whether a server initiated
> > >message using Destination-Host and app id 0 based routing works.
> > >
> > >S1 sends ASR to C3 (C3 diameter identity in Destination-Host
> > >AVP) app id 0. In the realm-based routing table R1 will
> > >certainly find a match for realm A and app id 0, say for
> > >instance the match is for P1. ASR is routed to P1, which
> > >doesn't have C3 in its peer table and then answers with
> > >DIAMETER_UNABLE_TO_DELIVER. R1 attempts then to deliver the
> > >message via the alternative entry for Realm A, hence P2. P2
> > >now deliver the message to C3. So, app-id 0 works at the end
> > >if Destination-Host based routing is used and, actually, is to
> > >be used for certain server initiated messages as also defined
> > >in RFC 3588 in section 6.1.
> > >
> > >[Tony]Because the Application Id 0,not advertisement in
> > >CER/CEA,so it means each realm will use the peet table select
> > >next hop,almost peer table have many peer can select,also
> > >include peer of receive the request. so it can happen loop
> > >routing.(maybe can add one process avoid this,when routing
> > >should input peer name of receive the request.).the other
> > >problem,after retry many peer ,then we find correct route,it
> > >consume long time,maybe the client already timer expire.also
> > >application id use for effectively routing,but for above the
> > >case ,it is not like this.
> > >
> > >sorry about i discuss this again,after 2004's dicuss,it is
> > >likely many people confusion.if this time have same conlusion
> > >maybe still have same problem.
> > >
> > >Thanks!
> > >Tony
> > >
> > >----- Original Message -----
> > >From: "STURA, Marco, VF-IT" <Marco.STURA@vodafone.com>
> > >To: "Tolga Asveren" <asveren@ulticom.com>; "Victor Fajardo"
> > ><vfajardo@tari.toshiba.com>
> > >Cc: <dime@ietf.org>
> > >Sent: Wednesday, July 19, 2006 5:11 PM
> > >Subject: RE: [Dime] Summary of 3588bis Issues Status
> > >
> > >
> > >See in line.
> > >
> > >Regards
> > >Marco
> > >
> > >-----Original Message-----
> > >From: Tolga Asveren [mailto:asveren@ulticom.com]
> > >Sent: marted?_ 18 luglio 2006 18.52
> > >To: STURA, Marco, VF-IT; Victor Fajardo
> > >Cc: dime@ietf.org
> > >Subject: RE: [Dime] Summary of 3588bis Issues Status
> > >
> > >[.. snip ..]
> > >> I agree with your example above regarding destination-host. It is
> > >> required in the case of ASR (and perhaps some other message) though I
> > >> guess I was stating a case which is a little bit different than your
> > >> example above. I was thinking of the following case:
> > >>
> > >> clients[1,2,3...x] <--- relay1 <---- relay2 <---- server
> > >>
> > >> in this case relay2 will not be able to route using
> > >dest-host. This is
> > >> where dest-realm and app id becomes important. In this case
> > >app id of 0
> > >> might not work as well ... or maybe I'm wrong.
> > >>
> > >> [MSt] In this case R1 would advertise it self as a relay (i.e.
> > >> 0xffffffff) it won't advertise app id x or y or z. So, any app id
> > >> would be routed to R1 by R2.
> > >[TOLGA] Let me try to further refine the scenario:
> > >              *****************************
> > >              *  Realm A                  *
> > >              *                           *
> > >              *           +---------+     *
> > >              *        +--+C1 App=X |     *
> > >              * +----+ |  +---------+     *
> > >         +----*-+ P1 +-+  +---------+     *
> > >+---+  +-+--+ * +----+----+C2 App=Y |     *
> > >|S1 +--+ R1 | *           +---------+     *
> > >+---+  +-+--+ *                           *
> > >         |    * +----+                    *
> > >         +----*-+ P2 +----+---------+     *
> > >              * +----+    |C3 App=Z |     *
> > >              *           +---------+     *
> > >              *                           *
> > >              *****************************
> > >In this case, R1 wouldn't have enough knowledge to route the message
> > >properly to the correct proxy just by looking to the App-Id in
> > >the message
> > >header, if App-Id is populated with "0".
> > >
> > >[MSt] I think you assume P1 and P2 advertise supports for App
> > >x/y and App z respectively but I would rather consider this
> > >configuration an academic use case since typically you have
> > >only one logical Proxy as a interconnect point for a given
> > >realm in real deployments as a central point for policy
> > >enforcement. However, let see whether a server initiated
> > >message using Destination-Host and app id 0 based routing works.
> > >
> > >S1 sends ASR to C3 (C3 diameter identity in Destination-Host
> > >AVP) app id 0. In the realm-based routing table R1 will
> > >certainly find a match for realm A and app id 0, say for
> > >instance the match is for P1. ASR is routed to P1, which
> > >doesn't have C3 in its peer table and then answers with
> > >DIAMETER_UNABLE_TO_DELIVER. R1 attempts then to deliver the
> > >message via the alternative entry for Realm A, hence P2. P2
> > >now deliver the message to C3. So, app-id 0 works at the end
> > >if Destination-Host based routing is used and, actually, is to
> > >be used for certain server initiated messages as also defined
> > >in RFC 3588 in section 6.1.
> > >
> > >
> > >_______________________________________________
> > >DiME mailing list
> > >DiME@ietf.org
> > >https://www1.ietf.org/mailman/listinfo/dime
> > >
> > >
> >
> >
> >
> > _______________________________________________
> > DiME mailing list
> > DiME@ietf.org
> > https://www1.ietf.org/mailman/listinfo/dime
> >
> >


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



From dime-bounces@ietf.org Fri Aug 04 13:33:25 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G93Y4-0006PM-QV; Fri, 04 Aug 2006 13:33:24 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G93Y3-0006PE-VX
	for dime@ietf.org; Fri, 04 Aug 2006 13:33:23 -0400
Received: from imx11.toshiba.co.jp ([61.202.160.20])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G93Y0-0006Hy-CF
	for dime@ietf.org; Fri, 04 Aug 2006 13:33:23 -0400
Received: from wall11.toshiba.co.jp (wall11 [133.199.90.149])
	by imx11.toshiba.co.jp  with ESMTP id k74HXFVS002461;
	Sat, 5 Aug 2006 02:33:15 +0900 (JST)
Received: (from root@localhost) by wall11.toshiba.co.jp  id k74HXFIR018203;
	Sat, 5 Aug 2006 02:33:15 +0900 (JST)
Received: from ovp11.toshiba.co.jp [133.199.90.148] 
	by wall11.toshiba.co.jp with SMTP id CAA18199;
	Sat, 5 Aug 2006 02:33:14 +0900
Received: from mx2.toshiba.co.jp (localhost [127.0.0.1])
	by ovp11.toshiba.co.jp  with ESMTP id k74HXEgq012074;
	Sat, 5 Aug 2006 02:33:14 +0900 (JST)
Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k74HXDLJ021056;
	Sat, 5 Aug 2006 02:33:13 +0900 (JST)
Received: from steelhead ([172.30.24.104])
	by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built
	Apr 28
	2004)) with ESMTPSA id <0J3H006Z5I38QIK0@mail.po.toshiba.co.jp>; Sat,
	05 Aug 2006 02:33:13 +0900 (JST)
Received: from ohba by steelhead with local (Exim 4.62)
	(envelope-from <yohba@tari.toshiba.com>)	id 1G93XY-0003lK-M2; Fri,
	04 Aug 2006 10:32:52 -0700
Date: Fri, 04 Aug 2006 13:32:52 -0400
From: Yoshihiro Ohba <yohba@tari.toshiba.com>
Subject: Re: [Dime] Summary of 3588bis Issues Status
In-reply-to: <GBEBKGPKHGPAOFCLBNAMCEMNEGAA.asveren@ulticom.com>
To: Tolga Asveren <asveren@ulticom.com>
Message-id: <20060804173252.GQ5883@steelhead>
MIME-version: 1.0
Content-type: text/plain; charset=iso-2022-jp
Content-disposition: inline
References: <20060804153151.GM5883@steelhead>
	<GBEBKGPKHGPAOFCLBNAMCEMNEGAA.asveren@ulticom.com>
User-Agent: Mutt/1.5.11+cvs20060403
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad
Cc: dime@ietf.org, Marco.STURA@vodafone.com
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

On Fri, Aug 04, 2006 at 11:50:30AM -0400, Tolga Asveren wrote:

(snip)

> 
> That being said, I understand the issue  about backward-compatibility, just
> let's be aware that there are certain technical drawbacks associated with
> AppId=0.

I agree.  I guess we are in agreement that maintaining backward
compability is more important than optimization like load-balancing.

Yoshihiro Ohba

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



From dime-bounces@ietf.org Fri Aug 04 20:22:35 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G99w1-0002nV-6W; Fri, 04 Aug 2006 20:22:33 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G99vz-0002nG-5s
	for dime@ietf.org; Fri, 04 Aug 2006 20:22:31 -0400
Received: from usaga01-in.huawei.com ([12.129.211.51])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G99vx-0005r9-Tj
	for dime@ietf.org; Fri, 04 Aug 2006 20:22:31 -0400
Received: from huawei.com (usaga01-in [172.18.4.6])
	by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0J3I001OJ0W8OP@usaga01-in.huawei.com> for
	dime@ietf.org; Fri, 04 Aug 2006 17:19:20 -0700 (PDT)
Received: from Nakhjiri73701
	(c-24-17-254-79.hsd1.mn.comcast.net [24.17.254.79]) by
	usaga01-in.huawei.com
	(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
	with ESMTPA id <0J3I00NAS0W44X@usaga01-in.huawei.com> for dime@ietf.org;
	Fri, 04 Aug 2006 17:19:20 -0700 (PDT)
Date: Fri, 04 Aug 2006 17:22:23 -0700
From: Madjid Nakhjiri <mnakhjiri@huawei.com>
Subject: RE: [Dime] IETF#66 Meeting Minutes
In-reply-to: <44BE47E7.5040900@gmx.net>
To: 'Hannes Tschofenig' <Hannes.Tschofenig@gmx.net>, dime@ietf.org
Message-id: <003a01c6b825$38fb4590$02fda8c0@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-index: AcarQ+wqZEvtnxl6QRe5MCdk8ekY5AM4S50w
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab
Cc: 
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

Was this minutes or 10-minutes:-)

-----Original Message-----
From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] 
Sent: Wednesday, July 19, 2006 7:56 AM
To: dime@ietf.org
Subject: [Dime] IETF#66 Meeting Minutes

Hi all,

please take a look at the meeting minutes:
http://www3.ietf.org/proceedings/06jul/minutes/dime.txt

Ciao
Hannes

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



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



From dime-bounces@ietf.org Sat Aug 05 08:29:03 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G9LH4-0000yJ-JG; Sat, 05 Aug 2006 08:29:02 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G9LH2-0000y6-NB
	for dime@ietf.org; Sat, 05 Aug 2006 08:29:00 -0400
Received: from mail.gmx.net ([213.165.64.20])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G9LH1-0006g4-9S
	for dime@ietf.org; Sat, 05 Aug 2006 08:29:00 -0400
Received: (qmail invoked by alias); 05 Aug 2006 12:22:17 -0000
Received: from p54987B16.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.123.22]
	by mail.gmx.net (mp035) with SMTP; 05 Aug 2006 14:22:17 +0200
X-Authenticated: #29516787
Message-ID: <44D48D70.2090103@gmx.net>
Date: Sat, 05 Aug 2006 14:22:08 +0200
From: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Madjid Nakhjiri <mnakhjiri@huawei.com>
Subject: Re: [Dime] IETF#66 Meeting Minutes
References: <003a01c6b825$38fb4590$02fda8c0@china.huawei.com>
In-Reply-To: <003a01c6b825$38fb4590$02fda8c0@china.huawei.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

I agree that the meeting minutes are somewhat brief this time.
We will do better with the next IETF meeting...

Ciao
Hannes

Madjid Nakhjiri wrote:
> Was this minutes or 10-minutes:-)
> 
> -----Original Message-----
> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] 
> Sent: Wednesday, July 19, 2006 7:56 AM
> To: dime@ietf.org
> Subject: [Dime] IETF#66 Meeting Minutes
> 
> Hi all,
> 
> please take a look at the meeting minutes:
> http://www3.ietf.org/proceedings/06jul/minutes/dime.txt
> 
> Ciao
> Hannes
> 
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www1.ietf.org/mailman/listinfo/dime
> 
> 
> 


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



From dime-bounces@ietf.org Sun Aug 06 23:57:09 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1G9wEk-0006kf-55; Sun, 06 Aug 2006 23:57:06 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1G9wEi-0006ka-Nv
	for dime@ietf.org; Sun, 06 Aug 2006 23:57:04 -0400
Received: from [2001:418:1403:0:212:17ff:fe52:7811]
	(helo=toshi17.tari.toshiba.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G9wEg-00014x-Ct
	for dime@ietf.org; Sun, 06 Aug 2006 23:57:04 -0400
Received: from [127.0.0.1] (mgw.toshibaamericaresearch.com [165.254.55.12])
	by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id
	k773tsYp046212; Sun, 6 Aug 2006 23:55:54 -0400 (EDT)
	(envelope-from vfajardo@tari.toshiba.com)
Message-ID: <44D40C4E.50008@tari.toshiba.com>
Date: Fri, 04 Aug 2006 23:11:10 -0400
From: Victor Fajardo <vfajardo@tari.toshiba.com>
User-Agent: Thunderbird 1.5.0.5 (X11/20060719)
MIME-Version: 1.0
To: Madjid Nakhjiri <mnakhjiri@huawei.com>
Subject: Re: [Dime] IETF#66 Meeting Minutes
References: <003a01c6b825$38fb4590$02fda8c0@china.huawei.com>
In-Reply-To: <003a01c6b825$38fb4590$02fda8c0@china.huawei.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.6 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

Hi Madjid,

I apologize, I will try to recoupe as much info from the last meetings 
as I can.

regards,
victor
> Was this minutes or 10-minutes:-)
>
> -----Original Message-----
> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] 
> Sent: Wednesday, July 19, 2006 7:56 AM
> To: dime@ietf.org
> Subject: [Dime] IETF#66 Meeting Minutes
>
> Hi all,
>
> please take a look at the meeting minutes:
> http://www3.ietf.org/proceedings/06jul/minutes/dime.txt
>
> Ciao
> Hannes
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www1.ietf.org/mailman/listinfo/dime
>
>
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www1.ietf.org/mailman/listinfo/dime
>
>
>   


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



From dime-bounces@ietf.org Mon Aug 07 05:10:58 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GA18S-0005cR-AP; Mon, 07 Aug 2006 05:10:56 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GA18Q-0005bo-NT
	for dime@ietf.org; Mon, 07 Aug 2006 05:10:54 -0400
Received: from py-out-1112.google.com ([64.233.166.177])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GA17k-0007XP-BX
	for dime@ietf.org; Mon, 07 Aug 2006 05:10:14 -0400
Received: by py-out-1112.google.com with SMTP id m51so770599pye
	for <dime@ietf.org>; Mon, 07 Aug 2006 02:10:10 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references;
	b=U1EDNmgu3/dCnFiNiGMszHMiQSXUJyO3LuvX6NBgcu4XYdaHquMp7P/XIGRRLKzaMA6X4+Boug59HbE1ikjlVx3pPgNuhEgDxoSQcL8CyO9X673sXgkcczrUige5dCE1VNZq5PqbIfGeUxxd9XewFUCwPwsWhRA0KMeIVIcESB0=
Received: by 10.35.61.2 with SMTP id o2mr11797689pyk;
	Mon, 07 Aug 2006 02:10:10 -0700 (PDT)
Received: by 10.35.82.12 with HTTP; Mon, 7 Aug 2006 02:10:10 -0700 (PDT)
Message-ID: <ce72e8460608070210j4662855ctc9144e8d9ea0e4b7@mail.gmail.com>
Date: Mon, 7 Aug 2006 14:40:10 +0530
From: "naveen sarma" <naveen.sarma@gmail.com>
To: rajithr@huawei.com
In-Reply-To: <000e01c6b0a1$5c5d7610$a905120a@china.huawei.com>
MIME-Version: 1.0
References: <Acawg3BsxXlMtsEEQ0Gj93BxJw4l/wAHdx2A>
	<000e01c6b0a1$5c5d7610$a905120a@china.huawei.com>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: d9238570526f12788af3d33c67f37625
Cc: aaa-wg@merit.edu, dime@ietf.org
Subject: [Dime] Re: FW: [AAA-WG]: Fwd: Failover processing
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0358432011=="
Errors-To: dime-bounces@ietf.org

--===============0358432011==
Content-Type: multipart/alternative; 
	boundary="----=_Part_45202_25125666.1154941810302"

------=_Part_45202_25125666.1154941810302
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi Rajith,
    Can you please send your answer to my question.  I haven't received any
reply.  I think there is some problem.

Thanks & Regards,
Naveen

On 7/26/06, Rajith R <rajithr@huawei.com> wrote:
>
>  Pls ignore the previous post.
>
>
>
>
>
>
> ************************************************************************************
>
> This e-mail and attachments contain confidential information from HUAWEI,
> which is intended only for the person or entity whose address is listed
> above. Any use of the information contained herein in any way (including,
> but not limited to, total or partial disclosure, reproduction, or
> dissemination) by persons other than the intended recipient's) is
> prohibited. If you receive this e-mail in error, please notify the sender by
> phone or email immediately and delete it!
>   ------------------------------
>
> *From:* owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu] *On Behalf
> Of *naveen sarma
> *Sent:* Wednesday, July 26, 2006 12:46 PM
> *To:* aaa-wg@merit.edu
> *Subject:* [AAA-WG]: Fwd: Failover processing
>
>
>
>
>
> ---------- Forwarded message ----------
> From: *naveen sarma* <naveen.sarma@gmail.com>
> Date: Jul 26, 2006 12:35 PM
> Subject: Failover processing
> To: dime-request@ietf.org
>
> Hi,
>
> In the case of failover processing, do we need to change the destination
> host before forwarding to the new alternate peer?
>
> Suppose consider the following scenario:
>
> P0 is the originating host, to which P1 and P2 are peers (direct
> connection).
>
> P0 is supporting applications 1, 2, 3
> P1 is supporting applications 1, 2
> P2 is supporting applications 2, 3
>
> After some time if P1 is down.  Cosider that in the pending message queue
> of P1, there is a message M1 with application id 2 and the destination host
> as P1.  As part of the failover, we will send the request message M1 to P2.
>
> In this case do we need to change the destination host inside the request
> message to P2, which was actually having the destination host as P1?
>
> Can anyone explain the responsibility when the diameter node is acting as
> an intermidate also?
>
> --
> Yours
>
> Naveen.
>
>
>
> --
> Yours
> Naveen.
>



-- 
Yours
Naveen.

------=_Part_45202_25125666.1154941810302
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi Rajith,<br>&nbsp;&nbsp;&nbsp; Can you please send your answer to my question.&nbsp; I haven't received any reply.&nbsp; I think there is some problem.<br><br>Thanks &amp; Regards,<br>Naveen<br><br><div><span class="gmail_quote">On 7/26/06, <b class="gmail_sendername">
Rajith R</b> &lt;<a href="mailto:rajithr@huawei.com">rajithr@huawei.com</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>









<div link="blue" vlink="blue" lang="EN-US">

<div>

<p><font color="navy" face="Arial" size="2"><span style="font-size: 10pt; font-family: Arial; color: navy;">Pls ignore the previous post.</span></font></p>

<p><font color="navy" face="Arial" size="2"><span style="font-size: 10pt; font-family: Arial; color: navy;">&nbsp;</span></font></p>

<p><font color="navy" face="Arial" size="2"><span style="font-size: 10pt; font-family: Arial; color: navy;">&nbsp;</span></font></p>

<div>

<p><font color="black" face="Arial" size="1"><span style="font-size: 8pt; font-family: Arial; color: black;">************************************************************************************</span></font></p>

<p><font color="black" face="Arial" size="1"><span style="font-size: 8pt; font-family: Arial; color: black;">This e-mail and attachments contain
confidential information from HUAWEI, which is intended only for the person or
entity whose address is listed above. Any use of the information contained
herein in any way (including, but not limited to, total or partial disclosure,
reproduction, or dissemination) by persons other than the intended recipient's)
is prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!</span></font></p>

</div>

<div>

<div style="text-align: center;" align="center"><font face="Times New Roman" size="3"><span style="font-size: 12pt;">

<hr align="center" size="2" width="100%">

</span></font></div>

<p><b><font face="Tahoma" size="2"><span style="font-size: 10pt; font-family: Tahoma; font-weight: bold;">From:</span></font></b><font face="Tahoma" size="2"><span style="font-size: 10pt; font-family: Tahoma;"> <a href="mailto:owner-aaa-wg@merit.edu" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
owner-aaa-wg@merit.edu</a> [mailto:<a href="mailto:owner-aaa-wg@merit.edu" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">owner-aaa-wg@merit.edu</a>] <b><span style="font-weight: bold;">On
Behalf Of </span></b>naveen sarma<br>
<b><span style="font-weight: bold;">Sent:</span></b> Wednesday, July 26, 2006
12:46 PM<br>
<b><span style="font-weight: bold;">To:</span></b> <a href="mailto:aaa-wg@merit.edu" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">aaa-wg@merit.edu</a><br>
<b><span style="font-weight: bold;">Subject:</span></b> [AAA-WG]: Fwd: Failover
processing</span></font></p>

</div>

<p><font face="Times New Roman" size="3"><span style="font-size: 12pt;">&nbsp;</span></font></p>

<p style="margin-bottom: 12pt;"><font face="Times New Roman" size="3"><span style="font-size: 12pt;"><br>
<br>
---------- Forwarded message ----------<br>
<span>From: <b><span style="font-weight: bold;">naveen sarma</span></b>
&lt;<a href="mailto:naveen.sarma@gmail.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">naveen.sarma@gmail.com</a>&gt;</span><br>
<span>Date: Jul 26, 2006 12:35 PM </span><br>
<span>Subject: Failover processing</span><br>
<span>To: <a href="mailto:dime-request@ietf.org" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">dime-request@ietf.org</a></span></span></font></p>

<div>

<p><font face="Times New Roman" size="3"><span style="font-size: 12pt;">Hi,<br>
<br>
In the case of failover processing, do we need to change the destination host
before forwarding to the new alternate peer? <br>
<br>
Suppose consider the following scenario:<br>
<br>
P0 is the originating host, to which P1 and P2 are peers (direct connection). <br>
<br>
P0 is supporting applications 1, 2, 3<br>
P1 is supporting applications 1, 2<br>
P2 is supporting applications 2, 3<br>
<br>
After some time if P1 is down.&nbsp; Cosider that in the pending message queue
of P1, there is a message M1 with application id 2 and the destination host as
P1.&nbsp; As part of the failover, we will send the request message M1 to P2. <br>
<br>
In this case do we need to change the destination host inside the request
message to P2, which was actually having the destination host as P1?<br>
<br>
Can anyone explain the responsibility when the diameter node is acting as an
intermidate also? <br>
<br>
-- <br>
Yours</span></font></p>

</div>

<div>

<p><span><font face="Times New Roman" size="3"><span style="font-size: 12pt;">Naveen. </span></font></span></p>

</div>

<p><font face="Times New Roman" size="3"><span style="font-size: 12pt;"><br clear="all">
<br>
-- <br>
Yours<br>
Naveen. </span></font></p>

</div>

</div>



</div></blockquote></div><br><br clear="all"><br>-- <br>Yours<br>Naveen.

------=_Part_45202_25125666.1154941810302--


--===============0358432011==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0358432011==--




From dime-bounces@ietf.org Mon Aug 07 05:10:59 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GA18V-0005eJ-NE; Mon, 07 Aug 2006 05:10:59 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GA18U-0005d4-BU
	for dime@ietf.org; Mon, 07 Aug 2006 05:10:58 -0400
Received: from ug-out-1314.google.com ([66.249.92.169])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GA16E-0007AM-5t
	for dime@ietf.org; Mon, 07 Aug 2006 05:08:39 -0400
Received: by ug-out-1314.google.com with SMTP id m2so12209ugc
	for <dime@ietf.org>; Mon, 07 Aug 2006 02:08:36 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:to:subject:mime-version:content-type;
	b=R1+IrZL7ZJzKK1oWJIn+rSLbQ2eAlzn0nkFajYtbt5NLb9FTzWRgEJHoC5uCj6bQ4OLbd771akGnfycwdzCBP4taYfAr7xL+VNFCsk/5KluX8jOmMd6IuIYYNGBdjKSZ98tXlqgCZEWwWuekhSFD9pGRHx29/DJszPKO28K7Sjg=
Received: by 10.66.249.11 with SMTP id w11mr7778820ugh;
	Mon, 07 Aug 2006 02:08:36 -0700 (PDT)
Received: by 10.67.19.18 with HTTP; Mon, 7 Aug 2006 02:08:36 -0700 (PDT)
Message-ID: <5be720c40608070208s1b933433of8973b463d6d9eb7@mail.gmail.com>
Date: Mon, 7 Aug 2006 14:38:36 +0530
From: "Monal Sengar" <monal.sengar@gmail.com>
To: dime@ietf.org, aaa-wg@merit.edu
MIME-Version: 1.0
X-Spam-Score: 0.2 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Cc: 
Subject: [Dime] Session Management APIs
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1144372367=="
Errors-To: dime-bounces@ietf.org

--===============1144372367==
Content-Type: multipart/alternative; 
	boundary="----=_Part_71579_38732.1154941716902"

------=_Part_71579_38732.1154941716902
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi ,

As per draft draft-ietf-aaa-diameter-api-04 , there are some APIs for
Session Management e.g.
1.AAAStartSession( )
2.AAAEndSession( )
3.AAAAbortSession ( ) e.t.c

But in case , we are implementing the Session state Machine (Sec 8 RFC 3588)
in application and not in Diameter Base Protocol (DBP) then do we need to
implement these API's in stack.


Thanks and Regards
Monal

------=_Part_71579_38732.1154941716902
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hi ,<br><br>As per draft draft-ietf-aaa-diameter-api-04 , there are some APIs for Session Management e.g.<br>1.AAAStartSession( )<br>2.AAAEndSession( )<br>3.AAAAbortSession ( ) e.t.c<br><br>But in case , we are implementing the Session state Machine (Sec 8 RFC 3588) in application and not in Diameter Base Protocol (DBP) then do we need to implement these API's in stack.
<br><br><br>Thanks and Regards<br>Monal<br>

------=_Part_71579_38732.1154941716902--


--===============1144372367==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============1144372367==--




From dime-bounces@ietf.org Mon Aug 07 05:23:03 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GA1KA-0003sR-Pd; Mon, 07 Aug 2006 05:23:02 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GA1K9-0003sM-4S
	for dime@ietf.org; Mon, 07 Aug 2006 05:23:01 -0400
Received: from szxga02-in.huawei.com ([61.144.161.54])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GA1K7-0000UY-Gd
	for dime@ietf.org; Mon, 07 Aug 2006 05:23:01 -0400
Received: from huawei.com (szxga02-in [172.24.2.6])
	by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0J3M000PPG3X3K@szxga02-in.huawei.com> for
	dime@ietf.org; Mon, 07 Aug 2006 17:38:21 +0800 (CST)
Received: from huawei.com ([172.24.1.18])
	by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0J3M0041WG3WY7@szxga02-in.huawei.com> for
	dime@ietf.org; Mon, 07 Aug 2006 17:38:20 +0800 (CST)
Received: from s70950 ([10.70.145.95])
	by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTPA id <0J3M008PTFG98O@szxml03-in.huawei.com> for
	dime@ietf.org; Mon, 07 Aug 2006 17:24:18 +0800 (CST)
Date: Mon, 07 Aug 2006 17:20:48 +0800
From: santhosh <santhoshkk@huawei.com>
In-reply-to: <5be720c40608070208s1b933433of8973b463d6d9eb7@mail.gmail.com>
To: dime@ietf.org, aaa-wg@merit.edu
Message-id: <003201c6ba02$c88e0790$5f91460a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Mailer: Microsoft Outlook, Build 10.0.3416
Importance: Normal
X-Priority: 3 (Normal)
X-MSMail-priority: Normal
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172
Cc: 
Subject: [Dime] RE: [AAA-WG]: Session Management APIs
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1464004993=="
Errors-To: dime-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1464004993==
Content-type: multipart/alternative;
	boundary="Boundary_(ID_MzBXFPIUdFbPFznUkAibQA)"

This is a multi-part message in MIME format.

--Boundary_(ID_MzBXFPIUdFbPFznUkAibQA)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

If Application is implementing the session state machine the Stack does
not need to provide this API..

 

-----Original Message-----
From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu] On Behalf
Of Monal Sengar
Sent: Monday, August 07, 2006 5:09 PM
To: dime@ietf.org; aaa-wg@merit.edu
Subject: [AAA-WG]: Session Management APIs

 

Hi ,

As per draft draft-ietf-aaa-diameter-api-04 , there are some APIs for
Session Management e.g.
1.AAAStartSession( )
2.AAAEndSession( )
3.AAAAbortSession ( ) e.t.c

But in case , we are implementing the Session state Machine (Sec 8 RFC
3588) in application and not in Diameter Base Protocol (DBP) then do we
need to implement these API's in stack. 


Thanks and Regards
Monal


--Boundary_(ID_MzBXFPIUdFbPFznUkAibQA)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT

<html>

<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">


<meta name=Generator content="Microsoft Word 10 (filtered)">

<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:"\@SimSun";
	panose-1:2 1 6 0 3 1 1 1 1 1;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=EN-US link=blue vlink=purple>

<div class=Section1>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>If Application is implementing the session
state machine the Stack does not need to provide this API&#8230;.</span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=MsoNormal style='margin-left:.5in'><font size=2 face=Tahoma><span
style='font-size:10.0pt;font-family:Tahoma'>-----Original Message-----<br>
<b><span style='font-weight:bold'>From:</span></b> owner-aaa-wg@merit.edu
[mailto:owner-aaa-wg@merit.edu] <b><span style='font-weight:bold'>On Behalf Of </span></b>Monal
Sengar<br>
<b><span style='font-weight:bold'>Sent:</span></b> </span></font><font size=2 face=Tahoma><span style='font-size:10.0pt;font-family:Tahoma'>Monday, August
 07, 2006</span></font><font size=2 face=Tahoma><span style='font-size:10.0pt;
font-family:Tahoma'> </span></font><font size=2 face=Tahoma><span
 style='font-size:10.0pt;font-family:Tahoma'>5:09 PM</span></font><font size=2
face=Tahoma><span style='font-size:10.0pt;font-family:Tahoma'><br>
<b><span style='font-weight:bold'>To:</span></b> dime@ietf.org;
aaa-wg@merit.edu<br>
<b><span style='font-weight:bold'>Subject:</span></b> [AAA-WG]: Session
Management APIs</span></font></p>

<p class=MsoNormal style='margin-left:.5in'><font size=3 face="Times New Roman"><span
style='font-size:12.0pt'>&nbsp;</span></font></p>

<p class=MsoNormal style='margin-left:.5in'><font size=3 face="Times New Roman"><span
style='font-size:12.0pt'>Hi ,<br>
<br>
As per draft draft-ietf-aaa-diameter-api-04 , there are some APIs for Session
Management e.g.<br>
1.AAAStartSession( )<br>
2.AAAEndSession( )<br>
3.AAAAbortSession ( ) e.t.c<br>
<br>
But in case , we are implementing the Session state Machine (Sec 8 RFC 3588) in
application and not in Diameter Base Protocol (DBP) then do we need to
implement these API's in stack. <br>
<br>
<br>
Thanks and Regards<br>
Monal</span></font></p>

</div>

</body>

</html>

--Boundary_(ID_MzBXFPIUdFbPFznUkAibQA)--


--===============1464004993==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============1464004993==--




From dime-bounces@ietf.org Mon Aug 07 05:33:21 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GA1U8-0000PI-S1; Mon, 07 Aug 2006 05:33:20 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GA1U7-0000PC-Li
	for dime@ietf.org; Mon, 07 Aug 2006 05:33:19 -0400
Received: from szxga03-in.huawei.com ([61.144.161.55])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GA1U6-0001m5-2e
	for dime@ietf.org; Mon, 07 Aug 2006 05:33:19 -0400
Received: from huawei.com (szxga03-in [172.24.2.9])
	by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0J3M00JYTG59XD@szxga03-in.huawei.com> for
	dime@ietf.org; Mon, 07 Aug 2006 17:39:09 +0800 (CST)
Received: from huawei.com ([172.24.1.18])
	by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0J3M00MPIG58NE@szxga03-in.huawei.com> for
	dime@ietf.org; Mon, 07 Aug 2006 17:39:09 +0800 (CST)
Received: from huawei1515 ([10.18.5.169])
	by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTPA id <0J3M00732FTRZU@szxml03-in.huawei.com> for
	dime@ietf.org; Mon, 07 Aug 2006 17:32:20 +0800 (CST)
Date: Mon, 07 Aug 2006 14:58:54 +0530
From: Rajith R <rajithr@huawei.com>
In-reply-to: <ce72e8460608070210j4662855ctc9144e8d9ea0e4b7@mail.gmail.com>
To: 'naveen sarma' <naveen.sarma@gmail.com>
Message-id: <001801c6ba03$e79ca9b0$a905120a@china.huawei.com>
Organization: huawei
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-Mailer: Microsoft Office Outlook 11
Thread-index: Aca6AVRgm6ktOBt2Qtm0UzcNWTAaOQAAjJHg
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cd000eda3d43531d5b01b5d305410e3c
Cc: dime@ietf.org
Subject: [Dime] RE: FW: [AAA-WG]: Fwd: Failover processing
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: rajithr@huawei.com
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0206861181=="
Errors-To: dime-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0206861181==
Content-type: multipart/alternative;
	boundary="Boundary_(ID_G8He2dW8Xm3K+Yf4Cj0HHg)"

This is a multi-part message in MIME format.

--Boundary_(ID_G8He2dW8Xm3K+Yf4Cj0HHg)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

Hi Naveen

            

            I had only posted your query to the apt WG viz. DiME, I hadn't
replied.

            Anyways, in my opinion, Diameter messages forwarded using
Destination Host should not subjected to failover.

 

Rajith

****************************************************************************
********

This e-mail and attachments contain confidential information from HUAWEI,
which is intended only for the person or entity whose address is listed
above. Any use of the information contained herein in any way (including,
but not limited to, total or partial disclosure, reproduction, or
dissemination) by persons other than the intended recipient's) is
prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!

  _____  

From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu] On Behalf Of
naveen sarma
Sent: Monday, August 07, 2006 2:40 PM
To: rajithr@huawei.com
Cc: aaa-wg@merit.edu; dime@ietf.org
Subject: Re: FW: [AAA-WG]: Fwd: Failover processing

 

Hi Rajith,
    Can you please send your answer to my question.  I haven't received any
reply.  I think there is some problem.

Thanks & Regards,
Naveen

On 7/26/06, Rajith R <rajithr@huawei.com> wrote:

Pls ignore the previous post.

 

 

****************************************************************************
********

This e-mail and attachments contain confidential information from HUAWEI,
which is intended only for the person or entity whose address is listed
above. Any use of the information contained herein in any way (including,
but not limited to, total or partial disclosure, reproduction, or
dissemination) by persons other than the intended recipient's) is
prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!

  _____  

From: owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu] On Behalf Of
naveen sarma
Sent: Wednesday, July 26, 2006 12:46 PM
To: aaa-wg@merit.edu
Subject: [AAA-WG]: Fwd: Failover processing

 



---------- Forwarded message ----------
From: naveen sarma <naveen.sarma@gmail.com>
Date: Jul 26, 2006 12:35 PM 
Subject: Failover processing
To: dime-request@ietf.org

Hi,

In the case of failover processing, do we need to change the destination
host before forwarding to the new alternate peer? 

Suppose consider the following scenario:

P0 is the originating host, to which P1 and P2 are peers (direct
connection). 

P0 is supporting applications 1, 2, 3
P1 is supporting applications 1, 2
P2 is supporting applications 2, 3

After some time if P1 is down.  Cosider that in the pending message queue of
P1, there is a message M1 with application id 2 and the destination host as
P1.  As part of the failover, we will send the request message M1 to P2. 

In this case do we need to change the destination host inside the request
message to P2, which was actually having the destination host as P1?

Can anyone explain the responsibility when the diameter node is acting as an
intermidate also? 

-- 
Yours

Naveen. 



-- 
Yours
Naveen. 




-- 
Yours
Naveen. 


--Boundary_(ID_G8He2dW8Xm3K+Yf4Cj0HHg)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT

<html>

<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 11 (filtered)">

<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
p
	{margin-right:0in;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.EmailStyle19
	{font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=EN-US link=blue vlink=blue>

<div class=Section1>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Hi Naveen</span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; I had only posted your query
to the apt WG viz. DiME, I hadn&#8217;t replied.</span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Anyways, in my opinion,
Diameter messages forwarded using Destination Host should not subjected to
failover.</span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Rajith</span></font></p>

<div>

<p class=MsoNormal><font size=1 color=black face=Arial><span style='font-size:
8.0pt;font-family:Arial;color:black'>************************************************************************************</span></font></p>

<p class=MsoNormal><font size=1 color=black face=Arial><span style='font-size:
8.0pt;font-family:Arial;color:black'>This e-mail and attachments contain
confidential information from HUAWEI, which is intended only for the person or
entity whose address is listed above. Any use of the information contained
herein in any way (including, but not limited to, total or partial disclosure,
reproduction, or dissemination) by persons other than the intended recipient's)
is prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!</span></font></p>

</div>

<div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'>

<div>

<div class=MsoNormal align=center style='text-align:center'><font size=3
face="Times New Roman"><span style='font-size:12.0pt'>

<hr size=2 width="100%" align=center tabindex=-1>

</span></font></div>

<p class=MsoNormal><b><font size=2 face=Tahoma><span style='font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=2
face=Tahoma><span style='font-size:10.0pt;font-family:Tahoma'> owner-aaa-wg@merit.edu [mailto:owner-aaa-wg@merit.edu] <b><span style='font-weight:bold'>On
Behalf Of </span></b>naveen sarma<br>
<b><span style='font-weight:bold'>Sent:</span></b> Monday, August 07, 2006 2:40
PM<br>
<b><span style='font-weight:bold'>To:</span></b> rajithr@huawei.com<br>
<b><span style='font-weight:bold'>Cc:</span></b> aaa-wg@merit.edu;
dime@ietf.org<br>
<b><span style='font-weight:bold'>Subject:</span></b> Re: FW: [AAA-WG]: Fwd:
Failover processing</span></font></p>

</div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>&nbsp;</span></font></p>

<p class=MsoNormal style='margin-bottom:12.0pt'><font size=3
face="Times New Roman"><span style='font-size:12.0pt'>Hi Rajith,<br>
&nbsp;&nbsp;&nbsp; Can you please send your answer to my question.&nbsp; I
haven't received any reply.&nbsp; I think there is some problem.<br>
<br>
Thanks &amp; Regards,<br>
Naveen</span></font></p>

<div>

<p class=MsoNormal><span class=gmailquote><font size=3 face="Times New Roman"><span
style='font-size:12.0pt'>On 7/26/06, <b><span style='font-weight:bold'>Rajith R</span></b>
&lt;<a href="mailto:rajithr@huawei.com">rajithr@huawei.com</a>&gt; wrote:</span></font></span></p>

<div>

<div link=blue vlink=blue>

<div>

<p><font size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:
Arial;color:navy'>Pls ignore the previous post.</span></font></p>

<p><font size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:
Arial;color:navy'>&nbsp;</span></font></p>

<p><font size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:
Arial;color:navy'>&nbsp;</span></font></p>

<div>

<p><font size=1 color=black face=Arial><span style='font-size:8.0pt;font-family:
Arial;color:black'>************************************************************************************</span></font></p>

<p><font size=1 color=black face=Arial><span style='font-size:8.0pt;font-family:
Arial;color:black'>This e-mail and attachments contain confidential information
from HUAWEI, which is intended only for the person or entity whose address is
listed above. Any use of the information contained herein in any way
(including, but not limited to, total or partial disclosure, reproduction, or
dissemination) by persons other than the intended recipient's) is prohibited.
If you receive this e-mail in error, please notify the sender by phone or email
immediately and delete it!</span></font></p>

</div>

<div>

<div class=MsoNormal align=center style='text-align:center'><font size=3
face="Times New Roman"><span style='font-size:12.0pt'>

<hr size=2 width="100%" align=center>

</span></font></div>

<p><b><font size=2 face=Tahoma><span style='font-size:10.0pt;font-family:Tahoma;
font-weight:bold'>From:</span></font></b><font size=2 face=Tahoma><span
style='font-size:10.0pt;font-family:Tahoma'> <a
href="mailto:owner-aaa-wg@merit.edu" target="_blank">owner-aaa-wg@merit.edu</a>
[mailto:<a href="mailto:owner-aaa-wg@merit.edu" target="_blank">owner-aaa-wg@merit.edu</a>]
<b><span style='font-weight:bold'>On Behalf Of </span></b>naveen sarma<br>
<b><span style='font-weight:bold'>Sent:</span></b> Wednesday, July 26, 2006
12:46 PM<br>
<b><span style='font-weight:bold'>To:</span></b> <a
href="mailto:aaa-wg@merit.edu" target="_blank">aaa-wg@merit.edu</a><br>
<b><span style='font-weight:bold'>Subject:</span></b> [AAA-WG]: Fwd: Failover
processing</span></font></p>

</div>

<p><font size=3 face="Times New Roman"><span style='font-size:12.0pt'>&nbsp;</span></font></p>

<p style='margin-bottom:12.0pt'><font size=3 face="Times New Roman"><span
style='font-size:12.0pt'><br>
<br>
---------- Forwarded message ----------<br>
From: <b><span style='font-weight:bold'>naveen sarma</span></b> &lt;<a
href="mailto:naveen.sarma@gmail.com" target="_blank">naveen.sarma@gmail.com</a>&gt;<br>
Date: Jul 26, 2006 12:35 PM <br>
Subject: Failover processing<br>
To: <a href="mailto:dime-request@ietf.org" target="_blank">dime-request@ietf.org</a></span></font></p>

<div>

<p><font size=3 face="Times New Roman"><span style='font-size:12.0pt'>Hi,<br>
<br>
In the case of failover processing, do we need to change the destination host
before forwarding to the new alternate peer? <br>
<br>
Suppose consider the following scenario:<br>
<br>
P0 is the originating host, to which P1 and P2 are peers (direct connection). <br>
<br>
P0 is supporting applications 1, 2, 3<br>
P1 is supporting applications 1, 2<br>
P2 is supporting applications 2, 3<br>
<br>
After some time if P1 is down.&nbsp; Cosider that in the pending message queue
of P1, there is a message M1 with application id 2 and the destination host as
P1.&nbsp; As part of the failover, we will send the request message M1 to P2. <br>
<br>
In this case do we need to change the destination host inside the request
message to P2, which was actually having the destination host as P1?<br>
<br>
Can anyone explain the responsibility when the diameter node is acting as an intermidate
also? <br>
<br>
-- <br>
Yours</span></font></p>

</div>

<div>

<p><font size=3 face="Times New Roman"><span style='font-size:12.0pt'>Naveen. </span></font></p>

</div>

<p><font size=3 face="Times New Roman"><span style='font-size:12.0pt'><br
clear=all>
<br>
-- <br>
Yours<br>
Naveen. </span></font></p>

</div>

</div>

</div>

</div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><br>
<br clear=all>
<br>
-- <br>
Yours<br>
Naveen. </span></font></p>

</div>

</div>

</body>

</html>

--Boundary_(ID_G8He2dW8Xm3K+Yf4Cj0HHg)--


--===============0206861181==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0206861181==--




From dime-bounces@ietf.org Mon Aug 07 09:35:12 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GA5GC-0003iO-D5; Mon, 07 Aug 2006 09:35:12 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GA5GA-0003iC-Fl
	for dime@ietf.org; Mon, 07 Aug 2006 09:35:10 -0400
Received: from usaga01-in.huawei.com ([12.129.211.51])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GA5G4-0007dB-Ee
	for dime@ietf.org; Mon, 07 Aug 2006 09:35:10 -0400
Received: from huawei.com (usaga01-in [172.18.4.6])
	by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0J3M00EABQX4L3@usaga01-in.huawei.com> for
	dime@ietf.org; Mon, 07 Aug 2006 06:31:53 -0700 (PDT)
Received: from Nakhjiri73701
	(c-24-17-254-79.hsd1.wa.comcast.net [24.17.254.79]) by
	usaga01-in.huawei.com
	(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
	with ESMTPA id <0J3M00DK4QX0DF@usaga01-in.huawei.com> for dime@ietf.org;
	Mon, 07 Aug 2006 06:31:52 -0700 (PDT)
Date: Mon, 07 Aug 2006 06:34:55 -0700
From: Madjid Nakhjiri <mnakhjiri@huawei.com>
Subject: RE: [Dime] MIP6 App ID/ was: IETF#66 Meeting Minutes
In-reply-to: <44D48D70.2090103@gmx.net>
To: 'Hannes Tschofenig' <Hannes.Tschofenig@gmx.net>
Message-id: <004501c6ba26$455a57b0$03fda8c0@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-index: Aca4ik8tYBhRGg/FR0SZS4fOvFUdEQBm2Ulw
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

No worries, I was being humorous. I wanted to see what was said during the
meeting regarding the Mobile IP6 drafts. I tried to see the archive
discussions, but did not see anything in June or July either.
I am seeing all this discussion on the use of App IDs on the ML, so I wanted
to see if MIP6 is getting its own App ID, or it is using the App ID assigned
to Mobile IP in 3588?

R,

Madjid

-----Original Message-----
From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] 
Sent: Saturday, August 05, 2006 5:22 AM
To: Madjid Nakhjiri
Cc: dime@ietf.org
Subject: Re: [Dime] IETF#66 Meeting Minutes

I agree that the meeting minutes are somewhat brief this time.
We will do better with the next IETF meeting...

Ciao
Hannes

Madjid Nakhjiri wrote:
> Was this minutes or 10-minutes:-)
> 
> -----Original Message-----
> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] 
> Sent: Wednesday, July 19, 2006 7:56 AM
> To: dime@ietf.org
> Subject: [Dime] IETF#66 Meeting Minutes
> 
> Hi all,
> 
> please take a look at the meeting minutes:
> http://www3.ietf.org/proceedings/06jul/minutes/dime.txt
> 
> Ciao
> Hannes
> 
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www1.ietf.org/mailman/listinfo/dime
> 
> 
> 




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



From dime-bounces@ietf.org Mon Aug 07 09:39:22 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GA5KE-0006GB-Nk; Mon, 07 Aug 2006 09:39:22 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GA5KD-0006G4-Lq
	for dime@ietf.org; Mon, 07 Aug 2006 09:39:21 -0400
Received: from smtp2.int-evry.fr ([157.159.10.45])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GA5KC-00009Z-8V
	for dime@ietf.org; Mon, 07 Aug 2006 09:39:21 -0400
Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76])
	by smtp2.int-evry.fr (Postfix) with ESMTP id 38EC62FD0D;
	Mon,  7 Aug 2006 15:39:18 +0200 (CEST)
Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.52)
	id 1GA5ML-0002K7-Qo; Mon, 07 Aug 2006 15:41:33 +0200
Date: Mon, 7 Aug 2006 15:41:33 +0200
From: Julien Bournelle <julien.bournelle@int-evry.fr>
To: Madjid Nakhjiri <mnakhjiri@huawei.com>
Subject: Re: [Dime] MIP6 App ID/ was: IETF#66 Meeting Minutes
Message-ID: <20060807134133.GA8927@ipv6-3.int-evry.fr>
References: <44D48D70.2090103@gmx.net>
	<004501c6ba26$455a57b0$03fda8c0@china.huawei.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <004501c6ba26$455a57b0$03fda8c0@china.huawei.com>
User-Agent: Mutt/1.5.9i
X-INT-MailScanner-Information: Please contact the ISP for more information
X-INT-MailScanner: Found to be clean
X-INT-MailScanner-MCPCheck: 
X-INT-MailScanner-SpamCheck: 
X-MailScanner-From: jb@int-evry.fr
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

HI madjid,

On Mon, Aug 07, 2006 at 06:34:55AM -0700, Madjid Nakhjiri wrote:
> No worries, I was being humorous. I wanted to see what was said during the
> meeting regarding the Mobile IP6 drafts. I tried to see the archive
> discussions, but did not see anything in June or July either.
> I am seeing all this discussion on the use of App IDs on the ML, so I wanted
> to see if MIP6 is getting its own App ID, or it is using the App ID assigned
> to Mobiloe IP in 3588?

 basically the question is: do we need a specific App ID or do a
 Service-Type AVP (indicating that it's a HA for the split scenario) is
 sufficient ?

 regards,

 Julien

> 
> R,
> 
> Madjid
> 
> -----Original Message-----
> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] 
> Sent: Saturday, August 05, 2006 5:22 AM
> To: Madjid Nakhjiri
> Cc: dime@ietf.org
> Subject: Re: [Dime] IETF#66 Meeting Minutes
> 
> I agree that the meeting minutes are somewhat brief this time.
> We will do better with the next IETF meeting...
> 
> Ciao
> Hannes
> 
> Madjid Nakhjiri wrote:
> > Was this minutes or 10-minutes:-)
> > 
> > -----Original Message-----
> > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] 
> > Sent: Wednesday, July 19, 2006 7:56 AM
> > To: dime@ietf.org
> > Subject: [Dime] IETF#66 Meeting Minutes
> > 
> > Hi all,
> > 
> > please take a look at the meeting minutes:
> > http://www3.ietf.org/proceedings/06jul/minutes/dime.txt
> > 
> > Ciao
> > Hannes
> > 
> > _______________________________________________
> > DiME mailing list
> > DiME@ietf.org
> > https://www1.ietf.org/mailman/listinfo/dime
> > 
> > 
> > 
> 
> 
> 
> 
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www1.ietf.org/mailman/listinfo/dime

-- 
julien.bournelle at int-evry.fr

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



From dime-bounces@ietf.org Mon Aug 07 10:04:34 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GA5ic-0001p4-KM; Mon, 07 Aug 2006 10:04:34 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GA5ib-0001ov-Gr
	for dime@ietf.org; Mon, 07 Aug 2006 10:04:33 -0400
Received: from usaga01-in.huawei.com ([12.129.211.51])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GA5iZ-0007kJ-6T
	for dime@ietf.org; Mon, 07 Aug 2006 10:04:33 -0400
Received: from huawei.com (usaga01-in [172.18.4.6])
	by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0J3M00EIZS6KL3@usaga01-in.huawei.com> for
	dime@ietf.org; Mon, 07 Aug 2006 06:59:09 -0700 (PDT)
Received: from Nakhjiri73701
	(c-24-17-254-79.hsd1.wa.comcast.net [24.17.254.79]) by
	usaga01-in.huawei.com
	(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
	with ESMTPA id <0J3M00DPAS6EJS@usaga01-in.huawei.com> for dime@ietf.org;
	Mon, 07 Aug 2006 06:59:08 -0700 (PDT)
Date: Mon, 07 Aug 2006 07:02:09 -0700
From: Madjid Nakhjiri <mnakhjiri@huawei.com>
Subject: RE: [Dime] IETF#66 Meeting Minutes
In-reply-to: <44D40C4E.50008@tari.toshiba.com>
To: 'Victor Fajardo' <vfajardo@tari.toshiba.com>
Message-id: <004901c6ba2a$1442e940$03fda8c0@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-index: Aca51exI2SnjREAeQnGp447dMqrRSAAU4A4A
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

Hi Victor, 

No need to apologize. Minute taking is a volunteer work and sometime minute
takers get busy with Microphone discussion. I did not know who took it. I
follow up with the presenters. 

I remember there was some discussion on MIP6 drafts and use of App ID.
Basically my confusion is about the fact that the base spec 3588 has an App
ID for Mobile IP general, while 4004 is only on MIP4. Are you going to
revise 3588 to have two App IDs? One for MIP4 and one for MIP6? Or is there
another way to distinguish between the two?

Thanks,

Madjid

-----Original Message-----
From: Victor Fajardo [mailto:vfajardo@tari.toshiba.com] 
Sent: Friday, August 04, 2006 8:11 PM
To: Madjid Nakhjiri
Cc: 'Hannes Tschofenig'; dime@ietf.org
Subject: Re: [Dime] IETF#66 Meeting Minutes

Hi Madjid,

I apologize, I will try to recoupe as much info from the last meetings 
as I can.

regards,
victor
> Was this minutes or 10-minutes:-)
>
> -----Original Message-----
> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] 
> Sent: Wednesday, July 19, 2006 7:56 AM
> To: dime@ietf.org
> Subject: [Dime] IETF#66 Meeting Minutes
>
> Hi all,
>
> please take a look at the meeting minutes:
> http://www3.ietf.org/proceedings/06jul/minutes/dime.txt
>
> Ciao
> Hannes
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www1.ietf.org/mailman/listinfo/dime
>
>
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www1.ietf.org/mailman/listinfo/dime
>
>
>   




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



From dime-bounces@ietf.org Mon Aug 07 10:22:09 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GA5zd-00023c-Fs; Mon, 07 Aug 2006 10:22:09 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GA5zc-00023W-VW
	for dime@ietf.org; Mon, 07 Aug 2006 10:22:08 -0400
Received: from lizzard.sbs.de ([194.138.37.39])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GA5zb-00019e-D6
	for dime@ietf.org; Mon, 07 Aug 2006 10:22:08 -0400
Received: from mail2.sbs.de (localhost [127.0.0.1])
	by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k77ELRBx003455;
	Mon, 7 Aug 2006 16:21:27 +0200
Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net
	[157.163.133.222])
	by mail2.sbs.de (8.12.6/8.12.6) with ESMTP id k77ELQX5019093;
	Mon, 7 Aug 2006 16:21:26 +0200
Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by
	fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 7 Aug 2006 16:21:26 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: AW: [Dime] MIP6 App ID/ was: IETF#66 Meeting Minutes
Date: Mon, 7 Aug 2006 16:21:26 +0200
Message-ID: <A5D2BD54850CCA4AA3B93227205D8A30898B8D@MCHP7IEA.ww002.siemens.net>
In-Reply-To: <004501c6ba26$455a57b0$03fda8c0@china.huawei.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Dime] MIP6 App ID/ was: IETF#66 Meeting Minutes
Thread-Index: Aca4ik8tYBhRGg/FR0SZS4fOvFUdEQBm2UlwAACMu7A=
From: "Tschofenig, Hannes" <hannes.tschofenig@siemens.com>
To: "Madjid Nakhjiri" <mnakhjiri@huawei.com>,
	"Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>
X-OriginalArrivalTime: 07 Aug 2006 14:21:26.0728 (UTC)
	FILETIME=[C4A78C80:01C6BA2C]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

Hi Madjid,=20

> No worries, I was being humorous. I wanted to see what was=20
> said during the
> meeting regarding the Mobile IP6 drafts. I tried to see the archive
> discussions, but did not see anything in June or July either.
> I am seeing all this discussion on the use of App IDs on the=20
> ML, so I wanted
> to see if MIP6 is getting its own App ID, or it is using the=20
> App ID assigned
> to Mobile IP in 3588?
This is essentially the main question with the work on the mobility
protocols. From the discussions I couldn't see a rough consensus. Hence,
I will read through the discussions again, summarize them and see what
we can do. I plan to send something to the list this week to move the
work forward.=20

Ciao
Hannes

>=20
> R,
>=20
> Madjid
>=20
> -----Original Message-----
> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20
> Sent: Saturday, August 05, 2006 5:22 AM
> To: Madjid Nakhjiri
> Cc: dime@ietf.org
> Subject: Re: [Dime] IETF#66 Meeting Minutes
>=20
> I agree that the meeting minutes are somewhat brief this time.
> We will do better with the next IETF meeting...
>=20
> Ciao
> Hannes
>=20
> Madjid Nakhjiri wrote:
> > Was this minutes or 10-minutes:-)
> >=20
> > -----Original Message-----
> > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20
> > Sent: Wednesday, July 19, 2006 7:56 AM
> > To: dime@ietf.org
> > Subject: [Dime] IETF#66 Meeting Minutes
> >=20
> > Hi all,
> >=20
> > please take a look at the meeting minutes:
> > http://www3.ietf.org/proceedings/06jul/minutes/dime.txt
> >=20
> > Ciao
> > Hannes
> >=20
> > _______________________________________________
> > DiME mailing list
> > DiME@ietf.org
> > https://www1.ietf.org/mailman/listinfo/dime
> >=20
> >=20
> >=20
>=20
>=20
>=20
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www1.ietf.org/mailman/listinfo/dime
>=20

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



From dime-bounces@ietf.org Tue Aug 08 19:51:26 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GAbM5-0003lS-Ef; Tue, 08 Aug 2006 19:51:25 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GAbM4-0003lN-Fz
	for dime@ietf.org; Tue, 08 Aug 2006 19:51:24 -0400
Received: from usaga01-in.huawei.com ([12.129.211.51])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAbM3-0007xu-5G
	for dime@ietf.org; Tue, 08 Aug 2006 19:51:24 -0400
Received: from huawei.com (usaga01-in [172.18.4.6])
	by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0J3P0061CE4BZ9@usaga01-in.huawei.com> for
	dime@ietf.org; Tue, 08 Aug 2006 16:48:11 -0700 (PDT)
Received: from Nakhjiri73701
	(pool-71-112-12-134.sttlwa.dsl-w.verizon.net [71.112.12.134])
	by usaga01-in.huawei.com
	(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
	with ESMTPA id <0J3P00KEJE43VV@usaga01-in.huawei.com> for dime@ietf.org;
	Tue, 08 Aug 2006 16:48:11 -0700 (PDT)
Date: Tue, 08 Aug 2006 16:51:08 -0700
From: Madjid Nakhjiri <mnakhjiri@huawei.com>
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???
In-reply-to: <20060807134133.GA8927@ipv6-3.int-evry.fr>
To: 'Julien Bournelle' <julien.bournelle@int-evry.fr>
Message-id: <004801c6bb45$875b4140$2f01a8c0@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-index: Aca6J2gfkOLqsi6yR/Od584yVt5NyQBHONJQ
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

Hi Julien,

I just looked at the RFC 4005 definition of Service_Type.
The services listed there are quite mixed. I am not quite sure what
applications besides NASREQ are supposed to support Service_Type? Or is it
that Mobile IP application assumes NASREQ must be supported?

If one is to go about without modifying RFC 3588 that uses just one App ID
for Mobile IP, then I guess there is just one choice of having

two Service_types for Mobile IPv6 
and 
one Service_Type for Mobile IPv4, 

(3 total for Mobile IP), but then don't you have to modify RFC 4004 to add
the service_type to Mobile IPv4?

Madjid

-----Original Message-----
From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr] 
Sent: Monday, August 07, 2006 6:42 AM
To: Madjid Nakhjiri
Cc: 'Hannes Tschofenig'; dime@ietf.org
Subject: Re: [Dime] MIP6 App ID/ was: IETF#66 Meeting Minutes

HI madjid,

On Mon, Aug 07, 2006 at 06:34:55AM -0700, Madjid Nakhjiri wrote:
> No worries, I was being humorous. I wanted to see what was said during the
> meeting regarding the Mobile IP6 drafts. I tried to see the archive
> discussions, but did not see anything in June or July either.
> I am seeing all this discussion on the use of App IDs on the ML, so I
wanted
> to see if MIP6 is getting its own App ID, or it is using the App ID
assigned
> to Mobiloe IP in 3588?

 basically the question is: do we need a specific App ID or do a
 Service-Type AVP (indicating that it's a HA for the split scenario) is
 sufficient ?


 regards,

 Julien

> 
> R,
> 
> Madjid
> 
> -----Original Message-----
> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] 
> Sent: Saturday, August 05, 2006 5:22 AM
> To: Madjid Nakhjiri
> Cc: dime@ietf.org
> Subject: Re: [Dime] IETF#66 Meeting Minutes
> 
> I agree that the meeting minutes are somewhat brief this time.
> We will do better with the next IETF meeting...
> 
> Ciao
> Hannes
> 
> Madjid Nakhjiri wrote:
> > Was this minutes or 10-minutes:-)
> > 
> > -----Original Message-----
> > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] 
> > Sent: Wednesday, July 19, 2006 7:56 AM
> > To: dime@ietf.org
> > Subject: [Dime] IETF#66 Meeting Minutes
> > 
> > Hi all,
> > 
> > please take a look at the meeting minutes:
> > http://www3.ietf.org/proceedings/06jul/minutes/dime.txt
> > 
> > Ciao
> > Hannes
> > 
> > _______________________________________________
> > DiME mailing list
> > DiME@ietf.org
> > https://www1.ietf.org/mailman/listinfo/dime
> > 
> > 
> > 
> 
> 
> 
> 
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www1.ietf.org/mailman/listinfo/dime

-- 
julien.bournelle at int-evry.fr



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



From dime-bounces@ietf.org Wed Aug 09 04:37:21 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GAjZ1-0004nO-Mu; Wed, 09 Aug 2006 04:37:19 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GAjZ0-0004nJ-IZ
	for dime@ietf.org; Wed, 09 Aug 2006 04:37:18 -0400
Received: from smtp2.int-evry.fr ([157.159.10.45])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GAjYz-0003SJ-3m
	for dime@ietf.org; Wed, 09 Aug 2006 04:37:18 -0400
Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76])
	by smtp2.int-evry.fr (Postfix) with ESMTP id 464F62FD89;
	Wed,  9 Aug 2006 10:37:14 +0200 (CEST)
Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.52)
	id 1GAjb5-0003Dq-HL; Wed, 09 Aug 2006 10:39:27 +0200
Date: Wed, 9 Aug 2006 10:39:27 +0200
From: Julien Bournelle <julien.bournelle@int-evry.fr>
To: Madjid Nakhjiri <mnakhjiri@huawei.com>
Subject: Re: [Dime] MIP6 App ID/ revise RFC 3588???
Message-ID: <20060809083927.GB12246@ipv6-3.int-evry.fr>
References: <20060807134133.GA8927@ipv6-3.int-evry.fr>
	<004801c6bb45$875b4140$2f01a8c0@china.huawei.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <004801c6bb45$875b4140$2f01a8c0@china.huawei.com>
User-Agent: Mutt/1.5.9i
X-INT-MailScanner-Information: Please contact the ISP for more information
X-INT-MailScanner: Found to be clean
X-INT-MailScanner-MCPCheck: 
X-INT-MailScanner-SpamCheck: 
X-MailScanner-From: jb@int-evry.fr
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

Hi madjid,

On Tue, Aug 08, 2006 at 04:51:08PM -0700, Madjid Nakhjiri wrote:
> Hi Julien,
> 
> I just looked at the RFC 4005 definition of Service_Type.
> The services listed there are quite mixed. I am not quite sure what
> applications besides NASREQ are supposed to support Service_Type? Or is it
> that Mobile IP application assumes NASREQ must be supported?

 Let me try to sum up the issue:

 In the split scenario, the HA acts as a IKEv2 responder and uses EAP
 (oIKEv2) to authenticate the user (of the MN). The HA then relies on a
 EAP/AAA server and thus could use Diameter EAP. THe problem that we
 have here is that we are not performing AAA for "basic" network access
 but for the IPv6 Mobility service. Thus we have the problem of, how the
 AAA server knows that. 

 You can take a look at the thread:

 http://www1.ietf.org/mail-archive/web/dime/current/msg00262.html

 for previous discussions on this topic which is still unsolved.

 At this point, as noted in:

 http://www1.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-00.txt

 the 2 options that we have are:

 - define a new Service-Type for "Mobile IPv6 - Split" and puts it in
   DER message (Diameter EAP Request)
 - define a new Application-ID and re-use Diameter EAP messages.

 Hope it helps,

 regards,

 Julien

> 
> If one is to go about without modifying RFC 3588 that uses just one App ID
> for Mobile IP, then I guess there is just one choice of having
> 
> two Service_types for Mobile IPv6 
> and 
> one Service_Type for Mobile IPv4, 
> 
> (3 total for Mobile IP), but then don't you have to modify RFC 4004 to add
> the service_type to Mobile IPv4?
> 
> Madjid
> 
> -----Original Message-----
> From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr] 
> Sent: Monday, August 07, 2006 6:42 AM
> To: Madjid Nakhjiri
> Cc: 'Hannes Tschofenig'; dime@ietf.org
> Subject: Re: [Dime] MIP6 App ID/ was: IETF#66 Meeting Minutes
> 
> HI madjid,
> 
> On Mon, Aug 07, 2006 at 06:34:55AM -0700, Madjid Nakhjiri wrote:
> > No worries, I was being humorous. I wanted to see what was said during the
> > meeting regarding the Mobile IP6 drafts. I tried to see the archive
> > discussions, but did not see anything in June or July either.
> > I am seeing all this discussion on the use of App IDs on the ML, so I
> wanted
> > to see if MIP6 is getting its own App ID, or it is using the App ID
> assigned
> > to Mobiloe IP in 3588?
> 
>  basically the question is: do we need a specific App ID or do a
>  Service-Type AVP (indicating that it's a HA for the split scenario) is
>  sufficient ?
> 
> 
>  regards,
> 
>  Julien
> 
> > 
> > R,
> > 
> > Madjid
> > 
> > -----Original Message-----
> > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] 
> > Sent: Saturday, August 05, 2006 5:22 AM
> > To: Madjid Nakhjiri
> > Cc: dime@ietf.org
> > Subject: Re: [Dime] IETF#66 Meeting Minutes
> > 
> > I agree that the meeting minutes are somewhat brief this time.
> > We will do better with the next IETF meeting...
> > 
> > Ciao
> > Hannes
> > 
> > Madjid Nakhjiri wrote:
> > > Was this minutes or 10-minutes:-)
> > > 
> > > -----Original Message-----
> > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] 
> > > Sent: Wednesday, July 19, 2006 7:56 AM
> > > To: dime@ietf.org
> > > Subject: [Dime] IETF#66 Meeting Minutes
> > > 
> > > Hi all,
> > > 
> > > please take a look at the meeting minutes:
> > > http://www3.ietf.org/proceedings/06jul/minutes/dime.txt
> > > 
> > > Ciao
> > > Hannes
> > > 
> > > _______________________________________________
> > > DiME mailing list
> > > DiME@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/dime
> > > 
> > > 
> > > 
> > 
> > 
> > 
> > 
> > _______________________________________________
> > DiME mailing list
> > DiME@ietf.org
> > https://www1.ietf.org/mailman/listinfo/dime
> 
> -- 
> julien.bournelle at int-evry.fr
> 
> 

-- 
julien.bournelle at int-evry.fr

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



From dime-bounces@ietf.org Fri Aug 11 18:59:55 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GBfyt-0005A9-FN; Fri, 11 Aug 2006 18:59:55 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GBfys-00051z-2S
	for dime@ietf.org; Fri, 11 Aug 2006 18:59:54 -0400
Received: from usaga01-in.huawei.com ([12.129.211.51])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GBfon-00082f-5P
	for dime@ietf.org; Fri, 11 Aug 2006 18:49:29 -0400
Received: from huawei.com (usaga01-in [172.18.4.6])
	by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0J3U00EJDV98LD@usaga01-in.huawei.com> for
	dime@ietf.org; Fri, 11 Aug 2006 15:46:21 -0700 (PDT)
Received: from Nakhjiri73701
	(pool-71-112-12-134.sttlwa.dsl-w.verizon.net [71.112.12.134])
	by usaga01-in.huawei.com
	(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
	with ESMTPA id <0J3U00D75V929I@usaga01-in.huawei.com> for dime@ietf.org;
	Fri, 11 Aug 2006 15:46:20 -0700 (PDT)
Date: Fri, 11 Aug 2006 15:49:18 -0700
From: Madjid Nakhjiri <mnakhjiri@huawei.com>
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???
In-reply-to: <20060809083927.GB12246@ipv6-3.int-evry.fr>
To: 'Julien Bournelle' <julien.bournelle@int-evry.fr>
Message-id: <005f01c6bd98$61ff2e70$2f01a8c0@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
Thread-index: Aca7j5pLlwjYezfqQhS35Ix/bK+xSgCBYw0Q
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b8f3559805f7873076212d6f63ee803e
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

Hi Julien,

Thanks for pointing me to the archives.
I have one general issue that maybe is related to me not quite understanding
EAP-IKEv2 and that is EAP is run between a peer and an EAP server (in this
case the backend AAA server). EAP-IKEv2 was designed so that a mature
authentication/key management method could be used within EAP framework.
Running EAP-IKEv2 results in authentication of peer to backend AAA, not to
HA and possibly a key between the peer and AAA server. How does this help
the need for IPsec between MN and HA?

Now as far as the discussions on the archives, RFC 4072 only talks about
carrying EAP over Diameter without talking about what EAP is being used for
(your question: mobility versus access service). I think distinguishing
mobility versus access is a AAA signaling issue not an EAP signaling issue.
In RADIUS and MIP4 it is simpler (look at draft-nakhjiri-radius-mip4-02)
because there are attributes related to MIP4 authentication (such as
MIP-MN-AAA-Authenticator, etc) within the Access Request that tells the
server this is about RADIUS. Diameter on the other hand has the notion of
Application ID and should not rely on explicit hint on this. When we got to
the point of trying to translate Diameter messaging to RADIUS, we had to
resort to port types, because Diameter had different messages (depending on
whether HA or FA were involved) while all RADIUS had was Access
Request/Accepts not recognizing between HA and FA.
Here your case is different. Diameter already has an Application ID for
Mobile IP. That is how you distinguish between access and mobility service,
not through service type. Now there are two choices as I said before:

A) revise 3588 to have one App ID for MIPv4 and one for MIPv6 (separate MIP6
split versus integrated through service types). This of course mean revising
4004 to indicate specifically what MIPv4 App ID is.

B) Use the same App ID of 3588 for both MIP4 and MIP6, but then you have to
define 4 service types
1) MIP4 split
2) MIP4 integrated
3) MIP6 split
4) MIP6 integrated.

I prefer A (I can live with B, if you tie a rope to my neck, just kidding).
I think A is cleaner. I think split-integrated versus MIP4-mip6 are two
different degrees of freedom. Just because MIP4 WG did not make the split
integrated distinction, does not mean the business case cannot exist.
Plus that Avi stated that Service type seems to be mandatory.

Madjid

-----Original Message-----
From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr] 
Sent: Wednesday, August 09, 2006 1:39 AM
To: Madjid Nakhjiri
Cc: 'Julien Bournelle'; 'Hannes Tschofenig'; dime@ietf.org
Subject: Re: [Dime] MIP6 App ID/ revise RFC 3588???

Hi madjid,

On Tue, Aug 08, 2006 at 04:51:08PM -0700, Madjid Nakhjiri wrote:
> Hi Julien,
> 
> I just looked at the RFC 4005 definition of Service_Type.
> The services listed there are quite mixed. I am not quite sure what
> applications besides NASREQ are supposed to support Service_Type? Or is it
> that Mobile IP application assumes NASREQ must be supported?

 Let me try to sum up the issue:

 In the split scenario, the HA acts as a IKEv2 responder and uses EAP
 (oIKEv2) to authenticate the user (of the MN). The HA then relies on a
 EAP/AAA server and thus could use Diameter EAP. THe problem that we
 have here is that we are not performing AAA for "basic" network access
 but for the IPv6 Mobility service. Thus we have the problem of, how the
 AAA server knows that. 

 You can take a look at the thread:

 http://www1.ietf.org/mail-archive/web/dime/current/msg00262.html

 for previous discussions on this topic which is still unsolved.

 At this point, as noted in:

 http://www1.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-00.txt

 the 2 options that we have are:

 - define a new Service-Type for "Mobile IPv6 - Split" and puts it in
   DER message (Diameter EAP Request)
 - define a new Application-ID and re-use Diameter EAP messages.

 Hope it helps,

 regards,

 Julien

> 
> If one is to go about without modifying RFC 3588 that uses just one App ID
> for Mobile IP, then I guess there is just one choice of having
> 
> two Service_types for Mobile IPv6 
> and 
> one Service_Type for Mobile IPv4, 
> 
> (3 total for Mobile IP), but then don't you have to modify RFC 4004 to add
> the service_type to Mobile IPv4?
> 
> Madjid
> 
> -----Original Message-----
> From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr] 
> Sent: Monday, August 07, 2006 6:42 AM
> To: Madjid Nakhjiri
> Cc: 'Hannes Tschofenig'; dime@ietf.org
> Subject: Re: [Dime] MIP6 App ID/ was: IETF#66 Meeting Minutes
> 
> HI madjid,
> 
> On Mon, Aug 07, 2006 at 06:34:55AM -0700, Madjid Nakhjiri wrote:
> > No worries, I was being humorous. I wanted to see what was said during
the
> > meeting regarding the Mobile IP6 drafts. I tried to see the archive
> > discussions, but did not see anything in June or July either.
> > I am seeing all this discussion on the use of App IDs on the ML, so I
> wanted
> > to see if MIP6 is getting its own App ID, or it is using the App ID
> assigned
> > to Mobiloe IP in 3588?
> 
>  basically the question is: do we need a specific App ID or do a
>  Service-Type AVP (indicating that it's a HA for the split scenario) is
>  sufficient ?
> 
> 
>  regards,
> 
>  Julien
> 
> > 
> > R,
> > 
> > Madjid
> > 
> > -----Original Message-----
> > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] 
> > Sent: Saturday, August 05, 2006 5:22 AM
> > To: Madjid Nakhjiri
> > Cc: dime@ietf.org
> > Subject: Re: [Dime] IETF#66 Meeting Minutes
> > 
> > I agree that the meeting minutes are somewhat brief this time.
> > We will do better with the next IETF meeting...
> > 
> > Ciao
> > Hannes
> > 
> > Madjid Nakhjiri wrote:
> > > Was this minutes or 10-minutes:-)
> > > 
> > > -----Original Message-----
> > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] 
> > > Sent: Wednesday, July 19, 2006 7:56 AM
> > > To: dime@ietf.org
> > > Subject: [Dime] IETF#66 Meeting Minutes
> > > 
> > > Hi all,
> > > 
> > > please take a look at the meeting minutes:
> > > http://www3.ietf.org/proceedings/06jul/minutes/dime.txt
> > > 
> > > Ciao
> > > Hannes
> > > 
> > > _______________________________________________
> > > DiME mailing list
> > > DiME@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/dime
> > > 
> > > 
> > > 
> > 
> > 
> > 
> > 
> > _______________________________________________
> > DiME mailing list
> > DiME@ietf.org
> > https://www1.ietf.org/mailman/listinfo/dime
> 
> -- 
> julien.bournelle at int-evry.fr
> 
> 

-- 
julien.bournelle at int-evry.fr



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



From dime-bounces@ietf.org Tue Aug 15 10:01:02 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GCzTZ-00054j-LZ; Tue, 15 Aug 2006 10:01:01 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GCzTY-00053O-G6
	for dime@ietf.org; Tue, 15 Aug 2006 10:01:00 -0400
Received: from bws14.bridgewatersystems.com ([216.113.7.14]
	helo=exchange.bridgewatersys.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCzTX-0005k8-At
	for dime@ietf.org; Tue, 15 Aug 2006 10:01:00 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???
Date: Tue, 15 Aug 2006 10:01:02 -0400
Message-ID: <E7CCE8A83907104ABEE91AC3AE3709A01167DA@exchange.bridgewatersys.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Dime] MIP6 App ID/ revise RFC 3588???
Thread-Index: Aca7j5pLlwjYezfqQhS35Ix/bK+xSgCBYw0QALeF6YM=
References: <005f01c6bd98$61ff2e70$2f01a8c0@china.huawei.com>
From: "Avi Lior" <avi@bridgewatersystems.com>
To: "Madjid Nakhjiri" <mnakhjiri@huawei.com>,
	"Julien Bournelle" <julien.bournelle@int-evry.fr>
X-Spam-Score: 0.6 (/)
X-Scan-Signature: 78a8240bd7a9c0d7033035fffd7b84c6
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1074118190=="
Errors-To: dime-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1074118190==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C6C073.62B28000"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6C073.62B28000
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


How about the correct (IMO) option and that is assign this new =
application its own Application ID.  THis afterall is what an =
Application ID is supposed to do.



-----Original Message-----
From: Madjid Nakhjiri [mailto:mnakhjiri@huawei.com]
Sent: Fri 8/11/2006 6:49 PM
To: 'Julien Bournelle'
Cc: dime@ietf.org
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???
=20
Hi Julien,

Thanks for pointing me to the archives.
I have one general issue that maybe is related to me not quite =
understanding
EAP-IKEv2 and that is EAP is run between a peer and an EAP server (in =
this
case the backend AAA server). EAP-IKEv2 was designed so that a mature
authentication/key management method could be used within EAP framework.
Running EAP-IKEv2 results in authentication of peer to backend AAA, not =
to
HA and possibly a key between the peer and AAA server. How does this =
help
the need for IPsec between MN and HA?

Now as far as the discussions on the archives, RFC 4072 only talks about
carrying EAP over Diameter without talking about what EAP is being used =
for
(your question: mobility versus access service). I think distinguishing
mobility versus access is a AAA signaling issue not an EAP signaling =
issue.
In RADIUS and MIP4 it is simpler (look at draft-nakhjiri-radius-mip4-02)
because there are attributes related to MIP4 authentication (such as
MIP-MN-AAA-Authenticator, etc) within the Access Request that tells the
server this is about RADIUS. Diameter on the other hand has the notion =
of
Application ID and should not rely on explicit hint on this. When we got =
to
the point of trying to translate Diameter messaging to RADIUS, we had to
resort to port types, because Diameter had different messages (depending =
on
whether HA or FA were involved) while all RADIUS had was Access
Request/Accepts not recognizing between HA and FA.
Here your case is different. Diameter already has an Application ID for
Mobile IP. That is how you distinguish between access and mobility =
service,
not through service type. Now there are two choices as I said before:

A) revise 3588 to have one App ID for MIPv4 and one for MIPv6 (separate =
MIP6
split versus integrated through service types). This of course mean =
revising
4004 to indicate specifically what MIPv4 App ID is.

B) Use the same App ID of 3588 for both MIP4 and MIP6, but then you have =
to
define 4 service types
1) MIP4 split
2) MIP4 integrated
3) MIP6 split
4) MIP6 integrated.

I prefer A (I can live with B, if you tie a rope to my neck, just =
kidding).
I think A is cleaner. I think split-integrated versus MIP4-mip6 are two
different degrees of freedom. Just because MIP4 WG did not make the =
split
integrated distinction, does not mean the business case cannot exist.
Plus that Avi stated that Service type seems to be mandatory.

Madjid

-----Original Message-----
From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr]=20
Sent: Wednesday, August 09, 2006 1:39 AM
To: Madjid Nakhjiri
Cc: 'Julien Bournelle'; 'Hannes Tschofenig'; dime@ietf.org
Subject: Re: [Dime] MIP6 App ID/ revise RFC 3588???

Hi madjid,

On Tue, Aug 08, 2006 at 04:51:08PM -0700, Madjid Nakhjiri wrote:
> Hi Julien,
>=20
> I just looked at the RFC 4005 definition of Service_Type.
> The services listed there are quite mixed. I am not quite sure what
> applications besides NASREQ are supposed to support Service_Type? Or =
is it
> that Mobile IP application assumes NASREQ must be supported?

 Let me try to sum up the issue:

 In the split scenario, the HA acts as a IKEv2 responder and uses EAP
 (oIKEv2) to authenticate the user (of the MN). The HA then relies on a
 EAP/AAA server and thus could use Diameter EAP. THe problem that we
 have here is that we are not performing AAA for "basic" network access
 but for the IPv6 Mobility service. Thus we have the problem of, how the
 AAA server knows that.=20

 You can take a look at the thread:

 http://www1.ietf.org/mail-archive/web/dime/current/msg00262.html

 for previous discussions on this topic which is still unsolved.

 At this point, as noted in:

 http://www1.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-00.txt

 the 2 options that we have are:

 - define a new Service-Type for "Mobile IPv6 - Split" and puts it in
   DER message (Diameter EAP Request)
 - define a new Application-ID and re-use Diameter EAP messages.

 Hope it helps,

 regards,

 Julien

>=20
> If one is to go about without modifying RFC 3588 that uses just one =
App ID
> for Mobile IP, then I guess there is just one choice of having
>=20
> two Service_types for Mobile IPv6=20
> and=20
> one Service_Type for Mobile IPv4,=20
>=20
> (3 total for Mobile IP), but then don't you have to modify RFC 4004 to =
add
> the service_type to Mobile IPv4?
>=20
> Madjid
>=20
> -----Original Message-----
> From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr]=20
> Sent: Monday, August 07, 2006 6:42 AM
> To: Madjid Nakhjiri
> Cc: 'Hannes Tschofenig'; dime@ietf.org
> Subject: Re: [Dime] MIP6 App ID/ was: IETF#66 Meeting Minutes
>=20
> HI madjid,
>=20
> On Mon, Aug 07, 2006 at 06:34:55AM -0700, Madjid Nakhjiri wrote:
> > No worries, I was being humorous. I wanted to see what was said =
during
the
> > meeting regarding the Mobile IP6 drafts. I tried to see the archive
> > discussions, but did not see anything in June or July either.
> > I am seeing all this discussion on the use of App IDs on the ML, so =
I
> wanted
> > to see if MIP6 is getting its own App ID, or it is using the App ID
> assigned
> > to Mobiloe IP in 3588?
>=20
>  basically the question is: do we need a specific App ID or do a
>  Service-Type AVP (indicating that it's a HA for the split scenario) =
is
>  sufficient ?
>=20
>=20
>  regards,
>=20
>  Julien
>=20
> >=20
> > R,
> >=20
> > Madjid
> >=20
> > -----Original Message-----
> > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20
> > Sent: Saturday, August 05, 2006 5:22 AM
> > To: Madjid Nakhjiri
> > Cc: dime@ietf.org
> > Subject: Re: [Dime] IETF#66 Meeting Minutes
> >=20
> > I agree that the meeting minutes are somewhat brief this time.
> > We will do better with the next IETF meeting...
> >=20
> > Ciao
> > Hannes
> >=20
> > Madjid Nakhjiri wrote:
> > > Was this minutes or 10-minutes:-)
> > >=20
> > > -----Original Message-----
> > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20
> > > Sent: Wednesday, July 19, 2006 7:56 AM
> > > To: dime@ietf.org
> > > Subject: [Dime] IETF#66 Meeting Minutes
> > >=20
> > > Hi all,
> > >=20
> > > please take a look at the meeting minutes:
> > > http://www3.ietf.org/proceedings/06jul/minutes/dime.txt
> > >=20
> > > Ciao
> > > Hannes
> > >=20
> > > _______________________________________________
> > > DiME mailing list
> > > DiME@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/dime
> > >=20
> > >=20
> > >=20
> >=20
> >=20
> >=20
> >=20
> > _______________________________________________
> > DiME mailing list
> > DiME@ietf.org
> > https://www1.ietf.org/mailman/listinfo/dime
>=20
> --=20
> julien.bournelle at int-evry.fr
>=20
>=20

--=20
julien.bournelle at int-evry.fr



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


------_=_NextPart_001_01C6C073.62B28000
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 =
6.5.7650.28">
<TITLE>RE: [Dime] MIP6 App ID/ revise RFC 3588???</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<BR>

<P><FONT SIZE=3D2>How about the correct (IMO) option and that is assign =
this new application its own Application ID.&nbsp; THis afterall is what =
an Application ID is supposed to do.<BR>
<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: Madjid Nakhjiri [<A =
HREF=3D"mailto:mnakhjiri@huawei.com">mailto:mnakhjiri@huawei.com</A>]<BR>=

Sent: Fri 8/11/2006 6:49 PM<BR>
To: 'Julien Bournelle'<BR>
Cc: dime@ietf.org<BR>
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???<BR>
<BR>
Hi Julien,<BR>
<BR>
Thanks for pointing me to the archives.<BR>
I have one general issue that maybe is related to me not quite =
understanding<BR>
EAP-IKEv2 and that is EAP is run between a peer and an EAP server (in =
this<BR>
case the backend AAA server). EAP-IKEv2 was designed so that a =
mature<BR>
authentication/key management method could be used within EAP =
framework.<BR>
Running EAP-IKEv2 results in authentication of peer to backend AAA, not =
to<BR>
HA and possibly a key between the peer and AAA server. How does this =
help<BR>
the need for IPsec between MN and HA?<BR>
<BR>
Now as far as the discussions on the archives, RFC 4072 only talks =
about<BR>
carrying EAP over Diameter without talking about what EAP is being used =
for<BR>
(your question: mobility versus access service). I think =
distinguishing<BR>
mobility versus access is a AAA signaling issue not an EAP signaling =
issue.<BR>
In RADIUS and MIP4 it is simpler (look at =
draft-nakhjiri-radius-mip4-02)<BR>
because there are attributes related to MIP4 authentication (such as<BR>
MIP-MN-AAA-Authenticator, etc) within the Access Request that tells =
the<BR>
server this is about RADIUS. Diameter on the other hand has the notion =
of<BR>
Application ID and should not rely on explicit hint on this. When we got =
to<BR>
the point of trying to translate Diameter messaging to RADIUS, we had =
to<BR>
resort to port types, because Diameter had different messages (depending =
on<BR>
whether HA or FA were involved) while all RADIUS had was Access<BR>
Request/Accepts not recognizing between HA and FA.<BR>
Here your case is different. Diameter already has an Application ID =
for<BR>
Mobile IP. That is how you distinguish between access and mobility =
service,<BR>
not through service type. Now there are two choices as I said =
before:<BR>
<BR>
A) revise 3588 to have one App ID for MIPv4 and one for MIPv6 (separate =
MIP6<BR>
split versus integrated through service types). This of course mean =
revising<BR>
4004 to indicate specifically what MIPv4 App ID is.<BR>
<BR>
B) Use the same App ID of 3588 for both MIP4 and MIP6, but then you have =
to<BR>
define 4 service types<BR>
1) MIP4 split<BR>
2) MIP4 integrated<BR>
3) MIP6 split<BR>
4) MIP6 integrated.<BR>
<BR>
I prefer A (I can live with B, if you tie a rope to my neck, just =
kidding).<BR>
I think A is cleaner. I think split-integrated versus MIP4-mip6 are =
two<BR>
different degrees of freedom. Just because MIP4 WG did not make the =
split<BR>
integrated distinction, does not mean the business case cannot =
exist.<BR>
Plus that Avi stated that Service type seems to be mandatory.<BR>
<BR>
Madjid<BR>
<BR>
-----Original Message-----<BR>
From: Julien Bournelle [<A =
HREF=3D"mailto:julien.bournelle@int-evry.fr">mailto:julien.bournelle@int-=
evry.fr</A>]<BR>
Sent: Wednesday, August 09, 2006 1:39 AM<BR>
To: Madjid Nakhjiri<BR>
Cc: 'Julien Bournelle'; 'Hannes Tschofenig'; dime@ietf.org<BR>
Subject: Re: [Dime] MIP6 App ID/ revise RFC 3588???<BR>
<BR>
Hi madjid,<BR>
<BR>
On Tue, Aug 08, 2006 at 04:51:08PM -0700, Madjid Nakhjiri wrote:<BR>
&gt; Hi Julien,<BR>
&gt;<BR>
&gt; I just looked at the RFC 4005 definition of Service_Type.<BR>
&gt; The services listed there are quite mixed. I am not quite sure =
what<BR>
&gt; applications besides NASREQ are supposed to support Service_Type? =
Or is it<BR>
&gt; that Mobile IP application assumes NASREQ must be supported?<BR>
<BR>
&nbsp;Let me try to sum up the issue:<BR>
<BR>
&nbsp;In the split scenario, the HA acts as a IKEv2 responder and uses =
EAP<BR>
&nbsp;(oIKEv2) to authenticate the user (of the MN). The HA then relies =
on a<BR>
&nbsp;EAP/AAA server and thus could use Diameter EAP. THe problem that =
we<BR>
&nbsp;have here is that we are not performing AAA for &quot;basic&quot; =
network access<BR>
&nbsp;but for the IPv6 Mobility service. Thus we have the problem of, =
how the<BR>
&nbsp;AAA server knows that.<BR>
<BR>
&nbsp;You can take a look at the thread:<BR>
<BR>
&nbsp;<A =
HREF=3D"http://www1.ietf.org/mail-archive/web/dime/current/msg00262.html"=
>http://www1.ietf.org/mail-archive/web/dime/current/msg00262.html</A><BR>=

<BR>
&nbsp;for previous discussions on this topic which is still =
unsolved.<BR>
<BR>
&nbsp;At this point, as noted in:<BR>
<BR>
&nbsp;<A =
HREF=3D"http://www1.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-0=
0.txt">http://www1.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-00=
.txt</A><BR>
<BR>
&nbsp;the 2 options that we have are:<BR>
<BR>
&nbsp;- define a new Service-Type for &quot;Mobile IPv6 - Split&quot; =
and puts it in<BR>
&nbsp;&nbsp; DER message (Diameter EAP Request)<BR>
&nbsp;- define a new Application-ID and re-use Diameter EAP =
messages.<BR>
<BR>
&nbsp;Hope it helps,<BR>
<BR>
&nbsp;regards,<BR>
<BR>
&nbsp;Julien<BR>
<BR>
&gt;<BR>
&gt; If one is to go about without modifying RFC 3588 that uses just one =
App ID<BR>
&gt; for Mobile IP, then I guess there is just one choice of having<BR>
&gt;<BR>
&gt; two Service_types for Mobile IPv6<BR>
&gt; and<BR>
&gt; one Service_Type for Mobile IPv4,<BR>
&gt;<BR>
&gt; (3 total for Mobile IP), but then don't you have to modify RFC 4004 =
to add<BR>
&gt; the service_type to Mobile IPv4?<BR>
&gt;<BR>
&gt; Madjid<BR>
&gt;<BR>
&gt; -----Original Message-----<BR>
&gt; From: Julien Bournelle [<A =
HREF=3D"mailto:julien.bournelle@int-evry.fr">mailto:julien.bournelle@int-=
evry.fr</A>]<BR>
&gt; Sent: Monday, August 07, 2006 6:42 AM<BR>
&gt; To: Madjid Nakhjiri<BR>
&gt; Cc: 'Hannes Tschofenig'; dime@ietf.org<BR>
&gt; Subject: Re: [Dime] MIP6 App ID/ was: IETF#66 Meeting Minutes<BR>
&gt;<BR>
&gt; HI madjid,<BR>
&gt;<BR>
&gt; On Mon, Aug 07, 2006 at 06:34:55AM -0700, Madjid Nakhjiri =
wrote:<BR>
&gt; &gt; No worries, I was being humorous. I wanted to see what was =
said during<BR>
the<BR>
&gt; &gt; meeting regarding the Mobile IP6 drafts. I tried to see the =
archive<BR>
&gt; &gt; discussions, but did not see anything in June or July =
either.<BR>
&gt; &gt; I am seeing all this discussion on the use of App IDs on the =
ML, so I<BR>
&gt; wanted<BR>
&gt; &gt; to see if MIP6 is getting its own App ID, or it is using the =
App ID<BR>
&gt; assigned<BR>
&gt; &gt; to Mobiloe IP in 3588?<BR>
&gt;<BR>
&gt;&nbsp; basically the question is: do we need a specific App ID or do =
a<BR>
&gt;&nbsp; Service-Type AVP (indicating that it's a HA for the split =
scenario) is<BR>
&gt;&nbsp; sufficient ?<BR>
&gt;<BR>
&gt;<BR>
&gt;&nbsp; regards,<BR>
&gt;<BR>
&gt;&nbsp; Julien<BR>
&gt;<BR>
&gt; &gt;<BR>
&gt; &gt; R,<BR>
&gt; &gt;<BR>
&gt; &gt; Madjid<BR>
&gt; &gt;<BR>
&gt; &gt; -----Original Message-----<BR>
&gt; &gt; From: Hannes Tschofenig [<A =
HREF=3D"mailto:Hannes.Tschofenig@gmx.net">mailto:Hannes.Tschofenig@gmx.ne=
t</A>]<BR>
&gt; &gt; Sent: Saturday, August 05, 2006 5:22 AM<BR>
&gt; &gt; To: Madjid Nakhjiri<BR>
&gt; &gt; Cc: dime@ietf.org<BR>
&gt; &gt; Subject: Re: [Dime] IETF#66 Meeting Minutes<BR>
&gt; &gt;<BR>
&gt; &gt; I agree that the meeting minutes are somewhat brief this =
time.<BR>
&gt; &gt; We will do better with the next IETF meeting...<BR>
&gt; &gt;<BR>
&gt; &gt; Ciao<BR>
&gt; &gt; Hannes<BR>
&gt; &gt;<BR>
&gt; &gt; Madjid Nakhjiri wrote:<BR>
&gt; &gt; &gt; Was this minutes or 10-minutes:-)<BR>
&gt; &gt; &gt;<BR>
&gt; &gt; &gt; -----Original Message-----<BR>
&gt; &gt; &gt; From: Hannes Tschofenig [<A =
HREF=3D"mailto:Hannes.Tschofenig@gmx.net">mailto:Hannes.Tschofenig@gmx.ne=
t</A>]<BR>
&gt; &gt; &gt; Sent: Wednesday, July 19, 2006 7:56 AM<BR>
&gt; &gt; &gt; To: dime@ietf.org<BR>
&gt; &gt; &gt; Subject: [Dime] IETF#66 Meeting Minutes<BR>
&gt; &gt; &gt;<BR>
&gt; &gt; &gt; Hi all,<BR>
&gt; &gt; &gt;<BR>
&gt; &gt; &gt; please take a look at the meeting minutes:<BR>
&gt; &gt; &gt; <A =
HREF=3D"http://www3.ietf.org/proceedings/06jul/minutes/dime.txt">http://w=
ww3.ietf.org/proceedings/06jul/minutes/dime.txt</A><BR>
&gt; &gt; &gt;<BR>
&gt; &gt; &gt; Ciao<BR>
&gt; &gt; &gt; Hannes<BR>
&gt; &gt; &gt;<BR>
&gt; &gt; &gt; _______________________________________________<BR>
&gt; &gt; &gt; DiME mailing list<BR>
&gt; &gt; &gt; DiME@ietf.org<BR>
&gt; &gt; &gt; <A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/dime">https://www1.ietf.or=
g/mailman/listinfo/dime</A><BR>
&gt; &gt; &gt;<BR>
&gt; &gt; &gt;<BR>
&gt; &gt; &gt;<BR>
&gt; &gt;<BR>
&gt; &gt;<BR>
&gt; &gt;<BR>
&gt; &gt;<BR>
&gt; &gt; _______________________________________________<BR>
&gt; &gt; DiME mailing list<BR>
&gt; &gt; DiME@ietf.org<BR>
&gt; &gt; <A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/dime">https://www1.ietf.or=
g/mailman/listinfo/dime</A><BR>
&gt;<BR>
&gt; --<BR>
&gt; julien.bournelle at int-evry.fr<BR>
&gt;<BR>
&gt;<BR>
<BR>
--<BR>
julien.bournelle at int-evry.fr<BR>
<BR>
<BR>
<BR>
_______________________________________________<BR>
DiME mailing list<BR>
DiME@ietf.org<BR>
<A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/dime">https://www1.ietf.or=
g/mailman/listinfo/dime</A><BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C6C073.62B28000--


--===============1074118190==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============1074118190==--




From dime-bounces@ietf.org Tue Aug 15 10:07:59 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GCzaJ-0006g1-Hf; Tue, 15 Aug 2006 10:07:59 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GCzaI-0006fw-0J
	for dime@ietf.org; Tue, 15 Aug 2006 10:07:58 -0400
Received: from usaga01-in.huawei.com ([12.129.211.51])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCzaC-00069W-JS
	for dime@ietf.org; Tue, 15 Aug 2006 10:07:57 -0400
Received: from huawei.com (usaga01-in [172.18.4.6])
	by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0J4100MSFLRTIO@usaga01-in.huawei.com> for
	dime@ietf.org; Tue, 15 Aug 2006 07:04:41 -0700 (PDT)
Received: from Nakhjiri73701
	(c-24-17-254-79.hsd1.wa.comcast.net [24.17.254.79]) by
	usaga01-in.huawei.com
	(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
	with ESMTPA id <0J4100H8NLRMHS@usaga01-in.huawei.com> for dime@ietf.org;
	Tue, 15 Aug 2006 07:04:41 -0700 (PDT)
Date: Tue, 15 Aug 2006 07:07:38 -0700
From: Madjid Nakhjiri <mnakhjiri@huawei.com>
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???
In-reply-to: <E7CCE8A83907104ABEE91AC3AE3709A01167DA@exchange.bridgewatersys.com>
To: 'Avi Lior' <avi@bridgewatersystems.com>,
	'Julien Bournelle' <julien.bournelle@int-evry.fr>
Message-id: <002d01c6c074$2a8534b0$02fda8c0@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869
X-Mailer: Microsoft Office Outlook 11
Thread-index: Aca7j5pLlwjYezfqQhS35Ix/bK+xSgCBYw0QALeF6YMAABfC8A==
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 8a7d7b1ff9fdb39b8762b25bc5367e56
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0476882287=="
Errors-To: dime-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0476882287==
Content-type: multipart/alternative;
	boundary="Boundary_(ID_SHsp7QGiBByXPOUy/YXmOw)"

This is a multi-part message in MIME format.

--Boundary_(ID_SHsp7QGiBByXPOUy/YXmOw)
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT

Hi Avi,

 

Not sure what "correct" means:-) I am planning on looking a bit closer at
3588 to see exactly how "application" and "App ID" is used.

As I said I _prefer_ adding a new Application ID for Mobile IPv6, but then
both RFC 3588 and 4004 needs to be revised to reflect that, I think the harm
for that is minimal anyway, given the fairly rare deployment of 4004 (I
think).

 

Madjid.

 

  _____  

From: Avi Lior [mailto:avi@bridgewatersystems.com] 
Sent: Tuesday, August 15, 2006 7:01 AM
To: Madjid Nakhjiri; Julien Bournelle
Cc: dime@ietf.org
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???

 

 

How about the correct (IMO) option and that is assign this new application
its own Application ID.  THis afterall is what an Application ID is supposed
to do.



-----Original Message-----
From: Madjid Nakhjiri [mailto:mnakhjiri@huawei.com]
Sent: Fri 8/11/2006 6:49 PM
To: 'Julien Bournelle'
Cc: dime@ietf.org
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???

Hi Julien,

Thanks for pointing me to the archives.
I have one general issue that maybe is related to me not quite understanding
EAP-IKEv2 and that is EAP is run between a peer and an EAP server (in this
case the backend AAA server). EAP-IKEv2 was designed so that a mature
authentication/key management method could be used within EAP framework.
Running EAP-IKEv2 results in authentication of peer to backend AAA, not to
HA and possibly a key between the peer and AAA server. How does this help
the need for IPsec between MN and HA?

Now as far as the discussions on the archives, RFC 4072 only talks about
carrying EAP over Diameter without talking about what EAP is being used for
(your question: mobility versus access service). I think distinguishing
mobility versus access is a AAA signaling issue not an EAP signaling issue.
In RADIUS and MIP4 it is simpler (look at draft-nakhjiri-radius-mip4-02)
because there are attributes related to MIP4 authentication (such as
MIP-MN-AAA-Authenticator, etc) within the Access Request that tells the
server this is about RADIUS. Diameter on the other hand has the notion of
Application ID and should not rely on explicit hint on this. When we got to
the point of trying to translate Diameter messaging to RADIUS, we had to
resort to port types, because Diameter had different messages (depending on
whether HA or FA were involved) while all RADIUS had was Access
Request/Accepts not recognizing between HA and FA.
Here your case is different. Diameter already has an Application ID for
Mobile IP. That is how you distinguish between access and mobility service,
not through service type. Now there are two choices as I said before:

A) revise 3588 to have one App ID for MIPv4 and one for MIPv6 (separate MIP6
split versus integrated through service types). This of course mean revising
4004 to indicate specifically what MIPv4 App ID is.

B) Use the same App ID of 3588 for both MIP4 and MIP6, but then you have to
define 4 service types
1) MIP4 split
2) MIP4 integrated
3) MIP6 split
4) MIP6 integrated.

I prefer A (I can live with B, if you tie a rope to my neck, just kidding).
I think A is cleaner. I think split-integrated versus MIP4-mip6 are two
different degrees of freedom. Just because MIP4 WG did not make the split
integrated distinction, does not mean the business case cannot exist.
Plus that Avi stated that Service type seems to be mandatory.

Madjid

-----Original Message-----
From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr]
Sent: Wednesday, August 09, 2006 1:39 AM
To: Madjid Nakhjiri
Cc: 'Julien Bournelle'; 'Hannes Tschofenig'; dime@ietf.org
Subject: Re: [Dime] MIP6 App ID/ revise RFC 3588???

Hi madjid,

On Tue, Aug 08, 2006 at 04:51:08PM -0700, Madjid Nakhjiri wrote:
> Hi Julien,
>
> I just looked at the RFC 4005 definition of Service_Type.
> The services listed there are quite mixed. I am not quite sure what
> applications besides NASREQ are supposed to support Service_Type? Or is it
> that Mobile IP application assumes NASREQ must be supported?

 Let me try to sum up the issue:

 In the split scenario, the HA acts as a IKEv2 responder and uses EAP
 (oIKEv2) to authenticate the user (of the MN). The HA then relies on a
 EAP/AAA server and thus could use Diameter EAP. THe problem that we
 have here is that we are not performing AAA for "basic" network access
 but for the IPv6 Mobility service. Thus we have the problem of, how the
 AAA server knows that.

 You can take a look at the thread:

 http://www1.ietf.org/mail-archive/web/dime/current/msg00262.html

 for previous discussions on this topic which is still unsolved.

 At this point, as noted in:

 http://www1.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-00.txt

 the 2 options that we have are:

 - define a new Service-Type for "Mobile IPv6 - Split" and puts it in
   DER message (Diameter EAP Request)
 - define a new Application-ID and re-use Diameter EAP messages.

 Hope it helps,

 regards,

 Julien

>
> If one is to go about without modifying RFC 3588 that uses just one App ID
> for Mobile IP, then I guess there is just one choice of having
>
> two Service_types for Mobile IPv6
> and
> one Service_Type for Mobile IPv4,
>
> (3 total for Mobile IP), but then don't you have to modify RFC 4004 to add
> the service_type to Mobile IPv4?
>
> Madjid
>
> -----Original Message-----
> From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr]
> Sent: Monday, August 07, 2006 6:42 AM
> To: Madjid Nakhjiri
> Cc: 'Hannes Tschofenig'; dime@ietf.org
> Subject: Re: [Dime] MIP6 App ID/ was: IETF#66 Meeting Minutes
>
> HI madjid,
>
> On Mon, Aug 07, 2006 at 06:34:55AM -0700, Madjid Nakhjiri wrote:
> > No worries, I was being humorous. I wanted to see what was said during
the
> > meeting regarding the Mobile IP6 drafts. I tried to see the archive
> > discussions, but did not see anything in June or July either.
> > I am seeing all this discussion on the use of App IDs on the ML, so I
> wanted
> > to see if MIP6 is getting its own App ID, or it is using the App ID
> assigned
> > to Mobiloe IP in 3588?
>
>  basically the question is: do we need a specific App ID or do a
>  Service-Type AVP (indicating that it's a HA for the split scenario) is
>  sufficient ?
>
>
>  regards,
>
>  Julien
>
> >
> > R,
> >
> > Madjid
> >
> > -----Original Message-----
> > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
> > Sent: Saturday, August 05, 2006 5:22 AM
> > To: Madjid Nakhjiri
> > Cc: dime@ietf.org
> > Subject: Re: [Dime] IETF#66 Meeting Minutes
> >
> > I agree that the meeting minutes are somewhat brief this time.
> > We will do better with the next IETF meeting...
> >
> > Ciao
> > Hannes
> >
> > Madjid Nakhjiri wrote:
> > > Was this minutes or 10-minutes:-)
> > >
> > > -----Original Message-----
> > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
> > > Sent: Wednesday, July 19, 2006 7:56 AM
> > > To: dime@ietf.org
> > > Subject: [Dime] IETF#66 Meeting Minutes
> > >
> > > Hi all,
> > >
> > > please take a look at the meeting minutes:
> > > http://www3.ietf.org/proceedings/06jul/minutes/dime.txt
> > >
> > > Ciao
> > > Hannes
> > >
> > > _______________________________________________
> > > DiME mailing list
> > > DiME@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/dime
> > >
> > >
> > >
> >
> >
> >
> >
> > _______________________________________________
> > DiME mailing list
> > DiME@ietf.org
> > https://www1.ietf.org/mailman/listinfo/dime
>
> --
> julien.bournelle at int-evry.fr
>
>

--
julien.bournelle at int-evry.fr



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


--Boundary_(ID_SHsp7QGiBByXPOUy/YXmOw)
Content-type: text/html; charset=US-ASCII
Content-transfer-encoding: 7BIT

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<title>RE: [Dime] MIP6 App ID/ revise RFC 3588???</title>
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
p
	{mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=EN-US link=blue vlink=blue>

<div class=Section1>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Hi Avi,<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Not sure what &#8220;correct&#8221; means</span></font><font
size=2 color=navy face=Wingdings><span style='font-size:10.0pt;font-family:
Wingdings;color:navy'>J</span></font><font size=2 color=navy face=Arial><span
style='font-size:10.0pt;font-family:Arial;color:navy'> I am planning on looking
a bit closer at 3588 to see exactly how &#8220;application&#8221; and &#8220;App
ID&#8221; is used.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>As I said I _<i><span style='font-style:
italic'>prefer</span></i>_ adding a new Application ID for Mobile IPv6, but
then both RFC 3588 and 4004 needs to be revised to reflect that, I think the
harm for that is minimal anyway, given the fairly rare deployment of 4004 (I
think).<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Madjid.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div class=MsoNormal align=center style='text-align:center'><font size=3
face="Times New Roman"><span style='font-size:12.0pt'>

<hr size=3 width="100%" align=center tabindex=-1>

</span></font></div>

<p class=MsoNormal><b><font size=2 face=Tahoma><span style='font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=2
face=Tahoma><span style='font-size:10.0pt;font-family:Tahoma'> Avi Lior
[mailto:avi@bridgewatersystems.com] <br>
<b><span style='font-weight:bold'>Sent:</span></b> Tuesday, August 15, 2006
7:01 AM<br>
<b><span style='font-weight:bold'>To:</span></b> Madjid Nakhjiri; Julien
Bournelle<br>
<b><span style='font-weight:bold'>Cc:</span></b> dime@ietf.org<br>
<b><span style='font-weight:bold'>Subject:</span></b> RE: [Dime] MIP6 App ID/
revise RFC 3588???</span></font><o:p></o:p></p>

</div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p style='margin-bottom:12.0pt'><font size=2 face="Times New Roman"><span
style='font-size:10.0pt'>How about the correct (IMO) option and that is assign
this new application its own Application ID.&nbsp; THis afterall is what an
Application ID is supposed to do.<br>
<br>
<br>
<br>
-----Original Message-----<br>
From: Madjid Nakhjiri [<a href="mailto:mnakhjiri@huawei.com">mailto:mnakhjiri@huawei.com</a>]<br>
Sent: Fri 8/11/2006 6:49 PM<br>
To: 'Julien Bournelle'<br>
Cc: dime@ietf.org<br>
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???<br>
<br>
Hi Julien,<br>
<br>
Thanks for pointing me to the archives.<br>
I have one general issue that maybe is related to me not quite understanding<br>
EAP-IKEv2 and that is EAP is run between a peer and an EAP server (in this<br>
case the backend AAA server). EAP-IKEv2 was designed so that a mature<br>
authentication/key management method could be used within EAP framework.<br>
Running EAP-IKEv2 results in authentication of peer to backend AAA, not to<br>
HA and possibly a key between the peer and AAA server. How does this help<br>
the need for IPsec between MN and HA?<br>
<br>
Now as far as the discussions on the archives, RFC 4072 only talks about<br>
carrying EAP over Diameter without talking about what EAP is being used for<br>
(your question: mobility versus access service). I think distinguishing<br>
mobility versus access is a AAA signaling issue not an EAP signaling issue.<br>
In RADIUS and MIP4 it is simpler (look at draft-nakhjiri-radius-mip4-02)<br>
because there are attributes related to MIP4 authentication (such as<br>
MIP-MN-AAA-Authenticator, etc) within the Access Request that tells the<br>
server this is about RADIUS. Diameter on the other hand has the notion of<br>
Application ID and should not rely on explicit hint on this. When we got to<br>
the point of trying to translate Diameter messaging to RADIUS, we had to<br>
resort to port types, because Diameter had different messages (depending on<br>
whether HA or FA were involved) while all RADIUS had was Access<br>
Request/Accepts not recognizing between HA and FA.<br>
Here your case is different. Diameter already has an Application ID for<br>
Mobile IP. That is how you distinguish between access and mobility service,<br>
not through service type. Now there are two choices as I said before:<br>
<br>
A) revise 3588 to have one App ID for MIPv4 and one for MIPv6 (separate MIP6<br>
split versus integrated through service types). This of course mean revising<br>
4004 to indicate specifically what MIPv4 App ID is.<br>
<br>
B) Use the same App ID of 3588 for both MIP4 and MIP6, but then you have to<br>
define 4 service types<br>
1) MIP4 split<br>
2) MIP4 integrated<br>
3) MIP6 split<br>
4) MIP6 integrated.<br>
<br>
I prefer A (I can live with B, if you tie a rope to my neck, just kidding).<br>
I think A is cleaner. I think split-integrated versus MIP4-mip6 are two<br>
different degrees of freedom. Just because MIP4 WG did not make the split<br>
integrated distinction, does not mean the business case cannot exist.<br>
Plus that Avi stated that Service type seems to be mandatory.<br>
<br>
Madjid<br>
<br>
-----Original Message-----<br>
From: Julien Bournelle [<a href="mailto:julien.bournelle@int-evry.fr">mailto:julien.bournelle@int-evry.fr</a>]<br>
Sent: Wednesday, August 09, 2006 1:39 AM<br>
To: Madjid Nakhjiri<br>
Cc: 'Julien Bournelle'; 'Hannes Tschofenig'; dime@ietf.org<br>
Subject: Re: [Dime] MIP6 App ID/ revise RFC 3588???<br>
<br>
Hi madjid,<br>
<br>
On Tue, Aug 08, 2006 at 04:51:08PM -0700, Madjid Nakhjiri wrote:<br>
&gt; Hi Julien,<br>
&gt;<br>
&gt; I just looked at the RFC 4005 definition of Service_Type.<br>
&gt; The services listed there are quite mixed. I am not quite sure what<br>
&gt; applications besides NASREQ are supposed to support Service_Type? Or is it<br>
&gt; that Mobile IP application assumes NASREQ must be supported?<br>
<br>
&nbsp;Let me try to sum up the issue:<br>
<br>
&nbsp;In the split scenario, the HA acts as a IKEv2 responder and uses EAP<br>
&nbsp;(oIKEv2) to authenticate the user (of the MN). The HA then relies on a<br>
&nbsp;EAP/AAA server and thus could use Diameter EAP. THe problem that we<br>
&nbsp;have here is that we are not performing AAA for &quot;basic&quot; network
access<br>
&nbsp;but for the IPv6 Mobility service. Thus we have the problem of, how the<br>
&nbsp;AAA server knows that.<br>
<br>
&nbsp;You can take a look at the thread:<br>
<br>
&nbsp;<a href="http://www1.ietf.org/mail-archive/web/dime/current/msg00262.html">http://www1.ietf.org/mail-archive/web/dime/current/msg00262.html</a><br>
<br>
&nbsp;for previous discussions on this topic which is still unsolved.<br>
<br>
&nbsp;At this point, as noted in:<br>
<br>
&nbsp;<a
href="http://www1.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-00.txt">http://www1.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-00.txt</a><br>
<br>
&nbsp;the 2 options that we have are:<br>
<br>
&nbsp;- define a new Service-Type for &quot;Mobile IPv6 - Split&quot; and puts
it in<br>
&nbsp;&nbsp; DER message (Diameter EAP Request)<br>
&nbsp;- define a new Application-ID and re-use Diameter EAP messages.<br>
<br>
&nbsp;Hope it helps,<br>
<br>
&nbsp;regards,<br>
<br>
&nbsp;Julien<br>
<br>
&gt;<br>
&gt; If one is to go about without modifying RFC 3588 that uses just one App ID<br>
&gt; for Mobile IP, then I guess there is just one choice of having<br>
&gt;<br>
&gt; two Service_types for Mobile IPv6<br>
&gt; and<br>
&gt; one Service_Type for Mobile IPv4,<br>
&gt;<br>
&gt; (3 total for Mobile IP), but then don't you have to modify RFC 4004 to add<br>
&gt; the service_type to Mobile IPv4?<br>
&gt;<br>
&gt; Madjid<br>
&gt;<br>
&gt; -----Original Message-----<br>
&gt; From: Julien Bournelle [<a href="mailto:julien.bournelle@int-evry.fr">mailto:julien.bournelle@int-evry.fr</a>]<br>
&gt; Sent: Monday, August 07, 2006 6:42 AM<br>
&gt; To: Madjid Nakhjiri<br>
&gt; Cc: 'Hannes Tschofenig'; dime@ietf.org<br>
&gt; Subject: Re: [Dime] MIP6 App ID/ was: IETF#66 Meeting Minutes<br>
&gt;<br>
&gt; HI madjid,<br>
&gt;<br>
&gt; On Mon, Aug 07, 2006 at 06:34:55AM -0700, Madjid Nakhjiri wrote:<br>
&gt; &gt; No worries, I was being humorous. I wanted to see what was said
during<br>
the<br>
&gt; &gt; meeting regarding the Mobile IP6 drafts. I tried to see the archive<br>
&gt; &gt; discussions, but did not see anything in June or July either.<br>
&gt; &gt; I am seeing all this discussion on the use of App IDs on the ML, so I<br>
&gt; wanted<br>
&gt; &gt; to see if MIP6 is getting its own App ID, or it is using the App ID<br>
&gt; assigned<br>
&gt; &gt; to Mobiloe IP in 3588?<br>
&gt;<br>
&gt;&nbsp; basically the question is: do we need a specific App ID or do a<br>
&gt;&nbsp; Service-Type AVP (indicating that it's a HA for the split scenario)
is<br>
&gt;&nbsp; sufficient ?<br>
&gt;<br>
&gt;<br>
&gt;&nbsp; regards,<br>
&gt;<br>
&gt;&nbsp; Julien<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt; R,<br>
&gt; &gt;<br>
&gt; &gt; Madjid<br>
&gt; &gt;<br>
&gt; &gt; -----Original Message-----<br>
&gt; &gt; From: Hannes Tschofenig [<a href="mailto:Hannes.Tschofenig@gmx.net">mailto:Hannes.Tschofenig@gmx.net</a>]<br>
&gt; &gt; Sent: Saturday, August 05, 2006 5:22 AM<br>
&gt; &gt; To: Madjid Nakhjiri<br>
&gt; &gt; Cc: dime@ietf.org<br>
&gt; &gt; Subject: Re: [Dime] IETF#66 Meeting Minutes<br>
&gt; &gt;<br>
&gt; &gt; I agree that the meeting minutes are somewhat brief this time.<br>
&gt; &gt; We will do better with the next IETF meeting...<br>
&gt; &gt;<br>
&gt; &gt; Ciao<br>
&gt; &gt; Hannes<br>
&gt; &gt;<br>
&gt; &gt; Madjid Nakhjiri wrote:<br>
&gt; &gt; &gt; Was this minutes or 10-minutes:-)<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; -----Original Message-----<br>
&gt; &gt; &gt; From: Hannes Tschofenig [<a
href="mailto:Hannes.Tschofenig@gmx.net">mailto:Hannes.Tschofenig@gmx.net</a>]<br>
&gt; &gt; &gt; Sent: Wednesday, July 19, 2006 7:56 AM<br>
&gt; &gt; &gt; To: dime@ietf.org<br>
&gt; &gt; &gt; Subject: [Dime] IETF#66 Meeting Minutes<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Hi all,<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; please take a look at the meeting minutes:<br>
&gt; &gt; &gt; <a href="http://www3.ietf.org/proceedings/06jul/minutes/dime.txt">http://www3.ietf.org/proceedings/06jul/minutes/dime.txt</a><br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Ciao<br>
&gt; &gt; &gt; Hannes<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; _______________________________________________<br>
&gt; &gt; &gt; DiME mailing list<br>
&gt; &gt; &gt; DiME@ietf.org<br>
&gt; &gt; &gt; <a href="https://www1.ietf.org/mailman/listinfo/dime">https://www1.ietf.org/mailman/listinfo/dime</a><br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; _______________________________________________<br>
&gt; &gt; DiME mailing list<br>
&gt; &gt; DiME@ietf.org<br>
&gt; &gt; <a href="https://www1.ietf.org/mailman/listinfo/dime">https://www1.ietf.org/mailman/listinfo/dime</a><br>
&gt;<br>
&gt; --<br>
&gt; julien.bournelle at int-evry.fr<br>
&gt;<br>
&gt;<br>
<br>
--<br>
julien.bournelle at int-evry.fr<br>
<br>
<br>
<br>
_______________________________________________<br>
DiME mailing list<br>
DiME@ietf.org<br>
<a href="https://www1.ietf.org/mailman/listinfo/dime">https://www1.ietf.org/mailman/listinfo/dime</a></span></font><o:p></o:p></p>

</div>

</body>

</html>

--Boundary_(ID_SHsp7QGiBByXPOUy/YXmOw)--


--===============0476882287==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0476882287==--




From dime-bounces@ietf.org Tue Aug 15 10:24:00 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GCzpO-0002uB-1k; Tue, 15 Aug 2006 10:23:34 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GCzpN-0002u6-Ia
	for dime@ietf.org; Tue, 15 Aug 2006 10:23:33 -0400
Received: from bws14.bridgewatersystems.com ([216.113.7.14]
	helo=exchange.bridgewatersys.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GCzpG-0007kn-Aa
	for dime@ietf.org; Tue, 15 Aug 2006 10:23:33 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???
Date: Tue, 15 Aug 2006 10:24:31 -0400
Message-ID: <E7CCE8A83907104ABEE91AC3AE3709A01167DC@exchange.bridgewatersys.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Dime] MIP6 App ID/ revise RFC 3588???
Thread-Index: Aca7j5pLlwjYezfqQhS35Ix/bK+xSgCBYw0QALeF6YMAABfC8AAAO289
References: <002d01c6c074$2a8534b0$02fda8c0@china.huawei.com>
From: "Avi Lior" <avi@bridgewatersystems.com>
To: "Madjid Nakhjiri" <mnakhjiri@huawei.com>,
	"Julien Bournelle" <julien.bournelle@int-evry.fr>
X-Spam-Score: 0.6 (/)
X-Scan-Signature: 8897a8f96c648179e32cc9ffbb0aaffd
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0609930476=="
Errors-To: dime-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0609930476==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C6C076.85DCCB26"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6C076.85DCCB26
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


I don't think RFC3588 needs to be touched when adding an new Application =
ID. Neither should

Why do you think you need to touch 3588 or 4004?

-----Original Message-----
From: Madjid Nakhjiri [mailto:mnakhjiri@huawei.com]
Sent: Tue 8/15/2006 10:07 AM
To: Avi Lior; 'Julien Bournelle'
Cc: dime@ietf.org; 'Madjid Nakhjiri'
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???
=20
Hi Avi,

=20

Not sure what "correct" meansJ I am planning on looking a bit closer at =
3588 to see exactly how "application" and "App ID" is used.

As I said I _prefer_ adding a new Application ID for Mobile IPv6, but =
then both RFC 3588 and 4004 needs to be revised to reflect that, I think =
the harm for that is minimal anyway, given the fairly rare deployment of =
4004 (I think).

=20

Madjid.

=20

________________________________

From: Avi Lior [mailto:avi@bridgewatersystems.com]=20
Sent: Tuesday, August 15, 2006 7:01 AM
To: Madjid Nakhjiri; Julien Bournelle
Cc: dime@ietf.org
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???

=20

=20

How about the correct (IMO) option and that is assign this new =
application its own Application ID.  THis afterall is what an =
Application ID is supposed to do.



-----Original Message-----
From: Madjid Nakhjiri [mailto:mnakhjiri@huawei.com]
Sent: Fri 8/11/2006 6:49 PM
To: 'Julien Bournelle'
Cc: dime@ietf.org
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???

Hi Julien,

Thanks for pointing me to the archives.
I have one general issue that maybe is related to me not quite =
understanding
EAP-IKEv2 and that is EAP is run between a peer and an EAP server (in =
this
case the backend AAA server). EAP-IKEv2 was designed so that a mature
authentication/key management method could be used within EAP framework.
Running EAP-IKEv2 results in authentication of peer to backend AAA, not =
to
HA and possibly a key between the peer and AAA server. How does this =
help
the need for IPsec between MN and HA?

Now as far as the discussions on the archives, RFC 4072 only talks about
carrying EAP over Diameter without talking about what EAP is being used =
for
(your question: mobility versus access service). I think distinguishing
mobility versus access is a AAA signaling issue not an EAP signaling =
issue.
In RADIUS and MIP4 it is simpler (look at draft-nakhjiri-radius-mip4-02)
because there are attributes related to MIP4 authentication (such as
MIP-MN-AAA-Authenticator, etc) within the Access Request that tells the
server this is about RADIUS. Diameter on the other hand has the notion =
of
Application ID and should not rely on explicit hint on this. When we got =
to
the point of trying to translate Diameter messaging to RADIUS, we had to
resort to port types, because Diameter had different messages (depending =
on
whether HA or FA were involved) while all RADIUS had was Access
Request/Accepts not recognizing between HA and FA.
Here your case is different. Diameter already has an Application ID for
Mobile IP. That is how you distinguish between access and mobility =
service,
not through service type. Now there are two choices as I said before:

A) revise 3588 to have one App ID for MIPv4 and one for MIPv6 (separate =
MIP6
split versus integrated through service types). This of course mean =
revising
4004 to indicate specifically what MIPv4 App ID is.

B) Use the same App ID of 3588 for both MIP4 and MIP6, but then you have =
to
define 4 service types
1) MIP4 split
2) MIP4 integrated
3) MIP6 split
4) MIP6 integrated.

I prefer A (I can live with B, if you tie a rope to my neck, just =
kidding).
I think A is cleaner. I think split-integrated versus MIP4-mip6 are two
different degrees of freedom. Just because MIP4 WG did not make the =
split
integrated distinction, does not mean the business case cannot exist.
Plus that Avi stated that Service type seems to be mandatory.

Madjid

-----Original Message-----
From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr]
Sent: Wednesday, August 09, 2006 1:39 AM
To: Madjid Nakhjiri
Cc: 'Julien Bournelle'; 'Hannes Tschofenig'; dime@ietf.org
Subject: Re: [Dime] MIP6 App ID/ revise RFC 3588???

Hi madjid,

On Tue, Aug 08, 2006 at 04:51:08PM -0700, Madjid Nakhjiri wrote:
> Hi Julien,
>
> I just looked at the RFC 4005 definition of Service_Type.
> The services listed there are quite mixed. I am not quite sure what
> applications besides NASREQ are supposed to support Service_Type? Or =
is it
> that Mobile IP application assumes NASREQ must be supported?

 Let me try to sum up the issue:

 In the split scenario, the HA acts as a IKEv2 responder and uses EAP
 (oIKEv2) to authenticate the user (of the MN). The HA then relies on a
 EAP/AAA server and thus could use Diameter EAP. THe problem that we
 have here is that we are not performing AAA for "basic" network access
 but for the IPv6 Mobility service. Thus we have the problem of, how the
 AAA server knows that.

 You can take a look at the thread:

 http://www1.ietf.org/mail-archive/web/dime/current/msg00262.html

 for previous discussions on this topic which is still unsolved.

 At this point, as noted in:

 http://www1.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-00.txt

 the 2 options that we have are:

 - define a new Service-Type for "Mobile IPv6 - Split" and puts it in
   DER message (Diameter EAP Request)
 - define a new Application-ID and re-use Diameter EAP messages.

 Hope it helps,

 regards,

 Julien

>
> If one is to go about without modifying RFC 3588 that uses just one =
App ID
> for Mobile IP, then I guess there is just one choice of having
>
> two Service_types for Mobile IPv6
> and
> one Service_Type for Mobile IPv4,
>
> (3 total for Mobile IP), but then don't you have to modify RFC 4004 to =
add
> the service_type to Mobile IPv4?
>
> Madjid
>
> -----Original Message-----
> From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr]
> Sent: Monday, August 07, 2006 6:42 AM
> To: Madjid Nakhjiri
> Cc: 'Hannes Tschofenig'; dime@ietf.org
> Subject: Re: [Dime] MIP6 App ID/ was: IETF#66 Meeting Minutes
>
> HI madjid,
>
> On Mon, Aug 07, 2006 at 06:34:55AM -0700, Madjid Nakhjiri wrote:
> > No worries, I was being humorous. I wanted to see what was said =
during
the
> > meeting regarding the Mobile IP6 drafts. I tried to see the archive
> > discussions, but did not see anything in June or July either.
> > I am seeing all this discussion on the use of App IDs on the ML, so =
I
> wanted
> > to see if MIP6 is getting its own App ID, or it is using the App ID
> assigned
> > to Mobiloe IP in 3588?
>
>  basically the question is: do we need a specific App ID or do a
>  Service-Type AVP (indicating that it's a HA for the split scenario) =
is
>  sufficient ?
>
>
>  regards,
>
>  Julien
>
> >
> > R,
> >
> > Madjid
> >
> > -----Original Message-----
> > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
> > Sent: Saturday, August 05, 2006 5:22 AM
> > To: Madjid Nakhjiri
> > Cc: dime@ietf.org
> > Subject: Re: [Dime] IETF#66 Meeting Minutes
> >
> > I agree that the meeting minutes are somewhat brief this time.
> > We will do better with the next IETF meeting...
> >
> > Ciao
> > Hannes
> >
> > Madjid Nakhjiri wrote:
> > > Was this minutes or 10-minutes:-)
> > >
> > > -----Original Message-----
> > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
> > > Sent: Wednesday, July 19, 2006 7:56 AM
> > > To: dime@ietf.org
> > > Subject: [Dime] IETF#66 Meeting Minutes
> > >
> > > Hi all,
> > >
> > > please take a look at the meeting minutes:
> > > http://www3.ietf.org/proceedings/06jul/minutes/dime.txt
> > >
> > > Ciao
> > > Hannes
> > >
> > > _______________________________________________
> > > DiME mailing list
> > > DiME@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/dime
> > >
> > >
> > >
> >
> >
> >
> >
> > _______________________________________________
> > DiME mailing list
> > DiME@ietf.org
> > https://www1.ietf.org/mailman/listinfo/dime
>
> --
> julien.bournelle at int-evry.fr
>
>

--
julien.bournelle at int-evry.fr



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



------_=_NextPart_001_01C6C076.85DCCB26
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 =
6.5.7650.28">
<TITLE>RE: [Dime] MIP6 App ID/ revise RFC 3588???</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<BR>

<P><FONT SIZE=3D2>I don't think RFC3588 needs to be touched when adding =
an new Application ID. Neither should<BR>
<BR>
Why do you think you need to touch 3588 or 4004?<BR>
<BR>
-----Original Message-----<BR>
From: Madjid Nakhjiri [<A =
HREF=3D"mailto:mnakhjiri@huawei.com">mailto:mnakhjiri@huawei.com</A>]<BR>=

Sent: Tue 8/15/2006 10:07 AM<BR>
To: Avi Lior; 'Julien Bournelle'<BR>
Cc: dime@ietf.org; 'Madjid Nakhjiri'<BR>
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???<BR>
<BR>
Hi Avi,<BR>
<BR>
<BR>
<BR>
Not sure what &quot;correct&quot; meansJ I am planning on looking a bit =
closer at 3588 to see exactly how &quot;application&quot; and &quot;App =
ID&quot; is used.<BR>
<BR>
As I said I _prefer_ adding a new Application ID for Mobile IPv6, but =
then both RFC 3588 and 4004 needs to be revised to reflect that, I think =
the harm for that is minimal anyway, given the fairly rare deployment of =
4004 (I think).<BR>
<BR>
<BR>
<BR>
Madjid.<BR>
<BR>
<BR>
<BR>
________________________________<BR>
<BR>
From: Avi Lior [<A =
HREF=3D"mailto:avi@bridgewatersystems.com">mailto:avi@bridgewatersystems.=
com</A>]<BR>
Sent: Tuesday, August 15, 2006 7:01 AM<BR>
To: Madjid Nakhjiri; Julien Bournelle<BR>
Cc: dime@ietf.org<BR>
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
How about the correct (IMO) option and that is assign this new =
application its own Application ID.&nbsp; THis afterall is what an =
Application ID is supposed to do.<BR>
<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: Madjid Nakhjiri [<A =
HREF=3D"mailto:mnakhjiri@huawei.com">mailto:mnakhjiri@huawei.com</A>]<BR>=

Sent: Fri 8/11/2006 6:49 PM<BR>
To: 'Julien Bournelle'<BR>
Cc: dime@ietf.org<BR>
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???<BR>
<BR>
Hi Julien,<BR>
<BR>
Thanks for pointing me to the archives.<BR>
I have one general issue that maybe is related to me not quite =
understanding<BR>
EAP-IKEv2 and that is EAP is run between a peer and an EAP server (in =
this<BR>
case the backend AAA server). EAP-IKEv2 was designed so that a =
mature<BR>
authentication/key management method could be used within EAP =
framework.<BR>
Running EAP-IKEv2 results in authentication of peer to backend AAA, not =
to<BR>
HA and possibly a key between the peer and AAA server. How does this =
help<BR>
the need for IPsec between MN and HA?<BR>
<BR>
Now as far as the discussions on the archives, RFC 4072 only talks =
about<BR>
carrying EAP over Diameter without talking about what EAP is being used =
for<BR>
(your question: mobility versus access service). I think =
distinguishing<BR>
mobility versus access is a AAA signaling issue not an EAP signaling =
issue.<BR>
In RADIUS and MIP4 it is simpler (look at =
draft-nakhjiri-radius-mip4-02)<BR>
because there are attributes related to MIP4 authentication (such as<BR>
MIP-MN-AAA-Authenticator, etc) within the Access Request that tells =
the<BR>
server this is about RADIUS. Diameter on the other hand has the notion =
of<BR>
Application ID and should not rely on explicit hint on this. When we got =
to<BR>
the point of trying to translate Diameter messaging to RADIUS, we had =
to<BR>
resort to port types, because Diameter had different messages (depending =
on<BR>
whether HA or FA were involved) while all RADIUS had was Access<BR>
Request/Accepts not recognizing between HA and FA.<BR>
Here your case is different. Diameter already has an Application ID =
for<BR>
Mobile IP. That is how you distinguish between access and mobility =
service,<BR>
not through service type. Now there are two choices as I said =
before:<BR>
<BR>
A) revise 3588 to have one App ID for MIPv4 and one for MIPv6 (separate =
MIP6<BR>
split versus integrated through service types). This of course mean =
revising<BR>
4004 to indicate specifically what MIPv4 App ID is.<BR>
<BR>
B) Use the same App ID of 3588 for both MIP4 and MIP6, but then you have =
to<BR>
define 4 service types<BR>
1) MIP4 split<BR>
2) MIP4 integrated<BR>
3) MIP6 split<BR>
4) MIP6 integrated.<BR>
<BR>
I prefer A (I can live with B, if you tie a rope to my neck, just =
kidding).<BR>
I think A is cleaner. I think split-integrated versus MIP4-mip6 are =
two<BR>
different degrees of freedom. Just because MIP4 WG did not make the =
split<BR>
integrated distinction, does not mean the business case cannot =
exist.<BR>
Plus that Avi stated that Service type seems to be mandatory.<BR>
<BR>
Madjid<BR>
<BR>
-----Original Message-----<BR>
From: Julien Bournelle [<A =
HREF=3D"mailto:julien.bournelle@int-evry.fr">mailto:julien.bournelle@int-=
evry.fr</A>]<BR>
Sent: Wednesday, August 09, 2006 1:39 AM<BR>
To: Madjid Nakhjiri<BR>
Cc: 'Julien Bournelle'; 'Hannes Tschofenig'; dime@ietf.org<BR>
Subject: Re: [Dime] MIP6 App ID/ revise RFC 3588???<BR>
<BR>
Hi madjid,<BR>
<BR>
On Tue, Aug 08, 2006 at 04:51:08PM -0700, Madjid Nakhjiri wrote:<BR>
&gt; Hi Julien,<BR>
&gt;<BR>
&gt; I just looked at the RFC 4005 definition of Service_Type.<BR>
&gt; The services listed there are quite mixed. I am not quite sure =
what<BR>
&gt; applications besides NASREQ are supposed to support Service_Type? =
Or is it<BR>
&gt; that Mobile IP application assumes NASREQ must be supported?<BR>
<BR>
&nbsp;Let me try to sum up the issue:<BR>
<BR>
&nbsp;In the split scenario, the HA acts as a IKEv2 responder and uses =
EAP<BR>
&nbsp;(oIKEv2) to authenticate the user (of the MN). The HA then relies =
on a<BR>
&nbsp;EAP/AAA server and thus could use Diameter EAP. THe problem that =
we<BR>
&nbsp;have here is that we are not performing AAA for &quot;basic&quot; =
network access<BR>
&nbsp;but for the IPv6 Mobility service. Thus we have the problem of, =
how the<BR>
&nbsp;AAA server knows that.<BR>
<BR>
&nbsp;You can take a look at the thread:<BR>
<BR>
&nbsp;<A =
HREF=3D"http://www1.ietf.org/mail-archive/web/dime/current/msg00262.html"=
>http://www1.ietf.org/mail-archive/web/dime/current/msg00262.html</A><BR>=

<BR>
&nbsp;for previous discussions on this topic which is still =
unsolved.<BR>
<BR>
&nbsp;At this point, as noted in:<BR>
<BR>
&nbsp;<A =
HREF=3D"http://www1.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-0=
0.txt">http://www1.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-00=
.txt</A><BR>
<BR>
&nbsp;the 2 options that we have are:<BR>
<BR>
&nbsp;- define a new Service-Type for &quot;Mobile IPv6 - Split&quot; =
and puts it in<BR>
&nbsp;&nbsp; DER message (Diameter EAP Request)<BR>
&nbsp;- define a new Application-ID and re-use Diameter EAP =
messages.<BR>
<BR>
&nbsp;Hope it helps,<BR>
<BR>
&nbsp;regards,<BR>
<BR>
&nbsp;Julien<BR>
<BR>
&gt;<BR>
&gt; If one is to go about without modifying RFC 3588 that uses just one =
App ID<BR>
&gt; for Mobile IP, then I guess there is just one choice of having<BR>
&gt;<BR>
&gt; two Service_types for Mobile IPv6<BR>
&gt; and<BR>
&gt; one Service_Type for Mobile IPv4,<BR>
&gt;<BR>
&gt; (3 total for Mobile IP), but then don't you have to modify RFC 4004 =
to add<BR>
&gt; the service_type to Mobile IPv4?<BR>
&gt;<BR>
&gt; Madjid<BR>
&gt;<BR>
&gt; -----Original Message-----<BR>
&gt; From: Julien Bournelle [<A =
HREF=3D"mailto:julien.bournelle@int-evry.fr">mailto:julien.bournelle@int-=
evry.fr</A>]<BR>
&gt; Sent: Monday, August 07, 2006 6:42 AM<BR>
&gt; To: Madjid Nakhjiri<BR>
&gt; Cc: 'Hannes Tschofenig'; dime@ietf.org<BR>
&gt; Subject: Re: [Dime] MIP6 App ID/ was: IETF#66 Meeting Minutes<BR>
&gt;<BR>
&gt; HI madjid,<BR>
&gt;<BR>
&gt; On Mon, Aug 07, 2006 at 06:34:55AM -0700, Madjid Nakhjiri =
wrote:<BR>
&gt; &gt; No worries, I was being humorous. I wanted to see what was =
said during<BR>
the<BR>
&gt; &gt; meeting regarding the Mobile IP6 drafts. I tried to see the =
archive<BR>
&gt; &gt; discussions, but did not see anything in June or July =
either.<BR>
&gt; &gt; I am seeing all this discussion on the use of App IDs on the =
ML, so I<BR>
&gt; wanted<BR>
&gt; &gt; to see if MIP6 is getting its own App ID, or it is using the =
App ID<BR>
&gt; assigned<BR>
&gt; &gt; to Mobiloe IP in 3588?<BR>
&gt;<BR>
&gt;&nbsp; basically the question is: do we need a specific App ID or do =
a<BR>
&gt;&nbsp; Service-Type AVP (indicating that it's a HA for the split =
scenario) is<BR>
&gt;&nbsp; sufficient ?<BR>
&gt;<BR>
&gt;<BR>
&gt;&nbsp; regards,<BR>
&gt;<BR>
&gt;&nbsp; Julien<BR>
&gt;<BR>
&gt; &gt;<BR>
&gt; &gt; R,<BR>
&gt; &gt;<BR>
&gt; &gt; Madjid<BR>
&gt; &gt;<BR>
&gt; &gt; -----Original Message-----<BR>
&gt; &gt; From: Hannes Tschofenig [<A =
HREF=3D"mailto:Hannes.Tschofenig@gmx.net">mailto:Hannes.Tschofenig@gmx.ne=
t</A>]<BR>
&gt; &gt; Sent: Saturday, August 05, 2006 5:22 AM<BR>
&gt; &gt; To: Madjid Nakhjiri<BR>
&gt; &gt; Cc: dime@ietf.org<BR>
&gt; &gt; Subject: Re: [Dime] IETF#66 Meeting Minutes<BR>
&gt; &gt;<BR>
&gt; &gt; I agree that the meeting minutes are somewhat brief this =
time.<BR>
&gt; &gt; We will do better with the next IETF meeting...<BR>
&gt; &gt;<BR>
&gt; &gt; Ciao<BR>
&gt; &gt; Hannes<BR>
&gt; &gt;<BR>
&gt; &gt; Madjid Nakhjiri wrote:<BR>
&gt; &gt; &gt; Was this minutes or 10-minutes:-)<BR>
&gt; &gt; &gt;<BR>
&gt; &gt; &gt; -----Original Message-----<BR>
&gt; &gt; &gt; From: Hannes Tschofenig [<A =
HREF=3D"mailto:Hannes.Tschofenig@gmx.net">mailto:Hannes.Tschofenig@gmx.ne=
t</A>]<BR>
&gt; &gt; &gt; Sent: Wednesday, July 19, 2006 7:56 AM<BR>
&gt; &gt; &gt; To: dime@ietf.org<BR>
&gt; &gt; &gt; Subject: [Dime] IETF#66 Meeting Minutes<BR>
&gt; &gt; &gt;<BR>
&gt; &gt; &gt; Hi all,<BR>
&gt; &gt; &gt;<BR>
&gt; &gt; &gt; please take a look at the meeting minutes:<BR>
&gt; &gt; &gt; <A =
HREF=3D"http://www3.ietf.org/proceedings/06jul/minutes/dime.txt">http://w=
ww3.ietf.org/proceedings/06jul/minutes/dime.txt</A><BR>
&gt; &gt; &gt;<BR>
&gt; &gt; &gt; Ciao<BR>
&gt; &gt; &gt; Hannes<BR>
&gt; &gt; &gt;<BR>
&gt; &gt; &gt; _______________________________________________<BR>
&gt; &gt; &gt; DiME mailing list<BR>
&gt; &gt; &gt; DiME@ietf.org<BR>
&gt; &gt; &gt; <A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/dime">https://www1.ietf.or=
g/mailman/listinfo/dime</A><BR>
&gt; &gt; &gt;<BR>
&gt; &gt; &gt;<BR>
&gt; &gt; &gt;<BR>
&gt; &gt;<BR>
&gt; &gt;<BR>
&gt; &gt;<BR>
&gt; &gt;<BR>
&gt; &gt; _______________________________________________<BR>
&gt; &gt; DiME mailing list<BR>
&gt; &gt; DiME@ietf.org<BR>
&gt; &gt; <A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/dime">https://www1.ietf.or=
g/mailman/listinfo/dime</A><BR>
&gt;<BR>
&gt; --<BR>
&gt; julien.bournelle at int-evry.fr<BR>
&gt;<BR>
&gt;<BR>
<BR>
--<BR>
julien.bournelle at int-evry.fr<BR>
<BR>
<BR>
<BR>
_______________________________________________<BR>
DiME mailing list<BR>
DiME@ietf.org<BR>
<A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/dime">https://www1.ietf.or=
g/mailman/listinfo/dime</A><BR>
<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C6C076.85DCCB26--


--===============0609930476==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0609930476==--




From dime-bounces@ietf.org Tue Aug 15 12:10:55 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GD1VA-0001kc-JM; Tue, 15 Aug 2006 12:10:48 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GD1V9-0001kX-2m
	for dime@ietf.org; Tue, 15 Aug 2006 12:10:47 -0400
Received: from usaga01-in.huawei.com ([12.129.211.51])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD1Uy-0005py-2K
	for dime@ietf.org; Tue, 15 Aug 2006 12:10:47 -0400
Received: from huawei.com (usaga01-in [172.18.4.6])
	by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0J4100MP8RGEIO@usaga01-in.huawei.com> for
	dime@ietf.org; Tue, 15 Aug 2006 09:07:27 -0700 (PDT)
Received: from Nakhjiri73701
	(pool-71-112-12-134.sttlwa.dsl-w.verizon.net [71.112.12.134])
	by usaga01-in.huawei.com
	(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
	with ESMTPA id <0J4100F09RFXUU@usaga01-in.huawei.com> for dime@ietf.org;
	Tue, 15 Aug 2006 09:07:26 -0700 (PDT)
Date: Tue, 15 Aug 2006 09:10:16 -0700
From: Madjid Nakhjiri <mnakhjiri@huawei.com>
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???
In-reply-to: <E7CCE8A83907104ABEE91AC3AE3709A01167DC@exchange.bridgewatersys.com>
To: 'Avi Lior' <avi@bridgewatersystems.com>,
	'Julien Bournelle' <julien.bournelle@int-evry.fr>
Message-id: <001801c6c085$4e985fb0$2f01a8c0@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869
X-Mailer: Microsoft Office Outlook 11
Thread-index: Aca7j5pLlwjYezfqQhS35Ix/bK+xSgCBYw0QALeF6YMAABfC8AAAO289AAQhW/A=
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 4824b9ef1b1988f2983d420e78cedc0a
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1254898596=="
Errors-To: dime-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1254898596==
Content-type: multipart/alternative;
	boundary="Boundary_(ID_d9Aui2mQZEi1hpH2F89TzQ)"

This is a multi-part message in MIME format.

--Boundary_(ID_d9Aui2mQZEi1hpH2F89TzQ)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

Because RFC 3588 defines a single Application ID for Mobile IP and 3588 is
being revised anyway.

If this was a brand new application, it would not matter, but you already
have one App ID for Mobile IP, that could only be used for MIP4, if you now
define a different App ID for Mip6.

 

  _____  

From: Avi Lior [mailto:avi@bridgewatersystems.com] 
Sent: Tuesday, August 15, 2006 7:25 AM
To: Madjid Nakhjiri; Julien Bournelle
Cc: dime@ietf.org
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???

 

 

I don't think RFC3588 needs to be touched when adding an new Application ID.
Neither should

Why do you think you need to touch 3588 or 4004?

-----Original Message-----
From: Madjid Nakhjiri [mailto:mnakhjiri@huawei.com]
Sent: Tue 8/15/2006 10:07 AM
To: Avi Lior; 'Julien Bournelle'
Cc: dime@ietf.org; 'Madjid Nakhjiri'
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???

Hi Avi,



Not sure what "correct" meansJ I am planning on looking a bit closer at 3588
to see exactly how "application" and "App ID" is used.

As I said I _prefer_ adding a new Application ID for Mobile IPv6, but then
both RFC 3588 and 4004 needs to be revised to reflect that, I think the harm
for that is minimal anyway, given the fairly rare deployment of 4004 (I
think).



Madjid.



________________________________

From: Avi Lior [mailto:avi@bridgewatersystems.com]
Sent: Tuesday, August 15, 2006 7:01 AM
To: Madjid Nakhjiri; Julien Bournelle
Cc: dime@ietf.org
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???





How about the correct (IMO) option and that is assign this new application
its own Application ID.  THis afterall is what an Application ID is supposed
to do.



-----Original Message-----
From: Madjid Nakhjiri [mailto:mnakhjiri@huawei.com]
Sent: Fri 8/11/2006 6:49 PM
To: 'Julien Bournelle'
Cc: dime@ietf.org
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???

Hi Julien,

Thanks for pointing me to the archives.
I have one general issue that maybe is related to me not quite understanding
EAP-IKEv2 and that is EAP is run between a peer and an EAP server (in this
case the backend AAA server). EAP-IKEv2 was designed so that a mature
authentication/key management method could be used within EAP framework.
Running EAP-IKEv2 results in authentication of peer to backend AAA, not to
HA and possibly a key between the peer and AAA server. How does this help
the need for IPsec between MN and HA?

Now as far as the discussions on the archives, RFC 4072 only talks about
carrying EAP over Diameter without talking about what EAP is being used for
(your question: mobility versus access service). I think distinguishing
mobility versus access is a AAA signaling issue not an EAP signaling issue.
In RADIUS and MIP4 it is simpler (look at draft-nakhjiri-radius-mip4-02)
because there are attributes related to MIP4 authentication (such as
MIP-MN-AAA-Authenticator, etc) within the Access Request that tells the
server this is about RADIUS. Diameter on the other hand has the notion of
Application ID and should not rely on explicit hint on this. When we got to
the point of trying to translate Diameter messaging to RADIUS, we had to
resort to port types, because Diameter had different messages (depending on
whether HA or FA were involved) while all RADIUS had was Access
Request/Accepts not recognizing between HA and FA.
Here your case is different. Diameter already has an Application ID for
Mobile IP. That is how you distinguish between access and mobility service,
not through service type. Now there are two choices as I said before:

A) revise 3588 to have one App ID for MIPv4 and one for MIPv6 (separate MIP6
split versus integrated through service types). This of course mean revising
4004 to indicate specifically what MIPv4 App ID is.

B) Use the same App ID of 3588 for both MIP4 and MIP6, but then you have to
define 4 service types
1) MIP4 split
2) MIP4 integrated
3) MIP6 split
4) MIP6 integrated.

I prefer A (I can live with B, if you tie a rope to my neck, just kidding).
I think A is cleaner. I think split-integrated versus MIP4-mip6 are two
different degrees of freedom. Just because MIP4 WG did not make the split
integrated distinction, does not mean the business case cannot exist.
Plus that Avi stated that Service type seems to be mandatory.

Madjid

-----Original Message-----
From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr]
Sent: Wednesday, August 09, 2006 1:39 AM
To: Madjid Nakhjiri
Cc: 'Julien Bournelle'; 'Hannes Tschofenig'; dime@ietf.org
Subject: Re: [Dime] MIP6 App ID/ revise RFC 3588???

Hi madjid,

On Tue, Aug 08, 2006 at 04:51:08PM -0700, Madjid Nakhjiri wrote:
> Hi Julien,
>
> I just looked at the RFC 4005 definition of Service_Type.
> The services listed there are quite mixed. I am not quite sure what
> applications besides NASREQ are supposed to support Service_Type? Or is it
> that Mobile IP application assumes NASREQ must be supported?

 Let me try to sum up the issue:

 In the split scenario, the HA acts as a IKEv2 responder and uses EAP
 (oIKEv2) to authenticate the user (of the MN). The HA then relies on a
 EAP/AAA server and thus could use Diameter EAP. THe problem that we
 have here is that we are not performing AAA for "basic" network access
 but for the IPv6 Mobility service. Thus we have the problem of, how the
 AAA server knows that.

 You can take a look at the thread:

 http://www1.ietf.org/mail-archive/web/dime/current/msg00262.html

 for previous discussions on this topic which is still unsolved.

 At this point, as noted in:

 http://www1.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-00.txt

 the 2 options that we have are:

 - define a new Service-Type for "Mobile IPv6 - Split" and puts it in
   DER message (Diameter EAP Request)
 - define a new Application-ID and re-use Diameter EAP messages.

 Hope it helps,

 regards,

 Julien

>
> If one is to go about without modifying RFC 3588 that uses just one App ID
> for Mobile IP, then I guess there is just one choice of having
>
> two Service_types for Mobile IPv6
> and
> one Service_Type for Mobile IPv4,
>
> (3 total for Mobile IP), but then don't you have to modify RFC 4004 to add
> the service_type to Mobile IPv4?
>
> Madjid
>
> -----Original Message-----
> From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr]
> Sent: Monday, August 07, 2006 6:42 AM
> To: Madjid Nakhjiri
> Cc: 'Hannes Tschofenig'; dime@ietf.org
> Subject: Re: [Dime] MIP6 App ID/ was: IETF#66 Meeting Minutes
>
> HI madjid,
>
> On Mon, Aug 07, 2006 at 06:34:55AM -0700, Madjid Nakhjiri wrote:
> > No worries, I was being humorous. I wanted to see what was said during
the
> > meeting regarding the Mobile IP6 drafts. I tried to see the archive
> > discussions, but did not see anything in June or July either.
> > I am seeing all this discussion on the use of App IDs on the ML, so I
> wanted

> > to see if MIP6 is getting its own App ID, or it is using the App ID
> assigned
> > to Mobiloe IP in 3588?
>
>  basically the question is: do we need a specific App ID or do a
>  Service-Type AVP (indicating that it's a HA for the split scenario) is
>  sufficient ?
>
>
>  regards,
>
>  Julien
>
> >
> > R,
> >
> > Madjid
> >
> > -----Original Message-----
> > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
> > Sent: Saturday, August 05, 2006 5:22 AM
> > To: Madjid Nakhjiri
> > Cc: dime@ietf.org
> > Subject: Re: [Dime] IETF#66 Meeting Minutes
> >
> > I agree that the meeting minutes are somewhat brief this time.
> > We will do better with the next IETF meeting...
> >
> > Ciao
> > Hannes
> >
> > Madjid Nakhjiri wrote:
> > > Was this minutes or 10-minutes:-)
> > >
> > > -----Original Message-----
> > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
> > > Sent: Wednesday, July 19, 2006 7:56 AM
> > > To: dime@ietf.org
> > > Subject: [Dime] IETF#66 Meeting Minutes
> > >
> > > Hi all,
> > >
> > > please take a look at the meeting minutes:
> > > http://www3.ietf.org/proceedings/06jul/minutes/dime.txt
> > >
> > > Ciao
> > > Hannes
> > >
> > > _______________________________________________
> > > DiME mailing list
> > > DiME@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/dime
> > >
> > >
> > >
> >
> >
> >
> >
> > _______________________________________________
> > DiME mailing list
> > DiME@ietf.org
> > https://www1.ietf.org/mailman/listinfo/dime
>
> --
> julien.bournelle at int-evry.fr
>
>

--
julien.bournelle at int-evry.fr



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




--Boundary_(ID_d9Aui2mQZEi1hpH2F89TzQ)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<title>RE: [Dime] MIP6 App ID/ revise RFC 3588???</title>
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
p
	{mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=EN-US link=blue vlink=blue>

<div class=Section1>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Because RFC 3588 defines a single
Application ID for Mobile IP and 3588 is being revised anyway.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>If this was a brand new application, it
would not matter, but you already have one App ID for Mobile IP, that could
only be used for MIP4, if you now define a different App ID for Mip6.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div class=MsoNormal align=center style='text-align:center'><font size=3
face="Times New Roman"><span style='font-size:12.0pt'>

<hr size=3 width="100%" align=center tabindex=-1>

</span></font></div>

<p class=MsoNormal><b><font size=2 face=Tahoma><span style='font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=2
face=Tahoma><span style='font-size:10.0pt;font-family:Tahoma'> Avi Lior
[mailto:avi@bridgewatersystems.com] <br>
<b><span style='font-weight:bold'>Sent:</span></b> Tuesday, August 15, 2006
7:25 AM<br>
<b><span style='font-weight:bold'>To:</span></b> Madjid Nakhjiri; Julien
Bournelle<br>
<b><span style='font-weight:bold'>Cc:</span></b> dime@ietf.org<br>
<b><span style='font-weight:bold'>Subject:</span></b> RE: [Dime] MIP6 App ID/
revise RFC 3588???</span></font><o:p></o:p></p>

</div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p style='margin-bottom:12.0pt'><font size=2 face="Times New Roman"><span
style='font-size:10.0pt'>I don't think RFC3588 needs to be touched when adding
an new Application ID. Neither should<br>
<br>
Why do you think you need to touch 3588 or 4004?<br>
<br>
-----Original Message-----<br>
From: Madjid Nakhjiri [<a href="mailto:mnakhjiri@huawei.com">mailto:mnakhjiri@huawei.com</a>]<br>
Sent: Tue 8/15/2006 10:07 AM<br>
To: Avi Lior; 'Julien Bournelle'<br>
Cc: dime@ietf.org; 'Madjid Nakhjiri'<br>
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???<br>
<br>
Hi Avi,<br>
<br>
<br>
<br>
Not sure what &quot;correct&quot; meansJ I am planning on looking a bit closer
at 3588 to see exactly how &quot;application&quot; and &quot;App ID&quot; is
used.<br>
<br>
As I said I _prefer_ adding a new Application ID for Mobile IPv6, but then both
RFC 3588 and 4004 needs to be revised to reflect that, I think the harm for
that is minimal anyway, given the fairly rare deployment of 4004 (I think).<br>
<br>
<br>
<br>
Madjid.<br>
<br>
<br>
<br>
________________________________<br>
<br>
From: Avi Lior [<a href="mailto:avi@bridgewatersystems.com">mailto:avi@bridgewatersystems.com</a>]<br>
Sent: Tuesday, August 15, 2006 7:01 AM<br>
To: Madjid Nakhjiri; Julien Bournelle<br>
Cc: dime@ietf.org<br>
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???<br>
<br>
<br>
<br>
<br>
<br>
How about the correct (IMO) option and that is assign this new application its
own Application ID.&nbsp; THis afterall is what an Application ID is supposed
to do.<br>
<br>
<br>
<br>
-----Original Message-----<br>
From: Madjid Nakhjiri [<a href="mailto:mnakhjiri@huawei.com">mailto:mnakhjiri@huawei.com</a>]<br>
Sent: Fri 8/11/2006 6:49 PM<br>
To: 'Julien Bournelle'<br>
Cc: dime@ietf.org<br>
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???<br>
<br>
Hi Julien,<br>
<br>
Thanks for pointing me to the archives.<br>
I have one general issue that maybe is related to me not quite understanding<br>
EAP-IKEv2 and that is EAP is run between a peer and an EAP server (in this<br>
case the backend AAA server). EAP-IKEv2 was designed so that a mature<br>
authentication/key management method could be used within EAP framework.<br>
Running EAP-IKEv2 results in authentication of peer to backend AAA, not to<br>
HA and possibly a key between the peer and AAA server. How does this help<br>
the need for IPsec between MN and HA?<br>
<br>
Now as far as the discussions on the archives, RFC 4072 only talks about<br>
carrying EAP over Diameter without talking about what EAP is being used for<br>
(your question: mobility versus access service). I think distinguishing<br>
mobility versus access is a AAA signaling issue not an EAP signaling issue.<br>
In RADIUS and MIP4 it is simpler (look at draft-nakhjiri-radius-mip4-02)<br>
because there are attributes related to MIP4 authentication (such as<br>
MIP-MN-AAA-Authenticator, etc) within the Access Request that tells the<br>
server this is about RADIUS. Diameter on the other hand has the notion of<br>
Application ID and should not rely on explicit hint on this. When we got to<br>
the point of trying to translate Diameter messaging to RADIUS, we had to<br>
resort to port types, because Diameter had different messages (depending on<br>
whether HA or FA were involved) while all RADIUS had was Access<br>
Request/Accepts not recognizing between HA and FA.<br>
Here your case is different. Diameter already has an Application ID for<br>
Mobile IP. That is how you distinguish between access and mobility service,<br>
not through service type. Now there are two choices as I said before:<br>
<br>
A) revise 3588 to have one App ID for MIPv4 and one for MIPv6 (separate MIP6<br>
split versus integrated through service types). This of course mean revising<br>
4004 to indicate specifically what MIPv4 App ID is.<br>
<br>
B) Use the same App ID of 3588 for both MIP4 and MIP6, but then you have to<br>
define 4 service types<br>
1) MIP4 split<br>
2) MIP4 integrated<br>
3) MIP6 split<br>
4) MIP6 integrated.<br>
<br>
I prefer A (I can live with B, if you tie a rope to my neck, just kidding).<br>
I think A is cleaner. I think split-integrated versus MIP4-mip6 are two<br>
different degrees of freedom. Just because MIP4 WG did not make the split<br>
integrated distinction, does not mean the business case cannot exist.<br>
Plus that Avi stated that Service type seems to be mandatory.<br>
<br>
Madjid<br>
<br>
-----Original Message-----<br>
From: Julien Bournelle [<a href="mailto:julien.bournelle@int-evry.fr">mailto:julien.bournelle@int-evry.fr</a>]<br>
Sent: Wednesday, August 09, 2006 1:39 AM<br>
To: Madjid Nakhjiri<br>
Cc: 'Julien Bournelle'; 'Hannes Tschofenig'; dime@ietf.org<br>
Subject: Re: [Dime] MIP6 App ID/ revise RFC 3588???<br>
<br>
Hi madjid,<br>
<br>
On Tue, Aug 08, 2006 at 04:51:08PM -0700, Madjid Nakhjiri wrote:<br>
&gt; Hi Julien,<br>
&gt;<br>
&gt; I just looked at the RFC 4005 definition of Service_Type.<br>
&gt; The services listed there are quite mixed. I am not quite sure what<br>
&gt; applications besides NASREQ are supposed to support Service_Type? Or is it<br>
&gt; that Mobile IP application assumes NASREQ must be supported?<br>
<br>
&nbsp;Let me try to sum up the issue:<br>
<br>
&nbsp;In the split scenario, the HA acts as a IKEv2 responder and uses EAP<br>
&nbsp;(oIKEv2) to authenticate the user (of the MN). The HA then relies on a<br>
&nbsp;EAP/AAA server and thus could use Diameter EAP. THe problem that we<br>
&nbsp;have here is that we are not performing AAA for &quot;basic&quot; network
access<br>
&nbsp;but for the IPv6 Mobility service. Thus we have the problem of, how the<br>
&nbsp;AAA server knows that.<br>
<br>
&nbsp;You can take a look at the thread:<br>
<br>
&nbsp;<a href="http://www1.ietf.org/mail-archive/web/dime/current/msg00262.html">http://www1.ietf.org/mail-archive/web/dime/current/msg00262.html</a><br>
<br>
&nbsp;for previous discussions on this topic which is still unsolved.<br>
<br>
&nbsp;At this point, as noted in:<br>
<br>
&nbsp;<a
href="http://www1.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-00.txt">http://www1.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-00.txt</a><br>
<br>
&nbsp;the 2 options that we have are:<br>
<br>
&nbsp;- define a new Service-Type for &quot;Mobile IPv6 - Split&quot; and puts
it in<br>
&nbsp;&nbsp; DER message (Diameter EAP Request)<br>
&nbsp;- define a new Application-ID and re-use Diameter EAP messages.<br>
<br>
&nbsp;Hope it helps,<br>
<br>
&nbsp;regards,<br>
<br>
&nbsp;Julien<br>
<br>
&gt;<br>
&gt; If one is to go about without modifying RFC 3588 that uses just one App ID<br>
&gt; for Mobile IP, then I guess there is just one choice of having<br>
&gt;<br>
&gt; two Service_types for Mobile IPv6<br>
&gt; and<br>
&gt; one Service_Type for Mobile IPv4,<br>
&gt;<br>
&gt; (3 total for Mobile IP), but then don't you have to modify RFC 4004 to add<br>
&gt; the service_type to Mobile IPv4?<br>
&gt;<br>
&gt; Madjid<br>
&gt;<br>
&gt; -----Original Message-----<br>
&gt; From: Julien Bournelle [<a href="mailto:julien.bournelle@int-evry.fr">mailto:julien.bournelle@int-evry.fr</a>]<br>
&gt; Sent: Monday, August 07, 2006 6:42 AM<br>
&gt; To: Madjid Nakhjiri<br>
&gt; Cc: 'Hannes Tschofenig'; dime@ietf.org<br>
&gt; Subject: Re: [Dime] MIP6 App ID/ was: IETF#66 Meeting Minutes<br>
&gt;<br>
&gt; HI madjid,<br>
&gt;<br>
&gt; On Mon, Aug 07, 2006 at 06:34:55AM -0700, Madjid Nakhjiri wrote:<br>
&gt; &gt; No worries, I was being humorous. I wanted to see what was said
during<br>
the<br>
&gt; &gt; meeting regarding the Mobile IP6 drafts. I tried to see the archive<br>
&gt; &gt; discussions, but did not see anything in June or July either.<br>
&gt; &gt; I am seeing all this discussion on the use of App IDs on the ML, so I<br>
&gt; wanted<br>
&gt; &gt; to see if MIP6 is getting its own App ID, or it is using the App ID<br>
&gt; assigned<br>
&gt; &gt; to Mobiloe IP in 3588?<br>
&gt;<br>
&gt;&nbsp; basically the question is: do we need a specific App ID or do a<br>
&gt;&nbsp; Service-Type AVP (indicating that it's a HA for the split scenario)
is<br>
&gt;&nbsp; sufficient ?<br>
&gt;<br>
&gt;<br>
&gt;&nbsp; regards,<br>
&gt;<br>
&gt;&nbsp; Julien<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt; R,<br>
&gt; &gt;<br>
&gt; &gt; Madjid<br>
&gt; &gt;<br>
&gt; &gt; -----Original Message-----<br>
&gt; &gt; From: Hannes Tschofenig [<a href="mailto:Hannes.Tschofenig@gmx.net">mailto:Hannes.Tschofenig@gmx.net</a>]<br>
&gt; &gt; Sent: Saturday, August 05, 2006 5:22 AM<br>
&gt; &gt; To: Madjid Nakhjiri<br>
&gt; &gt; Cc: dime@ietf.org<br>
&gt; &gt; Subject: Re: [Dime] IETF#66 Meeting Minutes<br>
&gt; &gt;<br>
&gt; &gt; I agree that the meeting minutes are somewhat brief this time.<br>
&gt; &gt; We will do better with the next IETF meeting...<br>
&gt; &gt;<br>
&gt; &gt; Ciao<br>
&gt; &gt; Hannes<br>
&gt; &gt;<br>
&gt; &gt; Madjid Nakhjiri wrote:<br>
&gt; &gt; &gt; Was this minutes or 10-minutes:-)<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; -----Original Message-----<br>
&gt; &gt; &gt; From: Hannes Tschofenig [<a
href="mailto:Hannes.Tschofenig@gmx.net">mailto:Hannes.Tschofenig@gmx.net</a>]<br>
&gt; &gt; &gt; Sent: Wednesday, July 19, 2006 7:56 AM<br>
&gt; &gt; &gt; To: dime@ietf.org<br>
&gt; &gt; &gt; Subject: [Dime] IETF#66 Meeting Minutes<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Hi all,<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; please take a look at the meeting minutes:<br>
&gt; &gt; &gt; <a href="http://www3.ietf.org/proceedings/06jul/minutes/dime.txt">http://www3.ietf.org/proceedings/06jul/minutes/dime.txt</a><br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Ciao<br>
&gt; &gt; &gt; Hannes<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; _______________________________________________<br>
&gt; &gt; &gt; DiME mailing list<br>
&gt; &gt; &gt; DiME@ietf.org<br>
&gt; &gt; &gt; <a href="https://www1.ietf.org/mailman/listinfo/dime">https://www1.ietf.org/mailman/listinfo/dime</a><br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; _______________________________________________<br>
&gt; &gt; DiME mailing list<br>
&gt; &gt; DiME@ietf.org<br>
&gt; &gt; <a href="https://www1.ietf.org/mailman/listinfo/dime">https://www1.ietf.org/mailman/listinfo/dime</a><br>
&gt;<br>
&gt; --<br>
&gt; julien.bournelle at int-evry.fr<br>
&gt;<br>
&gt;<br>
<br>
--<br>
julien.bournelle at int-evry.fr<br>
<br>
<br>
<br>
_______________________________________________<br>
DiME mailing list<br>
DiME@ietf.org<br>
<a href="https://www1.ietf.org/mailman/listinfo/dime">https://www1.ietf.org/mailman/listinfo/dime</a><br>
<br>
</span></font><o:p></o:p></p>

</div>

</body>

</html>

--Boundary_(ID_d9Aui2mQZEi1hpH2F89TzQ)--


--===============1254898596==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============1254898596==--




From dime-bounces@ietf.org Tue Aug 15 12:26:56 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GD1ki-0006m7-Hq; Tue, 15 Aug 2006 12:26:52 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GD1kh-0006ds-Ec
	for dime@ietf.org; Tue, 15 Aug 2006 12:26:51 -0400
Received: from bws14.bridgewatersystems.com ([216.113.7.14]
	helo=exchange.bridgewatersys.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD1kg-0006gh-6z
	for dime@ietf.org; Tue, 15 Aug 2006 12:26:51 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???
Date: Tue, 15 Aug 2006 12:25:05 -0400
Message-ID: <E7CCE8A83907104ABEE91AC3AE3709A01167DE@exchange.bridgewatersys.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Dime] MIP6 App ID/ revise RFC 3588???
Thread-Index: Aca7j5pLlwjYezfqQhS35Ix/bK+xSgCBYw0QALeF6YMAABfC8AAAO289AAQhW/AAAJNTag==
References: <001801c6c085$4e985fb0$2f01a8c0@china.huawei.com>
From: "Avi Lior" <avi@bridgewatersystems.com>
To: "Madjid Nakhjiri" <mnakhjiri@huawei.com>,
	"Julien Bournelle" <julien.bournelle@int-evry.fr>
X-Spam-Score: 0.6 (/)
X-Scan-Signature: 86a4d7ebdc337882c86d755b1c60a122
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0009423845=="
Errors-To: dime-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0009423845==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C6C087.9D73B2BA"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6C087.9D73B2BA
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


I think that RFC3588 should not define any application ids.  If it does =
they should be informative.

So if we are going to change 3588 we should remove any reference to any =
Application IDs.

IANA should be the only authoritative (normative) entity for Application =
IDS.

-----Original Message-----
From: Madjid Nakhjiri [mailto:mnakhjiri@huawei.com]
Sent: Tue 8/15/2006 12:10 PM
To: Avi Lior; 'Julien Bournelle'
Cc: dime@ietf.org
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???
=20
Because RFC 3588 defines a single Application ID for Mobile IP and 3588 =
is being revised anyway.

If this was a brand new application, it would not matter, but you =
already have one App ID for Mobile IP, that could only be used for MIP4, =
if you now define a different App ID for Mip6.

=20

________________________________

From: Avi Lior [mailto:avi@bridgewatersystems.com]=20
Sent: Tuesday, August 15, 2006 7:25 AM
To: Madjid Nakhjiri; Julien Bournelle
Cc: dime@ietf.org
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???

=20

=20

I don't think RFC3588 needs to be touched when adding an new Application =
ID. Neither should

Why do you think you need to touch 3588 or 4004?

-----Original Message-----
From: Madjid Nakhjiri [mailto:mnakhjiri@huawei.com]
Sent: Tue 8/15/2006 10:07 AM
To: Avi Lior; 'Julien Bournelle'
Cc: dime@ietf.org; 'Madjid Nakhjiri'
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???

Hi Avi,



Not sure what "correct" meansJ I am planning on looking a bit closer at =
3588 to see exactly how "application" and "App ID" is used.

As I said I _prefer_ adding a new Application ID for Mobile IPv6, but =
then both RFC 3588 and 4004 needs to be revised to reflect that, I think =
the harm for that is minimal anyway, given the fairly rare deployment of =
4004 (I think).



Madjid.



________________________________

From: Avi Lior [mailto:avi@bridgewatersystems.com]
Sent: Tuesday, August 15, 2006 7:01 AM
To: Madjid Nakhjiri; Julien Bournelle
Cc: dime@ietf.org
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???





How about the correct (IMO) option and that is assign this new =
application its own Application ID.  THis afterall is what an =
Application ID is supposed to do.



-----Original Message-----
From: Madjid Nakhjiri [mailto:mnakhjiri@huawei.com]
Sent: Fri 8/11/2006 6:49 PM
To: 'Julien Bournelle'
Cc: dime@ietf.org
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???

Hi Julien,

Thanks for pointing me to the archives.
I have one general issue that maybe is related to me not quite =
understanding
EAP-IKEv2 and that is EAP is run between a peer and an EAP server (in =
this
case the backend AAA server). EAP-IKEv2 was designed so that a mature
authentication/key management method could be used within EAP framework.
Running EAP-IKEv2 results in authentication of peer to backend AAA, not =
to
HA and possibly a key between the peer and AAA server. How does this =
help
the need for IPsec between MN and HA?

Now as far as the discussions on the archives, RFC 4072 only talks about
carrying EAP over Diameter without talking about what EAP is being used =
for
(your question: mobility versus access service). I think distinguishing
mobility versus access is a AAA signaling issue not an EAP signaling =
issue.
In RADIUS and MIP4 it is simpler (look at draft-nakhjiri-radius-mip4-02)
because there are attributes related to MIP4 authentication (such as
MIP-MN-AAA-Authenticator, etc) within the Access Request that tells the
server this is about RADIUS. Diameter on the other hand has the notion =
of
Application ID and should not rely on explicit hint on this. When we got =
to
the point of trying to translate Diameter messaging to RADIUS, we had to
resort to port types, because Diameter had different messages (depending =
on
whether HA or FA were involved) while all RADIUS had was Access
Request/Accepts not recognizing between HA and FA.
Here your case is different. Diameter already has an Application ID for
Mobile IP. That is how you distinguish between access and mobility =
service,
not through service type. Now there are two choices as I said before:

A) revise 3588 to have one App ID for MIPv4 and one for MIPv6 (separate =
MIP6
split versus integrated through service types). This of course mean =
revising
4004 to indicate specifically what MIPv4 App ID is.

B) Use the same App ID of 3588 for both MIP4 and MIP6, but then you have =
to
define 4 service types
1) MIP4 split
2) MIP4 integrated
3) MIP6 split
4) MIP6 integrated.

I prefer A (I can live with B, if you tie a rope to my neck, just =
kidding).
I think A is cleaner. I think split-integrated versus MIP4-mip6 are two
different degrees of freedom. Just because MIP4 WG did not make the =
split
integrated distinction, does not mean the business case cannot exist.
Plus that Avi stated that Service type seems to be mandatory.

Madjid

-----Original Message-----
From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr]
Sent: Wednesday, August 09, 2006 1:39 AM
To: Madjid Nakhjiri
Cc: 'Julien Bournelle'; 'Hannes Tschofenig'; dime@ietf.org
Subject: Re: [Dime] MIP6 App ID/ revise RFC 3588???

Hi madjid,

On Tue, Aug 08, 2006 at 04:51:08PM -0700, Madjid Nakhjiri wrote:
> Hi Julien,
>
> I just looked at the RFC 4005 definition of Service_Type.
> The services listed there are quite mixed. I am not quite sure what
> applications besides NASREQ are supposed to support Service_Type? Or =
is it
> that Mobile IP application assumes NASREQ must be supported?

 Let me try to sum up the issue:

 In the split scenario, the HA acts as a IKEv2 responder and uses EAP
 (oIKEv2) to authenticate the user (of the MN). The HA then relies on a
 EAP/AAA server and thus could use Diameter EAP. THe problem that we
 have here is that we are not performing AAA for "basic" network access
 but for the IPv6 Mobility service. Thus we have the problem of, how the
 AAA server knows that.

 You can take a look at the thread:

 http://www1.ietf.org/mail-archive/web/dime/current/msg00262.html

 for previous discussions on this topic which is still unsolved.

 At this point, as noted in:

 http://www1.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-00.txt

 the 2 options that we have are:

 - define a new Service-Type for "Mobile IPv6 - Split" and puts it in
   DER message (Diameter EAP Request)
 - define a new Application-ID and re-use Diameter EAP messages.

 Hope it helps,

 regards,

 Julien

>
> If one is to go about without modifying RFC 3588 that uses just one =
App ID
> for Mobile IP, then I guess there is just one choice of having
>
> two Service_types for Mobile IPv6
> and
> one Service_Type for Mobile IPv4,
>
> (3 total for Mobile IP), but then don't you have to modify RFC 4004 to =
add
> the service_type to Mobile IPv4?
>
> Madjid
>
> -----Original Message-----
> From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr]
> Sent: Monday, August 07, 2006 6:42 AM
> To: Madjid Nakhjiri
> Cc: 'Hannes Tschofenig'; dime@ietf.org
> Subject: Re: [Dime] MIP6 App ID/ was: IETF#66 Meeting Minutes
>
> HI madjid,
>
> On Mon, Aug 07, 2006 at 06:34:55AM -0700, Madjid Nakhjiri wrote:
> > No worries, I was being humorous. I wanted to see what was said =
during
the
> > meeting regarding the Mobile IP6 drafts. I tried to see the archive
> > discussions, but did not see anything in June or July either.
> > I am seeing all this discussion on the use of App IDs on the ML, so =
I
> wanted
> > to see if MIP6 is getting its own App ID, or it is using the App ID
> assigned
> > to Mobiloe IP in 3588?
>
>  basically the question is: do we need a specific App ID or do a
>  Service-Type AVP (indicating that it's a HA for the split scenario) =
is
>  sufficient ?
>
>
>  regards,
>
>  Julien
>
> >
> > R,
> >
> > Madjid
> >
> > -----Original Message-----
> > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
> > Sent: Saturday, August 05, 2006 5:22 AM
> > To: Madjid Nakhjiri
> > Cc: dime@ietf.org
> > Subject: Re: [Dime] IETF#66 Meeting Minutes
> >
> > I agree that the meeting minutes are somewhat brief this time.
> > We will do better with the next IETF meeting...
> >
> > Ciao
> > Hannes
> >
> > Madjid Nakhjiri wrote:
> > > Was this minutes or 10-minutes:-)
> > >
> > > -----Original Message-----
> > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
> > > Sent: Wednesday, July 19, 2006 7:56 AM
> > > To: dime@ietf.org
> > > Subject: [Dime] IETF#66 Meeting Minutes
> > >
> > > Hi all,
> > >
> > > please take a look at the meeting minutes:
> > > http://www3.ietf.org/proceedings/06jul/minutes/dime.txt
> > >
> > > Ciao
> > > Hannes
> > >
> > > _______________________________________________
> > > DiME mailing list
> > > DiME@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/dime
> > >
> > >
> > >
> >
> >
> >
> >
> > _______________________________________________
> > DiME mailing list
> > DiME@ietf.org
> > https://www1.ietf.org/mailman/listinfo/dime
>
> --
> julien.bournelle at int-evry.fr
>
>

--
julien.bournelle at int-evry.fr



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





------_=_NextPart_001_01C6C087.9D73B2BA
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 =
6.5.7650.28">
<TITLE>RE: [Dime] MIP6 App ID/ revise RFC 3588???</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->
<BR>

<P><FONT SIZE=3D2>I think that RFC3588 should not define any application =
ids.&nbsp; If it does they should be informative.<BR>
<BR>
So if we are going to change 3588 we should remove any reference to any =
Application IDs.<BR>
<BR>
IANA should be the only authoritative (normative) entity for Application =
IDS.<BR>
<BR>
-----Original Message-----<BR>
From: Madjid Nakhjiri [<A =
HREF=3D"mailto:mnakhjiri@huawei.com">mailto:mnakhjiri@huawei.com</A>]<BR>=

Sent: Tue 8/15/2006 12:10 PM<BR>
To: Avi Lior; 'Julien Bournelle'<BR>
Cc: dime@ietf.org<BR>
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???<BR>
<BR>
Because RFC 3588 defines a single Application ID for Mobile IP and 3588 =
is being revised anyway.<BR>
<BR>
If this was a brand new application, it would not matter, but you =
already have one App ID for Mobile IP, that could only be used for MIP4, =
if you now define a different App ID for Mip6.<BR>
<BR>
<BR>
<BR>
________________________________<BR>
<BR>
From: Avi Lior [<A =
HREF=3D"mailto:avi@bridgewatersystems.com">mailto:avi@bridgewatersystems.=
com</A>]<BR>
Sent: Tuesday, August 15, 2006 7:25 AM<BR>
To: Madjid Nakhjiri; Julien Bournelle<BR>
Cc: dime@ietf.org<BR>
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
I don't think RFC3588 needs to be touched when adding an new Application =
ID. Neither should<BR>
<BR>
Why do you think you need to touch 3588 or 4004?<BR>
<BR>
-----Original Message-----<BR>
From: Madjid Nakhjiri [<A =
HREF=3D"mailto:mnakhjiri@huawei.com">mailto:mnakhjiri@huawei.com</A>]<BR>=

Sent: Tue 8/15/2006 10:07 AM<BR>
To: Avi Lior; 'Julien Bournelle'<BR>
Cc: dime@ietf.org; 'Madjid Nakhjiri'<BR>
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???<BR>
<BR>
Hi Avi,<BR>
<BR>
<BR>
<BR>
Not sure what &quot;correct&quot; meansJ I am planning on looking a bit =
closer at 3588 to see exactly how &quot;application&quot; and &quot;App =
ID&quot; is used.<BR>
<BR>
As I said I _prefer_ adding a new Application ID for Mobile IPv6, but =
then both RFC 3588 and 4004 needs to be revised to reflect that, I think =
the harm for that is minimal anyway, given the fairly rare deployment of =
4004 (I think).<BR>
<BR>
<BR>
<BR>
Madjid.<BR>
<BR>
<BR>
<BR>
________________________________<BR>
<BR>
From: Avi Lior [<A =
HREF=3D"mailto:avi@bridgewatersystems.com">mailto:avi@bridgewatersystems.=
com</A>]<BR>
Sent: Tuesday, August 15, 2006 7:01 AM<BR>
To: Madjid Nakhjiri; Julien Bournelle<BR>
Cc: dime@ietf.org<BR>
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
How about the correct (IMO) option and that is assign this new =
application its own Application ID.&nbsp; THis afterall is what an =
Application ID is supposed to do.<BR>
<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: Madjid Nakhjiri [<A =
HREF=3D"mailto:mnakhjiri@huawei.com">mailto:mnakhjiri@huawei.com</A>]<BR>=

Sent: Fri 8/11/2006 6:49 PM<BR>
To: 'Julien Bournelle'<BR>
Cc: dime@ietf.org<BR>
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???<BR>
<BR>
Hi Julien,<BR>
<BR>
Thanks for pointing me to the archives.<BR>
I have one general issue that maybe is related to me not quite =
understanding<BR>
EAP-IKEv2 and that is EAP is run between a peer and an EAP server (in =
this<BR>
case the backend AAA server). EAP-IKEv2 was designed so that a =
mature<BR>
authentication/key management method could be used within EAP =
framework.<BR>
Running EAP-IKEv2 results in authentication of peer to backend AAA, not =
to<BR>
HA and possibly a key between the peer and AAA server. How does this =
help<BR>
the need for IPsec between MN and HA?<BR>
<BR>
Now as far as the discussions on the archives, RFC 4072 only talks =
about<BR>
carrying EAP over Diameter without talking about what EAP is being used =
for<BR>
(your question: mobility versus access service). I think =
distinguishing<BR>
mobility versus access is a AAA signaling issue not an EAP signaling =
issue.<BR>
In RADIUS and MIP4 it is simpler (look at =
draft-nakhjiri-radius-mip4-02)<BR>
because there are attributes related to MIP4 authentication (such as<BR>
MIP-MN-AAA-Authenticator, etc) within the Access Request that tells =
the<BR>
server this is about RADIUS. Diameter on the other hand has the notion =
of<BR>
Application ID and should not rely on explicit hint on this. When we got =
to<BR>
the point of trying to translate Diameter messaging to RADIUS, we had =
to<BR>
resort to port types, because Diameter had different messages (depending =
on<BR>
whether HA or FA were involved) while all RADIUS had was Access<BR>
Request/Accepts not recognizing between HA and FA.<BR>
Here your case is different. Diameter already has an Application ID =
for<BR>
Mobile IP. That is how you distinguish between access and mobility =
service,<BR>
not through service type. Now there are two choices as I said =
before:<BR>
<BR>
A) revise 3588 to have one App ID for MIPv4 and one for MIPv6 (separate =
MIP6<BR>
split versus integrated through service types). This of course mean =
revising<BR>
4004 to indicate specifically what MIPv4 App ID is.<BR>
<BR>
B) Use the same App ID of 3588 for both MIP4 and MIP6, but then you have =
to<BR>
define 4 service types<BR>
1) MIP4 split<BR>
2) MIP4 integrated<BR>
3) MIP6 split<BR>
4) MIP6 integrated.<BR>
<BR>
I prefer A (I can live with B, if you tie a rope to my neck, just =
kidding).<BR>
I think A is cleaner. I think split-integrated versus MIP4-mip6 are =
two<BR>
different degrees of freedom. Just because MIP4 WG did not make the =
split<BR>
integrated distinction, does not mean the business case cannot =
exist.<BR>
Plus that Avi stated that Service type seems to be mandatory.<BR>
<BR>
Madjid<BR>
<BR>
-----Original Message-----<BR>
From: Julien Bournelle [<A =
HREF=3D"mailto:julien.bournelle@int-evry.fr">mailto:julien.bournelle@int-=
evry.fr</A>]<BR>
Sent: Wednesday, August 09, 2006 1:39 AM<BR>
To: Madjid Nakhjiri<BR>
Cc: 'Julien Bournelle'; 'Hannes Tschofenig'; dime@ietf.org<BR>
Subject: Re: [Dime] MIP6 App ID/ revise RFC 3588???<BR>
<BR>
Hi madjid,<BR>
<BR>
On Tue, Aug 08, 2006 at 04:51:08PM -0700, Madjid Nakhjiri wrote:<BR>
&gt; Hi Julien,<BR>
&gt;<BR>
&gt; I just looked at the RFC 4005 definition of Service_Type.<BR>
&gt; The services listed there are quite mixed. I am not quite sure =
what<BR>
&gt; applications besides NASREQ are supposed to support Service_Type? =
Or is it<BR>
&gt; that Mobile IP application assumes NASREQ must be supported?<BR>
<BR>
&nbsp;Let me try to sum up the issue:<BR>
<BR>
&nbsp;In the split scenario, the HA acts as a IKEv2 responder and uses =
EAP<BR>
&nbsp;(oIKEv2) to authenticate the user (of the MN). The HA then relies =
on a<BR>
&nbsp;EAP/AAA server and thus could use Diameter EAP. THe problem that =
we<BR>
&nbsp;have here is that we are not performing AAA for &quot;basic&quot; =
network access<BR>
&nbsp;but for the IPv6 Mobility service. Thus we have the problem of, =
how the<BR>
&nbsp;AAA server knows that.<BR>
<BR>
&nbsp;You can take a look at the thread:<BR>
<BR>
&nbsp;<A =
HREF=3D"http://www1.ietf.org/mail-archive/web/dime/current/msg00262.html"=
>http://www1.ietf.org/mail-archive/web/dime/current/msg00262.html</A><BR>=

<BR>
&nbsp;for previous discussions on this topic which is still =
unsolved.<BR>
<BR>
&nbsp;At this point, as noted in:<BR>
<BR>
&nbsp;<A =
HREF=3D"http://www1.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-0=
0.txt">http://www1.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-00=
.txt</A><BR>
<BR>
&nbsp;the 2 options that we have are:<BR>
<BR>
&nbsp;- define a new Service-Type for &quot;Mobile IPv6 - Split&quot; =
and puts it in<BR>
&nbsp;&nbsp; DER message (Diameter EAP Request)<BR>
&nbsp;- define a new Application-ID and re-use Diameter EAP =
messages.<BR>
<BR>
&nbsp;Hope it helps,<BR>
<BR>
&nbsp;regards,<BR>
<BR>
&nbsp;Julien<BR>
<BR>
&gt;<BR>
&gt; If one is to go about without modifying RFC 3588 that uses just one =
App ID<BR>
&gt; for Mobile IP, then I guess there is just one choice of having<BR>
&gt;<BR>
&gt; two Service_types for Mobile IPv6<BR>
&gt; and<BR>
&gt; one Service_Type for Mobile IPv4,<BR>
&gt;<BR>
&gt; (3 total for Mobile IP), but then don't you have to modify RFC 4004 =
to add<BR>
&gt; the service_type to Mobile IPv4?<BR>
&gt;<BR>
&gt; Madjid<BR>
&gt;<BR>
&gt; -----Original Message-----<BR>
&gt; From: Julien Bournelle [<A =
HREF=3D"mailto:julien.bournelle@int-evry.fr">mailto:julien.bournelle@int-=
evry.fr</A>]<BR>
&gt; Sent: Monday, August 07, 2006 6:42 AM<BR>
&gt; To: Madjid Nakhjiri<BR>
&gt; Cc: 'Hannes Tschofenig'; dime@ietf.org<BR>
&gt; Subject: Re: [Dime] MIP6 App ID/ was: IETF#66 Meeting Minutes<BR>
&gt;<BR>
&gt; HI madjid,<BR>
&gt;<BR>
&gt; On Mon, Aug 07, 2006 at 06:34:55AM -0700, Madjid Nakhjiri =
wrote:<BR>
&gt; &gt; No worries, I was being humorous. I wanted to see what was =
said during<BR>
the<BR>
&gt; &gt; meeting regarding the Mobile IP6 drafts. I tried to see the =
archive<BR>
&gt; &gt; discussions, but did not see anything in June or July =
either.<BR>
&gt; &gt; I am seeing all this discussion on the use of App IDs on the =
ML, so I<BR>
&gt; wanted<BR>
&gt; &gt; to see if MIP6 is getting its own App ID, or it is using the =
App ID<BR>
&gt; assigned<BR>
&gt; &gt; to Mobiloe IP in 3588?<BR>
&gt;<BR>
&gt;&nbsp; basically the question is: do we need a specific App ID or do =
a<BR>
&gt;&nbsp; Service-Type AVP (indicating that it's a HA for the split =
scenario) is<BR>
&gt;&nbsp; sufficient ?<BR>
&gt;<BR>
&gt;<BR>
&gt;&nbsp; regards,<BR>
&gt;<BR>
&gt;&nbsp; Julien<BR>
&gt;<BR>
&gt; &gt;<BR>
&gt; &gt; R,<BR>
&gt; &gt;<BR>
&gt; &gt; Madjid<BR>
&gt; &gt;<BR>
&gt; &gt; -----Original Message-----<BR>
&gt; &gt; From: Hannes Tschofenig [<A =
HREF=3D"mailto:Hannes.Tschofenig@gmx.net">mailto:Hannes.Tschofenig@gmx.ne=
t</A>]<BR>
&gt; &gt; Sent: Saturday, August 05, 2006 5:22 AM<BR>
&gt; &gt; To: Madjid Nakhjiri<BR>
&gt; &gt; Cc: dime@ietf.org<BR>
&gt; &gt; Subject: Re: [Dime] IETF#66 Meeting Minutes<BR>
&gt; &gt;<BR>
&gt; &gt; I agree that the meeting minutes are somewhat brief this =
time.<BR>
&gt; &gt; We will do better with the next IETF meeting...<BR>
&gt; &gt;<BR>
&gt; &gt; Ciao<BR>
&gt; &gt; Hannes<BR>
&gt; &gt;<BR>
&gt; &gt; Madjid Nakhjiri wrote:<BR>
&gt; &gt; &gt; Was this minutes or 10-minutes:-)<BR>
&gt; &gt; &gt;<BR>
&gt; &gt; &gt; -----Original Message-----<BR>
&gt; &gt; &gt; From: Hannes Tschofenig [<A =
HREF=3D"mailto:Hannes.Tschofenig@gmx.net">mailto:Hannes.Tschofenig@gmx.ne=
t</A>]<BR>
&gt; &gt; &gt; Sent: Wednesday, July 19, 2006 7:56 AM<BR>
&gt; &gt; &gt; To: dime@ietf.org<BR>
&gt; &gt; &gt; Subject: [Dime] IETF#66 Meeting Minutes<BR>
&gt; &gt; &gt;<BR>
&gt; &gt; &gt; Hi all,<BR>
&gt; &gt; &gt;<BR>
&gt; &gt; &gt; please take a look at the meeting minutes:<BR>
&gt; &gt; &gt; <A =
HREF=3D"http://www3.ietf.org/proceedings/06jul/minutes/dime.txt">http://w=
ww3.ietf.org/proceedings/06jul/minutes/dime.txt</A><BR>
&gt; &gt; &gt;<BR>
&gt; &gt; &gt; Ciao<BR>
&gt; &gt; &gt; Hannes<BR>
&gt; &gt; &gt;<BR>
&gt; &gt; &gt; _______________________________________________<BR>
&gt; &gt; &gt; DiME mailing list<BR>
&gt; &gt; &gt; DiME@ietf.org<BR>
&gt; &gt; &gt; <A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/dime">https://www1.ietf.or=
g/mailman/listinfo/dime</A><BR>
&gt; &gt; &gt;<BR>
&gt; &gt; &gt;<BR>
&gt; &gt; &gt;<BR>
&gt; &gt;<BR>
&gt; &gt;<BR>
&gt; &gt;<BR>
&gt; &gt;<BR>
&gt; &gt; _______________________________________________<BR>
&gt; &gt; DiME mailing list<BR>
&gt; &gt; DiME@ietf.org<BR>
&gt; &gt; <A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/dime">https://www1.ietf.or=
g/mailman/listinfo/dime</A><BR>
&gt;<BR>
&gt; --<BR>
&gt; julien.bournelle at int-evry.fr<BR>
&gt;<BR>
&gt;<BR>
<BR>
--<BR>
julien.bournelle at int-evry.fr<BR>
<BR>
<BR>
<BR>
_______________________________________________<BR>
DiME mailing list<BR>
DiME@ietf.org<BR>
<A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/dime">https://www1.ietf.or=
g/mailman/listinfo/dime</A><BR>
<BR>
<BR>
<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C6C087.9D73B2BA--


--===============0009423845==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0009423845==--




From dime-bounces@ietf.org Tue Aug 15 13:13:27 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GD2Tn-00048j-3i; Tue, 15 Aug 2006 13:13:27 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GD2Tl-00048a-Gy
	for dime@ietf.org; Tue, 15 Aug 2006 13:13:25 -0400
Received: from sj-iport-6.cisco.com ([171.71.176.117])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD2Ti-0000dq-59
	for dime@ietf.org; Tue, 15 Aug 2006 13:13:25 -0400
Received: from sj-dkim-3.cisco.com ([171.71.179.195])
	by sj-iport-6.cisco.com with ESMTP; 15 Aug 2006 10:13:21 -0700
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238])
	by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id
	k7FHDLAS031664; Tue, 15 Aug 2006 10:13:21 -0700
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com
	[128.107.191.63])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k7FHDKUJ024829;
	Tue, 15 Aug 2006 10:13:20 -0700 (PDT)
Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by
	xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 15 Aug 2006 10:13:20 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???
Date: Tue, 15 Aug 2006 10:13:18 -0700
Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB26250272B892@xmb-sjc-215.amer.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Dime] MIP6 App ID/ revise RFC 3588???
Thread-Index: Aca7j5pLlwjYezfqQhS35Ix/bK+xSgCBYw0QALeF6YMAABfC8AAGj5KA
From: "Glen Zorn \(gwz\)" <gwz@cisco.com>
To: "Madjid Nakhjiri" <mnakhjiri@huawei.com>,
	"Avi Lior" <avi@bridgewatersystems.com>,
	"Julien Bournelle" <julien.bournelle@int-evry.fr>
X-OriginalArrivalTime: 15 Aug 2006 17:13:20.0624 (UTC)
	FILETIME=[1B852F00:01C6C08E]
DKIM-Signature: a=rsa-sha1; q=dns; l=3231; t=1155662001; x=1156526001;
	c=relaxed/simple; s=sjdkim3002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=gwz@cisco.com;
	z=From:=22Glen=20Zorn=20\(gwz\)=22=20<gwz@cisco.com>
	|Subject:RE=3A=20[Dime]=20MIP6=20App=20ID/=20revise=20RFC=203588???;
	X=v=3Dcisco.com=3B=20h=3DYc55G/OrL/EqM7ikwr5TjGwAQlo=3D;
	b=jsWeFqgEdkRbi1xxyNgzL9TAAvglLqlHz+adZjLXnYi2cxwkT10sSboE9Tj1QVuQ7hui3o6i
	mAKUWrjU2yY6zYx0J3kNBQ6Xt02o2RI2sjK4kqovBJS9qkYvwgHw7x0Z;
Authentication-Results: sj-dkim-3.cisco.com; header.From=gwz@cisco.com;
	dkim=pass (
	59 extraneous bytes; sig from cisco.com verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a8a20a483a84f747e56475e290ee868e
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1600326025=="
Errors-To: dime-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1600326025==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C6C08E.1B657B57"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6C08E.1B657B57
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I give up, why do 3588 & 4004 need to be revised?
=20
...
both RFC 3588 and 4004 needs to be revised to reflect that, I think the =
harm for that is minimal anyway, given the fairly rare deployment of =
4004 (I think).
...

------_=_NextPart_001_01C6C08E.1B657B57
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20
"urn:schemas-microsoft-com:vml" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word"><HEAD><TITLE>RE: [Dime] MIP6 App =
ID/ revise RFC 3588???</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1555" name=3DGENERATOR><!--[if !mso]>
<STYLE>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</STYLE>
<![endif]-->
<STYLE>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
p
	{mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</STYLE>
</HEAD>
<BODY lang=3DEN-US vLink=3Dblue link=3Dblue>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D133331117-15082006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>I give up, why do 3588 &amp; 4004 need to be=20
revised?</FONT></SPAN></DIV>
<DIV><FONT face=3DArial><FONT size=3D2><FONT color=3D#0000ff><SPAN=20
class=3D133331117-15082006>&nbsp;</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT size=3D2><FONT color=3D#0000ff><SPAN=20
class=3D133331117-15082006>...</SPAN></FONT></FONT></FONT></DIV>
<DIV><FONT face=3DArial><FONT size=3D2><FONT color=3Dnavy><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">both RFC 3588 =
and 4004=20
needs to be revised to reflect that, I think the harm for that is =
minimal=20
anyway, given the fairly rare deployment of 4004 (I=20
think).<o:p></o:p></SPAN></FONT></FONT></FONT></DIV>
<DIV class=3DSection1><SPAN class=3D133331117-15082006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>...</FONT></SPAN></DIV></BODY></HTML>

------_=_NextPart_001_01C6C08E.1B657B57--


--===============1600326025==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============1600326025==--




From dime-bounces@ietf.org Tue Aug 15 13:24:07 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GD2e7-0007Pl-Bi; Tue, 15 Aug 2006 13:24:07 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GD2e5-0007Pg-G6
	for dime@ietf.org; Tue, 15 Aug 2006 13:24:05 -0400
Received: from mgw-ext12.nokia.com ([131.228.20.171])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD2e1-00016t-VQ
	for dime@ietf.org; Tue, 15 Aug 2006 13:24:05 -0400
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211])
	by mgw-ext12.nokia.com (Switch-3.1.10/Switch-3.1.7) with ESMTP id
	k7FHNpXb005140; Tue, 15 Aug 2006 20:23:51 +0300
Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by
	esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 15 Aug 2006 20:23:51 +0300
Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by
	esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 15 Aug 2006 20:23:50 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???
Date: Tue, 15 Aug 2006 20:23:50 +0300
Message-ID: <BAA65A575825454CBB0103267553FCCC8920AE@esebe199.NOE.Nokia.com>
In-Reply-To: <E7CCE8A83907104ABEE91AC3AE3709A01167DE@exchange.bridgewatersys.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Dime] MIP6 App ID/ revise RFC 3588???
Thread-Index: Aca7j5pLlwjYezfqQhS35Ix/bK+xSgCBYw0QALeF6YMAABfC8AAAO289AAQhW/AAAJNTagACAoPQ
From: <john.loughney@nokia.com>
To: <avi@bridgewatersystems.com>, <mnakhjiri@huawei.com>,
	<julien.bournelle@int-evry.fr>
X-OriginalArrivalTime: 15 Aug 2006 17:23:50.0620 (UTC)
	FILETIME=[9306F1C0:01C6C08F]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 8b46f883d051ec9bb02ad32011a213d1
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0695543943=="
Errors-To: dime-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0695543943==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C6C08F.92E42404"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6C08F.92E42404
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Avi,
=20
3588 defines the IANA considerations for registering App IDs.  The
document defines the initial Diameter IANA registry. This is standard
procedure.  I don't quite understand what the problem is.
=20
John
=20

11.3.  Application Identifiers



   As defined in Section 2.4
<http://tools.ietf.org/html/rfc3588#section-2.4> , the Application
Identifier is used to
   identify a specific Diameter Application.  There are standards-track
   application ids and vendor specific application ids.

   IANA [IANA <http://tools.ietf.org/html/rfc3588#ref-IANA> ] has
assigned the range 0x00000001 to 0x00ffffff for
   standards-track applications; and 0x01000000 - 0xfffffffe for vendor
   specific applications, on a first-come, first-served basis.  The
   following values are allocated.

      Diameter Common Messages            0
      NASREQ                              1 [NASREQ
<http://tools.ietf.org/html/rfc3588#ref-NASREQ> ]
      Mobile-IP                           2 [DIAMMIP
<http://tools.ietf.org/html/rfc3588#ref-DIAMMIP> ]
      Diameter Base Accounting            3
      Relay                               0xffffffff

   Assignment of standards-track application IDs are by Designated
   Expert with Specification Required [IANA
<http://tools.ietf.org/html/rfc3588#ref-IANA> ].

   Both Application-Id and Acct-Application-Id AVPs use the same
   Application Identifier space.

   Vendor-Specific Application Identifiers, are for Private Use.
   Vendor-Specific Application Identifiers are assigned on a First Come,
   First Served basis by IANA.
T


________________________________

	From: ext Avi Lior [mailto:avi@bridgewatersystems.com]=20
	Sent: 15 August, 2006 19:25
	To: Madjid Nakhjiri; Julien Bournelle
	Cc: dime@ietf.org
	Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???
=09
=09


	I think that RFC3588 should not define any application ids.  If
it does they should be informative.
=09
	So if we are going to change 3588 we should remove any reference
to any Application IDs.
=09
	IANA should be the only authoritative (normative) entity for
Application IDS.
=09
	-----Original Message-----
	From: Madjid Nakhjiri [mailto:mnakhjiri@huawei.com]
	Sent: Tue 8/15/2006 12:10 PM
	To: Avi Lior; 'Julien Bournelle'
	Cc: dime@ietf.org
	Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???
=09
	Because RFC 3588 defines a single Application ID for Mobile IP
and 3588 is being revised anyway.
=09
	If this was a brand new application, it would not matter, but
you already have one App ID for Mobile IP, that could only be used for
MIP4, if you now define a different App ID for Mip6.
=09
=09
=09
	________________________________
=09
	From: Avi Lior [mailto:avi@bridgewatersystems.com]
	Sent: Tuesday, August 15, 2006 7:25 AM
	To: Madjid Nakhjiri; Julien Bournelle
	Cc: dime@ietf.org
	Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???
=09
=09
=09
=09
=09
	I don't think RFC3588 needs to be touched when adding an new
Application ID. Neither should
=09
	Why do you think you need to touch 3588 or 4004?
=09
	-----Original Message-----
	From: Madjid Nakhjiri [mailto:mnakhjiri@huawei.com]
	Sent: Tue 8/15/2006 10:07 AM
	To: Avi Lior; 'Julien Bournelle'
	Cc: dime@ietf.org; 'Madjid Nakhjiri'
	Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???
=09
	Hi Avi,
=09
=09
=09
	Not sure what "correct" meansJ I am planning on looking a bit
closer at 3588 to see exactly how "application" and "App ID" is used.
=09
	As I said I _prefer_ adding a new Application ID for Mobile
IPv6, but then both RFC 3588 and 4004 needs to be revised to reflect
that, I think the harm for that is minimal anyway, given the fairly rare
deployment of 4004 (I think).
=09
=09
=09
	Madjid.
=09
=09
=09
	________________________________
=09
	From: Avi Lior [mailto:avi@bridgewatersystems.com]
	Sent: Tuesday, August 15, 2006 7:01 AM
	To: Madjid Nakhjiri; Julien Bournelle
	Cc: dime@ietf.org
	Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???
=09
=09
=09
=09
=09
	How about the correct (IMO) option and that is assign this new
application its own Application ID.  THis afterall is what an
Application ID is supposed to do.
=09
=09
=09
	-----Original Message-----
	From: Madjid Nakhjiri [mailto:mnakhjiri@huawei.com]
	Sent: Fri 8/11/2006 6:49 PM
	To: 'Julien Bournelle'
	Cc: dime@ietf.org
	Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???
=09
	Hi Julien,
=09
	Thanks for pointing me to the archives.
	I have one general issue that maybe is related to me not quite
understanding
	EAP-IKEv2 and that is EAP is run between a peer and an EAP
server (in this
	case the backend AAA server). EAP-IKEv2 was designed so that a
mature
	authentication/key management method could be used within EAP
framework.
	Running EAP-IKEv2 results in authentication of peer to backend
AAA, not to
	HA and possibly a key between the peer and AAA server. How does
this help
	the need for IPsec between MN and HA?
=09
	Now as far as the discussions on the archives, RFC 4072 only
talks about
	carrying EAP over Diameter without talking about what EAP is
being used for
	(your question: mobility versus access service). I think
distinguishing
	mobility versus access is a AAA signaling issue not an EAP
signaling issue.
	In RADIUS and MIP4 it is simpler (look at
draft-nakhjiri-radius-mip4-02)
	because there are attributes related to MIP4 authentication
(such as
	MIP-MN-AAA-Authenticator, etc) within the Access Request that
tells the
	server this is about RADIUS. Diameter on the other hand has the
notion of
	Application ID and should not rely on explicit hint on this.
When we got to
	the point of trying to translate Diameter messaging to RADIUS,
we had to
	resort to port types, because Diameter had different messages
(depending on
	whether HA or FA were involved) while all RADIUS had was Access
	Request/Accepts not recognizing between HA and FA.
	Here your case is different. Diameter already has an Application
ID for
	Mobile IP. That is how you distinguish between access and
mobility service,
	not through service type. Now there are two choices as I said
before:
=09
	A) revise 3588 to have one App ID for MIPv4 and one for MIPv6
(separate MIP6
	split versus integrated through service types). This of course
mean revising
	4004 to indicate specifically what MIPv4 App ID is.
=09
	B) Use the same App ID of 3588 for both MIP4 and MIP6, but then
you have to
	define 4 service types
	1) MIP4 split
	2) MIP4 integrated
	3) MIP6 split
	4) MIP6 integrated.
=09
	I prefer A (I can live with B, if you tie a rope to my neck,
just kidding).
	I think A is cleaner. I think split-integrated versus MIP4-mip6
are two
	different degrees of freedom. Just because MIP4 WG did not make
the split
	integrated distinction, does not mean the business case cannot
exist.
	Plus that Avi stated that Service type seems to be mandatory.
=09
	Madjid
=09
	-----Original Message-----
	From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr]
	Sent: Wednesday, August 09, 2006 1:39 AM
	To: Madjid Nakhjiri
	Cc: 'Julien Bournelle'; 'Hannes Tschofenig'; dime@ietf.org
	Subject: Re: [Dime] MIP6 App ID/ revise RFC 3588???
=09
	Hi madjid,
=09
	On Tue, Aug 08, 2006 at 04:51:08PM -0700, Madjid Nakhjiri wrote:
	> Hi Julien,
	>
	> I just looked at the RFC 4005 definition of Service_Type.
	> The services listed there are quite mixed. I am not quite sure
what
	> applications besides NASREQ are supposed to support
Service_Type? Or is it
	> that Mobile IP application assumes NASREQ must be supported?
=09
	 Let me try to sum up the issue:
=09
	 In the split scenario, the HA acts as a IKEv2 responder and
uses EAP
	 (oIKEv2) to authenticate the user (of the MN). The HA then
relies on a
	 EAP/AAA server and thus could use Diameter EAP. THe problem
that we
	 have here is that we are not performing AAA for "basic" network
access
	 but for the IPv6 Mobility service. Thus we have the problem of,
how the
	 AAA server knows that.
=09
	 You can take a look at the thread:
=09
=09
http://www1.ietf.org/mail-archive/web/dime/current/msg00262.html
=09
	 for previous discussions on this topic which is still unsolved.
=09
	 At this point, as noted in:
=09
=09
http://www1.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-00.txt
=09
	 the 2 options that we have are:
=09
	 - define a new Service-Type for "Mobile IPv6 - Split" and puts
it in
	   DER message (Diameter EAP Request)
	 - define a new Application-ID and re-use Diameter EAP messages.
=09
	 Hope it helps,
=09
	 regards,
=09
	 Julien
=09
	>
	> If one is to go about without modifying RFC 3588 that uses
just one App ID
	> for Mobile IP, then I guess there is just one choice of having
	>
	> two Service_types for Mobile IPv6
	> and
	> one Service_Type for Mobile IPv4,
	>
	> (3 total for Mobile IP), but then don't you have to modify RFC
4004 to add
	> the service_type to Mobile IPv4?
	>
	> Madjid
	>
	> -----Original Message-----
	> From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr]
	> Sent: Monday, August 07, 2006 6:42 AM
	> To: Madjid Nakhjiri
	> Cc: 'Hannes Tschofenig'; dime@ietf.org
	> Subject: Re: [Dime] MIP6 App ID/ was: IETF#66 Meeting Minutes
	>
	> HI madjid,
	>
	> On Mon, Aug 07, 2006 at 06:34:55AM -0700, Madjid Nakhjiri
wrote:
	> > No worries, I was being humorous. I wanted to see what was
said during
	the
	> > meeting regarding the Mobile IP6 drafts. I tried to see the
archive
	> > discussions, but did not see anything in June or July
either.
	> > I am seeing all this discussion on the use of App IDs on the
ML, so I
	> wanted
	> > to see if MIP6 is getting its own App ID, or it is using the
App ID
	> assigned
	> > to Mobiloe IP in 3588?
	>
	>  basically the question is: do we need a specific App ID or do
a
	>  Service-Type AVP (indicating that it's a HA for the split
scenario) is
	>  sufficient ?
	>
	>
	>  regards,
	>
	>  Julien
	>
	> >
	> > R,
	> >
	> > Madjid
	> >
	> > -----Original Message-----
	> > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
	> > Sent: Saturday, August 05, 2006 5:22 AM
	> > To: Madjid Nakhjiri
	> > Cc: dime@ietf.org
	> > Subject: Re: [Dime] IETF#66 Meeting Minutes
	> >
	> > I agree that the meeting minutes are somewhat brief this
time.
	> > We will do better with the next IETF meeting...
	> >
	> > Ciao
	> > Hannes
	> >
	> > Madjid Nakhjiri wrote:
	> > > Was this minutes or 10-minutes:-)
	> > >
	> > > -----Original Message-----
	> > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
	> > > Sent: Wednesday, July 19, 2006 7:56 AM
	> > > To: dime@ietf.org
	> > > Subject: [Dime] IETF#66 Meeting Minutes
	> > >
	> > > Hi all,
	> > >
	> > > please take a look at the meeting minutes:
	> > > http://www3.ietf.org/proceedings/06jul/minutes/dime.txt
	> > >
	> > > Ciao
	> > > Hannes
	> > >
	> > > _______________________________________________
	> > > DiME mailing list
	> > > DiME@ietf.org
	> > > https://www1.ietf.org/mailman/listinfo/dime
	> > >
	> > >
	> > >
	> >
	> >
	> >
	> >
	> > _______________________________________________
	> > DiME mailing list
	> > DiME@ietf.org
	> > https://www1.ietf.org/mailman/listinfo/dime
	>
	> --
	> julien.bournelle at int-evry.fr
	>
	>
=09
	--
	julien.bournelle at int-evry.fr
=09
=09
=09
	_______________________________________________
	DiME mailing list
	DiME@ietf.org
	https://www1.ietf.org/mailman/listinfo/dime
=09
=09
=09
=09
=09


------_=_NextPart_001_01C6C08F.92E42404
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>RE: [Dime] MIP6 App ID/ revise RFC 3588???</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2963" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D380382217-15082006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Avi,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D380382217-15082006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D380382217-15082006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>3588 defines the IANA considerations for =
registering App=20
IDs.&nbsp; The document defines the initial Diameter IANA registry. This =
is=20
standard procedure.&nbsp; I don't quite understand what the problem=20
is.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D380382217-15082006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D380382217-15082006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>John</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D380382217-15082006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D380382217-15082006><PRE><SPAN =
class=3Dheader level=3D"3"><H3><A name=3Dsection-11.3>11.3</A>.  =
Application Identifiers</H3></SPAN>

   As defined in <A =
href=3D"http://tools.ietf.org/html/rfc3588#section-2.4">Section 2.4</A>, =
the Application Identifier is used to
   identify a specific Diameter Application.  There are standards-track
   application ids and vendor specific application ids.

   IANA [<A =
href=3D"http://tools.ietf.org/html/rfc3588#ref-IANA">IANA</A>] has =
assigned the range 0x00000001 to 0x00ffffff for
   standards-track applications; and 0x01000000 - 0xfffffffe for vendor
   specific applications, on a first-come, first-served basis.  The
   following values are allocated.

      Diameter Common Messages            0
      NASREQ                              1 [<A =
href=3D"http://tools.ietf.org/html/rfc3588#ref-NASREQ">NASREQ</A>]
      Mobile-IP                           2 [<A =
href=3D"http://tools.ietf.org/html/rfc3588#ref-DIAMMIP">DIAMMIP</A>]
      Diameter Base Accounting            3
      Relay                               0xffffffff

   Assignment of standards-track application IDs are by Designated
   Expert with Specification Required [<A =
href=3D"http://tools.ietf.org/html/rfc3588#ref-IANA">IANA</A>].

   Both Application-Id and Acct-Application-Id AVPs use the same
   Application Identifier space.

   Vendor-Specific Application Identifiers, are for Private Use.
   Vendor-Specific Application Identifiers are assigned on a First Come,
   First Served basis by IANA.</PRE><PRE>T</PRE></SPAN></DIV><BR>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> ext Avi Lior=20
  [mailto:avi@bridgewatersystems.com] <BR><B>Sent:</B> 15 August, 2006=20
  19:25<BR><B>To:</B> Madjid Nakhjiri; Julien Bournelle<BR><B>Cc:</B>=20
  dime@ietf.org<BR><B>Subject:</B> RE: [Dime] MIP6 App ID/ revise RFC=20
  3588???<BR></FONT><BR></DIV>
  <DIV></DIV><!-- Converted from text/plain format --><BR>
  <P><FONT size=3D2>I think that RFC3588 should not define any =
application=20
  ids.&nbsp; If it does they should be informative.<BR><BR>So if we are =
going to=20
  change 3588 we should remove any reference to any Application =
IDs.<BR><BR>IANA=20
  should be the only authoritative (normative) entity for Application=20
  IDS.<BR><BR>-----Original Message-----<BR>From: Madjid Nakhjiri [<A=20
  =
href=3D"mailto:mnakhjiri@huawei.com">mailto:mnakhjiri@huawei.com</A>]<BR>=
Sent:=20
  Tue 8/15/2006 12:10 PM<BR>To: Avi Lior; 'Julien Bournelle'<BR>Cc:=20
  dime@ietf.org<BR>Subject: RE: [Dime] MIP6 App ID/ revise RFC=20
  3588???<BR><BR>Because RFC 3588 defines a single Application ID for =
Mobile IP=20
  and 3588 is being revised anyway.<BR><BR>If this was a brand new =
application,=20
  it would not matter, but you already have one App ID for Mobile IP, =
that could=20
  only be used for MIP4, if you now define a different App ID for=20
  Mip6.<BR><BR><BR><BR>________________________________<BR><BR>From: Avi =
Lior=20
  [<A=20
  =
href=3D"mailto:avi@bridgewatersystems.com">mailto:avi@bridgewatersystems.=
com</A>]<BR>Sent:=20
  Tuesday, August 15, 2006 7:25 AM<BR>To: Madjid Nakhjiri; Julien=20
  Bournelle<BR>Cc: dime@ietf.org<BR>Subject: RE: [Dime] MIP6 App ID/ =
revise RFC=20
  3588???<BR><BR><BR><BR><BR><BR>I don't think RFC3588 needs to be =
touched when=20
  adding an new Application ID. Neither should<BR><BR>Why do you think =
you need=20
  to touch 3588 or 4004?<BR><BR>-----Original Message-----<BR>From: =
Madjid=20
  Nakhjiri [<A=20
  =
href=3D"mailto:mnakhjiri@huawei.com">mailto:mnakhjiri@huawei.com</A>]<BR>=
Sent:=20
  Tue 8/15/2006 10:07 AM<BR>To: Avi Lior; 'Julien Bournelle'<BR>Cc:=20
  dime@ietf.org; 'Madjid Nakhjiri'<BR>Subject: RE: [Dime] MIP6 App ID/ =
revise=20
  RFC 3588???<BR><BR>Hi Avi,<BR><BR><BR><BR>Not sure what "correct" =
meansJ I am=20
  planning on looking a bit closer at 3588 to see exactly how =
"application" and=20
  "App ID" is used.<BR><BR>As I said I _prefer_ adding a new Application =
ID for=20
  Mobile IPv6, but then both RFC 3588 and 4004 needs to be revised to =
reflect=20
  that, I think the harm for that is minimal anyway, given the fairly =
rare=20
  deployment of 4004 (I=20
  =
think).<BR><BR><BR><BR>Madjid.<BR><BR><BR><BR>___________________________=
_____<BR><BR>From:=20
  Avi Lior [<A=20
  =
href=3D"mailto:avi@bridgewatersystems.com">mailto:avi@bridgewatersystems.=
com</A>]<BR>Sent:=20
  Tuesday, August 15, 2006 7:01 AM<BR>To: Madjid Nakhjiri; Julien=20
  Bournelle<BR>Cc: dime@ietf.org<BR>Subject: RE: [Dime] MIP6 App ID/ =
revise RFC=20
  3588???<BR><BR><BR><BR><BR><BR>How about the correct (IMO) option and =
that is=20
  assign this new application its own Application ID.&nbsp; THis =
afterall is=20
  what an Application ID is supposed to do.<BR><BR><BR><BR>-----Original =

  Message-----<BR>From: Madjid Nakhjiri [<A=20
  =
href=3D"mailto:mnakhjiri@huawei.com">mailto:mnakhjiri@huawei.com</A>]<BR>=
Sent:=20
  Fri 8/11/2006 6:49 PM<BR>To: 'Julien Bournelle'<BR>Cc:=20
  dime@ietf.org<BR>Subject: RE: [Dime] MIP6 App ID/ revise RFC =
3588???<BR><BR>Hi=20
  Julien,<BR><BR>Thanks for pointing me to the archives.<BR>I have one =
general=20
  issue that maybe is related to me not quite understanding<BR>EAP-IKEv2 =
and=20
  that is EAP is run between a peer and an EAP server (in this<BR>case =
the=20
  backend AAA server). EAP-IKEv2 was designed so that a=20
  mature<BR>authentication/key management method could be used within =
EAP=20
  framework.<BR>Running EAP-IKEv2 results in authentication of peer to =
backend=20
  AAA, not to<BR>HA and possibly a key between the peer and AAA server. =
How does=20
  this help<BR>the need for IPsec between MN and HA?<BR><BR>Now as far =
as the=20
  discussions on the archives, RFC 4072 only talks about<BR>carrying EAP =
over=20
  Diameter without talking about what EAP is being used for<BR>(your =
question:=20
  mobility versus access service). I think distinguishing<BR>mobility =
versus=20
  access is a AAA signaling issue not an EAP signaling issue.<BR>In =
RADIUS and=20
  MIP4 it is simpler (look at draft-nakhjiri-radius-mip4-02)<BR>because =
there=20
  are attributes related to MIP4 authentication (such=20
  as<BR>MIP-MN-AAA-Authenticator, etc) within the Access Request that =
tells=20
  the<BR>server this is about RADIUS. Diameter on the other hand has the =
notion=20
  of<BR>Application ID and should not rely on explicit hint on this. =
When we got=20
  to<BR>the point of trying to translate Diameter messaging to RADIUS, =
we had=20
  to<BR>resort to port types, because Diameter had different messages =
(depending=20
  on<BR>whether HA or FA were involved) while all RADIUS had was=20
  Access<BR>Request/Accepts not recognizing between HA and FA.<BR>Here =
your case=20
  is different. Diameter already has an Application ID for<BR>Mobile IP. =
That is=20
  how you distinguish between access and mobility service,<BR>not =
through=20
  service type. Now there are two choices as I said before:<BR><BR>A) =
revise=20
  3588 to have one App ID for MIPv4 and one for MIPv6 (separate =
MIP6<BR>split=20
  versus integrated through service types). This of course mean =
revising<BR>4004=20
  to indicate specifically what MIPv4 App ID is.<BR><BR>B) Use the same =
App ID=20
  of 3588 for both MIP4 and MIP6, but then you have to<BR>define 4 =
service=20
  types<BR>1) MIP4 split<BR>2) MIP4 integrated<BR>3) MIP6 split<BR>4) =
MIP6=20
  integrated.<BR><BR>I prefer A (I can live with B, if you tie a rope to =
my=20
  neck, just kidding).<BR>I think A is cleaner. I think split-integrated =
versus=20
  MIP4-mip6 are two<BR>different degrees of freedom. Just because MIP4 =
WG did=20
  not make the split<BR>integrated distinction, does not mean the =
business case=20
  cannot exist.<BR>Plus that Avi stated that Service type seems to be=20
  mandatory.<BR><BR>Madjid<BR><BR>-----Original Message-----<BR>From: =
Julien=20
  Bournelle [<A=20
  =
href=3D"mailto:julien.bournelle@int-evry.fr">mailto:julien.bournelle@int-=
evry.fr</A>]<BR>Sent:=20
  Wednesday, August 09, 2006 1:39 AM<BR>To: Madjid Nakhjiri<BR>Cc: =
'Julien=20
  Bournelle'; 'Hannes Tschofenig'; dime@ietf.org<BR>Subject: Re: [Dime] =
MIP6 App=20
  ID/ revise RFC 3588???<BR><BR>Hi madjid,<BR><BR>On Tue, Aug 08, 2006 =
at=20
  04:51:08PM -0700, Madjid Nakhjiri wrote:<BR>&gt; Hi =
Julien,<BR>&gt;<BR>&gt; I=20
  just looked at the RFC 4005 definition of Service_Type.<BR>&gt; The =
services=20
  listed there are quite mixed. I am not quite sure what<BR>&gt; =
applications=20
  besides NASREQ are supposed to support Service_Type? Or is it<BR>&gt; =
that=20
  Mobile IP application assumes NASREQ must be =
supported?<BR><BR>&nbsp;Let me=20
  try to sum up the issue:<BR><BR>&nbsp;In the split scenario, the HA =
acts as a=20
  IKEv2 responder and uses EAP<BR>&nbsp;(oIKEv2) to authenticate the =
user (of=20
  the MN). The HA then relies on a<BR>&nbsp;EAP/AAA server and thus =
could use=20
  Diameter EAP. THe problem that we<BR>&nbsp;have here is that we are =
not=20
  performing AAA for "basic" network access<BR>&nbsp;but for the IPv6 =
Mobility=20
  service. Thus we have the problem of, how the<BR>&nbsp;AAA server =
knows=20
  that.<BR><BR>&nbsp;You can take a look at the thread:<BR><BR>&nbsp;<A=20
  =
href=3D"http://www1.ietf.org/mail-archive/web/dime/current/msg00262.html"=
>http://www1.ietf.org/mail-archive/web/dime/current/msg00262.html</A><BR>=
<BR>&nbsp;for=20
  previous discussions on this topic which is still =
unsolved.<BR><BR>&nbsp;At=20
  this point, as noted in:<BR><BR>&nbsp;<A=20
  =
href=3D"http://www1.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-0=
0.txt">http://www1.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-00=
.txt</A><BR><BR>&nbsp;the=20
  2 options that we have are:<BR><BR>&nbsp;- define a new Service-Type =
for=20
  "Mobile IPv6 - Split" and puts it in<BR>&nbsp;&nbsp; DER message =
(Diameter EAP=20
  Request)<BR>&nbsp;- define a new Application-ID and re-use Diameter =
EAP=20
  messages.<BR><BR>&nbsp;Hope it=20
  helps,<BR><BR>&nbsp;regards,<BR><BR>&nbsp;Julien<BR><BR>&gt;<BR>&gt; =
If one is=20
  to go about without modifying RFC 3588 that uses just one App =
ID<BR>&gt; for=20
  Mobile IP, then I guess there is just one choice of =
having<BR>&gt;<BR>&gt; two=20
  Service_types for Mobile IPv6<BR>&gt; and<BR>&gt; one Service_Type for =
Mobile=20
  IPv4,<BR>&gt;<BR>&gt; (3 total for Mobile IP), but then don't you have =
to=20
  modify RFC 4004 to add<BR>&gt; the service_type to Mobile=20
  IPv4?<BR>&gt;<BR>&gt; Madjid<BR>&gt;<BR>&gt; -----Original=20
  Message-----<BR>&gt; From: Julien Bournelle [<A=20
  =
href=3D"mailto:julien.bournelle@int-evry.fr">mailto:julien.bournelle@int-=
evry.fr</A>]<BR>&gt;=20
  Sent: Monday, August 07, 2006 6:42 AM<BR>&gt; To: Madjid =
Nakhjiri<BR>&gt; Cc:=20
  'Hannes Tschofenig'; dime@ietf.org<BR>&gt; Subject: Re: [Dime] MIP6 =
App ID/=20
  was: IETF#66 Meeting Minutes<BR>&gt;<BR>&gt; HI =
madjid,<BR>&gt;<BR>&gt; On=20
  Mon, Aug 07, 2006 at 06:34:55AM -0700, Madjid Nakhjiri wrote:<BR>&gt; =
&gt; No=20
  worries, I was being humorous. I wanted to see what was said=20
  during<BR>the<BR>&gt; &gt; meeting regarding the Mobile IP6 drafts. I =
tried to=20
  see the archive<BR>&gt; &gt; discussions, but did not see anything in =
June or=20
  July either.<BR>&gt; &gt; I am seeing all this discussion on the use =
of App=20
  IDs on the ML, so I<BR>&gt; wanted<BR>&gt; &gt; to see if MIP6 is =
getting its=20
  own App ID, or it is using the App ID<BR>&gt; assigned<BR>&gt; &gt; to =
Mobiloe=20
  IP in 3588?<BR>&gt;<BR>&gt;&nbsp; basically the question is: do we =
need a=20
  specific App ID or do a<BR>&gt;&nbsp; Service-Type AVP (indicating =
that it's a=20
  HA for the split scenario) is<BR>&gt;&nbsp; sufficient=20
  ?<BR>&gt;<BR>&gt;<BR>&gt;&nbsp; regards,<BR>&gt;<BR>&gt;&nbsp;=20
  Julien<BR>&gt;<BR>&gt; &gt;<BR>&gt; &gt; R,<BR>&gt; &gt;<BR>&gt; &gt;=20
  Madjid<BR>&gt; &gt;<BR>&gt; &gt; -----Original Message-----<BR>&gt; =
&gt; From:=20
  Hannes Tschofenig [<A=20
  =
href=3D"mailto:Hannes.Tschofenig@gmx.net">mailto:Hannes.Tschofenig@gmx.ne=
t</A>]<BR>&gt;=20
  &gt; Sent: Saturday, August 05, 2006 5:22 AM<BR>&gt; &gt; To: Madjid=20
  Nakhjiri<BR>&gt; &gt; Cc: dime@ietf.org<BR>&gt; &gt; Subject: Re: =
[Dime]=20
  IETF#66 Meeting Minutes<BR>&gt; &gt;<BR>&gt; &gt; I agree that the =
meeting=20
  minutes are somewhat brief this time.<BR>&gt; &gt; We will do better =
with the=20
  next IETF meeting...<BR>&gt; &gt;<BR>&gt; &gt; Ciao<BR>&gt; &gt;=20
  Hannes<BR>&gt; &gt;<BR>&gt; &gt; Madjid Nakhjiri wrote:<BR>&gt; &gt; =
&gt; Was=20
  this minutes or 10-minutes:-)<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt;=20
  -----Original Message-----<BR>&gt; &gt; &gt; From: Hannes Tschofenig =
[<A=20
  =
href=3D"mailto:Hannes.Tschofenig@gmx.net">mailto:Hannes.Tschofenig@gmx.ne=
t</A>]<BR>&gt;=20
  &gt; &gt; Sent: Wednesday, July 19, 2006 7:56 AM<BR>&gt; &gt; &gt; To: =

  dime@ietf.org<BR>&gt; &gt; &gt; Subject: [Dime] IETF#66 Meeting=20
  Minutes<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; Hi all,<BR>&gt; &gt; =
&gt;<BR>&gt;=20
  &gt; &gt; please take a look at the meeting minutes:<BR>&gt; &gt; &gt; =
<A=20
  =
href=3D"http://www3.ietf.org/proceedings/06jul/minutes/dime.txt">http://w=
ww3.ietf.org/proceedings/06jul/minutes/dime.txt</A><BR>&gt;=20
  &gt; &gt;<BR>&gt; &gt; &gt; Ciao<BR>&gt; &gt; &gt; Hannes<BR>&gt; &gt; =

  &gt;<BR>&gt; &gt; &gt; =
_______________________________________________<BR>&gt;=20
  &gt; &gt; DiME mailing list<BR>&gt; &gt; &gt; DiME@ietf.org<BR>&gt; =
&gt; &gt;=20
  <A=20
  =
href=3D"https://www1.ietf.org/mailman/listinfo/dime">https://www1.ietf.or=
g/mailman/listinfo/dime</A><BR>&gt;=20
  &gt; &gt;<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt;<BR>&gt; &gt;<BR>&gt;=20
  &gt;<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt; &gt;=20
  _______________________________________________<BR>&gt; &gt; DiME =
mailing=20
  list<BR>&gt; &gt; DiME@ietf.org<BR>&gt; &gt; <A=20
  =
href=3D"https://www1.ietf.org/mailman/listinfo/dime">https://www1.ietf.or=
g/mailman/listinfo/dime</A><BR>&gt;<BR>&gt;=20
  --<BR>&gt; julien.bournelle at=20
  int-evry.fr<BR>&gt;<BR>&gt;<BR><BR>--<BR>julien.bournelle at=20
  =
int-evry.fr<BR><BR><BR><BR>______________________________________________=
_<BR>DiME=20
  mailing list<BR>DiME@ietf.org<BR><A=20
  =
href=3D"https://www1.ietf.org/mailman/listinfo/dime">https://www1.ietf.or=
g/mailman/listinfo/dime</A><BR><BR><BR><BR><BR></FONT></P></BLOCKQUOTE></=
BODY></HTML>

------_=_NextPart_001_01C6C08F.92E42404--


--===============0695543943==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0695543943==--




From dime-bounces@ietf.org Tue Aug 15 13:26:46 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GD2gg-0008CO-Ln; Tue, 15 Aug 2006 13:26:46 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GD2ge-0008CI-NN
	for dime@ietf.org; Tue, 15 Aug 2006 13:26:44 -0400
Received: from mgw-ext13.nokia.com ([131.228.20.172])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD2gd-0001HF-9H
	for dime@ietf.org; Tue, 15 Aug 2006 13:26:44 -0400
Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143])
	by mgw-ext13.nokia.com (Switch-3.1.10/Switch-3.1.7) with ESMTP id
	k7FHQNBO027186; Tue, 15 Aug 2006 20:26:24 +0300
Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by
	esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 15 Aug 2006 20:26:24 +0300
Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by
	esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 15 Aug 2006 20:26:23 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???
Date: Tue, 15 Aug 2006 20:26:23 +0300
Message-ID: <BAA65A575825454CBB0103267553FCCC8920AF@esebe199.NOE.Nokia.com>
In-Reply-To: <001801c6c085$4e985fb0$2f01a8c0@china.huawei.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Dime] MIP6 App ID/ revise RFC 3588???
Thread-Index: Aca7j5pLlwjYezfqQhS35Ix/bK+xSgCBYw0QALeF6YMAABfC8AAAO289AAQhW/AAAqFwoA==
From: <john.loughney@nokia.com>
To: <mnakhjiri@huawei.com>, <avi@bridgewatersystems.com>,
	<julien.bournelle@int-evry.fr>
X-OriginalArrivalTime: 15 Aug 2006 17:26:23.0718 (UTC)
	FILETIME=[EE47D860:01C6C08F]
X-Spam-Score: 0.3 (/)
X-Scan-Signature: 47d6e33caab9a47557c20591160ac87c
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0687079803=="
Errors-To: dime-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0687079803==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C6C08F.EE366B4E"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6C08F.EE366B4E
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

3588 defines MIP(v4). If we think that a common App ID, that's fine. If
we think a seperate MIPv6 App ID is needed, than that is OK. I don't
think that which document these are defined are important (IMO). We can
define a new RFC that extends/updates 4004 for MIPv6, for example, if
needed.=20
=20
I'm happy just getting consensus on the technical issues here, not on
the documentation, at the moment.
=20
John


________________________________

	From: ext Madjid Nakhjiri [mailto:mnakhjiri@huawei.com]=20
	Sent: 15 August, 2006 19:10
	To: 'Avi Lior'; 'Julien Bournelle'
	Cc: dime@ietf.org
	Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???
=09
=09

	Because RFC 3588 defines a single Application ID for Mobile IP
and 3588 is being revised anyway.

	If this was a brand new application, it would not matter, but
you already have one App ID for Mobile IP, that could only be used for
MIP4, if you now define a different App ID for Mip6.

	=20

=09
________________________________


	From: Avi Lior [mailto:avi@bridgewatersystems.com]=20
	Sent: Tuesday, August 15, 2006 7:25 AM
	To: Madjid Nakhjiri; Julien Bournelle
	Cc: dime@ietf.org
	Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???

	=20

	=20

	I don't think RFC3588 needs to be touched when adding an new
Application ID. Neither should
=09
	Why do you think you need to touch 3588 or 4004?
=09
	-----Original Message-----
	From: Madjid Nakhjiri [mailto:mnakhjiri@huawei.com]
	Sent: Tue 8/15/2006 10:07 AM
	To: Avi Lior; 'Julien Bournelle'
	Cc: dime@ietf.org; 'Madjid Nakhjiri'
	Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???
=09
	Hi Avi,
=09
=09
=09
	Not sure what "correct" meansJ I am planning on looking a bit
closer at 3588 to see exactly how "application" and "App ID" is used.
=09
	As I said I _prefer_ adding a new Application ID for Mobile
IPv6, but then both RFC 3588 and 4004 needs to be revised to reflect
that, I think the harm for that is minimal anyway, given the fairly rare
deployment of 4004 (I think).
=09
=09
=09
	Madjid.
=09
=09
=09
	________________________________
=09
	From: Avi Lior [mailto:avi@bridgewatersystems.com]
	Sent: Tuesday, August 15, 2006 7:01 AM
	To: Madjid Nakhjiri; Julien Bournelle
	Cc: dime@ietf.org
	Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???
=09
=09
=09
=09
=09
	How about the correct (IMO) option and that is assign this new
application its own Application ID.  THis afterall is what an
Application ID is supposed to do.
=09
=09
=09
	-----Original Message-----
	From: Madjid Nakhjiri [mailto:mnakhjiri@huawei.com]
	Sent: Fri 8/11/2006 6:49 PM
	To: 'Julien Bournelle'
	Cc: dime@ietf.org
	Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???
=09
	Hi Julien,
=09
	Thanks for pointing me to the archives.
	I have one general issue that maybe is related to me not quite
understanding
	EAP-IKEv2 and that is EAP is run between a peer and an EAP
server (in this
	case the backend AAA server). EAP-IKEv2 was designed so that a
mature
	authentication/key management method could be used within EAP
framework.
	Running EAP-IKEv2 results in authentication of peer to backend
AAA, not to
	HA and possibly a key between the peer and AAA server. How does
this help
	the need for IPsec between MN and HA?
=09
	Now as far as the discussions on the archives, RFC 4072 only
talks about
	carrying EAP over Diameter without talking about what EAP is
being used for
	(your question: mobility versus access service). I think
distinguishing
	mobility versus access is a AAA signaling issue not an EAP
signaling issue.
	In RADIUS and MIP4 it is simpler (look at
draft-nakhjiri-radius-mip4-02)
	because there are attributes related to MIP4 authentication
(such as
	MIP-MN-AAA-Authenticator, etc) within the Access Request that
tells the
	server this is about RADIUS. Diameter on the other hand has the
notion of
	Application ID and should not rely on explicit hint on this.
When we got to
	the point of trying to translate Diameter messaging to RADIUS,
we had to
	resort to port types, because Diameter had different messages
(depending on
	whether HA or FA were involved) while all RADIUS had was Access
	Request/Accepts not recognizing between HA and FA.
	Here your case is different. Diameter already has an Application
ID for
	Mobile IP. That is how you distinguish between access and
mobility service,
	not through service type. Now there are two choices as I said
before:
=09
	A) revise 3588 to have one App ID for MIPv4 and one for MIPv6
(separate MIP6
	split versus integrated through service types). This of course
mean revising
	4004 to indicate specifically what MIPv4 App ID is.
=09
	B) Use the same App ID of 3588 for both MIP4 and MIP6, but then
you have to
	define 4 service types
	1) MIP4 split
	2) MIP4 integrated
	3) MIP6 split
	4) MIP6 integrated.
=09
	I prefer A (I can live with B, if you tie a rope to my neck,
just kidding).
	I think A is cleaner. I think split-integrated versus MIP4-mip6
are two
	different degrees of freedom. Just because MIP4 WG did not make
the split
	integrated distinction, does not mean the business case cannot
exist.
	Plus that Avi stated that Service type seems to be mandatory.
=09
	Madjid
=09
	-----Original Message-----
	From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr]
	Sent: Wednesday, August 09, 2006 1:39 AM
	To: Madjid Nakhjiri
	Cc: 'Julien Bournelle'; 'Hannes Tschofenig'; dime@ietf.org
	Subject: Re: [Dime] MIP6 App ID/ revise RFC 3588???
=09
	Hi madjid,
=09
	On Tue, Aug 08, 2006 at 04:51:08PM -0700, Madjid Nakhjiri wrote:
	> Hi Julien,
	>
	> I just looked at the RFC 4005 definition of Service_Type.
	> The services listed there are quite mixed. I am not quite sure
what
	> applications besides NASREQ are supposed to support
Service_Type? Or is it
	> that Mobile IP application assumes NASREQ must be supported?
=09
	 Let me try to sum up the issue:
=09
	 In the split scenario, the HA acts as a IKEv2 responder and
uses EAP
	 (oIKEv2) to authenticate the user (of the MN). The HA then
relies on a
	 EAP/AAA server and thus could use Diameter EAP. THe problem
that we
	 have here is that we are not performing AAA for "basic" network
access
	 but for the IPv6 Mobility service. Thus we have the problem of,
how the
	 AAA server knows that.
=09
	 You can take a look at the thread:
=09
=09
http://www1.ietf.org/mail-archive/web/dime/current/msg00262.html
=09
	 for previous discussions on this topic which is still unsolved.
=09
	 At this point, as noted in:
=09
=09
http://www1.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-00.txt
=09
	 the 2 options that we have are:
=09
	 - define a new Service-Type for "Mobile IPv6 - Split" and puts
it in
	   DER message (Diameter EAP Request)
	 - define a new Application-ID and re-use Diameter EAP messages.
=09
	 Hope it helps,
=09
	 regards,
=09
	 Julien
=09
	>
	> If one is to go about without modifying RFC 3588 that uses
just one App ID
	> for Mobile IP, then I guess there is just one choice of having
	>
	> two Service_types for Mobile IPv6
	> and
	> one Service_Type for Mobile IPv4,
	>
	> (3 total for Mobile IP), but then don't you have to modify RFC
4004 to add
	> the service_type to Mobile IPv4?
	>
	> Madjid
	>
	> -----Original Message-----
	> From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr]
	> Sent: Monday, August 07, 2006 6:42 AM
	> To: Madjid Nakhjiri
	> Cc: 'Hannes Tschofenig'; dime@ietf.org
	> Subject: Re: [Dime] MIP6 App ID/ was: IETF#66 Meeting Minutes
	>
	> HI madjid,
	>
	> On Mon, Aug 07, 2006 at 06:34:55AM -0700, Madjid Nakhjiri
wrote:
	> > No worries, I was being humorous. I wanted to see what was
said during
	the
	> > meeting regarding the Mobile IP6 drafts. I tried to see the
archive
	> > discussions, but did not see anything in June or July
either.
	> > I am seeing all this discussion on the use of App IDs on the
ML, so I
	> wanted
	> > to see if MIP6 is getting its own App ID, or it is using the
App ID
	> assigned
	> > to Mobiloe IP in 3588?
	>
	>  basically the question is: do we need a specific App ID or do
a
	>  Service-Type AVP (indicating that it's a HA for the split
scenario) is
	>  sufficient ?
	>
	>
	>  regards,
	>
	>  Julien
	>
	> >
	> > R,
	> >
	> > Madjid
	> >
	> > -----Original Message-----
	> > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
	> > Sent: Saturday, August 05, 2006 5:22 AM
	> > To: Madjid Nakhjiri
	> > Cc: dime@ietf.org
	> > Subject: Re: [Dime] IETF#66 Meeting Minutes
	> >
	> > I agree that the meeting minutes are somewhat brief this
time.
	> > We will do better with the next IETF meeting...
	> >
	> > Ciao
	> > Hannes
	> >
	> > Madjid Nakhjiri wrote:
	> > > Was this minutes or 10-minutes:-)
	> > >
	> > > -----Original Message-----
	> > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
	> > > Sent: Wednesday, July 19, 2006 7:56 AM
	> > > To: dime@ietf.org
	> > > Subject: [Dime] IETF#66 Meeting Minutes
	> > >
	> > > Hi all,
	> > >
	> > > please take a look at the meeting minutes:
	> > > http://www3.ietf.org/proceedings/06jul/minutes/dime.txt
	> > >
	> > > Ciao
	> > > Hannes
	> > >
	> > > _______________________________________________
	> > > DiME mailing list
	> > > DiME@ietf.org
	> > > https://www1.ietf.org/mailman/listinfo/dime
	> > >
	> > >
	> > >
	> >
	> >
	> >
	> >
	> > _______________________________________________
	> > DiME mailing list
	> > DiME@ietf.org
	> > https://www1.ietf.org/mailman/listinfo/dime
	>
	> --
	> julien.bournelle at int-evry.fr
	>
	>
=09
	--
	julien.bournelle at int-evry.fr
=09
=09
=09
	_______________________________________________
	DiME mailing list
	DiME@ietf.org
	https://www1.ietf.org/mailman/listinfo/dime
=09
=09


------_=_NextPart_001_01C6C08F.EE366B4E
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20
"urn:schemas-microsoft-com:vml" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word"><HEAD><TITLE>RE: [Dime] MIP6 App =
ID/ revise RFC 3588???</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2963" name=3DGENERATOR><!--[if !mso]>
<STYLE>v\:* {
	BEHAVIOR: url(#default#VML)
}
o\:* {
	BEHAVIOR: url(#default#VML)
}
w\:* {
	BEHAVIOR: url(#default#VML)
}
.shape {
	BEHAVIOR: url(#default#VML)
}
</STYLE>
<![endif]-->
<STYLE>@font-face {
	font-family: SimSun;
}
@font-face {
	font-family: Tahoma;
}
@font-face {
	font-family: SimSun;
}
@page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.25in 1.0in 1.25in; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: blue; TEXT-DECORATION: underline
}
P {
	FONT-SIZE: 12pt; MARGIN-LEFT: 0in; MARGIN-RIGHT: 0in; FONT-FAMILY: =
"Times New Roman"; mso-margin-top-alt: auto; mso-margin-bottom-alt: auto
}
SPAN.EmailStyle18 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal-reply
}
DIV.Section1 {
	page: Section1
}
</STYLE>
</HEAD>
<BODY lang=3DEN-US vLink=3Dblue link=3Dblue>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D771552317-15082006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>3588 defines MIP(v4). If we think that a common =
App ID,=20
that's fine. If we think a seperate MIPv6 App ID is needed, than that is =
OK. I=20
don't think that which document these are defined are important (IMO). =
We can=20
define a new RFC that extends/updates 4004 for MIPv6, for example, if =
needed.=20
</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D771552317-15082006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D771552317-15082006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>I'm happy just getting consensus on the =
technical issues=20
here, not on the documentation, at the moment.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D771552317-15082006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D771552317-15082006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>John</FONT></SPAN></DIV><BR>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> ext Madjid Nakhjiri=20
  [mailto:mnakhjiri@huawei.com] <BR><B>Sent:</B> 15 August, 2006=20
  19:10<BR><B>To:</B> 'Avi Lior'; 'Julien Bournelle'<BR><B>Cc:</B>=20
  dime@ietf.org<BR><B>Subject:</B> RE: [Dime] MIP6 App ID/ revise RFC=20
  3588???<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV class=3DSection1>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Because RFC =
3588=20
  defines a single Application ID for Mobile IP and 3588 is being =
revised=20
  anyway.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">If this was =
a brand=20
  new application, it would not matter, but you already have one App ID =
for=20
  Mobile IP, that could only be used for MIP4, if you now define a =
different App=20
  ID for Mip6.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <DIV>
  <DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" =
align=3Dcenter><FONT=20
  face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: 12pt">
  <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D3>
  </SPAN></FONT></DIV>
  <P class=3DMsoNormal><B><FONT face=3DTahoma size=3D2><SPAN=20
  style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">From:</SPAN></FONT></B><FONT=20
  face=3DTahoma size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma"> Avi=20
  Lior [mailto:avi@bridgewatersystems.com] <BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> Tuesday, August 15, 2006 =
7:25=20
  AM<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B> Madjid =
Nakhjiri;=20
  Julien Bournelle<BR><B><SPAN style=3D"FONT-WEIGHT: =
bold">Cc:</SPAN></B>=20
  dime@ietf.org<BR><B><SPAN style=3D"FONT-WEIGHT: =
bold">Subject:</SPAN></B> RE:=20
  [Dime] MIP6 App ID/ revise RFC =
3588???</SPAN></FONT><o:p></o:p></P></DIV>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P style=3D"MARGIN-BOTTOM: 12pt"><FONT face=3D"Times New Roman" =
size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt">I don't think RFC3588 needs to be touched =
when adding=20
  an new Application ID. Neither should<BR><BR>Why do you think you need =
to=20
  touch 3588 or 4004?<BR><BR>-----Original Message-----<BR>From: Madjid =
Nakhjiri=20
  [<A=20
  =
href=3D"mailto:mnakhjiri@huawei.com">mailto:mnakhjiri@huawei.com</A>]<BR>=
Sent:=20
  Tue 8/15/2006 10:07 AM<BR>To: Avi Lior; 'Julien Bournelle'<BR>Cc:=20
  dime@ietf.org; 'Madjid Nakhjiri'<BR>Subject: RE: [Dime] MIP6 App ID/ =
revise=20
  RFC 3588???<BR><BR>Hi Avi,<BR><BR><BR><BR>Not sure what "correct" =
meansJ I am=20
  planning on looking a bit closer at 3588 to see exactly how =
"application" and=20
  "App ID" is used.<BR><BR>As I said I _prefer_ adding a new Application =
ID for=20
  Mobile IPv6, but then both RFC 3588 and 4004 needs to be revised to =
reflect=20
  that, I think the harm for that is minimal anyway, given the fairly =
rare=20
  deployment of 4004 (I=20
  =
think).<BR><BR><BR><BR>Madjid.<BR><BR><BR><BR>___________________________=
_____<BR><BR>From:=20
  Avi Lior [<A=20
  =
href=3D"mailto:avi@bridgewatersystems.com">mailto:avi@bridgewatersystems.=
com</A>]<BR>Sent:=20
  Tuesday, August 15, 2006 7:01 AM<BR>To: Madjid Nakhjiri; Julien=20
  Bournelle<BR>Cc: dime@ietf.org<BR>Subject: RE: [Dime] MIP6 App ID/ =
revise RFC=20
  3588???<BR><BR><BR><BR><BR><BR>How about the correct (IMO) option and =
that is=20
  assign this new application its own Application ID.&nbsp; THis =
afterall is=20
  what an Application ID is supposed to do.<BR><BR><BR><BR>-----Original =

  Message-----<BR>From: Madjid Nakhjiri [<A=20
  =
href=3D"mailto:mnakhjiri@huawei.com">mailto:mnakhjiri@huawei.com</A>]<BR>=
Sent:=20
  Fri 8/11/2006 6:49 PM<BR>To: 'Julien Bournelle'<BR>Cc:=20
  dime@ietf.org<BR>Subject: RE: [Dime] MIP6 App ID/ revise RFC =
3588???<BR><BR>Hi=20
  Julien,<BR><BR>Thanks for pointing me to the archives.<BR>I have one =
general=20
  issue that maybe is related to me not quite understanding<BR>EAP-IKEv2 =
and=20
  that is EAP is run between a peer and an EAP server (in this<BR>case =
the=20
  backend AAA server). EAP-IKEv2 was designed so that a=20
  mature<BR>authentication/key management method could be used within =
EAP=20
  framework.<BR>Running EAP-IKEv2 results in authentication of peer to =
backend=20
  AAA, not to<BR>HA and possibly a key between the peer and AAA server. =
How does=20
  this help<BR>the need for IPsec between MN and HA?<BR><BR>Now as far =
as the=20
  discussions on the archives, RFC 4072 only talks about<BR>carrying EAP =
over=20
  Diameter without talking about what EAP is being used for<BR>(your =
question:=20
  mobility versus access service). I think distinguishing<BR>mobility =
versus=20
  access is a AAA signaling issue not an EAP signaling issue.<BR>In =
RADIUS and=20
  MIP4 it is simpler (look at draft-nakhjiri-radius-mip4-02)<BR>because =
there=20
  are attributes related to MIP4 authentication (such=20
  as<BR>MIP-MN-AAA-Authenticator, etc) within the Access Request that =
tells=20
  the<BR>server this is about RADIUS. Diameter on the other hand has the =
notion=20
  of<BR>Application ID and should not rely on explicit hint on this. =
When we got=20
  to<BR>the point of trying to translate Diameter messaging to RADIUS, =
we had=20
  to<BR>resort to port types, because Diameter had different messages =
(depending=20
  on<BR>whether HA or FA were involved) while all RADIUS had was=20
  Access<BR>Request/Accepts not recognizing between HA and FA.<BR>Here =
your case=20
  is different. Diameter already has an Application ID for<BR>Mobile IP. =
That is=20
  how you distinguish between access and mobility service,<BR>not =
through=20
  service type. Now there are two choices as I said before:<BR><BR>A) =
revise=20
  3588 to have one App ID for MIPv4 and one for MIPv6 (separate =
MIP6<BR>split=20
  versus integrated through service types). This of course mean =
revising<BR>4004=20
  to indicate specifically what MIPv4 App ID is.<BR><BR>B) Use the same =
App ID=20
  of 3588 for both MIP4 and MIP6, but then you have to<BR>define 4 =
service=20
  types<BR>1) MIP4 split<BR>2) MIP4 integrated<BR>3) MIP6 split<BR>4) =
MIP6=20
  integrated.<BR><BR>I prefer A (I can live with B, if you tie a rope to =
my=20
  neck, just kidding).<BR>I think A is cleaner. I think split-integrated =
versus=20
  MIP4-mip6 are two<BR>different degrees of freedom. Just because MIP4 =
WG did=20
  not make the split<BR>integrated distinction, does not mean the =
business case=20
  cannot exist.<BR>Plus that Avi stated that Service type seems to be=20
  mandatory.<BR><BR>Madjid<BR><BR>-----Original Message-----<BR>From: =
Julien=20
  Bournelle [<A=20
  =
href=3D"mailto:julien.bournelle@int-evry.fr">mailto:julien.bournelle@int-=
evry.fr</A>]<BR>Sent:=20
  Wednesday, August 09, 2006 1:39 AM<BR>To: Madjid Nakhjiri<BR>Cc: =
'Julien=20
  Bournelle'; 'Hannes Tschofenig'; dime@ietf.org<BR>Subject: Re: [Dime] =
MIP6 App=20
  ID/ revise RFC 3588???<BR><BR>Hi madjid,<BR><BR>On Tue, Aug 08, 2006 =
at=20
  04:51:08PM -0700, Madjid Nakhjiri wrote:<BR>&gt; Hi =
Julien,<BR>&gt;<BR>&gt; I=20
  just looked at the RFC 4005 definition of Service_Type.<BR>&gt; The =
services=20
  listed there are quite mixed. I am not quite sure what<BR>&gt; =
applications=20
  besides NASREQ are supposed to support Service_Type? Or is it<BR>&gt; =
that=20
  Mobile IP application assumes NASREQ must be =
supported?<BR><BR>&nbsp;Let me=20
  try to sum up the issue:<BR><BR>&nbsp;In the split scenario, the HA =
acts as a=20
  IKEv2 responder and uses EAP<BR>&nbsp;(oIKEv2) to authenticate the =
user (of=20
  the MN). The HA then relies on a<BR>&nbsp;EAP/AAA server and thus =
could use=20
  Diameter EAP. THe problem that we<BR>&nbsp;have here is that we are =
not=20
  performing AAA for "basic" network access<BR>&nbsp;but for the IPv6 =
Mobility=20
  service. Thus we have the problem of, how the<BR>&nbsp;AAA server =
knows=20
  that.<BR><BR>&nbsp;You can take a look at the thread:<BR><BR>&nbsp;<A=20
  =
href=3D"http://www1.ietf.org/mail-archive/web/dime/current/msg00262.html"=
>http://www1.ietf.org/mail-archive/web/dime/current/msg00262.html</A><BR>=
<BR>&nbsp;for=20
  previous discussions on this topic which is still =
unsolved.<BR><BR>&nbsp;At=20
  this point, as noted in:<BR><BR>&nbsp;<A=20
  =
href=3D"http://www1.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-0=
0.txt">http://www1.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-00=
.txt</A><BR><BR>&nbsp;the=20
  2 options that we have are:<BR><BR>&nbsp;- define a new Service-Type =
for=20
  "Mobile IPv6 - Split" and puts it in<BR>&nbsp;&nbsp; DER message =
(Diameter EAP=20
  Request)<BR>&nbsp;- define a new Application-ID and re-use Diameter =
EAP=20
  messages.<BR><BR>&nbsp;Hope it=20
  helps,<BR><BR>&nbsp;regards,<BR><BR>&nbsp;Julien<BR><BR>&gt;<BR>&gt; =
If one is=20
  to go about without modifying RFC 3588 that uses just one App =
ID<BR>&gt; for=20
  Mobile IP, then I guess there is just one choice of =
having<BR>&gt;<BR>&gt; two=20
  Service_types for Mobile IPv6<BR>&gt; and<BR>&gt; one Service_Type for =
Mobile=20
  IPv4,<BR>&gt;<BR>&gt; (3 total for Mobile IP), but then don't you have =
to=20
  modify RFC 4004 to add<BR>&gt; the service_type to Mobile=20
  IPv4?<BR>&gt;<BR>&gt; Madjid<BR>&gt;<BR>&gt; -----Original=20
  Message-----<BR>&gt; From: Julien Bournelle [<A=20
  =
href=3D"mailto:julien.bournelle@int-evry.fr">mailto:julien.bournelle@int-=
evry.fr</A>]<BR>&gt;=20
  Sent: Monday, August 07, 2006 6:42 AM<BR>&gt; To: Madjid =
Nakhjiri<BR>&gt; Cc:=20
  'Hannes Tschofenig'; dime@ietf.org<BR>&gt; Subject: Re: [Dime] MIP6 =
App ID/=20
  was: IETF#66 Meeting Minutes<BR>&gt;<BR>&gt; HI =
madjid,<BR>&gt;<BR>&gt; On=20
  Mon, Aug 07, 2006 at 06:34:55AM -0700, Madjid Nakhjiri wrote:<BR>&gt; =
&gt; No=20
  worries, I was being humorous. I wanted to see what was said=20
  during<BR>the<BR>&gt; &gt; meeting regarding the Mobile IP6 drafts. I =
tried to=20
  see the archive<BR>&gt; &gt; discussions, but did not see anything in =
June or=20
  July either.<BR>&gt; &gt; I am seeing all this discussion on the use =
of App=20
  IDs on the ML, so I<BR>&gt; wanted<BR>&gt; &gt; to see if MIP6 is =
getting its=20
  own App ID, or it is using the App ID<BR>&gt; assigned<BR>&gt; &gt; to =
Mobiloe=20
  IP in 3588?<BR>&gt;<BR>&gt;&nbsp; basically the question is: do we =
need a=20
  specific App ID or do a<BR>&gt;&nbsp; Service-Type AVP (indicating =
that it's a=20
  HA for the split scenario) is<BR>&gt;&nbsp; sufficient=20
  ?<BR>&gt;<BR>&gt;<BR>&gt;&nbsp; regards,<BR>&gt;<BR>&gt;&nbsp;=20
  Julien<BR>&gt;<BR>&gt; &gt;<BR>&gt; &gt; R,<BR>&gt; &gt;<BR>&gt; &gt;=20
  Madjid<BR>&gt; &gt;<BR>&gt; &gt; -----Original Message-----<BR>&gt; =
&gt; From:=20
  Hannes Tschofenig [<A=20
  =
href=3D"mailto:Hannes.Tschofenig@gmx.net">mailto:Hannes.Tschofenig@gmx.ne=
t</A>]<BR>&gt;=20
  &gt; Sent: Saturday, August 05, 2006 5:22 AM<BR>&gt; &gt; To: Madjid=20
  Nakhjiri<BR>&gt; &gt; Cc: dime@ietf.org<BR>&gt; &gt; Subject: Re: =
[Dime]=20
  IETF#66 Meeting Minutes<BR>&gt; &gt;<BR>&gt; &gt; I agree that the =
meeting=20
  minutes are somewhat brief this time.<BR>&gt; &gt; We will do better =
with the=20
  next IETF meeting...<BR>&gt; &gt;<BR>&gt; &gt; Ciao<BR>&gt; &gt;=20
  Hannes<BR>&gt; &gt;<BR>&gt; &gt; Madjid Nakhjiri wrote:<BR>&gt; &gt; =
&gt; Was=20
  this minutes or 10-minutes:-)<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt;=20
  -----Original Message-----<BR>&gt; &gt; &gt; From: Hannes Tschofenig =
[<A=20
  =
href=3D"mailto:Hannes.Tschofenig@gmx.net">mailto:Hannes.Tschofenig@gmx.ne=
t</A>]<BR>&gt;=20
  &gt; &gt; Sent: Wednesday, July 19, 2006 7:56 AM<BR>&gt; &gt; &gt; To: =

  dime@ietf.org<BR>&gt; &gt; &gt; Subject: [Dime] IETF#66 Meeting=20
  Minutes<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; Hi all,<BR>&gt; &gt; =
&gt;<BR>&gt;=20
  &gt; &gt; please take a look at the meeting minutes:<BR>&gt; &gt; &gt; =
<A=20
  =
href=3D"http://www3.ietf.org/proceedings/06jul/minutes/dime.txt">http://w=
ww3.ietf.org/proceedings/06jul/minutes/dime.txt</A><BR>&gt;=20
  &gt; &gt;<BR>&gt; &gt; &gt; Ciao<BR>&gt; &gt; &gt; Hannes<BR>&gt; &gt; =

  &gt;<BR>&gt; &gt; &gt; =
_______________________________________________<BR>&gt;=20
  &gt; &gt; DiME mailing list<BR>&gt; &gt; &gt; DiME@ietf.org<BR>&gt; =
&gt; &gt;=20
  <A=20
  =
href=3D"https://www1.ietf.org/mailman/listinfo/dime">https://www1.ietf.or=
g/mailman/listinfo/dime</A><BR>&gt;=20
  &gt; &gt;<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt;<BR>&gt; &gt;<BR>&gt;=20
  &gt;<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt; &gt;=20
  _______________________________________________<BR>&gt; &gt; DiME =
mailing=20
  list<BR>&gt; &gt; DiME@ietf.org<BR>&gt; &gt; <A=20
  =
href=3D"https://www1.ietf.org/mailman/listinfo/dime">https://www1.ietf.or=
g/mailman/listinfo/dime</A><BR>&gt;<BR>&gt;=20
  --<BR>&gt; julien.bournelle at=20
  int-evry.fr<BR>&gt;<BR>&gt;<BR><BR>--<BR>julien.bournelle at=20
  =
int-evry.fr<BR><BR><BR><BR>______________________________________________=
_<BR>DiME=20
  mailing list<BR>DiME@ietf.org<BR><A=20
  =
href=3D"https://www1.ietf.org/mailman/listinfo/dime">https://www1.ietf.or=
g/mailman/listinfo/dime</A><BR><BR></SPAN></FONT><o:p></o:p></P></DIV></B=
LOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C6C08F.EE366B4E--


--===============0687079803==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0687079803==--




From dime-bounces@ietf.org Tue Aug 15 13:27:06 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GD2h0-0008GE-J5; Tue, 15 Aug 2006 13:27:06 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GD2gy-0008FH-31
	for dime@ietf.org; Tue, 15 Aug 2006 13:27:04 -0400
Received: from sj-iport-1-in.cisco.com ([171.71.176.70]
	helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GD2gx-0001Ic-04
	for dime@ietf.org; Tue, 15 Aug 2006 13:27:04 -0400
Received: from sj-dkim-2.cisco.com ([171.71.179.186])
	by sj-iport-1.cisco.com with ESMTP; 15 Aug 2006 10:27:02 -0700
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254])
	by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id
	k7FHR2Th021830; Tue, 15 Aug 2006 10:27:02 -0700
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com
	[128.107.191.63])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k7FHR2lN006774;
	Tue, 15 Aug 2006 10:27:02 -0700 (PDT)
Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by
	xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 15 Aug 2006 10:27:02 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???
Date: Tue, 15 Aug 2006 10:27:00 -0700
Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB26250272B8A9@xmb-sjc-215.amer.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Dime] MIP6 App ID/ revise RFC 3588???
Thread-Index: Aca7j5pLlwjYezfqQhS35Ix/bK+xSgCBYw0QALeF6YMAABfC8AAAO289AAQhW/AAApAF8A==
From: "Glen Zorn \(gwz\)" <gwz@cisco.com>
To: "Madjid Nakhjiri" <mnakhjiri@huawei.com>,
	"Avi Lior" <avi@bridgewatersystems.com>,
	"Julien Bournelle" <julien.bournelle@int-evry.fr>
X-OriginalArrivalTime: 15 Aug 2006 17:27:02.0113 (UTC)
	FILETIME=[052A7510:01C6C090]
DKIM-Signature: a=rsa-sha1; q=dns; l=25232; t=1155662822; x=1156526822;
	c=relaxed/simple; s=sjdkim2002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=gwz@cisco.com;
	z=From:=22Glen=20Zorn=20\(gwz\)=22=20<gwz@cisco.com>
	|Subject:RE=3A=20[Dime]=20MIP6=20App=20ID/=20revise=20RFC=203588???;
	X=v=3Dcisco.com=3B=20h=3DDFkMl2Ub3zoT/KoPNyLm7iLwkas=3D;
	b=hoRChEpYDWDVnmd0cPpnqVrztiokEGtkZqnIMrypdYN48srbTETvfYmC6vC9CLEgSASl6P0P
	LaQLjgYCu2dYnP6qo3h4VaWaysjGmwX4XvHYBh25BcbHOhT5V94wRi+X;
Authentication-Results: sj-dkim-2.cisco.com; header.From=gwz@cisco.com;
	dkim=pass (
	52 extraneous bytes; sig from cisco.com verified; ); 
X-Spam-Score: 0.1 (/)
X-Scan-Signature: eb4c5242518af073df6fe45f0d1cde3e
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0484520641=="
Errors-To: dime-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0484520641==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C6C090.05156CCE"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6C090.05156CCE
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Because RFC 3588 defines a single Application ID for Mobile IP and 3588 =
is being revised anyway.

If this was a brand new application, it would not matter, but you =
already have one App ID for Mobile IP, that could only be used for MIP4, =
if you now define a different App ID for Mip6.=20

=20

OK, so what?  The app ID defined in 3588 is pretty obviously for MIP v4, =
the one defined in 4004 is _specifically_ for MIP v4, & MIP v6 _is_ a =
brand new application....

=20

________________________________

From: Avi Lior [mailto:avi@bridgewatersystems.com]=20
Sent: Tuesday, August 15, 2006 7:25 AM
To: Madjid Nakhjiri; Julien Bournelle
Cc: dime@ietf.org
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???

=20

=20

I don't think RFC3588 needs to be touched when adding an new Application =
ID. Neither should

Why do you think you need to touch 3588 or 4004?

-----Original Message-----
From: Madjid Nakhjiri [mailto:mnakhjiri@huawei.com]
Sent: Tue 8/15/2006 10:07 AM
To: Avi Lior; 'Julien Bournelle'
Cc: dime@ietf.org; 'Madjid Nakhjiri'
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???

Hi Avi,



Not sure what "correct" meansJ I am planning on looking a bit closer at =
3588 to see exactly how "application" and "App ID" is used.

As I said I _prefer_ adding a new Application ID for Mobile IPv6, but =
then both RFC 3588 and 4004 needs to be revised to reflect that, I think =
the harm for that is minimal anyway, given the fairly rare deployment of =
4004 (I think).



Madjid.



________________________________

From: Avi Lior [mailto:avi@bridgewatersystems.com]
Sent: Tuesday, August 15, 2006 7:01 AM
To: Madjid Nakhjiri; Julien Bournelle
Cc: dime@ietf.org
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???





How about the correct (IMO) option and that is assign this new =
application its own Application ID.  THis afterall is what an =
Application ID is supposed to do.



-----Original Message-----
From: Madjid Nakhjiri [mailto:mnakhjiri@huawei.com]
Sent: Fri 8/11/2006 6:49 PM
To: 'Julien Bournelle'
Cc: dime@ietf.org
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???

Hi Julien,

Thanks for pointing me to the archives.
I have one general issue that maybe is related to me not quite =
understanding
EAP-IKEv2 and that is EAP is run between a peer and an EAP server (in =
this
case the backend AAA server). EAP-IKEv2 was designed so that a mature
authentication/key management method could be used within EAP framework.
Running EAP-IKEv2 results in authentication of peer to backend AAA, not =
to
HA and possibly a key between the peer and AAA server. How does this =
help
the need for IPsec between MN and HA?

Now as far as the discussions on the archives, RFC 4072 only talks about
carrying EAP over Diameter without talking about what EAP is being used =
for
(your question: mobility versus access service). I think distinguishing
mobility versus access is a AAA signaling issue not an EAP signaling =
issue.
In RADIUS and MIP4 it is simpler (look at draft-nakhjiri-radius-mip4-02)
because there are attributes related to MIP4 authentication (such as
MIP-MN-AAA-Authenticator, etc) within the Access Request that tells the
server this is about RADIUS. Diameter on the other hand has the notion =
of
Application ID and should not rely on explicit hint on this. When we got =
to
the point of trying to translate Diameter messaging to RADIUS, we had to
resort to port types, because Diameter had different messages (depending =
on
whether HA or FA were involved) while all RADIUS had was Access
Request/Accepts not recognizing between HA and FA.
Here your case is different. Diameter already has an Application ID for
Mobile IP. That is how you distinguish between access and mobility =
service,
not through service type. Now there are two choices as I said before:

A) revise 3588 to have one App ID for MIPv4 and one for MIPv6 (separate =
MIP6
split versus integrated through service types). This of course mean =
revising
4004 to indicate specifically what MIPv4 App ID is.

B) Use the same App ID of 3588 for both MIP4 and MIP6, but then you have =
to
define 4 service types
1) MIP4 split
2) MIP4 integrated
3) MIP6 split
4) MIP6 integrated.

I prefer A (I can live with B, if you tie a rope to my neck, just =
kidding).
I think A is cleaner. I think split-integrated versus MIP4-mip6 are two
different degrees of freedom. Just because MIP4 WG did not make the =
split
integrated distinction, does not mean the business case cannot exist.
Plus that Avi stated that Service type seems to be mandatory.

Madjid

-----Original Message-----
From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr]
Sent: Wednesday, August 09, 2006 1:39 AM
To: Madjid Nakhjiri
Cc: 'Julien Bournelle'; 'Hannes Tschofenig'; dime@ietf.org
Subject: Re: [Dime] MIP6 App ID/ revise RFC 3588???

Hi madjid,

On Tue, Aug 08, 2006 at 04:51:08PM -0700, Madjid Nakhjiri wrote:
> Hi Julien,
>
> I just looked at the RFC 4005 definition of Service_Type.
> The services listed there are quite mixed. I am not quite sure what
> applications besides NASREQ are supposed to support Service_Type? Or =
is it
> that Mobile IP application assumes NASREQ must be supported?

 Let me try to sum up the issue:

 In the split scenario, the HA acts as a IKEv2 responder and uses EAP
 (oIKEv2) to authenticate the user (of the MN). The HA then relies on a
 EAP/AAA server and thus could use Diameter EAP. THe problem that we
 have here is that we are not performing AAA for "basic" network access
 but for the IPv6 Mobility service. Thus we have the problem of, how the
 AAA server knows that.

 You can take a look at the thread:

 http://www1.ietf.org/mail-archive/web/dime/current/msg00262.html

 for previous discussions on this topic which is still unsolved.

 At this point, as noted in:

 http://www1.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-00.txt

 the 2 options that we have are:

 - define a new Service-Type for "Mobile IPv6 - Split" and puts it in
   DER message (Diameter EAP Request)
 - define a new Application-ID and re-use Diameter EAP messages.

 Hope it helps,

 regards,

 Julien

>
> If one is to go about without modifying RFC 3588 that uses just one =
App ID
> for Mobile IP, then I guess there is just one choice of having
>
> two Service_types for Mobile IPv6
> and
> one Service_Type for Mobile IPv4,
>
> (3 total for Mobile IP), but then don't you have to modify RFC 4004 to =
add
> the service_type to Mobile IPv4?
>
> Madjid
>
> -----Original Message-----
> From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr]
> Sent: Monday, August 07, 2006 6:42 AM
> To: Madjid Nakhjiri
> Cc: 'Hannes Tschofenig'; dime@ietf.org
> Subject: Re: [Dime] MIP6 App ID/ was: IETF#66 Meeting Minutes
>
> HI madjid,
>
> On Mon, Aug 07, 2006 at 06:34:55AM -0700, Madjid Nakhjiri wrote:
> > No worries, I was being humorous. I wanted to see what was said =
during
the
> > meeting regarding the Mobile IP6 drafts. I tried to see the archive
> > discussions, but did not see anything in June or July either.
> > I am seeing all this discussion on the use of App IDs on the ML, so =
I
> wanted
> > to see if MIP6 is getting its own App ID, or it is using the App ID
> assigned
> > to Mobiloe IP in 3588?
>
>  basically the question is: do we need a specific App ID or do a
>  Service-Type AVP (indicating that it's a HA for the split scenario) =
is
>  sufficient ?
>
>
>  regards,
>
>  Julien
>
> >
> > R,
> >
> > Madjid
> >
> > -----Original Message-----
> > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
> > Sent: Saturday, August 05, 2006 5:22 AM
> > To: Madjid Nakhjiri
> > Cc: dime@ietf.org
> > Subject: Re: [Dime] IETF#66 Meeting Minutes
> >
> > I agree that the meeting minutes are somewhat brief this time.
> > We will do better with the next IETF meeting...
> >
> > Ciao
> > Hannes
> >
> > Madjid Nakhjiri wrote:
> > > Was this minutes or 10-minutes:-)
> > >
> > > -----Original Message-----
> > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
> > > Sent: Wednesday, July 19, 2006 7:56 AM
> > > To: dime@ietf.org
> > > Subject: [Dime] IETF#66 Meeting Minutes
> > >
> > > Hi all,
> > >
> > > please take a look at the meeting minutes:
> > > http://www3.ietf.org/proceedings/06jul/minutes/dime.txt
> > >
> > > Ciao
> > > Hannes
> > >
> > > _______________________________________________
> > > DiME mailing list
> > > DiME@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/dime
> > >
> > >
> > >
> >
> >
> >
> >
> > _______________________________________________
> > DiME mailing list
> > DiME@ietf.org
> > https://www1.ietf.org/mailman/listinfo/dime
>
> --
> julien.bournelle at int-evry.fr
>
>

--
julien.bournelle at int-evry.fr



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




------_=_NextPart_001_01C6C090.05156CCE
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20
"urn:schemas-microsoft-com:vml" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word"><HEAD><TITLE>RE: [Dime] MIP6 App =
ID/ revise RFC 3588???</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1555" name=3DGENERATOR><!--[if !mso]>
<STYLE>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</STYLE>
<![endif]-->
<STYLE>
<!--
 /* Font Definitions */
 @font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
p
	{mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</STYLE>
</HEAD>
<BODY lang=3DEN-US vLink=3Dblue link=3Dblue>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Because RFC =
3588=20
defines a single Application ID for Mobile IP and 3588 is being revised=20
anyway.<o:p></o:p></SPAN></FONT></DIV>
<DIV class=3DSection1>
<P class=3DMsoNormal><FONT color=3Dnavy><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">If this was a =
brand new=20
application, it would not matter,<SPAN class=3D852582117-15082006><FONT=20
color=3D#0000ff>&nbsp;</FONT></SPAN></SPAN></FONT><FONT =
color=3Dnavy><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">but you =
already have=20
one App ID for Mobile IP, that could only be used for MIP4, if you now =
define a=20
different App ID for Mip6.<FONT color=3D#0000ff><SPAN=20
class=3D852582117-15082006>&nbsp;</SPAN></FONT></SPAN></FONT></P>
<P class=3DMsoNormal><FONT color=3Dnavy><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT=20
color=3D#0000ff><SPAN=20
class=3D852582117-15082006></SPAN></FONT></SPAN></FONT>&nbsp;</P>
<P class=3DMsoNormal><FONT color=3Dnavy><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><FONT=20
color=3D#0000ff><SPAN class=3D852582117-15082006>OK, so what?&nbsp; The =
app ID=20
defined in 3588 is pretty obviously for MIP v4, the one defined in 4004 =
is=20
_specifically_ for MIP v4, &amp; MIP v6 _is_ a brand new=20
application....</SPAN></FONT></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<DIV>
<DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" align=3Dcenter><FONT =

face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: 12pt">
<HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D3>
</SPAN></FONT></DIV>
<P class=3DMsoNormal><B><FONT face=3DTahoma size=3D2><SPAN=20
style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">From:</SPAN></FONT></B><FONT=20
face=3DTahoma size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma"> Avi Lior=20
[mailto:avi@bridgewatersystems.com] <BR><B><SPAN=20
style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> Tuesday, August 15, 2006 =
7:25=20
AM<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B> Madjid =
Nakhjiri; Julien=20
Bournelle<BR><B><SPAN style=3D"FONT-WEIGHT: bold">Cc:</SPAN></B>=20
dime@ietf.org<BR><B><SPAN style=3D"FONT-WEIGHT: =
bold">Subject:</SPAN></B> RE:=20
[Dime] MIP6 App ID/ revise RFC =
3588???</SPAN></FONT><o:p></o:p></P></DIV>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P style=3D"MARGIN-BOTTOM: 12pt"><FONT face=3D"Times New Roman" =
size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt">I don't think RFC3588 needs to be touched when =
adding an=20
new Application ID. Neither should<BR><BR>Why do you think you need to =
touch=20
3588 or 4004?<BR><BR>-----Original Message-----<BR>From: Madjid Nakhjiri =
[<A=20
href=3D"mailto:mnakhjiri@huawei.com">mailto:mnakhjiri@huawei.com</A>]<BR>=
Sent: Tue=20
8/15/2006 10:07 AM<BR>To: Avi Lior; 'Julien Bournelle'<BR>Cc: =
dime@ietf.org;=20
'Madjid Nakhjiri'<BR>Subject: RE: [Dime] MIP6 App ID/ revise RFC=20
3588???<BR><BR>Hi Avi,<BR><BR><BR><BR>Not sure what "correct" meansJ I =
am=20
planning on looking a bit closer at 3588 to see exactly how =
"application" and=20
"App ID" is used.<BR><BR>As I said I _prefer_ adding a new Application =
ID for=20
Mobile IPv6, but then both RFC 3588 and 4004 needs to be revised to =
reflect=20
that, I think the harm for that is minimal anyway, given the fairly rare =

deployment of 4004 (I=20
think).<BR><BR><BR><BR>Madjid.<BR><BR><BR><BR>___________________________=
_____<BR><BR>From:=20
Avi Lior [<A=20
href=3D"mailto:avi@bridgewatersystems.com">mailto:avi@bridgewatersystems.=
com</A>]<BR>Sent:=20
Tuesday, August 15, 2006 7:01 AM<BR>To: Madjid Nakhjiri; Julien =
Bournelle<BR>Cc:=20
dime@ietf.org<BR>Subject: RE: [Dime] MIP6 App ID/ revise RFC=20
3588???<BR><BR><BR><BR><BR><BR>How about the correct (IMO) option and =
that is=20
assign this new application its own Application ID.&nbsp; THis afterall =
is what=20
an Application ID is supposed to do.<BR><BR><BR><BR>-----Original=20
Message-----<BR>From: Madjid Nakhjiri [<A=20
href=3D"mailto:mnakhjiri@huawei.com">mailto:mnakhjiri@huawei.com</A>]<BR>=
Sent: Fri=20
8/11/2006 6:49 PM<BR>To: 'Julien Bournelle'<BR>Cc: =
dime@ietf.org<BR>Subject: RE:=20
[Dime] MIP6 App ID/ revise RFC 3588???<BR><BR>Hi Julien,<BR><BR>Thanks =
for=20
pointing me to the archives.<BR>I have one general issue that maybe is =
related=20
to me not quite understanding<BR>EAP-IKEv2 and that is EAP is run =
between a peer=20
and an EAP server (in this<BR>case the backend AAA server). EAP-IKEv2 =
was=20
designed so that a mature<BR>authentication/key management method could =
be used=20
within EAP framework.<BR>Running EAP-IKEv2 results in authentication of =
peer to=20
backend AAA, not to<BR>HA and possibly a key between the peer and AAA =
server.=20
How does this help<BR>the need for IPsec between MN and HA?<BR><BR>Now =
as far as=20
the discussions on the archives, RFC 4072 only talks about<BR>carrying =
EAP over=20
Diameter without talking about what EAP is being used for<BR>(your =
question:=20
mobility versus access service). I think distinguishing<BR>mobility =
versus=20
access is a AAA signaling issue not an EAP signaling issue.<BR>In RADIUS =
and=20
MIP4 it is simpler (look at draft-nakhjiri-radius-mip4-02)<BR>because =
there are=20
attributes related to MIP4 authentication (such =
as<BR>MIP-MN-AAA-Authenticator,=20
etc) within the Access Request that tells the<BR>server this is about =
RADIUS.=20
Diameter on the other hand has the notion of<BR>Application ID and =
should not=20
rely on explicit hint on this. When we got to<BR>the point of trying to=20
translate Diameter messaging to RADIUS, we had to<BR>resort to port =
types,=20
because Diameter had different messages (depending on<BR>whether HA or =
FA were=20
involved) while all RADIUS had was Access<BR>Request/Accepts not =
recognizing=20
between HA and FA.<BR>Here your case is different. Diameter already has =
an=20
Application ID for<BR>Mobile IP. That is how you distinguish between =
access and=20
mobility service,<BR>not through service type. Now there are two choices =
as I=20
said before:<BR><BR>A) revise 3588 to have one App ID for MIPv4 and one =
for=20
MIPv6 (separate MIP6<BR>split versus integrated through service types). =
This of=20
course mean revising<BR>4004 to indicate specifically what MIPv4 App ID=20
is.<BR><BR>B) Use the same App ID of 3588 for both MIP4 and MIP6, but =
then you=20
have to<BR>define 4 service types<BR>1) MIP4 split<BR>2) MIP4 =
integrated<BR>3)=20
MIP6 split<BR>4) MIP6 integrated.<BR><BR>I prefer A (I can live with B, =
if you=20
tie a rope to my neck, just kidding).<BR>I think A is cleaner. I think=20
split-integrated versus MIP4-mip6 are two<BR>different degrees of =
freedom. Just=20
because MIP4 WG did not make the split<BR>integrated distinction, does =
not mean=20
the business case cannot exist.<BR>Plus that Avi stated that Service =
type seems=20
to be mandatory.<BR><BR>Madjid<BR><BR>-----Original =
Message-----<BR>From: Julien=20
Bournelle [<A=20
href=3D"mailto:julien.bournelle@int-evry.fr">mailto:julien.bournelle@int-=
evry.fr</A>]<BR>Sent:=20
Wednesday, August 09, 2006 1:39 AM<BR>To: Madjid Nakhjiri<BR>Cc: 'Julien =

Bournelle'; 'Hannes Tschofenig'; dime@ietf.org<BR>Subject: Re: [Dime] =
MIP6 App=20
ID/ revise RFC 3588???<BR><BR>Hi madjid,<BR><BR>On Tue, Aug 08, 2006 at=20
04:51:08PM -0700, Madjid Nakhjiri wrote:<BR>&gt; Hi =
Julien,<BR>&gt;<BR>&gt; I=20
just looked at the RFC 4005 definition of Service_Type.<BR>&gt; The =
services=20
listed there are quite mixed. I am not quite sure what<BR>&gt; =
applications=20
besides NASREQ are supposed to support Service_Type? Or is it<BR>&gt; =
that=20
Mobile IP application assumes NASREQ must be supported?<BR><BR>&nbsp;Let =
me try=20
to sum up the issue:<BR><BR>&nbsp;In the split scenario, the HA acts as =
a IKEv2=20
responder and uses EAP<BR>&nbsp;(oIKEv2) to authenticate the user (of =
the MN).=20
The HA then relies on a<BR>&nbsp;EAP/AAA server and thus could use =
Diameter EAP.=20
THe problem that we<BR>&nbsp;have here is that we are not performing AAA =
for=20
"basic" network access<BR>&nbsp;but for the IPv6 Mobility service. Thus =
we have=20
the problem of, how the<BR>&nbsp;AAA server knows that.<BR><BR>&nbsp;You =
can=20
take a look at the thread:<BR><BR>&nbsp;<A=20
href=3D"http://www1.ietf.org/mail-archive/web/dime/current/msg00262.html"=
>http://www1.ietf.org/mail-archive/web/dime/current/msg00262.html</A><BR>=
<BR>&nbsp;for=20
previous discussions on this topic which is still =
unsolved.<BR><BR>&nbsp;At this=20
point, as noted in:<BR><BR>&nbsp;<A=20
href=3D"http://www1.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-0=
0.txt">http://www1.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-00=
.txt</A><BR><BR>&nbsp;the=20
2 options that we have are:<BR><BR>&nbsp;- define a new Service-Type for =
"Mobile=20
IPv6 - Split" and puts it in<BR>&nbsp;&nbsp; DER message (Diameter EAP=20
Request)<BR>&nbsp;- define a new Application-ID and re-use Diameter EAP=20
messages.<BR><BR>&nbsp;Hope it=20
helps,<BR><BR>&nbsp;regards,<BR><BR>&nbsp;Julien<BR><BR>&gt;<BR>&gt; If =
one is=20
to go about without modifying RFC 3588 that uses just one App ID<BR>&gt; =
for=20
Mobile IP, then I guess there is just one choice of =
having<BR>&gt;<BR>&gt; two=20
Service_types for Mobile IPv6<BR>&gt; and<BR>&gt; one Service_Type for =
Mobile=20
IPv4,<BR>&gt;<BR>&gt; (3 total for Mobile IP), but then don't you have =
to modify=20
RFC 4004 to add<BR>&gt; the service_type to Mobile IPv4?<BR>&gt;<BR>&gt; =

Madjid<BR>&gt;<BR>&gt; -----Original Message-----<BR>&gt; From: Julien =
Bournelle=20
[<A=20
href=3D"mailto:julien.bournelle@int-evry.fr">mailto:julien.bournelle@int-=
evry.fr</A>]<BR>&gt;=20
Sent: Monday, August 07, 2006 6:42 AM<BR>&gt; To: Madjid =
Nakhjiri<BR>&gt; Cc:=20
'Hannes Tschofenig'; dime@ietf.org<BR>&gt; Subject: Re: [Dime] MIP6 App =
ID/ was:=20
IETF#66 Meeting Minutes<BR>&gt;<BR>&gt; HI madjid,<BR>&gt;<BR>&gt; On =
Mon, Aug=20
07, 2006 at 06:34:55AM -0700, Madjid Nakhjiri wrote:<BR>&gt; &gt; No =
worries, I=20
was being humorous. I wanted to see what was said during<BR>the<BR>&gt; =
&gt;=20
meeting regarding the Mobile IP6 drafts. I tried to see the =
archive<BR>&gt; &gt;=20
discussions, but did not see anything in June or July either.<BR>&gt; =
&gt; I am=20
seeing all this discussion on the use of App IDs on the ML, so I<BR>&gt; =

wanted<BR>&gt; &gt; to see if MIP6 is getting its own App ID, or it is =
using the=20
App ID<BR>&gt; assigned<BR>&gt; &gt; to Mobiloe IP in=20
3588?<BR>&gt;<BR>&gt;&nbsp; basically the question is: do we need a =
specific App=20
ID or do a<BR>&gt;&nbsp; Service-Type AVP (indicating that it's a HA for =
the=20
split scenario) is<BR>&gt;&nbsp; sufficient =
?<BR>&gt;<BR>&gt;<BR>&gt;&nbsp;=20
regards,<BR>&gt;<BR>&gt;&nbsp; Julien<BR>&gt;<BR>&gt; &gt;<BR>&gt; &gt;=20
R,<BR>&gt; &gt;<BR>&gt; &gt; Madjid<BR>&gt; &gt;<BR>&gt; &gt; =
-----Original=20
Message-----<BR>&gt; &gt; From: Hannes Tschofenig [<A=20
href=3D"mailto:Hannes.Tschofenig@gmx.net">mailto:Hannes.Tschofenig@gmx.ne=
t</A>]<BR>&gt;=20
&gt; Sent: Saturday, August 05, 2006 5:22 AM<BR>&gt; &gt; To: Madjid=20
Nakhjiri<BR>&gt; &gt; Cc: dime@ietf.org<BR>&gt; &gt; Subject: Re: [Dime] =
IETF#66=20
Meeting Minutes<BR>&gt; &gt;<BR>&gt; &gt; I agree that the meeting =
minutes are=20
somewhat brief this time.<BR>&gt; &gt; We will do better with the next =
IETF=20
meeting...<BR>&gt; &gt;<BR>&gt; &gt; Ciao<BR>&gt; &gt; Hannes<BR>&gt;=20
&gt;<BR>&gt; &gt; Madjid Nakhjiri wrote:<BR>&gt; &gt; &gt; Was this =
minutes or=20
10-minutes:-)<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; -----Original=20
Message-----<BR>&gt; &gt; &gt; From: Hannes Tschofenig [<A=20
href=3D"mailto:Hannes.Tschofenig@gmx.net">mailto:Hannes.Tschofenig@gmx.ne=
t</A>]<BR>&gt;=20
&gt; &gt; Sent: Wednesday, July 19, 2006 7:56 AM<BR>&gt; &gt; &gt; To:=20
dime@ietf.org<BR>&gt; &gt; &gt; Subject: [Dime] IETF#66 Meeting =
Minutes<BR>&gt;=20
&gt; &gt;<BR>&gt; &gt; &gt; Hi all,<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; =
please=20
take a look at the meeting minutes:<BR>&gt; &gt; &gt; <A=20
href=3D"http://www3.ietf.org/proceedings/06jul/minutes/dime.txt">http://w=
ww3.ietf.org/proceedings/06jul/minutes/dime.txt</A><BR>&gt;=20
&gt; &gt;<BR>&gt; &gt; &gt; Ciao<BR>&gt; &gt; &gt; Hannes<BR>&gt; &gt;=20
&gt;<BR>&gt; &gt; &gt; =
_______________________________________________<BR>&gt;=20
&gt; &gt; DiME mailing list<BR>&gt; &gt; &gt; DiME@ietf.org<BR>&gt; &gt; =
&gt; <A=20
href=3D"https://www1.ietf.org/mailman/listinfo/dime">https://www1.ietf.or=
g/mailman/listinfo/dime</A><BR>&gt;=20
&gt; &gt;<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt;<BR>&gt; &gt;<BR>&gt; =
&gt;<BR>&gt;=20
&gt;<BR>&gt; &gt;<BR>&gt; &gt;=20
_______________________________________________<BR>&gt; &gt; DiME =
mailing=20
list<BR>&gt; &gt; DiME@ietf.org<BR>&gt; &gt; <A=20
href=3D"https://www1.ietf.org/mailman/listinfo/dime">https://www1.ietf.or=
g/mailman/listinfo/dime</A><BR>&gt;<BR>&gt;=20
--<BR>&gt; julien.bournelle at=20
int-evry.fr<BR>&gt;<BR>&gt;<BR><BR>--<BR>julien.bournelle at=20
int-evry.fr<BR><BR><BR><BR>______________________________________________=
_<BR>DiME=20
mailing list<BR>DiME@ietf.org<BR><A=20
href=3D"https://www1.ietf.org/mailman/listinfo/dime">https://www1.ietf.or=
g/mailman/listinfo/dime</A><BR><BR></SPAN></FONT><o:p></o:p></P></DIV></B=
ODY></HTML>

------_=_NextPart_001_01C6C090.05156CCE--


--===============0484520641==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0484520641==--




From dime-bounces@ietf.org Tue Aug 15 13:27:40 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GD2hY-0008Ne-2O; Tue, 15 Aug 2006 13:27:40 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GD2hW-0008NY-VL
	for dime@ietf.org; Tue, 15 Aug 2006 13:27:38 -0400
Received: from mgw-ext11.nokia.com ([131.228.20.170])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD2hV-0001KZ-Qq
	for dime@ietf.org; Tue, 15 Aug 2006 13:27:38 -0400
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211])
	by mgw-ext11.nokia.com (Switch-3.1.10/Switch-3.1.7) with ESMTP id
	k7FGRRMF016655; Tue, 15 Aug 2006 19:27:27 +0300
Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by
	esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 15 Aug 2006 20:27:26 +0300
Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by
	esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 15 Aug 2006 20:27:25 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???
Date: Tue, 15 Aug 2006 20:27:25 +0300
Message-ID: <BAA65A575825454CBB0103267553FCCC8920B0@esebe199.NOE.Nokia.com>
In-Reply-To: <E7CCE8A83907104ABEE91AC3AE3709A01167DA@exchange.bridgewatersys.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Dime] MIP6 App ID/ revise RFC 3588???
Thread-Index: Aca7j5pLlwjYezfqQhS35Ix/bK+xSgCBYw0QALeF6YMABy8igA==
From: <john.loughney@nokia.com>
To: <avi@bridgewatersystems.com>, <mnakhjiri@huawei.com>,
	<julien.bournelle@int-evry.fr>
X-OriginalArrivalTime: 15 Aug 2006 17:27:25.0876 (UTC)
	FILETIME=[13546740:01C6C090]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 9724479da43a8325ad975c1a9b841870
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0583083194=="
Errors-To: dime-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0583083194==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C6C090.133D8466"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6C090.133D8466
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Agree with Avi. =20


________________________________

	From: ext Avi Lior [mailto:avi@bridgewatersystems.com]=20
	Sent: 15 August, 2006 17:01
	To: Madjid Nakhjiri; Julien Bournelle
	Cc: dime@ietf.org
	Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???
=09
=09


	How about the correct (IMO) option and that is assign this new
application its own Application ID.  THis afterall is what an
Application ID is supposed to do.
=09
=09
=09
	-----Original Message-----
	From: Madjid Nakhjiri [mailto:mnakhjiri@huawei.com]
	Sent: Fri 8/11/2006 6:49 PM
	To: 'Julien Bournelle'
	Cc: dime@ietf.org
	Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???
=09
	Hi Julien,
=09
	Thanks for pointing me to the archives.
	I have one general issue that maybe is related to me not quite
understanding
	EAP-IKEv2 and that is EAP is run between a peer and an EAP
server (in this
	case the backend AAA server). EAP-IKEv2 was designed so that a
mature
	authentication/key management method could be used within EAP
framework.
	Running EAP-IKEv2 results in authentication of peer to backend
AAA, not to
	HA and possibly a key between the peer and AAA server. How does
this help
	the need for IPsec between MN and HA?
=09
	Now as far as the discussions on the archives, RFC 4072 only
talks about
	carrying EAP over Diameter without talking about what EAP is
being used for
	(your question: mobility versus access service). I think
distinguishing
	mobility versus access is a AAA signaling issue not an EAP
signaling issue.
	In RADIUS and MIP4 it is simpler (look at
draft-nakhjiri-radius-mip4-02)
	because there are attributes related to MIP4 authentication
(such as
	MIP-MN-AAA-Authenticator, etc) within the Access Request that
tells the
	server this is about RADIUS. Diameter on the other hand has the
notion of
	Application ID and should not rely on explicit hint on this.
When we got to
	the point of trying to translate Diameter messaging to RADIUS,
we had to
	resort to port types, because Diameter had different messages
(depending on
	whether HA or FA were involved) while all RADIUS had was Access
	Request/Accepts not recognizing between HA and FA.
	Here your case is different. Diameter already has an Application
ID for
	Mobile IP. That is how you distinguish between access and
mobility service,
	not through service type. Now there are two choices as I said
before:
=09
	A) revise 3588 to have one App ID for MIPv4 and one for MIPv6
(separate MIP6
	split versus integrated through service types). This of course
mean revising
	4004 to indicate specifically what MIPv4 App ID is.
=09
	B) Use the same App ID of 3588 for both MIP4 and MIP6, but then
you have to
	define 4 service types
	1) MIP4 split
	2) MIP4 integrated
	3) MIP6 split
	4) MIP6 integrated.
=09
	I prefer A (I can live with B, if you tie a rope to my neck,
just kidding).
	I think A is cleaner. I think split-integrated versus MIP4-mip6
are two
	different degrees of freedom. Just because MIP4 WG did not make
the split
	integrated distinction, does not mean the business case cannot
exist.
	Plus that Avi stated that Service type seems to be mandatory.
=09
	Madjid
=09
	-----Original Message-----
	From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr]
	Sent: Wednesday, August 09, 2006 1:39 AM
	To: Madjid Nakhjiri
	Cc: 'Julien Bournelle'; 'Hannes Tschofenig'; dime@ietf.org
	Subject: Re: [Dime] MIP6 App ID/ revise RFC 3588???
=09
	Hi madjid,
=09
	On Tue, Aug 08, 2006 at 04:51:08PM -0700, Madjid Nakhjiri wrote:
	> Hi Julien,
	>
	> I just looked at the RFC 4005 definition of Service_Type.
	> The services listed there are quite mixed. I am not quite sure
what
	> applications besides NASREQ are supposed to support
Service_Type? Or is it
	> that Mobile IP application assumes NASREQ must be supported?
=09
	 Let me try to sum up the issue:
=09
	 In the split scenario, the HA acts as a IKEv2 responder and
uses EAP
	 (oIKEv2) to authenticate the user (of the MN). The HA then
relies on a
	 EAP/AAA server and thus could use Diameter EAP. THe problem
that we
	 have here is that we are not performing AAA for "basic" network
access
	 but for the IPv6 Mobility service. Thus we have the problem of,
how the
	 AAA server knows that.
=09
	 You can take a look at the thread:
=09
=09
http://www1.ietf.org/mail-archive/web/dime/current/msg00262.html
=09
	 for previous discussions on this topic which is still unsolved.
=09
	 At this point, as noted in:
=09
=09
http://www1.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-00.txt
=09
	 the 2 options that we have are:
=09
	 - define a new Service-Type for "Mobile IPv6 - Split" and puts
it in
	   DER message (Diameter EAP Request)
	 - define a new Application-ID and re-use Diameter EAP messages.
=09
	 Hope it helps,
=09
	 regards,
=09
	 Julien
=09
	>
	> If one is to go about without modifying RFC 3588 that uses
just one App ID
	> for Mobile IP, then I guess there is just one choice of having
	>
	> two Service_types for Mobile IPv6
	> and
	> one Service_Type for Mobile IPv4,
	>
	> (3 total for Mobile IP), but then don't you have to modify RFC
4004 to add
	> the service_type to Mobile IPv4?
	>
	> Madjid
	>
	> -----Original Message-----
	> From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr]
	> Sent: Monday, August 07, 2006 6:42 AM
	> To: Madjid Nakhjiri
	> Cc: 'Hannes Tschofenig'; dime@ietf.org
	> Subject: Re: [Dime] MIP6 App ID/ was: IETF#66 Meeting Minutes
	>
	> HI madjid,
	>
	> On Mon, Aug 07, 2006 at 06:34:55AM -0700, Madjid Nakhjiri
wrote:
	> > No worries, I was being humorous. I wanted to see what was
said during
	the
	> > meeting regarding the Mobile IP6 drafts. I tried to see the
archive
	> > discussions, but did not see anything in June or July
either.
	> > I am seeing all this discussion on the use of App IDs on the
ML, so I
	> wanted
	> > to see if MIP6 is getting its own App ID, or it is using the
App ID
	> assigned
	> > to Mobiloe IP in 3588?
	>
	>  basically the question is: do we need a specific App ID or do
a
	>  Service-Type AVP (indicating that it's a HA for the split
scenario) is
	>  sufficient ?
	>
	>
	>  regards,
	>
	>  Julien
	>
	> >
	> > R,
	> >
	> > Madjid
	> >
	> > -----Original Message-----
	> > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
	> > Sent: Saturday, August 05, 2006 5:22 AM
	> > To: Madjid Nakhjiri
	> > Cc: dime@ietf.org
	> > Subject: Re: [Dime] IETF#66 Meeting Minutes
	> >
	> > I agree that the meeting minutes are somewhat brief this
time.
	> > We will do better with the next IETF meeting...
	> >
	> > Ciao
	> > Hannes
	> >
	> > Madjid Nakhjiri wrote:
	> > > Was this minutes or 10-minutes:-)
	> > >
	> > > -----Original Message-----
	> > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
	> > > Sent: Wednesday, July 19, 2006 7:56 AM
	> > > To: dime@ietf.org
	> > > Subject: [Dime] IETF#66 Meeting Minutes
	> > >
	> > > Hi all,
	> > >
	> > > please take a look at the meeting minutes:
	> > > http://www3.ietf.org/proceedings/06jul/minutes/dime.txt
	> > >
	> > > Ciao
	> > > Hannes
	> > >
	> > > _______________________________________________
	> > > DiME mailing list
	> > > DiME@ietf.org
	> > > https://www1.ietf.org/mailman/listinfo/dime
	> > >
	> > >
	> > >
	> >
	> >
	> >
	> >
	> > _______________________________________________
	> > DiME mailing list
	> > DiME@ietf.org
	> > https://www1.ietf.org/mailman/listinfo/dime
	>
	> --
	> julien.bournelle at int-evry.fr
	>
	>
=09
	--
	julien.bournelle at int-evry.fr
=09
=09
=09
	_______________________________________________
	DiME mailing list
	DiME@ietf.org
	https://www1.ietf.org/mailman/listinfo/dime
=09
=09


------_=_NextPart_001_01C6C090.133D8466
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>RE: [Dime] MIP6 App ID/ revise RFC 3588???</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2963" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D524442617-15082006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Agree with Avi.&nbsp; </FONT></SPAN></DIV><BR>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> ext Avi Lior=20
  [mailto:avi@bridgewatersystems.com] <BR><B>Sent:</B> 15 August, 2006=20
  17:01<BR><B>To:</B> Madjid Nakhjiri; Julien Bournelle<BR><B>Cc:</B>=20
  dime@ietf.org<BR><B>Subject:</B> RE: [Dime] MIP6 App ID/ revise RFC=20
  3588???<BR></FONT><BR></DIV>
  <DIV></DIV><!-- Converted from text/plain format --><BR>
  <P><FONT size=3D2>How about the correct (IMO) option and that is =
assign this new=20
  application its own Application ID.&nbsp; THis afterall is what an =
Application=20
  ID is supposed to do.<BR><BR><BR><BR>-----Original =
Message-----<BR>From:=20
  Madjid Nakhjiri [<A=20
  =
href=3D"mailto:mnakhjiri@huawei.com">mailto:mnakhjiri@huawei.com</A>]<BR>=
Sent:=20
  Fri 8/11/2006 6:49 PM<BR>To: 'Julien Bournelle'<BR>Cc:=20
  dime@ietf.org<BR>Subject: RE: [Dime] MIP6 App ID/ revise RFC =
3588???<BR><BR>Hi=20
  Julien,<BR><BR>Thanks for pointing me to the archives.<BR>I have one =
general=20
  issue that maybe is related to me not quite understanding<BR>EAP-IKEv2 =
and=20
  that is EAP is run between a peer and an EAP server (in this<BR>case =
the=20
  backend AAA server). EAP-IKEv2 was designed so that a=20
  mature<BR>authentication/key management method could be used within =
EAP=20
  framework.<BR>Running EAP-IKEv2 results in authentication of peer to =
backend=20
  AAA, not to<BR>HA and possibly a key between the peer and AAA server. =
How does=20
  this help<BR>the need for IPsec between MN and HA?<BR><BR>Now as far =
as the=20
  discussions on the archives, RFC 4072 only talks about<BR>carrying EAP =
over=20
  Diameter without talking about what EAP is being used for<BR>(your =
question:=20
  mobility versus access service). I think distinguishing<BR>mobility =
versus=20
  access is a AAA signaling issue not an EAP signaling issue.<BR>In =
RADIUS and=20
  MIP4 it is simpler (look at draft-nakhjiri-radius-mip4-02)<BR>because =
there=20
  are attributes related to MIP4 authentication (such=20
  as<BR>MIP-MN-AAA-Authenticator, etc) within the Access Request that =
tells=20
  the<BR>server this is about RADIUS. Diameter on the other hand has the =
notion=20
  of<BR>Application ID and should not rely on explicit hint on this. =
When we got=20
  to<BR>the point of trying to translate Diameter messaging to RADIUS, =
we had=20
  to<BR>resort to port types, because Diameter had different messages =
(depending=20
  on<BR>whether HA or FA were involved) while all RADIUS had was=20
  Access<BR>Request/Accepts not recognizing between HA and FA.<BR>Here =
your case=20
  is different. Diameter already has an Application ID for<BR>Mobile IP. =
That is=20
  how you distinguish between access and mobility service,<BR>not =
through=20
  service type. Now there are two choices as I said before:<BR><BR>A) =
revise=20
  3588 to have one App ID for MIPv4 and one for MIPv6 (separate =
MIP6<BR>split=20
  versus integrated through service types). This of course mean =
revising<BR>4004=20
  to indicate specifically what MIPv4 App ID is.<BR><BR>B) Use the same =
App ID=20
  of 3588 for both MIP4 and MIP6, but then you have to<BR>define 4 =
service=20
  types<BR>1) MIP4 split<BR>2) MIP4 integrated<BR>3) MIP6 split<BR>4) =
MIP6=20
  integrated.<BR><BR>I prefer A (I can live with B, if you tie a rope to =
my=20
  neck, just kidding).<BR>I think A is cleaner. I think split-integrated =
versus=20
  MIP4-mip6 are two<BR>different degrees of freedom. Just because MIP4 =
WG did=20
  not make the split<BR>integrated distinction, does not mean the =
business case=20
  cannot exist.<BR>Plus that Avi stated that Service type seems to be=20
  mandatory.<BR><BR>Madjid<BR><BR>-----Original Message-----<BR>From: =
Julien=20
  Bournelle [<A=20
  =
href=3D"mailto:julien.bournelle@int-evry.fr">mailto:julien.bournelle@int-=
evry.fr</A>]<BR>Sent:=20
  Wednesday, August 09, 2006 1:39 AM<BR>To: Madjid Nakhjiri<BR>Cc: =
'Julien=20
  Bournelle'; 'Hannes Tschofenig'; dime@ietf.org<BR>Subject: Re: [Dime] =
MIP6 App=20
  ID/ revise RFC 3588???<BR><BR>Hi madjid,<BR><BR>On Tue, Aug 08, 2006 =
at=20
  04:51:08PM -0700, Madjid Nakhjiri wrote:<BR>&gt; Hi =
Julien,<BR>&gt;<BR>&gt; I=20
  just looked at the RFC 4005 definition of Service_Type.<BR>&gt; The =
services=20
  listed there are quite mixed. I am not quite sure what<BR>&gt; =
applications=20
  besides NASREQ are supposed to support Service_Type? Or is it<BR>&gt; =
that=20
  Mobile IP application assumes NASREQ must be =
supported?<BR><BR>&nbsp;Let me=20
  try to sum up the issue:<BR><BR>&nbsp;In the split scenario, the HA =
acts as a=20
  IKEv2 responder and uses EAP<BR>&nbsp;(oIKEv2) to authenticate the =
user (of=20
  the MN). The HA then relies on a<BR>&nbsp;EAP/AAA server and thus =
could use=20
  Diameter EAP. THe problem that we<BR>&nbsp;have here is that we are =
not=20
  performing AAA for "basic" network access<BR>&nbsp;but for the IPv6 =
Mobility=20
  service. Thus we have the problem of, how the<BR>&nbsp;AAA server =
knows=20
  that.<BR><BR>&nbsp;You can take a look at the thread:<BR><BR>&nbsp;<A=20
  =
href=3D"http://www1.ietf.org/mail-archive/web/dime/current/msg00262.html"=
>http://www1.ietf.org/mail-archive/web/dime/current/msg00262.html</A><BR>=
<BR>&nbsp;for=20
  previous discussions on this topic which is still =
unsolved.<BR><BR>&nbsp;At=20
  this point, as noted in:<BR><BR>&nbsp;<A=20
  =
href=3D"http://www1.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-0=
0.txt">http://www1.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-00=
.txt</A><BR><BR>&nbsp;the=20
  2 options that we have are:<BR><BR>&nbsp;- define a new Service-Type =
for=20
  "Mobile IPv6 - Split" and puts it in<BR>&nbsp;&nbsp; DER message =
(Diameter EAP=20
  Request)<BR>&nbsp;- define a new Application-ID and re-use Diameter =
EAP=20
  messages.<BR><BR>&nbsp;Hope it=20
  helps,<BR><BR>&nbsp;regards,<BR><BR>&nbsp;Julien<BR><BR>&gt;<BR>&gt; =
If one is=20
  to go about without modifying RFC 3588 that uses just one App =
ID<BR>&gt; for=20
  Mobile IP, then I guess there is just one choice of =
having<BR>&gt;<BR>&gt; two=20
  Service_types for Mobile IPv6<BR>&gt; and<BR>&gt; one Service_Type for =
Mobile=20
  IPv4,<BR>&gt;<BR>&gt; (3 total for Mobile IP), but then don't you have =
to=20
  modify RFC 4004 to add<BR>&gt; the service_type to Mobile=20
  IPv4?<BR>&gt;<BR>&gt; Madjid<BR>&gt;<BR>&gt; -----Original=20
  Message-----<BR>&gt; From: Julien Bournelle [<A=20
  =
href=3D"mailto:julien.bournelle@int-evry.fr">mailto:julien.bournelle@int-=
evry.fr</A>]<BR>&gt;=20
  Sent: Monday, August 07, 2006 6:42 AM<BR>&gt; To: Madjid =
Nakhjiri<BR>&gt; Cc:=20
  'Hannes Tschofenig'; dime@ietf.org<BR>&gt; Subject: Re: [Dime] MIP6 =
App ID/=20
  was: IETF#66 Meeting Minutes<BR>&gt;<BR>&gt; HI =
madjid,<BR>&gt;<BR>&gt; On=20
  Mon, Aug 07, 2006 at 06:34:55AM -0700, Madjid Nakhjiri wrote:<BR>&gt; =
&gt; No=20
  worries, I was being humorous. I wanted to see what was said=20
  during<BR>the<BR>&gt; &gt; meeting regarding the Mobile IP6 drafts. I =
tried to=20
  see the archive<BR>&gt; &gt; discussions, but did not see anything in =
June or=20
  July either.<BR>&gt; &gt; I am seeing all this discussion on the use =
of App=20
  IDs on the ML, so I<BR>&gt; wanted<BR>&gt; &gt; to see if MIP6 is =
getting its=20
  own App ID, or it is using the App ID<BR>&gt; assigned<BR>&gt; &gt; to =
Mobiloe=20
  IP in 3588?<BR>&gt;<BR>&gt;&nbsp; basically the question is: do we =
need a=20
  specific App ID or do a<BR>&gt;&nbsp; Service-Type AVP (indicating =
that it's a=20
  HA for the split scenario) is<BR>&gt;&nbsp; sufficient=20
  ?<BR>&gt;<BR>&gt;<BR>&gt;&nbsp; regards,<BR>&gt;<BR>&gt;&nbsp;=20
  Julien<BR>&gt;<BR>&gt; &gt;<BR>&gt; &gt; R,<BR>&gt; &gt;<BR>&gt; &gt;=20
  Madjid<BR>&gt; &gt;<BR>&gt; &gt; -----Original Message-----<BR>&gt; =
&gt; From:=20
  Hannes Tschofenig [<A=20
  =
href=3D"mailto:Hannes.Tschofenig@gmx.net">mailto:Hannes.Tschofenig@gmx.ne=
t</A>]<BR>&gt;=20
  &gt; Sent: Saturday, August 05, 2006 5:22 AM<BR>&gt; &gt; To: Madjid=20
  Nakhjiri<BR>&gt; &gt; Cc: dime@ietf.org<BR>&gt; &gt; Subject: Re: =
[Dime]=20
  IETF#66 Meeting Minutes<BR>&gt; &gt;<BR>&gt; &gt; I agree that the =
meeting=20
  minutes are somewhat brief this time.<BR>&gt; &gt; We will do better =
with the=20
  next IETF meeting...<BR>&gt; &gt;<BR>&gt; &gt; Ciao<BR>&gt; &gt;=20
  Hannes<BR>&gt; &gt;<BR>&gt; &gt; Madjid Nakhjiri wrote:<BR>&gt; &gt; =
&gt; Was=20
  this minutes or 10-minutes:-)<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt;=20
  -----Original Message-----<BR>&gt; &gt; &gt; From: Hannes Tschofenig =
[<A=20
  =
href=3D"mailto:Hannes.Tschofenig@gmx.net">mailto:Hannes.Tschofenig@gmx.ne=
t</A>]<BR>&gt;=20
  &gt; &gt; Sent: Wednesday, July 19, 2006 7:56 AM<BR>&gt; &gt; &gt; To: =

  dime@ietf.org<BR>&gt; &gt; &gt; Subject: [Dime] IETF#66 Meeting=20
  Minutes<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt; Hi all,<BR>&gt; &gt; =
&gt;<BR>&gt;=20
  &gt; &gt; please take a look at the meeting minutes:<BR>&gt; &gt; &gt; =
<A=20
  =
href=3D"http://www3.ietf.org/proceedings/06jul/minutes/dime.txt">http://w=
ww3.ietf.org/proceedings/06jul/minutes/dime.txt</A><BR>&gt;=20
  &gt; &gt;<BR>&gt; &gt; &gt; Ciao<BR>&gt; &gt; &gt; Hannes<BR>&gt; &gt; =

  &gt;<BR>&gt; &gt; &gt; =
_______________________________________________<BR>&gt;=20
  &gt; &gt; DiME mailing list<BR>&gt; &gt; &gt; DiME@ietf.org<BR>&gt; =
&gt; &gt;=20
  <A=20
  =
href=3D"https://www1.ietf.org/mailman/listinfo/dime">https://www1.ietf.or=
g/mailman/listinfo/dime</A><BR>&gt;=20
  &gt; &gt;<BR>&gt; &gt; &gt;<BR>&gt; &gt; &gt;<BR>&gt; &gt;<BR>&gt;=20
  &gt;<BR>&gt; &gt;<BR>&gt; &gt;<BR>&gt; &gt;=20
  _______________________________________________<BR>&gt; &gt; DiME =
mailing=20
  list<BR>&gt; &gt; DiME@ietf.org<BR>&gt; &gt; <A=20
  =
href=3D"https://www1.ietf.org/mailman/listinfo/dime">https://www1.ietf.or=
g/mailman/listinfo/dime</A><BR>&gt;<BR>&gt;=20
  --<BR>&gt; julien.bournelle at=20
  int-evry.fr<BR>&gt;<BR>&gt;<BR><BR>--<BR>julien.bournelle at=20
  =
int-evry.fr<BR><BR><BR><BR>______________________________________________=
_<BR>DiME=20
  mailing list<BR>DiME@ietf.org<BR><A=20
  =
href=3D"https://www1.ietf.org/mailman/listinfo/dime">https://www1.ietf.or=
g/mailman/listinfo/dime</A><BR><BR></FONT></P></BLOCKQUOTE></BODY></HTML>=


------_=_NextPart_001_01C6C090.133D8466--


--===============0583083194==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0583083194==--




From dime-bounces@ietf.org Tue Aug 15 13:28:54 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GD2ik-000087-G0; Tue, 15 Aug 2006 13:28:54 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GD2ij-000082-C0
	for dime@ietf.org; Tue, 15 Aug 2006 13:28:53 -0400
Received: from usaga01-in.huawei.com ([12.129.211.51])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD2ic-0001N8-Bh
	for dime@ietf.org; Tue, 15 Aug 2006 13:28:53 -0400
Received: from huawei.com (usaga01-in [172.18.4.6])
	by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0J4100K7IV2PDZ@usaga01-in.huawei.com> for
	dime@ietf.org; Tue, 15 Aug 2006 10:25:37 -0700 (PDT)
Received: from Nakhjiri73701
	(pool-71-112-12-134.sttlwa.dsl-w.verizon.net [71.112.12.134])
	by usaga01-in.huawei.com
	(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
	with ESMTPA id <0J4100FNIV2HWH@usaga01-in.huawei.com> for dime@ietf.org;
	Tue, 15 Aug 2006 10:25:37 -0700 (PDT)
Date: Tue, 15 Aug 2006 10:28:33 -0700
From: Madjid Nakhjiri <mnakhjiri@huawei.com>
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???
In-reply-to: <4C0FAAC489C8B74F96BEAD85EAEB26250272B892@xmb-sjc-215.amer.cisco.com>
To: "'Glen Zorn (gwz)'" <gwz@cisco.com>,
	'Avi Lior' <avi@bridgewatersystems.com>,
	'Julien Bournelle' <julien.bournelle@int-evry.fr>
Message-id: <003e01c6c090$3db91080$2f01a8c0@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869
X-Mailer: Microsoft Office Outlook 11
Thread-index: Aca7j5pLlwjYezfqQhS35Ix/bK+xSgCBYw0QALeF6YMAABfC8AAGj5KAAABcrDA=
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1250085482=="
Errors-To: dime-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1250085482==
Content-type: multipart/alternative;
	boundary="Boundary_(ID_lTJ3Ta0EV1eFipvtv5cKoA)"

This is a multi-part message in MIME format.

--Boundary_(ID_lTJ3Ta0EV1eFipvtv5cKoA)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

Hi Glen,

 

Don't give up so easily, we need you here :-)



As I said earlier, 3588 has a little table defining the 5 App IDs, including
a App ID for Mobile IP. So far we 4004 on MIP4 and I am guessing we will
have 1 or 2 specs for MIP6. Avi suggests defining a new App ID for MIP6, I
agree with him, but I am weighing the consequences, one of which is how can
you have one App ID for Mobile IP, and another for Mobile IPv6. So there are
two choices if we define a new App ID for MIP6:

 

1)     take App ID table out of 3588

2)     revise Mobile IP to Mobile IPv4 in 3588

 

Both of which can count as revisions, don't you think? Seems that the group
is revising 3588 anyway (tell me if I misunderstood), and in that case, this
is a minor change.

 

Madjid

 

  _____  

From: Glen Zorn (gwz) [mailto:gwz@cisco.com] 
Sent: Tuesday, August 15, 2006 10:13 AM
To: Madjid Nakhjiri; Avi Lior; Julien Bournelle
Cc: dime@ietf.org
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???

 

I give up, why do 3588 & 4004 need to be revised?

 

...

both RFC 3588 and 4004 needs to be revised to reflect that, I think the harm
for that is minimal anyway, given the fairly rare deployment of 4004 (I
think).

...


--Boundary_(ID_lTJ3Ta0EV1eFipvtv5cKoA)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<title>RE: [Dime] MIP6 App ID/ revise RFC 3588???</title>
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
p
	{mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.EmailStyle18
	{mso-style-type:personal;
	font-family:Arial;
	color:navy;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:1636982651;
	mso-list-type:hybrid;
	mso-list-template-ids:904272498 67698705 67698713 67698715 67698703 67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
	{mso-level-text:"%1\)";
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</style>

</head>

<body lang=EN-US link=blue vlink=blue>

<div class=Section1>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Hi Glen,<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Don&#8217;t give up so easily, we need you
here </span></font><font size=2 color=navy face=Wingdings><span
style='font-size:10.0pt;font-family:Wingdings;color:navy'>J</span></font><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'><br>
<br>
<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>As I said earlier, 3588 has a little table
defining the 5 App IDs, including a App ID for Mobile IP. So far we 4004 on
MIP4 and I am guessing we will have 1 or 2 specs for MIP6. Avi suggests defining
a new App ID for MIP6, I agree with him, but I am weighing the consequences,
one of which is how can you have one App ID for Mobile IP, and another for
Mobile IPv6. So there are two choices if we define a new App ID for MIP6:<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal style='margin-left:.5in;text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'><span style='mso-list:Ignore'>1)<font size=1 face="Times New Roman"><span
style='font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp; </span></font></span></span></font><![endif]><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'>take App ID table out of 3588<o:p></o:p></span></font></p>

<p class=MsoNormal style='margin-left:.5in;text-indent:-.25in;mso-list:l0 level1 lfo1'><![if !supportLists]><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'><span style='mso-list:Ignore'>2)<font size=1 face="Times New Roman"><span
style='font:7.0pt "Times New Roman"'>&nbsp;&nbsp;&nbsp;&nbsp; </span></font></span></span></font><![endif]><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'>revise Mobile IP to Mobile IPv4 in 3588<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Both of which can count as revisions, don&#8217;t
you think? Seems that the group is revising 3588 anyway (tell me if I
misunderstood), and in that case, this is a minor change.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Madjid<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div class=MsoNormal align=center style='text-align:center'><font size=3
face="Times New Roman"><span style='font-size:12.0pt'>

<hr size=3 width="100%" align=center tabindex=-1>

</span></font></div>

<p class=MsoNormal><b><font size=2 face=Tahoma><span style='font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=2
face=Tahoma><span style='font-size:10.0pt;font-family:Tahoma'> Glen Zorn (gwz)
[mailto:gwz@cisco.com] <br>
<b><span style='font-weight:bold'>Sent:</span></b> Tuesday, August 15, 2006
10:13 AM<br>
<b><span style='font-weight:bold'>To:</span></b> Madjid Nakhjiri; Avi Lior;
Julien Bournelle<br>
<b><span style='font-weight:bold'>Cc:</span></b> dime@ietf.org<br>
<b><span style='font-weight:bold'>Subject:</span></b> RE: [Dime] MIP6 App ID/
revise RFC 3588???</span></font><o:p></o:p></p>

</div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'>I give up, why do 3588 &amp; 4004 need to
be revised?</span></font><o:p></o:p></p>

<div>

<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'>&nbsp;</span></font><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'>...</span></font><o:p></o:p></p>

</div>

<div>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>both RFC 3588 and 4004 needs to be revised
to reflect that, I think the harm for that is minimal anyway, given the fairly
rare deployment of 4004 (I think).<o:p></o:p></span></font></p>

</div>

<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'>...</span></font><o:p></o:p></p>

</div>

</body>

</html>

--Boundary_(ID_lTJ3Ta0EV1eFipvtv5cKoA)--


--===============1250085482==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============1250085482==--




From dime-bounces@ietf.org Tue Aug 15 13:32:48 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GD2mW-0001NS-A9; Tue, 15 Aug 2006 13:32:48 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GD2mV-0001NM-NG
	for dime@ietf.org; Tue, 15 Aug 2006 13:32:47 -0400
Received: from mgw-ext14.nokia.com ([131.228.20.173])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD2mU-0001eR-0K
	for dime@ietf.org; Tue, 15 Aug 2006 13:32:47 -0400
Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145])
	by mgw-ext14.nokia.com (Switch-3.1.10/Switch-3.1.7) with ESMTP id
	k7FHWOwJ001169; Tue, 15 Aug 2006 20:32:27 +0300
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by
	esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 15 Aug 2006 20:32:08 +0300
Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by
	esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 15 Aug 2006 20:32:07 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???
Date: Tue, 15 Aug 2006 20:32:07 +0300
Message-ID: <BAA65A575825454CBB0103267553FCCC8920B3@esebe199.NOE.Nokia.com>
In-Reply-To: <003e01c6c090$3db91080$2f01a8c0@china.huawei.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Dime] MIP6 App ID/ revise RFC 3588???
Thread-Index: Aca7j5pLlwjYezfqQhS35Ix/bK+xSgCBYw0QALeF6YMAABfC8AAGj5KAAABcrDAAAFTKUA==
From: <john.loughney@nokia.com>
To: <mnakhjiri@huawei.com>, <gwz@cisco.com>, <avi@bridgewatersystems.com>,
	<julien.bournelle@int-evry.fr>
X-OriginalArrivalTime: 15 Aug 2006 17:32:07.0925 (UTC)
	FILETIME=[BB71AA50:01C6C090]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: d11a451997816a91a305dcb5ab1b85dd
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0827825390=="
Errors-To: dime-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0827825390==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C6C090.BB4EFD93"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6C090.BB4EFD93
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

3588 defines the initial IANA registry, not the complete registry.  A
new Diameter App spec can define a new App ID. =20
=20
John


________________________________

	From: ext Madjid Nakhjiri [mailto:mnakhjiri@huawei.com]=20
	Sent: 15 August, 2006 20:29
	To: 'Glen Zorn (gwz)'; 'Avi Lior'; 'Julien Bournelle'
	Cc: dime@ietf.org
	Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???
=09
=09

	Hi Glen,

	=20

	Don't give up so easily, we need you here :-)
=09
=09

	As I said earlier, 3588 has a little table defining the 5 App
IDs, including a App ID for Mobile IP. So far we 4004 on MIP4 and I am
guessing we will have 1 or 2 specs for MIP6. Avi suggests defining a new
App ID for MIP6, I agree with him, but I am weighing the consequences,
one of which is how can you have one App ID for Mobile IP, and another
for Mobile IPv6. So there are two choices if we define a new App ID for
MIP6:

	=20

	1)     take App ID table out of 3588

	2)     revise Mobile IP to Mobile IPv4 in 3588

	=20

	Both of which can count as revisions, don't you think? Seems
that the group is revising 3588 anyway (tell me if I misunderstood), and
in that case, this is a minor change.

	=20

	Madjid

	=20

=09
________________________________


	From: Glen Zorn (gwz) [mailto:gwz@cisco.com]=20
	Sent: Tuesday, August 15, 2006 10:13 AM
	To: Madjid Nakhjiri; Avi Lior; Julien Bournelle
	Cc: dime@ietf.org
	Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???

	=20

	I give up, why do 3588 & 4004 need to be revised?

	=20

	...

	both RFC 3588 and 4004 needs to be revised to reflect that, I
think the harm for that is minimal anyway, given the fairly rare
deployment of 4004 (I think).

	...


------_=_NextPart_001_01C6C090.BB4EFD93
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20
"urn:schemas-microsoft-com:vml" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word"><HEAD><TITLE>RE: [Dime] MIP6 App =
ID/ revise RFC 3588???</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dus-ascii">
<META content=3D"MSHTML 6.00.2900.2963" name=3DGENERATOR><!--[if !mso]>
<STYLE>v\:* {
	BEHAVIOR: url(#default#VML)
}
o\:* {
	BEHAVIOR: url(#default#VML)
}
w\:* {
	BEHAVIOR: url(#default#VML)
}
.shape {
	BEHAVIOR: url(#default#VML)
}
</STYLE>
<![endif]-->
<STYLE>@font-face {
	font-family: Wingdings;
}
@font-face {
	font-family: SimSun;
}
@font-face {
	font-family: Tahoma;
}
@font-face {
	font-family: SimSun;
}
@page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.25in 1.0in 1.25in; }
P.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
LI.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
DIV.MsoNormal {
	FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"
}
A:link {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
	COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
	COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
	COLOR: blue; TEXT-DECORATION: underline
}
P {
	FONT-SIZE: 12pt; MARGIN-LEFT: 0in; MARGIN-RIGHT: 0in; FONT-FAMILY: =
"Times New Roman"; mso-margin-top-alt: auto; mso-margin-bottom-alt: auto
}
SPAN.EmailStyle18 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal
}
SPAN.EmailStyle19 {
	COLOR: navy; FONT-FAMILY: Arial; mso-style-type: personal-reply
}
DIV.Section1 {
	page: Section1
}
OL {
	MARGIN-BOTTOM: 0in
}
UL {
	MARGIN-BOTTOM: 0in
}
</STYLE>
</HEAD>
<BODY lang=3DEN-US vLink=3Dblue link=3Dblue>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D066243117-15082006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>3588 defines the initial IANA registry, not the =
complete=20
registry.&nbsp; A new Diameter App spec can define a new App ID.&nbsp;=20
</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D066243117-15082006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D066243117-15082006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>John</FONT></SPAN></DIV><BR>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px =
solid; MARGIN-RIGHT: 0px">
  <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
  <HR tabIndex=3D-1>
  <FONT face=3DTahoma size=3D2><B>From:</B> ext Madjid Nakhjiri=20
  [mailto:mnakhjiri@huawei.com] <BR><B>Sent:</B> 15 August, 2006=20
  20:29<BR><B>To:</B> 'Glen Zorn (gwz)'; 'Avi Lior'; 'Julien=20
  Bournelle'<BR><B>Cc:</B> dime@ietf.org<BR><B>Subject:</B> RE: [Dime] =
MIP6 App=20
  ID/ revise RFC 3588???<BR></FONT><BR></DIV>
  <DIV></DIV>
  <DIV class=3DSection1>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Hi=20
  Glen,<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Don&#8217;t =
give up so=20
  easily, we need you here </SPAN></FONT><FONT face=3DWingdings =
color=3Dnavy=20
  size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Wingdings">J</SPAN></FONT><FONT=20
  face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><BR><BR><o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">As I said =
earlier,=20
  3588 has a little table defining the 5 App IDs, including a App ID for =
Mobile=20
  IP. So far we 4004 on MIP4 and I am guessing we will have 1 or 2 specs =
for=20
  MIP6. Avi suggests defining a new App ID for MIP6, I agree with him, =
but I am=20
  weighing the consequences, one of which is how can you have one App ID =
for=20
  Mobile IP, and another for Mobile IPv6. So there are two choices if we =
define=20
  a new App ID for MIP6:<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal=20
  style=3D"MARGIN-LEFT: 0.5in; TEXT-INDENT: -0.25in; mso-list: l0 level1 =
lfo1"><![if !supportLists]><FONT=20
  face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><SPAN=20
  style=3D"mso-list: Ignore">1)<FONT face=3D"Times New Roman" =
size=3D1><SPAN=20
  style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN></FONT></SPAN></SPAN></FONT><![endif]><FONT face=3DArial =
color=3Dnavy=20
  size=3D2><SPAN style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">take App=20
  ID table out of 3588<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal=20
  style=3D"MARGIN-LEFT: 0.5in; TEXT-INDENT: -0.25in; mso-list: l0 level1 =
lfo1"><![if !supportLists]><FONT=20
  face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><SPAN=20
  style=3D"mso-list: Ignore">2)<FONT face=3D"Times New Roman" =
size=3D1><SPAN=20
  style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;=20
  </SPAN></FONT></SPAN></SPAN></FONT><![endif]><FONT face=3DArial =
color=3Dnavy=20
  size=3D2><SPAN style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">revise=20
  Mobile IP to Mobile IPv4 in 3588<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Both of =
which can=20
  count as revisions, don&#8217;t you think? Seems that the group is =
revising 3588=20
  anyway (tell me if I misunderstood), and in that case, this is a minor =

  change.<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">Madjid<o:p></o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <DIV>
  <DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" =
align=3Dcenter><FONT=20
  face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: 12pt">
  <HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D3>
  </SPAN></FONT></DIV>
  <P class=3DMsoNormal><B><FONT face=3DTahoma size=3D2><SPAN=20
  style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">From:</SPAN></FONT></B><FONT=20
  face=3DTahoma size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma"> Glen=20
  Zorn (gwz) [mailto:gwz@cisco.com] <BR><B><SPAN=20
  style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> Tuesday, August 15, 2006 =
10:13=20
  AM<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B> Madjid =
Nakhjiri; Avi=20
  Lior; Julien Bournelle<BR><B><SPAN style=3D"FONT-WEIGHT: =
bold">Cc:</SPAN></B>=20
  dime@ietf.org<BR><B><SPAN style=3D"FONT-WEIGHT: =
bold">Subject:</SPAN></B> RE:=20
  [Dime] MIP6 App ID/ revise RFC =
3588???</SPAN></FONT><o:p></o:p></P></DIV>
  <P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
  style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">I give up, =
why do=20
  3588 &amp; 4004 need to be revised?</SPAN></FONT><o:p></o:p></P>
  <DIV>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">&nbsp;</SPAN></FONT><o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">...</SPAN></FONT><o:p></o:p></P></DIV>
  <DIV>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">both RFC =
3588 and=20
  4004 needs to be revised to reflect that, I think the harm for that is =
minimal=20
  anyway, given the fairly rare deployment of 4004 (I=20
  think).<o:p></o:p></SPAN></FONT></P></DIV>
  <P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
  style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">...</SPAN></FONT><o:p></o:p></P></DIV></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C6C090.BB4EFD93--


--===============0827825390==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0827825390==--




From dime-bounces@ietf.org Tue Aug 15 13:34:49 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GD2oT-0001jx-1g; Tue, 15 Aug 2006 13:34:49 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GD2oR-0001iE-5o
	for dime@ietf.org; Tue, 15 Aug 2006 13:34:47 -0400
Received: from usaga01-in.huawei.com ([12.129.211.51])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD2oP-0001pl-OM
	for dime@ietf.org; Tue, 15 Aug 2006 13:34:47 -0400
Received: from huawei.com (usaga01-in [172.18.4.6])
	by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0J4100K8ZVCODZ@usaga01-in.huawei.com> for
	dime@ietf.org; Tue, 15 Aug 2006 10:31:37 -0700 (PDT)
Received: from Nakhjiri73701
	(pool-71-112-12-134.sttlwa.dsl-w.verizon.net [71.112.12.134])
	by usaga01-in.huawei.com
	(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
	with ESMTPA id <0J41001BYVCFHW@usaga01-in.huawei.com> for dime@ietf.org;
	Tue, 15 Aug 2006 10:31:36 -0700 (PDT)
Date: Tue, 15 Aug 2006 10:34:33 -0700
From: Madjid Nakhjiri <mnakhjiri@huawei.com>
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???
In-reply-to: <4C0FAAC489C8B74F96BEAD85EAEB26250272B8A9@xmb-sjc-215.amer.cisco.com>
To: "'Glen Zorn (gwz)'" <gwz@cisco.com>,
	'Avi Lior' <avi@bridgewatersystems.com>,
	'Julien Bournelle' <julien.bournelle@int-evry.fr>
Message-id: <004901c6c091$13c24ed0$2f01a8c0@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869
X-Mailer: Microsoft Office Outlook 11
Thread-index: Aca7j5pLlwjYezfqQhS35Ix/bK+xSgCBYw0QALeF6YMAABfC8AAAO289AAQhW/AAApAF8AAAUD6Q
X-Spam-Score: 0.1 (/)
X-Scan-Signature: afddcc4f0dbd876d4009dc71857c6cc6
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1373524801=="
Errors-To: dime-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1373524801==
Content-type: multipart/alternative;
	boundary="Boundary_(ID_42Z0yGGj3qtzsLzO04XWdQ)"

This is a multi-part message in MIME format.

--Boundary_(ID_42Z0yGGj3qtzsLzO04XWdQ)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

Obvious to us, obviously? 

 

Ok, seems like everybody agrees on giving MIP6 a new App ID, so I am happy.
If newcomers don't get the App ID list in 3588, that is their problem, I
love working on AAA, there is so much job security.

 

  _____  

From: Glen Zorn (gwz) [mailto:gwz@cisco.com] 
Sent: Tuesday, August 15, 2006 10:27 AM
To: Madjid Nakhjiri; Avi Lior; Julien Bournelle
Cc: dime@ietf.org
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???

 

Because RFC 3588 defines a single Application ID for Mobile IP and 3588 is
being revised anyway.

If this was a brand new application, it would not matter, but you already
have one App ID for Mobile IP, that could only be used for MIP4, if you now
define a different App ID for Mip6. 

 

OK, so what?  The app ID defined in 3588 is pretty obviously for MIP v4, the
one defined in 4004 is _specifically_ for MIP v4, & MIP v6 _is_ a brand new
application....

 

  _____  

From: Avi Lior [mailto:avi@bridgewatersystems.com] 
Sent: Tuesday, August 15, 2006 7:25 AM
To: Madjid Nakhjiri; Julien Bournelle
Cc: dime@ietf.org
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???

 

 

I don't think RFC3588 needs to be touched when adding an new Application ID.
Neither should

Why do you think you need to touch 3588 or 4004?

-----Original Message-----
From: Madjid Nakhjiri [mailto:mnakhjiri@huawei.com]
Sent: Tue 8/15/2006 10:07 AM
To: Avi Lior; 'Julien Bournelle'
Cc: dime@ietf.org; 'Madjid Nakhjiri'
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???

Hi Avi,



Not sure what "correct" meansJ I am planning on looking a bit closer at 3588
to see exactly how "application" and "App ID" is used.

As I said I _prefer_ adding a new Application ID for Mobile IPv6, but then
both RFC 3588 and 4004 needs to be revised to reflect that, I think the harm
for that is minimal anyway, given the fairly rare deployment of 4004 (I
think).



Madjid.



________________________________

From: Avi Lior [mailto:avi@bridgewatersystems.com]
Sent: Tuesday, August 15, 2006 7:01 AM
To: Madjid Nakhjiri; Julien Bournelle
Cc: dime@ietf.org
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???





How about the correct (IMO) option and that is assign this new application
its own Application ID.  THis afterall is what an Application ID is supposed
to do.



-----Original Message-----
From: Madjid Nakhjiri [mailto:mnakhjiri@huawei.com]
Sent: Fri 8/11/2006 6:49 PM
To: 'Julien Bournelle'
Cc: dime@ietf.org
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???

Hi Julien,

Thanks for pointing me to the archives.
I have one general issue that maybe is related to me not quite understanding
EAP-IKEv2 and that is EAP is run between a peer and an EAP server (in this
case the backend AAA server). EAP-IKEv2 was designed so that a mature
authentication/key management method could be used within EAP framework.
Running EAP-IKEv2 results in authentication of peer to backend AAA, not to
HA and possibly a key between the peer and AAA server. How does this help
the need for IPsec between MN and HA?

Now as far as the discussions on the archives, RFC 4072 only talks about
carrying EAP over Diameter without talking about what EAP is being used for
(your question: mobility versus access service). I think distinguishing
mobility versus access is a AAA signaling issue not an EAP signaling issue.
In RADIUS and MIP4 it is simpler (look at draft-nakhjiri-radius-mip4-02)
because there are attributes related to MIP4 authentication (such as
MIP-MN-AAA-Authenticator, etc) within the Access Request that tells the
server this is about RADIUS. Diameter on the other hand has the notion of
Application ID and should not rely on explicit hint on this. When we got to
the point of trying to translate Diameter messaging to RADIUS, we had to
resort to port types, because Diameter had different messages (depending on
whether HA or FA were involved) while all RADIUS had was Access
Request/Accepts not recognizing between HA and FA.
Here your case is different. Diameter already has an Application ID for
Mobile IP. That is how you distinguish between access and mobility service,
not through service type. Now there are two choices as I said before:

A) revise 3588 to have one App ID for MIPv4 and one for MIPv6 (separate MIP6
split versus integrated through service types). This of course mean revising
4004 to indicate specifically what MIPv4 App ID is.

B) Use the same App ID of 3588 for both MIP4 and MIP6, but then you have to
define 4 service types
1) MIP4 split
2) MIP4 integrated
3) MIP6 split
4) MIP6 integrated.

I prefer A (I can live with B, if you tie a rope to my neck, just kidding).
I think A is cleaner. I think split-integrated versus MIP4-mip6 are two
different degrees of freedom. Just because MIP4 WG did not make the split
integrated distinction, does not mean the business case cannot exist.
Plus that Avi stated that Service type seems to be mandatory.

Madjid

-----Original Message-----
From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr]
Sent: Wednesday, August 09, 2006 1:39 AM
To: Madjid Nakhjiri
Cc: 'Julien Bournelle'; 'Hannes Tschofenig'; dime@ietf.org
Subject: Re: [Dime] MIP6 App ID/ revise RFC 3588???

Hi madjid,

On Tue, Aug 08, 2006 at 04:51:08PM -0700, Madjid Nakhjiri wrote:
> Hi Julien,
>
> I just looked at the RFC 4005 definition of Service_Type.
> The services listed there are quite mixed. I am not quite sure what
> applications besides NASREQ are supposed to support Service_Type? Or is it
> that Mobile IP application assumes NASREQ must be supported?

 Let me try to sum up the issue:

 In the split scenario, the HA acts as a IKEv2 responder and uses EAP
 (oIKEv2) to authenticate the user (of the MN). The HA then relies on a
 EAP/AAA server and thus could use Diameter EAP. THe problem that we
 have here is that we are not performing AAA for "basic" network access
 but for the IPv6 Mobility service. Thus we have the problem of, how the
 AAA server knows that.

 You can take a look at the thread:

 http://www1.ietf.org/mail-archive/web/dime/current/msg00262.html

 for previous discussions on this topic which is still unsolved.

 At this point, as noted in:

 http://www1.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-00.txt

 the 2 options that we have are:

 - define a new Service-Type for "Mobile IPv6 - Split" and puts it in
   DER message (Diameter EAP Request)
 - define a new Application-ID and re-use Diameter EAP messages.

 Hope it helps,

 regards,

 Julien

>
> If one is to go about without modifying RFC 3588 that uses just one App ID
> for Mobile IP, then I guess there is just one choice of having
>
> two Service_types for Mobile IPv6
> and
> one Service_Type for Mobile IPv4,
>
> (3 total for Mobile IP), but then don't you have to modify RFC 4004 to add
> the service_type to Mobile IPv4?
>
> Madjid
>
> -----Original Message-----
> From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr]
> Sent: Monday, August 07, 2006 6:42 AM
> To: Madjid Nakhjiri
> Cc: 'Hannes Tschofenig'; dime@ietf.org
> Subject: Re: [Dime] MIP6 App ID/ was: IETF#66 Meeting Minutes
>
> HI madjid,
>
> On Mon, Aug 07, 2006 at 06:34:55AM -0700, Madjid Nakhjiri wrote:
> > No worries, I was being humorous. I wanted to see what was said during
the
> > meeting regarding the Mobile IP6 drafts. I tried to see the archive
> > discussions, but did not see anything in June or July either.
> > I am seeing all this discussion on the use of App IDs on the ML, so I
> wanted
> > to see if MIP6 is getting its own App ID, or it is using the App ID
> assigned
> > to Mobiloe IP in 3588?
>
>  basically the question is: do we need a specific App ID or do a
>  Service-Type AVP (indicating that it's a HA for the split scenario) is
>  sufficient ?
>
>
>  regards,
>
>  Julien
>
> >
> > R,
> >
> > Madjid
> >
> > -----Original Message-----
> > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
> > Sent: Saturday, August 05, 2006 5:22 AM
> > To: Madjid Nakhjiri
> > Cc: dime@ietf.org
> > Subject: Re: [Dime] IETF#66 Meeting Minutes
> >
> > I agree that the meeting minutes are somewhat brief this time.
> > We will do better with the next IETF meeting...
> >
> > Ciao
> > Hannes
> >
> > Madjid Nakhjiri wrote:
> > > Was this minutes or 10-minutes:-)
> > >
> > > -----Original Message-----
> > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
> > > Sent: Wednesday, July 19, 2006 7:56 AM
> > > To: dime@ietf.org
> > > Subject: [Dime] IETF#66 Meeting Minutes
> > >
> > > Hi all,
> > >
> > > please take a look at the meeting minutes:
> > > http://www3.ietf.org/proceedings/06jul/minutes/dime.txt
> > >
> > > Ciao
> > > Hannes
> > >
> > > _______________________________________________
> > > DiME mailing list
> > > DiME@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/dime
> > >
> > >
> > >
> >
> >
> >
> >
> > _______________________________________________
> > DiME mailing list
> > DiME@ietf.org
> > https://www1.ietf.org/mailman/listinfo/dime
>
> --
> julien.bournelle at int-evry.fr
>
>

--
julien.bournelle at int-evry.fr



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


--Boundary_(ID_42Z0yGGj3qtzsLzO04XWdQ)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<title>RE: [Dime] MIP6 App ID/ revise RFC 3588???</title>
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
p
	{mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.EmailStyle18
	{mso-style-type:personal;
	font-family:Arial;
	color:navy;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=EN-US link=blue vlink=blue>

<div class=Section1>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Obvious to us, obviously? <o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Ok, seems like everybody agrees on giving
MIP6 a new App ID, so I am happy. If newcomers don&#8217;t get the App ID list
in 3588, that is their problem, I love working on AAA, there is so much job
security&#8230;<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div class=MsoNormal align=center style='text-align:center'><font size=3
face="Times New Roman"><span style='font-size:12.0pt'>

<hr size=3 width="100%" align=center tabindex=-1>

</span></font></div>

<p class=MsoNormal><b><font size=2 face=Tahoma><span style='font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=2
face=Tahoma><span style='font-size:10.0pt;font-family:Tahoma'> Glen Zorn (gwz)
[mailto:gwz@cisco.com] <br>
<b><span style='font-weight:bold'>Sent:</span></b> Tuesday, August 15, 2006
10:27 AM<br>
<b><span style='font-weight:bold'>To:</span></b> Madjid Nakhjiri; Avi Lior;
Julien Bournelle<br>
<b><span style='font-weight:bold'>Cc:</span></b> dime@ietf.org<br>
<b><span style='font-weight:bold'>Subject:</span></b> RE: [Dime] MIP6 App ID/
revise RFC 3588???</span></font><o:p></o:p></p>

</div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Because RFC 3588 defines a single
Application ID for Mobile IP and 3588 is being revised anyway.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>If this was a brand new application, it
would not matter,</span></font><font size=2 color=blue face=Arial><span
style='font-size:10.0pt;font-family:Arial;color:blue'>&nbsp;</span></font><font
size=2 color=navy face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:navy'>but you already have one App ID for Mobile IP, that could only be
used for MIP4, if you now define a different App ID for Mip6.</span></font><font
size=2 color=blue face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:blue'>&nbsp;</span></font><o:p></o:p></p>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'>OK, so what?&nbsp; The app ID defined in
3588 is pretty obviously for MIP v4, the one defined in 4004 is _specifically_
for MIP v4, &amp; MIP v6 _is_ a brand new application....</span></font><o:p></o:p></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div class=MsoNormal align=center style='text-align:center'><font size=3
face="Times New Roman"><span style='font-size:12.0pt'>

<hr size=3 width="100%" align=center tabIndex=-1>

</span></font></div>

<p class=MsoNormal><b><font size=2 face=Tahoma><span style='font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=2
face=Tahoma><span style='font-size:10.0pt;font-family:Tahoma'> Avi Lior
[mailto:avi@bridgewatersystems.com] <br>
<b><span style='font-weight:bold'>Sent:</span></b> Tuesday, August 15, 2006
7:25 AM<br>
<b><span style='font-weight:bold'>To:</span></b> Madjid Nakhjiri; Julien
Bournelle<br>
<b><span style='font-weight:bold'>Cc:</span></b> dime@ietf.org<br>
<b><span style='font-weight:bold'>Subject:</span></b> RE: [Dime] MIP6 App ID/
revise RFC 3588???</span></font><o:p></o:p></p>

</div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p style='margin-bottom:12.0pt'><font size=2 face="Times New Roman"><span
style='font-size:10.0pt'>I don't think RFC3588 needs to be touched when adding
an new Application ID. Neither should<br>
<br>
Why do you think you need to touch 3588 or 4004?<br>
<br>
-----Original Message-----<br>
From: Madjid Nakhjiri [<a href="mailto:mnakhjiri@huawei.com">mailto:mnakhjiri@huawei.com</a>]<br>
Sent: Tue 8/15/2006 10:07 AM<br>
To: Avi Lior; 'Julien Bournelle'<br>
Cc: dime@ietf.org; 'Madjid Nakhjiri'<br>
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???<br>
<br>
Hi Avi,<br>
<br>
<br>
<br>
Not sure what &quot;correct&quot; meansJ I am planning on looking a bit closer
at 3588 to see exactly how &quot;application&quot; and &quot;App ID&quot; is
used.<br>
<br>
As I said I _prefer_ adding a new Application ID for Mobile IPv6, but then both
RFC 3588 and 4004 needs to be revised to reflect that, I think the harm for
that is minimal anyway, given the fairly rare deployment of 4004 (I think).<br>
<br>
<br>
<br>
Madjid.<br>
<br>
<br>
<br>
________________________________<br>
<br>
From: Avi Lior [<a href="mailto:avi@bridgewatersystems.com">mailto:avi@bridgewatersystems.com</a>]<br>
Sent: Tuesday, August 15, 2006 7:01 AM<br>
To: Madjid Nakhjiri; Julien Bournelle<br>
Cc: dime@ietf.org<br>
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???<br>
<br>
<br>
<br>
<br>
<br>
How about the correct (IMO) option and that is assign this new application its
own Application ID.&nbsp; THis afterall is what an Application ID is supposed
to do.<br>
<br>
<br>
<br>
-----Original Message-----<br>
From: Madjid Nakhjiri [<a href="mailto:mnakhjiri@huawei.com">mailto:mnakhjiri@huawei.com</a>]<br>
Sent: Fri 8/11/2006 6:49 PM<br>
To: 'Julien Bournelle'<br>
Cc: dime@ietf.org<br>
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???<br>
<br>
Hi Julien,<br>
<br>
Thanks for pointing me to the archives.<br>
I have one general issue that maybe is related to me not quite understanding<br>
EAP-IKEv2 and that is EAP is run between a peer and an EAP server (in this<br>
case the backend AAA server). EAP-IKEv2 was designed so that a mature<br>
authentication/key management method could be used within EAP framework.<br>
Running EAP-IKEv2 results in authentication of peer to backend AAA, not to<br>
HA and possibly a key between the peer and AAA server. How does this help<br>
the need for IPsec between MN and HA?<br>
<br>
Now as far as the discussions on the archives, RFC 4072 only talks about<br>
carrying EAP over Diameter without talking about what EAP is being used for<br>
(your question: mobility versus access service). I think distinguishing<br>
mobility versus access is a AAA signaling issue not an EAP signaling issue.<br>
In RADIUS and MIP4 it is simpler (look at draft-nakhjiri-radius-mip4-02)<br>
because there are attributes related to MIP4 authentication (such as<br>
MIP-MN-AAA-Authenticator, etc) within the Access Request that tells the<br>
server this is about RADIUS. Diameter on the other hand has the notion of<br>
Application ID and should not rely on explicit hint on this. When we got to<br>
the point of trying to translate Diameter messaging to RADIUS, we had to<br>
resort to port types, because Diameter had different messages (depending on<br>
whether HA or FA were involved) while all RADIUS had was Access<br>
Request/Accepts not recognizing between HA and FA.<br>
Here your case is different. Diameter already has an Application ID for<br>
Mobile IP. That is how you distinguish between access and mobility service,<br>
not through service type. Now there are two choices as I said before:<br>
<br>
A) revise 3588 to have one App ID for MIPv4 and one for MIPv6 (separate MIP6<br>
split versus integrated through service types). This of course mean revising<br>
4004 to indicate specifically what MIPv4 App ID is.<br>
<br>
B) Use the same App ID of 3588 for both MIP4 and MIP6, but then you have to<br>
define 4 service types<br>
1) MIP4 split<br>
2) MIP4 integrated<br>
3) MIP6 split<br>
4) MIP6 integrated.<br>
<br>
I prefer A (I can live with B, if you tie a rope to my neck, just kidding).<br>
I think A is cleaner. I think split-integrated versus MIP4-mip6 are two<br>
different degrees of freedom. Just because MIP4 WG did not make the split<br>
integrated distinction, does not mean the business case cannot exist.<br>
Plus that Avi stated that Service type seems to be mandatory.<br>
<br>
Madjid<br>
<br>
-----Original Message-----<br>
From: Julien Bournelle [<a href="mailto:julien.bournelle@int-evry.fr">mailto:julien.bournelle@int-evry.fr</a>]<br>
Sent: Wednesday, August 09, 2006 1:39 AM<br>
To: Madjid Nakhjiri<br>
Cc: 'Julien Bournelle'; 'Hannes Tschofenig'; dime@ietf.org<br>
Subject: Re: [Dime] MIP6 App ID/ revise RFC 3588???<br>
<br>
Hi madjid,<br>
<br>
On Tue, Aug 08, 2006 at 04:51:08PM -0700, Madjid Nakhjiri wrote:<br>
&gt; Hi Julien,<br>
&gt;<br>
&gt; I just looked at the RFC 4005 definition of Service_Type.<br>
&gt; The services listed there are quite mixed. I am not quite sure what<br>
&gt; applications besides NASREQ are supposed to support Service_Type? Or is it<br>
&gt; that Mobile IP application assumes NASREQ must be supported?<br>
<br>
&nbsp;Let me try to sum up the issue:<br>
<br>
&nbsp;In the split scenario, the HA acts as a IKEv2 responder and uses EAP<br>
&nbsp;(oIKEv2) to authenticate the user (of the MN). The HA then relies on a<br>
&nbsp;EAP/AAA server and thus could use Diameter EAP. THe problem that we<br>
&nbsp;have here is that we are not performing AAA for &quot;basic&quot; network
access<br>
&nbsp;but for the IPv6 Mobility service. Thus we have the problem of, how the<br>
&nbsp;AAA server knows that.<br>
<br>
&nbsp;You can take a look at the thread:<br>
<br>
&nbsp;<a href="http://www1.ietf.org/mail-archive/web/dime/current/msg00262.html">http://www1.ietf.org/mail-archive/web/dime/current/msg00262.html</a><br>
<br>
&nbsp;for previous discussions on this topic which is still unsolved.<br>
<br>
&nbsp;At this point, as noted in:<br>
<br>
&nbsp;<a
href="http://www1.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-00.txt">http://www1.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-00.txt</a><br>
<br>
&nbsp;the 2 options that we have are:<br>
<br>
&nbsp;- define a new Service-Type for &quot;Mobile IPv6 - Split&quot; and puts
it in<br>
&nbsp;&nbsp; DER message (Diameter EAP Request)<br>
&nbsp;- define a new Application-ID and re-use Diameter EAP messages.<br>
<br>
&nbsp;Hope it helps,<br>
<br>
&nbsp;regards,<br>
<br>
&nbsp;Julien<br>
<br>
&gt;<br>
&gt; If one is to go about without modifying RFC 3588 that uses just one App ID<br>
&gt; for Mobile IP, then I guess there is just one choice of having<br>
&gt;<br>
&gt; two Service_types for Mobile IPv6<br>
&gt; and<br>
&gt; one Service_Type for Mobile IPv4,<br>
&gt;<br>
&gt; (3 total for Mobile IP), but then don't you have to modify RFC 4004 to add<br>
&gt; the service_type to Mobile IPv4?<br>
&gt;<br>
&gt; Madjid<br>
&gt;<br>
&gt; -----Original Message-----<br>
&gt; From: Julien Bournelle [<a href="mailto:julien.bournelle@int-evry.fr">mailto:julien.bournelle@int-evry.fr</a>]<br>
&gt; Sent: Monday, August 07, 2006 6:42 AM<br>
&gt; To: Madjid Nakhjiri<br>
&gt; Cc: 'Hannes Tschofenig'; dime@ietf.org<br>
&gt; Subject: Re: [Dime] MIP6 App ID/ was: IETF#66 Meeting Minutes<br>
&gt;<br>
&gt; HI madjid,<br>
&gt;<br>
&gt; On Mon, Aug 07, 2006 at 06:34:55AM -0700, Madjid Nakhjiri wrote:<br>
&gt; &gt; No worries, I was being humorous. I wanted to see what was said during<br>
the<br>
&gt; &gt; meeting regarding the Mobile IP6 drafts. I tried to see the archive<br>
&gt; &gt; discussions, but did not see anything in June or July either.<br>
&gt; &gt; I am seeing all this discussion on the use of App IDs on the ML, so I<br>
&gt; wanted<br>
&gt; &gt; to see if MIP6 is getting its own App ID, or it is using the App ID<br>
&gt; assigned<br>
&gt; &gt; to Mobiloe IP in 3588?<br>
&gt;<br>
&gt;&nbsp; basically the question is: do we need a specific App ID or do a<br>
&gt;&nbsp; Service-Type AVP (indicating that it's a HA for the split scenario)
is<br>
&gt;&nbsp; sufficient ?<br>
&gt;<br>
&gt;<br>
&gt;&nbsp; regards,<br>
&gt;<br>
&gt;&nbsp; Julien<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt; R,<br>
&gt; &gt;<br>
&gt; &gt; Madjid<br>
&gt; &gt;<br>
&gt; &gt; -----Original Message-----<br>
&gt; &gt; From: Hannes Tschofenig [<a href="mailto:Hannes.Tschofenig@gmx.net">mailto:Hannes.Tschofenig@gmx.net</a>]<br>
&gt; &gt; Sent: Saturday, August 05, 2006 5:22 AM<br>
&gt; &gt; To: Madjid Nakhjiri<br>
&gt; &gt; Cc: dime@ietf.org<br>
&gt; &gt; Subject: Re: [Dime] IETF#66 Meeting Minutes<br>
&gt; &gt;<br>
&gt; &gt; I agree that the meeting minutes are somewhat brief this time.<br>
&gt; &gt; We will do better with the next IETF meeting...<br>
&gt; &gt;<br>
&gt; &gt; Ciao<br>
&gt; &gt; Hannes<br>
&gt; &gt;<br>
&gt; &gt; Madjid Nakhjiri wrote:<br>
&gt; &gt; &gt; Was this minutes or 10-minutes:-)<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; -----Original Message-----<br>
&gt; &gt; &gt; From: Hannes Tschofenig [<a
href="mailto:Hannes.Tschofenig@gmx.net">mailto:Hannes.Tschofenig@gmx.net</a>]<br>
&gt; &gt; &gt; Sent: Wednesday, July 19, 2006 7:56 AM<br>
&gt; &gt; &gt; To: dime@ietf.org<br>
&gt; &gt; &gt; Subject: [Dime] IETF#66 Meeting Minutes<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Hi all,<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; please take a look at the meeting minutes:<br>
&gt; &gt; &gt; <a href="http://www3.ietf.org/proceedings/06jul/minutes/dime.txt">http://www3.ietf.org/proceedings/06jul/minutes/dime.txt</a><br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Ciao<br>
&gt; &gt; &gt; Hannes<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; _______________________________________________<br>
&gt; &gt; &gt; DiME mailing list<br>
&gt; &gt; &gt; DiME@ietf.org<br>
&gt; &gt; &gt; <a href="https://www1.ietf.org/mailman/listinfo/dime">https://www1.ietf.org/mailman/listinfo/dime</a><br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; _______________________________________________<br>
&gt; &gt; DiME mailing list<br>
&gt; &gt; DiME@ietf.org<br>
&gt; &gt; <a href="https://www1.ietf.org/mailman/listinfo/dime">https://www1.ietf.org/mailman/listinfo/dime</a><br>
&gt;<br>
&gt; --<br>
&gt; julien.bournelle at int-evry.fr<br>
&gt;<br>
&gt;<br>
<br>
--<br>
julien.bournelle at int-evry.fr<br>
<br>
<br>
<br>
_______________________________________________<br>
DiME mailing list<br>
DiME@ietf.org<br>
<a href="https://www1.ietf.org/mailman/listinfo/dime">https://www1.ietf.org/mailman/listinfo/dime</a></span></font><o:p></o:p></p>

</div>

</body>

</html>

--Boundary_(ID_42Z0yGGj3qtzsLzO04XWdQ)--


--===============1373524801==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============1373524801==--




From dime-bounces@ietf.org Tue Aug 15 13:36:47 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GD2qN-0002CT-8I; Tue, 15 Aug 2006 13:36:47 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GD2qL-0002A4-9N
	for dime@ietf.org; Tue, 15 Aug 2006 13:36:45 -0400
Received: from mail1.azairenet.com ([66.92.223.4] helo=bart.corp.azairenet.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD2qG-0001z4-VC
	for dime@ietf.org; Tue, 15 Aug 2006 13:36:45 -0400
Received: from [10.1.201.3] ([10.1.201.3]) by bart.corp.azairenet.com with
	Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 Aug 2006 10:36:39 -0700
Message-ID: <44E20623.8070009@azairenet.com>
Date: Tue, 15 Aug 2006 10:36:35 -0700
From: Vijay Devarapalli <vijay.devarapalli@azairenet.com>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: Madjid Nakhjiri <mnakhjiri@huawei.com>
Subject: Re: [Dime] MIP6 App ID/ revise RFC 3588???
References: <005f01c6bd98$61ff2e70$2f01a8c0@china.huawei.com>
In-Reply-To: <005f01c6bd98$61ff2e70$2f01a8c0@china.huawei.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 15 Aug 2006 17:36:39.0564 (UTC)
	FILETIME=[5D5A7CC0:01C6C091]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

Madjid Nakhjiri wrote:
> Hi Julien,
> 
> Thanks for pointing me to the archives.
> I have one general issue that maybe is related to me not quite understanding
> EAP-IKEv2 and that is EAP is run between a peer and an EAP server (in this
> case the backend AAA server). EAP-IKEv2 was designed so that a mature
> authentication/key management method could be used within EAP framework.
> Running EAP-IKEv2 results in authentication of peer to backend AAA, not to
> HA and possibly a key between the peer and AAA server. How does this help
> the need for IPsec between MN and HA?

two things here

1. the HA relies on the fact that the MN was authenticated
by the AAA server in the home domain.
2. if the EAP method used generates a key (MSK) between the
MN and the HA, the MSK is used to generated the AUTH payload
in the IKEv2 exchange. basically the MSK becomes the shared
key for IKE authentication.

> A) revise 3588 to have one App ID for MIPv4 and one for MIPv6 (separate MIP6
> split versus integrated through service types). This of course mean revising
> 4004 to indicate specifically what MIPv4 App ID is.

adding an application ID should not require revising RFC
3588. see the Applications ID section at
http://www.iana.org/assignments/aaa-parameters.

Vijay

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



From dime-bounces@ietf.org Tue Aug 15 13:54:43 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GD37g-0000c8-QJ; Tue, 15 Aug 2006 13:54:40 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GD37g-0000ap-E8
	for dime@ietf.org; Tue, 15 Aug 2006 13:54:40 -0400
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD37d-00034G-SP
	for dime@ietf.org; Tue, 15 Aug 2006 13:54:40 -0400
Received: from sj-dkim-7.cisco.com ([171.68.10.88])
	by sj-iport-4.cisco.com with ESMTP; 15 Aug 2006 10:54:38 -0700
X-IronPort-AV: i="4.08,128,1154934000"; 
	d="scan'208,217"; a="1847232045:sNHT52840164"
Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137])
	by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id
	k7FHsbPG003604; Tue, 15 Aug 2006 10:54:37 -0700
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com
	[128.107.191.63])
	by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k7FHsaSl014960;
	Tue, 15 Aug 2006 10:54:36 -0700 (PDT)
Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by
	xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 15 Aug 2006 10:54:35 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???
Date: Tue, 15 Aug 2006 10:54:34 -0700
Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB26250272B8D4@xmb-sjc-215.amer.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Dime] MIP6 App ID/ revise RFC 3588???
Thread-Index: Aca7j5pLlwjYezfqQhS35Ix/bK+xSgCBYw0QALeF6YMAABfC8AAAO289AAQhW/AAAJNTagACZUpA
From: "Glen Zorn \(gwz\)" <gwz@cisco.com>
To: "Avi Lior" <avi@bridgewatersystems.com>,
	"Madjid Nakhjiri" <mnakhjiri@huawei.com>,
	"Julien Bournelle" <julien.bournelle@int-evry.fr>
X-OriginalArrivalTime: 15 Aug 2006 17:54:35.0842 (UTC)
	FILETIME=[DEDD7A20:01C6C093]
DKIM-Signature: a=rsa-sha1; q=dns; l=5199; t=1155664477; x=1156528477;
	c=relaxed/simple; s=sjdkim7002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=gwz@cisco.com;
	z=From:=22Glen=20Zorn=20\(gwz\)=22=20<gwz@cisco.com>
	|Subject:RE=3A=20[Dime]=20MIP6=20App=20ID/=20revise=20RFC=203588???;
	X=v=3Dcisco.com=3B=20h=3DdRVmTkNdOGQXTAedBYfz4c4m5vo=3D;
	b=UNwFfPGWHHoec9vNPSjuTevyyg877BT29BT1NBejnRZtuPss1UHmQTXhn5ZJEJzRMJwTcOYT
	eCVd5Gxa04Bj8hbH/kef6/Y+wV8AE1DD+BdylrtvygFNd3apAmz1LxCS;
Authentication-Results: sj-dkim-7.cisco.com; header.From=gwz@cisco.com;
	dkim=pass (
	59 extraneous bytes; sig from cisco.com verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 6ffdee8af20de249c24731d8414917d3
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0135816186=="
Errors-To: dime-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0135816186==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C6C093.DEAEE2EE"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6C093.DEAEE2EE
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

...
=20
 I think that RFC3588 should not define any application ids.  If it does =
they should be informative.=20
=20
Nonsense.  Various numbers have been defined in RFCs (with the =
assignment of future numbers left to the IANA) for literally years: =
somehow developers have found the right numbers to use & the Internet =
has survived.  I realize that there is a trend to turn RFCs into =
tutorials for uni freshmen and bellheads but this is getting ridiculous. =
 If you need even more clarity, the IANA entry for Diameter Application =
ID 2 identifies it as representing "Mobile IP v4".  =20

So if we are going to change 3588 we should remove any reference to any =
Application IDs.=20

IANA should be the only authoritative (normative) entity for Application =
IDS.=20
=20
Nonsense, again.  The normative reference for a number is the document =
in which that numbers usage is defined; it must be so since the IANA is =
just a registry containing neither syntactic nor semantic information =
regarding the entries.  In fact the IANA entries for the first 4 =
Diameter app IDs reference RFC 3588. =20
=20
...=20



Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by simply =
listening to John Coltrane?
  -- Henry Gabriel=20


------_=_NextPart_001_01C6C093.DEAEE2EE
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>RE: [Dime] MIP6 App ID/ revise RFC 3588???</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1555" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><FONT color=3D#0000ff size=3D2><SPAN=20
class=3D782403317-15082006>...</SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT><SPAN =
class=3D782403317-15082006></SPAN></FONT><FONT=20
size=3D2><SPAN class=3D782403317-15082006><FONT face=3DArial=20
color=3D#0000ff>&nbsp;</FONT></SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT size=3D2><SPAN=20
class=3D782403317-15082006>&nbsp;</SPAN>I think that RFC3588 should not =
define any=20
application ids.&nbsp; If it does they should be informative.<SPAN=20
class=3D782403317-15082006><FONT face=3DArial=20
color=3D#0000ff>&nbsp;</FONT></SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT size=3D2><SPAN=20
class=3D782403317-15082006></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT size=3D2><SPAN =
class=3D782403317-15082006><FONT=20
face=3DArial color=3D#0000ff>Nonsense.&nbsp; Various numbers have been =
defined in=20
RFCs (with&nbsp;the assignment of future numbers left to&nbsp;the IANA)=20
for&nbsp;literally years: </FONT><FONT face=3DArial =
color=3D#0000ff>somehow=20
developers have found the right numbers to use &amp;&nbsp;the Internet =
has=20
survived.&nbsp; I realize that&nbsp;there is a trend to turn RFCs into =
tutorials=20
for uni freshmen and bellheads but this is getting ridiculous.&nbsp; If =
you need=20
even more clarity, the IANA entry for Diameter Application ID 2 =
identifies it as=20
representing "Mobile IP v4".&nbsp;&nbsp;<FONT face=3D"Times New Roman"=20
color=3D#000000>&nbsp;</FONT><BR></FONT></SPAN><BR>So if we are going to =
change=20
3588 we should remove any reference to any Application IDs.<SPAN=20
class=3D782403317-15082006><FONT face=3DArial=20
color=3D#0000ff>&nbsp;</FONT></SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT size=3D2><BR>IANA should be the only =
authoritative=20
(normative) entity for Application IDS.<SPAN =
class=3D782403317-15082006><FONT=20
face=3DArial color=3D#0000ff>&nbsp;</FONT></SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT size=3D2><SPAN=20
class=3D782403317-15082006></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT size=3D2><SPAN =
class=3D782403317-15082006><FONT=20
face=3DArial color=3D#0000ff>Nonsense, again.&nbsp; The normative =
reference for a=20
number is the document in which that numbers usage is defined; it must =
be so=20
since the IANA is just a registry containing neither syntactic nor =
semantic=20
information regarding the entries.&nbsp; In fact the IANA entries for =
the first=20
4 Diameter app IDs&nbsp;reference RFC=20
3588.&nbsp;&nbsp;</FONT></SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN =
class=3D782403317-15082006></SPAN><FONT size=3D2><SPAN=20
class=3D782403317-15082006><FONT face=3DArial=20
color=3D#0000ff>&nbsp;</FONT></SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT size=3D2><SPAN =
class=3D782403317-15082006><FONT=20
face=3DArial color=3D#0000ff>...</FONT>&nbsp;</SPAN><BR></FONT><!-- =
Converted from text/plain format --><BR>
<P><FONT color=3D#0000ff><FONT size=3D2>Hope this =
helps,<BR><BR>~gwz<BR><BR>Why is=20
it that most of the world's problems can't be solved by simply listening =
to John=20
Coltrane?<BR>&nbsp; -- Henry Gabriel</FONT> =
</FONT></P></DIV></BODY></HTML>

------_=_NextPart_001_01C6C093.DEAEE2EE--


--===============0135816186==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0135816186==--




From dime-bounces@ietf.org Tue Aug 15 13:55:59 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GD38x-00016e-9H; Tue, 15 Aug 2006 13:55:59 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GD38w-00016Z-4x
	for dime@ietf.org; Tue, 15 Aug 2006 13:55:58 -0400
Received: from bws14.bridgewatersystems.com ([216.113.7.14]
	helo=exchange.bridgewatersys.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD38u-00036w-TR
	for dime@ietf.org; Tue, 15 Aug 2006 13:55:58 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???
Date: Tue, 15 Aug 2006 13:57:01 -0400
Message-ID: <E7CCE8A83907104ABEE91AC3AE3709A01167E0@exchange.bridgewatersys.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Dime] MIP6 App ID/ revise RFC 3588???
Thread-Index: Aca7j5pLlwjYezfqQhS35Ix/bK+xSgCBYw0QALeF6YMAABfC8AAAO289AAQhW/AAApAF8AAAUD6QAAC0OyI=
References: <004901c6c091$13c24ed0$2f01a8c0@china.huawei.com>
From: "Avi Lior" <avi@bridgewatersystems.com>
To: "Madjid Nakhjiri" <mnakhjiri@huawei.com>,
	"Glen Zorn \(gwz\)" <gwz@cisco.com>,
	"Julien Bournelle" <julien.bournelle@int-evry.fr>
X-Spam-Score: 0.6 (/)
X-Scan-Signature: 9d5866e4c615ceea0db8f42c46495d22
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============2082655860=="
Errors-To: dime-bounces@ietf.org

This is a multi-part message in MIME format.

--===============2082655860==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C6C094.35917EF6"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6C094.35917EF6
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

To summarize:

No need to update 3588 or 4004 just because we add a new application =
with its own application id.

Madjid wrote:

Ok, seems like everybody agrees on giving MIP6 a new App ID, so I am =
happy. If newcomers don't get the App ID list in 3588, that is their =
problem, I love working on AAA, there is so much job security.

I dont think that this is strictly a AAA problem. Nor do I think that =
this is a problem.  IANA is the authoritative place where ids or =
assigned numbers of all sorts are kept.  Hence the name.



-----Original Message-----
From: Madjid Nakhjiri [mailto:mnakhjiri@huawei.com]
Sent: Tue 8/15/2006 1:34 PM
To: 'Glen Zorn (gwz)'; Avi Lior; 'Julien Bournelle'
Cc: dime@ietf.org; 'Madjid Nakhjiri'
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???
=20
Obvious to us, obviously?=20

=20

Ok, seems like everybody agrees on giving MIP6 a new App ID, so I am =
happy. If newcomers don't get the App ID list in 3588, that is their =
problem, I love working on AAA, there is so much job security.

=20

________________________________

From: Glen Zorn (gwz) [mailto:gwz@cisco.com]=20
Sent: Tuesday, August 15, 2006 10:27 AM
To: Madjid Nakhjiri; Avi Lior; Julien Bournelle
Cc: dime@ietf.org
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???

=20

Because RFC 3588 defines a single Application ID for Mobile IP and 3588 =
is being revised anyway.

If this was a brand new application, it would not matter, but you =
already have one App ID for Mobile IP, that could only be used for MIP4, =
if you now define a different App ID for Mip6.=20

=20

OK, so what?  The app ID defined in 3588 is pretty obviously for MIP v4, =
the one defined in 4004 is _specifically_ for MIP v4, & MIP v6 _is_ a =
brand new application....

=20

________________________________

From: Avi Lior [mailto:avi@bridgewatersystems.com]=20
Sent: Tuesday, August 15, 2006 7:25 AM
To: Madjid Nakhjiri; Julien Bournelle
Cc: dime@ietf.org
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???

=20

=20

I don't think RFC3588 needs to be touched when adding an new Application =
ID. Neither should

Why do you think you need to touch 3588 or 4004?

-----Original Message-----
From: Madjid Nakhjiri [mailto:mnakhjiri@huawei.com]
Sent: Tue 8/15/2006 10:07 AM
To: Avi Lior; 'Julien Bournelle'
Cc: dime@ietf.org; 'Madjid Nakhjiri'
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???

Hi Avi,



Not sure what "correct" meansJ I am planning on looking a bit closer at =
3588 to see exactly how "application" and "App ID" is used.

As I said I _prefer_ adding a new Application ID for Mobile IPv6, but =
then both RFC 3588 and 4004 needs to be revised to reflect that, I think =
the harm for that is minimal anyway, given the fairly rare deployment of =
4004 (I think).



Madjid.



________________________________

From: Avi Lior [mailto:avi@bridgewatersystems.com]
Sent: Tuesday, August 15, 2006 7:01 AM
To: Madjid Nakhjiri; Julien Bournelle
Cc: dime@ietf.org
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???





How about the correct (IMO) option and that is assign this new =
application its own Application ID.  THis afterall is what an =
Application ID is supposed to do.



-----Original Message-----
From: Madjid Nakhjiri [mailto:mnakhjiri@huawei.com]
Sent: Fri 8/11/2006 6:49 PM
To: 'Julien Bournelle'
Cc: dime@ietf.org
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???

Hi Julien,

Thanks for pointing me to the archives.
I have one general issue that maybe is related to me not quite =
understanding
EAP-IKEv2 and that is EAP is run between a peer and an EAP server (in =
this
case the backend AAA server). EAP-IKEv2 was designed so that a mature
authentication/key management method could be used within EAP framework.
Running EAP-IKEv2 results in authentication of peer to backend AAA, not =
to
HA and possibly a key between the peer and AAA server. How does this =
help
the need for IPsec between MN and HA?

Now as far as the discussions on the archives, RFC 4072 only talks about
carrying EAP over Diameter without talking about what EAP is being used =
for
(your question: mobility versus access service). I think distinguishing
mobility versus access is a AAA signaling issue not an EAP signaling =
issue.
In RADIUS and MIP4 it is simpler (look at draft-nakhjiri-radius-mip4-02)
because there are attributes related to MIP4 authentication (such as
MIP-MN-AAA-Authenticator, etc) within the Access Request that tells the
server this is about RADIUS. Diameter on the other hand has the notion =
of
Application ID and should not rely on explicit hint on this. When we got =
to
the point of trying to translate Diameter messaging to RADIUS, we had to
resort to port types, because Diameter had different messages (depending =
on
whether HA or FA were involved) while all RADIUS had was Access
Request/Accepts not recognizing between HA and FA.
Here your case is different. Diameter already has an Application ID for
Mobile IP. That is how you distinguish between access and mobility =
service,
not through service type. Now there are two choices as I said before:

A) revise 3588 to have one App ID for MIPv4 and one for MIPv6 (separate =
MIP6
split versus integrated through service types). This of course mean =
revising
4004 to indicate specifically what MIPv4 App ID is.

B) Use the same App ID of 3588 for both MIP4 and MIP6, but then you have =
to
define 4 service types
1) MIP4 split
2) MIP4 integrated
3) MIP6 split
4) MIP6 integrated.

I prefer A (I can live with B, if you tie a rope to my neck, just =
kidding).
I think A is cleaner. I think split-integrated versus MIP4-mip6 are two
different degrees of freedom. Just because MIP4 WG did not make the =
split
integrated distinction, does not mean the business case cannot exist.
Plus that Avi stated that Service type seems to be mandatory.

Madjid

-----Original Message-----
From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr]
Sent: Wednesday, August 09, 2006 1:39 AM
To: Madjid Nakhjiri
Cc: 'Julien Bournelle'; 'Hannes Tschofenig'; dime@ietf.org
Subject: Re: [Dime] MIP6 App ID/ revise RFC 3588???

Hi madjid,

On Tue, Aug 08, 2006 at 04:51:08PM -0700, Madjid Nakhjiri wrote:
> Hi Julien,
>
> I just looked at the RFC 4005 definition of Service_Type.
> The services listed there are quite mixed. I am not quite sure what
> applications besides NASREQ are supposed to support Service_Type? Or =
is it
> that Mobile IP application assumes NASREQ must be supported?

 Let me try to sum up the issue:

 In the split scenario, the HA acts as a IKEv2 responder and uses EAP
 (oIKEv2) to authenticate the user (of the MN). The HA then relies on a
 EAP/AAA server and thus could use Diameter EAP. THe problem that we
 have here is that we are not performing AAA for "basic" network access
 but for the IPv6 Mobility service. Thus we have the problem of, how the
 AAA server knows that.

 You can take a look at the thread:

 http://www1.ietf.org/mail-archive/web/dime/current/msg00262.html

 for previous discussions on this topic which is still unsolved.

 At this point, as noted in:

 http://www1.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-00.txt

 the 2 options that we have are:

 - define a new Service-Type for "Mobile IPv6 - Split" and puts it in
   DER message (Diameter EAP Request)
 - define a new Application-ID and re-use Diameter EAP messages.

 Hope it helps,

 regards,

 Julien

>
> If one is to go about without modifying RFC 3588 that uses just one =
App ID
> for Mobile IP, then I guess there is just one choice of having
>
> two Service_types for Mobile IPv6
> and
> one Service_Type for Mobile IPv4,
>
> (3 total for Mobile IP), but then don't you have to modify RFC 4004 to =
add
> the service_type to Mobile IPv4?
>
> Madjid
>
> -----Original Message-----
> From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr]
> Sent: Monday, August 07, 2006 6:42 AM
> To: Madjid Nakhjiri
> Cc: 'Hannes Tschofenig'; dime@ietf.org
> Subject: Re: [Dime] MIP6 App ID/ was: IETF#66 Meeting Minutes
>
> HI madjid,
>
> On Mon, Aug 07, 2006 at 06:34:55AM -0700, Madjid Nakhjiri wrote:
> > No worries, I was being humorous. I wanted to see what was said =
during
the
> > meeting regarding the Mobile IP6 drafts. I tried to see the archive
> > discussions, but did not see anything in June or July either.
> > I am seeing all this discussion on the use of App IDs on the ML, so =
I
> wanted
> > to see if MIP6 is getting its own App ID, or it is using the App ID
> assigned
> > to Mobiloe IP in 3588?
>
>  basically the question is: do we need a specific App ID or do a
>  Service-Type AVP (indicating that it's a HA for the split scenario) =
is
>  sufficient ?
>
>
>  regards,
>
>  Julien
>
> >
> > R,
> >
> > Madjid
> >
> > -----Original Message-----
> > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
> > Sent: Saturday, August 05, 2006 5:22 AM
> > To: Madjid Nakhjiri
> > Cc: dime@ietf.org
> > Subject: Re: [Dime] IETF#66 Meeting Minutes
> >
> > I agree that the meeting minutes are somewhat brief this time.
> > We will do better with the next IETF meeting...
> >
> > Ciao
> > Hannes
> >
> > Madjid Nakhjiri wrote:
> > > Was this minutes or 10-minutes:-)
> > >
> > > -----Original Message-----
> > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
> > > Sent: Wednesday, July 19, 2006 7:56 AM
> > > To: dime@ietf.org
> > > Subject: [Dime] IETF#66 Meeting Minutes
> > >
> > > Hi all,
> > >
> > > please take a look at the meeting minutes:
> > > http://www3.ietf.org/proceedings/06jul/minutes/dime.txt
> > >
> > > Ciao
> > > Hannes
> > >
> > > _______________________________________________
> > > DiME mailing list
> > > DiME@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/dime
> > >
> > >
> > >
> >
> >
> >
> >
> > _______________________________________________
> > DiME mailing list
> > DiME@ietf.org
> > https://www1.ietf.org/mailman/listinfo/dime
>
> --
> julien.bournelle at int-evry.fr
>
>

--
julien.bournelle at int-evry.fr



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



------_=_NextPart_001_01C6C094.35917EF6
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 =
6.5.7650.28">
<TITLE>RE: [Dime] MIP6 App ID/ revise RFC 3588???</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>To summarize:<BR>
<BR>
No need to update 3588 or 4004 just because we add a new application =
with its own application id.<BR>
<BR>
Madjid wrote:<BR>
<BR>
Ok, seems like everybody agrees on giving MIP6 a new App ID, so I am =
happy. If newcomers don't get the App ID list in 3588, that is their =
problem, I love working on AAA, there is so much job security.<BR>
<BR>
I dont think that this is strictly a AAA problem. Nor do I think that =
this is a problem.&nbsp; IANA is the authoritative place where ids or =
assigned numbers of all sorts are kept.&nbsp; Hence the name.<BR>
<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: Madjid Nakhjiri [<A =
HREF=3D"mailto:mnakhjiri@huawei.com">mailto:mnakhjiri@huawei.com</A>]<BR>=

Sent: Tue 8/15/2006 1:34 PM<BR>
To: 'Glen Zorn (gwz)'; Avi Lior; 'Julien Bournelle'<BR>
Cc: dime@ietf.org; 'Madjid Nakhjiri'<BR>
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???<BR>
<BR>
Obvious to us, obviously?<BR>
<BR>
<BR>
<BR>
Ok, seems like everybody agrees on giving MIP6 a new App ID, so I am =
happy. If newcomers don't get the App ID list in 3588, that is their =
problem, I love working on AAA, there is so much job security.<BR>
<BR>
<BR>
<BR>
________________________________<BR>
<BR>
From: Glen Zorn (gwz) [<A =
HREF=3D"mailto:gwz@cisco.com">mailto:gwz@cisco.com</A>]<BR>
Sent: Tuesday, August 15, 2006 10:27 AM<BR>
To: Madjid Nakhjiri; Avi Lior; Julien Bournelle<BR>
Cc: dime@ietf.org<BR>
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???<BR>
<BR>
<BR>
<BR>
Because RFC 3588 defines a single Application ID for Mobile IP and 3588 =
is being revised anyway.<BR>
<BR>
If this was a brand new application, it would not matter, but you =
already have one App ID for Mobile IP, that could only be used for MIP4, =
if you now define a different App ID for Mip6.<BR>
<BR>
<BR>
<BR>
OK, so what?&nbsp; The app ID defined in 3588 is pretty obviously for =
MIP v4, the one defined in 4004 is _specifically_ for MIP v4, &amp; MIP =
v6 _is_ a brand new application....<BR>
<BR>
<BR>
<BR>
________________________________<BR>
<BR>
From: Avi Lior [<A =
HREF=3D"mailto:avi@bridgewatersystems.com">mailto:avi@bridgewatersystems.=
com</A>]<BR>
Sent: Tuesday, August 15, 2006 7:25 AM<BR>
To: Madjid Nakhjiri; Julien Bournelle<BR>
Cc: dime@ietf.org<BR>
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
I don't think RFC3588 needs to be touched when adding an new Application =
ID. Neither should<BR>
<BR>
Why do you think you need to touch 3588 or 4004?<BR>
<BR>
-----Original Message-----<BR>
From: Madjid Nakhjiri [<A =
HREF=3D"mailto:mnakhjiri@huawei.com">mailto:mnakhjiri@huawei.com</A>]<BR>=

Sent: Tue 8/15/2006 10:07 AM<BR>
To: Avi Lior; 'Julien Bournelle'<BR>
Cc: dime@ietf.org; 'Madjid Nakhjiri'<BR>
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???<BR>
<BR>
Hi Avi,<BR>
<BR>
<BR>
<BR>
Not sure what &quot;correct&quot; meansJ I am planning on looking a bit =
closer at 3588 to see exactly how &quot;application&quot; and &quot;App =
ID&quot; is used.<BR>
<BR>
As I said I _prefer_ adding a new Application ID for Mobile IPv6, but =
then both RFC 3588 and 4004 needs to be revised to reflect that, I think =
the harm for that is minimal anyway, given the fairly rare deployment of =
4004 (I think).<BR>
<BR>
<BR>
<BR>
Madjid.<BR>
<BR>
<BR>
<BR>
________________________________<BR>
<BR>
From: Avi Lior [<A =
HREF=3D"mailto:avi@bridgewatersystems.com">mailto:avi@bridgewatersystems.=
com</A>]<BR>
Sent: Tuesday, August 15, 2006 7:01 AM<BR>
To: Madjid Nakhjiri; Julien Bournelle<BR>
Cc: dime@ietf.org<BR>
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
How about the correct (IMO) option and that is assign this new =
application its own Application ID.&nbsp; THis afterall is what an =
Application ID is supposed to do.<BR>
<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: Madjid Nakhjiri [<A =
HREF=3D"mailto:mnakhjiri@huawei.com">mailto:mnakhjiri@huawei.com</A>]<BR>=

Sent: Fri 8/11/2006 6:49 PM<BR>
To: 'Julien Bournelle'<BR>
Cc: dime@ietf.org<BR>
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???<BR>
<BR>
Hi Julien,<BR>
<BR>
Thanks for pointing me to the archives.<BR>
I have one general issue that maybe is related to me not quite =
understanding<BR>
EAP-IKEv2 and that is EAP is run between a peer and an EAP server (in =
this<BR>
case the backend AAA server). EAP-IKEv2 was designed so that a =
mature<BR>
authentication/key management method could be used within EAP =
framework.<BR>
Running EAP-IKEv2 results in authentication of peer to backend AAA, not =
to<BR>
HA and possibly a key between the peer and AAA server. How does this =
help<BR>
the need for IPsec between MN and HA?<BR>
<BR>
Now as far as the discussions on the archives, RFC 4072 only talks =
about<BR>
carrying EAP over Diameter without talking about what EAP is being used =
for<BR>
(your question: mobility versus access service). I think =
distinguishing<BR>
mobility versus access is a AAA signaling issue not an EAP signaling =
issue.<BR>
In RADIUS and MIP4 it is simpler (look at =
draft-nakhjiri-radius-mip4-02)<BR>
because there are attributes related to MIP4 authentication (such as<BR>
MIP-MN-AAA-Authenticator, etc) within the Access Request that tells =
the<BR>
server this is about RADIUS. Diameter on the other hand has the notion =
of<BR>
Application ID and should not rely on explicit hint on this. When we got =
to<BR>
the point of trying to translate Diameter messaging to RADIUS, we had =
to<BR>
resort to port types, because Diameter had different messages (depending =
on<BR>
whether HA or FA were involved) while all RADIUS had was Access<BR>
Request/Accepts not recognizing between HA and FA.<BR>
Here your case is different. Diameter already has an Application ID =
for<BR>
Mobile IP. That is how you distinguish between access and mobility =
service,<BR>
not through service type. Now there are two choices as I said =
before:<BR>
<BR>
A) revise 3588 to have one App ID for MIPv4 and one for MIPv6 (separate =
MIP6<BR>
split versus integrated through service types). This of course mean =
revising<BR>
4004 to indicate specifically what MIPv4 App ID is.<BR>
<BR>
B) Use the same App ID of 3588 for both MIP4 and MIP6, but then you have =
to<BR>
define 4 service types<BR>
1) MIP4 split<BR>
2) MIP4 integrated<BR>
3) MIP6 split<BR>
4) MIP6 integrated.<BR>
<BR>
I prefer A (I can live with B, if you tie a rope to my neck, just =
kidding).<BR>
I think A is cleaner. I think split-integrated versus MIP4-mip6 are =
two<BR>
different degrees of freedom. Just because MIP4 WG did not make the =
split<BR>
integrated distinction, does not mean the business case cannot =
exist.<BR>
Plus that Avi stated that Service type seems to be mandatory.<BR>
<BR>
Madjid<BR>
<BR>
-----Original Message-----<BR>
From: Julien Bournelle [<A =
HREF=3D"mailto:julien.bournelle@int-evry.fr">mailto:julien.bournelle@int-=
evry.fr</A>]<BR>
Sent: Wednesday, August 09, 2006 1:39 AM<BR>
To: Madjid Nakhjiri<BR>
Cc: 'Julien Bournelle'; 'Hannes Tschofenig'; dime@ietf.org<BR>
Subject: Re: [Dime] MIP6 App ID/ revise RFC 3588???<BR>
<BR>
Hi madjid,<BR>
<BR>
On Tue, Aug 08, 2006 at 04:51:08PM -0700, Madjid Nakhjiri wrote:<BR>
&gt; Hi Julien,<BR>
&gt;<BR>
&gt; I just looked at the RFC 4005 definition of Service_Type.<BR>
&gt; The services listed there are quite mixed. I am not quite sure =
what<BR>
&gt; applications besides NASREQ are supposed to support Service_Type? =
Or is it<BR>
&gt; that Mobile IP application assumes NASREQ must be supported?<BR>
<BR>
&nbsp;Let me try to sum up the issue:<BR>
<BR>
&nbsp;In the split scenario, the HA acts as a IKEv2 responder and uses =
EAP<BR>
&nbsp;(oIKEv2) to authenticate the user (of the MN). The HA then relies =
on a<BR>
&nbsp;EAP/AAA server and thus could use Diameter EAP. THe problem that =
we<BR>
&nbsp;have here is that we are not performing AAA for &quot;basic&quot; =
network access<BR>
&nbsp;but for the IPv6 Mobility service. Thus we have the problem of, =
how the<BR>
&nbsp;AAA server knows that.<BR>
<BR>
&nbsp;You can take a look at the thread:<BR>
<BR>
&nbsp;<A =
HREF=3D"http://www1.ietf.org/mail-archive/web/dime/current/msg00262.html"=
>http://www1.ietf.org/mail-archive/web/dime/current/msg00262.html</A><BR>=

<BR>
&nbsp;for previous discussions on this topic which is still =
unsolved.<BR>
<BR>
&nbsp;At this point, as noted in:<BR>
<BR>
&nbsp;<A =
HREF=3D"http://www1.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-0=
0.txt">http://www1.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-00=
.txt</A><BR>
<BR>
&nbsp;the 2 options that we have are:<BR>
<BR>
&nbsp;- define a new Service-Type for &quot;Mobile IPv6 - Split&quot; =
and puts it in<BR>
&nbsp;&nbsp; DER message (Diameter EAP Request)<BR>
&nbsp;- define a new Application-ID and re-use Diameter EAP =
messages.<BR>
<BR>
&nbsp;Hope it helps,<BR>
<BR>
&nbsp;regards,<BR>
<BR>
&nbsp;Julien<BR>
<BR>
&gt;<BR>
&gt; If one is to go about without modifying RFC 3588 that uses just one =
App ID<BR>
&gt; for Mobile IP, then I guess there is just one choice of having<BR>
&gt;<BR>
&gt; two Service_types for Mobile IPv6<BR>
&gt; and<BR>
&gt; one Service_Type for Mobile IPv4,<BR>
&gt;<BR>
&gt; (3 total for Mobile IP), but then don't you have to modify RFC 4004 =
to add<BR>
&gt; the service_type to Mobile IPv4?<BR>
&gt;<BR>
&gt; Madjid<BR>
&gt;<BR>
&gt; -----Original Message-----<BR>
&gt; From: Julien Bournelle [<A =
HREF=3D"mailto:julien.bournelle@int-evry.fr">mailto:julien.bournelle@int-=
evry.fr</A>]<BR>
&gt; Sent: Monday, August 07, 2006 6:42 AM<BR>
&gt; To: Madjid Nakhjiri<BR>
&gt; Cc: 'Hannes Tschofenig'; dime@ietf.org<BR>
&gt; Subject: Re: [Dime] MIP6 App ID/ was: IETF#66 Meeting Minutes<BR>
&gt;<BR>
&gt; HI madjid,<BR>
&gt;<BR>
&gt; On Mon, Aug 07, 2006 at 06:34:55AM -0700, Madjid Nakhjiri =
wrote:<BR>
&gt; &gt; No worries, I was being humorous. I wanted to see what was =
said during<BR>
the<BR>
&gt; &gt; meeting regarding the Mobile IP6 drafts. I tried to see the =
archive<BR>
&gt; &gt; discussions, but did not see anything in June or July =
either.<BR>
&gt; &gt; I am seeing all this discussion on the use of App IDs on the =
ML, so I<BR>
&gt; wanted<BR>
&gt; &gt; to see if MIP6 is getting its own App ID, or it is using the =
App ID<BR>
&gt; assigned<BR>
&gt; &gt; to Mobiloe IP in 3588?<BR>
&gt;<BR>
&gt;&nbsp; basically the question is: do we need a specific App ID or do =
a<BR>
&gt;&nbsp; Service-Type AVP (indicating that it's a HA for the split =
scenario) is<BR>
&gt;&nbsp; sufficient ?<BR>
&gt;<BR>
&gt;<BR>
&gt;&nbsp; regards,<BR>
&gt;<BR>
&gt;&nbsp; Julien<BR>
&gt;<BR>
&gt; &gt;<BR>
&gt; &gt; R,<BR>
&gt; &gt;<BR>
&gt; &gt; Madjid<BR>
&gt; &gt;<BR>
&gt; &gt; -----Original Message-----<BR>
&gt; &gt; From: Hannes Tschofenig [<A =
HREF=3D"mailto:Hannes.Tschofenig@gmx.net">mailto:Hannes.Tschofenig@gmx.ne=
t</A>]<BR>
&gt; &gt; Sent: Saturday, August 05, 2006 5:22 AM<BR>
&gt; &gt; To: Madjid Nakhjiri<BR>
&gt; &gt; Cc: dime@ietf.org<BR>
&gt; &gt; Subject: Re: [Dime] IETF#66 Meeting Minutes<BR>
&gt; &gt;<BR>
&gt; &gt; I agree that the meeting minutes are somewhat brief this =
time.<BR>
&gt; &gt; We will do better with the next IETF meeting...<BR>
&gt; &gt;<BR>
&gt; &gt; Ciao<BR>
&gt; &gt; Hannes<BR>
&gt; &gt;<BR>
&gt; &gt; Madjid Nakhjiri wrote:<BR>
&gt; &gt; &gt; Was this minutes or 10-minutes:-)<BR>
&gt; &gt; &gt;<BR>
&gt; &gt; &gt; -----Original Message-----<BR>
&gt; &gt; &gt; From: Hannes Tschofenig [<A =
HREF=3D"mailto:Hannes.Tschofenig@gmx.net">mailto:Hannes.Tschofenig@gmx.ne=
t</A>]<BR>
&gt; &gt; &gt; Sent: Wednesday, July 19, 2006 7:56 AM<BR>
&gt; &gt; &gt; To: dime@ietf.org<BR>
&gt; &gt; &gt; Subject: [Dime] IETF#66 Meeting Minutes<BR>
&gt; &gt; &gt;<BR>
&gt; &gt; &gt; Hi all,<BR>
&gt; &gt; &gt;<BR>
&gt; &gt; &gt; please take a look at the meeting minutes:<BR>
&gt; &gt; &gt; <A =
HREF=3D"http://www3.ietf.org/proceedings/06jul/minutes/dime.txt">http://w=
ww3.ietf.org/proceedings/06jul/minutes/dime.txt</A><BR>
&gt; &gt; &gt;<BR>
&gt; &gt; &gt; Ciao<BR>
&gt; &gt; &gt; Hannes<BR>
&gt; &gt; &gt;<BR>
&gt; &gt; &gt; _______________________________________________<BR>
&gt; &gt; &gt; DiME mailing list<BR>
&gt; &gt; &gt; DiME@ietf.org<BR>
&gt; &gt; &gt; <A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/dime">https://www1.ietf.or=
g/mailman/listinfo/dime</A><BR>
&gt; &gt; &gt;<BR>
&gt; &gt; &gt;<BR>
&gt; &gt; &gt;<BR>
&gt; &gt;<BR>
&gt; &gt;<BR>
&gt; &gt;<BR>
&gt; &gt;<BR>
&gt; &gt; _______________________________________________<BR>
&gt; &gt; DiME mailing list<BR>
&gt; &gt; DiME@ietf.org<BR>
&gt; &gt; <A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/dime">https://www1.ietf.or=
g/mailman/listinfo/dime</A><BR>
&gt;<BR>
&gt; --<BR>
&gt; julien.bournelle at int-evry.fr<BR>
&gt;<BR>
&gt;<BR>
<BR>
--<BR>
julien.bournelle at int-evry.fr<BR>
<BR>
<BR>
<BR>
_______________________________________________<BR>
DiME mailing list<BR>
DiME@ietf.org<BR>
<A =
HREF=3D"https://www1.ietf.org/mailman/listinfo/dime">https://www1.ietf.or=
g/mailman/listinfo/dime</A><BR>
<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C6C094.35917EF6--


--===============2082655860==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============2082655860==--




From dime-bounces@ietf.org Tue Aug 15 14:28:34 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GD3eJ-0002J1-Fa; Tue, 15 Aug 2006 14:28:23 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GD3eH-0002I5-Ij
	for dime@ietf.org; Tue, 15 Aug 2006 14:28:21 -0400
Received: from bws14.bridgewatersystems.com ([216.113.7.14]
	helo=exchange.bridgewatersys.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD3Yx-00051I-40
	for dime@ietf.org; Tue, 15 Aug 2006 14:22:51 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???
Date: Tue, 15 Aug 2006 14:23:56 -0400
Message-ID: <E7CCE8A83907104ABEE91AC3AE3709A01167E2@exchange.bridgewatersys.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Dime] MIP6 App ID/ revise RFC 3588???
Thread-Index: Aca7j5pLlwjYezfqQhS35Ix/bK+xSgCBYw0QALeF6YMAABfC8AAAO289AAQhW/AAAJNTagACZUpAAAE3ESA=
References: <4C0FAAC489C8B74F96BEAD85EAEB26250272B8D4@xmb-sjc-215.amer.cisco.com>
From: "Avi Lior" <avi@bridgewatersystems.com>
To: "Glen Zorn \(gwz\)" <gwz@cisco.com>,
	"Madjid Nakhjiri" <mnakhjiri@huawei.com>,
	"Julien Bournelle" <julien.bournelle@int-evry.fr>
X-Spam-Score: 0.6 (/)
X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1078656398=="
Errors-To: dime-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1078656398==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C6C097.F807F27C"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6C097.F807F27C
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Glen,

Glen Zorn wrote:

"Nonsense, again.  The normative reference for a number is the document =
in which that numbers usage is defined; it must be so since the IANA is =
just a registry containing neither syntactic nor semantic information =
regarding the entries.  In fact the IANA entries for the first 4 =
Diameter app IDs reference RFC 3588."

Doesn't IANA own the numbers?

Second, dont you think that the fact that IANA refences RFC 3588 for =
those numbers (NASREQ and MIPv4) is wrong since RFC3588 does not define =
the syntactic nor semantic information regarding those enteries.

I am not suggesting that we need to "bis" 3588 because of a new =
application.  I was suggesting that if were were to update 3588 because =
of a new application we should remove those applications ids from 3588 =
so that we dont get into a discussion in the future whereby some newbie =
suggests that we update 3588 to reflect new application ids.


-----Original Message-----
From: Glen Zorn (gwz) [mailto:gwz@cisco.com]
Sent: Tue 8/15/2006 1:54 PM
To: Avi Lior; Madjid Nakhjiri; Julien Bournelle
Cc: dime@ietf.org
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???
=20
...
=20
 I think that RFC3588 should not define any application ids.  If it does =
they should be informative.=20
=20
Nonsense.  Various numbers have been defined in RFCs (with the =
assignment of future numbers left to the IANA) for literally years: =
somehow developers have found the right numbers to use & the Internet =
has survived.  I realize that there is a trend to turn RFCs into =
tutorials for uni freshmen and bellheads but this is getting ridiculous. =
 If you need even more clarity, the IANA entry for Diameter Application =
ID 2 identifies it as representing "Mobile IP v4".  =20

So if we are going to change 3588 we should remove any reference to any =
Application IDs.=20

IANA should be the only authoritative (normative) entity for Application =
IDS.=20
=20
Nonsense, again.  The normative reference for a number is the document =
in which that numbers usage is defined; it must be so since the IANA is =
just a registry containing neither syntactic nor semantic information =
regarding the entries.  In fact the IANA entries for the first 4 =
Diameter app IDs reference RFC 3588. =20
=20
...=20



Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by simply =
listening to John Coltrane?
  -- Henry Gabriel=20



------_=_NextPart_001_01C6C097.F807F27C
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 =
6.5.7650.28">
<TITLE>RE: [Dime] MIP6 App ID/ revise RFC 3588???</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>Glen,<BR>
<BR>
Glen Zorn wrote:<BR>
<BR>
&quot;Nonsense, again.&nbsp; The normative reference for a number is the =
document in which that numbers usage is defined; it must be so since the =
IANA is just a registry containing neither syntactic nor semantic =
information regarding the entries.&nbsp; In fact the IANA entries for =
the first 4 Diameter app IDs reference RFC 3588.&quot;<BR>
<BR>
Doesn't IANA own the numbers?<BR>
<BR>
Second, dont you think that the fact that IANA refences RFC 3588 for =
those numbers (NASREQ and MIPv4) is wrong since RFC3588 does not define =
the syntactic nor semantic information regarding those enteries.<BR>
<BR>
I am not suggesting that we need to &quot;bis&quot; 3588 because of a =
new application.&nbsp; I was suggesting that if were were to update 3588 =
because of a new application we should remove those applications ids =
from 3588 so that we dont get into a discussion in the future whereby =
some newbie suggests that we update 3588 to reflect new application =
ids.<BR>
<BR>
<BR>
-----Original Message-----<BR>
From: Glen Zorn (gwz) [<A =
HREF=3D"mailto:gwz@cisco.com">mailto:gwz@cisco.com</A>]<BR>
Sent: Tue 8/15/2006 1:54 PM<BR>
To: Avi Lior; Madjid Nakhjiri; Julien Bournelle<BR>
Cc: dime@ietf.org<BR>
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???<BR>
<BR>
...<BR>
<BR>
&nbsp;I think that RFC3588 should not define any application ids.&nbsp; =
If it does they should be informative.<BR>
<BR>
Nonsense.&nbsp; Various numbers have been defined in RFCs (with the =
assignment of future numbers left to the IANA) for literally years: =
somehow developers have found the right numbers to use &amp; the =
Internet has survived.&nbsp; I realize that there is a trend to turn =
RFCs into tutorials for uni freshmen and bellheads but this is getting =
ridiculous.&nbsp; If you need even more clarity, the IANA entry for =
Diameter Application ID 2 identifies it as representing &quot;Mobile IP =
v4&quot;.&nbsp;&nbsp;<BR>
<BR>
So if we are going to change 3588 we should remove any reference to any =
Application IDs.<BR>
<BR>
IANA should be the only authoritative (normative) entity for Application =
IDS.<BR>
<BR>
Nonsense, again.&nbsp; The normative reference for a number is the =
document in which that numbers usage is defined; it must be so since the =
IANA is just a registry containing neither syntactic nor semantic =
information regarding the entries.&nbsp; In fact the IANA entries for =
the first 4 Diameter app IDs reference RFC 3588.&nbsp;<BR>
<BR>
...<BR>
<BR>
<BR>
<BR>
Hope this helps,<BR>
<BR>
~gwz<BR>
<BR>
Why is it that most of the world's problems can't be solved by simply =
listening to John Coltrane?<BR>
&nbsp; -- Henry Gabriel<BR>
<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C6C097.F807F27C--


--===============1078656398==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============1078656398==--




From dime-bounces@ietf.org Tue Aug 15 14:29:04 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GD3ey-0002kd-Fe; Tue, 15 Aug 2006 14:29:04 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GD3ex-0002kM-PS
	for dime@ietf.org; Tue, 15 Aug 2006 14:29:03 -0400
Received: from sj-iport-1-in.cisco.com ([171.71.176.70]
	helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GD3QN-0004Cv-IO
	for dime@ietf.org; Tue, 15 Aug 2006 14:14:02 -0400
Received: from sj-dkim-2.cisco.com ([171.71.179.186])
	by sj-iport-1.cisco.com with ESMTP; 15 Aug 2006 11:13:59 -0700
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254])
	by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id
	k7FIDwEd008803; Tue, 15 Aug 2006 11:13:58 -0700
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com
	[128.107.191.63])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k7FIDwlN005698;
	Tue, 15 Aug 2006 11:13:58 -0700 (PDT)
Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by
	xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 15 Aug 2006 11:13:58 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???
Date: Tue, 15 Aug 2006 11:13:57 -0700
Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB26250272B8F9@xmb-sjc-215.amer.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Dime] MIP6 App ID/ revise RFC 3588???
Thread-Index: Aca7j5pLlwjYezfqQhS35Ix/bK+xSgCBYw0QALeF6YMAABfC8AAGj5KAAABcrDAAATdcMA==
From: "Glen Zorn \(gwz\)" <gwz@cisco.com>
To: "Madjid Nakhjiri" <mnakhjiri@huawei.com>,
	"Avi Lior" <avi@bridgewatersystems.com>,
	"Julien Bournelle" <julien.bournelle@int-evry.fr>
X-OriginalArrivalTime: 15 Aug 2006 18:13:58.0351 (UTC)
	FILETIME=[93C645F0:01C6C096]
DKIM-Signature: a=rsa-sha1; q=dns; l=11926; t=1155665639; x=1156529639;
	c=relaxed/simple; s=sjdkim2002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=gwz@cisco.com;
	z=From:=22Glen=20Zorn=20\(gwz\)=22=20<gwz@cisco.com>
	|Subject:RE=3A=20[Dime]=20MIP6=20App=20ID/=20revise=20RFC=203588???;
	X=v=3Dcisco.com=3B=20h=3DclTfX7CEiNg3hBXjbSQddXWAtz0=3D;
	b=wcV+MoyF54IzUN/J6xvCc0LpxTCrEsVO9jTUbMj+XkFlfrkSFCIHnw6UmmyhpfsP2DsNJqKQ
	tq72Tfx2WgING5SmbyqaMydJeVSXKDEOT+Y0IUNGMbMV6SoGS3V2GgCr;
Authentication-Results: sj-dkim-2.cisco.com; header.From=gwz@cisco.com;
	dkim=pass (
	59 extraneous bytes; sig from cisco.com verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d11a451997816a91a305dcb5ab1b85dd
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1831861587=="
Errors-To: dime-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1831861587==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C6C096.93A9B90A"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6C096.93A9B90A
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi Glen,

=20

Don't give up so easily, we need you here :-)



As I said earlier, 3588 has a little table defining the 5 App IDs, =
including a App ID for Mobile IP. So far we 4004 on MIP4 and I am =
guessing we will have 1 or 2 specs for MIP6. Avi suggests defining a new =
App ID for MIP6, I agree with him, but I am weighing the consequences, =
one of which is how can you have one App ID for Mobile IP, and another =
for Mobile IPv6. So there are two choices if we define a new App ID for =
MIP6:

=20

1)     take App ID table out of 3588

2)     revise Mobile IP to Mobile IPv4 in 3588=20

=20

Actually, there's another option: Use brain ;-).  The assignment in 3588 =
is pretty obviously for MIP v4; both 4004 and the IANA entry make it =
blatantly specific.  OTOH, if you really believe that the lack of "IPv4" =
 on the third entry in RFC 3588's table of app IDs will so paralyze =
developers that they will become incapable of functioning, go ahead and =
add it.  OTOOH, please give some thought to what the Internet might be =
like if those same developers found employment in areas for which they =
might be better suited (say, the food service or hospitality =
industries).  Please don't do something like overloading the =
Service-Type AVP, though.

=20

Both of which can count as revisions, don't you think? Seems that the =
group is revising 3588 anyway (tell me if I misunderstood), and in that =
case, this is a minor change.

=20

Madjid

=20

________________________________

From: Glen Zorn (gwz) [mailto:gwz@cisco.com]=20
Sent: Tuesday, August 15, 2006 10:13 AM
To: Madjid Nakhjiri; Avi Lior; Julien Bournelle
Cc: dime@ietf.org
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???

=20

I give up, why do 3588 & 4004 need to be revised?

=20

...

both RFC 3588 and 4004 needs to be revised to reflect that, I think the =
harm for that is minimal anyway, given the fairly rare deployment of =
4004 (I think).

...


------_=_NextPart_001_01C6C096.93A9B90A
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML xmlns=3D"http://www.w3.org/TR/REC-html40" xmlns:v =3D=20
"urn:schemas-microsoft-com:vml" xmlns:o =3D=20
"urn:schemas-microsoft-com:office:office" xmlns:w =3D=20
"urn:schemas-microsoft-com:office:word"><HEAD><TITLE>RE: [Dime] MIP6 App =
ID/ revise RFC 3588???</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1555" name=3DGENERATOR><!--[if !mso]>
<STYLE>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</STYLE>
<![endif]-->
<STYLE>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
p
	{mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.EmailStyle18
	{mso-style-type:personal;
	font-family:Arial;
	color:navy;}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:1636982651;
	mso-list-type:hybrid;
	mso-list-template-ids:904272498 67698705 67698713 67698715 67698703 =
67698713 67698715 67698703 67698713 67698715;}
@list l0:level1
	{mso-level-text:"%1\)";
	mso-level-tab-stop:.5in;
	mso-level-number-position:left;
	text-indent:-.25in;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
-->
</STYLE>
</HEAD>
<BODY lang=3DEN-US vLink=3Dblue link=3Dblue>
<DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3Dnavy =
size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Hi=20
Glen,<o:p></o:p></SPAN></FONT></DIV>
<DIV class=3DSection1>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Don=92t give =
up so=20
easily, we need you here </SPAN></FONT><FONT face=3DWingdings =
color=3Dnavy=20
size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Wingdings">J</SPAN></FONT><FONT=20
face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><BR><BR><o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">As I said =
earlier, 3588=20
has a little table defining the 5 App IDs, including a App ID for Mobile =
IP. So=20
far we 4004 on MIP4 and I am guessing we will have 1 or 2 specs for =
MIP6. Avi=20
suggests defining a new App ID for MIP6, I agree with him, but I am =
weighing the=20
consequences, one of which is how can you have one App ID for Mobile IP, =
and=20
another for Mobile IPv6. So there are two choices if we define a new App =
ID for=20
MIP6:<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal=20
style=3D"MARGIN-LEFT: 0.5in; TEXT-INDENT: -0.25in; mso-list: l0 level1 =
lfo1"><![if !supportLists]><FONT=20
face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><SPAN=20
style=3D"mso-list: Ignore">1)<FONT face=3D"Times New Roman" =
size=3D1><SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></FONT></SPAN></SPAN></FONT><![endif]><FONT face=3DArial =
color=3Dnavy=20
size=3D2><SPAN style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">take App=20
ID table out of 3588<o:p></o:p></SPAN></FONT></P><![if !supportLists]>
<P class=3DMsoNormal=20
style=3D"MARGIN-LEFT: 0.5in; TEXT-INDENT: -0.25in; mso-list: l0 level1 =
lfo1"><FONT=20
color=3Dnavy><SPAN style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><SPAN=20
style=3D"mso-list: Ignore">2)<FONT face=3DArial size=3D2><SPAN=20
style=3D"FONT: 7pt 'Times New Roman'">&nbsp;&nbsp;&nbsp;&nbsp;=20
</SPAN></FONT></SPAN></SPAN></FONT><![endif]><FONT color=3Dnavy><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">revise Mobile =
IP to=20
Mobile IPv4 in 3588<FONT color=3D#0000ff><SPAN=20
class=3D561445617-15082006>&nbsp;</SPAN></FONT></SPAN></FONT></P>
<P class=3DMsoNormal=20
style=3D"MARGIN-LEFT: 0.5in; TEXT-INDENT: -0.25in; mso-list: l0 level1 =
lfo1"><FONT=20
color=3Dnavy><SPAN style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><FONT=20
color=3D#0000ff><SPAN=20
class=3D561445617-15082006></SPAN></FONT></SPAN></FONT>&nbsp;</P>
<P class=3DMsoNormal><FONT color=3Dnavy><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><SPAN=20
class=3D561445617-15082006><FONT color=3D#0000ff>Actually, there's =
another option:=20
Use brain ;-).&nbsp; The assignment in 3588 is pretty obviously for MIP =
v4; both=20
4004 and the IANA entry make it blatantly specific.&nbsp; OTOH, if you =
really=20
believe that the lack of "IPv4"&nbsp; on the third entry in RFC 3588's =
table of=20
app IDs will so paralyze developers that they will become incapable of=20
functioning, go ahead and add it.&nbsp; OTOOH, please give some thought =
to what=20
the Internet might be like if those same developers found employment in =
areas=20
for which they might be better suited (say, the food service or =
hospitality=20
industries).&nbsp; Please don't do something like overloading the =
Service-Type=20
AVP, though.</FONT></SPAN></SPAN></FONT></P>
<P class=3DMsoNormal><FONT color=3Dnavy><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial"><SPAN=20
class=3D561445617-15082006></SPAN></SPAN></FONT>&nbsp;</P>
<P class=3DMsoNormal><FONT color=3Dnavy><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">Both of which =
can count=20
as revisions, don=92t you think? Seems that the group is revising 3588 =
anyway=20
(tell me if I misunderstood), and in that case, this is a minor=20
change.<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial">Madjid<o:p></o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: =
Arial"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<DIV>
<DIV class=3DMsoNormal style=3D"TEXT-ALIGN: center" align=3Dcenter><FONT =

face=3D"Times New Roman" size=3D3><SPAN style=3D"FONT-SIZE: 12pt">
<HR tabIndex=3D-1 align=3Dcenter width=3D"100%" SIZE=3D3>
</SPAN></FONT></DIV>
<P class=3DMsoNormal><B><FONT face=3DTahoma size=3D2><SPAN=20
style=3D"FONT-WEIGHT: bold; FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma">From:</SPAN></FONT></B><FONT=20
face=3DTahoma size=3D2><SPAN style=3D"FONT-SIZE: 10pt; FONT-FAMILY: =
Tahoma"> Glen Zorn=20
(gwz) [mailto:gwz@cisco.com] <BR><B><SPAN=20
style=3D"FONT-WEIGHT: bold">Sent:</SPAN></B> Tuesday, August 15, 2006 =
10:13=20
AM<BR><B><SPAN style=3D"FONT-WEIGHT: bold">To:</SPAN></B> Madjid =
Nakhjiri; Avi=20
Lior; Julien Bournelle<BR><B><SPAN style=3D"FONT-WEIGHT: =
bold">Cc:</SPAN></B>=20
dime@ietf.org<BR><B><SPAN style=3D"FONT-WEIGHT: =
bold">Subject:</SPAN></B> RE:=20
[Dime] MIP6 App ID/ revise RFC =
3588???</SPAN></FONT><o:p></o:p></P></DIV>
<P class=3DMsoNormal><FONT face=3D"Times New Roman" size=3D3><SPAN=20
style=3D"FONT-SIZE: 12pt"><o:p>&nbsp;</o:p></SPAN></FONT></P>
<P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: Arial">I give up, =
why do 3588=20
&amp; 4004 need to be revised?</SPAN></FONT><o:p></o:p></P>
<DIV>
<P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">&nbsp;</SPAN></FONT><o:p></o:p></P></DIV>
<DIV>
<P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">...</SPAN></FONT><o:p></o:p></P></DIV>
<DIV>
<P class=3DMsoNormal><FONT face=3DArial color=3Dnavy size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: navy; FONT-FAMILY: Arial">both RFC 3588 =
and 4004=20
needs to be revised to reflect that, I think the harm for that is =
minimal=20
anyway, given the fairly rare deployment of 4004 (I=20
think).<o:p></o:p></SPAN></FONT></P></DIV>
<P class=3DMsoNormal><FONT face=3DArial color=3Dblue size=3D2><SPAN=20
style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: =
Arial">...</SPAN></FONT><o:p></o:p></P></DIV></BODY></HTML>

------_=_NextPart_001_01C6C096.93A9B90A--


--===============1831861587==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============1831861587==--




From dime-bounces@ietf.org Tue Aug 15 14:57:17 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GD46H-0002pP-Ij; Tue, 15 Aug 2006 14:57:17 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GD46H-0002pK-88
	for dime@ietf.org; Tue, 15 Aug 2006 14:57:17 -0400
Received: from sj-iport-6.cisco.com ([171.71.176.117])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD46F-0007DX-Js
	for dime@ietf.org; Tue, 15 Aug 2006 14:57:17 -0400
Received: from sj-dkim-1.cisco.com ([171.71.179.21])
	by sj-iport-6.cisco.com with ESMTP; 15 Aug 2006 11:57:15 -0700
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254])
	by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id
	k7FIvFHd029022; Tue, 15 Aug 2006 11:57:15 -0700
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com
	[128.107.191.63])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k7FIvElN004344;
	Tue, 15 Aug 2006 11:57:14 -0700 (PDT)
Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by
	xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 15 Aug 2006 11:57:14 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???
Date: Tue, 15 Aug 2006 11:57:13 -0700
Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB26250272B92B@xmb-sjc-215.amer.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Dime] MIP6 App ID/ revise RFC 3588???
Thread-Index: Aca7j5pLlwjYezfqQhS35Ix/bK+xSgCBYw0QALeF6YMAABfC8AAAO289AAQhW/AAAJNTagACZUpAAAE3ESAAAYfxAA==
From: "Glen Zorn \(gwz\)" <gwz@cisco.com>
To: "Avi Lior" <avi@bridgewatersystems.com>,
	"Madjid Nakhjiri" <mnakhjiri@huawei.com>,
	"Julien Bournelle" <julien.bournelle@int-evry.fr>
X-OriginalArrivalTime: 15 Aug 2006 18:57:14.0488 (UTC)
	FILETIME=[9F315780:01C6C09C]
DKIM-Signature: a=rsa-sha1; q=dns; l=7236; t=1155668235; x=1156532235;
	c=relaxed/simple; s=sjdkim1002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=gwz@cisco.com;
	z=From:=22Glen=20Zorn=20\(gwz\)=22=20<gwz@cisco.com>
	|Subject:RE=3A=20[Dime]=20MIP6=20App=20ID/=20revise=20RFC=203588???;
	X=v=3Dcisco.com=3B=20h=3DmakALPxsBX1ceuaKEuxLj9kFg+Y=3D;
	b=XjXum5+CfOURT2nyPDV4MlnvXZVIFAL+FH8/PG/2V7sbkTy8tz72LtLlC4NKQP657fqzh91Z
	WFnwl2QJuF/e7LdVv6hdzCacWm3rknpZ+hbhqToWeHqkCEHVoDAZO/db;
Authentication-Results: sj-dkim-1.cisco.com; header.From=gwz@cisco.com;
	dkim=pass (
	59 extraneous bytes; sig from cisco.com verified; ); 
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 33cc095b503da4365ce57c727e553cf1
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1753844047=="
Errors-To: dime-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1753844047==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C6C09C.9EE723BA"

This is a multi-part message in MIME format.

------_=_NextPart_001_01C6C09C.9EE723BA
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Glen,

Glen Zorn wrote:

"Nonsense, again.  The normative reference for a number is the document =
in which that numbers usage is defined; it must be so since the IANA is =
just a registry containing neither syntactic nor semantic information =
regarding the entries.  In fact the IANA entries for the first 4 =
Diameter app IDs reference RFC 3588."

Doesn't IANA own the numbers?

Second, dont you think that the fact that IANA refences RFC 3588 for =
those numbers (NASREQ and MIPv4) is wrong since RFC3588 does not define =
the syntactic nor semantic information regarding those enteries.=20
=20
Doesn't it define the syntax/semantic of an (any) Application-ID?=20

I am not suggesting that we need to "bis" 3588 because of a new =
application.  I was suggesting that if were were to update 3588 because =
of a new application we should remove those applications ids from 3588 =
so that we dont get into a discussion in the future whereby some newbie =
suggests that we update 3588 to reflect new application ids.=20
=20
Rather than modifying RFCs, I would prefer that the WG Chair(s) refer =
the questioner (newbie or veteran) to the archives & move the discussion =
along.  =20


-----Original Message-----
From: Glen Zorn (gwz) [mailto:gwz@cisco.com <mailto:gwz@cisco.com> ]
Sent: Tue 8/15/2006 1:54 PM
To: Avi Lior; Madjid Nakhjiri; Julien Bournelle
Cc: dime@ietf.org
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???

...

 I think that RFC3588 should not define any application ids.  If it does =
they should be informative.

Nonsense.  Various numbers have been defined in RFCs (with the =
assignment of future numbers left to the IANA) for literally years: =
somehow developers have found the right numbers to use & the Internet =
has survived.  I realize that there is a trend to turn RFCs into =
tutorials for uni freshmen and bellheads but this is getting ridiculous. =
 If you need even more clarity, the IANA entry for Diameter Application =
ID 2 identifies it as representing "Mobile IP v4". =20

So if we are going to change 3588 we should remove any reference to any =
Application IDs.

IANA should be the only authoritative (normative) entity for Application =
IDS.

Nonsense, again.  The normative reference for a number is the document =
in which that numbers usage is defined; it must be so since the IANA is =
just a registry containing neither syntactic nor semantic information =
regarding the entries.  In fact the IANA entries for the first 4 =
Diameter app IDs reference RFC 3588.=20

...



Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by simply =
listening to John Coltrane?
  -- Henry Gabriel




------_=_NextPart_001_01C6C09C.9EE723BA
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>RE: [Dime] MIP6 App ID/ revise RFC 3588???</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2800.1555" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><FONT size=3D2>Glen,<BR><BR>Glen Zorn=20
wrote:<BR><BR>"Nonsense, again.&nbsp; The normative reference for a =
number is=20
the document in which that numbers usage is defined; it must be so since =
the=20
IANA is just a registry containing neither syntactic nor semantic =
information=20
regarding the entries.&nbsp; In fact the IANA entries for the first 4 =
Diameter=20
app IDs reference RFC 3588."<BR><BR>Doesn't IANA own the =
numbers?<BR><BR>Second,=20
dont you think that the fact that IANA refences RFC 3588 for those =
numbers=20
(NASREQ and MIPv4) is wrong since RFC3588 does not define the syntactic =
nor=20
semantic information regarding those enteries.<SPAN=20
class=3D573185218-15082006><FONT face=3DArial=20
color=3D#0000ff>&nbsp;</FONT></SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT size=3D2><SPAN=20
class=3D573185218-15082006></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT size=3D2><SPAN =
class=3D573185218-15082006><FONT=20
face=3DArial color=3D#0000ff>Doesn't it define the syntax/semantic of an =
(any)=20
Application-ID?</FONT>&nbsp;</SPAN><BR><BR>I am not suggesting that we =
need to=20
"bis" 3588 because of a new application.&nbsp; I was suggesting that if =
were=20
were to update 3588 because of a new application we should remove those=20
applications ids from 3588 so that we dont get into a discussion in the =
future=20
whereby some newbie suggests that we update 3588 to reflect new =
application=20
ids.<SPAN class=3D573185218-15082006><FONT face=3DArial=20
color=3D#0000ff>&nbsp;</FONT></SPAN></FONT></DIV>
<DIV dir=3Dltr align=3Dleft><FONT size=3D2><SPAN=20
class=3D573185218-15082006></SPAN></FONT>&nbsp;</DIV>
<DIV dir=3Dltr align=3Dleft><FONT size=3D2><SPAN =
class=3D573185218-15082006><FONT=20
face=3DArial color=3D#0000ff>Rather than modifying RFCs, I would prefer =
that the WG=20
Chair(s) refer the questioner (newbie or veteran) to the archives &amp; =
move the=20
discussion along.&nbsp; </FONT>&nbsp;</SPAN><BR><BR><BR>-----Original=20
Message-----<BR>From: Glen Zorn (gwz) [</FONT><A=20
href=3D"mailto:gwz@cisco.com"><FONT =
size=3D2>mailto:gwz@cisco.com</FONT></A><FONT=20
size=3D2>]<BR>Sent: Tue 8/15/2006 1:54 PM<BR>To: Avi Lior; Madjid =
Nakhjiri; Julien=20
Bournelle<BR>Cc: dime@ietf.org<BR>Subject: RE: [Dime] MIP6 App ID/ =
revise RFC=20
3588???<BR><BR>...<BR><BR>&nbsp;I think that RFC3588 should not define =
any=20
application ids.&nbsp; If it does they should be=20
informative.<BR><BR>Nonsense.&nbsp; Various numbers have been defined in =
RFCs=20
(with the assignment of future numbers left to the IANA) for literally =
years:=20
somehow developers have found the right numbers to use &amp; the =
Internet has=20
survived.&nbsp; I realize that there is a trend to turn RFCs into =
tutorials for=20
uni freshmen and bellheads but this is getting ridiculous.&nbsp; If you =
need=20
even more clarity, the IANA entry for Diameter Application ID 2 =
identifies it as=20
representing "Mobile IP v4".&nbsp;&nbsp;<BR><BR>So if we are going to =
change=20
3588 we should remove any reference to any Application IDs.<BR><BR>IANA =
should=20
be the only authoritative (normative) entity for Application=20
IDS.<BR><BR>Nonsense, again.&nbsp; The normative reference for a number =
is the=20
document in which that numbers usage is defined; it must be so since the =
IANA is=20
just a registry containing neither syntactic nor semantic information =
regarding=20
the entries.&nbsp; In fact the IANA entries for the first 4 Diameter app =
IDs=20
reference RFC 3588.&nbsp;<BR><BR>...<BR><BR><BR><BR>Hope this=20
helps,<BR><BR>~gwz<BR><BR>Why is it that most of the world's problems =
can't be=20
solved by simply listening to John Coltrane?<BR>&nbsp; -- Henry=20
Gabriel<BR><BR><BR></DIV></FONT></BODY></HTML>

------_=_NextPart_001_01C6C09C.9EE723BA--


--===============1753844047==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============1753844047==--




From dime-bounces@ietf.org Tue Aug 15 17:50:34 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GD6nt-00079a-SG; Tue, 15 Aug 2006 17:50:29 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GD6nr-00079C-OY
	for dime@ietf.org; Tue, 15 Aug 2006 17:50:27 -0400
Received: from usaga01-in.huawei.com ([12.129.211.51])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD6nq-0004Xo-E6
	for dime@ietf.org; Tue, 15 Aug 2006 17:50:27 -0400
Received: from huawei.com (usaga01-in [172.18.4.6])
	by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0J4200NQQ76T2H@usaga01-in.huawei.com> for
	dime@ietf.org; Tue, 15 Aug 2006 14:47:18 -0700 (PDT)
Received: from Nakhjiri73701
	(pool-71-112-12-134.sttlwa.dsl-w.verizon.net [71.112.12.134])
	by usaga01-in.huawei.com
	(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
	with ESMTPA id <0J4200FW376KWI@usaga01-in.huawei.com> for dime@ietf.org;
	Tue, 15 Aug 2006 14:47:17 -0700 (PDT)
Date: Tue, 15 Aug 2006 14:50:13 -0700
From: Madjid Nakhjiri <mnakhjiri@huawei.com>
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???
In-reply-to: <E7CCE8A83907104ABEE91AC3AE3709A01167E0@exchange.bridgewatersys.com>
To: 'Avi Lior' <avi@bridgewatersystems.com>,
	"'Glen Zorn (gwz)'" <gwz@cisco.com>,
	'Julien Bournelle' <julien.bournelle@int-evry.fr>
Message-id: <003001c6c0b4$cac915a0$2f01a8c0@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869
X-Mailer: Microsoft Office Outlook 11
Thread-index: Aca7j5pLlwjYezfqQhS35Ix/bK+xSgCBYw0QALeF6YMAABfC8AAAO289AAQhW/AAApAF8AAAUD6QAAC0OyIACDJOYA==
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 28c4c369715777944de1d586eee1c7cb
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0081416032=="
Errors-To: dime-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0081416032==
Content-type: multipart/alternative;
	boundary="Boundary_(ID_Touvfym4OHyr/FlBDz48bw)"

This is a multi-part message in MIME format.

--Boundary_(ID_Touvfym4OHyr/FlBDz48bw)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

OK, let me add my own summary:

 

I am _for_ a new application ID for Mobile IPv6.

 

I did not say update RFC3588 because we add a new application ID, this is
not just a new application, it is a spawn of previously defined application.
Now with that being said, I don't really care where App ID for MIP6 is
posted as long as it is not in USA today!!

It just makes sense to revise 3588 text IF AND ONLY IF 3588 is being
revised.

 

Madjid

  _____  

From: Avi Lior [mailto:avi@bridgewatersystems.com] 
Sent: Tuesday, August 15, 2006 10:57 AM
To: Madjid Nakhjiri; Glen Zorn (gwz); Julien Bournelle
Cc: dime@ietf.org
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???

 

To summarize:

No need to update 3588 or 4004 just because we add a new application with
its own application id.

Madjid wrote:

Ok, seems like everybody agrees on giving MIP6 a new App ID, so I am happy.
If newcomers don't get the App ID list in 3588, that is their problem, I
love working on AAA, there is so much job security.

I dont think that this is strictly a AAA problem. Nor do I think that this
is a problem.  IANA is the authoritative place where ids or assigned numbers
of all sorts are kept.  Hence the name.



-----Original Message-----
From: Madjid Nakhjiri [mailto:mnakhjiri@huawei.com]
Sent: Tue 8/15/2006 1:34 PM
To: 'Glen Zorn (gwz)'; Avi Lior; 'Julien Bournelle'
Cc: dime@ietf.org; 'Madjid Nakhjiri'
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???

Obvious to us, obviously?



Ok, seems like everybody agrees on giving MIP6 a new App ID, so I am happy.
If newcomers don't get the App ID list in 3588, that is their problem, I
love working on AAA, there is so much job security.



________________________________

From: Glen Zorn (gwz) [mailto:gwz@cisco.com]
Sent: Tuesday, August 15, 2006 10:27 AM
To: Madjid Nakhjiri; Avi Lior; Julien Bournelle
Cc: dime@ietf.org
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???



Because RFC 3588 defines a single Application ID for Mobile IP and 3588 is
being revised anyway.

If this was a brand new application, it would not matter, but you already
have one App ID for Mobile IP, that could only be used for MIP4, if you now
define a different App ID for Mip6.



OK, so what?  The app ID defined in 3588 is pretty obviously for MIP v4, the
one defined in 4004 is _specifically_ for MIP v4, & MIP v6 _is_ a brand new
application....



________________________________

From: Avi Lior [mailto:avi@bridgewatersystems.com]
Sent: Tuesday, August 15, 2006 7:25 AM
To: Madjid Nakhjiri; Julien Bournelle
Cc: dime@ietf.org
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???





I don't think RFC3588 needs to be touched when adding an new Application ID.
Neither should

Why do you think you need to touch 3588 or 4004?

-----Original Message-----
From: Madjid Nakhjiri [mailto:mnakhjiri@huawei.com]
Sent: Tue 8/15/2006 10:07 AM
To: Avi Lior; 'Julien Bournelle'
Cc: dime@ietf.org; 'Madjid Nakhjiri'
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???

Hi Avi,



Not sure what "correct" meansJ I am planning on looking a bit closer at 3588
to see exactly how "application" and "App ID" is used.

As I said I _prefer_ adding a new Application ID for Mobile IPv6, but then
both RFC 3588 and 4004 needs to be revised to reflect that, I think the harm
for that is minimal anyway, given the fairly rare deployment of 4004 (I
think).



Madjid.



________________________________

From: Avi Lior [mailto:avi@bridgewatersystems.com]
Sent: Tuesday, August 15, 2006 7:01 AM
To: Madjid Nakhjiri; Julien Bournelle
Cc: dime@ietf.org
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???





How about the correct (IMO) option and that is assign this new application
its own Application ID.  THis afterall is what an Application ID is supposed
to do.



-----Original Message-----
From: Madjid Nakhjiri [mailto:mnakhjiri@huawei.com]
Sent: Fri 8/11/2006 6:49 PM
To: 'Julien Bournelle'
Cc: dime@ietf.org
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???

Hi Julien,

Thanks for pointing me to the archives.
I have one general issue that maybe is related to me not quite understanding
EAP-IKEv2 and that is EAP is run between a peer and an EAP server (in this
case the backend AAA server). EAP-IKEv2 was designed so that a mature
authentication/key management method could be used within EAP framework.
Running EAP-IKEv2 results in authentication of peer to backend AAA, not to
HA and possibly a key between the peer and AAA server. How does this help
the need for IPsec between MN and HA?

Now as far as the discussions on the archives, RFC 4072 only talks about
carrying EAP over Diameter without talking about what EAP is being used for
(your question: mobility versus access service). I think distinguishing
mobility versus access is a AAA signaling issue not an EAP signaling issue.
In RADIUS and MIP4 it is simpler (look at draft-nakhjiri-radius-mip4-02)
because there are attributes related to MIP4 authentication (such as
MIP-MN-AAA-Authenticator, etc) within the Access Request that tells the
server this is about RADIUS. Diameter on the other hand has the notion of
Application ID and should not rely on explicit hint on this. When we got to
the point of trying to translate Diameter messaging to RADIUS, we had to
resort to port types, because Diameter had different messages (depending on
whether HA or FA were involved) while all RADIUS had was Access
Request/Accepts not recognizing between HA and FA.
Here your case is different. Diameter already has an Application ID for
Mobile IP. That is how you distinguish between access and mobility service,
not through service type. Now there are two choices as I said before:

A) revise 3588 to have one App ID for MIPv4 and one for MIPv6 (separate MIP6
split versus integrated through service types). This of course mean revising
4004 to indicate specifically what MIPv4 App ID is.

B) Use the same App ID of 3588 for both MIP4 and MIP6, but then you have to
define 4 service types
1) MIP4 split
2) MIP4 integrated
3) MIP6 split
4) MIP6 integrated.

I prefer A (I can live with B, if you tie a rope to my neck, just kidding).
I think A is cleaner. I think split-integrated versus MIP4-mip6 are two
different degrees of freedom. Just because MIP4 WG did not make the split
integrated distinction, does not mean the business case cannot exist.
Plus that Avi stated that Service type seems to be mandatory.

Madjid

-----Original Message-----
From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr]
Sent: Wednesday, August 09, 2006 1:39 AM
To: Madjid Nakhjiri
Cc: 'Julien Bournelle'; 'Hannes Tschofenig'; dime@ietf.org
Subject: Re: [Dime] MIP6 App ID/ revise RFC 3588???

Hi madjid,

On Tue, Aug 08, 2006 at 04:51:08PM -0700, Madjid Nakhjiri wrote:
> Hi Julien,
>
> I just looked at the RFC 4005 definition of Service_Type.
> The services listed there are quite mixed. I am not quite sure what
> applications besides NASREQ are supposed to support Service_Type? Or is it
> that Mobile IP application assumes NASREQ must be supported?

 Let me try to sum up the issue:

 In the split scenario, the HA acts as a IKEv2 responder and uses EAP
 (oIKEv2) to authenticate the user (of the MN). The HA then relies on a
 EAP/AAA server and thus could use Diameter EAP. THe problem that we
 have here is that we are not performing AAA for "basic" network access
 but for the IPv6 Mobility service. Thus we have the problem of, how the
 AAA server knows that.

 You can take a look at the thread:

 http://www1.ietf.org/mail-archive/web/dime/current/msg00262.html

 for previous discussions on this topic which is still unsolved.

 At this point, as noted in:

 http://www1.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-00.txt

 the 2 options that we have are:

 - define a new Service-Type for "Mobile IPv6 - Split" and puts it in
   DER message (Diameter EAP Request)
 - define a new Application-ID and re-use Diameter EAP messages.

 Hope it helps,

 regards,

 Julien

>
> If one is to go about without modifying RFC 3588 that uses just one App ID
> for Mobile IP, then I guess there is just one choice of having
>
> two Service_types for Mobile IPv6
> and
> one Service_Type for Mobile IPv4,
>
> (3 total for Mobile IP), but then don't you have to modify RFC 4004 to add
> the service_type to Mobile IPv4?
>
> Madjid
>
> -----Original Message-----
> From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr]
> Sent: Monday, August 07, 2006 6:42 AM
> To: Madjid Nakhjiri
> Cc: 'Hannes Tschofenig'; dime@ietf.org
> Subject: Re: [Dime] MIP6 App ID/ was: IETF#66 Meeting Minutes
>
> HI madjid,
>
> On Mon, Aug 07, 2006 at 06:34:55AM -0700, Madjid Nakhjiri wrote:
> > No worries, I was being humorous. I wanted to see what was said during
the
> > meeting regarding the Mobile IP6 drafts. I tried to see the archive
> > discussions, but did not see anything in June or July either.
> > I am seeing all this discussion on the use of App IDs on the ML, so I
> wanted
> > to see if MIP6 is getting its own App ID, or it is using the App ID
> assigned
> > to Mobiloe IP in 3588?
>
>  basically the question is: do we need a specific App ID or do a
>  Service-Type AVP (indicating that it's a HA for the split scenario) is
>  sufficient ?
>
>
>  regards,
>
>  Julien
>
> >
> > R,
> >
> > Madjid
> >
> > -----Original Message-----
> > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
> > Sent: Saturday, August 05, 2006 5:22 AM
> > To: Madjid Nakhjiri
> > Cc: dime@ietf.org
> > Subject: Re: [Dime] IETF#66 Meeting Minutes
> >
> > I agree that the meeting minutes are somewhat brief this time.
> > We will do better with the next IETF meeting...
> >
> > Ciao
> > Hannes
> >
> > Madjid Nakhjiri wrote:
> > > Was this minutes or 10-minutes:-)
> > >
> > > -----Original Message-----
> > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
> > > Sent: Wednesday, July 19, 2006 7:56 AM
> > > To: dime@ietf.org
> > > Subject: [Dime] IETF#66 Meeting Minutes
> > >
> > > Hi all,
> > >
> > > please take a look at the meeting minutes:
> > > http://www3.ietf.org/proceedings/06jul/minutes/dime.txt
> > >
> > > Ciao
> > > Hannes
> > >
> > > _______________________________________________
> > > DiME mailing list
> > > DiME@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/dime
> > >
> > >
> > >
> >
> >
> >
> >
> > _______________________________________________
> > DiME mailing list
> > DiME@ietf.org
> > https://www1.ietf.org/mailman/listinfo/dime
>
> --
> julien.bournelle at int-evry.fr
>
>

--
julien.bournelle at int-evry.fr



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




--Boundary_(ID_Touvfym4OHyr/FlBDz48bw)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:st1="urn:schemas-microsoft-com:office:smarttags" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<title>RE: [Dime] MIP6 App ID/ revise RFC 3588???</title>
<o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags"
 name="country-region"/>
<o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags"
 name="place"/>
<!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
p
	{mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=EN-US link=blue vlink=blue>

<div class=Section1>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>OK, let me add my own summary:<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>I am _<i><span style='font-style:italic'>for</span></i>_
a new application ID for Mobile IPv6.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>I did not say update RFC3588 because we
add a new application ID, this is not just a new application, it is a spawn of
previously defined application. Now with that being said, I don&#8217;t really
care where App ID for MIP6 is posted as long as it is not in <st1:place w:st="on"><st1:country-region
 w:st="on">USA</st1:country-region></st1:place> today!!<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>It just makes sense to revise 3588 text IF
AND ONLY IF 3588 is being revised&#8230;<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Madjid<o:p></o:p></span></font></p>

<div>

<div class=MsoNormal align=center style='text-align:center'><font size=3
face="Times New Roman"><span style='font-size:12.0pt'>

<hr size=3 width="100%" align=center tabindex=-1>

</span></font></div>

<p class=MsoNormal><b><font size=2 face=Tahoma><span style='font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=2
face=Tahoma><span style='font-size:10.0pt;font-family:Tahoma'> Avi Lior
[mailto:avi@bridgewatersystems.com] <br>
<b><span style='font-weight:bold'>Sent:</span></b> Tuesday, August 15, 2006
10:57 AM<br>
<b><span style='font-weight:bold'>To:</span></b> Madjid Nakhjiri; Glen Zorn
(gwz); Julien Bournelle<br>
<b><span style='font-weight:bold'>Cc:</span></b> dime@ietf.org<br>
<b><span style='font-weight:bold'>Subject:</span></b> RE: [Dime] MIP6 App ID/
revise RFC 3588???</span></font><o:p></o:p></p>

</div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p style='margin-bottom:12.0pt'><font size=2 face="Times New Roman"><span
style='font-size:10.0pt'>To summarize:<br>
<br>
No need to update 3588 or 4004 just because we add a new application with its
own application id.<br>
<br>
Madjid wrote:<br>
<br>
Ok, seems like everybody agrees on giving MIP6 a new App ID, so I am happy. If
newcomers don't get the App ID list in 3588, that is their problem, I love
working on AAA, there is so much job security.<br>
<br>
I dont think that this is strictly a AAA problem. Nor do I think that this is a
problem.&nbsp; IANA is the authoritative place where ids or assigned numbers of
all sorts are kept.&nbsp; Hence the name.<br>
<br>
<br>
<br>
-----Original Message-----<br>
From: Madjid Nakhjiri [<a href="mailto:mnakhjiri@huawei.com">mailto:mnakhjiri@huawei.com</a>]<br>
Sent: Tue 8/15/2006 1:34 PM<br>
To: 'Glen Zorn (gwz)'; Avi Lior; 'Julien Bournelle'<br>
Cc: dime@ietf.org; 'Madjid Nakhjiri'<br>
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???<br>
<br>
Obvious to us, obviously?<br>
<br>
<br>
<br>
Ok, seems like everybody agrees on giving MIP6 a new App ID, so I am happy. If
newcomers don't get the App ID list in 3588, that is their problem, I love
working on AAA, there is so much job security.<br>
<br>
<br>
<br>
________________________________<br>
<br>
From: Glen Zorn (gwz) [<a href="mailto:gwz@cisco.com">mailto:gwz@cisco.com</a>]<br>
Sent: Tuesday, August 15, 2006 10:27 AM<br>
To: Madjid Nakhjiri; Avi Lior; Julien Bournelle<br>
Cc: dime@ietf.org<br>
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???<br>
<br>
<br>
<br>
Because RFC 3588 defines a single Application ID for Mobile IP and 3588 is
being revised anyway.<br>
<br>
If this was a brand new application, it would not matter, but you already have
one App ID for Mobile IP, that could only be used for MIP4, if you now define a
different App ID for Mip6.<br>
<br>
<br>
<br>
OK, so what?&nbsp; The app ID defined in 3588 is pretty obviously for MIP v4,
the one defined in 4004 is _specifically_ for MIP v4, &amp; MIP v6 _is_ a brand
new application....<br>
<br>
<br>
<br>
________________________________<br>
<br>
From: Avi Lior [<a href="mailto:avi@bridgewatersystems.com">mailto:avi@bridgewatersystems.com</a>]<br>
Sent: Tuesday, August 15, 2006 7:25 AM<br>
To: Madjid Nakhjiri; Julien Bournelle<br>
Cc: dime@ietf.org<br>
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???<br>
<br>
<br>
<br>
<br>
<br>
I don't think RFC3588 needs to be touched when adding an new Application ID.
Neither should<br>
<br>
Why do you think you need to touch 3588 or 4004?<br>
<br>
-----Original Message-----<br>
From: Madjid Nakhjiri [<a href="mailto:mnakhjiri@huawei.com">mailto:mnakhjiri@huawei.com</a>]<br>
Sent: Tue 8/15/2006 10:07 AM<br>
To: Avi Lior; 'Julien Bournelle'<br>
Cc: dime@ietf.org; 'Madjid Nakhjiri'<br>
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???<br>
<br>
Hi Avi,<br>
<br>
<br>
<br>
Not sure what &quot;correct&quot; meansJ I am planning on looking a bit closer
at 3588 to see exactly how &quot;application&quot; and &quot;App ID&quot; is
used.<br>
<br>
As I said I _prefer_ adding a new Application ID for Mobile IPv6, but then both
RFC 3588 and 4004 needs to be revised to reflect that, I think the harm for
that is minimal anyway, given the fairly rare deployment of 4004 (I think).<br>
<br>
<br>
<br>
Madjid.<br>
<br>
<br>
<br>
________________________________<br>
<br>
From: Avi Lior [<a href="mailto:avi@bridgewatersystems.com">mailto:avi@bridgewatersystems.com</a>]<br>
Sent: Tuesday, August 15, 2006 7:01 AM<br>
To: Madjid Nakhjiri; Julien Bournelle<br>
Cc: dime@ietf.org<br>
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???<br>
<br>
<br>
<br>
<br>
<br>
How about the correct (IMO) option and that is assign this new application its
own Application ID.&nbsp; THis afterall is what an Application ID is supposed
to do.<br>
<br>
<br>
<br>
-----Original Message-----<br>
From: Madjid Nakhjiri [<a href="mailto:mnakhjiri@huawei.com">mailto:mnakhjiri@huawei.com</a>]<br>
Sent: Fri 8/11/2006 6:49 PM<br>
To: 'Julien Bournelle'<br>
Cc: dime@ietf.org<br>
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???<br>
<br>
Hi Julien,<br>
<br>
Thanks for pointing me to the archives.<br>
I have one general issue that maybe is related to me not quite understanding<br>
EAP-IKEv2 and that is EAP is run between a peer and an EAP server (in this<br>
case the backend AAA server). EAP-IKEv2 was designed so that a mature<br>
authentication/key management method could be used within EAP framework.<br>
Running EAP-IKEv2 results in authentication of peer to backend AAA, not to<br>
HA and possibly a key between the peer and AAA server. How does this help<br>
the need for IPsec between MN and HA?<br>
<br>
Now as far as the discussions on the archives, RFC 4072 only talks about<br>
carrying EAP over Diameter without talking about what EAP is being used for<br>
(your question: mobility versus access service). I think distinguishing<br>
mobility versus access is a AAA signaling issue not an EAP signaling issue.<br>
In RADIUS and MIP4 it is simpler (look at draft-nakhjiri-radius-mip4-02)<br>
because there are attributes related to MIP4 authentication (such as<br>
MIP-MN-AAA-Authenticator, etc) within the Access Request that tells the<br>
server this is about RADIUS. Diameter on the other hand has the notion of<br>
Application ID and should not rely on explicit hint on this. When we got to<br>
the point of trying to translate Diameter messaging to RADIUS, we had to<br>
resort to port types, because Diameter had different messages (depending on<br>
whether HA or FA were involved) while all RADIUS had was Access<br>
Request/Accepts not recognizing between HA and FA.<br>
Here your case is different. Diameter already has an Application ID for<br>
Mobile IP. That is how you distinguish between access and mobility service,<br>
not through service type. Now there are two choices as I said before:<br>
<br>
A) revise 3588 to have one App ID for MIPv4 and one for MIPv6 (separate MIP6<br>
split versus integrated through service types). This of course mean revising<br>
4004 to indicate specifically what MIPv4 App ID is.<br>
<br>
B) Use the same App ID of 3588 for both MIP4 and MIP6, but then you have to<br>
define 4 service types<br>
1) MIP4 split<br>
2) MIP4 integrated<br>
3) MIP6 split<br>
4) MIP6 integrated.<br>
<br>
I prefer A (I can live with B, if you tie a rope to my neck, just kidding).<br>
I think A is cleaner. I think split-integrated versus MIP4-mip6 are two<br>
different degrees of freedom. Just because MIP4 WG did not make the split<br>
integrated distinction, does not mean the business case cannot exist.<br>
Plus that Avi stated that Service type seems to be mandatory.<br>
<br>
Madjid<br>
<br>
-----Original Message-----<br>
From: Julien Bournelle [<a href="mailto:julien.bournelle@int-evry.fr">mailto:julien.bournelle@int-evry.fr</a>]<br>
Sent: Wednesday, August 09, 2006 1:39 AM<br>
To: Madjid Nakhjiri<br>
Cc: 'Julien Bournelle'; 'Hannes Tschofenig'; dime@ietf.org<br>
Subject: Re: [Dime] MIP6 App ID/ revise RFC 3588???<br>
<br>
Hi madjid,<br>
<br>
On Tue, Aug 08, 2006 at 04:51:08PM -0700, Madjid Nakhjiri wrote:<br>
&gt; Hi Julien,<br>
&gt;<br>
&gt; I just looked at the RFC 4005 definition of Service_Type.<br>
&gt; The services listed there are quite mixed. I am not quite sure what<br>
&gt; applications besides NASREQ are supposed to support Service_Type? Or is it<br>
&gt; that Mobile IP application assumes NASREQ must be supported?<br>
<br>
&nbsp;Let me try to sum up the issue:<br>
<br>
&nbsp;In the split scenario, the HA acts as a IKEv2 responder and uses EAP<br>
&nbsp;(oIKEv2) to authenticate the user (of the MN). The HA then relies on a<br>
&nbsp;EAP/AAA server and thus could use Diameter EAP. THe problem that we<br>
&nbsp;have here is that we are not performing AAA for &quot;basic&quot; network
access<br>
&nbsp;but for the IPv6 Mobility service. Thus we have the problem of, how the<br>
&nbsp;AAA server knows that.<br>
<br>
&nbsp;You can take a look at the thread:<br>
<br>
&nbsp;<a href="http://www1.ietf.org/mail-archive/web/dime/current/msg00262.html">http://www1.ietf.org/mail-archive/web/dime/current/msg00262.html</a><br>
<br>
&nbsp;for previous discussions on this topic which is still unsolved.<br>
<br>
&nbsp;At this point, as noted in:<br>
<br>
&nbsp;<a
href="http://www1.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-00.txt">http://www1.ietf.org/internet-drafts/draft-ietf-dime-mip6-split-00.txt</a><br>
<br>
&nbsp;the 2 options that we have are:<br>
<br>
&nbsp;- define a new Service-Type for &quot;Mobile IPv6 - Split&quot; and puts
it in<br>
&nbsp;&nbsp; DER message (Diameter EAP Request)<br>
&nbsp;- define a new Application-ID and re-use Diameter EAP messages.<br>
<br>
&nbsp;Hope it helps,<br>
<br>
&nbsp;regards,<br>
<br>
&nbsp;Julien<br>
<br>
&gt;<br>
&gt; If one is to go about without modifying RFC 3588 that uses just one App ID<br>
&gt; for Mobile IP, then I guess there is just one choice of having<br>
&gt;<br>
&gt; two Service_types for Mobile IPv6<br>
&gt; and<br>
&gt; one Service_Type for Mobile IPv4,<br>
&gt;<br>
&gt; (3 total for Mobile IP), but then don't you have to modify RFC 4004 to add<br>
&gt; the service_type to Mobile IPv4?<br>
&gt;<br>
&gt; Madjid<br>
&gt;<br>
&gt; -----Original Message-----<br>
&gt; From: Julien Bournelle [<a href="mailto:julien.bournelle@int-evry.fr">mailto:julien.bournelle@int-evry.fr</a>]<br>
&gt; Sent: Monday, August 07, 2006 6:42 AM<br>
&gt; To: Madjid Nakhjiri<br>
&gt; Cc: 'Hannes Tschofenig'; dime@ietf.org<br>
&gt; Subject: Re: [Dime] MIP6 App ID/ was: IETF#66 Meeting Minutes<br>
&gt;<br>
&gt; HI madjid,<br>
&gt;<br>
&gt; On Mon, Aug 07, 2006 at 06:34:55AM -0700, Madjid Nakhjiri wrote:<br>
&gt; &gt; No worries, I was being humorous. I wanted to see what was said
during<br>
the<br>
&gt; &gt; meeting regarding the Mobile IP6 drafts. I tried to see the archive<br>
&gt; &gt; discussions, but did not see anything in June or July either.<br>
&gt; &gt; I am seeing all this discussion on the use of App IDs on the ML, so I<br>
&gt; wanted<br>
&gt; &gt; to see if MIP6 is getting its own App ID, or it is using the App ID<br>
&gt; assigned<br>
&gt; &gt; to Mobiloe IP in 3588?<br>
&gt;<br>
&gt;&nbsp; basically the question is: do we need a specific App ID or do a<br>
&gt;&nbsp; Service-Type AVP (indicating that it's a HA for the split scenario)
is<br>
&gt;&nbsp; sufficient ?<br>
&gt;<br>
&gt;<br>
&gt;&nbsp; regards,<br>
&gt;<br>
&gt;&nbsp; Julien<br>
&gt;<br>
&gt; &gt;<br>
&gt; &gt; R,<br>
&gt; &gt;<br>
&gt; &gt; Madjid<br>
&gt; &gt;<br>
&gt; &gt; -----Original Message-----<br>
&gt; &gt; From: Hannes Tschofenig [<a href="mailto:Hannes.Tschofenig@gmx.net">mailto:Hannes.Tschofenig@gmx.net</a>]<br>
&gt; &gt; Sent: Saturday, August 05, 2006 5:22 AM<br>
&gt; &gt; To: Madjid Nakhjiri<br>
&gt; &gt; Cc: dime@ietf.org<br>
&gt; &gt; Subject: Re: [Dime] IETF#66 Meeting Minutes<br>
&gt; &gt;<br>
&gt; &gt; I agree that the meeting minutes are somewhat brief this time.<br>
&gt; &gt; We will do better with the next IETF meeting...<br>
&gt; &gt;<br>
&gt; &gt; Ciao<br>
&gt; &gt; Hannes<br>
&gt; &gt;<br>
&gt; &gt; Madjid Nakhjiri wrote:<br>
&gt; &gt; &gt; Was this minutes or 10-minutes:-)<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; -----Original Message-----<br>
&gt; &gt; &gt; From: Hannes Tschofenig [<a
href="mailto:Hannes.Tschofenig@gmx.net">mailto:Hannes.Tschofenig@gmx.net</a>]<br>
&gt; &gt; &gt; Sent: Wednesday, July 19, 2006 7:56 AM<br>
&gt; &gt; &gt; To: dime@ietf.org<br>
&gt; &gt; &gt; Subject: [Dime] IETF#66 Meeting Minutes<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Hi all,<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; please take a look at the meeting minutes:<br>
&gt; &gt; &gt; <a href="http://www3.ietf.org/proceedings/06jul/minutes/dime.txt">http://www3.ietf.org/proceedings/06jul/minutes/dime.txt</a><br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Ciao<br>
&gt; &gt; &gt; Hannes<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; _______________________________________________<br>
&gt; &gt; &gt; DiME mailing list<br>
&gt; &gt; &gt; DiME@ietf.org<br>
&gt; &gt; &gt; <a href="https://www1.ietf.org/mailman/listinfo/dime">https://www1.ietf.org/mailman/listinfo/dime</a><br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; _______________________________________________<br>
&gt; &gt; DiME mailing list<br>
&gt; &gt; DiME@ietf.org<br>
&gt; &gt; <a href="https://www1.ietf.org/mailman/listinfo/dime">https://www1.ietf.org/mailman/listinfo/dime</a><br>
&gt;<br>
&gt; --<br>
&gt; julien.bournelle at int-evry.fr<br>
&gt;<br>
&gt;<br>
<br>
--<br>
julien.bournelle at int-evry.fr<br>
<br>
<br>
<br>
_______________________________________________<br>
DiME mailing list<br>
DiME@ietf.org<br>
<a href="https://www1.ietf.org/mailman/listinfo/dime">https://www1.ietf.org/mailman/listinfo/dime</a><br>
<br>
</span></font><o:p></o:p></p>

</div>

</body>

</html>

--Boundary_(ID_Touvfym4OHyr/FlBDz48bw)--


--===============0081416032==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0081416032==--




From dime-bounces@ietf.org Tue Aug 15 17:58:45 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GD6vt-00008q-P2; Tue, 15 Aug 2006 17:58:45 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GD6vs-00008l-Rv
	for dime@ietf.org; Tue, 15 Aug 2006 17:58:44 -0400
Received: from usaga01-in.huawei.com ([12.129.211.51])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD6vq-0005F1-99
	for dime@ietf.org; Tue, 15 Aug 2006 17:58:44 -0400
Received: from huawei.com (usaga01-in [172.18.4.6])
	by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0J4200NWA7KI2H@usaga01-in.huawei.com> for
	dime@ietf.org; Tue, 15 Aug 2006 14:55:30 -0700 (PDT)
Received: from Nakhjiri73701
	(pool-71-112-12-134.sttlwa.dsl-w.verizon.net [71.112.12.134])
	by usaga01-in.huawei.com
	(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
	with ESMTPA id <0J4200F5S7KDWI@usaga01-in.huawei.com> for dime@ietf.org;
	Tue, 15 Aug 2006 14:55:30 -0700 (PDT)
Date: Tue, 15 Aug 2006 14:58:30 -0700
From: Madjid Nakhjiri <mnakhjiri@huawei.com>
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???
In-reply-to: <4C0FAAC489C8B74F96BEAD85EAEB26250272B8D4@xmb-sjc-215.amer.cisco.com>
To: "'Glen Zorn (gwz)'" <gwz@cisco.com>,
	'Avi Lior' <avi@bridgewatersystems.com>,
	'Julien Bournelle' <julien.bournelle@int-evry.fr>
Message-id: <003801c6c0b5$f26cada0$2f01a8c0@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869
X-Mailer: Microsoft Office Outlook 11
Thread-index: Aca7j5pLlwjYezfqQhS35Ix/bK+xSgCBYw0QALeF6YMAABfC8AAAO289AAQhW/AAAJNTagACZUpAAAkkjGA=
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 10d2fdecab7a7fa796e06e001d026c91
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0298714103=="
Errors-To: dime-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0298714103==
Content-type: multipart/alternative;
	boundary="Boundary_(ID_BM5Q8QN1XycFCB5XZR+HHg)"

This is a multi-part message in MIME format.

--Boundary_(ID_BM5Q8QN1XycFCB5XZR+HHg)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

I agree with Glen, it does not make sense to have numberless RFCs. We can
always have some numbers defined later after the RFC is published (just as
it is the case for MIP6 and 3588) but if the numbers are known at the time
of publishing RFCs, there is no reason to go look for it somewhere else.

 

That being said, thanks Glen for bringing up the IANA link. I checked and it
does say "Mobile IPv4", so I am ok now.

 

R,

 

Madjid

 

  _____  

From: Glen Zorn (gwz) [mailto:gwz@cisco.com] 
Sent: Tuesday, August 15, 2006 10:55 AM
To: Avi Lior; Madjid Nakhjiri; Julien Bournelle
Cc: dime@ietf.org
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???

 

...

 

 I think that RFC3588 should not define any application ids.  If it does
they should be informative. 

 

Nonsense.  Various numbers have been defined in RFCs (with the assignment of
future numbers left to the IANA) for literally years: somehow developers
have found the right numbers to use & the Internet has survived.  I realize
that there is a trend to turn RFCs into tutorials for uni freshmen and
bellheads but this is getting ridiculous.  If you need even more clarity,
the IANA entry for Diameter Application ID 2 identifies it as representing
"Mobile IP v4".   

So if we are going to change 3588 we should remove any reference to any
Application IDs. 


IANA should be the only authoritative (normative) entity for Application
IDS. 

 

Nonsense, again.  The normative reference for a number is the document in
which that numbers usage is defined; it must be so since the IANA is just a
registry containing neither syntactic nor semantic information regarding the
entries.  In fact the IANA entries for the first 4 Diameter app IDs
reference RFC 3588.  

 

... 



Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by simply
listening to John Coltrane?
  -- Henry Gabriel 


--Boundary_(ID_BM5Q8QN1XycFCB5XZR+HHg)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<title>RE: [Dime] MIP6 App ID/ revise RFC 3588???</title>
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p
	{mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:0in;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=EN-US link=blue vlink=purple>

<div class=Section1>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>I agree with Glen, it does not make sense
to have numberless RFCs. We can always have some numbers defined later after
the RFC is published (just as it is the case for MIP6 and 3588) but if the
numbers are known at the time of publishing RFCs, there is no reason to go look
for it somewhere else.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>That being said, thanks Glen for bringing
up the IANA link. I checked and it does say &#8220;Mobile IPv4&#8221;, so I am
ok now.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>R,<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Madjid<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div class=MsoNormal align=center style='text-align:center'><font size=3
face="Times New Roman"><span style='font-size:12.0pt'>

<hr size=3 width="100%" align=center tabindex=-1>

</span></font></div>

<p class=MsoNormal><b><font size=2 face=Tahoma><span style='font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=2
face=Tahoma><span style='font-size:10.0pt;font-family:Tahoma'> Glen Zorn (gwz)
[mailto:gwz@cisco.com] <br>
<b><span style='font-weight:bold'>Sent:</span></b> Tuesday, August 15, 2006
10:55 AM<br>
<b><span style='font-weight:bold'>To:</span></b> Avi Lior; Madjid Nakhjiri;
Julien Bournelle<br>
<b><span style='font-weight:bold'>Cc:</span></b> dime@ietf.org<br>
<b><span style='font-weight:bold'>Subject:</span></b> RE: [Dime] MIP6 App ID/
revise RFC 3588???</span></font><o:p></o:p></p>

</div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=blue face="Times New Roman"><span
style='font-size:10.0pt;color:blue'>...</span></font><o:p></o:p></p>

<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'>&nbsp;</span></font><o:p></o:p></p>

<p class=MsoNormal><font size=2 face="Times New Roman"><span style='font-size:
10.0pt'>&nbsp;I think that RFC3588 should not define any application ids.&nbsp;
If it does they should be informative.</span></font><font size=2 color=blue
face=Arial><span style='font-size:10.0pt;font-family:Arial;color:blue'>&nbsp;</span></font><o:p></o:p></p>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'>Nonsense.&nbsp; Various numbers have been
defined in RFCs (with&nbsp;the assignment of future numbers left to&nbsp;the
IANA) for&nbsp;literally years: somehow developers have found the right numbers
to use &amp;&nbsp;the Internet has survived.&nbsp; I realize that&nbsp;there is
a trend to turn RFCs into tutorials for uni freshmen and bellheads but this is
getting ridiculous.&nbsp; If you need even more clarity, the IANA entry for
Diameter Application ID 2 identifies it as representing &quot;Mobile IP
v4&quot;.&nbsp;&nbsp;</span></font><font size=2 color=black><span
style='font-size:10.0pt;color:black'>&nbsp;</span></font><font size=2
color=blue face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:blue'><br>
</span></font><font size=2><span style='font-size:10.0pt'><br>
So if we are going to change 3588 we should remove any reference to any
Application IDs.</span></font><font size=2 color=blue face=Arial><span
style='font-size:10.0pt;font-family:Arial;color:blue'>&nbsp;</span></font><o:p></o:p></p>

<p class=MsoNormal><font size=2 face="Times New Roman"><span style='font-size:
10.0pt'><br>
IANA should be the only authoritative (normative) entity for Application IDS.</span></font><font
size=2 color=blue face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:blue'>&nbsp;</span></font><o:p></o:p></p>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'>Nonsense, again.&nbsp; The normative
reference for a number is the document in which that numbers usage is defined;
it must be so since the IANA is just a registry containing neither syntactic
nor semantic information regarding the entries.&nbsp; In fact the IANA entries
for the first 4 Diameter app IDs&nbsp;reference RFC 3588.&nbsp;&nbsp;</span></font><o:p></o:p></p>

<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'>&nbsp;</span></font><o:p></o:p></p>

<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'>...</span></font><font size=2><span
style='font-size:10.0pt'>&nbsp;<br>
<br>
</span></font><o:p></o:p></p>

<!-- Converted from text/plain format -->

<p><font size=2 color=blue face="Times New Roman"><span style='font-size:10.0pt;
color:blue'>Hope this helps,<br>
<br>
~gwz<br>
<br>
Why is it that most of the world's problems can't be solved by simply listening
to John Coltrane?<br>
&nbsp; -- Henry Gabriel</span></font><font color=blue><span style='color:blue'>
</span></font><o:p></o:p></p>

</div>

</body>

</html>

--Boundary_(ID_BM5Q8QN1XycFCB5XZR+HHg)--


--===============0298714103==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0298714103==--




From dime-bounces@ietf.org Tue Aug 15 19:45:26 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GD8b6-0002Kx-Fp; Tue, 15 Aug 2006 19:45:24 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GD8b4-0002Ks-Kb
	for dime@ietf.org; Tue, 15 Aug 2006 19:45:22 -0400
Received: from usaga01-in.huawei.com ([12.129.211.51])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GD8b4-0007vL-3S
	for dime@ietf.org; Tue, 15 Aug 2006 19:45:22 -0400
Received: from huawei.com (usaga01-in [172.18.4.6])
	by usaga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0J4200N9XCIE2H@usaga01-in.huawei.com> for
	dime@ietf.org; Tue, 15 Aug 2006 16:42:14 -0700 (PDT)
Received: from Nakhjiri73701
	(pool-71-112-12-134.sttlwa.dsl-w.verizon.net [71.112.12.134])
	by usaga01-in.huawei.com
	(iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar  3 2004))
	with ESMTPA id <0J4200FOOCI8UD@usaga01-in.huawei.com> for dime@ietf.org;
	Tue, 15 Aug 2006 16:42:14 -0700 (PDT)
Date: Tue, 15 Aug 2006 16:45:12 -0700
From: Madjid Nakhjiri <mnakhjiri@huawei.com>
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???
In-reply-to: <4C0FAAC489C8B74F96BEAD85EAEB26250272B92B@xmb-sjc-215.amer.cisco.com>
To: "'Glen Zorn (gwz)'" <gwz@cisco.com>,
	'Avi Lior' <avi@bridgewatersystems.com>,
	'Julien Bournelle' <julien.bournelle@int-evry.fr>
Message-id: <004d01c6c0c4$dae8f120$2f01a8c0@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2869
X-Mailer: Microsoft Office Outlook 11
Thread-index: Aca7j5pLlwjYezfqQhS35Ix/bK+xSgCBYw0QALeF6YMAABfC8AAAO289AAQhW/AAAJNTagACZUpAAAE3ESAAAYfxAAAKJUIg
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e16ce0269ccb2f59707d16700199d13b
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1050915360=="
Errors-To: dime-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1050915360==
Content-type: multipart/alternative;
	boundary="Boundary_(ID_ocl/trgxuIf10Uvh1fkz9g)"

This is a multi-part message in MIME format.

--Boundary_(ID_ocl/trgxuIf10Uvh1fkz9g)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT

Hi Glen

 

The discussion was whether we use App ID or Service_Type for MIP6 and I
think the current thread at least shows people want App ID.

 

Madjid

 

  _____  

From: Glen Zorn (gwz) [mailto:gwz@cisco.com] 
Sent: Tuesday, August 15, 2006 11:57 AM
To: Avi Lior; Madjid Nakhjiri; Julien Bournelle
Cc: dime@ietf.org
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???

 

Glen,

Glen Zorn wrote:

"Nonsense, again.  The normative reference for a number is the document in
which that numbers usage is defined; it must be so since the IANA is just a
registry containing neither syntactic nor semantic information regarding the
entries.  In fact the IANA entries for the first 4 Diameter app IDs
reference RFC 3588."

Doesn't IANA own the numbers?

Second, dont you think that the fact that IANA refences RFC 3588 for those
numbers (NASREQ and MIPv4) is wrong since RFC3588 does not define the
syntactic nor semantic information regarding those enteries. 

 

Doesn't it define the syntax/semantic of an (any) Application-ID? 

I am not suggesting that we need to "bis" 3588 because of a new application.
I was suggesting that if were were to update 3588 because of a new
application we should remove those applications ids from 3588 so that we
dont get into a discussion in the future whereby some newbie suggests that
we update 3588 to reflect new application ids. 

 

Rather than modifying RFCs, I would prefer that the WG Chair(s) refer the
questioner (newbie or veteran) to the archives & move the discussion along.



-----Original Message-----
From: Glen Zorn (gwz) [ <mailto:gwz@cisco.com> mailto:gwz@cisco.com]
Sent: Tue 8/15/2006 1:54 PM
To: Avi Lior; Madjid Nakhjiri; Julien Bournelle
Cc: dime@ietf.org
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???

...

 I think that RFC3588 should not define any application ids.  If it does
they should be informative.

Nonsense.  Various numbers have been defined in RFCs (with the assignment of
future numbers left to the IANA) for literally years: somehow developers
have found the right numbers to use & the Internet has survived.  I realize
that there is a trend to turn RFCs into tutorials for uni freshmen and
bellheads but this is getting ridiculous.  If you need even more clarity,
the IANA entry for Diameter Application ID 2 identifies it as representing
"Mobile IP v4".  

So if we are going to change 3588 we should remove any reference to any
Application IDs.

IANA should be the only authoritative (normative) entity for Application
IDS.

Nonsense, again.  The normative reference for a number is the document in
which that numbers usage is defined; it must be so since the IANA is just a
registry containing neither syntactic nor semantic information regarding the
entries.  In fact the IANA entries for the first 4 Diameter app IDs
reference RFC 3588. 

...



Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by simply
listening to John Coltrane?
  -- Henry Gabriel




--Boundary_(ID_ocl/trgxuIf10Uvh1fkz9g)
Content-type: text/html; charset=us-ascii
Content-transfer-encoding: 7BIT

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]-->
<title>RE: [Dime] MIP6 App ID/ revise RFC 3588???</title>
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:SimSun;
	panose-1:2 1 6 0 3 1 1 1 1 1;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:Arial;
	color:navy;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=EN-US link=blue vlink=blue>

<div class=Section1>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Hi Glen<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>The discussion was whether we use App ID
or Service_Type for MIP6 and I think the current thread at least shows people
want App ID.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Madjid<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'><o:p>&nbsp;</o:p></span></font></p>

<div>

<div class=MsoNormal align=center style='text-align:center'><font size=3
face="Times New Roman"><span style='font-size:12.0pt'>

<hr size=3 width="100%" align=center tabindex=-1>

</span></font></div>

<p class=MsoNormal><b><font size=2 face=Tahoma><span style='font-size:10.0pt;
font-family:Tahoma;font-weight:bold'>From:</span></font></b><font size=2
face=Tahoma><span style='font-size:10.0pt;font-family:Tahoma'> Glen Zorn (gwz)
[mailto:gwz@cisco.com] <br>
<b><span style='font-weight:bold'>Sent:</span></b> Tuesday, August 15, 2006
11:57 AM<br>
<b><span style='font-weight:bold'>To:</span></b> Avi Lior; Madjid Nakhjiri;
Julien Bournelle<br>
<b><span style='font-weight:bold'>Cc:</span></b> dime@ietf.org<br>
<b><span style='font-weight:bold'>Subject:</span></b> RE: [Dime] MIP6 App ID/
revise RFC 3588???</span></font><o:p></o:p></p>

</div>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 face="Times New Roman"><span style='font-size:
10.0pt'>Glen,<br>
<br>
Glen Zorn wrote:<br>
<br>
&quot;Nonsense, again.&nbsp; The normative reference for a number is the
document in which that numbers usage is defined; it must be so since the IANA
is just a registry containing neither syntactic nor semantic information
regarding the entries.&nbsp; In fact the IANA entries for the first 4 Diameter
app IDs reference RFC 3588.&quot;<br>
<br>
Doesn't IANA own the numbers?<br>
<br>
Second, dont you think that the fact that IANA refences RFC 3588 for those
numbers (NASREQ and MIPv4) is wrong since RFC3588 does not define the syntactic
nor semantic information regarding those enteries.</span></font><font size=2
color=blue face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:blue'>&nbsp;</span></font><o:p></o:p></p>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 color=blue face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:blue'>Doesn't it define the syntax/semantic of
an (any) Application-ID?</span></font><font size=2><span style='font-size:10.0pt'>&nbsp;<br>
<br>
I am not suggesting that we need to &quot;bis&quot; 3588 because of a new
application.&nbsp; I was suggesting that if were were to update 3588 because of
a new application we should remove those applications ids from 3588 so that we
dont get into a discussion in the future whereby some newbie suggests that we
update 3588 to reflect new application ids.</span></font><font size=2
color=blue face=Arial><span style='font-size:10.0pt;font-family:Arial;
color:blue'>&nbsp;</span></font><o:p></o:p></p>

<p class=MsoNormal><font size=3 face="Times New Roman"><span style='font-size:
12.0pt'>&nbsp;<o:p></o:p></span></font></p>

<p class=MsoNormal style='margin-bottom:12.0pt'><font size=2 color=blue
face=Arial><span style='font-size:10.0pt;font-family:Arial;color:blue'>Rather
than modifying RFCs, I would prefer that the WG Chair(s) refer the questioner
(newbie or veteran) to the archives &amp; move the discussion along.&nbsp; </span></font><font
size=2><span style='font-size:10.0pt'>&nbsp;<br>
<br>
<br>
-----Original Message-----<br>
From: Glen Zorn (gwz) [</span></font><a href="mailto:gwz@cisco.com"><font
size=2><span style='font-size:10.0pt'>mailto:gwz@cisco.com</span></font></a><font
size=2><span style='font-size:10.0pt'>]<br>
Sent: Tue 8/15/2006 1:54 PM<br>
To: Avi Lior; Madjid Nakhjiri; Julien Bournelle<br>
Cc: dime@ietf.org<br>
Subject: RE: [Dime] MIP6 App ID/ revise RFC 3588???<br>
<br>
...<br>
<br>
&nbsp;I think that RFC3588 should not define any application ids.&nbsp; If it
does they should be informative.<br>
<br>
Nonsense.&nbsp; Various numbers have been defined in RFCs (with the assignment
of future numbers left to the IANA) for literally years: somehow developers
have found the right numbers to use &amp; the Internet has survived.&nbsp; I
realize that there is a trend to turn RFCs into tutorials for uni freshmen and
bellheads but this is getting ridiculous.&nbsp; If you need even more clarity,
the IANA entry for Diameter Application ID 2 identifies it as representing
&quot;Mobile IP v4&quot;.&nbsp;&nbsp;<br>
<br>
So if we are going to change 3588 we should remove any reference to any
Application IDs.<br>
<br>
IANA should be the only authoritative (normative) entity for Application IDS.<br>
<br>
Nonsense, again.&nbsp; The normative reference for a number is the document in
which that numbers usage is defined; it must be so since the IANA is just a
registry containing neither syntactic nor semantic information regarding the
entries.&nbsp; In fact the IANA entries for the first 4 Diameter app IDs
reference RFC 3588.&nbsp;<br>
<br>
...<br>
<br>
<br>
<br>
Hope this helps,<br>
<br>
~gwz<br>
<br>
Why is it that most of the world's problems can't be solved by simply listening
to John Coltrane?<br>
&nbsp; -- Henry Gabriel<br>
<br>
<o:p></o:p></span></font></p>

</div>

</body>

</html>

--Boundary_(ID_ocl/trgxuIf10Uvh1fkz9g)--


--===============1050915360==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============1050915360==--




From dime-bounces@ietf.org Wed Aug 16 16:13:57 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GDRlk-0000YI-P6; Wed, 16 Aug 2006 16:13:40 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GDRlk-0000Xx-3g
	for dime@ietf.org; Wed, 16 Aug 2006 16:13:40 -0400
Received: from mail.gmx.net ([213.165.64.20])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GDRlf-00071X-LR
	for dime@ietf.org; Wed, 16 Aug 2006 16:13:40 -0400
Received: (qmail invoked by alias); 16 Aug 2006 20:13:33 -0000
Received: from p549873DF.dip.t-dialin.net (EHLO [192.168.2.33])
	[84.152.115.223]
	by mail.gmx.net (mp040) with SMTP; 16 Aug 2006 22:13:33 +0200
X-Authenticated: #29516787
Message-ID: <44E37C6D.1080703@gmx.net>
Date: Wed, 16 Aug 2006 22:13:33 +0200
From: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: dime@ietf.org
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c
Subject: [Dime] DIME Working Group Status
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

Hi all,

here is a short working group status:

* Diameter Base Revision

We have an issue tracker setup that lists a bunch of open issues:
http://www.tschofenig.priv.at:8080/diameter-interop/index

We had a many discussions on the mailing list.

I have converted the draft to XML so that we can actually start 
compiling new draft snapshots.

Unfortunately, we do not yet have specific text proposals.

* Diameter Interop

As mentioned at the IETF#66 DIME working group meeting there was 
interest to have another Diameter Interop event. See also Slide 9 at
http://www3.ietf.org/proceedings/06jul/slides/dime-2/sld1.htm

Please drop us a mail if you are interested to participate to simplify 
planning!

* Diameter URI

--> See separate mail.

* The Diameter API

We basically stalled.

--> See separate mail.

* Mobile IPv6 Bootstrapping  (Split Scenario & Integrated Scenario)

Progress is blocked due to the unfinished "Application ID" vs. 
"NAS-Port-Type AVP/Service-Type" discussion.

We hope that the authors of 
http://www.ietf.org/internet-drafts/draft-ietf-mip6-aaa-ha-goals-02.txt
compile a draft update that can serve as input to the ongoing work 
(since there are other technical aspects that need to be addressed).

--> See separate mail.

* draft-tsou-dime-base-routing-ext-00

--> See separate mail.

* draft-bodin-dime-auditing-reqs-00.txt

--> See separate mail.

* Diameter QoS

A small group consisting of Avri Doria, Glen Zorn, Pete McCann, Tina 
Tsou and myself are working on an updated version of the document. We 
plan to have something ready for the group by end of September.

In summary, I think we need to work a bit harder and more focused to 
make better progress.

Ciao
Hannes & John

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



From dime-bounces@ietf.org Wed Aug 16 16:13:57 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GDRln-0000Yx-VS; Wed, 16 Aug 2006 16:13:43 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GDRlm-0000Yd-Gz
	for dime@ietf.org; Wed, 16 Aug 2006 16:13:42 -0400
Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GDRll-00072E-4c
	for dime@ietf.org; Wed, 16 Aug 2006 16:13:42 -0400
Received: (qmail invoked by alias); 16 Aug 2006 20:13:40 -0000
Received: from p549873DF.dip.t-dialin.net (EHLO [192.168.2.33])
	[84.152.115.223]
	by mail.gmx.net (mp043) with SMTP; 16 Aug 2006 22:13:40 +0200
X-Authenticated: #29516787
Message-ID: <44E37C74.4060006@gmx.net>
Date: Wed, 16 Aug 2006 22:13:40 +0200
From: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: avri@acm.org,  Ulf.Bodin@operax.com
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c
Cc: dime@ietf.org
Subject: [Dime] Next Steps for draft-bodin-dime-auditing-reqs-00.txt
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

Hi Avri,
Hi Ulf,

during the DIME working group meeting at IETF#66 a number of folks 
showed interest in your work. It was, however, also noted that the draft 
requires a bit more details.

Do you plan to update the draft? When do you plan to submit the draft? 
Do you need help with the draft editing (I bet there are some DIME 
working group members willing to help.)?
Is there interest from ETSI TISPAN and the ITU-T on this subject?

Ciao
Hannes & John


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



From dime-bounces@ietf.org Wed Aug 16 16:15:24 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GDRnQ-0000qJ-6X; Wed, 16 Aug 2006 16:15:24 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GDRnP-0000pr-48
	for dime@ietf.org; Wed, 16 Aug 2006 16:15:23 -0400
Received: from mail.gmx.net ([213.165.64.20])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GDRnN-0007Hn-SY
	for dime@ietf.org; Wed, 16 Aug 2006 16:15:23 -0400
Received: (qmail invoked by alias); 16 Aug 2006 20:15:20 -0000
Received: from p549873DF.dip.t-dialin.net (EHLO [192.168.2.33])
	[84.152.115.223]
	by mail.gmx.net (mp029) with SMTP; 16 Aug 2006 22:15:20 +0200
X-Authenticated: #29516787
Message-ID: <44E37CD7.4000601@gmx.net>
Date: Wed, 16 Aug 2006 22:15:19 +0200
From: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: Tina TSOU <tena@huawei.com>, 
 Victor Fajardo <vfajardo@tari.toshiba.com>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014
Cc: dime@ietf.org
Subject: [Dime] Next Steps for draft-tsou-dime-base-routing-ext-00
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

Hi all,

we discussed this document during the IETF#66 DIME working group 
meeting. The meeting participants did not express excitement. We would 
like to solicit feedback from the working group to see whether there is 
interest in this work and how we should proceed.

Ciao
Hannes & John

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



From dime-bounces@ietf.org Wed Aug 16 16:16:00 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GDRo0-0000yo-3u; Wed, 16 Aug 2006 16:16:00 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GDRny-0000yh-SV
	for dime@ietf.org; Wed, 16 Aug 2006 16:15:58 -0400
Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GDRnx-0007Ke-Ew
	for dime@ietf.org; Wed, 16 Aug 2006 16:15:58 -0400
Received: (qmail invoked by alias); 16 Aug 2006 20:15:55 -0000
Received: from p549873DF.dip.t-dialin.net (EHLO [192.168.2.33])
	[84.152.115.223]
	by mail.gmx.net (mp036) with SMTP; 16 Aug 2006 22:15:55 +0200
X-Authenticated: #29516787
Message-ID: <44E37CF9.2040409@gmx.net>
Date: Wed, 16 Aug 2006 22:15:53 +0200
From: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: pcalhoun@airespace.com,  dave@frascone.com, 
 kempf@docomolabs-usa.com
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Cc: dime@ietf.org
Subject: [Dime] Next Steps for draft-ietf-dime-diameter-api-00.txt
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

Hi all,

our DIME working group charter webpage indicates that the
http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-api-00.txt
should be finished already:

     Mar 2006 Submit Diameter API to IESG as an information RFC

Question to the authors: Are you done with the document?

Question to the working group: Are you happy with the document? If not, 
what needs to be changed?

Ciao
Hannes & John

PS: I know that we had a discussion about this document already a few 
months ago. It hasn't pushed the work forward.

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



From dime-bounces@ietf.org Wed Aug 16 16:16:12 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GDRoC-00012u-A3; Wed, 16 Aug 2006 16:16:12 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GDRoB-00012k-Jz
	for dime@ietf.org; Wed, 16 Aug 2006 16:16:11 -0400
Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GDRo9-0007NE-5k
	for dime@ietf.org; Wed, 16 Aug 2006 16:16:11 -0400
Received: (qmail invoked by alias); 16 Aug 2006 20:16:08 -0000
Received: from p549873DF.dip.t-dialin.net (EHLO [192.168.2.33])
	[84.152.115.223]
	by mail.gmx.net (mp036) with SMTP; 16 Aug 2006 22:16:08 +0200
X-Authenticated: #29516787
Message-ID: <44E37D07.107@gmx.net>
Date: Wed, 16 Aug 2006 22:16:07 +0200
From: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: miguel.an.garcia@nokia.com
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a
Cc: dime@ietf.org
Subject: [Dime] Next Steps for draft-garcia-dime-aaa-uri-00.txt
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

Hi all,

Miguel discovered a bug in RFC 3588 regarding the definition of the 
"aaa" and "aaas" scheme. His presentation at the IETF#66 DIME working 
group meeting showed that we have several options. There was no clear 
conclusion and we agreed to move the discussion to the list.

Please find the draft at:
http://tools.ietf.org/wg/dime/draft-garcia-dime-aaa-uri-00.txt

Slide 5 of http://www3.ietf.org/proceedings/06jul/slides/dime-9/sld1.htm 
defines possible next steps:

* We don’t care, so we do nothing
* We fix the IANA the AAA/AAAS URI scheme in a backwards compatible way, 
and we register with IANA.
* We register with IANA the AAA/AAAS URI scheme (with no changes towards 
RFC 3588) and work in a definition of a ‘diameter’ URI scheme that need 
not necessarily be backwards compatible with the AAA URI scheme.
* We register with IANA the AAA/AAAS URI scheme (with no changes towards 
RFC 3588).

Please state your opinion. Please let us also know if you have no clue 
what the stuff is about.

Ciao
Hannes & John

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



From dime-bounces@ietf.org Wed Aug 16 16:56:00 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GDSQi-0007uT-0i; Wed, 16 Aug 2006 16:56:00 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GDSQg-0007m9-OL
	for dime@ietf.org; Wed, 16 Aug 2006 16:55:58 -0400
Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GDSM1-0002xd-MN
	for dime@ietf.org; Wed, 16 Aug 2006 16:51:10 -0400
Received: (qmail invoked by alias); 16 Aug 2006 20:51:08 -0000
Received: from p549873DF.dip.t-dialin.net (EHLO [192.168.2.33])
	[84.152.115.223]
	by mail.gmx.net (mp034) with SMTP; 16 Aug 2006 22:51:08 +0200
X-Authenticated: #29516787
Message-ID: <44E3853B.2090406@gmx.net>
Date: Wed, 16 Aug 2006 22:51:07 +0200
From: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: dime@ietf.org
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
X-Spam-Score: 0.1 (/)
X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b
Subject: [Dime] Mobile IPv6 Bootstrapping - "Application ID" vs.
 "NAS-Port-Type AVP/Service-Type": Summary
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

Hi all,

I went through the discussion again and noticed that we haven't reached 
a conclusion.

Here is my impression:

* RFC 3588 leaves a question regarding the extensibility open.
   This needs to be captured in the revision of the base specification.

* The main issue seems to be

   - Do we want to route 'Diameter EAP' message and 'Diameter Mobile 
IPv6 Bootstrapping' messages differently?

     If we want to route them differently then we need to define 
'Diameter MIPv6 Bootstrapping' as a Diameter application.

   - The AAA server differentiates ordinary network access and MIPv6 
bootstrapping functionality (with respect to authorization and 
accounting). In order to do so it must understand the Service-Type 
and/or NAS-Port-Type AVPs and the defined values.

     Is this a problem?

   - There are problems with proxies and newly defined Diameter 
Application IDs. Every
proxy on the path needs new code to handle the new application, while
just adding an extra AVP or new Service-Type value does not hurt.

     Is this an issue for us?

Ciao
Hannes

PS: Here is copy-and-paste version of some discussion snippets to allow 
others to catch-up.

Julien starts the discussion with a question about Application IDs.

Pasi suggests to consider Service-Type and/or NAS-Port-Type AVPs as 
well.... the problem starts.

Avi states that the problem is that neither Service-Type or Port-Type is 
mandatory.
"
Service Type seems to be the correct way but in RADIUS and
Diameter service-type also can be authenticate-only or authorize-only.
So what if the HA wanted to authenticate-only or authorize-only for the
MIP service?  I would lose the ability to also indicate that this is an
HA.

So Port-Type seems to be the way to go....
"

Jari jumps in:
"
One of the reasons why an existing application would
be preferred is that then a AAA server that does not
care about the type of service can be used without
changes. Yet servers that do care can look at the
AVPs and make more detailed authorization
decisions.


RFC 3588 states that  "Creation of a new application
should be viewed as a last resort." and that "In order
to justify allocation of a new application identifier,
Diameter applications MUST define one Command Code,
or add new mandatory AVPs to the ABNF." Note that
mandatory AVPs can be viewed in different ways,
and that we should not be too strict about them.
For instance, Framed-Protocol is an optional AVP in
RFCs 4005 and 4072. Yet, you could argue that if you
are doing PPP then you need to use this attribute and
set it to PPP. But that didn't make the attribute mandatory.
Do we have a similar situation for the IKEv2/MIPv6
attributes and values? They are not necessary from
the NASREQ/EAP perspective, but in the specific context
you need to use the attributes. In my mind, this does not
make the attributes mandatory from a Diameter
application point of view. If we start creating
new applications for every different situation,
we'll have lots of applications and interoperability
problems. Its better to add new optional AVPs and
describe in text when they should be used. The
only exception that I see is security related AVPs
that must be understood by the other side or else
the session should be terminated.
"

Avi responds:
"
Mandatory does not mean required in the Command.  It means that it must
be understood by the receiver.  We need to clarify that.
"

Gerardo and Lionel agree with Jari.



Avi writes:
"
If I have two EAP based application in my network, one that is
handling pure EAP application, the other is extended to handle the new
behavior then I need a way to route the (same) command correctly.
"

Jari writes:
"
Ah, but that is a new requirement. If you believe that you need
to route EAP authentication from a 802.11 AP differently
than from IKEv2/MIPv6, then you need one of these:

- Use different user/domain names for the users of
   the different services.

- Point to different servers from the AP and SGW (but
   this works less well if you have proxies and roaming).

- New application ID.

- Some weird form of Diameter and RADIUS source routing
   based on what type of node sent the message.

However, it is far from clear to me why you would really
need to route the authentication differently *for the same
user*. Many authentication mechanisms can also have state,
which would imply that at the end they need to end up in
the same device anyhow. Can you expand on why you need
to handle the same users in different authentication
servers?
"

Avi to Jari:

"
BTW in the context of the original question raised, the attribute(s)
will not be optional. Here is the snippet:

 >> >>  In our case, the AAA server must perform AAA functionality for the
 >> >> Mobile IPv6 service. The AAA server must know that it has to
 >> >> authorize the mip6 service and the accounting (ASR/ASA) is also for
 >> >>  mip6 and not for network access.

If the Diameter message comes from the HA then the HA MUST include the
NAS-Port-type attribute. So the command ABNF is being changed. Also the
behavior is being changed of the Server.  It MUST recognize the (new)
value of the NAS-Port-Type.
"


Yoshi says:
"
If what is important is service-specific routing (I am not convinced
with it yet), I'd suggest defining a new authorization-only
application used only for carrying service-specific attributes
(analogous to NASREQ usage in RFC 4072).  The downside is that it
needs another message roundtrip than carrying the attributes in
DER/DEA.
"


Julien wrote:
"
 > >
 > > I don't think it's clean to require use of different
 > > users'identifiers in order to distinguish which services is
 > > provided. For me, it looks like a 'hack'.
" and Pasi responded:
"
I fully agree -- but having separate user identifiers should not be
necessary. If, for example, an operator wants to perform different
authorizations for WiFi and WiMAX (e.g., some users can access only
WiFi but not WiMAX), that's simple to do: just check Service-Type,
NAS-Port-Type, and other relevant authorization AVPs.  There's
absolutely no need to create a new Diameter application.

If the AAA server is really strict about WiFi vs. WiMAX separation, it
can have a policy that requires the NAS-Port-Type AVP to be present
(if the request does not contain it, access is denied). Although this
in some sense make NAS-Port-Type AVP "mandatory", it's not "mandatory"
in the sense that would require a new Diameter application.

While IKEv2 and MIP6 are not WiFi and WiMAX, I don't think there are
any significant differences from Diameter point-of-view. There's a box
providing some service; authentication works with EAP; authorization
AVPs indicate what exactly is being authorized. What's missing is
a document describing how the different authorization AVPs are
used in this particular situation; sort of like RFC 3580 (IEEE 802.1X
RADIUS Usage Guidelines), but for Diameter with IKEv2.

One important reason NOT to create new applications: proxies. Every
proxy on the path needs new code to handle the new application, while
just adding an extra AVP or new Service-Type value doesn't.
"

John agrees with Pasi.

Avi writes:
"
A mandatory attribute (a must understand attribute) that has a new
enumeration is in my mind is like adding a new attribute that must be
understood.  There is no wigle room here.  The command carrying that
attribute must reach the implementation that knows how to interpret the
attribute.  This is  because an implmentation that does not understand
Service-Type = X must return an error.

It is obvious that the rules in 3588 are not sufficient to describe when
to use a new Application ID or not.  And we should not have to have a
debate on this topic.

BTW if we do what you say then in networks where I have NASREQ
performing Network Access and now I want to roll out MIPv6 I would have
to upgrade all my old NASREQ deployed applications.  This is wrong.  I
should be able to add a MIPv6 compliant diameter application without
having to force upgrading my NASREQ applications.
"


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



From dime-bounces@ietf.org Wed Aug 16 17:57:09 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GDTNt-00028d-Kv; Wed, 16 Aug 2006 17:57:09 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GDTNs-00022Z-Aw
	for dime@ietf.org; Wed, 16 Aug 2006 17:57:08 -0400
Received: from bw.ulticom.com ([208.255.120.38])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDTAQ-0002wX-Ky
	for dime@ietf.org; Wed, 16 Aug 2006 17:43:16 -0400
Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP
	id 09B9033EE0; Wed, 16 Aug 2006 17:43:04 -0400 (EDT)
Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55])
	by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k7GLgoWi007678;
	Wed, 16 Aug 2006 17:42:54 -0400 (EDT)
From: "Tolga Asveren" <asveren@ulticom.com>
To: "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>,
	"Tina TSOU" <tena@huawei.com>, "Victor Fajardo" <vfajardo@tari.toshiba.com>
Subject: RE: [Dime] Next Steps for draft-tsou-dime-base-routing-ext-00
Date: Wed, 16 Aug 2006 17:18:48 -0400
Message-ID: <GBEBKGPKHGPAOFCLBNAMEEILEHAA.asveren@ulticom.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="ISO-8859-15"
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: <44E37CD7.4000601@gmx.net>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506
Importance: Normal
Received-SPF: none
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

I think the mechanism described in this draft could be useful for certain
cases. My understanding is, depending on the scenario, there may be other
solutions as well and at the end it is the operators choice to deploy this
or that alternative.

What needs to be done about this draft is also very much dependent on the
famous AppId discussion about the common messages defined in the base
protocol. To me, using AppId=0 for such messages is clearly a bug in the
base protocol and needs to be corrected, because it breaks the routability
of the messages for some very-real configurations. OTOH, I am also
acknowledging the backward compatibility issue. So, depending on the
decision of WG, I personally prefer the following:

A) WG wants to keep AppId=0 for base protocol common messages
- Add a section to 3588-bis about the routing problem and possible
solutions. I would prefer some not-so-shallow discussion of the issue in the
document with explanation of what type of topologies would work and which
ones won't.
- draft-tsou-dime-base-routing-ext-00 becomes a WG document
- We either update draft-tsou-dime-base-routing-ext-00 to reflect other
possible solutions to the problems it addresses or discuss all of them in
another draft.

B) WG decides to use AppId!=0 for base protocol common messages
- Work on draft-tsou-dime-base-routing-ext-00 continues with discussions on
the mailing list, it gets updated if necessary and possibly becomes a WG
item. I lean to think, it should be a WG-item.
- We either update draft-tsou-dime-base-routing-ext-00 to reflect other
possible solutions to the problems it addresses or discuss all of them in
another draft.

My choice would be B).

    Thanks,
    Tolga

> -----Original Message-----
> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
> Sent: Wednesday, August 16, 2006 4:15 PM
> To: Tina TSOU; Victor Fajardo
> Cc: dime@ietf.org
> Subject: [Dime] Next Steps for draft-tsou-dime-base-routing-ext-00
>
>
> Hi all,
>
> we discussed this document during the IETF#66 DIME working group
> meeting. The meeting participants did not express excitement. We would
> like to solicit feedback from the working group to see whether there is
> interest in this work and how we should proceed.
>
> Ciao
> Hannes & John
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www1.ietf.org/mailman/listinfo/dime


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



From dime-bounces@ietf.org Wed Aug 16 18:59:05 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GDULj-0004RM-Dk; Wed, 16 Aug 2006 18:58:59 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GDULi-0004Pi-8W
	for dime@ietf.org; Wed, 16 Aug 2006 18:58:58 -0400
Received: from defender.ccpu.com ([216.54.134.34] helo=smtp.ccpu.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDULf-0004FB-Rk
	for dime@ietf.org; Wed, 16 Aug 2006 18:58:58 -0400
Received: from smtp.ccpu.com (localhost.localdomain [127.0.0.1])
	by localhost.ccpu.com (Postfix) with ESMTP
	id 4094E346927; Wed, 16 Aug 2006 15:58:55 -0700 (PDT)
Received: from sd-exchange.ccsd.ccpu.com (sd-exchange.ccpu.com [172.16.0.203])
	by smtp.ccpu.com (Postfix) with ESMTP
	id 346333469B0; Wed, 16 Aug 2006 15:58:55 -0700 (PDT)
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Dime] DIME Working Group Status
Date: Wed, 16 Aug 2006 15:58:52 -0700
Message-ID: <C499405203244F4F8ECC637C6A8F498B0548EC60@sd-exchange>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Dime] DIME Working Group Status
Thread-Index: AcbBcKK3wlwsk01ZQJ+UhwrYNnFBrgAFs4QQ
From: "Todd Mersch" <todd.mersch@ccpu.com>
To: "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>, <dime@ietf.org>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 31247fb3be228bb596db9127becad0bc
Cc: 
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

In reference to the Diameter Interop, Continuous Computing (Trillium)
would be interested in participating.

Thanks,
Todd=20

-----Original Message-----
From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20
Sent: Wednesday, August 16, 2006 1:14 PM
To: dime@ietf.org
Subject: [Dime] DIME Working Group Status

Hi all,

here is a short working group status:

* Diameter Base Revision

We have an issue tracker setup that lists a bunch of open issues:
http://www.tschofenig.priv.at:8080/diameter-interop/index

We had a many discussions on the mailing list.

I have converted the draft to XML so that we can actually start
compiling new draft snapshots.

Unfortunately, we do not yet have specific text proposals.

* Diameter Interop

As mentioned at the IETF#66 DIME working group meeting there was
interest to have another Diameter Interop event. See also Slide 9 at
http://www3.ietf.org/proceedings/06jul/slides/dime-2/sld1.htm

Please drop us a mail if you are interested to participate to simplify
planning!

* Diameter URI

--> See separate mail.

* The Diameter API

We basically stalled.

--> See separate mail.

* Mobile IPv6 Bootstrapping  (Split Scenario & Integrated Scenario)

Progress is blocked due to the unfinished "Application ID" vs.=20
"NAS-Port-Type AVP/Service-Type" discussion.

We hope that the authors of
http://www.ietf.org/internet-drafts/draft-ietf-mip6-aaa-ha-goals-02.txt
compile a draft update that can serve as input to the ongoing work
(since there are other technical aspects that need to be addressed).

--> See separate mail.

* draft-tsou-dime-base-routing-ext-00

--> See separate mail.

* draft-bodin-dime-auditing-reqs-00.txt

--> See separate mail.

* Diameter QoS

A small group consisting of Avri Doria, Glen Zorn, Pete McCann, Tina
Tsou and myself are working on an updated version of the document. We
plan to have something ready for the group by end of September.

In summary, I think we need to work a bit harder and more focused to
make better progress.

Ciao
Hannes & John

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

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



From dime-bounces@ietf.org Thu Aug 17 02:14:08 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GDb8m-0001Su-Bu; Thu, 17 Aug 2006 02:14:04 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GDb8k-0001Ru-MW
	for dime@ietf.org; Thu, 17 Aug 2006 02:14:02 -0400
Received: from szxga02-in.huawei.com ([61.144.161.54])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDb8i-0003Wr-Sc
	for dime@ietf.org; Thu, 17 Aug 2006 02:14:02 -0400
Received: from huawei.com (szxga02-in [172.24.2.6])
	by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0J4400243Q3GVK@szxga02-in.huawei.com> for
	dime@ietf.org; Thu, 17 Aug 2006 14:30:52 +0800 (CST)
Received: from huawei.com ([172.24.1.24])
	by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0J440096ZQ3FDG@szxga02-in.huawei.com> for
	dime@ietf.org; Thu, 17 Aug 2006 14:30:51 +0800 (CST)
Received: from z26452a ([10.70.145.98])
	by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTPA id <0J4400HB2PTZOS@szxml04-in.huawei.com> for
	dime@ietf.org; Thu, 17 Aug 2006 14:25:14 +0800 (CST)
Date: Thu, 17 Aug 2006 14:13:08 +0800
From: Tony Zhang <zhangtao_hw@huawei.com>
Subject: RE: [Dime] Next Steps for draft-tsou-dime-base-routing-ext-00
In-reply-to: <GBEBKGPKHGPAOFCLBNAMEEILEHAA.asveren@ulticom.com>
To: 'Tolga Asveren' <asveren@ulticom.com>,
	'Hannes Tschofenig' <Hannes.Tschofenig@gmx.net>,
	'Tina TSOU' <tena@huawei.com>, 'Victor Fajardo' <vfajardo@tari.toshiba.com>
Message-id: <000d01c6c1c4$35c45d50$6291460a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 7BIT
Thread-index: AcbBfyalfw013HIpTLmP3I5PEfqzCgARKFEg
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

My Choice is :
(1)use AppId!=0 for base protocol common messages
(2) draft-tsou-dime-base-routing-ext-00 should be a WG_ITEM

Regards!
Tony


-----Original Message-----
From: Tolga Asveren [mailto:asveren@ulticom.com] 
Sent: Thursday, August 17, 2006 5:19 AM
To: Hannes Tschofenig; Tina TSOU; Victor Fajardo
Cc: dime@ietf.org
Subject: RE: [Dime] Next Steps for draft-tsou-dime-base-routing-ext-00

I think the mechanism described in this draft could be useful for certain
cases. My understanding is, depending on the scenario, there may be other
solutions as well and at the end it is the operators choice to deploy this
or that alternative.

What needs to be done about this draft is also very much dependent on the
famous AppId discussion about the common messages defined in the base
protocol. To me, using AppId=0 for such messages is clearly a bug in the
base protocol and needs to be corrected, because it breaks the routability
of the messages for some very-real configurations. OTOH, I am also
acknowledging the backward compatibility issue. So, depending on the
decision of WG, I personally prefer the following:

A) WG wants to keep AppId=0 for base protocol common messages
- Add a section to 3588-bis about the routing problem and possible
solutions. I would prefer some not-so-shallow discussion of the issue in the
document with explanation of what type of topologies would work and which
ones won't.
- draft-tsou-dime-base-routing-ext-00 becomes a WG document
- We either update draft-tsou-dime-base-routing-ext-00 to reflect other
possible solutions to the problems it addresses or discuss all of them in
another draft.

B) WG decides to use AppId!=0 for base protocol common messages
- Work on draft-tsou-dime-base-routing-ext-00 continues with discussions on
the mailing list, it gets updated if necessary and possibly becomes a WG
item. I lean to think, it should be a WG-item.
- We either update draft-tsou-dime-base-routing-ext-00 to reflect other
possible solutions to the problems it addresses or discuss all of them in
another draft.

My choice would be B).

    Thanks,
    Tolga

> -----Original Message-----
> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
> Sent: Wednesday, August 16, 2006 4:15 PM
> To: Tina TSOU; Victor Fajardo
> Cc: dime@ietf.org
> Subject: [Dime] Next Steps for draft-tsou-dime-base-routing-ext-00
>
>
> Hi all,
>
> we discussed this document during the IETF#66 DIME working group
> meeting. The meeting participants did not express excitement. We would
> like to solicit feedback from the working group to see whether there is
> interest in this work and how we should proceed.
>
> Ciao
> Hannes & John
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www1.ietf.org/mailman/listinfo/dime


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



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



From dime-bounces@ietf.org Thu Aug 17 03:02:41 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GDbtn-0004cz-Dp; Thu, 17 Aug 2006 03:02:39 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GDbtm-0004Xk-5Y
	for dime@ietf.org; Thu, 17 Aug 2006 03:02:38 -0400
Received: from szxga01-in.huawei.com ([61.144.161.53])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDbtk-0000zV-Kd
	for dime@ietf.org; Thu, 17 Aug 2006 03:02:38 -0400
Received: from huawei.com (szxga01-in [172.24.2.3])
	by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0J4400LZ7RNQ7N@szxga01-in.huawei.com> for
	dime@ietf.org; Thu, 17 Aug 2006 15:04:38 +0800 (CST)
Received: from huawei.com ([172.24.1.18])
	by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0J44005TPRNP6X@szxga01-in.huawei.com> for
	dime@ietf.org; Thu, 17 Aug 2006 15:04:38 +0800 (CST)
Received: from z26452a ([10.70.145.98])
	by szxml03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTPA id <0J4400I3PROUOX@szxml03-in.huawei.com> for
	dime@ietf.org; Thu, 17 Aug 2006 15:05:21 +0800 (CST)
Date: Thu, 17 Aug 2006 15:01:34 +0800
From: Tony Zhang <zhangtao_hw@huawei.com>
Subject: RE: [Dime] Mobile IPv6 Bootstrapping - "Application ID" vs.
	"NAS-Port-Type AVP/Service-Type": Summary
In-reply-to: <44E3853B.2090406@gmx.net>
To: 'Hannes Tschofenig' <Hannes.Tschofenig@gmx.net>, dime@ietf.org
Message-id: <000e01c6c1ca$f9d4df70$6291460a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Mailer: Microsoft Office Outlook 11
Content-type: text/plain; charset=utf-8
Content-transfer-encoding: 7BIT
Thread-index: AcbBdop38qonbbQ/Rai/tgcb+qDQRgAUbOkg
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 223e3c753032a50d5dc4443c921c3fcd
Cc: 
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

* RFC 3588 leaves a question regarding the extensibility open.
   This needs to be captured in the revision of the base specification.
[Tony]Agree
* The main issue seems to be

   - Do we want to route 'Diameter EAP' message and 'Diameter Mobile 
IPv6 Bootstrapping' messages differently?
     If we want to route them differently then we need to define 
'Diameter MIPv6 Bootstrapping' as a Diameter application.
[Tony]In my understanding, less chance on Diameter MIPV6 and EAP ACCSS use same Server. my choice use new application ID ,but still better define new Service Type and NAS Port Type(because maybe it will share same account server).
   - The AAA server differentiates ordinary network access and MIPv6 
bootstrapping functionality (with respect to authorization and 
accounting). In order to do so it must understand the Service-Type 
and/or NAS-Port-Type AVPs and the defined values.
     Is this a problem?
[Tony] in my understand,AAA server should understand this.
   - There are problems with proxies and newly defined Diameter 
Application IDs. Every
proxy on the path needs new code to handle the new application, while
just adding an extra AVP or new Service-Type value does not hurt.

     Is this an issue for us?
[Tony]Proxy agent compare to Realy agent,it should unsterstand the application.so I think no issue for us!

-----Original Message-----
From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net] 
Sent: Thursday, August 17, 2006 4:51 AM
To: dime@ietf.org
Subject: [Dime] Mobile IPv6 Bootstrapping - "Application ID" vs. "NAS-Port-Type AVP/Service-Type": Summary

Hi all,

I went through the discussion again and noticed that we haven't reached 
a conclusion.

Here is my impression:

* RFC 3588 leaves a question regarding the extensibility open.
   This needs to be captured in the revision of the base specification.

* The main issue seems to be

   - Do we want to route 'Diameter EAP' message and 'Diameter Mobile 
IPv6 Bootstrapping' messages differently?

     If we want to route them differently then we need to define 
'Diameter MIPv6 Bootstrapping' as a Diameter application.

   - The AAA server differentiates ordinary network access and MIPv6 
bootstrapping functionality (with respect to authorization and 
accounting). In order to do so it must understand the Service-Type 
and/or NAS-Port-Type AVPs and the defined values.

     Is this a problem?

   - There are problems with proxies and newly defined Diameter 
Application IDs. Every
proxy on the path needs new code to handle the new application, while
just adding an extra AVP or new Service-Type value does not hurt.

     Is this an issue for us?

Ciao
Hannes

PS: Here is copy-and-paste version of some discussion snippets to allow 
others to catch-up.

Julien starts the discussion with a question about Application IDs.

Pasi suggests to consider Service-Type and/or NAS-Port-Type AVPs as 
well.... the problem starts.

Avi states that the problem is that neither Service-Type or Port-Type is 
mandatory.
"
Service Type seems to be the correct way but in RADIUS and
Diameter service-type also can be authenticate-only or authorize-only.
So what if the HA wanted to authenticate-only or authorize-only for the
MIP service?  I would lose the ability to also indicate that this is an
HA.

So Port-Type seems to be the way to go....
"

Jari jumps in:
"
One of the reasons why an existing application would
be preferred is that then a AAA server that does not
care about the type of service can be used without
changes. Yet servers that do care can look at the
AVPs and make more detailed authorization
decisions.


RFC 3588 states that  "Creation of a new application
should be viewed as a last resort." and that "In order
to justify allocation of a new application identifier,
Diameter applications MUST define one Command Code,
or add new mandatory AVPs to the ABNF." Note that
mandatory AVPs can be viewed in different ways,
and that we should not be too strict about them.
For instance, Framed-Protocol is an optional AVP in
RFCs 4005 and 4072. Yet, you could argue that if you
are doing PPP then you need to use this attribute and
set it to PPP. But that didn't make the attribute mandatory.
Do we have a similar situation for the IKEv2/MIPv6
attributes and values? They are not necessary from
the NASREQ/EAP perspective, but in the specific context
you need to use the attributes. In my mind, this does not
make the attributes mandatory from a Diameter
application point of view. If we start creating
new applications for every different situation,
we'll have lots of applications and interoperability
problems. Its better to add new optional AVPs and
describe in text when they should be used. The
only exception that I see is security related AVPs
that must be understood by the other side or else
the session should be terminated.
"

Avi responds:
"
Mandatory does not mean required in the Command.  It means that it must
be understood by the receiver.  We need to clarify that.
"

Gerardo and Lionel agree with Jari.



Avi writes:
"
If I have two EAP based application in my network, one that is
handling pure EAP application, the other is extended to handle the new
behavior then I need a way to route the (same) command correctly.
"

Jari writes:
"
Ah, but that is a new requirement. If you believe that you need
to route EAP authentication from a 802.11 AP differently
than from IKEv2/MIPv6, then you need one of these:

- Use different user/domain names for the users of
   the different services.

- Point to different servers from the AP and SGW (but
   this works less well if you have proxies and roaming).

- New application ID.

- Some weird form of Diameter and RADIUS source routing
   based on what type of node sent the message.

However, it is far from clear to me why you would really
need to route the authentication differently *for the same
user*. Many authentication mechanisms can also have state,
which would imply that at the end they need to end up in
the same device anyhow. Can you expand on why you need
to handle the same users in different authentication
servers?
"

Avi to Jari:

"
BTW in the context of the original question raised, the attribute(s)
will not be optional. Here is the snippet:

 >> >>  In our case, the AAA server must perform AAA functionality for the
 >> >> Mobile IPv6 service. The AAA server must know that it has to
 >> >> authorize the mip6 service and the accounting (ASR/ASA) is also for
 >> >>  mip6 and not for network access.

If the Diameter message comes from the HA then the HA MUST include the
NAS-Port-type attribute. So the command ABNF is being changed. Also the
behavior is being changed of the Server.  It MUST recognize the (new)
value of the NAS-Port-Type.
"


Yoshi says:
"
If what is important is service-specific routing (I am not convinced
with it yet), I'd suggest defining a new authorization-only
application used only for carrying service-specific attributes
(analogous to NASREQ usage in RFC 4072).  The downside is that it
needs another message roundtrip than carrying the attributes in
DER/DEA.
"


Julien wrote:
"
 > >
 > > I don't think it's clean to require use of different
 > > users'identifiers in order to distinguish which services is
 > > provided. For me, it looks like a 'hack'.
" and Pasi responded:
"
I fully agree -- but having separate user identifiers should not be
necessary. If, for example, an operator wants to perform different
authorizations for WiFi and WiMAX (e.g., some users can access only
WiFi but not WiMAX), that's simple to do: just check Service-Type,
NAS-Port-Type, and other relevant authorization AVPs.  There's
absolutely no need to create a new Diameter application.

If the AAA server is really strict about WiFi vs. WiMAX separation, it
can have a policy that requires the NAS-Port-Type AVP to be present
(if the request does not contain it, access is denied). Although this
in some sense make NAS-Port-Type AVP "mandatory", it's not "mandatory"
in the sense that would require a new Diameter application.

While IKEv2 and MIP6 are not WiFi and WiMAX, I don't think there are
any significant differences from Diameter point-of-view. There's a box
providing some service; authentication works with EAP; authorization
AVPs indicate what exactly is being authorized. What's missing is
a document describing how the different authorization AVPs are
used in this particular situation; sort of like RFC 3580 (IEEE 802.1X
RADIUS Usage Guidelines), but for Diameter with IKEv2.

One important reason NOT to create new applications: proxies. Every
proxy on the path needs new code to handle the new application, while
just adding an extra AVP or new Service-Type value doesn't.
"

John agrees with Pasi.

Avi writes:
"
A mandatory attribute (a must understand attribute) that has a new
enumeration is in my mind is like adding a new attribute that must be
understood.  There is no wigle room here.  The command carrying that
attribute must reach the implementation that knows how to interpret the
attribute.  This is  because an implmentation that does not understand
Service-Type = X must return an error.

It is obvious that the rules in 3588 are not sufficient to describe when
to use a new Application ID or not.  And we should not have to have a
debate on this topic.

BTW if we do what you say then in networks where I have NASREQ
performing Network Access and now I want to roll out MIPv6 I would have
to upgrade all my old NASREQ deployed applications.  This is wrong.  I
should be able to add a MIPv6 compliant diameter application without
having to force upgrading my NASREQ applications.
"


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



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



From dime-bounces@ietf.org Thu Aug 17 03:41:26 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GDcVA-00036t-1C; Thu, 17 Aug 2006 03:41:16 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GDcV9-00035I-6a
	for dime@ietf.org; Thu, 17 Aug 2006 03:41:15 -0400
Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GDcV6-0005k4-D6
	for dime@ietf.org; Thu, 17 Aug 2006 03:41:15 -0400
Received: (qmail invoked by alias); 17 Aug 2006 07:41:11 -0000
Received: from socks2.netz.sbs.de (EHLO [192.35.17.25]) [192.35.17.25]
	by mail.gmx.net (mp027) with SMTP; 17 Aug 2006 09:41:11 +0200
X-Authenticated: #29516787
Message-ID: <44E41D98.2010505@gmx.net>
Date: Thu, 17 Aug 2006 09:41:12 +0200
From: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: Tony Zhang <zhangtao_hw@huawei.com>
Subject: Re: [Dime] Mobile IPv6 Bootstrapping - "Application ID" vs.
	"NAS-Port-Type AVP/Service-Type": Summary
References: <000e01c6c1ca$f9d4df70$6291460a@china.huawei.com>
In-Reply-To: <000e01c6c1ca$f9d4df70$6291460a@china.huawei.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
X-Spam-Score: 0.1 (/)
X-Scan-Signature: c2e58d9873012c90703822e287241385
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

Hi Tony,

Tony Zhang schrieb:
> * RFC 3588 leaves a question regarding the extensibility open. This
> needs to be captured in the revision of the base specification. 
> [Tony]Agree * The main issue seems to be
> 
> - Do we want to route 'Diameter EAP' message and 'Diameter Mobile 
> IPv6 Bootstrapping' messages differently? If we want to route them
> differently then we need to define 'Diameter MIPv6 Bootstrapping' as
> a Diameter application. [Tony]In my understanding, less chance on
> Diameter MIPV6 and EAP ACCSS use same Server. my choice use new
> application ID ,but still better define new Service Type and NAS Port
> Type(because maybe it will share same account server).

But setting an additional value in the Service Type/NAS Port Type in 
addition to using a new Application ID would not help. Using either / or 
would not be useful either since the AAA client does not know when the 
AAA server of the two services are different.

> - The AAA server differentiates ordinary network access and MIPv6 
> bootstrapping functionality (with respect to authorization and 
> accounting). In order to do so it must understand the Service-Type 
> and/or NAS-Port-Type AVPs and the defined values. Is this a problem? 
> [Tony] in my understand,AAA server should understand this. - There
> are problems with proxies and newly defined Diameter Application IDs.
> Every proxy on the path needs new code to handle the new application,
> while just adding an extra AVP or new Service-Type value does not
> hurt.

The problem with proxies is that they need to understand the new 
Application ID since otherwise they will not process the Service Type 
values.

Mandating the servers to understand the specific values is difficult; 
See also the discussion.

If the AAA server does not understand the specific value it just treats 
the access like an ordinary network access. It is up to the MIPv6 guys 
to indicate whether that's fine with them.

> 
> Is this an issue for us? [Tony]Proxy agent compare to Realy agent,it
> should unsterstand the application.so I think no issue for us!

It is a deployment problem. For a protocol designer it might not be a 
problem...

Ciao
Hannes


> -----Original Message----- From: Hannes Tschofenig
> [mailto:Hannes.Tschofenig@gmx.net] Sent: Thursday, August 17, 2006
> 4:51 AM To: dime@ietf.org Subject: [Dime] Mobile IPv6 Bootstrapping -
> "Application ID" vs. "NAS-Port-Type AVP/Service-Type": Summary
> 
> Hi all,
> 
> I went through the discussion again and noticed that we haven't
> reached a conclusion.
> 
> Here is my impression:
> 
> * RFC 3588 leaves a question regarding the extensibility open. This
> needs to be captured in the revision of the base specification.
> 
> * The main issue seems to be
> 
> - Do we want to route 'Diameter EAP' message and 'Diameter Mobile 
> IPv6 Bootstrapping' messages differently?
> 
> If we want to route them differently then we need to define 'Diameter
> MIPv6 Bootstrapping' as a Diameter application.
> 
> - The AAA server differentiates ordinary network access and MIPv6 
> bootstrapping functionality (with respect to authorization and 
> accounting). In order to do so it must understand the Service-Type 
> and/or NAS-Port-Type AVPs and the defined values.
> 
> Is this a problem?
> 
> - There are problems with proxies and newly defined Diameter 
> Application IDs. Every proxy on the path needs new code to handle the
> new application, while just adding an extra AVP or new Service-Type
> value does not hurt.
> 
> Is this an issue for us?
> 
> Ciao Hannes
> 
> PS: Here is copy-and-paste version of some discussion snippets to
> allow others to catch-up.
> 
> Julien starts the discussion with a question about Application IDs.
> 
> Pasi suggests to consider Service-Type and/or NAS-Port-Type AVPs as 
> well.... the problem starts.
> 
> Avi states that the problem is that neither Service-Type or Port-Type
> is mandatory. " Service Type seems to be the correct way but in
> RADIUS and Diameter service-type also can be authenticate-only or
> authorize-only. So what if the HA wanted to authenticate-only or
> authorize-only for the MIP service?  I would lose the ability to also
> indicate that this is an HA.
> 
> So Port-Type seems to be the way to go.... "
> 
> Jari jumps in: " One of the reasons why an existing application would
>  be preferred is that then a AAA server that does not care about the
> type of service can be used without changes. Yet servers that do care
> can look at the AVPs and make more detailed authorization decisions.
> 
> 
> RFC 3588 states that  "Creation of a new application should be viewed
> as a last resort." and that "In order to justify allocation of a new
> application identifier, Diameter applications MUST define one Command
> Code, or add new mandatory AVPs to the ABNF." Note that mandatory
> AVPs can be viewed in different ways, and that we should not be too
> strict about them. For instance, Framed-Protocol is an optional AVP
> in RFCs 4005 and 4072. Yet, you could argue that if you are doing PPP
> then you need to use this attribute and set it to PPP. But that
> didn't make the attribute mandatory. Do we have a similar situation
> for the IKEv2/MIPv6 attributes and values? They are not necessary
> from the NASREQ/EAP perspective, but in the specific context you need
> to use the attributes. In my mind, this does not make the attributes
> mandatory from a Diameter application point of view. If we start
> creating new applications for every different situation, we'll have
> lots of applications and interoperability problems. Its better to add
> new optional AVPs and describe in text when they should be used. The 
> only exception that I see is security related AVPs that must be
> understood by the other side or else the session should be
> terminated. "
> 
> Avi responds: " Mandatory does not mean required in the Command.  It
> means that it must be understood by the receiver.  We need to clarify
> that. "
> 
> Gerardo and Lionel agree with Jari.
> 
> 
> 
> Avi writes: " If I have two EAP based application in my network, one
> that is handling pure EAP application, the other is extended to
> handle the new behavior then I need a way to route the (same) command
> correctly. "
> 
> Jari writes: " Ah, but that is a new requirement. If you believe that
> you need to route EAP authentication from a 802.11 AP differently 
> than from IKEv2/MIPv6, then you need one of these:
> 
> - Use different user/domain names for the users of the different
> services.
> 
> - Point to different servers from the AP and SGW (but this works less
> well if you have proxies and roaming).
> 
> - New application ID.
> 
> - Some weird form of Diameter and RADIUS source routing based on what
> type of node sent the message.
> 
> However, it is far from clear to me why you would really need to
> route the authentication differently *for the same user*. Many
> authentication mechanisms can also have state, which would imply that
> at the end they need to end up in the same device anyhow. Can you
> expand on why you need to handle the same users in different
> authentication servers? "
> 
> Avi to Jari:
> 
> " BTW in the context of the original question raised, the
> attribute(s) will not be optional. Here is the snippet:
> 
>>>>> In our case, the AAA server must perform AAA functionality
>>>>> for the Mobile IPv6 service. The AAA server must know that it
>>>>> has to authorize the mip6 service and the accounting
>>>>> (ASR/ASA) is also for mip6 and not for network access.
> 
> If the Diameter message comes from the HA then the HA MUST include
> the NAS-Port-type attribute. So the command ABNF is being changed.
> Also the behavior is being changed of the Server.  It MUST recognize
> the (new) value of the NAS-Port-Type. "
> 
> 
> Yoshi says: " If what is important is service-specific routing (I am
> not convinced with it yet), I'd suggest defining a new
> authorization-only application used only for carrying
> service-specific attributes (analogous to NASREQ usage in RFC 4072).
> The downside is that it needs another message roundtrip than carrying
> the attributes in DER/DEA. "
> 
> 
> Julien wrote: "
>>> 
>>> I don't think it's clean to require use of different 
>>> users'identifiers in order to distinguish which services is 
>>> provided. For me, it looks like a 'hack'.
> " and Pasi responded: " I fully agree -- but having separate user
> identifiers should not be necessary. If, for example, an operator
> wants to perform different authorizations for WiFi and WiMAX (e.g.,
> some users can access only WiFi but not WiMAX), that's simple to do:
> just check Service-Type, NAS-Port-Type, and other relevant
> authorization AVPs.  There's absolutely no need to create a new
> Diameter application.
> 
> If the AAA server is really strict about WiFi vs. WiMAX separation,
> it can have a policy that requires the NAS-Port-Type AVP to be
> present (if the request does not contain it, access is denied).
> Although this in some sense make NAS-Port-Type AVP "mandatory", it's
> not "mandatory" in the sense that would require a new Diameter
> application.
> 
> While IKEv2 and MIP6 are not WiFi and WiMAX, I don't think there are 
> any significant differences from Diameter point-of-view. There's a
> box providing some service; authentication works with EAP;
> authorization AVPs indicate what exactly is being authorized. What's
> missing is a document describing how the different authorization AVPs
> are used in this particular situation; sort of like RFC 3580 (IEEE
> 802.1X RADIUS Usage Guidelines), but for Diameter with IKEv2.
> 
> One important reason NOT to create new applications: proxies. Every 
> proxy on the path needs new code to handle the new application, while
>  just adding an extra AVP or new Service-Type value doesn't. "
> 
> John agrees with Pasi.
> 
> Avi writes: " A mandatory attribute (a must understand attribute)
> that has a new enumeration is in my mind is like adding a new
> attribute that must be understood.  There is no wigle room here.  The
> command carrying that attribute must reach the implementation that
> knows how to interpret the attribute.  This is  because an
> implmentation that does not understand Service-Type = X must return
> an error.
> 
> It is obvious that the rules in 3588 are not sufficient to describe
> when to use a new Application ID or not.  And we should not have to
> have a debate on this topic.
> 
> BTW if we do what you say then in networks where I have NASREQ 
> performing Network Access and now I want to roll out MIPv6 I would
> have to upgrade all my old NASREQ deployed applications.  This is
> wrong.  I should be able to add a MIPv6 compliant diameter
> application without having to force upgrading my NASREQ applications.
>  "
> 
> 
> _______________________________________________ DiME mailing list 
> DiME@ietf.org https://www1.ietf.org/mailman/listinfo/dime
> 
> 
> 


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



From dime-bounces@ietf.org Thu Aug 17 10:50:00 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GDjC0-0004S1-8j; Thu, 17 Aug 2006 10:49:56 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GDjBy-0004RV-P6
	for dime@ietf.org; Thu, 17 Aug 2006 10:49:54 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDjBw-0000V1-GY
	for dime@ietf.org; Thu, 17 Aug 2006 10:49:54 -0400
Received: from psg.com ([147.28.0.62] helo=[127.0.0.1])
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <avri@acm.org>)
	id 1GDjBv-000LQt-P5; Thu, 17 Aug 2006 14:49:51 +0000
In-Reply-To: <44E37C74.4060006@gmx.net>
References: <44E37C74.4060006@gmx.net>
Mime-Version: 1.0 (Apple Message framework v752.2)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <74F8139D-44B8-48FC-BA0B-1C9364C5D485@acm.org>
Content-Transfer-Encoding: 7bit
From: Avri Doria <avri@acm.org>
Date: Thu, 17 Aug 2006 10:49:48 -0400
To: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
X-Mailer: Apple Mail (2.752.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52e1467c2184c31006318542db5614d5
Cc: Ulf.Bodin@operax.com, dime@ietf.org
Subject: [Dime] Re: Next Steps for draft-bodin-dime-auditing-reqs-00.txt
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

Hi,

Yes, we are planning to put out another version, i will most probably  
be acting as the editor of the version.  I have been away for the  
last few weeks, but am back now and expect to float a new version in  
the next 2 weeks.

I do think there is interst in ETSI TISPAN as this was were the  
original impetus came from.  Not sure about the  ITU.

I would certainly appreciate any use case text members of the dime wg  
would like to see included in the updated document.

thanks

a.

On 16 aug 2006, at 16.13, Hannes Tschofenig wrote:

> Hi Avri,
> Hi Ulf,
>
> during the DIME working group meeting at IETF#66 a number of folks  
> showed interest in your work. It was, however, also noted that the  
> draft requires a bit more details.
>
> Do you plan to update the draft? When do you plan to submit the  
> draft? Do you need help with the draft editing (I bet there are  
> some DIME working group members willing to help.)?
> Is there interest from ETSI TISPAN and the ITU-T on this subject?
>
> Ciao
> Hannes & John
>
>


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



From dime-bounces@ietf.org Thu Aug 17 10:58:52 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GDjKe-0008VI-FU; Thu, 17 Aug 2006 10:58:52 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GDjKd-0008VD-2y
	for dime@ietf.org; Thu, 17 Aug 2006 10:58:51 -0400
Received: from bw.ulticom.com ([208.255.120.38])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDjKa-0002EW-VR
	for dime@ietf.org; Thu, 17 Aug 2006 10:58:51 -0400
Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP
	id 991F94A7C6; Thu, 17 Aug 2006 10:58:46 -0400 (EDT)
Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55])
	by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k7HEwjPq026275;
	Thu, 17 Aug 2006 10:58:45 -0400 (EDT)
From: "Tolga Asveren" <asveren@ulticom.com>
To: "Avri Doria" <avri@acm.org>,
	"Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>
Subject: RE: [Dime] Re: Next Steps for draft-bodin-dime-auditing-reqs-00.txt
Date: Thu, 17 Aug 2006 10:34:38 -0400
Message-ID: <GBEBKGPKHGPAOFCLBNAMAEJCEHAA.asveren@ulticom.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)
In-Reply-To: <74F8139D-44B8-48FC-BA0B-1C9364C5D485@acm.org>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506
Importance: Normal
Received-SPF: none
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da
Cc: Ulf.Bodin@operax.com, dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

Hi Avri,

I am most interested at a clear definition of the problem the draft is
about:

a) Preventing session leaking
b) Retrieving state information
c) Both

If that is made more clear, it would be easirt to understand/to move
forward -at least for me-

    Thanks,
    Tolga

> -----Original Message-----
> From: Avri Doria [mailto:avri@acm.org]
> Sent: Thursday, August 17, 2006 10:50 AM
> To: Hannes Tschofenig
> Cc: Ulf.Bodin@operax.com; dime@ietf.org
> Subject: [Dime] Re: Next Steps for draft-bodin-dime-auditing-reqs-00.txt
>
>
> Hi,
>
> Yes, we are planning to put out another version, i will most probably
> be acting as the editor of the version.  I have been away for the
> last few weeks, but am back now and expect to float a new version in
> the next 2 weeks.
>
> I do think there is interst in ETSI TISPAN as this was were the
> original impetus came from.  Not sure about the  ITU.
>
> I would certainly appreciate any use case text members of the dime wg
> would like to see included in the updated document.
>
> thanks
>
> a.
>
> On 16 aug 2006, at 16.13, Hannes Tschofenig wrote:
>
> > Hi Avri,
> > Hi Ulf,
> >
> > during the DIME working group meeting at IETF#66 a number of folks
> > showed interest in your work. It was, however, also noted that the
> > draft requires a bit more details.
> >
> > Do you plan to update the draft? When do you plan to submit the
> > draft? Do you need help with the draft editing (I bet there are
> > some DIME working group members willing to help.)?
> > Is there interest from ETSI TISPAN and the ITU-T on this subject?
> >
> > Ciao
> > Hannes & John
> >
> >
>
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www1.ietf.org/mailman/listinfo/dime


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



From dime-bounces@ietf.org Thu Aug 17 11:24:49 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GDjjl-0004Rp-1C; Thu, 17 Aug 2006 11:24:49 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GDjjj-0004Lf-FS
	for dime@ietf.org; Thu, 17 Aug 2006 11:24:47 -0400
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDjjh-00049L-3g
	for dime@ietf.org; Thu, 17 Aug 2006 11:24:47 -0400
Received: from rtp-dkim-2.cisco.com ([64.102.121.159])
	by rtp-iport-1.cisco.com with ESMTP; 17 Aug 2006 08:24:43 -0700
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="4.08,137,1154934000"; 
	d="scan'208"; a="36711883:sNHT24650692"
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12])
	by rtp-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id
	k7HFOhR0021496; Thu, 17 Aug 2006 11:24:43 -0400
Received: from [161.44.55.215] (dhcp-161-44-55-215.cisco.com [161.44.55.215])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id
	k7HFOfdM001389; Thu, 17 Aug 2006 11:24:41 -0400 (EDT)
Message-ID: <44E48A39.7050803@cisco.com>
Date: Thu, 17 Aug 2006 11:24:41 -0400
From: Anders Kristensen <andersk@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Jan Nordqvist <jnordqvist@lucent.com>
Subject: Re: [Dime] Summary of 3588bis Issues Status
References: <GBEBKGPKHGPAOFCLBNAMEEFNEFAA.asveren@ulticom.com>
	<44BD5532.2040002@aaa.lucent.com>
In-Reply-To: <44BD5532.2040002@aaa.lucent.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1; q=dns; l=4403; t=1155828283; x=1156692283;
	c=relaxed/simple; s=rtpdkim2001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=andersk@cisco.com;
	z=From:Anders=20Kristensen=20<andersk@cisco.com>
	|Subject:Re=3A=20[Dime]=20Summary=20of=203588bis=20Issues=20Status
	|To:Jan=20Nordqvist=20<jnordqvist@lucent.com>;
	X=v=3Dcisco.com=3B=20h=3Dcmqegl8ax+cjNK7Z5ko0g0V8/e4=3D;
	b=S7DH7k6uun3GqAGIpDFq5eZj5MJKUAXCVhI9Wn9s5KA/q0Wmw8OvPrBi5PRiJvMmR/ha+ggl
	CIdMOLP9XGH0fk81oaSG5TyxHpsRBHf3QwIREUYAX9FgUVB1h10rueUH;
Authentication-Results: rtp-dkim-2.cisco.com; header.From=andersk@cisco.com;
	dkim=pass ( sig from cisco.com verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 73734d43604d52d23b3eba644a169745
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

[Going through old email.]

I like this proposal a lot. It's simple and greatly clarifies things. 
IMO 3588 is pretty clear that the app id space is flat. It's a mystery 
why application IDs were ever tagged with vendor IDs but if the 
Vendor-Specific-Application-Id can be retired then good riddance (due to 
backwards compatibility it probably can't, though). If we could get rid 
of the Auth/Acct tagging of app IDs then in my view that would be a good 
thing too. For better or worse Diameter is being used for non-AAA 
purposes too now.

Thanks,
Anders

Jan Nordqvist wrote:
> Few topics has generated as many messages in this and other groups as 
> the subject regarding (or the confusion surrounding) the fact that there 
> is an AVP-based application id in the message in addition to the message 
> id in the Diameter header.
> 
> As far as I am concerned, the application-id serves three purposes:
> 
>  1. Combined with the Command-Code as a message type discriminator to
>     determine what dictionary and processing entry point to apply in
>     order to process the message.
>  2. Combined with the Destination-Realm to determine message routing.
>  3. As a special case in the CER/CEA as a means to advertise
>     application id support.
> 
> I just can't imagine what scenario would require more than one 
> application id in a message to serve the purpose of both case 1 and 2 
> above, but I may be wrong.
> Only in case 3, which is an exception, use of the application id AVPs is 
> necessary since they are overloaded to mean "support for" in contrast to 
> identifying the type of message. In this latter case the header 
> application id only serves as a discriminator to indicate "base".
> 
> For messages that are intended for a specific server, such as ASRs or 
> any other message that are tied to a specific session, the primary means 
> for reaching the correct destination is the Destination-Host AVP. The 
> application id may of course still be used to make coarse routing 
> decisions to reach a host that has connectivity to and knowledge about 
> the given host. Obviously it is the responsibility of the network 
> administrator to configure the network in this case in such a way that 
> messages aren't dropped, i.e. are being relayed or proxied to reach a 
> "knowledgeable" peer. This would also seem as a very likely way to set 
> up routing in practice, i.e. make course decisions far away from the 
> target and make more precise decisions as the message gets closer to its 
> destination.
> 
> If the header application id is always set to resolve cases 1 and 2 
> above, i.e. set to identify the application pertaining to the message, 
> the only remaining meaningful use for the AVP based application ids is 
> for CE[AR]s. For existing AVP rules that include application ids as 
> AVPs, the standard could simply state that if one of the Application-Id 
> AVPs appear in a message, it MUST be set to the same value as the header 
> application id and thereby relieve implementers from a lot of confusion. 
> For new definitions, AVP application ids may be defined as optional, or 
> simply handled by the "universal last resort" *AVP rule.
> 
> IMHO, a clean and simple rule that would make life much easier both for 
> implementers and standards writers that avoids complicated and/or hard 
> to grasp rules regarding when to use one or the other of the application 
> ids.
> 
> One obvious issue is that the AVP application id can carry 65 bits of 
> information; an optional 32 bits of vendor id and a binary selector 
> between Auth versus Acct. There seems to be some disagreement as to 
> whether the application id numbering space is flat or not, but if it 
> considered flat, which indeed a 32 bit number would be sufficient for, 
> the "optional" AVP information could be disregarded and the header carry 
> the authoritative source of information.  As an alternative, if the 
> vendor id and the Auth/Acct distinction is deemed necessary, the header 
> application id could be disregarded and the AVP be treated as the only 
> authoritative piece of information instead.
> 
> Just my five cents,
> Jan Nordqvist
> 
> 
> 
> 
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www1.ietf.org/mailman/listinfo/dime
> 

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



From dime-bounces@ietf.org Thu Aug 17 11:48:21 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GDk6X-0006be-Nm; Thu, 17 Aug 2006 11:48:21 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GDk6W-0006bZ-Po
	for dime@ietf.org; Thu, 17 Aug 2006 11:48:20 -0400
Received: from imx11.toshiba.co.jp ([61.202.160.20])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDk6M-00068W-3M
	for dime@ietf.org; Thu, 17 Aug 2006 11:48:20 -0400
Received: from wall11.toshiba.co.jp (wall11 [133.199.90.149])
	by imx11.toshiba.co.jp  with ESMTP id k7HFlpMD000935;
	Fri, 18 Aug 2006 00:47:51 +0900 (JST)
Received: (from root@localhost) by wall11.toshiba.co.jp  id k7HFlpLP026543;
	Fri, 18 Aug 2006 00:47:51 +0900 (JST)
Received: from ovp11.toshiba.co.jp [133.199.90.148] 
	by wall11.toshiba.co.jp with SMTP id AAA26515;
	Fri, 18 Aug 2006 00:47:51 +0900
Received: from mx.toshiba.co.jp (localhost [127.0.0.1])
	by ovp11.toshiba.co.jp  with ESMTP id k7HFloCe026674;
	Fri, 18 Aug 2006 00:47:50 +0900 (JST)
Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k7HFloES004663;
	Fri, 18 Aug 2006 00:47:50 +0900 (JST)
Received: from steelhead ([133.120.196.135])
	by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built
	Apr 28
	2004)) with ESMTPSA id <0J4500DF6FVLKEJ0@mail.po.toshiba.co.jp>; Fri,
	18 Aug 2006 00:47:50 +0900 (JST)
Received: from ohba by steelhead with local (Exim 4.62)
	(envelope-from <yohba@tari.toshiba.com>)	id 1GDk5q-0005Dg-33; Thu,
	17 Aug 2006 08:47:38 -0700
Date: Thu, 17 Aug 2006 11:47:37 -0400
From: Yoshihiro Ohba <yohba@tari.toshiba.com>
Subject: Re: [Dime] Next Steps for draft-tsou-dime-base-routing-ext-00
In-reply-to: <44E37CD7.4000601@gmx.net>
To: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
Message-id: <20060817154737.GD18621@steelhead>
MIME-version: 1.0
Content-type: text/plain; charset=iso-2022-jp
Content-disposition: inline
References: <44E37CD7.4000601@gmx.net>
User-Agent: Mutt/1.5.11+cvs20060403
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

I think the content of draft-tsou-dime-base-routing-ext-00 should be
integrated into rfc3588bis, because I think source routing is needed
to support stateful agents and thus should be part of base protocol.

Also, I think that source routing issue can/should be discussed
separately from the Application Identifier issue.

Yoshihiro Ohba


On Wed, Aug 16, 2006 at 10:15:19PM +0200, Hannes Tschofenig wrote:
> Hi all,
> 
> we discussed this document during the IETF#66 DIME working group 
> meeting. The meeting participants did not express excitement. We would 
> like to solicit feedback from the working group to see whether there is 
> interest in this work and how we should proceed.
> 
> Ciao
> Hannes & John
> 
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www1.ietf.org/mailman/listinfo/dime

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



From dime-bounces@ietf.org Thu Aug 17 21:32:00 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GDtDG-0000Gr-HC; Thu, 17 Aug 2006 21:31:54 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GDtDE-0000Gj-El
	for dime@ietf.org; Thu, 17 Aug 2006 21:31:52 -0400
Received: from szxga01-in.huawei.com ([61.144.161.53])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDtDC-0000UA-Ls
	for dime@ietf.org; Thu, 17 Aug 2006 21:31:52 -0400
Received: from huawei.com (szxga01-in [172.24.2.3])
	by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0J460075E70NCG@szxga01-in.huawei.com> for
	dime@ietf.org; Fri, 18 Aug 2006 09:33:59 +0800 (CST)
Received: from huawei.com ([172.24.1.6])
	by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0J4600IA570MJH@szxga01-in.huawei.com> for
	dime@ietf.org; Fri, 18 Aug 2006 09:33:59 +0800 (CST)
Received: from CMTEST6 ([10.70.149.78])
	by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTPA id <0J4600AZX7ODPB@szxml02-in.huawei.com>; Fri,
	18 Aug 2006 09:48:14 +0800 (CST)
Date: Fri, 18 Aug 2006 09:31:24 +0800
From: Tina TSOU <tena@huawei.com>
Subject: Re: [Dime] Next Steps for draft-tsou-dime-base-routing-ext-00
To: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>,
	Yoshihiro Ohba <yohba@tari.toshiba.com>
Message-id: <003c01c6c266$04a060f0$4e95460a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
Content-type: text/plain; charset=iso-2022-jp
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <44E37CD7.4000601@gmx.net> <20060817154737.GD18621@steelhead>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

I agree with Yoshihiro.

B. R.
Tina
----- Original Message ----- 
From: "Yoshihiro Ohba" <yohba@tari.toshiba.com>
To: "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>
Cc: "Tina TSOU" <tena@huawei.com>; "Victor Fajardo" <vfajardo@tari.toshiba.com>; <dime@ietf.org>
Sent: Thursday, August 17, 2006 11:47 PM
Subject: Re: [Dime] Next Steps for draft-tsou-dime-base-routing-ext-00


> I think the content of draft-tsou-dime-base-routing-ext-00 should be
> integrated into rfc3588bis, because I think source routing is needed
> to support stateful agents and thus should be part of base protocol.
> 
> Also, I think that source routing issue can/should be discussed
> separately from the Application Identifier issue.
> 
> Yoshihiro Ohba
> 
> 
> On Wed, Aug 16, 2006 at 10:15:19PM +0200, Hannes Tschofenig wrote:
> > Hi all,
> > 
> > we discussed this document during the IETF#66 DIME working group 
> > meeting. The meeting participants did not express excitement. We would 
> > like to solicit feedback from the working group to see whether there is 
> > interest in this work and how we should proceed.
> > 
> > Ciao
> > Hannes & John
> > 
> > _______________________________________________
> > DiME mailing list
> > DiME@ietf.org
> > https://www1.ietf.org/mailman/listinfo/dime
> 

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



From dime-bounces@ietf.org Thu Aug 17 22:13:53 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GDtrt-00047l-FU; Thu, 17 Aug 2006 22:13:53 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GDtrs-00047c-0c
	for dime@ietf.org; Thu, 17 Aug 2006 22:13:52 -0400
Received: from sj-iport-1-in.cisco.com ([171.71.176.70]
	helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GDtrq-00062u-NO
	for dime@ietf.org; Thu, 17 Aug 2006 22:13:51 -0400
Received: from sj-dkim-1.cisco.com ([171.71.179.21])
	by sj-iport-1.cisco.com with ESMTP; 17 Aug 2006 19:13:50 -0700
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254])
	by sj-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id
	k7I2Dodp013589; Thu, 17 Aug 2006 19:13:50 -0700
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com
	[171.70.151.144])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k7I2DoYp005531;
	Thu, 17 Aug 2006 19:13:50 -0700 (PDT)
Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by
	xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Thu, 17 Aug 2006 19:13:49 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
Subject: RE: [Dime] Next Steps for draft-tsou-dime-base-routing-ext-00
Date: Thu, 17 Aug 2006 19:13:48 -0700
Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB26250279D852@xmb-sjc-215.amer.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Dime] Next Steps for draft-tsou-dime-base-routing-ext-00
Thread-Index: AcbCFLa+iKpEBfdcQryrV+ZtKfWezQAU9RxA
From: "Glen Zorn \(gwz\)" <gwz@cisco.com>
To: "Yoshihiro Ohba" <yohba@tari.toshiba.com>
X-OriginalArrivalTime: 18 Aug 2006 02:13:50.0039 (UTC)
	FILETIME=[F1C8B670:01C6C26B]
DKIM-Signature: a=rsa-sha1; q=dns; l=614; t=1155867230; x=1156731230;
	c=relaxed/simple; s=sjdkim1002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=gwz@cisco.com;
	z=From:=22Glen=20Zorn=20\(gwz\)=22=20<gwz@cisco.com>
	|Subject:RE=3A=20[Dime]=20Next=20Steps=20for=20draft-tsou-dime-base-routing-ext-0
	0; X=v=3Dcisco.com=3B=20h=3DO/PlCPiXc8YIrfSrH9C5g7t57sk=3D;
	b=W7M1jJ9hETsxzdoUzufZNTCRqQEPBa+IcoURZqjFRZPBU2T8vuCl9F/VBYkl5aNaEaOAlNCi
	duNMeOPNmEIr/wfI1qhl7uBL9I6yR+AcJQE3yFmhkCiJmRY2xRp7ifLw;
Authentication-Results: sj-dkim-1.cisco.com; header.From=gwz@cisco.com;
	dkim=pass ( sig from cisco.com verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

Yoshihiro Ohba <mailto:yohba@tari.toshiba.com> supposedly scribbled:

> I think the content of draft-tsou-dime-base-routing-ext-00 should be
> integrated into rfc3588bis, because I think source routing is needed
> to support stateful agents 

Assuming that some Diameter agents currently exist & given that Diameter agents are by definition stateful (see RFC 3588, section 1.3, "Transaction State", it's hard to see how this statement can be correct.

...

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by simply
  listening to John Coltrane? -- Henry Gabriel

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



From dime-bounces@ietf.org Fri Aug 18 02:11:55 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GDxa5-0002wV-2p; Fri, 18 Aug 2006 02:11:45 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GDxa4-0002wP-A0
	for dime@ietf.org; Fri, 18 Aug 2006 02:11:44 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129]
	helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GDwNk-0001A4-Pb
	for dime@ietf.org; Fri, 18 Aug 2006 00:54:56 -0400
Received: from szxga03-in.huawei.com ([61.144.161.55])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GDw9Q-0008En-0i
	for dime@ietf.org; Fri, 18 Aug 2006 00:40:21 -0400
Received: from huawei.com (szxga03-in [172.24.2.9])
	by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0J46001IKG2K2I@szxga03-in.huawei.com> for
	dime@ietf.org; Fri, 18 Aug 2006 12:49:32 +0800 (CST)
Received: from huawei.com ([172.24.1.3])
	by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0J4600BSZG2BJB@szxga03-in.huawei.com> for
	dime@ietf.org; Fri, 18 Aug 2006 12:49:32 +0800 (CST)
Received: from CMTEST6 ([10.70.149.78])
	by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTPA id <0J4600C20DBOYG@szxml01-in.huawei.com>; Fri,
	18 Aug 2006 11:50:12 +0800 (CST)
Date: Fri, 18 Aug 2006 11:28:55 +0800
From: Tina TSOU <tena@huawei.com>
Subject: Re: [Dime] Next Steps for draft-tsou-dime-base-routing-ext-00
To: Yoshihiro Ohba <yohba@tari.toshiba.com>, "Glen Zorn (gwz)" <gwz@cisco.com>
Message-id: <009001c6c276$6f3aece0$4e95460a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
Content-type: text/plain; charset=iso-2022-jp
Content-transfer-encoding: 7BIT
X-Priority: 3
X-MSMail-priority: Normal
References: <4C0FAAC489C8B74F96BEAD85EAEB26250279D852@xmb-sjc-215.amer.cisco.com>
X-Spam-Score: -2.6 (--)
X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

Hi Glen,
Then what's your concrete proposal to proceed with this draft? :)

B. R.
Tina
//Looking forward to the weekend...

----- Original Message ----- 
From: "Glen Zorn (gwz)" <gwz@cisco.com>
To: "Yoshihiro Ohba" <yohba@tari.toshiba.com>
Cc: <dime@ietf.org>
Sent: Friday, August 18, 2006 10:13 AM
Subject: RE: [Dime] Next Steps for draft-tsou-dime-base-routing-ext-00


> Yoshihiro Ohba <mailto:yohba@tari.toshiba.com> supposedly scribbled:
> 
> > I think the content of draft-tsou-dime-base-routing-ext-00 should be
> > integrated into rfc3588bis, because I think source routing is needed
> > to support stateful agents 
> 
> Assuming that some Diameter agents currently exist & given that Diameter agents are by definition stateful (see RFC 3588, section 1.3, "Transaction State", it's hard to see how this statement can be correct.
> 
> ...
> 
> Hope this helps,
> 
> ~gwz
> 
> Why is it that most of the world's problems can't be solved by simply
> 
>   listening to John Coltrane? -- Henry Gabriel
> 
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www1.ietf.org/mailman/listinfo/dime
> 

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



From dime-bounces@ietf.org Fri Aug 18 12:40:20 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GE7OK-0002dP-KX; Fri, 18 Aug 2006 12:40:16 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GE7OK-0002dK-EJ
	for dime@ietf.org; Fri, 18 Aug 2006 12:40:16 -0400
Received: from bw.ulticom.com ([208.255.120.38])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GE7OI-0000l2-1g
	for dime@ietf.org; Fri, 18 Aug 2006 12:40:16 -0400
Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP
	id C40A89E3B3; Fri, 18 Aug 2006 12:40:13 -0400 (EDT)
Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55])
	by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k7IGe72m021921;
	Fri, 18 Aug 2006 12:40:12 -0400 (EDT)
From: "Tolga Asveren" <asveren@ulticom.com>
To: "Yoshihiro Ohba" <yohba@tari.toshiba.com>
Subject: RE: [Dime] Next Steps for draft-tsou-dime-base-routing-ext-00
Date: Fri, 18 Aug 2006 12:15:53 -0400
Message-ID: <GBEBKGPKHGPAOFCLBNAMMEJPEHAA.asveren@ulticom.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
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: <20060817154737.GD18621@steelhead>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506
Importance: Normal
Received-SPF: none
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

Hi Yoshihiro,


> -----Original Message-----
> From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com]
> Sent: Thursday, August 17, 2006 11:48 AM
> To: Hannes Tschofenig
> Cc: dime@ietf.org
> Subject: Re: [Dime] Next Steps for draft-tsou-dime-base-routing-ext-00
>
>
> I think the content of draft-tsou-dime-base-routing-ext-00 should be
> integrated into rfc3588bis, because I think source routing is needed
> to support stateful agents and thus should be part of base protocol.
[TOLGA]I think we should distinguish between intermediaries, which advertise
support for individual applications instead of 0xffffffff but are not really
stateful and which are really stateful. Currently being stateful and
advertising specific application support is tied together in RFC3588 by
definition of a proxy but I don't think it needs to be. Acctually not doing
so is not violation of the protocol, just defining a new node type, which is
not explicitly mentioned in RFC3588.

An example for the first one is a load-balancer for a specific application.
It is interested to get only messages for a specific application but doesn't
keep session related state. If a message does not have Destination-Host AVP,
it forwards the message to a server based on congestion status of servers
(how this information is propogated is topic for another thread). If a
message has Destination-Host AVP, it just sends the message to that server.

For that first type of intermediaries, everything would be working fine if
AppId!=0 is used for common messages. Otherwise, a relay agent in front of
load balancers serving different applications is enough to have common
messages not routable to the correct load balancer.

For second type of nodes, which are stateful and want to stay on the message
path, a mechanism as described in the draft is usefull. There could be other
solutions as well -which we discussed to some extent on the list-, and I
would prefer them to be explained -somewhere-.

>
> Also, I think that source routing issue can/should be discussed
> separately from the Application Identifier issue.
[TOLGA]I see some correlation because using AppId=0 for common messages
breaks routability of such messages for some configurations and the draft
provides a solution for that. Otherwise, the draft is useful only for
intermediares, which want to stay on the path during a session.
>
> Yoshihiro Ohba
>
>
> On Wed, Aug 16, 2006 at 10:15:19PM +0200, Hannes Tschofenig wrote:
> > Hi all,
> >
> > we discussed this document during the IETF#66 DIME working group
> > meeting. The meeting participants did not express excitement. We would
> > like to solicit feedback from the working group to see whether there is
> > interest in this work and how we should proceed.
> >
> > Ciao
> > Hannes & John
> >
> > _______________________________________________
> > DiME mailing list
> > DiME@ietf.org
> > https://www1.ietf.org/mailman/listinfo/dime
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www1.ietf.org/mailman/listinfo/dime


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



From dime-bounces@ietf.org Fri Aug 18 12:52:35 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GE7aF-0000Kt-Ik; Fri, 18 Aug 2006 12:52:35 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GE7aE-0000Kl-Ta
	for dime@ietf.org; Fri, 18 Aug 2006 12:52:34 -0400
Received: from smtp2.int-evry.fr ([157.159.10.45])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GE7aE-0002Vo-7x
	for dime@ietf.org; Fri, 18 Aug 2006 12:52:34 -0400
Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76])
	by smtp2.int-evry.fr (Postfix) with ESMTP id 3D2762FDD5;
	Fri, 18 Aug 2006 18:52:23 +0200 (CEST)
Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.52)
	id 1GE7c0-0006Iz-GE; Fri, 18 Aug 2006 18:54:24 +0200
Date: Fri, 18 Aug 2006 18:54:24 +0200
From: Julien Bournelle <julien.bournelle@int-evry.fr>
To: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
Subject: Re: [Dime] Mobile IPv6 Bootstrapping - "Application ID" vs.
	"NAS-Port-Type AVP/Service-Type": Summary
Message-ID: <20060818165424.GA24233@ipv6-3.int-evry.fr>
References: <44E3853B.2090406@gmx.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <44E3853B.2090406@gmx.net>
User-Agent: Mutt/1.5.9i
X-INT-MailScanner-Information: Please contact the ISP for more information
X-INT-MailScanner: Found to be clean
X-INT-MailScanner-MCPCheck: 
X-INT-MailScanner-SpamCheck: 
X-MailScanner-From: jb@int-evry.fr
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 65bc4909d78e8b10349def623cf7a1d1
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

Hi hannes,

 thanks for this clarifying mail.


On Wed, Aug 16, 2006 at 10:51:07PM +0200, Hannes Tschofenig wrote:
> Hi all,
> 
> I went through the discussion again and noticed that we haven't reached 
> a conclusion.
> 
> Here is my impression:
> 
> * RFC 3588 leaves a question regarding the extensibility open.
>   This needs to be captured in the revision of the base specification.
> 
> * The main issue seems to be
> 
>   - Do we want to route 'Diameter EAP' message and 'Diameter Mobile 
> IPv6 Bootstrapping' messages differently?

 I tend to think that it is safer to assume that some operators may
 desire that.

> 
>     If we want to route them differently then we need to define 
> 'Diameter MIPv6 Bootstrapping' as a Diameter application.
> 
>   - The AAA server differentiates ordinary network access and MIPv6 
> bootstrapping functionality (with respect to authorization and 
> accounting). In order to do so it must understand the Service-Type 
> and/or NAS-Port-Type AVPs and the defined values.
> 
>     Is this a problem?

 Not sure to understand this problem. For me, if we have the App-Id we
 don't need Service-Type nor NAS-Port Type.
 IF we don't have the App-ID, yes we need to define new values.

 Maybe i missed the problem you raised.

 regards,

 Julien

> 
>   - There are problems with proxies and newly defined Diameter 
> Application IDs. Every
> proxy on the path needs new code to handle the new application, while
> just adding an extra AVP or new Service-Type value does not hurt.
> 
>     Is this an issue for us?
> 
> Ciao
> Hannes
> 
> PS: Here is copy-and-paste version of some discussion snippets to allow 
> others to catch-up.
> 
> Julien starts the discussion with a question about Application IDs.
> 
> Pasi suggests to consider Service-Type and/or NAS-Port-Type AVPs as 
> well.... the problem starts.
> 
> Avi states that the problem is that neither Service-Type or Port-Type is 
> mandatory.
> "
> Service Type seems to be the correct way but in RADIUS and
> Diameter service-type also can be authenticate-only or authorize-only.
> So what if the HA wanted to authenticate-only or authorize-only for the
> MIP service?  I would lose the ability to also indicate that this is an
> HA.
> 
> So Port-Type seems to be the way to go....
> "
> 
> Jari jumps in:
> "
> One of the reasons why an existing application would
> be preferred is that then a AAA server that does not
> care about the type of service can be used without
> changes. Yet servers that do care can look at the
> AVPs and make more detailed authorization
> decisions.
> 
> 
> RFC 3588 states that  "Creation of a new application
> should be viewed as a last resort." and that "In order
> to justify allocation of a new application identifier,
> Diameter applications MUST define one Command Code,
> or add new mandatory AVPs to the ABNF." Note that
> mandatory AVPs can be viewed in different ways,
> and that we should not be too strict about them.
> For instance, Framed-Protocol is an optional AVP in
> RFCs 4005 and 4072. Yet, you could argue that if you
> are doing PPP then you need to use this attribute and
> set it to PPP. But that didn't make the attribute mandatory.
> Do we have a similar situation for the IKEv2/MIPv6
> attributes and values? They are not necessary from
> the NASREQ/EAP perspective, but in the specific context
> you need to use the attributes. In my mind, this does not
> make the attributes mandatory from a Diameter
> application point of view. If we start creating
> new applications for every different situation,
> we'll have lots of applications and interoperability
> problems. Its better to add new optional AVPs and
> describe in text when they should be used. The
> only exception that I see is security related AVPs
> that must be understood by the other side or else
> the session should be terminated.
> "
> 
> Avi responds:
> "
> Mandatory does not mean required in the Command.  It means that it must
> be understood by the receiver.  We need to clarify that.
> "
> 
> Gerardo and Lionel agree with Jari.
> 
> 
> 
> Avi writes:
> "
> If I have two EAP based application in my network, one that is
> handling pure EAP application, the other is extended to handle the new
> behavior then I need a way to route the (same) command correctly.
> "
> 
> Jari writes:
> "
> Ah, but that is a new requirement. If you believe that you need
> to route EAP authentication from a 802.11 AP differently
> than from IKEv2/MIPv6, then you need one of these:
> 
> - Use different user/domain names for the users of
>   the different services.
> 
> - Point to different servers from the AP and SGW (but
>   this works less well if you have proxies and roaming).
> 
> - New application ID.
> 
> - Some weird form of Diameter and RADIUS source routing
>   based on what type of node sent the message.
> 
> However, it is far from clear to me why you would really
> need to route the authentication differently *for the same
> user*. Many authentication mechanisms can also have state,
> which would imply that at the end they need to end up in
> the same device anyhow. Can you expand on why you need
> to handle the same users in different authentication
> servers?
> "
> 
> Avi to Jari:
> 
> "
> BTW in the context of the original question raised, the attribute(s)
> will not be optional. Here is the snippet:
> 
> >> >>  In our case, the AAA server must perform AAA functionality for the
> >> >> Mobile IPv6 service. The AAA server must know that it has to
> >> >> authorize the mip6 service and the accounting (ASR/ASA) is also for
> >> >>  mip6 and not for network access.
> 
> If the Diameter message comes from the HA then the HA MUST include the
> NAS-Port-type attribute. So the command ABNF is being changed. Also the
> behavior is being changed of the Server.  It MUST recognize the (new)
> value of the NAS-Port-Type.
> "
> 
> 
> Yoshi says:
> "
> If what is important is service-specific routing (I am not convinced
> with it yet), I'd suggest defining a new authorization-only
> application used only for carrying service-specific attributes
> (analogous to NASREQ usage in RFC 4072).  The downside is that it
> needs another message roundtrip than carrying the attributes in
> DER/DEA.
> "
> 
> 
> Julien wrote:
> "
> > >
> > > I don't think it's clean to require use of different
> > > users'identifiers in order to distinguish which services is
> > > provided. For me, it looks like a 'hack'.
> " and Pasi responded:
> "
> I fully agree -- but having separate user identifiers should not be
> necessary. If, for example, an operator wants to perform different
> authorizations for WiFi and WiMAX (e.g., some users can access only
> WiFi but not WiMAX), that's simple to do: just check Service-Type,
> NAS-Port-Type, and other relevant authorization AVPs.  There's
> absolutely no need to create a new Diameter application.
> 
> If the AAA server is really strict about WiFi vs. WiMAX separation, it
> can have a policy that requires the NAS-Port-Type AVP to be present
> (if the request does not contain it, access is denied). Although this
> in some sense make NAS-Port-Type AVP "mandatory", it's not "mandatory"
> in the sense that would require a new Diameter application.
> 
> While IKEv2 and MIP6 are not WiFi and WiMAX, I don't think there are
> any significant differences from Diameter point-of-view. There's a box
> providing some service; authentication works with EAP; authorization
> AVPs indicate what exactly is being authorized. What's missing is
> a document describing how the different authorization AVPs are
> used in this particular situation; sort of like RFC 3580 (IEEE 802.1X
> RADIUS Usage Guidelines), but for Diameter with IKEv2.
> 
> One important reason NOT to create new applications: proxies. Every
> proxy on the path needs new code to handle the new application, while
> just adding an extra AVP or new Service-Type value doesn't.
> "
> 
> John agrees with Pasi.
> 
> Avi writes:
> "
> A mandatory attribute (a must understand attribute) that has a new
> enumeration is in my mind is like adding a new attribute that must be
> understood.  There is no wigle room here.  The command carrying that
> attribute must reach the implementation that knows how to interpret the
> attribute.  This is  because an implmentation that does not understand
> Service-Type = X must return an error.
> 
> It is obvious that the rules in 3588 are not sufficient to describe when
> to use a new Application ID or not.  And we should not have to have a
> debate on this topic.
> 
> BTW if we do what you say then in networks where I have NASREQ
> performing Network Access and now I want to roll out MIPv6 I would have
> to upgrade all my old NASREQ deployed applications.  This is wrong.  I
> should be able to add a MIPv6 compliant diameter application without
> having to force upgrading my NASREQ applications.
> "
> 
> 
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www1.ietf.org/mailman/listinfo/dime

-- 
julien.bournelle at int-evry.fr

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



From dime-bounces@ietf.org Fri Aug 18 14:42:41 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GE9Ii-0001PJ-UO; Fri, 18 Aug 2006 14:42:36 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GE9Ih-0001PB-FG
	for dime@ietf.org; Fri, 18 Aug 2006 14:42:35 -0400
Received: from mx0.starentnetworks.com ([12.38.223.203])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GE9If-0005w1-OO
	for dime@ietf.org; Fri, 18 Aug 2006 14:42:35 -0400
Received: from localhost (localhost.localdomain [127.0.0.1])
	by mx0.starentnetworks.com (Postfix) with ESMTP id 2D41D9004A;
	Fri, 18 Aug 2006 14:42:29 -0400 (EDT)
Received: from mx0.starentnetworks.com ([127.0.0.1])
	by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 03459-08; Fri, 18 Aug 2006 14:42:27 -0400 (EDT)
Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com
	[12.33.233.52]) by mx0.starentnetworks.com (Postfix) with ESMTP;
	Fri, 18 Aug 2006 14:42:27 -0400 (EDT)
X-MessageTextProcessor: DisclaimIt (2.70.271) [Starent Networks Corp.]
Received: from exchtewks2.starentnetworks.com ([12.33.232.12]) by
	exchtewks1.starentnetworks.com with Microsoft
	SMTPSVC(6.0.3790.1830); Fri, 18 Aug 2006 14:42:27 -0400
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Dime] Mobile IPv6 Bootstrapping - "Application ID"
	vs."NAS-Port-Type AVP/Service-Type": Summary
Date: Fri, 18 Aug 2006 14:42:27 -0400
Message-ID: <7CCD07160348804497EF29E9EA5560D78371FE@exchtewks2.starentnetworks.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Dime] Mobile IPv6 Bootstrapping - "Application ID"
	vs."NAS-Port-Type AVP/Service-Type": Summary
thread-index: AcbC5sGAEwSWRY6cTNuCYNF2mep/KgADodEA
From: "Chowdhury, Kuntal" <kchowdhury@starentnetworks.com>
Importance: normal
To: "Julien Bournelle" <julien.bournelle@int-evry.fr>,
	"Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>
Priority: normal
X-OriginalArrivalTime: 18 Aug 2006 18:42:27.0909 (UTC)
	FILETIME=[0DFD5F50:01C6C2F6]
X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: fcb459c204557d9509ce9c1b55d771f1
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

Hi Hannes, Julien,

Application-ID is one way, but as has been discussed so far it requires
changes in the intermediaries. A new value in NAS-Port-Type AVP seems
more logical and easier to implement, IMHO. I am not sure about the
Service-Type AVP. I am wondering what cannot be conveyed via
NAS-Port-Type AVP so that we need this additional AVP?

Apologize for jumping in late....still trying to understand the whole
issue.

-Kuntal


> -----Original Message-----
> From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr]
> Sent: Friday, August 18, 2006 11:54 AM
> To: Hannes Tschofenig
> Cc: dime@ietf.org
> Subject: Re: [Dime] Mobile IPv6 Bootstrapping - "Application ID"
vs."NAS-
> Port-Type AVP/Service-Type": Summary
>=20
> Hi hannes,
>=20
>  thanks for this clarifying mail.
>=20
>=20
> On Wed, Aug 16, 2006 at 10:51:07PM +0200, Hannes Tschofenig wrote:
> > Hi all,
> >
> > I went through the discussion again and noticed that we haven't
reached
> > a conclusion.
> >
> > Here is my impression:
> >
> > * RFC 3588 leaves a question regarding the extensibility open.
> >   This needs to be captured in the revision of the base
specification.
> >
> > * The main issue seems to be
> >
> >   - Do we want to route 'Diameter EAP' message and 'Diameter Mobile
> > IPv6 Bootstrapping' messages differently?
>=20
>  I tend to think that it is safer to assume that some operators may
>  desire that.
>=20
> >
> >     If we want to route them differently then we need to define
> > 'Diameter MIPv6 Bootstrapping' as a Diameter application.
> >
> >   - The AAA server differentiates ordinary network access and MIPv6
> > bootstrapping functionality (with respect to authorization and
> > accounting). In order to do so it must understand the Service-Type
> > and/or NAS-Port-Type AVPs and the defined values.
> >
> >     Is this a problem?
>=20
>  Not sure to understand this problem. For me, if we have the App-Id we
>  don't need Service-Type nor NAS-Port Type.
>  IF we don't have the App-ID, yes we need to define new values.
>=20
>  Maybe i missed the problem you raised.
>=20
>  regards,
>=20
>  Julien
>=20
> >
> >   - There are problems with proxies and newly defined Diameter
> > Application IDs. Every
> > proxy on the path needs new code to handle the new application,
while
> > just adding an extra AVP or new Service-Type value does not hurt.
> >
> >     Is this an issue for us?
> >
> > Ciao
> > Hannes
> >
> > PS: Here is copy-and-paste version of some discussion snippets to
allow
> > others to catch-up.
> >
> > Julien starts the discussion with a question about Application IDs.
> >
> > Pasi suggests to consider Service-Type and/or NAS-Port-Type AVPs as
> > well.... the problem starts.
> >
> > Avi states that the problem is that neither Service-Type or
Port-Type is
> > mandatory.
> > "
> > Service Type seems to be the correct way but in RADIUS and
> > Diameter service-type also can be authenticate-only or
authorize-only.
> > So what if the HA wanted to authenticate-only or authorize-only for
the
> > MIP service?  I would lose the ability to also indicate that this is
an
> > HA.
> >
> > So Port-Type seems to be the way to go....
> > "
> >
> > Jari jumps in:
> > "
> > One of the reasons why an existing application would
> > be preferred is that then a AAA server that does not
> > care about the type of service can be used without
> > changes. Yet servers that do care can look at the
> > AVPs and make more detailed authorization
> > decisions.
> >
> >
> > RFC 3588 states that  "Creation of a new application
> > should be viewed as a last resort." and that "In order
> > to justify allocation of a new application identifier,
> > Diameter applications MUST define one Command Code,
> > or add new mandatory AVPs to the ABNF." Note that
> > mandatory AVPs can be viewed in different ways,
> > and that we should not be too strict about them.
> > For instance, Framed-Protocol is an optional AVP in
> > RFCs 4005 and 4072. Yet, you could argue that if you
> > are doing PPP then you need to use this attribute and
> > set it to PPP. But that didn't make the attribute mandatory.
> > Do we have a similar situation for the IKEv2/MIPv6
> > attributes and values? They are not necessary from
> > the NASREQ/EAP perspective, but in the specific context
> > you need to use the attributes. In my mind, this does not
> > make the attributes mandatory from a Diameter
> > application point of view. If we start creating
> > new applications for every different situation,
> > we'll have lots of applications and interoperability
> > problems. Its better to add new optional AVPs and
> > describe in text when they should be used. The
> > only exception that I see is security related AVPs
> > that must be understood by the other side or else
> > the session should be terminated.
> > "
> >
> > Avi responds:
> > "
> > Mandatory does not mean required in the Command.  It means that it
must
> > be understood by the receiver.  We need to clarify that.
> > "
> >
> > Gerardo and Lionel agree with Jari.
> >
> >
> >
> > Avi writes:
> > "
> > If I have two EAP based application in my network, one that is
> > handling pure EAP application, the other is extended to handle the
new
> > behavior then I need a way to route the (same) command correctly.
> > "
> >
> > Jari writes:
> > "
> > Ah, but that is a new requirement. If you believe that you need
> > to route EAP authentication from a 802.11 AP differently
> > than from IKEv2/MIPv6, then you need one of these:
> >
> > - Use different user/domain names for the users of
> >   the different services.
> >
> > - Point to different servers from the AP and SGW (but
> >   this works less well if you have proxies and roaming).
> >
> > - New application ID.
> >
> > - Some weird form of Diameter and RADIUS source routing
> >   based on what type of node sent the message.
> >
> > However, it is far from clear to me why you would really
> > need to route the authentication differently *for the same
> > user*. Many authentication mechanisms can also have state,
> > which would imply that at the end they need to end up in
> > the same device anyhow. Can you expand on why you need
> > to handle the same users in different authentication
> > servers?
> > "
> >
> > Avi to Jari:
> >
> > "
> > BTW in the context of the original question raised, the attribute(s)
> > will not be optional. Here is the snippet:
> >
> > >> >>  In our case, the AAA server must perform AAA functionality
for
> the
> > >> >> Mobile IPv6 service. The AAA server must know that it has to
> > >> >> authorize the mip6 service and the accounting (ASR/ASA) is
also
> for
> > >> >>  mip6 and not for network access.
> >
> > If the Diameter message comes from the HA then the HA MUST include
the
> > NAS-Port-type attribute. So the command ABNF is being changed. Also
the
> > behavior is being changed of the Server.  It MUST recognize the
(new)
> > value of the NAS-Port-Type.
> > "
> >
> >
> > Yoshi says:
> > "
> > If what is important is service-specific routing (I am not convinced
> > with it yet), I'd suggest defining a new authorization-only
> > application used only for carrying service-specific attributes
> > (analogous to NASREQ usage in RFC 4072).  The downside is that it
> > needs another message roundtrip than carrying the attributes in
> > DER/DEA.
> > "
> >
> >
> > Julien wrote:
> > "
> > > >
> > > > I don't think it's clean to require use of different
> > > > users'identifiers in order to distinguish which services is
> > > > provided. For me, it looks like a 'hack'.
> > " and Pasi responded:
> > "
> > I fully agree -- but having separate user identifiers should not be
> > necessary. If, for example, an operator wants to perform different
> > authorizations for WiFi and WiMAX (e.g., some users can access only
> > WiFi but not WiMAX), that's simple to do: just check Service-Type,
> > NAS-Port-Type, and other relevant authorization AVPs.  There's
> > absolutely no need to create a new Diameter application.
> >
> > If the AAA server is really strict about WiFi vs. WiMAX separation,
it
> > can have a policy that requires the NAS-Port-Type AVP to be present
> > (if the request does not contain it, access is denied). Although
this
> > in some sense make NAS-Port-Type AVP "mandatory", it's not
"mandatory"
> > in the sense that would require a new Diameter application.
> >
> > While IKEv2 and MIP6 are not WiFi and WiMAX, I don't think there are
> > any significant differences from Diameter point-of-view. There's a
box
> > providing some service; authentication works with EAP; authorization
> > AVPs indicate what exactly is being authorized. What's missing is
> > a document describing how the different authorization AVPs are
> > used in this particular situation; sort of like RFC 3580 (IEEE
802.1X
> > RADIUS Usage Guidelines), but for Diameter with IKEv2.
> >
> > One important reason NOT to create new applications: proxies. Every
> > proxy on the path needs new code to handle the new application,
while
> > just adding an extra AVP or new Service-Type value doesn't.
> > "
> >
> > John agrees with Pasi.
> >
> > Avi writes:
> > "
> > A mandatory attribute (a must understand attribute) that has a new
> > enumeration is in my mind is like adding a new attribute that must
be
> > understood.  There is no wigle room here.  The command carrying that
> > attribute must reach the implementation that knows how to interpret
the
> > attribute.  This is  because an implmentation that does not
understand
> > Service-Type =3D X must return an error.
> >
> > It is obvious that the rules in 3588 are not sufficient to describe
when
> > to use a new Application ID or not.  And we should not have to have
a
> > debate on this topic.
> >
> > BTW if we do what you say then in networks where I have NASREQ
> > performing Network Access and now I want to roll out MIPv6 I would
have
> > to upgrade all my old NASREQ deployed applications.  This is wrong.
I
> > should be able to add a MIPv6 compliant diameter application without
> > having to force upgrading my NASREQ applications.
> > "
> >
> >
> > _______________________________________________
> > DiME mailing list
> > DiME@ietf.org
> > https://www1.ietf.org/mailman/listinfo/dime
>=20
> --
> julien.bournelle at int-evry.fr
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www1.ietf.org/mailman/listinfo/dime


"This email message and any attachments are confidential information of =
Starent Networks, Corp. The information transmitted may not be used to =
create or change any contractual obligations of Starent Networks, Corp.  =
Any review, retransmission, dissemination or other use of, or taking of =
any action in reliance upon this e-mail and its attachments by persons =
or entities other than the intended recipient is prohibited. If you are =
not the intended recipient, please notify the sender immediately -- by =
replying to this message or by sending an email to =
postmaster@starentnetworks.com -- and destroy all copies of this message =
and any attachments without reading or disclosing their contents. Thank =
you."

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



From dime-bounces@ietf.org Sat Aug 19 05:59:00 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GENbG-0000rz-91; Sat, 19 Aug 2006 05:58:42 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GENbF-0000ru-Js
	for dime@ietf.org; Sat, 19 Aug 2006 05:58:41 -0400
Received: from smtp2.int-evry.fr ([157.159.10.45])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GENbE-0007Mf-Rz
	for dime@ietf.org; Sat, 19 Aug 2006 05:58:41 -0400
Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76])
	by smtp2.int-evry.fr (Postfix) with ESMTP id 0F9662FDAC;
	Sat, 19 Aug 2006 11:58:28 +0200 (CEST)
Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.52)
	id 1GENcy-0006PW-Bp; Sat, 19 Aug 2006 12:00:28 +0200
Date: Sat, 19 Aug 2006 12:00:28 +0200
From: Julien Bournelle <julien.bournelle@int-evry.fr>
To: "Chowdhury, Kuntal" <kchowdhury@starentnetworks.com>
Subject: Re: [Dime] Mobile IPv6 Bootstrapping - "Application ID"
	vs."NAS-Port-Type AVP/Service-Type": Summary
Message-ID: <20060819100028.GA24638@ipv6-3.int-evry.fr>
References: <7CCD07160348804497EF29E9EA5560D78371FE@exchtewks2.starentnetworks.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <7CCD07160348804497EF29E9EA5560D78371FE@exchtewks2.starentnetworks.com>
User-Agent: Mutt/1.5.9i
X-INT-MailScanner-Information: Please contact the ISP for more information
X-INT-MailScanner: Found to be clean
X-INT-MailScanner-MCPCheck: 
X-INT-MailScanner-SpamCheck: 
X-MailScanner-From: jb@int-evry.fr
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 79bb66f827e54e9d5c5c7f1f9d645608
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

Hi all,


On Fri, Aug 18, 2006 at 02:42:27PM -0400, Chowdhury, Kuntal wrote:
> Hi Hannes, Julien,
> 
> Application-ID is one way, but as has been discussed so far it requires
> changes in the intermediaries. A new value in NAS-Port-Type AVP seems
> more logical and easier to implement, IMHO. I am not sure about the
> Service-Type AVP. I am wondering what cannot be conveyed via
> NAS-Port-Type AVP so that we need this additional AVP?

 For the integrated scenario, the issue is different. The reason is
 that, in this case, we're doing AAA operations for network access and
 we use that to provide HA info. After getting network access, the MN
 falls in the split case and use IKEv2 with the HA (and we have AAA
 again described in draft-ietf-dime-split-OO.txt). 

 However, it could be interesting for the AAA server to know if the NAS
 support the "Integrated case"' operations. This is why we thought that
 we could add an AVP sent from the NAS to the AAA indicating this feature.
 This could be done during CER/CEA exchange. But if we do this, if we
 have intermediaries AAA equipments, the final AAA server won't know.

 So it seems better to add an AVP in DER or AAR messages (messages sent
 by the NAS to the AAA infrastructure). Having said that, a new
 NAS-Port-Type may be needed.

> Apologize for jumping in late....still trying to understand the whole
> issue.

 No problem Kuntal, your opinion on this subject is really needed. I
 hope my quick explanation will help you to catch the whole issue.

 Regards,

 Julien

> 
> -Kuntal
> 
> 
> > -----Original Message-----
> > From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr]
> > Sent: Friday, August 18, 2006 11:54 AM
> > To: Hannes Tschofenig
> > Cc: dime@ietf.org
> > Subject: Re: [Dime] Mobile IPv6 Bootstrapping - "Application ID"
> vs."NAS-
> > Port-Type AVP/Service-Type": Summary
> > 
> > Hi hannes,
> > 
> >  thanks for this clarifying mail.
> > 
> > 
> > On Wed, Aug 16, 2006 at 10:51:07PM +0200, Hannes Tschofenig wrote:
> > > Hi all,
> > >
> > > I went through the discussion again and noticed that we haven't
> reached
> > > a conclusion.
> > >
> > > Here is my impression:
> > >
> > > * RFC 3588 leaves a question regarding the extensibility open.
> > >   This needs to be captured in the revision of the base
> specification.
> > >
> > > * The main issue seems to be
> > >
> > >   - Do we want to route 'Diameter EAP' message and 'Diameter Mobile
> > > IPv6 Bootstrapping' messages differently?
> > 
> >  I tend to think that it is safer to assume that some operators may
> >  desire that.
> > 
> > >
> > >     If we want to route them differently then we need to define
> > > 'Diameter MIPv6 Bootstrapping' as a Diameter application.
> > >
> > >   - The AAA server differentiates ordinary network access and MIPv6
> > > bootstrapping functionality (with respect to authorization and
> > > accounting). In order to do so it must understand the Service-Type
> > > and/or NAS-Port-Type AVPs and the defined values.
> > >
> > >     Is this a problem?
> > 
> >  Not sure to understand this problem. For me, if we have the App-Id we
> >  don't need Service-Type nor NAS-Port Type.
> >  IF we don't have the App-ID, yes we need to define new values.
> > 
> >  Maybe i missed the problem you raised.
> > 
> >  regards,
> > 
> >  Julien
> > 
> > >
> > >   - There are problems with proxies and newly defined Diameter
> > > Application IDs. Every
> > > proxy on the path needs new code to handle the new application,
> while
> > > just adding an extra AVP or new Service-Type value does not hurt.
> > >
> > >     Is this an issue for us?
> > >
> > > Ciao
> > > Hannes
> > >
> > > PS: Here is copy-and-paste version of some discussion snippets to
> allow
> > > others to catch-up.
> > >
> > > Julien starts the discussion with a question about Application IDs.
> > >
> > > Pasi suggests to consider Service-Type and/or NAS-Port-Type AVPs as
> > > well.... the problem starts.
> > >
> > > Avi states that the problem is that neither Service-Type or
> Port-Type is
> > > mandatory.
> > > "
> > > Service Type seems to be the correct way but in RADIUS and
> > > Diameter service-type also can be authenticate-only or
> authorize-only.
> > > So what if the HA wanted to authenticate-only or authorize-only for
> the
> > > MIP service?  I would lose the ability to also indicate that this is
> an
> > > HA.
> > >
> > > So Port-Type seems to be the way to go....
> > > "
> > >
> > > Jari jumps in:
> > > "
> > > One of the reasons why an existing application would
> > > be preferred is that then a AAA server that does not
> > > care about the type of service can be used without
> > > changes. Yet servers that do care can look at the
> > > AVPs and make more detailed authorization
> > > decisions.
> > >
> > >
> > > RFC 3588 states that  "Creation of a new application
> > > should be viewed as a last resort." and that "In order
> > > to justify allocation of a new application identifier,
> > > Diameter applications MUST define one Command Code,
> > > or add new mandatory AVPs to the ABNF." Note that
> > > mandatory AVPs can be viewed in different ways,
> > > and that we should not be too strict about them.
> > > For instance, Framed-Protocol is an optional AVP in
> > > RFCs 4005 and 4072. Yet, you could argue that if you
> > > are doing PPP then you need to use this attribute and
> > > set it to PPP. But that didn't make the attribute mandatory.
> > > Do we have a similar situation for the IKEv2/MIPv6
> > > attributes and values? They are not necessary from
> > > the NASREQ/EAP perspective, but in the specific context
> > > you need to use the attributes. In my mind, this does not
> > > make the attributes mandatory from a Diameter
> > > application point of view. If we start creating
> > > new applications for every different situation,
> > > we'll have lots of applications and interoperability
> > > problems. Its better to add new optional AVPs and
> > > describe in text when they should be used. The
> > > only exception that I see is security related AVPs
> > > that must be understood by the other side or else
> > > the session should be terminated.
> > > "
> > >
> > > Avi responds:
> > > "
> > > Mandatory does not mean required in the Command.  It means that it
> must
> > > be understood by the receiver.  We need to clarify that.
> > > "
> > >
> > > Gerardo and Lionel agree with Jari.
> > >
> > >
> > >
> > > Avi writes:
> > > "
> > > If I have two EAP based application in my network, one that is
> > > handling pure EAP application, the other is extended to handle the
> new
> > > behavior then I need a way to route the (same) command correctly.
> > > "
> > >
> > > Jari writes:
> > > "
> > > Ah, but that is a new requirement. If you believe that you need
> > > to route EAP authentication from a 802.11 AP differently
> > > than from IKEv2/MIPv6, then you need one of these:
> > >
> > > - Use different user/domain names for the users of
> > >   the different services.
> > >
> > > - Point to different servers from the AP and SGW (but
> > >   this works less well if you have proxies and roaming).
> > >
> > > - New application ID.
> > >
> > > - Some weird form of Diameter and RADIUS source routing
> > >   based on what type of node sent the message.
> > >
> > > However, it is far from clear to me why you would really
> > > need to route the authentication differently *for the same
> > > user*. Many authentication mechanisms can also have state,
> > > which would imply that at the end they need to end up in
> > > the same device anyhow. Can you expand on why you need
> > > to handle the same users in different authentication
> > > servers?
> > > "
> > >
> > > Avi to Jari:
> > >
> > > "
> > > BTW in the context of the original question raised, the attribute(s)
> > > will not be optional. Here is the snippet:
> > >
> > > >> >>  In our case, the AAA server must perform AAA functionality
> for
> > the
> > > >> >> Mobile IPv6 service. The AAA server must know that it has to
> > > >> >> authorize the mip6 service and the accounting (ASR/ASA) is
> also
> > for
> > > >> >>  mip6 and not for network access.
> > >
> > > If the Diameter message comes from the HA then the HA MUST include
> the
> > > NAS-Port-type attribute. So the command ABNF is being changed. Also
> the
> > > behavior is being changed of the Server.  It MUST recognize the
> (new)
> > > value of the NAS-Port-Type.
> > > "
> > >
> > >
> > > Yoshi says:
> > > "
> > > If what is important is service-specific routing (I am not convinced
> > > with it yet), I'd suggest defining a new authorization-only
> > > application used only for carrying service-specific attributes
> > > (analogous to NASREQ usage in RFC 4072).  The downside is that it
> > > needs another message roundtrip than carrying the attributes in
> > > DER/DEA.
> > > "
> > >
> > >
> > > Julien wrote:
> > > "
> > > > >
> > > > > I don't think it's clean to require use of different
> > > > > users'identifiers in order to distinguish which services is
> > > > > provided. For me, it looks like a 'hack'.
> > > " and Pasi responded:
> > > "
> > > I fully agree -- but having separate user identifiers should not be
> > > necessary. If, for example, an operator wants to perform different
> > > authorizations for WiFi and WiMAX (e.g., some users can access only
> > > WiFi but not WiMAX), that's simple to do: just check Service-Type,
> > > NAS-Port-Type, and other relevant authorization AVPs.  There's
> > > absolutely no need to create a new Diameter application.
> > >
> > > If the AAA server is really strict about WiFi vs. WiMAX separation,
> it
> > > can have a policy that requires the NAS-Port-Type AVP to be present
> > > (if the request does not contain it, access is denied). Although
> this
> > > in some sense make NAS-Port-Type AVP "mandatory", it's not
> "mandatory"
> > > in the sense that would require a new Diameter application.
> > >
> > > While IKEv2 and MIP6 are not WiFi and WiMAX, I don't think there are
> > > any significant differences from Diameter point-of-view. There's a
> box
> > > providing some service; authentication works with EAP; authorization
> > > AVPs indicate what exactly is being authorized. What's missing is
> > > a document describing how the different authorization AVPs are
> > > used in this particular situation; sort of like RFC 3580 (IEEE
> 802.1X
> > > RADIUS Usage Guidelines), but for Diameter with IKEv2.
> > >
> > > One important reason NOT to create new applications: proxies. Every
> > > proxy on the path needs new code to handle the new application,
> while
> > > just adding an extra AVP or new Service-Type value doesn't.
> > > "
> > >
> > > John agrees with Pasi.
> > >
> > > Avi writes:
> > > "
> > > A mandatory attribute (a must understand attribute) that has a new
> > > enumeration is in my mind is like adding a new attribute that must
> be
> > > understood.  There is no wigle room here.  The command carrying that
> > > attribute must reach the implementation that knows how to interpret
> the
> > > attribute.  This is  because an implmentation that does not
> understand
> > > Service-Type = X must return an error.
> > >
> > > It is obvious that the rules in 3588 are not sufficient to describe
> when
> > > to use a new Application ID or not.  And we should not have to have
> a
> > > debate on this topic.
> > >
> > > BTW if we do what you say then in networks where I have NASREQ
> > > performing Network Access and now I want to roll out MIPv6 I would
> have
> > > to upgrade all my old NASREQ deployed applications.  This is wrong.
> I
> > > should be able to add a MIPv6 compliant diameter application without
> > > having to force upgrading my NASREQ applications.
> > > "
> > >
> > >
> > > _______________________________________________
> > > DiME mailing list
> > > DiME@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/dime
> > 
> > --
> > julien.bournelle at int-evry.fr
> > 
> > _______________________________________________
> > DiME mailing list
> > DiME@ietf.org
> > https://www1.ietf.org/mailman/listinfo/dime
> 
> 
> "This email message and any attachments are confidential information of Starent Networks, Corp. The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp.  Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to postmaster@starentnetworks.com -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you."

-- 
julien.bournelle at int-evry.fr

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



From dime-bounces@ietf.org Sat Aug 19 12:00:22 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GETFA-0006SI-E0; Sat, 19 Aug 2006 12:00:16 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GETF4-0006Pl-G0
	for dime@ietf.org; Sat, 19 Aug 2006 12:00:10 -0400
Received: from bender-mail.tigertech.net ([64.62.209.30])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GETF3-0004q5-6k
	for dime@ietf.org; Sat, 19 Aug 2006 12:00:10 -0400
Received: from localhost (localhost [127.0.0.1])
	by bender.tigertech.net (Postfix) with ESMTP id 1080A7DDD;
	Sat, 19 Aug 2006 08:59:48 -0700 (PDT)
Received: from [192.168.0.18] (c-71-204-88-42.hsd1.ga.comcast.net
	[71.204.88.42])
	by bender.tigertech.net (Postfix) with ESMTP id 1A6847DD9;
	Sat, 19 Aug 2006 08:59:44 -0700 (PDT)
Message-ID: <44E7356D.9010506@frascone.com>
Date: Sat, 19 Aug 2006 11:59:41 -0400
From: David Frascone <dave@frascone.com>
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
References: <44E37CF9.2040409@gmx.net>
In-Reply-To: <44E37CF9.2040409@gmx.net>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at tigertech.net
X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on bender.tigertech.net
X-Spam-Status: No, hits=-2.8 tagged_above=-999.0 required=7.0 tests=ALL_TRUSTED
X-Spam-Level: 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Cc: dime@ietf.org, kempf@docomolabs-usa.com, pcalhoun@airespace.com
Subject: [Dime] Re: Next Steps for draft-ietf-dime-diameter-api-00.txt
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org


I have received no comments since October of 2005.  Those comments were 
all addressed.

As far as I know, it's finished.  (Unless I receive more comments)

-Dave

Hannes Tschofenig wrote:
> Hi all,
>
> our DIME working group charter webpage indicates that the
> http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-api-00.txt
> should be finished already:
>
>     Mar 2006 Submit Diameter API to IESG as an information RFC
>
> Question to the authors: Are you done with the document?
>
> Question to the working group: Are you happy with the document? If 
> not, what needs to be changed?
>
> Ciao
> Hannes & John
>
> PS: I know that we had a discussion about this document already a few 
> months ago. It hasn't pushed the work forward.


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



From dime-bounces@ietf.org Sun Aug 20 03:57:06 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GEiAy-0007Hz-0r; Sun, 20 Aug 2006 03:56:56 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GEBjw-00017u-Kv
	for dime@ietf.org; Fri, 18 Aug 2006 17:18:52 -0400
Received: from key1.docomolabs-usa.com ([216.98.102.225]
	helo=fridge.docomolabs-usa.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GEBjv-0001WK-7K
	for dime@ietf.org; Fri, 18 Aug 2006 17:18:52 -0400
Message-ID: <039c01c6c30b$e5214fe0$5e6015ac@dcml.docomolabsusa.com>
From: "James Kempf" <kempf@docomolabs-usa.com>
To: "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>,
	<pcalhoun@airespace.com>, <dave@frascone.com>
References: <44E37CF9.2040409@gmx.net>
Date: Fri, 18 Aug 2006 14:18:48 -0700
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-15";
	reply-type=response
Content-Transfer-Encoding: 7bit
X-Spam-Score: 3.1 (+++)
X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17
X-Mailman-Approved-At: Sun, 20 Aug 2006 03:56:53 -0400
Cc: dime@ietf.org
Subject: [Dime] Re: Next Steps for draft-ietf-dime-diameter-api-00.txt
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

I haven't worked on this document for over 5 years. I think you should 
remove my name as a co-author.

                   jak

----- Original Message ----- 
From: "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>
To: <pcalhoun@airespace.com>; <dave@frascone.com>; 
<kempf@docomolabs-usa.com>
Cc: <dime@ietf.org>
Sent: Wednesday, August 16, 2006 1:15 PM
Subject: Next Steps for draft-ietf-dime-diameter-api-00.txt


> Hi all,
>
> our DIME working group charter webpage indicates that the
> http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-api-00.txt
> should be finished already:
>
>     Mar 2006 Submit Diameter API to IESG as an information RFC
>
> Question to the authors: Are you done with the document?
>
> Question to the working group: Are you happy with the document? If not, 
> what needs to be changed?
>
> Ciao
> Hannes & John
>
> PS: I know that we had a discussion about this document already a few 
> months ago. It hasn't pushed the work forward.
> 



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



From dime-bounces@ietf.org Sun Aug 20 04:03:11 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GEiH1-00010Y-1O; Sun, 20 Aug 2006 04:03:11 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GEiGz-00010P-BF
	for dime@ietf.org; Sun, 20 Aug 2006 04:03:09 -0400
Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GEiGw-0007y7-G6
	for dime@ietf.org; Sun, 20 Aug 2006 04:03:08 -0400
Received: (qmail invoked by alias); 20 Aug 2006 08:03:04 -0000
Received: from p54986990.dip.t-dialin.net (EHLO [192.168.2.33])
	[84.152.105.144]
	by mail.gmx.net (mp016) with SMTP; 20 Aug 2006 10:03:04 +0200
X-Authenticated: #29516787
Message-ID: <44E8173D.9090705@gmx.net>
Date: Sun, 20 Aug 2006 10:03:09 +0200
From: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: Julien Bournelle <julien.bournelle@int-evry.fr>
Subject: Re: [Dime] Mobile IPv6 Bootstrapping - "Application ID" vs.
	"NAS-Port-Type AVP/Service-Type": Summary
References: <44E3853B.2090406@gmx.net>
	<20060818165424.GA24233@ipv6-3.int-evry.fr>
In-Reply-To: <20060818165424.GA24233@ipv6-3.int-evry.fr>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 578c2c9d0cb01ffe6e1ca36540edd070
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

Hi Julien,


Julien Bournelle schrieb:
> Hi hannes,
> 
>  thanks for this clarifying mail.
> 
> 
> On Wed, Aug 16, 2006 at 10:51:07PM +0200, Hannes Tschofenig wrote:
>> Hi all,
>>
>> I went through the discussion again and noticed that we haven't reached 
>> a conclusion.
>>
>> Here is my impression:
>>
>> * RFC 3588 leaves a question regarding the extensibility open.
>>   This needs to be captured in the revision of the base specification.
>>
>> * The main issue seems to be
>>
>>   - Do we want to route 'Diameter EAP' message and 'Diameter Mobile 
>> IPv6 Bootstrapping' messages differently?
> 
>  I tend to think that it is safer to assume that some operators may
>  desire that.
> 
>>     If we want to route them differently then we need to define 
>> 'Diameter MIPv6 Bootstrapping' as a Diameter application.
>>
>>   - The AAA server differentiates ordinary network access and MIPv6 
>> bootstrapping functionality (with respect to authorization and 
>> accounting). In order to do so it must understand the Service-Type 
>> and/or NAS-Port-Type AVPs and the defined values.
>>
>>     Is this a problem?
> 
>  Not sure to understand this problem. For me, if we have the App-Id we
>  don't need Service-Type nor NAS-Port Type.
>  IF we don't have the App-ID, yes we need to define new values.
> 
>  Maybe i missed the problem you raised.

This item is only relevant if you use the Service-Type / NAS-Port Type 
approach. The problem raised in the mailing list discussion was 
regarding the type of authorization performed by the AAA server. If the 
AAA server understands the new values then everything is fine. If it 
does not understand them then the authorization decision would be 
treated as a normal network access scenario. Is this desirable?



Ciao
Hannes

> 
>  regards,
> 
>  Julien

Ciao
Hannes


> 
>>   - There are problems with proxies and newly defined Diameter 
>> Application IDs. Every
>> proxy on the path needs new code to handle the new application, while
>> just adding an extra AVP or new Service-Type value does not hurt.
>>
>>     Is this an issue for us?
>>
>> Ciao
>> Hannes
>>
>> PS: Here is copy-and-paste version of some discussion snippets to allow 
>> others to catch-up.
>>
>> Julien starts the discussion with a question about Application IDs.
>>
>> Pasi suggests to consider Service-Type and/or NAS-Port-Type AVPs as 
>> well.... the problem starts.
>>
>> Avi states that the problem is that neither Service-Type or Port-Type is 
>> mandatory.
>> "
>> Service Type seems to be the correct way but in RADIUS and
>> Diameter service-type also can be authenticate-only or authorize-only.
>> So what if the HA wanted to authenticate-only or authorize-only for the
>> MIP service?  I would lose the ability to also indicate that this is an
>> HA.
>>
>> So Port-Type seems to be the way to go....
>> "
>>
>> Jari jumps in:
>> "
>> One of the reasons why an existing application would
>> be preferred is that then a AAA server that does not
>> care about the type of service can be used without
>> changes. Yet servers that do care can look at the
>> AVPs and make more detailed authorization
>> decisions.
>>
>>
>> RFC 3588 states that  "Creation of a new application
>> should be viewed as a last resort." and that "In order
>> to justify allocation of a new application identifier,
>> Diameter applications MUST define one Command Code,
>> or add new mandatory AVPs to the ABNF." Note that
>> mandatory AVPs can be viewed in different ways,
>> and that we should not be too strict about them.
>> For instance, Framed-Protocol is an optional AVP in
>> RFCs 4005 and 4072. Yet, you could argue that if you
>> are doing PPP then you need to use this attribute and
>> set it to PPP. But that didn't make the attribute mandatory.
>> Do we have a similar situation for the IKEv2/MIPv6
>> attributes and values? They are not necessary from
>> the NASREQ/EAP perspective, but in the specific context
>> you need to use the attributes. In my mind, this does not
>> make the attributes mandatory from a Diameter
>> application point of view. If we start creating
>> new applications for every different situation,
>> we'll have lots of applications and interoperability
>> problems. Its better to add new optional AVPs and
>> describe in text when they should be used. The
>> only exception that I see is security related AVPs
>> that must be understood by the other side or else
>> the session should be terminated.
>> "
>>
>> Avi responds:
>> "
>> Mandatory does not mean required in the Command.  It means that it must
>> be understood by the receiver.  We need to clarify that.
>> "
>>
>> Gerardo and Lionel agree with Jari.
>>
>>
>>
>> Avi writes:
>> "
>> If I have two EAP based application in my network, one that is
>> handling pure EAP application, the other is extended to handle the new
>> behavior then I need a way to route the (same) command correctly.
>> "
>>
>> Jari writes:
>> "
>> Ah, but that is a new requirement. If you believe that you need
>> to route EAP authentication from a 802.11 AP differently
>> than from IKEv2/MIPv6, then you need one of these:
>>
>> - Use different user/domain names for the users of
>>   the different services.
>>
>> - Point to different servers from the AP and SGW (but
>>   this works less well if you have proxies and roaming).
>>
>> - New application ID.
>>
>> - Some weird form of Diameter and RADIUS source routing
>>   based on what type of node sent the message.
>>
>> However, it is far from clear to me why you would really
>> need to route the authentication differently *for the same
>> user*. Many authentication mechanisms can also have state,
>> which would imply that at the end they need to end up in
>> the same device anyhow. Can you expand on why you need
>> to handle the same users in different authentication
>> servers?
>> "
>>
>> Avi to Jari:
>>
>> "
>> BTW in the context of the original question raised, the attribute(s)
>> will not be optional. Here is the snippet:
>>
>>>>>>  In our case, the AAA server must perform AAA functionality for the
>>>>>> Mobile IPv6 service. The AAA server must know that it has to
>>>>>> authorize the mip6 service and the accounting (ASR/ASA) is also for
>>>>>>  mip6 and not for network access.
>> If the Diameter message comes from the HA then the HA MUST include the
>> NAS-Port-type attribute. So the command ABNF is being changed. Also the
>> behavior is being changed of the Server.  It MUST recognize the (new)
>> value of the NAS-Port-Type.
>> "
>>
>>
>> Yoshi says:
>> "
>> If what is important is service-specific routing (I am not convinced
>> with it yet), I'd suggest defining a new authorization-only
>> application used only for carrying service-specific attributes
>> (analogous to NASREQ usage in RFC 4072).  The downside is that it
>> needs another message roundtrip than carrying the attributes in
>> DER/DEA.
>> "
>>
>>
>> Julien wrote:
>> "
>>>> I don't think it's clean to require use of different
>>>> users'identifiers in order to distinguish which services is
>>>> provided. For me, it looks like a 'hack'.
>> " and Pasi responded:
>> "
>> I fully agree -- but having separate user identifiers should not be
>> necessary. If, for example, an operator wants to perform different
>> authorizations for WiFi and WiMAX (e.g., some users can access only
>> WiFi but not WiMAX), that's simple to do: just check Service-Type,
>> NAS-Port-Type, and other relevant authorization AVPs.  There's
>> absolutely no need to create a new Diameter application.
>>
>> If the AAA server is really strict about WiFi vs. WiMAX separation, it
>> can have a policy that requires the NAS-Port-Type AVP to be present
>> (if the request does not contain it, access is denied). Although this
>> in some sense make NAS-Port-Type AVP "mandatory", it's not "mandatory"
>> in the sense that would require a new Diameter application.
>>
>> While IKEv2 and MIP6 are not WiFi and WiMAX, I don't think there are
>> any significant differences from Diameter point-of-view. There's a box
>> providing some service; authentication works with EAP; authorization
>> AVPs indicate what exactly is being authorized. What's missing is
>> a document describing how the different authorization AVPs are
>> used in this particular situation; sort of like RFC 3580 (IEEE 802.1X
>> RADIUS Usage Guidelines), but for Diameter with IKEv2.
>>
>> One important reason NOT to create new applications: proxies. Every
>> proxy on the path needs new code to handle the new application, while
>> just adding an extra AVP or new Service-Type value doesn't.
>> "
>>
>> John agrees with Pasi.
>>
>> Avi writes:
>> "
>> A mandatory attribute (a must understand attribute) that has a new
>> enumeration is in my mind is like adding a new attribute that must be
>> understood.  There is no wigle room here.  The command carrying that
>> attribute must reach the implementation that knows how to interpret the
>> attribute.  This is  because an implmentation that does not understand
>> Service-Type = X must return an error.
>>
>> It is obvious that the rules in 3588 are not sufficient to describe when
>> to use a new Application ID or not.  And we should not have to have a
>> debate on this topic.
>>
>> BTW if we do what you say then in networks where I have NASREQ
>> performing Network Access and now I want to roll out MIPv6 I would have
>> to upgrade all my old NASREQ deployed applications.  This is wrong.  I
>> should be able to add a MIPv6 compliant diameter application without
>> having to force upgrading my NASREQ applications.
>> "
>>
>>
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www1.ietf.org/mailman/listinfo/dime
> 


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



From dime-bounces@ietf.org Sun Aug 20 04:07:01 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GEiKj-0002X5-QD; Sun, 20 Aug 2006 04:07:01 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GEiKj-0002X0-2U
	for dime@ietf.org; Sun, 20 Aug 2006 04:07:01 -0400
Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GEiKi-0008Nd-9G
	for dime@ietf.org; Sun, 20 Aug 2006 04:07:01 -0400
Received: (qmail invoked by alias); 20 Aug 2006 08:06:58 -0000
Received: from p54986990.dip.t-dialin.net (EHLO [192.168.2.33])
	[84.152.105.144]
	by mail.gmx.net (mp032) with SMTP; 20 Aug 2006 10:06:58 +0200
X-Authenticated: #29516787
Message-ID: <44E81827.3070208@gmx.net>
Date: Sun, 20 Aug 2006 10:07:03 +0200
From: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: "Chowdhury, Kuntal" <kchowdhury@starentnetworks.com>
Subject: Re: [Dime] Mobile IPv6 Bootstrapping - "Application ID"
	vs."NAS-Port-Type AVP/Service-Type": Summary
References: <7CCD07160348804497EF29E9EA5560D78371FE@exchtewks2.starentnetworks.com>
In-Reply-To: <7CCD07160348804497EF29E9EA5560D78371FE@exchtewks2.starentnetworks.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 3b8eea209b62bd15620865bc4fbef8cd
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

Hi Kuntal,


Chowdhury, Kuntal schrieb:
> Hi Hannes, Julien,
> 
> Application-ID is one way, but as has been discussed so far it requires
> changes in the intermediaries.

True.

  A new value in NAS-Port-Type AVP seems
> more logical and easier to implement, IMHO.

Easier to implement: True.

  I am not sure about the
> Service-Type AVP. I am wondering what cannot be conveyed via
> NAS-Port-Type AVP so that we need this additional AVP?
> 
> Apologize for jumping in late....still trying to understand the whole
> issue.
Please read my copy-and-paste summary of the discussion.

In some sense we are discussing fundamentals of how to extend Diameter.
The application ID is used for routing. If we don't define a new app-ID 
then we cannot route network access messages and MIP6 bootstrapping 
messages differently. Some folks think that this is important.
What do you think?

Ciao
Hannes

> 
> -Kuntal
> 
> 
>> -----Original Message-----
>> From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr]
>> Sent: Friday, August 18, 2006 11:54 AM
>> To: Hannes Tschofenig
>> Cc: dime@ietf.org
>> Subject: Re: [Dime] Mobile IPv6 Bootstrapping - "Application ID"
> vs."NAS-
>> Port-Type AVP/Service-Type": Summary
>>
>> Hi hannes,
>>
>>  thanks for this clarifying mail.
>>
>>
>> On Wed, Aug 16, 2006 at 10:51:07PM +0200, Hannes Tschofenig wrote:
>>> Hi all,
>>>
>>> I went through the discussion again and noticed that we haven't
> reached
>>> a conclusion.
>>>
>>> Here is my impression:
>>>
>>> * RFC 3588 leaves a question regarding the extensibility open.
>>>   This needs to be captured in the revision of the base
> specification.
>>> * The main issue seems to be
>>>
>>>   - Do we want to route 'Diameter EAP' message and 'Diameter Mobile
>>> IPv6 Bootstrapping' messages differently?
>>  I tend to think that it is safer to assume that some operators may
>>  desire that.
>>
>>>     If we want to route them differently then we need to define
>>> 'Diameter MIPv6 Bootstrapping' as a Diameter application.
>>>
>>>   - The AAA server differentiates ordinary network access and MIPv6
>>> bootstrapping functionality (with respect to authorization and
>>> accounting). In order to do so it must understand the Service-Type
>>> and/or NAS-Port-Type AVPs and the defined values.
>>>
>>>     Is this a problem?
>>  Not sure to understand this problem. For me, if we have the App-Id we
>>  don't need Service-Type nor NAS-Port Type.
>>  IF we don't have the App-ID, yes we need to define new values.
>>
>>  Maybe i missed the problem you raised.
>>
>>  regards,
>>
>>  Julien
>>
>>>   - There are problems with proxies and newly defined Diameter
>>> Application IDs. Every
>>> proxy on the path needs new code to handle the new application,
> while
>>> just adding an extra AVP or new Service-Type value does not hurt.
>>>
>>>     Is this an issue for us?
>>>
>>> Ciao
>>> Hannes
>>>
>>> PS: Here is copy-and-paste version of some discussion snippets to
> allow
>>> others to catch-up.
>>>
>>> Julien starts the discussion with a question about Application IDs.
>>>
>>> Pasi suggests to consider Service-Type and/or NAS-Port-Type AVPs as
>>> well.... the problem starts.
>>>
>>> Avi states that the problem is that neither Service-Type or
> Port-Type is
>>> mandatory.
>>> "
>>> Service Type seems to be the correct way but in RADIUS and
>>> Diameter service-type also can be authenticate-only or
> authorize-only.
>>> So what if the HA wanted to authenticate-only or authorize-only for
> the
>>> MIP service?  I would lose the ability to also indicate that this is
> an
>>> HA.
>>>
>>> So Port-Type seems to be the way to go....
>>> "
>>>
>>> Jari jumps in:
>>> "
>>> One of the reasons why an existing application would
>>> be preferred is that then a AAA server that does not
>>> care about the type of service can be used without
>>> changes. Yet servers that do care can look at the
>>> AVPs and make more detailed authorization
>>> decisions.
>>>
>>>
>>> RFC 3588 states that  "Creation of a new application
>>> should be viewed as a last resort." and that "In order
>>> to justify allocation of a new application identifier,
>>> Diameter applications MUST define one Command Code,
>>> or add new mandatory AVPs to the ABNF." Note that
>>> mandatory AVPs can be viewed in different ways,
>>> and that we should not be too strict about them.
>>> For instance, Framed-Protocol is an optional AVP in
>>> RFCs 4005 and 4072. Yet, you could argue that if you
>>> are doing PPP then you need to use this attribute and
>>> set it to PPP. But that didn't make the attribute mandatory.
>>> Do we have a similar situation for the IKEv2/MIPv6
>>> attributes and values? They are not necessary from
>>> the NASREQ/EAP perspective, but in the specific context
>>> you need to use the attributes. In my mind, this does not
>>> make the attributes mandatory from a Diameter
>>> application point of view. If we start creating
>>> new applications for every different situation,
>>> we'll have lots of applications and interoperability
>>> problems. Its better to add new optional AVPs and
>>> describe in text when they should be used. The
>>> only exception that I see is security related AVPs
>>> that must be understood by the other side or else
>>> the session should be terminated.
>>> "
>>>
>>> Avi responds:
>>> "
>>> Mandatory does not mean required in the Command.  It means that it
> must
>>> be understood by the receiver.  We need to clarify that.
>>> "
>>>
>>> Gerardo and Lionel agree with Jari.
>>>
>>>
>>>
>>> Avi writes:
>>> "
>>> If I have two EAP based application in my network, one that is
>>> handling pure EAP application, the other is extended to handle the
> new
>>> behavior then I need a way to route the (same) command correctly.
>>> "
>>>
>>> Jari writes:
>>> "
>>> Ah, but that is a new requirement. If you believe that you need
>>> to route EAP authentication from a 802.11 AP differently
>>> than from IKEv2/MIPv6, then you need one of these:
>>>
>>> - Use different user/domain names for the users of
>>>   the different services.
>>>
>>> - Point to different servers from the AP and SGW (but
>>>   this works less well if you have proxies and roaming).
>>>
>>> - New application ID.
>>>
>>> - Some weird form of Diameter and RADIUS source routing
>>>   based on what type of node sent the message.
>>>
>>> However, it is far from clear to me why you would really
>>> need to route the authentication differently *for the same
>>> user*. Many authentication mechanisms can also have state,
>>> which would imply that at the end they need to end up in
>>> the same device anyhow. Can you expand on why you need
>>> to handle the same users in different authentication
>>> servers?
>>> "
>>>
>>> Avi to Jari:
>>>
>>> "
>>> BTW in the context of the original question raised, the attribute(s)
>>> will not be optional. Here is the snippet:
>>>
>>>>>>>  In our case, the AAA server must perform AAA functionality
> for
>> the
>>>>>>> Mobile IPv6 service. The AAA server must know that it has to
>>>>>>> authorize the mip6 service and the accounting (ASR/ASA) is
> also
>> for
>>>>>>>  mip6 and not for network access.
>>> If the Diameter message comes from the HA then the HA MUST include
> the
>>> NAS-Port-type attribute. So the command ABNF is being changed. Also
> the
>>> behavior is being changed of the Server.  It MUST recognize the
> (new)
>>> value of the NAS-Port-Type.
>>> "
>>>
>>>
>>> Yoshi says:
>>> "
>>> If what is important is service-specific routing (I am not convinced
>>> with it yet), I'd suggest defining a new authorization-only
>>> application used only for carrying service-specific attributes
>>> (analogous to NASREQ usage in RFC 4072).  The downside is that it
>>> needs another message roundtrip than carrying the attributes in
>>> DER/DEA.
>>> "
>>>
>>>
>>> Julien wrote:
>>> "
>>>>> I don't think it's clean to require use of different
>>>>> users'identifiers in order to distinguish which services is
>>>>> provided. For me, it looks like a 'hack'.
>>> " and Pasi responded:
>>> "
>>> I fully agree -- but having separate user identifiers should not be
>>> necessary. If, for example, an operator wants to perform different
>>> authorizations for WiFi and WiMAX (e.g., some users can access only
>>> WiFi but not WiMAX), that's simple to do: just check Service-Type,
>>> NAS-Port-Type, and other relevant authorization AVPs.  There's
>>> absolutely no need to create a new Diameter application.
>>>
>>> If the AAA server is really strict about WiFi vs. WiMAX separation,
> it
>>> can have a policy that requires the NAS-Port-Type AVP to be present
>>> (if the request does not contain it, access is denied). Although
> this
>>> in some sense make NAS-Port-Type AVP "mandatory", it's not
> "mandatory"
>>> in the sense that would require a new Diameter application.
>>>
>>> While IKEv2 and MIP6 are not WiFi and WiMAX, I don't think there are
>>> any significant differences from Diameter point-of-view. There's a
> box
>>> providing some service; authentication works with EAP; authorization
>>> AVPs indicate what exactly is being authorized. What's missing is
>>> a document describing how the different authorization AVPs are
>>> used in this particular situation; sort of like RFC 3580 (IEEE
> 802.1X
>>> RADIUS Usage Guidelines), but for Diameter with IKEv2.
>>>
>>> One important reason NOT to create new applications: proxies. Every
>>> proxy on the path needs new code to handle the new application,
> while
>>> just adding an extra AVP or new Service-Type value doesn't.
>>> "
>>>
>>> John agrees with Pasi.
>>>
>>> Avi writes:
>>> "
>>> A mandatory attribute (a must understand attribute) that has a new
>>> enumeration is in my mind is like adding a new attribute that must
> be
>>> understood.  There is no wigle room here.  The command carrying that
>>> attribute must reach the implementation that knows how to interpret
> the
>>> attribute.  This is  because an implmentation that does not
> understand
>>> Service-Type = X must return an error.
>>>
>>> It is obvious that the rules in 3588 are not sufficient to describe
> when
>>> to use a new Application ID or not.  And we should not have to have
> a
>>> debate on this topic.
>>>
>>> BTW if we do what you say then in networks where I have NASREQ
>>> performing Network Access and now I want to roll out MIPv6 I would
> have
>>> to upgrade all my old NASREQ deployed applications.  This is wrong.
> I
>>> should be able to add a MIPv6 compliant diameter application without
>>> having to force upgrading my NASREQ applications.
>>> "
>>>
>>>
>>> _______________________________________________
>>> DiME mailing list
>>> DiME@ietf.org
>>> https://www1.ietf.org/mailman/listinfo/dime
>> --
>> julien.bournelle at int-evry.fr
>>
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www1.ietf.org/mailman/listinfo/dime
> 
> 
> "This email message and any attachments are confidential information of Starent Networks, Corp. The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp.  Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to postmaster@starentnetworks.com -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you."
> 
> 


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



From dime-bounces@ietf.org Sun Aug 20 06:41:45 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GEkkF-0005pK-4Z; Sun, 20 Aug 2006 06:41:31 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GEkkD-0005pF-UY
	for dime@ietf.org; Sun, 20 Aug 2006 06:41:29 -0400
Received: from mail.gmx.net ([213.165.64.20])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GEkkC-0003zA-Gz
	for dime@ietf.org; Sun, 20 Aug 2006 06:41:29 -0400
Received: (qmail invoked by alias); 20 Aug 2006 10:34:45 -0000
Received: from p54986990.dip.t-dialin.net (EHLO [192.168.2.33])
	[84.152.105.144]
	by mail.gmx.net (mp030) with SMTP; 20 Aug 2006 12:34:45 +0200
X-Authenticated: #29516787
Message-ID: <44E83ACA.3020805@gmx.net>
Date: Sun, 20 Aug 2006 12:34:50 +0200
From: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: dime@ietf.org
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
Subject: [Dime] Diameter Interop & Diameter Interoperability Test Suite
	Document
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

Hi all,

to perform the interop testing in a more structured way we once wrote 
the following Diameter Interoperability Test Suite document:
http://tools.ietf.org/wg/dime/draft-fajardo-dime-interop-test-suite-01.txt

It was updated after the last interop based on the feedback we got; more 
updates might, however, be needed.

Since we are looking ahead to the next interop it would be good to get 
some feedback to agree on the test scenarios ahead of time. This also 
gives us the chance to more clearly summarize the outcome of the event 
in the report. It might also give participants the chance to prepare 
some scripts and to agree on the scope of the tests.

Ciao
Hannes


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



From dime-bounces@ietf.org Mon Aug 21 02:47:39 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GF3ZF-0003rG-Fk; Mon, 21 Aug 2006 02:47:25 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GF3ZD-0003r5-Jd
	for dime@ietf.org; Mon, 21 Aug 2006 02:47:23 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129]
	helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GF2mk-0001nC-G4
	for dime@ietf.org; Mon, 21 Aug 2006 01:57:18 -0400
Received: from mgw-ext14.nokia.com ([131.228.20.173])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GF2cB-0004sO-8v
	for dime@ietf.org; Mon, 21 Aug 2006 01:46:24 -0400
Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143])
	by mgw-ext14.nokia.com (Switch-3.1.10/Switch-3.1.7) with ESMTP id
	k7L5kKmo009456; Mon, 21 Aug 2006 08:46:21 +0300
Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by
	esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 21 Aug 2006 08:46:20 +0300
Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by
	esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 21 Aug 2006 08:46:20 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Dime] Mobile IPv6 Bootstrapping - "Application
	ID"vs."NAS-Port-Type AVP/Service-Type": Summary
Date: Mon, 21 Aug 2006 08:46:19 +0300
Message-ID: <BAA65A575825454CBB0103267553FCCC892123@esebe199.NOE.Nokia.com>
In-Reply-To: <44E81827.3070208@gmx.net>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Dime] Mobile IPv6 Bootstrapping - "Application
	ID"vs."NAS-Port-Type AVP/Service-Type": Summary
Thread-Index: AcbETVDJaGthlCLjRcG6F/bJ2VWo3wAl0aXg
From: <john.loughney@nokia.com>
To: <Hannes.Tschofenig@gmx.net>, <kchowdhury@starentnetworks.com>
X-OriginalArrivalTime: 21 Aug 2006 05:46:20.0256 (UTC)
	FILETIME=[20BEAE00:01C6C4E5]
X-Spam-Score: -2.3 (--)
X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

Hannes,


>> Apologize for jumping in late....still trying to understand the whole

>> issue.
>Please read my copy-and-paste summary of the discussion.
>
>In some sense we are discussing fundamentals of how to extend Diameter.
>The application ID is used for routing. If we don't define a=20
>new app-ID then we cannot route network access messages and=20
>MIP6 bootstrapping messages differently. Some folks think that=20
>this is important.
>What do you think?

Just to stir the pot a bit .. I agree with you, we are discussing how
have a Diameter extension and how it fits into the existing deployment.
If using MIPv6 with Diameter creates new manditory attributes and/or
changes the basic state machine, I assume a new application ID should be
used.
I think that if a new application ID is used, it still could be
reasonable
to include information how this new MIPv6 Diameter Application could be
collocated
with the existing MIP(v4) Application.

However, general question - have we gotten past the point where we know
that=20
manditory attributes are required?  I just want to verify that.

thanks,
John

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



From dime-bounces@ietf.org Mon Aug 21 04:22:37 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GF53N-0006lv-UW; Mon, 21 Aug 2006 04:22:37 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GF53M-0006lo-Tr
	for dime@ietf.org; Mon, 21 Aug 2006 04:22:36 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129]
	helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GF2mj-0001nC-Cz
	for dime@ietf.org; Mon, 21 Aug 2006 01:57:17 -0400
Received: from mgw-ext11.nokia.com ([131.228.20.170])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GF2eQ-0004uQ-H3
	for dime@ietf.org; Mon, 21 Aug 2006 01:48:52 -0400
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211])
	by mgw-ext11.nokia.com (Switch-3.1.10/Switch-3.1.7) with ESMTP id
	k7L4mWYe005755; Mon, 21 Aug 2006 07:48:32 +0300
Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by
	esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 21 Aug 2006 08:48:31 +0300
Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by
	esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 21 Aug 2006 08:48:30 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Dime] Re: Next Steps for draft-ietf-dime-diameter-api-00.txt
Date: Mon, 21 Aug 2006 08:48:30 +0300
Message-ID: <BAA65A575825454CBB0103267553FCCC892124@esebe199.NOE.Nokia.com>
In-Reply-To: <44E7356D.9010506@frascone.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Dime] Re: Next Steps for draft-ietf-dime-diameter-api-00.txt
Thread-Index: AcbDxAq1ccfRLLaSQwO5quzglshhnABISJdw
From: <john.loughney@nokia.com>
To: <dave@frascone.com>, <Hannes.Tschofenig@gmx.net>
X-OriginalArrivalTime: 21 Aug 2006 05:48:30.0670 (UTC)
	FILETIME=[6E7A46E0:01C6C4E5]
X-Spam-Score: -2.3 (--)
X-Scan-Signature: 97adf591118a232206bdb5a27b217034
Cc: pcalhoun@airespace.com, kempf@docomolabs-usa.com, dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

Hi all,

>I have received no comments since October of 2005.  Those=20
>comments were all addressed.
>
>As far as I know, it's finished.  (Unless I receive more comments)
>
>-Dave
>
>Hannes Tschofenig wrote:
>> Hi all,
>>
>> our DIME working group charter webpage indicates that the=20
>>=20
>http://www.ietf.org/internet-drafts/draft-ietf-dime-diameter-api-00.txt
>> should be finished already:
>>
>>     Mar 2006 Submit Diameter API to IESG as an information RFC
>>
>> Question to the authors: Are you done with the document?
>>
>> Question to the working group: Are you happy with the document? If=20
>> not, what needs to be changed?

My general assumption is that there are no new comments.  I think that
some
members of the WG objected - more on a procedural level.  It seemed that
there
was some smoke and noise, but I'd really like to have more technical
comments
on the document.

thanks,
John

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



From dime-bounces@ietf.org Mon Aug 21 04:59:34 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GF5cy-0000kh-6E; Mon, 21 Aug 2006 04:59:24 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GF5cw-0000kb-G8
	for dime@ietf.org; Mon, 21 Aug 2006 04:59:22 -0400
Received: from smtp2.int-evry.fr ([157.159.10.45])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GF5cv-0003cz-Qe
	for dime@ietf.org; Mon, 21 Aug 2006 04:59:22 -0400
Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76])
	by smtp2.int-evry.fr (Postfix) with ESMTP id 2B47730037;
	Mon, 21 Aug 2006 10:51:53 +0200 (CEST)
Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.52)
	id 1GF5Xa-0006iI-Oi; Mon, 21 Aug 2006 10:53:50 +0200
Date: Mon, 21 Aug 2006 10:53:50 +0200
From: Julien Bournelle <julien.bournelle@int-evry.fr>
To: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
Subject: Re: [Dime] Mobile IPv6 Bootstrapping - "Application ID" vs.
	"NAS-Port-Type AVP/Service-Type": Summary
Message-ID: <20060821085350.GA25787@ipv6-3.int-evry.fr>
References: <44E3853B.2090406@gmx.net>
	<20060818165424.GA24233@ipv6-3.int-evry.fr>
	<44E8173D.9090705@gmx.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <44E8173D.9090705@gmx.net>
User-Agent: Mutt/1.5.9i
X-INT-MailScanner-Information: Please contact the ISP for more information
X-INT-MailScanner: Found to be clean
X-INT-MailScanner-MCPCheck: 
X-INT-MailScanner-SpamCheck: 
X-MailScanner-From: jb@int-evry.fr
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2a9ffb6f997442a3b543bcdaf483b990
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

Hi hannes, all,

On Sun, Aug 20, 2006 at 10:03:09AM +0200, Hannes Tschofenig wrote:
<snip>

> >>  - The AAA server differentiates ordinary network access and MIPv6 
> >>bootstrapping functionality (with respect to authorization and 
> >>accounting). In order to do so it must understand the Service-Type 
> >>and/or NAS-Port-Type AVPs and the defined values.
> >>
> >>    Is this a problem?
> >
> > Not sure to understand this problem. For me, if we have the App-Id we
> > don't need Service-Type nor NAS-Port Type.
> > IF we don't have the App-ID, yes we need to define new values.
> >
> > Maybe i missed the problem you raised.
> 
> This item is only relevant if you use the Service-Type / NAS-Port Type 
> approach. The problem raised in the mailing list discussion was 
> regarding the type of authorization performed by the AAA server. If the 
> AAA server understands the new values then everything is fine. If it 
> does not understand them then the authorization decision would be 
> treated as a normal network access scenario. Is this desirable?

 I think operators need to know if it's normal network access scenario
 or Mobile IPv6 Service. Reasons that I can see are:

 - charging
 - policies to apply on the service equipment (network access: NAS, mip6
   service: HA)

 regards,

 Julien

> 
> 
> 
> Ciao
> Hannes
> 
> >
> > regards,
> >
> > Julien
> 
> Ciao
> Hannes
> 
> 
> >
> >>  - There are problems with proxies and newly defined Diameter 
> >>Application IDs. Every
> >>proxy on the path needs new code to handle the new application, while
> >>just adding an extra AVP or new Service-Type value does not hurt.
> >>
> >>    Is this an issue for us?
> >>
> >>Ciao
> >>Hannes
> >>
> >>PS: Here is copy-and-paste version of some discussion snippets to allow 
> >>others to catch-up.
> >>
> >>Julien starts the discussion with a question about Application IDs.
> >>
> >>Pasi suggests to consider Service-Type and/or NAS-Port-Type AVPs as 
> >>well.... the problem starts.
> >>
> >>Avi states that the problem is that neither Service-Type or Port-Type is 
> >>mandatory.
> >>"
> >>Service Type seems to be the correct way but in RADIUS and
> >>Diameter service-type also can be authenticate-only or authorize-only.
> >>So what if the HA wanted to authenticate-only or authorize-only for the
> >>MIP service?  I would lose the ability to also indicate that this is an
> >>HA.
> >>
> >>So Port-Type seems to be the way to go....
> >>"
> >>
> >>Jari jumps in:
> >>"
> >>One of the reasons why an existing application would
> >>be preferred is that then a AAA server that does not
> >>care about the type of service can be used without
> >>changes. Yet servers that do care can look at the
> >>AVPs and make more detailed authorization
> >>decisions.
> >>
> >>
> >>RFC 3588 states that  "Creation of a new application
> >>should be viewed as a last resort." and that "In order
> >>to justify allocation of a new application identifier,
> >>Diameter applications MUST define one Command Code,
> >>or add new mandatory AVPs to the ABNF." Note that
> >>mandatory AVPs can be viewed in different ways,
> >>and that we should not be too strict about them.
> >>For instance, Framed-Protocol is an optional AVP in
> >>RFCs 4005 and 4072. Yet, you could argue that if you
> >>are doing PPP then you need to use this attribute and
> >>set it to PPP. But that didn't make the attribute mandatory.
> >>Do we have a similar situation for the IKEv2/MIPv6
> >>attributes and values? They are not necessary from
> >>the NASREQ/EAP perspective, but in the specific context
> >>you need to use the attributes. In my mind, this does not
> >>make the attributes mandatory from a Diameter
> >>application point of view. If we start creating
> >>new applications for every different situation,
> >>we'll have lots of applications and interoperability
> >>problems. Its better to add new optional AVPs and
> >>describe in text when they should be used. The
> >>only exception that I see is security related AVPs
> >>that must be understood by the other side or else
> >>the session should be terminated.
> >>"
> >>
> >>Avi responds:
> >>"
> >>Mandatory does not mean required in the Command.  It means that it must
> >>be understood by the receiver.  We need to clarify that.
> >>"
> >>
> >>Gerardo and Lionel agree with Jari.
> >>
> >>
> >>
> >>Avi writes:
> >>"
> >>If I have two EAP based application in my network, one that is
> >>handling pure EAP application, the other is extended to handle the new
> >>behavior then I need a way to route the (same) command correctly.
> >>"
> >>
> >>Jari writes:
> >>"
> >>Ah, but that is a new requirement. If you believe that you need
> >>to route EAP authentication from a 802.11 AP differently
> >>than from IKEv2/MIPv6, then you need one of these:
> >>
> >>- Use different user/domain names for the users of
> >>  the different services.
> >>
> >>- Point to different servers from the AP and SGW (but
> >>  this works less well if you have proxies and roaming).
> >>
> >>- New application ID.
> >>
> >>- Some weird form of Diameter and RADIUS source routing
> >>  based on what type of node sent the message.
> >>
> >>However, it is far from clear to me why you would really
> >>need to route the authentication differently *for the same
> >>user*. Many authentication mechanisms can also have state,
> >>which would imply that at the end they need to end up in
> >>the same device anyhow. Can you expand on why you need
> >>to handle the same users in different authentication
> >>servers?
> >>"
> >>
> >>Avi to Jari:
> >>
> >>"
> >>BTW in the context of the original question raised, the attribute(s)
> >>will not be optional. Here is the snippet:
> >>
> >>>>>> In our case, the AAA server must perform AAA functionality for the
> >>>>>>Mobile IPv6 service. The AAA server must know that it has to
> >>>>>>authorize the mip6 service and the accounting (ASR/ASA) is also for
> >>>>>> mip6 and not for network access.
> >>If the Diameter message comes from the HA then the HA MUST include the
> >>NAS-Port-type attribute. So the command ABNF is being changed. Also the
> >>behavior is being changed of the Server.  It MUST recognize the (new)
> >>value of the NAS-Port-Type.
> >>"
> >>
> >>
> >>Yoshi says:
> >>"
> >>If what is important is service-specific routing (I am not convinced
> >>with it yet), I'd suggest defining a new authorization-only
> >>application used only for carrying service-specific attributes
> >>(analogous to NASREQ usage in RFC 4072).  The downside is that it
> >>needs another message roundtrip than carrying the attributes in
> >>DER/DEA.
> >>"
> >>
> >>
> >>Julien wrote:
> >>"
> >>>>I don't think it's clean to require use of different
> >>>>users'identifiers in order to distinguish which services is
> >>>>provided. For me, it looks like a 'hack'.
> >>" and Pasi responded:
> >>"
> >>I fully agree -- but having separate user identifiers should not be
> >>necessary. If, for example, an operator wants to perform different
> >>authorizations for WiFi and WiMAX (e.g., some users can access only
> >>WiFi but not WiMAX), that's simple to do: just check Service-Type,
> >>NAS-Port-Type, and other relevant authorization AVPs.  There's
> >>absolutely no need to create a new Diameter application.
> >>
> >>If the AAA server is really strict about WiFi vs. WiMAX separation, it
> >>can have a policy that requires the NAS-Port-Type AVP to be present
> >>(if the request does not contain it, access is denied). Although this
> >>in some sense make NAS-Port-Type AVP "mandatory", it's not "mandatory"
> >>in the sense that would require a new Diameter application.
> >>
> >>While IKEv2 and MIP6 are not WiFi and WiMAX, I don't think there are
> >>any significant differences from Diameter point-of-view. There's a box
> >>providing some service; authentication works with EAP; authorization
> >>AVPs indicate what exactly is being authorized. What's missing is
> >>a document describing how the different authorization AVPs are
> >>used in this particular situation; sort of like RFC 3580 (IEEE 802.1X
> >>RADIUS Usage Guidelines), but for Diameter with IKEv2.
> >>
> >>One important reason NOT to create new applications: proxies. Every
> >>proxy on the path needs new code to handle the new application, while
> >>just adding an extra AVP or new Service-Type value doesn't.
> >>"
> >>
> >>John agrees with Pasi.
> >>
> >>Avi writes:
> >>"
> >>A mandatory attribute (a must understand attribute) that has a new
> >>enumeration is in my mind is like adding a new attribute that must be
> >>understood.  There is no wigle room here.  The command carrying that
> >>attribute must reach the implementation that knows how to interpret the
> >>attribute.  This is  because an implmentation that does not understand
> >>Service-Type = X must return an error.
> >>
> >>It is obvious that the rules in 3588 are not sufficient to describe when
> >>to use a new Application ID or not.  And we should not have to have a
> >>debate on this topic.
> >>
> >>BTW if we do what you say then in networks where I have NASREQ
> >>performing Network Access and now I want to roll out MIPv6 I would have
> >>to upgrade all my old NASREQ deployed applications.  This is wrong.  I
> >>should be able to add a MIPv6 compliant diameter application without
> >>having to force upgrading my NASREQ applications.
> >>"
> >>
> >>
> >>_______________________________________________
> >>DiME mailing list
> >>DiME@ietf.org
> >>https://www1.ietf.org/mailman/listinfo/dime
> >
> 

-- 
julien.bournelle at int-evry.fr

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



From dime-bounces@ietf.org Mon Aug 21 04:59:41 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GF5dF-0000nB-C2; Mon, 21 Aug 2006 04:59:41 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GF5dF-0000n0-3u
	for dime@ietf.org; Mon, 21 Aug 2006 04:59:41 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129]
	helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GF2mj-0001nC-7e
	for dime@ietf.org; Mon, 21 Aug 2006 01:57:17 -0400
Received: from mgw-ext13.nokia.com ([131.228.20.172])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GF2fs-0004vW-81
	for dime@ietf.org; Mon, 21 Aug 2006 01:50:15 -0400
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211])
	by mgw-ext13.nokia.com (Switch-3.1.10/Switch-3.1.7) with ESMTP id
	k7L5o9NZ018610; Mon, 21 Aug 2006 08:50:10 +0300
Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by
	esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 21 Aug 2006 08:50:09 +0300
Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by
	esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 21 Aug 2006 08:50:09 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Dime] Next Steps for draft-tsou-dime-base-routing-ext-00
Date: Mon, 21 Aug 2006 08:50:08 +0300
Message-ID: <BAA65A575825454CBB0103267553FCCC892125@esebe199.NOE.Nokia.com>
In-Reply-To: <GBEBKGPKHGPAOFCLBNAMMEJPEHAA.asveren@ulticom.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Dime] Next Steps for draft-tsou-dime-base-routing-ext-00
Thread-Index: AcbC5TI2yNxOlnFiToa6v7Nyb1RpvwCAEhHA
From: <john.loughney@nokia.com>
To: <asveren@ulticom.com>, <yohba@tari.toshiba.com>
X-OriginalArrivalTime: 21 Aug 2006 05:50:09.0075 (UTC)
	FILETIME=[A921B030:01C6C4E5]
X-Spam-Score: -2.3 (--)
X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

Hi all,

A very basic question - do we have consensus that we need source
routing and that it is a basic functionality?  Is this something
that is broken in the current document.  If so, then it should
be fixed in the base.  If this is an additional feature, then
it might be fine to have this as an extension draft.

thanks,
John

>-----Original Message-----
>From: ext Tolga Asveren [mailto:asveren@ulticom.com]=20
>Sent: 18 August, 2006 19:16
>To: Yoshihiro Ohba
>Cc: dime@ietf.org
>Subject: RE: [Dime] Next Steps for draft-tsou-dime-base-routing-ext-00
>
>Hi Yoshihiro,
>
>
>> -----Original Message-----
>> From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com]
>> Sent: Thursday, August 17, 2006 11:48 AM
>> To: Hannes Tschofenig
>> Cc: dime@ietf.org
>> Subject: Re: [Dime] Next Steps for=20
>draft-tsou-dime-base-routing-ext-00
>>
>>
>> I think the content of draft-tsou-dime-base-routing-ext-00 should be=20
>> integrated into rfc3588bis, because I think source routing is needed=20
>> to support stateful agents and thus should be part of base protocol.
>[TOLGA]I think we should distinguish between intermediaries,=20
>which advertise support for individual applications instead of=20
>0xffffffff but are not really stateful and which are really=20
>stateful. Currently being stateful and advertising specific=20
>application support is tied together in RFC3588 by definition=20
>of a proxy but I don't think it needs to be. Acctually not=20
>doing so is not violation of the protocol, just defining a new=20
>node type, which is not explicitly mentioned in RFC3588.
>
>An example for the first one is a load-balancer for a specific=20
>application.
>It is interested to get only messages for a specific=20
>application but doesn't keep session related state. If a=20
>message does not have Destination-Host AVP, it forwards the=20
>message to a server based on congestion status of servers (how=20
>this information is propogated is topic for another thread).=20
>If a message has Destination-Host AVP, it just sends the=20
>message to that server.
>
>For that first type of intermediaries, everything would be=20
>working fine if AppId!=3D0 is used for common messages.=20
>Otherwise, a relay agent in front of load balancers serving=20
>different applications is enough to have common messages not=20
>routable to the correct load balancer.
>
>For second type of nodes, which are stateful and want to stay=20
>on the message path, a mechanism as described in the draft is=20
>usefull. There could be other solutions as well -which we=20
>discussed to some extent on the list-, and I would prefer them=20
>to be explained -somewhere-.
>
>>
>> Also, I think that source routing issue can/should be discussed=20
>> separately from the Application Identifier issue.
>[TOLGA]I see some correlation because using AppId=3D0 for common=20
>messages breaks routability of such messages for some=20
>configurations and the draft provides a solution for that.=20
>Otherwise, the draft is useful only for intermediares, which=20
>want to stay on the path during a session.
>>
>> Yoshihiro Ohba
>>
>>
>> On Wed, Aug 16, 2006 at 10:15:19PM +0200, Hannes Tschofenig wrote:
>> > Hi all,
>> >
>> > we discussed this document during the IETF#66 DIME working group=20
>> > meeting. The meeting participants did not express excitement. We=20
>> > would like to solicit feedback from the working group to=20
>see whether=20
>> > there is interest in this work and how we should proceed.
>> >
>> > Ciao
>> > Hannes & John
>> >
>> > _______________________________________________
>> > DiME mailing list
>> > DiME@ietf.org
>> > https://www1.ietf.org/mailman/listinfo/dime
>>
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www1.ietf.org/mailman/listinfo/dime
>
>
>_______________________________________________
>DiME mailing list
>DiME@ietf.org
>https://www1.ietf.org/mailman/listinfo/dime
>

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



From dime-bounces@ietf.org Mon Aug 21 05:34:27 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GF6At-0002s2-UY; Mon, 21 Aug 2006 05:34:27 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GF6As-0002rv-MQ
	for dime@ietf.org; Mon, 21 Aug 2006 05:34:26 -0400
Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GF6Aq-0002j8-9G
	for dime@ietf.org; Mon, 21 Aug 2006 05:34:26 -0400
Received: (qmail invoked by alias); 21 Aug 2006 09:34:22 -0000
Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26]
	by mail.gmx.net (mp041) with SMTP; 21 Aug 2006 11:34:22 +0200
X-Authenticated: #29516787
Message-ID: <44E97E23.3090302@gmx.net>
Date: Mon, 21 Aug 2006 11:34:27 +0200
From: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: john.loughney@nokia.com
Subject: Re: [Dime] Mobile IPv6 Bootstrapping - "Application
	ID"vs."NAS-Port-Type AVP/Service-Type": Summary
References: <BAA65A575825454CBB0103267553FCCC892123@esebe199.NOE.Nokia.com>
In-Reply-To: <BAA65A575825454CBB0103267553FCCC892123@esebe199.NOE.Nokia.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

Hi John,

john.loughney@nokia.com schrieb:
> Hannes,
> 
> 
>>> Apologize for jumping in late....still trying to understand the whole
> 
>>> issue.
>> Please read my copy-and-paste summary of the discussion.
>>
>> In some sense we are discussing fundamentals of how to extend Diameter.
>> The application ID is used for routing. If we don't define a 
>> new app-ID then we cannot route network access messages and 
>> MIP6 bootstrapping messages differently. Some folks think that 
>> this is important.
>> What do you think?
> 
> Just to stir the pot a bit .. I agree with you, we are discussing how
> have a Diameter extension and how it fits into the existing deployment.
> If using MIPv6 with Diameter creates new manditory attributes and/or
> changes the basic state machine, I assume a new application ID should be
> used.

I fully agree with you. If certain criteria are fulfilled then we need 
to work on a Diameter Mobile IPv6 application. We just don't know 
whether these criteria are actually fulfilled given the other 
constraints we have.

> I think that if a new application ID is used, it still could be
> reasonable
> to include information how this new MIPv6 Diameter Application could be
> collocated
> with the existing MIP(v4) Application.

That's certainly a good point; We do not have "a lot of meat" in the 
current document.

> 
> However, general question - have we gotten past the point where we know
> that 
> manditory attributes are required?  I just want to verify that.

I don't think so.

Ciao
Hannes

> 
> thanks,
> John

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



From dime-bounces@ietf.org Mon Aug 21 05:41:59 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GF6IB-0005Iw-Um; Mon, 21 Aug 2006 05:41:59 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GF6IA-0005Gu-P5
	for dime@ietf.org; Mon, 21 Aug 2006 05:41:58 -0400
Received: from smtp2.int-evry.fr ([157.159.10.45])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GF6I9-0004AS-C3
	for dime@ietf.org; Mon, 21 Aug 2006 05:41:58 -0400
Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76])
	by smtp2.int-evry.fr (Postfix) with ESMTP id 4FB27302B7;
	Mon, 21 Aug 2006 11:12:08 +0200 (CEST)
Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.52)
	id 1GF5rB-0006ii-Ut; Mon, 21 Aug 2006 11:14:06 +0200
Date: Mon, 21 Aug 2006 11:14:05 +0200
From: Julien Bournelle <julien.bournelle@int-evry.fr>
To: john.loughney@nokia.com
Subject: Re: [Dime] Mobile IPv6 Bootstrapping - "Application
	ID"vs."NAS-Port-Type AVP/Service-Type": Summary
Message-ID: <20060821091405.GB25787@ipv6-3.int-evry.fr>
References: <44E81827.3070208@gmx.net>
	<BAA65A575825454CBB0103267553FCCC892123@esebe199.NOE.Nokia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <BAA65A575825454CBB0103267553FCCC892123@esebe199.NOE.Nokia.com>
User-Agent: Mutt/1.5.9i
X-INT-MailScanner-Information: Please contact the ISP for more information
X-INT-MailScanner: Found to be clean
X-INT-MailScanner-MCPCheck: 
X-INT-MailScanner-SpamCheck: 
X-MailScanner-From: jb@int-evry.fr
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

Hi John, all,

On Mon, Aug 21, 2006 at 08:46:19AM +0300, john.loughney@nokia.com wrote:
> Hannes,
> 
> 
> >> Apologize for jumping in late....still trying to understand the whole
> 
> >> issue.
> >Please read my copy-and-paste summary of the discussion.
> >
> >In some sense we are discussing fundamentals of how to extend Diameter.
> >The application ID is used for routing. If we don't define a 
> >new app-ID then we cannot route network access messages and 
> >MIP6 bootstrapping messages differently. Some folks think that 
> >this is important.
> >What do you think?
> 
> Just to stir the pot a bit .. I agree with you, we are discussing how
> have a Diameter extension and how it fits into the existing deployment.
> If using MIPv6 with Diameter creates new manditory attributes and/or
> changes the basic state machine, I assume a new application ID should be
> used.
> I think that if a new application ID is used, it still could be
> reasonable
> to include information how this new MIPv6 Diameter Application could be
> collocated
> with the existing MIP(v4) Application.

 The MIPv4 Application is different of the eventual MIPv6 Application.
 The difference is mainly in the Authentication process, MIPv4 defines
 its own messages AMR/AMA which basically carries a MN-AAA
 Authentication AVP. This MN-AAA-Auth AVP is sent in the Reg-Request
 message by the MN to the HA (or FA).
 In MIPv6, EAP is used for authentication.
 So I don't think we could collcoate MIP6 Application with MIP4
 Application.

> 
> However, general question - have we gotten past the point where we know
> that 
> manditory attributes are required?  I just want to verify that.

 For the split scenario (draft-ietf-dime-split-00.txt), if we don't have 
 an App-ID and want the AAA
 server be able for sure that it is performing AAA for mip6 service and
 not for network access, we need to define a new Type for the
 Service-Type AVP or NAS-Port-Type AVP. These AVPs are already
 mandatory.

 Julien
 

> 
> thanks,
> John
> 
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www1.ietf.org/mailman/listinfo/dime

-- 
julien.bournelle at int-evry.fr

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



From dime-bounces@ietf.org Mon Aug 21 06:03:01 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GF6cX-0003EV-7I; Mon, 21 Aug 2006 06:03:01 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GF6cV-0003EQ-SR
	for dime@ietf.org; Mon, 21 Aug 2006 06:02:59 -0400
Received: from mail.gmx.net ([213.165.64.20])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GF6cU-0000TQ-FV
	for dime@ietf.org; Mon, 21 Aug 2006 06:02:59 -0400
Received: (qmail invoked by alias); 21 Aug 2006 09:36:18 -0000
Received: from socks1.netz.sbs.de (EHLO [192.35.17.26]) [192.35.17.26]
	by mail.gmx.net (mp018) with SMTP; 21 Aug 2006 11:36:18 +0200
X-Authenticated: #29516787
Message-ID: <44E97E97.2000102@gmx.net>
Date: Mon, 21 Aug 2006 11:36:23 +0200
From: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: jouni.korhonen@teliasonera.com
Subject: Re: [Dime] Mobile IPv6 Bootstrapping - "Application ID"
	vs."NAS-Port-Type AVP/Service-Type": Summary
References: <5D25AEFB114D034FBDC8B156FCA78E03F1E696@SEHAN021MB.tcad.telia.se>
In-Reply-To: <5D25AEFB114D034FBDC8B156FCA78E03F1E696@SEHAN021MB.tcad.telia.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

Hi Jouni,

~snip~

> For an operator being able to separate normal access and MIP service is
> a desirable feature. However, imho that also falls to general operator
> subscription policies. I.e. whether the operator wants to allow access
> with and without specific service (such as MIP) or not. In the
> integrated
> scenario the MN cannot assume that all access networks support
> bootstrapping
> anyway so the AAA server needs to be prepared for both cases.

So, what is the conclusion. Do we need to have mandatory attributes?

Ciao
Hannes

> 
> Cheers,
> 	Jouni

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



From dime-bounces@ietf.org Mon Aug 21 06:51:15 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GF7N8-0001FC-R0; Mon, 21 Aug 2006 06:51:10 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GF7N6-0001Ek-Sz
	for dime@ietf.org; Mon, 21 Aug 2006 06:51:08 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129]
	helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GF6dW-0000cl-QZ
	for dime@ietf.org; Mon, 21 Aug 2006 06:04:02 -0400
Received: from lizzard.sbs.de ([194.138.37.39])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GF6Di-0001fa-3Y
	for dime@ietf.org; Mon, 21 Aug 2006 05:37:24 -0400
Received: from mail1.sbs.de (localhost [127.0.0.1])
	by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k7L9bI9F000047;
	Mon, 21 Aug 2006 11:37:18 +0200
Received: from fthw9xpa.ww002.siemens.net (fthw9xpa.ww002.siemens.net
	[157.163.133.222])
	by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k7L9bHVU004075;
	Mon, 21 Aug 2006 11:37:17 +0200
Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by
	fthw9xpa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 21 Aug 2006 11:37:17 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: AW: [Dime] Next Steps for draft-tsou-dime-base-routing-ext-00
Date: Mon, 21 Aug 2006 11:37:16 +0200
Message-ID: <A5D2BD54850CCA4AA3B93227205D8A30898C46@MCHP7IEA.ww002.siemens.net>
In-Reply-To: <BAA65A575825454CBB0103267553FCCC892125@esebe199.NOE.Nokia.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Dime] Next Steps for draft-tsou-dime-base-routing-ext-00
Thread-Index: AcbC5TI2yNxOlnFiToa6v7Nyb1RpvwCAEhHAAAevCXA=
From: "Tschofenig, Hannes" <hannes.tschofenig@siemens.com>
To: <john.loughney@nokia.com>, <asveren@ulticom.com>, <yohba@tari.toshiba.com>
X-OriginalArrivalTime: 21 Aug 2006 09:37:17.0244 (UTC)
	FILETIME=[64273FC0:01C6C505]
X-Spam-Score: -2.4 (--)
X-Scan-Signature: 8f374d0786b25a451ef87d82c076f593
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

Hi John,=20
Hi all,

John raised a good point.=20

I went through the mail discussions trigger by
http://www1.ietf.org/mail-archive/web/dime/current/msg00212.html

A draft with a solution was submitted
http://tools.ietf.org/wg/dime/draft-tsou-dime-base-routing-ext-00.txt

Most discussions focused on details of solutions. I was not able to find =

a good problem description, requirements or scenarios. It is not even=20
clear whether there is a real world problem here.

Who is going to write a problem statement/requirements document?=20

Ciao
Hannes=20

> -----Urspr=FCngliche Nachricht-----
> Von: john.loughney@nokia.com [mailto:john.loughney@nokia.com]=20
> Gesendet: Montag, 21. August 2006 07:50
> An: asveren@ulticom.com; yohba@tari.toshiba.com
> Cc: dime@ietf.org
> Betreff: RE: [Dime] Next Steps for draft-tsou-dime-base-routing-ext-00
>=20
> Hi all,
>=20
> A very basic question - do we have consensus that we need source
> routing and that it is a basic functionality?  Is this something
> that is broken in the current document.  If so, then it should
> be fixed in the base.  If this is an additional feature, then
> it might be fine to have this as an extension draft.
>=20
> thanks,
> John
>=20
> >-----Original Message-----
> >From: ext Tolga Asveren [mailto:asveren@ulticom.com]=20
> >Sent: 18 August, 2006 19:16
> >To: Yoshihiro Ohba
> >Cc: dime@ietf.org
> >Subject: RE: [Dime] Next Steps for=20
> draft-tsou-dime-base-routing-ext-00
> >
> >Hi Yoshihiro,
> >
> >
> >> -----Original Message-----
> >> From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com]
> >> Sent: Thursday, August 17, 2006 11:48 AM
> >> To: Hannes Tschofenig
> >> Cc: dime@ietf.org
> >> Subject: Re: [Dime] Next Steps for=20
> >draft-tsou-dime-base-routing-ext-00
> >>
> >>
> >> I think the content of draft-tsou-dime-base-routing-ext-00=20
> should be=20
> >> integrated into rfc3588bis, because I think source routing=20
> is needed=20
> >> to support stateful agents and thus should be part of base=20
> protocol.
> >[TOLGA]I think we should distinguish between intermediaries,=20
> >which advertise support for individual applications instead of=20
> >0xffffffff but are not really stateful and which are really=20
> >stateful. Currently being stateful and advertising specific=20
> >application support is tied together in RFC3588 by definition=20
> >of a proxy but I don't think it needs to be. Acctually not=20
> >doing so is not violation of the protocol, just defining a new=20
> >node type, which is not explicitly mentioned in RFC3588.
> >
> >An example for the first one is a load-balancer for a specific=20
> >application.
> >It is interested to get only messages for a specific=20
> >application but doesn't keep session related state. If a=20
> >message does not have Destination-Host AVP, it forwards the=20
> >message to a server based on congestion status of servers (how=20
> >this information is propogated is topic for another thread).=20
> >If a message has Destination-Host AVP, it just sends the=20
> >message to that server.
> >
> >For that first type of intermediaries, everything would be=20
> >working fine if AppId!=3D0 is used for common messages.=20
> >Otherwise, a relay agent in front of load balancers serving=20
> >different applications is enough to have common messages not=20
> >routable to the correct load balancer.
> >
> >For second type of nodes, which are stateful and want to stay=20
> >on the message path, a mechanism as described in the draft is=20
> >usefull. There could be other solutions as well -which we=20
> >discussed to some extent on the list-, and I would prefer them=20
> >to be explained -somewhere-.
> >
> >>
> >> Also, I think that source routing issue can/should be discussed=20
> >> separately from the Application Identifier issue.
> >[TOLGA]I see some correlation because using AppId=3D0 for common=20
> >messages breaks routability of such messages for some=20
> >configurations and the draft provides a solution for that.=20
> >Otherwise, the draft is useful only for intermediares, which=20
> >want to stay on the path during a session.
> >>
> >> Yoshihiro Ohba
> >>
> >>
> >> On Wed, Aug 16, 2006 at 10:15:19PM +0200, Hannes Tschofenig wrote:
> >> > Hi all,
> >> >
> >> > we discussed this document during the IETF#66 DIME working group=20
> >> > meeting. The meeting participants did not express excitement. We=20
> >> > would like to solicit feedback from the working group to=20
> >see whether=20
> >> > there is interest in this work and how we should proceed.
> >> >
> >> > Ciao
> >> > Hannes & John
> >> >
> >> > _______________________________________________
> >> > DiME mailing list
> >> > DiME@ietf.org
> >> > https://www1.ietf.org/mailman/listinfo/dime
> >>
> >> _______________________________________________
> >> DiME mailing list
> >> DiME@ietf.org
> >> https://www1.ietf.org/mailman/listinfo/dime
> >
> >
> >_______________________________________________
> >DiME mailing list
> >DiME@ietf.org
> >https://www1.ietf.org/mailman/listinfo/dime
> >
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www1.ietf.org/mailman/listinfo/dime
>=20

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



From dime-bounces@ietf.org Mon Aug 21 08:38:14 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GF92c-0007vq-6w; Mon, 21 Aug 2006 08:38:06 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GF92b-0007vZ-EZ
	for dime@ietf.org; Mon, 21 Aug 2006 08:38:05 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129]
	helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GF5su-0006Qk-LP
	for dime@ietf.org; Mon, 21 Aug 2006 05:15:52 -0400
Received: from sehan001bb.han.telia.se ([131.115.18.152])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GF5hT-0000Xa-TY
	for dime@ietf.org; Mon, 21 Aug 2006 05:04:08 -0400
Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by
	sehan001bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 21 Aug 2006 11:04:00 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Dime] Mobile IPv6 Bootstrapping - "Application ID"
	vs."NAS-Port-Type AVP/Service-Type": Summary
Date: Mon, 21 Aug 2006 11:03:54 +0200
Message-ID: <5D25AEFB114D034FBDC8B156FCA78E03F1E696@SEHAN021MB.tcad.telia.se>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Dime] Mobile IPv6 Bootstrapping - "Application ID"
	vs."NAS-Port-Type AVP/Service-Type": Summary
thread-index: AcbELyJyx0yagpypRz+5McD18iWHAwAtDNdQ
From: <jouni.korhonen@teliasonera.com>
To: <Hannes.Tschofenig@gmx.net>,
	<julien.bournelle@int-evry.fr>
X-OriginalArrivalTime: 21 Aug 2006 09:04:00.0557 (UTC)
	FILETIME=[BE08FDD0:01C6C500]
X-Spam-Score: -2.2 (--)
X-Scan-Signature: 1ba0ec39a747b7612d6a8ae66d1a873c
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

Hannes, Julien,=20

> -----Original Message-----
> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]=20
> Sent: 20. elokuuta 2006 11:03
> To: Julien Bournelle
> Cc: dime@ietf.org
> Subject: Re: [Dime] Mobile IPv6 Bootstrapping - "Application=20
> ID" vs."NAS-Port-Type AVP/Service-Type": Summary
>=20
> Hi Julien,
>=20
>=20
> Julien Bournelle schrieb:
> > Hi hannes,
> >=20
> >  thanks for this clarifying mail.
> >=20
> >=20
> > On Wed, Aug 16, 2006 at 10:51:07PM +0200, Hannes Tschofenig wrote:
> >> Hi all,
> >>
> >> I went through the discussion again and noticed that we=20
> haven't reached=20
> >> a conclusion.
> >>
> >> Here is my impression:
> >>
> >> * RFC 3588 leaves a question regarding the extensibility open.
> >>   This needs to be captured in the revision of the base=20
> specification.
> >>
> >> * The main issue seems to be
> >>
> >>   - Do we want to route 'Diameter EAP' message and=20
> 'Diameter Mobile=20
> >> IPv6 Bootstrapping' messages differently?
> >=20
> >  I tend to think that it is safer to assume that some operators may
> >  desire that.
> >=20
> >>     If we want to route them differently then we need to define=20
> >> 'Diameter MIPv6 Bootstrapping' as a Diameter application.
> >>
> >>   - The AAA server differentiates ordinary network access=20
> and MIPv6=20
> >> bootstrapping functionality (with respect to authorization and=20
> >> accounting). In order to do so it must understand the Service-Type=20
> >> and/or NAS-Port-Type AVPs and the defined values.
> >>
> >>     Is this a problem?
> >=20
> >  Not sure to understand this problem. For me, if we have=20
> the App-Id we
> >  don't need Service-Type nor NAS-Port Type.
> >  IF we don't have the App-ID, yes we need to define new values.
> >=20
> >  Maybe i missed the problem you raised.
>=20
> This item is only relevant if you use the Service-Type /=20
> NAS-Port Type=20
> approach. The problem raised in the mailing list discussion was=20
> regarding the type of authorization performed by the AAA=20
> server. If the=20
> AAA server understands the new values then everything is fine. If it=20
> does not understand them then the authorization decision would be=20
> treated as a normal network access scenario. Is this desirable?

For an operator being able to separate normal access and MIP service is
a desirable feature. However, imho that also falls to general operator
subscription policies. I.e. whether the operator wants to allow access
with and without specific service (such as MIP) or not. In the
integrated
scenario the MN cannot assume that all access networks support
bootstrapping
anyway so the AAA server needs to be prepared for both cases.


Cheers,
	Jouni


>=20
>=20
>=20
> Ciao
> Hannes
>=20
> >=20
> >  regards,
> >=20
> >  Julien
>=20
> Ciao
> Hannes
>=20
>=20
> >=20
> >>   - There are problems with proxies and newly defined Diameter=20
> >> Application IDs. Every
> >> proxy on the path needs new code to handle the new=20
> application, while
> >> just adding an extra AVP or new Service-Type value does not hurt.
> >>
> >>     Is this an issue for us?
> >>
> >> Ciao
> >> Hannes
> >>
> >> PS: Here is copy-and-paste version of some discussion=20
> snippets to allow=20
> >> others to catch-up.
> >>
> >> Julien starts the discussion with a question about Application IDs.
> >>
> >> Pasi suggests to consider Service-Type and/or=20
> NAS-Port-Type AVPs as=20
> >> well.... the problem starts.
> >>
> >> Avi states that the problem is that neither Service-Type=20
> or Port-Type is=20
> >> mandatory.
> >> "
> >> Service Type seems to be the correct way but in RADIUS and
> >> Diameter service-type also can be authenticate-only or=20
> authorize-only.
> >> So what if the HA wanted to authenticate-only or=20
> authorize-only for the
> >> MIP service?  I would lose the ability to also indicate=20
> that this is an
> >> HA.
> >>
> >> So Port-Type seems to be the way to go....
> >> "
> >>
> >> Jari jumps in:
> >> "
> >> One of the reasons why an existing application would
> >> be preferred is that then a AAA server that does not
> >> care about the type of service can be used without
> >> changes. Yet servers that do care can look at the
> >> AVPs and make more detailed authorization
> >> decisions.
> >>
> >>
> >> RFC 3588 states that  "Creation of a new application
> >> should be viewed as a last resort." and that "In order
> >> to justify allocation of a new application identifier,
> >> Diameter applications MUST define one Command Code,
> >> or add new mandatory AVPs to the ABNF." Note that
> >> mandatory AVPs can be viewed in different ways,
> >> and that we should not be too strict about them.
> >> For instance, Framed-Protocol is an optional AVP in
> >> RFCs 4005 and 4072. Yet, you could argue that if you
> >> are doing PPP then you need to use this attribute and
> >> set it to PPP. But that didn't make the attribute mandatory.
> >> Do we have a similar situation for the IKEv2/MIPv6
> >> attributes and values? They are not necessary from
> >> the NASREQ/EAP perspective, but in the specific context
> >> you need to use the attributes. In my mind, this does not
> >> make the attributes mandatory from a Diameter
> >> application point of view. If we start creating
> >> new applications for every different situation,
> >> we'll have lots of applications and interoperability
> >> problems. Its better to add new optional AVPs and
> >> describe in text when they should be used. The
> >> only exception that I see is security related AVPs
> >> that must be understood by the other side or else
> >> the session should be terminated.
> >> "
> >>
> >> Avi responds:
> >> "
> >> Mandatory does not mean required in the Command.  It means=20
> that it must
> >> be understood by the receiver.  We need to clarify that.
> >> "
> >>
> >> Gerardo and Lionel agree with Jari.
> >>
> >>
> >>
> >> Avi writes:
> >> "
> >> If I have two EAP based application in my network, one that is
> >> handling pure EAP application, the other is extended to=20
> handle the new
> >> behavior then I need a way to route the (same) command correctly.
> >> "
> >>
> >> Jari writes:
> >> "
> >> Ah, but that is a new requirement. If you believe that you need
> >> to route EAP authentication from a 802.11 AP differently
> >> than from IKEv2/MIPv6, then you need one of these:
> >>
> >> - Use different user/domain names for the users of
> >>   the different services.
> >>
> >> - Point to different servers from the AP and SGW (but
> >>   this works less well if you have proxies and roaming).
> >>
> >> - New application ID.
> >>
> >> - Some weird form of Diameter and RADIUS source routing
> >>   based on what type of node sent the message.
> >>
> >> However, it is far from clear to me why you would really
> >> need to route the authentication differently *for the same
> >> user*. Many authentication mechanisms can also have state,
> >> which would imply that at the end they need to end up in
> >> the same device anyhow. Can you expand on why you need
> >> to handle the same users in different authentication
> >> servers?
> >> "
> >>
> >> Avi to Jari:
> >>
> >> "
> >> BTW in the context of the original question raised, the=20
> attribute(s)
> >> will not be optional. Here is the snippet:
> >>
> >>>>>>  In our case, the AAA server must perform AAA=20
> functionality for the
> >>>>>> Mobile IPv6 service. The AAA server must know that it has to
> >>>>>> authorize the mip6 service and the accounting=20
> (ASR/ASA) is also for
> >>>>>>  mip6 and not for network access.
> >> If the Diameter message comes from the HA then the HA MUST=20
> include the
> >> NAS-Port-type attribute. So the command ABNF is being=20
> changed. Also the
> >> behavior is being changed of the Server.  It MUST=20
> recognize the (new)
> >> value of the NAS-Port-Type.
> >> "
> >>
> >>
> >> Yoshi says:
> >> "
> >> If what is important is service-specific routing (I am not=20
> convinced
> >> with it yet), I'd suggest defining a new authorization-only
> >> application used only for carrying service-specific attributes
> >> (analogous to NASREQ usage in RFC 4072).  The downside is that it
> >> needs another message roundtrip than carrying the attributes in
> >> DER/DEA.
> >> "
> >>
> >>
> >> Julien wrote:
> >> "
> >>>> I don't think it's clean to require use of different
> >>>> users'identifiers in order to distinguish which services is
> >>>> provided. For me, it looks like a 'hack'.
> >> " and Pasi responded:
> >> "
> >> I fully agree -- but having separate user identifiers should not be
> >> necessary. If, for example, an operator wants to perform different
> >> authorizations for WiFi and WiMAX (e.g., some users can access only
> >> WiFi but not WiMAX), that's simple to do: just check Service-Type,
> >> NAS-Port-Type, and other relevant authorization AVPs.  There's
> >> absolutely no need to create a new Diameter application.
> >>
> >> If the AAA server is really strict about WiFi vs. WiMAX=20
> separation, it
> >> can have a policy that requires the NAS-Port-Type AVP to be present
> >> (if the request does not contain it, access is denied).=20
> Although this
> >> in some sense make NAS-Port-Type AVP "mandatory", it's not=20
> "mandatory"
> >> in the sense that would require a new Diameter application.
> >>
> >> While IKEv2 and MIP6 are not WiFi and WiMAX, I don't think=20
> there are
> >> any significant differences from Diameter point-of-view.=20
> There's a box
> >> providing some service; authentication works with EAP;=20
> authorization
> >> AVPs indicate what exactly is being authorized. What's missing is
> >> a document describing how the different authorization AVPs are
> >> used in this particular situation; sort of like RFC 3580=20
> (IEEE 802.1X
> >> RADIUS Usage Guidelines), but for Diameter with IKEv2.
> >>
> >> One important reason NOT to create new applications: proxies. Every
> >> proxy on the path needs new code to handle the new=20
> application, while
> >> just adding an extra AVP or new Service-Type value doesn't.
> >> "
> >>
> >> John agrees with Pasi.
> >>
> >> Avi writes:
> >> "
> >> A mandatory attribute (a must understand attribute) that has a new
> >> enumeration is in my mind is like adding a new attribute=20
> that must be
> >> understood.  There is no wigle room here.  The command=20
> carrying that
> >> attribute must reach the implementation that knows how to=20
> interpret the
> >> attribute.  This is  because an implmentation that does=20
> not understand
> >> Service-Type =3D X must return an error.
> >>
> >> It is obvious that the rules in 3588 are not sufficient to=20
> describe when
> >> to use a new Application ID or not.  And we should not=20
> have to have a
> >> debate on this topic.
> >>
> >> BTW if we do what you say then in networks where I have NASREQ
> >> performing Network Access and now I want to roll out MIPv6=20
> I would have
> >> to upgrade all my old NASREQ deployed applications.  This=20
> is wrong.  I
> >> should be able to add a MIPv6 compliant diameter=20
> application without
> >> having to force upgrading my NASREQ applications.
> >> "
> >>
> >>
> >> _______________________________________________
> >> DiME mailing list
> >> DiME@ietf.org
> >> https://www1.ietf.org/mailman/listinfo/dime
> >=20
>=20
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www1.ietf.org/mailman/listinfo/dime
>=20

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



From dime-bounces@ietf.org Mon Aug 21 09:04:17 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GF9Rx-0007Cf-5q; Mon, 21 Aug 2006 09:04:17 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GF9Rw-0007CG-0N
	for dime@ietf.org; Mon, 21 Aug 2006 09:04:16 -0400
Received: from inet-tsb.toshiba.co.jp ([202.33.96.40])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GF9Ro-0000T7-6u
	for dime@ietf.org; Mon, 21 Aug 2006 09:04:15 -0400
Received: from tsb-wall.toshiba.co.jp ([133.199.160.134])
	by inet-tsb.toshiba.co.jp  with ESMTP id k7LD438W017195;
	Mon, 21 Aug 2006 22:04:03 +0900 (JST)
Received: (from root@localhost) by tsb-wall.toshiba.co.jp  id k7LD44xG003861;
	Mon, 21 Aug 2006 22:04:04 +0900 (JST)
Received: from ovp1.toshiba.co.jp [133.199.192.124] 
	by tsb-wall.toshiba.co.jp with SMTP id YAA03827;
	Mon, 21 Aug 2006 22:04:04 +0900
Received: from mx.toshiba.co.jp (localhost [127.0.0.1])
	by ovp1.toshiba.co.jp  with ESMTP id k7LD42c0015841;
	Mon, 21 Aug 2006 22:04:02 +0900 (JST)
Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k7LD42C7004097;
	Mon, 21 Aug 2006 22:04:02 +0900 (JST)
Received: from steelhead ([172.30.24.104])
	by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built
	Apr 28
	2004)) with ESMTPSA id <0J4C00A40MYLLWL0@mail.po.toshiba.co.jp>; Mon,
	21 Aug 2006 22:04:02 +0900 (JST)
Received: from ohba by steelhead with local (Exim 4.62)
	(envelope-from <yohba@tari.toshiba.com>)	id 1GF9RU-0005ea-5z; Mon,
	21 Aug 2006 06:03:48 -0700
Date: Mon, 21 Aug 2006 09:03:48 -0400
From: Yoshihiro Ohba <yohba@tari.toshiba.com>
Subject: Re: [Dime] Next Steps for draft-tsou-dime-base-routing-ext-00
In-reply-to: <4C0FAAC489C8B74F96BEAD85EAEB26250279D852@xmb-sjc-215.amer.cisco.com>
To: "Glen Zorn (gwz)" <gwz@cisco.com>
Message-id: <20060821130348.GC21216@steelhead>
MIME-version: 1.0
Content-type: text/plain; charset=iso-2022-jp
Content-disposition: inline
References: <4C0FAAC489C8B74F96BEAD85EAEB26250279D852@xmb-sjc-215.amer.cisco.com>
User-Agent: Mutt/1.5.11+cvs20060403
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

Hi Glen,

On Thu, Aug 17, 2006 at 07:13:48PM -0700, Glen Zorn (gwz) wrote:
> Yoshihiro Ohba <mailto:yohba@tari.toshiba.com> supposedly scribbled:
> 
> > I think the content of draft-tsou-dime-base-routing-ext-00 should be
> > integrated into rfc3588bis, because I think source routing is needed
> > to support stateful agents 
> 
> Assuming that some Diameter agents currently exist & given that Diameter agents are by definition stateful (see RFC 3588, section 1.3, "Transaction State", it's hard to see how this statement can be correct.
> 

Statefulness of Diameter agents is in terms of session state, not
transaction state.  In fact, Section 1.3 of RFC 3588 says:

"A stateless agent is one that only maintains transaction state."

Regards,
Yoshihiro Ohba

> ...
> 
> Hope this helps,
> 
> ~gwz
> 
> Why is it that most of the world's problems can't be solved by simply
>   listening to John Coltrane? -- Henry Gabriel

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



From dime-bounces@ietf.org Mon Aug 21 09:11:13 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GF9Yf-0000N9-R9; Mon, 21 Aug 2006 09:11:13 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GF9Ye-0000N1-Ra; Mon, 21 Aug 2006 09:11:12 -0400
Received: from mgw-ext14.nokia.com ([131.228.20.173])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GF9Yd-0001Z5-Bn; Mon, 21 Aug 2006 09:11:12 -0400
Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211])
	by mgw-ext14.nokia.com (Switch-3.1.10/Switch-3.1.7) with ESMTP id
	k7LDAuqJ010133; Mon, 21 Aug 2006 16:10:59 +0300
Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by
	esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 21 Aug 2006 16:10:39 +0300
Received: from esebe199.NOE.Nokia.com ([172.21.138.143]) by
	esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 21 Aug 2006 16:10:39 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Dime] Mobile IPv6 Bootstrapping - "Application
	ID"vs."NAS-Port-Type AVP/Service-Type": Summary
Date: Mon, 21 Aug 2006 16:10:39 +0300
Message-ID: <BAA65A575825454CBB0103267553FCCC89215B@esebe199.NOE.Nokia.com>
In-Reply-To: <5D25AEFB114D034FBDC8B156FCA78E03F1E696@SEHAN021MB.tcad.telia.se>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Dime] Mobile IPv6 Bootstrapping - "Application
	ID"vs."NAS-Port-Type AVP/Service-Type": Summary
Thread-Index: AcbELyJyx0yagpypRz+5McD18iWHAwAtDNdQAA/vJ5A=
From: <john.loughney@nokia.com>
To: <dime-bounces@ietf.org>, <Hannes.Tschofenig@gmx.net>,
	<julien.bournelle@int-evry.fr>
X-OriginalArrivalTime: 21 Aug 2006 13:10:39.0473 (UTC)
	FILETIME=[32E05E10:01C6C523]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

Hi all,

>> This item is only relevant if you use the Service-Type /=20
>NAS-Port Type=20
>> approach. The problem raised in the mailing list discussion was=20
>> regarding the type of authorization performed by the AAA server. If=20
>> the AAA server understands the new values then everything is=20
>fine. If=20
>> it does not understand them then the authorization decision would be=20
>> treated as a normal network access scenario. Is this desirable?
>
>For an operator being able to separate normal access and MIP=20
>service is a desirable feature. However, imho that also falls=20
>to general operator subscription policies. I.e. whether the=20
>operator wants to allow access with and without specific=20
>service (such as MIP) or not. In the integrated scenario the=20
>MN cannot assume that all access networks support=20
>bootstrapping anyway so the AAA server needs to be prepared=20
>for both cases.

Out of curiousity, are there any networks doing this? I assume in
3GPP2 networks where MIPv4 is deployed, MIPv4 access isn't an extra,
billable service.

John

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



From dime-bounces@ietf.org Mon Aug 21 10:28:01 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GFAkr-0007nf-Dn; Mon, 21 Aug 2006 10:27:53 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GFAkp-0007nK-HO; Mon, 21 Aug 2006 10:27:51 -0400
Received: from mx0.starentnetworks.com ([12.38.223.203])
	by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GFAjQ-0007cM-Vu; Mon, 21 Aug 2006 10:26:26 -0400
Received: from localhost (localhost.localdomain [127.0.0.1])
	by mx0.starentnetworks.com (Postfix) with ESMTP id 747C990011;
	Mon, 21 Aug 2006 10:26:19 -0400 (EDT)
Received: from mx0.starentnetworks.com ([127.0.0.1])
	by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 07623-07; Mon, 21 Aug 2006 10:26:18 -0400 (EDT)
Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com
	[12.33.233.52]) by mx0.starentnetworks.com (Postfix) with ESMTP;
	Mon, 21 Aug 2006 10:26:18 -0400 (EDT)
X-MessageTextProcessor: DisclaimIt (2.70.271) [Starent Networks Corp.]
Received: from exchtewks2.starentnetworks.com ([12.33.232.12]) by
	exchtewks1.starentnetworks.com with Microsoft
	SMTPSVC(6.0.3790.1830); Mon, 21 Aug 2006 10:26:18 -0400
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Dime] Mobile IPv6 Bootstrapping -
	"ApplicationID"vs."NAS-Port-Type AVP/Service-Type": Summary
Date: Mon, 21 Aug 2006 10:26:18 -0400
Message-ID: <7CCD07160348804497EF29E9EA5560D7837215@exchtewks2.starentnetworks.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Dime] Mobile IPv6 Bootstrapping -
	"ApplicationID"vs."NAS-Port-Type AVP/Service-Type": Summary
thread-index: AcbELyJyx0yagpypRz+5McD18iWHAwAtDNdQAA/vJ5AAAoDfkA==
From: "Chowdhury, Kuntal" <kchowdhury@starentnetworks.com>
To: <john.loughney@nokia.com>, <dime-bounces@ietf.org>,
	<Hannes.Tschofenig@gmx.net>, <julien.bournelle@int-evry.fr>
Importance: normal
Priority: normal
X-OriginalArrivalTime: 21 Aug 2006 14:26:18.0658 (UTC)
	FILETIME=[C4710820:01C6C52D]
X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org



> -----Original Message-----
> From: john.loughney@nokia.com [mailto:john.loughney@nokia.com]
> Sent: Monday, August 21, 2006 8:11 AM
> To: dime-bounces@ietf.org; Hannes.Tschofenig@gmx.net;
> julien.bournelle@int-evry.fr
> Cc: dime@ietf.org
> Subject: RE: [Dime] Mobile IPv6 Bootstrapping -
"ApplicationID"vs."NAS-
> Port-Type AVP/Service-Type": Summary
>=20
> Hi all,
>=20
> >> This item is only relevant if you use the Service-Type /
> >NAS-Port Type
> >> approach. The problem raised in the mailing list discussion was
> >> regarding the type of authorization performed by the AAA server. If
> >> the AAA server understands the new values then everything is
> >fine. If
> >> it does not understand them then the authorization decision would
be
> >> treated as a normal network access scenario. Is this desirable?
> >
> >For an operator being able to separate normal access and MIP
> >service is a desirable feature. However, imho that also falls
> >to general operator subscription policies. I.e. whether the
> >operator wants to allow access with and without specific
> >service (such as MIP) or not. In the integrated scenario the
> >MN cannot assume that all access networks support
> >bootstrapping anyway so the AAA server needs to be prepared
> >for both cases.
>=20
> Out of curiousity, are there any networks doing this? I assume in
> 3GPP2 networks where MIPv4 is deployed, MIPv4 access isn't an extra,
> billable service.
>=20
[KC>] Not that I know of. The parameters for MIP6 bootstrapping are
downloaded to the NAS or to the HA via regular EAP auth (i.e. access
auth at the NAS and IKEv2 auth at the HA) via DER/DEA.
=20
> John
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www1.ietf.org/mailman/listinfo/dime


"This email message and any attachments are confidential information of =
Starent Networks, Corp. The information transmitted may not be used to =
create or change any contractual obligations of Starent Networks, Corp.  =
Any review, retransmission, dissemination or other use of, or taking of =
any action in reliance upon this e-mail and its attachments by persons =
or entities other than the intended recipient is prohibited. If you are =
not the intended recipient, please notify the sender immediately -- by =
replying to this message or by sending an email to =
postmaster@starentnetworks.com -- and destroy all copies of this message =
and any attachments without reading or disclosing their contents. Thank =
you."

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



From dime-bounces@ietf.org Mon Aug 21 10:29:34 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GFAmU-0008Hg-8p; Mon, 21 Aug 2006 10:29:34 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GFAmT-0008Hb-E7
	for dime@ietf.org; Mon, 21 Aug 2006 10:29:33 -0400
Received: from [2001:418:1403:0:212:17ff:fe52:7811]
	(helo=toshi17.tari.toshiba.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFAmN-0008Us-TC
	for dime@ietf.org; Mon, 21 Aug 2006 10:29:33 -0400
Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10])
	by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id
	k7LESh4N001106; Mon, 21 Aug 2006 10:28:43 -0400 (EDT)
	(envelope-from vfajardo@tari.toshiba.com)
Message-ID: <44E9C32E.5060007@tari.toshiba.com>
Date: Mon, 21 Aug 2006 10:29:02 -0400
From: Victor Fajardo <vfajardo@tari.toshiba.com>
User-Agent: Thunderbird 1.5.0.5 (X11/20060719)
MIME-Version: 1.0
To: john.loughney@nokia.com
Subject: Re: [Dime] Next Steps for draft-tsou-dime-base-routing-ext-00
References: <BAA65A575825454CBB0103267553FCCC892125@esebe199.NOE.Nokia.com>
In-Reply-To: <BAA65A575825454CBB0103267553FCCC892125@esebe199.NOE.Nokia.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: -2.4 (--)
X-Scan-Signature: 6640e3bbe8a4d70c4469bcdcbbf0921d
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

Hi John,

> Hi all,
>
> A very basic question - do we have consensus that we need source
> routing and that it is a basic functionality?  Is this something
> that is broken in the current document.  

The intention of the document was to propose an "extension" to the 
current routing functionality of the base to fulfill requirements in 
topologies where this functionality is needed. (i think these 
topologies/scenarios has been discussed lengthly in the list). Following 
your guideline, I think it maybe better that this should be an extension 
document given that it is not proposing changes to the existing routing 
schemes. I also think that the WG should work on this document since it 
does fulfill real world requirements.

regards,
victor

> If so, then it should
> be fixed in the base.  If this is an additional feature, then
> it might be fine to have this as an extension draft.
>
> thanks,
> John
>
>   
>> -----Original Message-----
>> From: ext Tolga Asveren [mailto:asveren@ulticom.com] 
>> Sent: 18 August, 2006 19:16
>> To: Yoshihiro Ohba
>> Cc: dime@ietf.org
>> Subject: RE: [Dime] Next Steps for draft-tsou-dime-base-routing-ext-00
>>
>> Hi Yoshihiro,
>>
>>
>>     
>>> -----Original Message-----
>>> From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com]
>>> Sent: Thursday, August 17, 2006 11:48 AM
>>> To: Hannes Tschofenig
>>> Cc: dime@ietf.org
>>> Subject: Re: [Dime] Next Steps for 
>>>       
>> draft-tsou-dime-base-routing-ext-00
>>     
>>> I think the content of draft-tsou-dime-base-routing-ext-00 should be 
>>> integrated into rfc3588bis, because I think source routing is needed 
>>> to support stateful agents and thus should be part of base protocol.
>>>       
>> [TOLGA]I think we should distinguish between intermediaries, 
>> which advertise support for individual applications instead of 
>> 0xffffffff but are not really stateful and which are really 
>> stateful. Currently being stateful and advertising specific 
>> application support is tied together in RFC3588 by definition 
>> of a proxy but I don't think it needs to be. Acctually not 
>> doing so is not violation of the protocol, just defining a new 
>> node type, which is not explicitly mentioned in RFC3588.
>>
>> An example for the first one is a load-balancer for a specific 
>> application.
>> It is interested to get only messages for a specific 
>> application but doesn't keep session related state. If a 
>> message does not have Destination-Host AVP, it forwards the 
>> message to a server based on congestion status of servers (how 
>> this information is propogated is topic for another thread). 
>> If a message has Destination-Host AVP, it just sends the 
>> message to that server.
>>
>> For that first type of intermediaries, everything would be 
>> working fine if AppId!=0 is used for common messages. 
>> Otherwise, a relay agent in front of load balancers serving 
>> different applications is enough to have common messages not 
>> routable to the correct load balancer.
>>
>> For second type of nodes, which are stateful and want to stay 
>> on the message path, a mechanism as described in the draft is 
>> usefull. There could be other solutions as well -which we 
>> discussed to some extent on the list-, and I would prefer them 
>> to be explained -somewhere-.
>>
>>     
>>> Also, I think that source routing issue can/should be discussed 
>>> separately from the Application Identifier issue.
>>>       
>> [TOLGA]I see some correlation because using AppId=0 for common 
>> messages breaks routability of such messages for some 
>> configurations and the draft provides a solution for that. 
>> Otherwise, the draft is useful only for intermediares, which 
>> want to stay on the path during a session.
>>     
>>> Yoshihiro Ohba
>>>
>>>
>>> On Wed, Aug 16, 2006 at 10:15:19PM +0200, Hannes Tschofenig wrote:
>>>       
>>>> Hi all,
>>>>
>>>> we discussed this document during the IETF#66 DIME working group 
>>>> meeting. The meeting participants did not express excitement. We 
>>>> would like to solicit feedback from the working group to 
>>>>         
>> see whether 
>>     
>>>> there is interest in this work and how we should proceed.
>>>>
>>>> Ciao
>>>> Hannes & John
>>>>
>>>> _______________________________________________
>>>> DiME mailing list
>>>> DiME@ietf.org
>>>> https://www1.ietf.org/mailman/listinfo/dime
>>>>         
>>> _______________________________________________
>>> DiME mailing list
>>> DiME@ietf.org
>>> https://www1.ietf.org/mailman/listinfo/dime
>>>       
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www1.ietf.org/mailman/listinfo/dime
>>
>>     
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www1.ietf.org/mailman/listinfo/dime
>
>
>
>   


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



From dime-bounces@ietf.org Mon Aug 21 10:45:44 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GFB1y-0005JH-DQ; Mon, 21 Aug 2006 10:45:34 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GFB1w-0005J4-P0
	for dime@ietf.org; Mon, 21 Aug 2006 10:45:32 -0400
Received: from mx0.starentnetworks.com ([12.38.223.203])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFB1t-0004sT-Of
	for dime@ietf.org; Mon, 21 Aug 2006 10:45:32 -0400
Received: from localhost (localhost.localdomain [127.0.0.1])
	by mx0.starentnetworks.com (Postfix) with ESMTP id DC8AC90041;
	Mon, 21 Aug 2006 10:45:25 -0400 (EDT)
Received: from mx0.starentnetworks.com ([127.0.0.1])
	by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 08125-04; Mon, 21 Aug 2006 10:45:24 -0400 (EDT)
Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com
	[12.33.233.52]) by mx0.starentnetworks.com (Postfix) with ESMTP;
	Mon, 21 Aug 2006 10:45:24 -0400 (EDT)
X-MessageTextProcessor: DisclaimIt (2.70.271) [Starent Networks Corp.]
Received: from exchtewks2.starentnetworks.com ([12.33.232.12]) by
	exchtewks1.starentnetworks.com with Microsoft
	SMTPSVC(6.0.3790.1830); Mon, 21 Aug 2006 10:45:24 -0400
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Dime] Mobile IPv6 Bootstrapping - "Application ID"
	vs."NAS-Port-Type AVP/Service-Type": Summary
Date: Mon, 21 Aug 2006 10:45:24 -0400
Message-ID: <7CCD07160348804497EF29E9EA5560D7837217@exchtewks2.starentnetworks.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Dime] Mobile IPv6 Bootstrapping - "Application ID"
	vs."NAS-Port-Type AVP/Service-Type": Summary
thread-index: AcbEL57agT/n7nm3TmmkI0AGzDo4RAA/kEAw
From: "Chowdhury, Kuntal" <kchowdhury@starentnetworks.com>
To: "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>
Importance: normal
Priority: normal
X-OriginalArrivalTime: 21 Aug 2006 14:45:24.0594 (UTC)
	FILETIME=[6F78FD20:01C6C530]
X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2fe944273194be3112d13b31c91e6941
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org



> -----Original Message-----
> From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
> Sent: Sunday, August 20, 2006 3:07 AM
> To: Chowdhury, Kuntal
> Cc: Julien Bournelle; dime@ietf.org
> Subject: Re: [Dime] Mobile IPv6 Bootstrapping - "Application ID"
vs."NAS-
> Port-Type AVP/Service-Type": Summary
>=20
> Hi Kuntal,
>=20
>=20
> Chowdhury, Kuntal schrieb:
> > Hi Hannes, Julien,
> >
> > Application-ID is one way, but as has been discussed so far it
requires
> > changes in the intermediaries.
>=20
> True.
>=20
>   A new value in NAS-Port-Type AVP seems
> > more logical and easier to implement, IMHO.
>=20
> Easier to implement: True.
>=20
>   I am not sure about the
> > Service-Type AVP. I am wondering what cannot be conveyed via
> > NAS-Port-Type AVP so that we need this additional AVP?
> >
> > Apologize for jumping in late....still trying to understand the
whole
> > issue.
> Please read my copy-and-paste summary of the discussion.
>=20
> In some sense we are discussing fundamentals of how to extend
Diameter.
> The application ID is used for routing. If we don't define a new
app-ID
> then we cannot route network access messages and MIP6 bootstrapping
> messages differently. Some folks think that this is important.
> What do you think?
>=20
[KC>] In case of split scenario, I see the use case where the AAA
transaction for network access at the NAS is going to a different AAA
server than the same at the HA, since ASA !=3D MSA in split. In case of
integrated scenario, it is essential that the AAA transactions from the
NAS and from the HA get routed to the same AAA server (ASA =3D=3D MSA). =
So
we need to keep this in mind.

>From the AAA message routing point of view, I thought the @realm part of
the username (NAI) was sufficient to route AAA messages to different AAA
systems. There are other reasons for separate APP-ID for MIP6
bootstrapping, e.g. if we decide to mandate AVPs needed for MIP6
bootstrapping in DER/DEA (as an example). I don't know why we would do
that i.e. mandate MIP6 bootstrapping AVPs in DER/DEA.


> Ciao
> Hannes
>=20
> >
> > -Kuntal
> >
> >
> >> -----Original Message-----
> >> From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr]
> >> Sent: Friday, August 18, 2006 11:54 AM
> >> To: Hannes Tschofenig
> >> Cc: dime@ietf.org
> >> Subject: Re: [Dime] Mobile IPv6 Bootstrapping - "Application ID"
> > vs."NAS-
> >> Port-Type AVP/Service-Type": Summary
> >>
> >> Hi hannes,
> >>
> >>  thanks for this clarifying mail.
> >>
> >>
> >> On Wed, Aug 16, 2006 at 10:51:07PM +0200, Hannes Tschofenig wrote:
> >>> Hi all,
> >>>
> >>> I went through the discussion again and noticed that we haven't
> > reached
> >>> a conclusion.
> >>>
> >>> Here is my impression:
> >>>
> >>> * RFC 3588 leaves a question regarding the extensibility open.
> >>>   This needs to be captured in the revision of the base
> > specification.
> >>> * The main issue seems to be
> >>>
> >>>   - Do we want to route 'Diameter EAP' message and 'Diameter
Mobile
> >>> IPv6 Bootstrapping' messages differently?
> >>  I tend to think that it is safer to assume that some operators may
> >>  desire that.
> >>
> >>>     If we want to route them differently then we need to define
> >>> 'Diameter MIPv6 Bootstrapping' as a Diameter application.
> >>>
> >>>   - The AAA server differentiates ordinary network access and
MIPv6
> >>> bootstrapping functionality (with respect to authorization and
> >>> accounting). In order to do so it must understand the Service-Type
> >>> and/or NAS-Port-Type AVPs and the defined values.
> >>>
> >>>     Is this a problem?
> >>  Not sure to understand this problem. For me, if we have the App-Id
we
> >>  don't need Service-Type nor NAS-Port Type.
> >>  IF we don't have the App-ID, yes we need to define new values.
> >>
> >>  Maybe i missed the problem you raised.
> >>
> >>  regards,
> >>
> >>  Julien
> >>
> >>>   - There are problems with proxies and newly defined Diameter
> >>> Application IDs. Every
> >>> proxy on the path needs new code to handle the new application,
> > while
> >>> just adding an extra AVP or new Service-Type value does not hurt.
> >>>
> >>>     Is this an issue for us?
> >>>
> >>> Ciao
> >>> Hannes
> >>>
> >>> PS: Here is copy-and-paste version of some discussion snippets to
> > allow
> >>> others to catch-up.
> >>>
> >>> Julien starts the discussion with a question about Application
IDs.
> >>>
> >>> Pasi suggests to consider Service-Type and/or NAS-Port-Type AVPs
as
> >>> well.... the problem starts.
> >>>
> >>> Avi states that the problem is that neither Service-Type or
> > Port-Type is
> >>> mandatory.
> >>> "
> >>> Service Type seems to be the correct way but in RADIUS and
> >>> Diameter service-type also can be authenticate-only or
> > authorize-only.
> >>> So what if the HA wanted to authenticate-only or authorize-only
for
> > the
> >>> MIP service?  I would lose the ability to also indicate that this
is
> > an
> >>> HA.
> >>>
> >>> So Port-Type seems to be the way to go....
> >>> "
> >>>
> >>> Jari jumps in:
> >>> "
> >>> One of the reasons why an existing application would
> >>> be preferred is that then a AAA server that does not
> >>> care about the type of service can be used without
> >>> changes. Yet servers that do care can look at the
> >>> AVPs and make more detailed authorization
> >>> decisions.
> >>>
> >>>
> >>> RFC 3588 states that  "Creation of a new application
> >>> should be viewed as a last resort." and that "In order
> >>> to justify allocation of a new application identifier,
> >>> Diameter applications MUST define one Command Code,
> >>> or add new mandatory AVPs to the ABNF." Note that
> >>> mandatory AVPs can be viewed in different ways,
> >>> and that we should not be too strict about them.
> >>> For instance, Framed-Protocol is an optional AVP in
> >>> RFCs 4005 and 4072. Yet, you could argue that if you
> >>> are doing PPP then you need to use this attribute and
> >>> set it to PPP. But that didn't make the attribute mandatory.
> >>> Do we have a similar situation for the IKEv2/MIPv6
> >>> attributes and values? They are not necessary from
> >>> the NASREQ/EAP perspective, but in the specific context
> >>> you need to use the attributes. In my mind, this does not
> >>> make the attributes mandatory from a Diameter
> >>> application point of view. If we start creating
> >>> new applications for every different situation,
> >>> we'll have lots of applications and interoperability
> >>> problems. Its better to add new optional AVPs and
> >>> describe in text when they should be used. The
> >>> only exception that I see is security related AVPs
> >>> that must be understood by the other side or else
> >>> the session should be terminated.
> >>> "
> >>>
> >>> Avi responds:
> >>> "
> >>> Mandatory does not mean required in the Command.  It means that it
> > must
> >>> be understood by the receiver.  We need to clarify that.
> >>> "
> >>>
> >>> Gerardo and Lionel agree with Jari.
> >>>
> >>>
> >>>
> >>> Avi writes:
> >>> "
> >>> If I have two EAP based application in my network, one that is
> >>> handling pure EAP application, the other is extended to handle the
> > new
> >>> behavior then I need a way to route the (same) command correctly.
> >>> "
> >>>
> >>> Jari writes:
> >>> "
> >>> Ah, but that is a new requirement. If you believe that you need
> >>> to route EAP authentication from a 802.11 AP differently
> >>> than from IKEv2/MIPv6, then you need one of these:
> >>>
> >>> - Use different user/domain names for the users of
> >>>   the different services.
> >>>
> >>> - Point to different servers from the AP and SGW (but
> >>>   this works less well if you have proxies and roaming).
> >>>
> >>> - New application ID.
> >>>
> >>> - Some weird form of Diameter and RADIUS source routing
> >>>   based on what type of node sent the message.
> >>>
> >>> However, it is far from clear to me why you would really
> >>> need to route the authentication differently *for the same
> >>> user*. Many authentication mechanisms can also have state,
> >>> which would imply that at the end they need to end up in
> >>> the same device anyhow. Can you expand on why you need
> >>> to handle the same users in different authentication
> >>> servers?
> >>> "
> >>>
> >>> Avi to Jari:
> >>>
> >>> "
> >>> BTW in the context of the original question raised, the
attribute(s)
> >>> will not be optional. Here is the snippet:
> >>>
> >>>>>>>  In our case, the AAA server must perform AAA functionality
> > for
> >> the
> >>>>>>> Mobile IPv6 service. The AAA server must know that it has to
> >>>>>>> authorize the mip6 service and the accounting (ASR/ASA) is
> > also
> >> for
> >>>>>>>  mip6 and not for network access.
> >>> If the Diameter message comes from the HA then the HA MUST include
> > the
> >>> NAS-Port-type attribute. So the command ABNF is being changed.
Also
> > the
> >>> behavior is being changed of the Server.  It MUST recognize the
> > (new)
> >>> value of the NAS-Port-Type.
> >>> "
> >>>
> >>>
> >>> Yoshi says:
> >>> "
> >>> If what is important is service-specific routing (I am not
convinced
> >>> with it yet), I'd suggest defining a new authorization-only
> >>> application used only for carrying service-specific attributes
> >>> (analogous to NASREQ usage in RFC 4072).  The downside is that it
> >>> needs another message roundtrip than carrying the attributes in
> >>> DER/DEA.
> >>> "
> >>>
> >>>
> >>> Julien wrote:
> >>> "
> >>>>> I don't think it's clean to require use of different
> >>>>> users'identifiers in order to distinguish which services is
> >>>>> provided. For me, it looks like a 'hack'.
> >>> " and Pasi responded:
> >>> "
> >>> I fully agree -- but having separate user identifiers should not
be
> >>> necessary. If, for example, an operator wants to perform different
> >>> authorizations for WiFi and WiMAX (e.g., some users can access
only
> >>> WiFi but not WiMAX), that's simple to do: just check Service-Type,
> >>> NAS-Port-Type, and other relevant authorization AVPs.  There's
> >>> absolutely no need to create a new Diameter application.
> >>>
> >>> If the AAA server is really strict about WiFi vs. WiMAX
separation,
> > it
> >>> can have a policy that requires the NAS-Port-Type AVP to be
present
> >>> (if the request does not contain it, access is denied). Although
> > this
> >>> in some sense make NAS-Port-Type AVP "mandatory", it's not
> > "mandatory"
> >>> in the sense that would require a new Diameter application.
> >>>
> >>> While IKEv2 and MIP6 are not WiFi and WiMAX, I don't think there
are
> >>> any significant differences from Diameter point-of-view. There's a
> > box
> >>> providing some service; authentication works with EAP;
authorization
> >>> AVPs indicate what exactly is being authorized. What's missing is
> >>> a document describing how the different authorization AVPs are
> >>> used in this particular situation; sort of like RFC 3580 (IEEE
> > 802.1X
> >>> RADIUS Usage Guidelines), but for Diameter with IKEv2.
> >>>
> >>> One important reason NOT to create new applications: proxies.
Every
> >>> proxy on the path needs new code to handle the new application,
> > while
> >>> just adding an extra AVP or new Service-Type value doesn't.
> >>> "
> >>>
> >>> John agrees with Pasi.
> >>>
> >>> Avi writes:
> >>> "
> >>> A mandatory attribute (a must understand attribute) that has a new
> >>> enumeration is in my mind is like adding a new attribute that must
> > be
> >>> understood.  There is no wigle room here.  The command carrying
that
> >>> attribute must reach the implementation that knows how to
interpret
> > the
> >>> attribute.  This is  because an implmentation that does not
> > understand
> >>> Service-Type =3D X must return an error.
> >>>
> >>> It is obvious that the rules in 3588 are not sufficient to
describe
> > when
> >>> to use a new Application ID or not.  And we should not have to
have
> > a
> >>> debate on this topic.
> >>>
> >>> BTW if we do what you say then in networks where I have NASREQ
> >>> performing Network Access and now I want to roll out MIPv6 I would
> > have
> >>> to upgrade all my old NASREQ deployed applications.  This is
wrong.
> > I
> >>> should be able to add a MIPv6 compliant diameter application
without
> >>> having to force upgrading my NASREQ applications.
> >>> "
> >>>
> >>>
> >>> _______________________________________________
> >>> DiME mailing list
> >>> DiME@ietf.org
> >>> https://www1.ietf.org/mailman/listinfo/dime
> >> --
> >> julien.bournelle at int-evry.fr
> >>
> >> _______________________________________________
> >> DiME mailing list
> >> DiME@ietf.org
> >> https://www1.ietf.org/mailman/listinfo/dime
> >
> >
> > "This email message and any attachments are confidential information
of
> Starent Networks, Corp. The information transmitted may not be used to
> create or change any contractual obligations of Starent Networks,
Corp.
> Any review, retransmission, dissemination or other use of, or taking
of
> any action in reliance upon this e-mail and its attachments by persons
or
> entities other than the intended recipient is prohibited. If you are
not
> the intended recipient, please notify the sender immediately -- by
> replying to this message or by sending an email to
> postmaster@starentnetworks.com -- and destroy all copies of this
message
> and any attachments without reading or disclosing their contents.
Thank
> you."
> >
> >


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



From dime-bounces@ietf.org Mon Aug 21 11:02:56 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GFBIm-0001O6-O0; Mon, 21 Aug 2006 11:02:56 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GFBIl-0001O1-AC
	for dime@ietf.org; Mon, 21 Aug 2006 11:02:55 -0400
Received: from bws14.bridgewatersystems.com ([216.113.7.14]
	helo=exchange.bridgewatersys.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFBIk-0000kO-Jo
	for dime@ietf.org; Mon, 21 Aug 2006 11:02:55 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Dime] Mobile IPv6 Bootstrapping - "Application
	ID"vs."NAS-Port-Type AVP/Service-Type": Summary
Date: Mon, 21 Aug 2006 11:01:50 -0400
Message-ID: <E7CCE8A83907104ABEE91AC3AE3709A0070673D8@exchange.bridgewatersys.com>
In-Reply-To: <7CCD07160348804497EF29E9EA5560D78371FE@exchtewks2.starentnetworks.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Dime] Mobile IPv6 Bootstrapping - "Application
	ID"vs."NAS-Port-Type AVP/Service-Type": Summary
Thread-Index: AcbC5sGAEwSWRY6cTNuCYNF2mep/KgADodEAAI8rG1A=
From: "Avi Lior" <avi@bridgewatersystems.com>
To: "Chowdhury, Kuntal" <kchowdhury@starentnetworks.com>,
	"Julien Bournelle" <julien.bournelle@int-evry.fr>,
	"Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 4cbeb0f20efb229aa93fae1468d20275
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

Application-ID should be the way we do this.  That is what it was
designed for.

Not sure what the issue is with intermediaries.

I don't think I agree with the proxy argument.  Why would proxies have
to change?

They would only have to change if they are going to be proxies of this
new Application.  Which is exactly what they should do.

If you don't want the intemediary to change -- they will not support
this new Application then they would simply be relay agents right?

=20

> -----Original Message-----
> From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com]=20
> Sent: Friday, August 18, 2006 2:42 PM
> To: Julien Bournelle; Hannes Tschofenig
> Cc: dime@ietf.org
> Subject: RE: [Dime] Mobile IPv6 Bootstrapping - "Application=20
> ID"vs."NAS-Port-Type AVP/Service-Type": Summary
>=20
> Hi Hannes, Julien,
>=20
> Application-ID is one way, but as has been discussed so far=20
> it requires changes in the intermediaries. A new value in=20
> NAS-Port-Type AVP seems more logical and easier to implement,=20
> IMHO. I am not sure about the Service-Type AVP. I am=20
> wondering what cannot be conveyed via NAS-Port-Type AVP so=20
> that we need this additional AVP?
>=20
> Apologize for jumping in late....still trying to understand=20
> the whole issue.
>=20
> -Kuntal
>=20
>=20
> > -----Original Message-----
> > From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr]
> > Sent: Friday, August 18, 2006 11:54 AM
> > To: Hannes Tschofenig
> > Cc: dime@ietf.org
> > Subject: Re: [Dime] Mobile IPv6 Bootstrapping - "Application ID"
> vs."NAS-
> > Port-Type AVP/Service-Type": Summary
> >=20
> > Hi hannes,
> >=20
> >  thanks for this clarifying mail.
> >=20
> >=20
> > On Wed, Aug 16, 2006 at 10:51:07PM +0200, Hannes Tschofenig wrote:
> > > Hi all,
> > >
> > > I went through the discussion again and noticed that we haven't
> reached
> > > a conclusion.
> > >
> > > Here is my impression:
> > >
> > > * RFC 3588 leaves a question regarding the extensibility open.
> > >   This needs to be captured in the revision of the base
> specification.
> > >
> > > * The main issue seems to be
> > >
> > >   - Do we want to route 'Diameter EAP' message and=20
> 'Diameter Mobile
> > > IPv6 Bootstrapping' messages differently?
> >=20
> >  I tend to think that it is safer to assume that some=20
> operators may =20
> > desire that.
> >=20
> > >
> > >     If we want to route them differently then we need to define=20
> > > 'Diameter MIPv6 Bootstrapping' as a Diameter application.
> > >
> > >   - The AAA server differentiates ordinary network access=20
> and MIPv6=20
> > > bootstrapping functionality (with respect to authorization and=20
> > > accounting). In order to do so it must understand the=20
> Service-Type=20
> > > and/or NAS-Port-Type AVPs and the defined values.
> > >
> > >     Is this a problem?
> >=20
> >  Not sure to understand this problem. For me, if we have=20
> the App-Id we =20
> > don't need Service-Type nor NAS-Port Type.
> >  IF we don't have the App-ID, yes we need to define new values.
> >=20
> >  Maybe i missed the problem you raised.
> >=20
> >  regards,
> >=20
> >  Julien
> >=20
> > >
> > >   - There are problems with proxies and newly defined Diameter=20
> > > Application IDs. Every proxy on the path needs new code to handle=20
> > > the new application,
> while
> > > just adding an extra AVP or new Service-Type value does not hurt.
> > >
> > >     Is this an issue for us?
> > >
> > > Ciao
> > > Hannes
> > >
> > > PS: Here is copy-and-paste version of some discussion snippets to
> allow
> > > others to catch-up.
> > >
> > > Julien starts the discussion with a question about=20
> Application IDs.
> > >
> > > Pasi suggests to consider Service-Type and/or=20
> NAS-Port-Type AVPs as=20
> > > well.... the problem starts.
> > >
> > > Avi states that the problem is that neither Service-Type or
> Port-Type is
> > > mandatory.
> > > "
> > > Service Type seems to be the correct way but in RADIUS=20
> and Diameter=20
> > > service-type also can be authenticate-only or
> authorize-only.
> > > So what if the HA wanted to authenticate-only or=20
> authorize-only for
> the
> > > MIP service?  I would lose the ability to also indicate=20
> that this is
> an
> > > HA.
> > >
> > > So Port-Type seems to be the way to go....
> > > "
> > >
> > > Jari jumps in:
> > > "
> > > One of the reasons why an existing application would be=20
> preferred is=20
> > > that then a AAA server that does not care about the type=20
> of service=20
> > > can be used without changes. Yet servers that do care can look at=20
> > > the AVPs and make more detailed authorization decisions.
> > >
> > >
> > > RFC 3588 states that  "Creation of a new application should be=20
> > > viewed as a last resort." and that "In order to justify=20
> allocation=20
> > > of a new application identifier, Diameter applications=20
> MUST define=20
> > > one Command Code, or add new mandatory AVPs to the ABNF."=20
> Note that=20
> > > mandatory AVPs can be viewed in different ways, and that=20
> we should=20
> > > not be too strict about them.
> > > For instance, Framed-Protocol is an optional AVP in RFCs 4005 and=20
> > > 4072. Yet, you could argue that if you are doing PPP then=20
> you need=20
> > > to use this attribute and set it to PPP. But that didn't make the=20
> > > attribute mandatory.
> > > Do we have a similar situation for the IKEv2/MIPv6 attributes and=20
> > > values? They are not necessary from the NASREQ/EAP=20
> perspective, but=20
> > > in the specific context you need to use the attributes.=20
> In my mind,=20
> > > this does not make the attributes mandatory from a Diameter=20
> > > application point of view. If we start creating new=20
> applications for=20
> > > every different situation, we'll have lots of applications and=20
> > > interoperability problems. Its better to add new optional=20
> AVPs and=20
> > > describe in text when they should be used. The only=20
> exception that I=20
> > > see is security related AVPs that must be understood by the other=20
> > > side or else the session should be terminated.
> > > "
> > >
> > > Avi responds:
> > > "
> > > Mandatory does not mean required in the Command.  It means that it
> must
> > > be understood by the receiver.  We need to clarify that.
> > > "
> > >
> > > Gerardo and Lionel agree with Jari.
> > >
> > >
> > >
> > > Avi writes:
> > > "
> > > If I have two EAP based application in my network, one that is=20
> > > handling pure EAP application, the other is extended to handle the
> new
> > > behavior then I need a way to route the (same) command correctly.
> > > "
> > >
> > > Jari writes:
> > > "
> > > Ah, but that is a new requirement. If you believe that=20
> you need to=20
> > > route EAP authentication from a 802.11 AP differently than from=20
> > > IKEv2/MIPv6, then you need one of these:
> > >
> > > - Use different user/domain names for the users of
> > >   the different services.
> > >
> > > - Point to different servers from the AP and SGW (but
> > >   this works less well if you have proxies and roaming).
> > >
> > > - New application ID.
> > >
> > > - Some weird form of Diameter and RADIUS source routing
> > >   based on what type of node sent the message.
> > >
> > > However, it is far from clear to me why you would really need to=20
> > > route the authentication differently *for the same user*. Many=20
> > > authentication mechanisms can also have state, which would imply=20
> > > that at the end they need to end up in the same device=20
> anyhow. Can=20
> > > you expand on why you need to handle the same users in different=20
> > > authentication servers?
> > > "
> > >
> > > Avi to Jari:
> > >
> > > "
> > > BTW in the context of the original question raised, the=20
> attribute(s)=20
> > > will not be optional. Here is the snippet:
> > >
> > > >> >>  In our case, the AAA server must perform AAA functionality
> for
> > the
> > > >> >> Mobile IPv6 service. The AAA server must know that=20
> it has to=20
> > > >> >> authorize the mip6 service and the accounting (ASR/ASA) is
> also
> > for
> > > >> >>  mip6 and not for network access.
> > >
> > > If the Diameter message comes from the HA then the HA MUST include
> the
> > > NAS-Port-type attribute. So the command ABNF is being=20
> changed. Also
> the
> > > behavior is being changed of the Server.  It MUST recognize the
> (new)
> > > value of the NAS-Port-Type.
> > > "
> > >
> > >
> > > Yoshi says:
> > > "
> > > If what is important is service-specific routing (I am=20
> not convinced=20
> > > with it yet), I'd suggest defining a new authorization-only=20
> > > application used only for carrying service-specific attributes=20
> > > (analogous to NASREQ usage in RFC 4072).  The downside is that it=20
> > > needs another message roundtrip than carrying the attributes in=20
> > > DER/DEA.
> > > "
> > >
> > >
> > > Julien wrote:
> > > "
> > > > >
> > > > > I don't think it's clean to require use of different=20
> > > > > users'identifiers in order to distinguish which services is=20
> > > > > provided. For me, it looks like a 'hack'.
> > > " and Pasi responded:
> > > "
> > > I fully agree -- but having separate user identifiers=20
> should not be=20
> > > necessary. If, for example, an operator wants to perform=20
> different=20
> > > authorizations for WiFi and WiMAX (e.g., some users can=20
> access only=20
> > > WiFi but not WiMAX), that's simple to do: just check=20
> Service-Type,=20
> > > NAS-Port-Type, and other relevant authorization AVPs.  There's=20
> > > absolutely no need to create a new Diameter application.
> > >
> > > If the AAA server is really strict about WiFi vs. WiMAX=20
> separation,
> it
> > > can have a policy that requires the NAS-Port-Type AVP to=20
> be present=20
> > > (if the request does not contain it, access is denied). Although
> this
> > > in some sense make NAS-Port-Type AVP "mandatory", it's not
> "mandatory"
> > > in the sense that would require a new Diameter application.
> > >
> > > While IKEv2 and MIP6 are not WiFi and WiMAX, I don't=20
> think there are=20
> > > any significant differences from Diameter point-of-view. There's a
> box
> > > providing some service; authentication works with EAP;=20
> authorization=20
> > > AVPs indicate what exactly is being authorized. What's=20
> missing is a=20
> > > document describing how the different authorization AVPs=20
> are used in=20
> > > this particular situation; sort of like RFC 3580 (IEEE
> 802.1X
> > > RADIUS Usage Guidelines), but for Diameter with IKEv2.
> > >
> > > One important reason NOT to create new applications:=20
> proxies. Every=20
> > > proxy on the path needs new code to handle the new application,
> while
> > > just adding an extra AVP or new Service-Type value doesn't.
> > > "
> > >
> > > John agrees with Pasi.
> > >
> > > Avi writes:
> > > "
> > > A mandatory attribute (a must understand attribute) that=20
> has a new=20
> > > enumeration is in my mind is like adding a new attribute that must
> be
> > > understood.  There is no wigle room here.  The command=20
> carrying that=20
> > > attribute must reach the implementation that knows how to=20
> interpret
> the
> > > attribute.  This is  because an implmentation that does not
> understand
> > > Service-Type =3D X must return an error.
> > >
> > > It is obvious that the rules in 3588 are not sufficient=20
> to describe
> when
> > > to use a new Application ID or not.  And we should not=20
> have to have
> a
> > > debate on this topic.
> > >
> > > BTW if we do what you say then in networks where I have NASREQ=20
> > > performing Network Access and now I want to roll out MIPv6 I would
> have
> > > to upgrade all my old NASREQ deployed applications.  This=20
> is wrong.
> I
> > > should be able to add a MIPv6 compliant diameter=20
> application without=20
> > > having to force upgrading my NASREQ applications.
> > > "
> > >
> > >
> > > _______________________________________________
> > > DiME mailing list
> > > DiME@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/dime
> >=20
> > --
> > julien.bournelle at int-evry.fr
> >=20
> > _______________________________________________
> > DiME mailing list
> > DiME@ietf.org
> > https://www1.ietf.org/mailman/listinfo/dime
>=20
>=20
> "This email message and any attachments are confidential=20
> information of Starent Networks, Corp. The information=20
> transmitted may not be used to create or change any=20
> contractual obligations of Starent Networks, Corp.  Any=20
> review, retransmission, dissemination or other use of, or=20
> taking of any action in reliance upon this e-mail and its=20
> attachments by persons or entities other than the intended=20
> recipient is prohibited. If you are not the intended=20
> recipient, please notify the sender immediately -- by=20
> replying to this message or by sending an email to=20
> postmaster@starentnetworks.com -- and destroy all copies of=20
> this message and any attachments without reading or=20
> disclosing their contents. Thank you."
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www1.ietf.org/mailman/listinfo/dime
>=20

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



From dime-bounces@ietf.org Mon Aug 21 12:19:39 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GFCV1-0001tu-0P; Mon, 21 Aug 2006 12:19:39 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GFCUz-0001tg-Ee
	for dime@ietf.org; Mon, 21 Aug 2006 12:19:37 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129]
	helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFBRo-0001nQ-Fb
	for dime@ietf.org; Mon, 21 Aug 2006 11:12:16 -0400
Received: from imx11.toshiba.co.jp ([61.202.160.20])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GFB5O-0001ry-GH
	for dime@ietf.org; Mon, 21 Aug 2006 10:49:09 -0400
Received: from wall11.toshiba.co.jp (wall11 [133.199.90.149])
	by imx11.toshiba.co.jp  with ESMTP id k7LEn2IG022917;
	Mon, 21 Aug 2006 23:49:02 +0900 (JST)
Received: (from root@localhost) by wall11.toshiba.co.jp  id k7LEn2G3014238;
	Mon, 21 Aug 2006 23:49:02 +0900 (JST)
Received: from ovp11.toshiba.co.jp [133.199.90.148] 
	by wall11.toshiba.co.jp with SMTP id ZAA14188;
	Mon, 21 Aug 2006 23:49:01 +0900
Received: from mx.toshiba.co.jp (localhost [127.0.0.1])
	by ovp11.toshiba.co.jp  with ESMTP id k7LEn1Jn021528;
	Mon, 21 Aug 2006 23:49:01 +0900 (JST)
Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k7LEn1YC015478;
	Mon, 21 Aug 2006 23:49:01 +0900 (JST)
Received: from steelhead ([172.30.24.104])
	by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built
	Apr 28
	2004)) with ESMTPSA id <0J4C003L9RTJ4N00@mail.po.toshiba.co.jp>; Mon,
	21 Aug 2006 23:49:01 +0900 (JST)
Received: from ohba by steelhead with local (Exim 4.62)
	(envelope-from <yohba@tari.toshiba.com>)	id 1GFB55-0005zS-1r; Mon,
	21 Aug 2006 07:48:47 -0700
Date: Mon, 21 Aug 2006 10:48:46 -0400
From: Yoshihiro Ohba <yohba@tari.toshiba.com>
Subject: Re: [Dime] Next Steps for draft-tsou-dime-base-routing-ext-00
In-reply-to: <GBEBKGPKHGPAOFCLBNAMMEJPEHAA.asveren@ulticom.com>
To: Tolga Asveren <asveren@ulticom.com>
Message-id: <20060821144846.GE21216@steelhead>
MIME-version: 1.0
Content-type: text/plain; charset=iso-2022-jp
Content-disposition: inline
References: <20060817154737.GD18621@steelhead>
	<GBEBKGPKHGPAOFCLBNAMMEJPEHAA.asveren@ulticom.com>
User-Agent: Mutt/1.5.11+cvs20060403
X-Spam-Score: -2.6 (--)
X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

Hi Tolga,

On Fri, Aug 18, 2006 at 12:15:53PM -0400, Tolga Asveren wrote:
> Hi Yoshihiro,
> 
> 
> > -----Original Message-----
> > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com]
> > Sent: Thursday, August 17, 2006 11:48 AM
> > To: Hannes Tschofenig
> > Cc: dime@ietf.org
> > Subject: Re: [Dime] Next Steps for draft-tsou-dime-base-routing-ext-00
> >
> >
> > I think the content of draft-tsou-dime-base-routing-ext-00 should be
> > integrated into rfc3588bis, because I think source routing is needed
> > to support stateful agents and thus should be part of base protocol.
> [TOLGA]I think we should distinguish between intermediaries, which advertise
> support for individual applications instead of 0xffffffff but are not really
> stateful and which are really stateful. Currently being stateful and
> advertising specific application support is tied together in RFC3588 by
> definition of a proxy but I don't think it needs to be. Acctually not doing
> so is not violation of the protocol, just defining a new node type, which is
> not explicitly mentioned in RFC3588.


What description in RFC 3588 ties being stateful and advertising
specific application support by definition of a proxy?

In fact, statefulness is not a requirement for a proxy.

So I don't understand what problem is solved with defining a new node
type.

> 
> An example for the first one is a load-balancer for a specific application.
> It is interested to get only messages for a specific application but doesn't
> keep session related state. If a message does not have Destination-Host AVP,
> it forwards the message to a server based on congestion status of servers
> (how this information is propogated is topic for another thread). If a
> message has Destination-Host AVP, it just sends the message to that server.
> 
> For that first type of intermediaries, everything would be working fine if
> AppId!=0 is used for common messages. Otherwise, a relay agent in front of
> load balancers serving different applications is enough to have common
> messages not routable to the correct load balancer.

This first case does not require a stateful agent, so I agree with you
that it may not be appropriate to discuss
draft-tsou-dime-base-routing-ext-00 to address the first case.

> 
> For second type of nodes, which are stateful and want to stay on the message
> path, a mechanism as described in the draft is usefull. There could be other
> solutions as well -which we discussed to some extent on the list-, and I
> would prefer them to be explained -somewhere-.

Source routing is needed at least to support stateful agents that is
defined in RFC 3588 but actually is not completely supported by RFC
3588.  For completeness of the base specification, I'd suggest
defining source routing in the document that defines stateful agent,
but I am also ok with defining it in a separate document if the
document is referred from RFC3588bis.

> 
> >
> > Also, I think that source routing issue can/should be discussed
> > separately from the Application Identifier issue.
> [TOLGA]I see some correlation because using AppId=0 for common messages
> breaks routability of such messages for some configurations and the draft
> provides a solution for that. Otherwise, the draft is useful only for
> intermediares, which want to stay on the path during a session.

I'd think that the draft is useful only for stateful agents.

Regards,
Yoshihiro Ohba



> >
> > Yoshihiro Ohba
> >
> >
> > On Wed, Aug 16, 2006 at 10:15:19PM +0200, Hannes Tschofenig wrote:
> > > Hi all,
> > >
> > > we discussed this document during the IETF#66 DIME working group
> > > meeting. The meeting participants did not express excitement. We would
> > > like to solicit feedback from the working group to see whether there is
> > > interest in this work and how we should proceed.
> > >
> > > Ciao
> > > Hannes & John
> > >
> > > _______________________________________________
> > > DiME mailing list
> > > DiME@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/dime
> >
> > _______________________________________________
> > DiME mailing list
> > DiME@ietf.org
> > https://www1.ietf.org/mailman/listinfo/dime
> 

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



From dime-bounces@ietf.org Mon Aug 21 12:28:15 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GFCdL-0005Fj-L0; Mon, 21 Aug 2006 12:28:15 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GFCdK-0005FZ-SC
	for dime@ietf.org; Mon, 21 Aug 2006 12:28:15 -0400
Received: from [2001:418:1403:0:212:17ff:fe52:7811]
	(helo=toshi17.tari.toshiba.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFCdJ-0000Rm-BR
	for dime@ietf.org; Mon, 21 Aug 2006 12:28:14 -0400
Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10])
	by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id
	k7LGRa1H001687; Mon, 21 Aug 2006 12:27:37 -0400 (EDT)
	(envelope-from vfajardo@tari.toshiba.com)
Message-ID: <44E9DF11.3060208@tari.toshiba.com>
Date: Mon, 21 Aug 2006 12:28:01 -0400
From: Victor Fajardo <vfajardo@tari.toshiba.com>
User-Agent: Thunderbird 1.5.0.5 (X11/20060719)
MIME-Version: 1.0
To: "Tschofenig, Hannes" <hannes.tschofenig@siemens.com>
Subject: Re: AW: [Dime] Next Steps for draft-tsou-dime-base-routing-ext-00
References: <A5D2BD54850CCA4AA3B93227205D8A30898C54@MCHP7IEA.ww002.siemens.net>
In-Reply-To: <A5D2BD54850CCA4AA3B93227205D8A30898C54@MCHP7IEA.ww002.siemens.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by
	toshi17.tari.toshiba.com id k7LGRa1H001687
X-Spam-Score: -2.4 (--)
X-Scan-Signature: 140baa79ca42e6b0e2b4504291346186
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

Hi Hannes,
> Hi Victor,=20
>
> in the discussions the 3GPP WLAN work was mentioned as the usage scenar=
io.=20
> Is it a real problem in their environment? I have never heard something=
 about problems along these lines.=20
>  =20

 From what I understood, it is a problem envisioned by some folks when=20
trying to deploy diameter in such environment. I think Tina and others=20
can shed light into this better than I can.

regards,
victor

> Ciao
> Hannes
> =20
>
>  =20
>> -----Urspr=FCngliche Nachricht-----
>> Von: Victor Fajardo [mailto:vfajardo@tari.toshiba.com]=20
>> Gesendet: Montag, 21. August 2006 16:29
>> An: john.loughney@nokia.com
>> Cc: dime@ietf.org
>> Betreff: Re: [Dime] Next Steps for draft-tsou-dime-base-routing-ext-00
>>
>> Hi John,
>>
>>    =20
>>> Hi all,
>>>
>>> A very basic question - do we have consensus that we need source
>>> routing and that it is a basic functionality?  Is this something
>>> that is broken in the current document. =20
>>>      =20
>> The intention of the document was to propose an "extension" to the=20
>> current routing functionality of the base to fulfill requirements in=20
>> topologies where this functionality is needed. (i think these=20
>> topologies/scenarios has been discussed lengthly in the=20
>> list). Following=20
>> your guideline, I think it maybe better that this should be=20
>> an extension=20
>> document given that it is not proposing changes to the=20
>> existing routing=20
>> schemes. I also think that the WG should work on this=20
>> document since it=20
>> does fulfill real world requirements.
>>
>> regards,
>> victor
>>
>>    =20
>>> If so, then it should
>>> be fixed in the base.  If this is an additional feature, then
>>> it might be fine to have this as an extension draft.
>>>
>>> thanks,
>>> John
>>>
>>>  =20
>>>      =20
>>>> -----Original Message-----
>>>> From: ext Tolga Asveren [mailto:asveren@ulticom.com]=20
>>>> Sent: 18 August, 2006 19:16
>>>> To: Yoshihiro Ohba
>>>> Cc: dime@ietf.org
>>>> Subject: RE: [Dime] Next Steps for=20
>>>>        =20
>> draft-tsou-dime-base-routing-ext-00
>>    =20
>>>> Hi Yoshihiro,
>>>>
>>>>
>>>>    =20
>>>>        =20
>>>>> -----Original Message-----
>>>>> From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com]
>>>>> Sent: Thursday, August 17, 2006 11:48 AM
>>>>> To: Hannes Tschofenig
>>>>> Cc: dime@ietf.org
>>>>> Subject: Re: [Dime] Next Steps for=20
>>>>>      =20
>>>>>          =20
>>>> draft-tsou-dime-base-routing-ext-00
>>>>    =20
>>>>        =20
>>>>> I think the content of=20
>>>>>          =20
>> draft-tsou-dime-base-routing-ext-00 should be=20
>>    =20
>>>>> integrated into rfc3588bis, because I think source=20
>>>>>          =20
>> routing is needed=20
>>    =20
>>>>> to support stateful agents and thus should be part of=20
>>>>>          =20
>> base protocol.
>>    =20
>>>>>      =20
>>>>>          =20
>>>> [TOLGA]I think we should distinguish between intermediaries,=20
>>>> which advertise support for individual applications instead of=20
>>>> 0xffffffff but are not really stateful and which are really=20
>>>> stateful. Currently being stateful and advertising specific=20
>>>> application support is tied together in RFC3588 by definition=20
>>>> of a proxy but I don't think it needs to be. Acctually not=20
>>>> doing so is not violation of the protocol, just defining a new=20
>>>> node type, which is not explicitly mentioned in RFC3588.
>>>>
>>>> An example for the first one is a load-balancer for a specific=20
>>>> application.
>>>> It is interested to get only messages for a specific=20
>>>> application but doesn't keep session related state. If a=20
>>>> message does not have Destination-Host AVP, it forwards the=20
>>>> message to a server based on congestion status of servers (how=20
>>>> this information is propogated is topic for another thread).=20
>>>> If a message has Destination-Host AVP, it just sends the=20
>>>> message to that server.
>>>>
>>>> For that first type of intermediaries, everything would be=20
>>>> working fine if AppId!=3D0 is used for common messages.=20
>>>> Otherwise, a relay agent in front of load balancers serving=20
>>>> different applications is enough to have common messages not=20
>>>> routable to the correct load balancer.
>>>>
>>>> For second type of nodes, which are stateful and want to stay=20
>>>> on the message path, a mechanism as described in the draft is=20
>>>> usefull. There could be other solutions as well -which we=20
>>>> discussed to some extent on the list-, and I would prefer them=20
>>>> to be explained -somewhere-.
>>>>
>>>>    =20
>>>>        =20
>>>>> Also, I think that source routing issue can/should be discussed=20
>>>>> separately from the Application Identifier issue.
>>>>>      =20
>>>>>          =20
>>>> [TOLGA]I see some correlation because using AppId=3D0 for common=20
>>>> messages breaks routability of such messages for some=20
>>>> configurations and the draft provides a solution for that.=20
>>>> Otherwise, the draft is useful only for intermediares, which=20
>>>> want to stay on the path during a session.
>>>>    =20
>>>>        =20
>>>>> Yoshihiro Ohba
>>>>>
>>>>>
>>>>> On Wed, Aug 16, 2006 at 10:15:19PM +0200, Hannes Tschofenig wrote:
>>>>>      =20
>>>>>          =20
>>>>>> Hi all,
>>>>>>
>>>>>> we discussed this document during the IETF#66 DIME working group=20
>>>>>> meeting. The meeting participants did not express excitement. We=20
>>>>>> would like to solicit feedback from the working group to=20
>>>>>>        =20
>>>>>>            =20
>>>> see whether=20
>>>>    =20
>>>>        =20
>>>>>> there is interest in this work and how we should proceed.
>>>>>>
>>>>>> Ciao
>>>>>> Hannes & John
>>>>>>
>>>>>> _______________________________________________
>>>>>> DiME mailing list
>>>>>> DiME@ietf.org
>>>>>> https://www1.ietf.org/mailman/listinfo/dime
>>>>>>        =20
>>>>>>            =20
>>>>> _______________________________________________
>>>>> DiME mailing list
>>>>> DiME@ietf.org
>>>>> https://www1.ietf.org/mailman/listinfo/dime
>>>>>      =20
>>>>>          =20
>>>> _______________________________________________
>>>> DiME mailing list
>>>> DiME@ietf.org
>>>> https://www1.ietf.org/mailman/listinfo/dime
>>>>
>>>>    =20
>>>>        =20
>>> _______________________________________________
>>> DiME mailing list
>>> DiME@ietf.org
>>> https://www1.ietf.org/mailman/listinfo/dime
>>>
>>>
>>>
>>>  =20
>>>      =20
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www1.ietf.org/mailman/listinfo/dime
>>
>>    =20
>
>
>
>  =20


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



From dime-bounces@ietf.org Mon Aug 21 12:41:55 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GFCqZ-0001gj-P5; Mon, 21 Aug 2006 12:41:55 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GFCqY-0001gW-4m
	for dime@ietf.org; Mon, 21 Aug 2006 12:41:54 -0400
Received: from mx0.starentnetworks.com ([12.38.223.203])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFCqV-0003S0-38
	for dime@ietf.org; Mon, 21 Aug 2006 12:41:54 -0400
Received: from localhost (localhost.localdomain [127.0.0.1])
	by mx0.starentnetworks.com (Postfix) with ESMTP id 343F990011;
	Mon, 21 Aug 2006 12:41:47 -0400 (EDT)
Received: from mx0.starentnetworks.com ([127.0.0.1])
	by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 10667-05; Mon, 21 Aug 2006 12:41:45 -0400 (EDT)
Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com
	[12.33.233.52]) by mx0.starentnetworks.com (Postfix) with ESMTP;
	Mon, 21 Aug 2006 12:41:33 -0400 (EDT)
X-MessageTextProcessor: DisclaimIt (2.70.271) [Starent Networks Corp.]
Received: from exchtewks2.starentnetworks.com ([12.33.232.12]) by
	exchtewks1.starentnetworks.com with Microsoft
	SMTPSVC(6.0.3790.1830); Mon, 21 Aug 2006 12:41:33 -0400
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Dime] Mobile IPv6 Bootstrapping - "Application
	ID"vs."NAS-Port-Type AVP/Service-Type": Summary
Date: Mon, 21 Aug 2006 12:41:32 -0400
Message-ID: <7CCD07160348804497EF29E9EA5560D7837219@exchtewks2.starentnetworks.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Dime] Mobile IPv6 Bootstrapping - "Application
	ID"vs."NAS-Port-Type AVP/Service-Type": Summary
thread-index: AcbC5sGAEwSWRY6cTNuCYNF2mep/KgADodEAAI8rG1AAAysUsA==
From: "Chowdhury, Kuntal" <kchowdhury@starentnetworks.com>
To: "Avi Lior" <avi@bridgewatersystems.com>
Importance: normal
Priority: normal
X-OriginalArrivalTime: 21 Aug 2006 16:41:33.0060 (UTC)
	FILETIME=[A9008440:01C6C540]
X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 94962611154c8404498b19f744990308
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org



> -----Original Message-----
> From: Avi Lior [mailto:avi@bridgewatersystems.com]
> Sent: Monday, August 21, 2006 10:02 AM
> To: Chowdhury, Kuntal; Julien Bournelle; Hannes Tschofenig
> Cc: dime@ietf.org
> Subject: RE: [Dime] Mobile IPv6 Bootstrapping - "Application
ID"vs."NAS-
> Port-Type AVP/Service-Type": Summary
>=20
> Application-ID should be the way we do this.  That is what it was
> designed for.
>=20
[KC>] Are you talking about creating an application ID for MIP6 or you
are talking about application ID for MIP6 bootstrapping?

> Not sure what the issue is with intermediaries.
>=20
> I don't think I agree with the proxy argument.  Why would proxies have
> to change?
>=20
[KC>] the proxy needs to act like a relay if it does not understand the
app ID...isn't that a change? Albeit it is not a code change but it is a
behavior change.


> They would only have to change if they are going to be proxies of this
> new Application.  Which is exactly what they should do.
>=20
[KC>] If I am a MSP, I have to make sure that my proxies understand this
new app ID, right? If not, I won't have to do anything more than
supporting Diameter base and NASREQ.

> If you don't want the intemediary to change -- they will not support
> this new Application then they would simply be relay agents right?
>=20
[KC>] OK.

>=20
>=20
> > -----Original Message-----
> > From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com]
> > Sent: Friday, August 18, 2006 2:42 PM
> > To: Julien Bournelle; Hannes Tschofenig
> > Cc: dime@ietf.org
> > Subject: RE: [Dime] Mobile IPv6 Bootstrapping - "Application
> > ID"vs."NAS-Port-Type AVP/Service-Type": Summary
> >
> > Hi Hannes, Julien,
> >
> > Application-ID is one way, but as has been discussed so far
> > it requires changes in the intermediaries. A new value in
> > NAS-Port-Type AVP seems more logical and easier to implement,
> > IMHO. I am not sure about the Service-Type AVP. I am
> > wondering what cannot be conveyed via NAS-Port-Type AVP so
> > that we need this additional AVP?
> >
> > Apologize for jumping in late....still trying to understand
> > the whole issue.
> >
> > -Kuntal
> >
> >
> > > -----Original Message-----
> > > From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr]
> > > Sent: Friday, August 18, 2006 11:54 AM
> > > To: Hannes Tschofenig
> > > Cc: dime@ietf.org
> > > Subject: Re: [Dime] Mobile IPv6 Bootstrapping - "Application ID"
> > vs."NAS-
> > > Port-Type AVP/Service-Type": Summary
> > >
> > > Hi hannes,
> > >
> > >  thanks for this clarifying mail.
> > >
> > >
> > > On Wed, Aug 16, 2006 at 10:51:07PM +0200, Hannes Tschofenig wrote:
> > > > Hi all,
> > > >
> > > > I went through the discussion again and noticed that we haven't
> > reached
> > > > a conclusion.
> > > >
> > > > Here is my impression:
> > > >
> > > > * RFC 3588 leaves a question regarding the extensibility open.
> > > >   This needs to be captured in the revision of the base
> > specification.
> > > >
> > > > * The main issue seems to be
> > > >
> > > >   - Do we want to route 'Diameter EAP' message and
> > 'Diameter Mobile
> > > > IPv6 Bootstrapping' messages differently?
> > >
> > >  I tend to think that it is safer to assume that some
> > operators may
> > > desire that.
> > >
> > > >
> > > >     If we want to route them differently then we need to define
> > > > 'Diameter MIPv6 Bootstrapping' as a Diameter application.
> > > >
> > > >   - The AAA server differentiates ordinary network access
> > and MIPv6
> > > > bootstrapping functionality (with respect to authorization and
> > > > accounting). In order to do so it must understand the
> > Service-Type
> > > > and/or NAS-Port-Type AVPs and the defined values.
> > > >
> > > >     Is this a problem?
> > >
> > >  Not sure to understand this problem. For me, if we have
> > the App-Id we
> > > don't need Service-Type nor NAS-Port Type.
> > >  IF we don't have the App-ID, yes we need to define new values.
> > >
> > >  Maybe i missed the problem you raised.
> > >
> > >  regards,
> > >
> > >  Julien
> > >
> > > >
> > > >   - There are problems with proxies and newly defined Diameter
> > > > Application IDs. Every proxy on the path needs new code to
handle
> > > > the new application,
> > while
> > > > just adding an extra AVP or new Service-Type value does not
hurt.
> > > >
> > > >     Is this an issue for us?
> > > >
> > > > Ciao
> > > > Hannes
> > > >
> > > > PS: Here is copy-and-paste version of some discussion snippets
to
> > allow
> > > > others to catch-up.
> > > >
> > > > Julien starts the discussion with a question about
> > Application IDs.
> > > >
> > > > Pasi suggests to consider Service-Type and/or
> > NAS-Port-Type AVPs as
> > > > well.... the problem starts.
> > > >
> > > > Avi states that the problem is that neither Service-Type or
> > Port-Type is
> > > > mandatory.
> > > > "
> > > > Service Type seems to be the correct way but in RADIUS
> > and Diameter
> > > > service-type also can be authenticate-only or
> > authorize-only.
> > > > So what if the HA wanted to authenticate-only or
> > authorize-only for
> > the
> > > > MIP service?  I would lose the ability to also indicate
> > that this is
> > an
> > > > HA.
> > > >
> > > > So Port-Type seems to be the way to go....
> > > > "
> > > >
> > > > Jari jumps in:
> > > > "
> > > > One of the reasons why an existing application would be
> > preferred is
> > > > that then a AAA server that does not care about the type
> > of service
> > > > can be used without changes. Yet servers that do care can look
at
> > > > the AVPs and make more detailed authorization decisions.
> > > >
> > > >
> > > > RFC 3588 states that  "Creation of a new application should be
> > > > viewed as a last resort." and that "In order to justify
> > allocation
> > > > of a new application identifier, Diameter applications
> > MUST define
> > > > one Command Code, or add new mandatory AVPs to the ABNF."
> > Note that
> > > > mandatory AVPs can be viewed in different ways, and that
> > we should
> > > > not be too strict about them.
> > > > For instance, Framed-Protocol is an optional AVP in RFCs 4005
and
> > > > 4072. Yet, you could argue that if you are doing PPP then
> > you need
> > > > to use this attribute and set it to PPP. But that didn't make
the
> > > > attribute mandatory.
> > > > Do we have a similar situation for the IKEv2/MIPv6 attributes
and
> > > > values? They are not necessary from the NASREQ/EAP
> > perspective, but
> > > > in the specific context you need to use the attributes.
> > In my mind,
> > > > this does not make the attributes mandatory from a Diameter
> > > > application point of view. If we start creating new
> > applications for
> > > > every different situation, we'll have lots of applications and
> > > > interoperability problems. Its better to add new optional
> > AVPs and
> > > > describe in text when they should be used. The only
> > exception that I
> > > > see is security related AVPs that must be understood by the
other
> > > > side or else the session should be terminated.
> > > > "
> > > >
> > > > Avi responds:
> > > > "
> > > > Mandatory does not mean required in the Command.  It means that
it
> > must
> > > > be understood by the receiver.  We need to clarify that.
> > > > "
> > > >
> > > > Gerardo and Lionel agree with Jari.
> > > >
> > > >
> > > >
> > > > Avi writes:
> > > > "
> > > > If I have two EAP based application in my network, one that is
> > > > handling pure EAP application, the other is extended to handle
the
> > new
> > > > behavior then I need a way to route the (same) command
correctly.
> > > > "
> > > >
> > > > Jari writes:
> > > > "
> > > > Ah, but that is a new requirement. If you believe that
> > you need to
> > > > route EAP authentication from a 802.11 AP differently than from
> > > > IKEv2/MIPv6, then you need one of these:
> > > >
> > > > - Use different user/domain names for the users of
> > > >   the different services.
> > > >
> > > > - Point to different servers from the AP and SGW (but
> > > >   this works less well if you have proxies and roaming).
> > > >
> > > > - New application ID.
> > > >
> > > > - Some weird form of Diameter and RADIUS source routing
> > > >   based on what type of node sent the message.
> > > >
> > > > However, it is far from clear to me why you would really need to
> > > > route the authentication differently *for the same user*. Many
> > > > authentication mechanisms can also have state, which would imply
> > > > that at the end they need to end up in the same device
> > anyhow. Can
> > > > you expand on why you need to handle the same users in different
> > > > authentication servers?
> > > > "
> > > >
> > > > Avi to Jari:
> > > >
> > > > "
> > > > BTW in the context of the original question raised, the
> > attribute(s)
> > > > will not be optional. Here is the snippet:
> > > >
> > > > >> >>  In our case, the AAA server must perform AAA
functionality
> > for
> > > the
> > > > >> >> Mobile IPv6 service. The AAA server must know that
> > it has to
> > > > >> >> authorize the mip6 service and the accounting (ASR/ASA) is
> > also
> > > for
> > > > >> >>  mip6 and not for network access.
> > > >
> > > > If the Diameter message comes from the HA then the HA MUST
include
> > the
> > > > NAS-Port-type attribute. So the command ABNF is being
> > changed. Also
> > the
> > > > behavior is being changed of the Server.  It MUST recognize the
> > (new)
> > > > value of the NAS-Port-Type.
> > > > "
> > > >
> > > >
> > > > Yoshi says:
> > > > "
> > > > If what is important is service-specific routing (I am
> > not convinced
> > > > with it yet), I'd suggest defining a new authorization-only
> > > > application used only for carrying service-specific attributes
> > > > (analogous to NASREQ usage in RFC 4072).  The downside is that
it
> > > > needs another message roundtrip than carrying the attributes in
> > > > DER/DEA.
> > > > "
> > > >
> > > >
> > > > Julien wrote:
> > > > "
> > > > > >
> > > > > > I don't think it's clean to require use of different
> > > > > > users'identifiers in order to distinguish which services is
> > > > > > provided. For me, it looks like a 'hack'.
> > > > " and Pasi responded:
> > > > "
> > > > I fully agree -- but having separate user identifiers
> > should not be
> > > > necessary. If, for example, an operator wants to perform
> > different
> > > > authorizations for WiFi and WiMAX (e.g., some users can
> > access only
> > > > WiFi but not WiMAX), that's simple to do: just check
> > Service-Type,
> > > > NAS-Port-Type, and other relevant authorization AVPs.  There's
> > > > absolutely no need to create a new Diameter application.
> > > >
> > > > If the AAA server is really strict about WiFi vs. WiMAX
> > separation,
> > it
> > > > can have a policy that requires the NAS-Port-Type AVP to
> > be present
> > > > (if the request does not contain it, access is denied). Although
> > this
> > > > in some sense make NAS-Port-Type AVP "mandatory", it's not
> > "mandatory"
> > > > in the sense that would require a new Diameter application.
> > > >
> > > > While IKEv2 and MIP6 are not WiFi and WiMAX, I don't
> > think there are
> > > > any significant differences from Diameter point-of-view. There's
a
> > box
> > > > providing some service; authentication works with EAP;
> > authorization
> > > > AVPs indicate what exactly is being authorized. What's
> > missing is a
> > > > document describing how the different authorization AVPs
> > are used in
> > > > this particular situation; sort of like RFC 3580 (IEEE
> > 802.1X
> > > > RADIUS Usage Guidelines), but for Diameter with IKEv2.
> > > >
> > > > One important reason NOT to create new applications:
> > proxies. Every
> > > > proxy on the path needs new code to handle the new application,
> > while
> > > > just adding an extra AVP or new Service-Type value doesn't.
> > > > "
> > > >
> > > > John agrees with Pasi.
> > > >
> > > > Avi writes:
> > > > "
> > > > A mandatory attribute (a must understand attribute) that
> > has a new
> > > > enumeration is in my mind is like adding a new attribute that
must
> > be
> > > > understood.  There is no wigle room here.  The command
> > carrying that
> > > > attribute must reach the implementation that knows how to
> > interpret
> > the
> > > > attribute.  This is  because an implmentation that does not
> > understand
> > > > Service-Type =3D X must return an error.
> > > >
> > > > It is obvious that the rules in 3588 are not sufficient
> > to describe
> > when
> > > > to use a new Application ID or not.  And we should not
> > have to have
> > a
> > > > debate on this topic.
> > > >
> > > > BTW if we do what you say then in networks where I have NASREQ
> > > > performing Network Access and now I want to roll out MIPv6 I
would
> > have
> > > > to upgrade all my old NASREQ deployed applications.  This
> > is wrong.
> > I
> > > > should be able to add a MIPv6 compliant diameter
> > application without
> > > > having to force upgrading my NASREQ applications.
> > > > "
> > > >
> > > >
> > > > _______________________________________________
> > > > DiME mailing list
> > > > DiME@ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/dime
> > >
> > > --
> > > julien.bournelle at int-evry.fr
> > >
> > > _______________________________________________
> > > DiME mailing list
> > > DiME@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/dime
> >
> >
> > "This email message and any attachments are confidential
> > information of Starent Networks, Corp. The information
> > transmitted may not be used to create or change any
> > contractual obligations of Starent Networks, Corp.  Any
> > review, retransmission, dissemination or other use of, or
> > taking of any action in reliance upon this e-mail and its
> > attachments by persons or entities other than the intended
> > recipient is prohibited. If you are not the intended
> > recipient, please notify the sender immediately -- by
> > replying to this message or by sending an email to
> > postmaster@starentnetworks.com -- and destroy all copies of
> > this message and any attachments without reading or
> > disclosing their contents. Thank you."
> >
> > _______________________________________________
> > DiME mailing list
> > DiME@ietf.org
> > https://www1.ietf.org/mailman/listinfo/dime
> >

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



From dime-bounces@ietf.org Mon Aug 21 13:10:42 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GFDIK-00040t-Pg; Mon, 21 Aug 2006 13:10:36 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GFDIJ-0003zq-R0
	for dime@ietf.org; Mon, 21 Aug 2006 13:10:35 -0400
Received: from mx0.starentnetworks.com ([12.38.223.203])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFDHs-0000MV-Rn
	for dime@ietf.org; Mon, 21 Aug 2006 13:10:11 -0400
Received: from localhost (localhost.localdomain [127.0.0.1])
	by mx0.starentnetworks.com (Postfix) with ESMTP id 66BF290002;
	Mon, 21 Aug 2006 13:10:05 -0400 (EDT)
Received: from mx0.starentnetworks.com ([127.0.0.1])
	by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 11200-04; Mon, 21 Aug 2006 13:10:02 -0400 (EDT)
Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com
	[12.33.233.52]) by mx0.starentnetworks.com (Postfix) with ESMTP;
	Mon, 21 Aug 2006 13:10:02 -0400 (EDT)
X-MessageTextProcessor: DisclaimIt (2.70.271) [Starent Networks Corp.]
Received: from exchtewks2.starentnetworks.com ([12.33.232.12]) by
	exchtewks1.starentnetworks.com with Microsoft
	SMTPSVC(6.0.3790.1830); Mon, 21 Aug 2006 13:10:02 -0400
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Dime] Mobile IPv6 Bootstrapping - "Application
	ID"vs."NAS-Port-Type AVP/Service-Type": Summary
Date: Mon, 21 Aug 2006 13:10:02 -0400
Message-ID: <7CCD07160348804497EF29E9EA5560D783721A@exchtewks2.starentnetworks.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Dime] Mobile IPv6 Bootstrapping - "Application
	ID"vs."NAS-Port-Type AVP/Service-Type": Summary
thread-index: AcbEL57agT/n7nm3TmmkI0AGzDo4RAA/kEAwAAF00GAAA6OdwA==
From: "Chowdhury, Kuntal" <kchowdhury@starentnetworks.com>
To: "Avi Lior" <avi@bridgewatersystems.com>,
	"Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>
Importance: normal
Priority: normal
X-OriginalArrivalTime: 21 Aug 2006 17:10:02.0849 (UTC)
	FILETIME=[A41D9D10:01C6C544]
X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3da7e5d5ca82d58872786934e4963616
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org



> -----Original Message-----
> From: Avi Lior [mailto:avi@bridgewatersystems.com]
> Sent: Monday, August 21, 2006 11:06 AM
> To: Chowdhury, Kuntal; Hannes Tschofenig
> Cc: dime@ietf.org
> Subject: RE: [Dime] Mobile IPv6 Bootstrapping - "Application
ID"vs."NAS-
> Port-Type AVP/Service-Type": Summary
>=20
> Service-Type should not be used.
>=20
> If you add a new value to the NAS-Port-Type then you need a new
> Application-ID anyway.  You have to make sure that the packet reaches
an
> entity that can understands the new value.  Otherewise you could end
up
> delivering the packet to a legacy server that doesn't not understand
the
> MIPv6 application.
>=20
[KC>] Hmmm...it will be an interesting situation when the Mobility
Service Provider (MSP) deploys AAA servers that do not understand MIP6!

> Once you have a new Application-ID you really don't need NAS-Port-Type
> (as pointed out correctly by Julien).
>=20
[KC>] How about NAS-port AVP? Do we need a new application ID if we
decide to use a specific value in NAS-port AVP to indicate MIP6
bootstrapping?

> I don't understand what the concern about modification of Diameter
> Agents.
>=20
[KC>] My main goal is this: If we can use Diameter EAP (DER/DEA) or
NASREQ (AAR/AAA) transactions to download MIP6 bootstrapping parameters
(HA, HL etc.) that will be ideal. I am trying to avoid extra
transactions from NAS and HA if possible. Hope you will appreciate this
goal. If we end-up mandating some non-mandatory AVPs in EAP/NASREQ, only
then we should define new application ID for MIP6 bootstrapping, IMHO.

> If you use Application Id then Relays wont have to change right?
>=20
> Proxies would have to change if and only if they are going to be
proxies
> for that Application.  But that is the definition of a Proxy right?
>=20
>=20
> > -----Original Message-----
> > From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com]
> > Sent: Monday, August 21, 2006 10:45 AM
> > To: Hannes Tschofenig
> > Cc: dime@ietf.org
> > Subject: RE: [Dime] Mobile IPv6 Bootstrapping - "Application
> > ID"vs."NAS-Port-Type AVP/Service-Type": Summary
> >
> >
> >
> > > -----Original Message-----
> > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
> > > Sent: Sunday, August 20, 2006 3:07 AM
> > > To: Chowdhury, Kuntal
> > > Cc: Julien Bournelle; dime@ietf.org
> > > Subject: Re: [Dime] Mobile IPv6 Bootstrapping - "Application ID"
> > vs."NAS-
> > > Port-Type AVP/Service-Type": Summary
> > >
> > > Hi Kuntal,
> > >
> > >
> > > Chowdhury, Kuntal schrieb:
> > > > Hi Hannes, Julien,
> > > >
> > > > Application-ID is one way, but as has been discussed so far it
> > requires
> > > > changes in the intermediaries.
> > >
> > > True.
> > >
> > >   A new value in NAS-Port-Type AVP seems
> > > > more logical and easier to implement, IMHO.
> > >
> > > Easier to implement: True.
> > >
> > >   I am not sure about the
> > > > Service-Type AVP. I am wondering what cannot be conveyed via
> > > > NAS-Port-Type AVP so that we need this additional AVP?
> > > >
> > > > Apologize for jumping in late....still trying to understand the
> > whole
> > > > issue.
> > > Please read my copy-and-paste summary of the discussion.
> > >
> > > In some sense we are discussing fundamentals of how to extend
> > Diameter.
> > > The application ID is used for routing. If we don't define a new
> > app-ID
> > > then we cannot route network access messages and MIP6
bootstrapping
> > > messages differently. Some folks think that this is important.
> > > What do you think?
> > >
> > [KC>] In case of split scenario, I see the use case where the
> > AAA transaction for network access at the NAS is going to a
> > different AAA server than the same at the HA, since ASA !=3D
> > MSA in split. In case of integrated scenario, it is essential
> > that the AAA transactions from the NAS and from the HA get
> > routed to the same AAA server (ASA =3D=3D MSA). So we need to
> > keep this in mind.
> >
> > >From the AAA message routing point of view, I thought the
> > @realm part
> > >of
> > the username (NAI) was sufficient to route AAA messages to
> > different AAA systems. There are other reasons for separate
> > APP-ID for MIP6 bootstrapping, e.g. if we decide to mandate
> > AVPs needed for MIP6 bootstrapping in DER/DEA (as an
> > example). I don't know why we would do that i.e. mandate MIP6
> > bootstrapping AVPs in DER/DEA.
> >
> >
> > > Ciao
> > > Hannes
> > >
> > > >
> > > > -Kuntal
> > > >
> > > >
> > > >> -----Original Message-----
> > > >> From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr]
> > > >> Sent: Friday, August 18, 2006 11:54 AM
> > > >> To: Hannes Tschofenig
> > > >> Cc: dime@ietf.org
> > > >> Subject: Re: [Dime] Mobile IPv6 Bootstrapping - "Application
ID"
> > > > vs."NAS-
> > > >> Port-Type AVP/Service-Type": Summary
> > > >>
> > > >> Hi hannes,
> > > >>
> > > >>  thanks for this clarifying mail.
> > > >>
> > > >>
> > > >> On Wed, Aug 16, 2006 at 10:51:07PM +0200, Hannes
> > Tschofenig wrote:
> > > >>> Hi all,
> > > >>>
> > > >>> I went through the discussion again and noticed that we
haven't
> > > > reached
> > > >>> a conclusion.
> > > >>>
> > > >>> Here is my impression:
> > > >>>
> > > >>> * RFC 3588 leaves a question regarding the extensibility open.
> > > >>>   This needs to be captured in the revision of the base
> > > > specification.
> > > >>> * The main issue seems to be
> > > >>>
> > > >>>   - Do we want to route 'Diameter EAP' message and 'Diameter
> > Mobile
> > > >>> IPv6 Bootstrapping' messages differently?
> > > >>  I tend to think that it is safer to assume that some
> > operators may
> > > >> desire that.
> > > >>
> > > >>>     If we want to route them differently then we need to
define
> > > >>> 'Diameter MIPv6 Bootstrapping' as a Diameter application.
> > > >>>
> > > >>>   - The AAA server differentiates ordinary network access and
> > MIPv6
> > > >>> bootstrapping functionality (with respect to authorization and
> > > >>> accounting). In order to do so it must understand the
> > Service-Type
> > > >>> and/or NAS-Port-Type AVPs and the defined values.
> > > >>>
> > > >>>     Is this a problem?
> > > >>  Not sure to understand this problem. For me, if we have
> > the App-Id
> > we
> > > >>  don't need Service-Type nor NAS-Port Type.
> > > >>  IF we don't have the App-ID, yes we need to define new values.
> > > >>
> > > >>  Maybe i missed the problem you raised.
> > > >>
> > > >>  regards,
> > > >>
> > > >>  Julien
> > > >>
> > > >>>   - There are problems with proxies and newly defined Diameter
> > > >>> Application IDs. Every proxy on the path needs new code
> > to handle
> > > >>> the new application,
> > > > while
> > > >>> just adding an extra AVP or new Service-Type value does
> > not hurt.
> > > >>>
> > > >>>     Is this an issue for us?
> > > >>>
> > > >>> Ciao
> > > >>> Hannes
> > > >>>
> > > >>> PS: Here is copy-and-paste version of some discussion
> > snippets to
> > > > allow
> > > >>> others to catch-up.
> > > >>>
> > > >>> Julien starts the discussion with a question about Application
> > IDs.
> > > >>>
> > > >>> Pasi suggests to consider Service-Type and/or NAS-Port-Type
AVPs
> > as
> > > >>> well.... the problem starts.
> > > >>>
> > > >>> Avi states that the problem is that neither Service-Type or
> > > > Port-Type is
> > > >>> mandatory.
> > > >>> "
> > > >>> Service Type seems to be the correct way but in RADIUS and
> > > >>> Diameter service-type also can be authenticate-only or
> > > > authorize-only.
> > > >>> So what if the HA wanted to authenticate-only or
authorize-only
> > for
> > > > the
> > > >>> MIP service?  I would lose the ability to also indicate
> > that this
> > is
> > > > an
> > > >>> HA.
> > > >>>
> > > >>> So Port-Type seems to be the way to go....
> > > >>> "
> > > >>>
> > > >>> Jari jumps in:
> > > >>> "
> > > >>> One of the reasons why an existing application would be
> > preferred
> > > >>> is that then a AAA server that does not care about the type of
> > > >>> service can be used without changes. Yet servers that
> > do care can
> > > >>> look at the AVPs and make more detailed authorization
decisions.
> > > >>>
> > > >>>
> > > >>> RFC 3588 states that  "Creation of a new application should be
> > > >>> viewed as a last resort." and that "In order to justify
> > allocation
> > > >>> of a new application identifier, Diameter applications
> > MUST define
> > > >>> one Command Code, or add new mandatory AVPs to the ABNF." Note
> > > >>> that mandatory AVPs can be viewed in different ways,
> > and that we
> > > >>> should not be too strict about them.
> > > >>> For instance, Framed-Protocol is an optional AVP in
> > RFCs 4005 and
> > > >>> 4072. Yet, you could argue that if you are doing PPP
> > then you need
> > > >>> to use this attribute and set it to PPP. But that
> > didn't make the
> > > >>> attribute mandatory.
> > > >>> Do we have a similar situation for the IKEv2/MIPv6
> > attributes and
> > > >>> values? They are not necessary from the NASREQ/EAP
perspective,
> > > >>> but in the specific context you need to use the
> > attributes. In my
> > > >>> mind, this does not make the attributes mandatory from
> > a Diameter
> > > >>> application point of view. If we start creating new
> > applications
> > > >>> for every different situation, we'll have lots of
> > applications and
> > > >>> interoperability problems. Its better to add new
> > optional AVPs and
> > > >>> describe in text when they should be used. The only
> > exception that
> > > >>> I see is security related AVPs that must be understood by the
> > > >>> other side or else the session should be terminated.
> > > >>> "
> > > >>>
> > > >>> Avi responds:
> > > >>> "
> > > >>> Mandatory does not mean required in the Command.  It
> > means that it
> > > > must
> > > >>> be understood by the receiver.  We need to clarify that.
> > > >>> "
> > > >>>
> > > >>> Gerardo and Lionel agree with Jari.
> > > >>>
> > > >>>
> > > >>>
> > > >>> Avi writes:
> > > >>> "
> > > >>> If I have two EAP based application in my network, one that is
> > > >>> handling pure EAP application, the other is extended to
> > handle the
> > > > new
> > > >>> behavior then I need a way to route the (same) command
> > correctly.
> > > >>> "
> > > >>>
> > > >>> Jari writes:
> > > >>> "
> > > >>> Ah, but that is a new requirement. If you believe that
> > you need to
> > > >>> route EAP authentication from a 802.11 AP differently than
from
> > > >>> IKEv2/MIPv6, then you need one of these:
> > > >>>
> > > >>> - Use different user/domain names for the users of
> > > >>>   the different services.
> > > >>>
> > > >>> - Point to different servers from the AP and SGW (but
> > > >>>   this works less well if you have proxies and roaming).
> > > >>>
> > > >>> - New application ID.
> > > >>>
> > > >>> - Some weird form of Diameter and RADIUS source routing
> > > >>>   based on what type of node sent the message.
> > > >>>
> > > >>> However, it is far from clear to me why you would
> > really need to
> > > >>> route the authentication differently *for the same user*. Many
> > > >>> authentication mechanisms can also have state, which
> > would imply
> > > >>> that at the end they need to end up in the same device
> > anyhow. Can
> > > >>> you expand on why you need to handle the same users in
> > different
> > > >>> authentication servers?
> > > >>> "
> > > >>>
> > > >>> Avi to Jari:
> > > >>>
> > > >>> "
> > > >>> BTW in the context of the original question raised, the
> > attribute(s)
> > > >>> will not be optional. Here is the snippet:
> > > >>>
> > > >>>>>>>  In our case, the AAA server must perform AAA
functionality
> > > > for
> > > >> the
> > > >>>>>>> Mobile IPv6 service. The AAA server must know that
> > it has to
> > > >>>>>>> authorize the mip6 service and the accounting (ASR/ASA) is
> > > > also
> > > >> for
> > > >>>>>>>  mip6 and not for network access.
> > > >>> If the Diameter message comes from the HA then the HA
> > MUST include
> > > > the
> > > >>> NAS-Port-type attribute. So the command ABNF is being changed.
> > Also
> > > > the
> > > >>> behavior is being changed of the Server.  It MUST recognize
the
> > > > (new)
> > > >>> value of the NAS-Port-Type.
> > > >>> "
> > > >>>
> > > >>>
> > > >>> Yoshi says:
> > > >>> "
> > > >>> If what is important is service-specific routing (I am not
> > convinced
> > > >>> with it yet), I'd suggest defining a new authorization-only
> > > >>> application used only for carrying service-specific attributes
> > > >>> (analogous to NASREQ usage in RFC 4072).  The downside
> > is that it
> > > >>> needs another message roundtrip than carrying the attributes
in
> > > >>> DER/DEA.
> > > >>> "
> > > >>>
> > > >>>
> > > >>> Julien wrote:
> > > >>> "
> > > >>>>> I don't think it's clean to require use of different
> > > >>>>> users'identifiers in order to distinguish which services is
> > > >>>>> provided. For me, it looks like a 'hack'.
> > > >>> " and Pasi responded:
> > > >>> "
> > > >>> I fully agree -- but having separate user identifiers should
not
> > be
> > > >>> necessary. If, for example, an operator wants to
> > perform different
> > > >>> authorizations for WiFi and WiMAX (e.g., some users can access
> > only
> > > >>> WiFi but not WiMAX), that's simple to do: just check
> > Service-Type,
> > > >>> NAS-Port-Type, and other relevant authorization AVPs.  There's
> > > >>> absolutely no need to create a new Diameter application.
> > > >>>
> > > >>> If the AAA server is really strict about WiFi vs. WiMAX
> > separation,
> > > > it
> > > >>> can have a policy that requires the NAS-Port-Type AVP to be
> > present
> > > >>> (if the request does not contain it, access is denied).
Although
> > > > this
> > > >>> in some sense make NAS-Port-Type AVP "mandatory", it's not
> > > > "mandatory"
> > > >>> in the sense that would require a new Diameter application.
> > > >>>
> > > >>> While IKEv2 and MIP6 are not WiFi and WiMAX, I don't think
there
> > are
> > > >>> any significant differences from Diameter
> > point-of-view. There's a
> > > > box
> > > >>> providing some service; authentication works with EAP;
> > authorization
> > > >>> AVPs indicate what exactly is being authorized. What's
> > missing is
> > > >>> a document describing how the different authorization AVPs are
> > > >>> used in this particular situation; sort of like RFC 3580 (IEEE
> > > > 802.1X
> > > >>> RADIUS Usage Guidelines), but for Diameter with IKEv2.
> > > >>>
> > > >>> One important reason NOT to create new applications: proxies.
> > Every
> > > >>> proxy on the path needs new code to handle the new
application,
> > > > while
> > > >>> just adding an extra AVP or new Service-Type value doesn't.
> > > >>> "
> > > >>>
> > > >>> John agrees with Pasi.
> > > >>>
> > > >>> Avi writes:
> > > >>> "
> > > >>> A mandatory attribute (a must understand attribute)
> > that has a new
> > > >>> enumeration is in my mind is like adding a new
> > attribute that must
> > > > be
> > > >>> understood.  There is no wigle room here.  The command
carrying
> > that
> > > >>> attribute must reach the implementation that knows how to
> > interpret
> > > > the
> > > >>> attribute.  This is  because an implmentation that does not
> > > > understand
> > > >>> Service-Type =3D X must return an error.
> > > >>>
> > > >>> It is obvious that the rules in 3588 are not sufficient to
> > describe
> > > > when
> > > >>> to use a new Application ID or not.  And we should not have to
> > have
> > > > a
> > > >>> debate on this topic.
> > > >>>
> > > >>> BTW if we do what you say then in networks where I have NASREQ
> > > >>> performing Network Access and now I want to roll out
> > MIPv6 I would
> > > > have
> > > >>> to upgrade all my old NASREQ deployed applications.  This is
> > wrong.
> > > > I
> > > >>> should be able to add a MIPv6 compliant diameter application
> > without
> > > >>> having to force upgrading my NASREQ applications.
> > > >>> "
> > > >>>
> > > >>>
> > > >>> _______________________________________________
> > > >>> DiME mailing list
> > > >>> DiME@ietf.org
> > > >>> https://www1.ietf.org/mailman/listinfo/dime
> > > >> --
> > > >> julien.bournelle at int-evry.fr
> > > >>
> > > >> _______________________________________________
> > > >> DiME mailing list
> > > >> DiME@ietf.org
> > > >> https://www1.ietf.org/mailman/listinfo/dime
> > > >
> > > >
> > > > "This email message and any attachments are confidential
> > information
> > of
> > > Starent Networks, Corp. The information transmitted may not
> > be used to
> > > create or change any contractual obligations of Starent Networks,
> > Corp.
> > > Any review, retransmission, dissemination or other use of, or
taking
> > of
> > > any action in reliance upon this e-mail and its attachments
> > by persons
> > or
> > > entities other than the intended recipient is prohibited. If you
are
> > not
> > > the intended recipient, please notify the sender immediately -- by
> > > replying to this message or by sending an email to
> > > postmaster@starentnetworks.com -- and destroy all copies of this
> > message
> > > and any attachments without reading or disclosing their contents.
> > Thank
> > > you."
> > > >
> > > >
> >
> >
> > _______________________________________________
> > DiME mailing list
> > DiME@ietf.org
> > https://www1.ietf.org/mailman/listinfo/dime
> >

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



From dime-bounces@ietf.org Mon Aug 21 13:50:13 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GFDub-0001mu-Ha; Mon, 21 Aug 2006 13:50:09 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GFDua-0001mp-J1
	for dime@ietf.org; Mon, 21 Aug 2006 13:50:08 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129]
	helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFBRh-0001mt-F9
	for dime@ietf.org; Mon, 21 Aug 2006 11:12:09 -0400
Received: from mgw.toshibaamericaresearch.com ([165.254.55.12]
	helo=toshi17.tari.toshiba.com)
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GFBBH-0001y9-C3
	for dime@ietf.org; Mon, 21 Aug 2006 10:55:13 -0400
Received: from [127.0.0.1] (toshi17.tari.toshiba.com [172.30.24.10])
	by toshi17.tari.toshiba.com (8.13.1/8.13.1) with ESMTP id
	k7LEt3Oq001228; Mon, 21 Aug 2006 10:55:03 -0400 (EDT)
	(envelope-from vfajardo@tari.toshiba.com)
Message-ID: <44E9C95B.7060602@tari.toshiba.com>
Date: Mon, 21 Aug 2006 10:55:23 -0400
From: Victor Fajardo <vfajardo@tari.toshiba.com>
User-Agent: Thunderbird 1.5.0.5 (X11/20060719)
MIME-Version: 1.0
To: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
Subject: Re: [Dime] Diameter Interop & Diameter Interoperability Test Suite
	Document
References: <44E83ACA.3020805@gmx.net>
In-Reply-To: <44E83ACA.3020805@gmx.net>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: -2.3 (--)
X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

Hi all,

Just to add on what Hannes has mentioned, it maybe best to get more 
feedback on the following:

1. Which applications/interfaces are people more interested in testing, 
especially if they are not currently present in the document.
2. The test scenarios you would want to perform on new/existing 
applications that are not covered by the existing document.
3. If the test topologies present in the document is sufficient.

Based on the last bake off, some time was spent on setting up initial 
connectivity so I think it maybe best if we also think about how to 
prepare the test environment to reduce this initial chaos and it may 
also help in preparing for more complex topologies. We may also want to 
think about more formal test procedures which deals with issues such as 
setting up test pairs especially in this second interop where previous 
participants may have more mature implementations than newer participants.

regards,
victor

> Hi all,
>
> to perform the interop testing in a more structured way we once wrote 
> the following Diameter Interoperability Test Suite document:
> http://tools.ietf.org/wg/dime/draft-fajardo-dime-interop-test-suite-01.txt 
>
>
> It was updated after the last interop based on the feedback we got; 
> more updates might, however, be needed.
>
> Since we are looking ahead to the next interop it would be good to get 
> some feedback to agree on the test scenarios ahead of time. This also 
> gives us the chance to more clearly summarize the outcome of the event 
> in the report. It might also give participants the chance to prepare 
> some scripts and to agree on the scope of the tests.
>
> Ciao
> Hannes
>
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www1.ietf.org/mailman/listinfo/dime
>
>


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



From dime-bounces@ietf.org Mon Aug 21 14:12:54 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GFEGa-0000TU-C2; Mon, 21 Aug 2006 14:12:52 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GFEGZ-0000SS-7A
	for dime@ietf.org; Mon, 21 Aug 2006 14:12:51 -0400
Received: from smtp2.int-evry.fr ([157.159.10.45])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFECq-0001UW-Qh
	for dime@ietf.org; Mon, 21 Aug 2006 14:09:04 -0400
Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76])
	by smtp2.int-evry.fr (Postfix) with ESMTP id 0A3CF2FDD7;
	Mon, 21 Aug 2006 20:08:53 +0200 (CEST)
Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.52)
	id 1GFEEc-00075P-9r; Mon, 21 Aug 2006 20:10:50 +0200
Date: Mon, 21 Aug 2006 20:10:50 +0200
From: Julien Bournelle <julien.bournelle@int-evry.fr>
To: "Chowdhury, Kuntal" <kchowdhury@starentnetworks.com>
Subject: Re: [Dime] Mobile IPv6 Bootstrapping - "Application
	ID"vs."NAS-Port-Type AVP/Service-Type": Summary
Message-ID: <20060821181050.GB27228@ipv6-3.int-evry.fr>
References: <7CCD07160348804497EF29E9EA5560D783721A@exchtewks2.starentnetworks.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <7CCD07160348804497EF29E9EA5560D783721A@exchtewks2.starentnetworks.com>
User-Agent: Mutt/1.5.9i
X-INT-MailScanner-Information: Please contact the ISP for more information
X-INT-MailScanner: Found to be clean
X-INT-MailScanner-MCPCheck: 
X-INT-MailScanner-SpamCheck: 
X-MailScanner-From: jb@int-evry.fr
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e9eeacd7fe925d5f7faae01ed8f85b97
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

HI Kuntal,

On Mon, Aug 21, 2006 at 01:10:02PM -0400, Chowdhury, Kuntal wrote:
> 
> 
> > -----Original Message-----
> > From: Avi Lior [mailto:avi@bridgewatersystems.com]
> > Sent: Monday, August 21, 2006 11:06 AM
> > To: Chowdhury, Kuntal; Hannes Tschofenig
> > Cc: dime@ietf.org
> > Subject: RE: [Dime] Mobile IPv6 Bootstrapping - "Application
> ID"vs."NAS-
> > Port-Type AVP/Service-Type": Summary
> > 
> > Service-Type should not be used.
> > 
> > If you add a new value to the NAS-Port-Type then you need a new
> > Application-ID anyway.  You have to make sure that the packet reaches
> an
> > entity that can understands the new value.  Otherewise you could end
> up
> > delivering the packet to a legacy server that doesn't not understand
> the
> > MIPv6 application.
> > 
> [KC>] Hmmm...it will be an interesting situation when the Mobility
> Service Provider (MSP) deploys AAA servers that do not understand MIP6!
> 
> > Once you have a new Application-ID you really don't need NAS-Port-Type
> > (as pointed out correctly by Julien).
> > 
> [KC>] How about NAS-port AVP? Do we need a new application ID if we
> decide to use a specific value in NAS-port AVP to indicate MIP6
> bootstrapping?
> 
> > I don't understand what the concern about modification of Diameter
> > Agents.
> > 
> [KC>] My main goal is this: If we can use Diameter EAP (DER/DEA) or
> NASREQ (AAR/AAA) transactions to download MIP6 bootstrapping parameters
> (HA, HL etc.) that will be ideal. I am trying to avoid extra
> transactions from NAS and HA if possible. Hope you will appreciate this
> goal. If we end-up mandating some non-mandatory AVPs in EAP/NASREQ, only
> then we should define new application ID for MIP6 bootstrapping, IMHO.

 I think we should not mix the integrated and split scenario case.

 In the integrated, we're doing AAA for network access and we provide to
 the NAS the HA info. So in this case, I don't think we need a new
 App-ID. NASREQ or EAP Application is used. However, it may be
 interesting that the AAA server knows if the NAS support
 functionalities described in the draft-ietf-mip6-integrated.

 In the split, we're doing AAA for the Mobile IPv6 service and thus the
 discussion.

 Julien

> 
> > If you use Application Id then Relays wont have to change right?
> > 
> > Proxies would have to change if and only if they are going to be
> proxies
> > for that Application.  But that is the definition of a Proxy right?
> > 
> > 
> > > -----Original Message-----
> > > From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com]
> > > Sent: Monday, August 21, 2006 10:45 AM
> > > To: Hannes Tschofenig
> > > Cc: dime@ietf.org
> > > Subject: RE: [Dime] Mobile IPv6 Bootstrapping - "Application
> > > ID"vs."NAS-Port-Type AVP/Service-Type": Summary
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
> > > > Sent: Sunday, August 20, 2006 3:07 AM
> > > > To: Chowdhury, Kuntal
> > > > Cc: Julien Bournelle; dime@ietf.org
> > > > Subject: Re: [Dime] Mobile IPv6 Bootstrapping - "Application ID"
> > > vs."NAS-
> > > > Port-Type AVP/Service-Type": Summary
> > > >
> > > > Hi Kuntal,
> > > >
> > > >
> > > > Chowdhury, Kuntal schrieb:
> > > > > Hi Hannes, Julien,
> > > > >
> > > > > Application-ID is one way, but as has been discussed so far it
> > > requires
> > > > > changes in the intermediaries.
> > > >
> > > > True.
> > > >
> > > >   A new value in NAS-Port-Type AVP seems
> > > > > more logical and easier to implement, IMHO.
> > > >
> > > > Easier to implement: True.
> > > >
> > > >   I am not sure about the
> > > > > Service-Type AVP. I am wondering what cannot be conveyed via
> > > > > NAS-Port-Type AVP so that we need this additional AVP?
> > > > >
> > > > > Apologize for jumping in late....still trying to understand the
> > > whole
> > > > > issue.
> > > > Please read my copy-and-paste summary of the discussion.
> > > >
> > > > In some sense we are discussing fundamentals of how to extend
> > > Diameter.
> > > > The application ID is used for routing. If we don't define a new
> > > app-ID
> > > > then we cannot route network access messages and MIP6
> bootstrapping
> > > > messages differently. Some folks think that this is important.
> > > > What do you think?
> > > >
> > > [KC>] In case of split scenario, I see the use case where the
> > > AAA transaction for network access at the NAS is going to a
> > > different AAA server than the same at the HA, since ASA !=
> > > MSA in split. In case of integrated scenario, it is essential
> > > that the AAA transactions from the NAS and from the HA get
> > > routed to the same AAA server (ASA == MSA). So we need to
> > > keep this in mind.
> > >
> > > >From the AAA message routing point of view, I thought the
> > > @realm part
> > > >of
> > > the username (NAI) was sufficient to route AAA messages to
> > > different AAA systems. There are other reasons for separate
> > > APP-ID for MIP6 bootstrapping, e.g. if we decide to mandate
> > > AVPs needed for MIP6 bootstrapping in DER/DEA (as an
> > > example). I don't know why we would do that i.e. mandate MIP6
> > > bootstrapping AVPs in DER/DEA.
> > >
> > >
> > > > Ciao
> > > > Hannes
> > > >
> > > > >
> > > > > -Kuntal
> > > > >
> > > > >
> > > > >> -----Original Message-----
> > > > >> From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr]
> > > > >> Sent: Friday, August 18, 2006 11:54 AM
> > > > >> To: Hannes Tschofenig
> > > > >> Cc: dime@ietf.org
> > > > >> Subject: Re: [Dime] Mobile IPv6 Bootstrapping - "Application
> ID"
> > > > > vs."NAS-
> > > > >> Port-Type AVP/Service-Type": Summary
> > > > >>
> > > > >> Hi hannes,
> > > > >>
> > > > >>  thanks for this clarifying mail.
> > > > >>
> > > > >>
> > > > >> On Wed, Aug 16, 2006 at 10:51:07PM +0200, Hannes
> > > Tschofenig wrote:
> > > > >>> Hi all,
> > > > >>>
> > > > >>> I went through the discussion again and noticed that we
> haven't
> > > > > reached
> > > > >>> a conclusion.
> > > > >>>
> > > > >>> Here is my impression:
> > > > >>>
> > > > >>> * RFC 3588 leaves a question regarding the extensibility open.
> > > > >>>   This needs to be captured in the revision of the base
> > > > > specification.
> > > > >>> * The main issue seems to be
> > > > >>>
> > > > >>>   - Do we want to route 'Diameter EAP' message and 'Diameter
> > > Mobile
> > > > >>> IPv6 Bootstrapping' messages differently?
> > > > >>  I tend to think that it is safer to assume that some
> > > operators may
> > > > >> desire that.
> > > > >>
> > > > >>>     If we want to route them differently then we need to
> define
> > > > >>> 'Diameter MIPv6 Bootstrapping' as a Diameter application.
> > > > >>>
> > > > >>>   - The AAA server differentiates ordinary network access and
> > > MIPv6
> > > > >>> bootstrapping functionality (with respect to authorization and
> > > > >>> accounting). In order to do so it must understand the
> > > Service-Type
> > > > >>> and/or NAS-Port-Type AVPs and the defined values.
> > > > >>>
> > > > >>>     Is this a problem?
> > > > >>  Not sure to understand this problem. For me, if we have
> > > the App-Id
> > > we
> > > > >>  don't need Service-Type nor NAS-Port Type.
> > > > >>  IF we don't have the App-ID, yes we need to define new values.
> > > > >>
> > > > >>  Maybe i missed the problem you raised.
> > > > >>
> > > > >>  regards,
> > > > >>
> > > > >>  Julien
> > > > >>
> > > > >>>   - There are problems with proxies and newly defined Diameter
> > > > >>> Application IDs. Every proxy on the path needs new code
> > > to handle
> > > > >>> the new application,
> > > > > while
> > > > >>> just adding an extra AVP or new Service-Type value does
> > > not hurt.
> > > > >>>
> > > > >>>     Is this an issue for us?
> > > > >>>
> > > > >>> Ciao
> > > > >>> Hannes
> > > > >>>
> > > > >>> PS: Here is copy-and-paste version of some discussion
> > > snippets to
> > > > > allow
> > > > >>> others to catch-up.
> > > > >>>
> > > > >>> Julien starts the discussion with a question about Application
> > > IDs.
> > > > >>>
> > > > >>> Pasi suggests to consider Service-Type and/or NAS-Port-Type
> AVPs
> > > as
> > > > >>> well.... the problem starts.
> > > > >>>
> > > > >>> Avi states that the problem is that neither Service-Type or
> > > > > Port-Type is
> > > > >>> mandatory.
> > > > >>> "
> > > > >>> Service Type seems to be the correct way but in RADIUS and
> > > > >>> Diameter service-type also can be authenticate-only or
> > > > > authorize-only.
> > > > >>> So what if the HA wanted to authenticate-only or
> authorize-only
> > > for
> > > > > the
> > > > >>> MIP service?  I would lose the ability to also indicate
> > > that this
> > > is
> > > > > an
> > > > >>> HA.
> > > > >>>
> > > > >>> So Port-Type seems to be the way to go....
> > > > >>> "
> > > > >>>
> > > > >>> Jari jumps in:
> > > > >>> "
> > > > >>> One of the reasons why an existing application would be
> > > preferred
> > > > >>> is that then a AAA server that does not care about the type of
> > > > >>> service can be used without changes. Yet servers that
> > > do care can
> > > > >>> look at the AVPs and make more detailed authorization
> decisions.
> > > > >>>
> > > > >>>
> > > > >>> RFC 3588 states that  "Creation of a new application should be
> > > > >>> viewed as a last resort." and that "In order to justify
> > > allocation
> > > > >>> of a new application identifier, Diameter applications
> > > MUST define
> > > > >>> one Command Code, or add new mandatory AVPs to the ABNF." Note
> > > > >>> that mandatory AVPs can be viewed in different ways,
> > > and that we
> > > > >>> should not be too strict about them.
> > > > >>> For instance, Framed-Protocol is an optional AVP in
> > > RFCs 4005 and
> > > > >>> 4072. Yet, you could argue that if you are doing PPP
> > > then you need
> > > > >>> to use this attribute and set it to PPP. But that
> > > didn't make the
> > > > >>> attribute mandatory.
> > > > >>> Do we have a similar situation for the IKEv2/MIPv6
> > > attributes and
> > > > >>> values? They are not necessary from the NASREQ/EAP
> perspective,
> > > > >>> but in the specific context you need to use the
> > > attributes. In my
> > > > >>> mind, this does not make the attributes mandatory from
> > > a Diameter
> > > > >>> application point of view. If we start creating new
> > > applications
> > > > >>> for every different situation, we'll have lots of
> > > applications and
> > > > >>> interoperability problems. Its better to add new
> > > optional AVPs and
> > > > >>> describe in text when they should be used. The only
> > > exception that
> > > > >>> I see is security related AVPs that must be understood by the
> > > > >>> other side or else the session should be terminated.
> > > > >>> "
> > > > >>>
> > > > >>> Avi responds:
> > > > >>> "
> > > > >>> Mandatory does not mean required in the Command.  It
> > > means that it
> > > > > must
> > > > >>> be understood by the receiver.  We need to clarify that.
> > > > >>> "
> > > > >>>
> > > > >>> Gerardo and Lionel agree with Jari.
> > > > >>>
> > > > >>>
> > > > >>>
> > > > >>> Avi writes:
> > > > >>> "
> > > > >>> If I have two EAP based application in my network, one that is
> > > > >>> handling pure EAP application, the other is extended to
> > > handle the
> > > > > new
> > > > >>> behavior then I need a way to route the (same) command
> > > correctly.
> > > > >>> "
> > > > >>>
> > > > >>> Jari writes:
> > > > >>> "
> > > > >>> Ah, but that is a new requirement. If you believe that
> > > you need to
> > > > >>> route EAP authentication from a 802.11 AP differently than
> from
> > > > >>> IKEv2/MIPv6, then you need one of these:
> > > > >>>
> > > > >>> - Use different user/domain names for the users of
> > > > >>>   the different services.
> > > > >>>
> > > > >>> - Point to different servers from the AP and SGW (but
> > > > >>>   this works less well if you have proxies and roaming).
> > > > >>>
> > > > >>> - New application ID.
> > > > >>>
> > > > >>> - Some weird form of Diameter and RADIUS source routing
> > > > >>>   based on what type of node sent the message.
> > > > >>>
> > > > >>> However, it is far from clear to me why you would
> > > really need to
> > > > >>> route the authentication differently *for the same user*. Many
> > > > >>> authentication mechanisms can also have state, which
> > > would imply
> > > > >>> that at the end they need to end up in the same device
> > > anyhow. Can
> > > > >>> you expand on why you need to handle the same users in
> > > different
> > > > >>> authentication servers?
> > > > >>> "
> > > > >>>
> > > > >>> Avi to Jari:
> > > > >>>
> > > > >>> "
> > > > >>> BTW in the context of the original question raised, the
> > > attribute(s)
> > > > >>> will not be optional. Here is the snippet:
> > > > >>>
> > > > >>>>>>>  In our case, the AAA server must perform AAA
> functionality
> > > > > for
> > > > >> the
> > > > >>>>>>> Mobile IPv6 service. The AAA server must know that
> > > it has to
> > > > >>>>>>> authorize the mip6 service and the accounting (ASR/ASA) is
> > > > > also
> > > > >> for
> > > > >>>>>>>  mip6 and not for network access.
> > > > >>> If the Diameter message comes from the HA then the HA
> > > MUST include
> > > > > the
> > > > >>> NAS-Port-type attribute. So the command ABNF is being changed.
> > > Also
> > > > > the
> > > > >>> behavior is being changed of the Server.  It MUST recognize
> the
> > > > > (new)
> > > > >>> value of the NAS-Port-Type.
> > > > >>> "
> > > > >>>
> > > > >>>
> > > > >>> Yoshi says:
> > > > >>> "
> > > > >>> If what is important is service-specific routing (I am not
> > > convinced
> > > > >>> with it yet), I'd suggest defining a new authorization-only
> > > > >>> application used only for carrying service-specific attributes
> > > > >>> (analogous to NASREQ usage in RFC 4072).  The downside
> > > is that it
> > > > >>> needs another message roundtrip than carrying the attributes
> in
> > > > >>> DER/DEA.
> > > > >>> "
> > > > >>>
> > > > >>>
> > > > >>> Julien wrote:
> > > > >>> "
> > > > >>>>> I don't think it's clean to require use of different
> > > > >>>>> users'identifiers in order to distinguish which services is
> > > > >>>>> provided. For me, it looks like a 'hack'.
> > > > >>> " and Pasi responded:
> > > > >>> "
> > > > >>> I fully agree -- but having separate user identifiers should
> not
> > > be
> > > > >>> necessary. If, for example, an operator wants to
> > > perform different
> > > > >>> authorizations for WiFi and WiMAX (e.g., some users can access
> > > only
> > > > >>> WiFi but not WiMAX), that's simple to do: just check
> > > Service-Type,
> > > > >>> NAS-Port-Type, and other relevant authorization AVPs.  There's
> > > > >>> absolutely no need to create a new Diameter application.
> > > > >>>
> > > > >>> If the AAA server is really strict about WiFi vs. WiMAX
> > > separation,
> > > > > it
> > > > >>> can have a policy that requires the NAS-Port-Type AVP to be
> > > present
> > > > >>> (if the request does not contain it, access is denied).
> Although
> > > > > this
> > > > >>> in some sense make NAS-Port-Type AVP "mandatory", it's not
> > > > > "mandatory"
> > > > >>> in the sense that would require a new Diameter application.
> > > > >>>
> > > > >>> While IKEv2 and MIP6 are not WiFi and WiMAX, I don't think
> there
> > > are
> > > > >>> any significant differences from Diameter
> > > point-of-view. There's a
> > > > > box
> > > > >>> providing some service; authentication works with EAP;
> > > authorization
> > > > >>> AVPs indicate what exactly is being authorized. What's
> > > missing is
> > > > >>> a document describing how the different authorization AVPs are
> > > > >>> used in this particular situation; sort of like RFC 3580 (IEEE
> > > > > 802.1X
> > > > >>> RADIUS Usage Guidelines), but for Diameter with IKEv2.
> > > > >>>
> > > > >>> One important reason NOT to create new applications: proxies.
> > > Every
> > > > >>> proxy on the path needs new code to handle the new
> application,
> > > > > while
> > > > >>> just adding an extra AVP or new Service-Type value doesn't.
> > > > >>> "
> > > > >>>
> > > > >>> John agrees with Pasi.
> > > > >>>
> > > > >>> Avi writes:
> > > > >>> "
> > > > >>> A mandatory attribute (a must understand attribute)
> > > that has a new
> > > > >>> enumeration is in my mind is like adding a new
> > > attribute that must
> > > > > be
> > > > >>> understood.  There is no wigle room here.  The command
> carrying
> > > that
> > > > >>> attribute must reach the implementation that knows how to
> > > interpret
> > > > > the
> > > > >>> attribute.  This is  because an implmentation that does not
> > > > > understand
> > > > >>> Service-Type = X must return an error.
> > > > >>>
> > > > >>> It is obvious that the rules in 3588 are not sufficient to
> > > describe
> > > > > when
> > > > >>> to use a new Application ID or not.  And we should not have to
> > > have
> > > > > a
> > > > >>> debate on this topic.
> > > > >>>
> > > > >>> BTW if we do what you say then in networks where I have NASREQ
> > > > >>> performing Network Access and now I want to roll out
> > > MIPv6 I would
> > > > > have
> > > > >>> to upgrade all my old NASREQ deployed applications.  This is
> > > wrong.
> > > > > I
> > > > >>> should be able to add a MIPv6 compliant diameter application
> > > without
> > > > >>> having to force upgrading my NASREQ applications.
> > > > >>> "
> > > > >>>
> > > > >>>
> > > > >>> _______________________________________________
> > > > >>> DiME mailing list
> > > > >>> DiME@ietf.org
> > > > >>> https://www1.ietf.org/mailman/listinfo/dime
> > > > >> --
> > > > >> julien.bournelle at int-evry.fr
> > > > >>
> > > > >> _______________________________________________
> > > > >> DiME mailing list
> > > > >> DiME@ietf.org
> > > > >> https://www1.ietf.org/mailman/listinfo/dime
> > > > >
> > > > >
> > > > > "This email message and any attachments are confidential
> > > information
> > > of
> > > > Starent Networks, Corp. The information transmitted may not
> > > be used to
> > > > create or change any contractual obligations of Starent Networks,
> > > Corp.
> > > > Any review, retransmission, dissemination or other use of, or
> taking
> > > of
> > > > any action in reliance upon this e-mail and its attachments
> > > by persons
> > > or
> > > > entities other than the intended recipient is prohibited. If you
> are
> > > not
> > > > the intended recipient, please notify the sender immediately -- by
> > > > replying to this message or by sending an email to
> > > > postmaster@starentnetworks.com -- and destroy all copies of this
> > > message
> > > > and any attachments without reading or disclosing their contents.
> > > Thank
> > > > you."
> > > > >
> > > > >
> > >
> > >
> > > _______________________________________________
> > > DiME mailing list
> > > DiME@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/dime
> > >
> 
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www1.ietf.org/mailman/listinfo/dime

-- 
julien.bournelle at int-evry.fr

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



From dime-bounces@ietf.org Mon Aug 21 14:22:09 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GFEPZ-0003ZS-1P; Mon, 21 Aug 2006 14:22:09 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GFEPY-0003ZN-22
	for dime@ietf.org; Mon, 21 Aug 2006 14:22:08 -0400
Received: from mail.gmx.net ([213.165.64.20])
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GFEPT-0003nD-KN
	for dime@ietf.org; Mon, 21 Aug 2006 14:22:08 -0400
Received: (qmail invoked by alias); 21 Aug 2006 18:22:02 -0000
Received: from p54985AA8.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.90.168]
	by mail.gmx.net (mp015) with SMTP; 21 Aug 2006 20:22:02 +0200
X-Authenticated: #29516787
Message-ID: <44E9F9C9.3050904@gmx.net>
Date: Mon, 21 Aug 2006 20:22:01 +0200
From: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: "Chowdhury, Kuntal" <kchowdhury@starentnetworks.com>
References: <7CCD07160348804497EF29E9EA5560D7837217@exchtewks2.starentnetworks.com>
In-Reply-To: <7CCD07160348804497EF29E9EA5560D7837217@exchtewks2.starentnetworks.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Cc: dime@ietf.org
Subject: [Dime] ASA == MSA: Is it the same Server? 
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

Hi Kuntal,

> [KC>] In case of split scenario, I see the use case where the AAA
> transaction for network access at the NAS is going to a different AAA
> server than the same at the HA, since ASA != MSA in split.

In this case the identities are different though. You cannot use the 
same identity to hit two different domains.
Hence, there is no problem as such.

  In case of
> integrated scenario, it is essential that the AAA transactions from the
> NAS and from the HA get routed to the same AAA server (ASA == MSA). So
> we need to keep this in mind.

Here is the question whether they are indeed the same server. Some folks 
they argue that it is not the same one

>>From the AAA message routing point of view, I thought the @realm part of
> the username (NAI) was sufficient to route AAA messages to different AAA
> systems.

IMHO, for the ASA != MSA scenario it is.

Ciao
Hannes

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



From dime-bounces@ietf.org Mon Aug 21 14:51:52 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GFEsG-0005dU-88; Mon, 21 Aug 2006 14:51:48 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GFEsE-0005dI-Vw
	for dime@ietf.org; Mon, 21 Aug 2006 14:51:46 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129]
	helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFCgI-0001OQ-6a
	for dime@ietf.org; Mon, 21 Aug 2006 12:31:18 -0400
Received: from rtp-iport-2.cisco.com ([64.102.122.149])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GFCWC-00043e-E4
	for dime@ietf.org; Mon, 21 Aug 2006 12:20:54 -0400
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
	by rtp-iport-2.cisco.com with ESMTP; 21 Aug 2006 12:20:52 -0400
X-IronPort-AV: i="4.08,152,1154923200"; 
	d="scan'208"; a="97829469:sNHT31906976"
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12])
	by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id
	k7LGKplN029854; Mon, 21 Aug 2006 12:20:51 -0400
Received: from [161.44.55.195] (dhcp-161-44-55-195.cisco.com [161.44.55.195])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id
	k7LGKpdM010857; Mon, 21 Aug 2006 12:20:51 -0400 (EDT)
Message-ID: <44E9DD61.1000100@cisco.com>
Date: Mon, 21 Aug 2006 12:20:49 -0400
From: Anders Kristensen <andersk@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: john.loughney@nokia.com
Subject: criteria for new app ID [was: Re: [Dime] Mobile IPv6 Bootstrapping
	- "Application	ID"vs."NAS-Port-Type AVP/Service-Type": Summary]
References: <BAA65A575825454CBB0103267553FCCC892123@esebe199.NOE.Nokia.com>
In-Reply-To: <BAA65A575825454CBB0103267553FCCC892123@esebe199.NOE.Nokia.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1; q=dns; l=2499; t=1156177252; x=1157041252;
	c=relaxed/simple; s=rtpdkim1001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=andersk@cisco.com;
	z=From:Anders=20Kristensen=20<andersk@cisco.com>
	|Subject:criteria=20for=20new=20app=20ID=20[was=3A=20Re=3A=20[Dime]=20Mobile=20IP
	v6=20Bootstrapping=0A=20-=20=22Application=09ID=22vs.=22NAS-Port-Type=20AVP
	/Service-Type=22=3A=20Summary] |To:john.loughney@nokia.com;
	X=v=3Dcisco.com=3B=20h=3DS04BeYGXSLHSctjApwUPdr/9Mz8=3D;
	b=dFcc5DAEaU/wqXOkUZJO428Wq4RS3GMfa+QvGUkZhqzepSu3oAioOloPHRVv1sYsaxBebyJ1
	y3EYnWGArpmlVCIA9WRqArdjNMFoxT6aQRmT2ZJRcIHxAbzUBvGH59n7;
Authentication-Results: rtp-dkim-1.cisco.com; header.From=andersk@cisco.com;
	dkim=pass ( sig from cisco.com verified; ); 
X-Spam-Score: -2.6 (--)
X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org



john.loughney@nokia.com wrote:
> Hannes,
> 
> 
> 
>>>Apologize for jumping in late....still trying to understand the whole
> 
> 
>>>issue.
>>
>>Please read my copy-and-paste summary of the discussion.
>>
>>In some sense we are discussing fundamentals of how to extend Diameter.
>>The application ID is used for routing. If we don't define a 
>>new app-ID then we cannot route network access messages and 
>>MIP6 bootstrapping messages differently. Some folks think that 
>>this is important.
>>What do you think?
> 
> 
> Just to stir the pot a bit .. I agree with you, we are discussing how
> have a Diameter extension and how it fits into the existing deployment.
> If using MIPv6 with Diameter creates new manditory attributes and/or
> changes the basic state machine, I assume a new application ID should be
> used.

I think there are other conditions under which a separate app ID is in 
order, e.g. if mandatory AVPs have been removed from the definition of 
messages or, more importantly, if the semantics of the new app are 
"sufficiently different" from those of the original application.

Regarding the latter case consider, for example, the definition of 
AA-Request in RFC 4005. The AAR definition lists pretty much all AVPs as 
being optional meaning one can reuse AAR to do basically anything.

3GPP's Gq spec defines its own version of the AA-Request which reuses 
*none* of the 4005 specific AVPs but includes a bunch of its own AVPs, 
also all optional. Gq was given its own app ID which I think was 
appropriate because although nominally they're reusing AAR and some 
other messages, effectively it's a very different application. This is 
even though a Gq AAR is, technically speaking, a valid 4005 AAR, also - 
except for the app ID, that is.

(I see now that 4005's AAR has a mandatory Auth-Request-Type AVP and 
Gq's AAR does not but that doesn't really change the point.)

Thanks,
Anders

> I think that if a new application ID is used, it still could be
> reasonable
> to include information how this new MIPv6 Diameter Application could be
> collocated
> with the existing MIP(v4) Application.
> 
> However, general question - have we gotten past the point where we know
> that 
> manditory attributes are required?  I just want to verify that.
> 
> thanks,
> John
> 
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www1.ietf.org/mailman/listinfo/dime
> 

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



From dime-bounces@ietf.org Mon Aug 21 15:00:30 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GFF0g-0000VH-Iy; Mon, 21 Aug 2006 15:00:30 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GFF0e-0000VC-Ua
	for dime@ietf.org; Mon, 21 Aug 2006 15:00:28 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129]
	helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFCgL-0001NE-SL
	for dime@ietf.org; Mon, 21 Aug 2006 12:31:21 -0400
Received: from lizzard.sbs.de ([194.138.37.39])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GFCWj-00044M-BU
	for dime@ietf.org; Mon, 21 Aug 2006 12:21:31 -0400
Received: from mail1.sbs.de (localhost [127.0.0.1])
	by lizzard.sbs.de (8.12.6/8.12.6) with ESMTP id k7LGLNZk031223;
	Mon, 21 Aug 2006 18:21:23 +0200
Received: from fthw9xoa.ww002.siemens.net (fthw9xoa.ww002.siemens.net
	[157.163.133.201])
	by mail1.sbs.de (8.12.6/8.12.6) with ESMTP id k7LGLNf8003277;
	Mon, 21 Aug 2006 18:21:23 +0200
Received: from MCHP7IEA.ww002.siemens.net ([139.25.131.145]) by
	fthw9xoa.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 21 Aug 2006 18:21:23 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: AW: [Dime] Next Steps for draft-tsou-dime-base-routing-ext-00
Date: Mon, 21 Aug 2006 18:21:22 +0200
Message-ID: <A5D2BD54850CCA4AA3B93227205D8A30898C54@MCHP7IEA.ww002.siemens.net>
In-Reply-To: <44E9C32E.5060007@tari.toshiba.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Dime] Next Steps for draft-tsou-dime-base-routing-ext-00
Thread-Index: AcbFLld9PLf+PMPxSWeZOdc2UwCzKAAA1rJg
From: "Tschofenig, Hannes" <hannes.tschofenig@siemens.com>
To: "Victor Fajardo" <vfajardo@tari.toshiba.com>, <john.loughney@nokia.com>
X-OriginalArrivalTime: 21 Aug 2006 16:21:23.0017 (UTC)
	FILETIME=[D7C29B90:01C6C53D]
X-Spam-Score: -2.4 (--)
X-Scan-Signature: 25eb6223a37c19d53ede858176b14339
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

Hi Victor,=20

in the discussions the 3GPP WLAN work was mentioned as the usage =
scenario.=20
Is it a real problem in their environment? I have never heard something =
about problems along these lines.=20

Ciao
Hannes
=20

> -----Urspr=FCngliche Nachricht-----
> Von: Victor Fajardo [mailto:vfajardo@tari.toshiba.com]=20
> Gesendet: Montag, 21. August 2006 16:29
> An: john.loughney@nokia.com
> Cc: dime@ietf.org
> Betreff: Re: [Dime] Next Steps for draft-tsou-dime-base-routing-ext-00
>=20
> Hi John,
>=20
> > Hi all,
> >
> > A very basic question - do we have consensus that we need source
> > routing and that it is a basic functionality?  Is this something
> > that is broken in the current document. =20
>=20
> The intention of the document was to propose an "extension" to the=20
> current routing functionality of the base to fulfill requirements in=20
> topologies where this functionality is needed. (i think these=20
> topologies/scenarios has been discussed lengthly in the=20
> list). Following=20
> your guideline, I think it maybe better that this should be=20
> an extension=20
> document given that it is not proposing changes to the=20
> existing routing=20
> schemes. I also think that the WG should work on this=20
> document since it=20
> does fulfill real world requirements.
>=20
> regards,
> victor
>=20
> > If so, then it should
> > be fixed in the base.  If this is an additional feature, then
> > it might be fine to have this as an extension draft.
> >
> > thanks,
> > John
> >
> >  =20
> >> -----Original Message-----
> >> From: ext Tolga Asveren [mailto:asveren@ulticom.com]=20
> >> Sent: 18 August, 2006 19:16
> >> To: Yoshihiro Ohba
> >> Cc: dime@ietf.org
> >> Subject: RE: [Dime] Next Steps for=20
> draft-tsou-dime-base-routing-ext-00
> >>
> >> Hi Yoshihiro,
> >>
> >>
> >>    =20
> >>> -----Original Message-----
> >>> From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com]
> >>> Sent: Thursday, August 17, 2006 11:48 AM
> >>> To: Hannes Tschofenig
> >>> Cc: dime@ietf.org
> >>> Subject: Re: [Dime] Next Steps for=20
> >>>      =20
> >> draft-tsou-dime-base-routing-ext-00
> >>    =20
> >>> I think the content of=20
> draft-tsou-dime-base-routing-ext-00 should be=20
> >>> integrated into rfc3588bis, because I think source=20
> routing is needed=20
> >>> to support stateful agents and thus should be part of=20
> base protocol.
> >>>      =20
> >> [TOLGA]I think we should distinguish between intermediaries,=20
> >> which advertise support for individual applications instead of=20
> >> 0xffffffff but are not really stateful and which are really=20
> >> stateful. Currently being stateful and advertising specific=20
> >> application support is tied together in RFC3588 by definition=20
> >> of a proxy but I don't think it needs to be. Acctually not=20
> >> doing so is not violation of the protocol, just defining a new=20
> >> node type, which is not explicitly mentioned in RFC3588.
> >>
> >> An example for the first one is a load-balancer for a specific=20
> >> application.
> >> It is interested to get only messages for a specific=20
> >> application but doesn't keep session related state. If a=20
> >> message does not have Destination-Host AVP, it forwards the=20
> >> message to a server based on congestion status of servers (how=20
> >> this information is propogated is topic for another thread).=20
> >> If a message has Destination-Host AVP, it just sends the=20
> >> message to that server.
> >>
> >> For that first type of intermediaries, everything would be=20
> >> working fine if AppId!=3D0 is used for common messages.=20
> >> Otherwise, a relay agent in front of load balancers serving=20
> >> different applications is enough to have common messages not=20
> >> routable to the correct load balancer.
> >>
> >> For second type of nodes, which are stateful and want to stay=20
> >> on the message path, a mechanism as described in the draft is=20
> >> usefull. There could be other solutions as well -which we=20
> >> discussed to some extent on the list-, and I would prefer them=20
> >> to be explained -somewhere-.
> >>
> >>    =20
> >>> Also, I think that source routing issue can/should be discussed=20
> >>> separately from the Application Identifier issue.
> >>>      =20
> >> [TOLGA]I see some correlation because using AppId=3D0 for common=20
> >> messages breaks routability of such messages for some=20
> >> configurations and the draft provides a solution for that.=20
> >> Otherwise, the draft is useful only for intermediares, which=20
> >> want to stay on the path during a session.
> >>    =20
> >>> Yoshihiro Ohba
> >>>
> >>>
> >>> On Wed, Aug 16, 2006 at 10:15:19PM +0200, Hannes Tschofenig wrote:
> >>>      =20
> >>>> Hi all,
> >>>>
> >>>> we discussed this document during the IETF#66 DIME working group=20
> >>>> meeting. The meeting participants did not express excitement. We=20
> >>>> would like to solicit feedback from the working group to=20
> >>>>        =20
> >> see whether=20
> >>    =20
> >>>> there is interest in this work and how we should proceed.
> >>>>
> >>>> Ciao
> >>>> Hannes & John
> >>>>
> >>>> _______________________________________________
> >>>> DiME mailing list
> >>>> DiME@ietf.org
> >>>> https://www1.ietf.org/mailman/listinfo/dime
> >>>>        =20
> >>> _______________________________________________
> >>> DiME mailing list
> >>> DiME@ietf.org
> >>> https://www1.ietf.org/mailman/listinfo/dime
> >>>      =20
> >> _______________________________________________
> >> DiME mailing list
> >> DiME@ietf.org
> >> https://www1.ietf.org/mailman/listinfo/dime
> >>
> >>    =20
> >
> > _______________________________________________
> > DiME mailing list
> > DiME@ietf.org
> > https://www1.ietf.org/mailman/listinfo/dime
> >
> >
> >
> >  =20
>=20
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www1.ietf.org/mailman/listinfo/dime
>=20

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



From dime-bounces@ietf.org Mon Aug 21 15:04:42 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GFF4e-00023V-6u; Mon, 21 Aug 2006 15:04:36 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GFF4c-00023Q-9O
	for dime@ietf.org; Mon, 21 Aug 2006 15:04:34 -0400
Received: from bws14.bridgewatersystems.com ([216.113.7.14]
	helo=exchange.bridgewatersys.com)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFCHC-00023m-3X
	for dime@ietf.org; Mon, 21 Aug 2006 12:05:22 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Dime] Mobile IPv6 Bootstrapping - "Application
	ID"vs."NAS-Port-Type AVP/Service-Type": Summary
Date: Mon, 21 Aug 2006 12:06:27 -0400
Message-ID: <E7CCE8A83907104ABEE91AC3AE3709A0070674B7@exchange.bridgewatersys.com>
In-Reply-To: <7CCD07160348804497EF29E9EA5560D7837217@exchtewks2.starentnetworks.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Dime] Mobile IPv6 Bootstrapping - "Application
	ID"vs."NAS-Port-Type AVP/Service-Type": Summary
Thread-Index: AcbEL57agT/n7nm3TmmkI0AGzDo4RAA/kEAwAAF00GA=
From: "Avi Lior" <avi@bridgewatersystems.com>
To: "Chowdhury, Kuntal" <kchowdhury@starentnetworks.com>,
	"Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 3cb75504e283d08ef0543f38ba481a75
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

Service-Type should not be used.

If you add a new value to the NAS-Port-Type then you need a new
Application-ID anyway.  You have to make sure that the packet reaches an
entity that can understands the new value.  Otherewise you could end up
delivering the packet to a legacy server that doesn't not understand the
MIPv6 application.

Once you have a new Application-ID you really don't need NAS-Port-Type
(as pointed out correctly by Julien).

I don't understand what the concern about modification of Diameter
Agents.

If you use Application Id then Relays wont have to change right?

Proxies would have to change if and only if they are going to be proxies
for that Application.  But that is the definition of a Proxy right?=20
=20

> -----Original Message-----
> From: Chowdhury, Kuntal [mailto:kchowdhury@starentnetworks.com]=20
> Sent: Monday, August 21, 2006 10:45 AM
> To: Hannes Tschofenig
> Cc: dime@ietf.org
> Subject: RE: [Dime] Mobile IPv6 Bootstrapping - "Application=20
> ID"vs."NAS-Port-Type AVP/Service-Type": Summary
>=20
>=20
>=20
> > -----Original Message-----
> > From: Hannes Tschofenig [mailto:Hannes.Tschofenig@gmx.net]
> > Sent: Sunday, August 20, 2006 3:07 AM
> > To: Chowdhury, Kuntal
> > Cc: Julien Bournelle; dime@ietf.org
> > Subject: Re: [Dime] Mobile IPv6 Bootstrapping - "Application ID"
> vs."NAS-
> > Port-Type AVP/Service-Type": Summary
> >=20
> > Hi Kuntal,
> >=20
> >=20
> > Chowdhury, Kuntal schrieb:
> > > Hi Hannes, Julien,
> > >
> > > Application-ID is one way, but as has been discussed so far it
> requires
> > > changes in the intermediaries.
> >=20
> > True.
> >=20
> >   A new value in NAS-Port-Type AVP seems
> > > more logical and easier to implement, IMHO.
> >=20
> > Easier to implement: True.
> >=20
> >   I am not sure about the
> > > Service-Type AVP. I am wondering what cannot be conveyed via=20
> > > NAS-Port-Type AVP so that we need this additional AVP?
> > >
> > > Apologize for jumping in late....still trying to understand the
> whole
> > > issue.
> > Please read my copy-and-paste summary of the discussion.
> >=20
> > In some sense we are discussing fundamentals of how to extend
> Diameter.
> > The application ID is used for routing. If we don't define a new
> app-ID
> > then we cannot route network access messages and MIP6 bootstrapping=20
> > messages differently. Some folks think that this is important.
> > What do you think?
> >=20
> [KC>] In case of split scenario, I see the use case where the=20
> AAA transaction for network access at the NAS is going to a=20
> different AAA server than the same at the HA, since ASA !=3D=20
> MSA in split. In case of integrated scenario, it is essential=20
> that the AAA transactions from the NAS and from the HA get=20
> routed to the same AAA server (ASA =3D=3D MSA). So we need to=20
> keep this in mind.
>=20
> >From the AAA message routing point of view, I thought the=20
> @realm part=20
> >of
> the username (NAI) was sufficient to route AAA messages to=20
> different AAA systems. There are other reasons for separate=20
> APP-ID for MIP6 bootstrapping, e.g. if we decide to mandate=20
> AVPs needed for MIP6 bootstrapping in DER/DEA (as an=20
> example). I don't know why we would do that i.e. mandate MIP6=20
> bootstrapping AVPs in DER/DEA.
>=20
>=20
> > Ciao
> > Hannes
> >=20
> > >
> > > -Kuntal
> > >
> > >
> > >> -----Original Message-----
> > >> From: Julien Bournelle [mailto:julien.bournelle@int-evry.fr]
> > >> Sent: Friday, August 18, 2006 11:54 AM
> > >> To: Hannes Tschofenig
> > >> Cc: dime@ietf.org
> > >> Subject: Re: [Dime] Mobile IPv6 Bootstrapping - "Application ID"
> > > vs."NAS-
> > >> Port-Type AVP/Service-Type": Summary
> > >>
> > >> Hi hannes,
> > >>
> > >>  thanks for this clarifying mail.
> > >>
> > >>
> > >> On Wed, Aug 16, 2006 at 10:51:07PM +0200, Hannes=20
> Tschofenig wrote:
> > >>> Hi all,
> > >>>
> > >>> I went through the discussion again and noticed that we haven't
> > > reached
> > >>> a conclusion.
> > >>>
> > >>> Here is my impression:
> > >>>
> > >>> * RFC 3588 leaves a question regarding the extensibility open.
> > >>>   This needs to be captured in the revision of the base
> > > specification.
> > >>> * The main issue seems to be
> > >>>
> > >>>   - Do we want to route 'Diameter EAP' message and 'Diameter
> Mobile
> > >>> IPv6 Bootstrapping' messages differently?
> > >>  I tend to think that it is safer to assume that some=20
> operators may =20
> > >> desire that.
> > >>
> > >>>     If we want to route them differently then we need to define=20
> > >>> 'Diameter MIPv6 Bootstrapping' as a Diameter application.
> > >>>
> > >>>   - The AAA server differentiates ordinary network access and
> MIPv6
> > >>> bootstrapping functionality (with respect to authorization and=20
> > >>> accounting). In order to do so it must understand the=20
> Service-Type=20
> > >>> and/or NAS-Port-Type AVPs and the defined values.
> > >>>
> > >>>     Is this a problem?
> > >>  Not sure to understand this problem. For me, if we have=20
> the App-Id
> we
> > >>  don't need Service-Type nor NAS-Port Type.
> > >>  IF we don't have the App-ID, yes we need to define new values.
> > >>
> > >>  Maybe i missed the problem you raised.
> > >>
> > >>  regards,
> > >>
> > >>  Julien
> > >>
> > >>>   - There are problems with proxies and newly defined Diameter=20
> > >>> Application IDs. Every proxy on the path needs new code=20
> to handle=20
> > >>> the new application,
> > > while
> > >>> just adding an extra AVP or new Service-Type value does=20
> not hurt.
> > >>>
> > >>>     Is this an issue for us?
> > >>>
> > >>> Ciao
> > >>> Hannes
> > >>>
> > >>> PS: Here is copy-and-paste version of some discussion=20
> snippets to
> > > allow
> > >>> others to catch-up.
> > >>>
> > >>> Julien starts the discussion with a question about Application
> IDs.
> > >>>
> > >>> Pasi suggests to consider Service-Type and/or NAS-Port-Type AVPs
> as
> > >>> well.... the problem starts.
> > >>>
> > >>> Avi states that the problem is that neither Service-Type or
> > > Port-Type is
> > >>> mandatory.
> > >>> "
> > >>> Service Type seems to be the correct way but in RADIUS and=20
> > >>> Diameter service-type also can be authenticate-only or
> > > authorize-only.
> > >>> So what if the HA wanted to authenticate-only or authorize-only
> for
> > > the
> > >>> MIP service?  I would lose the ability to also indicate=20
> that this
> is
> > > an
> > >>> HA.
> > >>>
> > >>> So Port-Type seems to be the way to go....
> > >>> "
> > >>>
> > >>> Jari jumps in:
> > >>> "
> > >>> One of the reasons why an existing application would be=20
> preferred=20
> > >>> is that then a AAA server that does not care about the type of=20
> > >>> service can be used without changes. Yet servers that=20
> do care can=20
> > >>> look at the AVPs and make more detailed authorization decisions.
> > >>>
> > >>>
> > >>> RFC 3588 states that  "Creation of a new application should be=20
> > >>> viewed as a last resort." and that "In order to justify=20
> allocation=20
> > >>> of a new application identifier, Diameter applications=20
> MUST define=20
> > >>> one Command Code, or add new mandatory AVPs to the ABNF." Note=20
> > >>> that mandatory AVPs can be viewed in different ways,=20
> and that we=20
> > >>> should not be too strict about them.
> > >>> For instance, Framed-Protocol is an optional AVP in=20
> RFCs 4005 and=20
> > >>> 4072. Yet, you could argue that if you are doing PPP=20
> then you need=20
> > >>> to use this attribute and set it to PPP. But that=20
> didn't make the=20
> > >>> attribute mandatory.
> > >>> Do we have a similar situation for the IKEv2/MIPv6=20
> attributes and=20
> > >>> values? They are not necessary from the NASREQ/EAP perspective,=20
> > >>> but in the specific context you need to use the=20
> attributes. In my=20
> > >>> mind, this does not make the attributes mandatory from=20
> a Diameter=20
> > >>> application point of view. If we start creating new=20
> applications=20
> > >>> for every different situation, we'll have lots of=20
> applications and=20
> > >>> interoperability problems. Its better to add new=20
> optional AVPs and=20
> > >>> describe in text when they should be used. The only=20
> exception that=20
> > >>> I see is security related AVPs that must be understood by the=20
> > >>> other side or else the session should be terminated.
> > >>> "
> > >>>
> > >>> Avi responds:
> > >>> "
> > >>> Mandatory does not mean required in the Command.  It=20
> means that it
> > > must
> > >>> be understood by the receiver.  We need to clarify that.
> > >>> "
> > >>>
> > >>> Gerardo and Lionel agree with Jari.
> > >>>
> > >>>
> > >>>
> > >>> Avi writes:
> > >>> "
> > >>> If I have two EAP based application in my network, one that is=20
> > >>> handling pure EAP application, the other is extended to=20
> handle the
> > > new
> > >>> behavior then I need a way to route the (same) command=20
> correctly.
> > >>> "
> > >>>
> > >>> Jari writes:
> > >>> "
> > >>> Ah, but that is a new requirement. If you believe that=20
> you need to=20
> > >>> route EAP authentication from a 802.11 AP differently than from=20
> > >>> IKEv2/MIPv6, then you need one of these:
> > >>>
> > >>> - Use different user/domain names for the users of
> > >>>   the different services.
> > >>>
> > >>> - Point to different servers from the AP and SGW (but
> > >>>   this works less well if you have proxies and roaming).
> > >>>
> > >>> - New application ID.
> > >>>
> > >>> - Some weird form of Diameter and RADIUS source routing
> > >>>   based on what type of node sent the message.
> > >>>
> > >>> However, it is far from clear to me why you would=20
> really need to=20
> > >>> route the authentication differently *for the same user*. Many=20
> > >>> authentication mechanisms can also have state, which=20
> would imply=20
> > >>> that at the end they need to end up in the same device=20
> anyhow. Can=20
> > >>> you expand on why you need to handle the same users in=20
> different=20
> > >>> authentication servers?
> > >>> "
> > >>>
> > >>> Avi to Jari:
> > >>>
> > >>> "
> > >>> BTW in the context of the original question raised, the
> attribute(s)
> > >>> will not be optional. Here is the snippet:
> > >>>
> > >>>>>>>  In our case, the AAA server must perform AAA functionality
> > > for
> > >> the
> > >>>>>>> Mobile IPv6 service. The AAA server must know that=20
> it has to=20
> > >>>>>>> authorize the mip6 service and the accounting (ASR/ASA) is
> > > also
> > >> for
> > >>>>>>>  mip6 and not for network access.
> > >>> If the Diameter message comes from the HA then the HA=20
> MUST include
> > > the
> > >>> NAS-Port-type attribute. So the command ABNF is being changed.
> Also
> > > the
> > >>> behavior is being changed of the Server.  It MUST recognize the
> > > (new)
> > >>> value of the NAS-Port-Type.
> > >>> "
> > >>>
> > >>>
> > >>> Yoshi says:
> > >>> "
> > >>> If what is important is service-specific routing (I am not
> convinced
> > >>> with it yet), I'd suggest defining a new authorization-only=20
> > >>> application used only for carrying service-specific attributes=20
> > >>> (analogous to NASREQ usage in RFC 4072).  The downside=20
> is that it=20
> > >>> needs another message roundtrip than carrying the attributes in=20
> > >>> DER/DEA.
> > >>> "
> > >>>
> > >>>
> > >>> Julien wrote:
> > >>> "
> > >>>>> I don't think it's clean to require use of different=20
> > >>>>> users'identifiers in order to distinguish which services is=20
> > >>>>> provided. For me, it looks like a 'hack'.
> > >>> " and Pasi responded:
> > >>> "
> > >>> I fully agree -- but having separate user identifiers should not
> be
> > >>> necessary. If, for example, an operator wants to=20
> perform different=20
> > >>> authorizations for WiFi and WiMAX (e.g., some users can access
> only
> > >>> WiFi but not WiMAX), that's simple to do: just check=20
> Service-Type,=20
> > >>> NAS-Port-Type, and other relevant authorization AVPs.  There's=20
> > >>> absolutely no need to create a new Diameter application.
> > >>>
> > >>> If the AAA server is really strict about WiFi vs. WiMAX
> separation,
> > > it
> > >>> can have a policy that requires the NAS-Port-Type AVP to be
> present
> > >>> (if the request does not contain it, access is denied). Although
> > > this
> > >>> in some sense make NAS-Port-Type AVP "mandatory", it's not
> > > "mandatory"
> > >>> in the sense that would require a new Diameter application.
> > >>>
> > >>> While IKEv2 and MIP6 are not WiFi and WiMAX, I don't think there
> are
> > >>> any significant differences from Diameter=20
> point-of-view. There's a
> > > box
> > >>> providing some service; authentication works with EAP;
> authorization
> > >>> AVPs indicate what exactly is being authorized. What's=20
> missing is=20
> > >>> a document describing how the different authorization AVPs are=20
> > >>> used in this particular situation; sort of like RFC 3580 (IEEE
> > > 802.1X
> > >>> RADIUS Usage Guidelines), but for Diameter with IKEv2.
> > >>>
> > >>> One important reason NOT to create new applications: proxies.
> Every
> > >>> proxy on the path needs new code to handle the new application,
> > > while
> > >>> just adding an extra AVP or new Service-Type value doesn't.
> > >>> "
> > >>>
> > >>> John agrees with Pasi.
> > >>>
> > >>> Avi writes:
> > >>> "
> > >>> A mandatory attribute (a must understand attribute)=20
> that has a new=20
> > >>> enumeration is in my mind is like adding a new=20
> attribute that must
> > > be
> > >>> understood.  There is no wigle room here.  The command carrying
> that
> > >>> attribute must reach the implementation that knows how to
> interpret
> > > the
> > >>> attribute.  This is  because an implmentation that does not
> > > understand
> > >>> Service-Type =3D X must return an error.
> > >>>
> > >>> It is obvious that the rules in 3588 are not sufficient to
> describe
> > > when
> > >>> to use a new Application ID or not.  And we should not have to
> have
> > > a
> > >>> debate on this topic.
> > >>>
> > >>> BTW if we do what you say then in networks where I have NASREQ=20
> > >>> performing Network Access and now I want to roll out=20
> MIPv6 I would
> > > have
> > >>> to upgrade all my old NASREQ deployed applications.  This is
> wrong.
> > > I
> > >>> should be able to add a MIPv6 compliant diameter application
> without
> > >>> having to force upgrading my NASREQ applications.
> > >>> "
> > >>>
> > >>>
> > >>> _______________________________________________
> > >>> DiME mailing list
> > >>> DiME@ietf.org
> > >>> https://www1.ietf.org/mailman/listinfo/dime
> > >> --
> > >> julien.bournelle at int-evry.fr
> > >>
> > >> _______________________________________________
> > >> DiME mailing list
> > >> DiME@ietf.org
> > >> https://www1.ietf.org/mailman/listinfo/dime
> > >
> > >
> > > "This email message and any attachments are confidential=20
> information
> of
> > Starent Networks, Corp. The information transmitted may not=20
> be used to=20
> > create or change any contractual obligations of Starent Networks,
> Corp.
> > Any review, retransmission, dissemination or other use of, or taking
> of
> > any action in reliance upon this e-mail and its attachments=20
> by persons
> or
> > entities other than the intended recipient is prohibited. If you are
> not
> > the intended recipient, please notify the sender immediately -- by=20
> > replying to this message or by sending an email to=20
> > postmaster@starentnetworks.com -- and destroy all copies of this
> message
> > and any attachments without reading or disclosing their contents.
> Thank
> > you."
> > >
> > >
>=20
>=20
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www1.ietf.org/mailman/listinfo/dime
>=20

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



From dime-bounces@ietf.org Mon Aug 21 16:32:15 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GFGRP-000052-0B; Mon, 21 Aug 2006 16:32:11 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GFGRN-00004x-UR
	for dime@ietf.org; Mon, 21 Aug 2006 16:32:09 -0400
Received: from sj-iport-4.cisco.com ([171.68.10.86])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFGRL-0001Vc-Iu
	for dime@ietf.org; Mon, 21 Aug 2006 16:32:09 -0400
Received: from sj-dkim-7.cisco.com ([171.68.10.88])
	by sj-iport-4.cisco.com with ESMTP; 21 Aug 2006 13:32:07 -0700
X-IronPort-AV: i="4.08,152,1154934000"; 
	d="scan'208"; a="1849389153:sNHT33545368"
Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137])
	by sj-dkim-7.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id
	k7LKW6fw006673; Mon, 21 Aug 2006 13:32:06 -0700
Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com
	[128.107.191.100])
	by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id k7LKW4w9025236;
	Mon, 21 Aug 2006 13:32:06 -0700 (PDT)
Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by
	xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211);
	Mon, 21 Aug 2006 13:32:04 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: criteria for new app ID [was: Re: [Dime] Mobile IPv6
	Bootstrapping- "Application	ID"vs."NAS-Port-Type
	AVP/Service-Type": Summary]
Date: Mon, 21 Aug 2006 13:32:03 -0700
Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB26250279DE14@xmb-sjc-215.amer.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: criteria for new app ID [was: Re: [Dime] Mobile IPv6
	Bootstrapping- "Application	ID"vs."NAS-Port-Type
	AVP/Service-Type": Summary]
Thread-Index: AcbFUyNUMJvafXnzTFC+PyR5BU+70wADLERQ
From: "Glen Zorn \(gwz\)" <gwz@cisco.com>
To: "Anders Kristensen" <andersk@cisco.com>
X-OriginalArrivalTime: 21 Aug 2006 20:32:04.0993 (UTC)
	FILETIME=[DD79FF10:01C6C560]
DKIM-Signature: a=rsa-sha1; q=dns; l=2072; t=1156192326; x=1157056326;
	c=relaxed/simple; s=sjdkim7002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=gwz@cisco.com;
	z=From:=22Glen=20Zorn=20\(gwz\)=22=20<gwz@cisco.com>
	|Subject:RE=3A=20criteria=20for=20new=20app=20ID=20[was=3A=20Re=3A=20[Dime]=20Mob
	ile=20IPv6=20Bootstrapping-=20=22Application=09ID=22vs.=22NAS-Port-Type=20A
	VP/Service-Type=22=3A=20Summary];
	X=v=3Dcisco.com=3B=20h=3DSQJKSOch1sjJo9MaEWn3Vbvh7LI=3D;
	b=Bt+Ji1j5u9PLK7PxEPtSxR+wr4uRC6o6q0FM44FIPDHeSoyC17M1j3rRR7T4JzEIqBpWD7HB
	uw3clxvM0AM1u6bJ6dZWkvLG5ErL+JJqLc5wLEt0sYeWlRq6ripFRX6j;
Authentication-Results: sj-dkim-7.cisco.com; header.From=gwz@cisco.com;
	dkim=pass ( sig from cisco.com verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

Anders Kristensen <mailto:andersk@cisco.com> supposedly scribbled:

...

>> Just to stir the pot a bit .. I agree with you, we are discussing how
>> have a Diameter extension and how it fits into the existing
>> deployment. If using MIPv6 with Diameter creates new manditory
>> attributes and/or changes the basic state machine, I assume a new
>> application ID should be used.
>=20
> I think there are other conditions under which a separate app ID is
> in order, e.g. if mandatory AVPs have been removed from the
> definition of messages or, more importantly, if the semantics of the
> new app are "sufficiently different" from those of the original
> application.   =20
>=20
> Regarding the latter case consider, for example, the definition of
> AA-Request in RFC 4005. The AAR definition lists pretty much all AVPs
> as being optional meaning one can reuse AAR to do basically anything.
>=20
> 3GPP's Gq spec defines its own version of the AA-Request which reuses
> *none* of the 4005 specific AVPs but includes a bunch of its own
> AVPs, also all optional. Gq was given its own app ID which I think
> was appropriate because although nominally they're reusing AAR and
> some other messages, effectively it's a very different application.
> This is even though a Gq AAR is, technically speaking, a valid 4005
> AAR, also - except for the app ID, that is.    =20
>=20
> (I see now that 4005's AAR has a mandatory Auth-Request-Type AVP and
> Gq's AAR does not but that doesn't really change the point.)=20

Actually, it completely invalidates your example: Gq was _required_ to =
use a different app ID _because_ it had a different set of mandatory =
AVPs.  Note that 1) modifying the set of mandatory AVPs  is enough to =
require the usage of a different app ID & 2) if you change the set of =
values allowed in a mandatory AVP, you have modified the set of =
mandatory AVPs.

...

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by simply
  listening to John Coltrane? -- Henry Gabriel

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



From dime-bounces@ietf.org Mon Aug 21 16:34:45 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GFGTt-0001Kv-2H; Mon, 21 Aug 2006 16:34:45 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GFGTs-0001Kq-5L
	for dime@ietf.org; Mon, 21 Aug 2006 16:34:44 -0400
Received: from sj-iport-6.cisco.com ([171.71.176.117])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFGTp-00026R-S2
	for dime@ietf.org; Mon, 21 Aug 2006 16:34:44 -0400
Received: from sj-dkim-2.cisco.com ([171.71.179.186])
	by sj-iport-6.cisco.com with ESMTP; 21 Aug 2006 13:34:41 -0700
Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238])
	by sj-dkim-2.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id
	k7LKYfNd025911; Mon, 21 Aug 2006 13:34:41 -0700
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com
	[171.70.151.144])
	by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id k7LKYc1G004814;
	Mon, 21 Aug 2006 13:34:41 -0700 (PDT)
Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by
	xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 21 Aug 2006 13:34:38 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: AW: [Dime] Next Steps for draft-tsou-dime-base-routing-ext-00
Date: Mon, 21 Aug 2006 13:34:37 -0700
Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB26250279DE1F@xmb-sjc-215.amer.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: AW: [Dime] Next Steps for draft-tsou-dime-base-routing-ext-00
Thread-Index: AcbFPuZTpWtBUxkMRVar+2/h06kilAAIi6ww
From: "Glen Zorn \(gwz\)" <gwz@cisco.com>
To: "Victor Fajardo" <vfajardo@tari.toshiba.com>,
	"Tschofenig, Hannes" <hannes.tschofenig@siemens.com>
X-OriginalArrivalTime: 21 Aug 2006 20:34:38.0810 (UTC)
	FILETIME=[39289BA0:01C6C561]
DKIM-Signature: a=rsa-sha1; q=dns; l=731; t=1156192481; x=1157056481;
	c=relaxed/simple; s=sjdkim2002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=gwz@cisco.com;
	z=From:=22Glen=20Zorn=20\(gwz\)=22=20<gwz@cisco.com>
	|Subject:RE=3A=20AW=3A=20[Dime]=20Next=20Steps=20for=20draft-tsou-dime-base-routi
	ng-ext-00;
	X=v=3Dcisco.com=3B=20h=3DEJ4dl54lI1WniPaT7WHaSiZDXJo=3D;
	b=Kc8S95+jvTEdpC7YXO+K3SxtFGgYFUtBhfQ8I4jcLKvjHbr8zVyEDmhi8yFR4dvGERYC0w9r
	cXcQGcbAvbvIrjeNzun0k13X6VjO+eN7HCb956JtE4b9za13SQgegxoX;
Authentication-Results: sj-dkim-2.cisco.com; header.From=gwz@cisco.com;
	dkim=pass ( sig from cisco.com verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

Victor Fajardo <mailto:vfajardo@tari.toshiba.com> supposedly scribbled:

> Hi Hannes,
>> Hi Victor,
>>=20
>> in the discussions the 3GPP WLAN work was mentioned as the usage
>> scenario.=20
>> Is it a real problem in their environment? I have never heard
>> something about problems along these lines.=20
>>=20
>=20
>  From what I understood, it is a problem envisioned by some folks
> when trying to deploy diameter in such environment. I think Tina and
> others can shed light into this better than I can. =20

I, for one, would _really_ like to hear this.

...

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by simply
  listening to John Coltrane? -- Henry Gabriel

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



From dime-bounces@ietf.org Mon Aug 21 16:39:37 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GFGYb-0003Za-PT; Mon, 21 Aug 2006 16:39:37 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GFGYa-0003ZV-FY
	for dime@ietf.org; Mon, 21 Aug 2006 16:39:36 -0400
Received: from sj-iport-6.cisco.com ([171.71.176.117])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFGYY-0003YQ-5W
	for dime@ietf.org; Mon, 21 Aug 2006 16:39:36 -0400
Received: from sj-dkim-4.cisco.com ([171.71.179.196])
	by sj-iport-6.cisco.com with ESMTP; 21 Aug 2006 13:39:33 -0700
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254])
	by sj-dkim-4.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id
	k7LKdX3v000307; Mon, 21 Aug 2006 13:39:33 -0700
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com
	[128.107.191.63])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k7LKdTZ1027900;
	Mon, 21 Aug 2006 13:39:33 -0700 (PDT)
Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by
	xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 21 Aug 2006 13:39:29 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Dime] Mobile IPv6 Bootstrapping -
	"ApplicationID"vs."NAS-Port-Type AVP/Service-Type": Summary
Date: Mon, 21 Aug 2006 13:39:28 -0700
Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB26250279DE2A@xmb-sjc-215.amer.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Dime] Mobile IPv6 Bootstrapping -
	"ApplicationID"vs."NAS-Port-Type AVP/Service-Type": Summary
Thread-Index: AcbEL57agT/n7nm3TmmkI0AGzDo4RAA/kEAwAAF00GAAC3UtoA==
From: "Glen Zorn \(gwz\)" <gwz@cisco.com>
To: "Avi Lior" <avi@bridgewatersystems.com>,
	"Chowdhury, Kuntal" <kchowdhury@starentnetworks.com>,
	"Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>
X-OriginalArrivalTime: 21 Aug 2006 20:39:29.0401 (UTC)
	FILETIME=[E65D4690:01C6C561]
DKIM-Signature: a=rsa-sha1; q=dns; l=1116; t=1156192773; x=1157056773;
	c=relaxed/simple; s=sjdkim4002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=gwz@cisco.com;
	z=From:=22Glen=20Zorn=20\(gwz\)=22=20<gwz@cisco.com>
	|Subject:RE=3A=20[Dime]=20Mobile=20IPv6=20Bootstrapping=20-=20=22ApplicationID=22
	vs.=22NAS-Port-Type=20AVP/Service-Type=22=3A=20Summary;
	X=v=3Dcisco.com=3B=20h=3DE9db+oNjsE2hoXJ9/HEKT8kkV/0=3D;
	b=rUiZYxhgGaTcwNjRPF8hHMWmH+/q8cgbDK/lWy1wvFhboEW89qVuy2JKfBDSlW2ZhruzG6Ev
	1PgSrwqWqrq/CphZGnOGhRfk9fzSzoagSo+gQq54NlyXZykbCBSgaHDx;
Authentication-Results: sj-dkim-4.cisco.com; header.From=gwz@cisco.com;
	dkim=pass ( sig from cisco.com verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

Avi Lior <mailto:avi@bridgewatersystems.com> supposedly scribbled:

> Service-Type should not be used.

Agree.

>=20
> If you add a new value to the NAS-Port-Type then you need a new
> Application-ID anyway.  You have to make sure that the packet reaches
> an entity that can understands the new value.  Otherewise you could
> end up delivering the packet to a legacy server that doesn't not
> understand the MIPv6 application.=20

Right.
 =20
>=20
> Once you have a new Application-ID you really don't need
> NAS-Port-Type (as pointed out correctly by Julien).=20

Right.

>=20
> I don't understand what the concern about modification of Diameter
> Agents.=20

Me, neither.

>=20
> If you use Application Id then Relays wont have to change right?
>=20
> Proxies would have to change if and only if they are going to be
> proxies for that Application.  But that is the definition of a Proxy
> right?=20

Right & right!=20
=20
...

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by simply
  listening to John Coltrane? -- Henry Gabriel

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



From dime-bounces@ietf.org Mon Aug 21 17:14:35 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GFH6Q-0008I6-R0; Mon, 21 Aug 2006 17:14:34 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GFH6P-0008I1-T9
	for dime@ietf.org; Mon, 21 Aug 2006 17:14:33 -0400
Received: from rtp-iport-1.cisco.com ([64.102.122.148])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFH6O-0004Ob-L6
	for dime@ietf.org; Mon, 21 Aug 2006 17:14:33 -0400
Received: from rtp-dkim-1.cisco.com ([64.102.121.158])
	by rtp-iport-1.cisco.com with ESMTP; 21 Aug 2006 14:14:32 -0700
X-BrightmailFiltered: true
X-Brightmail-Tracker: AAAAAA==
X-IronPort-AV: i="4.08,153,1154934000"; 
	d="scan'208"; a="37288199:sNHT23974664"
Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12])
	by rtp-dkim-1.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id
	k7LLEVck014385; Mon, 21 Aug 2006 17:14:31 -0400
Received: from [10.86.240.60] (che-vpn-cluster-1-60.cisco.com [10.86.240.60])
	by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id
	k7LLEUdM008476; Mon, 21 Aug 2006 17:14:31 -0400 (EDT)
Message-ID: <44EA2236.3070306@cisco.com>
Date: Mon, 21 Aug 2006 17:14:30 -0400
From: Anders Kristensen <andersk@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
	rv:1.7.12) Gecko/20050915
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Glen Zorn (gwz)" <gwz@cisco.com>
Subject: Re: criteria for new app ID [was: Re: [Dime] Mobile IPv6
	Bootstrapping-
	"Application	ID"vs."NAS-Port-Type AVP/Service-Type": Summary]
References: <4C0FAAC489C8B74F96BEAD85EAEB26250279DE14@xmb-sjc-215.amer.cisco.com>
In-Reply-To: <4C0FAAC489C8B74F96BEAD85EAEB26250279DE14@xmb-sjc-215.amer.cisco.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1; q=dns; l=2331; t=1156194871; x=1157058871;
	c=relaxed/simple; s=rtpdkim1001;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=andersk@cisco.com;
	z=From:Anders=20Kristensen=20<andersk@cisco.com>
	|Subject:Re=3A=20criteria=20for=20new=20app=20ID=20[was=3A=20Re=3A=20[Dime]=20Mob
	ile=20IPv6=20Bootstrapping-=0A=20=22Application=09ID=22vs.=22NAS-Port-Type=
	20AVP/Service-Type=22=3A=20Summary]
	|To:=22Glen=20Zorn=20(gwz)=22=20<gwz@cisco.com>;
	X=v=3Dcisco.com=3B=20h=3Dx/wNoxw/KMoVQ9JOqLDxwIbgAkQ=3D;
	b=SL9Sjp6Xq6QhiNnmqobZBOgD8+xQFg33TPTFiwAHnHhwkYVA5DfZIUoYJVOJgL0Jd607jnZH
	hh1dJAwByqmpjhJlFGuFKW0HoJo/hjnCWv8ziva9CNrB5bGOoaurFYEM;
Authentication-Results: rtp-dkim-1.cisco.com; header.From=andersk@cisco.com;
	dkim=pass ( sig from cisco.com verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org



Glen Zorn (gwz) wrote:

> Anders Kristensen <mailto:andersk@cisco.com> supposedly scribbled:
> 
> ...
> 
> 
>>>Just to stir the pot a bit .. I agree with you, we are discussing how
>>>have a Diameter extension and how it fits into the existing
>>>deployment. If using MIPv6 with Diameter creates new manditory
>>>attributes and/or changes the basic state machine, I assume a new
>>>application ID should be used.
>>
>>I think there are other conditions under which a separate app ID is
>>in order, e.g. if mandatory AVPs have been removed from the
>>definition of messages or, more importantly, if the semantics of the
>>new app are "sufficiently different" from those of the original
>>application.    
>>
>>Regarding the latter case consider, for example, the definition of
>>AA-Request in RFC 4005. The AAR definition lists pretty much all AVPs
>>as being optional meaning one can reuse AAR to do basically anything.
>>
>>3GPP's Gq spec defines its own version of the AA-Request which reuses
>>*none* of the 4005 specific AVPs but includes a bunch of its own
>>AVPs, also all optional. Gq was given its own app ID which I think
>>was appropriate because although nominally they're reusing AAR and
>>some other messages, effectively it's a very different application.
>>This is even though a Gq AAR is, technically speaking, a valid 4005
>>AAR, also - except for the app ID, that is.     
>>
>>(I see now that 4005's AAR has a mandatory Auth-Request-Type AVP and
>>Gq's AAR does not but that doesn't really change the point.) 
> 
> 
> Actually, it completely invalidates your example: Gq was _required_ to use a different app ID _because_ it had a different set of mandatory AVPs.  Note that 1) modifying the set of mandatory AVPs  is enough to require the usage of a different app ID & 2) if you change the set of values allowed in a mandatory AVP, you have modified the set of mandatory AVPs.
> 

Well, suppose Gq's AAR did include that AVP. The question is whether 
we'd want Gq to define its own app ID in that case. I think we would 
because it seems semantically quite different from NASREQ.

Anders

> ...
> 
> Hope this helps,
> 
> ~gwz
> 
> Why is it that most of the world's problems can't be solved by simply
>   listening to John Coltrane? -- Henry Gabriel
> 

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



From dime-bounces@ietf.org Mon Aug 21 17:59:11 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GFHnb-0006Y6-CG; Mon, 21 Aug 2006 17:59:11 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GFHnZ-0006Uk-QA
	for dime@ietf.org; Mon, 21 Aug 2006 17:59:09 -0400
Received: from bw.ulticom.com ([208.255.120.38])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFHnY-0001RO-BP
	for dime@ietf.org; Mon, 21 Aug 2006 17:59:09 -0400
Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP
	id 56DC6E1C05; Mon, 21 Aug 2006 17:59:03 -0400 (EDT)
Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55])
	by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k7LLx2Dt000524;
	Mon, 21 Aug 2006 17:59:03 -0400 (EDT)
From: "Tolga Asveren" <asveren@ulticom.com>
To: "Yoshihiro Ohba" <yohba@tari.toshiba.com>
Subject: RE: [Dime] Next Steps for draft-tsou-dime-base-routing-ext-00
Date: Mon, 21 Aug 2006 17:34:25 -0400
Message-ID: <GBEBKGPKHGPAOFCLBNAMMELNEHAA.asveren@ulticom.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
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: <20060821144846.GE21216@steelhead>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506
Importance: Normal
Received-SPF: none
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

Hi Yoshihiro,

> -----Original Message-----
> From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com]
> Sent: Monday, August 21, 2006 10:49 AM
> To: Tolga Asveren
> Cc: Yoshihiro Ohba; dime@ietf.org
> Subject: Re: [Dime] Next Steps for draft-tsou-dime-base-routing-ext-00
>
>
> Hi Tolga,
>
> On Fri, Aug 18, 2006 at 12:15:53PM -0400, Tolga Asveren wrote:
> > Hi Yoshihiro,
> >
> >
> > > -----Original Message-----
> > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com]
> > > Sent: Thursday, August 17, 2006 11:48 AM
> > > To: Hannes Tschofenig
> > > Cc: dime@ietf.org
> > > Subject: Re: [Dime] Next Steps for draft-tsou-dime-base-routing-ext-00
> > >
> > >
> > > I think the content of draft-tsou-dime-base-routing-ext-00 should be
> > > integrated into rfc3588bis, because I think source routing is needed
> > > to support stateful agents and thus should be part of base protocol.
> > [TOLGA]I think we should distinguish between intermediaries,
> which advertise
> > support for individual applications instead of 0xffffffff but
> are not really
> > stateful and which are really stateful. Currently being stateful and
> > advertising specific application support is tied together in RFC3588 by
> > definition of a proxy but I don't think it needs to be.
> Acctually not doing
> > so is not violation of the protocol, just defining a new node
> type, which is
> > not explicitly mentioned in RFC3588.
>
>
> What description in RFC 3588 ties being stateful and advertising
> specific application support by definition of a proxy?
>
> In fact, statefulness is not a requirement for a proxy.
>
> So I don't understand what problem is solved with defining a new node
> type.
[TOLGA]I didn't propose to define something new but it is my bad to assume
proxies are by definition stateful.
>
> >
> > An example for the first one is a load-balancer for a specific
> application.
> > It is interested to get only messages for a specific
> application but doesn't
> > keep session related state. If a message does not have
> Destination-Host AVP,
> > it forwards the message to a server based on congestion status
> of servers
> > (how this information is propogated is topic for another thread). If a
> > message has Destination-Host AVP, it just sends the message to
> that server.
> >
> > For that first type of intermediaries, everything would be
> working fine if
> > AppId!=0 is used for common messages. Otherwise, a relay agent
> in front of
> > load balancers serving different applications is enough to have common
> > messages not routable to the correct load balancer.
>
> This first case does not require a stateful agent, so I agree with you
> that it may not be appropriate to discuss
> draft-tsou-dime-base-routing-ext-00 to address the first case.
>
> >
> > For second type of nodes, which are stateful and want to stay
> on the message
> > path, a mechanism as described in the draft is usefull. There
> could be other
> > solutions as well -which we discussed to some extent on the list-, and I
> > would prefer them to be explained -somewhere-.
>
> Source routing is needed at least to support stateful agents that is
> defined in RFC 3588 but actually is not completely supported by RFC
> 3588.  For completeness of the base specification, I'd suggest
> defining source routing in the document that defines stateful agent,
> but I am also ok with defining it in a separate document if the
> document is referred from RFC3588bis.
[TOLGA]IMHO, source routing is only one of the possible solutions to this
problem, which may be more attractive than the other ones for certain
configurations. Overall, I also think that it should be a WG-item.
>
> >
> > >
> > > Also, I think that source routing issue can/should be discussed
> > > separately from the Application Identifier issue.
> > [TOLGA]I see some correlation because using AppId=0 for common messages
> > breaks routability of such messages for some configurations and
> the draft
> > provides a solution for that. Otherwise, the draft is useful only for
> > intermediares, which want to stay on the path during a session.
>
> I'd think that the draft is useful only for stateful agents.
[TOLGA]AFAICS, your statement is true only if AppId!=0 is used for common
messages. Consider the following scenario, where all intermediaries are
stateless:

                    +---------+
                    |Load     +------- Servers
                +---+Balancer +------- for App1
 +-------+      |   |for App1 +-------
 | Relay +------+   +---------+
 | Agent +------+
 +-------+      |   +---------+
                |   |Load     +------- Servers
                +---+Balancer +------- for App2
                    |for App2 +-------
                    +---------+

Load balancers are stateless but advertise support for only App1 and App2
respectively. The first message of a session will have the AppId for either
App1 or App2 and so could be routed to the correct load balancer. OTOH, and
mid-session common message would have App-Id=0, and relay agent won't have
enough information to select the right load balancer, unless it knows the
identities of each server and which load balancer can be used to reach that
server (If that were true, it could route by making use of Destination-Host
AVP). Requring such a configuration is quite a restriction. The mechanism in
the draft would allow the load balancers to insert themselves in the session
path. This IMHO is not an ideal solution for this problem, but if we are
stuck with AppId=0 for common messages, it is better than nothing.
>
> Regards,
> Yoshihiro Ohba
>
>
>
> > >
> > > Yoshihiro Ohba
> > >
> > >
> > > On Wed, Aug 16, 2006 at 10:15:19PM +0200, Hannes Tschofenig wrote:
> > > > Hi all,
> > > >
> > > > we discussed this document during the IETF#66 DIME working group
> > > > meeting. The meeting participants did not express
> excitement. We would
> > > > like to solicit feedback from the working group to see
> whether there is
> > > > interest in this work and how we should proceed.
> > > >
> > > > Ciao
> > > > Hannes & John
> > > >
> > > > _______________________________________________
> > > > DiME mailing list
> > > > DiME@ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/dime
> > >
> > > _______________________________________________
> > > DiME mailing list
> > > DiME@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/dime
> >


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



From dime-bounces@ietf.org Mon Aug 21 20:47:01 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GFKQ1-0001LF-Ip; Mon, 21 Aug 2006 20:47:01 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GFKQ0-0001Kz-KX
	for dime@ietf.org; Mon, 21 Aug 2006 20:47:00 -0400
Received: from sj-iport-2-in.cisco.com ([171.71.176.71]
	helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43)
	id 1GFKPz-0007Ig-BR
	for dime@ietf.org; Mon, 21 Aug 2006 20:47:00 -0400
Received: from sj-dkim-3.cisco.com ([171.71.179.195])
	by sj-iport-2.cisco.com with ESMTP; 21 Aug 2006 17:46:58 -0700
X-IronPort-AV: i="4.08,153,1154934000"; 
	d="scan'208"; a="337347753:sNHT30722940"
Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254])
	by sj-dkim-3.cisco.com (8.12.11.20060308/8.12.11) with ESMTP id
	k7M0kwtx027301; Mon, 21 Aug 2006 17:46:58 -0700
Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com
	[171.70.151.144])
	by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id k7M0kwYp026611;
	Mon, 21 Aug 2006 17:46:58 -0700 (PDT)
Received: from xmb-sjc-215.amer.cisco.com ([171.70.151.169]) by
	xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Mon, 21 Aug 2006 17:46:58 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: criteria for new app ID [was: Re: [Dime] Mobile IPv6
	Bootstrapping- "Application	ID"vs."NAS-Port-Type
	AVP/Service-Type": Summary]
Date: Mon, 21 Aug 2006 17:46:54 -0700
Message-ID: <4C0FAAC489C8B74F96BEAD85EAEB26250279DFA2@xmb-sjc-215.amer.cisco.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: criteria for new app ID [was: Re: [Dime] Mobile IPv6
	Bootstrapping- "Application	ID"vs."NAS-Port-Type
	AVP/Service-Type": Summary]
Thread-Index: AcbFZswIZYAn91GUT9SsjLelXIyJrgAHW8rA
From: "Glen Zorn \(gwz\)" <gwz@cisco.com>
To: "Anders Kristensen" <andersk@cisco.com>
X-OriginalArrivalTime: 22 Aug 2006 00:46:58.0301 (UTC)
	FILETIME=[78FF9AD0:01C6C584]
DKIM-Signature: a=rsa-sha1; q=dns; l=535; t=1156207618; x=1157071618;
	c=relaxed/simple; s=sjdkim3002;
	h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version;
	d=cisco.com; i=gwz@cisco.com;
	z=From:=22Glen=20Zorn=20\(gwz\)=22=20<gwz@cisco.com>
	|Subject:RE=3A=20criteria=20for=20new=20app=20ID=20[was=3A=20Re=3A=20[Dime]=20Mob
	ile=20IPv6=20Bootstrapping-=20=22Application=09ID=22vs.=22NAS-Port-Type=20A
	VP/Service-Type=22=3A=20Summary];
	X=v=3Dcisco.com=3B=20h=3DSQJKSOch1sjJo9MaEWn3Vbvh7LI=3D;
	b=rnysP7ncKcch6sDTA7ZAd3tIx3K9c6rLDSfrLfAfgj0hCThzRHxK4GvsOfutL4qFp7UoNPOa
	rlveiMHpxZ9OZnY4bBc8jNZ6VP+MG++4j36QzqLrH9UGxb9YUN5OaHF9;
Authentication-Results: sj-dkim-3.cisco.com; header.From=gwz@cisco.com;
	dkim=pass ( sig from cisco.com verified; ); 
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d6b246023072368de71562c0ab503126
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

Anders Kristensen <mailto:andersk@cisco.com> supposedly scribbled:

...

>=20
> Well, suppose Gq's AAR did include that AVP. The question is whether
> we'd want Gq to define its own app ID in that case. I think we would
> because it seems semantically quite different from NASREQ. =20
>=20

It might be nice (from a human POV), but I don't think that we could =
require it.

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by simply
  listening to John Coltrane? -- Henry Gabriel

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



From dime-bounces@ietf.org Tue Aug 22 03:21:37 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GFQZp-00067U-IZ; Tue, 22 Aug 2006 03:21:33 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GFQZo-00067P-LO
	for dime@ietf.org; Tue, 22 Aug 2006 03:21:32 -0400
Received: from ug-out-1314.google.com ([66.249.92.173])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFQZn-0004U0-BB
	for dime@ietf.org; Tue, 22 Aug 2006 03:21:32 -0400
Received: by ug-out-1314.google.com with SMTP id m2so1959452uge
	for <dime@ietf.org>; Tue, 22 Aug 2006 00:21:30 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com;
	h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
	b=du7FvglwhS6zAyObp6eEofT/Tj7V1E02AEp2gt1jRdX6vMq6lXoZqHH2uIyCPzKLaHZOrkErJwDeuuuJdq9MjW4ZU6lN4LTyQMsR07mq0eCnAwVKpzk/hi2eTDvSeWMbHpZr+T1qjlEunnc0l5+0Zr3fK/UauRD0PxKmbCRfuk0=
Received: by 10.66.240.12 with SMTP id n12mr4176608ugh;
	Tue, 22 Aug 2006 00:21:30 -0700 (PDT)
Received: by 10.66.243.16 with HTTP; Tue, 22 Aug 2006 00:21:30 -0700 (PDT)
Message-ID: <eaa74a7e0608220021j47fcd46fu6702ba431cd7ae14@mail.gmail.com>
Date: Tue, 22 Aug 2006 09:21:30 +0200
From: "Gerardo Giaretta" <gerardo.giaretta@gmail.com>
To: "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>
Subject: Re: [Dime] ASA == MSA: Is it the same Server?
In-Reply-To: <44E9F9C9.3050904@gmx.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <7CCD07160348804497EF29E9EA5560D7837217@exchtewks2.starentnetworks.com>
	<44E9F9C9.3050904@gmx.net>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

Hi Kuntal and Hannes,

> > [KC>] In case of split scenario, I see the use case where the AAA
> > transaction for network access at the NAS is going to a different AAA
> > server than the same at the HA, since ASA != MSA in split.
>
> In this case the identities are different though. You cannot use the
> same identity to hit two different domains.
> Hence, there is no problem as such.
>
>   In case of
> > integrated scenario, it is essential that the AAA transactions from the
> > NAS and from the HA get routed to the same AAA server (ASA == MSA). So
> > we need to keep this in mind.
>
> Here is the question whether they are indeed the same server. Some folks
> they argue that it is not the same one
>

Some background: the integrated scenario was defined during the
bootstrapping DT discussion because some proposed solutions were
applicable only in the case the entity that authenticates the user for
network access is the same entity that authenticate the user for
mobility service. In my view, the initial assumption was that the same
AAA server authenticates the user for both services, since during the
authentication for network access some MIP6 related information are
sent to the NAS.

However, in a AAA stateless architecture, it would be possible to have
also different AAA servers; I guess in this case the solution for
integrated scenario would still work: the first AAA server (that
authenticates the user for network access) sends the MIP6-related
information to the NAS, and the second AAA server (that authenticates
the user for mobility service) just terminates the EAP exchange
carried on IKEv2 between MN and HA.

Therefore, I think the servers may be different, but the AAA
infrastructure/business entity is the same. Am I missing something?

> >>From the AAA message routing point of view, I thought the @realm part of
> > the username (NAI) was sufficient to route AAA messages to different AAA
> > systems.
>
> IMHO, for the ASA != MSA scenario it is.
>

agree for the split scenario.

--Gerardo

> Ciao
> Hannes
>
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www1.ietf.org/mailman/listinfo/dime
>

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



From dime-bounces@ietf.org Tue Aug 22 05:31:22 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GFSbO-0001wi-Gs; Tue, 22 Aug 2006 05:31:18 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GFSbN-0001wI-3r
	for dime@ietf.org; Tue, 22 Aug 2006 05:31:17 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129]
	helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFRBn-0001na-Me
	for dime@ietf.org; Tue, 22 Aug 2006 04:00:47 -0400
Received: from sehan002bb.han.telia.se ([131.115.18.153])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GFR4e-0008H6-Ma
	for dime@ietf.org; Tue, 22 Aug 2006 03:53:27 -0400
Received: from SEHAN021MB.tcad.telia.se ([131.115.18.160]) by
	sehan002bb.han.telia.se with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 22 Aug 2006 09:53:14 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Dime] Mobile IPv6 Bootstrapping - "Application ID"
	vs."NAS-Port-TypeAVP/Service-Type": Summary
Date: Tue, 22 Aug 2006 09:53:15 +0200
Message-ID: <5D25AEFB114D034FBDC8B156FCA78E03F1E6DE@SEHAN021MB.tcad.telia.se>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Dime] Mobile IPv6 Bootstrapping - "Application ID"
	vs."NAS-Port-TypeAVP/Service-Type": Summary
thread-index: AcbFBUMFtp8TZQ+9QXe1s9y6Es/L+gAt+Hxg
From: <jouni.korhonen@teliasonera.com>
To: <Hannes.Tschofenig@gmx.net>
X-OriginalArrivalTime: 22 Aug 2006 07:53:14.0573 (UTC)
	FILETIME=[05A4FFD0:01C6C5C0]
X-Spam-Score: -2.3 (--)
X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

Hannes,

> Hi Jouni,
>=20
> ~snip~
>=20
> > For an operator being able to separate normal access and=20
> MIP service is
> > a desirable feature. However, imho that also falls to=20
> general operator
> > subscription policies. I.e. whether the operator wants to=20
> allow access
> > with and without specific service (such as MIP) or not. In the
> > integrated
> > scenario the MN cannot assume that all access networks support
> > bootstrapping
> > anyway so the AAA server needs to be prepared for both cases.
>=20
> So, what is the conclusion. Do we need to have mandatory attributes?

Currently the draft does not define any mandatory avp. And I tend to
think for now that there is no compelling need to have any (as I think
the AAA must have a possibility to hinder sending bootstrapping avps
even if it knows that the NAS supports it and still let the access
auth to succeed).

cheers,
	Jouni

>=20
> Ciao
> Hannes
>=20
> >=20
> > Cheers,
> > 	Jouni
>=20

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



From dime-bounces@ietf.org Tue Aug 22 08:04:31 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GFUzZ-0006QT-Jd; Tue, 22 Aug 2006 08:04:25 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GFUzY-0006QN-MR
	for dime@ietf.org; Tue, 22 Aug 2006 08:04:24 -0400
Received: from inet-tsb.toshiba.co.jp ([202.33.96.40])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFUzT-0003eb-1G
	for dime@ietf.org; Tue, 22 Aug 2006 08:04:24 -0400
Received: from tsb-wall.toshiba.co.jp ([133.199.160.134])
	by inet-tsb.toshiba.co.jp  with ESMTP id k7MC424x002872;
	Tue, 22 Aug 2006 21:04:02 +0900 (JST)
Received: (from root@localhost) by tsb-wall.toshiba.co.jp  id k7MC43xR004638;
	Tue, 22 Aug 2006 21:04:03 +0900 (JST)
Received: from ovp11.toshiba.co.jp [133.199.90.148] 
	by tsb-wall.toshiba.co.jp with SMTP id XAA04633;
	Tue, 22 Aug 2006 21:04:03 +0900
Received: from mx2.toshiba.co.jp (localhost [127.0.0.1])
	by ovp11.toshiba.co.jp  with ESMTP id k7MC41PG026731;
	Tue, 22 Aug 2006 21:04:01 +0900 (JST)
Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k7MC41GN004002;
	Tue, 22 Aug 2006 21:04:01 +0900 (JST)
Received: from steelhead ([172.30.24.47])
	by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built
	Apr 28
	2004)) with ESMTPSA id <0J4E005KHEUIQLM0@mail.po.toshiba.co.jp>; Tue,
	22 Aug 2006 21:04:01 +0900 (JST)
Received: from ohba by steelhead with local (Exim 4.62)
	(envelope-from <yohba@tari.toshiba.com>)	id 1GFUyu-0007RI-LM; Tue,
	22 Aug 2006 05:03:44 -0700
Date: Tue, 22 Aug 2006 08:03:44 -0400
From: Yoshihiro Ohba <yohba@tari.toshiba.com>
Subject: Re: [Dime] Next Steps for draft-tsou-dime-base-routing-ext-00
In-reply-to: <GBEBKGPKHGPAOFCLBNAMMELNEHAA.asveren@ulticom.com>
To: Tolga Asveren <asveren@ulticom.com>
Message-id: <20060822120344.GA28318@steelhead>
MIME-version: 1.0
Content-type: text/plain; charset=iso-2022-jp
Content-disposition: inline
References: <20060821144846.GE21216@steelhead>
	<GBEBKGPKHGPAOFCLBNAMMELNEHAA.asveren@ulticom.com>
User-Agent: Mutt/1.5.11+cvs20060403
X-Spam-Score: 0.0 (/)
X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

Hi Tolga,

In your example below, all messages (i.e., the first and subsequent
messages) for a session need to be routed to the same server where a
server is chosen by a load balancer when routing the first message.
In this case I think hop-by-hop routing based on Destination-Host AVP
is sufficient and source routing is not needed.

Yoshihiro Ohba


On Mon, Aug 21, 2006 at 05:34:25PM -0400, Tolga Asveren wrote:

(snip)

> >
> > I'd think that the draft is useful only for stateful agents.
> [TOLGA]AFAICS, your statement is true only if AppId!=0 is used for common
> messages. Consider the following scenario, where all intermediaries are
> stateless:
> 
>                     +---------+
>                     |Load     +------- Servers
>                 +---+Balancer +------- for App1
>  +-------+      |   |for App1 +-------
>  | Relay +------+   +---------+
>  | Agent +------+
>  +-------+      |   +---------+
>                 |   |Load     +------- Servers
>                 +---+Balancer +------- for App2
>                     |for App2 +-------
>                     +---------+
> 
> Load balancers are stateless but advertise support for only App1 and App2
> respectively. The first message of a session will have the AppId for either
> App1 or App2 and so could be routed to the correct load balancer. OTOH, and
> mid-session common message would have App-Id=0, and relay agent won't have
> enough information to select the right load balancer, unless it knows the
> identities of each server and which load balancer can be used to reach that
> server (If that were true, it could route by making use of Destination-Host
> AVP). Requring such a configuration is quite a restriction. The mechanism in
> the draft would allow the load balancers to insert themselves in the session
> path. This IMHO is not an ideal solution for this problem, but if we are
> stuck with AppId=0 for common messages, it is better than nothing.
> >
> > Regards,
> > Yoshihiro Ohba
> >
> >
> >
> > > >
> > > > Yoshihiro Ohba
> > > >
> > > >
> > > > On Wed, Aug 16, 2006 at 10:15:19PM +0200, Hannes Tschofenig wrote:
> > > > > Hi all,
> > > > >
> > > > > we discussed this document during the IETF#66 DIME working group
> > > > > meeting. The meeting participants did not express
> > excitement. We would
> > > > > like to solicit feedback from the working group to see
> > whether there is
> > > > > interest in this work and how we should proceed.
> > > > >
> > > > > Ciao
> > > > > Hannes & John
> > > > >
> > > > > _______________________________________________
> > > > > DiME mailing list
> > > > > DiME@ietf.org
> > > > > https://www1.ietf.org/mailman/listinfo/dime
> > > >
> > > > _______________________________________________
> > > > DiME mailing list
> > > > DiME@ietf.org
> > > > https://www1.ietf.org/mailman/listinfo/dime
> > >
> 
> 

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



From dime-bounces@ietf.org Tue Aug 22 08:36:22 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GFVUT-0007Bu-Ot; Tue, 22 Aug 2006 08:36:21 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GFVUS-0007Bo-UW
	for dime@ietf.org; Tue, 22 Aug 2006 08:36:20 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129]
	helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFVUS-0002nH-SE
	for dime@ietf.org; Tue, 22 Aug 2006 08:36:20 -0400
Received: from bw.ulticom.com ([208.255.120.38])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GFVJh-0005qz-Af
	for dime@ietf.org; Tue, 22 Aug 2006 08:25:15 -0400
Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP
	id 730678586F; Tue, 22 Aug 2006 08:25:12 -0400 (EDT)
Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55])
	by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k7MCPC2H004547;
	Tue, 22 Aug 2006 08:25:12 -0400 (EDT)
From: "Tolga Asveren" <asveren@ulticom.com>
To: "Yoshihiro Ohba" <yohba@tari.toshiba.com>
Subject: RE: [Dime] Next Steps for draft-tsou-dime-base-routing-ext-00
Date: Tue, 22 Aug 2006 08:00:30 -0400
Message-ID: <GBEBKGPKHGPAOFCLBNAMIEMEEHAA.asveren@ulticom.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
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: <20060822120344.GA28318@steelhead>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506
Importance: Normal
Received-SPF: none
X-Spam-Score: -2.4 (--)
X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

Hi Yoshihiro,

> -----Original Message-----
> From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com]
> Sent: Tuesday, August 22, 2006 8:04 AM
> To: Tolga Asveren
> Cc: Yoshihiro Ohba; dime@ietf.org
> Subject: Re: [Dime] Next Steps for draft-tsou-dime-base-routing-ext-00
>
>
> Hi Tolga,
>
> In your example below, all messages (i.e., the first and subsequent
> messages) for a session need to be routed to the same server where a
> server is chosen by a load balancer when routing the first message.
> In this case I think hop-by-hop routing based on Destination-Host AVP
> is sufficient and source routing is not needed.
[TOLGA]The problem is not between load balancers and the servers, it is
between relay agent and the load balancers. AFAICS, if the relay agent is
unaware of the identities of the servers and their mapping to different load
balancers, it can't route mid-session common messages to the correct load
balancer efficiently.
>
> Yoshihiro Ohba
>
>
> On Mon, Aug 21, 2006 at 05:34:25PM -0400, Tolga Asveren wrote:
>
> (snip)
>
> > >
> > > I'd think that the draft is useful only for stateful agents.
> > [TOLGA]AFAICS, your statement is true only if AppId!=0 is used
> for common
> > messages. Consider the following scenario, where all intermediaries are
> > stateless:
> >
> >                     +---------+
> >                     |Load     +------- Servers
> >                 +---+Balancer +------- for App1
> >  +-------+      |   |for App1 +-------
> >  | Relay +------+   +---------+
> >  | Agent +------+
> >  +-------+      |   +---------+
> >                 |   |Load     +------- Servers
> >                 +---+Balancer +------- for App2
> >                     |for App2 +-------
> >                     +---------+
> >
> > Load balancers are stateless but advertise support for only
> App1 and App2
> > respectively. The first message of a session will have the
> AppId for either
> > App1 or App2 and so could be routed to the correct load
> balancer. OTOH, and
> > mid-session common message would have App-Id=0, and relay agent
> won't have
> > enough information to select the right load balancer, unless it
> knows the
> > identities of each server and which load balancer can be used
> to reach that
> > server (If that were true, it could route by making use of
> Destination-Host
> > AVP). Requring such a configuration is quite a restriction. The
> mechanism in
> > the draft would allow the load balancers to insert themselves
> in the session
> > path. This IMHO is not an ideal solution for this problem, but if we are
> > stuck with AppId=0 for common messages, it is better than nothing.
> > >
> > > Regards,
> > > Yoshihiro Ohba
> > >
> > >
> > >
> > > > >
> > > > > Yoshihiro Ohba
> > > > >
> > > > >
> > > > > On Wed, Aug 16, 2006 at 10:15:19PM +0200, Hannes Tschofenig wrote:
> > > > > > Hi all,
> > > > > >
> > > > > > we discussed this document during the IETF#66 DIME working group
> > > > > > meeting. The meeting participants did not express
> > > excitement. We would
> > > > > > like to solicit feedback from the working group to see
> > > whether there is
> > > > > > interest in this work and how we should proceed.
> > > > > >
> > > > > > Ciao
> > > > > > Hannes & John
> > > > > >
> > > > > > _______________________________________________
> > > > > > DiME mailing list
> > > > > > DiME@ietf.org
> > > > > > https://www1.ietf.org/mailman/listinfo/dime
> > > > >
> > > > > _______________________________________________
> > > > > DiME mailing list
> > > > > DiME@ietf.org
> > > > > https://www1.ietf.org/mailman/listinfo/dime
> > > >
> >
> >


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



From dime-bounces@ietf.org Tue Aug 22 11:22:41 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GFY5R-00012s-DM; Tue, 22 Aug 2006 11:22:41 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GFY5Q-00012d-CU
	for dime@ietf.org; Tue, 22 Aug 2006 11:22:40 -0400
Received: from imx11.toshiba.co.jp ([61.202.160.20])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFY5O-0004HX-6M
	for dime@ietf.org; Tue, 22 Aug 2006 11:22:39 -0400
Received: from wall11.toshiba.co.jp (wall11 [133.199.90.149])
	by imx11.toshiba.co.jp  with ESMTP id k7MFMPWL013765;
	Wed, 23 Aug 2006 00:22:25 +0900 (JST)
Received: (from root@localhost) by wall11.toshiba.co.jp  id k7MFMPPJ003518;
	Wed, 23 Aug 2006 00:22:25 +0900 (JST)
Received: from ovp11.toshiba.co.jp [133.199.90.148] 
	by wall11.toshiba.co.jp with SMTP id AAA03458;
	Wed, 23 Aug 2006 00:22:25 +0900
Received: from mx2.toshiba.co.jp (localhost [127.0.0.1])
	by ovp11.toshiba.co.jp  with ESMTP id k7MFMOge024388;
	Wed, 23 Aug 2006 00:22:24 +0900 (JST)
Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k7MFMOng008495;
	Wed, 23 Aug 2006 00:22:24 +0900 (JST)
Received: from steelhead ([172.30.24.47])
	by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built
	Apr 28
	2004)) with ESMTPSA id <0J4E008IXO17MI00@mail.po.toshiba.co.jp>; Wed,
	23 Aug 2006 00:22:24 +0900 (JST)
Received: from ohba by steelhead with local (Exim 4.62)
	(envelope-from <yohba@tari.toshiba.com>)	id 1GFY4l-00082O-6h; Tue,
	22 Aug 2006 08:21:59 -0700
Date: Tue, 22 Aug 2006 11:21:59 -0400
From: Yoshihiro Ohba <yohba@tari.toshiba.com>
Subject: Re: [Dime] Next Steps for draft-tsou-dime-base-routing-ext-00
In-reply-to: <GBEBKGPKHGPAOFCLBNAMIEMEEHAA.asveren@ulticom.com>
To: Tolga Asveren <asveren@ulticom.com>
Message-id: <20060822152159.GE28318@steelhead>
MIME-version: 1.0
Content-type: text/plain; charset=iso-2022-jp
Content-disposition: inline
References: <20060822120344.GA28318@steelhead>
	<GBEBKGPKHGPAOFCLBNAMIEMEEHAA.asveren@ulticom.com>
User-Agent: Mutt/1.5.11+cvs20060403
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

Hi Tolga,

Relay agent is aware of the server's identitity based on
Destination-Host AVP which is supposed to exist in all mid-session
common messages.  Am I missing something?

Yoshihiro Ohba

On Tue, Aug 22, 2006 at 08:00:30AM -0400, Tolga Asveren wrote:
> Hi Yoshihiro,
> 
> > -----Original Message-----
> > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com]
> > Sent: Tuesday, August 22, 2006 8:04 AM
> > To: Tolga Asveren
> > Cc: Yoshihiro Ohba; dime@ietf.org
> > Subject: Re: [Dime] Next Steps for draft-tsou-dime-base-routing-ext-00
> >
> >
> > Hi Tolga,
> >
> > In your example below, all messages (i.e., the first and subsequent
> > messages) for a session need to be routed to the same server where a
> > server is chosen by a load balancer when routing the first message.
> > In this case I think hop-by-hop routing based on Destination-Host AVP
> > is sufficient and source routing is not needed.
> [TOLGA]The problem is not between load balancers and the servers, it is
> between relay agent and the load balancers. AFAICS, if the relay agent is
> unaware of the identities of the servers and their mapping to different load
> balancers, it can't route mid-session common messages to the correct load
> balancer efficiently.
> >
> > Yoshihiro Ohba
> >
> >
> > On Mon, Aug 21, 2006 at 05:34:25PM -0400, Tolga Asveren wrote:
> >
> > (snip)
> >
> > > >
> > > > I'd think that the draft is useful only for stateful agents.
> > > [TOLGA]AFAICS, your statement is true only if AppId!=0 is used
> > for common
> > > messages. Consider the following scenario, where all intermediaries are
> > > stateless:
> > >
> > >                     +---------+
> > >                     |Load     +------- Servers
> > >                 +---+Balancer +------- for App1
> > >  +-------+      |   |for App1 +-------
> > >  | Relay +------+   +---------+
> > >  | Agent +------+
> > >  +-------+      |   +---------+
> > >                 |   |Load     +------- Servers
> > >                 +---+Balancer +------- for App2
> > >                     |for App2 +-------
> > >                     +---------+
> > >
> > > Load balancers are stateless but advertise support for only
> > App1 and App2
> > > respectively. The first message of a session will have the
> > AppId for either
> > > App1 or App2 and so could be routed to the correct load
> > balancer. OTOH, and
> > > mid-session common message would have App-Id=0, and relay agent
> > won't have
> > > enough information to select the right load balancer, unless it
> > knows the
> > > identities of each server and which load balancer can be used
> > to reach that
> > > server (If that were true, it could route by making use of
> > Destination-Host
> > > AVP). Requring such a configuration is quite a restriction. The
> > mechanism in
> > > the draft would allow the load balancers to insert themselves
> > in the session
> > > path. This IMHO is not an ideal solution for this problem, but if we are
> > > stuck with AppId=0 for common messages, it is better than nothing.
> > > >
> > > > Regards,
> > > > Yoshihiro Ohba
> > > >
> > > >
> > > >
> > > > > >
> > > > > > Yoshihiro Ohba
> > > > > >
> > > > > >
> > > > > > On Wed, Aug 16, 2006 at 10:15:19PM +0200, Hannes Tschofenig wrote:
> > > > > > > Hi all,
> > > > > > >
> > > > > > > we discussed this document during the IETF#66 DIME working group
> > > > > > > meeting. The meeting participants did not express
> > > > excitement. We would
> > > > > > > like to solicit feedback from the working group to see
> > > > whether there is
> > > > > > > interest in this work and how we should proceed.
> > > > > > >
> > > > > > > Ciao
> > > > > > > Hannes & John
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > DiME mailing list
> > > > > > > DiME@ietf.org
> > > > > > > https://www1.ietf.org/mailman/listinfo/dime
> > > > > >
> > > > > > _______________________________________________
> > > > > > DiME mailing list
> > > > > > DiME@ietf.org
> > > > > > https://www1.ietf.org/mailman/listinfo/dime
> > > > >
> > >
> > >
> 
> 

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



From dime-bounces@ietf.org Tue Aug 22 11:32:41 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GFYF3-0004UP-02; Tue, 22 Aug 2006 11:32:37 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GFYF1-0004UK-Ny
	for dime@ietf.org; Tue, 22 Aug 2006 11:32:35 -0400
Received: from bw.ulticom.com ([208.255.120.38])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFYF0-0005ti-8n
	for dime@ietf.org; Tue, 22 Aug 2006 11:32:35 -0400
Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP
	id 3D45D0493C; Tue, 22 Aug 2006 11:32:29 -0400 (EDT)
Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55])
	by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k7MFWTsE023158;
	Tue, 22 Aug 2006 11:32:29 -0400 (EDT)
From: "Tolga Asveren" <asveren@ulticom.com>
To: "Yoshihiro Ohba" <yohba@tari.toshiba.com>
Subject: RE: [Dime] Next Steps for draft-tsou-dime-base-routing-ext-00
Date: Tue, 22 Aug 2006 11:07:46 -0400
Message-ID: <GBEBKGPKHGPAOFCLBNAMMEMKEHAA.asveren@ulticom.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
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: <20060822152159.GE28318@steelhead>
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506
Importance: Normal
Received-SPF: none
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 87a3f533bb300b99e2a18357f3c1563d
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

Hi Yoshihiro,

Yes, you are right that Relay Agent can access Destination-Host AVP in the
message. OTOH, unless it knows which load balancer needs to be used to reach
a specific server, there will be a problem with routing for mid-session
common messages (which wouldn't be a problem if common messages used
AppId!=0, because then we could have relied on AppId in the message header
for routing). IMHO, requiring relay agents to configure that type of
information is a big and non-elegant restriction.

    Thanks,
    Tolga

> -----Original Message-----
> From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com]
> Sent: Tuesday, August 22, 2006 11:22 AM
> To: Tolga Asveren
> Cc: Yoshihiro Ohba; dime@ietf.org
> Subject: Re: [Dime] Next Steps for draft-tsou-dime-base-routing-ext-00
>
>
> Hi Tolga,
>
> Relay agent is aware of the server's identitity based on
> Destination-Host AVP which is supposed to exist in all mid-session
> common messages.  Am I missing something?
>
> Yoshihiro Ohba
>
> On Tue, Aug 22, 2006 at 08:00:30AM -0400, Tolga Asveren wrote:
> > Hi Yoshihiro,
> >
> > > -----Original Message-----
> > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com]
> > > Sent: Tuesday, August 22, 2006 8:04 AM
> > > To: Tolga Asveren
> > > Cc: Yoshihiro Ohba; dime@ietf.org
> > > Subject: Re: [Dime] Next Steps for draft-tsou-dime-base-routing-ext-00
> > >
> > >
> > > Hi Tolga,
> > >
> > > In your example below, all messages (i.e., the first and subsequent
> > > messages) for a session need to be routed to the same server where a
> > > server is chosen by a load balancer when routing the first message.
> > > In this case I think hop-by-hop routing based on Destination-Host AVP
> > > is sufficient and source routing is not needed.
> > [TOLGA]The problem is not between load balancers and the servers, it is
> > between relay agent and the load balancers. AFAICS, if the
> relay agent is
> > unaware of the identities of the servers and their mapping to
> different load
> > balancers, it can't route mid-session common messages to the
> correct load
> > balancer efficiently.
> > >
> > > Yoshihiro Ohba
> > >
> > >
> > > On Mon, Aug 21, 2006 at 05:34:25PM -0400, Tolga Asveren wrote:
> > >
> > > (snip)
> > >
> > > > >
> > > > > I'd think that the draft is useful only for stateful agents.
> > > > [TOLGA]AFAICS, your statement is true only if AppId!=0 is used
> > > for common
> > > > messages. Consider the following scenario, where all
> intermediaries are
> > > > stateless:
> > > >
> > > >                     +---------+
> > > >                     |Load     +------- Servers
> > > >                 +---+Balancer +------- for App1
> > > >  +-------+      |   |for App1 +-------
> > > >  | Relay +------+   +---------+
> > > >  | Agent +------+
> > > >  +-------+      |   +---------+
> > > >                 |   |Load     +------- Servers
> > > >                 +---+Balancer +------- for App2
> > > >                     |for App2 +-------
> > > >                     +---------+
> > > >
> > > > Load balancers are stateless but advertise support for only
> > > App1 and App2
> > > > respectively. The first message of a session will have the
> > > AppId for either
> > > > App1 or App2 and so could be routed to the correct load
> > > balancer. OTOH, and
> > > > mid-session common message would have App-Id=0, and relay agent
> > > won't have
> > > > enough information to select the right load balancer, unless it
> > > knows the
> > > > identities of each server and which load balancer can be used
> > > to reach that
> > > > server (If that were true, it could route by making use of
> > > Destination-Host
> > > > AVP). Requring such a configuration is quite a restriction. The
> > > mechanism in
> > > > the draft would allow the load balancers to insert themselves
> > > in the session
> > > > path. This IMHO is not an ideal solution for this problem,
> but if we are
> > > > stuck with AppId=0 for common messages, it is better than nothing.
> > > > >
> > > > > Regards,
> > > > > Yoshihiro Ohba
> > > > >
> > > > >
> > > > >
> > > > > > >
> > > > > > > Yoshihiro Ohba
> > > > > > >
> > > > > > >
> > > > > > > On Wed, Aug 16, 2006 at 10:15:19PM +0200, Hannes
> Tschofenig wrote:
> > > > > > > > Hi all,
> > > > > > > >
> > > > > > > > we discussed this document during the IETF#66 DIME
> working group
> > > > > > > > meeting. The meeting participants did not express
> > > > > excitement. We would
> > > > > > > > like to solicit feedback from the working group to see
> > > > > whether there is
> > > > > > > > interest in this work and how we should proceed.
> > > > > > > >
> > > > > > > > Ciao
> > > > > > > > Hannes & John
> > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > DiME mailing list
> > > > > > > > DiME@ietf.org
> > > > > > > > https://www1.ietf.org/mailman/listinfo/dime
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > DiME mailing list
> > > > > > > DiME@ietf.org
> > > > > > > https://www1.ietf.org/mailman/listinfo/dime
> > > > > >
> > > >
> > > >
> >
> >


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



From dime-bounces@ietf.org Tue Aug 22 12:12:37 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GFYrl-0001ql-59; Tue, 22 Aug 2006 12:12:37 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GFYrj-0001pI-MG
	for dime@ietf.org; Tue, 22 Aug 2006 12:12:35 -0400
Received: from inet-tsb.toshiba.co.jp ([202.33.96.40])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFYcs-00018y-2l
	for dime@ietf.org; Tue, 22 Aug 2006 11:57:15 -0400
Received: from tsb-wall.toshiba.co.jp ([133.199.160.134])
	by inet-tsb.toshiba.co.jp  with ESMTP id k7MFvCwi017425;
	Wed, 23 Aug 2006 00:57:12 +0900 (JST)
Received: (from root@localhost) by tsb-wall.toshiba.co.jp  id k7MFvDdJ027419;
	Wed, 23 Aug 2006 00:57:13 +0900 (JST)
Received: from ovp1.toshiba.co.jp [133.199.192.124] 
	by tsb-wall.toshiba.co.jp with SMTP id AAA27387;
	Wed, 23 Aug 2006 00:57:13 +0900
Received: from mx.toshiba.co.jp (localhost [127.0.0.1])
	by ovp1.toshiba.co.jp  with ESMTP id k7MFvBWA002399;
	Wed, 23 Aug 2006 00:57:11 +0900 (JST)
Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k7MFvBVu017069;
	Wed, 23 Aug 2006 00:57:11 +0900 (JST)
Received: from steelhead ([172.30.24.47])
	by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built
	Apr 28
	2004)) with ESMTPSA id <0J4E008PTPN6MI00@mail.po.toshiba.co.jp>; Wed,
	23 Aug 2006 00:57:11 +0900 (JST)
Received: from ohba by steelhead with local (Exim 4.62)
	(envelope-from <yohba@tari.toshiba.com>)	id 1GFYcU-00089x-8A; Tue,
	22 Aug 2006 08:56:50 -0700
Date: Tue, 22 Aug 2006 11:56:50 -0400
From: Yoshihiro Ohba <yohba@tari.toshiba.com>
Subject: Re: [Dime] Next Steps for draft-tsou-dime-base-routing-ext-00
In-reply-to: <GBEBKGPKHGPAOFCLBNAMMEMKEHAA.asveren@ulticom.com>
To: Tolga Asveren <asveren@ulticom.com>
Message-id: <20060822155650.GI28318@steelhead>
MIME-version: 1.0
Content-type: text/plain; charset=iso-2022-jp
Content-disposition: inline
References: <20060822152159.GE28318@steelhead>
	<GBEBKGPKHGPAOFCLBNAMMEMKEHAA.asveren@ulticom.com>
User-Agent: Mutt/1.5.11+cvs20060403
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 3971661e40967acfc35f708dd5f33760
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

Hi Tolga,

OK, now I clearly understand your scenario.

Thank you,
Yoshihiro Ohba


On Tue, Aug 22, 2006 at 11:07:46AM -0400, Tolga Asveren wrote:
> Hi Yoshihiro,
> 
> Yes, you are right that Relay Agent can access Destination-Host AVP in the
> message. OTOH, unless it knows which load balancer needs to be used to reach
> a specific server, there will be a problem with routing for mid-session
> common messages (which wouldn't be a problem if common messages used
> AppId!=0, because then we could have relied on AppId in the message header
> for routing). IMHO, requiring relay agents to configure that type of
> information is a big and non-elegant restriction.
> 
>     Thanks,
>     Tolga
> 
> > -----Original Message-----
> > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com]
> > Sent: Tuesday, August 22, 2006 11:22 AM
> > To: Tolga Asveren
> > Cc: Yoshihiro Ohba; dime@ietf.org
> > Subject: Re: [Dime] Next Steps for draft-tsou-dime-base-routing-ext-00
> >
> >
> > Hi Tolga,
> >
> > Relay agent is aware of the server's identitity based on
> > Destination-Host AVP which is supposed to exist in all mid-session
> > common messages.  Am I missing something?
> >
> > Yoshihiro Ohba
> >
> > On Tue, Aug 22, 2006 at 08:00:30AM -0400, Tolga Asveren wrote:
> > > Hi Yoshihiro,
> > >
> > > > -----Original Message-----
> > > > From: Yoshihiro Ohba [mailto:yohba@tari.toshiba.com]
> > > > Sent: Tuesday, August 22, 2006 8:04 AM
> > > > To: Tolga Asveren
> > > > Cc: Yoshihiro Ohba; dime@ietf.org
> > > > Subject: Re: [Dime] Next Steps for draft-tsou-dime-base-routing-ext-00
> > > >
> > > >
> > > > Hi Tolga,
> > > >
> > > > In your example below, all messages (i.e., the first and subsequent
> > > > messages) for a session need to be routed to the same server where a
> > > > server is chosen by a load balancer when routing the first message.
> > > > In this case I think hop-by-hop routing based on Destination-Host AVP
> > > > is sufficient and source routing is not needed.
> > > [TOLGA]The problem is not between load balancers and the servers, it is
> > > between relay agent and the load balancers. AFAICS, if the
> > relay agent is
> > > unaware of the identities of the servers and their mapping to
> > different load
> > > balancers, it can't route mid-session common messages to the
> > correct load
> > > balancer efficiently.
> > > >
> > > > Yoshihiro Ohba
> > > >
> > > >
> > > > On Mon, Aug 21, 2006 at 05:34:25PM -0400, Tolga Asveren wrote:
> > > >
> > > > (snip)
> > > >
> > > > > >
> > > > > > I'd think that the draft is useful only for stateful agents.
> > > > > [TOLGA]AFAICS, your statement is true only if AppId!=0 is used
> > > > for common
> > > > > messages. Consider the following scenario, where all
> > intermediaries are
> > > > > stateless:
> > > > >
> > > > >                     +---------+
> > > > >                     |Load     +------- Servers
> > > > >                 +---+Balancer +------- for App1
> > > > >  +-------+      |   |for App1 +-------
> > > > >  | Relay +------+   +---------+
> > > > >  | Agent +------+
> > > > >  +-------+      |   +---------+
> > > > >                 |   |Load     +------- Servers
> > > > >                 +---+Balancer +------- for App2
> > > > >                     |for App2 +-------
> > > > >                     +---------+
> > > > >
> > > > > Load balancers are stateless but advertise support for only
> > > > App1 and App2
> > > > > respectively. The first message of a session will have the
> > > > AppId for either
> > > > > App1 or App2 and so could be routed to the correct load
> > > > balancer. OTOH, and
> > > > > mid-session common message would have App-Id=0, and relay agent
> > > > won't have
> > > > > enough information to select the right load balancer, unless it
> > > > knows the
> > > > > identities of each server and which load balancer can be used
> > > > to reach that
> > > > > server (If that were true, it could route by making use of
> > > > Destination-Host
> > > > > AVP). Requring such a configuration is quite a restriction. The
> > > > mechanism in
> > > > > the draft would allow the load balancers to insert themselves
> > > > in the session
> > > > > path. This IMHO is not an ideal solution for this problem,
> > but if we are
> > > > > stuck with AppId=0 for common messages, it is better than nothing.
> > > > > >
> > > > > > Regards,
> > > > > > Yoshihiro Ohba
> > > > > >
> > > > > >
> > > > > >
> > > > > > > >
> > > > > > > > Yoshihiro Ohba
> > > > > > > >
> > > > > > > >
> > > > > > > > On Wed, Aug 16, 2006 at 10:15:19PM +0200, Hannes
> > Tschofenig wrote:
> > > > > > > > > Hi all,
> > > > > > > > >
> > > > > > > > > we discussed this document during the IETF#66 DIME
> > working group
> > > > > > > > > meeting. The meeting participants did not express
> > > > > > excitement. We would
> > > > > > > > > like to solicit feedback from the working group to see
> > > > > > whether there is
> > > > > > > > > interest in this work and how we should proceed.
> > > > > > > > >
> > > > > > > > > Ciao
> > > > > > > > > Hannes & John
> > > > > > > > >
> > > > > > > > > _______________________________________________
> > > > > > > > > DiME mailing list
> > > > > > > > > DiME@ietf.org
> > > > > > > > > https://www1.ietf.org/mailman/listinfo/dime
> > > > > > > >
> > > > > > > > _______________________________________________
> > > > > > > > DiME mailing list
> > > > > > > > DiME@ietf.org
> > > > > > > > https://www1.ietf.org/mailman/listinfo/dime
> > > > > > >
> > > > >
> > > > >
> > >
> > >
> 
> 

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



From dime-bounces@ietf.org Tue Aug 22 14:16:54 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GFanl-0003vk-Oa; Tue, 22 Aug 2006 14:16:37 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GFanl-0003vf-98
	for dime@ietf.org; Tue, 22 Aug 2006 14:16:37 -0400
Received: from imx11.toshiba.co.jp ([61.202.160.20])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFanf-00016h-EK
	for dime@ietf.org; Tue, 22 Aug 2006 14:16:37 -0400
Received: from wall11.toshiba.co.jp (wall11 [133.199.90.149])
	by imx11.toshiba.co.jp  with ESMTP id k7MIGQca020689;
	Wed, 23 Aug 2006 03:16:26 +0900 (JST)
Received: (from root@localhost) by wall11.toshiba.co.jp  id k7MIGQHj011141;
	Wed, 23 Aug 2006 03:16:26 +0900 (JST)
Received: from ovp11.toshiba.co.jp [133.199.90.148] 
	by wall11.toshiba.co.jp with SMTP id DAA11109;
	Wed, 23 Aug 2006 03:16:26 +0900
Received: from mx.toshiba.co.jp (localhost [127.0.0.1])
	by ovp11.toshiba.co.jp  with ESMTP id k7MIGPQS020628;
	Wed, 23 Aug 2006 03:16:26 +0900 (JST)
Received: from tsbpoa.po.toshiba.co.jp by toshiba.co.jp id k7MIGPXW026972;
	Wed, 23 Aug 2006 03:16:25 +0900 (JST)
Received: from steelhead ([172.30.24.47])
	by mail.po.toshiba.co.jp (Sun Java System Messaging Server 6.1 (built
	Apr 28
	2004)) with ESMTPSA id <0J4E008LOW38MJ10@mail.po.toshiba.co.jp>; Wed,
	23 Aug 2006 03:16:25 +0900 (JST)
Received: from ohba by steelhead with local (Exim 4.62)
	(envelope-from <yohba@tari.toshiba.com>)	id 1GFanA-00006u-0q; Tue,
	22 Aug 2006 11:16:00 -0700
Date: Tue, 22 Aug 2006 14:15:59 -0400
From: Yoshihiro Ohba <yohba@tari.toshiba.com>
Subject: Re: [Dime] Mobile IPv6 Bootstrapping - "Application ID" vs.
	"NAS-Port-Type AVP/Service-Type": Summary
In-reply-to: <44E3853B.2090406@gmx.net>
To: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
Message-id: <20060822181559.GL28318@steelhead>
MIME-version: 1.0
Content-type: text/plain; charset=iso-2022-jp
Content-disposition: inline
References: <44E3853B.2090406@gmx.net>
User-Agent: Mutt/1.5.11+cvs20060403
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f0b5a4216bfa030ed8a6f68d1833f8ae
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

On Wed, Aug 16, 2006 at 10:51:07PM +0200, Hannes Tschofenig wrote:
> Hi all,
> 
> I went through the discussion again and noticed that we haven't reached 
> a conclusion.
> 
> Here is my impression:
> 
> * RFC 3588 leaves a question regarding the extensibility open.
>   This needs to be captured in the revision of the base specification.
> 
> * The main issue seems to be
> 
>   - Do we want to route 'Diameter EAP' message and 'Diameter Mobile 
> IPv6 Bootstrapping' messages differently?

I have two questions.

- Can someone show a compelling reason for why the two types of
messages need to be routed differently?

- If the first question is answered, can we define 'Diameter Mobile
IPv6 Bootstrapping' as a new application but using totally new
messages that carry only information specific to MIPv6 bootstrapping
rather than carrying the information in Diameter EAP messages?  (This
might not be so much optimized but it would be good in terms of
modularity in that we can add any new bootstrapping application in the
same way without touching Diameter EAP application.)

Best regards,
Yoshihiro Ohba


> 
>     If we want to route them differently then we need to define 
> 'Diameter MIPv6 Bootstrapping' as a Diameter application.
> 
>   - The AAA server differentiates ordinary network access and MIPv6 
> bootstrapping functionality (with respect to authorization and 
> accounting). In order to do so it must understand the Service-Type 
> and/or NAS-Port-Type AVPs and the defined values.
> 
>     Is this a problem?
> 
>   - There are problems with proxies and newly defined Diameter 
> Application IDs. Every
> proxy on the path needs new code to handle the new application, while
> just adding an extra AVP or new Service-Type value does not hurt.
> 
>     Is this an issue for us?
> 
> Ciao
> Hannes
> 
> PS: Here is copy-and-paste version of some discussion snippets to allow 
> others to catch-up.
> 
> Julien starts the discussion with a question about Application IDs.
> 
> Pasi suggests to consider Service-Type and/or NAS-Port-Type AVPs as 
> well.... the problem starts.
> 
> Avi states that the problem is that neither Service-Type or Port-Type is 
> mandatory.
> "
> Service Type seems to be the correct way but in RADIUS and
> Diameter service-type also can be authenticate-only or authorize-only.
> So what if the HA wanted to authenticate-only or authorize-only for the
> MIP service?  I would lose the ability to also indicate that this is an
> HA.
> 
> So Port-Type seems to be the way to go....
> "
> 
> Jari jumps in:
> "
> One of the reasons why an existing application would
> be preferred is that then a AAA server that does not
> care about the type of service can be used without
> changes. Yet servers that do care can look at the
> AVPs and make more detailed authorization
> decisions.
> 
> 
> RFC 3588 states that  "Creation of a new application
> should be viewed as a last resort." and that "In order
> to justify allocation of a new application identifier,
> Diameter applications MUST define one Command Code,
> or add new mandatory AVPs to the ABNF." Note that
> mandatory AVPs can be viewed in different ways,
> and that we should not be too strict about them.
> For instance, Framed-Protocol is an optional AVP in
> RFCs 4005 and 4072. Yet, you could argue that if you
> are doing PPP then you need to use this attribute and
> set it to PPP. But that didn't make the attribute mandatory.
> Do we have a similar situation for the IKEv2/MIPv6
> attributes and values? They are not necessary from
> the NASREQ/EAP perspective, but in the specific context
> you need to use the attributes. In my mind, this does not
> make the attributes mandatory from a Diameter
> application point of view. If we start creating
> new applications for every different situation,
> we'll have lots of applications and interoperability
> problems. Its better to add new optional AVPs and
> describe in text when they should be used. The
> only exception that I see is security related AVPs
> that must be understood by the other side or else
> the session should be terminated.
> "
> 
> Avi responds:
> "
> Mandatory does not mean required in the Command.  It means that it must
> be understood by the receiver.  We need to clarify that.
> "
> 
> Gerardo and Lionel agree with Jari.
> 
> 
> 
> Avi writes:
> "
> If I have two EAP based application in my network, one that is
> handling pure EAP application, the other is extended to handle the new
> behavior then I need a way to route the (same) command correctly.
> "
> 
> Jari writes:
> "
> Ah, but that is a new requirement. If you believe that you need
> to route EAP authentication from a 802.11 AP differently
> than from IKEv2/MIPv6, then you need one of these:
> 
> - Use different user/domain names for the users of
>   the different services.
> 
> - Point to different servers from the AP and SGW (but
>   this works less well if you have proxies and roaming).
> 
> - New application ID.
> 
> - Some weird form of Diameter and RADIUS source routing
>   based on what type of node sent the message.
> 
> However, it is far from clear to me why you would really
> need to route the authentication differently *for the same
> user*. Many authentication mechanisms can also have state,
> which would imply that at the end they need to end up in
> the same device anyhow. Can you expand on why you need
> to handle the same users in different authentication
> servers?
> "
> 
> Avi to Jari:
> 
> "
> BTW in the context of the original question raised, the attribute(s)
> will not be optional. Here is the snippet:
> 
> >> >>  In our case, the AAA server must perform AAA functionality for the
> >> >> Mobile IPv6 service. The AAA server must know that it has to
> >> >> authorize the mip6 service and the accounting (ASR/ASA) is also for
> >> >>  mip6 and not for network access.
> 
> If the Diameter message comes from the HA then the HA MUST include the
> NAS-Port-type attribute. So the command ABNF is being changed. Also the
> behavior is being changed of the Server.  It MUST recognize the (new)
> value of the NAS-Port-Type.
> "
> 
> 
> Yoshi says:
> "
> If what is important is service-specific routing (I am not convinced
> with it yet), I'd suggest defining a new authorization-only
> application used only for carrying service-specific attributes
> (analogous to NASREQ usage in RFC 4072).  The downside is that it
> needs another message roundtrip than carrying the attributes in
> DER/DEA.
> "
> 
> 
> Julien wrote:
> "
> > >
> > > I don't think it's clean to require use of different
> > > users'identifiers in order to distinguish which services is
> > > provided. For me, it looks like a 'hack'.
> " and Pasi responded:
> "
> I fully agree -- but having separate user identifiers should not be
> necessary. If, for example, an operator wants to perform different
> authorizations for WiFi and WiMAX (e.g., some users can access only
> WiFi but not WiMAX), that's simple to do: just check Service-Type,
> NAS-Port-Type, and other relevant authorization AVPs.  There's
> absolutely no need to create a new Diameter application.
> 
> If the AAA server is really strict about WiFi vs. WiMAX separation, it
> can have a policy that requires the NAS-Port-Type AVP to be present
> (if the request does not contain it, access is denied). Although this
> in some sense make NAS-Port-Type AVP "mandatory", it's not "mandatory"
> in the sense that would require a new Diameter application.
> 
> While IKEv2 and MIP6 are not WiFi and WiMAX, I don't think there are
> any significant differences from Diameter point-of-view. There's a box
> providing some service; authentication works with EAP; authorization
> AVPs indicate what exactly is being authorized. What's missing is
> a document describing how the different authorization AVPs are
> used in this particular situation; sort of like RFC 3580 (IEEE 802.1X
> RADIUS Usage Guidelines), but for Diameter with IKEv2.
> 
> One important reason NOT to create new applications: proxies. Every
> proxy on the path needs new code to handle the new application, while
> just adding an extra AVP or new Service-Type value doesn't.
> "
> 
> John agrees with Pasi.
> 
> Avi writes:
> "
> A mandatory attribute (a must understand attribute) that has a new
> enumeration is in my mind is like adding a new attribute that must be
> understood.  There is no wigle room here.  The command carrying that
> attribute must reach the implementation that knows how to interpret the
> attribute.  This is  because an implmentation that does not understand
> Service-Type = X must return an error.
> 
> It is obvious that the rules in 3588 are not sufficient to describe when
> to use a new Application ID or not.  And we should not have to have a
> debate on this topic.
> 
> BTW if we do what you say then in networks where I have NASREQ
> performing Network Access and now I want to roll out MIPv6 I would have
> to upgrade all my old NASREQ deployed applications.  This is wrong.  I
> should be able to add a MIPv6 compliant diameter application without
> having to force upgrading my NASREQ applications.
> "
> 
> 
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www1.ietf.org/mailman/listinfo/dime

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



From dime-bounces@ietf.org Tue Aug 22 22:57:14 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GFivS-0006kg-ML; Tue, 22 Aug 2006 22:57:06 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GFivS-0006k5-17
	for dime@ietf.org; Tue, 22 Aug 2006 22:57:06 -0400
Received: from szxga03-in.huawei.com ([61.144.161.55])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFijv-00080C-4n
	for dime@ietf.org; Tue, 22 Aug 2006 22:45:16 -0400
Received: from huawei.com (szxga03-in [172.24.2.9])
	by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0J4F00CAKK3BQA@szxga03-in.huawei.com> for
	dime@ietf.org; Wed, 23 Aug 2006 10:54:48 +0800 (CST)
Received: from huawei.com ([172.24.1.3])
	by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0J4F00K5DK3AF0@szxga03-in.huawei.com> for
	dime@ietf.org; Wed, 23 Aug 2006 10:54:47 +0800 (CST)
Received: from CMTEST6 ([10.70.149.78])
	by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTPA id <0J4F007A4KLMC0@szxml01-in.huawei.com>; Wed,
	23 Aug 2006 11:05:47 +0800 (CST)
Date: Wed, 23 Aug 2006 10:44:19 +0800
From: Tina TSOU <tena@huawei.com>
Subject: Re: AW: [Dime] Next Steps for draft-tsou-dime-base-routing-ext-00
To: "Tschofenig, Hannes" <hannes.tschofenig@siemens.com>,
	Victor Fajardo <vfajardo@tari.toshiba.com>,
	"Glen Zorn (gwz)" <gwz@cisco.com>
Message-id: <00b401c6c65e$080d1b60$4e95460a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-Priority: 3
X-MSMail-priority: Normal
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 343d06d914165ffd9d590a64755216ca
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============0259514505=="
Errors-To: dime-bounces@ietf.org

This is a multi-part message in MIME format.

--===============0259514505==
Content-type: multipart/alternative;
	boundary="Boundary_(ID_op2wfpvnRVwf8x8i5zxw9Q)"

This is a multi-part message in MIME format.

--Boundary_(ID_op2wfpvnRVwf8x8i5zxw9Q)
Content-type: text/plain; charset=gb2312
Content-transfer-encoding: 7BIT

Hi all,
   In [RFC3588], routing of request messages from source to the
   destination is based solely on the routing decision made by each node
   along the path.  In a topology where multiple paths are possible from
   source to destination, it is not guaranteed that all messages
   constituting a session will take the same path.  For a proxy node
   residing along a path that maintains stateful information for a
   session, it is desirable that it remains in the routing path of all
   message exchanges of that a session.

   In general, a session which comprises of multiple message exchanges
   and requires intermediary proxy functions will require explicit
   routing for all request messages within that session.  An example of
   a stateful proxies are in the WLAN 3GPP IP access [TS23.234].  The
   WLAN Access Network (WLAN AN) can use Diameter EAP with the 3GPP AAA
   server or proxy for authentication & authorization.  In the roaming
   case, the WLAN AN is communicating with a 3GPP AAA Proxy in the
   visited network over the Wa reference point.  The 3GPP AAA proxy is
   then connected to the 3GPP Server in the home network over the Wd
   reference point.  The 3GPP AAA Proxy among its many functions will
   enforce local policies on access based on agreement with the 3GPP
   Home Network and with the WLAN operator.  It will also send per user
   charging information for the session to the Offline Charging system.
   This necessitates that the proxy maintains the session state
   information and hence it needs to remain in-path for the entire
   session.

   Given that there are cases where a stateful proxies need to be in the
   routing path of a session, a generic description of the problem is
   shown in Figure 1.  In this scenario there is a relay in the visited
   network (Relay1) and two(2) proxies in the home network (Proxy2 and
   Proxy3).  Relay1 is connected to Proxy2 and Proxy3 for scalability
   and/or redundancy.  If a session is composed of several request/
   answer exchanges it is possible that each request of the session
   takes different paths towards the Home Server.  As an example, if
   Relay1 can route messages via Proxy2 or Proxy3 based on some policy
   independent of the session then the first message of the session can
   take the path Client->Relay1->Proxy2->Home Server while subsequent
   message can take the path Client->Relay1->Proxy3->Home Server.  In
   this case if Proxy2 is stateful then it expects to process not only
   the first message but subsequent request as well.
              VISITED NETWORK     |    HOME NETWORK
                                  |
      +--------+     +--------+   |   +--------+
      | Client |<--->| Relay1 |<----->| Proxy2 |
      +--------+     +--------+   |   +--------+\
                               \  |              \+-------------+
                                \ |               | Home Server |
                                 \|              /+-------------+
                                  \   +--------+/
                                  |---| Proxy3 |
                                  |   +--------+


   Figure 1: Generic Stateful Proxy Problem

   In larger deployments, the issue can be aggrevated when there are a
   greater number of proxy nodes in both visited and home networks in
   Figure 1.  Further escalation of the problem occurs if the deployment
   adds stateless relays preceding any of the proxy nodes in Figure 1.

   In [RFC3588], it is possible to use static routing between the source
   and the proxy to ensure all message exchanges traverses the proxy in
   question.  However, static routing in general, introduces many
   limitations.

   o  Static routing implies that all messages, regardless of session,
      will have to traverse the same proxy.  This introduces a single
      point of failure in the routing path and affects any and all
      sessions regardless of whether the session is of interest to the
      proxy.

   o  It compromises failover procedure in the node adjacent to the
      proxy and preceding it in the request forwarding path.  This
      becomes apparent if the adjacent node explicitly and statically
      routes only towards the proxy.

   o  In the event of more complex topologies where multiple proxies are
      traversed between source and destination, the administrative
      burden of static configuration along the path may be considerable.

   o  No provision for load balancing as all the nodes in the path will
      be subjected to static routing.

   Considering these limitations, an alternative and more dynamic method
   of establishing an explicit routing is proposed.

B. R.
Tina

----- Original Message ----- 
From: "Glen Zorn (gwz)" <gwz@cisco.com>
To: "Victor Fajardo" <vfajardo@tari.toshiba.com>; "Tschofenig, Hannes" <hannes.tschofenig@siemens.com>
Cc: <dime@ietf.org>
Sent: Tuesday, August 22, 2006 4:34 AM
Subject: RE: AW: [Dime] Next Steps for draft-tsou-dime-base-routing-ext-00


Victor Fajardo <mailto:vfajardo@tari.toshiba.com> supposedly scribbled:

> Hi Hannes,
>> Hi Victor,
>> 
>> in the discussions the 3GPP WLAN work was mentioned as the usage
>> scenario. 
>> Is it a real problem in their environment? I have never heard
>> something about problems along these lines. 
>> 
> 
>  From what I understood, it is a problem envisioned by some folks
> when trying to deploy diameter in such environment. I think Tina and
> others can shed light into this better than I can.  

I, for one, would _really_ like to hear this.

...

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by simply
  listening to John Coltrane? -- Henry Gabriel

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

--Boundary_(ID_op2wfpvnRVwf8x8i5zxw9Q)
Content-type: text/html; charset=gb2312
Content-transfer-encoding: 7BIT

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=gb2312">
<META content="MSHTML 6.00.2800.1555" name=GENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=#ffffff>
<DIV><FONT face="Courier New" size=2>Hi all,</FONT></DIV>
<DIV><FONT face="Courier New" size=2>&nbsp;&nbsp; In [RFC3588], routing of 
request messages from source to the<BR>&nbsp;&nbsp; destination is based solely 
on the routing decision made by each node<BR>&nbsp;&nbsp; along the path.&nbsp; 
In a topology where multiple paths are possible from<BR>&nbsp;&nbsp; source to 
destination, it is not guaranteed that all messages<BR>&nbsp;&nbsp; constituting 
a session will take the same path.&nbsp; For a proxy node<BR>&nbsp;&nbsp; 
residing along a path that maintains stateful information for a<BR>&nbsp;&nbsp; 
session, it is desirable that it remains in the routing path of 
all<BR>&nbsp;&nbsp; message exchanges of that a session.</FONT></DIV>
<DIV><FONT face="Courier New"></FONT>&nbsp;</DIV>
<DIV><FONT face="Courier New" size=2>&nbsp;&nbsp; In general, a session which 
comprises of multiple message exchanges<BR>&nbsp;&nbsp; and requires 
intermediary proxy functions will require explicit<BR>&nbsp;&nbsp; routing for 
all request messages within that session.&nbsp; An example of<BR>&nbsp;&nbsp; a 
stateful proxies are in the WLAN 3GPP IP access [TS23.234].&nbsp; 
The<BR>&nbsp;&nbsp; WLAN Access Network (WLAN AN) can use Diameter EAP with the 
3GPP AAA<BR>&nbsp;&nbsp; server or proxy for authentication &amp; 
authorization.&nbsp; In the roaming<BR>&nbsp;&nbsp; case, the WLAN AN is 
communicating with a 3GPP AAA Proxy in the<BR>&nbsp;&nbsp; visited network over 
the Wa reference point.&nbsp; The 3GPP AAA proxy is<BR>&nbsp;&nbsp; then 
connected to the 3GPP Server in the home network over the Wd<BR>&nbsp;&nbsp; 
reference point.&nbsp; The 3GPP AAA Proxy among its many functions 
will<BR>&nbsp;&nbsp; enforce local policies on access based on agreement with 
the 3GPP<BR>&nbsp;&nbsp; Home Network and with the WLAN operator.&nbsp; It will 
also send per user<BR>&nbsp;&nbsp; charging information for the session to the 
Offline Charging system.<BR>&nbsp;&nbsp; This necessitates that the proxy 
maintains the session state<BR>&nbsp;&nbsp; information and hence it needs to 
remain in-path for the entire<BR>&nbsp;&nbsp; session.</FONT></DIV>
<DIV><FONT face="Courier New"></FONT>&nbsp;</DIV>
<DIV><FONT face="Courier New" size=2>&nbsp;&nbsp; Given that there are cases 
where a stateful proxies need to be in the<BR>&nbsp;&nbsp; routing path of a 
session, a generic description of the problem is<BR>&nbsp;&nbsp; shown in Figure 
1.&nbsp; In this scenario there is a relay in the visited<BR>&nbsp;&nbsp; 
network (Relay1) and two(2) proxies in the home network (Proxy2 
and<BR>&nbsp;&nbsp; Proxy3).&nbsp; Relay1 is connected to Proxy2 and Proxy3 for 
scalability<BR>&nbsp;&nbsp; and/or redundancy.&nbsp; If a session is composed of 
several request/<BR>&nbsp;&nbsp; answer exchanges it is possible that each 
request of the session<BR>&nbsp;&nbsp; takes different paths towards the Home 
Server.&nbsp; As an example, if<BR>&nbsp;&nbsp; Relay1 can route messages via 
Proxy2 or Proxy3 based on some policy<BR>&nbsp;&nbsp; independent of the session 
then the first message of the session can<BR>&nbsp;&nbsp; take the path 
Client-&gt;Relay1-&gt;Proxy2-&gt;Home Server while subsequent<BR>&nbsp;&nbsp; 
message can take the path Client-&gt;Relay1-&gt;Proxy3-&gt;Home Server.&nbsp; 
In<BR>&nbsp;&nbsp; this case if Proxy2 is stateful then it expects to process 
not only<BR>&nbsp;&nbsp; the first message but subsequent request as 
well.<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
VISITED NETWORK&nbsp;&nbsp;&nbsp;&nbsp; |&nbsp;&nbsp;&nbsp; HOME 
NETWORK<BR>&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; 
|<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; +--------+&nbsp;&nbsp;&nbsp;&nbsp; 
+--------+&nbsp;&nbsp; |&nbsp;&nbsp; 
+--------+<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; | Client |&lt;---&gt;| Relay1 
|&lt;-----&gt;| Proxy2 |<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
+--------+&nbsp;&nbsp;&nbsp;&nbsp; +--------+&nbsp;&nbsp; |&nbsp;&nbsp; 
+--------+\<BR>&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; 
\+-------------+<BR>&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; 
| Home Server 
|<BR>&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; 
/+-------------+<BR>&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; 
+--------+/<BR>&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; 
|---| Proxy3 
|<BR>&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; +--------+<BR></FONT></DIV><FONT face=Arial size=2>
<DIV><BR><FONT face="Courier New">&nbsp;&nbsp; Figure 1: Generic Stateful Proxy 
Problem</FONT></DIV>
<DIV><FONT face="Courier New"></FONT>&nbsp;</DIV>
<DIV><FONT face="Courier New">&nbsp;&nbsp; In larger deployments, the issue can 
be aggrevated when there are a<BR>&nbsp;&nbsp; greater number of proxy nodes in 
both visited and home networks in<BR>&nbsp;&nbsp; Figure 1.&nbsp; Further 
escalation of the problem occurs if the deployment<BR>&nbsp;&nbsp; adds 
stateless relays preceding any of the proxy nodes in Figure 1.</FONT></DIV>
<DIV><FONT face="Courier New"></FONT>&nbsp;</DIV>
<DIV><FONT face="Courier New">&nbsp;&nbsp; In [RFC3588], it is possible to use 
static routing between the source<BR>&nbsp;&nbsp; and the proxy to ensure all 
message exchanges traverses the proxy in<BR>&nbsp;&nbsp; question.&nbsp; 
However, static routing in general, introduces many<BR>&nbsp;&nbsp; 
limitations.</FONT></DIV>
<DIV><FONT face="Courier New"></FONT>&nbsp;</DIV>
<DIV><FONT face="Courier New">&nbsp;&nbsp; o&nbsp; Static routing implies that 
all messages, regardless of session,<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; will have 
to traverse the same proxy.&nbsp; This introduces a 
single<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; point of failure in the routing path 
and affects any and all<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; sessions regardless of 
whether the session is of interest to the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
proxy.</FONT></DIV>
<DIV><FONT face="Courier New"></FONT>&nbsp;</DIV>
<DIV><FONT face="Courier New">&nbsp;&nbsp; o&nbsp; It compromises failover 
procedure in the node adjacent to the<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; proxy 
and preceding it in the request forwarding path.&nbsp; 
This<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; becomes apparent if the adjacent node 
explicitly and statically<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; routes only towards 
the proxy.</FONT></DIV>
<DIV><FONT face="Courier New"></FONT>&nbsp;</DIV>
<DIV><FONT face="Courier New">&nbsp;&nbsp; o&nbsp; In the event of more complex 
topologies where multiple proxies are<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 
traversed between source and destination, the 
administrative<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; burden of static configuration 
along the path may be considerable.</FONT></DIV>
<DIV><FONT face="Courier New"></FONT>&nbsp;</DIV>
<DIV><FONT face="Courier New">&nbsp;&nbsp; o&nbsp; No provision for load 
balancing as all the nodes in the path will<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; be 
subjected to static routing.</FONT></DIV>
<DIV><FONT face="Courier New"></FONT>&nbsp;</DIV>
<DIV><FONT face="Courier New">&nbsp;&nbsp; Considering these limitations, an 
alternative and more dynamic method<BR>&nbsp;&nbsp; of establishing an explicit 
routing is proposed.<BR></FONT></DIV>
<DIV><FONT face="Courier New">B. R.</FONT></DIV>
<DIV><FONT face="Courier New">Tina</DIV></FONT></FONT>
<DIV><FONT face="Courier New" size=2></FONT>&nbsp;</DIV>
<DIV>
<DIV>----- Original Message ----- 
<DIV>From: "Glen Zorn (gwz)" &lt;<A 
href="mailto:gwz@cisco.com">gwz@cisco.com</A>&gt;</DIV>
<DIV>To: "Victor Fajardo" &lt;<A 
href="mailto:vfajardo@tari.toshiba.com">vfajardo@tari.toshiba.com</A>&gt;; 
"Tschofenig, Hannes" &lt;<A 
href="mailto:hannes.tschofenig@siemens.com">hannes.tschofenig@siemens.com</A>&gt;</DIV>
<DIV>Cc: &lt;<A href="mailto:dime@ietf.org">dime@ietf.org</A>&gt;</DIV>
<DIV>Sent: Tuesday, August 22, 2006 4:34 AM</DIV>
<DIV>Subject: RE: AW: [Dime] Next Steps for 
draft-tsou-dime-base-routing-ext-00</DIV></DIV>
<DIV><BR></DIV>Victor Fajardo &lt;<A 
href="mailto:vfajardo@tari.toshiba.com">mailto:vfajardo@tari.toshiba.com</A>&gt; 
supposedly scribbled:<BR><BR>&gt; Hi Hannes,<BR>&gt;&gt; Hi Victor,<BR>&gt;&gt; 
<BR>&gt;&gt; in the discussions the 3GPP WLAN work was mentioned as the 
usage<BR>&gt;&gt; scenario. <BR>&gt;&gt; Is it a real problem in their 
environment? I have never heard<BR>&gt;&gt; something about problems along these 
lines. <BR>&gt;&gt; <BR>&gt; <BR>&gt;&nbsp; From what I understood, it is a 
problem envisioned by some folks<BR>&gt; when trying to deploy diameter in such 
environment. I think Tina and<BR>&gt; others can shed light into this better 
than I can.&nbsp; <BR><BR>I, for one, would _really_ like to hear 
this.<BR><BR>...<BR><BR>Hope this helps,<BR><BR>~gwz<BR><BR>Why is it that most 
of the world's problems can't be solved by simply<BR>&nbsp; listening to John 
Coltrane? -- Henry 
Gabriel<BR><BR>_______________________________________________<BR>DiME mailing 
list<BR><A href="mailto:DiME@ietf.org">DiME@ietf.org</A><BR><A 
href="https://www1.ietf.org/mailman/listinfo/dime">https://www1.ietf.org/mailman/listinfo/dime</A></DIV></BODY></HTML>

--Boundary_(ID_op2wfpvnRVwf8x8i5zxw9Q)--


--===============0259514505==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0259514505==--




From dime-bounces@ietf.org Wed Aug 23 10:18:27 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GFtYh-0003Qa-J3; Wed, 23 Aug 2006 10:18:19 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GFtYf-0003QQ-Ii
	for dime@ietf.org; Wed, 23 Aug 2006 10:18:17 -0400
Received: from mx0.starentnetworks.com ([12.38.223.203])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFtYc-0004WD-2v
	for dime@ietf.org; Wed, 23 Aug 2006 10:18:17 -0400
Received: from localhost (localhost.localdomain [127.0.0.1])
	by mx0.starentnetworks.com (Postfix) with ESMTP id D4DE89000C;
	Wed, 23 Aug 2006 10:18:09 -0400 (EDT)
Received: from mx0.starentnetworks.com ([127.0.0.1])
	by localhost (mx0.starentnetworks.com [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id 29791-10; Wed, 23 Aug 2006 10:18:08 -0400 (EDT)
Received: from exchtewks1.starentnetworks.com (exchtewks1.starentnetworks.com
	[12.33.233.52]) by mx0.starentnetworks.com (Postfix) with ESMTP;
	Wed, 23 Aug 2006 10:18:08 -0400 (EDT)
X-MessageTextProcessor: DisclaimIt (2.70.271) [Starent Networks Corp.]
Received: from exchtewks2.starentnetworks.com ([12.33.232.12]) by
	exchtewks1.starentnetworks.com with Microsoft
	SMTPSVC(6.0.3790.1830); Wed, 23 Aug 2006 10:18:08 -0400
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.1830
Content-Class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Dime] ASA == MSA: Is it the same Server?
Date: Wed, 23 Aug 2006 10:18:08 -0400
Message-ID: <7CCD07160348804497EF29E9EA5560D7837255@exchtewks2.starentnetworks.com>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [Dime] ASA == MSA: Is it the same Server?
thread-index: AcbFu5isBWlSmSr/S96tQmbOG9THSQA/2GTA
From: "Chowdhury, Kuntal" <kchowdhury@starentnetworks.com>
To: "Gerardo Giaretta" <gerardo.giaretta@gmail.com>
Importance: normal
Priority: normal
X-OriginalArrivalTime: 23 Aug 2006 14:18:08.0895 (UTC)
	FILETIME=[F558A0F0:01C6C6BE]
X-Virus-Scanned: amavisd-new 2.2.1 (20041222) at mx0.starentnetworks.com
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

Gerardo,

What you describe is a possibility i.e. the AAA server that hands out
the HA info to the MN (via the NAS) is different from the one that is
doing EAP auth for IKE_Auth at the HA for mobility access.

The point we are trying to clarify here is, the AAA server (ASA) that
hands out HA address to the MN (via the NAS), does it have to know
whether it is authorizing the MN for MIP6 service? This will need the
NAS to include a hint to the AAA server via App-ID or NAS-port to
indicate that the MN intends to start a MIP6 service. The question is
how does the NAS know whether the MN wants to start MIP6? At the time of
access auth at the NAS there is no such indication from the MN. So, the
more fundamental question is, regardless of which way we go i.e. APP-ID
or NAS-port, how the NAS know that the MN is going to start a MIP6
session?

-Kuntal
=20

> -----Original Message-----
> From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com]
> Sent: Tuesday, August 22, 2006 2:22 AM
> To: Hannes Tschofenig
> Cc: Chowdhury, Kuntal; dime@ietf.org
> Subject: Re: [Dime] ASA =3D=3D MSA: Is it the same Server?
>=20
> Hi Kuntal and Hannes,
>=20
> > > [KC>] In case of split scenario, I see the use case where the AAA
> > > transaction for network access at the NAS is going to a different
AAA
> > > server than the same at the HA, since ASA !=3D MSA in split.
> >
> > In this case the identities are different though. You cannot use the
> > same identity to hit two different domains.
> > Hence, there is no problem as such.
> >
> >   In case of
> > > integrated scenario, it is essential that the AAA transactions
from
> the
> > > NAS and from the HA get routed to the same AAA server (ASA =3D=3D
MSA). So
> > > we need to keep this in mind.
> >
> > Here is the question whether they are indeed the same server. Some
folks
> > they argue that it is not the same one
> >
>=20
> Some background: the integrated scenario was defined during the
> bootstrapping DT discussion because some proposed solutions were
> applicable only in the case the entity that authenticates the user for
> network access is the same entity that authenticate the user for
> mobility service. In my view, the initial assumption was that the same
> AAA server authenticates the user for both services, since during the
> authentication for network access some MIP6 related information are
> sent to the NAS.
>=20
> However, in a AAA stateless architecture, it would be possible to have
> also different AAA servers; I guess in this case the solution for
> integrated scenario would still work: the first AAA server (that
> authenticates the user for network access) sends the MIP6-related
> information to the NAS, and the second AAA server (that authenticates
> the user for mobility service) just terminates the EAP exchange
> carried on IKEv2 between MN and HA.
>=20
> Therefore, I think the servers may be different, but the AAA
> infrastructure/business entity is the same. Am I missing something?
>=20
> > >>From the AAA message routing point of view, I thought the @realm
part
> of
> > > the username (NAI) was sufficient to route AAA messages to
different
> AAA
> > > systems.
> >
> > IMHO, for the ASA !=3D MSA scenario it is.
> >
>=20
> agree for the split scenario.
>=20
> --Gerardo
>=20
> > Ciao
> > Hannes
> >
> > _______________________________________________
> > DiME mailing list
> > DiME@ietf.org
> > https://www1.ietf.org/mailman/listinfo/dime
> >


"This email message and any attachments are confidential information of =
Starent Networks, Corp. The information transmitted may not be used to =
create or change any contractual obligations of Starent Networks, Corp.  =
Any review, retransmission, dissemination or other use of, or taking of =
any action in reliance upon this e-mail and its attachments by persons =
or entities other than the intended recipient is prohibited. If you are =
not the intended recipient, please notify the sender immediately -- by =
replying to this message or by sending an email to =
postmaster@starentnetworks.com -- and destroy all copies of this message =
and any attachments without reading or disclosing their contents. Thank =
you."

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



From dime-bounces@ietf.org Wed Aug 23 10:25:47 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GFtfv-0006P0-2n; Wed, 23 Aug 2006 10:25:47 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GFtft-0006Ov-Sa
	for dime@ietf.org; Wed, 23 Aug 2006 10:25:45 -0400
Received: from smtp2.int-evry.fr ([157.159.10.45])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GFtfs-0006ua-Bt
	for dime@ietf.org; Wed, 23 Aug 2006 10:25:45 -0400
Received: from ipv6-3.int-evry.fr (ipv6-3.int-evry.fr [157.159.100.76])
	by smtp2.int-evry.fr (Postfix) with ESMTP id 5B8632FE67;
	Wed, 23 Aug 2006 16:25:37 +0200 (CEST)
Received: from jb by ipv6-3.int-evry.fr with local (Exim 4.52)
	id 1GFthc-0007pt-8Z; Wed, 23 Aug 2006 16:27:32 +0200
Date: Wed, 23 Aug 2006 16:27:32 +0200
From: Julien Bournelle <julien.bournelle@int-evry.fr>
To: "Chowdhury, Kuntal" <kchowdhury@starentnetworks.com>
Subject: Re: [Dime] ASA == MSA: Is it the same Server?
Message-ID: <20060823142732.GA30117@ipv6-3.int-evry.fr>
References: <7CCD07160348804497EF29E9EA5560D7837255@exchtewks2.starentnetworks.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <7CCD07160348804497EF29E9EA5560D7837255@exchtewks2.starentnetworks.com>
User-Agent: Mutt/1.5.9i
X-INT-MailScanner-Information: Please contact the ISP for more information
X-INT-MailScanner: Found to be clean
X-INT-MailScanner-MCPCheck: 
X-INT-MailScanner-SpamCheck: 
X-MailScanner-From: jb@int-evry.fr
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

Hi kuntal,

On Wed, Aug 23, 2006 at 10:18:08AM -0400, Chowdhury, Kuntal wrote:
> Gerardo,
> 
> What you describe is a possibility i.e. the AAA server that hands out
> the HA info to the MN (via the NAS) is different from the one that is
> doing EAP auth for IKE_Auth at the HA for mobility access.
> 
> The point we are trying to clarify here is, the AAA server (ASA) that
> hands out HA address to the MN (via the NAS), does it have to know
> whether it is authorizing the MN for MIP6 service? 

 this is not the point I try to clarify :)
 For what you describe, I don't think that the ASA has to authorize the
 mip6 service at this point of time. It just provide the HA info.

 The MSA authorize the mip6 service when the MN uses IKEv2 with the HA.

 Maybe I miss something.

 regards,

 Julien

> This will need the
> NAS to include a hint to the AAA server via App-ID or NAS-port to
> indicate that the MN intends to start a MIP6 service. The question is
> how does the NAS know whether the MN wants to start MIP6? At the time of
> access auth at the NAS there is no such indication from the MN. So, the
> more fundamental question is, regardless of which way we go i.e. APP-ID
> or NAS-port, how the NAS know that the MN is going to start a MIP6
> session?
> 
> -Kuntal
>  
> 
> > -----Original Message-----
> > From: Gerardo Giaretta [mailto:gerardo.giaretta@gmail.com]
> > Sent: Tuesday, August 22, 2006 2:22 AM
> > To: Hannes Tschofenig
> > Cc: Chowdhury, Kuntal; dime@ietf.org
> > Subject: Re: [Dime] ASA == MSA: Is it the same Server?
> > 
> > Hi Kuntal and Hannes,
> > 
> > > > [KC>] In case of split scenario, I see the use case where the AAA
> > > > transaction for network access at the NAS is going to a different
> AAA
> > > > server than the same at the HA, since ASA != MSA in split.
> > >
> > > In this case the identities are different though. You cannot use the
> > > same identity to hit two different domains.
> > > Hence, there is no problem as such.
> > >
> > >   In case of
> > > > integrated scenario, it is essential that the AAA transactions
> from
> > the
> > > > NAS and from the HA get routed to the same AAA server (ASA ==
> MSA). So
> > > > we need to keep this in mind.
> > >
> > > Here is the question whether they are indeed the same server. Some
> folks
> > > they argue that it is not the same one
> > >
> > 
> > Some background: the integrated scenario was defined during the
> > bootstrapping DT discussion because some proposed solutions were
> > applicable only in the case the entity that authenticates the user for
> > network access is the same entity that authenticate the user for
> > mobility service. In my view, the initial assumption was that the same
> > AAA server authenticates the user for both services, since during the
> > authentication for network access some MIP6 related information are
> > sent to the NAS.
> > 
> > However, in a AAA stateless architecture, it would be possible to have
> > also different AAA servers; I guess in this case the solution for
> > integrated scenario would still work: the first AAA server (that
> > authenticates the user for network access) sends the MIP6-related
> > information to the NAS, and the second AAA server (that authenticates
> > the user for mobility service) just terminates the EAP exchange
> > carried on IKEv2 between MN and HA.
> > 
> > Therefore, I think the servers may be different, but the AAA
> > infrastructure/business entity is the same. Am I missing something?
> > 
> > > >>From the AAA message routing point of view, I thought the @realm
> part
> > of
> > > > the username (NAI) was sufficient to route AAA messages to
> different
> > AAA
> > > > systems.
> > >
> > > IMHO, for the ASA != MSA scenario it is.
> > >
> > 
> > agree for the split scenario.
> > 
> > --Gerardo
> > 
> > > Ciao
> > > Hannes
> > >
> > > _______________________________________________
> > > DiME mailing list
> > > DiME@ietf.org
> > > https://www1.ietf.org/mailman/listinfo/dime
> > >
> 
> 
> "This email message and any attachments are confidential information of Starent Networks, Corp. The information transmitted may not be used to create or change any contractual obligations of Starent Networks, Corp.  Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this e-mail and its attachments by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify the sender immediately -- by replying to this message or by sending an email to postmaster@starentnetworks.com -- and destroy all copies of this message and any attachments without reading or disclosing their contents. Thank you."
> 
> _______________________________________________
> DiME mailing list
> DiME@ietf.org
> https://www1.ietf.org/mailman/listinfo/dime

-- 
julien.bournelle at int-evry.fr

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



From dime-bounces@ietf.org Thu Aug 24 11:00:19 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GGGgk-0002pz-QN; Thu, 24 Aug 2006 11:00:10 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GGGgj-0002pq-Kd
	for dime@ietf.org; Thu, 24 Aug 2006 11:00:09 -0400
Received: from psg.com ([147.28.0.62])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGGgi-0005c4-B3
	for dime@ietf.org; Thu, 24 Aug 2006 11:00:09 -0400
Received: from psg.com ([147.28.0.62] helo=[127.0.0.1])
	by psg.com with esmtp (Exim 4.60 (FreeBSD))
	(envelope-from <avri@acm.org>)
	id 1GGGgh-000JPT-Rn; Thu, 24 Aug 2006 15:00:08 +0000
In-Reply-To: <GBEBKGPKHGPAOFCLBNAMAEJCEHAA.asveren@ulticom.com>
References: <GBEBKGPKHGPAOFCLBNAMAEJCEHAA.asveren@ulticom.com>
Mime-Version: 1.0 (Apple Message framework v752.2)
X-Priority: 3 (Normal)
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <EE4B41E3-A699-4BDC-B8A1-9340BE64DE02@acm.org>
Content-Transfer-Encoding: 7bit
From: Avri Doria <avri@acm.org>
Subject: Re: [Dime] Re: Next Steps for draft-bodin-dime-auditing-reqs-00.txt
Date: Thu, 24 Aug 2006 11:00:02 -0400
To: Tolga Asveren <asveren@ulticom.com>
X-Mailer: Apple Mail (2.752.2)
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 31247fb3be228bb596db9127becad0bc
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

Hi,

I will add some clarification of the definition of the problem.

I think the main problem is b) retrieving state information.

But, I do not understand what you mean by preventing session  
leaking.  can you explain?

thanks

a.

On 17 aug 2006, at 10.34, Tolga Asveren wrote:

> Hi Avri,
>
> I am most interested at a clear definition of the problem the draft is
> about:
>
> a) Preventing session leaking
> b) Retrieving state information
> c) Both
>
> If that is made more clear, it would be easirt to understand/to move
> forward -at least for me-
>
>     Thanks,
>     Tolga
>
>> -----Original Message-----
>> From: Avri Doria [mailto:avri@acm.org]
>> Sent: Thursday, August 17, 2006 10:50 AM
>> To: Hannes Tschofenig
>> Cc: Ulf.Bodin@operax.com; dime@ietf.org
>> Subject: [Dime] Re: Next Steps for draft-bodin-dime-auditing- 
>> reqs-00.txt
>>
>>
>> Hi,
>>
>> Yes, we are planning to put out another version, i will most probably
>> be acting as the editor of the version.  I have been away for the
>> last few weeks, but am back now and expect to float a new version in
>> the next 2 weeks.
>>
>> I do think there is interst in ETSI TISPAN as this was were the
>> original impetus came from.  Not sure about the  ITU.
>>
>> I would certainly appreciate any use case text members of the dime wg
>> would like to see included in the updated document.
>>
>> thanks
>>
>> a.
>>
>> On 16 aug 2006, at 16.13, Hannes Tschofenig wrote:
>>
>>> Hi Avri,
>>> Hi Ulf,
>>>
>>> during the DIME working group meeting at IETF#66 a number of folks
>>> showed interest in your work. It was, however, also noted that the
>>> draft requires a bit more details.
>>>
>>> Do you plan to update the draft? When do you plan to submit the
>>> draft? Do you need help with the draft editing (I bet there are
>>> some DIME working group members willing to help.)?
>>> Is there interest from ETSI TISPAN and the ITU-T on this subject?
>>>
>>> Ciao
>>> Hannes & John
>>>
>>>
>>
>>
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www1.ietf.org/mailman/listinfo/dime
>
>


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



From dime-bounces@ietf.org Fri Aug 25 22:24:19 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GGnqI-0003rB-R5; Fri, 25 Aug 2006 22:24:14 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GGnqH-0003r6-EZ
	for dime@ietf.org; Fri, 25 Aug 2006 22:24:13 -0400
Received: from szxga02-in.huawei.com ([61.144.161.54])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GGnqC-0004tX-9Z
	for dime@ietf.org; Fri, 25 Aug 2006 22:24:13 -0400
Received: from huawei.com (szxga02-in [172.24.2.6])
	by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0J4L00LKS3GWRS@szxga02-in.huawei.com> for
	dime@ietf.org; Sat, 26 Aug 2006 10:41:20 +0800 (CST)
Received: from huawei.com ([172.24.1.6])
	by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTP id <0J4L0085Y3GUO0@szxga02-in.huawei.com> for
	dime@ietf.org; Sat, 26 Aug 2006 10:41:20 +0800 (CST)
Received: from CMTEST6 ([10.70.149.78])
	by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25
	(built Mar
	3 2004)) with ESMTPA id <0J4L003283G796@szxml02-in.huawei.com>; Sat,
	26 Aug 2006 10:40:56 +0800 (CST)
Date: Sat, 26 Aug 2006 10:23:24 +0800
From: Tina TSOU <tena@huawei.com>
Subject: Re: AW: [Dime] Next Steps for draft-tsou-dime-base-routing-ext-00
To: "Glen Zorn (gwz)" <gwz@cisco.com>,
	Victor Fajardo <vfajardo@tari.toshiba.com>,
	"Tschofenig, Hannes" <hannes.tschofenig@siemens.com>
Message-id: <003501c6c8b6$9bcf6060$4e95460a@china.huawei.com>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409
X-Mailer: Microsoft Outlook Express 6.00.2800.1409
X-Priority: 3
X-MSMail-priority: Normal
References: <00b401c6c65e$080d1b60$4e95460a@china.huawei.com>
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 85e99493ec37f9acef29c7843dbf2e68
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Content-Type: multipart/mixed; boundary="===============1496910596=="
Errors-To: dime-bounces@ietf.org

This is a multi-part message in MIME format.

--===============1496910596==
Content-type: multipart/alternative;
	boundary="Boundary_(ID_QYjNrhRvKQsh+dG8y4Xhgg)"

This is a multi-part message in MIME format.

--Boundary_(ID_QYjNrhRvKQsh+dG8y4Xhgg)
Content-type: text/plain; charset=gb2312
Content-transfer-encoding: 7BIT

Hi all,
Furthermore,
1) What scenario is there Diameter Relay?
Between home network and visit network, one network (e.g. visit network) does not want to expose the IP address of all its AAA servers to the other network (e.g. home network). So, visit network puts a Diameter Relay as the single contact point for home network. At the same time, it reduces the connections number between home network and visit network.

2) What scenario is this Diameter Relay connected to two Diameter Proxies?
The capability of one Diameter Proxy is not enough to process all the users in one network. One network has more than 1,000,000 users. However, one Diameter Proxy has the capability of 1,000,000 users. Hence, more than one Diameter Proxies are needed in this network.

Have a great weekend:)

B. R.
Tina
  ----- Original Message ----- 
  From: Tina TSOU 
  To: Tschofenig, Hannes ; Victor Fajardo ; Glen Zorn (gwz) 
  Cc: dime@ietf.org 
  Sent: Wednesday, August 23, 2006 10:44 AM
  Subject: Re: AW: [Dime] Next Steps for draft-tsou-dime-base-routing-ext-00


  Hi all,
     In [RFC3588], routing of request messages from source to the
     destination is based solely on the routing decision made by each node
     along the path.  In a topology where multiple paths are possible from
     source to destination, it is not guaranteed that all messages
     constituting a session will take the same path.  For a proxy node
     residing along a path that maintains stateful information for a
     session, it is desirable that it remains in the routing path of all
     message exchanges of that a session.

     In general, a session which comprises of multiple message exchanges
     and requires intermediary proxy functions will require explicit
     routing for all request messages within that session.  An example of
     a stateful proxies are in the WLAN 3GPP IP access [TS23.234].  The
     WLAN Access Network (WLAN AN) can use Diameter EAP with the 3GPP AAA
     server or proxy for authentication & authorization.  In the roaming
     case, the WLAN AN is communicating with a 3GPP AAA Proxy in the
     visited network over the Wa reference point.  The 3GPP AAA proxy is
     then connected to the 3GPP Server in the home network over the Wd
     reference point.  The 3GPP AAA Proxy among its many functions will
     enforce local policies on access based on agreement with the 3GPP
     Home Network and with the WLAN operator.  It will also send per user
     charging information for the session to the Offline Charging system.
     This necessitates that the proxy maintains the session state
     information and hence it needs to remain in-path for the entire
     session.

     Given that there are cases where a stateful proxies need to be in the
     routing path of a session, a generic description of the problem is
     shown in Figure 1.  In this scenario there is a relay in the visited
     network (Relay1) and two(2) proxies in the home network (Proxy2 and
     Proxy3).  Relay1 is connected to Proxy2 and Proxy3 for scalability
     and/or redundancy.  If a session is composed of several request/
     answer exchanges it is possible that each request of the session
     takes different paths towards the Home Server.  As an example, if
     Relay1 can route messages via Proxy2 or Proxy3 based on some policy
     independent of the session then the first message of the session can
     take the path Client->Relay1->Proxy2->Home Server while subsequent
     message can take the path Client->Relay1->Proxy3->Home Server.  In
     this case if Proxy2 is stateful then it expects to process not only
     the first message but subsequent request as well.
                VISITED NETWORK     |    HOME NETWORK
                                    |
        +--------+     +--------+   |   +--------+
        | Client |<--->| Relay1 |<----->| Proxy2 |
        +--------+     +--------+   |   +--------+\
                                 \  |              \+-------------+
                                  \ |               | Home Server |
                                   \|              /+-------------+
                                    \   +--------+/
                                    |---| Proxy3 |
                                    |   +--------+


     Figure 1: Generic Stateful Proxy Problem

     In larger deployments, the issue can be aggrevated when there are a
     greater number of proxy nodes in both visited and home networks in
     Figure 1.  Further escalation of the problem occurs if the deployment
     adds stateless relays preceding any of the proxy nodes in Figure 1.

     In [RFC3588], it is possible to use static routing between the source
     and the proxy to ensure all message exchanges traverses the proxy in
     question.  However, static routing in general, introduces many
     limitations.

     o  Static routing implies that all messages, regardless of session,
        will have to traverse the same proxy.  This introduces a single
        point of failure in the routing path and affects any and all
        sessions regardless of whether the session is of interest to the
        proxy.

     o  It compromises failover procedure in the node adjacent to the
        proxy and preceding it in the request forwarding path.  This
        becomes apparent if the adjacent node explicitly and statically
        routes only towards the proxy.

     o  In the event of more complex topologies where multiple proxies are
        traversed between source and destination, the administrative
        burden of static configuration along the path may be considerable.

     o  No provision for load balancing as all the nodes in the path will
        be subjected to static routing.

     Considering these limitations, an alternative and more dynamic method
     of establishing an explicit routing is proposed.

  B. R.
  Tina

  ----- Original Message ----- 
  From: "Glen Zorn (gwz)" <gwz@cisco.com>
  To: "Victor Fajardo" <vfajardo@tari.toshiba.com>; "Tschofenig, Hannes" <hannes.tschofenig@siemens.com>
  Cc: <dime@ietf.org>
  Sent: Tuesday, August 22, 2006 4:34 AM
  Subject: RE: AW: [Dime] Next Steps for draft-tsou-dime-base-routing-ext-00


  Victor Fajardo <mailto:vfajardo@tari.toshiba.com> supposedly scribbled:

  > Hi Hannes,
  >> Hi Victor,
  >> 
  >> in the discussions the 3GPP WLAN work was mentioned as the usage
  >> scenario. 
  >> Is it a real problem in their environment? I have never heard
  >> something about problems along these lines. 
  >> 
  > 
  >  From what I understood, it is a problem envisioned by some folks
  > when trying to deploy diameter in such environment. I think Tina and
  > others can shed light into this better than I can.  

  I, for one, would _really_ like to hear this.

  ...

  Hope this helps,

  ~gwz

  Why is it that most of the world's problems can't be solved by simply
    listening to John Coltrane? -- Henry Gabriel

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


------------------------------------------------------------------------------


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

--Boundary_(ID_QYjNrhRvKQsh+dG8y4Xhgg)
Content-type: text/html; charset=gb2312
Content-transfer-encoding: base64

PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv
L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu
dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w
MC4yODAwLjE1NTUiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8
Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3IiBzaXpl
PTI+SGkgYWxsLDwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT0iQ291cmllciBOZXciIHNp
emU9Mj5GdXJ0aGVybW9yZSw8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9IkNvdXJpZXIg
TmV3IiBzaXplPTI+MSkgV2hhdCBzY2VuYXJpbyBpcyB0aGVyZSBEaWFtZXRlciANClJlbGF5PzxC
Uj5CZXR3ZWVuIGhvbWUgbmV0d29yayBhbmQgdmlzaXQgbmV0d29yaywgb25lIG5ldHdvcmsgKGUu
Zy4gdmlzaXQgDQpuZXR3b3JrKSBkb2VzIG5vdCB3YW50IHRvIGV4cG9zZSB0aGUgSVAgYWRkcmVz
cyBvZiBhbGwgaXRzIEFBQSBzZXJ2ZXJzIHRvIHRoZSANCm90aGVyIG5ldHdvcmsgKGUuZy4gaG9t
ZSBuZXR3b3JrKS4gU28sIHZpc2l0IG5ldHdvcmsgcHV0cyBhIERpYW1ldGVyIFJlbGF5IGFzIA0K
dGhlIHNpbmdsZSBjb250YWN0IHBvaW50IGZvciBob21lIG5ldHdvcmsuIEF0IHRoZSBzYW1lIHRp
bWUsIGl0IHJlZHVjZXMgdGhlIA0KY29ubmVjdGlvbnMgbnVtYmVyIGJldHdlZW4gaG9tZSBuZXR3
b3JrIGFuZCB2aXNpdCBuZXR3b3JrLjxCUj48QlI+MikgV2hhdCANCnNjZW5hcmlvIGlzIHRoaXMg
RGlhbWV0ZXIgUmVsYXkgY29ubmVjdGVkIHRvIHR3byBEaWFtZXRlciBQcm94aWVzPzxCUj5UaGUg
DQpjYXBhYmlsaXR5IG9mIG9uZSBEaWFtZXRlciBQcm94eSBpcyBub3QgZW5vdWdoIHRvIHByb2Nl
c3MgYWxsIHRoZSB1c2VycyBpbiBvbmUgDQpuZXR3b3JrLiBPbmUgbmV0d29yayBoYXMgbW9yZSB0
aGFuIDEsMDAwLDAwMCB1c2Vycy4gSG93ZXZlciwgb25lIERpYW1ldGVyIFByb3h5IA0KaGFzIHRo
ZSBjYXBhYmlsaXR5IG9mIDEsMDAwLDAwMCB1c2Vycy4gSGVuY2UsIG1vcmUgdGhhbiBvbmUgRGlh
bWV0ZXIgUHJveGllcyBhcmUgDQpuZWVkZWQgaW4gdGhpcyBuZXR3b3JrLjxCUj48L0ZPTlQ+PC9E
SVY+DQo8RElWPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3IiBzaXplPTI+SGF2ZSBhIGdyZWF0IHdl
ZWtlbmQ6KTwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBzaXplPTI+PC9GT05U
PjxCUj48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyIgc2l6ZT0yPkIuIA0KUi48QlI+VGluYTwvRk9O
VD48L0RJVj4NCjxCTE9DS1FVT1RFIA0Kc3R5bGU9IlBBRERJTkctUklHSFQ6IDBweDsgUEFERElO
Ry1MRUZUOiA1cHg7IE1BUkdJTi1MRUZUOiA1cHg7IEJPUkRFUi1MRUZUOiAjMDAwMDAwIDJweCBz
b2xpZDsgTUFSR0lOLVJJR0hUOiAwcHgiPg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQgy87M5SI+
LS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSA8L0RJVj4NCiAgPERJViBzdHlsZT0iQkFDS0dS
T1VORDogI2U0ZTRlNDsgRk9OVDogOXB0IMvOzOU7IGZvbnQtY29sb3I6IGJsYWNrIj48Qj5Gcm9t
OjwvQj4gDQogIDxBIHRpdGxlPXRlbmFAaHVhd2VpLmNvbSBocmVmPSJtYWlsdG86dGVuYUBodWF3
ZWkuY29tIj5UaW5hIFRTT1U8L0E+IDwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQgy87M
5SI+PEI+VG86PC9CPiA8QSB0aXRsZT1oYW5uZXMudHNjaG9mZW5pZ0BzaWVtZW5zLmNvbSANCiAg
aHJlZj0ibWFpbHRvOmhhbm5lcy50c2Nob2ZlbmlnQHNpZW1lbnMuY29tIj5Uc2Nob2ZlbmlnLCBI
YW5uZXM8L0E+IDsgPEEgDQogIHRpdGxlPXZmYWphcmRvQHRhcmkudG9zaGliYS5jb20gaHJlZj0i
bWFpbHRvOnZmYWphcmRvQHRhcmkudG9zaGliYS5jb20iPlZpY3RvciANCiAgRmFqYXJkbzwvQT4g
OyA8QSB0aXRsZT1nd3pAY2lzY28uY29tIGhyZWY9Im1haWx0bzpnd3pAY2lzY28uY29tIj5HbGVu
IFpvcm4gDQogIChnd3opPC9BPiA8L0RJVj4NCiAgPERJViBzdHlsZT0iRk9OVDogOXB0IMvOzOUi
PjxCPkNjOjwvQj4gPEEgdGl0bGU9ZGltZUBpZXRmLm9yZyANCiAgaHJlZj0ibWFpbHRvOmRpbWVA
aWV0Zi5vcmciPmRpbWVAaWV0Zi5vcmc8L0E+IDwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiA5
cHQgy87M5SI+PEI+U2VudDo8L0I+IFdlZG5lc2RheSwgQXVndXN0IDIzLCAyMDA2IDEwOjQ0IA0K
ICBBTTwvRElWPg0KICA8RElWIHN0eWxlPSJGT05UOiA5cHQgy87M5SI+PEI+U3ViamVjdDo8L0I+
IFJlOiBBVzogW0RpbWVdIE5leHQgU3RlcHMgZm9yIA0KICBkcmFmdC10c291LWRpbWUtYmFzZS1y
b3V0aW5nLWV4dC0wMDwvRElWPg0KICA8RElWPjxCUj48L0RJVj4NCiAgPERJVj48Rk9OVCBmYWNl
PSJDb3VyaWVyIE5ldyIgc2l6ZT0yPkhpIGFsbCw8L0ZPTlQ+PC9ESVY+DQogIDxESVY+PEZPTlQg
ZmFjZT0iQ291cmllciBOZXciIHNpemU9Mj4mbmJzcDsmbmJzcDsgSW4gW1JGQzM1ODhdLCByb3V0
aW5nIG9mIA0KICByZXF1ZXN0IG1lc3NhZ2VzIGZyb20gc291cmNlIHRvIHRoZTxCUj4mbmJzcDsm
bmJzcDsgZGVzdGluYXRpb24gaXMgYmFzZWQgDQogIHNvbGVseSBvbiB0aGUgcm91dGluZyBkZWNp
c2lvbiBtYWRlIGJ5IGVhY2ggbm9kZTxCUj4mbmJzcDsmbmJzcDsgYWxvbmcgdGhlIA0KICBwYXRo
LiZuYnNwOyBJbiBhIHRvcG9sb2d5IHdoZXJlIG11bHRpcGxlIHBhdGhzIGFyZSBwb3NzaWJsZSAN
CiAgZnJvbTxCUj4mbmJzcDsmbmJzcDsgc291cmNlIHRvIGRlc3RpbmF0aW9uLCBpdCBpcyBub3Qg
Z3VhcmFudGVlZCB0aGF0IGFsbCANCiAgbWVzc2FnZXM8QlI+Jm5ic3A7Jm5ic3A7IGNvbnN0aXR1
dGluZyBhIHNlc3Npb24gd2lsbCB0YWtlIHRoZSBzYW1lIHBhdGguJm5ic3A7IA0KICBGb3IgYSBw
cm94eSBub2RlPEJSPiZuYnNwOyZuYnNwOyByZXNpZGluZyBhbG9uZyBhIHBhdGggdGhhdCBtYWlu
dGFpbnMgc3RhdGVmdWwgDQogIGluZm9ybWF0aW9uIGZvciBhPEJSPiZuYnNwOyZuYnNwOyBzZXNz
aW9uLCBpdCBpcyBkZXNpcmFibGUgdGhhdCBpdCByZW1haW5zIGluIA0KICB0aGUgcm91dGluZyBw
YXRoIG9mIGFsbDxCUj4mbmJzcDsmbmJzcDsgbWVzc2FnZSBleGNoYW5nZXMgb2YgdGhhdCBhIA0K
ICBzZXNzaW9uLjwvRk9OVD48L0RJVj4NCiAgPERJVj48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+
PC9GT05UPiZuYnNwOzwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3IiBzaXpl
PTI+Jm5ic3A7Jm5ic3A7IEluIGdlbmVyYWwsIGEgc2Vzc2lvbiB3aGljaCANCiAgY29tcHJpc2Vz
IG9mIG11bHRpcGxlIG1lc3NhZ2UgZXhjaGFuZ2VzPEJSPiZuYnNwOyZuYnNwOyBhbmQgcmVxdWly
ZXMgDQogIGludGVybWVkaWFyeSBwcm94eSBmdW5jdGlvbnMgd2lsbCByZXF1aXJlIGV4cGxpY2l0
PEJSPiZuYnNwOyZuYnNwOyByb3V0aW5nIGZvciANCiAgYWxsIHJlcXVlc3QgbWVzc2FnZXMgd2l0
aGluIHRoYXQgc2Vzc2lvbi4mbmJzcDsgQW4gZXhhbXBsZSBvZjxCUj4mbmJzcDsmbmJzcDsgDQog
IGEgc3RhdGVmdWwgcHJveGllcyBhcmUgaW4gdGhlIFdMQU4gM0dQUCBJUCBhY2Nlc3MgW1RTMjMu
MjM0XS4mbmJzcDsgDQogIFRoZTxCUj4mbmJzcDsmbmJzcDsgV0xBTiBBY2Nlc3MgTmV0d29yayAo
V0xBTiBBTikgY2FuIHVzZSBEaWFtZXRlciBFQVAgd2l0aCANCiAgdGhlIDNHUFAgQUFBPEJSPiZu
YnNwOyZuYnNwOyBzZXJ2ZXIgb3IgcHJveHkgZm9yIGF1dGhlbnRpY2F0aW9uICZhbXA7IA0KICBh
dXRob3JpemF0aW9uLiZuYnNwOyBJbiB0aGUgcm9hbWluZzxCUj4mbmJzcDsmbmJzcDsgY2FzZSwg
dGhlIFdMQU4gQU4gaXMgDQogIGNvbW11bmljYXRpbmcgd2l0aCBhIDNHUFAgQUFBIFByb3h5IGlu
IHRoZTxCUj4mbmJzcDsmbmJzcDsgdmlzaXRlZCBuZXR3b3JrIA0KICBvdmVyIHRoZSBXYSByZWZl
cmVuY2UgcG9pbnQuJm5ic3A7IFRoZSAzR1BQIEFBQSBwcm94eSBpczxCUj4mbmJzcDsmbmJzcDsg
dGhlbiANCiAgY29ubmVjdGVkIHRvIHRoZSAzR1BQIFNlcnZlciBpbiB0aGUgaG9tZSBuZXR3b3Jr
IG92ZXIgdGhlIFdkPEJSPiZuYnNwOyZuYnNwOyANCiAgcmVmZXJlbmNlIHBvaW50LiZuYnNwOyBU
aGUgM0dQUCBBQUEgUHJveHkgYW1vbmcgaXRzIG1hbnkgZnVuY3Rpb25zIA0KICB3aWxsPEJSPiZu
YnNwOyZuYnNwOyBlbmZvcmNlIGxvY2FsIHBvbGljaWVzIG9uIGFjY2VzcyBiYXNlZCBvbiBhZ3Jl
ZW1lbnQgd2l0aCANCiAgdGhlIDNHUFA8QlI+Jm5ic3A7Jm5ic3A7IEhvbWUgTmV0d29yayBhbmQg
d2l0aCB0aGUgV0xBTiBvcGVyYXRvci4mbmJzcDsgSXQgDQogIHdpbGwgYWxzbyBzZW5kIHBlciB1
c2VyPEJSPiZuYnNwOyZuYnNwOyBjaGFyZ2luZyBpbmZvcm1hdGlvbiBmb3IgdGhlIHNlc3Npb24g
DQogIHRvIHRoZSBPZmZsaW5lIENoYXJnaW5nIHN5c3RlbS48QlI+Jm5ic3A7Jm5ic3A7IFRoaXMg
bmVjZXNzaXRhdGVzIHRoYXQgdGhlIA0KICBwcm94eSBtYWludGFpbnMgdGhlIHNlc3Npb24gc3Rh
dGU8QlI+Jm5ic3A7Jm5ic3A7IGluZm9ybWF0aW9uIGFuZCBoZW5jZSBpdCANCiAgbmVlZHMgdG8g
cmVtYWluIGluLXBhdGggZm9yIHRoZSBlbnRpcmU8QlI+Jm5ic3A7Jm5ic3A7IHNlc3Npb24uPC9G
T05UPjwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij48L0ZPTlQ+Jm5ic3A7
PC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT0iQ291cmllciBOZXciIHNpemU9Mj4mbmJzcDsmbmJz
cDsgR2l2ZW4gdGhhdCB0aGVyZSBhcmUgY2FzZXMgDQogIHdoZXJlIGEgc3RhdGVmdWwgcHJveGll
cyBuZWVkIHRvIGJlIGluIHRoZTxCUj4mbmJzcDsmbmJzcDsgcm91dGluZyBwYXRoIG9mIGEgDQog
IHNlc3Npb24sIGEgZ2VuZXJpYyBkZXNjcmlwdGlvbiBvZiB0aGUgcHJvYmxlbSBpczxCUj4mbmJz
cDsmbmJzcDsgc2hvd24gaW4gDQogIEZpZ3VyZSAxLiZuYnNwOyBJbiB0aGlzIHNjZW5hcmlvIHRo
ZXJlIGlzIGEgcmVsYXkgaW4gdGhlIA0KICB2aXNpdGVkPEJSPiZuYnNwOyZuYnNwOyBuZXR3b3Jr
IChSZWxheTEpIGFuZCB0d28oMikgcHJveGllcyBpbiB0aGUgaG9tZSANCiAgbmV0d29yayAoUHJv
eHkyIGFuZDxCUj4mbmJzcDsmbmJzcDsgUHJveHkzKS4mbmJzcDsgUmVsYXkxIGlzIGNvbm5lY3Rl
ZCB0byANCiAgUHJveHkyIGFuZCBQcm94eTMgZm9yIHNjYWxhYmlsaXR5PEJSPiZuYnNwOyZuYnNw
OyBhbmQvb3IgcmVkdW5kYW5jeS4mbmJzcDsgSWYgDQogIGEgc2Vzc2lvbiBpcyBjb21wb3NlZCBv
ZiBzZXZlcmFsIHJlcXVlc3QvPEJSPiZuYnNwOyZuYnNwOyBhbnN3ZXIgZXhjaGFuZ2VzIGl0IA0K
ICBpcyBwb3NzaWJsZSB0aGF0IGVhY2ggcmVxdWVzdCBvZiB0aGUgc2Vzc2lvbjxCUj4mbmJzcDsm
bmJzcDsgdGFrZXMgZGlmZmVyZW50IA0KICBwYXRocyB0b3dhcmRzIHRoZSBIb21lIFNlcnZlci4m
bmJzcDsgQXMgYW4gZXhhbXBsZSwgaWY8QlI+Jm5ic3A7Jm5ic3A7IFJlbGF5MSANCiAgY2FuIHJv
dXRlIG1lc3NhZ2VzIHZpYSBQcm94eTIgb3IgUHJveHkzIGJhc2VkIG9uIHNvbWUgcG9saWN5PEJS
PiZuYnNwOyZuYnNwOyANCiAgaW5kZXBlbmRlbnQgb2YgdGhlIHNlc3Npb24gdGhlbiB0aGUgZmly
c3QgbWVzc2FnZSBvZiB0aGUgc2Vzc2lvbiANCiAgY2FuPEJSPiZuYnNwOyZuYnNwOyB0YWtlIHRo
ZSBwYXRoIENsaWVudC0mZ3Q7UmVsYXkxLSZndDtQcm94eTItJmd0O0hvbWUgU2VydmVyIA0KICB3
aGlsZSBzdWJzZXF1ZW50PEJSPiZuYnNwOyZuYnNwOyBtZXNzYWdlIGNhbiB0YWtlIHRoZSBwYXRo
IA0KICBDbGllbnQtJmd0O1JlbGF5MS0mZ3Q7UHJveHkzLSZndDtIb21lIFNlcnZlci4mbmJzcDsg
SW48QlI+Jm5ic3A7Jm5ic3A7IHRoaXMgDQogIGNhc2UgaWYgUHJveHkyIGlzIHN0YXRlZnVsIHRo
ZW4gaXQgZXhwZWN0cyB0byBwcm9jZXNzIG5vdCBvbmx5PEJSPiZuYnNwOyZuYnNwOyANCiAgdGhl
IGZpcnN0IG1lc3NhZ2UgYnV0IHN1YnNlcXVlbnQgcmVxdWVzdCBhcyANCiAgd2VsbC48QlI+Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICBWSVNJVEVEIE5FVFdPUksmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsgfCZuYnNwOyZuYnNwOyZuYnNwOyBIT01FIA0KICBORVRXT1JLPEJSPiZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyANCiAgfDxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg
Ky0tLS0tLS0tKyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgKy0tLS0tLS0tKyZuYnNwOyZu
YnNwOyB8Jm5ic3A7Jm5ic3A7IA0KICArLS0tLS0tLS0rPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyB8IENsaWVudCB8Jmx0Oy0tLSZndDt8IFJlbGF5MSANCiAgfCZsdDstLS0tLSZn
dDt8IFByb3h5MiB8PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgKy0tLS0t
LS0tKyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyArLS0tLS0tLS0rJm5ic3A7Jm5ic3A7IHwmbmJz
cDsmbmJzcDsgDQogICstLS0tLS0tLStcPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgXCZuYnNwOyANCiAgfCZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyANCiAgXCstLS0tLS0tLS0tLS0tKzxCUj4mbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsgDQogIFwgDQogIHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogIHwgSG9tZSBTZXJ2
ZXIgDQogIHw8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICBcfCZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyANCiAgLystLS0tLS0tLS0tLS0tKzxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsg
DQogIFwmbmJzcDsmbmJzcDsgDQogICstLS0tLS0tLSsvPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyANCiAgfC0tLXwgUHJveHkzIA0KICB8PEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyANCiAgfCZuYnNwOyZuYnNwOyArLS0tLS0tLS0rPEJSPjwvRk9OVD48L0RJVj48Rk9OVCBm
YWNlPUFyaWFsIHNpemU9Mj4NCiAgPERJVj48QlI+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZu
YnNwOyZuYnNwOyBGaWd1cmUgMTogR2VuZXJpYyBTdGF0ZWZ1bCANCiAgUHJveHkgUHJvYmxlbTwv
Rk9OVD48L0RJVj4NCiAgPERJVj48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+PC9GT05UPiZuYnNw
OzwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDsmbmJzcDsgSW4g
bGFyZ2VyIGRlcGxveW1lbnRzLCB0aGUgaXNzdWUgDQogIGNhbiBiZSBhZ2dyZXZhdGVkIHdoZW4g
dGhlcmUgYXJlIGE8QlI+Jm5ic3A7Jm5ic3A7IGdyZWF0ZXIgbnVtYmVyIG9mIHByb3h5IA0KICBu
b2RlcyBpbiBib3RoIHZpc2l0ZWQgYW5kIGhvbWUgbmV0d29ya3MgaW48QlI+Jm5ic3A7Jm5ic3A7
IEZpZ3VyZSAxLiZuYnNwOyANCiAgRnVydGhlciBlc2NhbGF0aW9uIG9mIHRoZSBwcm9ibGVtIG9j
Y3VycyBpZiB0aGUgZGVwbG95bWVudDxCUj4mbmJzcDsmbmJzcDsgDQogIGFkZHMgc3RhdGVsZXNz
IHJlbGF5cyBwcmVjZWRpbmcgYW55IG9mIHRoZSBwcm94eSBub2RlcyBpbiBGaWd1cmUgDQogIDEu
PC9GT05UPjwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij48L0ZPTlQ+Jm5i
c3A7PC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZuYnNwOyZuYnNwOyBJ
biBbUkZDMzU4OF0sIGl0IGlzIHBvc3NpYmxlIHRvIHVzZSANCiAgc3RhdGljIHJvdXRpbmcgYmV0
d2VlbiB0aGUgc291cmNlPEJSPiZuYnNwOyZuYnNwOyBhbmQgdGhlIHByb3h5IHRvIGVuc3VyZSBh
bGwgDQogIG1lc3NhZ2UgZXhjaGFuZ2VzIHRyYXZlcnNlcyB0aGUgcHJveHkgaW48QlI+Jm5ic3A7
Jm5ic3A7IHF1ZXN0aW9uLiZuYnNwOyANCiAgSG93ZXZlciwgc3RhdGljIHJvdXRpbmcgaW4gZ2Vu
ZXJhbCwgaW50cm9kdWNlcyBtYW55PEJSPiZuYnNwOyZuYnNwOyANCiAgbGltaXRhdGlvbnMuPC9G
T05UPjwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij48L0ZPTlQ+Jm5ic3A7
PC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPiZuYnNwOyZuYnNwOyBvJm5i
c3A7IFN0YXRpYyByb3V0aW5nIGltcGxpZXMgdGhhdCANCiAgYWxsIG1lc3NhZ2VzLCByZWdhcmRs
ZXNzIG9mIHNlc3Npb24sPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB3aWxsIA0K
ICBoYXZlIHRvIHRyYXZlcnNlIHRoZSBzYW1lIHByb3h5LiZuYnNwOyBUaGlzIGludHJvZHVjZXMg
YSANCiAgc2luZ2xlPEJSPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBwb2ludCBvZiBm
YWlsdXJlIGluIHRoZSByb3V0aW5nIHBhdGggDQogIGFuZCBhZmZlY3RzIGFueSBhbmQgYWxsPEJS
PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzZXNzaW9ucyByZWdhcmRsZXNzIA0KICBv
ZiB3aGV0aGVyIHRoZSBzZXNzaW9uIGlzIG9mIGludGVyZXN0IHRvIHRoZTxCUj4mbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsgDQogIHByb3h5LjwvRk9OVD48L0RJVj4NCiAgPERJVj48Rk9O
VCBmYWNlPSJDb3VyaWVyIE5ldyI+PC9GT05UPiZuYnNwOzwvRElWPg0KICA8RElWPjxGT05UIGZh
Y2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDsmbmJzcDsgbyZuYnNwOyBJdCBjb21wcm9taXNlcyBmYWls
b3ZlciANCiAgcHJvY2VkdXJlIGluIHRoZSBub2RlIGFkamFjZW50IHRvIHRoZTxCUj4mbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgcHJveHkgDQogIGFuZCBwcmVjZWRpbmcgaXQgaW4gdGhl
IHJlcXVlc3QgZm9yd2FyZGluZyBwYXRoLiZuYnNwOyANCiAgVGhpczxCUj4mbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsgYmVjb21lcyBhcHBhcmVudCBpZiB0aGUgYWRqYWNlbnQgbm9kZSAN
CiAgZXhwbGljaXRseSBhbmQgc3RhdGljYWxseTxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsgcm91dGVzIG9ubHkgDQogIHRvd2FyZHMgdGhlIHByb3h5LjwvRk9OVD48L0RJVj4NCiAg
PERJVj48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+PC9GT05UPiZuYnNwOzwvRElWPg0KICA8RElW
PjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDsmbmJzcDsgbyZuYnNwOyBJbiB0aGUgZXZl
bnQgb2YgbW9yZSANCiAgY29tcGxleCB0b3BvbG9naWVzIHdoZXJlIG11bHRpcGxlIHByb3hpZXMg
DQogIGFyZTxCUj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdHJhdmVyc2VkIGJldHdl
ZW4gc291cmNlIGFuZCANCiAgZGVzdGluYXRpb24sIHRoZSBhZG1pbmlzdHJhdGl2ZTxCUj4mbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYnVyZGVuIG9mIA0KICBzdGF0aWMgY29uZmlndXJh
dGlvbiBhbG9uZyB0aGUgcGF0aCBtYXkgYmUgY29uc2lkZXJhYmxlLjwvRk9OVD48L0RJVj4NCiAg
PERJVj48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+PC9GT05UPiZuYnNwOzwvRElWPg0KICA8RElW
PjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDsmbmJzcDsgbyZuYnNwOyBObyBwcm92aXNp
b24gZm9yIGxvYWQgDQogIGJhbGFuY2luZyBhcyBhbGwgdGhlIG5vZGVzIGluIHRoZSBwYXRoIHdp
bGw8QlI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IA0KICBiZSBzdWJqZWN0ZWQgdG8g
c3RhdGljIHJvdXRpbmcuPC9GT05UPjwvRElWPg0KICA8RElWPjxGT05UIGZhY2U9IkNvdXJpZXIg
TmV3Ij48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQogIDxESVY+PEZPTlQgZmFjZT0iQ291cmllciBOZXci
PiZuYnNwOyZuYnNwOyBDb25zaWRlcmluZyB0aGVzZSBsaW1pdGF0aW9ucywgYW4gDQogIGFsdGVy
bmF0aXZlIGFuZCBtb3JlIGR5bmFtaWMgbWV0aG9kPEJSPiZuYnNwOyZuYnNwOyBvZiBlc3RhYmxp
c2hpbmcgYW4gDQogIGV4cGxpY2l0IHJvdXRpbmcgaXMgcHJvcG9zZWQuPEJSPjwvRk9OVD48L0RJ
Vj4NCiAgPERJVj48Rk9OVCBmYWNlPSJDb3VyaWVyIE5ldyI+Qi4gUi48L0ZPTlQ+PC9ESVY+DQog
IDxESVY+PEZPTlQgZmFjZT0iQ291cmllciBOZXciPlRpbmE8L0RJVj48L0ZPTlQ+PC9GT05UPg0K
ICA8RElWPjxGT05UIGZhY2U9IkNvdXJpZXIgTmV3IiBzaXplPTI+PC9GT05UPiZuYnNwOzwvRElW
Pg0KICA8RElWPg0KICA8RElWPi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQogIDxESVY+
RnJvbTogIkdsZW4gWm9ybiAoZ3d6KSIgJmx0OzxBIA0KICBocmVmPSJtYWlsdG86Z3d6QGNpc2Nv
LmNvbSI+Z3d6QGNpc2NvLmNvbTwvQT4mZ3Q7PC9ESVY+DQogIDxESVY+VG86ICJWaWN0b3IgRmFq
YXJkbyIgJmx0OzxBIA0KICBocmVmPSJtYWlsdG86dmZhamFyZG9AdGFyaS50b3NoaWJhLmNvbSI+
dmZhamFyZG9AdGFyaS50b3NoaWJhLmNvbTwvQT4mZ3Q7OyANCiAgIlRzY2hvZmVuaWcsIEhhbm5l
cyIgJmx0OzxBIA0KICBocmVmPSJtYWlsdG86aGFubmVzLnRzY2hvZmVuaWdAc2llbWVucy5jb20i
Pmhhbm5lcy50c2Nob2ZlbmlnQHNpZW1lbnMuY29tPC9BPiZndDs8L0RJVj4NCiAgPERJVj5DYzog
Jmx0OzxBIGhyZWY9Im1haWx0bzpkaW1lQGlldGYub3JnIj5kaW1lQGlldGYub3JnPC9BPiZndDs8
L0RJVj4NCiAgPERJVj5TZW50OiBUdWVzZGF5LCBBdWd1c3QgMjIsIDIwMDYgNDozNCBBTTwvRElW
Pg0KICA8RElWPlN1YmplY3Q6IFJFOiBBVzogW0RpbWVdIE5leHQgU3RlcHMgZm9yIA0KICBkcmFm
dC10c291LWRpbWUtYmFzZS1yb3V0aW5nLWV4dC0wMDwvRElWPjwvRElWPg0KICA8RElWPjxCUj48
L0RJVj5WaWN0b3IgRmFqYXJkbyAmbHQ7PEEgDQogIGhyZWY9Im1haWx0bzp2ZmFqYXJkb0B0YXJp
LnRvc2hpYmEuY29tIj5tYWlsdG86dmZhamFyZG9AdGFyaS50b3NoaWJhLmNvbTwvQT4mZ3Q7IA0K
ICBzdXBwb3NlZGx5IHNjcmliYmxlZDo8QlI+PEJSPiZndDsgSGkgSGFubmVzLDxCUj4mZ3Q7Jmd0
OyBIaSANCiAgVmljdG9yLDxCUj4mZ3Q7Jmd0OyA8QlI+Jmd0OyZndDsgaW4gdGhlIGRpc2N1c3Np
b25zIHRoZSAzR1BQIFdMQU4gd29yayB3YXMgDQogIG1lbnRpb25lZCBhcyB0aGUgdXNhZ2U8QlI+
Jmd0OyZndDsgc2NlbmFyaW8uIDxCUj4mZ3Q7Jmd0OyBJcyBpdCBhIHJlYWwgcHJvYmxlbSANCiAg
aW4gdGhlaXIgZW52aXJvbm1lbnQ/IEkgaGF2ZSBuZXZlciBoZWFyZDxCUj4mZ3Q7Jmd0OyBzb21l
dGhpbmcgYWJvdXQgcHJvYmxlbXMgDQogIGFsb25nIHRoZXNlIGxpbmVzLiA8QlI+Jmd0OyZndDsg
PEJSPiZndDsgPEJSPiZndDsmbmJzcDsgRnJvbSB3aGF0IEkgDQogIHVuZGVyc3Rvb2QsIGl0IGlz
IGEgcHJvYmxlbSBlbnZpc2lvbmVkIGJ5IHNvbWUgZm9sa3M8QlI+Jmd0OyB3aGVuIHRyeWluZyB0
byANCiAgZGVwbG95IGRpYW1ldGVyIGluIHN1Y2ggZW52aXJvbm1lbnQuIEkgdGhpbmsgVGluYSBh
bmQ8QlI+Jmd0OyBvdGhlcnMgY2FuIHNoZWQgDQogIGxpZ2h0IGludG8gdGhpcyBiZXR0ZXIgdGhh
biBJIGNhbi4mbmJzcDsgPEJSPjxCUj5JLCBmb3Igb25lLCB3b3VsZCBfcmVhbGx5XyANCiAgbGlr
ZSB0byBoZWFyIHRoaXMuPEJSPjxCUj4uLi48QlI+PEJSPkhvcGUgdGhpcyBoZWxwcyw8QlI+PEJS
Pn5nd3o8QlI+PEJSPldoeSANCiAgaXMgaXQgdGhhdCBtb3N0IG9mIHRoZSB3b3JsZCdzIHByb2Js
ZW1zIGNhbid0IGJlIHNvbHZlZCBieSBzaW1wbHk8QlI+Jm5ic3A7IA0KICBsaXN0ZW5pbmcgdG8g
Sm9obiBDb2x0cmFuZT8gLS0gSGVucnkgDQogIEdhYnJpZWw8QlI+PEJSPl9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPEJSPkRpTUUgbWFpbGluZyANCiAgbGlz
dDxCUj48QSBocmVmPSJtYWlsdG86RGlNRUBpZXRmLm9yZyI+RGlNRUBpZXRmLm9yZzwvQT48QlI+
PEEgDQogIGhyZWY9Imh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWUi
Pmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWU8L0E+PC9ESVY+DQog
IDxQPg0KICA8SFI+DQoNCiAgPFA+PC9QPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fPEJSPkRpTUUgbWFpbGluZyANCiAgbGlzdDxCUj5EaU1FQGlldGYub3Jn
PEJSPmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RpbWU8QlI+PC9CTE9D
S1FVT1RFPjwvQk9EWT48L0hUTUw+DQo=

--Boundary_(ID_QYjNrhRvKQsh+dG8y4Xhgg)--


--===============1496910596==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============1496910596==--




From dime-bounces@ietf.org Mon Aug 28 09:13:30 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GHgvb-0003Ac-SY; Mon, 28 Aug 2006 09:13:23 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GHgva-0003AV-Uw
	for dime@ietf.org; Mon, 28 Aug 2006 09:13:22 -0400
Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129]
	helo=chiedprmail1.ietf.org)
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GHgW2-0003TB-Vr
	for dime@ietf.org; Mon, 28 Aug 2006 08:46:59 -0400
Received: from bw.ulticom.com ([208.255.120.38])
	by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GHgMZ-0002I3-KS
	for dime@ietf.org; Mon, 28 Aug 2006 08:37:15 -0400
Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP
	id 5E65E2B68C; Mon, 28 Aug 2006 08:37:04 -0400 (EDT)
Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55])
	by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k7SCavxB022075;
	Mon, 28 Aug 2006 08:36:58 -0400 (EDT)
From: "Tolga Asveren" <asveren@ulticom.com>
To: "Tina TSOU" <tena@huawei.com>, "Glen Zorn (gwz)" <gwz@cisco.com>,
	"Victor Fajardo" <vfajardo@tari.toshiba.com>,
	"Tschofenig, Hannes" <hannes.tschofenig@siemens.com>
Subject: RE: AW: [Dime] Next Steps for draft-tsou-dime-base-routing-ext-00
Date: Mon, 28 Aug 2006 08:36:19 -0400
Message-ID: <GBEBKGPKHGPAOFCLBNAMCEBGEIAA.asveren@ulticom.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="gb2312"
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 V6.00.2800.1506
Importance: Normal
In-Reply-To: <003501c6c8b6$9bcf6060$4e95460a@china.huawei.com>
Received-SPF: none
X-Spam-Score: -2.5 (--)
X-Scan-Signature: bf422c85703d3d847fb014987125ac48
Cc: dime@ietf.org
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

IMHO, the problems Tina explained (and which are also explained in tne
draft) need to be addressed, so I think the draft defines a useful
mechanism.


The problems I see with the draft are:
a)It defines two different functionalities, they need to be separated.
b)It doesn't mention about alternative solutions (using stateful agents,
using ALG type approach to regenerate messages etc..). I don't know whether
this should be a different draft though (one about possible solutions for
"how to stay on the message path during the session" problem and one
defining the mechanism described in the draft, where it is referred to from
the first one)

    Thanks,
    Tolga


-----Original Message-----
From: Tina TSOU [mailto:tena@huawei.com]
Sent: Friday, August 25, 2006 10:23 PM
To: Glen Zorn (gwz); Victor Fajardo; Tschofenig, Hannes
Cc: dime@ietf.org
Subject: Re: AW: [Dime] Next Steps for draft-tsou-dime-base-routing-ext-00


Hi all,
Furthermore,
1) What scenario is there Diameter Relay?
Between home network and visit network, one network (e.g. visit network)
does not want to expose the IP address of all its AAA servers to the other
network (e.g. home network). So, visit network puts a Diameter Relay as the
single contact point for home network. At the same time, it reduces the
connections number between home network and visit network.

2) What scenario is this Diameter Relay connected to two Diameter Proxies?
The capability of one Diameter Proxy is not enough to process all the users
in one network. One network has more than 1,000,000 users. However, one
Diameter Proxy has the capability of 1,000,000 users. Hence, more than one
Diameter Proxies are needed in this network.

Have a great weekend:)

B. R.
Tina
----- Original Message -----
From: Tina TSOU
To: Tschofenig, Hannes ; Victor Fajardo ; Glen Zorn (gwz)
Cc: dime@ietf.org
Sent: Wednesday, August 23, 2006 10:44 AM
Subject: Re: AW: [Dime] Next Steps for draft-tsou-dime-base-routing-ext-00


Hi all,
   In [RFC3588], routing of request messages from source to the
   destination is based solely on the routing decision made by each node
   along the path.  In a topology where multiple paths are possible from
   source to destination, it is not guaranteed that all messages
   constituting a session will take the same path.  For a proxy node
   residing along a path that maintains stateful information for a
   session, it is desirable that it remains in the routing path of all
   message exchanges of that a session.

   In general, a session which comprises of multiple message exchanges
   and requires intermediary proxy functions will require explicit
   routing for all request messages within that session.  An example of
   a stateful proxies are in the WLAN 3GPP IP access [TS23.234].  The
   WLAN Access Network (WLAN AN) can use Diameter EAP with the 3GPP AAA
   server or proxy for authentication & authorization.  In the roaming
   case, the WLAN AN is communicating with a 3GPP AAA Proxy in the
   visited network over the Wa reference point.  The 3GPP AAA proxy is
   then connected to the 3GPP Server in the home network over the Wd
   reference point.  The 3GPP AAA Proxy among its many functions will
   enforce local policies on access based on agreement with the 3GPP
   Home Network and with the WLAN operator.  It will also send per user
   charging information for the session to the Offline Charging system.
   This necessitates that the proxy maintains the session state
   information and hence it needs to remain in-path for the entire
   session.

   Given that there are cases where a stateful proxies need to be in the
   routing path of a session, a generic description of the problem is
   shown in Figure 1.  In this scenario there is a relay in the visited
   network (Relay1) and two(2) proxies in the home network (Proxy2 and
   Proxy3).  Relay1 is connected to Proxy2 and Proxy3 for scalability
   and/or redundancy.  If a session is composed of several request/
   answer exchanges it is possible that each request of the session
   takes different paths towards the Home Server.  As an example, if
   Relay1 can route messages via Proxy2 or Proxy3 based on some policy
   independent of the session then the first message of the session can
   take the path Client->Relay1->Proxy2->Home Server while subsequent
   message can take the path Client->Relay1->Proxy3->Home Server.  In
   this case if Proxy2 is stateful then it expects to process not only
   the first message but subsequent request as well.
              VISITED NETWORK     |    HOME NETWORK
                                  |
      +--------+     +--------+   |   +--------+
      | Client |<--->| Relay1 |<----->| Proxy2 |
      +--------+     +--------+   |   +--------+\
                               \  |              \+-------------+
                                \ |               | Home Server |
                                 \|              /+-------------+
                                  \   +--------+/
                                  |---| Proxy3 |
                                  |   +--------+


   Figure 1: Generic Stateful Proxy Problem

   In larger deployments, the issue can be aggrevated when there are a
   greater number of proxy nodes in both visited and home networks in
   Figure 1.  Further escalation of the problem occurs if the deployment
   adds stateless relays preceding any of the proxy nodes in Figure 1.

   In [RFC3588], it is possible to use static routing between the source
   and the proxy to ensure all message exchanges traverses the proxy in
   question.  However, static routing in general, introduces many
   limitations.

   o  Static routing implies that all messages, regardless of session,
      will have to traverse the same proxy.  This introduces a single
      point of failure in the routing path and affects any and all
      sessions regardless of whether the session is of interest to the
      proxy.

   o  It compromises failover procedure in the node adjacent to the
      proxy and preceding it in the request forwarding path.  This
      becomes apparent if the adjacent node explicitly and statically
      routes only towards the proxy.

   o  In the event of more complex topologies where multiple proxies are
      traversed between source and destination, the administrative
      burden of static configuration along the path may be considerable.

   o  No provision for load balancing as all the nodes in the path will
      be subjected to static routing.

   Considering these limitations, an alternative and more dynamic method
   of establishing an explicit routing is proposed.

B. R.
Tina

----- Original Message -----
From: "Glen Zorn (gwz)" <gwz@cisco.com>
To: "Victor Fajardo" <vfajardo@tari.toshiba.com>; "Tschofenig, Hannes"
<hannes.tschofenig@siemens.com>
Cc: <dime@ietf.org>
Sent: Tuesday, August 22, 2006 4:34 AM
Subject: RE: AW: [Dime] Next Steps for draft-tsou-dime-base-routing-ext-00


Victor Fajardo <mailto:vfajardo@tari.toshiba.com> supposedly scribbled:

> Hi Hannes,
>> Hi Victor,
>>
>> in the discussions the 3GPP WLAN work was mentioned as the usage
>> scenario.
>> Is it a real problem in their environment? I have never heard
>> something about problems along these lines.
>>
>
>  From what I understood, it is a problem envisioned by some folks
> when trying to deploy diameter in such environment. I think Tina and
> others can shed light into this better than I can.

I, for one, would _really_ like to hear this.

...

Hope this helps,

~gwz

Why is it that most of the world's problems can't be solved by simply
  listening to John Coltrane? -- Henry Gabriel

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



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


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



From dime-bounces@ietf.org Wed Aug 30 16:35:34 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GIWmW-00015P-0n; Wed, 30 Aug 2006 16:35:28 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GIWmV-00015K-20
	for dime@ietf.org; Wed, 30 Aug 2006 16:35:27 -0400
Received: from bw.ulticom.com ([208.255.120.38])
	by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GIWmT-0006S2-OK
	for dime@ietf.org; Wed, 30 Aug 2006 16:35:27 -0400
Received: from colby.ulticom.com (colby.ulticom.com [192.73.206.10])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by bw.ulticom.com (BorderWare MXtreme Mail Firewall) with ESMTP id
	9C41EA3E58 for <dime@ietf.org>; Wed, 30 Aug 2006 16:35:22 -0400 (EDT)
Received: from pcasveren (pc-asveren.ulticom.com [172.25.33.55])
	by colby.ulticom.com (8.13.4/8.12.10) with SMTP id k7UKZLZd018881
	for <dime@ietf.org>; Wed, 30 Aug 2006 16:35:21 -0400 (EDT)
From: "Tolga Asveren" <asveren@ulticom.com>
To: <dime@ietf.org>
Date: Wed, 30 Aug 2006 16:35:04 -0400
Message-ID: <GBEBKGPKHGPAOFCLBNAMMEDFEIAA.asveren@ulticom.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-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 V6.00.2800.1506
Importance: Normal
Received-SPF: none
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d
Subject: [Dime] A draft about duplicate detection considerations
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

Hi All,

I recently submitted a draft:

http://www.ietf.org/internet-drafts/draft-asveren-dime-dupcons-00.txt

It discusses some implementation issues like buffering requirements for
different types of requests, End-to-End Id selection criteria, memory
requirements for duplicate detection etc..

I also added a few methods to make duplicate detection more implementation
friendly without defining anything new from on-the-wire protocol point of
view.

Overall, I hope this document can be the basis for some discussion in the
mailing list about duplicate detection implementation so that it can be
determined whether any protocol level improvements are necessary.

I believe with input from people, it could be also a nice
Best-Current-Practices type of document for duplicate detection
implementation, providing some guidance to implementors.


Your comments are highly appreciated.


    Thanks,
     Tolga


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



From dime-bounces@ietf.org Thu Aug 31 18:07:33 2006
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com)
	by megatron.ietf.org with esmtp (Exim 4.43)
	id 1GIuhB-00052C-BN; Thu, 31 Aug 2006 18:07:33 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org)
	by megatron.ietf.org with esmtp (Exim 4.43) id 1GIuh9-00051u-SB
	for dime@ietf.org; Thu, 31 Aug 2006 18:07:31 -0400
Received: from mail.gmx.de ([213.165.64.20] helo=mail.gmx.net)
	by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GIuh6-0004uR-Ee
	for dime@ietf.org; Thu, 31 Aug 2006 18:07:31 -0400
Received: (qmail invoked by alias); 31 Aug 2006 22:07:26 -0000
Received: from p54985631.dip.t-dialin.net (EHLO [192.168.2.33]) [84.152.86.49]
	by mail.gmx.net (mp016) with SMTP; 01 Sep 2006 00:07:26 +0200
X-Authenticated: #29516787
Message-ID: <44F75D9B.6030808@gmx.net>
Date: Fri, 01 Sep 2006 00:07:23 +0200
From: Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: dime@ietf.org
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
X-Spam-Score: 0.1 (/)
X-Scan-Signature: 79899194edc4f33a41f49410777972f8
Subject: [Dime] Diameter MIPv6 Bootstrapping: App-ID vs. Service-Type 
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/dime>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dime>,
	<mailto:dime-request@ietf.org?subject=subscribe>
Errors-To: dime-bounces@ietf.org

Hi all,

we have had long discussions about the App-ID vs. Service-Type usage for 
Diameter MIPv6 Bootstrapping.

It is time to see what the group thinks. Please indicate whether you 
prefer (1) an App-ID or (2) a Service-Type solution for

(a) NAS-to-AAAH communication (as required by the integrated scenario; 
as one part of the solution component)

(b) HA-to-AAAH communication (as used by the split scenario and the 
integrated scenario)

It might be useful to state a reason for your decision.

Please also indicate whether some aspects are still unclear to you.

Ciao
Hannes

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