Subject: RE: Subtypes
From: Avi Lior <[email-masked]>
To: "[email-masked]'" <[email-masked]>, Avi Lior <[email-masked]>, [email-masked], [email-masked]
Cc: [email-masked]
Date: Thu, 27 Nov 2003 10:49:09 -0500

> 
> Well, my point is that the current stuff will probably change 
> if RADext is chartered - we cannot expect that the current 
> stuff will just be rubber stamped.  

Sure.  But we have to be practical as well.  And if there is a huge
deployment that sometimes we just have to live with it.

>I think adding support 
> for subtypes will 
> change RADIUS.
It depends what you mean by changing RADIUS.

If by change you mean it will force folks to change their RADIUS
implementations then I don't agree.

To a RADIUS server the attribute would just look like a string.

RADIUS servers that have to dive into the attribute would have to parse this
string.

So all we are saying is that we want to define how something is encoded in a
string.

Lots of examples of that in RADIUS.  So what is the big issue here.

I think the real discussion should be based on an attribute by attribute
basis.

I could have a AAA application that has an attribute that is opaque.  What
is wrong with that?

A fair argument would be that a component of this string (a subtype) should
be exposed as its own attribute because of some reasons.

So if it is just a string encoding why do I raise the issue?  Because when I
do want to parse the string I don't want to have to support billions and
billions of different encoding styles.

To proffer an example:

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:
        
        Operator-name=GSM:T-Mobile, location-ID=44,location-
        name=starbucks-4,location-type=coffee shop, city= seattle, 
        state=Washington,country=us 

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)

In my opinion a valid argument would be for someone to say Operator-name
should be its own attribute because blah blah blah....

>  It is then reasonable to provide further 
> justification why these changes are good and how it will 
> impact existing RADIUS standards and deployment. 

Since I don't think we are fundementally changing RADIUS (above argument) I
don't think we need justification.  I see this as more of an exercise of
providing guidelines to a practice that has been in place.

> Will these 
> changes be backwards compatible? 

Yes.  Its just a string attribute we are not adding a new type.

>I don't think that it is 
> sufficient to say that there are existing 
> vendor extentions so we should support them.

> thanks,
> 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, 27 Nov 2003 09:12:41 +0000
Date: Thu, 27 Nov 2003 11:07:50 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Alan DeKok <[email-masked]>
Cc: [email-masked]
Subject: Re: Subtypes

Alan DeKok wrote:
> Avi Lior <[email-masked]> wrote:
> 
>>I doubt that the SIP folks would support not using what they have in the
>>draft already.  But I will let them voice their objections (or not).
> 
> 
>   The Sterman draft is outdated, and subject to MITM attacks.  I doubt
> that it will be accepted as-is, as an IETF draft.  It will need to be
> updated, and implementations will follow suit.

As discussed in IETF-58, it will probably also have to support
full digest, and not just one algorithm. I don't know if this
implies the attributes have to be significantly changed, if the
design is good then probably not. But I am sure that there are
at least some changes to the Sterman draft before it is applicable
for all SIP users, and up to the level required from a PS RFC.

--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, 27 Nov 2003 09:01:41 +0000
content-class: urn:content-classes:message
Subject: RE: Subtypes
Date: Thu, 27 Nov 2003 11:00:45 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Hi Avi,

> I don't disagree with you at all John.
>=20
> But lets not get tangled up on philosophical points and=20
> political points.

I agree, that was my point.
=20
> Subtypes are not that bad....they don't really break anything, they do
> create work if an intermediary had to add value by looking at some of =
the
> subtypes.  And given that there are subtypes both in VSAs and lets see
> parsing username to extract subtypes (ummmm data).  The code exists in
> probably every RADIUS server made today to do this.  So its not a big
> change.

Well, my point is that the current stuff will probably change if
RADext is chartered - we cannot expect that the current stuff
will just be rubber stamped.  I think adding support for subtypes will=20
change RADIUS.  It is then reasonable to provide further justification
why these changes are good and how it will impact existing RADIUS
standards and deployment.  Will these changes be backwards compatible?
I don't think that it is sufficient to say that there are existing=20
vendor extentions so we should support them.

thanks,
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, 27 Nov 2003 05:23:28 +0000
From: Avi Lior <[email-masked]>
To: Avi Lior <[email-masked]>, 'Alan DeKok' <[email-masked]>,  "[email-masked]'" <[email-masked]>
Subject: RE: Subtypes 
Date: Thu, 27 Nov 2003 00:23:02 -0500

Sorry that doesn't work.  Its late and I am going to bed.

> -----Original Message-----
> From: Avi Lior 
> Sent: November 26, 2003 11:55 PM
> To: 'Alan DeKok'; [email-masked]
> Subject: RE: Subtypes 
> 
> 
> Alan,
> 
> > 
> >   My opposition is based solely on implementation
> > difficulties in adding new code to handle subtypes, for more 
> > than Vendor-Specific.
> 
> Good so I have a solution for you to consider:
> 
> Lets see the difference is:
> 
> Type Length Vendor-Id Subtype1 Subtype2 Subtype3
> Vs.
> Type Length Subtype1 Subtype2 Subtytpe3
> 
> 
> If you want then we can do subtypes this way:
> 
> Type Length 0 string
> 
> Where Vendor Id of zero (0) means subtypes and string is TLV.
> 
> Now this is exactly like a VSA and would use exactly the same code.
> 
>  
> 

--
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, 27 Nov 2003 05:10:57 +0000
From: Avi Lior <[email-masked]>
To: "[email-masked]'" <[email-masked]>, Avi Lior <[email-masked]>, [email-masked], [email-masked]
Cc: [email-masked]
Subject: RE: Subtypes
Date: Thu, 27 Nov 2003 00:10:36 -0500

I don't disagree with you at all John.

But lets not get tangled up on philosophical points and political points.

