jiebi/CodeConvo huggingface dataset:
Code change:
and its links. <del> Commissioning Tool (CT) is a device that assists during the installation of the network by assigning values to parameters, naming endpoints and groups, or adapting the installation to the needs of the applications. </del> <ins> Commissioning Tool (CT) is a device that assists during installation events by assigning values to parameters, naming endpoints and groups, or adapting the installation to the needs of the applications. </ins> Registrant-ep is the endpoint that is registered into the RD.  The

Related discussion:
text: (Think new home construction in a new suburb) The RD lifetimes could be finite, but a few years in duration. The home owner, upon getting the keys (physically and cryptographically), would of course, rekey the entire house, and now there would be a management system to update RD lifetimes. Thread has a CT. I have no idea how it works, but perhaps NAME could comment. Zigbee CHIP project is doing something, but it's all NDA for now. I think that, when the time runs out, if there is nothing else to manage the system, then it should fail. I think that's okay. I think that the timeouts won't be minutes, but months... yes, there are issues. I don't think that the RD document needs to cover them though. {Feel free to invite me to collaborate on a script for the sequel to Sneakers/Leverage/MissionImpossible/EnemyOfTheState. I suggest it star Tom Greene rather than WillSmith or TomCruise.}
I think that there is probably a followup document that provides a way to backup/restore RD host data. OPC UA told me that they have created a spec for device independent backup/restore of configuration data in the case of device failure, but I don't have the details yet.
This might fit into -- any exchange format between the RDs could also be re-used for persistence. (With the caveat that the receiving server would need to inhabit the same address as the original server, or otherwise it could not service registration updates.)
Well, could it be an anycast address so that the RD could be highly available?
I don't see this as a viable design for a deployment. A change of system/address/network in the backend should never require the CT to come in and redo commissioning operations on IoT devices. Feeding the 'new RD' with stored information from a database is what would be most useful here. This database could be all those entries of devices that the CT had scanned initially, not necessarily the full RD state. Or alternatively all RD entries with lifetime e.g. > 48 hours could be restored; other devices need to re-register. Those entries that were registered with the CT could have a 10-year lifetime for example.
HI all, There are many installation firms, all with their own procedures and tools.
Code change:
and its links. <del> Commissioning Tool (CT) is a device that assists during the installation of the network by assigning values to parameters, naming endpoints and groups, or adapting the installation to the needs of the applications. </del> <ins> Commissioning Tool (CT) is a device that assists during installation events by assigning values to parameters, naming endpoints and groups, or adapting the installation to the needs of the applications. </ins> Registrant-ep is the endpoint that is registered into the RD.  The

Related discussion:
text: It is possible that an installation company deploys a CT during installation and takes it home afterwards. The contract might stipulate that he leaves behind a program to restart, update or refresh the network. It might be that an another company does the maintenance with another set of tools. Concerning duration, we may talk about years of operation without interruption. On other sites weekly upgrades may be necessary. At the end of the day, There are no general rules that may fix the CT behavior. I am afraid this does not help a lot and emphasizes that the CT example is just a likely example. Cheerio, Peter Esko Dijk schreef op 2020-10-21 09:02: Links: [1] URL [2] URL Thanks for addressing my DISCUSS and COMMENT feedback
Code change:
use the "a=imageattr" SDP attribute RFC6236 to indicate what video frame sizes it is capable of receiving.  A receiver may have hard limits on what its video decoder can process, or it may have some <del> maximum set by policy. </del> <ins> maximum set by policy.  By specifying these limits in an "a=imageattr" attribute, JSEP endpoints can attempt to ensure that the remote sender transmits video at an acceptable resolution. However, when communicating with a non-JSEP endpoint that does not understand this attribute, any signaled limits may be exceeded, and the JSEP implementation MUST handle this gracefully, e.g., by discarding the video. </ins> Note that certain codecs support transmission of samples with aspect ratios other than 1.0 (i.e., non-square pixels).  JSEP

