clarify wording in data layout + mandate sections

Author: jherrera-jump

proposals/0307-add-block-footer.md

@@ -61,7 +61,8 @@ arrangement of a typical network packet (e.g. MAC -> IP -> TCP -> HTTP). At the
 highest layer a block consists of some number (~100+) FEC sets. A single FEC
 set contains a handful of shreds (~32). Once sufficient shreds are available
 the raw block data is reconstructed and reinterpreted as an array of entry
-batches. Entry batches do not cross shred boundaries.
+batches. Entry batches are aligned with shred boundaries (i.e. they will
+start/stop at a shred boundary).
 
 This SIMD add the following footer at the end of the raw block data. This
 puts it on the same abstraction layer as serialized entry batch data. Put
@@ -280,7 +281,7 @@ Sample Response Payload
 
 While it is possible to make the block footer optional thanks to the
 `block_footer_flag` field, this proposal makes it mandatory. Blocks that don't
-include a valid footer in the block payload will be flagged as dead blocks and
+include a valid footer in the block payload must be flagged as dead blocks and
 skipped by the other nodes in the cluster.
 
 ## Alternatives Considered