jiebi/CodeConvo huggingface dataset:
Change:
or of their array elements or member values, respectively.  Applied to <del> other value types, it will select nothing. </del> <ins> primitive values, it will select nothing. </ins> The order in which the children of an object appear in the resultant nodelist is not stipulated, since JSON objects are unordered.

Discussion:
JSON types are not used much in the JSON spec. It is debatable whether there really is a boolean type or simply the values and . Also, the JSONPath spec doesn't really benefit from this term.
I think this reads well without breaking any semantics.
Change:
A push stream is indicated by a stream type of "0x01", followed by the Push ID of the promise that it fulfills, encoded as a variable- length integer.  The remaining data on this stream consists of HTTP/3 <del> frames, as defined in frames, and fulfills a promised server push. Server push and Push IDs are described in server-push. </del> <ins> frames, as defined in frames, and fulfills a promised server push by zero or more non-final HTTP responses followed by a single final HTTP response, as defined in request-response.  Server push and Push IDs are described in server-push. </ins> Only servers can push; if a server receives a client-initiated push stream, this MUST be treated as a connection error of type

Discussion:
Clarify HTTP message definition. Require the connection to be closed upon receipt of frames in incorrect order. Refer to HTTP messages in push stream section. This addresses URL
Good catch. I added a paragraph to explicitly allow unknown frames to the message exchange section. I also modified the wording in the push section to be more permissive of interleaved frames ("by" instead of "consists of").
LGTM
According to URL, a bidirectional HTTP stream can have at least one HEADERS frame (exactly one if the stream is client-initiated), zero or more DATA frames, then zero or one HEADERS frame, in this order. Handling the receipt of frames that does not conform to this requirement is inconsistent: (1) If a DATA frame is received before any other frame, that's an error: (2) If the trailing HEADERS frame is followed by another HEADERS frame, that is to be discarded: (3) There is no guidance on how to handle a DATA frame after the trailing headers. I suggest that every violation to this requirement should be an error. (I do not feel strongly whether a connection error like (1) is handled right now, or a stream error. The implementation I am contributing to will promote most stream errors to connection errors regardless.) Note that (2) comes from the technical limitation that header blocks needed to be processed, which is not the case any longer with QPACK. It just seems like that when the requirement to decode the header block was removed at URL, adding the requirement to signal an error was not in scope of that commit.
I agree with NAME . If you read that requirement a certain way, then any use of trailers will blow up the connection :) I think we could rewrite this text to be clearer about when DATA frames are expected to be received.
Good points. Let's continue tightening down the screws. :-)
Closed in .
This text was already somewhat lacking by not discussing the possibility of extension frames being interleaved; stating that the push stream consists of "responses" rather than "frames" extends this shortcoming to the push stream section. I'm open to fixing this in a separate PR, if you prefer, though.
Change:
present, but an "AS" value is specified, generate a "TIAS" value using this formula: <del> TIAS = AS * 1000 * 0.95 - 50 * 40 * 8 </del> <ins> TIAS = AS * 1000 * 0.95 - (50 * 40 * 8) </ins> The 50 is based on 50 packets per second, the 40 is based on an estimate of total header size, the 1000 changes the unit from

Discussion:
I object to shit sort of crap, if you are too short to do grade 3 math, you are too short to implement this spec.
Change:
either through timers or through least-recently-used eviction, depending on application requirements. <ins> RFC4787 recommends a 2 minute timeout interval for UDP, however, often timer are lower in the range of 15 to 30 second.  In constrast RFC5382 recommends a timeout of more than 2 hours for TCP, given TCP is a connection-oriented protocol with well defined closure semantics.  For network devices that are QUIC-aware, it is recommended to also use longer timeouts for QUIC traffic, as QUIC is connection-oriented and as such a handshake packet from the server indicates the willingness of the server to communicate with the client. </ins> The QUIC header optionally contains a Connection ID which can be used as additional entropy beyond the 5-tuple, if needed.  The QUIC handshake needs to be observed in order to understand whether the

