Re: Comments on draft-adrangi-radius-extension-for-pwlan-00.txt

[Jari Arkko <jari.arkko@piuha.net>]

Adrangi, Farid wrote:

> 1) Define a format/syntax by which the information can be represented
> (i.e., what
>    is currently being defined in the draft)
> 2) Use Subtypes (there has been some discussion on the mailing list;
> however, I
>    am not sure about the final conclusion)
> 3) Separate attributes
>
> We are not locked on a particular approach and open to ideas and
> suggestions.  Do 
> you have any suggestion how we can reach consensus on this?  Do you want
> me to revise
> the draft to include all three format/syntax with pros and cons of each?

Not really. One way is enough. Its up to the WG what that way is of course --
my preference is alt 3.

> >  o  Address type "Public and Private": I have trouble
> >     seeing how this works in IPv4.
>
>
> [FA] There are two aspects to this feature.  One is to enable Access
> Network
> to advertise its capability about private or public address assignment
> for a
> given WLAN client, and to enable the home RADIUS server to specify the
> desired
> address type option.  The other is how the Access Network is going to
> enforce
> the specified address type option (private or public address) when the
> client 
> does a DHCP request - which IMO, this is outside the scope of the
> document and 
> perhaps we should be more explicit about it.  Which aspect of the
> feature do 
> you have problem with? [FA]

1) Presumably, lack of indication about the address type from the
home network would be taken as either type being acceptable? If
yes, public+private option may not be necessary.

2) If you were to *enforce* the selection from the home network,
then public+private option would not work.

3) I get a bit worried that lack of enforcement is going to
cause problems. Is it a general approach for AAA attributes
from the home server to be hints? Is someone's billing going
to be based on a public or private address being provided?
Or is this simply a result of backwards compatibility i.e.
we do not wish to disable access from NASes that do not
yet support these new attributes?

> >  o  Sect 2.7 overlaps with draft-black. I liked the
> >     draft-black approach better.
>
>
> [FA] Yes, there is an overlap between two drafts.  We should definitely
> discuss which
> method is better - we also think there is a need for an access network
> to advertise
> its network rate capability as well. I am currently making some changes
> to the text 
> and the format/syntax. [FA]

Ok. Thanks for your response.

--Jari



--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>