Question on new dictionaries & values
G'day I've been pondering a bit on the different dictionnaries and hope to provide some new. I understand that modifying/renaming old values can be is putting at risk current setups current setups, however new ones are easier to add :-) What is the current consenscus on tha Attribute naming. I've learned that underline usage isn't appreciated even though some vendors use it. VENDOR foovendor <id> a) ATTRIBUTE foovendor-name-by-vendor-doc... b) ATTRIBUTE name-by-vendor-doc... I've seen both in usage but mostly consistently throughout a dictionary itself (some vendors indicate variant a, some don't but it doesn't always match with FR's dicts). Thanks for your feedback, I hope to send in some Equallogic updates to other vendors dictionaries that I've found on respective vendor docs. -- Mat
On 9 Feb 2014, at 11:02, Mathieu Simon (Lists) <matsimon.lists@simweb.ch> wrote:
G'day
I've been pondering a bit on the different dictionnaries and hope to provide some new.
I understand that modifying/renaming old values can be is putting at risk current setups current setups, however new ones are easier to add :-)
It's fine if it's going into the master branch, so long as it's not just spurious rewriting. As software evolves, naming schemes have to too.
What is the current consenscus on tha Attribute naming. I've learned that underline usage isn't appreciated even though some vendors use it.
VENDOR foovendor <id>
a) ATTRIBUTE foovendor-name-by-vendor-doc... b) ATTRIBUTE name-by-vendor-doc...
I've seen both in usage but mostly consistently throughout a dictionary itself (some vendors indicate variant a, some don't but it doesn't always match with FR's dicts).
Thanks for your feedback, I hope to send in some Equallogic updates to other vendors dictionaries that I've found on respective vendor docs.
If future versions we'll adopt an oid like syntax for specifying attributes (vendor.vendor_attribute.vendor_nested_attribute), then we won't need any of this prefix crap. But for now it should be: <vendor>-<vendor's attribute name> Unless the attribute name already starts with the vendor name... Replace underscores for hyphens in all cases. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
Mathieu Simon (Lists) wrote:
What is the current consenscus on tha Attribute naming. I've learned that underline usage isn't appreciated even though some vendors use it.
Personally, I hate it. It's annoying, and doesn't follow the 20 year practice of RADIUS.
VENDOR foovendor <id>
a) ATTRIBUTE foovendor-name-by-vendor-doc... b) ATTRIBUTE name-by-vendor-doc...
I've seen both in usage but mostly consistently throughout a dictionary itself (some vendors indicate variant a, some don't but it doesn't always match with FR's dicts).
We try to balance the approaches of "use sane names" and "use vendor names". It's not always perfect. The *official* recommendation for naming schemes is given here: http://tools.ietf.org/search/rfc6929#section-2.7.1 You'll note I'm the author. :) Alan DeKok.
Hi Arran and Alan Am 10.02.2014 15:03, schrieb Alan DeKok:
Mathieu Simon (Lists) wrote:
What is the current consenscus on tha Attribute naming. I've learned that underline usage isn't appreciated even though some vendors use it.
Personally, I hate it. It's annoying, and doesn't follow the 20 year practice of RADIUS.
Yup, that's what I learned from your reaction on a previous pull request ;-)
VENDOR foovendor <id>
a) ATTRIBUTE foovendor-name-by-vendor-doc... b) ATTRIBUTE name-by-vendor-doc...
I've seen both in usage but mostly consistently throughout a dictionary itself (some vendors indicate variant a, some don't but it doesn't always match with FR's dicts).
We try to balance the approaches of "use sane names" and "use vendor names". It's not always perfect.
I followed yours and Arran's recommendation, thanks for both clarifications. In the end there is always a human factor of "YMMV" and need to find an agreement :-)
The *official* recommendation for naming schemes is given here:
http://tools.ietf.org/search/rfc6929#section-2.7.1
You'll note I'm the author. :)
Yup, I now I read it and the wording "RECOMMENDED" and "SHOULD" are likely following the reality where you recommend the vendors to use sane namings but in reality they might just ignore the recommendation. Allas, good luck to get that RFC into a standard! -- Mat
participants (3)
-
Alan DeKok -
Arran Cudbard-Bell -
Mathieu Simon (Lists)