jiebi/TextFlow huggingface dataset:
Original text:
infrastructure network, and is therefore out of scope for this document. <del> 5.5.2. </del>  Hosts on the stub network may need to discover hosts on the AIL, or on the stub network.  In the IoT network example we've been using,

Reviewer comments:
… AIL change situations
Section 5.2.3 defines the mandatory DHCPv6-PD client role for the stub router. However, there are no details here what should trigger the stub router to renew/rebind the prefix lease. A reference to RFC 8415 should be added (as it contains some requirements on this topic). See section 18.2.12. Refreshing Configuration Information of RFC 8415. Do we define the SHOULD requirements of 18.2.12 about detecting a new network (new AIL) as mandatory for the stub router, or not? (If not: has consequences for wider IPv6 connectivity in such new-AIL cases) And what about the SHOULD requirement that involves "if the client detects a significant change regarding the prefixes available on the link (when new prefixes are added or existing prefixes are deprecated), as this may indicate a configuration change. " -> can we specify this better? What are the significant changes in our case? And how to do this detection? (e.g. monitor RAs?)
For this issue, we could reference the improved text in URL instead of RFC 8415. This text should be sufficient detail that stub router implementers know what to do. (Or at least, the DHC WG thinks it is enough for DHCPv6 client implementers to know what to do :-) ) PR with this pointer text is still needed.

Revised text:
infrastructure network, and is therefore out of scope for this document.  <ins> 5.2.6.2. </ins> Hosts on the stub network may need to discover hosts on the AIL, or on the stub network.  In the IoT network example we've been using,
Original text:
specific mechanism, the details of which are out of scope for this document. <del> 6. </del>  SNAC networks rely on IPv6 to enable routing between links, which would not be possible with IPv4 due to the lack of a standard

Reviewer comments:
… AIL change situations
Section 5.2.3 defines the mandatory DHCPv6-PD client role for the stub router. However, there are no details here what should trigger the stub router to renew/rebind the prefix lease. A reference to RFC 8415 should be added (as it contains some requirements on this topic). See section 18.2.12. Refreshing Configuration Information of RFC 8415. Do we define the SHOULD requirements of 18.2.12 about detecting a new network (new AIL) as mandatory for the stub router, or not? (If not: has consequences for wider IPv6 connectivity in such new-AIL cases) And what about the SHOULD requirement that involves "if the client detects a significant change regarding the prefixes available on the link (when new prefixes are added or existing prefixes are deprecated), as this may indicate a configuration change. " -> can we specify this better? What are the significant changes in our case? And how to do this detection? (e.g. monitor RAs?)
For this issue, we could reference the improved text in URL instead of RFC 8415. This text should be sufficient detail that stub router implementers know what to do. (Or at least, the DHC WG thinks it is enough for DHCPv6 client implementers to know what to do :-) ) PR with this pointer text is still needed.

Revised text:
specific mechanism, the details of which are out of scope for this document.  <ins> 5.3. </ins> SNAC networks rely on IPv6 to enable routing between links, which would not be possible with IPv4 due to the lack of a standard
Original text:
preference, the stub router SHOULD deprecate the prefix it is advertising. <del> 6.1. </del>  Stub networks are defined to be IPv6-only because it would be difficult to implement a stub network using IPv4 technology.

Reviewer comments:
… AIL change situations
Section 5.2.3 defines the mandatory DHCPv6-PD client role for the stub router. However, there are no details here what should trigger the stub router to renew/rebind the prefix lease. A reference to RFC 8415 should be added (as it contains some requirements on this topic). See section 18.2.12. Refreshing Configuration Information of RFC 8415. Do we define the SHOULD requirements of 18.2.12 about detecting a new network (new AIL) as mandatory for the stub router, or not? (If not: has consequences for wider IPv6 connectivity in such new-AIL cases) And what about the SHOULD requirement that involves "if the client detects a significant change regarding the prefixes available on the link (when new prefixes are added or existing prefixes are deprecated), as this may indicate a configuration change. " -> can we specify this better? What are the significant changes in our case? And how to do this detection? (e.g. monitor RAs?)
For this issue, we could reference the improved text in URL instead of RFC 8415. This text should be sufficient detail that stub router implementers know what to do. (Or at least, the DHC WG thinks it is enough for DHCPv6 client implementers to know what to do :-) ) PR with this pointer text is still needed.

