jiebi/CodeConvo huggingface dataset:
Code change:
by popular demand in .
As discussed at IETF 108. Split from .
Thanks for filing this. I agree that this was the feedback, but I'll take it from the list to be sure.
Removing this seems fine to me.
Yes, do it.
Seems fine.
Do it.
Do it.
Nick Harper concurred on the list
Yes, that works. Minor comment.

Related discussion:
text: map to the same server.  It could then apply analytical techniques to try to obtain the server encoding. <del> The Stream and Block Cipher CID algorithms provide robust entropy to making any sort of linkage.  The Obfuscated CID obscures the mapping and prevents trivial brute-force attacks to determine the routing parameters, but does not provide robust protection against sophisticated attacks. </del> <ins> The Stream and Block Cipher CID algorithms provide robust protection against any sort of linkage.  The Plaintext CID algorithm makes no attempt to protect this encoding. </ins> Were this analysis to obtain the server encoding, then on-path observers might apply this analysis to correlating different client
Code change:
by popular demand in .
As discussed at IETF 108. Split from .
Thanks for filing this. I agree that this was the feedback, but I'll take it from the list to be sure.
Removing this seems fine to me.
Yes, do it.
Seems fine.
Do it.
Do it.
Nick Harper concurred on the list
Yes, that works. Minor comment.

Related discussion:
text: To avoid this, the configuration agent SHOULD issue QUIC-LB configurations to mutually distrustful servers that have different <del> keys (for the block cipher or stream cipher algorithms) or routing masks and divisors (for the obfuscated algorithm).  The load balancers can distinguish these configurations by external IP address, or by assigning different values to the config rotation bits (config-rotation).  Note that either solution has a privay impact; see multiple-configs. </del> <ins> keys for encryption algorithms.  The load balancers can distinguish these configurations by external IP address, or by assigning different values to the config rotation bits (config-rotation).  Note that either solution has a privacy impact; see multiple-configs. </ins> These techniques are not necessary for the plaintext algorithm, as it does not attempt to conceal the server ID.
Code change:
Adding a description to signaling options to improve readability. I have pending to update L2TP after the other issue is solved URL
Thanks, Victor. Does the text reflect the latest version of signaling/discovery split?
leaf l2tp-type { type identityref { base t-ldp-pwe-type; } description "T-LDP PWE type."; }
The type should be taken from this registry: URL
A new IANA-maintained module is created to fix this issue.

