jiebi/CodeConvo huggingface dataset:
Code change:
Added Service & Infrastructure Maps (SIMAP) terminology Updated inventory use case to mention passive inventory Added requirements REQ-PASSIVE-TOPO: to include passive topology based on input from Brad Peters

Related discussion:
text: The document defines the following terms: <del> Digital Map is a data model that provides a view of the operator's </del> <ins> SIMAP is a data model that provides a view of the operator's </ins> networks and services, including how it is connected to other models/data (e.g. inventory, observability sources, and operational knowledge).  It specifically provides an approach to model multi-layered topology and appropriate mechanism to navigate <del> amongs layers and correlate between them.  This model is </del> <ins> amongs layers and correlate between them.  This includes layers from physical topology to service topology.  This model is </ins> applicable to multiple domains (access, core, data centers, etc.) and technologies (Optical, IP, etc.). The set of principles, guidelines, and conventions to model the <del> Digital Map using the IETF RFC8345 approach.  They cover the network types (layers and sublayers), entity types, entity roles (network, node, termination point or link), entity properties, relationship types between entities and relationships to other entities. </del> <ins> Service & Infrastructure Maps (SIMAP) using the IETF RFC8345 approach.  They cover the network types (layers and sublayers), entity types, entity roles (network, node, termination point or link), entity properties, relationship types between entities and relationships to other entities. </ins> Defines the core topological entities, their role in the network, core topological properties and relationships both inside each
Code change:
Added Service & Infrastructure Maps (SIMAP) terminology Updated inventory use case to mention passive inventory Added requirements REQ-PASSIVE-TOPO: to include passive topology based on input from Brad Peters

Related discussion:
text: Intent/service assurance <del> Service E2E and per-link KPIs on the Digital Map (connectivity status, high-availability, delay, jitter, and loss) </del> <ins> Service E2E and per-link KPIs on SIMAP (connectivity status, high- availability, delay, jitter, and loss) </ins> Capacity planning
Code change:
Added Service & Infrastructure Maps (SIMAP) terminology Updated inventory use case to mention passive inventory Added requirements REQ-PASSIVE-TOPO: to include passive topology based on input from Brad Peters

Related discussion:
text: 3.5. The application will be able to retrieve topology layer and any <del> network/node/tp/link instances from the controller via Digital Map API and from the response it will be able to determine the health of each instance by navigating to the SAIN subservices and its symptoms. </del> <ins> network/node/tp/link instances from the controller via the SIMAP API and from the response it will be able to determine the health of each instance by navigating to the SAIN subservices and its symptoms. </ins> 3.6. The application will be able to retieve the topology at any layer <del> from the controller via Digital Map API and from the response it will </del> <ins> from the controller via the SIMAP API and from the response it will </ins> be able to navigate any retrieve any KPIs for selected topology entity.
Code change:
Added Service & Infrastructure Maps (SIMAP) terminology Updated inventory use case to mention passive inventory Added requirements REQ-PASSIVE-TOPO: to include passive topology based on input from Brad Peters

Related discussion:
text: 5. <del> As this document covers the Digital Map concepts, requirements, and use cases, there is no specific security considerations.  However, the RFC 8345 Security Considerations aspects will be useful when </del> <ins> As this document covers the SIMAP concepts, requirements, and use cases, there is no specific security considerations.  However, the RFC 8345 Security Considerations aspects will be useful when </ins> designing the solution. 6.
Code change:
We remove incident type yang model, so the number of yang modules we proposed is reduced from 2 into 1. So I think the text still needs some tweak, besides this, all good changes.

Related discussion:
text: A network incident refers to an unexpected interruption of a network service, degradation of a network service quality, or sub-health of a <del> network service.  Different data sources including alarms, metrics </del> <ins> network service.  Different data sources including alarms, metrics, </ins> and other anomaly information can be aggregated into few amount of network incidents by data correlation analysis and the service impact analysis. This document defines YANG Modules for the network incident lifecycle <del> management.  The YANG modules are meant to provide a standard way to report, diagnose, and resolve network incidents for the sake of </del> <ins> management.  These YANG modules are meant to provide a standard way to report, diagnose, and resolve network incidents for the sake of </ins> network service health and root cause analysis. 1. RFC8969 defines a framework for Automating Service and Network <del> Management with YANG to full life cycle network management.  A set of YANG data models have already been developed in IETF for Network performance monitoring and fault monitoring,e.g.,A YANG RFC7950 data model for alarm management RFC8632 defines a standard interface for alarm management.  A data model for Network and VPN Service </del> <ins> Management with YANG RFC7950 to full life cycle network management. A set of YANG data models have already been developed in IETF for network performance monitoring and fault monitoring, e.g., a YANG data model for alarm management RFC8632 defines a standard interface for alarm management.  A data model for Network and VPN Service </ins> Performance Monitoring RFC9375 defines a standard interface for network performance management.  In addition, distributed tracing <del> mechanism defined in W3C-Trace-Context can also be used to analyze and debug operations, such as configuration transactions, across multiple distributed systems. </del> <ins> mechanism defined in W3C-Trace-Context can be used to analyze and debug operations, such as configuration transactions, across multiple distributed systems. </ins> <del> However these YANG data models for network maintenance are based on </del> <ins> However, these YANG data models for network maintenance are based on </ins> specific data source information and manage alarms and performance metrics data separately by different layers in various different management systems.  In addition, the frequency and quantity of
Code change:
We remove incident type yang model, so the number of yang modules we proposed is reduced from 2 into 1. So I think the text still needs some tweak, besides this, all good changes.