Revised text:
preference, the stub router SHOULD deprecate the prefix it is advertising.  <ins> 5.3.1. </ins> Stub networks are defined to be IPv6-only because it would be difficult to implement a stub network using IPv4 technology.
Original text:
NAT64 service on the stub network if it has not acquired the OSNR prefix through DHCPv6 Prefix Delegation. <del> 6.2. </del>  Most infrastructure networks at present do not provide NAT64 service. Many infrastructure networks do not provide DHCPv6 Prefix Delegation.

Reviewer comments:
… AIL change situations
Section 5.2.3 defines the mandatory DHCPv6-PD client role for the stub router. However, there are no details here what should trigger the stub router to renew/rebind the prefix lease. A reference to RFC 8415 should be added (as it contains some requirements on this topic). See section 18.2.12. Refreshing Configuration Information of RFC 8415. Do we define the SHOULD requirements of 18.2.12 about detecting a new network (new AIL) as mandatory for the stub router, or not? (If not: has consequences for wider IPv6 connectivity in such new-AIL cases) And what about the SHOULD requirement that involves "if the client detects a significant change regarding the prefixes available on the link (when new prefixes are added or existing prefixes are deprecated), as this may indicate a configuration change. " -> can we specify this better? What are the significant changes in our case? And how to do this detection? (e.g. monitor RAs?)
For this issue, we could reference the improved text in URL instead of RFC 8415. This text should be sufficient detail that stub router implementers know what to do. (Or at least, the DHC WG thinks it is enough for DHCPv6 client implementers to know what to do :-) ) PR with this pointer text is still needed.

Revised text:
NAT64 service on the stub network if it has not acquired the OSNR prefix through DHCPv6 Prefix Delegation.  <ins> 5.3.2. </ins> Most infrastructure networks at present do not provide NAT64 service. Many infrastructure networks do not provide DHCPv6 Prefix Delegation.
Original text:
Additional section.  The resolver should also include an ipv4only.arpa record in the Additional section. <del> 7. </del>  Some technologies used for stub networks, for example Thread or 6LoWPAN mesh networks, can produce partitioned networks, where what

Reviewer comments:
… AIL change situations
Section 5.2.3 defines the mandatory DHCPv6-PD client role for the stub router. However, there are no details here what should trigger the stub router to renew/rebind the prefix lease. A reference to RFC 8415 should be added (as it contains some requirements on this topic). See section 18.2.12. Refreshing Configuration Information of RFC 8415. Do we define the SHOULD requirements of 18.2.12 about detecting a new network (new AIL) as mandatory for the stub router, or not? (If not: has consequences for wider IPv6 connectivity in such new-AIL cases) And what about the SHOULD requirement that involves "if the client detects a significant change regarding the prefixes available on the link (when new prefixes are added or existing prefixes are deprecated), as this may indicate a configuration change. " -> can we specify this better? What are the significant changes in our case? And how to do this detection? (e.g. monitor RAs?)
For this issue, we could reference the improved text in URL instead of RFC 8415. This text should be sufficient detail that stub router implementers know what to do. (Or at least, the DHC WG thinks it is enough for DHCPv6 client implementers to know what to do :-) ) PR with this pointer text is still needed.

Revised text:
Additional section.  The resolver should also include an ipv4only.arpa record in the Additional section.  <ins> 5.4. </ins> Some technologies used for stub networks, for example Thread or 6LoWPAN mesh networks, can produce partitioned networks, where what
Original text:
and the others deprecated.  By using this approach, it is not necessary for the routers to coordinate in advance. <del> 8. </del>  In order to provide network access, stub routers must provide some network services to the stub network.  We have previously discussed the following services: <del> 9. </del>  This document has no IANA actions. <del> 10. </del>  Because a SNAC router operates as an IPv6 router that sends and receives IPv6 Neighbor Discovery protocol messages, the security

Reviewer comments:
… AIL change situations
Section 5.2.3 defines the mandatory DHCPv6-PD client role for the stub router. However, there are no details here what should trigger the stub router to renew/rebind the prefix lease. A reference to RFC 8415 should be added (as it contains some requirements on this topic). See section 18.2.12. Refreshing Configuration Information of RFC 8415. Do we define the SHOULD requirements of 18.2.12 about detecting a new network (new AIL) as mandatory for the stub router, or not? (If not: has consequences for wider IPv6 connectivity in such new-AIL cases) And what about the SHOULD requirement that involves "if the client detects a significant change regarding the prefixes available on the link (when new prefixes are added or existing prefixes are deprecated), as this may indicate a configuration change. " -> can we specify this better? What are the significant changes in our case? And how to do this detection? (e.g. monitor RAs?)
For this issue, we could reference the improved text in URL instead of RFC 8415. This text should be sufficient detail that stub router implementers know what to do. (Or at least, the DHC WG thinks it is enough for DHCPv6 client implementers to know what to do :-) ) PR with this pointer text is still needed.

