jiebi/CodeConvo huggingface dataset:
Change:
cc NAME NAME
Yeah, I agree. Something to bring up for discussion.
LGTM, 1 week might still be too small of a window for actively malicious servers, but I think that ties in to the open issue regarding malicious servers rather than the generic key rotation considerations.

Discussion:
on a fairly regular cycle to reduce the harmfulness of a server key compromise. <ins> With an active user-base, a week gives a fairly large window for clients to participate in the Privacy Pass protocol and thus enjoy the anonymity guarantees of being part of a larger group.  The low ceiling of 12 weeks prevents a key compromise from being too destructive.  If a server realizes that a key compromise has occurred then the server should sample a new key, and upload the public key to the key registry; invoking any revocation procedures that may apply for the old key. </ins> 7.2. Similarly to the server rotation dynamic that is raised above, if

8.2. <del> We highlighted previously that short key-cycles can be used to reduce client privacy.  However, regular key rotations of the issuing key are still recommended to maintain good server key hygiene. We recommend that Privacy Pass issuing keys are rotated from anywhere between 1 and 12 weeks.  With an active user-base, a week gives a fairly large window for clients to participate in the Privacy Pass protocol and thus enjoy the anonymity guarantees of being part of a larger group.  The low ceiling of 12 weeks prevents a key compromise from being too destructive.  If a server realizes that a key compromise has occurred then the server should sample a new key and upload the public key to the key registry; invoking any revocation procedures that may apply for the old key. 8.3. </del> When a client holds tokens for an server, it is possible for any verifier to invoke that client to redeem tokens for that server. This can lead to an attack where a malicious verifier can force a

need be, by providing an expiry date or by signaling that records from a particular window need to be refreshed. <del> 8.4. </del> <ins> 8.3. </ins> [[OPEN ISSUE: explain potential and mitigations for server centralization]]
Change:
Section 4 We should probably mention the URI security considerations (RFC 3986) somewhere, as well as that remote resources need to receive an equal amount of cryptographic protection as the manifest itself, when dereferencing URIs.
Addressed in URL
Addressed in draft-ietf-suit-information-model-11
It might also be worth reiterating the topic that came up during one of the other review threads: firmware update is by definition remote code execution, so if you trust an entity to provide your firmware, you are trusting them to do the right thing. Many classes of attack involving malicious or modified payloads then become irrelevant, so we are left with just needing to verify that it did come from a trusted party and is not going backwards, topics that are covered quite well already (including TOCTOU).
Addressed in URL
Addressed in draft-ietf-suit-information-model-11

Discussion:
A Manifest Information Model for Firmware Updates in IoT Devices <del> draft-ietf-suit-information-model-10 </del> <ins> draft-ietf-suit-information-model-11 </ins> Abstract

provides the motivations for each of the manifest information elements. <ins> Note that it is worthwhile to recall that a firmware update is, by definition, remote code execution.  Hence, if a device is configured to trust an entity to provide firmware, it trusts this entity to do the "right thing".  Many classes of attacks can be mitigated by verifying that a firmware update came from a trusted party and that no rollback is taking place.  However, if the trusted entity has been compromised and distributes attacker-provided firmware to devices then the possibilities for deference are limited. </ins> 4.1. The following sub-sections aim to provide information about the

4.3.7. The location where a target should find a payload MUST be <del> authenticated. </del> <ins> authenticated.  Remote resources need to receive an equal amount of cryptographic protection as the manifest itself, when dereferencing URIs.  The security considerations of Uniform Resource Identifiers (URIs) are applicable RFC3986. </ins> Mitigates: threat-net-redirect,
Change:
Clarified several points: Remote secure clocks require authentication. This was assumed when using the "correctness guarantees" however that was not sufficiently clear. Risks associated with using a flawed clock for manifest expiry. Secure clock can be used for key expiry. Risk of flawed clock for key expiry is identical to not having key rotation.
Ben Kaduk wrote:
We might also discuss the risks when a device believes that it possesses a source of secure time but the timesource is actually flawed.

Discussion:
sources.  For local time sources, this primarily means that the clock must be monotonically increasing, including across power cycles, firmware updates, etc.  For remote time sources, the provided time <del> must be guaranteed to be correct to within some predetermined bounds, whenever the time source is accessible. </del> <ins> must be both authenticated and guaranteed to be correct to within some predetermined bounds, whenever the time source is accessible. </ins> The term Envelope is used to describe an encoding that allows the bundling of a manifest with related information elements that are not

This element is OPTIONAL. <del> Implements: </del> <ins> Implements: req-use-delegation, </ins> 4.

able to sign manifests, even if the keys for manifest signing are held in an HSM that is accessed by the server. <del> Mitigated by: </del> <ins> Mitigated by: req-sec-key-protection, </ins> 4.2.17.

for a device.  The last valid firmware should not have an expiration time. <ins> If a device has a flawed time source (either local or remote), an old update can be deployed as new. </ins> Mitigates: Implemented by:

4.3.18. <ins> Cryptographic keys for signing/authenticating manifests SHOULD be replaced from time to time.  Because it is difficult and risky to replace a Trust Anchor, keys used for signing updates SHOULD be delegates of that Trust Anchor. If key expiration is performed based on time, then a secure clock is needed.  If the time source used by a recipient to check for expiration is flawed, an old signing key can be used as current, which compounds threat-key-exposure. Mitigates: 4.3.19. </ins> Manifests SHOULD be verified prior to deployment.  This reduces problems that may arise with devices installing firmware images that damage devices unintentionally. Mitigates: <del> 4.3.19. </del> <ins> 4.3.20. </ins> For high risk deployments, such as large numbers of devices or critical function devices, manifests SHOULD be constructed in an

Mitigates: <del> 4.3.20. </del> <ins> 4.3.21. </ins> Both the manifest and any data extracted from it MUST be held immutable between its authenticity verification (time of check) and
Change:
Clarify that delegation chains are lists of authentication tokens where each token provides credentials for the next until the final token which provides the credentials for the manifest.
Ben Kaduk wrote:

Discussion:
3.25. The delegation chain offers enhanced authorization functionality via <del> authorization tokens.  Each token itself is protected and does not require another layer of protection.  Because the delegation chain is needed to verify the signature, it must be placed in the Manifest Envelope, rather than the Manifest. </del> <ins> authorization tokens, such as CBOR Web Tokens RFC8392 with Proof of Possession Key Semantics RFC8747.  Each token itself is protected and does not require another layer of protection.  Each authorization token typically includes a public key or a public key fingerprint, however this is dependent on the tokens used.  Each token MAY include additional metadata, such as key usage information.  Because the delegation chain is needed to verify the signature, it must be placed in the Manifest Envelope, rather than the Manifest. The first token in any delegation chain MUST be autheticated by the recipient's Trust Anchor.  Each subsequent token MUST be authenticated using the previous token.  This allows a recipient to discard each antecedent token after it has authenticated the subsequent token.  The final token MUST enable authentication of the manifest.  More than one delegation chain MAY be used if more than one signature is used.  Note that no restriction is placed on the encoding order of these tokens, the order of elements is logical only. </ins> This element is OPTIONAL.
Change:
(nit) §3: Please expand "RTMFP" on first mention. (nit) §5.2: "Mode 1 MUST only be used when user consent has been provided" Please consider "... MUST NOT be used unless user consent has been provided." : It seems like the references for STUN and TURN should be normative.

Discussion:
negative effects on both the proxy and on media quality. Note also that these concerns predate WebRTC; Adobe Flash Player has <del> provided similar functionality since the introduction of RTMFP RFC7016 in 2008. </del> <ins> provided similar functionality since the introduction of Real-Time Media Flow Protocol (RTMFP) support RFC7016 in 2008. </ins> 4.

quality, in addition to any performance considerations associated with sending all WebRTC media through the proxy server. <del> Mode 1 MUST only be used when user consent has been provided.  The </del> <ins> Mode 1 MUST NOT be used unless user consent has been provided.  The </ins> details of this consent are left to the implementation; one potential mechanism is to tie this consent to getUserMedia consent. Alternatively, implementations can provide a specific mechanism to
Change:
There is an implicit "where possible" here. The specific scenario is for two devices behind the same NAT who could communicate directly if only they knew each others' addresses; in this case, a direct connection should be possible, which implies that there needs to be some way for the two sides to share their machine addresses. Naturally, devices behind different NATs will not be able to do this. Noted.

Discussion:
By default, WebRTC should be able to negotiate direct peer-to-peer connections between endpoints (i.e., without traversing a NAT or <del> relay server).  This ensures that applications that need true peer-to-peer routing for bandwidth or latency reasons can operate successfully. </del> <ins> relay server) when such connections are possible.  This ensures that applications that need true peer-to-peer routing for bandwidth or latency reasons can operate successfully. </ins> It should be possible to configure WebRTC to not disclose private local IP addresses, to avoid the issues associated with web
Change:
Sure - happy to add text of this sort if we think it would be valuable. OK. :-) OK.
S 3. That said, I could get behind switching 'will' to 'can', as is used in S3, category . S 6.2. This seems like a good addition.
When I say "local" here, I am referring to the fact that the IP address is local to the machine, rather than an address for a remote party. To avoid confusion, I probably could just omit the word altogether here. Regarding NATing, your observation is often correct, but NAT64 is becoming increasingly common. I could just clarify and say that overall IPv6 avoids the issue through use of 4941 addresses.
The most obvious case is a NAT64 scenario, where the IPv6 address is never seen by the outside world, and therefore exposing said address to the web site presents a potential leakage concern. This concern is significantly mitigated if the IPv6 address is a RFC4941 ephemeral address.

