From f66adc0b65115050e0bd65f74dcc618a5416015a Mon Sep 17 00:00:00 2001 From: irl Date: Wed, 22 Apr 2026 11:54:58 +0100 Subject: [PATCH] feat: adds some draft policies --- .forgejo/workflows/publish.yaml | 2 - policies/Justfile | 8 + policies/biblio.json | 8 + policies/copyright.include | 3 + policies/header.include | 30 + policies/password_auth.bs | 147 ++ policies/public_wifi.bs | 61 + static/policies/password_auth/index.html | 2281 ++++++++++++++++++++++ static/policies/public_wifi/index.html | 2172 ++++++++++++++++++++ 9 files changed, 4710 insertions(+), 2 deletions(-) create mode 100644 policies/Justfile create mode 100644 policies/biblio.json create mode 100644 policies/copyright.include create mode 100644 policies/header.include create mode 100644 policies/password_auth.bs create mode 100644 policies/public_wifi.bs create mode 100644 static/policies/password_auth/index.html create mode 100644 static/policies/public_wifi/index.html diff --git a/.forgejo/workflows/publish.yaml b/.forgejo/workflows/publish.yaml index b2f9b5f..171faf2 100644 --- a/.forgejo/workflows/publish.yaml +++ b/.forgejo/workflows/publish.yaml @@ -16,8 +16,6 @@ jobs: submodules: true - uses: actions/setup-node@v4 - run: npm install -g bnycdn - - name: Install bikeshed - run: pip install bikeshed - name: Setup Hugo uses: https://guardianproject.dev/actions/actions-hugo@v3 with: diff --git a/policies/Justfile b/policies/Justfile new file mode 100644 index 0000000..d4f76ab --- /dev/null +++ b/policies/Justfile @@ -0,0 +1,8 @@ +update: + #!/usr/bin/env bash + for file in *.bs; do + specname="${file%.bs}" + mkdir -p "../static/policies/${specname}/" + bikeshed spec "${file}" "../static/policies/${specname}/index.html" + done + diff --git a/policies/biblio.json b/policies/biblio.json new file mode 100644 index 0000000..8376f1d --- /dev/null +++ b/policies/biblio.json @@ -0,0 +1,8 @@ +{ + "EFF-DICE": { + "href": "https://www.eff.org/dice", + "title": "EFF Dice-Generated Passphrases", + "publisher": "Electronic Frontier Foundation", + "source": "https://www.eff.org/dice" + } +} diff --git a/policies/copyright.include b/policies/copyright.include new file mode 100644 index 0000000..41a9607 --- /dev/null +++ b/policies/copyright.include @@ -0,0 +1,3 @@ +© SR2 Communications Limited. +This document is licensed under CC BY 4.0. + \ No newline at end of file diff --git a/policies/header.include b/policies/header.include new file mode 100644 index 0000000..6241d72 --- /dev/null +++ b/policies/header.include @@ -0,0 +1,30 @@ + + + + + [TITLE] + + + + +
+

TLP:CLEAR

+ SR2 Communications Limited +

[TITLE]

+

Draft for Approval by Company Directors, + [DATE] +

+
+
+

+
+
+ +
+
+ + +
\ No newline at end of file diff --git a/policies/password_auth.bs b/policies/password_auth.bs new file mode 100644 index 0000000..1d44e32 --- /dev/null +++ b/policies/password_auth.bs @@ -0,0 +1,147 @@ +

Passwords and Authentication Policy