Related discussion:
text: Section 3.6.2 would ideally include a disclaimer, like we have for many other features, indicating that -- despite normative statements in this section -- the remote side might not honor imageattr because of legacy behavior, and that implementations MUST be prepared to handle such situations.
Sure. This should probably go into 3.6 or 3.6.1, since those govern sent imageattr attribs.
LGTM
Code change:
be quite large.  If all the messages in a large flight are sent at once, this can result in network congestion.  A better strategy is to send out only part of the flight, sending more when messages are <del> acknowledged.  DTLS offers a number of mechanisms for minimizing the size of the certificate message, including the cached information extension RFC7924 and certificate compression RFC8879. </del> <ins> acknowledged.  Several extensions have been standardized to reduce the size of the certificate message, for example the cached information extension RFC7924, certificate compression RFC8879 and RFC6066, which defines the "client_certificate_url" extension allowing DTLS clients to send a sequence of Uniform Resource Locators (URLs) instead of the client certificate. </ins> 5.8.4.

Related discussion:
text: This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC EMAIL if you reply to or forward this review. TSV-ART Review of draft-ietf-tls-dtls13-41 Reviewer: Bernard Aboba Summary: The timeout and retransmission scheme looks workable for common cases, but could use some refinement to make it more robust. Technical Comments Handling Invalid Records Unlike TLS, DTLS is resilient in the face of invalid records (e.g., invalid formatting, length, MAC, etc.). In general, invalid records SHOULD be silently discarded, thus preserving the association; however, an error MAY be logged for diagnostic purposes. [BA] How does silent discard of invalid records interact with retransmission timers? Implementations which choose to generate an alert instead, MUST generate error alerts to avoid attacks where the attacker repeatedly probes the implementation to see how it responds to various types of error. Note that if DTLS is run over UDP, then any implementation which does this will be extremely susceptible to denial-of-service (DoS) attacks because UDP forgery is so easy. Thus, this practice is NOT RECOMMENDED for such transports, both to increase the reliability of DTLS service and to avoid the risk of spoofing attacks sending traffic to unrelated third parties. [BA] "this practice" refers to "generate an alert instead", correct? Timer Values Though timer values are the choice of the implementation, mishandling of the timer can lead to serious congestion problems, for example if [BA] Saying "timer values are the choice of the implementation" seems odd, because it is followed by normative language. I would delete this and start the sentence with "Mishandling...". many instances of a DTLS time out early and retransmit too quickly on a congested link.
Code change:
be quite large.  If all the messages in a large flight are sent at once, this can result in network congestion.  A better strategy is to send out only part of the flight, sending more when messages are <del> acknowledged.  DTLS offers a number of mechanisms for minimizing the size of the certificate message, including the cached information extension RFC7924 and certificate compression RFC8879. </del> <ins> acknowledged.  Several extensions have been standardized to reduce the size of the certificate message, for example the cached information extension RFC7924, certificate compression RFC8879 and RFC6066, which defines the "client_certificate_url" extension allowing DTLS clients to send a sequence of Uniform Resource Locators (URLs) instead of the client certificate. </ins> 5.8.4.