Related discussion:
text: 6.3.2.1. This sub-tree defines the L2VPN service type, according to the <del> several signalling options to exchange membership information between </del> <ins> several signaling options to exchange membership information between </ins> PEs of an L2VPN.  The following signaling options are supported: <del> Refers to the BGP control plane as described in RFC4761 and RFC6624. Refers to the BGP control plane as described in RFC7432 and RFC7209. </del> <ins> The service is a Multipoint VPLSs that use a BGP control plane as described in RFC4761 and RFC6624.  For this L2VPN service, the model allows configuring the Route Distinguisher, the Route Targets, the PWE encapsulation type and the MTU configurations to allow MTU mismatch. The service is a Multipoint VPLSs that use also a BGP control plane but also includes the additional features and related parameters RFC7432 and RFC7209.  The model allows the configuration of the EVPN service interface type, the local and remote VPWS Service Instance (VSI) RFC8214, the EVPN policies for handling MAC addresses and the Ethernet Segment Identifier (ESI) information. </ins> <del> Refers to LDP-signaled pseudowires RFC6074. </del> <ins> A Multipoint VPLSs that use a mesh of LDP-signaled Pseudowires RFC6074.  The model allows configuring the T-LDP PWE type, MTU mismatch and the list of AC and PW bindings. </ins> <del> Refers to L2TP-signaled pseudowires RFC6074. </del> <ins> The L2 VPN uses L2TP-signaled Pseudowires as described in RFC6074. The model allows configuring TBC. </ins> 6.3.2.2.
Code change:
adds a missing digest parameter corrects CDDL for suit-text removes dangling
I have discovered this because the EAT build process pulls the SUIT CDDL in for validation using the cddl tool.
NAME posted to the list the following: I think I found a little typo in the draft-ietf-suit-manifest-14 ... At the "Appendix A. A. Full CDDL" of the "SUITSeverableMembersChoice", the last two members are pointing to "SUITCommand_Sequence" are probably typos as following,
In draft-ietf-suit-manifest-04 In the example manifest image-digest parameter is set for component 0 in common sequence. The load sequence sets component-index to 1 and after directive-copy it specifies image-match condition. However, the image-digest parameter has not been set for component-index 1 causing the condition to fail as . Is it expected that parameters are implicitly copied from source component when copy-directive is executed? Should the image-digest be also specified for component-index 1 or perhaps for all components? Another observation in the example is that vendor-id and class-id parameters and corrsponding condition checks are specified for component 0, which seems to be the "external storage". Wouldn't it be better to specify the VID and CID globally for the entire device or for the component 1, which seems to be the one running the image? / common / 3:h'a2024782814100814101045856880c0014a40150fa6b4a5 3d5ad5fdfbe9de663e4d41ffe02501492af1425695e48bf429b2d51f2ab45038202582 000112233445566778899aabbccddeeff0123456789abcdeffedcba98765432100e198 7d001f602f6' / { / components / 2:h'82814100814101' / [ [h'00'] , [h'01'] ] /, / common-sequence / 4:h'880c0014a40150fa6b4a53d5ad5fdfbe9d e663e4d41ffe02501492af1425695e48bf429b2d51f2ab450382025820001122334455 66778899aabbccddeeff0123456789abcdeffedcba98765432100e1987d001f602f6' / [ / directive-set-component-index / 12,0 , / directive-override-parameters / 20,{ / vendor-id / 1:h'fa6b4a53d5ad5fdfbe9de663e4d41ffe' / fa6b4a53-d5ad-5fdf- be9d-e663e4d41ffe /, / class-id / 2:h'1492af1425695e48bf429b2d51f2ab45' / 1492af14-2569-5e48-bf42-9b2d51f2ab45 /, / image-digest / 3:[ / algorithm-id / 2 / sha256 /, / digest-bytes / h'00112233445566778899aabbccddeeff0123456789abcdeffedcba9876543210' ], / image-size / 14:34768, } , / condition-vendor-identifier / 1,F6 / nil / , / condition-class-identifier / 2,F6 / nil / ] /, } /, (...) / load / 11:h'880c0113a1160016f603f6' / [ / directive-set-component-index / 12,1 , / directive-set-parameters / 19,{ / source-component / 22:0 / [h'00'] /, } , / directive-copy / 22,F6 / nil / , / condition-image-match / 3,F6 / nil / ] /,

Related discussion:
text: of the element and to ensure correct serialization for integrity and authenticity checks. <ins> All CBOR maps in the Manifest and manifest envelope MUST be encoded with the canonical CBOR ordering as defined in RFC8949. </ins> 8.2. The Envelope contains each of the other primary constituent parts of
Code change:
adds a missing digest parameter corrects CDDL for suit-text removes dangling
I have discovered this because the EAT build process pulls the SUIT CDDL in for validation using the cddl tool.
NAME posted to the list the following: I think I found a little typo in the draft-ietf-suit-manifest-14 ... At the "Appendix A. A. Full CDDL" of the "SUITSeverableMembersChoice", the last two members are pointing to "SUITCommand_Sequence" are probably typos as following,
In draft-ietf-suit-manifest-04 In the example manifest image-digest parameter is set for component 0 in common sequence. The load sequence sets component-index to 1 and after directive-copy it specifies image-match condition. However, the image-digest parameter has not been set for component-index 1 causing the condition to fail as . Is it expected that parameters are implicitly copied from source component when copy-directive is executed? Should the image-digest be also specified for component-index 1 or perhaps for all components? Another observation in the example is that vendor-id and class-id parameters and corrsponding condition checks are specified for component 0, which seems to be the "external storage". Wouldn't it be better to specify the VID and CID globally for the entire device or for the component 1, which seems to be the one running the image? / common / 3:h'a2024782814100814101045856880c0014a40150fa6b4a5 3d5ad5fdfbe9de663e4d41ffe02501492af1425695e48bf429b2d51f2ab45038202582 000112233445566778899aabbccddeeff0123456789abcdeffedcba98765432100e198 7d001f602f6' / { / components / 2:h'82814100814101' / [ [h'00'] , [h'01'] ] /, / common-sequence / 4:h'880c0014a40150fa6b4a53d5ad5fdfbe9d e663e4d41ffe02501492af1425695e48bf429b2d51f2ab450382025820001122334455 66778899aabbccddeeff0123456789abcdeffedcba98765432100e1987d001f602f6' / [ / directive-set-component-index / 12,0 , / directive-override-parameters / 20,{ / vendor-id / 1:h'fa6b4a53d5ad5fdfbe9de663e4d41ffe' / fa6b4a53-d5ad-5fdf- be9d-e663e4d41ffe /, / class-id / 2:h'1492af1425695e48bf429b2d51f2ab45' / 1492af14-2569-5e48-bf42-9b2d51f2ab45 /, / image-digest / 3:[ / algorithm-id / 2 / sha256 /, / digest-bytes / h'00112233445566778899aabbccddeeff0123456789abcdeffedcba9876543210' ], / image-size / 14:34768, } , / condition-vendor-identifier / 1,F6 / nil / , / condition-class-identifier / 2,F6 / nil / ] /, } /, (...) / load / 11:h'880c0113a1160016f603f6' / [ / directive-set-component-index / 12,1 , / directive-set-parameters / 19,{ / source-component / 22:0 / [h'00'] /, } , / directive-copy / 22,F6 / nil / , / condition-image-match / 3,F6 / nil / ] /,