Discussion:
But how long...?
For discussion: should the manageability draft advise that idle timeouts should be longer for flows inferred/detected to be QUIC flows? I think the answer here is "it depends": for NATs, yes, state at the edge is not all that scarce anymore. For firewalls? Maybe not so much. Are there other applications to consider here, and is there any generalized advice this document could give? If so, is there any generalized advice for how long the timeout should be?
PR is an attempt to address this issue but doesn't provide much concrete guidance...
Change:
DetNet service Label (S-label) that identifies a DetNet flow to the peer node that is to process it.  The S-Label is allocated <del> from the platform label space. </del> <ins> from the platform label space RFC3031. </ins> Zero or more MPLS transport LSP label(s) (T-label) used to direct the packet along the label switched path (LSP) to the next peer

Discussion:
I have started to address the comments as agreed on the call 2nd May. Before I do a more significant edit next week I want to test out the pull mechanism,
Merged Stewart's first three commits to the master.
I wonder why we need to have/propose two approaches for the aggregation?
Change:
Corresponds to the fragment of a given length. <del> The content type describing the payload. </del> <ins> The content type describing the cleartext payload. </ins> An arbitrary-length run of zero-valued bytes may appear in the cleartext after the type field.  This provides an opportunity for

Discussion:
Russ Housley's secdir review: URL Reviewer: Russ Housley Review result: Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-tls-dtls-connection-id-10 Reviewer: Russ Housley Review Date: 2021-03-15 IETF LC End Date: 2021-03-28 IESG Telechat date: Unknown Summary: Ready Major Concerns: None. Minor Concerns: None. Nits: Section 4: For increased clarity, I suggest: OLD: realtype The content type describing the payload. NEW: realtype The content type describing the cleartext payload.
Change:
The extension type is specified as follows. The extension_data field of this extension, when included in the <del> ClientHello, MUST contain the CID structure, which carries the CID which the client wishes the server to use when sending messages towards it.  A zero-length value indicates that the client is prepared to send with a connection ID but does not wish the server to use one when sending (alternately, this can be interpreted as the </del> <ins> ClientHello, MUST contain the ConnectionId structure, which carries the CID which the client wishes the server to use when sending messages towards it.  A zero-length value indicates that the client is prepared to send with a connection ID but does not wish the server to use one when sending (alternately, this can be interpreted as the </ins> client wishes the server to use a zero-length CID; the result is the same).

Discussion:
This is pretty trivial, but the first use of CID in the draft isn't mated to the expanded "connection ID". Probably more seriously, that first mention is actually to cite a struct: The structure is called .
Change:
a peer is persistently sending bad messages and terminate the local connection state after such misbehavior is detected. <del> 5.10. </del> <ins> 5.11. </ins> If a DTLS client-server pair is configured in such a way that repeated connections happen on the same host/port quartet, then it is

Discussion:
omit the trailing space because TLS 1.3 went right up to the limit.
No, no, DTLS also uses HKDR for Key Separation++
Hearing no objections, we're merging this change. I'll fix the HKDR->HKDF typo in a followup PR.
This is perfectly fine. Thanks for making the edit.
Change:
Typically, a (D)TLS server uses a certificate provided by some entity other than the operator of the server (a "Certification Authority" or <del> CA) RFC8446 ID.ietf-tls-dtls13 RFC5280.  This organizational separation makes the (D)TLS server operator dependent on the CA for some aspects of its operations, for example: </del> <ins> CA) RFC8446 RFC5280.  This organizational separation makes the (D)TLS server operator dependent on the CA for some aspects of its operations, for example: </ins> Whenever the server operator wants to deploy a new certificate, it has to interact with the CA.

Discussion:
Editorial changes from AD review.
Modulo adding the hyphen in between the I and the D (my bad) to make sure we get a normative reference to DTLS 1.3. This is good to go.
Change:
[CREF1] JLS: I have not gone through the document to determine what needs to be here yet.  We mostly want to grab terms that are used in unusual ways or are not generally understood. <ins> [CREF2] JLS: Is is the same registry for both OKP and EC2? </ins>

