jiebi/TextFlow huggingface dataset:
Original text:
STUB_PROVIDED_PREFIX_LIFETIME seconds.  The stub router sends a router advertisement containing this prefix.  The 'A' (autonomous configuration), 'L' (on-link) RFC4861 and the Stub Router bit (I- <del> D.hui-stub-router-ra-flag) MUST be set in the prefix header. </del>  This router advertisement MUST also include a Route Information Option (RFC4191) for each routable prefix advertised on the stub

Reviewer comments:
…flag in the Prefix Information Option flags, but in fact Jonathan's document describing the flags field sets it in the Router Advertisement Flags Extension option. We discussed this in 6man and I think the general consensus was to just use one of the remaining reserved bits rather than requiring the additional extension option prematurely, so I'm updating the text to say that, and have asked Jonathan to update the stub router flags document accordingly.

Revised text:
STUB_PROVIDED_PREFIX_LIFETIME seconds.  The stub router sends a router advertisement containing this prefix.  The 'A' (autonomous configuration), 'L' (on-link) RFC4861 and the Stub Router bit (I-  <ins> D.hui-stub-router-ra-flag) MUST be set in the Router Advertisement header flags field RFC5175. </ins> This router advertisement MUST also include a Route Information Option (RFC4191) for each routable prefix advertised on the stub
Original text:
autonomous configuration. A prefix is not considered a usable on-link prefix if it is <del> advertised on the link as on-link, but the 'm' bit is set in the Router Advertisement message header (RFC4861) that contains the Prefix option.  This indicates that node addressability is being managed using DHCPv6.  Nodes are not required to use DHCPv6 to acquire addresses, so a prefix that requires the use of DHCPv6 can't be considered "usable"&#151;not all hosts can actually use it. </del>  A prefix is considered to be advertised on the link if, when a Router Solicit message (RFC4861) is sent, a Router Advertisement message is

Reviewer comments:
see URL in the working group meeting in London, and in both cases, it seemed that the argument that without NAT64 we can't deliver on "device must always be able to connect to the internet if it is available" overrode the objections that were raised. So despite some folks really not loving it, I think it's required. Michael (IIRC) also pointed out that we need DHCPv6 PD to get infrastructure-provided NAT64 to work, which I guess means that if we have IPv4 and infrastructure-provided NAT64, but no DHCPv6 PD, we have to do NAT64 in the stub router. If we have v6-only, infrastructure-provided NAT64, and no DHCPv6 PD, then in order to reach the internet, we'd need NAT66. I'm inclined to declare this situation out of scope, because (A) I really don't want to do NAT66, and (B) I think it's not a likely scenario at the moment, and the more devices out in the field that would break in this situation, the better.

Revised text:
autonomous configuration. A prefix is not considered a usable on-link prefix if it is  <ins> advertised on the link as on-link, but the 'a' bit is not set in the Prefix Information option header (RFC4861) that contains the Prefix option.  This indicates that node addressability is being managed using DHCPv6.  Nodes are not required to use DHCPv6 to acquire addresses, so a prefix that requires the use of DHCPv6 can't be considered "usable"&#151;not all hosts can actually use it. </ins> A prefix is considered to be advertised on the link if, when a Router Solicit message (RFC4861) is sent, a Router Advertisement message is
Original text:
header flags field RFC5175. This router advertisement MUST also include a Route Information <del> Option (RFC4191) for each routable prefix advertised on the stub </del>  network.  If the stub router is also a normal router (e.g. a home WiFi router), it SHOULD include all other routes that it is advertising in the RA, if there is space.

Reviewer comments:
see URL in the working group meeting in London, and in both cases, it seemed that the argument that without NAT64 we can't deliver on "device must always be able to connect to the internet if it is available" overrode the objections that were raised. So despite some folks really not loving it, I think it's required. Michael (IIRC) also pointed out that we need DHCPv6 PD to get infrastructure-provided NAT64 to work, which I guess means that if we have IPv4 and infrastructure-provided NAT64, but no DHCPv6 PD, we have to do NAT64 in the stub router. If we have v6-only, infrastructure-provided NAT64, and no DHCPv6 PD, then in order to reach the internet, we'd need NAT66. I'm inclined to declare this situation out of scope, because (A) I really don't want to do NAT66, and (B) I think it's not a likely scenario at the moment, and the more devices out in the field that would break in this situation, the better.

Revised text:
header flags field RFC5175. This router advertisement MUST also include a Route Information  <ins> option (RFC4191) for each routable prefix advertised on the stub </ins> network.  If the stub router is also a normal router (e.g. a home WiFi router), it SHOULD include all other routes that it is advertising in the RA, if there is space.
Original text:
It is also possible that stub routers for more than one stub network may be connected to the same adjacent infrastructure link.  In this <del> case, the stub routers will be advertising Router Information Options </del>  in their router advertisements for their OSNR prefixes.  Stub routers MUST track the presence of such routes, and MUST advertise reachability to them on interfaces connected to stub networks.

