#  -*- text -*-
#
#
#  $Id: 0c9842503067de7e18739e385bb2662a13e333ae $

#######################################################################
#
#  # Local dictionary definitions
#
#  This is the local dictionary file which can be
#  edited by local administrators.  It will be loaded
#  *after* the main dictionary files are loaded.
#
#
#  NOTE: We recommend using local variables inside of "unlang"
#        sections instead of defining attributes in this file. See
#        the xref:reference:index.adoc[reference documentation]
#        for more information on
#        xref:reference:unlang/local.adoc[local variables].
#
#
#  This file exists for two purposes:
#
#  1) defining local attributes in order to simplify the process
#     of migrating from version 3 to version 4.  We recommend
#     removing these attributes, and using local variables instead.
#
#  2) Including alias dictionaries  in order to simplify the
#     process of migrating from version 3 to version 4.  We
#     recommend using the new names where possible.
#
#  ## Dictionary loading order
#
#  FreeRADIUS will automatically load the main dictionary files from:
#
#  	${prefix}/share/freeradius/dictionary
#
#  It is no longer necessary for this file to `$INCLUDE` the main
#  dictionaries from this file.  However, if the `$INCLUDE` line is
#  here, nothing bad will happen.

#
#  ## Dictionaries per Virtual Server
#
#  v4 also supports a `dictionary { ... }` subsection in a virtual
#  server.  If the attributes are used only in one virtual server,
#  they should be defined there.
#

#
#  ## Editing the dictionary
#
#  Any new/changed attributes *must* be placed in this file.
#  The pre-defined dictionaries *should not* be edited.
#  See `man dictionary` for documentation on how dictionary
#  entries should be formatted.
#
#  All local attributes and `$INCLUDE` directives should
#  go into this files.
#
#  The attribute definitions here should use `DEFINE`, not `ATTRIBUTE`.
#  The `DEFINE` keyword is exactly like `ATTRIBUTE`, except it does not
#  require an attribute number.
#
#  As a result, there is no need to manually manage numbers.
#
#  Any attribute `DEFINE`d here will not go into a packet.
#
#  If you do want attributes to go into a RADIUS packet, you
#  will need to use VSAs. This means requesting allocation
#  of a Private Enterprise Code from https://www.iana.org/. We
#  strongly suggest doing that *only* if you are a vendor of
#  RADIUS equipment.
#
#  See RFC 6158 for more details:
#    http://ietf.org/rfc/rfc6158.txt

#
#  ## Example attributes
#
#  The attributes below are examples. You should edit them as
#  required, or add your own.
#

#DEFINE	My-Local-String		string
#DEFINE	My-Local-IPAddr		ipaddr
#DEFINE	My-Local-Integer	integer

#
#  ## v3 Compatible names.
#
#  All of the attributes have been renamed from v3.  This change was
#  necessary in order to support new functionality in v4.  The
#  unfortunate side effect of this change is that all of the names in
#  SQL, LDAP, and the "files" module are incompatible with v4.
#
#  We recognize that is is difficult to change every entry in a
#  database, especially when there's no clear mapping between the
#  "old" and "new" names.  This renaming is made more complex because
#  the "new" names need to be grouped and arranged in ways that the
#  old ones were not.
#
#  The "old" names were all in flat lists, so that User-Name appeared
#  next to Cisco-AVPAir.  This organization was simple enough to work
#  for 20 years, but its time has come.  The new names are
#  hierarchical, so that the organization is nested by definition.
#
#  For v4, the Cisco-AVPair attribute is called "AVPair", and it lives
#  inside of the "Cisco" namespace, which in turn lives inside of the
#  "Vendor-Specific" namespace.  So the new name for Cisco-AVPair is
#  Vendor-Specific.Cisco.AVPair.
#
#  This process continues for many thousands of vendor-specific
#  attributes.
#
#  Happily, it is possible to (mostly) use the old names with v4.
#  There are limitations, but it will mostly work.  The main reason
#  for enabling the old names is to try out v4 with a database that is
#  also used by v3.  This lets you test that v4 works, without going
#  through a complex "upgrade everything" process.
#
#  The old v3 names are in "alias" dictionaries, in the `${dictdir}`
#  directory.  To find out where this directory is on your local
#  system, run "radiusd -h" or "radclient -h".  Then look for the "-D"
#  command-line option, and it will tell you where the dictionary
#  files are located.
#
#  The v3 names are in `${dictdir}/radius/alias/VENDOR.txt` where
#  _VENDOR_ is the name of the vendor, which is taken from the `VENDOR`
#  definition in the v3 dictionaries.
#
#  You will need to add a `$INCLUDE` line for each vendor-specific
#  dictionary which is used by your local system.  The default v4
#  dictionaries do not enable all of v3 compatibility names.
#
#  Yes, we recognize that this process is a bit of work.  However, we
#  wish to encourage everyone using v4 to upgrade to using the new v4
#  features.  Our experience shows that if we automatically enable
#  "compatibility functions", then those compatibility functions will
#  be used for a decade.  So we need to find a balance between
#  upgrades and ongoing support.  Easy upgrades will mean complex
#  ongoing support.  Complex upgrades make ongoing support easier, but
#  also make it less likely that people will upgrade.
#
#
#  All of the v3 compatibility names are in the RADIUS namespace.
#

#BEGIN-PROTOCOL RADIUS
#$INCLUDE ${dictdir}/radius/alias/cisco.txt
#END-PROTOCOL RADIUS
