Spelling suggestions from @dvzrv, @lahwaacz and note by @allan

rfcs/0035-mirror-definition.rst

@@ -13,14 +13,14 @@ Mirror Definition
 Summary
 -------
 
-Before this proposal, there were a lack of security definitions and measures on mirrors within the Arch Linux community. This RFC therefore outlines the requirements, definitions and guidelines surrounding not only hardening but also maintaining proper security of a mirror.
+Before this proposal, there was a lack of security definitions and measures on mirrors within the Arch Linux community. This RFC therefore outlines the requirements, definitions and guidelines surrounding not only hardening but also maintaining proper security of a mirror.
 
 Motivation
 ----------
 
-At the current moment we have no means of security within the mirror infrastructure. We can neither proof ownership, track ownership changes or flag breaches. Current security model relies solely on package validation on pacman. Other security aspects like data privacy, availability of the supply chain are not taken care of. 
+At the current moment we have no means of security within the mirror infrastructure. We can neither prove ownership, track ownership changes or flag breaches. Current security model relies solely on package validation on pacman. Other security aspects like data privacy or availability of the supply chain are not taken care of.
 
-This RFC aims to introduce security awareness where there are none yet. We are fully aware that some attack vectors still remain availible. The security measures would mostly if not all be supported by proper tooling like `mirrorctl`_. 
+This RFC aims to introduce security awareness where there is none yet. We are fully aware that some attack vectors still remain available. The security measures would mostly if not all be supported by proper tooling like `mirrorctl`_. 
 
 The RFC introduces the concept of mirror ownerships and a process of validation by means of cryptographic signature. We also discuss the notion of having sane security defaults. 
 
@@ -54,8 +54,8 @@ This would mean that the clean up phase would start at somewhere around December
 Specification
 -------------
 
-Decomission procedure
-^^^^^^^^^^^^^^^^^^^^^
+Decommission procedure
+^^^^^^^^^^^^^^^^^^^^^^
 The decommission of a mirror should be announced with proper tooling. In addition to the described process in `RFC 0029`_, the decommission process would also start if the signature checks would fail repeatedly. 
 
 - Tier 1 and 2 mirrors will have 6 months to secure their servers, which can be extended if the procedure might take a longer time.
@@ -63,10 +63,10 @@ The decommission of a mirror should be announced with proper tooling. In additio
 
 In case of missing the grace period, additional warnings will be sent out which are then followed by removal from the official mirror list. Tier1 and Tier2 mirrors that don't follow the spec within the grace period will be downgraded to one level below after two attempts of contact without response over a period of two months. The new requirements will first be enacted only on **new** mirrors.
 
-Recommendation and Requirements for different mirror types
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Recommendation and requirements for different mirror types
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 
-For mirror definitions please refer to RFC !29.
+For mirror definitions please refer to `RFC 0029`_.
 
   Tier 1 Requirements	
 
@@ -111,7 +111,7 @@ Mirror Tooling
 
 To facilitate the changes outlined in this RFC, tooling would not only be beneficial but crucial for managing things going forward. To preface, all features workflows of ``mirrorctl`` should also be possible to do manually from the mirror administrators. 
 
-This RFC in combination with RFC !29 proposes a tool called ``mirrorctl`` which should have at least the following features:
+This RFC in combination with `RFC 0029`_ proposes a tool called ``mirrorctl`` which should have at least the following features:
 
 - Handle signing of proof-of-domain-ownership
 
@@ -129,7 +129,7 @@ It would require some more maintenance from Arch Linux staff, specifically the d
 Unresolved Questions
 --------------------
 
-No outstanding questions, see RFC !29.
+No outstanding questions, see `RFC 0029`_.
 
 Alternatives Considered
 -----------------------
@@ -137,27 +137,11 @@ Alternatives Considered
 Alternative discussions was not mentioned in the `Arch Summit 2023`_ as the conclusion was that this is a good step forward.
 
 .. _RFC 0029: https://gitlab.archlinux.org/archlinux/rfcs/-/merge_requests/29
-.. _scarecely doccumented: https://wiki.archlinux.org/title/DeveloperWiki:NewMirrors
-.. _archweb: https://github.com/archlinux/archweb
-.. _flyspray: https://bugs.archlinux.org/
 .. _mirror administrators: https://gitlab.archlinux.org/groups/archlinux/teams/mirror-administrator/-/group_members
-.. _mirror specification: https://gitlab.archlinux.org/archlinux/arch-mirrors/-/tree/main/specs?ref_type=heads
 .. _GitLab: https://gitlab.archlinux.org/
-.. _mirror project: https://gitlab.archlinux.org/archlinux/arch-mirrors
-.. _mirror definition: https://gitlab.archlinux.org/archlinux/arch-mirrors/-/tree/main/specs/mirror_def?ref_type=heads
-.. _reflector: https://xyne.dev/projects/reflector/
-.. _SLA: https://en.wikipedia.org/wiki/Service-level_agreement
-.. _CDN: https://en.wikipedia.org/wiki/Content_delivery_network
-.. _service specification: https://gitlab.archlinux.org/archlinux/arch-mirrors/-/tree/main/specs/service_def?ref_type=heads
-.. _well known: https://en.wikipedia.org/wiki/Well-known_URI
-.. _text storage site: https://en.wikipedia.org/wiki/Pastebin
 .. _domain hijacking: https://en.wikipedia.org/wiki/Domain_hijacking
 .. _FQDN: https://en.wikipedia.org/wiki/Fully_qualified_domain_name
-.. _archinstall: https://github.com/archlinux/archinstall
-.. _middleware: https://en.wikipedia.org/wiki/Middleware
 .. _pacman: https://wiki.archlinux.org/title/Pacman
-.. _Arch Summit 2023: https://md.archlinux.org/
-.. _pactor: https://github.com/Torxed/pactor
-.. _seed box: https://en.wikipedia.org/wiki/Seedbox
+.. _Arch Summit 2023: https://md.archlinux.org/5I61f0yFSmysBkV8QQFU-g
 .. _podman: https://wiki.archlinux.org/title/Podman
 .. _mirrorctl: https://gitlab.archlinux.org/archlinux/mirrorctl
\ No newline at end of file