jiebi/CodeConvo huggingface dataset:
Code change:
In order to provide network access, stub routers must provide some network services to the stub network.  We have previously discussed the following services: <ins> 9. This document has no IANA actions. 10. Because a SNAC router operates as an IPv6 router that sends and receives IPv6 Neighbor Discovery protocol messages, the security considerations of Section 11 of RFC4861 apply.  No additional security considerations are identified. </ins>

Related discussion:
text: In internet drafts, the IANA Considerations and Security Considerations sections are mandatory. Exact text for security can be adapted also later on if needed.
It's not really true that stub routers create a security problem by sending RAs: rather, it's the case that this security problem potentially exists on networks where RA guard is present, but this issue is in no way our responsibility, and probably shouldn't be mentioned in security considerations.
NAME I've removed the RA Guard text. It was there not because SNAC-routers introduce a security issue, but because we think that there's a group of people/network-administrators/IETFers/others who consider any device that can autostart acting as IPv6 router and can autostart sending ND message on a link as a "security hazard" even if it's not. Mentioning RA Guard there could be a proactive way to hopefully avoid too many discussions around this during future document reviews.
For security we may add: risk of advertising self-generated ULA prefix? Any specifics? if site employs technology like RA-guard, the RAs of our unmanaged stub router will be blocked
These sound more like operational considerations than security considerations. I suppose if we want to advise sites that do not want stub routers attaching to block RA, that would make sense, but I don't think that's really a problem unique to stub routers. Regarding the ULA prefix, the only risk is one we've already addressed: that the prefix could be used for tracking. I think the text on varying prefixes per-link probably needs work, but that addresses the privacy concern.
Code change:
In order to provide network access, stub routers must provide some network services to the stub network.  We have previously discussed the following services: <ins> 9. This document has no IANA actions. 10. Because a SNAC router operates as an IPv6 router that sends and receives IPv6 Neighbor Discovery protocol messages, the security considerations of Section 11 of RFC4861 apply.  No additional security considerations are identified. </ins>

Related discussion:
text: Closing issue This PR is not building, so need to clean it up before commit. Comments appreciated during that process.
NAME PR is still needed before anything can build ;-)
NAME NAME sorry I didn't intend to close this PR, Github did that somehow after me pushing to the branch. But it's good to have this one closed and replaced by , because the merge direction was specified here the wrong way around. The build is now fixed in the branch and also updated to make it merge-able into main. I prefer to merge rather sooner than later - nits can be corrected with future PRs easily.
Code change:
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

Related discussion:
text: 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.
Code change:
such as global open source repositories down to off-line constrained devices <del> 3.7. 3.7.1. Firmware is ubiquitous in IoT devices (e.g., appliances, televisions, smart LED bulbs, HVAC, automobiles), runs at the highest privilege level possible, and is often the bedrock on which the security story of the devices it powers. </del> <ins> 3.8. </ins> <del> Firmware is powerful.  It runs in the highest privilege level possible and is often the bedrock on which the security story of the devices it powers. </del> <ins> 3.8.1. </ins> <del> 3.7.2. </del> <ins> Firmware is a critical component for successful execution of any constrained IoT device.  It is often the bedrock on which the security story of the devices it powers. </ins> Personal health monitoring devices, i.e., eHealth devices, are generally battery driven and offer health telemetry monitoring, such

