jiebi/CodeConvo huggingface dataset:
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.
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
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
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
able to interoperate with hosts on other network links in the same infrastructure as well as hosts on the global internet. <del> It may be noted that just as you can plug several Home Gateway devices together in series to form multi-layer NATs, there is nothing </del> <ins> It may be noted that just as you can plug several CE Router devices together in series to form multi-layer NATs, there is nothing </ins> preventing the owner of a stub network router from attaching it to a stub network as if that network were its infrastructure network.  In the case of an IoT wireless network, there may be no way to do this,
The sent Router Advertisement message MUST also include a Route Information option (RFC4191) for each routable prefix advertised on <del> the stub network.  If the SNAC router is also a normal router (e.g. a home WiFi router), it SHOULD include all other routes that it is advertising in the RA, if there is space. </del> <ins> the stub network. </ins> After having sent the initial Router Advertisement, the SNAC router moves the interface into the STATE-ADVERTISING-SUITABLE state (state-
network SHOULD advertise reachability to all such prefixes on any AIL to which it is attached using router advertisements. <del> A SNAC router SHOULD NOT advertise itself as a default router on an AIL by setting a non-zero Router Lifetime value in the header of its Router Advertisements.  The exception to this rule is the case where the SNAC router itself is the default router for a particular AIL: for example, it may be the home router providing connectivity to an ISP. </del> <ins> A SNAC router MUST NOT advertise itself as a default router on an AIL by setting a non-zero Router Lifetime value in the header of its Router Advertisements. </ins> 5.4.
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
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
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
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
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
3.1. <ins> Workload identity often comprises multiple attributes that describe various aspects of a workload.  These attributes can encompass diverse sets of information, including the workload's role within a system, the software it operates, and the hardware environment it utilizes.  Different authorities across various parts of the system define these attribute sets.  This architecture introduces a Workload Identifier for representing and referencing workloads, enabling diverse authorities with distinct identity attribute sets to consistently reference the workload. The Workload Identifier consists of a concise string allocated within a namespace defined by a Trust Domain.  This Workload Identifier is present in Workload Identity Tokens and X.509 certificates issued by the authority for the Trust Domain.  The Workload Identifier is used to associate additional identity attributes to the workload through the use of tokens (workload attribute tokens?) or online look up services.  It may also be used directly in authorization calculations and audit logs. The Trust Domain consists of a string that matches the format of a fully qualified domain name.  It is the intent that a Trust Domain is actually a domain name registered to the organization defining the Trust Domain, but this may not be true in all cases.  The Trust Domain also maps to the issuer of cryptographically signed Workload Identity Tokens (WIT) or X.509 Certificate.  The association between a Trust Domain and the cryptographic root of the signing authority for that Trust Domain must be made securely through an out-of-band mechanisms.  [TODO: where should mechanisms be defined?] The Trust Domain also defines how the rest of the Workload Identifier is constructed.  The Workload Identifier may represent a type of workload such that the same identifier may be used by many instances of the same service.  A Trust Domain may choose identifiers to represent a specific instance of a workload such that each workload of the same type will have a specific identity.  The Trust Domain could choose a naming scheme that allows for both objects by imposing a hierarchical structure on the naming format. The Trust Domain also defines which mechanisms are used to initially bootstrap a workload with a Workload Identifier and the mechanisms for a workload to obtain its workload identity credentials in the form of X.509 certificates and Workload Identity Tokens. </ins> 3.1.1. <ins> [TODO: this section will need to be updated to discuss workload identifier as a concept as well] </ins> A workload needs to obtain its identity early in its lifecycle.  This identity is sometimes referred to as the "bottom turtle" on which further identity and security context is built.
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
authorization by verifying that the authenticated identity has the appropriate permissions to access the requested resources and perform required actions.  This process involves evaluating the security <del> context described previously.  The workload validates security context, checks validity of permissions against its security policies to ensure that only authorized actions are allowed. </del> <ins> context described previously.  The workload validates the security context, and checks the validity of permissions against its security policies to ensure that only authorized actions are allowed. </ins> 3.2.4. <del> TBD. </del> <ins> When source workloads send authenticated requests to destination workloads, those destination workloads may rely on upstream dependencies to fulfill such requests.  Such access patterns are increasingly common in a microservices architecture.  While X.509 certificates can be used for point-to-point authentication, such services relying on upstream microservices for answers, may use delegation and/or impersonation semantics as described in RFC 8693 OAuth 2.0 Access Token Exchange. WIMSE credentials constrain the subjects and actors identified in delegation and impersonation tokens to be bound by TrustDomains, and to follow their issuing authorities' trust configurations.  Upstream workloads should consider the security context of delegation and/or impersonation tokens within and across Trust Domains, when arriving at authorization decisions. </ins> 3.2.5. <del> TBD. </del> <ins> Source workloads may send authenticated asynchronous and batch requests to destination workloads.  A destination workload may need to fulfill such requests with requests to authorized upstream protected resources and workloads, after the source workload credentials have expired.  Credentials identifying the original source workload as subject may need to be obtained from the credential issuing authority with appropriately-downscoped context needed access to upstream workloads.  These credentials should identify the workload as the actor in the actor chain, but may also identify other principals that the action is taken on behalf.  To mitigate risks associated with long-duration credentials, these credentials should be bound to the workload identity credential such as an X.509 certificate or Workload Identity Token (WIT) of the acting service performing asynchronous computation on the source workload's behalf. </ins> 3.2.6.
URN Namespace for IETF Use [2] somehow.  Or maybe nothing.  Or maybe something else. <ins> TODO: "tth" and maybe "oth" claim in JSON Web Token Claims Registry [3] </ins> 6.1. TODO: "application/wimse-id+jwt" or appropriately bikeshedded media type name (despite my ongoing unease with using media types for <del> typing JWTs) in Media Types [3]. </del> <ins> typing JWTs) in Media Types [4]. TODO: "application/wimse-proof+jwt" ... </ins> 6.2. TODO: "Workload-Identity-Token" from <ins> TODO: "Workload-Proof-Token" from </ins> 7.  References 7.1.  URIs
of interaction between two workloads.  This is the core component of the WIMSE architecture I-D.ietf-wimse-arch.  Assume that Service A needs to call Service B.  For simplicity, this document focuses on <del> REST services, and the service-to-service call consists of a single HTTP request and its response.  We define the credentials that both services should possess and how they are used to protect the HTTP exchange. </del> <ins> HTTP-based services, and the service-to-service call consists of a single HTTP request and its response.  We define the credentials that both services should possess and how they are used to protect the HTTP exchange. </ins> There are multiple deployment styles in use today, and they result in different security properties.  We propose to address them
Workload A obtains a credential from the Identity Server.  This happens periodically, e.g. once every 24 hours. <del> Workload A makes a REST call into Workload B.  This is a regular REST call, with the additional protection mechanisms defined </del> <ins> Workload A makes an HTTP call into Workload B.  This is a regular HTTP request, with the additional protection mechanisms defined </ins> below. Workload B now authenticates Workload A and decides whether to
defined by the issuer.  Using a WIMSE ID without taking into account the trust domain could allow one domain to issue tokens to spoof identities in another domain.  Additionally, the trust domain must be <del> tied to an authorized issuer cryptographic trust root through some </del> <ins> tied to an authorized issuer cryptographic trust anchor through some </ins> mechanism such as a JWKS or X.509 certificate chain.  The association <del> of an issuer, trust domain and a cryptographic trust root MUST be </del> <ins> of an issuer, trust domain and a cryptographic trust anchor MUST be </ins> communicated securely out of band. 6.2.
WIMSE certificate may contain SubjectAltName extensions of other types such as DNSName. <del> WIMSE identities may be used to validate server and client connections.  When validating a WIMSE identity the relying party MUST validate that the CA issuer for the WIMSE identity is authorized to issue certificates for the trust domain of the WIMSE identity in the certificate.  Other PKIX path validation rules apply. Servers wishing to use the WIMSE identity for authorizing the client MUST require client certificate authentication in the TLS handshake. Other methods of post handshake authentication are not specified by this document. </del> <ins> WIMSE certificates may be used to secure both server and client connections.  When validating a WIMSE certificate, the relying party MUST validate that the CA issuer for the WIMSE certificate is authorized to issue certificates for the trust domain of the WIMSE workload identified by the certificate.  Other PKIX path validation rules apply. Servers wishing to use the WIMSE certificate for authorizing the client MUST require client certificate authentication in the TLS handshake.  Other methods of post handshake authentication are not specified by this document. </ins> WIMSE clients and servers MUST validate that the trust domain portion of the WIMSE certificate matches the expected trust domain for the
It is RECOMMENDED that the server certificate contain a DNS SAN that the client can use to perform standard host name validation <del> (RFC9525).  The client SHOULD also extract the WIMSE identity from </del> <ins> (RFC9525).  The client SHOULD also extract the WIMSE identifier from </ins> the certificate if it is present and validate that the WIMSE trust domain matches the intended trust domain for the server.  The client <del> MAY then further use the WIMSE identity in applying authorization </del> <ins> MAY then further use the WIMSE identifier in applying authorization </ins> policy to the server.  If the client does not use the DNS SAN then <del> the client MUST match the WIMSE identity in the certificate against </del> <ins> the client MUST match the WIMSE identifier in the certificate against </ins> the WIMSE identity of the workload of the intended server according to a locally defined policy.  The host portion of the WIMSE URI is NOT treated as a host name as specified in section 6.4 of RFC9525 but rather as a trust domain.  The server identity is encoded in the path <del> portion of the WIMSE identity in a deployment specific way. </del> <ins> portion of the WIMSE identifier in a deployment specific way. </ins> 5.2. <del> The client or server application may retrieve the WIMSE identity from the TLS layer for use in authorization, accounting and auditing.  For example, the full URI may be matched against ACLs and other policy constructs to authorize actions requested by the peer. </del> <ins> The client or server application may retrieve the WIMSE identifier from the TLS layer for use in authorization, accounting and auditing. For example, the full URI may be matched against ACLs and other policy constructs to authorize actions requested by the peer. </ins> 6.