Subject: RE: Encoding of Location-Id and Location-Name in draft-black-radi us-lanedge-00.txt
From: Avi Lior <[email-masked]>
To: 'Richard Perlman' <[email-masked]>, Avi Lior <[email-masked]>
Cc: "BLACK,CHUCK (HP-Roseville,ex1)" <[email-masked]>, "CONGDON,PAUL (HP-Roseville,ex1)" <[email-masked]>, [email-masked]
Date: Tue, 30 Dec 2003 13:43:27 -0500

Richard,

First, maybe for an enterpirse level RADIUS sever performance is not an
issue but for a carrier grade products performance is definetly an issue.

I don't think I would load up the location attributes in a dictionary.  TLVs
just make it easier to extract the attribute.

Instead of parsing " location-name = foobar,  address = 123 Main Street, " ;
we have using the TLV encoding

0106foobar0215123 Main Street

Where 01 is the location-name followed by the length of 6 and the value
"foobar" 2 is the address field etc... This is far quicker to parse and more
compact.

In both cases you will use the hash tables etc....

The only thing you add to the dictionary is the type 1 for location-name 2
for address etc...

> -----Original Message-----
> From: Richard Perlman [mailto:[email-masked]] 
> Sent: December 29, 2003 12:50 PM
> To: 'Avi Lior'
> Cc: BLACK,CHUCK (HP-Roseville,ex1); CONGDON,PAUL 
> (HP-Roseville,ex1); [email-masked]
> Subject: Re: Encoding of Location-Id and Location-Name in 
> draft-black-radius-lanedge-00.txt
> 
> 
> Avi:
> 
> I am not sure that the parsing of a string is all that much 
> more difficult. Given an arbitrarily large base of locations, 
> you would probably search a hashed list anyways, and strings 
> are a lot easier for people to manage in some table or file 
> rather than having to add value assignments to a dictionary.
> 
> Richard
> 
> On 12/29/03 09:17, "BLACK,CHUCK (HP-Roseville,ex1)" 
> <[email-masked]>
> wrote:
> 
> > Hi Avi,
> > 
> > The encoding of Location-ID is identical to that proposed 
> by the Wi-Fi 
> > Alliance in it's WISPr document in section 5.2 for their 
> "Location-ID" 
> > attribute.  I'm not sure where that encoding originated, so I'm not 
> > sure if there are other applications which make use of it or not.
> > 
> > There have been discussions regarding making attributes such as 
> > Location-ID into a common (not vendor-specific) attribute.  
> Since it 
> > may be used widely, whichever encoding format is preferable (the 
> > current WISPr or else TLV) should be chosen.  Perhaps there 
> are others 
> > who have knowledge of why and how the WISPr Location-ID format was 
> > chosen, and could add their input here.
> > 
> > /chuck
> > 
> > 
> > -----Original Message-----
> > From: Avi Lior [mailto:[email-masked]]
> > Sent: Monday, December 22, 2003 2:03 PM
> > To: 'CONGDON,PAUL (HP-Roseville,ex1)'; BLACK,CHUCK 
> (HP-Roseville,ex1); 
> > [email-masked]
> > Subject: Encoding of Location-Id and Location-Name in 
> > draft-black-radius-l anedge-00.txt
> > 
> > 
> > Hi Paul, Chuck
> > 
> > I have an issue with Location-ID and Location-Name.
> > 
> > Since these attribute may appear in an Access-Request message, I 
> > assume that they would be used by RADIUS in evaluating policy.  
> > Therefore I would not want these encoded as a string the 
> way you have 
> > it.  I would rather see a more efficient encoding scheme, one that 
> > would make it faster for RADIUS to parse.
> > 
> > In discussions on this list I proposed to use a single 
> attribute that 
> > is of type string (the same as yours) that would encode the 
> > information using TLV. Both of these schemes provide for 
> extensibility 
> > and optionality.  But the TLV approach as an advantage that it is 
> > easier to parse for RADIUS ( we don't want to slow RADIUS 
> down), and 
> > is more compact.  The encoding approach in your document is human 
> > readable.
> > 
> > IMO the string encoding you propose would be okay if it 
> already has an 
> > application that expects this type of encoding.
> > 
> > --
> > to unsubscribe send a message to 
> [email-masked] with 
> > the word 'unsubscribe' in a single line as the message text body.
> > archive: <http://psg.com/lists/radiusext/>
> > 
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 29 Dec 2003 17:50:48 +0000
Date: Mon, 29 Dec 2003 09:50:16 -0800
Subject: Re: Encoding of Location-Id and Location-Name in draft-black-radius-lanedge-00.txt
From: Richard Perlman <[email-masked]>
To: "'Avi Lior'" <[email-masked]>
CC: "BLACK,CHUCK (HP-Roseville,ex1)" <[email-masked]>, "CONGDON,PAUL (HP-Roseville,ex1)" <[email-masked]>, <[email-masked]>

Avi:

I am not sure that the parsing of a string is all that much more difficult.
Given an arbitrarily large base of locations, you would probably search a
hashed list anyways, and strings are a lot easier for people to manage in
some table or file rather than having to add value assignments to a
dictionary.

Richard

On 12/29/03 09:17, "BLACK,CHUCK (HP-Roseville,ex1)" <[email-masked]>
wrote:

> Hi Avi,
> 
> The encoding of Location-ID is identical to that proposed by the Wi-Fi
> Alliance in it's WISPr document in section 5.2 for their "Location-ID"
> attribute.  I'm not sure where that encoding originated, so I'm not sure if
> there are other applications which make use of it or not.
> 
> There have been discussions regarding making attributes such as Location-ID
> into a common (not vendor-specific) attribute.  Since it may be used widely,
> whichever encoding format is preferable (the current WISPr or else TLV)
> should be chosen.  Perhaps there are others who have knowledge of why and
> how the WISPr Location-ID format was chosen, and could add their input here.
> 
> /chuck
> 
> 
> -----Original Message-----
> From: Avi Lior [mailto:[email-masked]]
> Sent: Monday, December 22, 2003 2:03 PM
> To: 'CONGDON,PAUL (HP-Roseville,ex1)'; BLACK,CHUCK (HP-Roseville,ex1);
> [email-masked]
> Subject: Encoding of Location-Id and Location-Name in draft-black-radius-l
> anedge-00.txt
> 
> 
> Hi Paul, Chuck
> 
> I have an issue with Location-ID and Location-Name.
> 
> Since these attribute may appear in an Access-Request message, I assume that
> they would be used by RADIUS in evaluating policy.  Therefore I would not
> want these encoded as a string the way you have it.  I would rather see a
> more efficient encoding scheme, one that would make it faster for RADIUS to
> parse.
> 
> In discussions on this list I proposed to use a single attribute that is of
> type string (the same as yours) that would encode the information using TLV.
> Both of these schemes provide for extensibility and optionality.  But the
> TLV approach as an advantage that it is easier to parse for RADIUS ( we
> don't want to slow RADIUS down), and is more compact.  The encoding approach
> in your document is human readable.
> 
> IMO the string encoding you propose would be okay if it already has an
> application that expects this type of encoding.
> 
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 29 Dec 2003 17:18:01 +0000
From: "BLACK,CHUCK (HP-Roseville,ex1)" <[email-masked]>
To: 'Avi Lior' <[email-masked]>, "CONGDON,PAUL (HP-Roseville,ex1)" <[email-masked]>, "BLACK,CHUCK (HP-Roseville,ex1)" <[email-masked]>, [email-masked]
Subject: RE: Encoding of Location-Id and Location-Name in draft-black-radi us-l anedge-00.txt
Date: Mon, 29 Dec 2003 12:17:17 -0500

Hi Avi,

The encoding of Location-ID is identical to that proposed by the Wi-Fi
Alliance in it's WISPr document in section 5.2 for their "Location-ID"
attribute.  I'm not sure where that encoding originated, so I'm not sure if
there are other applications which make use of it or not.

There have been discussions regarding making attributes such as Location-ID
into a common (not vendor-specific) attribute.  Since it may be used widely,
whichever encoding format is preferable (the current WISPr or else TLV)
should be chosen.  Perhaps there are others who have knowledge of why and
how the WISPr Location-ID format was chosen, and could add their input here.

/chuck

-----Original Message-----
From: Avi Lior [mailto:[email-masked]] 
Sent: Monday, December 22, 2003 2:03 PM
To: 'CONGDON,PAUL (HP-Roseville,ex1)'; BLACK,CHUCK (HP-Roseville,ex1);
[email-masked]
Subject: Encoding of Location-Id and Location-Name in draft-black-radius-l
anedge-00.txt

Hi Paul, Chuck

I have an issue with Location-ID and Location-Name.

Since these attribute may appear in an Access-Request message, I assume that
they would be used by RADIUS in evaluating policy.  Therefore I would not
want these encoded as a string the way you have it.  I would rather see a
more efficient encoding scheme, one that would make it faster for RADIUS to
parse.

In discussions on this list I proposed to use a single attribute that is of
type string (the same as yours) that would encode the information using TLV.
Both of these schemes provide for extensibility and optionality.  But the
TLV approach as an advantage that it is easier to parse for RADIUS ( we
don't want to slow RADIUS down), and is more compact.  The encoding approach
in your document is human readable. 

IMO the string encoding you propose would be okay if it already has an
application that expects this type of encoding. 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sun, 28 Dec 2003 11:36:04 +0000
content-class: urn:content-classes:message
Subject: RE: QoS attributes
Date: Sun, 28 Dec 2003 13:35:15 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Hi Avi,

> There are two problems with this approach is certain conditions:
>=20
> Dealing with a QoS Class Id only only addresses static arrangements =
where
> both parties agree apriori on the contents of that are represented by =
a
> particular instance of the QoS Class Id.  This is useful but its not =
the
> only model.

> In some cases the QoS maybe more dynamic, we therefore need the =
flexibility
> to transfer the QoS Class Id and/or QoS parameters.

Agreed, however the more dynamic model is something that is probably
beyond RADext to standardize.

> Something that I understand is Bandwidth.  Two parties can agree on =
how to
> bill for bandwidth without having to agree on descrete bundles of =
bandwidth.
> We bill bandwidth on bits/second.

So, why are we not discussing Bandwidth?  If I understand, you want
to support a bandwidth attribute.  If so, I think that a more
comprehensive proposal would be good, one which discusses the
trade-offs, etc.  QoS is probably a swamp if we start at supporting
multiple attributes.

> Also I am very surprised about the resistance to do this.  If we =
justify
> doing Credit Control over AAA why is this a problem?=20

I don't see the comparison, actually.  The Credit Control is trying
to standardized a token based approach for doing AAA authorization.
It is not standardizing (or at least trying to carefully work
with) billing models, etc. =20

John

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 24 Dec 2003 16:51:02 +0000
Date: Wed, 24 Dec 2003 09:06:58 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: SIP/RADIUS work?

So far, this list has had discussion on a variety of topics, but very
little relating to SIP authentication, authorization or accounting.

What work, if any, relating to SIP should be contemplated?  Is this work
best done in RADEXT or in SIPPING?

Are there specific drafts that could become WG work items?  If so, is
there interest in ceding change control to the IETF, or is the desire to
publish these as individual submissions?

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 23 Dec 2003 23:07:19 +0000
From: Avi Lior <[email-masked]>
To: "'Nelson, David'" <[email-masked]>, [email-masked]
Subject: RE: QoS attributes
Date: Tue, 23 Dec 2003 18:06:43 -0500

David Nelson writes:

> I have not participated in the Credit Control over AAA 
> discussions, but what I have learned of it from speaking with 
> you, I suspect I would categorize it as a Bad Idea (tm).  It 
> sounds way more complicated than is really necessary.  Yes, 
> you can contrive a business model that requires that much 
> complexity.  However, not all business models make sense or 
> will be successful in the market.  Therefore, Credit Control 
> may not be the best precedent to cite.

The good news is David, that the business model for prepaid and credit
control is viable.  There is demand we and other companies are delivering
products today.  So Credit Control is the *best* precedent to cite.

> If the partners in a roaming consortium can't agree on a few, 
> simple classes of service for QoS that will be comprehensible 
> to the customer as he/she roams, and will be amenable to 
> straightforward billing and reconciliation at the end of the 
> month, then the business model is profoundly broken, and no 
> protocol in the world is going to fix it.

In a simple world the only relationships you have are bilateral
relationships.  In the real-world there are other relationships. Often the
home network has a relationships with intermediaries and the service is
actually provided by other parites. You can expect everyone in these cases
to know what a Gold User looks like. Or what Filter-Id "foobar" means.  

>  At least that's my 
> view of the situation.  Sometimes too much flexibility is a 
> severe impediment to scalability, especially across multiple 
> organizations.  I think maybe the KISS model applies here.

I am a big beliver in the KISS model.  Keep in mind that things that seem
simple at the surface may actually be broken.

Filter ID concept seems simple enough but we know that it is broken today in
that it doesn't scale.

> Authorizing a user to obtain or negotiate for a "class of 
> service" seems within the scope of AAA.  Provisioning the 
> detailed parameters of those "service classes", both at the 
> NAS and on end-to-end basis, seems out of scope for AAA.

Similar arguments were made about filers and filter-ids.  What you propose
is not always a viable solution - its broken.  And in the case of the
filter-id, Diameter fixed that.

Avi

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 23 Dec 2003 20:59:33 +0000
content-class: urn:content-classes:message
Subject: RE: QoS attributes
Date: Tue, 23 Dec 2003 12:59:13 -0800
From: "Bari, Farooq" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

So as I suspected the scenarios can be many and complex. However I feel
that the situation can be simplified if we consider  business models
that are likely to exist. My thinking is that in general we will have
two types of authentication / authorizations and associated QoS values

1) authentication/authorization for accessing the network. QoS
information carried in this part is tightly coupled to user's account /
subscription with his home operator. So this value can be the general
QoS class (e.g. something that indicates the user subscription to real
time services or the user is a gold user etc.). Since the WISP does the
financial settlements for this access by the user with his home network,
the WISP uses this user's QoS profile value provided by his home network
as an upper bound for any other QoS requests made by individual services
later on initiated by the user.

2) authentication/authorization for the service that the user decides to
use after he has been authenticated/authorized to access the network.
This value is provided by the service provider (possibly a 3rd party)
and its value and the way it is negotiated and signaled is independent
of AAA interactions with user's home network for accessing the network.
This QoS value can be more specific e.g. it may identify specific
bandwidth values etc. However the QoS values will be upper bound by the
(1) since the WISP can only charge and therefore provide a QoS that is
within the user's QoS profile provided by the home network at the time
of network access authentication/authorization.=20

If the WISP and service provide have direct business (roaming)
agreement, then I would consider it the case where the service provider
is also directly (in a way) paying for the extra QoS to the WISP and
therefore home network's authentication /authorization of subscribed QoS
can be over ruled.

Farooq

-----Original Message-----
From: Jari Arkko [mailto:[email-masked]]=20
Sent: Monday, December 22, 2003 11:53 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: QoS attributes

[email-masked] wrote:
> Farooq,
>=20
>=20
>>A question for my clarification. What happens if the service
>>that needs a specific QoS is a third party Service i.e. it is not
being
>>delivered/offered by the home network and therefore W/ISP=20
>>does not have a AAA relationship as such with the 3rd party.
>=20
>=20
> If there is no roaming in place, then there probably is no service.=20
> The user would then have to pay to the visited network via some=20
> mechanism.

I think there are several cases:

1. Service is provided free of charge, QoS set is just used
    to ensure that e.g. those who start the video download can
    also complete and get enough bandwidth while downloading.

    In this case there are no AAA issues. Some QoS signaling
    can take place between the user and the 3rd party service.

2. The 3rd party service has its own authentication and
    billing. The user initiates this authentication in
    addition to the one done at access level. Example:
    SIP layer authentication in addition to WLAN access.

    In this case there is AAA involved, but its local to the
    3rd party service i.e. no roaming to the home network.
    Subscriber pays two bills.

3. The 3rd party service employs authentication with a
    roaming agreement to the home network.

    Here too the service authentication and access
    authentication are separate, but both may use the
    same credentials and be authenticated to the same
    home server. Subscriber pays just one bill.

4. The 3rd party service employs authentication with
    a roaming agreement to the local access network.

    This is like alternative 3, but the roaming path
    goes through the access network.

5. The 3rd party service and the local access network
    can somehow agree to provide QoS services to the
    access network's users. Perhaps based on the block
    of IP addresses allocated to the access network,
    or something like that. Information about the
    provided QoS is exchanged between the networks
    for billing purposes.

--Jari

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 23 Dec 2003 20:54:43 +0000
content-class: urn:content-classes:message
Subject: RE: QoS attributes
Date: Tue, 23 Dec 2003 15:53:56 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Joel writes...

> This presume a very simple consortium model.

[DBN] Perhaps, but I do have a bias.  As a potential customer for
roaming access services, I like simple.  :-)

> At the very least I would
> expect hot spot operators to be planning to participate in multiple
> consortia, so as to offer service to the widest range of customers.
Those
> distinct consortia are not likely to have the same collections of QoS
> sets.

[DBN] I understand the apparent attractiveness of provisioning detailed
QoS parameters in AAA messages.  It means that all knowledge can be
centralized in a Home AAA Server.  There is only one place where the
operator has to go to twiddle the knobs, to define or re-define the
classes of service for QoS.  It also means that you don't have to deal
with other protocols for provisioning QoS definitions on your NASes,
such as CLI, SNMP or COPS.

[DBN] The problem with this vision is that it requires a level of
conformity in product offerings that is going to be very hard to
achieve, and it does not account for the end-to-end nature of QoS. It
does not indicate how the static AAA-provisioned QoS parameters interact
with the dynamic, negotiated QoS parameters. IMHO, this is like the
story of The Emperor's New Clothes.=20

-- Dave

=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 23 Dec 2003 20:17:34 +0000
Date: Tue, 23 Dec 2003 15:17:13 -0500
To: <[email-masked]>
From: "Joel M. Halpern" <[email-masked]>
Subject: RE: QoS attributes

This presume a very simple consortium model.  At the very least I would 
expect hot spot operators to be planning to participate in multiple 
consortia, so as to offer service to the widest range of customers.  Those 
distinct consortia are not likely to have the same collections of QoS sets.

Yours,
Joel M. Halpern

At 03:02 PM 12/23/2003 -0500, Nelson, David wrote:
>If the partners in a roaming consortium can't agree on a few, simple
>classes of service for QoS that will be comprehensible to the customer
>as he/she roams, and will be amenable to straightforward billing and
>reconciliation at the end of the month, then the business model is
>profoundly broken, and no protocol in the world is going to fix it.  At
>least that's my view of the situation.  Sometimes too much flexibility
>is a severe impediment to scalability, especially across multiple
>organizations.  I think maybe the KISS model applies here.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 23 Dec 2003 20:03:41 +0000
content-class: urn:content-classes:message
Subject: RE: QoS attributes
Date: Tue, 23 Dec 2003 15:02:02 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Avi writes...

> Also I am very surprised about the resistance to do this.  If we
justify
> doing Credit Control over AAA why is this a problem?

You probably shouldn't be surprised.  The point that is being made is
that AAA is used to authorize users to access services.  Specifically,
services that are pretty much static, pre-defined, and well-understood.
There are other protocols for negotiating dynamic service parameters,
e.g. in this instance we are talking about QoS parameters.  There is no
good reason to duplicate the functionality of QoS negotiation protocols
within AAA, and there are probably a host of reasons to avoid doing so.

I have not participated in the Credit Control over AAA discussions, but
what I have learned of it from speaking with you, I suspect I would
categorize it as a Bad Idea (tm).  It sounds way more complicated than
is really necessary.  Yes, you can contrive a business model that
requires that much complexity.  However, not all business models make
sense or will be successful in the market.  Therefore, Credit Control
may not be the best precedent to cite.

If the partners in a roaming consortium can't agree on a few, simple
classes of service for QoS that will be comprehensible to the customer
as he/she roams, and will be amenable to straightforward billing and
reconciliation at the end of the month, then the business model is
profoundly broken, and no protocol in the world is going to fix it.  At
least that's my view of the situation.  Sometimes too much flexibility
is a severe impediment to scalability, especially across multiple
organizations.  I think maybe the KISS model applies here.

Authorizing a user to obtain or negotiate for a "class of service" seems
within the scope of AAA.  Provisioning the detailed parameters of those
"service classes", both at the NAS and on end-to-end basis, seems out of
scope for AAA.

-- Dave

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 23 Dec 2003 17:33:59 +0000
From: Avi Lior <[email-masked]>
To: "[email-masked]'" <[email-masked]>, Avi Lior <[email-masked]>, [email-masked]
Subject: RE: QoS attributes
Date: Tue, 23 Dec 2003 12:32:43 -0500

John,

> > But I don't belive that those are the only use cases.  What
> > about when the  QoS classes are not configured such in 
> cases when we cross 
> > administrative domains where we don't have the QoS class configured 
> > or completely configured.  You would then need to actually 
> transport 
> > the actual parameters.  After all, isnt the QoS class an 
> alias for QoS 
> > parameters?
> 
> One would hope that if parties have agreements in place for 
> roaming, then they would also have some agreements on service 
> classes as well.  They would still 
> have to have some agreement on policy, for example, to know 
> if the roaming 
> user was authorized for certain types of service, I would guess.

There are two problems with this approach is certain conditions:

Dealing with a QoS Class Id only only addresses static arrangements where
both parties agree apriori on the contents of that are represented by a
particular instance of the QoS Class Id.  This is useful but its not the
only model.

In some cases the QoS maybe more dynamic, we therefore need the flexibility
to transfer the QoS Class Id and/or QoS parameters.

Something that I understand is Bandwidth.  Two parties can agree on how to
bill for bandwidth without having to agree on descrete bundles of bandwidth.
We bill bandwidth on bits/second.

Also I am very surprised about the resistance to do this.  If we justify
doing Credit Control over AAA why is this a problem? 

> John
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 23 Dec 2003 07:57:14 +0000
Date: Tue, 23 Dec 2003 09:56:00 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: [email-masked]
Cc: [email-masked]
Subject: Re: QoS attributes

[email-masked] wrote:
> Hi Jari,
> 
> 
>>>My issue still is (without getting into specifics of QoS or WLAN 
>>>parameters) how can bundle the parameters in a way that not every
>>>single parameter has to be listed in a RADIUS RFC?
>>
>>Oh that's easy -- we can just put it in some opaque string, vendor
>>specific attribute, or design some OID hierarchy around the 
>>parameters.
> 
> 
> Not that easy.  Lets take the case of bandwidth.  Lets say we allow
> a single QoS parameter called bandwidth.  Sounds simple.  What does
> the parameter denote? Average bandwidth (over what time?), instanteous
> bw, minimum bw, maximum bw, maximum sustained bw, bw from the point of
> monitor, bw to the end user?  How do the roaming partners agree on this.
> 
> After we settle this, I am sure some folks will want to add more QoS
> paramter, like delay, jitter, packet loss, throughput, goodput ...
> and so on.  At the end of the day, this becomes extremely complex and
> (IMO) unmanagable.

I agree -- but I was just responding that it is easy to provide
parameter space so that it doesn't have to be listed in the IETF
RFCs. Its another question if that would make sense, and yet another
question if we could agree what the parameters are in the first
place.

--Jari

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 23 Dec 2003 07:54:10 +0000
Date: Tue, 23 Dec 2003 09:52:48 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: QoS attributes

[email-masked] wrote:
> Farooq,
> 
> 
>>A question for my clarification. What happens if the service 
>>that needs a specific QoS is a third party Service i.e. it is not being
>>delivered/offered by the home network and therefore W/ISP 
>>does not have a AAA relationship as such with the 3rd party.
> 
> 
> If there is no roaming in place, then there probably is no service.
> The user would then have to pay to the visited network via some
> mechanism.

I think there are several cases:

1. Service is provided free of charge, QoS set is just used
    to ensure that e.g. those who start the video download can
    also complete and get enough bandwidth while downloading.

    In this case there are no AAA issues. Some QoS signaling
    can take place between the user and the 3rd party service.

2. The 3rd party service has its own authentication and
    billing. The user initiates this authentication in
    addition to the one done at access level. Example:
    SIP layer authentication in addition to WLAN access.

    In this case there is AAA involved, but its local to the
    3rd party service i.e. no roaming to the home network.
    Subscriber pays two bills.

3. The 3rd party service employs authentication with a
    roaming agreement to the home network.

    Here too the service authentication and access
    authentication are separate, but both may use the
    same credentials and be authenticated to the same
    home server. Subscriber pays just one bill.

4. The 3rd party service employs authentication with
    a roaming agreement to the local access network.

    This is like alternative 3, but the roaming path
    goes through the access network.

5. The 3rd party service and the local access network
    can somehow agree to provide QoS services to the
    access network's users. Perhaps based on the block
    of IP addresses allocated to the access network,
    or something like that. Information about the
    provided QoS is exchanged between the networks
    for billing purposes.

--Jari

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 23 Dec 2003 07:41:24 +0000
content-class: urn:content-classes:message
Subject: RE: QoS attributes
Date: Tue, 23 Dec 2003 09:39:48 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Hi Jari,

> > My issue still is (without getting into specifics of QoS or WLAN=20
> > parameters) how can bundle the parameters in a way that not every
> > single parameter has to be listed in a RADIUS RFC?
>=20
> Oh that's easy -- we can just put it in some opaque string, vendor
> specific attribute, or design some OID hierarchy around the=20
> parameters.

Not that easy.  Lets take the case of bandwidth.  Lets say we allow
a single QoS parameter called bandwidth.  Sounds simple.  What does
the parameter denote? Average bandwidth (over what time?), instanteous
bw, minimum bw, maximum bw, maximum sustained bw, bw from the point of
monitor, bw to the end user?  How do the roaming partners agree on this.

After we settle this, I am sure some folks will want to add more QoS
paramter, like delay, jitter, packet loss, throughput, goodput ...
and so on.  At the end of the day, this becomes extremely complex and
(IMO) unmanagable.

John

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 23 Dec 2003 07:35:29 +0000
content-class: urn:content-classes:message
Subject: RE: QoS attributes
Date: Tue, 23 Dec 2003 09:35:03 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

Farooq,

> A question for my clarification. What happens if the service=20
> that needs a specific QoS is a third party Service i.e. it is not =
being
> delivered/offered by the home network and therefore W/ISP=20
> does not have a AAA relationship as such with the 3rd party.

If there is no roaming in place, then there probably is no service.
The user would then have to pay to the visited network via some
mechanism.

John

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 23 Dec 2003 07:34:28 +0000
content-class: urn:content-classes:message
Subject: RE: QoS attributes
Date: Tue, 23 Dec 2003 09:33:57 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>

Avi,