+
+Status: DREAM
+Local Boilerplate: header yes, copyright yes, defaults yes
+Boilerplate: status no
+TR: https://www.sr2.uk/policies/password-auth/
+Shortname: password-auth
+Complain About: accidental-2119 yes
+No Editor: true
+!Version: 1.0
+Abstract: A policy defining an effective authentication management procedures when conducting company-related business.
+
+ +# Objective # {#objective} + +This policy defines an effective authentication management procedures when conducting company-related business and +includes the: + +* issuing and selection of strong authentication methods and credentials; +* protection of secret authentication credentials; +* frequency of change in terms of authentication credentials; +* reporting of any suspected breach or lost authentication credentials; +* use of authentication methods with third party systems (including cloud technology). + +Authentication is a key method of securing our information – choosing weak authentication methods, or failing to keep +the authentication credentials secure, places the confidentiality of our data at risk. + +# Scope # {#scope} + +The scope of the policy covers all individuals either employed or contracted to work with or for the company, either +in-office or remotely. + +# Definitions # {#definitions} + +: Authentication method +:: Any method by which a user may authenticate themselves in order to gain access to a location, data or service, such + as text entry (e.g. passwords, passphrases, PINs), biometrics (e.g. fingerprints), etc. +: Authentication credentials +:: The specific data or information used by a user to authenticate themselves, including but not limited to passwords, + passphrases, PINs, and biometric data. +: Multi-Factor Authentication (MFA) +:: An authentication method that requires the user to provide two or more verification factors to gain access, such as + something they know (e.g., password), something they have (e.g., a security token or mobile device), and/or + something they are (e.g., biometric data). +: Cloud-based system +:: A service or platform hosted over the internet that allows users to access data, applications and services remotely. +: Password manager +:: A software product used for the secure storage of passwords, which must be approved for use, and includes functions + for generating strong passwords compliant with this policy. + +# Policy # {#policy} + +Authentication method covers any methods by which a user may authenticate themselves in order to gain access to a +location, data or service, such as text entry (e.g. passwords, passphrases, PINs), biometrics (e.g. fingerprints), etc. +The company ensures that authentication credentials are kept confidential by: + +- storing authentication credentials in a secure manner; +- changing manufacturer default authentication credentials and disabling guest accounts on all equipment; +- issuing new users with temporary authentication credentials, which must be changed at first login to a stronger + alternative (defined later); +- authentication credentials issued to new users are done so in a secure manner (e.g. never in clear text via an email); +- changing all multi-user credentials (e.g. for communal equipment) used by an employee in the event that their + employment ends; +- ensuring that access to user credentials is limited to ICT administrators for the purpose of resetting, revoking or + problem resolution – authentication methods may only be reset once the identity of the user has been verified; +- locking accounts after 5 failed login attempts in order to dissuade brute-forcing attempts; +- training staff in the use of digital password managers, and the risks of storing passwords in any other form (such as + a notebook at their workstation, or Post-It note). + +Users must ensure that they do all they can to maintain the confidentiality of their authentication credentials by +never: + +- using company authentication credentials for any other account they hold (including personal accounts such as home + utilities, email, online shopping services, etc); +- having a physical copy of their credentials; +- using a non-approved method for password generation; +- entering authentication credentials on non-company equipment (for example, home or public access PCs); +- revealing authentication credentials to anyone, including line managers, unless relaying information on temporary + credentials which are changed immediately upon next login. This includes never + sharing authentication credentials with co-workers (e.g. whilst on annual leave); +- discussing authentication credentials in front of others. + +## Password Authentication ## {#passwords} + +Many services and policies only allow for password authentication methods, and so they are given a special focus here. +Strong passwords MUST be used for authentication. The company defines a strong password as one generated by one of two +processes: random string generation by a password manager or using diceware [[!EFF-DICE]]. + +Where a password is to be stored in a password manager, it MUST be randomly generated by the password manager with the +parameters: + +- having a minimum number of 14 characters in length; +- using longer passwords where permitted by the service; +- including a mixture of numbers, upper and lower case letters, and special characters. + +Where special characters are not possible due to technical restrictions, the minimum length is 20 characters. + +For the avoidance of doubt, weak passwords must never be used. Weak, text-based authentication credentials generally +have one or more of the following characteristics: + +- credential is the same, or partly the same, as the username; +- names of family members, friends, or pets are used; +- personal information about yourself or family members which can be easily found from social networking sites, + including date of birth, phone number, street name, etc.; +- consecutive alphanumeric characters or keys on the keyboard, such as ‘abc123’ or ‘qwerty’; +- dictionary words including the inclusion of a number or character at the start or end or substituting numbers or + punctuation for letters, for example, ‘P@55w0rd’; +- a known word from any language (which may not be in a dictionary). + +For passwords that are intended to be memorised, the MUST be generated using diceware. The above restrictions likely +will not be met using this method as the intention is to provide a strong password that is easy to remember, and the +strength comes from the underlying dice rolls. Any other method of generating a passphrase MUST NOT be used even if it +results in one that bears similarity to a diceware-generated passphrase. + +Memorised passphrases generated with diceware SHOULD be used for: + +- end-user device login passphrase; +- password manager decryption passphrase. + +## Multi-Factor Authentication ## {#mfa} + +Wherever the option is offered by a given service or piece of software, multi-factor authentication is to be used (e.g. +a fingerprint and a passphrase, or a voice sample, PIN and verification SMS). + +Where a hardware token is in use to authenticate to a system without a password, the token itself MUST be secured with +a memorised PIN of at least 6 digits. + +## Credentials for Cloud-Based Systems and Online Portals ## {#cloud} + +It is to be remembered that the company makes use of cloud-based technology and online portals, which may not enforce +strong authentication credentials. It is therefore up to the individual to ensure a good authentication regime is +maintained, which is as strong as that used within the organisation. In line with the company’s "Internet Use +Policy", users shall: + +- not create an online account for business purposes without authorisation from a director; +- advise a director when there is no longer a need to have the online account in order to ensure that it is + removed. + +## Credential Compromise Policy ## {#compromise} + +In the event of a credential compromise, users SHALL take immediate action to secure the account by resetting or +invalidating the credentials and report the incident to a director as soon as practical. +It is policy that any password compromise event will be shared with CiviCERT members via the MISP platform to allow for +shared learning from the incident. +Directors will be responsible for determining if a data breach notification is necessary to our clients or to the +Information Commissioners Office. + diff --git a/policies/public_wifi.bs b/policies/public_wifi.bs new file mode 100644 index 0000000..997c05f --- /dev/null +++ b/policies/public_wifi.bs @@ -0,0 +1,61 @@ +

