Re: [radext] Extended IDs

[Enke Chen <[e-mail]>]

Hi, Alan:

On 4/18/17 5:16 PM, Alan DeKok wrote:
> On Apr 18, 2017, at 6:47 PM, Enke Chen <[e-mail]> wrote:
>> Out of 255 numbers for the Packet Type Codes, 52 are currently allocated.  Given
>> the popularity of RAIDUS, this number space may run out in the future.
> 
>   That's called "Diameter".  :(

That is a different protocol :-) For better or worse RADIUS is not going away in
enterprise anytime soon.

> 
>> Although the Code field does not have to be enlarged together with the Identifier
>> field, it just makes sense to do them together so that we go through the changes
>> once and be done with it.  There is little additional cost (in terms of development,
>> memory and transmission) to cover the Code field, and its usage is optional until
>> needed.
> 
>   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. 

> 
>>>
>>> * The "status" field should similarly be removed from the document.  Instead,
>>>  just the presence of the attribute in a reply should be good enough.
>>
>> Without the "status" field, we are afraid that some implementation may just send
>> back the unrecognized attribute.  The field would certainly help make it more
>> explicit and deterministic about whether the feature is supported by a device.
> 
>   I think it's safe to say that servers don't "echo" back attributes.
> 
>   If you need an explicit ACK, create one.  Don't overload the contents of an attribute.
>   See RFC 6929 Section 6.3 for guidelines on using Complex Data Types.

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.

> 
>>> * using the 4-octet identifier *instead of* the normal ID means the protocol
>>>  is being changed, this cannot be done.
>>
>> I am not sure what you mean by the statement "the protocol is being changed, 
>> this cannot be done".
>>
>> You seem to mean that "such change is not allowed"?  If that is correct, then I
>> am wondering what basis you have (other than personal opinion) for such a position.
>> If there exists some official IETF rules that I am not aware of, please let me know.
> 
>   I mean that modifying RADIUS in minor ways is probably OK.  Changing the base
>   RADIUS protocol is not.
> 
>   Making clients and servers change the meaning and interpretation of the ID field
>   is changing RADIUS.  I don't think you will get consensus from RADEXT, much less
>   the IESG for this proposal.

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

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 have been involved in IETF (mostly in the routing area) for more than 20 years.
>> AFAIK, any extension to an existing protocol is a change to the protocol, and such
>> changes have been made and continue to be made all the time, and some by you in
>> this radext working group :-) 
> 
>   Sure.  Except that *major* changes to RADIUS are called "Diameter". :(

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.

> 
>> AFAIK, the RADIUS standard does not specify how the IDs are allocated, and that is
>> completely left to the implementation and as a local matter on the sender.
>>
>> IMO deviation from such well-established practice will be challenging for backward
>> compatibility and deployment.
> 
>    It's no more challenging than your proposal to replace the ID field entirely.
> 
>> In addition, following the current RADIUS practice it remains an implementation
>> decision how this new 4 bytes "ID" field is allocated.  However, I do not see any
>> value for combining this new 4-byte "ID" field with the existing one-byte "ID"
>> field and using them both.
> 
>   There is likely no technical value.  The issue is any change requires consensus
>   from RADEXT and IESG, which means the changes must be *percieved* to be minor
>   extensions to RADIUS.

Our experiences may differ. My experience with IETF has been quite positive regarding
addressing real world issues and making progress.  No religious, and no kings, and
"Rough consensus and running code" have got us this far.  But that is probably off
topic.

Thanks.   -- Enke