diff --git a/doc/administration_and_usage/basic_administration_and_usage-v1.7.md b/doc/administration_and_usage/basic_administration_and_usage-v1.7.md
index 0b84d7d2eb62615024d7f0da1957b75f199b0cc9..6e77138434e594d6aaf040cee95c3254d003dbfe 100644
--- a/doc/administration_and_usage/basic_administration_and_usage-v1.7.md
+++ b/doc/administration_and_usage/basic_administration_and_usage-v1.7.md
@@ -1,15 +1,15 @@
 # Basic Administration and Usage
 
-Early steps for administration and usage that can be done after FoD has been installed.
+Early steps for administration and usage that can be done after {{ product_name_short }} has been installed.
 
-## 1: Setup NETCONF + FoD admin user 
+## 1: Setup NETCONF + {{ product_name_short }} admin user 
 
-### 1 (local): Setup NETCONF + FoD admin user (FoD running locally)
+### 1 (local): Setup NETCONF + {{ product_name_short }} admin user ({{ product_name_short }} running locally)
 
 admin user password and NETCONF connection has to be setup, 
 either by
 
-A) via the setup page of FoD in container
+A) via the setup page of {{ product_name_short }} in container
 (needs ENABLE_SETUP_VIEW=True in ./flowspy/settings.py; 
 only applicable once, i.e., as long as no admin user has been setup, for security reasons):
 
@@ -29,21 +29,21 @@ edit /srv/flowspy/flowspy/settings.py : settings NETCONF_DEVICE, NETCONF_PORT, N
 
 make sure IP connectivity to NETCONF_DEVICE is available
 
-in FoD installation dir (default: /srv/flowspy): ./pythonenv ./manage.py createsuperuser ...
-in FoD installation dir (default: /srv/flowspy): ./pythonenv ./manage.py changepassword ...
+in {{ product_name_short }} installation dir (default: /srv/flowspy): ./pythonenv ./manage.py createsuperuser ...
+in {{ product_name_short }} installation dir (default: /srv/flowspy): ./pythonenv ./manage.py changepassword ...
 
-restart FoD: 'systemctl restart fod-gunicorn; systemctl restart fod-celeryd' (if installed and running with Systemd support)
+restart {{ product_name_short }}: 'systemctl restart fod-gunicorn; systemctl restart fod-celeryd' (if installed and running with Systemd support)
 
 or alternatively
 
 C) already having been set by install-\*.sh parameters (check [Debian/Ubuntu Installation](../installation/v1.7/debian_ubuntu.md) or [CENTOS 7 Installation](../installation/v1.7/centos.md) )
 
-### 1 (Docker): Setup NETCONF + FoD admin user (FoD running in a Docker container)
+### 1 (Docker): Setup NETCONF + {{ product_name_short }} admin user ({{ product_name_short }} running in a Docker container)
 
 admin user password and NETCONF connection has to be setup, 
 either by
 
-A) via the setup page of FoD in container
+A) via the setup page of {{ product_name_short }} in container
 (only applicable once, i.e., as long as no admin user has been setup, for security reasons):
 
 http://127.0.0.1:8001/setup/
@@ -69,7 +69,7 @@ in docker: cd /srv/flowspy; ./pythonenv ./manage.py createsuperuser ...
 
 in docker: cd /srv/flowspy; ./pythonenv ./manage.py changepassword ...
 
-## 2: Accessing the FoD UI running in container after setup of admin user and password
+## 2: Accessing the {{ product_name_short }} UI running in container after setup of admin user and password
 
 http(s)://SERVERNAME:SERVERPORT/altlogin
 (for use with Docker: http(s)://SERVERNAME:8000/altlogin)
@@ -85,22 +85,22 @@ via http(s)://SERVERNAME:SERVERPORT/admin (only accessible by admin users, e.g.,
 Peer ranges and Peers:
 (http(s)://SERVERNAME:SERVERPORT/admin/peers/peerrange/ and http(s)://SERVERNAME:SERVERPORT/admin/peers/peer/)
 
-The 'peer' is a concept in FoD to support multi-tenancy.
+The 'peer' is a concept in {{ product_name_short }} to support multi-tenancy.
 Each peer has assigned a set of allowed destination IP address prefixes ('peer ranges')
 for which the peer is allowed to deploy BGP FlowSpec rules.
-It typically corresponds to a customer organization of the network operator organization running FoD
+It typically corresponds to a customer organization of the network operator organization running {{ product_name_short }}
 to provided to users of the different customer organizations.
 
 For managing users (beyond the initial setup of the first admin user, under 1.) the /admin web UI interface can be used
 as well, specifically http(s)://SERVERNAME:SERVERPORT/admin/auth/user/.
 E.g., it allows adding/removing users, changing first/last name of a user, define whether it is an admin or not.
 
-A 'user' in FoD (including every admin user) has assigned a set of peers (typically, often only 1).
+A 'user' in {{ product_name_short }} (including every admin user) has assigned a set of peers (typically, often only 1).
 Only for destination IP address prefixes of assigned peers the user has the right to
 deploy or change BGP FlowSpec rules.
 
 This restriction also applies for the initial admin user created initially (see 1.).
-So before that admin user can deploy FlowSpec rules via FoD, a peer has to be created (maybe by this admin user).
+So before that admin user can deploy FlowSpec rules via {{ product_name_short }}, a peer has to be created (maybe by this admin user).
 and appropriate peer ranges have to assigned to the peer
 and this peer has to assigned to the user.
 
@@ -125,17 +125,17 @@ TODO: auto update of enrolled users on login
 
 #### 2.2.1 usage via web UI
 
-When logged into FoD UI via
+When logged into {{ product_name_short }} UI via
 http(s)://SERVERNAME:SERVERPORT/altlogin
 (or via https://SERVERNAME:SERVERPORT/login for use with Shibboleth enrolled/registered users, see 2.1.2)
-with a FoD user account which has assigned 1 or more peers with appropriate peer ranges (see 2.1.1)
+with a {{ product_name_short }} user account which has assigned 1 or more peers with appropriate peer ranges (see 2.1.1)
 the normal usage can start.
 
 ##### Rules list/table page
 
 Provides a list/table of of all rule for all peers of the user.
-BGP FlowSpec rule can have either status inactive (stored only in FoD database),
-or active (stored in FoD database + installed on the router via NETCONF)
+BGP FlowSpec rule can have either status inactive (stored only in {{ product_name_short }} database),
+or active (stored in {{ product_name_short }} database + installed on the router via NETCONF)
 
 ##### Rules dashboard
 
@@ -143,14 +143,14 @@ Provides a history of rule changes for all peers of the user.
 
 ##### Add New Rule
 
-Allows to add a new rule, i.e., one not yet stored in the FoD database,
-to FoD database and transfer it via NETCONF to the router(s).
+Allows to add a new rule, i.e., one not yet stored in the {{ product_name_short }} database,
+to {{ product_name_short }} database and transfer it via NETCONF to the router(s).
 
 ##### Edit Existing Rule
 
 Reachable from rules list page or dashboard page for all existing (active or inactive) displayed rules
 for all peers of the user.
-An edited route is changed in the FoD data base as well as updated on the router,
+An edited route is changed in the {{ product_name_short }} data base as well as updated on the router,
 i.e., will be in active status after the edit operation.
 
 ##### Overview (for admin users)
@@ -173,8 +173,8 @@ see [API v1.7](../api/api-v1.7.md)
 
 #### 3. Further/Regular Administration
 
-### FoD run-time status 
+### {{ product_name_short }} run-time status 
 
-There is ./systemd/fod-status.sh, a generic script (not limited to Systemd) for determining the process status of FoD along with some further aspects, e.g., Database connection, NETCONF configuration and reachability
+There is ./systemd/fod-status.sh, a generic script (not limited to Systemd) for determining the process status of {{ product_name_short }} along with some further aspects, e.g., Database connection, NETCONF configuration and reachability
 
 
diff --git a/doc/administration_and_usage/basic_administration_and_usage-v1.8.md b/doc/administration_and_usage/basic_administration_and_usage-v1.8.md
index 0b84d7d2eb62615024d7f0da1957b75f199b0cc9..6e77138434e594d6aaf040cee95c3254d003dbfe 100644
--- a/doc/administration_and_usage/basic_administration_and_usage-v1.8.md
+++ b/doc/administration_and_usage/basic_administration_and_usage-v1.8.md
@@ -1,15 +1,15 @@
 # Basic Administration and Usage
 
-Early steps for administration and usage that can be done after FoD has been installed.
+Early steps for administration and usage that can be done after {{ product_name_short }} has been installed.
 
-## 1: Setup NETCONF + FoD admin user 
+## 1: Setup NETCONF + {{ product_name_short }} admin user 
 
-### 1 (local): Setup NETCONF + FoD admin user (FoD running locally)
+### 1 (local): Setup NETCONF + {{ product_name_short }} admin user ({{ product_name_short }} running locally)
 
 admin user password and NETCONF connection has to be setup, 
 either by
 
-A) via the setup page of FoD in container
+A) via the setup page of {{ product_name_short }} in container
 (needs ENABLE_SETUP_VIEW=True in ./flowspy/settings.py; 
 only applicable once, i.e., as long as no admin user has been setup, for security reasons):
 
@@ -29,21 +29,21 @@ edit /srv/flowspy/flowspy/settings.py : settings NETCONF_DEVICE, NETCONF_PORT, N
 
 make sure IP connectivity to NETCONF_DEVICE is available
 
-in FoD installation dir (default: /srv/flowspy): ./pythonenv ./manage.py createsuperuser ...
-in FoD installation dir (default: /srv/flowspy): ./pythonenv ./manage.py changepassword ...
+in {{ product_name_short }} installation dir (default: /srv/flowspy): ./pythonenv ./manage.py createsuperuser ...
+in {{ product_name_short }} installation dir (default: /srv/flowspy): ./pythonenv ./manage.py changepassword ...
 
-restart FoD: 'systemctl restart fod-gunicorn; systemctl restart fod-celeryd' (if installed and running with Systemd support)
+restart {{ product_name_short }}: 'systemctl restart fod-gunicorn; systemctl restart fod-celeryd' (if installed and running with Systemd support)
 
 or alternatively
 
 C) already having been set by install-\*.sh parameters (check [Debian/Ubuntu Installation](../installation/v1.7/debian_ubuntu.md) or [CENTOS 7 Installation](../installation/v1.7/centos.md) )
 
-### 1 (Docker): Setup NETCONF + FoD admin user (FoD running in a Docker container)
+### 1 (Docker): Setup NETCONF + {{ product_name_short }} admin user ({{ product_name_short }} running in a Docker container)
 
 admin user password and NETCONF connection has to be setup, 
 either by
 
-A) via the setup page of FoD in container
+A) via the setup page of {{ product_name_short }} in container
 (only applicable once, i.e., as long as no admin user has been setup, for security reasons):
 
 http://127.0.0.1:8001/setup/
@@ -69,7 +69,7 @@ in docker: cd /srv/flowspy; ./pythonenv ./manage.py createsuperuser ...
 
 in docker: cd /srv/flowspy; ./pythonenv ./manage.py changepassword ...
 