Related discussion:
text: BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. <del> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </del> The following terms are defined in RFC8632 and are not redefined here:
Code change:
We remove incident type yang model, so the number of yang modules we proposed is reduced from 2 into 1. So I think the text still needs some tweak, besides this, all good changes.

Related discussion:
text: The following terms are defined in this document: <del> Network Incident: An unexpected interruption of a network service, degradation of network service quality, or sub-health of a network service TMF724A. Problem: The cause of one or more incidents.  The cause is not usually known when a problem record is created, and the problem management process is responsible for further investigation TMF724A. Incident management: Lifecycle management of incidents including incident identification, reporting, acknowledge, diagnosis, and resolution. Incident management system: An entity which implements incident management.  It include incident management server and incident management client. Incident management server: An entity which provides some functions of incident management.  For example, it can detect an incident, perform incident diagnosis, resolution and prediction,etc. Incident management client: An entity which can manage incidents. For example, it can receive incident notifications, query the information of incidents, instruct the incident management server to diagnose, resolve, etc. </del> 3. 3.1. <del> Traditionally, the dispatching of trouble tickets is mostly based on alarms data analysis and need to involve operators' maintenance engineers.  These operators' maintenance engineers are able to monitor and detect that alarms at both end devices of specific network tunnel or at both optical layer and IP layer which are associated with the same network fault.  Therefore, they can correlate these alarms to the same trouble ticket, which is in the low automation.  If there are more alarms, then the human costs for network maintenance are increased accordingly. </del> <ins> Usually, the dispatching of trouble tickets is mostly based on alarms data analysis and need to involve operators' maintenance engineers. These operators' maintenance engineers are able to monitor and detect that alarms at both end devices of specific network tunnel or at both optical layer and IP layer which are associated with the same network fault.  Therefore, they can correlate these alarms to the same trouble ticket, which is in the low automation.  If there are more alarms, then the human costs for network maintenance are increased accordingly. </ins> Some operators preconfigure whitelist and adopt some coarse granularity data correlation rules for the alarm management.  It
Code change:
The following changes are encapsulated in this PR: Update references from RFC7523 to RFC7521. Added a recommendation around order of validation for the two JWTs in the client_assertion parameter. Removed the note from the exp and iat claims for the client key Attestation JWT that imply this cannot be re-used across multiple requests. Removed the ability to use MAC based algorithms when producing the client key Attestation JWT. Updated the requirements around the presence of the JTI claim for the client key attestation PoP to be a MUST inline with DPoP PoPs for reliable basic replay attack detection mechanism. Added references to the JWT RFC. Added an implementation consideration that highlights a client instance can re-use a client key attestation JWT in multiple AS interactions/requests. Added aud as a required claim in the client attestation pop JWT. Add IANA registration request for the new client assertion type and token endpoint authentication method.

Related discussion:
text: Abstract This specification defines a new method of client authentication for <del> OAuth2 RFC6749 by extending the approach defined in RFC7523.  This </del> <ins> OAuth2 RFC6749 by extending the approach defined in RFC7521.  This </ins> new method enables client deployments that are traditionally viewed as public clients to be able to authenticate with the authorization server through an attested key based authentication scheme. 1. <del> RFC7523 defines a way for a client to include an assertion in a token </del> <ins> RFC7521 defines a way for a client to include an assertion in a token </ins> request to an authorization server for the purposes of client authentication.  This specification extends this mechanism to provide a way for a client instance to authenticate it self with the
Code change:
The following changes are encapsulated in this PR: Update references from RFC7523 to RFC7521. Added a recommendation around order of validation for the two JWTs in the client_assertion parameter. Removed the note from the exp and iat claims for the client key Attestation JWT that imply this cannot be re-used across multiple requests. Removed the ability to use MAC based algorithms when producing the client key Attestation JWT. Updated the requirements around the presence of the JTI claim for the client key attestation PoP to be a MUST inline with DPoP PoPs for reliable basic replay attack detection mechanism. Added references to the JWT RFC. Added an implementation consideration that highlights a client instance can re-use a client key attestation JWT in multiple AS interactions/requests. Added aud as a required claim in the client attestation pop JWT. Add IANA registration request for the new client assertion type and token endpoint authentication method.