Reviewer comments:
see URL in the working group meeting in London, and in both cases, it seemed that the argument that without NAT64 we can't deliver on "device must always be able to connect to the internet if it is available" overrode the objections that were raised. So despite some folks really not loving it, I think it's required. Michael (IIRC) also pointed out that we need DHCPv6 PD to get infrastructure-provided NAT64 to work, which I guess means that if we have IPv4 and infrastructure-provided NAT64, but no DHCPv6 PD, we have to do NAT64 in the stub router. If we have v6-only, infrastructure-provided NAT64, and no DHCPv6 PD, then in order to reach the internet, we'd need NAT66. I'm inclined to declare this situation out of scope, because (A) I really don't want to do NAT66, and (B) I think it's not a likely scenario at the moment, and the more devices out in the field that would break in this situation, the better.

Revised text:
It is also possible that stub routers for more than one stub network may be connected to the same adjacent infrastructure link.  In this  <ins> case, the stub routers will be advertising Router Information options </ins> in their router advertisements for their OSNR prefixes.  Stub routers MUST track the presence of such routes, and MUST advertise reachability to them on interfaces connected to stub networks.
Original text:
5.2.3. If DHCPv6 PD is available on the link, it is preferable to acquire a <del> prefix using DHCPv6 PD rather than generating a ULA prefix, because the DHCPv6-PD-provided prefix is routable at least on the local infrastructure.  Therefore, when DHCPv6-PD is available, the stub router MUST use DHCPv6 PD rather than its own prefix. </del>  5.3.

Reviewer comments:
Added a bunch of clarifying text about why to use the DHCPv6 PD prefix, and also clarified the bits about NAT64 with respect to when to use Infrastructure-provided versus stub-router-provided NAT64.
See URL in the working group meeting in London, and in both cases, it seemed that the argument that without NAT64 we can't deliver on "device must always be able to connect to the internet if it is available" overrode the objections that were raised. So despite some folks really not loving it, I think it's required. Michael (IIRC) also pointed out that we need DHCPv6 PD to get infrastructure-provided NAT64 to work, which I guess means that if we have IPv4 and infrastructure-provided NAT64, but no DHCPv6 PD, we have to do NAT64 in the stub router. If we have v6-only, infrastructure-provided NAT64, and no DHCPv6 PD, then in order to reach the internet, we'd need NAT66. I'm inclined to declare this situation out of scope, because (A) I really don't want to do NAT66, and (B) I think it's not a likely scenario at the moment, and the more devices out in the field that would break in this situation, the better.

Revised text:
5.2.3. If DHCPv6 PD is available on the link, it is preferable to acquire a  <ins> prefix using DHCPv6 PD rather than generating a ULA prefix.  Using a prefix provided by the infrastructure DHCPv6 prefix delegation service means (assuming the infrastructure is configured correctly) that routing is possible between the stub network links and all links on the infrastructure network, and possibly to the general internet. By contrast, if the prefix generated by the stub router is used, reachability is only possible between the stub network and the adjacent infrastructure link, because the OSNR prefix in this case is not known to the infrastructure network routing fabric.  So when the only prefix that is available is the one provided by the stub router, cloud services will not be reachable via IPv6, and infrastructure- provided NAT64 will not work.  Therefore, when DHCPv6-PD is available, the stub router MUST use DHCPv6 PD rather than its own prefix. </ins> 5.3.
Original text:
NAT64 prefix(es) MUST be advertised by those stub routers that are able to discover it.  6.2. Most infrastructure networks at present do not provide NAT64 service. <del> It is therefore necessary for stub routers to be able to provide </del>  NAT64 service if IPv4 hosts are to be reachable from the stub <del> network. </del>  To provide NAT64 service, a stub router must allocate a NAT64 prefix. For convenience, the stub network allocates a single prefix out of

Reviewer comments:
Added a bunch of clarifying text about why to use the DHCPv6 PD prefix, and also clarified the bits about NAT64 with respect to when to use Infrastructure-provided versus stub-router-provided NAT64.
See URL in the working group meeting in London, and in both cases, it seemed that the argument that without NAT64 we can't deliver on "device must always be able to connect to the internet if it is available" overrode the objections that were raised. So despite some folks really not loving it, I think it's required. Michael (IIRC) also pointed out that we need DHCPv6 PD to get infrastructure-provided NAT64 to work, which I guess means that if we have IPv4 and infrastructure-provided NAT64, but no DHCPv6 PD, we have to do NAT64 in the stub router. If we have v6-only, infrastructure-provided NAT64, and no DHCPv6 PD, then in order to reach the internet, we'd need NAT66. I'm inclined to declare this situation out of scope, because (A) I really don't want to do NAT66, and (B) I think it's not a likely scenario at the moment, and the more devices out in the field that would break in this situation, the better.

