jiebi/CodeConvo huggingface dataset:
Change:
result, the receiver of a conceptual message containing a timestamp can directly compare it to its own clock and timestamps. <del> In the figures above and in subsequent sections, curly braces indicate containment.  For example, the notation Evidence{foo} indicates that 'foo' is contained in the Evidence and is thus covered by its signature. </del> The Verifier can check whether the Evidence is fresh when appraising it at time(RG_v) by checking "time(RG_v) - time(EG_a) < Threshold", where the Verifier's threshold is large enough to account for the

Discussion:
Maybe move this paragraph to the super-section? Maybe this is intentional due to the proximity to a syntax example? Yet, the suffix syntax style is not placed here, correspondingly.
Change:
querying the described device's /.well-known/core resource directly. Data in the RD can only be provided by the device which hosts those <del> data or a dedicated Commissioning Tool (CT).  These CTs are thought to act on behalf of endpoints too constrained, or generally unable, to present that information themselves.  No other client can modify data in the RD.  Changes to the information in the RD do not propagate automatically back to the web servers from where the information originated. </del> <ins> data or a dedicated Commissioning Tool (CT).  These CTs act on behalf of endpoints too constrained, or generally unable, to present that information themselves.  No other client can modify data in the RD. Changes to the information in the RD do not propagate automatically back to the web servers from where the information originated. </ins> 3.2.

Discussion:
See-Also: URL Thank you -- I found this document to be a very friendly read. The Terminology section in particular was one of the best in recent memory. Comments: 1: "These CTs arethought to act on behalf of endpoints too constrained, or generally unable, to present that information themselves. " This reads very oddly - "thought to act on" sounds like we've seen some of these in the wild, and only have a vague idea about how they work. Does "These CTs act on behalf of endpoints too constrained, or generally unable, to present that information themselves. " work? 2: "From the system design point of view, the ambition is to design horizontal solutions that  can enable utilization of machines in different applications depending on their current availability and capabilities as well as application requirements, thus avoiding silo like solutions" - this is very buzzwordy, and I have no idea what it is actually trying to say... 3: "  A (re-)starting device may want to find one or more RDs for discovery purposes." Either I don't understand what this sentence is  trying to say, or "for discovery purposes" should be dropped....  4: "As some of the RD addresses obtained by the methods listed here are just (more or less educated) guesses, endpoints MUST make use of any error messages to very strictly rate-limit requests to candidate IP addresses that don't work out. " What happens if device A discovers RD X, and device B discovers RD Y? Surely there has to be some sort of deterministic method so that one doesn't end up in a "split brain" type outcome? Nits: 1: " The input to an RD is composed of links and the output is composed of links constructed from the information stored in the RD." While  true, this sentence doesn't actually communicate anything useful to the reader -- I'd suggest removing it from the Abstract (note that this is just a nit). 2: "The RD is primarily a tool to make discovery operations more efficient than querying /.well-known/core on all connected devices, or across boundaries that would be limiting those operations." s/would be limiting those/that would limit those/
Change:
The server's preferred address is used to effect a change in server address at the end of the handshake, as described in preferred-address.  The format of this transport parameter is the <del> PreferredAddress struct shown in fig-preffered-address.  This transport parameter is only sent by a server. </del> <ins> PreferredAddress struct shown in fig-preferred-address.  This transport parameter is only sent by a server.  Servers MAY choose to only send a preferred address of one address family by sending an all-zero address and port (0.0.0.0:0 or ::.0) for the other family. </ins> If present, transport parameters that set initial flow control limits (initial_max_stream_data_bidi_local,

