Subject: Re: Re: List of Open Issues II

From: Paal Engelstad <[email-masked]>
Date: Wed, 13 Feb 2002 1:33:29 +0100

Reinaldo, Alper,

> 
> Fra: "Alper Yegin" <[email-masked]>
> Dato: 2002/02/13 Wed AM 12:41:22 CET
> Til: "Paal Engelstad" <[email-masked]>, 
>    "Reinaldo Penno" <[email-masked]>,  <[email-masked]>
> Tema: Re: Re: List of Open Issues II
> 
> Paal,
> 
> > > Let me register my opinion on the following..
> > >
> > > > 5 - Device Identifier and Multicast Addresses. (Open)
> > > >
> > > > In the requirements it is said that.
> > > >
> > > > "Device Identifier (DI)
> > > >
> > > > The identifier used by the network as a handle to
> > > >
> > > > ...<snip>...<snip>...
> > > >
> > > > At most one PANA client should be associated with a DI
> > > > on a PANA authentication agent. "
> >
> > It was me who questioned this sentence. You can have duplicate DIs if you
> have 2 different PaCs on the same device.
> >
> 
> With PANA, the "device" gets the network access, not "a user on that
> device". Therefore
> PANA cannot make this distinction that you are looking for (each one of the
> users of a device
> getting different network access).  section 4.1.1. states that. Getting into
> "user authentication" is
> a slippery slope which we should stay away... IMHO.
> 
> alper
> 

Alper: I see your point, and I think it is a very good one.

Reinaldo: I think you thus can "close" this issue too.

Thanks for the clarifications,
Paal

> 
> 
> > I do not see why the PANA protocol should mandate that the "early bird" is
> the one be authenticated. Can't we leave this up to the implementors. It is
> a policy decision. This simple way of arbitration of a conflict may be good
> in some cases, but not necessarily all. That is why I wondered if we just
> remove it.
> >
> > If we do, how to deal with multicast would also be a policy decision that
> implementors/administartors/operators can make.
> >
> > This point is not very important to me, though. I just want to see the
> PANA protocol release 1 up an running. (Details and improvements can be
> addressed in release 2).
> >
> > Does anyone have an opinion?
> >
> > Paal
> >
> > > >
> > > > Given that the DI can an IP address, this means that
> > > > in the multicast case you cannot use DI as an
> > > > identifier (since several clients would be associated
> > > > with a DI), or we need to change the above definition
> > > > a little.
> > > >
> > > > So the main question is: Would that be a case where
> > > > you want to grant access to all members of a multicast
> > > > group without caring to know each client individually?
> > >
> > > I don't think we need to deal with multicast IP address as DI.
> > > DI can be used as the source of outgoing traffic and destination
> > > of incoming traffic. As such, a multicast IP address as DI doesn't
> > > make sense. Granting access to multicast members seem outside the scope
> > > to me. Are there similar protocols that handle this case?
> > >
> > > alper
> > >
> > >
> >
> >
> 
>