jiebi/CodeConvo huggingface dataset:
Code change:
9.3. <ins> A service requesting a Txn-Token SHOULD provide an incoming token if it has one that it used itself to authorize a caller, and if it directly correlates with the downstream call chain it needs the Txn- Token for.  In the absence of an appropriate incoming token, the requesting service MAY use a self-signed JWT, an unsigned JSON object or any other format to represent the details of the requester to the Txn-Token service. 9.4. </ins> How requesting clients authenticate to the Transaction Token Service is out of scope for this specification.  However, if using the "actor_token" and "actor_token_type" parameters of the OAuth 2.0

Related discussion:
text: The notes copy-pasted from the WG notes do say "when", but based on our recollection of the events during that session, the real ask was to clarify that one could use unsigned JSON objects. That is indicated in the action item (i.e. the last line in that issue description)
the following came up in the IETF 120 session about TraTs: "Add an outline on when self-signed may be useful Yaron thought self-signed wil be a footgun Suggest a simple JSON object as replacement." The description of in section 7.1 is too rigid as it only allows an inbound token or a self-signed token. It should make it clear that an implementation may choose to have any different format for the subjecttoken.
Just a few very minor comments
Code change:
9.3. <ins> A service requesting a Txn-Token SHOULD provide an incoming token if it has one that it used itself to authorize a caller, and if it directly correlates with the downstream call chain it needs the Txn- Token for.  In the absence of an appropriate incoming token, the requesting service MAY use a self-signed JWT, an unsigned JSON object or any other format to represent the details of the requester to the Txn-Token service. 9.4. </ins> How requesting clients authenticate to the Transaction Token Service is out of scope for this specification.  However, if using the "actor_token" and "actor_token_type" parameters of the OAuth 2.0

Related discussion:
text: The following issue came up during the IETF 120 session on TraTs: There was a comment about some of the processing rules that was the equivalent of NULL with extra processing steps (N_A)
George and Atul recommend that we should drop the sentences after "REQUIRED A unique transaction identifier as defined in Section 2.2 of ]." Since this is a normative section, it need not have any usage guidance in there. If required we can add non-normative usage guidance such as "The txn value MAY be used to identify the call chain"
Code change:
STUB_PROVIDED_PREFIX_LIFETIME seconds.  The stub router sends a router advertisement (RA) containing this prefix in a Prefix Information Option (PIO).  In the PIO, the 'A' flag bit (autonomous <del> configuration) flag RFC4861 MUST be set and the 'L' flag bit (on-link prefix) MUST be set.  Link-layer technologies that require the 'L' flag bit to be cleared are out of scope of this document. The Stub Router flag (I-D.hui-stub-router-ra-flag) MUST be set in the RA flags field.  The values of the M and O flags MUST be copied from the respective M/O flag values seen in the most recent (unicast or multicast) RA received from a non-stub-router.  For the selection of the most recent RA, the following RAs MUST be excluded: If there is no recent RA from a non-stub-router, both M and O flags MUST be cleared, unless the stub router rebooted recently.  After a reboot, if no recent RA is received from a non-stub router, but a recent RA has been received from a stub router, the values for the M and O flags provided by that stub router MUST be copied.  After MAX_FLAGS_COPY_TIME after reboot, the stub router MUST go back to the regular behavior defined above.  This avoids a situation where a stub router that has rebooted starts to advertise different M/O flag values than other stub routers present on the same link. </del> <ins> configuration) RFC4861 MUST be set and the 'L' flag bit (on-link prefix) MUST also be set.  Link-layer technologies that require the 'L' flag bit to be cleared are out of scope of this document. The 'Stub Router' flag bit (I-D.hui-stub-router-ra-flag) MUST be set in the RA flags field.  The values of the 'M' and 'O' flag bits MUST be copied from the respective 'M' and 'O' flag bit values seen in the most recent (unicast or multicast) RA received from a non-stub- router.  For the selection of the most recent RA, the following RAs MUST be excluded: If there is no recent RA from a non-stub-router, both 'M' and 'O' flag bits MUST be cleared, unless the stub router rebooted recently. After a reboot, if no recent RA is received from a non-stub router, but a recent RA has been received from a stub router, the values for the 'M' and 'O' flag bits provided by that stub router MUST be copied.  After MAX_FLAGS_COPY_TIME after reboot, the stub router MUST go back to the regular behavior defined above.  This avoids a situation where a stub router that has rebooted starts to advertise different 'M' and 'O' flag bit values than other stub routers present on the same link. </ins> The sent router advertisement MUST also include a Route Information option (RFC4191) for each routable prefix advertised on the stub

