jiebi/CodeConvo huggingface dataset:
Code change:
bandwidth- delay product, well below the standard operating range of most Internet flows. <del> 5.3. </del> <ins> 5.4. </ins> Satellite links often have delays longer than typical for wired paths RFC2488 and high delay bandwidth products RFC3649. <del> 5.4. </del> <ins> 5.5. </ins> The proposal should explore how the alternate congestion control mechanism performs with non-compliant senders, receivers, or routers.

Related discussion:
text: Added first-cut of minimum delay text. Intended to
Delay based congestion control protocols are making an assumption that the observed RTT is the sum of a constant "min delay" and a variable queuing delay. This assumption may not be valid on wireless links, as delays vary when the distance between mobile endpoint and base station increases, or when changing transmission condition cause the radios to adopt different modulation and coding strategies. I suspect we also have these "variable delays" in satellite services, especially when using constellations of low orbit satellites. The state of the art is not very good. BBR for example recognizes its dependency on accurate estimate of the min RTT, but has to resort to some kind of periodic reset if measurements of RTT kept over RTT min for 10 seconds -- which is both quite long for some apps, and quite annoying for real time apps suffering a transmission issue every ten seconds. LEDBAT++ does something similar. I think these "variable delays" link are good candidates for "special case" links, to be mentioned in a separate section.
The variable delay part applies to most satellite broadband access using GEO also - not because of propagation usually, but more a result of radio resource sharing. It might well apply to some other technologies that use a shared capacity pool.
Min delay variation strikes me as a bit of a corner case -- perhaps it can be an optional case to evaluate. The other piece is delay variation is not always congestion -- this is IIUC very common in wireless and is part of that mandatory case.
In think this is something like: An Internet Path can include simple links, where the minimum delay is the propagation delay, and any additional delay can be attributed to link buffering. In this case, a congestion controller could reduce the sending rate to the point of minimum buffering while still preserving the maximum throughput. An internet Path can also include complex subnetworks where the minimum delay changes over various time scales. This occurs when a subnet changes the forwarding path to optimise capacity, resilience, etc. It could also arise when a subnet uses a capacity management method where the available resource is periodically distributed among the active nodes and where a node might then have to buffer data until an assigned transmission opportunity. Variation also results when a higher priority diffserv traffic classic prompts the transmission by a lower class.
Code change:
bandwidth- delay product, well below the standard operating range of most Internet flows. <del> 5.3. </del> <ins> 5.4. </ins> Satellite links often have delays longer than typical for wired paths RFC2488 and high delay bandwidth products RFC3649. <del> 5.4. </del> <ins> 5.5. </ins> The proposal should explore how the alternate congestion control mechanism performs with non-compliant senders, receivers, or routers.

Related discussion:
text: In these cases, the delay varies as a function of external factors and attempting to infer congestion from an increase in the delay results in reduced throughput.
The delay will also change when the wireless path between two wireless nodes becomes longer, or slower, or shorter, or faster. Or when a wireless router changes the schedule of transmission and starts polling a wireless station more often. or less often. To give an extreme example, suppose a spacecraft flying away from earth at 12,000 km/h. Every hour, the delay will increase by 40 ms.
Sure, however that requirement is very specific to certain systems - my point is that even for fixed cabled and broadband wireless systems, the base delay changes.
I suggest the language "non stationary minimum delay" to encompass all causes that resemble some form of route or path change, explicitly including LEO and mobile motion. It doesn't really cover link layer re transmissions or delays caused by link scheduling algorithms, but these are short term variations that are more likely to be statistically similar to IP queuing delay. I would use the term "hidden queues" to refer to unmanaged queues that (almost) never incur significant backlog but do occasionally cause jitter and generally can not be observed at the IP queuing layer.
NAME will add something in Sec 5 ("Special Cases")
Code change:
OBJECT message headers carry a short hop-by-hop "Track Alias" that maps to the Full Track Name (see message-subscribe-ok).  Relays use the "Track Alias" of an incoming OBJECT message to identify its track <del> and find the active subscribers for that track.  Relays MUST NOT depend on OBJECT payload content for making forwarding decisions and MUST only depend on the fields, such as priority order and other metadata properties in the OBJECT message header.  Unless determined by congestion response, Relays MUST forward the OBJECT message to the matching subscribers. </del> <ins> and find the active subscribers for that track.  Relays MUST forward OBJECT messages to matching subscribers in accordance to each subscription's priority, group order, and delivery timeout. </ins> 5.3.

