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

From: "Glen Zorn" <[email-masked]>
Date: Thu, 31 Jan 2002 21:36:44 -0800

Randy Bush [mailto:[email-masked]] writes:

> > Here's the quote from section 6.2 of RFC 2865:
> > 
> > "Packet Type Coes have a range from 1 to 254, of which 1-5, 11-13 have
> > been allocated. Because a new Packet Type has considerable impact on 
> > interoperability, a new Packet Type Code requires Standards Action, and
> > should be allocated starting at 14."
> 
> given the above, what do the authors wish to do with this document?
> 
> and, if the authors were to propose this as a standards action, would
> anyone on this list think that technical objections might be raised?

Yes.

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

---

From: Randy Bush <[email-masked]>
Date: Thu, 31 Jan 2002 21:41:30 -0800

>> anyone on this list think that technical objections might be raised?

and, just to speculate, what technical objections do you think might be
raised.

randy
-

---

From: "Glen Zorn" <[email-masked]>
Date: Thu, 31 Jan 2002 22:20:24 -0800

> and, just to speculate, what technical objections do you think might be

Well, purely speculating, I might guess that some people might not
appreciate the standardization of what is basically a proprietary hack.
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.

-

---

From: David Mitton <[email-masked]>
Date: Fri, 01 Feb 2002 09:58:37 -0500

Sorry, I'm at a disavantage here.  I've fallen off the RADIUS list and I 
cannot find the archives yet.  So I haven't seen Bernard's message that 
Glen is referring to.

>appreciate the standardization of what is basically a proprietary hack.

Implemented by several vendors for several years now, but what the heck...

>but _standardizing_ them is another question entirely.

Well this was the AD's suggestion...

>  Furthermore, as

except that many implementations already have it...
and the code space has worked around it.

I'm not really disaggreeing, but I don't think it's that big a deal either.

Dave.

-

---

From: Ignacio Goyret <[email-masked]>
Date: Fri, 01 Feb 2002 09:51:33 -0800

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.

-

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 1 Feb 2002 09:48:13 -0800 (PST)

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

-