Related discussion:
text: Signed-off-by: Henk Birkholz
Looks good.
If there are no objections until the end of Fri, I'll merge for the meeting on Mon.
No objections with merging these changes.
My feedback is non blocking, PR authors may dismiss my suggestions.
LGTM!
Code change:
context: Re-ordering of header fields with different header field names <del> (HTTP, Section 3.2.2). </del> <ins> (MESSAGING, Section 3.2.2). </ins> <del> Combination of header fields with the same field name (HTTP, </del> <ins> Combination of header fields with the same field name (MESSAGING, </ins> Section 3.2.2). Removal of header fields listed in the "Connection" header field <del> (HTTP, Section 6.1). </del> <ins> (MESSAGING, Section 6.1). </ins> <del> Addition of header fields that indicate control options (HTTP, Section 6.1). </del> <ins> Addition of header fields that indicate control options (MESSAGING, Section 6.1). </ins> <del> Addition or removal of a transfer coding (HTTP, Section 5.7.2). </del> <ins> Addition or removal of a transfer coding (MESSAGING, Section 5.7.2). </ins> <del> Addition of header fields such as "Via" (HTTP, Section 5.7.1) and "Forwarded" (RFC7239, Section 4). </del> <ins> Addition of header fields such as "Via" (MESSAGING, Section 5.7.1) and "Forwarded" (RFC7239, Section 4). </ins> 1.3.

Related discussion:
text: separates MESSAGING and SEMANTICS concepts (Eg. fields)
Thanks! :tada:
The spec relies only on HTTP Semantics and not on HTTP/1.1 messaging. [ ] improve wording [ ] switch to http-core Check all references to Messaging and consider replacing them using Semantic. See URL
NAME NAME NAME I was re-reading the spec after the more recent filed issues, and I think that switching this draft to HTTP Core terminology (eg. I-D.ietf-httpbis-semantics ) we could have a more consistent background for taking the right decisions about things like transformations, intermediaries.
This should be taken care of with , NAME please re-open with comment if there are more things to be done.
Code change:
In the so-called Issuer-Holder-Verifier Model, Issuers issue so- called Verifiable Credentials to a Holder, who can then present the Verifiable Credentials to Verifiers.  Verifiable Credentials are <del> cryptographically signed statements about a Subject, typically the </del> <ins> cryptographically secured statements about a Subject, typically the </ins> Holder. Verifiers can check the authenticity of the data in the Verifiable

Related discussion:
text: Updated terminology and other sections to clarify VCs and presentations can be repudiable or non-repudiable Minor typo fixed See preview here: URL
3 approvals, merging
The specification currently uses terms like public key validation and potentially other things when it comes to the verification of the KB-JWT. We should make sure there is no language that would prohibit the use of MAC authentication for KB-JWT and Issuer-signed JWT.
Currently blocked by SD-JWT: URL URL
NAME A few options we discussed on the editor's call today (cc NAME NAME ): not do anything in SD-JWT to enable this since SD-JWT just prohibits "symmetric algorithms". We could wait for an JOSE value specification to appear and to be registered in the IANA registry which states that the algorithm is not symmetric. One downside of this approach is that standard JOSE libs won't work today since the value is not supported. Note that technically one could implement this using standard if the key was agreed/derived using an ECDH/ConcatKDF schema. remove the normative statement completely from SD-JWT that prohibits "symmetric algorithms". change the normative statement to a SHOULD NOT use "symmetric algorithms" and explain in the SD-JWT security - considerations section where symmetric values are acceptable and when not. keep the MUST NOT statement in SD-JWT but add an "... unless" clause that explains where this could be useful, e.g., for hybrid schemes but this needs to be confirmed if this process is indeed hybrid and therefore the use case is covered.
I think is the cleanest approach, but may take more time for implementations, we will try to get some experience there. also doesn't sound bad to me.
I think I still lean towards preferring something like # 2 - just remove the explicit prohibition of symmetric algorithms from SD-JWT and not say much, if anything else about it in that spec. Let the layer above SD-JWT/JOSE (probably the presentation protocol) define how an HMAC key is agreed upon and use existing JWS HMAC algs and implementations. I.e., the verifier sends a public key in it's presentation request, which the generator uses in a key agreement with their private key to get a key that is then KDFd to produce an appropriate key for existing/established JWS HS256[384|512] algs.
Code change:
In the so-called Issuer-Holder-Verifier Model, Issuers issue so- called Verifiable Credentials to a Holder, who can then present the Verifiable Credentials to Verifiers.  Verifiable Credentials are <del> cryptographically signed statements about a Subject, typically the </del> <ins> cryptographically secured statements about a Subject, typically the </ins> Holder. Verifiers can check the authenticity of the data in the Verifiable

Related discussion:
text: That layer is going to have to define much of that anyway so there's not much gain from pushing an ECDH-based MAC alg into JOSE/JWS (also note that defining and registering a new JOSE alg is far from a trivial exercise). And the prohibition of symmetric algorithms in SD-JWT makes sense from a particular perspective but is arguably just unnecessarily restrictive at the building block layer.
I would agree that removing the restriction is okay, as SD-JWT is an improvement of JWT and JWTs don't have this restriction. Do you think that ECDH-ES is an anti-pattern? It has been in JWA from the beginning and you could have the same arguments there?
I wouldn't take it that far. My comments/arguments here are really just in the context of the current state of JWS specs and existing library support.
NAME NAME if option 2 is our favorite options. Should the SD-JWT VC spec then say something about that? IMO, it would be good to say something in the security considerations at least.
I agree in general that since SD-JWT is a building block, being too restrictive there regarding symmetric algorithms is probably not necessary.
I don't object removing the restriction, I checked RFC7519 and there is no similar statement.
Definitely not opposed to saying something. But it might be challenging to say something that's actually meaningful/helpful.
URL removes the explicit prohibition on MAC from SD-JWT (which will be in the -08 draft-ietf-oauth-selective-disclosure-jwt)
Then, we need a PR that cleans up the language in this specification, so MAC is not going to be prohibited.
Code change:
7. <del> Unprompted Authentication allows a user-agent to authenticate to an </del> <ins> Unprompted Authentication allows a user agent to authenticate to an </ins> origin server while guaranteeing freshness and without the need for the server to transmit a nonce to the user agent.  This allows the server to accept authenticated clients without revealing that it

Related discussion:
text: The user ID parameter "u" effectively identifies the keying material that servers might use to verify the authenticator sent in the header. As noted on the list, this is more or less a key ID, and I think leaning into that framing could be helpful. For example, beyond avoiding the confusion raised on the list, it might also be more ergonomic for different types of authenticators. One could imagine using a for unprompted authentication where the server only learns that someone with a valid private key produced the authenticator but not necessarily which one.
Code change:
12. Transport protocols such as TCP and QUIC provide reliability by <del> detecting packet losses and retransmitting lost information.  While this document specifies HTTP-layer prioritization, its effectiveness can be further enhanced if the transport layer factors priority into scheduling both new data and retransmission data.  The remainder of </del> <ins> detecting packet losses and retransmitting lost information.  In addition to the considerations in server-scheduling, scheduling of retransmission data could compete with new data.  The remainder of </ins> this section discusses considerations when using QUIC. QUIC states "Endpoints SHOULD prioritize retransmission of data over

Related discussion:
text: Addresses Te of the TSVART review We don't have much evidence to quantify effectiveness. So drop that part and keep the focus purely on the considerations.
Code change:
The criteria in this section evaluate the congestion control algorithm when one or more flows using that algorithm share a <del> bottleneck link (i.e. with no flows using a differing congestion </del> <ins> bottleneck link (i.e., with no flows using a differing congestion </ins> control algorithm). 4.1.1.

Related discussion:
text: Please do not merge yet, I will tray to update to include a few sentences to address the issue related to in-network Circuit breakers.
From NAME review: I do wonder if this document needs to bring up the circuit breaker specifications (RFC 8083, RFC 8084) we do have and potential interaction with them. I would expect a congestion control algorithm to work well within the envelope which would trigger them. The question is if one needs to take them into account when dealing with them. I will note that traffic applying a circuit breaker can be dynamic in transmission pattern and rates and otherwise be very non-responsive in relation to congestion signals. Only if they exceed the circuit breaker threshold will something happen.
This looks good, but please don't mangle my name, or that of Lisong Xu, or ACM Queue reference. Minor edit suggestion on the wording of the last paragraph in "## Paths with Varying Delay {#delay}"
Code change:
13. <del> As a general guideline, a server SHOULD NOT use priority information for making scheduling decisions across multiple connections, unless it knows that those connections originate from the same client.  Due to this, priority information conveyed over a non-coalesced HTTP connection (e.g., HTTP/1.1) might go unused. The remainder of this section discusses scenarios where unfairness is problematic and presents possible mitigations, or where unfairness is desirable. </del> <ins> Typically, HTTP implementations depend on the underlying transport to maintain fairness between connections competing for bandwidth.  When HTTP requests are forwarded through intermediaries, progress made by each connection originating from end clients can become different over time, depending on how intermediaries coalesce or split requests into backend connections.  This unfairness can expand if priority signals are used. coalescing and h1-backends discuss mitigations against this expansion of unfairness. Conversely, intentional-unfairness discusses how servers might intentionally allocate unequal bandwidth to some connections depending on the priority signals. </ins> 13.1.

Related discussion:
text: As discussed in URL and URL, describe fairness and how that relates to priorities.
As part of the TSVART review, Bob said This seems like a fair point and we likely shouldn't say anything. We can remove this statement entirely but it is normative text so it'll be a change.
I initially thought the same, but now I have a counter-argument. This section (Section 13. Fairness) discusses distributing bandwidth between multiple connections. and 13.2 cover considerations when intermediaries coalesce requests originating from multiple connections onto a single backend connection, or split requests being received on one connection to multiple backend connections. Section 13.3 distributing bandwidth between multiple connections that might share same path. I would argue that all of these belong to IETF, and that they should be covered in the document. We can probably improve the explanation to avoid confusion.
OK that works for me too, could you tackle that?
:+1: Will do alongside .
From the TSVART review, Bob says: We should address this.
I think there's confusion here. Section 13 discusses fairness of bandwidth allocated between end clients, not requests. I think clarifying this might help.
Minor edits
Code change:
In order to mitigate this fairness problem, when a server responds to a request that is known to have come through an intermediary, the server SHOULD prioritize the response as if it was assigned the <del> priority of "u=1, i=?1" (i.e. round-robin) regardless of the value of </del> <ins> priority of "u=1, i" (i.e. round-robin) regardless of the value of </ins> the Priority header field being transmitted, unless the server knows the intermediary is not coalescing requests from multiple clients.

Related discussion:
text: Address some build warnings and fix typos.
and
Thank you for the fix. Merged.
Changes in structured headers means that boolean parameter values are reduced to their parameter name: -- URL
Q: should this be labeled ?
No, this issue addresses the minor editorial problem that needs fixing in the priorities spec e.g. URL just needs some tweaks to be compliant with structured headers.
The lowercase headings in the document imply that they represent field or parameter names, but these are concepts. For instance "incremental" doesn't appear on the wire, "i" does.
Code change:
Section 4.4 of oauth-security-topics provides additional details about mix-up attacks and the countermeasures mentioned above. <ins> 9.4. In browser-based apps, it is common to execute the OAuth flow in a secondary window, such as a popup or iframe, instead of redirecting the primary window.  In these flows, the browser-based app holds control of the primary window, for instance, to avoid page refreshes or run silent frame-based flows. If the browser-based app and the authorization server are invoked in different frames, they have to use in-browser communication techniques like the postMessage API (a.k.a.  WebMessaging) instead of top-level redirections.  To guarantee confidentiality and authenticity of messages, both the initiator origin and receiver origin of a postMessage MUST be verified using the mechanisms inherently provided by the postMessage API (Section 9.3.2 in WebMessaging). Section 4.18. of oauth-security-topics provides additional details about the security of in-browser communication flows and the countermeasures that browser-based apps and authorization servers MUST apply to defend against these attacks. </ins> 10. This document does not require any IANA actions.

Related discussion:
text: As discussed on the OSW, this PR adds a small section with security considerations on the use of (a.k.a. "web messaging") to this draft. It makes reference to , which already discusses the security implications of in-browser communication flows in detail. Since (silent) iframe flows and popup flows are especially used in browser-based apps, we think that it makes sense to include security considerations of their in-browser communication into this draft. Please let us know what you think about this. We appreciate any feedback.
Sounds good to me, thanks!
Code change:
The following is a non-normative example of a presentation of the SD- JWT shown in vc-sd-jwt-example including a Key Binding JWT.  In this <del> presentation, the Holder provides only the Disclosure for the </del> <ins> presentation, the Holder provides only the Disclosures for the and claims.  Other claims are not disclosed to the Verifier. After validation, the Verifier will have the following processed SD- JWT payload available for further handling: </ins> <del> claim.  Other claims are not disclosed to the Verifier. </del> <ins> The following example shows a presentation of a (similar but different) SD-JWT without a Key Binding JWT: </ins> <del> The following example shows a presentation of a (different) SD-JWT without a Key Binding JWT: </del> <ins> The Verifier will have the following processed SD-JWT payload after validation: </ins> 5.

Related discussion:
text: for and hopefully/maybe too URL URL URL
NAME this work and URL were largely undertaken as a result of your questions/feedback
Select parts of a conversation from an encrypted messaging service copied here. Editorial liberties have been taken to extract the most relevant parts of the discussion and protect the identities of the participants. >- the first example is just user claims that are being secured >- the second example is user claims + metadata that is necessary to be added when signing the sd-jwt IMHO it would be worthwhile to expand the example in URL with some additions to URL to also show the content of the thing that needs a name.
Seems related to
I think the understanding of the spec could be further facilitated by adding an example of a SD-JWT VC after the verifier has processed the SD-JWT VC and (basically) has constructed a JWT representation for further processing in the application.
The new PID example in draft -02/-03 shows the JSON data for "further processing" after validation: URL Does that seem sufficient? Or perhaps a similar addition to the example used in the main body of the draft ()? Or something different/more?
I personally don't understand why this applies to the verifier: "has constructed a JWT representation for further processing in the application". However, NAME has this issue been addressed by the examples NAME provided? Then we can close it.