Public WiFi Policy

+
+Status: DREAM
+Local Boilerplate: header yes, copyright yes
+Boilerplate: status no
+TR: https://www.sr2.uk/policies/public-wifi/
+Shortname: public-wifi
+Complain About: accidental-2119 yes
+No Editor: true
+!Version: 1.0
+Abstract: A policy governing staff and contractor use of public WiFi networks when accessing company data.
+
+ +# Objective # {#objective} + +The company approves remote working to work-related cloud services and work email accounts, as long as the devices used +to access these have been sanctioned by the company. Using public WiFi to conduct business, without the necessary +safeguards, places our data at risk of theft. The purpose of this policy is to provide the framework for those +safeguards. + +# Scope # {#scope} + +The scope of the policy covers all individuals either employed or contracted to work with, or for, the company, either +on a company site or remotely. + +# Definitions # {#definitions} + +: Public WiFi Network +:: Any wireless network access provided by a third party, such as hotels, cafes, airports, or public hotspots, that is + open to public or unvetted access. For the purpose of this policy, eduroam connections other than those on an SR2 + managed site are to be considered Public WiFi Networks. +: Sanctioned Device +:: A device (e.g., laptop, tablet, smartphone) that has been approved and provisioned by the + company for business use, with appropriate security configurations and software installed. + +# Policy # {#policy} + +Devices that are not sanctioned by the company, including home PCs or public access PCs, MUST NOT be used to access +company cloud services, data, or email accounts. + +Though the company takes every effort to ensure that sanctioned devices are adequately protected, the individual MUST +ensure that, before connecting to the Wi-Fi network, the device has: + +- up-to-date antivirus and antispyware software; +- a firewall that is activated and configured to company requirements (i.e. the settings have not been changed) since + the device was configured; +- all software (including the Web browser) is current with automatic updating; +- file sharing (e.g. SMB) is switched off. + +For security reasons staff and contractors MUST: + +- consider if mobile phone tethering is available and use this as the first choice; +- consider delaying transmission of information until at a secure location; +- not follow prompts to update software whilst connected to a public network; +- not rely on the encryption provided by the Public WiFi Network (e.g. WPA) to protect company data; +- ensure that an end-to-end encrypted connection is established and the user has been trained in setting up + such a connection for each service to be used (for the avoidance of doubt, TLS is considered to be end-to-end + providing that the certificate presented by the server is validated); +- ensure that URLs in Web browsers are showing the correct Web addresses in case a criminal has hijacked the Wireless + Access Point and is forwarding traffic to their site; +- keep all information secure, including restricting the view of the screen from any unauthorised person(s); diff --git a/static/policies/password_auth/index.html b/static/policies/password_auth/index.html new file mode 100644 index 0000000..a6f7841 --- /dev/null +++ b/static/policies/password_auth/index.html @@ -0,0 +1,2281 @@ + + + + Passwords and Authentication Policy + + + + + + + + + + + + + +
+