Related discussion:
text: Implementations SHOULD use an initial timer value of 100 msec (the minimum defined in RFC 6298 [RFC6298]) and double the value at each retransmission, up to no less than 60 seconds (the RFC 6298 maximum). Application specific profiles, such as those used for the Internet of Things environment, may recommend longer timer values. Note that a 100 msec timer is recommended rather than the 3-second RFC 6298 default in order to improve latency for time- sensitive applications. Because DTLS only uses retransmission for handshake and not dataflow, the effect on congestion should be minimal. Implementations SHOULD retain the current timer value until a message is transmitted and acknowledged without having to be retransmitted, at which time the value may be reset to the initial value. [BA] Is it always possible to distinguish a retransmission from a late arrival of an original packet? This seems like it could result in wrongly resetting the timer in some situations. Large Flight Sizes DTLS does not have any built-in congestion control or rate control; in general this is not an issue because messages tend to be small. However, in principle, some messages - especially Certificate - can be quite large. If all the messages in a large flight are sent at once, this can result in network congestion. A better strategy is to send out only part of the flight, sending more when messages are acknowledged. DTLS offers a number of mechanisms for minimizing the size of the certificate message, including the cached information extension [RFC7924] and certificate compression [RFC8879]. [BA] How does the implementation know how much of the flight to send? Not sure how prevalent large certs are for DTLS (e.g. compared with the self-signed certs of WebRTC), but in EAP-TLS deployments, large certs have caused problems. The EAP-TLS cert document draft-ietf-emu-eaptlscert cites some additional mechanisms for reducing certificate sizes, such as draft-ietf-tls-ctls and [RFC6066] which defines the "clientcertificateurl" extension which allows TLS clients to send a sequence of Uniform Resource Locators (URLs) instead of the client certificate. Alert Messages Note that Alert messages are not retransmitted at all, even when they occur in the context of a handshake.
Code change:
be quite large.  If all the messages in a large flight are sent at once, this can result in network congestion.  A better strategy is to send out only part of the flight, sending more when messages are <del> acknowledged.  DTLS offers a number of mechanisms for minimizing the size of the certificate message, including the cached information extension RFC7924 and certificate compression RFC8879. </del> <ins> acknowledged.  Several extensions have been standardized to reduce the size of the certificate message, for example the cached information extension RFC7924, certificate compression RFC8879 and RFC6066, which defines the "client_certificate_url" extension allowing DTLS clients to send a sequence of Uniform Resource Locators (URLs) instead of the client certificate. </ins> 5.8.4.

Related discussion:
text: However, a DTLS implementation which would ordinarily issue an alert SHOULD generate a new alert message if the offending record is received again (e.g., as a retransmitted handshake message). Implementations SHOULD detect when a peer is persistently sending bad messages and terminate the local connection state after such misbehavior is detected. Note that alerts are not reliably transmitted; implementation SHOULD NOT depend on receiving alerts in order to signal errors or connection closure. [BA] For the fatal alert case, it does seem like retransmission would be a good idea; otherwise the peer can be left hanging. Section 7.1 "Disruptions" such as reordering do not affect timers, correct? ACKs SHOULD NOT be sent for these flights unless generating the responding flight takes significant time. What is "significant time"? Editorial Comments (NITs) Section 2 The reader is also as to be familiar with [BA] "as" -> "assumed" Section 3 The basic design philosophy of DTLS is to construct "TLS over datagram transport". Datagram transport does not require nor provide reliable or in-order delivery of data. The DTLS protocol preserves this property for application data. Applications such as media streaming, Internet telephony, and online gaming use datagram transport for communication due to the delay-sensitive nature of transported data. The behavior of such applications is unchanged when the DTLS protocol is used to secure communication, since the DTLS protocol does not compensate for lost or reordered data traffic. [BA] While low-latency streaming and gaming does use DTLS to protect data (e.g. for protection of WebRTC data channel), telephony and RTC Audio/Video uses DTLS/SRTP for key derivation only, and SRTP for protection of data. So you might want to make a distinction. Section 3.1 Note that timeout and retransmission do not apply to the HelloRetryRequest since this would require creating state on the server. The HelloRetryRequest is designed to be small enough that it will not itself be fragmented, thus avoiding concerns about interleaving multiple HelloRetryRequests. [BA] I would add "For more detail on timeouts and retransmission, see Section 5.8." Transport Layer Mapping DTLS messages MAY be fragmented into multiple DTLS records. Each DTLS record MUST fit within a single datagram.
Code change:
be quite large.  If all the messages in a large flight are sent at once, this can result in network congestion.  A better strategy is to send out only part of the flight, sending more when messages are <del> acknowledged.  DTLS offers a number of mechanisms for minimizing the size of the certificate message, including the cached information extension RFC7924 and certificate compression RFC8879. </del> <ins> acknowledged.  Several extensions have been standardized to reduce the size of the certificate message, for example the cached information extension RFC7924, certificate compression RFC8879 and RFC6066, which defines the "client_certificate_url" extension allowing DTLS clients to send a sequence of Uniform Resource Locators (URLs) instead of the client certificate. </ins> 5.8.4.