Related discussion:
text: I am always confused when we use the term Relay to mean more than one thing. My thinking so far is, these are the middleboxes who have no role with payload of the MOQ objects. Yes, it cannot be enforced and a implementation can do whatever it wants. However, when we define security properties, we need to be clear on Relay's role. OTOH middleboxes like SFUs, transcoders are more flexible to access payload and may be payload headers based on the architecture and they fall into different category when defining the security of the system.
This is marked not-transport, but the issue was filed against text in moqt, so maybe that's not correct.
Code change:
(three dots).  The value MUST be the digest of the Disclosure created as described in hashing_disclosures.  There MUST NOT be any other <del> keys in the object. </del> <ins> keys in the object.  Note that the string was chosen because the ellipsis character, typically entered as three period characters, is commonly used in places where content is omitted from the present context. </ins> For example, using the digest of the array element Disclosure created above, the Issuer could create the following SD-JWT payload to make

Related discussion:
text: see URL and URL
oh wow... I apparently didn't confirm the merge so this is still pending. I really thought it was done and published -11. Sigh. Sorry. Will look at doing a -12 soonish.
see
Thanks for these additional updates. Michael B. Jones, Sir, I have endeavored to reply inline below to the remaining comments and/or addressing them with further updates to the source of the draft, which will appear in the -11 revision that hopefully will be published soon. I have the honor to be Your Obedient Servant, B. Cam remain consistent with that. But will expand the text defining Holder to better accommodate its use throughout the document. possible" line of reasoning, the use of the words "array elements" to mean array elements is the most concise and meaningful terminology the document authors were able to conceive of to convey the concept of elements in arrays. I believe it would be a disservice to readers to embellish the wording. a different misunderstanding at play here... and Terminology", sufficient and appropriate for the mention of a piece of terminology established by convention in a previously published RFC. 5.3. DPoP/RFC9449 is actually a complete sentence and this draft will be fixed so that it will also have a complete sentence. 5.3.2. the cnf claim the way to enable key binding with that increased interoperability as a primary aim. factually incorrect. The current wording might not be as descriptive as you'd like but it is correct. In what way does the encoding make it not a SHA-256 Hash? Asking rhetorically. opinion, that supports the assertion that any of that is "best practice". There are two occurrences of "[like or such as] nbf, iat, and exp" in the draft. In URL they are mentioned in the context of "claims carrying time information", which is what they all are. In URL they are mentioned in the context of claims to check regarding the validity of the SD-JWT. The "nbf" claim, as you likely know from (I think?) having written the text in RFC7519 , has normative requirements around when the "JWT MUST NOT be accepted for processing." As such, it is entirely appropriate in the context of mentioning some validity-controlling claims.
Code change:
(three dots).  The value MUST be the digest of the Disclosure created as described in hashing_disclosures.  There MUST NOT be any other <del> keys in the object. </del> <ins> keys in the object.  Note that the string was chosen because the ellipsis character, typically entered as three period characters, is commonly used in places where content is omitted from the present context. </ins> For example, using the digest of the array element Disclosure created above, the Issuer could create the following SD-JWT payload to make

Related discussion:
text: The only normative requirement on the "iat" claim , however, is about the syntax of its value. Rejecting a token based on the "iat" value can be required by a specific profile of JWT, such as was done in DPoP, but is otherwise something that is at the discretion of an implementation/deployment and something that has apparently been the cause of some interoperability problems . Arguably "iat" shouldn't be in that list. 10.7. belong in this list. place of content omitted from the main payload. The ellipsis is often used in place of content omitted from the context at hand. CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.
Thanks very much for addressing the majority of my comments and for replying to the rest of them. I’m replying inline to the remaining ones that I believe should still be addressed. I’ve deleted the ones from this thread that I’m satisfied with the responses to. Best wishes, -- Mike From: Kristina Yasuda Sent: Wednesday, August 14, 2024 6:07 AM To: Brian Campbell Cc: Michael Jones ; EMAIL Subject: Re: [OAUTH-WG] Re: Review of draft-ietf-oauth-selective-disclosure-jwt-10 Thank you very much, Mike. Majority of your comments have been incorporated in this PR URL, which has been merged. Below, in bold, please find explanations for the points that have not been reflected. We appreciate your review. Best, Kristina Introduction: The usage of “Holder” in “used a number of times by the user (the "Holder" of the JWT)” inconsistent with its usage in the definitions, which defines “Holder” as being “an entity”. The usage here in the introduction makes the holder into a person rather than an entity. Please adjust the language here to not confuse the user who utilizes the holder with the holder itself. -> Holder is defined as an entity and a person can be considered an entity.
Code change:
(three dots).  The value MUST be the digest of the Disclosure created as described in hashing_disclosures.  There MUST NOT be any other <del> keys in the object. </del> <ins> keys in the object.  Note that the string was chosen because the ellipsis character, typically entered as three period characters, is commonly used in places where content is omitted from the present context. </ins> For example, using the digest of the array element Disclosure created above, the Issuer could create the following SD-JWT payload to make