Discussion:
This change allows servers to send a preferred address of each address family. The previous definition of preferred_address only allowed sending one address family, and this had the disadvantage of picking the non-deterministic address family used by the Initial if the client is performing Happy Eyeballs. Clients may now use the best address family based on their network attachment.
NAME I went with this approach to minimize changes from the current design. Having a list that allows different ports and future versions of IP are fine by me, but there seemed to be more pushback when that was proposed in . As long as we have a way of communicating one IPv4 address and one IPv6 address I'm happy.
We could allow multiple PreferredAddress TPs and avoid the zero-length address problem.
NAME Thank you for the clarification. I think I'm fine with that. NAME The PreferredAddress structure includes Connection ID and Stateless Reset Token. I think we should avoid requiring the server to send them twice when it is constrained by the 3-packet rule.
I've simplified the wire-format using NAME suggestion with separate port numbers
NAME I think migration and preferred address are separate parts of the protocol. The goal of this PR is to improve preferred address. It allows the client to pick the address family it transfers to right after the handshake. If the server only provides you with a preferred address family you don't have access to, you can simply ignore it - and that's not new from this PR. I've slightly tweaked the text to clarify how clients respond to preferred_address. Does this address your concerns?
I'm good with this PR. NAME -- can you see if your concern is addressed?
NAME is there anything left for me to do so this can get merged in?
You could wait until I had time to check it, that's all.
After reading my text, I am not entirely happy with it, but I lack a better suggestion.Still LG
Change:
If the media section proto value indicates use of RTP: If there is no RtpTransceiver associated with this m= section <del> (which should only happen when applying an offer), find one and </del> <ins> (which will only happen when applying an offer), find one and </ins> associate it with this m= section according to the following steps: <del> Find the RtpTransceiver that corresponds to the m= section with the same MID in the created offer. </del> <ins> Find the RtpTransceiver that corresponds to this m= section, using the mapping between transceivers and m= section indices established when creating the offer. </ins> <del> Set the value of the RtpTransceiver's mid property to the </del> <ins> Set the value of this RtpTransceiver's mid property to the </ins> MID of the m= section. If RTCP mux is indicated, prepare to demux RTP and RTCP from

Discussion:
Also describing explicitly what it means for an RtpTransceiver to be "associated" with an m= section. Namely, that it has a mid attribute that matches the MID of that m= section. Addresses issue .
There probably are better ways of wording this, I'm open to suggestions.
Ekr pointed out that this doesn't handle situations where "a=mid" is not used. So I added text describing a transceiver->m= section index mapping.
I think I've addressed all of ekr and juberti's comments; ready for another review.
LGTM
Change:
if the request was protected with a security protocol, such as DTLS. This makes CoAP requests vulnerable to certain delay attacks which are particularly perilous in the case of actuators (I-D.mattsson- <del> core-coap-actuators).  Some attacks can be mitigated by establishing </del> <ins> core-coap-attacks).  Some attacks can be mitigated by establishing </ins> fresh session keys, e.g. performing a DTLS handshake for each request, but in general this is not a solution suitable for constrained environments, for example, due to increased message

Discussion:
We've mentioned outdated draft names at times. Details in individual commits, point-to-point updated in-PR too. The DTLS change is not so much an update but a not to the editor that they may update the reference at their discretion when the publication sequence is clear; I don't want to pull another normative dependency into our cluster because we don't normatively need anything from 1.3.
Change:
1.3 the key schedule is described in Section 7.1 of RFC8446. When EAP-TLS is used with TLS version 1.3 or higher the Key_Material, <del> IV, and Method-Id SHALL be derived from the exporter_master_secret using the TLS exporter interface RFC5705 (for TLS 1.3 this is defined in Section 7.5 of RFC8446). </del> <ins> IV, and Method-Id SHALL be derived from the exporter_secret using the TLS exporter interface RFC5705 (for TLS 1.3 this is defined in Section 7.5 of RFC8446). </ins> A zero-length context (indicated by "") is used in the TLS exporter interface.  The EAP-TLS Type-Code of '0D' (in hexadecimal) is

Discussion:
TLS WG has decided to change terminology in TLS 1.2 and TLS 1.3. The draft is already WG adopted. I suggest we make this change in EAP-TLS 1.3 as well.
Looks good to me
Change:
PRK_exporter is derived from PRK_out: where hash_length denotes the output size in bytes of the EDHOC hash <del> algorithm of the selected cipher suite.  Note that PRK_exporter changes every time EDHOC-KeyUpdate is used, see keyupdate. </del> <ins> algorithm of the selected cipher suite. </ins> The (exporter_label, context) pair used in EDHOC-Exporter must be unique, i.e., an (exporter_label, context) MUST NOT be used for two