Subtypes are not that bad....they don't really break anything, they do
create work if an intermediary had to add value by looking at some of the
subtypes.  And given that there are subtypes both in VSAs and lets see
parsing username to extract subtypes (ummmm data).  The code exists in
probably every RADIUS server made today to do this.  So its not a big
change.

Look at the Sterman draft.  Do you really think that an intermediary would
want to parse the guts of that attribute.

Look at PWLAN stuff.  And Prepaid.

My point is this, if there is a good argument to be made for a subtype not
to be a subtype then make it.

But banning them outright hmmmm that sounds .....

And exactly as you said, solid standards could mean having subtypes.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: November 26, 2003 11:33 PM
> To: [email-masked]; [email-masked]; 
> [email-masked]
> Cc: [email-masked]
> Subject: RE: Subtypes
> 
> 
> Hi Avi,
> 
> > Not withstanding those examples.  The sterman draft which 
> is already 
> > deployed uses subtypes are we going to force it to change?  
> (See 2.2 
> > Digest-Attributes attribute)
> 
> As I understood, the sense of the room in Minneapolis was 
> that the IETF would have change control over the 
> specifications in RADext.  I assumed that to mean that folks 
> were OK with changes to many of the protocols, and that 
> getting a solid standard was the motivation for starting a WG.
> 
> 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, 27 Nov 2003 04:55:26 +0000
From: Avi Lior <[email-masked]>
To: 'Alan DeKok' <[email-masked]>, [email-masked]
Subject: RE: Subtypes 
Date: Wed, 26 Nov 2003 23:54:59 -0500

Alan,

> 
>   My opposition is based solely on implementation 
> difficulties in adding new code to handle subtypes, for more 
> than Vendor-Specific.

Good so I have a solution for you to consider:

Lets see the difference is:

Type Length Vendor-Id Subtype1 Subtype2 Subtype3
Vs.
Type Length Subtype1 Subtype2 Subtytpe3

If you want then we can do subtypes this way:

Type Length 0 string

Where Vendor Id of zero (0) means subtypes and string is TLV.

Now this is exactly like a VSA and would use exactly the same code.

--
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, 27 Nov 2003 04:33:31 +0000
content-class: urn:content-classes:message
Subject: RE: Subtypes
Date: Thu, 27 Nov 2003 06:32:50 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Hi Avi,

> Not withstanding those examples.  The sterman draft which is already
> deployed uses subtypes are we going to force it to change?  (See 2.2
> Digest-Attributes attribute)

As I understood, the sense of the room in Minneapolis was that the IETF
would have change control over the specifications in RADext.  I assumed
that to mean that folks were OK with changes to many of the protocols,
and that getting a solid standard was the motivation for starting
a WG.

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

Envelope-to: [email-masked]
Delivery-date: Wed, 26 Nov 2003 23:00:27 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: Re: Subtypes 
Date: Wed, 26 Nov 2003 18:05:39 -0500
Message-Id: <[email-masked]>

Avi Lior <[email-masked]> wrote:
> I doubt that the SIP folks would support not using what they have in the
> draft already.  But I will let them voice their objections (or not).

  The Sterman draft is outdated, and subject to MITM attacks.  I doubt
that it will be accepted as-is, as an IETF draft.  It will need to be
updated, and implementations will follow suit.

> >   The same argument can be applied to any unknown attribute, 
> > tagged, sub-typed, or other.
> 
> Exactly. So what is the problem?

  My opposition is based solely on implementation difficulties in
adding new code to handle subtypes, for more than Vendor-Specific.

> >   With new attributes having sub-types, it's often impossible 
> > for any intermediate server to do *anything* with the 
> > attribute, other than blindly forward it.  This can 
> > significantly increase the cost of adoption.
> 
> But if those subtypes were not to be interpreted by intermediaries?

  I doubt that intermediaries would be happy being told that they
can't look at authentication packets which they forward.  Laziness
dictates that new attributes may be proxied without change by old
code, which leads to proxies not being updated.  However, for business
reasons, the proxy MAY choose to permit different service levels.  It
therefore needs to be able to examine the contents of new attributes,
even if it doesn't know what to do with them.

  It's a nit-pick, but a useful one.

> The guideline would be that subtypes would only be used if they were
> intended for a particular application.  Prepaid is a perfect example so is
> the Location Attribute and Digest attribute.

  Exactly.  Maybe your proxy refuses to permit SIP calls to the "555"
prefix.  With the current "grouped" attribute space, it's nearly
impossible for a proxy to implement that restriction without code
changes.  With a flat attribute space, it's substantially easier.

  All of this would be moot if subtypes were supported from the start,
but hind-sight is 20-20.

  Alan DeKok.

--
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, 26 Nov 2003 22:46:56 +0000
From: Avi Lior <[email-masked]>
To: 'Alan DeKok' <[email-masked]>, [email-masked]
Subject: RE: Subtypes 
Date: Wed, 26 Nov 2003 17:46:15 -0500

> 
> Avi Lior <[email-masked]> wrote:
> > Okay so are you (David Nelson) going to ask the Sterman draft to 
> > flatten their attribute?
> 
>   As an implementor, my response is "Yes, please."

I doubt that the SIP folks would support not using what they have in the
draft already.  But I will let them voice their objections (or not).
 
>   Having packed attributes is irritating.  VSA's are packed 
> solely for namespace considerations.  They are logically in 
> the same "flat" attribute space as all other RADIUS attributes.
> 
>   Having "grouped" attributes (other than tags) significantly 
> changes the RADIUS model, in my opinion.  Even the RFC 
> 2867/2868 tagged attributes are a pain.  (See recent posts to 
> full-disclosure for an
> example.)

I totally agree with your comments about the grouped attributes.  Subtypes
should have been invented at the writing of that RFC.

> > RADIUS already has the machinery for coding/decoding 
> subtypes.  What 
> > is the problem?
> 
>   It's specific to VSA's, and therefore magic.

I don't consider VSAs magic.  I do get the point that there would be some
work.
But this work would only be required where the attribute is generated and
interpreted.
 