Related discussion:
text: We also have a phrase "the user (the "Holder" of the JWT)" in the introduction. Hence the editors consider the current wording to be sufficient. Since “Holder” is sometimes used in the spec to refer to the Wallet software and sometimes used to refer to the person using the Wallet, I believe that readers would be well served to make a clear terminological distinction between the two. Introduction: In “"Claims" here refers to both object properties (name-value pairs) as well as array elements.” change “array elements” to “elements in arrays that are the values of name/value pairs” (or something like that). Without saying what the array elements are, readers will be confused about what’s being referred to. I’d apply this clarification in 4.1. SD-JWT and Disclosures and other applicable locations as well. -> There is a misunderstanding. the intended meaning here is exactly what the text says: "each element in the array (regardless if it is a name/value pair or not, an array element as a string counts too) can be selectively disclosed". The fact that a misunderstanding is possible and occurred leads me to believe that a clarification of this phrase is needed. Readers won’t necessarily know where the “array elements” being referred to occur in the data structures. That was certainly my experience, hence my initial comment. Possible wording that’s simpler than my initial proposed wording could be “array elements occurring within Claim values”. Or clarify it with different wording of your choosing. Feature Summary: In “A format for enabling selective disclosure in nested JSON data structures, supporting selectively disclosable object properties (name-value pairs) and array elements”, consider expanding “array elements” in the same manner as the preceding comment to make the meaning more evident. -> same as above. There is a misunderstanding. the intended meaning here is exactly what the text says: "each element in the array (regardless if it is a name/value pair or not, an array element as a string counts too) can be selectively disclosed". Same response as my previous comment. 1.2.
Code change:
(three dots).  The value MUST be the digest of the Disclosure created as described in hashing_disclosures.  There MUST NOT be any other <del> keys in the object. </del> <ins> keys in the object.  Note that the string was chosen because the ellipsis character, typically entered as three period characters, is commonly used in places where content is omitted from the present context. </ins> For example, using the digest of the array element Disclosure created above, the Issuer could create the following SD-JWT payload to make

Related discussion:
text: Conventions and Terminology: I suggest moving the “base64url” definition to the Terms and Definitions section and use a parallel structure to that at URL Specifically, say “The “base64url” term denotes the URL-safe base64 encoding without padding defined in Section 2 of [RFC7515].” Then introduce the rest of the definitions with the phrase “These terms are defined by this specification:” as is done in RFC 7519. The current presentation is fairly jarring. -> Current text already points to Section 2 of RFC7515. The editors consider the current definition sufficient and clear enough. Yes, the definition is clear, but it’s in the wrong place. Definitions belong in the Terms and Definitions section. The current location leaves it strangely hang in a different section by itself, separate from the other definitions in the spec. Key Binding JWT: Change “MUST NOT be none.” to “It MUST NOT be "none".”. -> Changed to “It MUST NOT be .”. it is exactly the same wording as in DPoP RFC. The current wording is a sentence fragment – not a complete sentence. The fact that that error slipped through in DPoP isn’t a reason not to correct it here. 5.3.2. Validating the Key Binding JWT: In “if the SD-JWT contains a cnf value with a jwk member, the Verifier could parse the provided JWK and use it to verify the Key Binding JWT.”, change “could” to “MUST”. Make this normative to increase interoperability! -> the sentence you point at is an example, so we cannot add a normative statement here. We changed "should" to "would" to reflect the intent behind the suggestion. OK. Please address this then by adding this normative sentence at an appropriate place in the specification. “When the SD-JWT contains a cnf value with a jwk member, this key MUST be used to very the Key Binding JWT.” 6.1. Issuance: There are many places from here on where the label “SHA-256 Hash” is used, for instance “SHA-256 Hash: jsu9yVulwQQlhFlM3JlzMaSFzglhQG0DpfayQwLUK4”.
Code change:
(three dots).  The value MUST be the digest of the Disclosure created as described in hashing_disclosures.  There MUST NOT be any other <del> keys in the object. </del> <ins> keys in the object.  Note that the string was chosen because the ellipsis character, typically entered as three period characters, is commonly used in places where content is omitted from the present context. </ins> For example, using the digest of the array element Disclosure created above, the Issuer could create the following SD-JWT payload to make

