jiebi/TextFlow huggingface dataset:
Original 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>  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

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.2. In order to be able to provide addressability either on the stub  <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
Original 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>  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

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.3. SNAC routers MUST advertise reachability to stub network OSNR  <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
Original 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>  itself as a default router. If the SNAC router is not advertising itself as a default router on

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 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  <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
Original 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>  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

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:
that received it. Consequently, SNAC routers SHOULD be configurable to not advertise  <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
Original text:
If the DHCPv6-PD client determines that the prefix it provided to use as the OSNR prefix is no longer valid, and no replacement prefix is provided by the DHCPv6 server, then the SNAC router MUST switch to <del> the ULA link prefix that it has allocated for use on the SNAC </del>  network.  In the case that the DHCPv6-PD client is unable to renew its lease on the current OSNR prefix, and time between the T2 interval for the prefix assignment I-D.ietf-dhc-rfc8415bis and the

Reviewer comments:
As Esko pointed out, the term "SNAC network" crept in during editing a few weeks ago, and doesn't add value. This pull request changes all instances of "SNAC network" to "stub network".
In -05, the term "SNAC network" is now used but not defined. Could we use the more generic term "stub network" instead? I.e. a SNAC router is able to automatically connect a stub network to an infrastructure network. So the stub network served by this SNAC router is still a "stub network". Or we could use the term "SNAC network" for any stub network that gets automatically connected via a SNAC router. But doing this adds an extra term throughout the document: it's not possible to mass-replace all occurrences of "stub network".
See also which overlaps with this issue, but targets a specific definition paragraph.
Right, this happened when we added a bunch of text in the last interim, and I think was a mistake. I think we just want to use the term "stub network" and not invent a new term. The thing that's new here is the "SNAC router", not the stub network.
I agree - "stub network" makes more sense here.
removed

Revised text:
If the DHCPv6-PD client determines that the prefix it provided to use as the OSNR prefix is no longer valid, and no replacement prefix is provided by the DHCPv6 server, then the SNAC router MUST switch to  <ins> the ULA link prefix that it has allocated for use on the stub </ins> network.  In the case that the DHCPv6-PD client is unable to renew its lease on the current OSNR prefix, and time between the T2 interval for the prefix assignment I-D.ietf-dhc-rfc8415bis and the
Original text:
6. <del> SNAC networks rely on IPv6 to enable routing between links, which </del>  would not be possible with IPv4 due to the lack of a standard mechanism similar to Router Advertisements in IPv4.  However, it can <del> stll be useful for hosts on the SNAC network to establish </del>  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 <del> enables IPv6 hosts on the SNAC network to discover and reach with </del>  IPv4 hosts on infrastructure, but does not provide a way for IPv4-only hosts on infrastructure to communicate to IPv6 hosts on the <del> SNAC network. </del>  This should be acceptable because hosts on the infrastructure network should not be IPv4-only, since the SNAC router is providing IPv6

Reviewer comments:
As Esko pointed out, the term "SNAC network" crept in during editing a few weeks ago, and doesn't add value. This pull request changes all instances of "SNAC network" to "stub network".
In -05, the term "SNAC network" is now used but not defined. Could we use the more generic term "stub network" instead? I.e. a SNAC router is able to automatically connect a stub network to an infrastructure network. So the stub network served by this SNAC router is still a "stub network". Or we could use the term "SNAC network" for any stub network that gets automatically connected via a SNAC router. But doing this adds an extra term throughout the document: it's not possible to mass-replace all occurrences of "stub network".
See also which overlaps with this issue, but targets a specific definition paragraph.
Right, this happened when we added a bunch of text in the last interim, and I think was a mistake. I think we just want to use the term "stub network" and not invent a new term. The thing that's new here is the "SNAC router", not the stub network.
I agree - "stub network" makes more sense here.
removed

Revised text:
6.  <ins> stub networks rely on IPv6 to enable routing between links, which </ins> would not be possible with IPv4 due to the lack of a standard mechanism similar to Router Advertisements in IPv4.  However, it can  <ins> stll be useful for hosts on the stub network to establish </ins> 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  <ins> enables IPv6 hosts on the stub network to discover and reach with </ins> IPv4 hosts on infrastructure, but does not provide a way for IPv4-only hosts on infrastructure to communicate to IPv6 hosts on the  <ins> stub network. </ins> This should be acceptable because hosts on the infrastructure network should not be IPv4-only, since the SNAC router is providing IPv6
Original text:
Prefix Information option header values: A prefix is not considered a suitable on-link prefix if the 'L' flag <del> 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. </del>  Note: there can be layer two networks where neighbor discovery is not supported and therefore we cannot set the 'L' flag bit, but could set

Reviewer comments:
Add text to the suitable prefix section that allows a prefix that is local and has either the A flag or the P flag set to be considered usable, whereas before only prefixes with the A flag set were considered usable.