Related discussion:
text: authorization server MUST validate BOTH the JWTs present in the "client_assertion" parameter according to the criteria below. <ins> It is RECOMMENDED that the authorization server validate the Client Key Attestation prior to validating the Client Key Attestation PoP. </ins> 3.1.1. The following rules apply to validating the client key attestation
Code change:
The following changes are encapsulated in this PR: Update references from RFC7523 to RFC7521. Added a recommendation around order of validation for the two JWTs in the client_assertion parameter. Removed the note from the exp and iat claims for the client key Attestation JWT that imply this cannot be re-used across multiple requests. Removed the ability to use MAC based algorithms when producing the client key Attestation JWT. Updated the requirements around the presence of the JTI claim for the client key attestation PoP to be a MUST inline with DPoP PoPs for reliable basic replay attack detection mechanism. Added references to the JWT RFC. Added an implementation consideration that highlights a client instance can re-use a client key attestation JWT in multiple AS interactions/requests. Added aud as a required claim in the client attestation pop JWT. Add IANA registration request for the new client assertion type and token endpoint authentication method.

Related discussion:
text: the time window during which the JWT can be used.  The authorization server MUST reject any JWT with an expiration time that has passed, subject to allowable clock skew between systems. <del> Note that the authorization server may reject JWTs with an "exp" claim value that is unreasonably far in the future. </del> The JWT MUST contain an "cnf" claim conforming RFC7800 that conveys the key to be used for sender constraining tokens issued
Code change:
The following changes are encapsulated in this PR: Update references from RFC7523 to RFC7521. Added a recommendation around order of validation for the two JWTs in the client_assertion parameter. Removed the note from the exp and iat claims for the client key Attestation JWT that imply this cannot be re-used across multiple requests. Removed the ability to use MAC based algorithms when producing the client key Attestation JWT. Updated the requirements around the presence of the JTI claim for the client key attestation PoP to be a MUST inline with DPoP PoPs for reliable basic replay attack detection mechanism. Added references to the JWT RFC. Added an implementation consideration that highlights a client instance can re-use a client key attestation JWT in multiple AS interactions/requests. Added aud as a required claim in the client attestation pop JWT. Add IANA registration request for the new client assertion type and token endpoint authentication method.

Related discussion:
text: processing. The JWT MAY contain an "iat" (issued at) claim that identifies the <del> time at which the JWT was issued.  Note that the authorization server may reject JWTs with an "iat" claim value that is unreasonably far in the past. </del> <ins> time at which the JWT was issued. </ins> The JWT MAY contain a "jti" (JWT ID) claim that provides a unique identifier for the token.  The authorization server MAY ensure
Code change:
The following changes are encapsulated in this PR: Update references from RFC7523 to RFC7521. Added a recommendation around order of validation for the two JWTs in the client_assertion parameter. Removed the note from the exp and iat claims for the client key Attestation JWT that imply this cannot be re-used across multiple requests. Removed the ability to use MAC based algorithms when producing the client key Attestation JWT. Updated the requirements around the presence of the JTI claim for the client key attestation PoP to be a MUST inline with DPoP PoPs for reliable basic replay attack detection mechanism. Added references to the JWT RFC. Added an implementation consideration that highlights a client instance can re-use a client key attestation JWT in multiple AS interactions/requests. Added aud as a required claim in the client attestation pop JWT. Add IANA registration request for the new client assertion type and token endpoint authentication method.

Related discussion:
text: The JWT MAY contain other claims. <del> The JWT MUST be digitally signed or have a Message Authentication Code (MAC) applied by the issuer.  The authorization server MUST reject JWTs with an invalid signature or MAC. </del> <ins> The JWT MUST be digitally signed using an asymmetric cryptographic algorithm.  The authorization server MUST reject the JWT if it is using a Message Authentication Code (MAC) based algorithm.  The authorization server MUST reject JWTs with an invalid signature. </ins> The authorization server MUST reject a JWT that is not valid in <del> all other respects per "JSON Web Token (JWT)". </del> <ins> all other respects per "JSON Web Token (JWT)" RFC7519. </ins> The following example is the decoded header and payload of a JWT meeting the processing rules as defined above.
Code change:
The following changes are encapsulated in this PR: Update references from RFC7523 to RFC7521. Added a recommendation around order of validation for the two JWTs in the client_assertion parameter. Removed the note from the exp and iat claims for the client key Attestation JWT that imply this cannot be re-used across multiple requests. Removed the ability to use MAC based algorithms when producing the client key Attestation JWT. Updated the requirements around the presence of the JTI claim for the client key attestation PoP to be a MUST inline with DPoP PoPs for reliable basic replay attack detection mechanism. Added references to the JWT RFC. Added an implementation consideration that highlights a client instance can re-use a client key attestation JWT in multiple AS interactions/requests. Added aud as a required claim in the client attestation pop JWT. Add IANA registration request for the new client assertion type and token endpoint authentication method.