Related discussion:
text: MUST still contain the suit-authentication-wrapper element, but the content MUST be a list containing only the SUIT_Digest. <ins> The algorithms used in SUIT_Authentication are defined by the profiles declared in I-D.moran-suit-mti. </ins> 8.4. The manifest contains:
Code change:
Let's remove this sentence and add more information when we will have this additional experimental data
This area probably needs more experimentation in general. For instance, it is unclear how much we could partition such IPv6 addresses by origin like we ask for mDNS names. Given we already talk about this approach in the privacy section, these sentences do not feel mandatory to keep. No strong feelings either way though.
I looked at the current text more closely and I see what you are saying, especially regarding different origins. We should probably talk about the separation of origins or browsing contexts more in the introduction though. Currently it only refers to the fingerprinting threat, which could be construed to simply mean a long-term identifier.
I don't think we needed to nuke this whole section, just the future version of the document sentence.

Related discussion:
text: explanation for the overall connection rate drop is that hairpinning failed in some cases. <del> One potential mitigation, as discussed in privacy, is to not conceal candidates created from RFC4941 IPv6 addresses.  This permits connectivity even in large internal networks or where mDNS is disabled.  Future versions of this document will include experimental data regarding this option. </del> 5.2. As noted in description, ICE agents using the mDNS technique are
Code change:
introduce numbered sections for YAML NAME since each media type is defined in its IANA consideration, would it be ok for you if we just add a section for YAML? Feel free to PR with another proposal.
NAME could you PTAL ? :)
to be honest, i prefer definitions to have URIs and not just registrations. but if we have URIs, that's already a lot better than not having URIs! thanks!
it's maybe just OCD (and because it's very useful for URL to have linkable references) but i think it's nice to have numbered sections for everything that's being defined in the spec. in this case, i suggest to have a numbered section for each of the four media types, and to have a brief explanation of what it identifies. that way, each definition is self-contained and can be easily referenced when necessary. NAME NAME

Related discussion:
text: This document uses the Augmented BNF defined in RFC5234 and updated by RFC7405. <del> 1.2. The OpenAPI Specification Media Types convey OpenAPI Specification (OAS) files as defined in oas for version 3.0.0 and above. Those files can be serialized in JSON or yaml.  Since there are multiple OpenAPI Specification Specifications versions, those media- types support the "version" parameter. The following examples conveys the desire of a client to receive an OpenAPI Specification resource preferably in the following order: openapi 3.1 in yaml openapi 3.0 in yaml any openapi version in json </del> 2. <del> Security requirements for both media type and media type suffix registrations are discussed in Section 4.6 of MEDIATYPE. </del> <ins> This section describes the information required to register the above media types. </ins> <del> 3. </del> <ins> 2.1. </ins> <del> This specification defines the following new Internet media types MEDIATYPE. 3.1. </del> <ins> The following information serves as the registration form for the "application/yaml" media type. </ins> Type name: application
Code change:
introduce numbered sections for YAML NAME since each media type is defined in its IANA consideration, would it be ok for you if we just add a section for YAML? Feel free to PR with another proposal.
NAME could you PTAL ? :)
to be honest, i prefer definitions to have URIs and not just registrations. but if we have URIs, that's already a lot better than not having URIs! thanks!
it's maybe just OCD (and because it's very useful for URL to have linkable references) but i think it's nice to have numbered sections for everything that's being defined in the spec. in this case, i suggest to have a numbered section for each of the four media types, and to have a brief explanation of what it identifies. that way, each definition is self-contained and can be easily referenced when necessary. NAME NAME