> > We use the scheme that the top level attribute is a string that 
> > contains subTLVs.  A RADIUS server that is not interested in that 
> > attribute will see a string.  This is exactly what sterman does.
> 
>   The same argument can be applied to any unknown attribute, 
> tagged, sub-typed, or other.

Exactly. So what is the problem?

> 
>   The benefit with re-using the existing attribute structure 
> is that intermediate RADIUS servers can filter new attributes 
> through simple dictionary updates.  They may not be able to 
> *process* such a request, but that can *catch* it.
> 
>   With new attributes having sub-types, it's often impossible 
> for any intermediate server to do *anything* with the 
> attribute, other than blindly forward it.  This can 
> significantly increase the cost of adoption.

But if those subtypes were not to be interpreted by intermediaries?

The guideline would be that subtypes would only be used if they were
intended for a particular application.  Prepaid is a perfect example so is
the Location Attribute and Digest attribute.

Attributes that are needed by intermediaries should not be subtypes.

Attributes that could be reused, that are general in nature should not be
subtypes etc.....

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

Envelope-to: [email-masked]
Delivery-date: Wed, 26 Nov 2003 22:04:53 +0000
From: "Alan DeKok" <[email-masked]>
To: [email-masked]
Subject: Re: Subtypes 
Date: Wed, 26 Nov 2003 17:10:01 -0500
Message-Id: <[email-masked]>

Avi Lior <[email-masked]> wrote:
> Okay so are you (David Nelson) going to ask the Sterman draft to flatten
> their attribute?

  As an implementor, my response is "Yes, please."

  Having packed attributes is irritating.  VSA's are packed solely for
namespace considerations.  They are logically in the same "flat"
attribute space as all other RADIUS attributes.

  Having "grouped" attributes (other than tags) significantly changes
the RADIUS model, in my opinion.  Even the RFC 2867/2868 tagged
attributes are a pain.  (See recent posts to full-disclosure for an
example.)

> RADIUS already has the machinery for coding/decoding subtypes.  What is the
> problem? 

  It's specific to VSA's, and therefore magic.  If the group decides
to have multiple "sub-type" attributes, then the implementations can
be updated to generalize the processing of those attributes.  Right
now, I can say from experience that implementing the Sterman draft was
minorly annoying, because of the "magic" nature of the sub-types.  I
was unwilling to re-architect the server in order to support sub-types
for one special attribute.

> We use the scheme that the top level attribute is a string that contains
> subTLVs.  A RADIUS server that is not interested in that attribute will see
> a string.  This is exactly what sterman does.

  The same argument can be applied to any unknown attribute, tagged,
sub-typed, or other.

  The benefit with re-using the existing attribute structure is that
intermediate RADIUS servers can filter new attributes through simple
dictionary updates.  They may not be able to *process* such a request,
but that can *catch* it.

  With new attributes having sub-types, it's often impossible for any
intermediate server to do *anything* with the attribute, other than
blindly forward it.  This can significantly increase the cost of
adoption.

  Alan DeKok.

--
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, 26 Nov 2003 21:05:12 +0000
From: Avi Lior <[email-masked]>
To: "'Nelson, David'" <[email-masked]>
Cc: [email-masked]
Subject: RE: Subtypes
Date: Wed, 26 Nov 2003 16:04:28 -0500

Practical hat on:

Okay so are you (David Nelson) going to ask the Sterman draft to flatten
their attribute?

I think we need to know sooner rather then later.  I and I gather Farid want
to progress our drafts.

Philosphical hat on:

RADIUS already has the machinery for coding/decoding subtypes.  What is the
problem? 

We use the scheme that the top level attribute is a string that contains
subTLVs.  A RADIUS server that is not interested in that attribute will see
a string.  This is exactly what sterman does.

We are not introducing a new type into RADIUS.  

Comments?

> -----Original Message-----
> From: Nelson, David [mailto:[email-masked]] 
> Sent: Wednesday, November 26, 2003 2:44 PM
> Cc: [email-masked]
> Subject: RE: Subtypes
> 
> 
> Avi Writes...
> 
> > Not withstanding those examples.  The sterman draft which 
> is already 
> > deployed uses subtypes are we going to force it to change?  
> (See 2.2 
> > Digest-Attributes attribute)
> 
> I thought the whole idea of having a WG to standardize 
> extensions was to avoid the sort of thing that happens when 
> individuals, companies or other SDOs, publish Informational 
> RFCs that don't under go an appropriate level of Internet 
> community review and don't maintain reasonable architectural 
> consistency with the base protocol they are attempting to 
> extend.  IMHO, sub-types is an example of the type of problem 
> that is desirable to avoid.
> 
> The fact that someone has implemented an Internet Draft is 
> not a good reason to exempt the implemented features thereof 
> from IETF "change control" during the WG process.
> 
> We should be seeking the minimal-impact extensions that get 
> the job done.  So far, I have not heard compelling logic that 
> says the existing mechanisms in RADIUS and/or Diameter are 
> insufficient to accomplish the needed functionality.  Unless 
> we have demonstrably exhausted the existing attribute space, 
> and given that grouping mechanisms exist, why are sub-types 
> *needed* (as opposed to *wanted*)?
> 
> 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: Wed, 26 Nov 2003 19:53:44 +0000
Date: Wed, 26 Nov 2003 14:50:10 -0500
To: [email-masked]
From: David Mitton <[email-masked]>
Subject: RE: Subtypes

On 11/26/2003 02:01 PM -0500, Avi Lior wrote:
>First and foremost VSAs are subtypes.  RADIUS servers already have the code
>to deal with VSAs.

well, given the state of RADIUS, even that cannot be so flatly stated.

I was just debugging a customer last week, whose RADIUS proxy server could 
not handle those dang USR VSAs, because they have no internal length 
field.  And the programmer evidently didn't think to skip something at the 
attribute level it couldn't parse, because it didn't follow the recommended 
format.

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, 26 Nov 2003 19:46:11 +0000
Content-Class: urn:content-classes:message
Subject: RE: Subtypes
Date: Wed, 26 Nov 2003 14:44:18 -0500
From: "Nelson, David" <[email-masked]>
Cc: <[email-masked]>