Revised text:
Prefix Information option header values: A prefix is not considered a suitable on-link prefix if the 'L' flag  <ins> bit is not set, or if neither the 'A' flag bit nor the 'P' flag bit is set.  When the 'A' flag bit is not set, this indicates that individual node addresses within the prefix are being managed using DHCPv6.  If the 'P' flag bit is set, then hosts that wish to allocate their own addresses can do so by acquiring a prefix from which to allocate them using DHCPv6 Prefix Delegation RFC 9663.  Nodes are not required to use DHCPv6 to acquire individual addresses, so a prefix that requires the use of DHCPv6 for that purpose 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 supported and therefore we cannot set the 'L' flag bit, but could set
Original text:
it MUST use DHCPv6 PD rather than the ULA Link prefix it allocated for the stub network out of its ULA Site Prefix. <del> A SNAC router SHOULD request stub network prefixes with length 64. If the SNAC router obtains a prefix with length less than 64, it SHOULD generate a /64 from the obtained prefix by padding with zeros. If the SNAC router obtains a prefix with length greater than 64, the SNAC router MUST treat the prefix as unsuitable and allocate a ULA Link Prefix out of its ULA Site Prefix instead. </del>  A DHCPv6-PD client can request a particular lease interval for the DHCPv6-delegated prefix.  However, there is no particular reason for

Reviewer comments:
This change does two things: change the SHOULD to a MUST when specifying what size of prefix to request, so that only requests for /64 prefixes are allowed, and providing a reference to RFC8415 that says how to provide such a hint. Additional text describes what to do if there is more than one prefix.
OLD: A SNAC router SHOULD request stub network prefixes with length 64. New: A SNAC router should request stub network prefixes using IAPD with IAPrefix with a hint of 64 as defined in RFC 8415 Section 18.3.9.
Agree with adding the details. Is there a reason to change SHOULD -> should ? Seems wise to keep the SHOULD in caps given the MUST requirement that follows soon after it:

Revised text:
it MUST use DHCPv6 PD rather than the ULA Link prefix it allocated for the stub network out of its ULA Site Prefix.  <ins> A SNAC router MUST request stub network prefixes with length 64.  It does so by sending an IA_PD option for each prefix, each with a different IAID, containing an IA_PREFIX with a hint of 64 as described in RFC8415.  If the SNAC router obtains a prefix with length less than 64, it SHOULD generate a /64 from the obtained prefix by padding with zeros.  If the SNAC router obtains a prefix with length greater than 64, the SNAC router MUST treat the prefix as unsuitable and allocate a ULA Link Prefix out of its ULA Site Prefix instead. </ins> A DHCPv6-PD client can request a particular lease interval for the DHCPv6-delegated prefix.  However, there is no particular reason for
Original text:
BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here.  3. Basic Service Authentication

Reviewer comments:
Initial try at the definition of a workload.
Closes issue
I think we could be a bit more specific here. Every software is executed for a purpose... I believe the key practical difference between workload identity and user run software such as browsers and interactive applications in that there is no user to perform some interactive authentication flow. Maybe we could try and reflect that? For example, For the purpose of this document, workload is defined as a non-interactive instance of software interacting over network with other software and services. Certain workloads can be live for a very short durations of time (nanoseconds) and run for a specific purpose such as to provide a response to an API request. Other kinds of workloads might be executed for a very long durations such as months or years - examples include database services and machine learning training jobs.
I think I understand what your are saying, but I'm not sure I can express it yet. Also it seems there maybe some special workloads that do interact with user authentication mechanisms. Perhaps those are architecturally distinct pieces "Authenticaition Services"

Revised text:
BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. <ins> 2.1. Workload A workload is a running instance of software executing for a specific purpose that interacts with other parts of a larger system.  A workload may exist for a very short durations of time (nanoseconds) and run for a specific purpose such as to provide a response to an API request.  Other kinds of workloads may execute for a very long duration such as months or years - examples include database services and machine learning training jobs. </ins> 3. Basic Service Authentication
Original text:
3.2.  3.3. <del> The identity is provisioned to the workload as a set of credentials. There are two main types of workload credentials: bearer tokens and X.509 certificates. </del>  Bearer tokens are tokens presented to another party as proof of identity.  They are typically signed to prevent forgery, however

Reviewer comments:
added Attestation as a function performed within the Server box. defined Agent. defined Attestation.
Thanks I think this helps my understanding, I'm sure we'll have more refining to do, but thanks for providing the text to get started.

