jiebi/CodeConvo huggingface dataset:
Code change:
… 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.

Related discussion:
text: preference, the stub router SHOULD deprecate the prefix it is advertising. <del> 6.1. </del> <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.
Code change:
… 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.

Related discussion:
text: NAT64 service on the stub network if it has not acquired the OSNR prefix through DHCPv6 Prefix Delegation. <del> 6.2. </del> <ins> 5.3.2. </ins> Most infrastructure networks at present do not provide NAT64 service. Many infrastructure networks do not provide DHCPv6 Prefix Delegation.
Code change:
… 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.

Related discussion:
text: Additional section.  The resolver should also include an ipv4only.arpa record in the Additional section. <del> 7. </del> <ins> 5.4. </ins> Some technologies used for stub networks, for example Thread or 6LoWPAN mesh networks, can produce partitioned networks, where what
Code change:
… 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.

Related discussion:
text: and the others deprecated.  By using this approach, it is not necessary for the routers to coordinate in advance. <del> 8. </del> <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: <del> 9. </del> <ins> 5.6. </ins> This document has no IANA actions. <del> 10. </del> <ins> 5.7. </ins> Because a SNAC router operates as an IPv6 router that sends and receives IPv6 Neighbor Discovery protocol messages, the security
Code change:
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.

Related discussion:
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> <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 <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> <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
Code change:
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.

Related discussion:
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> <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
Code change:
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.

Related discussion:
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> <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). <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> <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.
Code change:
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.

Related discussion:
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> <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
Code change:
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.)

Related discussion:
text: Automatically Connecting Stub Networks to Unmanaged Infrastructure <del> draft-ietf-snac-simple-04 </del> <ins> draft-ietf-snac-simple-05 </ins> Abstract
Code change:
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.)

Related discussion:
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> <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.
Code change:
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.)

Related discussion:
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> <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). <del> If the 'Stub Router' flag bit is set in the RA header flags field, </del> <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:
Code change:
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.)

Related discussion:
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> <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
Code change:
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.)

Related discussion:
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> <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
Code change:
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.)

Related discussion:
text: 5.2.2. In order to be able to provide addressability either on the stub <del> network or on an adjacent infrastructure network, a stub router MUST </del> <ins> network or on an adjacent infrastructure network, a SNAC router MUST </ins> allocate its own ULA Site Pefix.  ULA prefixes, described in Unique Local IPv6 Unicast Addresses (RFC4193) are randomly allocated prefixes.  A SNAC router MUST allocate a single ULA Site Prefix for
Code change:
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.)

Related discussion:
text: 5.3. SNAC routers MUST advertise reachability to stub network OSNR <del> prefixes on any AIL to which they are connected.  If the stub router </del> <ins> prefixes on any AIL to which they are connected.  If the SNAC router </ins> is advertising a suitable prefix on any interface, any such prefixes MUST be advertised on that interface in the same Router Advertisement message that is advertising the suitable prefix, to avoid unnecessary
Code change:
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.)

Related discussion:
text: The SNAC router MAY advertise itself as a default router on the stub network, if it itself has a default route on the AIL.  In some cases it may not be desirable to advertise reachability to the Internet as <del> a whole; in this case the stub router is not required to advertise </del> <ins> a whole; in this case the SNAC router is not required to advertise </ins> itself as a default router. If the SNAC router is not advertising itself as a default router on
Code change:
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.)

Related discussion:
text: that received it. Consequently, SNAC routers SHOULD be configurable to not advertise <del> themselves as default routers on the stub network.  Stub routers </del> <ins> themselves as default routers on the stub network.  SNAC routers </ins> SHOULD be configurable to explicitly advertise AIL prefixes on the stub network even if they are advertising as a default router.  The mechanisms by which such configuration can be accomplished are out of