Avi Writes...

> Not withstanding those examples.  The sterman draft which is already
> deployed uses subtypes are we going to force it to change?  (See 2.2
> Digest-Attributes attribute)

I thought the whole idea of having a WG to standardize extensions was to
avoid the sort of thing that happens when individuals, companies or
other SDOs, publish Informational RFCs that don't under go an
appropriate level of Internet community review and don't maintain
reasonable architectural consistency with the base protocol they are
attempting to extend.  IMHO, sub-types is an example of the type of
problem that is desirable to avoid.

The fact that someone has implemented an Internet Draft is not a good
reason to exempt the implemented features thereof from IETF "change
control" during the WG process.

We should be seeking the minimal-impact extensions that get the job
done.  So far, I have not heard compelling logic that says the existing
mechanisms in RADIUS and/or Diameter are insufficient to accomplish the
needed functionality.  Unless we have demonstrably exhausted the
existing attribute space, and given that grouping mechanisms exist, why
are sub-types *needed* (as opposed to *wanted*)?

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

Delivery-date: Wed, 26 Nov 2003 19:02:45 +0000
Date: Wed, 26 Nov 2003 11:01:47 -0800
To: Avi Lior <[email-masked]>, [email-masked]
From: Parviz Yegani <[email-masked]>
Subject: Re: Subtypes

At 03:55 PM 11/25/2003 -0500, Avi Lior wrote:
>During the BOF Subtypes came up again (cause I brought up the issue)
>
>The reason that I brought up the issue was because there were several Drafts
>that were using Subtypes.
>
>In one of the drafts that I was contributing, an attribute of type string
>contained sub-attributes that were encodes as attribute value pairs.  Having
>a RADIUS server decode this type of attribute is a sure way to kill RADIUS
>performance.
>
>Looking at the drafts, the reasons folks are using subtypes is to group
>attributes that only make sense together.  For example zipcode,
>streetAddress, etc in a LocationAttribute.  Or a bunch of attributes that
>reflect HTTP Digest authentication.
>
>We either disallow all subtypes period end!!! Or permit them providing they
>meet a certain set of criteria.
>
>To disallow them outright would be a problem because some of these drafts
>are already being used and some have been standerdized by other SDOs.

Yes, in 3GPP2 we've defined a dozen or more groups of subtypes. Each
subtype is used to group attributes that should go together. These are encoded
within VSAs. I agree with you and other folks that we should try to standardize
these subtypes in IETF so that we don't have to expand the attribute space to
accommodate new accounting applications.

-Parviz

>The criteria to use would be something along the line:
>
>Subtypes should follow TLV encoding.  This would allow RADIUS Servers to use
>the same code they already use to parse existing attributes.  This would
>also follow subtype encoding within VSAs.  TLV is what is being used most
>often when folks subtype.
>
>You only subtype attributes that belong together.  Typically they are going
>to be interpreted by the NAS and the RADIUS server.  Proxy's should not have
>to parse the subtypes.
>
>Comments?
>
>
>--
>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, 26 Nov 2003 19:02:16 +0000
From: Avi Lior <[email-masked]>
To: 'Bernard Aboba' <[email-masked]>, Jari Arkko <[email-masked]>
Cc: Avi Lior <[email-masked]>, [email-masked]
Subject: RE: Subtypes
Date: Wed, 26 Nov 2003 14:01:30 -0500

First and foremost VSAs are subtypes.  RADIUS servers already have the code
to deal with VSAs.

> I agree.  Since RADIUS only allows attributes of 253 octets, 
> subtypes are inherently limited in their functionality.  

I can show you tons of examples of subtypes that are useful with the
limitation of 253 octets.

Not withstanding those examples.  The sterman draft which is already
deployed uses subtypes are we going to force it to change?  (See 2.2
Digest-Attributes attribute)

I don't agree that it breaks RADIUS dictionaries in the following sense:
Only the Client and  Server that is supporting the functionality needs to
decode further than the top level attribute.

And furthermore, one can be argue that there are  efficiency gains at
intermediaries because intermediaries wouldn't have to parse the extra
sub-attributes that would materialize when we flatten the attributes.

> it is necessary to support grouping, the grouping mechanism 
> specified in RFC 2867 can be used.  If the issue is attribute 
> space and the need can be proven, we can talk about 
> expansion.  So far I don't see a requirement to change the 
> RADIUS dictionary.
> 
> On Wed, 26 Nov 2003, Jari Arkko wrote:
> 
> > I would personally prefer that we stick to the simple
> > and existing RADIUS AVP scheme. I am not convinced that
> > there is such a large number of subtypes that it would
> > have a big impact on performance if they were carried in separate 
> > AVPs.
> >
> > --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, 26 Nov 2003 17:30:57 +0000
Date: Wed, 26 Nov 2003 18:30:03 +0100
From: nagi reddy jonnala <[email-masked]>
Organization: Alcatel Telecom
To: Bernard Aboba <[email-masked]>
CC: Jari Arkko <[email-masked]>, Avi Lior <[email-masked]>, [email-masked]
Subject: Re: Subtypes

 I'm not sure how long the RADIUS will be? I guess we are somewhere
around Type-100.   It is reasonable to expect future applications that
need handful of attributes.  We wish,  we would NOT like to invent what
AAA supports. What if the market still want to use RADIUS and need
new RADIUS types?

Then, Do we say -

   i) No, we don't support
   ii) Be defensive and the question the need of support in RADIUS.

Unless we are sure that we never run out of the attribute space, I think,
we better introduce the sub-types now.

Folks might be interested to know that IS-IS protocol adopts sub-TLVs
without interoperability problems.

Comments?

-Nagi.

Otherwise
I don't really have any problems if that is decided if people really
think

