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

["Adrangi, Farid" <farid.adrangi@intel.com>]

Hello Jari,

Thanks for taking time and reading the draft, and for your excellent 
comments (as always).  Although these attributes were motivated by 
PWLAN roaming, they could be used as a general LAN attributes - a we
agreed in BoF, we need to change the wording to make this clear though.
we are currently working with GSMA and PA3 to finalize the details 
of these attributes and we will also have some additional attributes.
We are planning to send out a revised version to the RadiusExt mailing
List before Jan 31 of 2004 for review/discussion.

Please see my replies inline.  
BR,
Farid

> -----Original Message-----
> From: Jari Arkko [mailto:jari.arkko@piuha.net] 
> Sent: Monday, December 15, 2003 4:56 AM
> To: 'radiusext@ops.ietf.org'; Adrangi, Farid
> Subject: Comments on draft-adrangi-radius-extension-for-pwlan-00.txt
> 
> 
> 
> I have read
> 
>    
> http://www.ietf.org/internet-drafts/draft-adrangi-radius-exten
> sion-for-pwlan-00.txt
> 
> and have some questions and comments:
> 
>   o  I have stated previously that I would in general like to
>      see separate attributes rather than a new syntax within
>      a value. The location attribute would be more useful with
>      separate attributes for city etc, imho.
> 
>      And again, this is pretty general, not tied to PWLANs...
> 

[FA] I understand your point.  We also debated this among us, we are not
locked
on a particular Format /syntax to indicate the location related
information. 
We discussed three possibilities (not in any particular order) in the
time when
we are working on the first version:

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?


Since the submission of this draft, we have made some changes to the
attributes based
on the discussions that we had in recent GSMA meetings.  We will be
submitting a 
revised version soon. [FA]

>   o  I dislike the Sect 2.2 string syntax, as it is hard
>      to make this really work in a consistent manner across
>      vendors and organizations. A standardized bit pattern
>      approach would be better, IMHO. Then again, I'm not sure
>      whether we should really extend RADIUS with a feature
>      capabilities discovery.
> 

[FA] Ok. So, I suggest we discuss the usefulness of this attribute
before we
dive into the syntax (which we are open to suggestions and ideas).  
Why do you think this is not a useful attribute?  [FA]

>   o  I like the address range accounting control attributes.
> 
>   o  Sect 2.6 (address type) does not describe what to do
>      for IPv6... make it clear that it applies to IPv4
>      only, or?
> 
[FA] Ok. Will do so. [FA]

>   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]

>   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]

> --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/>