> Okay we are starting to converge here a bit.
>=20
> I understand the concept of having AAA authorize a certain=20
> QoS class.  And I agree with you on that.
>=20
> The simple use cases (if I got it right ) would be:
> Joe authenticates and the Access Accept message returns back a QoS =
class;
> alternatively Joe requests a new service instance with a certain QoS =
class,=20
> and the NAS authorizes the use of a QoS class with the AAA using an =
Authorize=20
> Only scheme.
>=20
> This is all good.
>=20
> But I don't belive that those are the only use cases.  What=20
> about when the  QoS classes are not configured such in cases when we =
cross=20
> administrative domains where we don't have the QoS class configured=20
> or completely configured.  You would then need to actually transport=20
> the actual parameters.  After all, isnt the QoS class an alias for QoS =

> parameters?

One would hope that if parties have agreements in place for roaming, =
then they
would also have some agreements on service classes as well.  They would =
still=20
have to have some agreement on policy, for example, to know if the =
roaming=20
user was authorized for certain types of service, I would guess.

John

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 22 Dec 2003 22:03:40 +0000
From: Avi Lior <[email-masked]>
To: "'CONGDON,PAUL (HP-Roseville,ex1)'" <[email-masked]>,  "BLACK,CHUCK (HP-Roseville,ex1)" <[email-masked]>,  [email-masked]
Subject: Encoding of Location-Id and Location-Name in draft-black-radius-l anedge-00.txt
Date: Mon, 22 Dec 2003 17:02:59 -0500

Hi Paul, Chuck

I have an issue with Location-ID and Location-Name.

Since these attribute may appear in an Access-Request message, I assume that
they would be used by RADIUS in evaluating policy.  Therefore I would not
want these encoded as a string the way you have it.  I would rather see a
more efficient encoding scheme, one that would make it faster for RADIUS to
parse.

In discussions on this list I proposed to use a single attribute that is of
type string (the same as yours) that would encode the information using TLV.
Both of these schemes provide for extensibility and optionality.  But the
TLV approach as an advantage that it is easier to parse for RADIUS ( we
don't want to slow RADIUS down), and is more compact.  The encoding approach
in your document is human readable. 

IMO the string encoding you propose would be okay if it already has an
application that expects this type of encoding. 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 22 Dec 2003 20:39:50 +0000
From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
To: "[email-masked]'" <[email-masked]>, Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Cc: [email-masked]
Subject: RE: QoS attributes
Date: Mon, 22 Dec 2003 14:39:02 -0600

-----Original Message-----
From: Jari Arkko [mailto:[email-masked]]
Sent: Monday, December 22, 2003 2:07 PM
To: Nakhjiri Madjid-MNAKHJI1
Cc: [email-masked]
Subject: Re: QoS attributes

Nakhjiri Madjid-MNAKHJI1 wrote:

> My issue still is (without getting into specifics of QoS or WLAN 
> parameters) how can bundle the parameters in a way that not every
> single parameter has to be listed in a RADIUS RFC?

Oh that's easy -- we can just put it in some opaque string, vendor
specific attribute, or design some OID hierarchy around the parameters.

Madjid>>I wonder if we could something in between. I.e.
It would be nice to have a hierarchy, where the server would 
recognize that an attribute is a QoS or L2 definition (WLAN, CDMA..)
attribute and then leave the details either as opague stings or VSAs?
Currently (correct me if I am wrong), it seems that if something is Vendor
specific, only a vendor ID is provided, but it does not say anything further.

But the question is do we want to? The hard issue is how all this works
without buying the whole network from one vendor. Or how a home server
can control parameters in a roaming situation when it has never even
heard of the link technology that the foreign network uses. Essentially,
there would have to standardization of the parameters. Whether or not
that happens inside a particular IETF RFC is another question.

Madjid>> Again, VSA kind of force you to buy from one vendor, they
don't promote interoperability. It seems they don't allow for negotiations
between vendors either. However, if you had a method where the servers
would at least know that the issue is QoS or an L2 attribute, they
may be able to query an entity that knows, for instance a QoS manager
or a mobility manager. I don't think we should require AAA server to 
understand all QoS techs and all L2 techs and all mobility techs and
so on, but many architectures do require that AAA server talks to other
entities in the network (QoS manager or Mobile IP HA).

Maybe the best we can do at the moment is this Gold-Silver-Etc
service level classification. 

Madjid>> Based on the discussions we had, Generic service level classes
are starting to appeal to me. However, I like to see categorizations that have come
out of IETF and are widely accepted, such as ToS or DSCP (I am not
sure how MPLS does classifications) and with many levels (DSCP has ~64) so anybody
can use them as they see fit (like DSCP bits), rather than too few levels
such as Gold-Silver,bronz, unless we run them all the way to alkali metals :) 
Did I miss any RFC that defines things in Gold-Silver-Bronz??

Madjid
 
Or perhaps we could do that, and
the specific, more detailed parameters for a popular link layer,
such as 802.11 wireless LANs.

--Jari

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 22 Dec 2003 20:39:42 +0000
Date: Mon, 22 Dec 2003 12:56:05 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: "Joel M. Halpern" <[email-masked]>
cc: [email-masked]
Subject: Re: QoS attributes

> I suppose that we could assert that the interpretation of the QoS colors by
> the roamer is to be influenced by the domain of the subscriber. But that
> seems to be asking an awful lot of other parts of the system.
>
> Am I misunderstanding the discussion?

I think you understand it pretty well.

Note that none of this is knew.  We had the same issue come up with
respect to the Filter-Id attribute defined in RFC 2865.  If the Filter-Id
is understood by all parties, it works.  If there are no prior
arrangements, sending a Filter-Id in a roaming situation can produce
unpredictable results.

One reason that *only* Filter-Id was supported in RFC 2865 is that vendors
had introduced their own distinct ways of handling explicit filters.  In
Diameter, standardized filter rules (for both packet filters and QoS) were
introduced.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 22 Dec 2003 20:34:29 +0000
Date: Mon, 22 Dec 2003 12:50:21 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: Nagi <[email-masked]>
cc: [email-masked]
Subject: Re: Reply-Message/EAP-Message attributes in RFC-3576

> > There is no equivalent acknowledgement defined for a Reply-Message.
>
> If no equivalent acknowledgement for Reply-Message, doesn't that mean user
> cannot confirm the service. Is that acceptable behavior? Also Do these
> attributes make sense in Disconnect requests? I suppose that saying "you are
> now being logged off" doesn't make sense. May be, that the ISP can display a
> message "Your service is over. Talk to customer care over the phone" does
> make sense.

Reply-Message attribute delivers a displayable message.  This could be
useful in a Disconnect-Request in that the reason for the disconnection
could be explained to the user (as in your example).

Even the EAP Notification-Response only acknowledges that the
Notification-Request was received, not that the user "responded" in any
way.  It is therefore only a transport-level acknowledgement.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 22 Dec 2003 20:26:50 +0000
Date: Mon, 22 Dec 2003 15:26:10 -0500
To: [email-masked]
From: "Joel M. Halpern" <[email-masked]>
Subject: Re: QoS attributes

I have been watching this exchange, and I am somewhat puzzled.
We all seem to agree that the interesting case is roaming.
There then seem to be a set of unstate assumptions about what the business 
relationships are between the roaming and home operators, and their 
relationship to the promises made to the customer.

I can imagine a model in which sending platinum / gold / silver / tin / 
copper is meaningful.  But that is a specific model where the customer has 
been told "you will get the negotiated corresponding service level from 
roaming partners", and part of the business negotiation is to define what 
the correspondences are.

THis is a defensible model.  It can even be extended to consortia, etc.
But it seems unlikely to be the only model.

One could easily imagine a model where the business relationship says "as a 
roaming operator we will support whatever QoS you would like to give your 
customers, and here is the price list."  Without a lot of work this does 
not map to a colored service model, since the relationship does not require 
picking levels in the business relationship, and the services to different 
roaming partners may well be chosen differently by those partners.

I suppose that we could assert that the interpretation of the QoS colors by 
the roamer is to be influenced by the domain of the subscriber. But that 
seems to be asking an awful lot of other parts of the system.

Am I misunderstanding the discussion?

Yours,
Joel M. Halpern

At 10:06 PM 12/22/2003 +0200, Jari Arkko wrote:
>Nakhjiri Madjid-MNAKHJI1 wrote:
>
>>My issue still is (without getting into specifics of QoS or WLAN 
>>parameters) how can bundle the parameters in a way that not every
>>single parameter has to be listed in a RADIUS RFC?
>
>Oh that's easy -- we can just put it in some opaque string, vendor
>specific attribute, or design some OID hierarchy around the parameters.
>
>But the question is do we want to? The hard issue is how all this works
>without buying the whole network from one vendor. Or how a home server
>can control parameters in a roaming situation when it has never even
>heard of the link technology that the foreign network uses. Essentially,
>there would have to standardization of the parameters. Whether or not
>that happens inside a particular IETF RFC is another question.
>
>Maybe the best we can do at the moment is this Gold-Silver-Etc
>service level classification. Or perhaps we could do that, and
>the specific, more detailed parameters for a popular link layer,
>such as 802.11 wireless LANs.
>
>--Jari
>
>
>--
>to unsubscribe send a message to [email-masked] with
>the word 'unsubscribe' in a single line as the message text body.
>archive: <http://psg.com/lists/radiusext/>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 22 Dec 2003 20:08:12 +0000
Date: Mon, 22 Dec 2003 22:06:48 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Cc: [email-masked]
Subject: Re: QoS attributes

Nakhjiri Madjid-MNAKHJI1 wrote:

> My issue still is (without getting into specifics of QoS or WLAN 
> parameters) how can bundle the parameters in a way that not every
> single parameter has to be listed in a RADIUS RFC?

Oh that's easy -- we can just put it in some opaque string, vendor
specific attribute, or design some OID hierarchy around the parameters.

But the question is do we want to? The hard issue is how all this works
without buying the whole network from one vendor. Or how a home server
can control parameters in a roaming situation when it has never even
heard of the link technology that the foreign network uses. Essentially,
there would have to standardization of the parameters. Whether or not
that happens inside a particular IETF RFC is another question.

Maybe the best we can do at the moment is this Gold-Silver-Etc
service level classification. Or perhaps we could do that, and
the specific, more detailed parameters for a popular link layer,
such as 802.11 wireless LANs.

--Jari

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 22 Dec 2003 18:16:20 +0000
content-class: urn:content-classes:message
Subject: RE: QoS attributes
Date: Mon, 22 Dec 2003 10:12:51 -0800
From: "Bari, Farooq" <[email-masked]>
To: "Avi Lior" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

A question for my clarification. What happens if the service that needs
a specific QoS is a third party Service i.e. it is not being
delivered/offered by the home network and therefore W/ISP does not have
a AAA relationship as such with the 3rd party.

Farooq

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Avi Lior
Sent: Monday, December 22, 2003 8:19 AM
To: [email-masked]'; Avi Lior; [email-masked];
[email-masked]
Subject: RE: QoS attributes

John,

Okay we are starting to converge here a bit.

I understand the concept of having AAA authorize a certain QoS class.
And I agree with you on that.

The simple use cases (if I got it right ) would be:
Joe authenticates and the Access Accept message returns back a QoS
class; alternatively Joe requests a new service instance with a certain
QoS class, and the NAS authorizes the use of a QoS class with the AAA
using an Authorize Only scheme.

This is all good.

But I don't belive that those are the only use cases.  What about when
the QoS classes are not configured such in cases when we cross
administrative domains where we don't have the QoS class configured or
completely configured.  You would then need to actually transport the
actual parameters.  After all, isnt the QoS class an alias for QoS
parameters?

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: December 22, 2003 2:26 AM
> To: [email-masked]; [email-masked];=20
> [email-masked]
> Subject: RE: QoS attributes
>=20
>=20
> Hi Avi,
>=20
> > I agree that we need a QoS Class Id, (or QoS-Bundle-Id).
> >=20
> > Would RADIUS only ever transport the QoS-Class-Id?
>=20
> My thoughts are that a AAA system would only authorize for
> a certain QoS Class, not necessarily authorize specific
> QoS parameters.
> =20
> > Also reading through some of the drafts you point to.  I noticed=20
> > that COPS is used.  I think that at least in certain cases that =20
> > RADIUS/Diameter should be utilized instead of COPS.  There certainly

> > have been discussion on this.
>=20
> I agree. I don't think that COPS is the proper mechanism,
> though some people use it.  Most of the discussions I have=20
> heard, as of late, seem to be about migrating to AAA=20
> mechanisms for QoS authorization.
>=20
> John
>=20

--
to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 22 Dec 2003 17:57:02 +0000
Date: Mon, 22 Dec 2003 18:56:21 +0100
From: Nagi <[email-masked]>
Organization: Alcatel Telecom
To: Bernard Aboba <[email-masked]>
CC: [email-masked]
Subject: Re: Reply-Message/EAP-Message attributes in RFC-3576

Bernard,

Thanks for the response. Please see comments inline.

Bernard Aboba wrote:

> > i) Can somebody educate me how are these attributes used. I'm wondering
> > how these messages are delivered to the user.
>
> They are there to allow the server to send a displayable message.  For
> example, a CoA-Request with an EAP-Message/Notification-Request stating
> "You have now been authorized for the Foo Service."
>
> How they are delivered to the user depends on the type of access they
> have.  If the client supports EAP, they can be sent as an
> EAP-Message/Notification-Request;  otherwise a Reply-Message attribute
> might be used.

Got the point. How can  the user request a service?

>
>
> > ii) Why is that Reply-Message not there in ACK messages where as the
> > EAP-Message can be there in ACKs as well.
>
> An EAP-Message attribute may be present in ACK messages so that an
> EAP-Message/Notification-Response can be sent back to the server,
> acknowledging receipt.
>
> There is no equivalent acknowledgement defined for a Reply-Message.

If no equivalent acknowledgement for Reply-Message, doesn't that mean user
cannot confirm the service. Is that acceptable behavior? Also Do these
attributes make sense in Disconnect requests? I suppose that saying "you are
now being logged off" doesn't make sense. May be, that the ISP can display a
message "Your service is over. Talk to customer care over the phone" does
make sense.

Thanks a lot,
Nagi.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 22 Dec 2003 17:17:01 +0000
From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
To: "'Avi Lior'" <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: RE: QoS attributes
Date: Mon, 22 Dec 2003 11:16:05 -0600

Hi Avi, John,

"I agree that we need a QoS Class Id, (or QoS-Bundle-Id)."

It seems that this is the closest we got to my question at least,
which was: how do RADIUS-NAS convey a variety of information,
containing a large number of parameters, between each other without
the RADIUS community having to assign an attribute to each parameter.
Is the "Class Id" (or bundle-ID) a Diameter notion? How is grouping
handled in Diameter?

Although I agree that this list neither is chartered nor has time to
solve all the QoS problems (the way NSIS does), I must say that QoS
type issues, or more specific authorization issues are AAA issues and
not just NSIS issues. A call control architecture (such as SIP) should
talk to both AAA servers and QoS managers before it sets up a call.
The problem is that authorization is not as clear cut for standards as
say authentication, since it depends on the QoS technology and service 
contracts. So as Dave said, we need to leave a lot of it to VSAs.

My issue still is (without getting into specifics of QoS or WLAN 
parameters) how can bundle the parameters in a way that not every
single parameter has to be listed in a RADIUS RFC?

Madjid 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Avi Lior
Sent: Friday, December 19, 2003 11:06 AM
To: [email-masked]; [email-masked];
[email-masked]
Subject: RE: QoS attributes

Hi John,

I agree that we need a QoS Class Id, (or QoS-Bundle-Id).

Would RADIUS only ever transport the QoS-Class-Id?

Also reading through some of the drafts you point to.  I noticed that COPS
is used.  I think that at least in certain cases that RADIUS/Diameter should
be utilized instead of COPS.  There certainly have been discussion on this.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: December 18, 2003 4:40 AM
> To: [email-masked]; [email-masked]
> Subject: RE: QoS attributes
> 
> 
> Hi all,
> 
> My 2 cents are as follows: RADext/AAAext (or whatever) 
> shouldn't define QoS signaling, 
> NSIS is already doing that:
> 
http://www.ietf.org/html.charters/nsis-charter.html

There has been some discussion on AAA issues for QoS:

http://www.ietf.org/internet-drafts/draft-alfano-aaa-qosreq-01.txt
http://www.ietf.org/internet-drafts/draft-tschofenig-nsis-qos-authz-issues-0
0.txt

Looking into QoS issues, my feeling is that we want to specify QoS classes.
These classes may support a set of QoS parameters.  I think that QoS will be
an area that vendors try to differentiate on; service providers may create
services that support different QoS parameters, etc.  I don't think that we
can get into the QoS signaling / provisioning / definition of QoS
parameters, as that excedes the scope of AAA (either RADIUS or Diameter).  I
would prefer that RADIUS / Diameter would contain a 
QoS class parameter, which could make use something like a IANA QoS class
registry. 

Different SDOs have different plans ITU-T, 3GPP, 3GPP2, etc. all have
defined seperate QOS classes.  One could imagine registering these classes
in IANA, and service providers could support, in various degrees, different
QoS classes.  It would then be in scope of AAA to provide authorization for
these classes.

John

--
to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 22 Dec 2003 16:50:28 +0000
Date: Mon, 22 Dec 2003 09:06:43 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: Nagi <[email-masked]>
cc: [email-masked]
Subject: Re: Reply-Message/EAP-Message attributes in RFC-3576

> i) Can somebody educate me how are these attributes used. I'm wondering
> how these messages are delivered to the user.

They are there to allow the server to send a displayable message.  For
example, a CoA-Request with an EAP-Message/Notification-Request stating
"You have now been authorized for the Foo Service."

How they are delivered to the user depends on the type of access they
have.  If the client supports EAP, they can be sent as an
EAP-Message/Notification-Request;  otherwise a Reply-Message attribute
might be used.

> ii) Why is that Reply-Message not there in ACK messages where as the
> EAP-Message can be there in ACKs as well.

An EAP-Message attribute may be present in ACK messages so that an
EAP-Message/Notification-Response can be sent back to the server,
acknowledging receipt.

There is no equivalent acknowledgement defined for a Reply-Message.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 22 Dec 2003 16:19:43 +0000
From: Avi Lior <[email-masked]>
To: "[email-masked]'" <[email-masked]>, Avi Lior <[email-masked]>, [email-masked],  [email-masked]
Subject: RE: QoS attributes
Date: Mon, 22 Dec 2003 11:18:54 -0500

John,

Okay we are starting to converge here a bit.

I understand the concept of having AAA authorize a certain QoS class.  And I
agree with you on that.

The simple use cases (if I got it right ) would be:
Joe authenticates and the Access Accept message returns back a QoS class;
alternatively
Joe requests a new service instance with a certain QoS class, and the NAS
authorizes the use of a QoS class with the AAA using an Authorize Only
scheme.

This is all good.

But I don't belive that those are the only use cases.  What about when the
QoS classes are not configured such in cases when we cross administrative
domains where we don't have the QoS class configured or completely
configured.  You would then need to actually transport the actual
parameters.  After all, isnt the QoS class an alias for QoS parameters?

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: December 22, 2003 2:26 AM
> To: [email-masked]; [email-masked]; 
> [email-masked]
> Subject: RE: QoS attributes
> 
> 
> Hi Avi,
> 
> > I agree that we need a QoS Class Id, (or QoS-Bundle-Id).
> > 
> > Would RADIUS only ever transport the QoS-Class-Id?
> 
> My thoughts are that a AAA system would only authorize for
> a certain QoS Class, not necessarily authorize specific
> QoS parameters.
>  
> > Also reading through some of the drafts you point to.  I
> > noticed that COPS is used.  I think that at least in certain 
> > cases that  RADIUS/Diameter should be utilized instead of 
> > COPS.  There certainly have been discussion on this.
> 
> I agree. I don't think that COPS is the proper mechanism, 
> though some people use it.  Most of the discussions I have 
> heard, as of late, seem to be about migrating to AAA 
> mechanisms for QoS authorization.
> 
> John
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 22 Dec 2003 16:05:08 +0000
content-class: urn:content-classes:message
Subject: RE: QoS attributes
Date: Mon, 22 Dec 2003 11:03:58 -0500
From: "Roy, Radhika R, ALABS" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>

John:

I think that COPS is a policy protocol, and policies related to QOS can =
also be used for distribution and enforcements. Similar may also be the =
case for security and accounting.

However, DIAMETER/RADIUS is also used for authentication, authorization, =
and accounting (AAA).

Here are the interesting points:=20

1. COPS for policies of authentication, authorization, and accounting =
including QOS.

2. DIAMETER/RADIUS for offering actual services for authentication, =
authorization, and accounting including QoS.

In item 2, I am lacking clear wordings here.

The question is this: Can we not develop standards complementing both =
COPS and DIAMETER/RADIUS as they are also a part of IETF standard =
protocols?

BR,

Radhika R. Roy
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, December 22, 2003 2:26 AM
To: [email-masked]; [email-masked];
[email-masked]
Subject: RE: QoS attributes

Hi Avi,

> I agree that we need a QoS Class Id, (or QoS-Bundle-Id).
>=20
> Would RADIUS only ever transport the QoS-Class-Id?

My thoughts are that a AAA system would only authorize for
a certain QoS Class, not necessarily authorize specific
QoS parameters.
=20
> Also reading through some of the drafts you point to.  I=20
> noticed that COPS is used.  I think that at least in certain=20
> cases that  RADIUS/Diameter should be utilized instead of=20
> COPS.  There certainly have been discussion on this.

I agree. I don't think that COPS is the proper mechanism,
though some people use it.  Most of the discussions I have
heard, as of late, seem to be about migrating to AAA mechanisms
for QoS authorization.

John

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 22 Dec 2003 15:23:32 +0000
Date: Mon, 22 Dec 2003 11:10:46 +0100
From: Nagi <[email-masked]>
Organization: Alcatel Telecom
To: "BLACK,CHUCK (HP-Roseville,ex1)" <[email-masked]>
CC: [email-masked]
Subject: Re: questions/comments on draft-black-radius-lanedge-00.txt

Chuck,

See the comment inline.

>
> > 3) The draft proposes a new Time attribute (along with Location-ID
> > and Location Name).  Why can't we use Event-TimeStamp define in RFC-2869
> > which is also in UTC format? Is there a specific reason to have a new
> attribute
> > defined here again?
>
> The Event-Timestamp of RFC-2869 is defined to be an Accounting-Request
> packet attribute.  Perhaps for standardization this attribute could be
> carried in either an Access-Request or an Accounting-Request packet?
>

<Nagi> RFC-3576 ( Dynamic authorization extensions) does recommend Event Time
Stamp to support replay detection. I believe the restriction is already lifted
for Disconnect and CoA messages.  Perhaps this is the right time to make the
attribute applicable to all messages.

Regards
Nagi.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 22 Dec 2003 14:39:27 +0000
Date: Mon, 22 Dec 2003 14:44:18 +0100
From: Nagi <[email-masked]>
Organization: Alcatel Telecom
To: [email-masked]
Subject: Reply-Message/EAP-Message attributes in RFC-3576

I have a question regarding the Reply-Message and EAP-message attributes
that can be present in the Disconnect (or CoA) request.

i) Can somebody educate me how are these attributes used. I'm wondering
how these messages are delivered to the user.
ii) Why is that Reply-Message not there in ACK messages where as the
EAP-Message can be there in ACKs as well.

Thanks in advance,
Nagi.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 22 Dec 2003 14:39:06 +0000
content-class: urn:content-classes:message
Subject: RE: QoS attributes
Date: Mon, 22 Dec 2003 09:26:08 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>

Hi Avi,

> I agree that we need a QoS Class Id, (or QoS-Bundle-Id).
>=20
> Would RADIUS only ever transport the QoS-Class-Id?

My thoughts are that a AAA system would only authorize for
a certain QoS Class, not necessarily authorize specific
QoS parameters.
=20
> Also reading through some of the drafts you point to.  I=20
> noticed that COPS is used.  I think that at least in certain=20
> cases that  RADIUS/Diameter should be utilized instead of=20
> COPS.  There certainly have been discussion on this.

I agree. I don't think that COPS is the proper mechanism,
though some people use it.  Most of the discussions I have
heard, as of late, seem to be about migrating to AAA mechanisms
for QoS authorization.

John

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sun, 21 Dec 2003 12:38:45 +0000
From: "Hannes Tschofenig" <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: "Avi Lior" <[email-masked]>, <[email-masked]>
Subject: AW: QoS attributes
Date: Sun, 21 Dec 2003 13:45:14 +0100

hi jari,

thanks for raising this problem with cops. theoretically it also provides
roaming with the same concepts. however, from a deployment point of view it
was only used within a local domain. most operators don't want to setup the
same infrastructure (cops and radius/diameter) for inter-domain
communication only to support authorization for qos requests.

this is one of the problems we discovered when we looked at how rsvp
provides authorization for qos requests (there are other issues which are
described in the 'rsvp security properties' draft).

hence, we started working on the draft <draft-alfano-aaa-qosreq-01.txt>
which john mentioned.

john might have some additional comments beyond my description of the
history behind this draft.

ciao
hannes

> -----Ursprüngliche Nachricht-----
> Von: Jari Arkko [mailto:[email-masked]]
> Gesendet: Freitag, 19. Dezember 2003 19:24
> An: [email-masked]'
> Cc: Avi Lior; [email-masked]
> Betreff: Re: QoS attributes
>
>
>
> Avi wrote:
>
> > ... COPS ... RADIUS/Diameter
>
> Interesting.
>
> John, perhaps you can educate me a little bit regarding the use
> of COPS in these environments. How does roaming work? That is,
> if my home operator is in Finland but I'm in California and use
> a local ISP's QoS and COPS-based services -- does COPS have a
> concept similar to AAA proxies and multiple parties that take
> part in the "transaction"?
>
> --Jari
>
>
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 19 Dec 2003 18:25:06 +0000
Date: Fri, 19 Dec 2003 20:23:46 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: "[email-masked]'" <[email-masked]>
Cc: Avi Lior <[email-masked]>, [email-masked]
Subject: Re: QoS attributes

Avi wrote:

> ... COPS ... RADIUS/Diameter 

Interesting.

John, perhaps you can educate me a little bit regarding the use
of COPS in these environments. How does roaming work? That is,
if my home operator is in Finland but I'm in California and use
a local ISP's QoS and COPS-based services -- does COPS have a
concept similar to AAA proxies and multiple parties that take
part in the "transaction"?

--Jari

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 19 Dec 2003 17:07:43 +0000
From: Avi Lior <[email-masked]>
To: "[email-masked]'" <[email-masked]>,  [email-masked], [email-masked]
Subject: RE: QoS attributes
Date: Fri, 19 Dec 2003 12:05:57 -0500

Hi John,

I agree that we need a QoS Class Id, (or QoS-Bundle-Id).

Would RADIUS only ever transport the QoS-Class-Id?

