Original text:
STUB_PROVIDED_PREFIX_LIFETIME seconds.  The stub router sends a router advertisement (RA) containing this prefix in a Prefix Information Option (PIO).  In the PIO, the 'A' flag bit (autonomous <del> configuration) flag RFC4861 MUST be set and the 'L' flag bit (on-link prefix) MUST be set.  Link-layer technologies that require the 'L' flag bit to be cleared are out of scope of this document. The Stub Router flag (I-D.hui-stub-router-ra-flag) MUST be set in the RA flags field.  The values of the M and O flags MUST be copied from the respective M/O flag values seen in the most recent (unicast or multicast) RA received from a non-stub-router.  For the selection of the most recent RA, the following RAs MUST be excluded: If there is no recent RA from a non-stub-router, both M and O flags MUST be cleared, unless the stub router rebooted recently.  After a reboot, if no recent RA is received from a non-stub router, but a recent RA has been received from a stub router, the values for the M and O flags provided by that stub router MUST be copied.  After MAX_FLAGS_COPY_TIME after reboot, the stub router MUST go back to the regular behavior defined above.  This avoids a situation where a stub router that has rebooted starts to advertise different M/O flag values than other stub routers present on the same link. </del>  The sent router advertisement MUST also include a Route Information option (RFC4191) for each routable prefix advertised on the stub

Reviewer comments:
Flag bits can be referred to as "bit", "flag", or "flag bit". This issue is an editorial reminder to update to a consistent term later on. E.g. "flag" or "flag bit" is most clear I think.
Assigning to myself, to make a PR later on. Everyone and NAME feel free to suggest preferred term. I find "flag bit" the most clear.

Revised text:
STUB_PROVIDED_PREFIX_LIFETIME seconds.  The stub router sends a router advertisement (RA) containing this prefix in a Prefix Information Option (PIO).  In the PIO, the 'A' flag bit (autonomous  <ins> configuration) RFC4861 MUST be set and the 'L' flag bit (on-link prefix) MUST also be set.  Link-layer technologies that require the 'L' flag bit to be cleared are out of scope of this document. The 'Stub Router' flag bit (I-D.hui-stub-router-ra-flag) MUST be set in the RA flags field.  The values of the 'M' and 'O' flag bits MUST be copied from the respective 'M' and 'O' flag bit values seen in the most recent (unicast or multicast) RA received from a non-stub- router.  For the selection of the most recent RA, the following RAs MUST be excluded: If there is no recent RA from a non-stub-router, both 'M' and 'O' flag bits MUST be cleared, unless the stub router rebooted recently. After a reboot, if no recent RA is received from a non-stub router, but a recent RA has been received from a stub router, the values for the 'M' and 'O' flag bits provided by that stub router MUST be copied.  After MAX_FLAGS_COPY_TIME after reboot, the stub router MUST go back to the regular behavior defined above.  This avoids a situation where a stub router that has rebooted starts to advertise different 'M' and 'O' flag bit values than other stub routers present on the same link. </ins> The sent router advertisement MUST also include a Route Information option (RFC4191) for each routable prefix advertised on the stub