Discussion:
Replacing a session key with its hash for forward secrecy as specified with EDHOC-KeyUpdate, can alternatively be defined by the application as is done in KUDOS (draft-core-oscore-key-update). For this reason there is no need to recommend EDHOC-KeyUpdate as is done in Section 7. "Implementations SHOULD support EDHOC-KeyUpdate." EDHOC-KeyUpdate can useful in other applications but the description should be moved out of the body in the interest of focusing on the core functionality of EDHOC.
Discussed in the interim and PR merged.
Change:
across multiple streams.  When a packet loss occurs, only streams with data in that packet are blocked waiting for a retransmission to be received, while other streams can continue making progress.  Note <del> that when data from multiple streams is bundled into a single QUIC </del> <ins> that when data from multiple streams is included in a single QUIC </ins> packet, loss of that packet blocks all those streams from making <del> progress.  Implementations are advised to bundle as few streams as </del> <ins> progress.  Implementations are advised to include as few streams as </ins> necessary in outgoing packets without losing transmission efficiency to underfilled packets.

Discussion:
We didn't really need to use a new "term" for the concept of including multiple frames in a packet. The use of "bundle" implied more than what was really happening. Using plain words is probably better.
What does “bundling” refer to? I think I might now understand coalescing, but I don’t understand if bundling is subtly different?
Several instances I see in the draft refer to the situation where an endpoint is required to send a packet containing certain frames. The endpoint might opportunistically add other frames, not mandated to be sent, as long as it's doing the work of generating and sending a packet anyway. These opportunistically added frames are "bundled" with the mandatory frames. More generally, the term refers to selecting a collection of frames waiting to be sent when generating an outgoing packet.
(Versus coalescing, which is putting more than one packet in a single UDP datagram.)
tbh, I think the text reads a lot better with bundling.Thanks! Clearer is better.
Change:
The DTLS 1.3 protocol is intentionally based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security <del> guarantees.  Datagram semantics of the underlying transport are preserved by the DTLS protocol. </del> <ins> guarantees with the exception of order protection/non-replayability. Datagram semantics of the underlying transport are preserved by the DTLS protocol. </ins> 1.

Discussion:
Suggested pull request related to issue
The Abstract states that: "The DTLS 1.3 protocol is intentionally based on the Transport Layer Security (TLS) 1.3 protocol and provides equivalent security guarantees." This is not true when it comes to Order protection/non-replayability which is states as a guarantee in Appendix E.2 of RFC 8446. DTLS does not provide order protection and may not provide replay protection. I suggested this statement "equivalent security guarantees" is deleted (or rewritten) in the abstract and that some short text describing this is added to the Security Considerations.
Fixed.
Change:
changes from -13 to -14 <ins> Introduced resource types core.rd-ep and core.rd-gp </ins> Registration management moved to appendix A Minor editorial changes

Discussion:
Populates missing descriptions in the IANA template for resource types, but primarily adds new resource types (URL and URL) to the lookup results.
(This was quickly but a bit vaguely agreed on in the last meeting; will merge if nobody objects.)
This was discussed in the last meeting but did not result in an action item; will check whether we agreed to do this (AFAIR we did) and add the text for it.
The right place is in the management example. I hesitated but did not do it chrysn schreef op 2018-06-27 11:51: Links: [1] URL [2] URL
Done with in 801a4352587f4354d57949ab7cb427600a139158.
Change:
3.1.6. <del> The "ClientIssuanceMessage" struct corresponds to the message that </del> <ins> The "ClientIssuanceRequest" struct corresponds to the message that </ins> the client sends to the server during the issuance phase of the protocol (issuance-phase).