Also reading through some of the drafts you point to.  I noticed that COPS
is used.  I think that at least in certain cases that RADIUS/Diameter should
be utilized instead of COPS.  There certainly have been discussion on this.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: December 18, 2003 4:40 AM
> To: [email-masked]; [email-masked]
> Subject: RE: QoS attributes
> 
> 
> Hi all,
> 
> My 2 cents are as follows: RADext/AAAext (or whatever) 
> shouldn't define QoS signaling, 
> NSIS is already doing that:
> 
http://www.ietf.org/html.charters/nsis-charter.html

There has been some discussion on AAA issues for QoS:

http://www.ietf.org/internet-drafts/draft-alfano-aaa-qosreq-01.txt
http://www.ietf.org/internet-drafts/draft-tschofenig-nsis-qos-authz-issues-0
0.txt

Looking into QoS issues, my feeling is that we want to specify QoS classes.
These classes may support a set of QoS parameters.  I think that QoS will be
an area that vendors try to differentiate on; service providers may create
services that support different QoS parameters, etc.  I don't think that we
can get into the QoS signaling / provisioning / definition of QoS
parameters, as that excedes the scope of AAA (either RADIUS or Diameter).  I
would prefer that RADIUS / Diameter would contain a 
QoS class parameter, which could make use something like a IANA QoS class
registry. 

Different SDOs have different plans ITU-T, 3GPP, 3GPP2, etc. all have
defined seperate QOS classes.  One could imagine registering these classes
in IANA, and service providers could support, in various degrees, different
QoS classes.  It would then be in scope of AAA to provide authorization for
these classes.

John

--
to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 18 Dec 2003 19:15:37 +0000
content-class: urn:content-classes:message
Subject: RE: questions/comments on draft-black-radius-lanedge-00.txt
Date: Thu, 18 Dec 2003 14:14:48 -0500
From: "Nelson, David" <[email-masked]>
Cc: <[email-masked]>

Comments on this thread ---

On NAS-Identifier vs. Location-ID:

If the proposed Location-ID is defined to contain X.500 format location
information, and the syntax is standardized and interoperable, it makes
sense to add this as a separate attribute and leave NAS-Identifier alone
(as it is typically the FQDN of the NAS).

On the new time attribute vs. Event-Timestamp:

Allowing an existing attribute, Event-Timestamp, to be included in other
packet types is preferable to creating a new attribute.

On Port-VLAN-ID vs. Tunnel-Private-Group-ID:

I have a mixed opinion on this one.  over-loading existing attributes
for new uses is less than desirable.  However, if the new use is
relatively compatible with the original use, and the exact usage is
absolutely clear from context (as it is in this case), I think that the
"protocol neatness" obtained from having a separate and distinct
Port-VLAN-ID, in preference to the Tunnel-Private-Group-ID is somewhat
marginal.  I could probably support either way, although we should be
clear on the status of the RFC 3580 usage -- are we going to deprecate
it?  Will we support the use of both attributes?  It should be made
clear what is the correct behavior if both attributes are contained in a
single Access-Accept and do not contain exactly the same value.=20

On IP-Filter-Name vs. Filter-ID:

I think that the new attribute is redundant and Filter-ID works just
fine for this purpose.  If one was to suggest (and I'm not doing so)
that it was desirable to have separately specified L2 and L3 filters
working "in series connection", this might make sense, but I don't think
that was the initial intent.

On the Bandwidth attributes:

If these are part of the over-all QoS solution, then I favor an
attribute or attributes that specify an authorized class of QoS for the
user, and favor leaving the provisioning of specific parameters and
rules to implement the various QoS classes to a more appropriate
protocol.  I don't think that detailed QoS parameter provisioning falls
into the scope of AAA protocols.

On etymology:

As to the colloquial phrase "passes muster", it evolves from military
terminology, in which early militias would "muster" and be inspected by
the command staff for battle readiness and other military fitness
requirements.

What I meant in using this phrase is that the proposed attributes obtain
broad Internet Community consensus and demonstrate multi-vendor
interoperability.

-- Dave

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 18 Dec 2003 18:37:10 +0000
From: "Ed Van Horne" <[email-masked]>
To: "'nagi reddy jonnala'" <[email-masked]>, "'BLACK,CHUCK \(HP-Roseville,ex1\)'" <[email-masked]>
Cc: <[email-masked]>
Subject: RE: questions/comments on draft-black-radius-lanedge-00.txt
Date: Thu, 18 Dec 2003 10:36:46 -0800
Organization: Cisco Systems

Nagi,

Based on discussions within and outside of IETF, I believe that both
LocationId and NAS-Identifier are useful. In the case of LocationId, the
contents of the field will be standardized, increasing the opportunities
for interoperability and the richness of the information conveyed. While
something similar could be done with NAS-Identifier, it would likely not
be interoperable.

Regards,
Ed

Ed Van Horne 
Building Broadband Solutions Unit - San Diego 
Cisco Systems 
10935 Vista Sorrento Parkway 
San Diego, CA 92130 
858.526.1152 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of nagi reddy jonnala
Sent: Thursday, December 18, 2003 10:16 AM
To: BLACK,CHUCK (HP-Roseville,ex1)
Cc: [email-masked]
Subject: Re: questions/comments on draft-black-radius-lanedge-00.txt

Hi Chuck,

Thanks for your responses. See my comments inline.

> > 1) Do access devices (such as IP DSLAMs) come under
> > LAN Edge switches? What exactly does a LAN Edge device mean?
>
> The intent of the document is to attempt to define the delivery of 
> 'edge'-type attributes -- VLANs, ACLs, QoS, bandwidth -- for delivery 
> via RADIUS reply to the RADIUS client (NAS or switch).  Your 
> suggestion of considering these attributes for a broadband environment

> such as IP DSLAM is interesting and, assuming those DSLAM devices 
> support some or all of those attributes, they may as well be a good 
> fit.

<Nagi> I believe it does make sense to consider the access devices such
as IP DSLAM since they do connect the IPoE users using 802.1x
authentication. More or less the attributes you mentioned are applicable
to these devices as well. I'll have to work out what more attributes are
needed in these environments.

>
>
> > 2) When do we use the Location-ID and Location-Name attributes. I 
> > guess they are used in wireless networks.  Can't NAS-ID be used to 
> > identify the Location? Can you explain little further.
>
> This document was really following the lead of the wireless 
> specification WISPr, which proposes the wireless attributes for 
> Location-ID and Location-Name.  It is possible that there should be 
> standard RADIUS attributes for these.  The NAS-Identifier attribute of

> standard RADIUS does not define a specification of the format of the 
> string; the Location-ID does specify a format 
> (isocc=<ISO_Country_Code>,cc=<E.164_Country_Code>, ...).
>
> I guess I'll leave it at that.  Either Location-ID or NAS-Identifier 
> is fine, as long as the format is specified so that we can all agree 
> on and use the same string.

<Nagi? Do you think we need two different identifiers, NAS-Identifier
and as well as Location-ID in some cases.

>
>
> > 3) The draft proposes a new Time attribute (along with Location-ID 
> > and Location Name).  Why can't we use Event-TimeStamp define in 
> > RFC-2869 which is also in UTC format? Is there a specific reason to 
> > have a new
> attribute
> > defined here again?

> The Event-Timestamp of RFC-2869 is defined to be an Accounting-Request

> packet attribute.  Perhaps for standardization this attribute could be

> carried in either an Access-Request or an Accounting-Request packet?

<Nagi>I think it doesn't harm if we make this attribute applicable to
any
packet.   To be future safe, I propose to make the Event-TimeStamp
attribute
applicable to any type of packet.

>
>
> > 4) Section 2.3.4 PVID (port VLAN ID) proposes to replace the use of 
> > Tunnel-Type=VLAN (13), Tunnel-Medium-  Type=802, and 
> > Tunnel-Private-Group-ID=VLANID as described in RFC 3580. I'm 
> > wondering how can a VSA which is by definition  an optional can 
> > replace the use of some thing that was
> standardized
> > before. I also feel that Tunnel Type usage doesn't look nice to 
> > carry
> VLAN-IDs.
> > But I suggest that we define a standard  attribute to carry VLAN-ID 
> > which can replace Tunnel Type usage.
>
> Since RFC-3580 is informational and regards suggested usage, it was 
> hoped that a new attribute, categorized as a part of a set of "LAN 
> Edge" attributes, would be a preferable solution.  So the question is:

> should we overload an old attribute which was not intended to carry 
> VLAN information in the first place (as in RFC-3580), or should we be 
> redundant and define a new one (as in this document)?  Perhaps the 
> best option is along the lines of what was suggested by another 
> reviewer here in this forum, wherein we create a better categorization

> of attributes, including common and domain-specific.

<Nagi> I agree with you.  Though it is redundant, better define new
attribute. I disagree if you say the new one is VSA.

>
>
> > 5) I'm trying to undertand the difference between PVID and 
> > Egress-VID. You mean, PVID is the default-VLAN-ID and Egree-VIDs are

> > allowed list of VLAN-IDs. Right?
>
> You are absolutely correct.  I favored using that terminology, but my 
> friend and colleague Paul Congdon, a confirmed IEEE 802 guy, favored 
> the more technically-precise but obtuse terminology you see there.  
> :-)

<Nagi>I don't have any concerns if the message is clear to all. Paul,
can we use the terminology that we are familiar atleast inside the
explanation :-)

>
>
> > 6) Section 2.3.6- How do we map the user-priority-generation-table? 
> > How is a byte (rather than a bit) is useful to re-map the 
> > priorities.
>
> The idea is that we send down an entire table of prioritization 
> mapping, which will tell the edge device how to map any of the 
> incoming priorities. Thus if byte 0's value is 4, and byte 1's value 
> is 2, and byte 2's value is 8, then incoming packets with priority 0 
> will be set to priority 4, incoming packets with priority 1 will be 
> set to priority 2, and incoming packets with priority 2 will be set to

> priority 8, and so on.  If all packets are to be forced to fixed 
> priority, then all eight bytes of the table will have that same value.
>
> I hope that I understood your question and that this explains the 
> intent of the table.

<Nagi> Yes, I got it.

>
>
> > 7) Section 2.3.7 - IP Filter Name: Do we really need a new attribute

> > for
> this?
> > Can't we use the Filter-ID defined in the standard. I agree that it
> doesn't
> > explicitly mean what filter it is.
>
> This is again the issue of whether to re-use an existing attribute, or

> define a new one within the domain ("LAN Edge") where it best belongs.

<Nagi> I see your point. My argument is that it is more work to the
implementors. Is it worth?

>
>
> > 8) I guess Bandwidth attributes "passes muster". I don't think the 
> > standardization of these attributes cause any problem to the 
> > implementors nor does it compell the radius client / proxy 
> > implementations to support these attributes.  In the "Table of 
> > attributes" section, we can specify if
> the
> > attribute may not be present at all.
>
> Agreed.  Although your use of the phrase "passes muster" makes me 
> wonder where that phrase came from.  I guess it's time to visit the 
> word-etymology web site...
>
>

Even I had to refer the idiom in dictionary.com but I thought that was
the common usage and borrowed it from David Nelson  ;-)

David, what are your comments on both the phrase and the bandwidth
attributes
:-)

Regards
Nagi.

>
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of nagi reddy jonnala
> Sent: Thursday, December 18, 2003 1:54 AM
> To: BLACK,CHUCK (HP-Roseville,ex1)
> Cc: [email-masked]
> Subject: questions/comments on draft-black-radius-lanedge-00.txt
>
> I've read 
> http://www.drizzle.com/~aboba/IEEE/draft-black-radius-lanedge-00.txt
>
> and have some questions and comments:
>
> 1) Do access devices (such as IP DSLAMs) come under LAN Edge switches?

> What exactly does a LAN Edge device mean?
>
> 2) When do we use the Location-ID and Location-Name attributes. I 
> guess they are used in wireless networks.  Can't NAS-ID be used to 
> identify the Location? Can you explain little further.
>
> 3) The draft proposes a new Time attribute (along with Location-ID and

> Location Name).  Why can't we use Event-TimeStamp define in RFC-2869 
> which is also in UTC format? Is there a specific reason to have a new 
> attribute defined here again?
>
> 4) Section 2.3.4 PVID (port VLAN ID) proposes to replace the use of 
> Tunnel-Type=VLAN (13), Tunnel-Medium-
>    Type=802, and Tunnel-Private-Group-ID=VLANID as described in RFC 
> 3580. I'm wondering how can a VSA which is by definition  an optional 
> can replace the use of some thing that was standardized before. I also

> feel that Tunnel Type usage doesn't look nice to carry VLAN-IDs. But I

> suggest that we define a standard  attribute to carry VLAN-ID which 
> can replace Tunnel Type usage.
>
> 5) I'm trying to undertand the difference between PVID and Egress-VID.

> You mean, PVID is the default-VLAN-ID and Egree-VIDs are allowed list 
> of VLAN-IDs. Right?
>
> 6) Section 2.3.6- How do we map the user-priority-generation-table? 
> How is a byte (rather than a bit) is useful to re-map the priorities.
>
> 7) Section 2.3.7 - IP Filter Name: Do we really need a new attribute 
> for this? Can't we use the Filter-ID defined in the standard. I agree 
> that it doesn't explicitly mean what filter it is.
>
> 8) I guess Bandwidth attributes "passes muster". I don't think the 
> standardization of these attributes cause any problem to the 
> implementors nor does it compell the radius client / proxy 
> implementations to support these attributes.  In the "Table of 
> attributes" section, we can specify if the attribute may not be 
> present at all.
>
> Comments welcome.
>
> Regards
> Nagi.
>
> --
> to unsubscribe send a message to [email-masked] with 
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>

--
to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 18 Dec 2003 18:16:57 +0000
Date: Thu, 18 Dec 2003 19:16:28 +0100
From: nagi reddy jonnala <[email-masked]>
Organization: Alcatel Telecom
To: "BLACK,CHUCK (HP-Roseville,ex1)" <[email-masked]>
CC: [email-masked]
Subject: Re: questions/comments on draft-black-radius-lanedge-00.txt

Hi Chuck,

Thanks for your responses. See my comments inline.

> > 1) Do access devices (such as IP DSLAMs) come under
> > LAN Edge switches? What exactly does a LAN Edge device mean?
>
> The intent of the document is to attempt to define the delivery of
> 'edge'-type attributes -- VLANs, ACLs, QoS, bandwidth -- for delivery via
> RADIUS reply to the RADIUS client (NAS or switch).  Your suggestion of
> considering these attributes for a broadband environment such as IP DSLAM is
> interesting and, assuming those DSLAM devices support some or all of those
> attributes, they may as well be a good fit.

<Nagi> I believe it does make sense to consider the access devices such as
IP DSLAM since they do connect the IPoE users using 802.1x authentication. More
or less the attributes you mentioned are applicable to these devices as well.
I'll have to work out what more attributes are needed in these environments.

>
>
> > 2) When do we use the Location-ID and Location-Name attributes.
> > I guess they are used in wireless networks.  Can't NAS-ID be used
> > to identify the Location? Can you explain little further.
>
> This document was really following the lead of the wireless specification
> WISPr, which proposes the wireless attributes for Location-ID and
> Location-Name.  It is possible that there should be standard RADIUS
> attributes for these.  The NAS-Identifier attribute of standard RADIUS does
> not define a specification of the format of the string; the Location-ID does
> specify a format (isocc=<ISO_Country_Code>,cc=<E.164_Country_Code>, ...).
>
> I guess I'll leave it at that.  Either Location-ID or NAS-Identifier is
> fine, as long as the format is specified so that we can all agree on and use
> the same string.

<Nagi? Do you think we need two different identifiers, NAS-Identifier and as
well as Location-ID in some cases.

>
>
> > 3) The draft proposes a new Time attribute (along with Location-ID
> > and Location Name).  Why can't we use Event-TimeStamp define in RFC-2869
> > which is also in UTC format? Is there a specific reason to have a new
> attribute
> > defined here again?

> The Event-Timestamp of RFC-2869 is defined to be an Accounting-Request

> packet attribute.  Perhaps for standardization this attribute could be
> carried in either an Access-Request or an Accounting-Request packet?

<Nagi>I think it doesn't harm if we make this attribute applicable to any
packet.   To be future safe, I propose to make the Event-TimeStamp attribute
applicable to any type of packet.

>
>
> > 4) Section 2.3.4 PVID (port VLAN ID) proposes to replace the use of
> > Tunnel-Type=VLAN (13), Tunnel-Medium-
> >  Type=802, and Tunnel-Private-Group-ID=VLANID
> > as described in RFC 3580. I'm wondering how can a VSA which is by
> > definition  an optional can replace the use of some thing that was
> standardized
> > before. I also feel that Tunnel Type usage doesn't look nice to carry
> VLAN-IDs.
> > But I suggest that we define a standard  attribute to carry VLAN-ID which
> > can replace Tunnel Type usage.
>
> Since RFC-3580 is informational and regards suggested usage, it was hoped
> that a new attribute, categorized as a part of a set of "LAN Edge"
> attributes, would be a preferable solution.  So the question is: should we
> overload an old attribute which was not intended to carry VLAN information
> in the first place (as in RFC-3580), or should we be redundant and define a
> new one (as in this document)?  Perhaps the best option is along the lines
> of what was suggested by another reviewer here in this forum, wherein we
> create a better categorization of attributes, including common and
> domain-specific.

<Nagi> I agree with you.  Though it is redundant, better define new attribute.
I disagree if you say the new one is VSA.

>
>
> > 5) I'm trying to undertand the difference between PVID and Egress-VID.
> > You mean, PVID is the default-VLAN-ID and Egree-VIDs are allowed list
> > of VLAN-IDs. Right?
>
> You are absolutely correct.  I favored using that terminology, but my friend
> and colleague Paul Congdon, a confirmed IEEE 802 guy, favored the more
> technically-precise but obtuse terminology you see there.  :-)

<Nagi>I don't have any concerns if the message is clear to all. Paul, can we
use the terminology that we are familiar atleast inside the explanation :-)

>
>
> > 6) Section 2.3.6- How do we map the user-priority-generation-table?
> > How is a byte (rather than a bit) is useful to re-map the priorities.
>
> The idea is that we send down an entire table of prioritization mapping,
> which will tell the edge device how to map any of the incoming priorities.
> Thus if byte 0's value is 4, and byte 1's value is 2, and byte 2's value is
> 8, then incoming packets with priority 0 will be set to priority 4, incoming
> packets with priority 1 will be set to priority 2, and incoming packets with
> priority 2 will be set to priority 8, and so on.  If all packets are to be
> forced to fixed priority, then all eight bytes of the table will have that
> same value.
>
> I hope that I understood your question and that this explains the intent of
> the table.

<Nagi> Yes, I got it.

>
>
> > 7) Section 2.3.7 - IP Filter Name: Do we really need a new attribute for
> this?
> > Can't we use the Filter-ID defined in the standard. I agree that it
> doesn't
> > explicitly mean what filter it is.
>
> This is again the issue of whether to re-use an existing attribute, or
> define a new one within the domain ("LAN Edge") where it best belongs.

<Nagi> I see your point. My argument is that it is more work to the
implementors. Is it worth?

>
>
> > 8) I guess Bandwidth attributes "passes muster". I don't think the
> > standardization of these attributes cause any problem to the implementors
> > nor does it compell the radius client / proxy implementations to support
> > these attributes.  In the "Table of attributes" section, we can specify if
> the
> > attribute may not be present at all.
>
> Agreed.  Although your use of the phrase "passes muster" makes me wonder
> where that phrase came from.  I guess it's time to visit the word-etymology
> web site...
>
>

Even I had to refer the idiom in dictionary.com but I thought that was the
common usage and borrowed it from David Nelson  ;-)

David, what are your comments on both the phrase and the bandwidth attributes
:-)

Regards
Nagi.

>
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of nagi reddy jonnala
> Sent: Thursday, December 18, 2003 1:54 AM
> To: BLACK,CHUCK (HP-Roseville,ex1)
> Cc: [email-masked]
> Subject: questions/comments on draft-black-radius-lanedge-00.txt
>
> I've read
> http://www.drizzle.com/~aboba/IEEE/draft-black-radius-lanedge-00.txt
>
> and have some questions and comments:
>
> 1) Do access devices (such as IP DSLAMs) come under LAN Edge switches? What
> exactly does a LAN Edge device mean?
>
> 2) When do we use the Location-ID and Location-Name attributes. I guess they
> are used in wireless networks.  Can't NAS-ID be used to identify the
> Location? Can you explain little further.
>
> 3) The draft proposes a new Time attribute (along with Location-ID and
> Location Name).  Why can't we use Event-TimeStamp define in RFC-2869 which
> is also in UTC format? Is there a specific reason to have a new attribute
> defined here again?
>
> 4) Section 2.3.4 PVID (port VLAN ID) proposes to replace the use of
> Tunnel-Type=VLAN (13), Tunnel-Medium-
>    Type=802, and Tunnel-Private-Group-ID=VLANID as described in RFC 3580.
> I'm wondering how can a VSA which is by definition  an optional can replace
> the use of some thing that was standardized before. I also feel that Tunnel
> Type usage doesn't look nice to carry VLAN-IDs. But I suggest that we define
> a standard  attribute to carry VLAN-ID which can replace Tunnel Type usage.
>
> 5) I'm trying to undertand the difference between PVID and Egress-VID.  You
> mean, PVID is the default-VLAN-ID and Egree-VIDs are allowed list of
> VLAN-IDs. Right?
>
> 6) Section 2.3.6- How do we map the user-priority-generation-table? How is a
> byte (rather than a bit) is useful to re-map the priorities.
>
> 7) Section 2.3.7 - IP Filter Name: Do we really need a new attribute for
> this? Can't we use the Filter-ID defined in the standard. I agree that it
> doesn't explicitly mean what filter it is.
>
> 8) I guess Bandwidth attributes "passes muster". I don't think the
> standardization of these attributes cause any problem to the implementors
> nor does it compell the radius client / proxy implementations to support
> these attributes.  In the "Table of attributes" section, we can specify if
> the attribute may not be present at all.
>
> Comments welcome.
>
> Regards
> Nagi.
>
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 18 Dec 2003 17:47:30 +0000
From: "CONGDON,PAUL (HP-Roseville,ex1)" <[email-masked]>
To: "BLACK,CHUCK (HP-Roseville,ex1)" <[email-masked]>, [email-masked]
Subject: RE: questions/comments on draft-black-radius-lanedge-00.txt
Date: Thu, 18 Dec 2003 12:46:45 -0500

I have a few comments and clarifications below...

> Subject: RE: questions/comments on draft-black-radius-lanedge-00.txt
> 
> 
> Hi Nagi,
> 
> Thanks for the comments.  Here are my replies:
>  
> > 1) Do access devices (such as IP DSLAMs) come under
> > LAN Edge switches? What exactly does a LAN Edge device mean?
> 
> The intent of the document is to attempt to define the 
> delivery of 'edge'-type attributes -- VLANs, ACLs, QoS, 
> bandwidth -- for delivery via RADIUS reply to the RADIUS 
> client (NAS or switch).  Your suggestion of considering these 
> attributes for a broadband environment such as IP DSLAM is 
> interesting and, assuming those DSLAM devices support some or 
> all of those attributes, they may as well be a good fit.
>

The primary focus has been on IEEE 802 devices like Ethernet switches and
802.11 Access Points.  Thus the term 'LAN'.  We are searching for
'standardized' management controls in 802 devices that we can configure with
these attributes.  Unfortunately, many of the things we want to configure
don't have standard controls.  That said, I see no reason why other 'edge'
devices couldn't take advantage of these attributes.  The first choice,
however, is to configure 'standardized' 802 management controls.  I'm not
sure if IP DSLAMs overload these controls or not.  I'm guessing they have
their own.
 
> > 2) When do we use the Location-ID and Location-Name attributes.
> > I guess they are used in wireless networks.  Can't NAS-ID be used 
> > to identify the Location? Can you explain little further.
> 
> This document was really following the lead of the wireless 
> specification WISPr, which proposes the wireless attributes 
> for Location-ID and Location-Name.  It is possible that there 
> should be standard RADIUS attributes for these.  The 
> NAS-Identifier attribute of standard RADIUS does not define a 
> specification of the format of the string; the Location-ID 
> does specify a format 
> (isocc=<ISO_Country_Code>,cc=<E.164_Country_Code>, ...).  
> 
> I guess I'll leave it at that.  Either Location-ID or 
> NAS-Identifier is fine, as long as the format is specified so 
> that we can all agree on and use the same string.
>

We certainly want to stick with the X.500 stuff for location specification.
I think NAS-Id typically contains a domain name and doesn't have specific
location information unless the string is formatted for this.  Location-ID
seems like the best idea to get specific location data.
 
> 
> > 5) I'm trying to undertand the difference between PVID and 
> Egress-VID.
> > You mean, PVID is the default-VLAN-ID and Egree-VIDs are 
> allowed list 
> > of VLAN-IDs. Right?
> 
> You are absolutely correct.  I favored using that 
> terminology, but my friend and colleague Paul Congdon, a 
> confirmed IEEE 802 guy, favored the more technically-precise 
> but obtuse terminology you see there.  :-)
>

Actually, this isn't entirely correct.  The PVID is the default VLAN for
untagged traffic received at the port.  The Egress list contains the VLANs
that can be transmitted out of the port (in either tagged or untagged
format).  Familiarity with IEEE 802.1Q helps a lot here.  If 'Ingress
Filters' are enabled, then the egress list kind of also becomes the list of
'allowed' VLANs to be received as well.  So, to confuse everyone here, VLANs
are sort of asymmetric unless Ingress Filters are turned on.  With untagged
traffic (which is what is typically at the 'edge' anyway), it is possible to
have many VLANs egress a port, but all received untagged traffic is mapped
to a single VLAN denoted by the PVID.  Since the traffic is untagged, the
different VLANs egressing the port aren't really apparent to the end
stations on that link.  This is really just a tricky way for switches to do
some forms of filtering.  With tagged traffic, the VLANs are explicitly
labeled, so everyone knows what VLAN the frame belongs to.  When 'ingress
filters' are enabled, the tagged frames received must be members of the
VLANs that are listed on the egress list.
 
Paul

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 18 Dec 2003 16:49:09 +0000
From: "BLACK,CHUCK (HP-Roseville,ex1)" <[email-masked]>
To: [email-masked]
Cc: "BLACK,CHUCK (HP-Roseville,ex1)" <[email-masked]>
Subject: RE: questions/comments on draft-black-radius-lanedge-00.txt
Date: Thu, 18 Dec 2003 08:48:23 -0800

Hi Nagi,

Thanks for the comments.  Here are my replies:
 
> 1) Do access devices (such as IP DSLAMs) come under 
> LAN Edge switches? What exactly does a LAN Edge device mean?

