Re: [radext] Extended IDs

[Alan DeKok <[e-mail]>]

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".  :(

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

>> 
>> * 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.

>> * 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.

> 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". :(

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

  Alan DeKok.