TLP:CLEAR

+ + SR2 Communications Limited + +

Passwords and Authentication Policy

+

Draft for Approval by Company Directors, + 22 April 2026 +

+
+
+
Latest published version: +
https://www.sr2.uk/policy/password-auth/ +
Version: +
1.0 +
+
+
+

© SR2 Communications Limited. +This document is licensed under CC BY 4.0. +

+
+
+
+

Abstract

+

A policy defining an effective authentication management procedures when conducting company-related business.

+
+
+ +
+

1. Objective

+

This policy defines an effective authentication management procedures when conducting company-related business and +includes the:

+
    +
  • +

    issuing and selection of strong authentication methods and credentials;

    +
  • +

    protection of secret authentication credentials;

    +
  • +

    frequency of change in terms of authentication credentials;

    +
  • +

    reporting of any suspected breach or lost authentication credentials;

    +
  • +

    use of authentication methods with third party systems (including cloud technology).

    +
+

Authentication is a key method of securing our information – choosing weak authentication methods, or failing to keep +the authentication credentials secure, places the confidentiality of our data at risk.

+

2. Scope

+

The scope of the policy covers all individuals either employed or contracted to work with or for the company, either +in-office or remotely.

+

3. Definitions

+
+
Authentication method +
+

Any method by which a user may authenticate themselves in order to gain access to a location, data or service, such + as text entry (e.g. passwords, passphrases, PINs), biometrics (e.g. fingerprints), etc.

+
Authentication credentials +
+

The specific data or information used by a user to authenticate themselves, including but not limited to passwords, + passphrases, PINs, and biometric data.

+
Multi-Factor Authentication (MFA) +
+

An authentication method that requires the user to provide two or more verification factors to gain access, such as + something they know (e.g., password), something they have (e.g., a security token or mobile device), and/or + something they are (e.g., biometric data).

+
Cloud-based system +
+

A service or platform hosted over the internet that allows users to access data, applications and services remotely.

+
Password manager +
+

A software product used for the secure storage of passwords, which must be approved for use, and includes functions + for generating strong passwords compliant with this policy.

+
+

4. Policy

+

Authentication method covers any methods by which a user may authenticate themselves in order to gain access to a +location, data or service, such as text entry (e.g. passwords, passphrases, PINs), biometrics (e.g. fingerprints), etc. +The company ensures that authentication credentials are kept confidential by:

+
    +
  • +

    storing authentication credentials in a secure manner;

    +
  • +

    changing manufacturer default authentication credentials and disabling guest accounts on all equipment;

    +
  • +

    issuing new users with temporary authentication credentials, which must be changed at first login to a stronger +alternative (defined later);

    +
  • +

    authentication credentials issued to new users are done so in a secure manner (e.g. never in clear text via an email);

    +
  • +

    changing all multi-user credentials (e.g. for communal equipment) used by an employee in the event that their +employment ends;

    +
  • +

    ensuring that access to user credentials is limited to ICT administrators for the purpose of resetting, revoking or +problem resolution – authentication methods may only be reset once the identity of the user has been verified;

    +
  • +

    locking accounts after 5 failed login attempts in order to dissuade brute-forcing attempts;

    +
  • +

    training staff in the use of digital password managers, and the risks of storing passwords in any other form (such as +a notebook at their workstation, or Post-It note).

    +
+

Users must ensure that they do all they can to maintain the confidentiality of their authentication credentials by +never:

+
    +
  • +

    using company authentication credentials for any other account they hold (including personal accounts such as home +utilities, email, online shopping services, etc);

    +
  • +

    having a physical copy of their credentials;

    +
  • +

    using a non-approved method for password generation;

    +
  • +

    entering authentication credentials on non-company equipment (for example, home or public access PCs);

    +
  • +

    revealing authentication credentials to anyone, including line managers, unless relaying information on temporary +credentials which are changed immediately upon next login. This includes never +sharing authentication credentials with co-workers (e.g. whilst on annual leave);

    +
  • +

    discussing authentication credentials in front of others.

    +
+

4.1. Password Authentication

+

Many services and policies only allow for password authentication methods, and so they are given a special focus here. +Strong passwords MUST be used for authentication. The company defines a strong password as one generated by one of two +processes: random string generation by a password manager or using diceware [EFF-DICE].

+

Where a password is to be stored in a password manager, it MUST be randomly generated by the password manager with the +parameters:

+
    +
  • +

    having a minimum number of 14 characters in length;

    +
  • +

    using longer passwords where permitted by the service;

    +
  • +

    including a mixture of numbers, upper and lower case letters, and special characters.

    +
+

Where special characters are not possible due to technical restrictions, the minimum length is 20 characters.

+

For the avoidance of doubt, weak passwords must never be used. Weak, text-based authentication credentials generally +have one or more of the following characteristics:

+
    +
  • +

    credential is the same, or partly the same, as the username;

    +
  • +

    names of family members, friends, or pets are used;

    +
  • +

    personal information about yourself or family members which can be easily found from social networking sites, +including date of birth, phone number, street name, etc.;

    +
  • +

    consecutive alphanumeric characters or keys on the keyboard, such as ‘abc123’ or ‘qwerty’;

    +
  • +

    dictionary words including the inclusion of a number or character at the start or end or substituting numbers or +punctuation for letters, for example, ‘P@55w0rd’;

    +
  • +

    a known word from any language (which may not be in a dictionary).

    +
+

For passwords that are intended to be memorised, the MUST be generated using diceware. The above restrictions likely +will not be met using this method as the intention is to provide a strong password that is easy to remember, and the +strength comes from the underlying dice rolls. Any other method of generating a passphrase MUST NOT be used even if it +results in one that bears similarity to a diceware-generated passphrase.

+

Memorised passphrases generated with diceware SHOULD be used for:

+
    +
  • +

    end-user device login passphrase;

    +
  • +

    password manager decryption passphrase.

    +
+

4.2. Multi-Factor Authentication

+

Wherever the option is offered by a given service or piece of software, multi-factor authentication is to be used (e.g. +a fingerprint and a passphrase, or a voice sample, PIN and verification SMS).

+

Where a hardware token is in use to authenticate to a system without a password, the token itself MUST be secured with +a memorised PIN of at least 6 digits.

+

4.3. Credentials for Cloud-Based Systems and Online Portals

+

It is to be remembered that the company makes use of cloud-based technology and online portals, which may not enforce +strong authentication credentials. It is therefore up to the individual to ensure a good authentication regime is +maintained, which is as strong as that used within the organisation. In line with the company’s "Internet Use +Policy", users shall:

+
    +
  • +

    not create an online account for business purposes without authorisation from a director;

    +
  • +

    advise a director when there is no longer a need to have the online account in order to ensure that it is +removed.

    +
+

4.4. Credential Compromise Policy

+

In the event of a credential compromise, users SHALL take immediate action to secure the account by resetting or +invalidating the credentials and report the incident to a director as soon as practical. +It is policy that any password compromise event will be shared with CiviCERT members via the MISP platform to allow for +shared learning from the incident. +Directors will be responsible for determining if a data breach notification is necessary to our clients or to the +Information Commissioners Office.

+
+
+

+ Conformance

+

+ Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. + The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” + in the normative parts of this document + are to be interpreted as described in RFC 2119. + However, for readability, + these words do not appear in all uppercase letters in this specification. + +

+

+ All of the text of this specification is normative + except sections explicitly marked as non-normative, examples, and notes. [RFC2119] + +

+

+ Examples in this specification are introduced with the words “for example” + or are set apart from the normative text with class="example", like this: + +

+
+ This is an example of an informative example. +
+

+ Informative notes begin with the word “Note” + and are set apart from the normative text with class="note", like this: + +

+

+ Note, this is an informative note.