Bernard Aboba wrote:

> I agree.  Since RADIUS only allows attributes of 253 octets, subtypes are
> inherently limited in their functionality.  If it is necessary to support
> grouping, the grouping mechanism specified in RFC 2867 can be used.  If
> the issue is attribute space and the need can be proven, we can talk about
> expansion.  So far I don't see a requirement to change the RADIUS
> dictionary.
>
> On Wed, 26 Nov 2003, Jari Arkko wrote:
>
> > I would personally prefer that we stick to the simple
> > and existing RADIUS AVP scheme. I am not convinced that
> > there is such a large number of subtypes that it would
> > have a big impact on performance if they were carried in
> > separate AVPs.
> >
> > --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: Wed, 26 Nov 2003 17:01:40 +0000
From: "Lila Madour (QA/EMC)" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: RE: Subtypes
Date: Wed, 26 Nov 2003 12:00:29 -0500

Hi John
please see=20
 http://www.3gpp2.org/Public_html/specs/index.cfm#tsgx
click on X.S0011-005-C v1.0 (cdma2000=AE Wireless IP Network Standard: =
Accounting Services and 3GPP2 RADIUS VSAs) chapter.

Lila
-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, November 26, 2003 11:54 AM
To: Lila Madour (QA/EMC)
Cc: [email-masked]
Subject: RE: Subtypes

Hi Lila,

> The 3GPP2 "published" specifications support grouping some of=20
> the RADIUS attributes into subtypes that make sense together.
> An example of the features already standaridzed in 3GPP2=20
> which uses this practice include but not limited to prepaid.=20
> Given that this practice has already been standardized=20
> outside IETF, and in use, this WG shouldn't disallow it.=20

Could you send a pointer to the 3GPP2 specs that have this?
I'd like to see what they are doing.

thanks,
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, 26 Nov 2003 16:54:54 +0000
From: Greg Weber <[email-masked]>
Subject: Re: Subtypes
To: [email-masked] ("Lila Madour (QA/EMC)")
Date: Wed, 26 Nov 2003 11:54:08 -0500 (EST)
Cc: [email-masked] ('Bernard Aboba'), [email-masked] (Jari Arkko), [email-masked] (Avi Lior), [email-masked]

I think we need to make a distinction between VSAs
and standard attributes.  We don't seem to be using
a common lexicon here.  Perhaps we need a definition
of 'subtype' as used in the proposed charter.

Greg

> 
> The 3GPP2 "published" specifications support grouping some of the RADIUS attributes into subtypes that make sense together.
> An example of the features already standaridzed in 3GPP2 which uses this practice include but not limited to prepaid. 
> Given that this practice has already been standardized outside IETF, and in use, this WG shouldn't disallow it. 
> Lila 
> 
> 
> --
> 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, 26 Nov 2003 16:54:47 +0000
content-class: urn:content-classes:message
Subject: RE: Subtypes
Date: Wed, 26 Nov 2003 18:54:10 +0200
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>

Hi Lila,

> The 3GPP2 "published" specifications support grouping some of=20
> the RADIUS attributes into subtypes that make sense together.
> An example of the features already standaridzed in 3GPP2=20
> which uses this practice include but not limited to prepaid.=20
> Given that this practice has already been standardized=20
> outside IETF, and in use, this WG shouldn't disallow it.=20

Could you send a pointer to the 3GPP2 specs that have this?
I'd like to see what they are doing.

thanks,
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, 26 Nov 2003 16:48:52 +0000
Date: Wed, 26 Nov 2003 17:48:01 +0100
From: nagi reddy jonnala <[email-masked]>
Organization: Alcatel Telecom
To: Bernard Aboba <[email-masked]>
CC: Jari Arkko <[email-masked]>, Avi Lior <[email-masked]>, [email-masked]
Subject: Re: Subtypes

I think it is RFC-2868, Section 3.1 Grouping mechanism using the
Tag field.

Right?

Bernard Aboba wrote:

> I agree.  Since RADIUS only allows attributes of 253 octets, subtypes are
> inherently limited in their functionality.  If it is necessary to support
> grouping, the grouping mechanism specified in RFC 2867 can be used.  If
> the issue is attribute space and the need can be proven, we can talk about
> expansion.  So far I don't see a requirement to change the RADIUS
> dictionary.
>
> On Wed, 26 Nov 2003, Jari Arkko wrote:
>
> > I would personally prefer that we stick to the simple
> > and existing RADIUS AVP scheme. I am not convinced that
> > there is such a large number of subtypes that it would
> > have a big impact on performance if they were carried in
> > separate AVPs.
> >
> > --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: Wed, 26 Nov 2003 16:46:46 +0000
From: "Lila Madour (QA/EMC)" <[email-masked]>
To: "'Bernard Aboba'" <[email-masked]>, Jari Arkko <[email-masked]>
Cc: Avi Lior <[email-masked]>, [email-masked]
Subject: RE: Subtypes
Date: Wed, 26 Nov 2003 11:44:16 -0500

The 3GPP2 "published" specifications support grouping some of the RADIUS attributes into subtypes that make sense together.
An example of the features already standaridzed in 3GPP2 which uses this practice include but not limited to prepaid. 
Given that this practice has already been standardized outside IETF, and in use, this WG shouldn't disallow it. 
Lila 

--
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, 26 Nov 2003 15:47:00 +0000
Date: Wed, 26 Nov 2003 08:05:51 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: Jari Arkko <[email-masked]>
cc: Avi Lior <[email-masked]>, [email-masked]
Subject: Re: Subtypes

I agree.  Since RADIUS only allows attributes of 253 octets, subtypes are
inherently limited in their functionality.  If it is necessary to support
grouping, the grouping mechanism specified in RFC 2867 can be used.  If
the issue is attribute space and the need can be proven, we can talk about
expansion.  So far I don't see a requirement to change the RADIUS
dictionary.

On Wed, 26 Nov 2003, Jari Arkko wrote:

