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

Related discussion:
text: 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 <del> 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 </del> <ins> to prefixes on the stub network.  Whenever we know of a reachable (scope is not link-local) prefix on the stub network, we include an </ins> 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 <del> prefix to be advertised and then withdrawn on the SNAC network, but </del> <ins> prefix to be advertised and then withdrawn on the stub network, but </ins> 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 <del> maintain a list of prefixes known to be valid on the SNAC network, </del> <ins> maintain a list of prefixes known to be valid on the stub network, </ins> 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.
Code change:
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

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

Related discussion:
text: the ULA link prefix. A failure to renew the DHCPv6-PD-provided OSNR prefix could be <del> because the SNAC network has been disconnected from one AIL and moved </del> <ins> because the stub network has been disconnected from one AIL and moved </ins> to a different AIL.  In this situation, if the new AIL also has IPv6 service and DHCPv6-PD service, the DHCPv6 client will get a clear indication that the old prefix is no longer valid.  However, it may be that no DHCPv6-PD service is available on the new link, either because it is an IPv4-only link or because it's an IPv6-capable link <del> that doesn't provide DHCPv6 service.  In this situation, if the SNAC </del> <ins> that doesn't provide DHCPv6 service.  In this situation, if the stub </ins> network remains connected to the link and no DHCPv6 service appears, the DHCPv6-PD-provided OSNR prefix will eventually time out and be replaced.  The SNAC router SHOULD NOT attempt to replace it prior to this normal timeout process, because there is no benefit to changing <del> the OSNR prefix on the SNAC network in such a situation, and it's </del> <ins> the OSNR prefix on the stub network in such a situation, and it's </ins> possible that the SNAC router will return to the other link before the OSNR prefix expires.
Code change:
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

Related discussion:
text: 6. <del> SNAC networks rely on IPv6 to enable routing between links, which </del> <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 <del> stll be useful for hosts on the SNAC network to establish </del> <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 <del> enables IPv6 hosts on the SNAC network to discover and reach with </del> <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 <del> SNAC network. </del> <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
Code change:
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.

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

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

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

Related discussion:
text: 3.2. <ins> The server issues workload identity credentials when requested by the Agent. </ins> 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> <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
Code change:
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.

Related discussion:
text: the presenter has access to the private key that corresponds to the public key in the certificate. <del> 3.4. </del> <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
Code change:
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.

Related discussion:
text: TLS authentication of the server and HTTP request signing using a secret key. <del> 3.5. </del> <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
Code change:
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.

Related discussion:
text: only be used by an authorized workload and that the context information originated from an authorized workload. <del> 3.6. </del> <ins> 3.8. </ins> TBD. <del> 3.7. </del> <ins> 3.9. </ins> TBD. <del> 3.8. </del> <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. <del> 3.8.1. </del> <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
Code change:
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.

Related discussion:
text: workload specific identity with a generalized one for a given administrative domain. <del> 3.8.2. </del> <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
Code change:
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

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

Related discussion:
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
Code change:
Fixed some of the wording and parallelism in the intro to keep the same ordering of X.509 certificates followed by Workload identity tokens. Generalized some of the phrasing. Removed concepts that aren't well defined in the document, such as "bottom turtle". I'm not opposed to adding these, I just don't think they make sense without an explanation of the analogy either inline or by-reference; so I tended towards keeping the document self-contained. Provided initial content for the Delegation and Impersonation, and Asynchronous and Batch Requests sections.

Related discussion:
text: identifier as a concept as well] A workload needs to obtain its identity early in its lifecycle.  This <del> identity is sometimes referred to as the "bottom turtle" on which further identity and security context is built. </del> <ins> identity is the base identity upon which further identity and security context are built. </ins> Identity bootstrapping often utilizes identity information provisioned through mechanisms specific to hosting platforms and orchestration services.  This initial bootstrapping information is used to obtain specific identity credentials for a workload.  This <del> process may use attestation to ensure the workload receives correct identity credentials.  An example of a bootstrapping process follows. </del> <ins> process may use attestation to ensure the workload receives the correct identity credentials.  An example of a bootstrapping process follows. </ins> arch-fig provides an example of software layering at a host running workloads.  During startup, workloads bootstrap their identity with the help of an agent.  The agent may be associated with one or more workloads to help ensure that workloads are provisioned with the correct identity.  The agent provides attestation evidence and other <del> relevant information to a server.  After obtaining identity credentials from the Server it passes them to the workload.  The server validates this information and provides the agent with identity credentials for the workloads it is associated with.  The server can use a variety of internal and external means to validate the request against policy. </del> <ins> relevant information to a server.  The server validates this information and provides the agent with identity credentials for the workloads it is associated with.  The server can use a variety of internal and external means to validate the request against policy. After obtaining identity credentials from the Server, the agent passes them to the workload. </ins> How the workload obtains its identity credentials and interacts with the agent is subject to different implementations.  Some common
Code change:
Fixed some of the wording and parallelism in the intro to keep the same ordering of X.509 certificates followed by Workload identity tokens. Generalized some of the phrasing. Removed concepts that aren't well defined in the document, such as "bottom turtle". I'm not opposed to adding these, I just don't think they make sense without an explanation of the analogy either inline or by-reference; so I tended towards keeping the document self-contained. Provided initial content for the Delegation and Impersonation, and Asynchronous and Batch Requests sections.

Related discussion:
text: authentication of one workload to another, such as in the case where one service is making a request to another service as part of a larger, more complex application.  Following authentication, the <del> request to the service offered by the workload it needs to be </del> <ins> request to the service offered by the workload needs to be </ins> authorized.  Even in this simple case the identity of a workload is often composed of many attributes such as: