This is yet another operator-quality-of-life small feature request:
The route server policy textual representation file could have simple metadata in it, preferably (IMHO) in a non-visible way such as some specific HTML tag (in head? not sure if suitable ones exist, maybe no?) or simply as a HTML comment.
Suggested metadata:
Date when the policy file was generated.
And possibly, more contentious metadata:
Version of arouteserver that generated this HTML file. Specifically I want to mention that currently this file is completely "whitelabel" in that it does not mention "arouteserver" and staying neutral would be good. If version is added, especially together with product name, this feature would be lost so adding this should be thought out carefully.
Changed timestamp of source file(s) used for generation of this file, such as the arouteserver configuration file. Not sure if this is useful since there might be many files and it'd just be more work. It might help in some obscure troubleshooting but I personally do not see the use for it.
Personally I'd be fine with just the generation timestamp.
This metadata could help in pinpointing specific versions of the policy. Users may have these cached or lying around for whatever -- usually bad -- reasons.
It might affect automated workflows where the policy files are compared for whatever reason as that metadata would change often.
I could not say if such use cases exist in the real world and this change would probably be net-beneficial to operators.
This is yet another operator-quality-of-life small feature request:
The route server policy textual representation file could have simple metadata in it, preferably (IMHO) in a non-visible way such as some specific HTML tag (in head? not sure if suitable ones exist, maybe no?) or simply as a HTML comment.
Suggested metadata:
Personally I'd be fine with just the generation timestamp.
This metadata could help in pinpointing specific versions of the policy. Users may have these cached or lying around for whatever -- usually bad -- reasons.
It might affect automated workflows where the policy files are compared for whatever reason as that metadata would change often.
I could not say if such use cases exist in the real world and this change would probably be net-beneficial to operators.