The intent of the document is to attempt to define the delivery of
'edge'-type attributes -- VLANs, ACLs, QoS, bandwidth -- for delivery via
RADIUS reply to the RADIUS client (NAS or switch).  Your suggestion of
considering these attributes for a broadband environment such as IP DSLAM is
interesting and, assuming those DSLAM devices support some or all of those
attributes, they may as well be a good fit.

> 2) When do we use the Location-ID and Location-Name attributes. 
> I guess they are used in wireless networks.  Can't NAS-ID be used 
> to identify the Location? Can you explain little further.

This document was really following the lead of the wireless specification
WISPr, which proposes the wireless attributes for Location-ID and
Location-Name.  It is possible that there should be standard RADIUS
attributes for these.  The NAS-Identifier attribute of standard RADIUS does
not define a specification of the format of the string; the Location-ID does
specify a format (isocc=<ISO_Country_Code>,cc=<E.164_Country_Code>, ...).  

I guess I'll leave it at that.  Either Location-ID or NAS-Identifier is
fine, as long as the format is specified so that we can all agree on and use
the same string.

> 3) The draft proposes a new Time attribute (along with Location-ID 
> and Location Name).  Why can't we use Event-TimeStamp define in RFC-2869 
> which is also in UTC format? Is there a specific reason to have a new
attribute 
> defined here again?

The Event-Timestamp of RFC-2869 is defined to be an Accounting-Request
packet attribute.  Perhaps for standardization this attribute could be
carried in either an Access-Request or an Accounting-Request packet?

> 4) Section 2.3.4 PVID (port VLAN ID) proposes to replace the use of 
> Tunnel-Type=VLAN (13), Tunnel-Medium-
>  Type=802, and Tunnel-Private-Group-ID=VLANID 
> as described in RFC 3580. I'm wondering how can a VSA which is by 
> definition  an optional can replace the use of some thing that was
standardized 
> before. I also feel that Tunnel Type usage doesn't look nice to carry
VLAN-IDs. 
> But I suggest that we define a standard  attribute to carry VLAN-ID which 
> can replace Tunnel Type usage.

Since RFC-3580 is informational and regards suggested usage, it was hoped
that a new attribute, categorized as a part of a set of "LAN Edge"
attributes, would be a preferable solution.  So the question is: should we
overload an old attribute which was not intended to carry VLAN information
in the first place (as in RFC-3580), or should we be redundant and define a
new one (as in this document)?  Perhaps the best option is along the lines
of what was suggested by another reviewer here in this forum, wherein we
create a better categorization of attributes, including common and
domain-specific.

> 5) I'm trying to undertand the difference between PVID and Egress-VID.  
> You mean, PVID is the default-VLAN-ID and Egree-VIDs are allowed list 
> of VLAN-IDs. Right?

You are absolutely correct.  I favored using that terminology, but my friend
and colleague Paul Congdon, a confirmed IEEE 802 guy, favored the more
technically-precise but obtuse terminology you see there.  :-)

> 6) Section 2.3.6- How do we map the user-priority-generation-table? 
> How is a byte (rather than a bit) is useful to re-map the priorities.

The idea is that we send down an entire table of prioritization mapping,
which will tell the edge device how to map any of the incoming priorities.
Thus if byte 0's value is 4, and byte 1's value is 2, and byte 2's value is
8, then incoming packets with priority 0 will be set to priority 4, incoming
packets with priority 1 will be set to priority 2, and incoming packets with
priority 2 will be set to priority 8, and so on.  If all packets are to be
forced to fixed priority, then all eight bytes of the table will have that
same value.  

I hope that I understood your question and that this explains the intent of
the table.

> 7) Section 2.3.7 - IP Filter Name: Do we really need a new attribute for
this? 
> Can't we use the Filter-ID defined in the standard. I agree that it
doesn't 
> explicitly mean what filter it is.

This is again the issue of whether to re-use an existing attribute, or
define a new one within the domain ("LAN Edge") where it best belongs.

> 8) I guess Bandwidth attributes "passes muster". I don't think the 
> standardization of these attributes cause any problem to the implementors 
> nor does it compell the radius client / proxy implementations to support 
> these attributes.  In the "Table of attributes" section, we can specify if
the 
> attribute may not be present at all.

Agreed.  Although your use of the phrase "passes muster" makes me wonder
where that phrase came from.  I guess it's time to visit the word-etymology
web site...

Thanks again for the comments,

/chuck

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of nagi reddy jonnala
Sent: Thursday, December 18, 2003 1:54 AM
To: BLACK,CHUCK (HP-Roseville,ex1)
Cc: [email-masked]
Subject: questions/comments on draft-black-radius-lanedge-00.txt

I've read
http://www.drizzle.com/~aboba/IEEE/draft-black-radius-lanedge-00.txt

and have some questions and comments:

1) Do access devices (such as IP DSLAMs) come under LAN Edge switches? What
exactly does a LAN Edge device mean?

2) When do we use the Location-ID and Location-Name attributes. I guess they
are used in wireless networks.  Can't NAS-ID be used to identify the
Location? Can you explain little further.

3) The draft proposes a new Time attribute (along with Location-ID and
Location Name).  Why can't we use Event-TimeStamp define in RFC-2869 which
is also in UTC format? Is there a specific reason to have a new attribute
defined here again?

4) Section 2.3.4 PVID (port VLAN ID) proposes to replace the use of
Tunnel-Type=VLAN (13), Tunnel-Medium-
   Type=802, and Tunnel-Private-Group-ID=VLANID as described in RFC 3580.
I'm wondering how can a VSA which is by definition  an optional can replace
the use of some thing that was standardized before. I also feel that Tunnel
Type usage doesn't look nice to carry VLAN-IDs. But I suggest that we define
a standard  attribute to carry VLAN-ID which can replace Tunnel Type usage.

5) I'm trying to undertand the difference between PVID and Egress-VID.  You
mean, PVID is the default-VLAN-ID and Egree-VIDs are allowed list of
VLAN-IDs. Right?

6) Section 2.3.6- How do we map the user-priority-generation-table? How is a
byte (rather than a bit) is useful to re-map the priorities.

7) Section 2.3.7 - IP Filter Name: Do we really need a new attribute for
this? Can't we use the Filter-ID defined in the standard. I agree that it
doesn't explicitly mean what filter it is.

8) I guess Bandwidth attributes "passes muster". I don't think the
standardization of these attributes cause any problem to the implementors
nor does it compell the radius client / proxy implementations to support
these attributes.  In the "Table of attributes" section, we can specify if
the attribute may not be present at all.

Comments welcome.

Regards
Nagi.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 18 Dec 2003 13:17:04 +0000
From: Tschofenig Hannes <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked], [email-masked]
Subject: RE: QoS attributes
Date: Thu, 18 Dec 2003 14:16:17 +0100

thank you john for the pointers. 

qos is more than just shuffling some bandwidth parameters around.  

comments to the drafts are highly appreciated. 

ciao
hannes

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Thursday, December 18, 2003 10:40 AM
> To: [email-masked]; [email-masked]
> Subject: RE: QoS attributes
> 
> 
> Hi all,
> 
> My 2 cents are as follows: RADext/AAAext (or whatever) 
> shouldn't define QoS signaling, 
> NSIS is already doing that:
> 
> http://www.ietf.org/html.charters/nsis-charter.html
> 
> There has been some discussion on AAA issues for QoS:
> 
> http://www.ietf.org/internet-drafts/draft-alfano-aaa-qosreq-01.txt
> http://www.ietf.org/internet-drafts/draft-tschofenig-nsis-qos-
> authz-issues-00.txt
> 
> Looking into QoS issues, my feeling is that we want to 
> specify QoS classes.
> These classes may support a set of QoS parameters.  I think that QoS
> will be an area that vendors try to differentiate on; service 
> providers
> may create services that support different QoS parameters, 
> etc.  I don't
> think that we can get into the QoS signaling / provisioning / 
> definition
> of QoS parameters, as that excedes the scope of AAA (either RADIUS or
> Diameter).  I would prefer that RADIUS / Diameter would contain a 
> QoS class parameter, which could make use something like a IANA QoS
> class registry. 
> 
> Different SDOs have different plans ITU-T, 3GPP, 3GPP2, etc. all have
> defined seperate QOS classes.  One could imagine registering 
> these classes
> in IANA, and service providers could support, in various 
> degrees, different
> QoS classes.  It would then be in scope of AAA to provide 
> authorization for
> these classes.
> 
> John
> 
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 18 Dec 2003 09:54:07 +0000
Date: Thu, 18 Dec 2003 10:53:42 +0100
From: nagi reddy jonnala <[email-masked]>
Organization: Alcatel Telecom
To: "BLACK,CHUCK (HP-Roseville,ex1)" <[email-masked]>
CC: [email-masked]
Subject: questions/comments on draft-black-radius-lanedge-00.txt

I've read
http://www.drizzle.com/~aboba/IEEE/draft-black-radius-lanedge-00.txt

and have some questions and comments:

1) Do access devices (such as IP DSLAMs) come under LAN Edge switches? What
exactly does a LAN Edge device mean?

2) When do we use the Location-ID and Location-Name attributes. I guess they
are used in wireless networks.  Can't NAS-ID be used to identify the
Location? Can you explain little further.

3) The draft proposes a new Time attribute (along with Location-ID and
Location Name).  Why can't we use Event-TimeStamp define in RFC-2869 which
is also in UTC format? Is there a specific reason to have a new attribute
defined here again?

4) Section 2.3.4 PVID (port VLAN ID) proposes to replace the use of
Tunnel-Type=VLAN (13), Tunnel-Medium-
   Type=802, and Tunnel-Private-Group-ID=VLANID as described in RFC 3580.
I'm wondering how can a VSA which is by definition  an optional can replace
the use of some thing that was standardized before. I also feel that Tunnel
Type usage doesn't look nice to carry VLAN-IDs. But I suggest that we define
a standard  attribute to carry VLAN-ID which can replace Tunnel Type usage.

5) I'm trying to undertand the difference between PVID and Egress-VID.  You
mean, PVID is the default-VLAN-ID and Egree-VIDs are allowed list of
VLAN-IDs. Right?

6) Section 2.3.6- How do we map the user-priority-generation-table? How is a
byte (rather than a bit) is useful to re-map the priorities.

7) Section 2.3.7 - IP Filter Name: Do we really need a new attribute for
this? Can't we use the Filter-ID defined in the standard. I agree that it
doesn't explicitly mean what filter it is.

8) I guess Bandwidth attributes "passes muster". I don't think the
standardization of these attributes cause any problem to the implementors
nor does it compell the radius client / proxy implementations to support
these attributes.  In the "Table of attributes" section, we can specify if
the attribute may not be present at all.

Comments welcome.

Regards
Nagi.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 18 Dec 2003 09:40:26 +0000
content-class: urn:content-classes:message
Subject: RE: QoS attributes
Date: Thu, 18 Dec 2003 11:39:34 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Hi all,

My 2 cents are as follows: RADext/AAAext (or whatever) shouldn't define =
QoS signaling,=20
NSIS is already doing that:

http://www.ietf.org/html.charters/nsis-charter.html

There has been some discussion on AAA issues for QoS:

http://www.ietf.org/internet-drafts/draft-alfano-aaa-qosreq-01.txt
http://www.ietf.org/internet-drafts/draft-tschofenig-nsis-qos-authz-issue=
s-00.txt

Looking into QoS issues, my feeling is that we want to specify QoS =
classes.
These classes may support a set of QoS parameters.  I think that QoS
will be an area that vendors try to differentiate on; service providers
may create services that support different QoS parameters, etc.  I don't
think that we can get into the QoS signaling / provisioning / definition
of QoS parameters, as that excedes the scope of AAA (either RADIUS or
Diameter).  I would prefer that RADIUS / Diameter would contain a=20
QoS class parameter, which could make use something like a IANA QoS
class registry.=20

Different SDOs have different plans ITU-T, 3GPP, 3GPP2, etc. all have
defined seperate QOS classes.  One could imagine registering these =
classes
in IANA, and service providers could support, in various degrees, =
different
QoS classes.  It would then be in scope of AAA to provide authorization =
for
these classes.

John

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 18 Dec 2003 08:30:24 +0000
Date: Thu, 18 Dec 2003 10:29:14 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: "Nelson, David" <[email-masked]>
Cc: [email-masked]
Subject: Re: QoS attributes

Nelson, David wrote:

> The attribute space is certainly finite.  My perception is that RADIUS

Yes. I would add that extending attribute space is always possible
later, as long as you have at least one free number left... this
was by the way the approach taken in EAP, RFC 2284bis.

> Let's come to consensus on the list of attributes that "pass muster",
> and then we can take a head-count to see if the attribute address space
> is in imminent risk of exhaustion.

I agree.

--Jari

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Thu, 18 Dec 2003 08:23:59 +0000
Date: Thu, 18 Dec 2003 10:22:32 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Avi Lior <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Re: [AAA-WG]: Question regarding IP Filter Rule

Avi Lior wrote:
> Hi Jari,
> 
> You could use Framed-Route but now all traffic would be routed to the Portal
> etc.....
> 
> I think it would be more appropriate to introduce a new attribute so that:
> 
> A) the NAS would deal with the routing functions (as it always does) and the
> Portal does not have to do it.
> 
> B) We would have the flexibility to decide whether to route all traffic or
> just some traffic.

Perhaps.

Are the redirection schemes used for payment? I.e. I need to log in to the
web page before I can continue? Or for something else?

There is a difference because if its used for payment, redirecting
just some protocols may leave a hole to the protocols. For instance,
I have sometimes succeeded in doing all my e-mail over SSH even if
there was some http-directing thing that prevented all web traffic.

--Jari

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 17 Dec 2003 22:21:32 +0000
From: "Ed Van Horne" <[email-masked]>
To: "'Avi Lior'" <[email-masked]>, <[email-masked]>
Subject: RE: QoS attributes
Date: Wed, 17 Dec 2003 14:20:08 -0800
Organization: Cisco Systems

Avi,

I agree with you on there being more than one type of QoS attribute. In
particular, robust support of VoIP, which seems to be taking off in the
market place, demands a way to prioritize and perhaps even reserve
bandwidth. VoIP is very sensitive to dropouts and jitter. The current
state of the art is rather variable voice quality depending on network
load, etc. (There was an interesting discussion of VoIP on PBS Talk of
the Nation recently.) So far this lack of a consistent level of service
is acceptable because VoIP is dirt cheap.

Fixing this is much more than a RADIUS issue, since consistent
technology to prioritize and reserve bandwidth is needed end to end. The
whole things falls apart if even one intermediate device does not
support QoS.

Most of this is out of scope for this discussion, but we could discuss
the RADIUS piece that determines whether a user is *allowed* to use this
hypothetical service.

My $.02,
Ed

Ed Van Horne 
Building Broadband Solutions Unit - San Diego 
Cisco Systems 
10935 Vista Sorrento Parkway 
San Diego, CA 92130 
858.526.1152 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Avi Lior
Sent: Tuesday, December 16, 2003 9:29 AM
To: [email-masked]'
Subject: QoS attributes

I noticed that we are talking about QoS on the list.

In the current drafts folks are talking about QoS but are only
specifying Bandwidth attributes.  There are other QoS attributes. The
problem is that there are a lot of different QoS attributes and
different flavours as well. The question is which attributes and
flavours should be modelled.

I think we need a RADIUS QoS Draft in general.  I started to write one
and stopped to see what was going on in a couple of other areas. (For
example Diameter and as well, work in 3GPP2 where the interface between
the PDSN and the AAA will be used to query and transport QoS
attributes).

For example, one of the useful things about the CoA is that now I can
change the QoS attributes of a session mid stream.  So it would be
useful to define these attributes (and not just Bandwidth).

Any comments would be greatly appreciated.

> -----Original Message-----
> From: Avi Lior [mailto:[email-masked]]
> Sent: Tuesday, December 16, 2003 11:45 AM
> To: [email-masked]'; [email-masked]'; Adrangi, Farid
> Subject: RE: Comments on 
> draft-adrangi-radius-extension-for-pwlan-00.txt
> 
> 
> 
> 
> > -----Original Message-----
> Jari wrote:
> 
>   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.
> 
> Avi's reply:
> 
> A bit mask maybe a better approach.
> 
> Capability advertizing is important in certain situations
> such a prepaid. We need to be able to ensure that AAA server 
> can make policy decision based on the capabilities that are 
> supported by the NAS.  In prepaid we need to know whether the 
> NAS can actually do that 'counting' and enforce the policy 
> that is required.  If the NAS did not then the AAA can decide 
> on a different tack for providing service to a prepaid 
> client.  For example it can ask the NAS to tunnel the client 
> to another device that can enforce the policy.
> 
> We also need to know whether the NAS supports POD or COA
> (3576) messages. Again this is improtant for prepaid etc....
> 
> Whether or not this is standardized or not it is important
> for the prepaid feature and hence its also part of the prepaid draft.
> 
> --
> to unsubscribe send a message to
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 17 Dec 2003 18:51:15 +0000
content-class: urn:content-classes:message
Subject: RE: QoS attributes
Date: Wed, 17 Dec 2003 10:49:55 -0800
From: "Bari, Farooq" <[email-masked]>
To: "nagi reddy jonnala" <[email-masked]>, "Nelson, David" <[email-masked]>, <[email-masked]>

Hi Nagi,

I am not sure what does subtitles have to do with QoS but If I
understood your example in 3) correctly, you want to see movie over the
internet and have same experience as in DVD. If this is correct then you
would be using something similar to RTSP in the control plane (RTSP
provides VCR like functionality of start, stop, forward, rewind, Pause
etc.). As part of the session setup, RTSP provides / negotiates codec
information along with bandwidth using SDP protocol. RADIUS does not get
involved in this process. I am trying to understand now, how you are
thinking of using RADIUS in the whole process. Are you suggesting that
after the session setup negotiations, the RTSP server (or the client ?)
talks to the RADIUS server, the RADIUS server then talks to RADIUS
client, the RADIUS client then talks to the policy enforcement point ?=20

Regards,

Farooq

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of nagi reddy jonnala
Sent: Wednesday, December 17, 2003 9:58 AM
To: Nelson, David; [email-masked]
Subject: Re: QoS attributes

David & All,

1) Yes, Attribute space is limited:

   I believe everybody thinks the attribute space is precious and I
think the reasonable proposals are  questioned based on this reason not
because of their merits/de-merits.

If the attribute space is not precious, then why is that the draft
dealing with LAN and WLAN specific attributes are not standardized. I
think the reason is VSA provide subtypes and this draft wants to
introduce handful of

attributes which we don't have space.  Right?

2)  QoS attributes:

    Even I don't believe in adding the all the QoS attributes under the
sun. At the sametime, I see a possibility for the need to change the QoS
attributes dynamically and it doesn't take much effort to standardize
them if we have some way to group them in one attribute.

3) Why should we handle QoS attributes in Radius:

It is a matter of choice and flexibility provided. For example, when I
watch a French movie DVD, I would like to see English subtitles. I can
switch on the subtitles using my remote  and the english menu is
provided by the DVD player (or) I can select an option in the movie menu
provided by

the particular movie DVD.  I like this option because I don't understand
French movie menu.

It is upto the Vendors to choose if they support this way handling the
QoS attributes or not. My argument is that why does the standard body
put the restriction?

Regards
Nagi

--
to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 17 Dec 2003 18:44:18 +0000
From: Avi Lior <[email-masked]>
To: "[email-masked]'" <[email-masked]>, Avi Lior <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: [AAA-WG]: Question regarding IP Filter Rule
Date: Wed, 17 Dec 2003 13:43:52 -0500

Yes. But you also need the same in Diameter (I think? Well DCC did right?)

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Wednesday, December 17, 2003 12:03 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: [AAA-WG]: Question regarding IP Filter Rule
> 
> 
> > You have to invent a new attribute or use Framed-IP-Route to
> > do redirects.
> 
> Are you talking about RADIUS attribute? 
> 
> > -----Original Message-----
> > From: ext Avi Lior [mailto:[email-masked]]
> > Sent: 17 December, 2003 18:58
> > To: Stura Marco (NET/Helsinki); Avi Lior
> > Cc: [email-masked]; [email-masked]
> > Subject: RE: [AAA-WG]: Question regarding IP Filter Rule
> > 
> > 
> > Scratch that.  I was mistaken. IPFW does not support redirects.
> > 
> > You have to invent a new attribute or use Framed-IP-Route to
> > do redirects.
> > 
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]]
> > > Sent: Wednesday, December 17, 2003 2:20 AM
> > > To: [email-masked]
> > > Cc: [email-masked]; [email-masked]
> > > Subject: RE: [AAA-WG]: Question regarding IP Filter Rule
> > > 
> > > 
> > > Avi Lior wrote
> > > 
> > > > The Black I-D and PWLAN draft prompted me to check 
> something out.
> > > > 
> > > > It seems to me that something is missing in Diameter.  
> Using the 
> > > > filter specification in 3588 its not clear how I force 
> a forward.
> > > > The only actions
> > > > supported are permit or deny whereas ipfw supports a forward 
> > > > mechanism as
> > > > well.
> > > > 
> > > > The motivation for this is the requirement in (WLAN for
> > > > example) whereby I
> > > > want to force all http traffic to a specific portal and
> > > deny all other
> > > > traffic until the portal instructs the NAS otherwise.  This
> > > > needs to be done
> > > > either during an Access Accept or mid-session using COA.
> > > 
> > > How to redirect user traffic (e.g. http) is implementation
> > > specific and I think is not a Diameter business. If you want 
> > > to indicate redirect traffic to a specific address, in 
> > > Diameter applications you can define a grouped AVP to realize 
> > > the functionality. One example could be the 
> > > Final-Unit-Indication in the DCC application.
> > > 
> > > Regards
> > > Marco
> > > 
> > 
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 17 Dec 2003 18:16:26 +0000
content-class: urn:content-classes:message
Subject: RE: QoS attributes
Date: Wed, 17 Dec 2003 13:15:32 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Nagi writes...

> If the attribute space is not precious, then why is that the draft
dealing
> with LAN and WLAN specific attributes are not standardized. I think
the
> reason is VSA provide subtypes and this draft wants to introduce
handful
> of attributes which we don't have space.  Right?

The attribute space is certainly finite.  My perception is that RADIUS
has a finite lifetime (remember we do have Diameter) and that the "good
ideas" for standard attributes will run out before the attribute space
runs out. The limited address space is a secondary, consideration, IMHO.
Of course, future events may prove me wrong.

So why are some proposals "good ideas" and some not?  Well, items that
have broad Internet Community consensus should be standardized.  Items
that are special "tweaks" that allow one vendor to differentiate itself
from the competition (in non interoperable ways) are what the VSA
attribute is for.  In between those extremes, we have the gray areas,
i.e. proposals that are of interest to a specific industry or market
segment or are of interest to a specific vendor.

It an attribute "passes muster" for broad Internet Community consensus
and multi-vendor interoperability it deserves to be a stand-alone,
standardized attribute.  If it does not pass that muster, it should be a
VSA.  Trying to "have it both ways" and bury multiple attributes in one
standard attribute, via sub-types, sub-fields, or whatever, is simply a
disservice to the RADIUS community, IMHO.

Allowing "bad ideas" to be standardized places an extra burden on the
implementers of RADIUS Clients, Servers and Proxies, who will be
pressured to support the new attributes.  That's why the RADUIS IANA
considerations talks about the requirement for IETF Standards Action.

Let's come to consensus on the list of attributes that "pass muster",
and then we can take a head-count to see if the attribute address space
is in imminent risk of exhaustion.
=20
-- Dave

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 17 Dec 2003 17:59:54 +0000
Date: Wed, 17 Dec 2003 18:58:13 +0100
From: nagi reddy jonnala <[email-masked]>
Organization: Alcatel Telecom
To: "Nelson, David" <[email-masked]>, [email-masked]
Subject: Re: QoS attributes

David & All,

1) Yes, Attribute space is limited:

   I believe everybody thinks the attribute space is precious and I think
the reasonable proposals are  questioned based on this reason not because
of their merits/de-merits.

If the attribute space is not precious, then why is that the draft dealing
with LAN and WLAN specific attributes are not standardized. I think the
reason is VSA provide subtypes and this draft wants to introduce handful of

attributes which we don't have space.  Right?

2)  QoS attributes:

    Even I don't believe in adding the all the QoS attributes under the
sun. At the sametime, I see a possibility for the need to change the QoS
attributes dynamically and it doesn't take much effort to standardize them
if we have some way to group them in one attribute.

3) Why should we handle QoS attributes in Radius:

It is a matter of choice and flexibility provided. For example, when I
watch a French movie DVD, I would like to see English subtitles. I can
switch on the subtitles using my remote  and the english menu is provided
by the DVD player (or) I can select an option in the movie menu provided by

the particular movie DVD.  I like this option because I don't understand
French movie menu.

It is upto the Vendors to choose if they support this way handling the QoS
attributes or not. My argument is that why does the standard body put the
restriction?

Regards
Nagi

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 17 Dec 2003 17:28:44 +0000
content-class: urn:content-classes:message
Subject: RE: QoS attributes
Date: Wed, 17 Dec 2003 09:27:55 -0800
From: "Bari, Farooq" <[email-masked]>
To: "Avi Lior" <[email-masked]>, "Bari, Farooq" <[email-masked]>, "Nelson, David" <[email-masked]>, <[email-masked]>

Hi Avi,

Most of the QoS sensitive services / applications have their own control
plane and corresponding protocols e.g. SIP, RTSP etc are used for
multimeida sessions and streaming. The QoS / bandwidth requirements etc.
are exchanged through them as part of session setup / modification and
in my opinion it is this control plane that should then be responsible
for informing the QoS enforcement point of the need for a specific QoS /
bandwidth for a specific service session. In many cases the enforcement
point may not actually be informed about it directly and the services
can for example do diffserv / bit coloring. The enforcement point will
however have to ensure that the request from a particular user for QoS
for certain service session does not fall outside the access network
capability or the user's QoS profile provided by the home network.

In the example that you gave, I would be quite surprised if operators
have such tight admission control whereby they can guarantee certain
minimum bandwidth for the last mile on a per user basis. I however think
average bandwidth to certain user can be achieved if the user was
classified for example as gold user who can if needed prioritize its
traffic by bit coloring  and therefore can have higher allowed average
bandwidth. That I believe can be done by just downloading user QoS
profile initially (that for example allows bit coloring from this user
to be honored in the access network) and later allowing applications to
use DSCP (no control protocol needed in this case).

Therefore I still think RADIUS QoS / bandwidth attribute is somewhat
static information to be used to define the overall bounds for a user -
the QoS individual for services has to be within these bounds but RADIUS
is not in the path of negotiating QoS for the services.

Regards

Farooq

