jiebi/CodeConvo huggingface dataset:
Code change:
states: | If IPv6 prefix delegation is available, which implies that IPv6 | service is also available on the infrastructure link, then the stub | router MAY use IPv6 prefix delegation to acquire a prefix to | advertise on the stub network, rather than allocating one out of its | ULA prefix. and 5.2.3: | Therefore, when DHCPv6-PD is available, the stub router MUST use DHCPv6 | PD rather than its own prefix. That's contradictory, I suppose 5.2.2 should say: | If IPv6 prefix delegation is available, which implies that IPv6 | service is also available on the infrastructure link, then the stub | router MUST use IPv6 prefix delegation to acquire a prefix to | advertise on the stub network, rather than allocating one out of its | ULA prefix. Or maybe just drop the last paragraph from 5.2.2 entirely. URL
Esko adds: What about the case where DHCPv6-PD is available, but the stub router doesn’t get the desired prefix length or encounters some error in the process? In that exceptional case it still MAY allocate a prefix out of its ULA prefix. Depending on the reader, “is available” and “works for me” can be different things.
My suggestion: Right, MAY would be way too unspecific in that case. MAY basically says "we aren't saying you shouldn't do this, nor that you mustn't do this." :) So I think as you say that what we really need here is to be more specific about exactly what "is available" means. So, perhaps: If IPv6 prefix delegation and IPv6 service is both available on the infrastructure link, then the stub router MUST attempt to acquire a prefix using IPv6 prefix delegation. and Therefore, when the stub router is able to successfully acquire a prefix using DHCPv6-PD, it MUST use DHCPv6 PD rather than its own self-generated ULA prefix.
Explain what to do if prefix is to narrow, and also if it is too wide. states: | If IPv6 prefix delegation is available, which implies that IPv6 | service is also available on the infrastructure link, then the stub | router MAY use IPv6 prefix delegation to acquire a prefix to | advertise on the stub network, rather than allocating one out of its | ULA prefix. and 5.2.3: | Therefore, when DHCPv6-PD is available, the stub router MUST use DHCPv6 | PD rather than its own prefix. That's contradictory, I suppose 5.2.2 should say: | If IPv6 prefix delegation is available, which implies that IPv6 | service is also available on the infrastructure link, then the stub | router MUST use IPv6 prefix delegation to acquire a prefix to | advertise on the stub network, rather than allocating one out of its | ULA prefix. Or maybe just drop the last paragraph from 5.2.2 entirely. In my defence, I have been left unsupervised.

Related discussion:
text: Automatically Connecting Stub Networks to Unmanaged Infrastructure <del> draft-ietf-snac-simple-00 </del> <ins> draft-ietf-snac-simple-01 </ins> Abstract
Code change:
The Makefile allows easy building of .txt, .html, or both output files.
NAME Maybe you can merge this PR, or give me write access so I can do it ;-) ?

Related discussion:
text: Automatically Connecting Stub Networks to Unmanaged Infrastructure <del> draft-ietf-snac-simple-02 </del> <ins> draft-ietf-snac-simple-04 </ins> Abstract
Code change:
Refer to state-begin-advertising to describe the states when ULA site prefix is advertised.
has currently: The "as needed" part here is not so clear and needs to be detailed. E.g. only if an on-link prefix on the AIL is not present, the stub router provides one from its own ULA prefix only if the stub network does not have an on-link prefix or on-mesh prefix (whatever applies), then it creates one from its own ULA prefix. sizes of the involved prefixes? Better to either specify sizes or say it's up to implementation. state some randomness requirements - although for the ULA Global ID it may be clear that it must be randomized; we also have Subnet ID to have requirements for (or not). In any case state these assumptions.
This can be resolved easily by a pointer to other parts of the draft ("as defined in Section N"). Because there are still some pending PRs that impact the text here and add the details, this issue can be postponed until after these PRs are merged.

