AW: : The Diameter Maintanence and Extentions WG proposed charter
"Tschofenig, Hannes" <[email protected]> Thu, 1 Dec 2005 14:45:12 +0100
| Newsgroups | gmane.ietf.aaa |
|---|---|
| Message-ID | <ECDC9C7BC7809340842C0E7FCF48C393A80097@MCHP7IEA.ww002.siemens.net> |
hi julien,=20 to me it still seems that we do not understand all details yet and = therefore i am not sure whether we need a new application for either = fmip or mip6 aaa interaction.=20 cannot we make a decision about one or two documents once we know the = details much better?=20 ciao hannes > -----Urspr=FCngliche Nachricht----- > Von: [email protected] [mailto:[email protected]]=20 > Im Auftrag von Julien Bournelle > Gesendet: Donnerstag, 1. Dezember 2005 11:36 > An: Tschofenig, Hannes > Cc: Julien Bournelle; [email protected];=20 > [email protected]; [email protected] > Betreff: Re: [AAA-WG]: The Diameter Maintanence and=20 > Extentions WG proposed charter >=20 > Hi hannes, >=20 > On Thu, Dec 01, 2005 at 10:57:13AM +0100, Tschofenig, Hannes wrote: > > hi julien,=20 > >=20 > > we are not fully sure what fmip and mip really requires.=20 >=20 > for mip6 bootstrapping, we have 2 solutions: integrated and split.=20 > =20 > In > the integrated scenario, we assume that the MN is authenticated for > network access and thus we implicitely assume that Diameter=20 > NASREQ/EAP > is used. At the end of the authentication, the AAAH sends a=20 > HA address > to the NAS. So, a priori we only need this AVP. >=20 > In the split scenario, the AAA exchange occurs between the=20 > HA and AAA. > And IKEv2 is used between MN and HA. So Diameter EAP should be used > between HA and the AAA to carry the EAP packets. As it is a=20 > HA and not > a NAS, we "may" define a specific application. >=20 > for fmip6, we might reuse Diameter NASREQ, but why not define a new > Diameter Application since what we want to do is really do=20 > AAA for the > FMIP6 service and not for network access. >=20 > > we have started with some thoughts but more input is needed.=20 >=20 > I agree=20 > >=20 > > i do not see a problem with the fact that the protocols are=20 > developed in > > different working groups. >=20 > the only problem that I can see is time. Maybe of one these=20 > 2 WGs might > require AAA before the other. If we have a single document,=20 > we'll have > to wait for both agreements. that's just my concern. >=20 ciao hannes > Julien >=20 > >=20 > > ciao > > hannes > >=20 > > > On Thu, Dec 01, 2005 at 11:07:21AM +0200,=20 > > > [email protected] wrote: > > > > Julien, > > > >=20 > > > > >> For the purposes of the DiME WG proposal, I think I am=20 > > > still lumping=20 > > > > >> MIPv6, FMIPv6 & MIPv6 bootstrapping into one topic. I=20 > > > think having a > > > >=20 > > > > >> single AAA document that addresses these points probably=20 > > > would be=20 > > > > >> useful. > > > > > > > > > > I don't think that we can have one document for all these=20 > > > > > things. You can use Mobile IPv6 without FMIP6.=20 > > > >=20 > > > > I look at FMIPv6 as an optional extension for MIPv6. So,=20 > > > if you need > > > > AAA support for FMIPv6, then you probably will need to=20 > also have AAA > > > > support for MIPv6. However, if you are looking at only=20 > MIPv6, then > > > > any extensions to support FMIPv6 would be purely optional. > > >=20 > > > yes you're right.=20 > > > =20 > > > On the other hand, what makes me think that 2 documents could be > > > better are the following arguments: > > >=20 > > > - FMIP6 is from the mipshop WG whereas MIP6 is from the=20 > mip6 WG.=20 > > > - FMIP6 probably requires a new Diameter Application=20 > whereas MIP6 > > > bootstrapping requires only AVPs. > > >=20 > > > Julien > > >=20 > > > >=20 > > > > >> However, as the MIP/FMIP work is still on-going, we can=20 > > > address this=20 > > > > >> after there is consensus in the mobility-related WGs=20 > about what=20 > > > > >> specifically is needed. > > > > >>=20 > > > > >> Does this sound reasonable? > > > > > > > > > > It sounds totally reasonable. > > > >=20 > > > > Good. > > > >=20 > > > > John > > >=20 > > > --=20 > > > julien.bournelle at int-evry.fr > > >=20 >=20 > --=20 > julien.bournelle at int-evry.fr >=20