-----Original Message-----
From: Avi Lior [mailto:[email-masked]]=20
Sent: Wednesday, December 17, 2003 8:36 AM
To: 'Bari, Farooq'; Avi Lior; 'Nelson, David'; [email-masked]'
Subject: RE: QoS attributes

Hi Farooq,

I will give you a real usecase in DSL/Cable systems that we are involved
with.

A user wants to download a movie from a content provider.  The Operator
offers a service whereby the user can extend his bandwidth for a period
of time for a fee.  This is called bandwidth on demand or BOD.  This is
done using two mechanisms: either by pressing a "turbo" button or by
going to a website.  In either case, the system validates that the
subscriber is allowed to request for more bandwidth, if so it then
checks to see what is available (not in scope for RADIUS but there are
ways to do this), and grants the user the bandwidth by sending the
network element a RADIUS CoA message (RFC 3576) instructing the device
to open up the user's pipe.  All of this is done mid-session.

This was an example where the user has initiated the request.  A similar
scenario can happen when the Content Provider can request that the
user's pipe be opened for a period of time.

Finally, there are examples that we are exploring now where a new IP
flow is requested mid session and the QoS has to be negotiated.  RADIUS
is involved because RADIUS know who the subscriber is and what the
subscriber is allowed.  Other elements are involved such as a Policy
Decision Function
(PDF) as well.  Still trying to figure out the details for this one.

But I hope that this gave you an insight that shows that these things
need to be addressed mid session as well as at the start of the session.

> -----Original Message-----
> From: Bari, Farooq [mailto:[email-masked]]
> Sent: December 16, 2003 5:05 PM
> To: Avi Lior; Nelson, David; [email-masked]
> Subject: RE: QoS attributes
>=20
>=20
> Hi Avi, all
>=20
> We need to have some consensus on what is the rationale/use
> of QoS attributes for RADIUS/DIAMETER before moving forward=20
> on the topic. It seems that we have more than one perspective=20
> on it. I for example see it as static information during an=20
> authorized session i.e. QoS information gets exchanged only=20
> during session setup where AN informs AAA of its capabilities=20
> and AAA server tells the AN of user QoS susbcription. I do=20
> not think RADIUS/DIAMETER servers should be involved in=20
> provisioning QoS for individual services running in an=20
> already authorized session later on.  However Avi's email=20
> suggests it is somewhat more dynamic than this. Avi, can you=20
> pls clarify if I understood your comments correctly.....
>=20
> Farooq
>=20
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> On Behalf Of Avi Lior
>=20
> Sent: Tuesday, December 16, 2003 1:42 PM
> To: 'Nelson, David'; [email-masked]
> Subject: RE: QoS attributes
>=20
>=20
>=20
> David Nelso wrote:
>=20
> > Provisioning detailed, and more importantly, potentially
> dynamic, QoS
> > parameters as authorization information in RADIUS or any other AAA
> > protocol is probably not the right thing to do.  What ought to be=20
> > provisioned is a "level of service" indication (e.g.=20
> bronze, silver,
> > gold, platinum) that can be used by each NAS to modify the QoS
> > parameter negotiation process for each session.
>=20
> It requires that each Hot Spot for example understand what to
> deliver to a Bronze User or a Gold user etc.....
>=20
> Like filter id, this just does not scale!
>=20
> We need a way to explicitly push attributes down to the NAS.
> Equally important is to make sure that the NAS tell us what=20
> it can currently honour. This will alow the home RADIUS to=20
> make an appropriate policy decision.
>=20
>=20
>=20
> --
> to unsubscribe send a message to
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 17 Dec 2003 17:01:10 +0000
From: Avi Lior <[email-masked]>
To: 'Jari Arkko' <[email-masked]>, Avi Lior <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: RE: [AAA-WG]: Question regarding IP Filter Rule
Date: Wed, 17 Dec 2003 12:00:48 -0500

Hi Jari,

You could use Framed-Route but now all traffic would be routed to the Portal
etc.....

I think it would be more appropriate to introduce a new attribute so that:

A) the NAS would deal with the routing functions (as it always does) and the
Portal does not have to do it.

B) We would have the flexibility to decide whether to route all traffic or
just some traffic.

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Tuesday, December 16, 2003 4:47 PM
> To: Avi Lior
> Cc: [email-masked]'; [email-masked]
> Subject: Re: [AAA-WG]: Question regarding IP Filter Rule
> 
> 
> Avi Lior wrote:
> > The Black I-D and PWLAN draft prompted me to check something out.
> > 
> > It seems to me that something is missing in Diameter.  Using the 
> > filter specification in 3588 its not clear how I force a 
> forward.  The 
> > only actions supported are permit or deny whereas ipfw supports a 
> > forward mechanism as well.
> > 
> > The motivation for this is the requirement in (WLAN for example) 
> > whereby I want to force all http traffic to a specific 
> portal and deny 
> > all other traffic until the portal instructs the NAS 
> otherwise.  This 
> > needs to be done either during an Access Accept or 
> mid-session using 
> > COA.
> 
> Does it have to be http specific? You could set Framed-Route 
> and then do Re-Authz when the routing changes. But 
> Framed-Route is not specific to a protocol or port.
> 
> --Jari
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 17 Dec 2003 16:58:28 +0000
From: Avi Lior <[email-masked]>
To: "[email-masked]'" <[email-masked]>, Avi Lior <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: [AAA-WG]: Question regarding IP Filter Rule
Date: Wed, 17 Dec 2003 11:58:05 -0500

Scratch that.  I was mistaken. IPFW does not support redirects.

You have to invent a new attribute or use Framed-IP-Route to do redirects.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Wednesday, December 17, 2003 2:20 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: [AAA-WG]: Question regarding IP Filter Rule
> 
> 
> Avi Lior wrote
> 
> > The Black I-D and PWLAN draft prompted me to check something out.
> > 
> > It seems to me that something is missing in Diameter.  Using
> > the filter
> > specification in 3588 its not clear how I force a forward.  
> > The only actions
> > supported are permit or deny whereas ipfw supports a forward 
> > mechanism as
> > well.
> > 
> > The motivation for this is the requirement in (WLAN for
> > example) whereby I
> > want to force all http traffic to a specific portal and 
> deny all other
> > traffic until the portal instructs the NAS otherwise.  This 
> > needs to be done
> > either during an Access Accept or mid-session using COA.
> 
> How to redirect user traffic (e.g. http) is implementation 
> specific and I think is not a Diameter business. If you want 
> to indicate redirect traffic to a specific address, in 
> Diameter applications you can define a grouped AVP to realize 
> the functionality. One example could be the 
> Final-Unit-Indication in the DCC application.
> 
> Regards
> Marco
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 17 Dec 2003 16:49:48 +0000
From: Avi Lior <[email-masked]>
To: "[email-masked]'" <[email-masked]>, Avi Lior <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: RE: [AAA-WG]: Question regarding IP Filter Rule
Date: Wed, 17 Dec 2003 11:49:27 -0500

Thanx Marco,

I am familiar with DCC.  My point was/is that IPFilterRules would have been
one way to do this and the IPFW appears to support this capability.  Its too
bad that IPFilterRules don't support this capability because now we have to
build it into our applications.

For RADIUS prepaid and PWLAN etc we will have to define a new AVP to do
redirects.  Alternatively, we could define an IPFilterRule attribute that
has the forwarding capability that went missing in Diameter.  But now we
would have a compatibility issue with Diameter.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Wednesday, December 17, 2003 2:20 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: RE: [AAA-WG]: Question regarding IP Filter Rule
> 
> 
> Avi Lior wrote
> 
> > The Black I-D and PWLAN draft prompted me to check something out.
> > 
> > It seems to me that something is missing in Diameter.  Using
> > the filter
> > specification in 3588 its not clear how I force a forward.  
> > The only actions
> > supported are permit or deny whereas ipfw supports a forward 
> > mechanism as
> > well.
> > 
> > The motivation for this is the requirement in (WLAN for
> > example) whereby I
> > want to force all http traffic to a specific portal and 
> deny all other
> > traffic until the portal instructs the NAS otherwise.  This 
> > needs to be done
> > either during an Access Accept or mid-session using COA.
> 
> How to redirect user traffic (e.g. http) is implementation 
> specific and I think is not a Diameter business. If you want 
> to indicate redirect traffic to a specific address, in 
> Diameter applications you can define a grouped AVP to realize 
> the functionality. One example could be the 
> Final-Unit-Indication in the DCC application.
> 
> Regards
> Marco
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 17 Dec 2003 16:36:05 +0000
From: Avi Lior <[email-masked]>
To: "'Bari, Farooq'" <[email-masked]>, Avi Lior <[email-masked]>, "'Nelson, David'" <[email-masked]>,  "[email-masked]'" <[email-masked]>
Subject: RE: QoS attributes
Date: Wed, 17 Dec 2003 11:35:44 -0500

Hi Farooq,

I will give you a real usecase in DSL/Cable systems that we are involved
with.

A user wants to download a movie from a content provider.  The Operator
offers a service whereby the user can extend his bandwidth for a period of
time for a fee.  This is called bandwidth on demand or BOD.  This is done
using two mechanisms: either by pressing a "turbo" button or by going to a
website.  In either case, the system validates that the subscriber is
allowed to request for more bandwidth, if so it then checks to see what is
available (not in scope for RADIUS but there are ways to do this), and
grants the user the bandwidth by sending the network element a RADIUS CoA
message (RFC 3576) instructing the device to open up the user's pipe.  All
of this is done mid-session.

This was an example where the user has initiated the request.  A similar
scenario can happen when the Content Provider can request that the user's
pipe be opened for a period of time.

Finally, there are examples that we are exploring now where a new IP flow is
requested mid session and the QoS has to be negotiated.  RADIUS is involved
because RADIUS know who the subscriber is and what the subscriber is
allowed.  Other elements are involved such as a Policy Decision Function
(PDF) as well.  Still trying to figure out the details for this one.

But I hope that this gave you an insight that shows that these things need
to be addressed mid session as well as at the start of the session.

> -----Original Message-----
> From: Bari, Farooq [mailto:[email-masked]] 
> Sent: December 16, 2003 5:05 PM
> To: Avi Lior; Nelson, David; [email-masked]
> Subject: RE: QoS attributes
> 
> 
> Hi Avi, all
> 
> We need to have some consensus on what is the rationale/use 
> of QoS attributes for RADIUS/DIAMETER before moving forward 
> on the topic. It seems that we have more than one perspective 
> on it. I for example see it as static information during an 
> authorized session i.e. QoS information gets exchanged only 
> during session setup where AN informs AAA of its capabilities 
> and AAA server tells the AN of user QoS susbcription. I do 
> not think RADIUS/DIAMETER servers should be involved in 
> provisioning QoS for individual services running in an 
> already authorized session later on.  However Avi's email 
> suggests it is somewhat more dynamic than this. Avi, can you 
> pls clarify if I understood your comments correctly.....
> 
> Farooq
> 
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]
> On Behalf Of Avi Lior
> 
> Sent: Tuesday, December 16, 2003 1:42 PM
> To: 'Nelson, David'; [email-masked]
> Subject: RE: QoS attributes
> 
> 
> 
> David Nelso wrote:
> 
> > Provisioning detailed, and more importantly, potentially 
> dynamic, QoS 
> > parameters as authorization information in RADIUS or any other AAA 
> > protocol is probably not the right thing to do.  What ought to be 
> > provisioned is a "level of service" indication (e.g. 
> bronze, silver, 
> > gold, platinum) that can be used by each NAS to modify the QoS 
> > parameter negotiation process for each session.
> 
> It requires that each Hot Spot for example understand what to 
> deliver to a Bronze User or a Gold user etc.....
> 
> Like filter id, this just does not scale!
> 
> We need a way to explicitly push attributes down to the NAS.  
> Equally important is to make sure that the NAS tell us what 
> it can currently honour. This will alow the home RADIUS to 
> make an appropriate policy decision.
> 
> 
> 
> --
> to unsubscribe send a message to 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 17 Dec 2003 16:32:22 +0000
From: Avi Lior <[email-masked]>
To: "'Nelson, David'" <[email-masked]>, [email-masked]
Subject: RE: QoS attributes
Date: Wed, 17 Dec 2003 11:32:03 -0500

Well I disagree....

The example you use is perfect.  Frequent flyers programs a mile is a mile
is a mile.  But when you claim your ticket although they all measure a mile
to be the same distance, one airline offers an economy ticket for 30,000
miles to europe another offers 40,000 miles.

It's the same for bandwidth.  They will all measure the bandwidth the same,
but a Gold user at one company will probably get more bandwidth then a gold
user in another company.

Although they belong to the same consortium they still compete and
differentiate themselves whereever and whenever they can -- and as Martha
would say, "this is a good thing".

The IETF should support protocols that will enable businesses to compete and
not prevent businesses from competing. 

> -----Original Message-----
> From: Nelson, David [mailto:[email-masked]] 
> Sent: Wednesday, December 17, 2003 11:00 AM
> To: [email-masked]
> Subject: RE: QoS attributes
> 
> 
> 
> Avi writes...
>  
> > Do you actually believe that operators will come to a 
> common agreement 
> > about what is a Gold profile?
> 
> I believe that operators that have a roaming agreement (i.e. 
> part of the same consortium) would do so.  I liken this to 
> the "partnerships" that the airlines have forged.  My 
> frequent flyer miles accumulate whenever I fly any of the 
> partners, and they honor each other frequent flyer status levels, etc.
> 
> Competitors would not easily come to agreement, but then 
> competitors may not want to allow transparent roaming across 
> each others infrastructure, so that point seems somewhat moot.
> 
> > Doesn't the very essence of competition require that they 
> would have a 
> > disagreement about what a Gold Profile is?
> 
> Yes, but it's not the competitors I'm addressing (see above).
> 
> -- Dave
> 
> 
> 
> --
> to unsubscribe send a message to 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 17 Dec 2003 16:02:20 +0000
content-class: urn:content-classes:message
Subject: RE: QoS attributes
Date: Wed, 17 Dec 2003 11:00:16 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Avi writes...
=20
> Do you actually believe that operators will come to a common agreement
> about what is a Gold profile?

I believe that operators that have a roaming agreement (i.e. part of the
same consortium) would do so.  I liken this to the "partnerships" that
the airlines have forged.  My frequent flyer miles accumulate whenever I
fly any of the partners, and they honor each other frequent flyer status
levels, etc.

Competitors would not easily come to agreement, but then competitors may
not want to allow transparent roaming across each others infrastructure,
so that point seems somewhat moot.

> Doesn't the very essence of competition require that they would have a
> disagreement about what a Gold Profile is?

Yes, but it's not the competitors I'm addressing (see above).

-- Dave

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 17 Dec 2003 01:21:09 +0000
content-class: urn:content-classes:message
Subject: RE: Comments on draft-adrangi-radius-extension-for-pwlan-00.txt
Date: Tue, 16 Dec 2003 17:20:38 -0800
From: "Adrangi, Farid" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>

Hi Jari,
Thanks for the dialogue - please see my commens inline.
BR,
Farid

> I guess part of my confusion comes from the fact that I don't=20
> know if IP Address Type Options =3D Public and Private in an=20
> Access-Accept means
>=20

[FA] I think there is a misunderstanding here - "public and private"=20
will be used only in the AccessRequest message to indicate that an
Access Network is capable of doing both options.
And I think the text is very specific about this fact. [FA]

>     (1) The home server does not care
>     (2) The home server wants both types of addresses to be assigned.
>=20
> Option 1 sounds logical to me.
>=20
> >>3) I get a bit worried that lack of enforcement is going to cause=20
> >>problems. Is it a general approach for AAA attributes from the home=20
> >>server to be hints?
> >=20
> > [FA] I would not consider this as a hint, rather a explicit=20
> request.=20
> > Because, this enforcement attribute is in response to the=20
> > advertisement in the access-request. Please note that the=20
> enforcement=20
> > attribute should not be sent if the advertisement attribute is not=20
> > present. [FA]
>=20
> It does indeed help if you only send the enforcement=20
> attribute after seeing an advertisement in access-request.=20
> Then we at least know the NAS supports this function, and we=20
> know what address types are available. Also, you wrote earlier:
>=20
[FA] That's the intent. [FA]

> > The other is how the Access Network is going to enforce the=20
> specified=20
> > address type option (private or public address) when the=20
> client  does=20
> > a DHCP request - which IMO, this is outside the scope of=20
> the document=20
> > and  perhaps we should be more explicit about it.
>=20
> So I guess what you mean is that you *will* enforce the=20
> address type. The only missing things are how the NAS will=20
> tell the DHCP server about this, and whether the client and=20
> the DHCP server need some protocol enhancements to get this=20
> done. And you consider these issues to be out of scope for=20
> this draft, which sounds reasonable.
>=20
> Is my understanding correct?
>=20

[FA] Yes, correct. [FA]

> --Jari
>=20
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 16 Dec 2003 23:15:42 +0000
content-class: urn:content-classes:message
Subject: RE: QoS attributes
Date: Tue, 16 Dec 2003 18:14:19 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Madjid writes...
=20
> Madjid>>Again, seeing the number of attribute proposals in this BoF
> so far and your notion of "reasonable" to me indicates that people
hold
> dear to the address space.

And just what do you think my notion of "reasonable" is, pray tell?  :-)

> Madjid>>Isn't levels of service, like bronze, silver... really depend
> on what is on the service contract in a specific scenario? Is what is
> bronze in one system, also bronze in another? Do all systems have
> the same number of levels. I don't see how this helps the problem
scale?

I think it helps the problem scale because it reduces it to relatively
simple "business domain" terminology.  If we had to worry about exact
levels of QoS, it's unlikely that we would ever come to agreement as to
when requirements effectively matched capabilities.  Sometimes too much
granularity is a bad thing.  The fact of the mater is that is that all
the players in a roaming consortium will have contractual relationships.
I assert this to be true, because there is virtually no other way that
each player can be confident that they will receive their share of the
revenue stream.  Given that business agreements will exist, coming to a
common agreement about the range of QoS parameters in each level of
service category (Bronze, Silver, Gold, Platinum, Unattanium, etc.)
should not be a very difficult problem to solve.

Let's not make thinks more complicated than they absolutely need to be.

-- Dave

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 16 Dec 2003 22:11:48 +0000
content-class: urn:content-classes:message
Subject: RE: QoS attributes
Date: Tue, 16 Dec 2003 17:10:51 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Avi writes...
=20
> It requires that each Hot Spot for example understand what to deliver
to a
> Bronze User or a Gold user etc.....
>=20
> Like filter id, this just does not scale!

Given the variety of possible parameters and capabilities, based on the
NAS, and its uplinks, getting too specific doesn't scale either.  If the
description is too loose, the customer may get "less" than they expect.
Or conversely, the customer may get "more" that their home provider
thinks the customer is entitled to.  For example, if the "minimum"
guaranteed bandwidth is 1.5 MB/s, and the NAS can only provide 1.0 MB/s
at that time, should the session set-up fail?  Would the customer rather
have the 1.0 MB/s then and there, or would they rather be forced to seek
an alternate roaming provider?  The possible "negotiations" and
"exceptions" could become daunting for any of the parties to handle in
an effective and predictable fashion.

> We need a way to explicitly push attributes down to the NAS.  Equally
> important is to make sure that the NAS tell us what it can currently
> honour.

Do we want the AAA protocol to also be the QoS parameter provisioning
protocol?  We went down that road with COPS-PR.  Or do we simply want
the AAA protocol to bind authorized users to general classes of QoS that
are provisioned by some more appropriate protocol?

-- Dave

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 16 Dec 2003 22:05:20 +0000
content-class: urn:content-classes:message
Subject: RE: QoS attributes
Date: Tue, 16 Dec 2003 14:04:43 -0800
From: "Bari, Farooq" <[email-masked]>
To: "Avi Lior" <[email-masked]>, "Nelson, David" <[email-masked]>, <[email-masked]>

Hi Avi, all

We need to have some consensus on what is the rationale/use of QoS
attributes for RADIUS/DIAMETER before moving forward on the topic. It
seems that we have more than one perspective on it. I for example see it
as static information during an authorized session i.e. QoS information
gets exchanged only during session setup where AN informs AAA of its
capabilities and AAA server tells the AN of user QoS susbcription. I do
not think RADIUS/DIAMETER servers should be involved in provisioning QoS
for individual services running in an already authorized session later
on.  However Avi's email suggests it is somewhat more dynamic than this.
Avi, can you pls clarify if I understood your comments correctly.....

Farooq

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Avi Lior
Sent: Tuesday, December 16, 2003 1:42 PM
To: 'Nelson, David'; [email-masked]
Subject: RE: QoS attributes

David Nelso wrote:

> Provisioning detailed, and more importantly, potentially
> dynamic, QoS parameters as authorization information in=20
> RADIUS or any other AAA protocol is probably not the right=20
> thing to do.  What ought to be provisioned is a "level of=20
> service" indication (e.g. bronze, silver, gold, platinum)=20
> that can be used by each NAS to modify the QoS parameter=20
> negotiation process for each session.=20

It requires that each Hot Spot for example understand what to deliver to
a Bronze User or a Gold user etc.....

Like filter id, this just does not scale!

We need a way to explicitly push attributes down to the NAS.  Equally
important is to make sure that the NAS tell us what it can currently
honour. This will alow the home RADIUS to make an appropriate policy
decision.

--
to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 16 Dec 2003 21:43:49 +0000
From: Avi Lior <[email-masked]>
To: "'Nelson, David'" <[email-masked]>
Cc: [email-masked]
Subject: RE: kickstart and SSPP
Date: Tue, 16 Dec 2003 16:43:21 -0500

Okay I knew that but I didn't make the context connection.  Thanx.

> -----Original Message-----
> From: Nelson, David [mailto:[email-masked]] 
> Sent: Tuesday, December 16, 2003 3:58 PM
> Cc: [email-masked]
> Subject: RE: kickstart and SSPP
> 
> 
> Avi writes...
> 
> > Not sure what you mean by no flixibility in secret lookup?
> 
> Shared secrets are looked-up on a hop-by-hop basis using the 
> Source IP Address of the incoming RADIUS packet as the look-up index.
> 
> -- Dave
> 
> 
> 
> --
> to unsubscribe send a message to 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 16 Dec 2003 21:41:58 +0000
From: Avi Lior <[email-masked]>
To: "'Nelson, David'" <[email-masked]>, [email-masked]
Subject: RE: QoS attributes
Date: Tue, 16 Dec 2003 16:41:30 -0500

David Nelso wrote:

> Provisioning detailed, and more importantly, potentially 
> dynamic, QoS parameters as authorization information in 
> RADIUS or any other AAA protocol is probably not the right 
> thing to do.  What ought to be provisioned is a "level of 
> service" indication (e.g. bronze, silver, gold, platinum) 
> that can be used by each NAS to modify the QoS parameter 
> negotiation process for each session. 

It requires that each Hot Spot for example understand what to deliver to a
Bronze User or a Gold user etc.....

Like filter id, this just does not scale!

We need a way to explicitly push attributes down to the NAS.  Equally
important is to make sure that the NAS tell us what it can currently honour.
This will alow the home RADIUS to make an appropriate policy decision.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 16 Dec 2003 21:36:02 +0000
From: Avi Lior <[email-masked]>
To: "[email-masked]'" <[email-masked]>, Avi Lior <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: QoS attributes
Date: Tue, 16 Dec 2003 16:35:40 -0500

> I think that at least the first approach makes sense. You
> Avi have looked into it more deeply, what do you think?
> Can we find a reasonable QoS attribute set without spending
> too much time?

As you say, there are so many and that's why I stopped (for a bit anyway).
Until I get a better lay of the land.  I noticed the Pat had a Diameter
Draft on QoS way back in 98 ( I think).

The easy ones are the bandwidth parameters and once we can agree what
"minimum" means and what "maximum" means we are pretty well off to the races
for services today.

The other ones that we would need are a way to associate a session with a
QoS bundle either by assigning a QoS bundle id which then translates to a
QoS parameters or specifically assigning a QoS bundle.  This is akeen to the
IP filter rules and IP filter rule ids.  A QoS bundle would contain a bunch
of QoS related attributes.  The QoS bundle Id can also be used for billing.

Because there are so many different attributes I was hoping that we come up
with a mechanism that could then be extended.

Not doing something about this will create a situation that I am starting to
see where folks are just going to be creating VSAs and we will never have
interoperability.

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]] 
> Sent: Tuesday, December 16, 2003 4:09 PM
> To: Avi Lior
> Cc: [email-masked]'
> Subject: Re: QoS attributes
> 
> 
> Avi Lior wrote:
> 
> > In the current drafts folks are talking about QoS but are only 
> > specifying Bandwidth attributes.  There are other QoS 
> attributes. The 
> > problem is that there are a lot of different QoS attributes and 
> > different flavours as well. The question is which attributes and 
> > flavours should be modelled.
> > 
> > I think we need a RADIUS QoS Draft in general.  I started 
> to write one 
> > and stopped to see what was going on in a couple of other 
> areas. (For 
> > example Diameter and as well, work in 3GPP2 where the interface 
> > between the PDSN and the AAA will be used to query and 
> transport QoS 
> > attributes).
> > 
> > For example, one of the useful things about the CoA is that 
> now I can 
> > change the QoS attributes of a session mid stream.  So it would be 
> > useful to define these attributes (and not just Bandwidth).
> > 
> > Any comments would be greatly appreciated.
> 
> I agree that there are other QoS attributes. In fact, there
> are so many and so different that this may be a problem.
> 
> Define just a limited set of bandwidth qos attributes and
> be satisfied with limited capabilities this offers? Or
> define link layer specific detailed qos attributes, and
> deal with the lack of server-side understanding of new
> link layers and the diversity of the parameters for different 
> links? Or try to come up with a general definition that suits 
> everyone, and probably take a long time to finish? ;-)
> 
> I think that at least the first approach makes sense. You
> Avi have looked into it more deeply, what do you think?
> Can we find a reasonable QoS attribute set without spending
> too much time?
> 
> --Jari
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 16 Dec 2003 21:33:10 +0000
content-class: urn:content-classes:message
Subject: RE: Comments on draft-black-radius-lanedge-00.txt
Date: Tue, 16 Dec 2003 13:31:57 -0800
From: "Bari, Farooq" <[email-masked]>
To: <[email-masked]>, "BLACK,CHUCK (HP-Roseville,ex1)" <[email-masked]>
Cc: <[email-masked]>

I support Jari's idea of renaming the group RADEXT to AAAEXT - this I
believe will reflect the true nature of the work and will also help
allay any concerns.

Farooq

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Jari Arkko
Sent: Monday, December 15, 2003 2:55 PM
To: BLACK,CHUCK (HP-Roseville,ex1)
Cc: [email-masked]
Subject: Re: Comments on draft-black-radius-lanedge-00.txt