Revised text:
NAT64 prefix(es) MUST be advertised by those stub routers that are able to discover it. <ins> In order for infrastructure-provided NAT64 to work, the stub network must have an OSNR prefix that is known to the infrastructure. Typically this means that the stub router must have acquired this prefix using DHCPv6 Prefix Delegation.  Unless otherwise configured to do so, the stub router MUST NOT advertise infrastructure-provided NAT64 service on the stub network if it has not acquired the OSNR prefix through DHCPv6 Prefix Delegation. </ins> 6.2. Most infrastructure networks at present do not provide NAT64 service.  <ins> Many infrastructure networks do not provide DHCPv6 Prefix Delegation. In these cases it is necessary for stub routers to be able to provide </ins> NAT64 service if IPv4 hosts are to be reachable from the stub  <ins> network.  Therefore, stub routers MUST be capable of providing NAT64 service to the stub network.  When infrastructure-provided NAT64 service is not present or is not usable, and when no other NAT64 service is already advertised on the stub network, stub routers MUST, by default, enable their own NAT64 service and advertise it on the stub network. </ins> To provide NAT64 service, a stub router must allocate a NAT64 prefix. For convenience, the stub network allocates a single prefix out of
Original text:
Additional section.  The resolver should also include an ipv4only.arpa record in the Additional section. <del> 7. </del>  If a stub network is constructed using mesh technology, it may become partitioned.  In such a situation, it may be one stub router is

Reviewer comments:
Added a bunch of clarifying text about why to use the DHCPv6 PD prefix, and also clarified the bits about NAT64 with respect to when to use Infrastructure-provided versus stub-router-provided NAT64.
See URL in the working group meeting in London, and in both cases, it seemed that the argument that without NAT64 we can't deliver on "device must always be able to connect to the internet if it is available" overrode the objections that were raised. So despite some folks really not loving it, I think it's required. Michael (IIRC) also pointed out that we need DHCPv6 PD to get infrastructure-provided NAT64 to work, which I guess means that if we have IPv4 and infrastructure-provided NAT64, but no DHCPv6 PD, we have to do NAT64 in the stub router. If we have v6-only, infrastructure-provided NAT64, and no DHCPv6 PD, then in order to reach the internet, we'd need NAT66. I'm inclined to declare this situation out of scope, because (A) I really don't want to do NAT66, and (B) I think it's not a likely scenario at the moment, and the more devices out in the field that would break in this situation, the better.

Revised text:
Additional section.  The resolver should also include an ipv4only.arpa record in the Additional section.  <ins> 6.3. Some network media may provide their own mechanisms for advertising NAT64 service to the stub network.  If such a mechanism is available, stub routers MUST use the mechanism provided by the network medium used on the stub network to advertise NAT64 service.  Otherwise, NAT64 service MUST be advertised using the PREF64 Router Advertisement option RFC8781. 6.4. </ins> If a stub network is constructed using mesh technology, it may become partitioned.  In such a situation, it may be one stub router is
Original text:
then the ULA prefix that is numerically lowest should be kept, and the others deprecated.  By using this approach, it is not necessary for the routers to coordinate in advance. 

Reviewer comments:
I added a section about services provided by the Stub Network. This will need some more work, but it seems useful to have, and it now says that DHCPv6 is generally NOT RECOMMENDED but is permitted, and MUST be off by default.
(Based on recent discussion in v6ops) We don't specify yet the type of hosts on the IPv6 stub network in detail. For example, an IoT device host only needs an address which it can configure with SLAAC based on the /64 on-mesh/on-link prefix. However, there could also be more complex hosts in principle that need their own prefixes (e.g. /64) delegated to it for internal usage and they may like to use their DHCPv6-PD client for that. For example for running multiple virtual machines / dockers inside the host where these VMs are on their own virtual network segment. I expect these cases to be out of scope and there's no requirement on the stub router to do either DHCPv6-PD server or relay role. Do we need to make this explicit in a goal / non-goal / out-of-scope section ?
With my AD hat one, I sincerely hope to keep the stub network with simple devices, else the SNAC WG will try to make a simple problem too complex ;-) Without any hat, I do not mind having an applicability statement with non-goals in it.

Revised text:
then the ULA prefix that is numerically lowest should be kept, and the others deprecated.  By using this approach, it is not necessary for the routers to coordinate in advance. <ins> 6.5. In order to provide network access, stub routers must provide some network services to the stub network.  We have previously discussed the following services: </ins>
Original text:
Automatically Connecting Stub Networks to Unmanaged Infrastructure <del> draft-lemon-stub-networks-07 </del>  Abstract