Related discussion:
text: Change controller: n/a <del> 3.2. </del> <ins> 2.2. The OpenAPI Specification Media Types convey OpenAPI document (OAS) files as defined in oas for version 3.0.0 and above. Those files can be serialized in JSON or yaml.  Since there are multiple OpenAPI Specification versions, those media-types support the "version" parameter. The following examples conveys the desire of a client to receive an OpenAPI Specification resource preferably in the following order: openapi 3.1 in yaml openapi 3.0 in yaml any openapi version in json 2.2.1. The following information serves as the registration form for the "application/openapi+json" media type. </ins> Type name: application
Code change:
introduce numbered sections for YAML NAME since each media type is defined in its IANA consideration, would it be ok for you if we just add a section for YAML? Feel free to PR with another proposal.
NAME could you PTAL ? :)
to be honest, i prefer definitions to have URIs and not just registrations. but if we have URIs, that's already a lot better than not having URIs! thanks!
it's maybe just OCD (and because it's very useful for URL to have linkable references) but i think it's nice to have numbered sections for everything that's being defined in the spec. in this case, i suggest to have a numbered section for each of the four media types, and to have a brief explanation of what it identifies. that way, each definition is self-contained and can be easily referenced when necessary. NAME NAME

Related discussion:
text: Change controller: n/a <del> 3.3. </del> <ins> 2.2.2. The following information serves as the registration form for the "application/openapi+yaml" media type. </ins> Type name: application
Code change:
introduce numbered sections for YAML NAME since each media type is defined in its IANA consideration, would it be ok for you if we just add a section for YAML? Feel free to PR with another proposal.
NAME could you PTAL ? :)
to be honest, i prefer definitions to have URIs and not just registrations. but if we have URIs, that's already a lot better than not having URIs! thanks!
it's maybe just OCD (and because it's very useful for URL to have linkable references) but i think it's nice to have numbered sections for everything that's being defined in the spec. in this case, i suggest to have a numbered section for each of the four media types, and to have a brief explanation of what it identifies. that way, each definition is self-contained and can be easily referenced when necessary. NAME NAME

Related discussion:
text: Change controller: n/a <del> 4.  References </del> <ins> 3. Security requirements for both media type and media type suffix registrations are discussed in Section 4.6 of MEDIATYPE. </ins> <del> 4.1.  URIs </del> <ins> 4. This specification defines the following new Internet media types MEDIATYPE. IANA has updated the "Media Types" registry at https://www.iana.org/assignments/media-types [3] with the registration information provided below. 5.  References 5.1.  URIs </ins> [1] https://mailarchive.ietf.org/arch/browse/httpapi/ [2] https://github.com/ioggstream/draft-polli-rest-api-mediatypes <ins> [3] https://www.iana.org/assignments/media-types </ins>
Code change:
WGLC comments on Operation Requirements section. Added several overlooked requirements
Discussed on 12/8 interim, and folks seemed fine with this. I.e., it's ready to merge.

Related discussion:
text: service, defines the types of credentials which may be used in a deployment and provides methods for: <del> Issuing new credentials, </del> <ins> Issuing new credentials with a relevant credential lifetime, </ins> <del> Validating a credential against a reference identifier, and </del> <ins> Validating a credential against a reference identifier, </ins> Validating whether or not two credentials represent the same <del> client. </del> <ins> client, and Optionally revoking credentials which are no longer authorized. </ins> A *Delivery Service*, described fully in delivery-service, provides methods for:
Code change:
WGLC comments on Operation Requirements section. Added several overlooked requirements
Discussed on 12/8 interim, and folks seemed fine with this. I.e., it's ready to merge.