+
+ +

References

+

Normative References

+
+
[EFF-DICE] +
EFF Dice-Generated Passphrases. URL: https://www.eff.org/dice +
[RFC2119] +
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc2119 +
\ No newline at end of file diff --git a/static/policies/public_wifi/index.html b/static/policies/public_wifi/index.html new file mode 100644 index 0000000..bd4480d --- /dev/null +++ b/static/policies/public_wifi/index.html @@ -0,0 +1,2172 @@ + + + + Public WiFi Policy + + + + + + + + + + + + + +
+

TLP:CLEAR

+ + SR2 Communications Limited + +

Public WiFi Policy

+

Draft for Approval by Company Directors, + 22 April 2026 +

+
+
+
Latest published version: +
https://www.sr2.uk/policy/public-wifi/ +
Version: +
1.0 +
+
+
+

© SR2 Communications Limited. +This document is licensed under CC BY 4.0. +

+
+
+
+

Abstract

+

A policy governing staff and contractor use of public WiFi networks when accessing company data.

+
+
+ +
+

1. Objective

+

The company approves remote working to work-related cloud services and work email accounts, as long as the devices used +to access these have been sanctioned by the company. Using public WiFi to conduct business, without the necessary +safeguards, places our data at risk of theft. The purpose of this policy is to provide the framework for those +safeguards.

+

2. Scope

+

The scope of the policy covers all individuals either employed or contracted to work with, or for, the company, either +on a company site or remotely.

+

3. Definitions

+
+
Public WiFi Network +
+

Any wireless network access provided by a third party, such as hotels, cafes, airports, or public hotspots, that is + open to public or unvetted access. For the purpose of this policy, eduroam connections other than those on an SR2 + managed site are to be considered Public WiFi Networks.

+
Sanctioned Device +
+

A device (e.g., laptop, tablet, smartphone) that has been approved and provisioned by the + company for business use, with appropriate security configurations and software installed.

+
+

4. Policy

+

Devices that are not sanctioned by the company, including home PCs or public access PCs, MUST NOT be used to access +company cloud services, data, or email accounts.

+

Though the company takes every effort to ensure that sanctioned devices are adequately protected, the individual MUST +ensure that, before connecting to the Wi-Fi network, the device has:

+
    +
  • +

    up-to-date antivirus and antispyware software;

    +
  • +

    a firewall that is activated and configured to company requirements (i.e. the settings have not been changed) since +the device was configured;

    +
  • +

    all software (including the Web browser) is current with automatic updating;

    +
  • +

    file sharing (e.g. SMB) is switched off.

    +
+

For security reasons staff and contractors MUST:

+
    +
  • +

    consider if mobile phone tethering is available and use this as the first choice;

    +
  • +

    consider delaying transmission of information until at a secure location;

    +
  • +

    not follow prompts to update software whilst connected to a public network;

    +
  • +

    not rely on the encryption provided by the Public WiFi Network (e.g. WPA) to protect company data;

    +
  • +

    ensure that an end-to-end encrypted connection is established and the user has been trained in setting up +such a connection for each service to be used (for the avoidance of doubt, TLS is considered to be end-to-end +providing that the certificate presented by the server is validated);

    +
  • +

    ensure that URLs in Web browsers are showing the correct Web addresses in case a criminal has hijacked the Wireless +Access Point and is forwarding traffic to their site;

    +
  • +

    keep all information secure, including restricting the view of the screen from any unauthorised person(s);

    +
+
+
+

+ Conformance

+

+ Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. + The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” + in the normative parts of this document + are to be interpreted as described in RFC 2119. + However, for readability, + these words do not appear in all uppercase letters in this specification. + +

+

+ All of the text of this specification is normative + except sections explicitly marked as non-normative, examples, and notes. [RFC2119] + +

+

+ Examples in this specification are introduced with the words “for example” + or are set apart from the normative text with class="example", like this: + +

+
+ This is an example of an informative example. +
+

+ Informative notes begin with the word “Note” + and are set apart from the normative text with class="note", like this: + +

+

+ Note, this is an informative note.

+
+ +

References

+

Normative References

+
+
[RFC2119] +
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc2119 +
\ No newline at end of file