Revised text:
3.2. <ins> The server issues workload identity credentials when requested by the Agent. </ins> 3.3.  <ins> The Agent performs the function of transmitting the initial workload identity to the Server to obtain the workload identity credentials. The Agent makes the workload identity credentials available to the workload. A task scheduler installs and starts a task containing the Agent on the Host Operating System.  A Host Operating System function performs attestation of the Agent-identity and issues a corresponding Agent- credential to the Agent.  The Agent presents the Agent-credential together with the Workload Identity to the Server to obtain the Workload's Identity Credentials. 3.4. Attestation is the function through which a task verifies the identity of a separate Workload or task. During Workload Attestation, the Server verifies the Agent- credential, Workload Identity, and the permission of the Agent to receive Credentials authenticating the Workload Identity.  The Server can use a variety of means to verify that permission, including a Policy decision based on the contents of a Workload Registration database or requesting assistance from a trusted Identity Provider. 3.5. The Agent provisions the identity credentials to the workload.  There are two main types of workload credentials: bearer tokens and X.509 certificates. </ins> Bearer tokens are tokens presented to another party as proof of identity.  They are typically signed to prevent forgery, however
Original text:
the presenter has access to the private key that corresponds to the public key in the certificate. <del> 3.4. </del>  One of the most basic use cases for workload identity is for authenticating one workload to another such as in the case where one

Reviewer comments:
added Attestation as a function performed within the Server box. defined Agent. defined Attestation.
Thanks I think this helps my understanding, I'm sure we'll have more refining to do, but thanks for providing the text to get started.

Revised text:
the presenter has access to the private key that corresponds to the public key in the certificate.  <ins> 3.6. </ins> One of the most basic use cases for workload identity is for authenticating one workload to another such as in the case where one
Original text:
TLS authentication of the server and HTTP request signing using a secret key. <del> 3.5. </del>  In a typical system of workloads additional information is needed in order for the workload to perform its function.  For example, it is

Reviewer comments:
added Attestation as a function performed within the Server box. defined Agent. defined Attestation.
Thanks I think this helps my understanding, I'm sure we'll have more refining to do, but thanks for providing the text to get started.

Revised text:
TLS authentication of the server and HTTP request signing using a secret key.  <ins> 3.7. </ins> In a typical system of workloads additional information is needed in order for the workload to perform its function.  For example, it is
Original text:
only be used by an authorized workload and that the context information originated from an authorized workload. <del> 3.6. </del>  TBD. <del> 3.7. </del>  TBD. <del> 3.8. </del>  As workloads often need to communicate across administrative boundaries, extra care needs to be taken when it comes to identity communication to ensure scalability and privacy. <del> 3.8.1. </del>  A workload communicating with a service, or another workload provided by an external organization may need to provide more generic identity

Reviewer comments:
added Attestation as a function performed within the Server box. defined Agent. defined Attestation.
Thanks I think this helps my understanding, I'm sure we'll have more refining to do, but thanks for providing the text to get started.

Revised text:
only be used by an authorized workload and that the context information originated from an authorized workload.  <ins> 3.8. </ins> TBD.  <ins> 3.9. </ins> TBD.  <ins> 3.10. </ins> As workloads often need to communicate across administrative boundaries, extra care needs to be taken when it comes to identity communication to ensure scalability and privacy.  <ins> 3.10.1. </ins> A workload communicating with a service, or another workload provided by an external organization may need to provide more generic identity
Original text:
workload specific identity with a generalized one for a given administrative domain. <del> 3.8.2. </del>  Inbound security gateway is a common design pattern for service protection.  This functionality is often found in CDN services, API

Reviewer comments:
added Attestation as a function performed within the Server box. defined Agent. defined Attestation.
Thanks I think this helps my understanding, I'm sure we'll have more refining to do, but thanks for providing the text to get started.

Revised text:
workload specific identity with a generalized one for a given administrative domain.  <ins> 3.10.2. </ins> Inbound security gateway is a common design pattern for service protection.  This functionality is often found in CDN services, API
Original text:
One of the most basic use cases for workload identity is authentication of one workload to another, such as in the case where <del> one service is making a request to another service within a larger application.  Even in this simple case the identity of a workload is </del>  often composed of many attributes such as: Trigger Information

Reviewer comments:
Updated figure in
NAME I made a slight update to remove the word authentication in the text since authentication is one specific type of interaction, there may be many others. This might also be a good place to introduce "context" that is propagated (although that seems to be more a topic of the next section

Revised text:
One of the most basic use cases for workload identity is authentication of one workload to another, such as in the case where  <ins> one service is making a request to another service as part of a larger, more complex application.  Following authentication, the request to the service offered by the workload it needs to be authorized.  Even in this simple case the identity of a workload is </ins> often composed of many attributes such as: Trigger Information
Original text:
TLS authentication of the server and HTTP request signing using a secret key.  3.2.2. In a typical system of workloads additional information is needed in

Reviewer comments:
Updated figure in
NAME I made a slight update to remove the word authentication in the text since authentication is one specific type of interaction, there may be many others. This might also be a good place to introduce "context" that is propagated (although that seems to be more a topic of the next section

Revised text:
TLS authentication of the server and HTTP request signing using a secret key. <ins> arch-chain illustrates the communication between different workloads. Two aspects are important to highlight: First, there is a need to consider the interaction with workloads that are external to the trust domain (sometimes called cross-domain).  Second, the interaction does not only occur between workloads that directly interact with each other but instead may also take place across intermediate workloads (in an end-to-end style). </ins> 3.2.2. In a typical system of workloads additional information is needed in