small typos

projects/alamesh/alanet_conf_reqs.md

@@ -2,7 +2,7 @@
 
 [[_TOC_]]
 
-Before we start peering there are some questions we need to answer and a way to store global configuration.
+Before we start peering there are some questions we need to answer and we need a way to store global configuration.
 
 # Network Questions
 
@@ -20,19 +20,16 @@ for the future mesh network :). It'd be nice to not share space with `dn42` in c
 * How large of a prefix do we want to give people? Each hex char in an address adds 4 to the prefix len.
   * `02::/8` since there's two chars "02" at the start. We could do `/16` for now. That's 256 at the start and limit to
   one per AS. If we get above say `127` unique ASNs, then we can bump it up to a `/32`.
-  * With a `/16` prefix, addresses would look like `2XX::/16`. I was using `255::/16` and `200::/16` for my tests. 
+    * With a `/16` prefix, addresses would look like `2XX::/16`. I was using `255::/16` and `200::/16` for my tests. 
   * Another option is to do `02XX:XX:X0::/32` where `X` is your ASN number suffix. That's kinda fun but then we don't get nice,
   short addresses.
   
-Think about it what you want to do! Remember, it's _our_ internet.
+Think about it what you want to do! Everyone has a say!
 
 The rest of the document discusses our configuration requirements.
 
 # What Config Information Do We Need?
 
-As discovered in [[setting_up_bird]], there's a lot that can go wrong when setting up peering and bird configuration. 
-We want to automate that process and make it **a single command** to peer with a new person.
-
 We need global information about the router and information per-peer.
 
 ## Router Config
@@ -83,12 +80,12 @@ We need the:
 - **Peer's endpoint**: the public endpoint, host with port, that we can reach this peer at. The port is different per-peer.
 
 The port is only different per-peer since we give each peer a separate interface. This makes things much easier from a 
-management and security perspective at the cost of making the port unknown.
-
-> We can setup auto-peering 
+management and security perspective at the cost of making the port unknown. 
 
 # What Are Our Automation Goals?
 
+Maybe not necessary for the near-future, but these goals should guide our implementation.
+
 * Only a single command to refresh or add a peer with a simple configuration format.
 * Simple way to add public router information (asn, internal ip, subnet).
 * Only exchange per-peer information _once_. I give you an endpoint and key, you give me an endpoint and key, done.
@@ -115,6 +112,8 @@ on the super cheap VPS I'm using. Maybe there's another way.
 
 ## Automatic Peering
 
+Not really a way to implement the above, but interesting nonetheless.
+
 This would be incredibly useful. There's some dn42 peers that provide a UI or custom wg server that's 100% self serve. 
 The custom wg server is interesting since your connection port is the last 5 digits of your ASN which is really nice and
 makes it very easy to peer with someone else. This makes me feel like peering should not be public and we might want to
@@ -130,4 +129,4 @@ See [Identity Management for WireGuard](https://lwn.net/Articles/910766/).
 # Conclusion
 
 We need to answer the questions at the very beginning and figure out how to store ASN information. We could honestly 
-just answer the initial quesitions and just peer manually / not try to make anything fancy. Or we make it fancy :)
+just answer the initial quesitions and just peer manually and not try to make anything fancy. Or we make it fancy :)