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