Subject: RE: About the NAP/ISP distinction in the usage-scenarios draft...

From: <[email-masked]>
Date: Mon, 13 Jan 2003 14:23:15 +0200

> -----Original Message-----
> From: ext Alper E. YEGIN [mailto:[email-masked]]
> Sent: 10 January, 2003 20:07
> To: Forsberg Dan (NRC/Helsinki); [email-masked]
> Cc: [email-masked]; Patil Basavaraj (NET/Dallas);
> [email-masked]
> Subject: Re: About the NAP/ISP distinction in the usage-scenarios
> draft...
> 
> 
> > Generally speaking, there could be multiple hops between EP 
> and PaC. So,
> why to limit this with a requirement. A more general 
> requirement could be to
> limit the number of hops between PAA and it's related EPs, if 
> that is really
> needed.
> >
> 
> There is no requirement regarding the number of hops between 
> the EP and PaC.
> But there is one for between PAA and PaC. The decision was to require
> them to be one hop away, because having multiple hops incurs 
> complexity
> which
> was not justified by an essential usage scenario.
> 
> alper
> 

This requirement means that a PaC client can't use PANA protocol from an access network (AN) that doesn't support PANA, even if there were networks that support PANA behind the AN :). This is an issue that affects the transition period.

Anyway, keeping this requirement prevents walled garden networks. And for me it doesn't make sense, since we are using IP as the transport mechanism.

Do you mean the PAA discovery with the incurring complexity? It would be nice to know (maybe I haven't read all the docs, though).

HTTP redirect is used for authentication. With this requirement PANA will not be in the same scope. On the second hand in the access networks EAP over Ethernet is pretty strong. So, where is PANA going to be if it doesn't even make it theoretically possible to combine these too..  there are VPNs too.

- Dan

---

From: "Alper E. YEGIN" <[email-masked]>
Date: Mon, 13 Jan 2003 12:20:31 -0800

> This requirement means that a PaC client can't use PANA protocol from an
access network (AN) that doesn't support PANA, even if there were networks
that support PANA behind the AN :). This is an issue that affects the
transition period.

Yes, if an access network wants to use PPP, or 802.1x, or PANA for
authentication, it has to place the right set of protocol entities in
the right place on the network. Enabling use of PANA thorugh access networks
that are not aware of this protocol does not sound too practical (or needed)
to me.

> Anyway, keeping this requirement prevents walled garden networks. And for
me it doesn't make sense, since we are using IP as the transport mechanism.

I'm not sure I understand this. Are you talking about the limited free
access
networks as described in section 4.6 of the usage scenarios draft? If so,
implementation of that scenario doesn't necessarily require the PAA to be
multiple hops away from the PaC.

> Do you mean the PAA discovery with the incurring complexity? It would be
nice to know (maybe I haven't read all the docs, though).

Yes. Requiring PAA be on the same hop enables a tighter system that
has less problems to worry about (security threats, discovery, IP
address configuration required, etc.)

> HTTP redirect is used for authentication. With this requirement PANA will
not be in the same scope. On the second hand in the access networks EAP over
Ethernet is pretty strong. So, where is PANA going to be if it doesn't even
make it theoretically possible to combine these too..  there are VPNs too.

I think the problem statement and usage scenarios draft answers this
question.

alper