Discussion:
Rename IssuanceMessage and RedemptionMessage to IssuanceRequest and RedemptionRequest, respectively. Rename SecretKey to PrivateKey. Change to an integer value, rather than opaque vector. I also removed company-specific information, which is not really relevant for the document. (That's useful information, but not appropriate for a standards document, I think.) cc NAME NAME
Change:
RFC3264, Section 6., and further processing for this m= section can be skipped. <del> Provided that is not the case, each m= section in the answer should then be generated as specified in RFC3264, Section 6.1.  For the m= line itself, the following rules must be followed: </del> <ins> Otherwise, each m= section in the answer should then be generated as specified in RFC3264, Section 6.1.  For the m= line itself, the following rules must be followed: </ins> The port value would normally be set to the port of the default ICE candidate for this m= section, but given that no candidates

Discussion:
LG modulo comment
LGTM
Split from URL Something for the "Setting a remote description section"
(For clarity, the proper outcome is for the answerer to reject the m= line in the offer with no matching codecs, as discussed in IETF 95)
NAME asked about how the sendonly case should be handled. The minutes say but I'm not sure if we need to add any text for this. Peter, do you recall the details here?
Change:
is required, e.g., when local authentication is requested by a remote. <del> Like transport parameters, security parameters are inherited during cloning (see groups). </del> 6. Before a Connection can be used for data transfer, it must be

Discussion:
Make sure all the examples in the API and interface drafts use constants agnostic to argument type and syntax. From Dave Thaler: On 2 May 2018, at 03:07, Dave Thaler wrote:
will fix this when it lands
Addressed by .
Security properties should be synchronized with (the next rev of) URL
Addressed by .
lgtm
Change:
serving.  An isolated LoWPAN also contains a 6LBR in the network, which provides the prefix(es) for the isolated network." <del> Flag Day: A transition that involves having a network with different values of RPI Option Type.  Thus the network does not work correctly (Lack of interoperation). </del> <ins> Flag Day: In this document, refers to a transition that involves having a network with different values of RPI Option Type. </ins> Non-Storing Mode (Non-SM): RPL mode of operation in which the RPL- aware-nodes send information to the root about their parents.  Thus,

Discussion:
This covers the text from the beginning up to Section 7.2.1. These were reviewed with Pascal on March 26th. I will continue my review from Section 7.2.2 forward. More trivial editorial suggestions to follow, as well.
Many thanks for these fixs.
Change:
structure, where "lp" and "np[i]" represent the leaf_priv and node_priv values generated as described above: <del> After performing these operations, the generator of the UpdatePath MUST delete the leaf_secret. </del> 8.3. In addition to the path-based updates to the tree described above, it

Discussion:
Changes (apart from editorial): Remove the text about the key schedule. Reason: I found the text confusing, because updating paths provides FS and PCS for the HPKE keys in the ratchet tree, and not directly for the key schedule. Generate the leaf key pair simply as a fresh HPKE key pair, and not from the leafsecret. I couldn't see any benefit of using the leafsecret. I wonder if there is a good reason?
I am concerned that we are asking for a LOT of fresh entropy if (in addition to nonces) we need a crypto-random value every epoch for every group (a Wire client can easily a member of thousands of groups at a time). Do you have a concern about deriving it?
Discussion on the virtual interim: To NAME concern: This allows the base path secret to be derived, e.g., using a KDF, so this doesn't necessarily increase the amount of entropy needed Clear to merge
Change:
by the other peer, i.e., the TCP passive opener, TLS server, or WebSocket server. <del> For simplicity, a Payload Marker (0xFF) is shown in all examples for message formats: The Payload Marker indicates the start of the optional payload and is absent for zero-length payloads (see Section 3 of RFC7252). </del> 3. The request/response interaction model of CoAP over TCP is the same

Discussion:
Changes since -09 (Brian's earlier ones included): URL
Yes, that happens to me as well. Keeps you awake :-) We have 14 more issues to go before a full reread is indicated...
The box notation in Figures 4, 5, 7, 8 does not make very transparent that this is all the same format. Maybe we can cut this down to a single figure of the form: This would also allow to pull down the remark at the end of section 2 to that single figure.
CoAP (RFC 7252) / This Document is too wide when indented as much as it is.
I propose that the speculation about what we'll do when we need something the reasons for which we don't even know yet can be removed.
»Messages may be in flight when the sender decides to send a Release message. The general expectation is that these will still be processed.« EKR notes that this is not clearly describing this case: The intention is that a Release actually does allow the other side to process outstanding requests, so in the above example the server would actually send “Response A” before closing.
+1 for consolidating the message format figures. One small, long-standing usability nit: Whenever I want to look at the message format, I scroll through the document until I see the first figure with a message format. Every time it takes me a few seconds to realize that this figure shows the existing RFC 7252 format, not the new message format that I'm looking for. Otherwise, this looks good to me. (I only read the diff. Let me know when I should read the whole document.)
Change:
This specification makes use of the following additional terminology: <ins> An ICE session consists of all ICE-related actions starting with the candidate gathering, followed by the interactions (candidate exchange, connectivity checks, nominations and keep-alives) between the ICE agents until all the candidates are released or ICE-restart is triggered. </ins> An agent is the protocol implementation involved in the ICE candidate exchange.  There are two agents involved in a typical candidate exchange.

Discussion:
Not sure this is correct. ICE session is something that continues until ufrag/passwords change. The same candidates can be re-used across multiple ICE sessions.
I think better definition will be: An ICE session consists of all ICE-related actions starting with the candidate gathering, followed by the interactions (candidate exchange, connectivity checks, nominations and keep-alives) between the ICE agents until all the candidates are released or ICE-restart is initiated by ufrag/password change.
Roman's suggestion looks good.
I think the current proposed explanation (one with more details) is good. Would suggest merging this.
My suggestion is to merge, submit a new version, and then continue working on Peter's issues.
Why not just say an ICE session is all ICE activity tied to a candidate exchange with a specific ufrag/pwd? Every time you do a candidate exchange with a new ufrag/pwd, you have a new ICE session. I don't think we need to say all the rest.
Change:
over the open Internet. The procedures for requesting values in the Specification Required <del> space are specified in I-D.ietf-tls-iana-registry-updates. </del> <ins> space are specified in RFC8447. </ins>

Discussion:
When running idnits, it reports a couple of issues: RFC1950 and RfC7932 are the zlib and brotli RFCs. I'm guessing the way to fix this would to remove the related MUSTs and downgrade the references, though I haven't come up with appropriate wording yet. /cc NAME (any suggestion?)
fixes a couple more errors that are not listed here btw.
Note that downref "nits" can be handled via documented procedures in . In summary, we can identify them in the IETF LC (when we get there) and see who objects to referring to an informative RFC from this draft, which is intended for standards track. For zlib there are a ton of these already and it looks like somebody just didn't update the downref registry (i.e., I suspect there will be no strenuous objections from anybody). For brotli, it's newer but I am not too worried about the uproar. I'd just leave the MUST and the normative references in.
Ok, thanks NAME I'll close this then.
Change:
same SCTP assocation, and shutdown proceeds as described under "Close". <ins> CloseGroup: Calling "CloseGroup" calls CLOSE.SCTP, closing all Connections in the SCTP association. AbortGroup: Calling "AbortGroup" calls ABORT.SCTP, immediately closing all Connections in the SCTP association. </ins> 11. RFC-EDITOR: Please remove this section before publication.

Discussion:
So, for a multiplexing protocol (SCTP, QUIC), CloseGroup and AbortGroup has a specific meaning to treat the group vs a single connection/stream. For TCP/UDP I wrote it to be a no-op, but I can say that it affects any other connections that were cloned out? But I wonder if that might be a little weird too.
I think we need the system to treat it that way for consistency. Clearly, for a mux'ing protocol this is the obvious choice - but the application is not aware of the protocol below... so if it creates a group of TCP connections, with or without congestion control coupling, it will expect: that changing a connection property on one of the connections will affect the others (so that also must be implemented - because it WILL happen with a mux'ing protocol), that closing the group will close them all. Imagine an application getting QUIC once, and not getting it another time... surely we need a consistent behavior towards the app for both of these cases?
NAME sounds good, please check the updated text (or suggest text if you have further ideas!)
This is probably fine as is, but I suggested alternative phrasing which might be even more clear.Great, thanks!!LGTM with the updates, thanks!