Re: [radext] Extended IDs

Alan DeKok <aland@deployingradius.com> Wed, 19 April 2017 01:54 UTC

Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alan DeKok <aland@deployingradius.com>
In-Reply-To: <6c0d923f-d27d-16f7-c1bc-65c96b98f228@cisco.com>
Date: Tue, 18 Apr 2017 21:54:47 -0400
Cc: radext@ietf.org, Naiming Shen <naiming@cisco.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <45205539-2F5B-4512-A40E-EF6B28E1A6A3@deployingradius.com>
References: <361AC9F2-4CFE-46D5-A893-CBEDAFFA85B8@deployingradius.com> <af16dfe3-f134-0478-6a02-f73699ecdb02@cisco.com> <1767D4FB-29BB-4E91-9339-1B40F3D3FC91@deployingradius.com> <6c0d923f-d27d-16f7-c1bc-65c96b98f228@cisco.com>
To: Enke Chen <enkechen@cisco.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/radext/DRHNW85p7TeHKRPL-lUDrpvYyWk>
Subject: Re: [radext] Extended IDs
Precedence: list

On Apr 18, 2017, at 8:52 PM, Enke Chen <enkechen@cisco.com> wrote:
> That is a different protocol :-) For better or worse RADIUS is not going away in
> enterprise anytime soon.

  What I mean is that extending the Code space has already been done in Diameter.  There is no need to do it in RADIUS.  Even worse, if there *is* a need to do it in RADIUS, the answer should be "don't do it, just use Diameter".

>>  The issue is solving one problem at a time.  There is no *current* need to extend
>>  the Code space.  Therefore, there shouldn't be a proposal to extend it.
> 
> I have to disagree. I do not see any benefits with the piecemeal approach in this
> case. 

  It's about doing what's necessary.  It's not necessary to extend the Code space at this time.  Therefore, it shouldn't be done.

> There are tradeoffs. The question is, do we really want to burn another attribute
> when one can do?  I would think that we want to preserve the attribute space and
> learn from the past.

  My $0.02 is that a simpler approach will work just as well.

> "minor" vs "major" is just opinion, right?  Also is there some IETF rule that
> states that a particular field can not be touched (even when needed), especially
> when it is done in a backward compatible way?

  It's at least convention.  I've had enough discussion with people that I think there is wide-spread consensus that major changes to RADIUS won't be approved.

> I think that we will be better served if we just speak for ourselves (instead of
> for someone else or IESG), and stay on the technical issues.

  I've given my technical review of the document.

> Again, you consider this ID enlargement as "major", and I do not, but that does not
> really matter. RADIUS is not going away anytime soon, and we have to keep addressing
> issues we face.  I guess that is the reason this WG still exists.

  Yes... that's not my point.  My point is that we've been patching RADIUS in minor ways for a long time now.  That's unpleasant, but part of real-world engineering.

  Major changes to RADIUS have wide-spread opposition in the IETF.  You don't need to convince me that the changes will be OK.  You need to convince everyone else.

  Alan DeKok.