Reviewer comments:
Didn't have time to add a state machine, but documented the ways that NAT64 advertising can happen.
There is a set of possible circumstances that we need to think about for infrastructure-provided NAT64: There is PD support, and infra is providing NAT64 There is no PD support, infra is providing NAT64, and there is no IPv4 on infra There is no PD support, infra is providing NAT64, and there is IPv4 on infra There is PD support, infra is not providing NAT64, infra is providing IPv4 In case (1), we can (and should) use the infrastructure-provided NAT64 service. In case (2), we have no way to do NAT64, because we don’t have a infrastructure-routable OMR prefix on the Thread mesh. So in this case, reachability to the cloud, both for IPv4 and IPv6, is not available. In case (3), although infrastructure is providing NAT64, we can’t use it. There is no IPv6 reachability to the internet, but a BR can provide its own NAT64 service to enable reachability to the internet over IPv4. In case (4), BR can provide NAT64 for IPv4 reachability to the internet, but additionally IPv6 reachability to the internet is present. Add text to the document to describe how we handle these situations, including state machine if appropriate.

Revised text:
Automatically Connecting Stub Networks to Unmanaged Infrastructure  <ins> draft-ietf-snac-simple-00 </ins> Abstract
Original text:
Additional section.  The resolver should also include an ipv4only.arpa record in the Additional section. <del> 6.3. Some network media may provide their own mechanisms for advertising NAT64 service to the stub network.  If such a mechanism is available, stub routers MUST use the mechanism provided by the network medium used on the stub network to advertise NAT64 service.  Otherwise, NAT64 service MUST be advertised using the PREF64 Router Advertisement option RFC8781. 6.4. </del>  If a stub network is constructed using mesh technology, it may become partitioned.  In such a situation, it may be one stub router is

Reviewer comments:
Didn't have time to add a state machine, but documented the ways that NAT64 advertising can happen.
There is a set of possible circumstances that we need to think about for infrastructure-provided NAT64: There is PD support, and infra is providing NAT64 There is no PD support, infra is providing NAT64, and there is no IPv4 on infra There is no PD support, infra is providing NAT64, and there is IPv4 on infra There is PD support, infra is not providing NAT64, infra is providing IPv4 In case (1), we can (and should) use the infrastructure-provided NAT64 service. In case (2), we have no way to do NAT64, because we don’t have a infrastructure-routable OMR prefix on the Thread mesh. So in this case, reachability to the cloud, both for IPv4 and IPv6, is not available. In case (3), although infrastructure is providing NAT64, we can’t use it. There is no IPv6 reachability to the internet, but a BR can provide its own NAT64 service to enable reachability to the internet over IPv4. In case (4), BR can provide NAT64 for IPv4 reachability to the internet, but additionally IPv6 reachability to the internet is present. Add text to the document to describe how we handle these situations, including state machine if appropriate.

Revised text:
Additional section.  The resolver should also include an ipv4only.arpa record in the Additional section.  <ins> 7. </ins> If a stub network is constructed using mesh technology, it may become partitioned.  In such a situation, it may be one stub router is
Original text:
the others deprecated.  By using this approach, it is not necessary for the routers to coordinate in advance. <del> 6.5. </del>  In order to provide network access, stub routers must provide some network services to the stub network.  We have previously discussed

Reviewer comments:
Didn't have time to add a state machine, but documented the ways that NAT64 advertising can happen.
There is a set of possible circumstances that we need to think about for infrastructure-provided NAT64: There is PD support, and infra is providing NAT64 There is no PD support, infra is providing NAT64, and there is no IPv4 on infra There is no PD support, infra is providing NAT64, and there is IPv4 on infra There is PD support, infra is not providing NAT64, infra is providing IPv4 In case (1), we can (and should) use the infrastructure-provided NAT64 service. In case (2), we have no way to do NAT64, because we don’t have a infrastructure-routable OMR prefix on the Thread mesh. So in this case, reachability to the cloud, both for IPv4 and IPv6, is not available. In case (3), although infrastructure is providing NAT64, we can’t use it. There is no IPv6 reachability to the internet, but a BR can provide its own NAT64 service to enable reachability to the internet over IPv4. In case (4), BR can provide NAT64 for IPv4 reachability to the internet, but additionally IPv6 reachability to the internet is present. Add text to the document to describe how we handle these situations, including state machine if appropriate.

Revised text:
the others deprecated.  By using this approach, it is not necessary for the routers to coordinate in advance.  <ins> 8. </ins> In order to provide network access, stub routers must provide some network services to the stub network.  We have previously discussed