Related discussion:
text: Local IPv6 Unicast Addresses (RFC4193) are randomly allocated prefixes.  A stub router MUST allocate a single ULA Site Prefix for use in providing on-link prefixes to the stub network and the <del> adjacent infrastructure link, as needed. </del> <ins> adjacent infrastructure link as described in state-begin-advertising. </ins> Any ULA Link Prefixes allocated by a stub router SHOULD be maintained across reboots, and SHOULD remain stable over time.  (TBD: mention
Code change:
Current Github text (May 9) still has the text In the last SNAC interim and a recent PR we changed this to L flag MUST be set (case of L=0 is out of scope). Above text still needs to be updated accordingly.

Related discussion:
text: the interface.  This prefix has a valid and preferred lifetime of STUB_PROVIDED_PREFIX_LIFETIME seconds.  The stub router sends a router advertisement (RA) containing this prefix in a Prefix <del> Information Option (PIO).  In the PIO, the A (autonomous configuration) flag RFC4861 MUST be set and the L (on-link) flag SHOULD be set.  The exception cases where the L flag can be cleared is where the specific link-layer technology and/or configuration requires clearing the L flag. </del> <ins> Information Option (PIO).  In the PIO, the 'A' flag bit (autonomous 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. </ins> 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
Code change:
In internet drafts, the IANA Considerations and Security Considerations sections are mandatory. Exact text for security can be adapted also later on if needed.
It's not really true that stub routers create a security problem by sending RAs: rather, it's the case that this security problem potentially exists on networks where RA guard is present, but this issue is in no way our responsibility, and probably shouldn't be mentioned in security considerations.
NAME I've removed the RA Guard text. It was there not because SNAC-routers introduce a security issue, but because we think that there's a group of people/network-administrators/IETFers/others who consider any device that can autostart acting as IPv6 router and can autostart sending ND message on a link as a "security hazard" even if it's not. Mentioning RA Guard there could be a proactive way to hopefully avoid too many discussions around this during future document reviews.
For security we may add: risk of advertising self-generated ULA prefix? Any specifics? if site employs technology like RA-guard, the RAs of our unmanaged stub router will be blocked
These sound more like operational considerations than security considerations. I suppose if we want to advise sites that do not want stub routers attaching to block RA, that would make sense, but I don't think that's really a problem unique to stub routers. Regarding the ULA prefix, the only risk is one we've already addressed: that the prefix could be used for tracking. I think the text on varying prefixes per-link probably needs work, but that addresses the privacy concern.

Related discussion:
text: 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> 9. This document has no IANA actions. 10. Because a SNAC router operates as an IPv6 router that sends and receives IPv6 Neighbor Discovery protocol messages, the security considerations of Section 11 of RFC4861 apply.  No additional security considerations are identified. </ins>
Code change:
Closing issue This PR is not building, so need to clean it up before commit. Comments appreciated during that process.
NAME PR is still needed before anything can build ;-)
NAME NAME sorry I didn't intend to close this PR, Github did that somehow after me pushing to the branch. But it's good to have this one closed and replaced by , because the merge direction was specified here the wrong way around. The build is now fixed in the branch and also updated to make it merge-able into main. I prefer to merge rather sooner than later - nits can be corrected with future PRs easily.

Related discussion:
text: all times, when a new host arrives on the AIL, it is able to acquire an IPv6 address on that link. <ins> During all of the states mentioned here except for state-unknown, the SNAC router is expected to treat the infrastructure interface as an Advertising Interface as described in RFC4861.  There are two sets of information that need to be sent in an RA; if neither is present, then the SNAC router SHOULD NOT send an RA even if it is treating the infrastructure interface as an advertising interface. These two sets of information are the on-link prefix, if any, that is to be advertised.  Whether or not such a prefix is advertised, and what exactly is advertised regarding that prefix, is determined by the state machine.  The other set of information is a set of routes to prefixes on the SNAC network.  Whenever we know of a reachable (scope is not link-local) prefix on the SNAC network, we include an RIO option in the RA on the infrastructure network indicating that that prefix is reachable through the SNAC router. It is important to note that it is possible for an on-link, routable prefix to be advertised and then withdrawn on the SNAC network, but for it to still be valid, and for there to still be some communication occurring using that prefix.  In order to avoid prematurely interrupting such communication, the SNAC router MUST maintain a list of prefixes known to be valid on the SNAC network, even if those prefixes have been deprecated, and MUST include RIO options for all such prefixes in the RAs that it sends on the adjacent infrastructure link. </ins> 5.1.2.1. When the stub router interface first connects to the AIL, it MUST
Code change:
Closing issue This PR is not building, so need to clean it up before commit. Comments appreciated during that process.
NAME PR is still needed before anything can build ;-)
NAME NAME sorry I didn't intend to close this PR, Github did that somehow after me pushing to the branch. But it's good to have this one closed and replaced by , because the merge direction was specified here the wrong way around. The build is now fixed in the branch and also updated to make it merge-able into main. I prefer to merge rather sooner than later - nits can be corrected with future PRs easily.