Discussion:
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 <del> 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </del> <ins> 14 RFC8174 when, and only when, they appear in all capitals, as shown here. </ins> 3.
Change:
I think it is better to support script names than block names for and . Unicode block names are not supported by regexp implementations an interoperable way. Block names as specified in URL allow ASCII alpha-numerics, hyphens and spec. Unicode says these names are supposed to be matched using URL (which says to ignore case, whitespace, underscore, hyphens, and any initial prefix string "is"). But implementations don't do this and compare names using a wide variety of different rules (as partially described by "Unicode blocks" section of https://www.regular-URL). Usage of block names can easily be replaced by ranges. Furthermore, block names are not covered by the Unicode stability policy. Scripts names don't have such a wide range of characters (there are also 4-char short script names) and scripts are generally preferable to blocks for regexps as explained here: URL Script is in the minimal list of properties that Unicode requires but block is not URL
Thank you! Very useful input. We are having an interim meeting (per web conference) of the JSONPath WG at this very moment; I'll look at this later today.
I just looked again at XSD and see that sadly it doesn't support scripts in . Every major regex implementation that I am aware of that does Unicode and does support scripts (Go, PCRE, Java, C#, Ruby). So if XSD compatibility is crucial (not sure why it would be at this point), my suggestion would be just to get rid of blocks. One could argue that supporting only the general category in is consistent with not supporting character set intersection/difference: once you have multiple things (e.g. script and category), you really need to be able to have intersections/differences of them.

Discussion:
"[^]", which according to this grammar would parse as a positive character class containing the single character "^". <del> This is essentially XSD regexp without character class subtraction and multi-character escapes such as "s", "S", and "w". </del> <ins> This is essentially XSD regexp without character class subtraction, without multi-character escapes such as "s", "S", and "w", and without Unicode blocks. </ins> An I-Regexp implementation MUST be a complete implementation of this limited subset.  In particular, full Unicode support is REQUIRED; the

regexp flavors.  Thus, they are omitted from I-Regexp. Not all regexp implementations support accesses to Unicode tables <del> that enable executing on constructs such as "p{IsCoptic}", although the "p"/"P" feature in general is now quite widely available.  While in principle it's possible to translate these into codepoint-range matches, this also requires access to those tables.  Thus, regexp libraries in severely constrained environments may not be able to support I-Regexp conformance. </del> <ins> that enable executing constructs such as "p{Nd}", although the "p"/"P" feature in general is now quite widely available.  While in principle it's possible to translate these into character-class matches, this also requires access to those tables.  Thus, regexp libraries in severely constrained environments may not be able to support I-Regexp conformance. </ins> 7.
Change:
Clarifications in conversion to platform regexps.
Looks plausible but I don't know these regexps well enough to approve.

Discussion:
For any dots (".") outside character classes (first alternative of "charClass" production): replace dot by "[^nr]". <del> Envelope the result in "^" and "$". </del> <ins> Envelope the result in "^(?:" and ")$". The ECMAScript regexp is to be interpreted as a Unicode pattern ("u" flag; see Section 21.2.2 "Pattern Semantics" of ECMA-262). </ins> Note that where a regexp literal is required, the actual regexp needs to be enclosed in "/".