> I would personally prefer that we stick to the simple
> and existing RADIUS AVP scheme. I am not convinced that
> there is such a large number of subtypes that it would
> have a big impact on performance if they were carried in
> separate AVPs.
>
> --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, 26 Nov 2003 09:12:41 +0000
Date: Wed, 26 Nov 2003 11:07:36 +0200
From: Jari Arkko <[email-masked]>
Reply-To: [email-masked]
Organization: None
To: Avi Lior <[email-masked]>
Cc: [email-masked]
Subject: Re: Subtypes

I would personally prefer that we stick to the simple
and existing RADIUS AVP scheme. I am not convinced that
there is such a large number of subtypes that it would
have a big impact on performance if they were carried in
separate AVPs.

--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, 25 Nov 2003 21:52:54 +0000
Content-Class: urn:content-classes:message
Subject: RE: Subtypes
Date: Tue, 25 Nov 2003 13:52:26 -0800
From: "Adrangi, Farid" <[email-masked]>
To: "Avi Lior" <[email-masked]>, <[email-masked]>

I think allowing use of subtypes is a good thing, in particular for
grouping attributes that only makes sense together.  We should reach
consensus (whether or not it is allowed) on this very soon as we are
currently working on revised version of our documents.  It would also be
nice to have a short draft describing the format of subtype as a
reference.
BR,
Farid

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Avi Lior
Sent: Tuesday, November 25, 2003 12:55 PM
To: [email-masked]
Subject: Subtypes

During the BOF Subtypes came up again (cause I brought up the issue)

The reason that I brought up the issue was because there were several
Drafts
that were using Subtypes.

In one of the drafts that I was contributing, an attribute of type
string
contained sub-attributes that were encodes as attribute value pairs.
Having
a RADIUS server decode this type of attribute is a sure way to kill
RADIUS
performance.

Looking at the drafts, the reasons folks are using subtypes is to group
attributes that only make sense together.  For example zipcode,
streetAddress, etc in a LocationAttribute.  Or a bunch of attributes
that
reflect HTTP Digest authentication.

We either disallow all subtypes period end!!! Or permit them providing
they
meet a certain set of criteria.

To disallow them outright would be a problem because some of these
drafts
are already being used and some have been standerdized by other SDOs.

The criteria to use would be something along the line:

Subtypes should follow TLV encoding.  This would allow RADIUS Servers to
use
the same code they already use to parse existing attributes.  This would
also follow subtype encoding within VSAs.  TLV is what is being used
most
often when folks subtype.

You only subtype attributes that belong together.  Typically they are
going
to be interpreted by the NAS and the RADIUS server.  Proxy's should not
have
to parse the subtypes.

Comments?

--
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, 25 Nov 2003 20:55:51 +0000
From: Avi Lior <[email-masked]>
To: [email-masked]
Subject: Subtypes
Date: Tue, 25 Nov 2003 15:55:22 -0500

During the BOF Subtypes came up again (cause I brought up the issue)

The reason that I brought up the issue was because there were several Drafts
that were using Subtypes.

In one of the drafts that I was contributing, an attribute of type string
contained sub-attributes that were encodes as attribute value pairs.  Having
a RADIUS server decode this type of attribute is a sure way to kill RADIUS
performance.

Looking at the drafts, the reasons folks are using subtypes is to group
attributes that only make sense together.  For example zipcode,
streetAddress, etc in a LocationAttribute.  Or a bunch of attributes that
reflect HTTP Digest authentication.

We either disallow all subtypes period end!!! Or permit them providing they
meet a certain set of criteria.

To disallow them outright would be a problem because some of these drafts
are already being used and some have been standerdized by other SDOs.

The criteria to use would be something along the line:

Subtypes should follow TLV encoding.  This would allow RADIUS Servers to use
the same code they already use to parse existing attributes.  This would
also follow subtype encoding within VSAs.  TLV is what is being used most
often when folks subtype.

You only subtype attributes that belong together.  Typically they are going
to be interpreted by the NAS and the RADIUS server.  Proxy's should not have
to parse the subtypes.

Comments?

--
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, 13 Nov 2003 22:25:25 +0000
Date: Thu, 13 Nov 2003 13:46:55 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Slides?

The slides for tommorrow's RADEXT BOF are available here:

http://www.drizzle.com/~aboba/IETF58/RADEXT.zip

If your slides are not included in this package, please get them in NOW.

--
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, 13 Nov 2003 15:54:57 +0000
content-class: urn:content-classes:message
Subject: RE: On the other hand...
Date: Thu, 13 Nov 2003 17:54:38 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Richard,

> If a business introduces a new product and the customers seem to =
prefer, or
> even demand the old one (remember "New" Coke) a smart business manager
> follows the market lead.

Perhaps the IETF will be a 'business' in the future (obtuse reference to
last nights plenary), but right now, I don't see the IETF's operation in =

this manner.=20

> If the IETF were to design a "New" protocol designed to update and =
replace
> an older one and people still wanted to stay with the older one, for
> whatever reasons, would the IETF ever simply say "we may have made a
> mistake."

SNMPv2 vs SNMPv3, anyone?

> I don't propose to know what the metrics of acceptance or rejection of =
a
> protocol are, but we certainly cannot believe that a standards body, =
even
> the IETF, is above the possibility of error and that we would never
> introduce a turkey of an RFC.

See above.

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, 13 Nov 2003 04:41:38 +0000
Date: Wed, 12 Nov 2003 20:41:25 -0800
Subject: On the other hand...
From: Richard Perlman <[email-masked]>
To: <[email-masked]>

If a business introduces a new product and the customers seem to prefer, or
even demand the old one (remember "New" Coke) a smart business manager
follows the market lead.

If the IETF were to design a "New" protocol designed to update and replace
an older one and people still wanted to stay with the older one, for
whatever reasons, would the IETF ever simply say "we may have made a
mistake."

I don't propose to know what the metrics of acceptance or rejection of a
protocol are, but we certainly cannot believe that a standards body, even
the IETF, is above the possibility of error and that we would never
introduce a turkey of an RFC.