BLACK,CHUCK (HP-Roseville,ex1) wrote:
> From: Jari Arkko [mailto:[email-masked]]
>=20
>=20
>> o  In general I support this type of a specification that would
>>    define WLAN or LAN specific attributes for AAA. We need this.
>=20
>=20
> Good, it seemed that there would be interest in this, and the=20
> intention was to generate discussion and arrive at some sort of=20
> consensus.

Yes. Thanks for your response.

>> o  The attributes should be done in a general fashion, in one
>>   document, and be applicable for both RADIUS and Diameter.
>>   With translation, if necessary, described in the document.
>=20
>=20
> Would you consider that this RADIUSEXT WG is the appropriate place for

> this discussion then, since many of the folks involved with RADIUS are

> also involved with Diameter?

Yes -- though I would probably name RADEXT to AAAEXT and avoid
unnecessary focus to RADIUS only. Not that the name defines what the
group will do, but...

>> o  Section 2.3.7, attribute IP-Filter-Name: What is the difference
>>    between this attribute and the Filter-Id attribute from RFC 2865?
>>    Do we need another one?
>=20
>=20
> There is no fundamental difference between the current typical usage=20
> of the Filter-Id attribute and the new IP-Filter-Name. However, this=20
> is also true, based on RFC 3580, of the VLAN attributes, which are=20
> using the Tunnel attributes to specify VLAN information (see section=20
> 3.9 of RFC 3580 for Filter-Id usage, and section 3.31 for Tunnel/VLAN=20
> usage).
>=20
> The intent was to extract the common LAN edge attributes and place=20
> them together.  At the risk, as you mention, of redundancy. I'm not=20
> sure argument should prevail, so some discussion on the matter will=20
> help to decide the issue.

I think its fine to document all the attributes relevant for LANs
together -- but you should then make a distinction of those attributes
that you are now introducing in this document, and those that you just
import from other documents. This would help those readers who know both
documents, would help IANA, and would make it clear what document is
normative wrt to a given attribute.

>>    Also, it would be better to hightlight the relationship of
>>    the proposed attribute and Diameter NASREQ NAS-Filter-Rule AVP.
>>    Note that this AVP has a code 400 which means it is not directly
>>    RADIUS compatible. But if the definitions are aligned otherwise
>>    then translation should at least be possible.
>=20
>=20
> This may be true.  The Diameter IPFilterRule was chosen because of its

> immediate likeness to the layer 3 inclinations of the IP-Filter-Raw=20
> attribute.  It seems like using the NAS-Filter-Rule AVP would be more=20
> inclusive; is that a desired direction?  There may be other reasons=20
> for using NAS-Filter-Rule of which I am unaware.

The definitions appear to have the same contents, given that you refer
to Diameter data type. I think the semantics are also the same. Perhaps
you should just state that this is like the NAS-Filter-Rule AVP -- and
maybe name it NAS-Filter-Rule-Radius or something like that to make it
obvious.

--Jari

--
to unsubscribe send a message to [email-masked] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 16 Dec 2003 21:10:14 +0000
Date: Tue, 16 Dec 2003 23:08:57 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Avi Lior <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: Re: QoS attributes

Avi Lior wrote:

> In the current drafts folks are talking about QoS but are only specifying
> Bandwidth attributes.  There are other QoS attributes. The problem is that
> there are a lot of different QoS attributes and different flavours as well.
> The question is which attributes and flavours should be modelled.
> 
> I think we need a RADIUS QoS Draft in general.  I started to write one and
> stopped to see what was going on in a couple of other areas. (For example
> Diameter and as well, work in 3GPP2 where the interface between the PDSN and
> the AAA will be used to query and transport QoS attributes).
> 
> For example, one of the useful things about the CoA is that now I can change
> the QoS attributes of a session mid stream.  So it would be useful to define
> these attributes (and not just Bandwidth).
> 
> Any comments would be greatly appreciated.

I agree that there are other QoS attributes. In fact, there
are so many and so different that this may be a problem.

Define just a limited set of bandwidth qos attributes and
be satisfied with limited capabilities this offers? Or
define link layer specific detailed qos attributes, and
deal with the lack of server-side understanding of new
link layers and the diversity of the parameters for different
links? Or try to come up with a general definition that
suits everyone, and probably take a long time to finish? ;-)

I think that at least the first approach makes sense. You
Avi have looked into it more deeply, what do you think?
Can we find a reasonable QoS attribute set without spending
too much time?

--Jari

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 16 Dec 2003 21:00:13 +0000
From: Avi Lior <[email-masked]>
To: 'Nakhjiri Madjid-MNAKHJI1' <[email-masked]>, Avi Lior <[email-masked]>, [email-masked]
Subject: RE: QoS attributes
Date: Tue, 16 Dec 2003 15:59:42 -0500

Thanx for the comments.  See my replies in line:
 
> 
> Not having much prior RADIUS experience and having looked at 
> the activities in this group, I have been wondering why 
> RADIUS needs to define every single parameter as an 
> attributes. Given that there are so many customers for 
> RADIUS: we have seen SIPPING, WLAN community, QoS and so 
> forth. Shouldn't there be a method to bundle paramters 
> regarding each application, given the fact that attribute 
> space is so limited??

The concept of applications has been addressed in Diameter.
The concept of grouping related has been address in Diameter as well.
However, if you look at some of the emails you will see some discussion on
subtypes that I have been pushing for.

> But that aside, to comment on the QoS issue, isn't the issue 
> that how the RADIUS server configure the NAS (which is 
> typically the same as the device at the edge of the network) 
> to know how to handle user's traffic? If so then it depends 
> on what kind of edge device the NAS is. Also each user may 
> have various kinds of sessions, for each it may get 
> different QoS treatment, so the QoS will be tied to SIP or other call 
> control protocols.
> If it is a Diffserv router(filter), it needs to have DSCP for 
> each flow the user is using (not just one per user). If it is 
> a L2 device, it may need to have a whole bunch of access 
> technology specific paramters, such as 
> slots, etc. 

Yes I agree that this is a difficult issue and there may not be away for
doing this other than to address specific requirements.
 
> So again the question is, whether there needs to be one 
> attribute for every QoS parameter under the sun, or is there 
> a way to do grouping?
> 
> my 2/100s
> 
> Madjid
> 
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf Of Avi Lior
> Sent: Tuesday, December 16, 2003 11:29 AM
> To: [email-masked]
> Subject: QoS attributes
> 
> 
> I noticed that we are talking about QoS on the list.
> 
> In the current drafts folks are talking about QoS but are 
> only specifying Bandwidth attributes.  There are other QoS 
> attributes. The problem is that there are a lot of different 
> QoS attributes and different flavours as well. The question 
> is which attributes and flavours should be modelled.
> 
> I think we need a RADIUS QoS Draft in general.  I started to 
> write one and stopped to see what was going on in a couple of 
> other areas. (For example Diameter and as well, work in 3GPP2 
> where the interface between the PDSN and the AAA will be used 
> to query and transport QoS attributes).
> 
> For example, one of the useful things about the CoA is that 
> now I can change the QoS attributes of a session mid stream.  
> So it would be useful to define these attributes (and not 
> just Bandwidth).
> 
> Any comments would be greatly appreciated.
> 
> 
> 
> 
> > -----Original Message-----
> > From: Avi Lior [mailto:[email-masked]]
> > Sent: Tuesday, December 16, 2003 11:45 AM
> > To: [email-masked]'; [email-masked]'; Adrangi, Farid
> > Subject: RE: Comments on 
> > draft-adrangi-radius-extension-for-pwlan-00.txt
> > 
> > 
> > 
> > 
> > > -----Original Message-----
> > Jari wrote:
> > 
> >   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.
> > 
> > Avi's reply:
> > 
> > A bit mask maybe a better approach.
> > 
> > Capability advertizing is important in certain situations
> > such a prepaid. We need to be able to ensure that AAA server 
> > can make policy decision based on the capabilities that are 
> > supported by the NAS.  In prepaid we need to know whether the 
> > NAS can actually do that 'counting' and enforce the policy 
> > that is required.  If the NAS did not then the AAA can decide 
> > on a different tack for providing service to a prepaid 
> > client.  For example it can ask the NAS to tunnel the client 
> > to another device that can enforce the policy.
> > 
> > We also need to know whether the NAS supports POD or COA
> > (3576) messages. Again this is improtant for prepaid etc....
> > 
> > Whether or not this is standardized or not it is important
> > for the prepaid feature and hence its also part of the 
> prepaid draft.
> > 
> > --
> > to unsubscribe send a message to
> > [email-masked] with the word 'unsubscribe' in 
> > a single line as the message text body.
> > archive: <http://psg.com/lists/radiusext/>
> > 
> 
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 16 Dec 2003 20:59:01 +0000
content-class: urn:content-classes:message
Subject: RE: kickstart and SSPP
Date: Tue, 16 Dec 2003 15:58:09 -0500
From: "Nelson, David" <[email-masked]>
Cc: <[email-masked]>

Avi writes...

> Not sure what you mean by no flixibility in secret lookup?

Shared secrets are looked-up on a hop-by-hop basis using the Source IP
Address of the incoming RADIUS packet as the look-up index.

-- Dave

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 16 Dec 2003 20:56:40 +0000
content-class: urn:content-classes:message
Subject: RE: QoS attributes
Date: Tue, 16 Dec 2003 15:55:42 -0500
From: "Nelson, David" <[email-masked]>
To: <[email-masked]>

Nakhjiri writes...
=20
> Shouldn't there be
> a method to bundle paramters regarding each application, given the
fact
> that attribute space is so limited??

I don't think it has been demonstrated that the current attribute
address space will be exhausted by the set of current [reasonable]
proposals.  Given that, I see no great pressure for sub-types,
sub-encodings or other methods to "bundle" multiple parameters in a
single attribute.

> So again the question is, whether there needs to be one attribute
> for every QoS parameter under the sun, or is there a way to do
grouping?

Provisioning detailed, and more importantly, potentially dynamic, QoS
parameters as authorization information in RADIUS or any other AAA
protocol is probably not the right thing to do.  What ought to be
provisioned is a "level of service" indication (e.g. bronze, silver,
gold, platinum) that can be used by each NAS to modify the QoS parameter
negotiation process for each session.=20

-- Dave

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 16 Dec 2003 20:55:46 +0000
From: Avi Lior <[email-masked]>
To: 'Nakhjiri Madjid-MNAKHJI1' <[email-masked]>, Avi Lior <[email-masked]>, "'Nelson, David'" <[email-masked]>
Cc: [email-masked]
Subject: RE: kickstart and SSPP
Date: Tue, 16 Dec 2003 15:55:19 -0500

Not sure what you mean by no flixibility in secret lookup?

> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]] 
> Sent: Tuesday, December 16, 2003 3:32 PM
> To: 'Avi Lior'; Nakhjiri Madjid-MNAKHJI1; 'Nelson, David'
> Cc: [email-masked]
> Subject: RE: kickstart and SSPP
> 
> 
> Thanks for the comments.
> 
> Ok, so it seems that there is some flexibility as far as 
> methods of representing NAS (its ID). but no flexibility in 
> secret lookup (has to be done based on IP address and nothing else).
> 
> Madjid
> 
> -----Original Message-----
> From: Avi Lior [mailto:[email-masked]]
> Sent: Tuesday, December 16, 2003 11:18 AM
> To: 'Nakhjiri Madjid-MNAKHJI1'; 'Nelson, David'
> Cc: [email-masked]
> Subject: RE: kickstart and SSPP
> 
> 
> The home radius server may store the NAS ID and/or the NAS IP 
> as well as other information.
> 
> Remember that RADIUS is stateless so what is stored by RADIUS 
> is highly dependant on the deployment or the use of the AAA.
> 
> For example, if the home network wanted to issue a Disconnect 
> Message or a Change of Authorization message (see RFC 3576) 
> then it would need the NAS identity and user session 
> identities inorder to issue these messages.
> 
> Hope this helps.
> 
> > -----Original Message-----
> > From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]]
> > Sent: Friday, December 12, 2003 5:07 PM
> > To: 'Nelson, David'; Nakhjiri Madjid-MNAKHJI1
> > Cc: [email-masked]
> > Subject: RE: kickstart and SSPP
> > 
> > 
> > Hi Dave,
> > 
> > Thank you for your answers.
> > 
> > What types of ID does the NAS use (beside IP address) in the
> > NAS ID field? Would the RADIUS server then later store this 
> > ID or the NAS IP address in its database? Also I am wondering 
> > if the RADIUS server keeps any entry about the user's IP address?
> > 
> > Thanks in advance,
> > 
> > Madjid
> > P.S. It seems that the SSPP and kick start drafts have found
> > a new home in Enroll WG.
> > 
> > 
> > The NAS has a transitive trust relationship with the home
> > server, via the proxy server chain, but no direct trust 
> > relationship.  Each proxy server will generally validate the 
> > NAS identity before forwarding a request.  If you have a 
> > "rogue" proxy in the chain, security problems will obviously exist.
> > 
> > > > The NAS ID is the of originating client, not the proxy.
> > > 
> > > Madjid>>So are you saying the packet carries both an IP 
> address (for
> > the
> > > proxy or NAS) and a NAS ID for originating NAS?
> > 
> > Yes.  The packet's source IP address is in the IP header and
> > the NAS ID (or NAS IP Address) is in the packet payload.  It 
> > is the Source IP address from the IP header that is used to 
> > look up the shared secret.
> > 
> > 
> > --
> > to unsubscribe send a message to
> > [email-masked] with the word 'unsubscribe' in 
> > a single line as the message text body.
> > archive: <http://psg.com/lists/radiusext/>
> > 
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 16 Dec 2003 20:32:24 +0000
From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
To: "'Avi Lior'" <[email-masked]>, Nakhjiri Madjid-MNAKHJI1 <[email-masked]>, "'Nelson, David'" <[email-masked]>
Cc: [email-masked]
Subject: RE: kickstart and SSPP
Date: Tue, 16 Dec 2003 14:31:46 -0600

Thanks for the comments.

Ok, so it seems that there is some flexibility as far as methods
of representing NAS (its ID). but no flexibility in secret lookup
(has to be done based on IP address and nothing else).

Madjid

-----Original Message-----
From: Avi Lior [mailto:[email-masked]]
Sent: Tuesday, December 16, 2003 11:18 AM
To: 'Nakhjiri Madjid-MNAKHJI1'; 'Nelson, David'
Cc: [email-masked]
Subject: RE: kickstart and SSPP

The home radius server may store the NAS ID and/or the NAS IP as well as
other information.

Remember that RADIUS is stateless so what is stored by RADIUS is highly
dependant on the deployment or the use of the AAA.

For example, if the home network wanted to issue a Disconnect Message or a
Change of Authorization message (see RFC 3576) then it would need the NAS
identity and user session identities inorder to issue these messages.

Hope this helps.

> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]] 
> Sent: Friday, December 12, 2003 5:07 PM
> To: 'Nelson, David'; Nakhjiri Madjid-MNAKHJI1
> Cc: [email-masked]
> Subject: RE: kickstart and SSPP
> 
> 
> Hi Dave,
> 
> Thank you for your answers. 
> 
> What types of ID does the NAS use (beside IP address) in the 
> NAS ID field? Would the RADIUS server then later store this 
> ID or the NAS IP address in its database? Also I am wondering 
> if the RADIUS server keeps any entry about the user's IP address?
> 
> Thanks in advance,
> 
> Madjid
> P.S. It seems that the SSPP and kick start drafts have found 
> a new home in Enroll WG.
> 
> 
> The NAS has a transitive trust relationship with the home 
> server, via the proxy server chain, but no direct trust 
> relationship.  Each proxy server will generally validate the 
> NAS identity before forwarding a request.  If you have a 
> "rogue" proxy in the chain, security problems will obviously exist.
> 
> > > The NAS ID is the of originating client, not the proxy.
> > 
> > Madjid>>So are you saying the packet carries both an IP address (for
> the
> > proxy or NAS) and a NAS ID for originating NAS?
> 
> Yes.  The packet's source IP address is in the IP header and 
> the NAS ID (or NAS IP Address) is in the packet payload.  It 
> is the Source IP address from the IP header that is used to 
> look up the shared secret.
> 
> 
> --
> to unsubscribe send a message to 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 16 Dec 2003 20:29:41 +0000
From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
To: "'Avi Lior'" <[email-masked]>, [email-masked]
Subject: RE: QoS attributes
Date: Tue, 16 Dec 2003 14:28:44 -0600

Not having much prior RADIUS experience and having looked at the activities
in this group, I have been wondering why RADIUS needs to define every single parameter as an attributes. Given that there are so many customers for RADIUS:
we have seen SIPPING, WLAN community, QoS and so forth. Shouldn't there be
a method to bundle paramters regarding each application, given the fact
that attribute space is so limited??

But that aside, to comment on the QoS issue, isn't the issue that how
the RADIUS server configure the NAS (which is typically the same as the
device at the edge of the network) to know how to handle user's traffic?
If so then it depends on what kind of edge device the NAS is.
Also each user may have various kinds of sessions, for each it may get 
different QoS treatment, so the QoS will be tied to SIP or other call 
control protocols.
If it is a Diffserv router(filter), it needs to have DSCP for each flow the
user is using (not just one per user). If it is a L2 device, it may need
to have a whole bunch of access technology specific paramters, such as 
slots, etc. 

So again the question is, whether there needs to be one attribute
for every QoS parameter under the sun, or is there a way to do grouping?

my 2/100s

Madjid

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Avi Lior
Sent: Tuesday, December 16, 2003 11:29 AM
To: [email-masked]
Subject: QoS attributes

I noticed that we are talking about QoS on the list.

In the current drafts folks are talking about QoS but are only specifying
Bandwidth attributes.  There are other QoS attributes. The problem is that
there are a lot of different QoS attributes and different flavours as well.
The question is which attributes and flavours should be modelled.

I think we need a RADIUS QoS Draft in general.  I started to write one and
stopped to see what was going on in a couple of other areas. (For example
Diameter and as well, work in 3GPP2 where the interface between the PDSN and
the AAA will be used to query and transport QoS attributes).

For example, one of the useful things about the CoA is that now I can change
the QoS attributes of a session mid stream.  So it would be useful to define
these attributes (and not just Bandwidth).

Any comments would be greatly appreciated.

> -----Original Message-----
> From: Avi Lior [mailto:[email-masked]] 
> Sent: Tuesday, December 16, 2003 11:45 AM
> To: [email-masked]'; [email-masked]'; Adrangi, Farid
> Subject: RE: Comments on 
> draft-adrangi-radius-extension-for-pwlan-00.txt
> 
> 
> 
> 
> > -----Original Message-----
> Jari wrote:
> 
>   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.
> 
> Avi's reply:
> 
> A bit mask maybe a better approach.
> 
> Capability advertizing is important in certain situations 
> such a prepaid. We need to be able to ensure that AAA server 
> can make policy decision based on the capabilities that are 
> supported by the NAS.  In prepaid we need to know whether the 
> NAS can actually do that 'counting' and enforce the policy 
> that is required.  If the NAS did not then the AAA can decide 
> on a different tack for providing service to a prepaid 
> client.  For example it can ask the NAS to tunnel the client 
> to another device that can enforce the policy.
> 
> We also need to know whether the NAS supports POD or COA 
> (3576) messages. Again this is improtant for prepaid etc....
> 
> Whether or not this is standardized or not it is important 
> for the prepaid feature and hence its also part of the prepaid draft.
> 
> --
> to unsubscribe send a message to 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 16 Dec 2003 20:11:02 +0000
content-class: urn:content-classes:message
Subject: RE: QoS attributes
Date: Tue, 16 Dec 2003 12:10:33 -0800
From: "Bari, Farooq" <[email-masked]>
To: "Avi Lior" <[email-masked]>, <[email-masked]>

Hi Avi,

My opinion on this issue is that RADIUS or DIAMETER attributes on QoS
should reflect a more static type of QoS information that does not
change during an authorized session like
* the access network capabilities (e.g. does it support 11e or admission
control or if it can provide any, min/max bandwidth guarantees for
session, jitter, latency, delay, packet drop guarantees etc.)=20
* user subscribed to QoS e.g. is the user bronze, silver, gold customer
and based on that what QoS should the user be provided.

The dynamic QoS for a particular service that the user decides to use
during an authorized session I believe is not something the RADIUS
should be used for. There are better mechanisms e.g. based on SDP
information in SIP or RTSP based services that should be utilized for
that purpose.=20

BR,

Farooq
=20

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Avi Lior
Sent: Tuesday, December 16, 2003 9:29 AM
To: [email-masked]'
Subject: QoS attributes

I noticed that we are talking about QoS on the list.

In the current drafts folks are talking about QoS but are only
specifying Bandwidth attributes.  There are other QoS attributes. The
problem is that there are a lot of different QoS attributes and
different flavours as well. The question is which attributes and
flavours should be modelled.

I think we need a RADIUS QoS Draft in general.  I started to write one
and stopped to see what was going on in a couple of other areas. (For
example Diameter and as well, work in 3GPP2 where the interface between
the PDSN and the AAA will be used to query and transport QoS
attributes).

For example, one of the useful things about the CoA is that now I can
change the QoS attributes of a session mid stream.  So it would be
useful to define these attributes (and not just Bandwidth).

Any comments would be greatly appreciated.

> -----Original Message-----
> From: Avi Lior [mailto:[email-masked]]
> Sent: Tuesday, December 16, 2003 11:45 AM
> To: [email-masked]'; [email-masked]'; Adrangi, Farid
> Subject: RE: Comments on=20
> draft-adrangi-radius-extension-for-pwlan-00.txt
>=20
>=20
>=20
>=20
> > -----Original Message-----
> Jari wrote:
>=20
>   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.
>=20
> Avi's reply:
>=20
> A bit mask maybe a better approach.
>=20
> Capability advertizing is important in certain situations
> such a prepaid. We need to be able to ensure that AAA server=20
> can make policy decision based on the capabilities that are=20
> supported by the NAS.  In prepaid we need to know whether the=20
> NAS can actually do that 'counting' and enforce the policy=20
> that is required.  If the NAS did not then the AAA can decide=20
> on a different tack for providing service to a prepaid=20
> client.  For example it can ask the NAS to tunnel the client=20
> to another device that can enforce the policy.
>=20
> We also need to know whether the NAS supports POD or COA
> (3576) messages. Again this is improtant for prepaid etc....
>=20
> Whether or not this is standardized or not it is important
> for the prepaid feature and hence its also part of the prepaid draft.
>=20
> --
> to unsubscribe send a message to
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 16 Dec 2003 20:03:51 +0000
From: Avi Lior <[email-masked]>
To: 'Christopher Richards' <[email-masked]>, Avi Lior <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked]
Subject: RE: [AAA-WG]: Question regarding IP Filter Rule
Date: Tue, 16 Dec 2003 15:03:28 -0500

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C3C40F.AC0AD350
Content-Type: text/plain

Chris,
 
Okay so forgive me but how do I specify where to redirect user traffic in
diameter.  Which attributes do that.  Note I am not talking about where to
redirect AAA traffic.
 
Avi

-----Original Message-----
From: Christopher Richards [mailto:[email-masked]] 
Sent: Tuesday, December 16, 2003 2:32 PM
To: 'Avi Lior'; [email-masked]'; [email-masked]
Subject: RE: [AAA-WG]: Question regarding IP Filter Rule

Hi Avi, 

The Diameter RFC (And applications) specify where to redirect user traffic -
not how. The "how" is implementation specific.

Best Regards, 
Chris. 

Shasta Wireless Development 
Nortel Networks 

Telephone: 
+1 972 684 3281 
ESN 444 3281 