Related discussion:
text: [BA] Do you mean "maximum retransmission timemout value"?
Addressed in
Code change:
usercode and the AS supports this mode for the client instance's request, the AS responds with a "user_code" field.  This field is string containing a unique short code that the user can type into a <del> web page.  This string MUST be case-insensitive, MUST consist of only easily typeable characters (such as letters or numbers).  The time in which this code will be accepted SHOULD be short lived, such as several minutes.  It is RECOMMENDED that this code be no more than </del> <ins> web page.  To facilitate usability, this string MUST be case- insensitive, MUST consist of only easily typeable characters (such as letters or numbers).  The string MUST be randomly generated so as to be unguessable by an attacker within the time it is accepted.  The time in which this code will be accepted SHOULD be short lived, such as several minutes.  It is RECOMMENDED that this code be no more than </ins> eight characters in length. The client instance MUST communicate the "user_code" value to the end

Related discussion:
text: clarify that user codes are unguessable, - update user code examples,
To edit notification comments on pull requests, go to your .
This is very minor, but there's a contradiction between the usercode provided in the example in section 3.3.3. and the recommendations that are mentioned in the text above it. The text says: And However, the example provided below it goes against these two recommendations, as it contains a special character (a hyphen) rather than just letters and numbers, and it's longer than eight characters in length: I'd suggest either tweaking the wording, or tweaking the example so that the usercode provided in the example is aligned to the recommendations mentioned in the text.
The specification does not require user codes to be unguessable. Section 3.3.3 (Display of a Short User Code) states that user codes have to be unique and should be short-lived, but this does not imply that codes should be unguessable. It seems that Section 13.27 (Exhaustion of Random Value Space) does not apply to user codes, but to values that are clearly random values "such as nonces, tokens, and randomized URIs". If attackers can guess user codes, the same attack described in URL is possible.
Good catch! The intent is for these to be unguessable, so we can add that explicitly.
Code change:
want to conceal its IPs, e.g., if it has a priori knowledge that its addresses are in fact public, this processing is unnecessary. <del> For any host candidate gathered by an ICE agent as part of RFC8445, Section 5.1.1, the candidate is handled as follows: </del> <ins> This section outlines how mDNS should be used by ICE agents to conceal local IP addresses. For each host candidate gathered by an ICE agent as part of the gathering process described in RFC8445, Section 5.1.1, the candidate is handled as described below. Check whether this IP address satisfies the ICE agent's policy regarding whether an address is safe to expose.  If so, expose the candidate and abort this process. </ins> Check whether the ICE agent has a usable registered mDNS hostname resolving to the ICE candidate's IP address.  If one exists, skip

