[radext] Re: New I-D: draft-seralathan-radext-persistent-devid-00

["Premanand Seralathan (pseralat)" <[e-mail]>]

A prefix convention in Class could work mechanically, but has a few practical issues:

  1.  As you noted, some NAS products don't support multiple Class attributes. Class is already widely used for policy names, VLAN tags, billing codes, etc. In those deployments there's no room for a device ID without displacing existing usage.

  2.  A "devid:" prefix is an ad-hoc convention -- every consuming system (profiling engine, SIEM, compliance) would need to know to parse Class values looking for the prefix. A defined attribute with IANA registration gives interoperability without per-deployment conventions.

  3.  Class is opaque by specification - RFC 2865 says implementations "SHOULD NOT attempt to interpret" it. Requiring systems to parse and interpret Class content works against this.

That said, these are fair points. We'll add a discussion in -01 covering Class as an alternative and why we chose a separate attribute.


Thanks

Prem


From: Alan DeKok <alan.dekok=[e-mail]>
Date: Tuesday, May 26, 2026 at 4:58 AM
To: Alexander Clouter <alex=2Bietf=[e-mail]>
Cc: Premanand Seralathan (pseralat) <[e-mail]>; [e-mail] <[e-mail]>
Subject: [radext] Re: New I-D: draft-seralathan-radext-persistent-devid-00

On May 26, 2026, at 7:20 AM, Alexander Clouter <alex=2Bietf=[e-mail]> wrote:
> Section 2.3 of the draft is wrong in stating Class is unsuitable as it is not stable, the value is determined by the RADIUS server so can be set to whatever you want.
>
> This could be solved by using a prefix (for example 'devid:') to colour your device ID value and extract it from the accounting data.

  TBH, that's likely the best solution.

  Some NAS products don't support multiple Class attributes.  But it's likely easier to add support for that, instead of adding an entirely new attribute.

  Alan DeKok.