Finished Rationale and Unresolved sections

text/0000-tangle/0000-tangle.md

@@ -5,7 +5,7 @@
 
 # Summary
 
-The Tangle is the core of IOTA's distributed ledger technology. This RFC proposes an API for interacting with and manipulating The Tangle in a type-safe manner that mirrors the flexible semantics of a garbage-collected language with retaining the performance and ownership model of Rust. It also proposes a novel eager solidification algorithm that is (likely to be) more performant than the existing thread-based solidification system, as well as only ever providing users of the API with a fully-informed, fully-inferred view of Tangle solidification.
+The Tangle is the core of IOTA's distributed ledger technology. This RFC proposes an API for interacting with and manipulating the Tangle in a type-safe manner that mirrors the flexible semantics of a garbage-collected language with retaining the performance and ownership model of Rust. It also proposes a novel eager solidification algorithm that is (likely to be) more performant than the existing thread-based solidification system, as well as only ever providing users of the API with a fully-informed, fully-inferred view of Tangle solidification.
 
 # Motivation
 
@@ -37,9 +37,9 @@ let tx0_trunk_trunk = tangle
     .unwrap();
 ```
 
-As can be seen, walking The Tangle is unnecessarily explicit.
+As can be seen, walking the Tangle is unnecessarily explicit.
 
-To address this issue we suggest a design that makes use of Rust's zero-cost approach to abstraction to transparently manipulate The Tangle using guard/reference types and the `Deref` trait.
+To address this issue we suggest a design that makes use of Rust's zero-cost approach to abstraction to transparently manipulate the Tangle using guard/reference types and the `Deref` trait.
 
 The equivalent code using the proposed API abstraction:
 
@@ -400,17 +400,10 @@ mod tests {
 
 # Rationale and alternatives
 
-- Why is this design the best in the space of possible designs?
-- What other designs have been considered and what is the rationale for not
-  choosing them?
-- What is the impact of not doing this?
+- The Tangle API design is both flexible for users (it feels like it has dynamic ownership) but also flexible for the implementation (it makes it easier to refactor the implementation later into a more efficient design without being tied to any particular ownership model).
+
+- Alternative solidification algorithms include sticking with the current implementation that uses a worker thread to solidify the tangle. As previously mentioned, the solution proposed will likely have much better performance in the average case.
 
 # Unresolved questions
 
-- What parts of the design do you expect to resolve through the RFC process
-  before this gets merged?
-- What parts of the design do you expect to resolve through the implementation
-  of this feature before stabilization?
-- What related issues do you consider out of scope for this RFC that could be
-  addressed in the future independently of the solution that comes out of this
-  RFC?
+- How does the design of this Tangle API relate to the implementation of the storage database layer? Should we move to an async query model?