Related discussion:
text: I think this is good to go, will plan to land at EOD.
Does it obfuscate, conceal, or obscure local IP addresses? My vote is for conceal.
Conceal/concealment sgtm.
As noted in , we don't need to use the same term in every case, but the terms should have the same meaning. conceal and hide are fairly synonymous, but conceal and obfuscate have slightly different meanings.
This section is largely normative, so it might make more sense to put some parts from it immediately after Principle, namely the various adjustments to the technique that need to be considered (TURN, IPv6, stats) Things where we merely provide discussion (e.g., session monitoring) rather than normative guidance could remain in the privacy section.
Due to their different sensitivity and lifetime.
If we add this indication, do we also need to clarify the use case for lite ICE agents?
What did you have in mind?
{{#gathering}} starts with "For any host candidate gathered by an ICE agent as part of {{RFC8445}} section 5.1.1," it seems the place we need to revise to resolve this issue. I was thinking of allowing ICE lite implementation to skip the mDNS wrapping, since lite agents only use host candidates (8445, section 2.5). The lite implementation is however not required restricted to ICE agents that always have public IPs from my reading of that section, but rather an alternative to simplify the implementation when possible. So I am still not sure if it makes sense to say lite ICE can be exempted from wrapping; or instead indicating mDNS wrapping can be skipped if host candidates are equivalent to srflx candidates, and automatically the intended use of lite ICE satisfies this condition.
Right, the public IPs exception probably covers this. also indicates that this is really for web browsers, which are not allowed to implement ICE Lite.
Started writing this up today, but realized it's not totally clear how this should work. The idea would be to use STUN to figure out if an IP is public or not, but... Should we wait to hand out the mDNS candidate until we determine if the IP is private (i.e., STUN finishes)? Should we not hand out the mDNS candidate if we get a srflx candidate that shows the IP is not private?
Code change:
want to conceal its IPs, e.g., if it has a priori knowledge that its addresses are in fact public, this processing is unnecessary. <del> For any host candidate gathered by an ICE agent as part of RFC8445, Section 5.1.1, the candidate is handled as follows: </del> <ins> This section outlines how mDNS should be used by ICE agents to conceal local IP addresses. For each host candidate gathered by an ICE agent as part of the gathering process described in RFC8445, Section 5.1.1, the candidate is handled as described below. Check whether this IP address satisfies the ICE agent's policy regarding whether an address is safe to expose.  If so, expose the candidate and abort this process. </ins> Check whether the ICE agent has a usable registered mDNS hostname resolving to the ICE candidate's IP address.  If one exists, skip

Related discussion:
text: If we hand out the mDNS candidate and then get a srflx candidate that matches the local IP, should we make that a host candidate? Once we learn an IP is not public, should we cache that for future ICE gathering sessions (i.e., not give out mDNS candidates?) The easiest thing would probably be to recommend handing out the mDNS and srflx candidates as usual, but allow implementations to skip mDNS for IPs it has learned are public. (Except for RFC1918 addresses, which would always be treated as private.)
Partially addressed in , will probably include some additional clarifying text once it lands
The rest LGTM
Code change:
If the "Idempotency-Key" request header is missing for a documented idempotent operation requiring this header, the resource server SHOULD reply with an HTTP "400" status code with body containing a <del> link pointing to relevant documentation.  Alternately, using the HTTP header "Link", the client can be informed about the error as shown below. </del> <ins> link pointing to relevant documentation.  Following examples shows an error response describing the problem using RFC7807. Alternately, using the HTTP header "Link", the client can be informed about the error as shown below. </ins> If there is an attempt to reuse an idempotency key with a different request payload, the resource server SHOULD reply with a HTTP "422" status code with body containing a link pointing to relevant documentation.  The status code "422" is defined in Section 11.2 of <del> RFC4918.  The server can also inform the client by using the HTTP header "Link" as shown below. </del> <ins> RFC4918. The server can also inform the client by using the HTTP header "Link" as shown below. </ins> If the request is retried, while the original request is still being processed, the resource server SHOULD reply with an HTTP "409" status <del> code with body containing a link or the HTTP header "Link" pointing to the relevant documentation. </del> <ins> code with body containing problem description. Or, alternately using the HTTP header "Link" pointing to the relevant documentation </ins> Error scenarios above describe the status of failed idempotent requests after the resource server prcocesses them.  Clients MUST

Related discussion:
text: Issue
NAME NAME pl review re issue
Looks good
the examples of errors use a pattern of using a link in a header, and then (supposedly) using a human-readable error message. what about using RFC 7807 instead and using examples that use problem reports to indicate failure semantics in addition to the status code?
I agree. coming up in the next draft.
NAME should we close this issue if it is resolved?
NAME closing this issue. Let me know if not addressed with my latest PR.