-## 2: Accessing the FoD UI running in container after setup of admin user and password
+## 2: Accessing the {{ product_name_short }} UI running in container after setup of admin user and password
 
 http(s)://SERVERNAME:SERVERPORT/altlogin
 (for use with Docker: http(s)://SERVERNAME:8000/altlogin)
@@ -85,22 +85,22 @@ via http(s)://SERVERNAME:SERVERPORT/admin (only accessible by admin users, e.g.,
 Peer ranges and Peers:
 (http(s)://SERVERNAME:SERVERPORT/admin/peers/peerrange/ and http(s)://SERVERNAME:SERVERPORT/admin/peers/peer/)
 
-The 'peer' is a concept in FoD to support multi-tenancy.
+The 'peer' is a concept in {{ product_name_short }} to support multi-tenancy.
 Each peer has assigned a set of allowed destination IP address prefixes ('peer ranges')
 for which the peer is allowed to deploy BGP FlowSpec rules.
-It typically corresponds to a customer organization of the network operator organization running FoD
+It typically corresponds to a customer organization of the network operator organization running {{ product_name_short }}
 to provided to users of the different customer organizations.
 
 For managing users (beyond the initial setup of the first admin user, under 1.) the /admin web UI interface can be used
 as well, specifically http(s)://SERVERNAME:SERVERPORT/admin/auth/user/.
 E.g., it allows adding/removing users, changing first/last name of a user, define whether it is an admin or not.
 
-A 'user' in FoD (including every admin user) has assigned a set of peers (typically, often only 1).
+A 'user' in {{ product_name_short }} (including every admin user) has assigned a set of peers (typically, often only 1).
 Only for destination IP address prefixes of assigned peers the user has the right to
 deploy or change BGP FlowSpec rules.
 
 This restriction also applies for the initial admin user created initially (see 1.).
-So before that admin user can deploy FlowSpec rules via FoD, a peer has to be created (maybe by this admin user).
+So before that admin user can deploy FlowSpec rules via {{ product_name_short }}, a peer has to be created (maybe by this admin user).
 and appropriate peer ranges have to assigned to the peer
 and this peer has to assigned to the user.
 
@@ -125,17 +125,17 @@ TODO: auto update of enrolled users on login
 
 #### 2.2.1 usage via web UI
 
-When logged into FoD UI via
+When logged into {{ product_name_short }} UI via
 http(s)://SERVERNAME:SERVERPORT/altlogin
 (or via https://SERVERNAME:SERVERPORT/login for use with Shibboleth enrolled/registered users, see 2.1.2)
-with a FoD user account which has assigned 1 or more peers with appropriate peer ranges (see 2.1.1)
+with a {{ product_name_short }} user account which has assigned 1 or more peers with appropriate peer ranges (see 2.1.1)
 the normal usage can start.
 
 ##### Rules list/table page
 
 Provides a list/table of of all rule for all peers of the user.
-BGP FlowSpec rule can have either status inactive (stored only in FoD database),
-or active (stored in FoD database + installed on the router via NETCONF)
+BGP FlowSpec rule can have either status inactive (stored only in {{ product_name_short }} database),
+or active (stored in {{ product_name_short }} database + installed on the router via NETCONF)
 
 ##### Rules dashboard
 
@@ -143,14 +143,14 @@ Provides a history of rule changes for all peers of the user.
 
 ##### Add New Rule
 
-Allows to add a new rule, i.e., one not yet stored in the FoD database,
-to FoD database and transfer it via NETCONF to the router(s).
+Allows to add a new rule, i.e., one not yet stored in the {{ product_name_short }} database,
+to {{ product_name_short }} database and transfer it via NETCONF to the router(s).
 
 ##### Edit Existing Rule
 
 Reachable from rules list page or dashboard page for all existing (active or inactive) displayed rules
 for all peers of the user.
-An edited route is changed in the FoD data base as well as updated on the router,
+An edited route is changed in the {{ product_name_short }} data base as well as updated on the router,
 i.e., will be in active status after the edit operation.
 
 ##### Overview (for admin users)
@@ -173,8 +173,8 @@ see [API v1.7](../api/api-v1.7.md)
 
 #### 3. Further/Regular Administration
 
-### FoD run-time status 
+### {{ product_name_short }} run-time status 
 
-There is ./systemd/fod-status.sh, a generic script (not limited to Systemd) for determining the process status of FoD along with some further aspects, e.g., Database connection, NETCONF configuration and reachability
+There is ./systemd/fod-status.sh, a generic script (not limited to Systemd) for determining the process status of {{ product_name_short }} along with some further aspects, e.g., Database connection, NETCONF configuration and reachability
 
 
diff --git a/doc/administration_and_usage/testing_and_using_fod_with_freertr.md b/doc/administration_and_usage/testing_and_using_fod_with_freertr.md
index cfdcd75a22e9b20ee4590817530583f84258e3b9..e617f570ec63b47e386ac27459827adb3df92bf1 100644
--- a/doc/administration_and_usage/testing_and_using_fod_with_freertr.md
+++ b/doc/administration_and_usage/testing_and_using_fod_with_freertr.md
@@ -1,23 +1,23 @@
-# Testing and Using FoD (exabgp version) with Freertr 
+# Testing and Using {{ product_name_short }} (exabgp version) with Freertr 
 
 Freertr ([http://www.freertr.org](http://www.freertr.org/), [http://docs.freertr.org/](http://docs.freertr.org/)): a Open Source Network Operating System with support of a huge list of routing prototocols, data plan protocols (including P4)
 
-## Docker containers for use of FoD (exabgp version) with Freertr:
+## Docker containers for use of {{ product_name_short }} (exabgp version) with Freertr:
 
-1. using 2 containers (FoD+exabgp container and freertr container) manually:
+1. using 2 containers ({{ product_name_short }}+exabgp container and freertr container) manually:
 ./inst/testing/fodexabgp/README.txt
 ./inst/testing/fodexabgp/install_fodexabgp__docker.sh
 
-2. using only freertr container (for use with OS-installed FoD)
+2. using only freertr container (for use with OS-installed {{ product_name_short }})
 ./inst/testing/fodexabgp/install_freertronly__docker.sh.new
 
-3. using containerlab for coordinated run of FoD+exabgp container, freertr container, and attacker/victim host containers
+3. using containerlab for coordinated run of {{ product_name_short }}+exabgp container, freertr container, and attacker/victim host containers
 ./inst/testing/fodexabgp-containerlab1/README.md info
 ./inst/testing/fodexabgp-containerlab1/Dockerfile
 
-4. using docker-compose for coordinated run of FoD+exabgp container, freertr container, and attacker/victim host containers
+4. using docker-compose for coordinated run of {{ product_name_short }}+exabgp container, freertr container, and attacker/victim host containers
 ./docker-compose/README.txt info
-./docker-compose.yml default docker compose specification using bind-mounted FoD dir (mainly for developers)
-./docker-compose-novol.yml docker compose specification without bind-mounted FoD dir (for testing or demo-ing)
+./docker-compose.yml default docker compose specification using bind-mounted {{ product_name_short }} dir (mainly for developers)
+./docker-compose-novol.yml docker compose specification without bind-mounted {{ product_name_short }} dir (for testing or demo-ing)
 
 
diff --git a/doc/api/api-v1.3.md b/doc/api/api-v1.3.md
index 6f536d83c77ca7246362b0d22aafd4c513d064cf..11481b12d9b4b77e95c446e57daace73cc382876 100644
--- a/doc/api/api-v1.3.md
+++ b/doc/api/api-v1.3.md
@@ -2,13 +2,13 @@
 
 # Description
 
-Current version of FoD officially has a REST API.
+Current version of {{ product_name_short }} officially has a REST API.
 The API needs authentication. Out of the box the supported authentication
 type is Token Authentication.
 
 ## Generating Tokens
 
-A user can generate an API token using the FoD UI. Select "My Profile" from the
+A user can generate an API token using the {{ product_name_short }} UI. Select "My Profile" from the
 top right menu and on the "Api Token" section click "Generate One".
 
 ## Accessing the API
@@ -332,12 +332,12 @@ See `ThenAction`s.
 
 ### General notes on `Route` models:
 
-* When `POST`ing a new `Route`, FoD will automatically commit it to the flowspec
+* When `POST`ing a new `Route`, {{ product_name_short }} will automatically commit it to the flowspec
 device. Thus, `POST`ing a new `Route` with a status of `INACTIVE` has no effect,
 since the `Route` will be activated and the status will be restored to `ACTIVE`.
-* When `DELETE`ing a `Route`, the actual `Route` object will remain. FoD will
+* When `DELETE`ing a `Route`, the actual `Route` object will remain. {{ product_name_short }} will
 only delete the rule from the flowspec device and change the `Route`'s status to
 'INACTIVE'
-* When changing (`PUT`/`PATCH`) a `Route`, FoD will sync the changes to the
+* When changing (`PUT`/`PATCH`) a `Route`, {{ product_name_short }} will sync the changes to the
 flowspec device. Changing the status of the `Route` will activate / delete the
 rule respectively.
diff --git a/doc/api/api-v1.7.md b/doc/api/api-v1.7.md
index e0311895d7df7c8b8fc87af3ba3c4d812794f982..edb18434bf1d39a976ab6990031cb63951a557d8 100644
--- a/doc/api/api-v1.7.md
+++ b/doc/api/api-v1.7.md
@@ -2,7 +2,7 @@
 
 # Description
 
-Current version of FoD officially has a REST API.
+Current version of {{ product_name_short }} officially has a REST API.
 The API needs authentication. Out of the box the supported authentication
 type is Token Authentication.
 
@@ -10,7 +10,7 @@ TO UPDATE
 
 ## Generating Tokens
 
-A user can generate an API token using the FoD UI. Select "My Profile" from the
+A user can generate an API token using the {{ product_name_short }} UI. Select "My Profile" from the
 top right menu and on the "Api Token" section click "Generate One".
 
 ## Accessing the API
@@ -55,7 +55,7 @@ URL: `/api/thenactions/`
 Example:
 ```
 curl -X GET https://fod.example.com/api/thenactions/ -H "Authorization: Token <your-token>"
-# or on the FoD host locally:
+# or on the {{ product_name_short }} host locally:
 curl -X GET http://localhost:8000/api/thenactions/ -H "Authorization: Token <your-token>"
 
 RESPONSE:
@@ -156,8 +156,8 @@ RESPONSE:
 
 ### POST
 
-Starting from FoD v1.7 the REST API accepts parameters for POST, PUT and PATCH only via JSON documents,
-old method used in REST API of FoD v1.3 to specify parameters as single form values is not supported any more.
+Starting from {{ product_name_short }} v1.7 the REST API accepts parameters for POST, PUT and PATCH only via JSON documents,
+old method used in REST API of {{ product_name_short }} v1.3 to specify parameters as single form values is not supported any more.
 
 Required fields (to be specified via JSON document):
 
@@ -242,8 +242,8 @@ the API returned.
 
 ### PUT, PATCH
 
-Starting from FoD v1.7 the REST API accepts parameters for POST, PUT and PATCH only via JSON documents,
-old method used in REST API of FoD v1.3 to specify parameters as single form values is not supported any more.
+Starting from {{ product_name_short }} v1.7 the REST API accepts parameters for POST, PUT and PATCH only via JSON documents,
+old method used in REST API of {{ product_name_short }} v1.3 to specify parameters as single form values is not supported any more.
 
 `Route` objects can be modified using the `PUT` / `PATCH` HTTP methods.
 
@@ -277,8 +277,8 @@ In contrast, a PUT of an active rule will always trigger a recommiting of that r
 on the configured NETCONF-linked router, independent of the attribute values changed.
 So, this is useful
 for ensuring that a rule is really still actively installed on the configured NETCONF-linked router
-with all match and action parameters as is was last deployed by FoD,
-and not changed by some other means without FoD's notice, e.g., other tools or directly by the CLI of the router.
+with all match and action parameters as is was last deployed by {{ product_name_short }},
+and not changed by some other means without {{ product_name_short }}'s notice, e.g., other tools or directly by the CLI of the router.
 
 ### DELETE
 
@@ -297,20 +297,20 @@ set of normal users is allowed to use DELETE method.
 The default values of the settings (flowspy/settings.py.dist) by this means 
 allow DELETE only for admins, only for a specificly defined set of normal users.
 
-### General notes on `Route` models (differences to REST API of FoD v1.7):
+### General notes on `Route` models (differences to REST API of {{ product_name_short }} v1.7):
 
-* Starting from FoD v1.7 the REST API accepts parameters for POST, PUT and PATCH only via JSON documents,
-old method used in REST API of FoD v1.3 to specify parameters as single form values is not supported any more.
+* Starting from {{ product_name_short }} v1.7 the REST API accepts parameters for POST, PUT and PATCH only via JSON documents,
+old method used in REST API of {{ product_name_short }} v1.3 to specify parameters as single form values is not supported any more.
 
-* In contrast to REST API of FoD v1.3, REST API of current version v1.7 will honor the status
+* In contrast to REST API of {{ product_name_short }} v1.3, REST API of current version v1.7 will honor the status
 value set in POST method calls.
 So, it is possible to create a Flowspec rule with status INACTIVE, 
 i.e., a rule which will not be automatically commited via NETCONF as result of the POST method call.
 
-* In contrast to REST API of FoD v1.3, REST API of current version v1.7,
+* In contrast to REST API of {{ product_name_short }} v1.3, REST API of current version v1.7,
 the reuslt of PUT and PATCH method differs in some occasions (see above).
 
-* In contrast to REST API of FoD v1.3, REST API of current version v1.7
+* In contrast to REST API of {{ product_name_short }} v1.3, REST API of current version v1.7
 will behave differently regarding the DELETE method (see above).
 
 
diff --git a/doc/api/api-v1.8.md b/doc/api/api-v1.8.md
index 5775381ce1a724b421c42558acdd099636075daa..1fdfbbf44495229d625cfde30fba69157691013a 100644
--- a/doc/api/api-v1.8.md
+++ b/doc/api/api-v1.8.md
@@ -4,7 +4,7 @@
 
 # Description
 
-Current version of FoD officially has a REST API.
+Current version of {{ product_name_short }} officially has a REST API.
 The API needs authentication. Out of the box the supported authentication
 type is Token Authentication.
 
@@ -12,7 +12,7 @@ TO UPDATE
 
 ## Generating Tokens
 
-A user can generate an API token using the FoD UI. Select "My Profile" from the
+A user can generate an API token using the {{ product_name_short }} UI. Select "My Profile" from the
 top right menu and on the "Api Token" section click "Generate One".
 
 ## Accessing the API
@@ -57,7 +57,7 @@ URL: `/api/thenactions/`
 Example:
 ```
 curl -X GET https://fod.example.com/api/thenactions/ -H "Authorization: Token <your-token>"
-# or on the FoD host locally:
+# or on the {{ product_name_short }} host locally:
 curl -X GET http://localhost:8000/api/thenactions/ -H "Authorization: Token <your-token>"
 
 RESPONSE:
@@ -158,8 +158,8 @@ RESPONSE:
 
 ### POST
 
-Starting from FoD v1.7 the REST API accepts parameters for POST, PUT and PATCH only via JSON documents,
-old method used in REST API of FoD v1.3 to specify parameters as single form values is not supported any more.
+Starting from {{ product_name_short }} v1.7 the REST API accepts parameters for POST, PUT and PATCH only via JSON documents,
+old method used in REST API of {{ product_name_short }} v1.3 to specify parameters as single form values is not supported any more.
 
 Required fields (to be specified via JSON document):
 
@@ -244,8 +244,8 @@ the API returned.
 
 ### PUT, PATCH
 
-Starting from FoD v1.7 the REST API accepts parameters for POST, PUT and PATCH only via JSON documents,
-old method used in REST API of FoD v1.3 to specify parameters as single form values is not supported any more.
+Starting from {{ product_name_short }} v1.7 the REST API accepts parameters for POST, PUT and PATCH only via JSON documents,
+old method used in REST API of {{ product_name_short }} v1.3 to specify parameters as single form values is not supported any more.
 
 `Route` objects can be modified using the `PUT` / `PATCH` HTTP methods.
 
@@ -279,8 +279,8 @@ In contrast, a PUT of an active rule will always trigger a recommiting of that r
 on the configured NETCONF-linked router, independent of the attribute values changed.
 So, this is useful
 for ensuring that a rule is really still actively installed on the configured NETCONF-linked router
-with all match and action parameters as is was last deployed by FoD,
-and not changed by some other means without FoD's notice, e.g., other tools or directly by the CLI of the router.
+with all match and action parameters as is was last deployed by {{ product_name_short }},
+and not changed by some other means without {{ product_name_short }}'s notice, e.g., other tools or directly by the CLI of the router.
 
 ### DELETE
 
@@ -299,20 +299,20 @@ set of normal users is allowed to use DELETE method.
 The default values of the settings (flowspy/settings.py.dist) by this means 
 allow DELETE only for admins, only for a specificly defined set of normal users.
 
-### General notes on `Route` models (differences to REST API of FoD v1.7):
+### General notes on `Route` models (differences to REST API of {{ product_name_short }} v1.7):
 
-* Starting from FoD v1.7 the REST API accepts parameters for POST, PUT and PATCH only via JSON documents,
-old method used in REST API of FoD v1.3 to specify parameters as single form values is not supported any more.
+* Starting from {{ product_name_short }} v1.7 the REST API accepts parameters for POST, PUT and PATCH only via JSON documents,
+old method used in REST API of {{ product_name_short }} v1.3 to specify parameters as single form values is not supported any more.
 
-* In contrast to REST API of FoD v1.3, REST API of current version v1.7 will honor the status
+* In contrast to REST API of {{ product_name_short }} v1.3, REST API of current version v1.7 will honor the status
 value set in POST method calls.
 So, it is possible to create a Flowspec rule with status INACTIVE, 
 i.e., a rule which will not be automatically commited via NETCONF as result of the POST method call.
 
-* In contrast to REST API of FoD v1.3, REST API of current version v1.7,
+* In contrast to REST API of {{ product_name_short }} v1.3, REST API of current version v1.7,
 the reuslt of PUT and PATCH method differs in some occasions (see above).
 
-* In contrast to REST API of FoD v1.3, REST API of current version v1.7
+* In contrast to REST API of {{ product_name_short }} v1.3, REST API of current version v1.7
 will behave differently regarding the DELETE method (see above).
 
 
diff --git a/doc/configuration/configuration-v1.3.md b/doc/configuration/configuration-v1.3.md
index 77e9b789339e617b64713b159b457e4e3fe02cb7..f723215fe519a8851f101ed3bca0dac2f5aeb619 100644
--- a/doc/configuration/configuration-v1.3.md
+++ b/doc/configuration/configuration-v1.3.md
@@ -16,7 +16,7 @@ Its time to configure `settings.py` in order to connect flowspy with a database,
 So lets edit settings.py file.
 
 It is strongly advised that you do not change the following to False
-values unless, you want to integrate FoD with you CRM or members
+values unless, you want to integrate {{ product_name_short }} with you CRM or members
 database. This implies that you are able/have the rights to create
 database views between the two databases:
 
@@ -102,8 +102,8 @@ Beanstalk configuration (as a broker for celery)
 ### Notifications
 Outgoing mail address and prefix.
 
-	SERVER_EMAIL = "Example FoD Service <noreply@example.com>"
-	EMAIL_SUBJECT_PREFIX = "[FoD] "
+	SERVER_EMAIL = "Example {{ product_name_short }} Service <noreply@example.com>"
+	EMAIL_SUBJECT_PREFIX = "[{{ product_name_short }}] "
 	NOTIFY_ADMIN_MAILS = ["admin@example.com"]
 
 
@@ -151,7 +151,7 @@ Flowspy supports shibboleth authentication.
 	SHIB_ENTITLEMENT = ['HTTP_SHIB_EP_ENTITLEMENT']
 
 ### Syncing the database
-To create all the tables needed by FoD we have to run the following commands:
+To create all the tables needed by {{ product_name_short }} we have to run the following commands:
 
 	cd /srv/flowspy
 	./manage.py syncdb --noinput
@@ -172,7 +172,7 @@ folder:
     python manage.py loaddata initial_data/fixtures_manual.xml
 
 ### Celery
-Celery is a distributed task queue, which helps FoD run some async tasks, like applying a flowspec rule to a router.
+Celery is a distributed task queue, which helps {{ product_name_short }} run some async tasks, like applying a flowspec rule to a router.
 
 `Note` In order to check if celery runs or even debug it, you can run:
 
@@ -220,13 +220,13 @@ welcome.html with your own images, carousel, videos, etc.
 ## Usage
 
 ### Web interface
-FoD comes with a web interface, in which one can edit and apply new routes.
+{{ product_name_short }} comes with a web interface, in which one can edit and apply new routes.
 
 ### Rest Api
-FoD provides a rest api. It uses token as authentication method.
+{{ product_name_short }} provides a rest api. It uses token as authentication method.
 
 ### Generating Tokens
-A user can generate a token for his account on "my profile" page from FoD's
+A user can generate a token for his account on "my profile" page from {{ product_name_short }}'s
 UI. Then by using this token in the header of the request he can list, retrieve,
 modify and create rules.
 
diff --git a/doc/configuration/configuration-v1.7.md b/doc/configuration/configuration-v1.7.md
index 4ecf82ded66439e637d548b613f6ba5f44f8a8ac..7073ac6e65b3a2ac2e3cdebf64d8d4d949b0e0c6 100644
--- a/doc/configuration/configuration-v1.7.md
+++ b/doc/configuration/configuration-v1.7.md
@@ -16,7 +16,7 @@ Its time to configure `settings.py` in order to connect flowspy with a database,
 So lets edit settings.py file.
 
 It is strongly advised that you do not change the following to False
-values unless, you want to integrate FoD with you CRM or members
+values unless, you want to integrate {{ product_name_short }} with you CRM or members
 database. This implies that you are able/have the rights to create
 database views between the two databases:
 
@@ -140,8 +140,8 @@ Outgoing mail address and prefix.
 
 	DISABLE_EMAIL_NOTIFICATION = False # only disable for testing
 
-	SERVER_EMAIL = "Example FoD Service <noreply@example.com>"
-	EMAIL_SUBJECT_PREFIX = "[FoD] "
+	SERVER_EMAIL = "Example {{ product_name_short }} Service <noreply@example.com>"
+	EMAIL_SUBJECT_PREFIX = "[{{ product_name_short }}] "
 	NOTIFY_ADMIN_MAILS = ["admin@example.com"]
 
 
@@ -220,7 +220,7 @@ attribute configuration:
 
 
 ### Syncing the database
-To create all the tables and fill with basic data needed by FoD we have to run the following commands:
+To create all the tables and fill with basic data needed by {{ product_name_short }} we have to run the following commands:
 
 	cd /srv/flowspy
 	./manage.py migrate
@@ -241,7 +241,7 @@ folder:
     python manage.py loaddata initial_data/fixtures_manual.xml
 
 ### Celery
-Celery is a distributed task queue, which helps FoD run some async tasks, like applying a flowspec rule to a router.
+Celery is a distributed task queue, which helps {{ product_name_short }} run some async tasks, like applying a flowspec rule to a router.
 
 `Note` In order to check if celery runs or even debug it, you can run:
 
@@ -289,13 +289,13 @@ welcome.html with your own images, carousel, videos, etc.
 ## Usage
 
 ### Web interface
-FoD comes with a web interface, in which one can edit and apply new routes.
+{{ product_name_short }} comes with a web interface, in which one can edit and apply new routes.
 
 ### Rest Api
-FoD provides a rest api. It uses token as authentication method.
+{{ product_name_short }} provides a rest api. It uses token as authentication method.
 
 ### Generating Tokens
-A user can generate a token for his account on "my profile" page from FoD's
+A user can generate a token for his account on "my profile" page from {{ product_name_short }}'s
 UI. Then by using this token in the header of the request he can list, retrieve,
 modify and create rules.
 
diff --git a/doc/configuration/configuration-v1.8.md b/doc/configuration/configuration-v1.8.md
index 230015502f246d74aa319bd8201c5ff5c225f310..eae3b24d096a4c232cd36e09facfd5b620c665d9 100644
--- a/doc/configuration/configuration-v1.8.md
+++ b/doc/configuration/configuration-v1.8.md
@@ -16,7 +16,7 @@ Its time to configure `settings.py` in order to connect flowspy with a database,
 So lets edit settings.py file.
 
 It is strongly advised that you do not change the following to False
-values unless, you want to integrate FoD with you CRM or members
+values unless, you want to integrate {{ product_name_short }} with you CRM or members
 database. This implies that you are able/have the rights to create
 database views between the two databases:
 
@@ -140,8 +140,8 @@ Outgoing mail address and prefix.
 
 	DISABLE_EMAIL_NOTIFICATION = False # only disable for testing
 
-	SERVER_EMAIL = "Example FoD Service <noreply@example.com>"
-	EMAIL_SUBJECT_PREFIX = "[FoD] "
+	SERVER_EMAIL = "Example {{ product_name_short }} Service <noreply@example.com>"
+	EMAIL_SUBJECT_PREFIX = "[{{ product_name_short }}] "
 	NOTIFY_ADMIN_MAILS = ["admin@example.com"]
 
 
@@ -220,7 +220,7 @@ attribute configuration:
 
 
 ### Syncing the database
-To create all the tables and fill with basic data needed by FoD we have to run the following commands:
+To create all the tables and fill with basic data needed by {{ product_name_short }} we have to run the following commands:
 
 	cd /srv/flowspy
 	./manage.py migrate
@@ -241,7 +241,7 @@ folder:
     python manage.py loaddata initial_data/fixtures_manual.xml
 
 ### Celery
-Celery is a distributed task queue, which helps FoD run some async tasks, like applying a flowspec rule to a router.
+Celery is a distributed task queue, which helps {{ product_name_short }} run some async tasks, like applying a flowspec rule to a router.
 
 `Note` In order to check if celery runs or even debug it, you can run:
 
@@ -289,13 +289,13 @@ welcome.html with your own images, carousel, videos, etc.
 ## Usage
 
 ### Web interface
-FoD comes with a web interface, in which one can edit and apply new routes.
+{{ product_name_short }} comes with a web interface, in which one can edit and apply new routes.
 
 ### Rest Api
-FoD provides a rest api. It uses token as authentication method.
+{{ product_name_short }} provides a rest api. It uses token as authentication method.
 
 ### Generating Tokens
-A user can generate a token for his account on "my profile" page from FoD's
+A user can generate a token for his account on "my profile" page from {{ product_name_short }}'s
 UI. Then by using this token in the header of the request he can list, retrieve,
 modify and create rules.
 
diff --git a/doc/index.md b/doc/index.md
index 9e4e4c0934288f0d73ab0a8e8716560981c8b754..4cc5f4624fd3036c9e3bba3fb1ee3d5719ba8568 100644
--- a/doc/index.md
+++ b/doc/index.md
@@ -1,15 +1,15 @@
 # Description
 
-Firewall on Demand applies, via Netconf, flow rules to a network device.
+{{ product_name }} applies, via Netconf, flow rules to a network device.
 These rules are then propagated via e-bgp to peering routers. Each user
 is authenticated against shibboleth. Authorization is performed via a
 combination of a Shibboleth attribute and the peer network address range
-that the user originates from. FoD is meant to operate over this
+that the user originates from. {{ product_name_short }} is meant to operate over this
 architecture:
 
 ```
     +-----------+          +------------+        +------------+  
-    |   FoD     | NETCONF  | flowspec   | ebgp   |   router   |  
+    |   {{ product_name_short }}     | NETCONF  | flowspec   | ebgp   |   router   |  
     | web app   +----------> device     +-------->            |  
     +-----------+          +------+-----+        +------------+  
                                   | ebgp  
@@ -22,13 +22,13 @@ architecture:
 
 NETCONF is chosen as the mgmt protocol to apply rules to a single
 flowspec capable device. Rules are then propagated via igbp to all
-flowspec capable routers. Of course FoD could apply rules directly (via
+flowspec capable routers. Of course {{ product_name_short }} could apply rules directly (via
 NETCONF always) to a router and then ibgp would do the rest. In GRNET’s
 case the flowspec capable device is an EX4200.
 
 > ** Attention **
 >
-> Make sure your FoD server has SSH access to your flowspec device.
+> Make sure your {{ product_name_short }} server has SSH access to your flowspec device.
 
 # Index
 
@@ -38,7 +38,7 @@ case the flowspec capable device is an EX4200.
 * [Installation/v1.7/DebianAndUbuntu](./installation/v1.7/debian_ubuntu.md)
 * [Installation/v1.7/CentOS](./installation/v1.7/centos.md)
 * [Installation/v1.7/Docker](./installation/v1.7/docker.md)
-* [Installation/v1.7/Extra Docker Container for Testing FoD without Router Hardware](./installation/v1.7/docker_extra.md)
+* [Installation/v1.7/Extra Docker Container for Testing {{ product_name_short }} without Router Hardware](./installation/v1.7/docker_extra.md)
 
 * [Configuration/v1.7](./configuration/configuration-v1.7.md)
 
@@ -50,14 +50,14 @@ case the flowspec capable device is an EX4200.
 
 # Contact 
 
-You can find more about FoD or raise your issues at [Github FoD
+You can find more about {{ product_name_short }} or raise your issues at [Github FoD
 repository].
 
 You can contact us directly at fod{at}lists[dot]geant(.)org
 
 # GRNET Contact 
 
-You can find more about FoD or raise your issues at [Github FoD
+You can find more about {{ product_name_short }} or raise your issues at [Github FoD
 repository].
 
 You can contact GRNET at dev{at}noc[dot]grnet(.)gr
diff --git a/doc/installation/v1.3/debian_wheezy.md b/doc/installation/v1.3/debian_wheezy.md
index 0b94d90a29f8326c1448dc1c4f0104e018735b0d..667a3bf31a6d6af9df230d6d82945a2479531ef6 100644
--- a/doc/installation/v1.3/debian_wheezy.md
+++ b/doc/installation/v1.3/debian_wheezy.md
@@ -1,6 +1,6 @@
 # Installing Flowspy v1.3 on Debian Wheezy (x64) - Django 1.4.x
 
-The following document describes the installation process of Firewall On Demand
+The following document describes the installation process of {{ product_name }}
 on a Debian Wheezy machine with Django 1.4
 
 ## Upgrading
@@ -54,7 +54,7 @@ not available, but one can install it via pip.
 > **note**
 >
 > If you wish to deploy an outgoing mail server, now it is time to do
-> it. Otherwise you could set FoD to send out mails via a third party
+> it. Otherwise you could set {{ product_name_short }} to send out mails via a third party
 > account
 
 ### Create a database
@@ -130,7 +130,7 @@ Create and edit /etc/gunicorn.d/fod:
 
     vim /etc/gunicorn.d/fod
 
-FoD is served via gunicorn and is then proxied by Apache. If the above
+{{ product_name_short }} is served via gunicorn and is then proxied by Apache. If the above
 directory conventions have been followed so far, then your configuration
 should be:
 
@@ -455,7 +455,7 @@ is the only site you host on your server:
     a2dissite default
     a2ensite fod
 
-You are not far away from deploying FoD. When asked for a super user,
+You are not far away from deploying {{ product_name_short }}. When asked for a super user,
 create one:
 
     cd /srv/flowspy
diff --git a/doc/installation/v1.3/generic.md b/doc/installation/v1.3/generic.md
index 67728249c8fba6183515c1226b92619b4cd4634c..001baf91be76900f15e3b1f25ff581320890e18d 100644
--- a/doc/installation/v1.3/generic.md
+++ b/doc/installation/v1.3/generic.md
@@ -10,7 +10,7 @@ will perform every action.
 ## Requirements
 
 ### System Requirements
-In order to install FoD properly, make sure the following software is installed on your computer.
+In order to install {{ product_name_short }} properly, make sure the following software is installed on your computer.
 
 - apache 2
 - memcached
@@ -112,7 +112,7 @@ Here is an example configuration.
 
 
 ### Gunicorn
-FoD is served via gunicorn and is then proxied by Apache. If the above
+{{ product_name_short }} is served via gunicorn and is then proxied by Apache. If the above
 directory conventions have been followed so far, then your configuration
 should be:
 
diff --git a/doc/installation/v1.3/redhat.md b/doc/installation/v1.3/redhat.md
index fd8f58c4da22271e2aa5004d299a6355dd7467e3..923a42c63c562ce85c44aeb81daa477d174f1d8c 100644
--- a/doc/installation/v1.3/redhat.md
+++ b/doc/installation/v1.3/redhat.md
@@ -1,6 +1,6 @@
 # Installing Flowspy v1.3 on Redhat
 
-The following document describes the installation process of Firewall On Demand
+The following document describes the installation process of {{ product_name }}
 on a redhat 6.5 machine with linux 2.6.32-431.17.1.el6.x86_64.
 
 ## Step 1: Installing Requirements
@@ -22,7 +22,7 @@ One can install nxpy from the official GRNETs code repository with the following
 	pip install git+https://code.grnet.gr/git/nxpy
 
 ## Step2: Configuring Requirements
-FoD Requires the following components to be set up and configured before the installation of FoD:
+{{ product_name_short }} Requires the following components to be set up and configured before the installation of {{ product_name_short }}:
 
 - Mysql
 - A router with flowspec enabled and a user with rw permissions to flowspec and netconf access (port 830) to the device.
@@ -42,7 +42,7 @@ After this action the database will accept connections to database `fod` from th
 ### Router
 Configuring the router in order to accept connections via netconf for a specific user is mentioned just for the sake of completeness.
 
-## Step3: Actuall Installation of FoD
+## Step3: Actuall Installation of {{ product_name_short }}
 
 ### Downloading and installing
 You can download Fod v1.1.1 from GRNETs github repository. Then you have to unzip the file and place it under /srv.
@@ -60,7 +60,7 @@ We have to create manually the root directory for the logs:
 
 
 ## Step4: Patching files for RedHat
-We have noticed that some changes must be made for FoD to work under RedHat.
+We have noticed that some changes must be made for {{ product_name_short }} to work under RedHat.
 
 ### Patch the `manage.py` file
 We have to change `/srv/flowspy/manage.py` file, and make it look like this:
@@ -82,7 +82,7 @@ Actually we have just added three new lines of code, but make sure the `manage.p
 
 
 ### Patch python-tinymce:
-We now have to fix a bug from a python package in order to get FoD up and running.
+We now have to fix a bug from a python package in order to get {{ product_name_short }} up and running.
 Open
 
 	/usr/lib/python2.6/site-packages/tinymce/widgets.py
@@ -95,7 +95,7 @@ to
 	from django.utils.encoding import smart_unicode
 
 ### Syncing the database
-To create all the tables needed by FoD we have to run the following commands:
+To create all the tables needed by {{ product_name_short }} we have to run the following commands:
 
 	cd /srv/flowspy
 	./manage.py syncdb --noinput
@@ -140,7 +140,7 @@ Just start beanstalk already!
 
 
 ### Celery
-Celery is a distributed task queue, which helps FoD run some async tasks, like applying a flowspec rule to a router.
+Celery is a distributed task queue, which helps {{ product_name_short }} run some async tasks, like applying a flowspec rule to a router.
 
 `Note` In order to check if celery runs or even debug it, you can run:
 
diff --git a/doc/installation/v1.7/centos.md b/doc/installation/v1.7/centos.md
index 175626a94c88cb8cb86d6c49bbb3e72e96de5fec..12ecba7909a657a68f172ef11557321c5f5358cf 100644
--- a/doc/installation/v1.7/centos.md
+++ b/doc/installation/v1.7/centos.md
@@ -4,10 +4,10 @@ For the installation on CENTOS,
 there is ./install-centos.sh, currently mainly used for installation inside a Docker container.
 Currently, it understands several command line switches:
 
-- --fod_dir DIRNAME : specify FoD run-time directory, where FoD files are to be copied and to be run from 
-- --venv_dir DIRNAME : specify where Python virtualenv used by FoD will be located
-- --base-dir DIRNAME : specify base directory where FoD run-time directory and virtualenv directory will be sub directories
-- --here : do not copy FoD files into a separate FoD run-time directory, but instead install and make to run from current directory (probably not so useful for production)
+- --fod_dir DIRNAME : specify {{ product_name_short }} run-time directory, where {{ product_name_short }} files are to be copied and to be run from 
+- --venv_dir DIRNAME : specify where Python virtualenv used by {{ product_name_short }} will be located
+- --base-dir DIRNAME : specify base directory where {{ product_name_short }} run-time directory and virtualenv directory will be sub directories
+- --here : do not copy {{ product_name_short }} files into a separate {{ product_name_short }} run-time directory, but instead install and make to run from current directory (probably not so useful for production)
 
 - --systemd : enable Systemd support explicitly, by default will be enabled if Systemd is detected 
 - --no_systemd : disable Systemd support explicitly, even if Systemd is detected
@@ -17,36 +17,36 @@ Currently, it understands several command line switches:
 - --supversiord : enable Supversiord instead of Systemd, inside Docker Supversiord is now enabled by default in case no Systemd running s detected
 - --no_supversiord : disable Supversiord explicitly
 
-- --basesw : only install FoD dependencies (OS packages + Python Pip packages in virtualenv directory), do not install and setup FoD run-time directory (combines --basesw_os and --basesw_python)
-- --basesw_os : only install FoD OS dependencies 
-- --basesw_python : only install FoD Python/Pip dependencies in virtualenv directory
-- --fodproper : skip installing FoD dependencies, only install and setup FoD run-time directory 
+- --basesw : only install {{ product_name_short }} dependencies (OS packages + Python Pip packages in virtualenv directory), do not install and setup {{ product_name_short }} run-time directory (combines --basesw_os and --basesw_python)
+- --basesw_os : only install {{ product_name_short }} OS dependencies 
+- --basesw_python : only install {{ product_name_short }} Python/Pip dependencies in virtualenv directory
+- --fodproper : skip installing {{ product_name_short }} dependencies, only install and setup {{ product_name_short }} run-time directory 
 
 - --setup_admin_user : setup default admin 
 - --setup_admin_user5 : setup admin specified by user name, password, email address, peer name, first IP prefix 
 
 - --netconf : setup NETCONF specified by device address, TCP port, user name, password
-- --exabgp : setup exabgp specified by BGP nodeid, IP address, AS number, peer IP address, peer AS number (only for the new FoD version, currently available in git branch "feature/exabgp_support2")
+- --exabgp : setup exabgp specified by BGP nodeid, IP address, AS number, peer IP address, peer AS number (only for the new {{ product_name_short }} version, currently available in git branch "feature/exabgp_support2")
 
-## Systemd support / Starting FoD
+## Systemd support / Starting {{ product_name_short }}
 
-FoD installation currently supports Systemd, i.e., it installs Systemd startup files (./systemd/fod-\*.service) when a running Systemd is detected. Otherwise, in case of running inside docker Supversiord is enabled.
+{{ product_name_short }} installation currently supports Systemd, i.e., it installs Systemd startup files (./systemd/fod-\*.service) when a running Systemd is detected. Otherwise, in case of running inside docker Supversiord is enabled.
 Also, Supversiord can be enabled instead of Systemd explicitly (check options above)
 
 When not running under systemd,
-alternatives for startup of FoD 
+alternatives for startup of {{ product_name_short }} 
 are either
-./runfod-fg.sh for directly starting FoD processes together with Redis task broker 
+./runfod-fg.sh for directly starting {{ product_name_short }} processes together with Redis task broker 
 or
-./runfod-supervisord.sh for starting FoD processes and Redis task broker via Supervisord
+./runfod-supervisord.sh for starting {{ product_name_short }} processes and Redis task broker via Supervisord
 or
 the overall wrapper script ./runfod.sh which uses either of the startup method depending 
 on the choice selected by options for install-centos.sh.
 
-The Systemd support also includes an experimental e-mail notification for startup-failures of the FoD processes
+The Systemd support also includes an experimental e-mail notification for startup-failures of the {{ product_name_short }} processes
 
-## FoD run-time status 
+## {{ product_name_short }} run-time status 
 
-There is ./systemd/fod-status.sh, a generic script (not limited to Systemd) for determining the process status of FoD along with some further aspects, e.g., Database connection, NETCONF configuration and reachability
+There is ./systemd/fod-status.sh, a generic script (not limited to Systemd) for determining the process status of {{ product_name_short }} along with some further aspects, e.g., Database connection, NETCONF configuration and reachability
 
 
diff --git a/doc/installation/v1.7/debian_ubuntu.md b/doc/installation/v1.7/debian_ubuntu.md
index 789ec113e0b4278af2506f00ce1c63b31c4a3603..cab4cd786cf12144b66dcf2f11acbac59ad44125 100644
--- a/doc/installation/v1.7/debian_ubuntu.md
+++ b/doc/installation/v1.7/debian_ubuntu.md
@@ -5,10 +5,10 @@ there is ./install-debian.sh .
 
 It understands several command line switches:
 
-- --fod_dir DIRNAME : specify FoD run-time directory, where FoD files are to be copied and to be run from 
-- --venv_dir DIRNAME : specify where Python virtualenv used by FoD will be located
-- --base-dir DIRNAME : specify base directory where FoD run-time directory and virtualenv directory will be sub directories
-- --here : do not copy FoD files into a separate FoD run-time directory, but instead install and make to run from current directory (probably not so useful for production)
+- --fod_dir DIRNAME : specify {{ product_name_short }} run-time directory, where {{ product_name_short }} files are to be copied and to be run from 
+- --venv_dir DIRNAME : specify where Python virtualenv used by {{ product_name_short }} will be located
+- --base-dir DIRNAME : specify base directory where {{ product_name_short }} run-time directory and virtualenv directory will be sub directories
+- --here : do not copy {{ product_name_short }} files into a separate {{ product_name_short }} run-time directory, but instead install and make to run from current directory (probably not so useful for production)
 
 - --systemd : enable Systemd support explicitly, by default will be enabled if Systemd is detected 
 - --no_systemd : disable Systemd support explicitly, even if Systemd is detected
@@ -18,43 +18,43 @@ It understands several command line switches:
 - --supversiord : enable Supversiord instead of Systemd, inside Docker Supversiord is now enabled by default in case no Systemd running s detected
 - --no_supversiord : disable Supversiord explicitly
 
-- --basesw : only install FoD dependencies (OS packages + Python Pip packages in virtualenv directory), do not install and setup FoD run-time directory (combines --basesw_os and --basesw_python)
-- --basesw_os : only install FoD OS dependencies 
-- --basesw_python : only install FoD Python/Pip dependencies in virtualenv directory
-- --fodproper : skip installing FoD dependencies, only install and setup FoD run-time directory 
+- --basesw : only install {{ product_name_short }} dependencies (OS packages + Python Pip packages in virtualenv directory), do not install and setup {{ product_name_short }} run-time directory (combines --basesw_os and --basesw_python)
+- --basesw_os : only install {{ product_name_short }} OS dependencies 
+- --basesw_python : only install {{ product_name_short }} Python/Pip dependencies in virtualenv directory
+- --fodproper : skip installing {{ product_name_short }} dependencies, only install and setup {{ product_name_short }} run-time directory 
 
 - --setup_admin_user : setup default admin 
 - --setup_admin_user5 : setup admin specified by user name, password, email address, peer name, first IP prefix 
 
 - --netconf : setup NETCONF specified by device address, TCP port, user name, password
-- --exabgp : setup exabgp specified by BGP nodeid, IP address, AS number, peer IP address, peer AS number (only for the new FoD version, currently available in git branch "feature/exabgp_support2")
+- --exabgp : setup exabgp specified by BGP nodeid, IP address, AS number, peer IP address, peer AS number (only for the new {{ product_name_short }} version, currently available in git branch "feature/exabgp_support2")
 
-- --with-mta-postfix : if no MTA is installed, will try to install postfix (FoD operation is dependant on e-mail sending being available)
+- --with-mta-postfix : if no MTA is installed, will try to install postfix ({{ product_name_short }} operation is dependant on e-mail sending being available)
 
-- --with-db-sqlite : use a SQLite DB for FoD DB (not recommended for production, but easy for testing)
-- --with-db-mysql : will try to install MySQL and to setup FoD database in MySQL
-- --with-db-mariadb : will try to install MariaDB and to setup FoD database in MariaDB
-- --with-db-mysqllike : assumes that MySQL or MariaDB is installed and will try to setup FoD database based on this
+- --with-db-sqlite : use a SQLite DB for {{ product_name_short }} DB (not recommended for production, but easy for testing)
+- --with-db-mysql : will try to install MySQL and to setup {{ product_name_short }} database in MySQL
+- --with-db-mariadb : will try to install MariaDB and to setup {{ product_name_short }} database in MariaDB
+- --with-db-mysqllike : assumes that MySQL or MariaDB is installed and will try to setup {{ product_name_short }} database based on this
 
-## Systemd support / Starting FoD
+## Systemd support / Starting {{ product_name_short }}
 
-FoD installation currently supports Systemd, i.e., it installs Systemd startup files (./systemd/fod-\*.service) when a running Systemd is detected. Otherwise, in case of running inside docker Supversiord is enabled.
+{{ product_name_short }} installation currently supports Systemd, i.e., it installs Systemd startup files (./systemd/fod-\*.service) when a running Systemd is detected. Otherwise, in case of running inside docker Supversiord is enabled.
 Also, Supversiord can be enabled instead of Systemd explicitly (check options above)
 
 When not running under systemd,
-alternatives for startup of FoD 
+alternatives for startup of {{ product_name_short }} 
 are either
-./runfod-fg.sh for directly starting FoD processes together with Redis task broker 
+./runfod-fg.sh for directly starting {{ product_name_short }} processes together with Redis task broker 
 or
-./runfod-supervisord.sh for starting FoD processes and Redis task broker via Supervisord
+./runfod-supervisord.sh for starting {{ product_name_short }} processes and Redis task broker via Supervisord
 or
 the overall wrapper script ./runfod.sh which uses either of the startup method depending 
 on the choice selected by options for install-debian.sh.
 
-The Systemd support also includes an experimental e-mail notification for startup-failures of the FoD processes
+The Systemd support also includes an experimental e-mail notification for startup-failures of the {{ product_name_short }} processes
 
-## FoD run-time status 
+## {{ product_name_short }} run-time status 
 
-There is ./systemd/fod-status.sh, a generic script (not limited to Systemd) for determining the process status of FoD along with some further aspects, e.g., Database connection, NETCONF configuration and reachability
+There is ./systemd/fod-status.sh, a generic script (not limited to Systemd) for determining the process status of {{ product_name_short }} along with some further aspects, e.g., Database connection, NETCONF configuration and reachability
 
 
diff --git a/doc/installation/v1.7/docker.md b/doc/installation/v1.7/docker.md
index 4736298d799f7182d1210b59cdfeb7835b5d3e11..302b9907464ea447a41f416b58991f2f2b31365f 100644
--- a/doc/installation/v1.7/docker.md
+++ b/doc/installation/v1.7/docker.md
@@ -18,8 +18,8 @@ The containers run `gunicorn`, `celeryd` and Redis - and use a SQLite database (
 # Building the Flowspy container
 
 First build your Flowspy container. The default (`Dockerfile` = `Dockerfile.fod.debian`) is a container which uses Debian and `supervisord`, but there are other options; `Dockerfile.fod.centos.\*` uses CENTOS 7, `Dockerfile.fod.centos.new` with `supervisord`, `Dockerfile.fod.centos.old` is left for compatibility without `supervisord`.
-`Dockerfile.fod.debian` and `Dockerfile.fod.centos.new` by default will split the installation of FoD during container build into 3 phases (OS dependencies, python/pip dependencies, FoD proper installation) to exploit Docker build cache for faster rebuilding.
-Moreover, `Dockerfile.fod.debian` and `Dockerfile.fod.centos.new` can be edited for uncommenting/commenting to switch more options: e.g., use `systemd` instead of `supervisord` or not splitting the FoD installation into 3 phases 
+`Dockerfile.fod.debian` and `Dockerfile.fod.centos.new` by default will split the installation of {{ product_name_short }} during container build into 3 phases (OS dependencies, python/pip dependencies, {{ product_name_short }} proper installation) to exploit Docker build cache for faster rebuilding.
+Moreover, `Dockerfile.fod.debian` and `Dockerfile.fod.centos.new` can be edited for uncommenting/commenting to switch more options: e.g., use `systemd` instead of `supervisord` or not splitting the {{ product_name_short }} installation into 3 phases 
 (first docker build will be a bit faster and the docker container building is more efficient, as the number of docker image layers is reduced, but subsequent build after some changes in code or settings will require nearly the same amount of time as the first build)
 
 > Although the examples below use CentOS, just replace `Dockerfile.centos.new` with `Dockerfile.debian` if you wish to use Debian instead.
diff --git a/doc/installation/v1.7/docker_extra.md b/doc/installation/v1.7/docker_extra.md
index f565745d8ff2c43bbe770572336580f84e5d316c..f318c4d30ecd9f449a767076ee806d92c38a3c7a 100644
--- a/doc/installation/v1.7/docker_extra.md
+++ b/doc/installation/v1.7/docker_extra.md
@@ -1,11 +1,11 @@
-# Extra Docker containers for testing FoD without router hardware
+# Extra Docker containers for testing {{ product_name_short }} without router hardware
 
 
 ### NETCONF test server docker container
 
 When no real NETCONF-enabled router supporting BGP FlowSpec is available, just for testing the NETCONF test server Docker container can be used:
 
-In FoD-cloned installation dir, e.g., residing in /srv/flowspy, go to sub directory `router-container`
+In {{ product_name_short }}-cloned installation dir, e.g., residing in /srv/flowspy, go to sub directory `router-container`
 
 ```
 docker build -t juniper .
@@ -18,11 +18,11 @@ To manually test NETCONF access to the test server, see `/router-container/run.t
 Now, find out IP address of the running test server container, e.g., by
 docker inspect "$DOCKERID_NETCONF" | grep IPAddress # find out DOCKERID_NETCONF, e.g. by "docker ps"
 
-In FoD test container (see above) configure this IP address of the NETCONF test server,
+In {{ product_name_short }} test container (see above) configure this IP address of the NETCONF test server,
 with NETCONF port 830, NETCONF_USER "netconf" and NETCONF_PASS "netconf"
 
-Now, FoD can submit FlowSpec rules which are actually only stored inside the NETCONF test server
-without an actual effect on any network, but FoD functionality of controlling rules can be tested. 
+Now, {{ product_name_short }} can submit FlowSpec rules which are actually only stored inside the NETCONF test server
+without an actual effect on any network, but {{ product_name_short }} functionality of controlling rules can be tested. 
 
 ### NETCONF test server docker container based on netconfd instead of netopeer
 
@@ -39,7 +39,7 @@ a basic a script for syncing NETCONF rules stored in the test NETCONF server
 to OpenFlow rules in Mininet simulating BGP FlowSpec rules (not all cases supported),
 SNMPd and a Perl SNMPd statistic collector script
 
-Yields a more complete simulation of a router for FoD.
+Yields a more complete simulation of a router for {{ product_name_short }}.
 
 - ./Dockerfiles.d/Dockerfile.vnet_router1 : based on netopeer2
 - ./Dockerfiles.d/Dockerfile.vnet_router2 : similar to Dockerfile.vnet_router1, but will use netconfd (DEBIAN package) instead of CESNET's netopeer NETCONF server
diff --git a/doc/installation/v1.7/generic.md b/doc/installation/v1.7/generic.md
index 85cba8e876407c3441eec9416de9570674226944..c23f56593564946b224093c5c9162e40f7ff6c49 100644
--- a/doc/installation/v1.7/generic.md
+++ b/doc/installation/v1.7/generic.md
@@ -1,6 +1,6 @@
-# Installing FoD v1.7 Generic
+# Installing {{ product_name_short }} v1.7 Generic
 
-This guide provides general information about the installation of FoD. In case you use Debian/UBUNTU, we provide detailed instructions for the installation.
+This guide provides general information about the installation of {{ product_name_short }}. In case you use Debian/UBUNTU, we provide detailed instructions for the installation.
 
 Also it assumes that installation is carried out in `/srv/flowspy`
 directory. If other directory is to be used, please change the
@@ -12,7 +12,7 @@ TO UPDATE
 ## Requirements
 
 ### System Requirements
-In order to install FoD properly, make sure the following software is installed on your computer.
+In order to install {{ product_name_short }} properly, make sure the following software is installed on your computer.
 
 - apache 2
 - libapache2-mod-proxy-html
@@ -25,12 +25,12 @@ In order to install FoD properly, make sure the following software is installed
 - pip
 - gcc
 
-### Download FoD
-You can clone FoD from GEANT github repository. 
+### Download {{ product_name_short }}
+You can clone {{ product_name_short }} from GEANT github repository. 
 
     mkdir -p /srv/
     cd /srv/
-    git clone https://github.com/GEANT/FoD flowspy
+    git clone https://github.com/GEANT/{{ product_name_short }} flowspy
 
 ### Python-virtualenv
 
@@ -39,7 +39,7 @@ You can clone FoD from GEANT github repository.
     . /srv/venv/bin/activate
 
 ### Pip
-In order to install the required python packages for FoD you can use pip:
+In order to install the required python packages for {{ product_name_short }} you can use pip:
 
     . /srv/venv/bin/activate
     cd /srv/flowspy
@@ -57,7 +57,7 @@ If you are using mysql, you should create a database:
     cp urls.py.dist urls.py
 
 ### Device Configuration
-FoD generates and commits flowspec rules to a
+{{ product_name_short }} generates and commits flowspec rules to a
 device via netconf. You have to create an account
 with rw access to flowspec and set these credentials
 in settings.py. See Configuration for details.
@@ -80,7 +80,7 @@ Just make sure redis is installed and started
 
 ### mkdocs-based internal documentation
 Just make sure mkdocs is installed and prepare documentation with it
-(the documentation is optional and non-essential for the operation of FoD)
+(the documentation is optional and non-essential for the operation of {{ product_name_short }})
 
      # on DEBIAN/UBUNTU (>= DEBIAN 10/UBUNTU 18)
      apt-get install mkdocs
@@ -131,7 +131,7 @@ Here is an example configuration.
 
 
 ### Gunicorn
-FoD is served via gunicorn and is then proxied by Apache. If the above
+{{ product_name_short }} is served via gunicorn and is then proxied by Apache. If the above
 directory conventions have been followed so far, then your configuration
 should be:
 
diff --git a/doc/installation/v1.8/centos.md b/doc/installation/v1.8/centos.md
index 175626a94c88cb8cb86d6c49bbb3e72e96de5fec..12ecba7909a657a68f172ef11557321c5f5358cf 100644
--- a/doc/installation/v1.8/centos.md
+++ b/doc/installation/v1.8/centos.md
@@ -4,10 +4,10 @@ For the installation on CENTOS,
 there is ./install-centos.sh, currently mainly used for installation inside a Docker container.
 Currently, it understands several command line switches:
 
-- --fod_dir DIRNAME : specify FoD run-time directory, where FoD files are to be copied and to be run from 
-- --venv_dir DIRNAME : specify where Python virtualenv used by FoD will be located
-- --base-dir DIRNAME : specify base directory where FoD run-time directory and virtualenv directory will be sub directories
-- --here : do not copy FoD files into a separate FoD run-time directory, but instead install and make to run from current directory (probably not so useful for production)
+- --fod_dir DIRNAME : specify {{ product_name_short }} run-time directory, where {{ product_name_short }} files are to be copied and to be run from 
+- --venv_dir DIRNAME : specify where Python virtualenv used by {{ product_name_short }} will be located
+- --base-dir DIRNAME : specify base directory where {{ product_name_short }} run-time directory and virtualenv directory will be sub directories
+- --here : do not copy {{ product_name_short }} files into a separate {{ product_name_short }} run-time directory, but instead install and make to run from current directory (probably not so useful for production)
 
 - --systemd : enable Systemd support explicitly, by default will be enabled if Systemd is detected 
 - --no_systemd : disable Systemd support explicitly, even if Systemd is detected
@@ -17,36 +17,36 @@ Currently, it understands several command line switches:
 - --supversiord : enable Supversiord instead of Systemd, inside Docker Supversiord is now enabled by default in case no Systemd running s detected
 - --no_supversiord : disable Supversiord explicitly
 
-- --basesw : only install FoD dependencies (OS packages + Python Pip packages in virtualenv directory), do not install and setup FoD run-time directory (combines --basesw_os and --basesw_python)
-- --basesw_os : only install FoD OS dependencies 
-- --basesw_python : only install FoD Python/Pip dependencies in virtualenv directory
-- --fodproper : skip installing FoD dependencies, only install and setup FoD run-time directory 
+- --basesw : only install {{ product_name_short }} dependencies (OS packages + Python Pip packages in virtualenv directory), do not install and setup {{ product_name_short }} run-time directory (combines --basesw_os and --basesw_python)
+- --basesw_os : only install {{ product_name_short }} OS dependencies 
+- --basesw_python : only install {{ product_name_short }} Python/Pip dependencies in virtualenv directory
+- --fodproper : skip installing {{ product_name_short }} dependencies, only install and setup {{ product_name_short }} run-time directory 
 
 - --setup_admin_user : setup default admin 
 - --setup_admin_user5 : setup admin specified by user name, password, email address, peer name, first IP prefix 
 
 - --netconf : setup NETCONF specified by device address, TCP port, user name, password
-- --exabgp : setup exabgp specified by BGP nodeid, IP address, AS number, peer IP address, peer AS number (only for the new FoD version, currently available in git branch "feature/exabgp_support2")
+- --exabgp : setup exabgp specified by BGP nodeid, IP address, AS number, peer IP address, peer AS number (only for the new {{ product_name_short }} version, currently available in git branch "feature/exabgp_support2")
 
-## Systemd support / Starting FoD
+## Systemd support / Starting {{ product_name_short }}
 
-FoD installation currently supports Systemd, i.e., it installs Systemd startup files (./systemd/fod-\*.service) when a running Systemd is detected. Otherwise, in case of running inside docker Supversiord is enabled.
+{{ product_name_short }} installation currently supports Systemd, i.e., it installs Systemd startup files (./systemd/fod-\*.service) when a running Systemd is detected. Otherwise, in case of running inside docker Supversiord is enabled.
 Also, Supversiord can be enabled instead of Systemd explicitly (check options above)
 
 When not running under systemd,
-alternatives for startup of FoD 
+alternatives for startup of {{ product_name_short }} 
 are either
-./runfod-fg.sh for directly starting FoD processes together with Redis task broker 
+./runfod-fg.sh for directly starting {{ product_name_short }} processes together with Redis task broker 
 or
-./runfod-supervisord.sh for starting FoD processes and Redis task broker via Supervisord
+./runfod-supervisord.sh for starting {{ product_name_short }} processes and Redis task broker via Supervisord
 or
 the overall wrapper script ./runfod.sh which uses either of the startup method depending 
 on the choice selected by options for install-centos.sh.
 
-The Systemd support also includes an experimental e-mail notification for startup-failures of the FoD processes
+The Systemd support also includes an experimental e-mail notification for startup-failures of the {{ product_name_short }} processes
 
-## FoD run-time status 
+## {{ product_name_short }} run-time status 
 
-There is ./systemd/fod-status.sh, a generic script (not limited to Systemd) for determining the process status of FoD along with some further aspects, e.g., Database connection, NETCONF configuration and reachability
+There is ./systemd/fod-status.sh, a generic script (not limited to Systemd) for determining the process status of {{ product_name_short }} along with some further aspects, e.g., Database connection, NETCONF configuration and reachability
 
 
diff --git a/doc/installation/v1.8/debian_ubuntu.md b/doc/installation/v1.8/debian_ubuntu.md
index 789ec113e0b4278af2506f00ce1c63b31c4a3603..cab4cd786cf12144b66dcf2f11acbac59ad44125 100644
--- a/doc/installation/v1.8/debian_ubuntu.md
+++ b/doc/installation/v1.8/debian_ubuntu.md
@@ -5,10 +5,10 @@ there is ./install-debian.sh .
 
 It understands several command line switches:
 
-- --fod_dir DIRNAME : specify FoD run-time directory, where FoD files are to be copied and to be run from 
-- --venv_dir DIRNAME : specify where Python virtualenv used by FoD will be located
-- --base-dir DIRNAME : specify base directory where FoD run-time directory and virtualenv directory will be sub directories
-- --here : do not copy FoD files into a separate FoD run-time directory, but instead install and make to run from current directory (probably not so useful for production)
+- --fod_dir DIRNAME : specify {{ product_name_short }} run-time directory, where {{ product_name_short }} files are to be copied and to be run from 
+- --venv_dir DIRNAME : specify where Python virtualenv used by {{ product_name_short }} will be located
+- --base-dir DIRNAME : specify base directory where {{ product_name_short }} run-time directory and virtualenv directory will be sub directories
+- --here : do not copy {{ product_name_short }} files into a separate {{ product_name_short }} run-time directory, but instead install and make to run from current directory (probably not so useful for production)
 
 - --systemd : enable Systemd support explicitly, by default will be enabled if Systemd is detected 
 - --no_systemd : disable Systemd support explicitly, even if Systemd is detected
@@ -18,43 +18,43 @@ It understands several command line switches:
 - --supversiord : enable Supversiord instead of Systemd, inside Docker Supversiord is now enabled by default in case no Systemd running s detected
 - --no_supversiord : disable Supversiord explicitly
 
-- --basesw : only install FoD dependencies (OS packages + Python Pip packages in virtualenv directory), do not install and setup FoD run-time directory (combines --basesw_os and --basesw_python)
-- --basesw_os : only install FoD OS dependencies 
-- --basesw_python : only install FoD Python/Pip dependencies in virtualenv directory
-- --fodproper : skip installing FoD dependencies, only install and setup FoD run-time directory 
+- --basesw : only install {{ product_name_short }} dependencies (OS packages + Python Pip packages in virtualenv directory), do not install and setup {{ product_name_short }} run-time directory (combines --basesw_os and --basesw_python)
+- --basesw_os : only install {{ product_name_short }} OS dependencies 
+- --basesw_python : only install {{ product_name_short }} Python/Pip dependencies in virtualenv directory
+- --fodproper : skip installing {{ product_name_short }} dependencies, only install and setup {{ product_name_short }} run-time directory 
 
 - --setup_admin_user : setup default admin 
 - --setup_admin_user5 : setup admin specified by user name, password, email address, peer name, first IP prefix 
 
 - --netconf : setup NETCONF specified by device address, TCP port, user name, password
-- --exabgp : setup exabgp specified by BGP nodeid, IP address, AS number, peer IP address, peer AS number (only for the new FoD version, currently available in git branch "feature/exabgp_support2")
+- --exabgp : setup exabgp specified by BGP nodeid, IP address, AS number, peer IP address, peer AS number (only for the new {{ product_name_short }} version, currently available in git branch "feature/exabgp_support2")
 
-- --with-mta-postfix : if no MTA is installed, will try to install postfix (FoD operation is dependant on e-mail sending being available)
+- --with-mta-postfix : if no MTA is installed, will try to install postfix ({{ product_name_short }} operation is dependant on e-mail sending being available)
 
-- --with-db-sqlite : use a SQLite DB for FoD DB (not recommended for production, but easy for testing)
-- --with-db-mysql : will try to install MySQL and to setup FoD database in MySQL
-- --with-db-mariadb : will try to install MariaDB and to setup FoD database in MariaDB
-- --with-db-mysqllike : assumes that MySQL or MariaDB is installed and will try to setup FoD database based on this
+- --with-db-sqlite : use a SQLite DB for {{ product_name_short }} DB (not recommended for production, but easy for testing)
+- --with-db-mysql : will try to install MySQL and to setup {{ product_name_short }} database in MySQL
+- --with-db-mariadb : will try to install MariaDB and to setup {{ product_name_short }} database in MariaDB
+- --with-db-mysqllike : assumes that MySQL or MariaDB is installed and will try to setup {{ product_name_short }} database based on this
 
-## Systemd support / Starting FoD
+## Systemd support / Starting {{ product_name_short }}
 
-FoD installation currently supports Systemd, i.e., it installs Systemd startup files (./systemd/fod-\*.service) when a running Systemd is detected. Otherwise, in case of running inside docker Supversiord is enabled.
+{{ product_name_short }} installation currently supports Systemd, i.e., it installs Systemd startup files (./systemd/fod-\*.service) when a running Systemd is detected. Otherwise, in case of running inside docker Supversiord is enabled.
 Also, Supversiord can be enabled instead of Systemd explicitly (check options above)
 
 When not running under systemd,
-alternatives for startup of FoD 
+alternatives for startup of {{ product_name_short }} 
 are either
-./runfod-fg.sh for directly starting FoD processes together with Redis task broker 
+./runfod-fg.sh for directly starting {{ product_name_short }} processes together with Redis task broker 
 or
-./runfod-supervisord.sh for starting FoD processes and Redis task broker via Supervisord
+./runfod-supervisord.sh for starting {{ product_name_short }} processes and Redis task broker via Supervisord
 or
 the overall wrapper script ./runfod.sh which uses either of the startup method depending 
 on the choice selected by options for install-debian.sh.
 
-The Systemd support also includes an experimental e-mail notification for startup-failures of the FoD processes
+The Systemd support also includes an experimental e-mail notification for startup-failures of the {{ product_name_short }} processes
 
-## FoD run-time status 
+## {{ product_name_short }} run-time status 
 
-There is ./systemd/fod-status.sh, a generic script (not limited to Systemd) for determining the process status of FoD along with some further aspects, e.g., Database connection, NETCONF configuration and reachability
+There is ./systemd/fod-status.sh, a generic script (not limited to Systemd) for determining the process status of {{ product_name_short }} along with some further aspects, e.g., Database connection, NETCONF configuration and reachability
 
 
diff --git a/doc/installation/v1.8/docker.md b/doc/installation/v1.8/docker.md
index 4f7bdfc5de5b58338d2a57bd86688b8a86ab47ce..af451cdafd7c277d4d8080c393d67a27acd4d06d 100644
--- a/doc/installation/v1.8/docker.md
+++ b/doc/installation/v1.8/docker.md
@@ -18,8 +18,8 @@ The containers run `gunicorn`, `celeryd` and Redis - and use a SQLite database (
 # Building the Flowspy container
 
 First build your Flowspy container. The default (`Dockerfile` = `Dockerfile.fod.debian`) is a container which uses Debian and `supervisord`, but there are other options; `Dockerfile.fod.centos.\*` uses CENTOS 7, `Dockerfile.fod.centos.new` with `supervisord`, `Dockerfile.fod.centos.old` is left for compatibility without `supervisord`.
-`Dockerfile.fod.debian` and `Dockerfile.fod.centos.new` by default will split the installation of FoD during container build into 3 phases (OS dependencies, python/pip dependencies, FoD proper installation) to exploit Docker build cache for faster rebuilding.
-Moreover, `Dockerfile.fod.debian` and `Dockerfile.fod.centos.new` can be edited for uncommenting/commenting to switch more options: e.g., use `systemd` instead of `supervisord` or not splitting the FoD installation into 3 phases 
+`Dockerfile.fod.debian` and `Dockerfile.fod.centos.new` by default will split the installation of {{ product_name_short }} during container build into 3 phases (OS dependencies, python/pip dependencies, {{ product_name_short }} proper installation) to exploit Docker build cache for faster rebuilding.
+Moreover, `Dockerfile.fod.debian` and `Dockerfile.fod.centos.new` can be edited for uncommenting/commenting to switch more options: e.g., use `systemd` instead of `supervisord` or not splitting the {{ product_name_short }} installation into 3 phases 
 (first docker build will be a bit faster and the docker container building is more efficient, as the number of docker image layers is reduced, but subsequent build after some changes in code or settings will require nearly the same amount of time as the first build)
 
 > Although the examples below use CentOS, just replace `Dockerfile.centos.new` with `Dockerfile.debian` if you wish to use Debian instead.
diff --git a/doc/installation/v1.8/docker_extra.md b/doc/installation/v1.8/docker_extra.md
index f565745d8ff2c43bbe770572336580f84e5d316c..f318c4d30ecd9f449a767076ee806d92c38a3c7a 100644
--- a/doc/installation/v1.8/docker_extra.md
+++ b/doc/installation/v1.8/docker_extra.md
@@ -1,11 +1,11 @@
-# Extra Docker containers for testing FoD without router hardware
+# Extra Docker containers for testing {{ product_name_short }} without router hardware
 
 
 ### NETCONF test server docker container
 
 When no real NETCONF-enabled router supporting BGP FlowSpec is available, just for testing the NETCONF test server Docker container can be used:
 
-In FoD-cloned installation dir, e.g., residing in /srv/flowspy, go to sub directory `router-container`
+In {{ product_name_short }}-cloned installation dir, e.g., residing in /srv/flowspy, go to sub directory `router-container`
 
 ```
 docker build -t juniper .
@@ -18,11 +18,11 @@ To manually test NETCONF access to the test server, see `/router-container/run.t
 Now, find out IP address of the running test server container, e.g., by
 docker inspect "$DOCKERID_NETCONF" | grep IPAddress # find out DOCKERID_NETCONF, e.g. by "docker ps"
 
-In FoD test container (see above) configure this IP address of the NETCONF test server,
+In {{ product_name_short }} test container (see above) configure this IP address of the NETCONF test server,
 with NETCONF port 830, NETCONF_USER "netconf" and NETCONF_PASS "netconf"
 
-Now, FoD can submit FlowSpec rules which are actually only stored inside the NETCONF test server
-without an actual effect on any network, but FoD functionality of controlling rules can be tested. 
+Now, {{ product_name_short }} can submit FlowSpec rules which are actually only stored inside the NETCONF test server
+without an actual effect on any network, but {{ product_name_short }} functionality of controlling rules can be tested. 
 
 ### NETCONF test server docker container based on netconfd instead of netopeer
 
@@ -39,7 +39,7 @@ a basic a script for syncing NETCONF rules stored in the test NETCONF server
 to OpenFlow rules in Mininet simulating BGP FlowSpec rules (not all cases supported),
 SNMPd and a Perl SNMPd statistic collector script
 
-Yields a more complete simulation of a router for FoD.
+Yields a more complete simulation of a router for {{ product_name_short }}.
 
 - ./Dockerfiles.d/Dockerfile.vnet_router1 : based on netopeer2
 - ./Dockerfiles.d/Dockerfile.vnet_router2 : similar to Dockerfile.vnet_router1, but will use netconfd (DEBIAN package) instead of CESNET's netopeer NETCONF server
diff --git a/doc/installation/v1.8/generic.md b/doc/installation/v1.8/generic.md
index 85cba8e876407c3441eec9416de9570674226944..c23f56593564946b224093c5c9162e40f7ff6c49 100644
--- a/doc/installation/v1.8/generic.md
+++ b/doc/installation/v1.8/generic.md
@@ -1,6 +1,6 @@
-# Installing FoD v1.7 Generic
+# Installing {{ product_name_short }} v1.7 Generic
 
-This guide provides general information about the installation of FoD. In case you use Debian/UBUNTU, we provide detailed instructions for the installation.
+This guide provides general information about the installation of {{ product_name_short }}. In case you use Debian/UBUNTU, we provide detailed instructions for the installation.
 
 Also it assumes that installation is carried out in `/srv/flowspy`
 directory. If other directory is to be used, please change the
@@ -12,7 +12,7 @@ TO UPDATE
 ## Requirements
 
 ### System Requirements
-In order to install FoD properly, make sure the following software is installed on your computer.
+In order to install {{ product_name_short }} properly, make sure the following software is installed on your computer.
 
 - apache 2
 - libapache2-mod-proxy-html
@@ -25,12 +25,12 @@ In order to install FoD properly, make sure the following software is installed
 - pip
 - gcc
 
-### Download FoD
-You can clone FoD from GEANT github repository. 
+### Download {{ product_name_short }}
+You can clone {{ product_name_short }} from GEANT github repository. 
 
     mkdir -p /srv/
     cd /srv/
-    git clone https://github.com/GEANT/FoD flowspy
+    git clone https://github.com/GEANT/{{ product_name_short }} flowspy
 
 ### Python-virtualenv
 
@@ -39,7 +39,7 @@ You can clone FoD from GEANT github repository.
     . /srv/venv/bin/activate
 
 ### Pip
-In order to install the required python packages for FoD you can use pip:
+In order to install the required python packages for {{ product_name_short }} you can use pip:
 
     . /srv/venv/bin/activate
     cd /srv/flowspy
@@ -57,7 +57,7 @@ If you are using mysql, you should create a database:
     cp urls.py.dist urls.py
 
 ### Device Configuration
-FoD generates and commits flowspec rules to a
+{{ product_name_short }} generates and commits flowspec rules to a
 device via netconf. You have to create an account
 with rw access to flowspec and set these credentials
 in settings.py. See Configuration for details.
@@ -80,7 +80,7 @@ Just make sure redis is installed and started
 
 ### mkdocs-based internal documentation
 Just make sure mkdocs is installed and prepare documentation with it
-(the documentation is optional and non-essential for the operation of FoD)
+(the documentation is optional and non-essential for the operation of {{ product_name_short }})
 
      # on DEBIAN/UBUNTU (>= DEBIAN 10/UBUNTU 18)
      apt-get install mkdocs
@@ -131,7 +131,7 @@ Here is an example configuration.
 
 
 ### Gunicorn
-FoD is served via gunicorn and is then proxied by Apache. If the above
+{{ product_name_short }} is served via gunicorn and is then proxied by Apache. If the above
 directory conventions have been followed so far, then your configuration
 should be:
 
diff --git a/doc/prerequisites/generic.md b/doc/prerequisites/generic.md
index 2ce87f193578e3204b1a36d0a8f1c0ff41beff6a..0a214318b450cb6e636ca97eb06c3994ae1a10dc 100644
--- a/doc/prerequisites/generic.md
+++ b/doc/prerequisites/generic.md
@@ -1,6 +1,6 @@
 # Prerequistes
 
-Operation of FoD requires a router which is 
+Operation of {{ product_name_short }} requires a router which is 
 
 * BGP FlowSpec-capable and 
 
@@ -23,7 +23,7 @@ example result of a NETCONF ``get_config`` query on a router with one IPv4-based
 
         <flow>
           <route>
-            <name>FoD_testrule1_529HMW</name>
+            <name>{{ product_name_short }}_testrule1_529HMW</name>
             <then>
               <rate-limit>10000k</rate-limit>
             </then>
@@ -43,7 +43,7 @@ example result of a NETCONF ``get_config`` query on a router with one IPv4-based
           <name>inet6.0</name>
           <flow>
             <route>
-              <name>FoD_testipv6_MPSKD8</name>
+              <name>{{ product_name_short }}_testipv6_MPSKD8</name>
               <then>
                 <discard/>
               </then>
diff --git a/mkdocs.yml b/mkdocs.yml
index 5b7e4f6c73cf735aef9e2dc894e9c3f6b18455e0..0655e7cd40acf56b460d9e28e525e36cbefce0f6 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -7,6 +7,14 @@ site_dir: static/site
 docs_dir: doc
 #theme: readthedocs
 #pages:
+plugins:
+        - macros:
+extra:
+        test1: test1 value
+        product_name1: 'Firewall On Demand'
+        product_name_short1: 'FoD'
+        product_name: 'Gatekeeper'
+        product_name_short: 'Gkr'
 nav:
     - 'Introduction': 'index.md'
     - 'Prerequisites': 'prerequisites/generic.md'
diff --git a/requirements.txt b/requirements.txt
index 9b2fc0b5c7473b5250701d089e5cd8a7f30a2e76..c502c367158a60e70fb6085edbe361fbb0a635b9 100644
--- a/requirements.txt
+++ b/requirements.txt
@@ -40,3 +40,5 @@ pytest-django==4.4.0
 psutil
 longerusername
 intervaltree
+mkdocs
+mkdocs-macros-plugin