Related discussion:
text: Note that the authorization server may reject JWTs with an "exp" claim value that is unreasonably far in the future. <ins> The JWT MUST contain a "jti" (JWT ID) claim that provides a unique identifier for the token.  The authorization server MAY ensure that JWTs are not replayed by maintaining the set of used "jti" values for the length of time for which the JWT would be considered valid based on the applicable "exp" instant. The JWT MUST contain an "aud" (audience) claim containing a value that identifies the authorization server as an intended audience. The RFC8414 issuer identifier URL of the authorization server MUST be used as a value for an "aud" element to identify the authorization server as the intended audience of the JWT. </ins> The JWT MAY contain an "nbf" (not before) claim that identifies the time before which the token MUST NOT be accepted for processing.
Code change:
The following changes are encapsulated in this PR: Update references from RFC7523 to RFC7521. Added a recommendation around order of validation for the two JWTs in the client_assertion parameter. Removed the note from the exp and iat claims for the client key Attestation JWT that imply this cannot be re-used across multiple requests. Removed the ability to use MAC based algorithms when producing the client key Attestation JWT. Updated the requirements around the presence of the JTI claim for the client key attestation PoP to be a MUST inline with DPoP PoPs for reliable basic replay attack detection mechanism. Added references to the JWT RFC. Added an implementation consideration that highlights a client instance can re-use a client key attestation JWT in multiple AS interactions/requests. Added aud as a required claim in the client attestation pop JWT. Add IANA registration request for the new client assertion type and token endpoint authentication method.

Related discussion:
text: server may reject JWTs with an "iat" claim value that is unreasonably far in the past. <del> The JWT MAY contain a "jti" (JWT ID) claim that provides a unique identifier for the token.  The authorization server MAY ensure that JWTs are not replayed by maintaining the set of used "jti" values for the length of time for which the JWT would be considered valid based on the applicable "exp" instant. </del> The JWT MAY contain other claims. The JWT MUST be digitally signed using an asymmetric cryptographic
Code change:
The following changes are encapsulated in this PR: Update references from RFC7523 to RFC7521. Added a recommendation around order of validation for the two JWTs in the client_assertion parameter. Removed the note from the exp and iat claims for the client key Attestation JWT that imply this cannot be re-used across multiple requests. Removed the ability to use MAC based algorithms when producing the client key Attestation JWT. Updated the requirements around the presence of the JTI claim for the client key attestation PoP to be a MUST inline with DPoP PoPs for reliable basic replay attack detection mechanism. Added references to the JWT RFC. Added an implementation consideration that highlights a client instance can re-use a client key attestation JWT in multiple AS interactions/requests. Added aud as a required claim in the client attestation pop JWT. Add IANA registration request for the new client assertion type and token endpoint authentication method.

Related discussion:
text: the "cnf" claim of the corresponding client key attestation JWT. The authorization server MUST reject a JWT that is not valid in <del> all other respects per "JSON Web Token (JWT)". </del> <ins> all other respects per "JSON Web Token (JWT)" RFC7519. </ins> The following example is the decoded header and payload of a JWT meeting the processing rules as defined above. 4. <del> TODO Security </del> <ins> 4.1. Implementers should be aware that the design of this authentication mechanism deliberately allows for a client instance to re-use a single Client Attestation JWT in multiple interactions/requests with an authorization server, whilst producing a fresh Client Attestation PoP JWT.  Client deployments should consider this when determining the validity period for issued Client Attestation JWTs as this ultimately controls how long a client instance can re-use a single Client Attestation JWT. </ins> 5. <del> This document has no IANA actions. </del> <ins> TODO 6. 6.1. This section registers the value "client-assertion-type:jwt-key- attestation" in the IANA "OAuth URI" registry established by "An IETF URN Sub-Namespace for OAuth" RFC6755. o URN: urn:ietf:params:oauth:client-assertion-type:jwt-key- attestation o Common Name: OAuth2 Attested Key Based Client Authentication Authentication o Change Controller: IESG o Specification Document: TBC 6.2. This section registers the value "attest_key_client_auth" in the IANA "OAuth Token Endpoint Authentication Methods" registry established by OAuth 2.0 Dynamic Client Registration Protocol RFC7591. o Token Endpoint Authentication Method Name: "attest_key_client_auth" o Change Controller: IESG o Specification Document(s): TBC </ins>