Original text:
able to interoperate with hosts on other network links in the same infrastructure as well as hosts on the global internet. <del> It may be noted that just as you can plug several Home Gateway devices together in series to form multi-layer NATs, there is nothing </del>  preventing the owner of a stub network router from attaching it to a stub network as if that network were its infrastructure network.  In the case of an IoT wireless network, there may be no way to do this,

Reviewer comments:
Because CE routers are infrastructure
This addresses
NAME could we change "customer edge router" to "home gateway" (per our official terminology )? I see now also the RFC reference in the PR is incorrect (rfc 704).
the text in this section can be confusing when dealing with 2 usable prefixes (see section 5.2.1.4 - ULA/non-ULA). In MCR's words: if there are two suitable prefixes, one of them will still need to be deprecated. According to Ted, this issue is orthogonal to reachability. Perhaps, we should explain that this state-machine does not talk about reachability for both the suitable prefixes. At least give forward reference to section 5.4 for complete behavior. This will explain that we can only transition to STATE-BEGIN-ADVERTIZING and in no case we transition to STATE_USABLE
I think the issue here is not about usable prefixes, but about routes. Suppose we have a DHCPv6 prefix, and the DHCPv6 server doesn't renew it. In this case, we probably want to stop advertising it at some point and start advertising a prefix based on our site ULA. We should talk about the timing of this switch-over. Separately, whenever we have advertised a prefix on either link, we need to continue advertising a route to that prefix until the prefix is no longer valid on the link on which we advertised it. So if we switch from DHCPv6 prefix to ULA prefix on infrastructure, we need to be advertising routes to both for as long as both are valid. Similarly, if we advertise a prefix on the stub network and later withdraw it because a higher-priority prefix is advertised there, we need to continue advertising a route to that prefix on the infrastructure link until the valid lifetime of the prefix we advertised has expired. I think all routers that have seen the prefix need to do this. Then there's the case where a stub router advertising a prefix reboots. We can't assume that it's written anything to stable storage other than what prefix it's allocated for the stub network and for the infrastructure network. So when the router comes up after booting, it needs to advertise routes to these prefixes on the appropriate link until the maximum possible valid lifetime for the prefix has expired. And finally there's the DHCPv6 case, where we got a prefix to advertise on the stub network via DHCPv6. In this case, I think we need to write the DHCPv6 prefix to stable storage when we get it, and remove it from stable storage when it expires. We should limit the lifetime we advertise on the stub network to a constant value (e.g. 30 minutes), and then if we find the DHCPv6 prefix recorded in stable storage, we advertise a route to it on infrastructure for 30 minutes after reboot. After 30 minutes, we can erase it from stable storage so that this doesn't repeat. I think if the BR doesn't have stable storage, then if it reboots with a DHCPv6 prefix still valid on the stub network, we just have to hope that it gets the same prefix when it comes back. If it does not, then that prefix may become unreachable while hosts on the stub network are still using it. We could have the stub network snoop source addresses to discover prefixes still in use on the stub network to ameliorate this situation, but that's somewhat problematic because it's a lot of work.
I think the conclusion of the WG is that we need to have an explicit state machine for the stub router on-link prefix because it's actually quite different from the state machine for infrastructure, where for example we do not need to do DHCP. Important to mention that we need to explicitly deprecate the DHCP prefix if we switch to ULA and vice versa.
One of the things that this state machine needs to talk about is what happens if the SNAC router sees an RIO on /its/ stub network that does not have the SNAC router flag bit set. In this case, the SNAC router should treat this network as an infrastructure network and should not perform SNAC router routing functions or service discovery functions between the two networks. Essentially in this case the SNAC router functionality should be completely disabled while such an RA is seen on the stub network.

Revised text:
able to interoperate with hosts on other network links in the same infrastructure as well as hosts on the global internet.  <ins> It may be noted that just as you can plug several CE Router devices together in series to form multi-layer NATs, there is nothing </ins> preventing the owner of a stub network router from attaching it to a stub network as if that network were its infrastructure network.  In the case of an IoT wireless network, there may be no way to do this,