Related discussion:
text: Flag bits can be referred to as "bit", "flag", or "flag bit". This issue is an editorial reminder to update to a consistent term later on. E.g. "flag" or "flag bit" is most clear I think.
Assigning to myself, to make a PR later on. Everyone and NAME feel free to suggest preferred term. I find "flag bit" the most clear.
Code change:
However, these rely on collision-resistance for their security proofs CMU-836068.  The MD5 and SHA-1 algorithms are vulnerable to <del> collisions attacks, so MD5 MUST NOT be used and SHA-1 is NOT RECOMMENDED for use with "Digest". </del> <ins> collisions attacks, so they MUST NOT be used with "Digest". </ins> 11.3.

Related discussion:
text: Deprecates SHA-1 as it's now vulnerable to collisions.
SHA-1 to be deprecated in because of https://sha-URL It's NOT RECOMMENDED When we decided to NOT RECOMMEND sha-1, we knew that collisions were possible. Now researchers states that The latest paper is here URL
Some feedback I've had is that we should deprecate. I'd like to hear from the WG if there is any pushback to doing so.
I'm in favour of deprecation.
3GPP TLS Profile 6 also makes SHA-1 a "must not" for TLS 1.2 [1]. [1] - URL
lgtm
Code change:
of the Parameter Value field in bytes. Each parameter description will indicate the data type in the <del> Parameter Value field.  If the parameter value is a varint, but the self-encoded length of that varint does not match the Parameter Length field, the receiver MUST ignore the parameter using the value in the Parameter Length field. </del> <ins> Parameter Value field.  If a receiver understands a parameter type, and the parameter length implied by that type does not match the Parameter Length field, the receiver MUST terminate the session with error code 'Parameter Length Mismatch'. </ins> 6.1.1.

Related discussion:
text: Currently, VarInts have two lengths: In the parameter length. In the first two bits of the parameter value. The decision in was that the two MUST match, which is a good solution without a full reform. However: Ignoring seems like the wrong play. For example, we know the role parameter (0x0) is a VarInt in the current draft. However this text says I MUST ignore any errors when parsing this varint and pretend like the parameter was never sent, which is both unenforceable and a major foot-gun (silently ignoring parameters). I think we close the connection with an error if there's an error parsing a known parameter.
If a parameter is unknown, then the parser doesn't know if the value is a varint and therefore can't check the length match. I thought it was better to have consistent behavior than not, because it's easier to write and easier to reason about. But if this has actual downstream consequences, I could be convinced otherwise.
I don't know what I was smoking when I came up with this title. My concern is that when a known parameter has the wrong length, the text says the decoder MUST ignore it. But it likely has the wrong length due to a bug, so this will cause unintended (non-fatal) behavior.
I understand what you mean. My point was that an unknown parameter has an inevitable result, and trying to make the processing for known parameters the same had some advantages. We'll discuss today.
Conclusion was to make it an error instead of skipping over the field if there's a length mismatch.
LG, though we can bikeshed about the error code name.
Code change:
A successful response to a SEARCH request is expected to provide some indication as to the final disposition of the search operation.  For instance, a successful search that yields no results can be <del> represented by a 204 No Content response.  If the response includes a </del> <ins> represented by a 204 No Content response.  If the response includes </ins> content, it is expected to describe the results of the search operation.  In some cases, the server may choose to respond indirectly to the SEARCH request by returning a 3xx Redirection with

Related discussion:
text: This minor nit was the only thing that jumped out at me during a read-through before the interim.
Code change:
3.2.1. <ins> In a typical live video ingest, the broadcast client - for example, an Open Broadcaster Software (OBS) client, publishes the video content to an ingest server under a provider domain. The Track IDs are scoped to the broadcast for the application under a provider domain. </ins> Where media is received from a source for onwards handling into a distribution platform.  The media may comprise of multiple audio and/ or video sources.  Bitrates may either be static or set dynamically

