Subject: RE: (radius) Re: draft-chiba-radius-dynamic-disconnect-00.txt

From: "Claudio Lapidus" <[email-masked]>
Date: Fri, 01 Feb 2002 14:21:39 -0300

"Glen Zorn" <[email-masked]> wrote:

>Note that I have no problem with _documenting_ proprietary hacks (viz. RFC
>2433, RFC 2637,... ;-), esp. if interoperability is improved by doing so,
>but _standardizing_ them is another question entirely.  Furthermore, as
>Bernard pointed out, this is a _major_ modification to the RADIUS protocol,
>a protocol that is in the process of being superceded by another which
>includes this capability as a native feature.

I agree with you that standardizing propietary extensions is a delicate 
issue, but perhaps there is something to gain in adding them with "OPTIONAL" 
level of compliance (per RFC 2119), thus guaranteeing interoperability with 
earlier implementations that, of course, do not implement the extension. 
IMHO, the fact is that this particular feature is very useful in a number of 
environments, and also that RADIUS has been rather aged by the evolution of 
technology. Perhaps giving the extension standard status would influence 
vendors to implement it more broadly, something I think would be beneficial 
for all of us.

It is also true that DIAMETER already includes this as native, but there are 
a very large number of RADIUS implementations out there, and it seems to me 
that it would be much faster for them to include the proposed extension as 
an additional feature than the time it will take for all of them to adopt 
DIAMETER as primary AAA protocol.

regards,
cl.

_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx

-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

---

From: "Nelson, David" <[email-masked]>
Date: Fri, 1 Feb 2002 14:02:15 -0500

Claudio Lapidus writes...

>DIAMETER as primary AAA protocol.

That's probably true, at least in some cases.  It is a Good Thing (tm), 
though?  Given that RADIUS has some substantial deficiencies, ought we not 
to spend our collective efforts moving on to the successor protocol?  There
was a proposal in the AAA WG to standardize an improved RADIUS, but that was

rejected in favor of standardizing Diameter.  Sometimes having two standard
protocols to solve a problem is less desirable than having one (good one). 

Regards,

Dave

David B. Nelson, Software Architect
Enterasys Networks, Inc.
50 Minuteman Road
Andover, MA 01801-1008
Phone: (978) 684-1330  FAX: (978) 684-1368
E-mail: [email-masked]

---

From: "Ashwin Palekar" <[email-masked]>
Date: Fri, 1 Feb 2002 14:20:41 -0800

Additional comments/questions:

1. Is the list of attributes that can be used for identification limited
in any way to UserID and SessionID? For example, Is it possible to
disconnect by using Calling-Station-ID (could be mac-address in 802.1x).

2. Might be better to have 1 draft for change filter(+ replymessage &
others) 
 and disconnect so that we do not have to come up with new packet 
 types.

-----Original Message-----
From: Bernard Aboba [mailto:[email-masked]] 
Sent: Friday, February 01, 2002 9:48 AM
To: Ignacio Goyret
Cc: David Mitton; Ashwin Palekar; [email-masked]
Subject: RE: (radius) Re: draft-chiba-radius-dynamic-disconnect-00.txt

> The mechanism is a well known and established common mechanism 
> implemented by several different vendors, beyond the original vendor. 
> If that doesn't qualify as de-facto "standard", I don't know what 
> does.
> 
> AFAIC, it won't change the world whether this draft is published as an

> informational or standard track.

Question: is the functionality implemented *exactly* the same way by
multiple vendors? In other words, has interoperability been
demonstrated? Who are the vendors who can interoperate with it? 

-