Don't take this as an obtuse suggestion that the RADIUS-EXT BOF should be
directed any differently than it is now.  But, we should keep our eyes open
and stay tuned-in to what gets built, implemented AND installed in the AAA
world.  The fastest way to extinction is to ignore a changing environment.

See y'all on Friday

Richard

--
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, 13 Nov 2003 04:05:19 +0000
content-class: urn:content-classes:message
Subject: RE: Why RADIUS-EXT BOF???
Date: Thu, 13 Nov 2003 06:05:12 +0200
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>

Hi Bernard,

> > Would it be reasonable for the IETF to make some determination that
> > if RADIUSext proposes enough changes to RADIUS to require new
> > implementations of RADIUSext protocols, that we should just throw
> > in the towel and use Diameter?
>=20
> So far, major protocol changes are not within scope of the RADEXT =
effort,
> and I haven't heard a lot of objections to that.  The need seems to be =
for
> some new attributes, a best current practice doc on prepaid, and some
> transport clarifications.  There have been more substantial changes
> proposed (changes to the dictionary, expansion in the attribute space,
> standardization of failover, new commands, etc.) but so far no one has
> stood up and said "I will implement this and have customers who will
> deploy it if the IETF develops it."
>=20
> That's somewhat understandable because RADIUS has been shipping for =
quite
> a while and most vendors have worked around these issues in one way or =
the
> other.  They may therefore have difficulty justifying a =
re-implementation
> of functionality that has already been available to customers.

That sounds like a reasonable scope to put on the bof.

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, 13 Nov 2003 04:04:23 +0000
Date: Wed, 12 Nov 2003 19:25:44 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: Why RADIUS-EXT BOF???

On Thu, 13 Nov 2003 [email-masked] wrote:

> Would it be reasonable for the IETF to make some determination that
> if RADIUSext proposes enough changes to RADIUS to require new
> implementations of RADIUSext protocols, that we should just throw
> in the towel and use Diameter?

So far, major protocol changes are not within scope of the RADEXT effort,
and I haven't heard a lot of objections to that.  The need seems to be for
some new attributes, a best current practice doc on prepaid, and some
transport clarifications.  There have been more substantial changes
proposed (changes to the dictionary, expansion in the attribute space,
standardization of failover, new commands, etc.) but so far no one has
stood up and said "I will implement this and have customers who will
deploy it if the IETF develops it."

That's somewhat understandable because RADIUS has been shipping for quite
a while and most vendors have worked around these issues in one way or the
other.  They may therefore have difficulty justifying a re-implementation
of functionality that has already been available to customers.

--
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, 13 Nov 2003 03:47:01 +0000
content-class: urn:content-classes:message
Subject: RE: Why RADIUS-EXT BOF???
Date: Thu, 13 Nov 2003 05:46:53 +0200
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>

Dean,

> Yes, DIAMETER will eventually be used in many of these roles, but it=20
> will come in as a part of new deployments, and won't displace existing =

> RADIUS systems   for several years after its availability. In the=20
> meantime, there are requests to authenticate.

Would it be reasonable for the IETF to make some determination that
if RADIUSext proposes enough changes to RADIUS to require new
implementations of RADIUSext protocols, that we should just throw
in the towel and use Diameter?

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, 13 Nov 2003 03:42:25 +0000
Date: Wed, 12 Nov 2003 21:41:14 -0600
From: Dean Willis <[email-masked]>
To: [email-masked]
CC: "'Richard Perlman'" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Why RADIUS-EXT BOF???

> Unfortunately, neither Bernard's reply nor any of the discussion of
> which I'm aware actually answers the question posed, which is
> (paraphrased but correctly) "Why is the IETF (IESG) apparently
> intentionally working to delay the deployment of Diameter?".  To say
> that 'Well, people were working on RADIUS' w/o discussing the reasons
> behind that work is just blowing smoke.  Having been involved in the
> work of at least a couple of the SDOs/trade organizations referred to
> (3GPP2 & WECA), I know that the reason for the work being done was _not_
> the magnificence of RADIUS but the interminable delays in the
> standardization of Diameter.  Since those delays were largely due to
> IESG actions (or lack thereof), we seem to be wandering a hall of
> mirrors rather than in engaging in honest inquiry.

Of course, it COULD also have something to do with the fact that we 
(tthe set of people currently running RADIUS) have several hundred 
million subscribers being happily authenticated using RADIUS systems 
that are stably deployed and mostly payed for, and are hesitant to throw 
out known working systems and replace them with new, untried, and 
expensive systems just to gain the dubious advantage of authenticating 
users of a new access protocol that may or may not take off.

Or it could just be that we're confused by the excessively long 
sentences I spew out.

Yes, DIAMETER will eventually be used in many of these roles, but it 
will come in as a part of new deployments, and won't displace existing 
RADIUS systems   for several years after its availability. In the 
meantime, there are requests to authenticate.

--
Dean

--
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, 10 Nov 2003 14:52:16 +0000
Date: Mon, 10 Nov 2003 06:13:58 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: REQUEST: Slides for RADEXT BOF

If you're presenting at the RADEXT BOF, please send me slides ASAP.  The
timeslot is very full, and so we'd like to have all the slides loaded
beforehand.

--
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, 09 Nov 2003 06:24:56 +0000
Reply-To: <[email-masked]>
From: "Glen Zorn" <[email-masked]>
To: "'Richard Perlman'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: Why RADIUS-EXT BOF???
Date: Sat, 8 Nov 2003 22:23:58 -0800
Organization: Cisco Systems

[email-masked] <mailto:[email-masked]>
writes:

> Phil:
> 
> In addition to reading Bernard's well written reply, you should
> probably also read the archives of this list to see the lengthily
> discussion (including the question you have posed) that has already
> taken place. 