Related discussion:
text: Change all of these to “Base64url-Encoded SHA-256 Hash” for correctness. -> Editors consider it to be sufficiently clear from the specification text that it is a base64url-endoded hash. This would also require changes to the tooling and might unintentionally make the examples harder to read. The fact remains that the current wording is factually incorrect and therefore needs to be corrected. If this can be done by updating the tooling, that’s actually good, since it means that it will be consistently corrected everywhere the error occurs. Verification of the SD-JWT: Delete “nbf” from “claims such as nbf, iat, and exp” and everywhere else in the spec, other than in 10.7. Selectively-Disclosable Validity Claims, where both “iat” and “nbf” should be listed, as described in my comment there. “iat” (Issued At) is a standard validity claim in JWT tokens (for instance, ID Tokens), whereas “nbf” (Not Before) is rarely used, since it is only useful when future-dating tokens, which is rare. -> "nbf" is used merely as an example here. the fact that it might be used rarely does not mean it cannot be used as an example, since it is a registered claim in JWT RFC. Sure, it’s an example, but the examples should nonetheless reflect best practices. Please delete “nbf” here. 10.7. Selectively-Disclosable Validity Claims: Add “iat (Issued At) to the validity claims list before “nbf”, and change “nbf (Not Before)” to “nbf (Not Before) (if present)”. “iat” (Issued At) is a standard validity claim in JWT tokens (for instance, ID Tokens), whereas “nbf” (Not Before) is rarely used, since it is only useful when future-dating tokens, which is rare. Change all uses of “nbf” to “iat” elsewhere in the spec. -> same as above. "nbf" is used merely as an example here. the fact that it might be used rarely does not mean it cannot be used as an example, since it is a registered claim in JWT RFC. As above, the examples should reflect best practices.
Code change:
(three dots).  The value MUST be the digest of the Disclosure created as described in hashing_disclosures.  There MUST NOT be any other <del> keys in the object. </del> <ins> keys in the object.  Note that the string was chosen because the ellipsis character, typically entered as three period characters, is commonly used in places where content is omitted from the present context. </ins> For example, using the digest of the array element Disclosure created above, the Issuer could create the following SD-JWT payload to make

Related discussion:
text: Please at least add “iat” to this list, even if you choose to retain “nbf”. Everywhere: Consider changing the name “…” to something more indicative of its function, such as “sdelement” or “sd_item”. Or alternatively, at least provide rationale for why that non-obvious name was chosen. -> we have extensively bikeshedded this claim name, and this one was chosen because it is concise and natural since '...' is what is used when something is omitted in a list. there seems to have been some misunderstanding how disclosure in the arrays work, so hopefully with the clarifications above, this claim also feels more appropriate than before. I wouldn’t say that there’s a misunderstanding in how disclosure in arrays work. Rather, I’d say that the current exposition of array disclosure can leave readers wondering what is meant, and could be improved by the suggested clarifications above. Thank you for explaining that “…” is intended to be understood as the ellipsis character, and the intuition behind it. Its usage in that way is slightly odd, since the ellipsis character is used in place of omitted content, whereas in this case it’s used with the opposite meaning to introduce content that is NOT omitted (content that is disclosed). Be that as it may, I understand very well the reasons for keeping the claim name as it is. Nonetheless, I think it would be helpful to readers to add a comment when the claim name is introduced about why this otherwise non-obvious claim name was chosen. The sentence you add could be something like “The claim name “…” was chosen because the ellipsis character, typically entered as three period characters, is used in contexts where content is omitted (not disclosed).” Or choose your own wording. Give readers the intuition behind the choice. Finally, this comment was incompletely addressed: Section 11.1. Storage of Signed User Data: Please change “OpenID Connect” to “OpenID Connect [OpenID.Core]” (adding the missing citation). Best wishes, -- Mike
Code change:
Some of these features are also absent in HTTP/2 and HTTP/3. Unlike HTTP/2 and HTTP/3, this format uses a fixed format for control <del> data rather than using pseudo-fields.  Messages are invalid (invalid) if they contain fields named ":method", ":scheme", ":authority", ":path", or ":status".  Other pseudo-fields that are defined by protocol extensions MAY be included; pseudo-fields cannot be included in trailers (see H2).  Field lines containing pseudo-fields MUST precede other field lines.  A message that contains a pseudo-field after any other field is invalid; see invalid. </del> <ins> data rather than using pseudo-fields. </ins> Note that while some messages - CONNECT or upgrade requests in particular - can be represented using this format, doing so serves no

Related discussion:
text: Moving normative language from Section 6 is the most useful, but there are a bunch of other stuff I noticed as I was reading through trying to implement James' other suggestion.
lgtm
Code change:
Consume a ";" character from the beginning of input_string. <del> Discard any leading OWS from input_string. </del> <ins> Discard any leading SP characters from input_string. </ins> let param_name be the result of running Parsing a Key (parse- key) with input_string.

Related discussion:
text: An alternative to - removes HTAB everywhere, replaces with .
Right now we use OWS, and suggests moving from SP to RWS for inner list separation. Should we allow tabs in SH? Error on them? If we want to allow them, 983 makes sense, as it's more consistent. However, we'll need to test for tabs...
What's the reason to allow tabs? Compatibility with current headers? Do actual tab characters show up in the wild that often?
We had them in there because we were reusing OWS, not purposefully. AFAICT they don't appear in the wild much at all. So +1 for .
LGTMThank you for working on this. LGTM.