Revised text:
and the others deprecated.  By using this approach, it is not necessary for the routers to coordinate in advance.  <ins> 5.5. </ins> 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> 5.6. </ins> This document has no IANA actions.  <ins> 5.7. </ins> Because a SNAC router operates as an IPv6 router that sends and receives IPv6 Neighbor Discovery protocol messages, the security
Original text:
link in a Prefix Information option (RFC4861) with the following Prefix Information option header values: <del> A prefix is not considered a suitable on-link prefix if the 'L' bit is set, but the 'A' bit is not set.  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 "suitable"&#151;not all hosts can actually use it. </del>  Note: there can be layer two networks where neighbor discovery is not <del> supported and therefore we cannot set the 'L' bit, but could set the 'A' bit.  The behavior of stub networks when connecting to such networks is out of scope for this document. </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:
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:
link in a Prefix Information option (RFC4861) with the following Prefix Information option header values:  <ins> A prefix is not considered a suitable on-link prefix if the 'L' flag bit is set, but the 'A' flag bit is not set.  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 "suitable"&#151;not all hosts can actually use it. </ins> Note: there can be layer two networks where neighbor discovery is not  <ins> supported and therefore we cannot set the 'L' flag bit, but could set the 'A' flag bit.  The behavior of stub networks when connecting to such networks is out of scope for this document. </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:
The stub router may receive a router advertisement containing one or more suitable on-link prefixes on the AIL.  If any of these prefixes are different than the prefix the stub router is advertising as the <del> on-link suitable prefix, and the Stub Router flag is not set in in the Router Advertisement flags field, the stub router moves the </del>  interface to STATE-DEPRECATING (state-deprecating). <del> If the stub router bit is set in the RA header flags field, then one of the following must be true in order for that prefix to be </del>  considered suitable: 5.1.2.5.

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:
The stub router may receive a router advertisement containing one or more suitable on-link prefixes on the AIL.  If any of these prefixes are different than the prefix the stub router is advertising as the  <ins> on-link suitable prefix, and the 'Stub Router' flag bit is not set in in the Router Advertisement flags field, the stub router moves the </ins> interface to STATE-DEPRECATING (state-deprecating).  <ins> If the 'Stub Router' flag bit is set in the RA header flags field, then one of the following must be true in order for that prefix to be </ins> considered suitable: 5.1.2.5.
Original text:
A stub network that services a Wi-Fi stub network SHOULD provide DNS64 translation: hosts on the stub network cannot be assumed to be able to do DNS64 synthesis in the stub resolver.  In this case the <del> DNS resolver on the stub router MUST honor the CD and DO bits if received in a request, since this indicates that the stub resolver on the requestor intends to do DNSSEC validation.  In this case, the resolver on the stub router MUST NOT perform DNS64 synthesis. </del>  On specific stub networks it may be desirable to require the stub network device to perform DNS64 synthesis.  Stub network routers for

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:
A stub network that services a Wi-Fi stub network SHOULD provide DNS64 translation: hosts on the stub network cannot be assumed to be able to do DNS64 synthesis in the stub resolver.  In this case the  <ins> DNS resolver on the stub router MUST honor the 'CD' and 'DO' flag bits if received in a request, since this indicates that the stub resolver on the requestor intends to do DNSSEC validation.  In this case, the resolver on the stub router MUST NOT perform DNS64 synthesis. </ins> On specific stub networks it may be desirable to require the stub network device to perform DNS64 synthesis.  Stub network routers for
Original text:
Automatically Connecting Stub Networks to Unmanaged Infrastructure <del> draft-ietf-snac-simple-04 </del>  Abstract

Reviewer comments:
Update draft version "stub router flag" -> SNAC router flag fix a few cases where Esko (I think!) missed changing stub router to SNAC router but should have (there are some cases where "stub router" is correct and I hope I did not change any of those.
In the update to the 'SNAC router' name () the flag name was not yet taken along in the update. This issue is to decide on that change also, and if needed make the change. (The 6man document would also need to change the flag name then, first.)

Revised text:
Automatically Connecting Stub Networks to Unmanaged Infrastructure  <ins> draft-ietf-snac-simple-05 </ins> Abstract
Original text:
prefix) MUST also be set.  Link-layer technologies that require the 'L' flag bit to be cleared are out of scope of this document. <del> 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-SNAC- router.  For the selection of the most recent RA, the following RAs MUST be excluded: </del>  If there is no recent RA from a non-SNAC-router, both 'M' and 'O' flag bits MUST be cleared, unless the SNAC router rebooted recently.