PCRE2, the Go programming language RE2, and the Ruby programming language, except that the last step is: <del> Enclose the regexp in "A" and "z". </del> <ins> Enclose the regexp in "A(?:" and ")z". </ins> 6.
Change:
This also adds in a sentence about using the MID header extension in outgoing streams, which was previously omitted despite there being a corresponding sentence for incoming streams.
The comment "[rfced] Please let us know if any changes are needed for the..." should also be removed.
AUTH48 on this document started with sixty [rfced] questions sent to the authors (NAME NAME NAME 2020 July 7. These questions were added as GitHub issues through . Follow on issues were created (in particular, splitting issues and ) to isolate some of the questions and to review normative text (). When PR is merged, all AUTH48 [rfced] questions will have been addressed, but there are some remaining XML comments that need to be removed.
This is sort of nuts but LGTM

Discussion:
lists each desired encoding, and no "recv" simulcast stream description.  The "m=" section will also include an "a=rid" attribute for each encoding, as specified in RFC8851; the use of Restriction <del> Identifiers (RIDs) allows the individual encodings to be disambiguated even though they are all part of the same "m=" section. </del> <ins> Identifiers (RIDs, also called rid-ids or RtpStreamIds) allows the individual encodings to be disambiguated even though they are all part of the same "m=" section. </ins> 3.8.

Once the proper "m=" section or sections are known, RTP/RTCP is delivered to the RtpTransceiver(s) associated with the "m=" section(s) and further processing of the RTP/RTCP is done at the <del> RtpTransceiver level.  This includes using RID RFC8851 to distinguish between multiple encoded streams, as well as to determine which </del> <ins> RtpTransceiver level.  This includes using the RID mechanism RFC8851 and its associated RtpStreamId and RepairedRtpStreamId identifiers to distinguish between multiple encoded streams and determine which </ins> Source RTP stream should be repaired by a given redundancy RTP stream.
Change:
is supplied to the ICE agent. In the case of a new remote candidate, connectivity checks will be sent to the new candidate. However, if you do this prior to setLD() this will not cause connectivity checks to be sent, right?
That is correct.
Do you think we should change the text to say that? Perhaps "In the case of a new remote candidate, connectivity checks will be sent to the new candidate as soon as setLD(answer) is called, or immediately if it has been called already."
Something like that seems like a good idea. It won't always be setLD with an answer though.
maybe just add ", assuming setLocalDescription has already been called to initialize the ICE gathering process."

Discussion:
Otherwise, the new remote candidate or end-of-candidates indication is supplied to the ICE agent.  In the case of a new remote candidate, <del> connectivity checks will be sent to the new candidate. </del> <ins> connectivity checks will be sent to the new candidate, assuming setLocalDescription has already been called to initialize the ICE gathering process. </ins> 4.1.20.
Change:
This includes the changes requested at IETF 111 (summarized in URL), which are: modified text in S 1.3 (requested by NAME to spell out that "must-bundle" is the behavior formerly known as "max-bundle" added brief discussion of interaction of BUNDLE and TPCC (requested by NAME
FYI NAME
LGTM.
Should we add a reference to rfc8843bis? The rest looks good.
LGTMLGTM

Discussion:
1.3. <del> When [RFC8829] was published, an inconsistency regarding BUNDLE RFC8843 operation was identified concerning both the specification text as well as implementation behavior.  The former concern was addressed via an update to RFC8843.  For the latter concern, it was observed that some implementations implemented the "max-bundle" bundle policy by assuming that bundling had already been negotiated, rather than marking "m=" sections as bundle-only as indicated by RFC8829.  In order to prevent unexpected changes to applications relying on the pre-standard behavior, the decision was made to deprecate the use of "max-bundle" and instead introduce a new "must- bundle" policy that, when selected, provides the correct behavior. </del> <ins> When RFC8829 was published, inconsistencies regarding BUNDLE RFC8843 operation were identified with regard to both the specification text as well as implementation behavior.  The former concern was addressed via an update to RFC8843.  For the latter concern, it was observed that some implementations implemented the "max-bundle" bundle policy defined in RFC8829 by assuming that bundling had already been negotiated, rather than marking "m=" sections as bundle-only as indicated by the specification.  In order to prevent unexpected changes to applications relying on the pre-standard behavior, the decision was made to deprecate "max-bundle" and instead introduce an identically defined "must-bundle" policy that, when selected, provides the behavior originally specified by RFC8829. </ins> 2.

MUST contain all "m=" sections that were previously bundled, as long as they are still alive, as well as any new "m=" sections. <ins> Note that if bundling has been negotiated, unbundling is no longer possible, and media sections will not be marked as bundle-only.  This is by design, but could cause issues in the rare case of sending a subsequent offer as an initial offer to a non-bundle-aware endpoint via Third Party Call Control (3PCC). </ins> "a=group:LS" attributes are generated in the same way as for initial offers, with the additional stipulation that any lip sync groups that were present in the most recent answer MUST continue to exist and
Change:
LGTM!
JSEP on two occasions says "SDP media description" where it seems "SDP session description" or similar would be more appropriate. "media description" seem to reference m-lines rather than the full SDP in other documents (4566, 3264).
agree - see if that pull request fixes it
to my understanding it does fix it!

Discussion:
3.1. JSEP does not specify a particular signaling model or state machine, <del> other than the generic need to exchange SDP media descriptions in the </del> <ins> other than the generic need to exchange session descriptions in the </ins> fashion described by RFC3264 (offer/answer) in order for both sides of the session to know how to conduct the session.  JSEP provides mechanisms to create offers and answers, as well as to apply them to

Changes MUST NOT be silently ignored. <del> The following elements of the SDP media description MUST NOT be changed between the createOffer and the setLocalDescription (or between the createAnswer and the setLocalDescription), since they reflect transport attributes that are solely under browser control, and the browser MUST NOT honor an attempt to change them: </del> <ins> The following elements of the session description MUST NOT be changed between the createOffer and the setLocalDescription (or between the createAnswer and the setLocalDescription), since they reflect transport attributes that are solely under browser control, and the browser MUST NOT honor an attempt to change them: </ins> The number, type and port number of m= lines.