Document how a previous SLURM version can be applied

diff --git a/docs/slurm.md b/docs/slurm.md
index 1810c63929efa0d39bbe3d8acbff275075c397a7..ddfbc7d66da1fd1ac9db7ffe06ff808ead5c8ce0 100644 (file)
--- a/docs/slurm.md
+++ b/docs/slurm.md
@@ -11,7 +11,7 @@ There are reasons why you might legitimately want to modify the RPKI assertions
 - To assert the validity of private IP addresses and/or AS numbers for local use. (Since they are outside of the scope of the global RPKI.)
 - To override temporarily incorrect or outdated global RPKI data.
 
-The "Simplified Local Internet Number Resource Management with the RPKI" (SLURM) is a [standard](https://tools.ietf.org/html/rfc8416) means to accomplish this. In a nutshell, it's just a bunch of JSON files with which you can filter out or append arbitrary ROAs to Fort's RTR payload.
+The "Simplified Local Internet Number Resource Management with the RPKI" (SLURM) is a [standard](https://tools.ietf.org/html/rfc8416) means to accomplish this. In a nutshell, it's just a bunch of JSON files with which you can filter out or append arbitrary ROAs to FORT validator's RTR payload.
 
 Note that, with the exception of the following section, most of this document is just a summary of [RFC 8416](https://tools.ietf.org/html/rfc8416). You can find more details there.
 
@@ -21,9 +21,9 @@ The SLURM files are defined by the [`--slurm`](usage.html#--slurm) flag. If the
 
 None of the entries of the SLURM configuration are allowed to collide with each other. If there is a collision, the overall SLURM configuration is invalidated.
 
-Fort reloads the SLURM files during every validation cycle. If the new configuration is invalid, **it is treated as nonexistent**. Note that this means that an isolated mistake will temporarily drop all your SLURM overrides. This is intended to change in a future revision of Fort, in which the validator will fall back to the previous valid SLURM configuration on error.
+FORT validator reloads the SLURM files during every validation cycle. If the new configuration is invalid (due to either a syntax or content error) the validator will fall back to the previous valid SLURM configuration, and will log a message to indicate this action.
 
-## SLURM File Definition
+## File Definition
 
 ### Root
 
@@ -55,7 +55,7 @@ The root object contains a `slurmVersion` field (which, for now, must be set to
 {
        "prefix": <IP prefix>,
        "asn": <AS number>,
-       "comment": <Explanatory comment; ignored by Fort for now>
+       "comment": <Explanatory comment>
 }
 ```
 
@@ -73,7 +73,7 @@ One of `prefix` and `asn` can be absent. On absence, any prefix matches `prefix`
 {
        "asn": <AS number>,
        "SKI": <Base64 of some SKI>,
-       "comment": <Explanatory comment; ignored by Fort for now>
+       "comment": <Explanatory comment>
 }
 ```
 
@@ -92,11 +92,11 @@ One of `asn` and `SKI` can be absent. On absence, any AS number matches `asn`, a
        "prefix": <IP prefix>,
        "asn": <AS number>,
        "maxPrefixLength": <Prefix length>
-       "comment": <Explanatory comment; ignored by Fort for now>
+       "comment": <Explanatory comment>
 }
 ```
 
-Will force Fort into believing that the [`prefix`, `asn`, `maxPrefixLength`] ROA validated successfully.
+Will force the validator into believing that the [`prefix`, `asn`, `maxPrefixLength`] ROA validated successfully.
 
 `prefix` and `asn` are mandatory, `maxPrefixLength` and `comment` are not. `maxPrefixLength` defaults to `prefix`'s length.
 
@@ -109,15 +109,15 @@ Will force Fort into believing that the [`prefix`, `asn`, `maxPrefixLength`] ROA
        "asn": <AS number>,
        "SKI": <Base64 of some SKI>,
        "routerPublicKey": <Base64 of some public key>,
-       "comment": <Explanatory comment; ignored by Fort for now>
+       "comment": <Explanatory comment>
 }
 ```
 
-Will force Fort into believing that the [`asn`, `SKI`, `routerPublicKey`] Router Key validated successfully.
+Will force the validator into believing that the [`asn`, `SKI`, `routerPublicKey`] Router Key validated successfully.
 
 Only `comment` isn't mandatory, the rest [`asn`, `SKI`, `routerPublicKey`] are mandatory.
 
-## SLURM File Example
+## File Example
 
 ```
 {

diff --git a/man/fort.8 b/man/fort.8
index ffeaa86079112446e7ac297b766d290833be8071..79dcf5f0e17accbc6625ca7d37ab0f5063ae2830 100644 (file)
--- a/man/fort.8
+++ b/man/fort.8
@@ -296,14 +296,20 @@ hierarchy." (RFC 6481))
 .RS 4
 Path to the SLURM FILE or SLURMs DIRECTORY.
 .P
-In case a DIRECTORY is set, the files with extension '\fI.slurm\fR' will be the
-ones considered as SLURM files and FORT will use them.
-.P
 The SLURM definition is from RFC 8416. SLURM stands for "Simplified Local
 Internet Number Resource Management with the RPKI", basically is a document
 that can override (either as a filter or adding assertions) the global RPKI
 repository data fetched by FORT; potentially useful for network operators.
 .P
+In case a DIRECTORY is set, the files with extension '\fI.slurm\fR' will be the
+ones considered as SLURM files and FORT will use them.
+.P
+The configured SLURM path (either \fIFILE\fR or \fIDIRECTORY\fR) will be read
+each time a new validation cycle begins. If there's a syntax or content error,
+the last valid version of the SLURM will be applied (if there's one) and a
+message will be logged to indicate this action. Note that all this will happen
+only if \fI--mode=server\fR and \fI--slurm\fR is configured.
+.P
 A basic example of a SLURM file can be seen in this manual at the
 \fBEXAMPLES\fR section (it's almost the same as the one in RFC 8416).
 .P