Reviewer comments:
Update draft version "stub router flag" -> SNAC router flag fix a few cases where Esko (I think!) missed changing stub router to SNAC router but should have (there are some cases where "stub router" is correct and I hope I did not change any of those.
In the update to the 'SNAC router' name () the flag name was not yet taken along in the update. This issue is to decide on that change also, and if needed make the change. (The 6man document would also need to change the flag name then, first.)

Revised text:
prefix) MUST also be set.  Link-layer technologies that require the 'L' flag bit to be cleared are out of scope of this document.  <ins> The 'SNAC Router' flag bit (I-D.ietf-6man-snac-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-SNAC-router.  For the selection of the most recent RA, the following RAs MUST be excluded: </ins> If there is no recent RA from a non-SNAC-router, both 'M' and 'O' flag bits MUST be cleared, unless the SNAC router rebooted recently.
Original text:
The SNAC router may receive a Router Advertisement message containing one or more suitable on-link prefixes on the AIL.  If any of these prefixes are different than the prefix the SNAC router is advertising <del> as the on-link suitable prefix, and the 'Stub Router' flag bit is not </del>  set in in the Router Advertisement flags field, the SNAC router moves the interface to STATE-DEPRECATING (state-deprecating). <del> If the 'Stub Router' flag bit is set in the RA header flags field, </del>  then one of the following must be true in order for that prefix to be considered suitable:

Reviewer comments:
Update draft version "stub router flag" -> SNAC router flag fix a few cases where Esko (I think!) missed changing stub router to SNAC router but should have (there are some cases where "stub router" is correct and I hope I did not change any of those.
In the update to the 'SNAC router' name () the flag name was not yet taken along in the update. This issue is to decide on that change also, and if needed make the change. (The 6man document would also need to change the flag name then, first.)

Revised text:
The SNAC router may receive a Router Advertisement message containing one or more suitable on-link prefixes on the AIL.  If any of these prefixes are different than the prefix the SNAC router is advertising  <ins> as the on-link suitable prefix, and the 'SNAC Router' flag bit is not </ins> set in in the Router Advertisement flags field, the SNAC router moves the interface to STATE-DEPRECATING (state-deprecating).  <ins> If the 'SNAC Router' flag bit is set in the RA header flags field, </ins> then one of the following must be true in order for that prefix to be considered suitable:
Original text:
5.2. How addressability is managed on stub networks depends on the nature <del> of the stub network.  For some stub networks, the stub router can be </del>  sure that it is the only router.  For example, a SNAC router that is providing a Wi-Fi network for tethering will advertise its own SSID and use its own joining credentials; in this case, it can assume that

Reviewer comments:
Update draft version "stub router flag" -> SNAC router flag fix a few cases where Esko (I think!) missed changing stub router to SNAC router but should have (there are some cases where "stub router" is correct and I hope I did not change any of those.
In the update to the 'SNAC router' name () the flag name was not yet taken along in the update. This issue is to decide on that change also, and if needed make the change. (The 6man document would also need to change the flag name then, first.)

Revised text:
5.2. How addressability is managed on stub networks depends on the nature  <ins> of the stub network.  For some stub networks, the SNAC router can be </ins> sure that it is the only router.  For example, a SNAC router that is providing a Wi-Fi network for tethering will advertise its own SSID and use its own joining credentials; in this case, it can assume that
Original text:
and on-link prefix just like any other router. However, some stub networks are more cooperative in nature, for <del> example IP mesh networks.  On such networks, multiple stub routers </del>  may be present and be providing addressability and reachability. In either case, some SNAC router connected to the stub network MUST

Reviewer comments:
Update draft version "stub router flag" -> SNAC router flag fix a few cases where Esko (I think!) missed changing stub router to SNAC router but should have (there are some cases where "stub router" is correct and I hope I did not change any of those.
In the update to the 'SNAC router' name () the flag name was not yet taken along in the update. This issue is to decide on that change also, and if needed make the change. (The 6man document would also need to change the flag name then, first.)

Revised text:
and on-link prefix just like any other router. However, some stub networks are more cooperative in nature, for  <ins> example IP mesh networks.  On such networks, multiple SNAC routers </ins> may be present and be providing addressability and reachability. In either case, some SNAC router connected to the stub network MUST