Related discussion:
text: Note - this is a rough draft, although I have done some edits while adding this material. I do have notes for to-dos, and I'm pretty sure I want to figure out how to do the diagrams in some way that will format with straight lines, for starters.
I'm happy to just merge this in now as is just to unblock other work and make progress, and make any adjustments later because there's nothing that stands out as controversial, NAME are you okay with this?
We have a plan on how to resolve our terminology migration for in this PR
Based on review comments from NAME on the mailing list .
Draft is in suhasHere/moq-drafts.
NAME - NAME and I are starting with the scenarios from URL
NAME - I think it would be good to close this issue when we have a reasonable plan for where the material from the scenarios draft goes, and then handle further changes via issues and PRs as usual. Does that make sense? NAME NAME and NAME - I wanted to let you know that NAME and I are (finally, finally!) merging text from the scenarios draft in the requirements draft, as NAME suggested. I think I have homes for almost all of the text from the requirements draft, but I do have some work to do, so that the material is in the right place, and that it flows with text from the previous version of the requirements draft. I am, of course, always interested in comments. And thank you each for the work you did on this material.
Awesome - let me know if something I can do to help
Thanks NAME .. look forward to the updates. +1 to NAME , please let me know if we can be of any help Here is my review. Firstly, I'd like to say that this document is badly needed. The requirements document doesn't get into the level of detail that this document does, and I think that this level of detail is important to make progress on the design. Terminology I think it would be useful to define some of the terminology, including terms like "track" and "media switch". Section 2.2 A few questions: Are the trackIDs "t1, t2, t3" separate MediaStreamTracks, or are they just multiple encodings of the same track?
Code change:
3.2.1. <ins> In a typical live video ingest, the broadcast client - for example, an Open Broadcaster Software (OBS) client, publishes the video content to an ingest server under a provider domain. The Track IDs are scoped to the broadcast for the application under a provider domain. </ins> Where media is received from a source for onwards handling into a distribution platform.  The media may comprise of multiple audio and/ or video sources.  Bitrates may either be static or set dynamically

Related discussion:
text: Are there scenarios in which it would be useful to be able to ingest multiple MediaStreamTracks (either audio or video)? I ask because the RUSH draft doesn't support ingestion of multiple tracks and I've been told that this is a problem by some customers. Section 2.4 A media switch, sourcing tracks that represent a subset of tracks from across all the emitters. Such subset may represent tracks representing top 5 speakers at higher qualities and lot of other tracks for rest of the emitters at lower qualities. [BA] The use of the term "media switch" suggests to me that it is forwarding tracks, rather than sourcing (e.g. transcoding) them. Can you clarify? subscribing to subset of the tracks [BA] I think there may be an implicit assumption here, which is that the receiver only indicates the track it wishes to subscribe to, rather than indicating the quality it wishes to receive. Above setup brings in following properties on the data model for the transport protocol [BA] The paragraphs that follow appear to describe different ways that the system could be implemented, rather than "properties on the data model". Do you mean to say that the design should be able to handle any of the approaches described? Media Switches to source new tracks but retain media payload from the original emitters. This implies publishing new Track IDs sourced from the SFU, with object payload unchanged from the original emitters. [BA] Is the term "source new tracks" implied by changing the Track IDs? If the payload is retained, this seems like forwarding to me, rather than "sourcing new tracks". Media Switches to propogate subset of tracks as-is from the emitters to the subscribers. This implies Track IDs to be unchanged between the emitters and the receivers. [BA] What does "as-is" mean here? Are you referring only the lack of a change in the "Track ID"? If the switch drops some frames in order to reduce quality (and bandwidth consumption) is it still "as-is"? Subscribers to explictily request multiple appropriate qualities and dynamically move between the qualtiies during the course of the session [BA] Is it a goal to be able to support such a "receiver driven" approach, as well as the other two approaches, which are sender driven?
Code change:
3.2.1. <ins> In a typical live video ingest, the broadcast client - for example, an Open Broadcaster Software (OBS) client, publishes the video content to an ingest server under a provider domain. The Track IDs are scoped to the broadcast for the application under a provider domain. </ins> Where media is received from a source for onwards handling into a distribution platform.  The media may comprise of multiple audio and/ or video sources.  Bitrates may either be static or set dynamically

Related discussion:
text: Section 3.1 For example, rather than waiting for 30 seconds before connecting, the user might quickly download the "key" frames of the past 30 seconds and replay them in order to "synchronize" the video decoder. [BA] I think this sentence points out that the term "access point" may need to be clarified, because in such a scenario, the term "access point" may have a different meaning in stored media than in media transmitted over the wire to speed up join latency. Section 3.2 It is possible to use groups as units of congestion control. When the sending strategy is understoud, the objects in the group can be assigned sequence numbers and drop priorities that capture the encoding dependencies, such that: an object can only have dependencies with other objects in the same group, an object can only have dependencies with other objects with lower sequence numbers, an object can only have dependencies with other objects with lower or equal drop priorities. [BA] This text seems to be mixing distinct concepts such as dependencies and layering. In layered coding, there is typically only a requirement not to depend on higher layers, but it's possible to depend on frames in lower layers. Mixing drop priority (a transport concept) with groups seems confusing to me. The main drawback is that if a packet with a given drop priority is actually dropped, all objects with higher sequence numbers and higher or equal drop priorities in the same group must be dropped. [BA] Leaving gaps in the sequence number space does seem problematic, but that's a choice, not a requirement. If the group duration is long, this means that the quality of experience may be lowered for a long time after a brief congestion. If the group duration is short, this can produce a jarring effect in which the quality of experience drops perdiodically at the tail of the group. [BA] What does "group duration" mean? Are you referring to time between I-frames? This paragraph seems to assume that group duration is a constant rather than something which can be set dynamically. Section 4 Some video codecs have a complex structure. [BA] Are you referring to codecs, or encodings? It would send for example: [BA] A picture might help here.
Code change:
3.2.1. <ins> In a typical live video ingest, the broadcast client - for example, an Open Broadcaster Software (OBS) client, publishes the video content to an ingest server under a provider domain. The Track IDs are scoped to the broadcast for the application under a provider domain. </ins> Where media is received from a source for onwards handling into a distribution platform.  The media may comprise of multiple audio and/ or video sources.  Bitrates may either be static or set dynamically