Unfortunately, neither Bernard's reply nor any of the discussion of
which I'm aware actually answers the question posed, which is
(paraphrased but correctly) "Why is the IETF (IESG) apparently
intentionally working to delay the deployment of Diameter?".  To say
that 'Well, people were working on RADIUS' w/o discussing the reasons
behind that work is just blowing smoke.  Having been involved in the
work of at least a couple of the SDOs/trade organizations referred to
(3GPP2 & WECA), I know that the reason for the work being done was _not_
the magnificence of RADIUS but the interminable delays in the
standardization of Diameter.  Since those delays were largely due to
IESG actions (or lack thereof), we seem to be wandering a hall of
mirrors rather than in engaging in honest inquiry.

Q: Why are you trying to delay Diameter deployment?
A: People have been working on RADIUS.
Q: Why did they have to change RADIUS?
A: We delayed the standardization (and thus deployment) of Diameter.

> 
>> archive: http://psg.com/lists/radiusext/
> 
> Richard
> 
> On 11/5/03 09:51, "[email-masked]"
> <[email-masked]> wrote: 
> 
>> Hi folks,
>> 
>> I know I am late to this discussion, however why pursue RADIUS
>> extensions when:
>> 
>> A).  Diameter has RFC's popping
>> B).  Diameter solves most the serious issues with RADIUS
>> C).  The Diameter designers strived to be backward compatible with
>> RADIUS 
>> 
>> The existence of this BOF, and any WG that results, will just further
>> delay the wide scale deployment of Diameter which is clearly
>> preferable. 
>> 
>> Please let me know why?
>> 
>> Thanks,
>> 
>> Phil Neumiller

Hope this helps,

~gwz

"They that can give up essential liberty to obtain a little temporary
safety deserve neither..." 
-- Benjamin Franklin, 1759

"It is forbidden to kill; therefore all murderers are punished unless
they kill in large numbers and to the sound of trumpets." 
-- Voltaire

--
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, 06 Nov 2003 00:02:28 +0000
Date: Wed, 05 Nov 2003 16:01:47 -0800
Subject: Re: Why RADIUS-EXT BOF???
From: Richard Perlman <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Phil:

In addition to reading Bernard's well written reply, you should probably
also read the archives of this list to see the lengthily discussion
(including the question you have posed) that has already taken place.

> archive: http://psg.com/lists/radiusext/

Richard

On 11/5/03 09:51, "[email-masked]"
<[email-masked]> wrote:

> Hi folks,
> 
> I know I am late to this discussion, however why pursue RADIUS extensions
> when:
> 
> A).  Diameter has RFC's popping
> B).  Diameter solves most the serious issues with RADIUS
> C).  The Diameter designers strived to be backward compatible with RADIUS
> 
> The existence of this BOF, and any WG that results, will just further delay
> the
> wide scale deployment of Diameter which is clearly preferable.
> 
> Please let me know why?
> 
> Thanks,
> 
> Phil Neumiller

--
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, 05 Nov 2003 19:07:43 +0000
Date: Wed, 5 Nov 2003 10:29:33 -0800 (PST)
From: Bernard Aboba <[email-masked]>
To: [email-masked]
Subject: Why a RADEXT BOF?

Recently I was asked what the purpose of the RADEXT BOF is... and how we
can measure success.

The RADEXT BOF was started as the result of a dinner that we had at IETF
57, where draft authors described their ongoing RADIUS work.  Attendees
also included representatives from SDOs such as 3GPP2 and IEEE 802 as well
as trade associations such as WFA.  The ongoing work was surprisingly
extensive and if anything was accelerating.

It became apparent that RADIUS standards work had not stopped when the
IETF RADIUS WG ended;  rather it moved outside the IETF. In addition to
defining new attributes (some of which were duplicative), SDOs were also
defining new RADIUS commands, sometimes by requesting allocation
of attribute values defined as "First Come First Served" in RFC
2865.

Furthermore, IETF WGs such as PPVPN and SIPPING were expressing interest
in doing their own RADIUS extensions. Given all the activity, it became
apparent that the IETF needed a plan for managing RADIUS-related work.
"Just say no" wasn't working any more, and the IESG was becoming concerned
over the increasing number of RADIUS-related individual submissions
looking to be published as RFCs.

The dinner at IETF 57 and the RADEXT BOF are efforts to understand
the potential scope of a RADIUS repatriation effort -- bringing RADIUS
work which had been done within SDOs and trade associations back into the
IETF.

"Fixing" RADIUS is outside the scope.  Major protocol changes
are out of scope -- RADIUS is far too widely deployed at this
point. Accounting reliability would be likely to require major protocol
changes, and so is also probably out of scope.  Changes to the dictionary,
running over new transports, changes to the attribute format,
etc. are also out of scope.

As I see it, the goal of a RADEXT BOF is to understand the minimum work
required to satisfy existing IETF WGs, SDOs and trade associations that
plan additional RADIUS-related work.  Success is measured by the timely production
of documents satisfying the needs of these SDOs, trade associations and
IETF WGs.

--
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, 05 Nov 2003 17:51:06 +0000
Subject: Why RADIUS-EXT BOF???
To: [email-masked]
From: [email-masked]
Date: Wed, 5 Nov 2003 12:51:31 -0500

Hi folks,

I know I am late to this discussion, however why pursue RADIUS extensions
when:

A).  Diameter has RFC's popping
B).  Diameter solves most the serious issues with RADIUS
C).  The Diameter designers strived to be backward compatible with RADIUS

The existence of this BOF, and any WG that results, will just further delay
the
wide scale deployment of Diameter which is clearly preferable.

Please let me know why?

Thanks,

Phil Neumiller

--
"NOTICE:  The information contained in this electronic mail transmission is
intended by Convergys Corporation for the use of the named individual or
entity to which it is directed and may contain information that is
privileged or otherwise confidential.  If you have received this electronic
mail transmission in error, please delete it from your system without
copying or forwarding it, and notify the sender of the error by reply email
or by telephone (collect), so that the sender's address records can be
corrected."

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