-----Original Message----- 
From: Avi Lior [mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Tuesday, December 16, 2003 1:23 PM 
To: [email-masked]'; [email-masked] 
Subject: [AAA-WG]: Question regarding IP Filter Rule 

The Black I-D and PWLAN draft prompted me to check something out. 

It seems to me that something is missing in Diameter.  Using the filter
specification in 3588 its not clear how I force a forward.  The only actions
supported are permit or deny whereas ipfw supports a forward mechanism as
well.

The motivation for this is the requirement in (WLAN for example) whereby I
want to force all http traffic to a specific portal and deny all other
traffic until the portal instructs the NAS otherwise.  This needs to be done
either during an Access Accept or mid-session using COA.

------_=_NextPart_001_01C3C40F.AC0AD350
Content-Type: text/html

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<TITLE>Message</TITLE>

<META content="MSHTML 6.00.2800.1276" name=GENERATOR></HEAD>
<BODY>
<DIV><SPAN class=917170220-16122003><FONT face=Arial color=#0000ff 
size=2>Chris,</FONT></SPAN></DIV>
<DIV><SPAN class=917170220-16122003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=917170220-16122003><FONT face=Arial color=#0000ff size=2>Okay 
so forgive me but how do I specify where to redirect user traffic in 
diameter.&nbsp; Which attributes do that.&nbsp; Note I am not talking about 
where to redirect AAA traffic.</FONT></SPAN></DIV>
<DIV><SPAN class=917170220-16122003><FONT face=Arial color=#0000ff 
size=2></FONT></SPAN>&nbsp;</DIV>
<DIV><SPAN class=917170220-16122003><FONT face=Arial color=#0000ff 
size=2>Avi</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr 
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
  <DIV></DIV>
  <DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left><FONT 
  face=Tahoma size=2>-----Original Message-----<BR><B>From:</B> Christopher 
  Richards [mailto:[email-masked]] <BR><B>Sent:</B> Tuesday, December 
  16, 2003 2:32 PM<BR><B>To:</B> 'Avi Lior'; [email-masked]'; 
  [email-masked]<BR><B>Subject:</B> RE: [AAA-WG]: Question regarding IP Filter 
  Rule<BR><BR></FONT></DIV>
  <P><FONT size=2>Hi Avi,</FONT> </P>
  <P><FONT size=2>The Diameter RFC (And applications) specify where to redirect 
  user traffic - not how. The "how" is implementation specific.</FONT></P>
  <P><FONT size=2>Best Regards,</FONT> <BR><FONT size=2>Chris.</FONT> </P>
  <P><FONT size=2>Shasta Wireless Development</FONT> <BR><FONT size=2>Nortel 
  Networks</FONT> </P>
  <P><FONT size=2>Telephone:</FONT> <BR><FONT size=2>+1 972 684 3281</FONT> 
  <BR><FONT size=2>ESN 444 3281</FONT> </P><BR>
  <P><FONT size=2>-----Original Message-----</FONT> <BR><FONT size=2>From: Avi 
  Lior [<A 
  href="mailto:[email-masked]">mailto:[email-masked]</A>] 
  </FONT><BR><FONT size=2>Sent: Tuesday, December 16, 2003 1:23 PM</FONT> 
  <BR><FONT size=2>To: [email-masked]'; [email-masked]</FONT> 
  <BR><FONT size=2>Subject: [AAA-WG]: Question regarding IP Filter Rule</FONT> 
  </P><BR>
  <P><FONT size=2>The Black I-D and PWLAN draft prompted me to check something 
  out.</FONT> </P>
  <P><FONT size=2>It seems to me that something is missing in Diameter.&nbsp; 
  Using the filter specification in 3588 its not clear how I force a 
  forward.&nbsp; The only actions supported are permit or deny whereas ipfw 
  supports a forward mechanism as well.</FONT></P>
  <P><FONT size=2>The motivation for this is the requirement in (WLAN for 
  example) whereby I want to force all http traffic to a specific portal and 
  deny all other traffic until the portal instructs the NAS otherwise.&nbsp; 
  This needs to be done either during an Access Accept or mid-session using 
  COA.</FONT></P></BLOCKQUOTE></BODY></HTML>

------_=_NextPart_001_01C3C40F.AC0AD350--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 16 Dec 2003 19:23:52 +0000
From: Avi Lior <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: Question regarding IP Filter Rule
Date: Tue, 16 Dec 2003 14:22:54 -0500

The Black I-D and PWLAN draft prompted me to check something out.

It seems to me that something is missing in Diameter.  Using the filter
specification in 3588 its not clear how I force a forward.  The only actions
supported are permit or deny whereas ipfw supports a forward mechanism as
well.

The motivation for this is the requirement in (WLAN for example) whereby I
want to force all http traffic to a specific portal and deny all other
traffic until the portal instructs the NAS otherwise.  This needs to be done
either during an Access Accept or mid-session using COA.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 16 Dec 2003 17:28:52 +0000
From: Avi Lior <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: QoS attributes
Date: Tue, 16 Dec 2003 12:28:31 -0500

I noticed that we are talking about QoS on the list.

In the current drafts folks are talking about QoS but are only specifying
Bandwidth attributes.  There are other QoS attributes. The problem is that
there are a lot of different QoS attributes and different flavours as well.
The question is which attributes and flavours should be modelled.

I think we need a RADIUS QoS Draft in general.  I started to write one and
stopped to see what was going on in a couple of other areas. (For example
Diameter and as well, work in 3GPP2 where the interface between the PDSN and
the AAA will be used to query and transport QoS attributes).

For example, one of the useful things about the CoA is that now I can change
the QoS attributes of a session mid stream.  So it would be useful to define
these attributes (and not just Bandwidth).

Any comments would be greatly appreciated.

> -----Original Message-----
> From: Avi Lior [mailto:[email-masked]] 
> Sent: Tuesday, December 16, 2003 11:45 AM
> To: [email-masked]'; [email-masked]'; Adrangi, Farid
> Subject: RE: Comments on 
> draft-adrangi-radius-extension-for-pwlan-00.txt
> 
> 
> 
> 
> > -----Original Message-----
> Jari wrote:
> 
>   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.
> 
> Avi's reply:
> 
> A bit mask maybe a better approach.
> 
> Capability advertizing is important in certain situations 
> such a prepaid. We need to be able to ensure that AAA server 
> can make policy decision based on the capabilities that are 
> supported by the NAS.  In prepaid we need to know whether the 
> NAS can actually do that 'counting' and enforce the policy 
> that is required.  If the NAS did not then the AAA can decide 
> on a different tack for providing service to a prepaid 
> client.  For example it can ask the NAS to tunnel the client 
> to another device that can enforce the policy.
> 
> We also need to know whether the NAS supports POD or COA 
> (3576) messages. Again this is improtant for prepaid etc....
> 
> Whether or not this is standardized or not it is important 
> for the prepaid feature and hence its also part of the prepaid draft.
> 
> --
> to unsubscribe send a message to 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 16 Dec 2003 17:18:18 +0000
From: Avi Lior <[email-masked]>
To: 'Nakhjiri Madjid-MNAKHJI1' <[email-masked]>,  "'Nelson, David'" <[email-masked]>
Cc: [email-masked]
Subject: RE: kickstart and SSPP
Date: Tue, 16 Dec 2003 12:17:43 -0500

The home radius server may store the NAS ID and/or the NAS IP as well as
other information.

Remember that RADIUS is stateless so what is stored by RADIUS is highly
dependant on the deployment or the use of the AAA.

For example, if the home network wanted to issue a Disconnect Message or a
Change of Authorization message (see RFC 3576) then it would need the NAS
identity and user session identities inorder to issue these messages.

Hope this helps.

> -----Original Message-----
> From: Nakhjiri Madjid-MNAKHJI1 [mailto:[email-masked]] 
> Sent: Friday, December 12, 2003 5:07 PM
> To: 'Nelson, David'; Nakhjiri Madjid-MNAKHJI1
> Cc: [email-masked]
> Subject: RE: kickstart and SSPP
> 
> 
> Hi Dave,
> 
> Thank you for your answers. 
> 
> What types of ID does the NAS use (beside IP address) in the 
> NAS ID field? Would the RADIUS server then later store this 
> ID or the NAS IP address in its database? Also I am wondering 
> if the RADIUS server keeps any entry about the user's IP address?
> 
> Thanks in advance,
> 
> Madjid
> P.S. It seems that the SSPP and kick start drafts have found 
> a new home in Enroll WG.
> 
> 
> The NAS has a transitive trust relationship with the home 
> server, via the proxy server chain, but no direct trust 
> relationship.  Each proxy server will generally validate the 
> NAS identity before forwarding a request.  If you have a 
> "rogue" proxy in the chain, security problems will obviously exist.
> 
> > > The NAS ID is the of originating client, not the proxy.
> > 
> > Madjid>>So are you saying the packet carries both an IP address (for
> the
> > proxy or NAS) and a NAS ID for originating NAS?
> 
> Yes.  The packet's source IP address is in the IP header and 
> the NAS ID (or NAS IP Address) is in the packet payload.  It 
> is the Source IP address from the IP header that is used to 
> look up the shared secret.
> 
> 
> --
> to unsubscribe send a message to 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 16 Dec 2003 16:45:23 +0000
From: Avi Lior <[email-masked]>
To: "[email-masked]'" <[email-masked]>,  "[email-masked]'" <[email-masked]>, "Adrangi, Farid" <[email-masked]>
Subject: RE: Comments on draft-adrangi-radius-extension-for-pwlan-00.txt
Date: Tue, 16 Dec 2003 11:45:04 -0500

> -----Original Message-----
Jari wrote:

  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.

Avi's reply:

A bit mask maybe a better approach.

Capability advertizing is important in certain situations such a prepaid.
We need to be able to ensure that AAA server can make policy decision based
on the capabilities that are supported by the NAS.  In prepaid we need to
know whether the NAS can actually do that 'counting' and enforce the policy
that is required.  If the NAS did not then the AAA can decide on a different
tack for providing service to a prepaid client.  For example it can ask the
NAS to tunnel the client to another device that can enforce the policy.

We also need to know whether the NAS supports POD or COA (3576) messages.
Again this is improtant for prepaid etc....

Whether or not this is standardized or not it is important for the prepaid
feature and hence its also part of the prepaid draft.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 16 Dec 2003 16:37:46 +0000
From: Avi Lior <[email-masked]>
To: "[email-masked]'" <[email-masked]>,  "[email-masked]'" <[email-masked]>, "Adrangi, Farid" <[email-masked]>
Subject: RE: Comments on draft-adrangi-radius-issues-in-pwlan-roaming-00.t xt
Date: Tue, 16 Dec 2003 11:37:10 -0500

See my comments inline.

> From: Jari Arkko [mailto:[email-masked]] 

> 
>   o  The lack of Identity for Accounting Purposes (sect. 3.1): I agree
>      that this is an issue where things like EAP-AKA which 
> has identity
>      protection or PEAP which hides the identity are used. Perhaps
>      draft-ietf-aaa-eap should discuss this. But since the issue is
>      in fact common to both Diameter and RADIUS, we could 
> also describe
>      it separately. "Accounting Considerations for Identity 
> Privicy" I-D?

This is not strictly an accounting problem either.  An alias for the user
needs to be included in both Access and Accounting type messages.
If it were an accounting problem only then the Class attribute would
probably suffice in this case.  Intermediaries need to be able to have an
alias for subscriber as well (which nulls out the use of the Class
attribute).

Username re-writing capability could work here.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 16 Dec 2003 09:22:15 +0000
Date: Tue, 16 Dec 2003 11:21:08 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: "Adrangi, Farid" <[email-masked]>
Cc: [email-masked]
Subject: Re: Comments on draft-adrangi-radius-extension-for-pwlan-00.txt

Adrangi, Farid wrote:

>>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.
>>
> 
> [FA] The lack of indication about the address type from the home 
> network would most likely be taken as private address assignment
> (i.e., the default option).  

I think it would be taken as the default option (but I'm not
sure that would be private address assignment in all cases).

>>2) If you were to *enforce* the selection from the home network,
>>then public+private option would not work.
>>
> 
> 
> [FA] Why wouldn't work? Sorry, I think I am missing your point 
> here. The home network specifies the preferred address type only 
> if it sees the Advertisement in the access-request indicating that
> the access network can either assign public or private address to
> a given WLAN client that is trying to connect. [FA]

I guess part of my confusion comes from the fact that I don't know
if IP Address Type Options = Public and Private in an Access-Accept
means

    (1) The home server does not care
    (2) The home server wants both types of addresses to be assigned.

Option 1 sounds logical to me.

>>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?
> 
> [FA] I would not consider this as a hint, rather a explicit request.
> Because, this enforcement attribute is in response to the advertisement
> in the access-request. Please note that the enforcement attribute should
> not be sent if the advertisement attribute is not present. [FA]

It does indeed help if you only send the enforcement attribute
after seeing an advertisement in access-request. Then we at least
know the NAS supports this function, and we know what address types
are available. Also, you wrote earlier:

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

So I guess what you mean is that you *will* enforce the address type.
The only missing things are how the NAS will tell the DHCP server about
this, and whether the client and the DHCP server need some protocol
enhancements to get this done. And you consider these issues to be
out of scope for this draft, which sounds reasonable.

Is my understanding correct?

--Jari

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 16 Dec 2003 08:52:37 +0000
content-class: urn:content-classes:message
Subject: RE: Comments on draft-adrangi-radius-extension-for-pwlan-00.txt
Date: Tue, 16 Dec 2003 00:52:03 -0800
From: "Adrangi, Farid" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>

Hi Jari,
Thanks.  Please see my replies in line.
BR,
Farid

> > [FA] There are two aspects to this feature.  One is to enable Access
> > Network
> > to advertise its capability about private or public address=20
> assignment
> > for a
> > given WLAN client, and to enable the home RADIUS server to=20
> specify the
> > desired
> > address type option.  The other is how the Access Network=20
> is going to
> > enforce
> > the specified address type option (private or public=20
> address) when the
> > client=20
> > does a DHCP request - which IMO, this is outside the scope of the
> > document and=20
> > perhaps we should be more explicit about it.  Which aspect of the
> > feature do=20
> > you have problem with? [FA]
>=20
> 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.
>=20
[FA] The lack of indication about the address type from the home=20
network would most likely be taken as private address assignment
(i.e., the default option). =20

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

[FA] Why wouldn't work? Sorry, I think I am missing your point=20
here. The home network specifies the preferred address type only=20
if it sees the Advertisement in the access-request indicating that
the access network can either assign public or private address to
a given WLAN client that is trying to connect. [FA]

> 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?
[FA] I would not consider this as a hint, rather a explicit request.
Because, this enforcement attribute is in response to the advertisement
in the access-request. Please note that the enforcement attribute should

not be sent if the advertisement attribute is not present. [FA]

> Is someone's billing going
> to be based on a public or private address being provided?

[FA] Most likely, Yes.  [FA]
> 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?

>=20
>=20
> --Jari
>=20
>=20
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 15 Dec 2003 22:55:41 +0000
Date: Tue, 16 Dec 2003 00:54:32 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: "BLACK,CHUCK (HP-Roseville,ex1)" <[email-masked]>
Cc: [email-masked]
Subject: Re: Comments on draft-black-radius-lanedge-00.txt

BLACK,CHUCK (HP-Roseville,ex1) wrote:
> From: Jari Arkko [mailto:[email-masked]] 
> 
> 
>> o  In general I support this type of a specification that would
>>    define WLAN or LAN specific attributes for AAA. We need this.
> 
> 
> Good, it seemed that there would be interest in this, and the intention
> was to generate discussion and arrive at some sort of consensus.

Yes. Thanks for your response.

>> o  The attributes should be done in a general fashion, in one
>>   document, and be applicable for both RADIUS and Diameter.
>>   With translation, if necessary, described in the document.
> 
> 
> Would you consider that this RADIUSEXT WG is the appropriate
> place for this discussion then, since many of the folks involved
> with RADIUS are also involved with Diameter?

Yes -- though I would probably name RADEXT to AAAEXT and avoid
unnecessary focus to RADIUS only. Not that the name defines what
the group will do, but...

>> o  Section 2.3.7, attribute IP-Filter-Name: What is the difference
>>    between this attribute and the Filter-Id attribute from RFC 2865?
>>    Do we need another one?
> 
> 
> There is no fundamental difference between the current typical
> usage of the Filter-Id attribute and the new IP-Filter-Name.
> However, this is also true, based on RFC 3580, of the VLAN
> attributes, which are using the Tunnel attributes to specify
> VLAN information (see section 3.9 of RFC 3580 for Filter-Id
> usage, and section 3.31 for Tunnel/VLAN usage).
> 
> The intent was to extract the common LAN edge attributes and
> place them together.  At the risk, as you mention, of redundancy.
> I'm not sure argument should prevail, so some discussion
> on the matter will help to decide the issue.

I think its fine to document all the attributes relevant for
LANs together -- but you should then make a distinction of
those attributes that you are now introducing in this document,
and those that you just import from other documents. This would
help those readers who know both documents, would help IANA,
and would make it clear what document is normative wrt to a given
attribute.

>>    Also, it would be better to hightlight the relationship of
>>    the proposed attribute and Diameter NASREQ NAS-Filter-Rule AVP.
>>    Note that this AVP has a code 400 which means it is not directly
>>    RADIUS compatible. But if the definitions are aligned otherwise
>>    then translation should at least be possible.
> 
> 
> This may be true.  The Diameter IPFilterRule was chosen because of its
> immediate likeness to the layer 3 inclinations of the IP-Filter-Raw
> attribute.  It seems like using the NAS-Filter-Rule AVP would be more
> inclusive; is that a desired direction?  There may be other reasons
> for using NAS-Filter-Rule of which I am unaware.

The definitions appear to have the same contents, given that you
refer to Diameter data type. I think the semantics are also the
same. Perhaps you should just state that this is like the NAS-Filter-Rule
AVP -- and maybe name it NAS-Filter-Rule-Radius or something like
that to make it obvious.

--Jari

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 15 Dec 2003 22:47:40 +0000
Date: Tue, 16 Dec 2003 00:46:32 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: "Adrangi, Farid" <[email-masked]>
Cc: [email-masked]
Subject: Re: Comments on draft-adrangi-radius-extension-for-pwlan-00.txt

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 [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 15 Dec 2003 22:31:38 +0000
content-class: urn:content-classes:message
Subject: RE: General comments on the LAN attributes work
Date: Mon, 15 Dec 2003 14:30:52 -0800
From: "Adrangi, Farid" <[email-masked]>
To: <[email-masked]>
Cc: "Bernard Aboba" <[email-masked]>, <[email-masked]>, <[email-masked]>, "Bari, Farooq" <[email-masked]>, "Korhonen Jouni" <[email-masked]>

Hi Jari,
Please see my comments inline.
BR,
Farid

> -----Original Message-----
> From: [email-masked]=20
> [mailto:[email-masked]] On Behalf Of Jari Arkko
> Sent: Monday, December 15, 2003 5:02 AM
> To: Bernard Aboba; [email-masked]'; [email-masked]
> Subject: General comments on the LAN attributes work
>=20
>=20
>=20
> 1) The world has evolved a lot since the RADIUS attributes
>     were defined, as we mainly had dial-in in mind back then.
>     New link layers, their new capabilities, and roaming imply
>     that there is a need for new AAA attributes as well. I support
>     extension work to define such attributes.
>=20
> 2) Most of the proposed new functions are valid. Not quite
>     sure about _all_ them, such as capabilities negotiation for
>     RADIUS.
>=20
[FA] If you are referring to Application-Based capability in our draft,=20
I wouldn't put it as capabilities negotiation, rather as capabilities=20
Advertisement. [FA]

> 3) Almost everything in the drafts that I read applies to
>     both Diameter and RADIUS. There were a few exceptions, such
>     as some attributes which already existed in RADIUS. I believe
>     it would be a serious design mistake to make the drafts apply
>     just for RADIUS. As these functions are mainly about new=20
> attributes,
>     they should be documented in such a way that they apply to
>     both Diameter and RADIUS. Please make it so. In one draft.
>=20
>     There may be a few cases where translation becomes an issue.
>     If so, those need to be documented. But there is simply no
>     excuse to making this work RADIUS-specific.
>=20

[FA] You have a point here. [FA]

> 4) It may be worthwhile to think about the organization of
>     the attribute definitions into different documents, if
>     we get to standardizing them. Some of this stuff is
>     more general than LAN.
>=20
>     Personally, I'd prefer a set of multiple smaller specifications.
>     Say, an RFC on location attributes for AAA. I think we could
>     get them done sooner and it would be easier for vendors to
>     document what they support.
>=20

[FA] Yes.  In fact, we (Farooq and I) discussed this with Bernard=20
after the RadiusExt BoF in IETF#58.  We specifically discussed this in=20
the context of location information as there is an urgency to get the
attributes finalized by GSMA.  This was also suggested in the last GSMA
meeting, and we are planning to submit the finalized version in a
separate
draft. [FA]

> --Jari
>=20
>=20
>=20
> --
> to unsubscribe send a message to=20
> [email-masked] with the word 'unsubscribe' in=20
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 15 Dec 2003 22:06:29 +0000
content-class: urn:content-classes:message
Subject: RE: Comments on draft-adrangi-radius-extension-for-pwlan-00.txt
Date: Mon, 15 Dec 2003 14:05:54 -0800
From: "Adrangi, Farid" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>

Hello Jari,

Thanks for taking time and reading the draft, and for your excellent=20
comments (as always).  Although these attributes were motivated by=20
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=20
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. =20
BR,
Farid

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]]=20
> Sent: Monday, December 15, 2003 4:56 AM
> To: [email-masked]'; Adrangi, Farid
> Subject: Comments on draft-adrangi-radius-extension-for-pwlan-00.txt
>=20
>=20
>=20
> I have read
>=20
>   =20
> http://www.ietf.org/internet-drafts/draft-adrangi-radius-exten
> sion-for-pwlan-00.txt
>=20
> and have some questions and comments:
>=20
>   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.
>=20
>      And again, this is pretty general, not tied to PWLANs...
>=20

[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.=20
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=20
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=20
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.
>=20

[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). =20
Why do you think this is not a useful attribute?  [FA]

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

>   o  Address type "Public and Private": I have trouble
>      seeing how this works in IPv4.
>=20

[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=20
does a DHCP request - which IMO, this is outside the scope of the
document and=20
perhaps we should be more explicit about it.  Which aspect of the
feature do=20
you have problem with? [FA]

>   o  Sect 2.7 overlaps with draft-black. I liked the
>      draft-black approach better.
>=20

[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=20
and the format/syntax. [FA]

> --Jari
>=20
>=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 15 Dec 2003 18:14:33 +0000
From: "BLACK,CHUCK (HP-Roseville,ex1)" <[email-masked]>
To: [email-masked]
Cc: "BLACK,CHUCK (HP-Roseville,ex1)" <[email-masked]>
Subject: RE: Comments on draft-black-radius-lanedge-00.txt
Date: Mon, 15 Dec 2003 13:13:59 -0500

From: Jari Arkko [mailto:[email-masked]] 

>  o  In general I support this type of a specification that would
>     define WLAN or LAN specific attributes for AAA. We need this.

Good, it seemed that there would be interest in this, and the intention
was to generate discussion and arrive at some sort of consensus.

>  o  The attributes should be done in a general fashion, in one
>    document, and be applicable for both RADIUS and Diameter.
>    With translation, if necessary, described in the document.

Would you consider that this RADIUSEXT WG is the appropriate
place for this discussion then, since many of the folks involved
with RADIUS are also involved with Diameter?

>  o  Section 2.3.7, attribute IP-Filter-Name: What is the difference
>     between this attribute and the Filter-Id attribute from RFC 2865?
>     Do we need another one?

There is no fundamental difference between the current typical
usage of the Filter-Id attribute and the new IP-Filter-Name.
However, this is also true, based on RFC 3580, of the VLAN
attributes, which are using the Tunnel attributes to specify
VLAN information (see section 3.9 of RFC 3580 for Filter-Id
usage, and section 3.31 for Tunnel/VLAN usage).

The intent was to extract the common LAN edge attributes and
place them together.  At the risk, as you mention, of redundancy.
I'm not sure argument should prevail, so some discussion
on the matter will help to decide the issue.

>o  Section 2.3.8, IP-Filter-Raw: Note that the RADIUS attribute
>     length may reduce the usefulness of this attribute. I think
>     Filter-Id may have to be sufficient where this is an issue.

This is unfortunate but true.

>     Also, it would be better to hightlight the relationship of
>     the proposed attribute and Diameter NASREQ NAS-Filter-Rule AVP.
>     Note that this AVP has a code 400 which means it is not directly
>     RADIUS compatible. But if the definitions are aligned otherwise
>     then translation should at least be possible.

This may be true.  The Diameter IPFilterRule was chosen because of its
immediate likeness to the layer 3 inclinations of the IP-Filter-Raw
attribute.  It seems like using the NAS-Filter-Rule AVP would be more
inclusive; is that a desired direction?  There may be other reasons
for using NAS-Filter-Rule of which I am unaware.

> ...

>  o  It may be worthwhile to think a little bit how to divide the work
>     into documents if we get to standardizing this. Maybe one draft
>     on general access attributes, another one on 802, and we already have
>     one one that clarifies the use of existing attributes in 802.1X (RFC
>     3580).

These are also good suggestions.  It would be useful to have a more
organized and intentional categorization of attributes into their
intended domains.

/chuck

-----Original Message-----
From: Jari Arkko [mailto:[email-masked]] 
Sent: Monday, December 15, 2003 4:54 AM
To: [email-masked]; [email-masked]
Subject: Comments on draft-black-radius-lanedge-00.txt

I have read

   http://www.drizzle.com/~aboba/IEEE/draft-black-radius-lanedge-00.txt

and have some questions and comments:

  o  In general I support this type of a specification that would
     define WLAN or LAN specific attributes for AAA. We need this.

  o  The attributes should be done in a general fashion, in one
     document, and be applicable for both RADIUS and Diameter.
     With translation, if necessary, described in the document.

  o  Section 2.3.7, attribute IP-Filter-Name: What is the difference
     between this attribute and the Filter-Id attribute from RFC 2865?
     Do we need another one?

  o  Section 2.3.8, IP-Filter-Raw: Note that the RADIUS attribute
     length may reduce the usefulness of this attribute. I think
     Filter-Id may have to be sufficient where this is an issue.
     Also, it would be better to hightlight the relationship of
     the proposed attribute and Diameter NASREQ NAS-Filter-Rule AVP.
     Note that this AVP has a code 400 which means it is not directly
     RADIUS compatible. But if the definitions are aligned otherwise
     then translation should at least be possible.

  o  The Bandwidth-*-* attributes: I like these attributes. This seems
     like a general set of attributes which may even be used outside LANs.

  o  It may be worthwhile to think a little bit how to divide the work
     into documents if we get to standardizing this. Maybe one draft
     on general access attributes, another one on 802, and we already have
     one one that clarifies the use of existing attributes in 802.1X (RFC
     3580).

--Jari

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 15 Dec 2003 13:03:10 +0000
Date: Mon, 15 Dec 2003 15:02:07 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Bernard Aboba <[email-masked]>, "[email-masked]'" <[email-masked]>, [email-masked]
Subject: General comments on the LAN attributes work

1) The world has evolved a lot since the RADIUS attributes
    were defined, as we mainly had dial-in in mind back then.
    New link layers, their new capabilities, and roaming imply
    that there is a need for new AAA attributes as well. I support
    extension work to define such attributes.

2) Most of the proposed new functions are valid. Not quite
    sure about _all_ them, such as capabilities negotiation for
    RADIUS.

3) Almost everything in the drafts that I read applies to
    both Diameter and RADIUS. There were a few exceptions, such
    as some attributes which already existed in RADIUS. I believe
    it would be a serious design mistake to make the drafts apply
    just for RADIUS. As these functions are mainly about new attributes,
    they should be documented in such a way that they apply to
    both Diameter and RADIUS. Please make it so. In one draft.

    There may be a few cases where translation becomes an issue.
    If so, those need to be documented. But there is simply no
    excuse to making this work RADIUS-specific.

4) It may be worthwhile to think about the organization of
    the attribute definitions into different documents, if
    we get to standardizing them. Some of this stuff is
    more general than LAN.

    Personally, I'd prefer a set of multiple smaller specifications.
    Say, an RFC on location attributes for AAA. I think we could
    get them done sooner and it would be easier for vendors to
    document what they support.

--Jari

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 15 Dec 2003 13:00:02 +0000
content-class: urn:content-classes:message
Subject: RE: Comments on draft-adrangi-radius-extension-for-pwlan-00.txt
Date: Mon, 15 Dec 2003 14:59:43 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>

Jari,

>   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.
>=20
>      And again, this is pretty general, not tied to PWLANs...

Location is a contentious issue in the IETF - I wonder if there
is any relation to the GEOPRIV work that is on-going.

John

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 15 Dec 2003 12:56:55 +0000
Date: Mon, 15 Dec 2003 14:55:53 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: "[email-masked]'" <[email-masked]>, "Adrangi, Farid" <[email-masked]>
Subject: Comments on draft-adrangi-radius-extension-for-pwlan-00.txt

I have read

   http://www.ietf.org/internet-drafts/draft-adrangi-radius-extension-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...

  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.

  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?

  o  Address type "Public and Private": I have trouble
     seeing how this works in IPv4.

  o  Sect 2.7 overlaps with draft-black. I liked the
     draft-black approach better.

--Jari

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 15 Dec 2003 12:56:14 +0000
Date: Mon, 15 Dec 2003 14:55:12 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: "[email-masked]'" <[email-masked]>, "Adrangi, Farid" <[email-masked]>
Subject: Comments on draft-adrangi-radius-issues-in-pwlan-roaming-00.txt

I have read

   http://www.ietf.org/internet-drafts/draft-adrangi-radius-issues-in-pwlan-roaming-00.txt