Discussion:
Deemed not used in enough locations - counter signatures suffer because of this but the group did not care.
Change:
feedback link is available, or File Delivery over Unidirectional Transport (FLUTE) RFC6726 otherwise.  Note that both NORM and FLUTE are limited to block coding, none of them supporting sliding window <del> encoding schemes RFC8406. </del> <ins> encoding schemes RFC8406.  Note that although FLUTE is defined as an unidirectional protocol, the RFC proposes a bidirectional communication method to enable full reliability transfer and for security purpose. </ins> 4.3.

Discussion:
Answer to issue
John Border: Section 4.2, 2nd Paragraph "Unidirectional" implies (to me) no ACKs. Without ACKs, FLUTE must do repair in such a way as to not need to know exactly what was lost. This seems different enough to me to be explained separate from NORM.
Our objective is not to discuss about NORM and FLUTE, which is out of scope of the document. We cite these protocols as possible usage example. Also note that although FLUTE is unidirectional, the RFC keeps a door open proposing bidirectional communications for security purpose and to enable full reliability transfer. As a result, we move this sentence at the end of this section as a complementary material and completed the FLUTE description.
Change:
The identifier itself. The status of this authorization.  Possible values are: "pending", <del> "valid", "invalid", "deactivated", and "revoked". </del> <ins> "valid", "invalid", "deactivated", "expired", and "revoked". </ins> The timestamp after which the server will consider this authorization invalid, encoded in the format specified in RFC 3339

Discussion:
1) Section 7.1.4 - Include "expires" in possible authz status values. 2) 7.1.2.1 - Fix orders link rel relation syntax Thanks to NAME for flagging these issues on-list.
Change:
2.3. The Delivery Service (DS) is expected to play multiple roles in the <del> Messaging Service architecture: </del> <ins> Service Provider architecture: </ins> To act as a directory service providing the initial keying material for clients to use.  This allows a client to establish a

Discussion:
This PR addresses URL
Thanks!
In the context of this document, the meaning of the term Messaging Service (MS) seems a little unclear to me. The document states that the protocol is intended to be embedded in a concrete protocol such as XMPP. However, is a MS meant to be a messaging service such as SMS or MMS? Or a service on the application layer, such as FB or WhatsApp? Essentially who provides / controls the AS and DS? I would be grateful for some clarification on this. Thanks.
It is meant to mean application layer, would changing that to "service provider" work better for you?
Thank you. I do think that the term service provider is less ambiguous.
Ack, will fix soon.
I can make a PR, if you want?
Sure, please go for it.
Fixed by
Change:
X.509 semantics are very rich.  This can cause unintended consequences if a service owner creates a proxy certificate where the properties differ from the leaf certificate.  For this reason, <del> delegated credentials have very restricted semantics which should </del> <ins> delegated credentials have very restricted semantics that should </ins> not conflict with X.509 semantics. Proxy certificates rely on the certificate path building process

Discussion:
No substantive changes, just grammatical nits and suggestions for clarifying the exposition. In the "Client Behavior" section (Section 3.1), I added a sentence explaining how to check the time-to-live to the first of the DC-validation steps. This might be helpful, as folks have been confused in the past about how to determine if a DC has expired.
LGTM
Change:
schemes constitute distinct namespaces and, in combination with the authority, are considered to be distinct origin servers. <del> 6.1. </del> <ins> 4.1.1. </ins> The semantics defined in RFC7252, Section 6.1, apply to this URI scheme, with the following changes:

Discussion:
This is an extremely rough merge of core-coap-tcp-tls and core-coap-websockets. The main intent was to get all the material into one draft with a potential outline and next perform an overall editorial pass.
With the merge of websockets-07, the scope of coap-tcp-tls is extended to include CoAP over WebSockets. The draft title should reflect that change in scope.
I probably would stay explicit (but then I'm biased -- RFC 3095 :-) CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets
WFM.
Neglected to close with
Change:
Orchestration. A single SAP network topology can be used for one of multiple service <del> types (e.g., L3VPN, EVPN).  The network controller can then expose the service type(s) and associated interfaces via the SAPs. </del> <ins> types (e.g., L3VPN, Ethernet VPN (EVPN)).  The network controller can then expose the service type(s) and associated interfaces via the SAPs. </ins> As shown in fi3a, the Service Orchestration layer will have also access to a set of Customer Service Model, e.g., an L3SM or L2SM data model in the customer-facing interface and a set of network models, <del> e.g., L3NM and Network topology data models in the resource-facing interface.  In this use case, it is assumed that the network </del> <ins> e.g., the L3NM and Network topology data models in the resource- facing interface.  In this use case, it is assumed that the network </ins> controller is unaware of what happens beyond the PEs towards the CEs; it is only responsible for the management and control of the network between PEs.

Discussion:
Check if we need to expose SAPs per servcie-type and if so, how we can easily add support for it OLD: NEW:
Change:
6.2. <del> Inputs: - "server_origin": The server origin to redeem a token for. - "target": The target endpoint to send the token to.  - "additional_data": Additional data to bind to this redemption request. </del> <ins> Inputs: - "context": The request context to use.  - "server_origin": The server origin to redeem a token for.  - "target": The target endpoint to send the token to.  - "additional_data": Additional data to bind to this redemption request. </ins> When a client wants to redeem tokens for a server, it should first fetch a key commitment from the server via the process described

Discussion:
Initial work for fixing .
NAME
As discussed during IETF 110, the architecture document should provide guidance on how redemption contexts can be used and how they impact privacy. This is a bit of the calculus we don't yet have. cc NAME NAME
Yeah, this likely needs to be embedded both into the Architecture draft for the generic concept of a context, and then an actual instantiation of redemption contexts in the HTTP API doc.
Yep should we split out the HTTP work into a separate issue?
Thanks NAME This looks good, I have mostly just a few nits to resolve.
Change:
Link/@type' in SWID. use (index 42): An integer or textual value (integer label with <del> text escape, see data-def, for the "Software ID Link Link Relationship Values" registry indexed-link-ownership) used to determine if the referenced software component has to be installed before installing the software component identified by the COSWID tag.  If an integer value is used it MUST be an index value in the range -256 to 255.  Integer values in the range -256 to -1 are reserved for testing and use in closed environments (see iana- private-use).  Integer values in the range 0 to 255 correspond to registered entries in the IANA "Link Use Values" registry (see iana-link-use).  If a string value is used it MUST be a private use name as defined in iana-private-use.  String values correspond to registered entries in the "Software ID Link Use Values" registry. </del> <ins> text escape, see data-def, for the "Software Tag Link Relationship Values" registry indexed-link-ownership) used to determine if the referenced software component has to be installed before installing the software component identified by the COSWID tag. If an integer value is used it MUST be an index value in the range -256 to 255.  Integer values in the range -256 to -1 are reserved for testing and use in closed environments (see iana-private-use). Integer values in the range 0 to 255 correspond to registered entries in the IANA "Link Use Values" registry (see iana-link-use. If a string value is used it MUST be a private use name as defined in iana-private-use.  String values correspond to registered entries in the "Software Tag Link Use Values" registry. </ins> $$link-extension: This CDDL socket can be used to extend the link- entry map model.  See model-extension.

Discussion:
Removed IANA registrations for swid and swidpath and updated text to note these are not technically URIs but just expressions using URI syntax.
Change:
WebTransport server MUST verify the "Origin" header to ensure that the specified origin is allowed to access the server in question. <del> A WebTransport session is established when the server sends a 200 </del> <ins> A WebTransport session is established when the server sends a 2xx </ins> response.  A server generates that response from the request header, not from the contents of the request.  To enable clients to resend data when attempting to re-establish a session that was rejected by a

Discussion:
The document currently mentions HTTP status code 200 explicitly, instead of following the usual convention of saying "any 2xx" status code. We already made this change in WebTransport over HTTP/3, we should do the same in this doc.
Ack, we're a bit mixed in the HTTP/2 document right now, will update so we're consistent everywhere.
Change:
the L3NM attribute (e.g., actual forwarding policies).  Some of the information captured in L3SM may be maintained locally within the Orchestrator; which is supposed to maintain a "glue" between a <del> Customer view and its network instantiation. </del> <ins> Customer view and its network instantiation.  Likewise, some of the information captured and exposed using L3NM can fed the service layer (e.g., capabilities) to derive L3SM and drive VPN service order handling. </ins> The L3NM module does not attempt to address all deployment cases especially those where the L3VPN connectivity is supported through

Discussion:
Allows a controller to expose the L3SM to which an L3NM is bound
OK! It is optional. Should work typically the other way around, allows the service orchestrator to maintain the match and facilitate reconciliation. NAME Please add some text in the draft to explain the parameter
Please see the change: Will add more text once we will work seriously on the tree structure part.
Change:
12. <del> We would like to thank Achim Kraus, Hanno Becker, Hanno Boeck, Manuel Pegourie-Gonnard, Mohit Sahni and Rich Salz for their input to this document. </del> <ins> We would like to thank Hanno Becker, , , Mohit Sahni and Rich Salz for their input to this document. </ins>

Discussion:
Signed-off-by: Thomas Fossati
Also, remove NAME who's now a co-author.
Change:
6. <ins> Data streams (see capsule-protocol) can be prioritized using any means suited to stream or request prioritization.  For example, Section 11 of PRIORITY. </ins> Prioritization of HTTP/3 datagrams is not defined in this document. Future extensions MAY define how to prioritize datagrams, and MAY define signaling to allow endpoints to communicate their

Discussion:
Most likely just need a sentence saying that the data stream is treated the same regardless if capsules are used or not.
Adding that sentence sounds fine by me.
Change:
technician operating the device, to avoid revealing this information to the MASA. <del> 9. </del> <ins> 10. </ins> <del> 9.1. </del> <ins> 10.1. </ins> Exhaustion attack on pledge based on DoS attack (connection establishment, etc.) <del> 9.2. </del> <ins> 10.2. </ins> Registrar-agent that uses acquired voucher and enrollment response for domain 1 in domain 2: can be detected in Voucher Request

Discussion:
Do we augment 8995? Do we augment 8366? Do we need to do both? What does it mean to augment something that augments something?
Hi, I'm working on that pull request right now. . I don't know how to manage YANG stuff in a bare MT / XML Makefile. We extend 8995 for the voucher-request. There are some practical YANG practices that I'm missing.
I enhanced the voucher-request with two additional leafs for the agent-sign-cert and the agent-provided-proximity-certificate.
YANG module for the extension of the voucher request will be put into the next update of the draft. The will need more investigation by the YANG doctor.
I guess this is fine as far as it goes, but I will admit to being nervous about augmenting a voucher-request (because it in itself is a voucher), but beyond that we also have to add a new assertion enumeration.
Change:
send multiple GOAWAY frames indicating different identifiers, but MUST NOT increase the identifier value they send, since clients might already have retried unprocessed requests on another connection. <ins> Receiving a GOAWAY containing a larger identifier than previously received MUST be treated as a connection error of type H3_ID_ERROR. </ins> An endpoint that is attempting to gracefully shut down a connection can send a GOAWAY frame with a value set to the maximum possible

Discussion:
Draft 27 says: Maybe I'm missing it but I can't see where we say how the GoAway receiver handles an seeing the GoAway ID getting increased. We typically state what the receiver should do in such a case. For instance, with MAXPUSHID we say " receipt of a MAXPUSHID that contains a smaller value than previously received MUST be treated as a connection error of type H3IDERROR.". I suggest that we need text that states receiving a larger GOAWAY ID than previously received MUST be treated as a connection error of type H3IDERROR. N.B. since draft-27 we landed changes to make the GOAWAY symmetrical. I believe this issue is still applicable to the most recent editors draft
H3IDERROR SGTM