Related discussion:
text: 5.1.2.2. <del> When entering this state, if the router MUST discontinue treating the interface as an Advertising Interface as described in RFC4861, if it has been doing so. </del> When a new host appears on the AIL and sends an initial router solicit, if it does not receive a suitable on-link prefix, it will not be able to communicate.  Consequently, the stub router MUST
Code change:
Closing issue This PR is not building, so need to clean it up before commit. Comments appreciated during that process.
NAME PR is still needed before anything can build ;-)
NAME NAME sorry I didn't intend to close this PR, Github did that somehow after me pushing to the branch. But it's good to have this one closed and replaced by , because the merge direction was specified here the wrong way around. The build is now fixed in the branch and also updated to make it merge-able into main. I prefer to merge rather sooner than later - nits can be corrected with future PRs easily.

Related discussion:
text: the interface.  This prefix has a valid and preferred lifetime of STUB_PROVIDED_PREFIX_LIFETIME seconds.  The stub router sends a router advertisement (RA) containing this prefix in a Prefix <del> Information Option (PIO).  In the PIO, the A (autonomous configuration) flag RFC4861 MUST be set and the L (on-link) flag SHOULD be set.  The exception cases where the L flag can be cleared is where the specific link-layer technology and/or configuration requires clearing the L flag. </del> <ins> Information Option (PIO).  In the PIO, the 'A' flag bit (autonomous 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. </ins> 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
Code change:
Closing issue This PR is not building, so need to clean it up before commit. Comments appreciated during that process.
NAME PR is still needed before anything can build ;-)
NAME NAME sorry I didn't intend to close this PR, Github did that somehow after me pushing to the branch. But it's good to have this one closed and replaced by , because the merge direction was specified here the wrong way around. The build is now fixed in the branch and also updated to make it merge-able into main. I prefer to merge rather sooner than later - nits can be corrected with future PRs easily.

Related discussion:
text: 6. <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 mechanism similar to router advertisements in IPv4.  However, it can stll be useful for hosts on the SNAC network to establish communications with IPv4-only hosts on the infrastructure network. Although NAT64 provides IPv6-only hosts with a way to reach IPv4 hosts, there is no easy way for an IPv4 host to use NAT64 to originate communication with an IPv6 host.  Therefore, this document enables IPv6 hosts on the SNAC network to discover and reach with IPv4 hosts on infrastructure, but does not provide a way for IPv4-only hosts on infrastructure to communicate to IPv6 hosts on the SNAC network. This should be acceptable because hosts on the infrastructure network should not be IPv4-only, since the SNAC router is providing IPv6 service on the infrastructure network that is suitable for communicating using IPv6 to hosts on the SNAC network--there should not be any hosts on the infrastructure network that can't communicate with hosts on the stub network unless such hosts do not have an IPv6 stack at all. So the purpose of providing IPv4 connectivity for SNAC hosts is to enable communication with arbitrary IPv4 hosts which may not be on the AIL.  This is accomplished by providing NAT64 address translation in the stub router, and by enabling service discovery using a Discovery Proxy. </ins> Stub Network routers must be capable of providing NAT64 themselves, and must be capable of discovering the availability of NAT64 service on the infrastructure network and providing it when it is available
Code change:
Closing issue This PR is not building, so need to clean it up before commit. Comments appreciated during that process.
NAME PR is still needed before anything can build ;-)
NAME NAME sorry I didn't intend to close this PR, Github did that somehow after me pushing to the branch. But it's good to have this one closed and replaced by , because the merge direction was specified here the wrong way around. The build is now fixed in the branch and also updated to make it merge-able into main. I prefer to merge rather sooner than later - nits can be corrected with future PRs easily.

Related discussion:
text: 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> 9. This document has no IANA actions. 10. Because a SNAC router operates as an IPv6 router that sends and receives IPv6 Neighbor Discovery protocol messages, the security considerations of Section 11 of RFC4861 apply.  No additional security considerations are identified. </ins>
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: for example, it may be the home router providing connectivity to an ISP. <del> 5.4. </del> <ins> 5.2.5. </ins> The stub 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
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: presence of such routes, and MUST advertise reachability to them on interfaces connected to stub networks. <del> 5.5. </del> <ins> 5.2.6. </ins> Since DNS-SD is in wide use, and provides for ad-hoc, self- configuring advertising using the mDNS transport, this is a suitable
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: mechanisms provided by the infrastructure.  Therefore, stub routers MUST provide DNS-SD service as described in this section. <del> 5.5.1. </del> <ins> 5.2.6.1. </ins> The adjacent infrastructure can be assumed to already enable some service discovery mechanism between hosts on the infrastructure
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: infrastructure network, and is therefore out of scope for this document. <del> 5.5.2. </del> <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,
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: specific mechanism, the details of which are out of scope for this document. <del> 6. </del> <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