and have some questions and comments:

  o  This is a good document and useful input for the kinds of
     problems the IETF should look at.

  o  The lack of Identity for Accounting Purposes (sect. 3.1): I agree
     that this is an issue where things like EAP-AKA which has identity
     protection or PEAP which hides the identity are used. Perhaps
     draft-ietf-aaa-eap should discuss this. But since the issue is
     in fact common to both Diameter and RADIUS, we could also describe
     it separately. "Accounting Considerations for Identity Privicy" I-D?

  o  The lack of Standard (sect. 3.2): I agree that it is troublesome
     to arrange global naming of filters in a roaming scenario. Diameter
     does help this by allowing the home network to define the filters;
     draft-black has a similar scheme but limited in packet size.

     I would support some standardization of basic filter sets, and their
     naming. This could be either an IETF effort, or maybe something done
     in, say, WiFi alliance.

  o  Access Network Location (sect. 3.4): I would like to do this
     in a manner which is as independent as possible from the given
     access network type. There seems to be two separate issues:
     geographic location (draft-black) and identity of the NAS.

  o  Type of address (sect. 3.5): Yes, this would be useful. This
     is again general, not tied to wireless LANs. I think there
     may be ip address pool attributes somewhere that could also be
     used for this purpose.

  o  QoS parameters (sect. 3.8): Yes, I agree that something like
     that is needed. Draft-black has some basic attributes for it.
     What parameters specifically would you need?

  o  The document should be focused around "AAA", not just RADIUS,
     issues in PWLAN roaming. It would be helpful to identify
     which issues are common (most are) and which are specific
     to a particular AAA protocol.

  o  Non-ascii characters in the text (at least quotes).

--Jari

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 15 Dec 2003 12:55:38 +0000
Date: Mon, 15 Dec 2003 14:53:59 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: [email-masked], [email-masked]
Subject: Comments on draft-black-radius-lanedge-00.txt

I have read

   http://www.drizzle.com/~aboba/IEEE/draft-black-radius-lanedge-00.txt

and have some questions and comments:

  o  In general I support this type of a specification that would
     define WLAN or LAN specific attributes for AAA. We need this.

  o  The attributes should be done in a general fashion, in one
     document, and be applicable for both RADIUS and Diameter.
     With translation, if necessary, described in the document.

  o  Section 2.3.7, attribute IP-Filter-Name: What is the difference
     between this attribute and the Filter-Id attribute from RFC 2865?
     Do we need another one?

  o  Section 2.3.8, IP-Filter-Raw: Note that the RADIUS attribute
     length may reduce the usefulness of this attribute. I think
     Filter-Id may have to be sufficient where this is an issue.
     Also, it would be better to hightlight the relationship of
     the proposed attribute and Diameter NASREQ NAS-Filter-Rule AVP.
     Note that this AVP has a code 400 which means it is not directly
     RADIUS compatible. But if the definitions are aligned otherwise
     then translation should at least be possible.

  o  The Bandwidth-*-* attributes: I like these attributes. This seems
     like a general set of attributes which may even be used outside LANs.

  o  It may be worthwhile to think a little bit how to divide the work
     into documents if we get to standardizing this. Maybe one draft
     on general access attributes, another one on 802, and we already have
     one one that clarifies the use of existing attributes in 802.1X (RFC
     3580).

--Jari

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 12 Dec 2003 22:08:10 +0000
From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
To: "'Nelson, David'" <[email-masked]>, Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Cc: [email-masked]
Subject: RE: kickstart and SSPP
Date: Fri, 12 Dec 2003 16:07:27 -0600

Hi Dave,

Thank you for your answers. 

What types of ID does the NAS use (beside IP address) in the NAS ID field?
Would the RADIUS server then later store this ID or the NAS IP address in
its database?
Also I am wondering if the RADIUS server keeps any entry about the user's IP
address?

Thanks in advance,

Madjid
P.S. It seems that the SSPP and kick start drafts have found a new home
in Enroll WG.

The NAS has a transitive trust relationship with the home server, via
the proxy server chain, but no direct trust relationship.  Each proxy
server will generally validate the NAS identity before forwarding a
request.  If you have a "rogue" proxy in the chain, security problems
will obviously exist.

> > The NAS ID is the of originating client, not the proxy.
> 
> Madjid>>So are you saying the packet carries both an IP address (for
the
> proxy or NAS) and a NAS ID for originating NAS?

Yes.  The packet's source IP address is in the IP header and the NAS ID
(or NAS IP Address) is in the packet payload.  It is the Source IP
address from the IP header that is used to look up the shared secret.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 09 Dec 2003 23:05:53 +0000
content-class: urn:content-classes:message
Subject: RE: kickstart and SSPP
Date: Tue, 9 Dec 2003 18:05:12 -0500
From: "Nelson, David" <[email-masked]>
To: "Nakhjiri Madjid-MNAKHJI1" <[email-masked]>
Cc: <[email-masked]>

Madjid writes...

> Thank you for your response. Let me try to understand your reponse:
> please see inserts.

<snip>

> > General question first, why did RADIUS madated the use
> > of source IP address from the UDP packet as a way of shared
> > secret look up in the first place.
>=20
> Because shared secrets in RADIUS are hop-by-hop, and the only reliable
> way to look up the shared secret for a proxy server is via the source
IP
> address.
>=20
> Madjid>>if the shared secret is hop by hop and there are proxies on
the
> way, does that mean the NAS will not have a shared secret with the
home=20
> RADIUS server?

Yes.  The NAS will share a RADIUS secret with any first-hop RADIUS
server it contacts, but will generally not share a secret with the
ultimate home RADIUS server, in proxy deployments.

> This means the home server will not have any trust relationship
> with the NAS that accepting users on behalf of that server?

The NAS has a transitive trust relationship with the home server, via
the proxy server chain, but no direct trust relationship.  Each proxy
server will generally validate the NAS identity before forwarding a
request.  If you have a "rogue" proxy in the chain, security problems
will obviously exist.

> > The NAS ID is the of originating client, not the proxy.
>=20
> Madjid>>So are you saying the packet carries both an IP address (for
the
> proxy or NAS) and a NAS ID for originating NAS?

Yes.  The packet's source IP address is in the IP header and the NAS ID
(or NAS IP Address) is in the packet payload.  It is the Source IP
address from the IP header that is used to look up the shared secret.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 09 Dec 2003 22:49:07 +0000
From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
To: "'Nelson, David'" <[email-masked]>
Cc: [email-masked]
Subject: RE: kickstart and SSPP
Date: Tue, 9 Dec 2003 16:46:38 -0600 

Hi Dave,

Thank you for your response. Let me try to understand your reponse:
please see inserts.

Regards,

Madjid

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Nelson, David
Sent: Saturday, December 06, 2003 9:27 AM
Cc: [email-masked]
Subject: RE: kickstart and SSPP

> General question first, why did RADIUS madated the use
> of source IP address from the UDP packet as a way of shared
> secret look up in the first place.

Because shared secrets in RADIUS are hop-by-hop, and the only reliable
way to look up the shared secret for a proxy server is via the source IP
address.  

Madjid>>if the shared secret is hop by hop and there are proxies on the way,
does that mean the NAS will not have a shared secret with the home RADIUS
server? This means the home server will not have any trust relationship with
the NAS that accepting users on behalf of that server? 

The NAS ID is the of originating client, not the proxy.

Madjid>>So are you saying the packet carries both an IP address (for the
proxy or NAS) and a NAS ID for originating NAS?

Regards,

Dave

David B. Nelson
Wireless & AAA Architect, Office of the CTO
Enterasys Networks, Inc.
50 Minuteman Road
Andover, MA 01810-1008
(978) 684-1330
[email-masked]

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 08 Dec 2003 22:54:33 +0000
From: Mike Santoro <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: This is my test to see if I am on the list
Date: Mon, 8 Dec 2003 17:53:59 -0500 

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C3BDDE.2AEF6FB0
Content-Type: text/plain

I just wanted to check and see if the List was functional from my mail
server.
 
Michael Santoro
Systems Engineer
Funk Software Inc.
617-497-6339 x220

------_=_NextPart_001_01C3BDDE.2AEF6FB0
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<html xmlns:o=3D"urn:schemas-microsoft-com:office:office" =
xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:st1=3D"urn:schemas-microsoft-com:office:smarttags" =
xmlns=3D"http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">

<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 10">
<meta name=3DOriginator content=3D"Microsoft Word 10">
<link rel=3DFile-List href=3D"cid:[email-masked]">
<o:SmartTagType =
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"
 name=3D"PersonName"/>
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:DoNotRelyOnCSS/>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:SpellingState>Clean</w:SpellingState>
  <w:DocumentKind>DocumentEmail</w:DocumentKind>
  <w:EnvelopeVis/>
  <w:Compatibility>
   <w:BreakWrappedTables/>
   <w:SnapToGridInCell/>
   <w:ApplyBreakingRules/>
   <w:WrapTextWithPunct/>
   <w:UseAsianBreakRules/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
 </w:WordDocument>
</xml><![endif]--><!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]-->
<style>
<!--
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;
	text-underline:single;}
p.MsoAutoSig, li.MsoAutoSig, div.MsoAutoSig
	{margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman";
	mso-fareast-font-family:"Times New Roman";}
span.EmailStyle17
	{mso-style-type:personal-compose;
	mso-style-noshow:yes;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;
	font-family:Arial;
	mso-ascii-font-family:Arial;
	mso-hansi-font-family:Arial;
	mso-bidi-font-family:Arial;
	color:windowtext;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.25in 1.0in 1.25in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */=20
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-parent:"";
	mso-padding-alt:0in 5.4pt 0in 5.4pt;
	mso-para-margin:0in;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman";}
</style>
<![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:.5in'>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'>I just wanted to check and =
</span></font><st1:PersonName><font
 size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>se</span></font></st1:Perso=
nName><font
size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;font-family:Arial'>e if the
List was functional from my mail server.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 face=3DArial><span =
style=3D'font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoAutoSig><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt;mso-no-proof:yes'>Michael Santoro<o:p></o:p></span></font></p>

<p class=3DMsoAutoSig><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt;mso-no-proof:yes'>Systems Engineer<o:p></o:p></span></font></p>

<p class=3DMsoAutoSig><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt;mso-no-proof:yes'>Funk Software =
Inc.<o:p></o:p></span></font></p>

<p class=3DMsoAutoSig><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt;mso-no-proof:yes'>617-497-6339 x220<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D3 face=3D"Times New Roman"><span =
style=3D'font-size:
12.0pt'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>

------_=_NextPart_001_01C3BDDE.2AEF6FB0--

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Sat, 06 Dec 2003 15:28:31 +0000
Subject: RE: kickstart and SSPP
Date: Sat, 6 Dec 2003 10:27:20 -0500
content-class: urn:content-classes:message
From: "Nelson, David" <[email-masked]>
Cc: <[email-masked]>

> General question first, why did RADIUS madated the use
> of source IP address from the UDP packet as a way of shared
> secret look up in the first place.

Because shared secrets in RADIUS are hop-by-hop, and the only reliable
way to look up the shared secret for a proxy server is via the source IP
address.  The NAS ID is the of originating client, not the proxy.

Regards,

Dave

David B. Nelson
Wireless & AAA Architect, Office of the CTO
Enterasys Networks, Inc.
50 Minuteman Road
Andover, MA 01810-1008
(978) 684-1330
[email-masked]

=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Fri, 05 Dec 2003 22:47:53 +0000
From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
To: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
Cc: [email-masked]
Subject: kickstart and SSPP
Date: Fri, 5 Dec 2003 16:46:27 -0600 

Hi,

First one question for the public and then a few for the authors
of kickstart draft.

General question first, why did RADIUS madated the use
of source IP address from the UDP packet as a way of shared
secret look up in the first place. Can't that requirement
be changed, seems like a solution of comparable complexity, no?
This proposal is creating new messages (access boot, access booted)
already (if I understand it correctly) and that is a comparable
change...

Second, why SSPP and not IKE, I am not a cryptographer, but from
what I can see there are several round trips involved here and 
then SSPP throws the confusing SSPP client=RADIUS server... thing
in there and there are plenty of computations.
Also I know I need to read the SSPP and kickstart drafts one more 
time to understand the issues, but according to the author it does not
prevent the case there can be wireless and unprotected route between
client and server, doesn't IKE provision for this?

It seems like there was a BoF in Minneapolis on IKEv2 for Mobile IP
seems like that work would be more generic.

I am sorry if I am blunt, I just heard my 11-month old daughter has
started walking so I am rushing home to see it:)

Thanks and Regards,

Madjid

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 03 Dec 2003 23:00:08 +0000
From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
To: "'Bernard Aboba'" <[email-masked]>
Cc: [email-masked]
Subject: RE: irtf-aaaarch-handoff-02 draft
Date: Wed, 3 Dec 2003 16:57:18 -0600 

Thanks,

What about the context transfer draft?

BR,
Madjid

-----Original Message-----
From: Bernard Aboba [mailto:[email-masked]]
Sent: Tuesday, December 02, 2003 9:33 PM
To: Nakhjiri Madjid-MNAKHJI1
Cc: [email-masked]
Subject: Re: irtf-aaaarch-handoff-02 draft

This work is ongoing within IRTF, and a request was made by the
lead author (Bill Arbaugh) that work continue there.

On Tue, 2 Dec 2003, Nakhjiri Madjid-MNAKHJI1 wrote:

> Question for the chair,
>
> The expertimental handoff extension draft was in the few first agendas
> for the IETF BoF, but it seems to have later on fell off the agenda.
>
> Care for any explanation? I am sorry if this had been discussed earlier,
> I am a newcomer on this list.
>
> Regards,
>
> Madjid Nakhjiri
>
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Wed, 03 Dec 2003 03:14:23 +0000
Date: Tue, 2 Dec 2003 19:32:42 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
cc: [email-masked]
Subject: Re: irtf-aaaarch-handoff-02 draft

This work is ongoing within IRTF, and a request was made by the
lead author (Bill Arbaugh) that work continue there.

On Tue, 2 Dec 2003, Nakhjiri Madjid-MNAKHJI1 wrote:

> Question for the chair,
>
> The expertimental handoff extension draft was in the few first agendas
> for the IETF BoF, but it seems to have later on fell off the agenda.
>
> Care for any explanation? I am sorry if this had been discussed earlier,
> I am a newcomer on this list.
>
> Regards,
>
> Madjid Nakhjiri
>
> --
> to unsubscribe send a message to [email-masked] with
> the word 'unsubscribe' in a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
>

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Tue, 02 Dec 2003 22:18:46 +0000
From: Nakhjiri Madjid-MNAKHJI1 <[email-masked]>
To: [email-masked]
Subject: irtf-aaaarch-handoff-02 draft
Date: Tue, 2 Dec 2003 16:14:52 -0600 

Question for the chair,

The expertimental handoff extension draft was in the few first agendas
for the IETF BoF, but it seems to have later on fell off the agenda.

Care for any explanation? I am sorry if this had been discussed earlier,
I am a newcomer on this list.

Regards,

Madjid Nakhjiri 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 01 Dec 2003 19:25:31 +0000
Content-Class: urn:content-classes:message
Subject: RE: Subtypes
Date: Mon, 1 Dec 2003 14:24:21 -0500
From: "Nelson, David" <[email-masked]>
Cc: <[email-masked]>

Avi Lior writes...

> Which approach?
> The approach of forcing an X.500 to be encoded using separate
attributes.
> Or the set of tests I defined above?

The former.

> Actually I will make a stronger statement: there is no distinction
between
> the two. =20

I respectfully disagree.

> One man's garbage is another man's treasure;

Well that's true, and I guess I tend to fall more in the camp of
considering multiple, ASCII-delimited, implicit-length, sub-type fields
in a single attribute as "garbage".  Sorry.

> But what is wrong with justifying existing implmentation for the sake
of
> convience to early adopters.  That should also be taken into account.
no?
> If the attribute as been in wide use and there is no good reason to
change
> it then lets not.  Doesn't that make common sense.

All else being equal, yes, it would make sense.  However, in this case,
I don't see all else actually being equal.  I see a serious protocol
design quality issue.

-- Dave

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 01 Dec 2003 19:16:35 +0000
From: Avi Lior <[email-masked]>
To: "'Nelson, David'" <[email-masked]>
Cc: [email-masked]
Subject: RE: Subtypes
Date: Mon, 1 Dec 2003 14:16:09 -0500 

> -----Original Message-----
> From: Nelson, David [mailto:[email-masked]] 
> Sent: Monday, December 01, 2003 12:06 PM
> Cc: [email-masked]
> Subject: RE: Subtypes
> 
> 
> Avi Lior writes...
> 
> > I would rather see a test that considers the following:
> > A) Are subcomponents of the attribute useful to intermediaries;
> > B) Should subcomponent be "promoted" because they are useful.
> > C) If a RADIUS server needs to parse the attributes, does it make 
> > sense to encode them using subTLVs. There could be other "tests" or 
> > guidelines.
> > 
> > If I wanted to be pendantic about the feedback I am getting on
> > this list; your X.500 MUST be encoded using separate attributes.
> 
> Fine.  I would not object to that approach. 

Which approach?
The approach of forcing an X.500 to be encoded using separate attributes. Or
the set of tests I defined above?

> My point was 
> that multi-part data entities that comprise a *single* entity 
> in a well-defined ASCII (UTF-8) syntax, such as FQDNs, are 
> perfectly "normal" as string-valued attribute content.  A 
> group of *related* data entities encoded in a similar fashion 
> is simply sub-types in disguise.  I agree
> that the distinction can be a fine one to attempt to codify, 
> however.   

Actully I will make a stronger statement: there is no distinction between
the two.  One man's garbage is another man's treasure;

> > Using my test we can decide what the best action to take on an
> > attribute by attribute basis.
> 
> Well, please forgive my directness, but your suggested rules 
> seem designed to justify existing implementation, for the 
> sake of convenience to the early adopters, rather than 
> focusing on good protocol design principles.  I understand 
> that this is also a somewhat subjective analysis -- but I 
> think it's one of those "I know it when I see it." sort of things.

Not for the sake of convenience to early adopters at all. But I think a
pragmatic approach to a problem.  BTW, my rules are not complete just
something I came up with on the fly - if that is the right approach lets
create a set of rules/guidelines that do make sense. 

But what is wrong with justifying existing implmentation for the sake of
convience to early adopters.  That should also be taken into account. no?
If the attribute as been in wide use and there is no good reason to change
it then lets not.  Doesn't that make common sense. 

> Regards,
>  
> Dave
>  
> David B. Nelson
> Wireless & AAA Architect, Office of the CTO
> Enterasys Networks, Inc.
> 50 Minuteman Road
> Andover, MA 01810-1008
> Phone: (978) 684-1330  
> E-mail: [email-masked]
>  
> 
> 
> --
> to unsubscribe send a message to 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.
> archive: <http://psg.com/lists/radiusext/>
> 

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 01 Dec 2003 17:06:31 +0000
Content-Class: urn:content-classes:message
Subject: RE: Subtypes
Date: Mon, 1 Dec 2003 12:05:40 -0500
From: "Nelson, David" <[email-masked]>
Cc: <[email-masked]>

Avi Lior writes...

> I would rather see a test that considers the following:
> A) Are subcomponents of the attribute useful to intermediaries;
> B) Should subcomponent be "promoted" because they are useful.
> C) If a RADIUS server needs to parse the attributes, does it make
> sense to encode them using subTLVs.
> There could be other "tests" or guidelines.
>=20
> If I wanted to be pendantic about the feedback I am getting on=20
> this list; your X.500 MUST be encoded using separate attributes.

Fine.  I would not object to that approach.  My point was that
multi-part data entities that comprise a *single* entity in a
well-defined ASCII (UTF-8) syntax, such as FQDNs, are perfectly "normal"
as string-valued attribute content.  A group of *related* data entities
encoded in a similar fashion is simply sub-types in disguise.  I agree
that the distinction can be a fine one to attempt to codify, however.  =20

> Using my test we can decide what the best action to take on an=20
> attribute by attribute basis.

Well, please forgive my directness, but your suggested rules seem
designed to justify existing implementation, for the sake of convenience
to the early adopters, rather than focusing on good protocol design
principles.  I understand that this is also a somewhat subjective
analysis -- but I think it's one of those "I know it when I see it."
sort of things.

Regards,
=20
Dave
=20
David B. Nelson
Wireless & AAA Architect, Office of the CTO
Enterasys Networks, Inc.
50 Minuteman Road
Andover, MA 01810-1008
Phone: (978) 684-1330 =20
E-mail: [email-masked]
=20

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 01 Dec 2003 16:51:40 +0000
From: Avi Lior <[email-masked]>
To: "'Nelson, David'" <[email-masked]>
Cc: [email-masked]
Subject: RE: Subtypes
Date: Mon, 1 Dec 2003 11:50:15 -0500 

> like this:
> > 
> >         Operator-name=GSM:T-Mobile, location-ID=44,location-
> >         name=starbucks-4,location-type=coffee shop, city= seattle,
> >         state=Washington,country=us

> String-valued attributes containing a single, well-defined 
> entity, such as a Fully-Qualified Domain Name or an X.500 
> Distinguished Name, would seem to be perfectly appropriate.

> However, attempting to create new "entities" in an effort to 
> encode sub-types in an ASCII-delimited, implicit-length 
> protocol encoding, would be a Very Bad Thing (tm), IMHO.

Your argument which relies on the premise that something that is well
defined is okay to be encoded as a subtype vs something that is not well
defined is not okay is problematic to me. Why, because whether something is
well defined or not is hugely debateable.

The authors of the above can argue that the example is a well defined
entity.
I will argue that my Prepaid attribute is a well defined entity and in fact
it is.

I would rather see a test that considers the following:
A) Are subcomponents of the attribute useful to intermediaries;
B) Should subcomponent be "promoted" because they are useful.
C) If a RADIUS server needs to parse the attributes, does it make sense to
encode them using subTLVs.
There could be other "tests" or guidelines.

If I wanted to be pendantic about the feedback I am getting on this list;
your X.500 MUST be encoded using separate attributes.

Using my test we can decide what the best action to take on an attribute by
attribute basis.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 01 Dec 2003 15:38:01 +0000
Content-Class: urn:content-classes:message
Subject: RE: Subtypes
Date: Mon, 1 Dec 2003 10:37:11 -0500
From: "Nelson, David" <[email-masked]>
Cc: <[email-masked]>

Avi Lior writes...

> I didn't hear too many folks complain about
> draft-adrangi-radius-extension-for-pwlan-00.txt PWLAN Location
Information
> Attribute (2.1) the proposed encoding in that document would yield an
> attribute that contained a string that would look something like this:
>=20
>         Operator-name=3DGSM:T-Mobile, location-ID=3D44,location-
>         name=3Dstarbucks-4,location-type=3Dcoffee shop, city=3D =
seattle,
>         state=3DWashington,country=3Dus
>=20
> We want this now to be encoded using subTLV.  What is wrong with that?
It
> saves space and it saves parsing time (when it needs to be parsed)

Well, perhaps we simply haven't attempted to "fry that fish" yet...  :-)

String-valued attributes containing a single, well-defined entity, such
as a Fully-Qualified Domain Name or an X.500 Distinguished Name, would
seem to be perfectly appropriate.

However, attempting to create new "entities" in an effort to encode
sub-types in an ASCII-delimited, implicit-length protocol encoding,
would be a Very Bad Thing (tm), IMHO.

Regards,
=20
Dave
=20
David B. Nelson
Wireless & AAA Architect, Office of the CTO
Enterasys Networks, Inc.
50 Minuteman Road
Andover, MA 01810-1008
Phone: (978) 684-1330 =20
E-mail: [email-masked]

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

Delivery-date: Mon, 01 Dec 2003 15:16:29 +0000
Date: Mon, 01 Dec 2003 16:15:32 +0100
From: nagi reddy jonnala <[email-masked]>
Organization: Alcatel Telecom
To: [email-masked]
Subject: Comments/questions on Prepaid-draft-02

Prepaid authors & all,

I hope not having a chartered WG is not a restriction to discuss
the drafts. Please let me know if I have the wrong assumption.

Here are the comments/questions on prepaid-draft-02.

1) I'm not really convinced with the way *Service Element" work?
How can an element sits in between access device and a Prepaid
server *disconnect* a session on the access device? I can unserstand
it can meter the things but can not disconnect sessions.

You can argue that Service element asks/updates the quotas. How do
you handle the re-authorizations that are supposed to be initiated
by access devices.

Can you explain little further of its significance and how it works?

2) Doesn't PP draft *standardize* the servic keys? I would assume
that it is really important for interoperation.

3) Always, Termination-Action MUST be set to Radius-Request to
   make sure that access device will ask for another quota rather than
   disconnecting the session (it is the case if Termination-Action
   = default).

4) Section 4.2 talks about sending User-Password attribute while sending

the message from HAAA to Prepaid server for more security.

I disagree with this. What are we doing here? Are we making PP server
another
authentication server?

5) Sections 4.2.1 and  4.4, Ascend-data-filter was mentioned separately.

     I guess we can remove this.

6) Section 4.4, Mid-Session Operation - doesn't consider if there are
Broker
AAAs in between. For example, You may need to add IP addresses of
PP servers to the Access-Requests.

7) Section 4.4, Mid-Session operation:

Isn't it possible that the operator wants to update his services
and wants to notify the access points.

8) Section 4.5.1. says "Each AAA MUST route the Disconnect Request
packet.
How the routing decision is made is an implementation detail. "

Can you explain how can a Disconnect message initiated by PP
server will reach the Access Device?  I mean what are the attributes
involved to make the packet reach its destination through the proxies.

9) what does a PP server do if it receives Disconnect-NAK?
Does it keep billing?

10) Section 4.5.1

"Once the Disconnect Request packet reaches AAA that is in the same
   network as the serving Access Device, if the Access Device supports
   Disconnect-Request (as per [RFC3576]), it sends the message directly
   to the Access Device; otherwise it uses other mechanisms such as
   SNMP or Telnet to command the Access Device to terminate the
   session."

  - How does a AAA server know that if the access point supports
     Disconnect (or) CoA messages?  Is this also out of scope? :)

  - How does Telnet/SNMP work in this scenario. Can you further explain?

11) Should there be a threshold value always ( with Volume/Time quota).
      Is it possible that an access device choose not to implement
      this attribute?

12) Section 5.3.

"Sub-Type (=3): Sub-Type for VolumeQuotaOverflow
   Length: length of VolumeQuotaOverflow attribute (= 4 octets)
   VolumeQuotaOverflow (VQO):

      The optional VolumeQuotaOverflow Sub-Type is used to indicate how
      many times the VolumeQuota counter has wrapped around 2^32 over
      the course of the service being provided. "

Is this present in access-request (or) access-accept? Its worth
mentioning
who sends to whom.

Regards
Nagi.

PS: Can you tell us what does it take to flatten the attributes.
Roughly, how many
new attributes are needed? I believe it is really important to debate
this topic
to make progress.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>