Related discussion:
text: I think you're referring to the scalabilty mode known as "L2T2h": URL Of course, we could encode these dependencies as properties of the object being sent, stating for example that "object 17 can only be decoded if objects 16, 11 and 7 are available." However, this approach leads to a lot of complexity in relays. We believe that a linear approach is preferable, using attributes of objects like delivery order or priorities. [BA] Why would this lead to complexity in relays in a receiver-driven scenario? The relay would only forward the layers that the receiver asked for, and wouldn't have to store state relating to the receivers. Also, the real issue here isn't dropping layers, which can occur at any point. The reason dependencies (and more) are needed (and why the "linear approach" doesn't work) comes when it is desired to add layers. It is of course possible just to start forwarding additional layers, but that doesn't improve quality unless the forwarded frames can actually be decoded. To figure this out, whoever is in charge (receiver or relay) needs to be able to determine the "upswitch points". This also implies feedback from the receivers to the encoder (e.g. LRR). Section 4.2 We propose to express dependencies using a combination of object number and object priority. [BA] How would this permit restoration of video quality after congestion clears up? I don't think you have enough information. Section 4.3 . Relay behavior In case of congestion, the relay will use the priorities to selectively drop the "least important" objects: [BA] Dropping is easy, it's adding layers back (and decoding them) that's hard.
Code change:
original header list. Once a header field is decoded and added to the reconstructed header <del> list, it cannot be removed from it.  A header field added to the </del> <ins> list, the field cannot be removed.  A header field added to the </ins> header list can be safely passed to the application. By passing the resulting header fields to the application, a decoder

Related discussion:
text: had a few actionable comments that seemed relatively easy to handle. In the absence of feedback from NAME and NAME I responded. Of note: the introductory text in URL about the choice to make the format inflexible.
Code change:
representation of the cache's state regarding that origin, for the type of cached response indicated by the "STALE" flag. <del> *VALIDATORS* (0x4): When set, indicates that the "validators" boolean in computing is true. *STALE* (0x8): When set, indicates that all cached responses represented in the digest-value are stale RFC7234 at the point in them that the digest was generated; otherwise, all are fresh. </del> 2.1. A CACHE_DIGEST frame MUST be sent from a client to a server on stream

Related discussion:
text: Resolves URL
cc NAME NAME
Hey Yoav, Thanks; will take a look. Two immediate things: You're getting a error in the markdown; . I see you've added yourself as an author. That's generally the decision of the chair - NAME in this case.
Hopefully fixed. Is there a way to test it locally? Apologies for the noobness. Removed myself.
See URL for build info.
NAME Thank you for working on the proposal. Am I correct in assuming that changes other than the switch to Cuckoo filters and the introduction are unintentional? For example, I see flag of the frame being removed. Do you have a working code that implements Cuckoo filters? I am curious to see it working. The concept of makes sense to me. Maybe we might want to adjust the codepoints and the naming in relation to .
Oh, I now understand the intent of removing the flag. The motive of the proposal is to build a digest without referring to every response object stored in cache. The fact means that it is not be easy for the client to determine the freshness of the entries that is going to be included in the digest. I am sympathetic to the idea, but I am afraid if the approach works well with the current mechanism of HTTP/2 caching. My understanding is that browsers that exist today only consume a pushed response when it fails to find a freshly cached response in its cache. Otherwise, the pushed response never lands in the browser cache. Unless we change the behavior of the browsers to respect the pushed response even if a freshly cached object already exists in its cache, there's a chance that servers would continually push responses that gets ignored by the client (due to the existence of a freshly cached response in the browser cache with the same URL). NAME Assuming that I correctly understand the motive of removing the distinction between a fresh digest and a stale digest, I would appreciate it if you could clarify your ideas on the problem.
Thanks for reviewing, NAME :) My intent was to include all stored resources in the digest, regardless of them being stale or fresh. Entries are added to the digest when a resource is added to the cache and removed from the digest when a resource is removed.