Related discussion:
text: Delivering Welcome messages to new members of a group. <del> Downloading KeyPackages for specific clients, and uploading new KeyPackages for a user's own clients. </del> <ins> Uploading new KeyPackages for a user's own clients. Downloading KeyPackages for specific clients.  Typically, KeyPackages are used once and consumed. </ins> Additional services may or may not be required depending on the application design:
Code change:
WGLC comments on Operation Requirements section. Added several overlooked requirements
Discussed on 12/8 interim, and folks seemed fine with this. I.e., it's ready to merge.

Related discussion:
text: set of acceptable behavior in a group.  These policies must be consistent between deployments for them to interoperate: <ins> A policy on which ciphersuites are acceptable. A policy on any mandatory or forbidden MLS extensions. </ins> A policy on when to send proposals and commits in plaintext instead of encrypted.
Code change:
WGLC comments on Operation Requirements section. Added several overlooked requirements
Discussed on 12/8 interim, and folks seemed fine with this. I.e., it's ready to merge.

Related discussion:
text: When, and under what circumstances, a reinitialization proposal is allowed. <del> When proposals from external senders are allowed. </del> <ins> When proposals from external senders are allowed and how to authorize those proposals. When external joiners are allowed and how to authorize those external commits. Which other proposal types are allowed. A policy of when members should commit pending proposals in a group. </ins> <del> When external joiners are allowed. </del> <ins> A policy of how to protect and share the GroupInfo objects needed for external joins. </ins> A policy for when two credentials represent the same client.  Note that many credentials may be issued authenticating the same
Code change:
This PR adds a short paragraph referencing the various academic works that has gone into MLS. The references to the various works still need to be cleaned up, which I will do once the list is complete. In particular, each reference needs to be checked for correctness (eprint version vs. publicized version) and then included as informal reference in the yaml header of the document.
Is there another RFC you can point to that links academic papers on the protocol? I'd expect TLS 1.3 to be a good example of this, but I don't see them do this. The references should be cited properly if we do include it (ie, added as citations at the top of the file)
The references are in the appendices. For instance URL The reader should refer to the following references for analysis of the TLS handshake: [DFGS15], [CHSV16], [DFGS16], [KW16], [Kraw16], [FGSW16], [LXZFH16], [FG17], and [BBK17].
TLS 1.3 as cited by NAME was indeed the inspiration for this. The idea was to just have a small paragraph to point the reader in the right direction and then have the full bibliographic entry in the "Informal References" section. As noted above, I intend to properly format all the references once we agree on what references to include, as formatting them into the right yaml is a bit of a pain.
Thanks Konrad!

Related discussion:
text: setting, HSMs and secure enclaves can be used to protect signature keys. <ins> 6.6. Various academic works have analyzed MLS and the different security guarantees it aims to provide.  The security of large parts of the protocol has been analyzed by [BBN19] (draft 7), [ACDT21] (draft 11) and [AJM20] (draft 12). Individual components of various drafts of the MLS protocol have been analyzed in isolation and with differing adversarial models, for example, [BBR18], [ACDT19], [ACCKKMPPWY19], [AJM20] and [ACJM20] analyze the ratcheting tree as the sub-protocol of MLS that facilitates key agreement, while [BCK21] analyzes the key derivation paths in the ratchet tree and key schedule.  Finally, [CHK19] analyzes the authentication and cross-group healing guarantees provided by MLS. </ins> 7. <ins> ACDT19: https://eprint.iacr.org/2019/1189 ACCKKMPPWY19: https://eprint.iacr.org/2019/1489 ACJM20: https://eprint.iacr.org/2020/752 AJM20: https://eprint.iacr.org/2020/1327 ACDT21: https://eprint.iacr.org/2021/1083 AHKM21: https://eprint.iacr.org/2021/1456 CHK19: https://eprint.iacr.org/2021/137 BCK21: https://eprint.iacr.org/2021/137 BBR18: https://hal.inria.fr/hal-02425247 BBN19: https://hal.laas.fr/INRIA/hal-02425229 8. </ins> This document makes no requests of IANA.