Version consistency checks (v3.0.x and master)

Bjørn Mork bjorn at
Thu Jan 30 16:24:30 CET 2014

Arran Cudbard-Bell <a.cudbardb at> writes:
> On 29 Jan 2014, at 13:35, Bjørn Mork <bjorn at> wrote:
>> Arran Cudbard-Bell <a.cudbardb at> writes:
>>> I'm guessing the majority of versioning issues before were caused 
>>> by people copying over old raddb/dictionary files into a new 3.0.0
>>> config so it picked up the wrong dictionaries.
>> I'd say supporting old dictionaries is crucial, given that you do mass
>> attribute renaming like this
> Changes on that scale are only done during major releases, which occur
> once every 4-5 years.

I could be wrong, but I don't think renaming on that scale has ever been
done before?

> That change was made to master. master (the next major release branch)
> != v3.0.x (the current major release branch)
> There was a less disruptive commit made for the erx/unisphere to
> v3.0.x which did not break compatibility.

Yes, I know.

> I believe i've mentioned this already, in which case you're being an
> ass.

Didn't mean to be...  It was just a striking example of why you should
both expect and support copying over old raddb/dictionary files.

> The alternative is that vendor documentation moves away from the
> dictionaries. This makes it harder for new users to create working
> configurations.

Yes, this has become more and more clear as time went by and the ERX
platform evolved. And then, when we thought that it had finally reached
it's end-of-life, the vendor-id and VSAs were reused for BRAS services
running on JUNOS...

In retrospect, there is no doubt that the initial renaming of the
"Unisphere-" attributes to "ERX-" was a big mistake. But at that point
we had just seen Redstone become Unisphere, and further company and
marketing name changes were not unlikely at all (and as you know,
Juniper bought Unisphere less than a year later).  The "ERX" name seemed
more likely to stick than anything else. But who imagined that we would
be using ERXes 13 years later, and that the JUNOS boxes we're replacing
the ERXes with are using the same "ERX" VSAs?  Not me, at least...

Anyway, I don't object to the renaming at all.  It's good to finally
have this cleaned up, as long as we can choose *when* we want to switch
dictionaries independently of switching FreeRADIUS versions.  But I will
object if you make incompatible dictionary format changes at the same

> If there was a major change in the format, a tool would be included to
> automate conversion.

Such a tool will of course be necessary to migrate private dictionaries.
But please don't mix attribute renaming with format changes.  That's
just not necessary.


More information about the Freeradius-Devel mailing list