jiebi/CodeConvo huggingface dataset:
Code change:
All expected to be uncontroversial; to be merged soon.
Commit 3809be46013e9708a6584c4fb730e7cfecab5f22 should have been part of this as well, and is already applied to master.

Related discussion:
text: they do not limit what a server may respond under atypical circumstances. <del> REST clients (registrant-EPs / CTs, lookup clients, RD servers during simple registrations) MUST be prepared to receive any unsuccessful code and act upon it according to its definition, options and/or payload to the best of their capabilities, falling back to failing the operation if recovery is not possible.  In particular, they should retry the request upon 5.03 (Service Unavailable; 503 in HTTP) according to the Max-Age (Retry-After in HTTP) option, and fall back to link-format when receiving 4.15 (Unsupported Content-Format; 415 in HTTP). </del> <ins> REST clients (registrant-EPs and CTs during registration and maintenance, lookup clients, RD servers during simple registrations) MUST be prepared to receive any unsuccessful code and act upon it according to its definition, options and/or payload to the best of their capabilities, falling back to failing the operation if recovery is not possible.  In particular, they should retry the request upon 5.03 (Service Unavailable; 503 in HTTP) according to the Max-Age (Retry-After in HTTP) option, and fall back to link-format when receiving 4.15 (Unsupported Content-Format; 415 in HTTP). </ins> A resource directory MAY make the information submitted to it available to further directories, if it can ensure that a loop does
Code change:
All expected to be uncontroversial; to be merged soon.
Commit 3809be46013e9708a6584c4fb730e7cfecab5f22 should have been part of this as well, and is already applied to master.

Related discussion:
text: 8.1. <del> An Endpoint (name, sector) pair is unique within the et of endpoints </del> <ins> An Endpoint (name, sector) pair is unique within the set of endpoints </ins> registered by the RD.  An Endpoint MUST NOT be identified by its protocol, port or IP address as these may change over the lifetime of an Endpoint.
Code change:
All expected to be uncontroversial; to be merged soon.
Commit 3809be46013e9708a6584c4fb730e7cfecab5f22 should have been part of this as well, and is already applied to master.

Related discussion:
text: IPv4 - "all CoRE resource directories" address MCD2 (suggestion: 224.0.1.189), from the "IPv4 Multicast Address Space Registry".  As the address is used for discovery that may span beyond a single <del> network, it has come from the Internetwork Control Block (224.0.1.x, RFC 5771). </del> <ins> network, it has come from the Internetwork Control Block (224.0.1.x) RFC5771. </ins> IPv6 - "all CoRE resource directories" address MCD1 (suggestions FF0X::FE), from the "IPv6 Multicast Address Space Registry", in the
Code change:
as suggested by Russ in the genart review: NAME did I get the intention of the expression right?
LGTM

Related discussion:
text: depending on their current availability and capabilities as well as application requirements, thus avoiding silo like solutions.  One of the crucial enablers of such design is the ability to discover <del> resources (machines -- endpoints) capable of providing required information at a given time or acting on instructions from the end users. </del> <ins> resources (and thus the endpoints they are hosted on) capable of providing required information at a given time or acting on instructions from the end users. </ins> Imagine a scenario where endpoints installed on vehicles enable tracking of the position of these vehicles for fleet management
Code change:
... and a few other cases of example errors and use of unregistered names.

Related discussion:
text: name and the same value, allowing for a trailing "*" wildcard operator as in Section 4.1 of RFC6690.  Attributes that are defined as "link-type" match if the search value matches any of their values <del> (see Section 4.1 of RFC6690; e.g. "?if=core.s" matches ";if="abc core.s";").  A resource link also matches a search criterion if its endpoint would match the criterion, and vice versa, an endpoint link matches a search criterion if any of its resource links matches it. </del> <ins> (see Section 4.1 of RFC6690; e.g. "?if=tag:example.net,2020:sensor" matches ";if="example.regname tag:example.net,2020:sensor";").  A resource link also matches a search criterion if its endpoint would match the criterion, and vice versa, an endpoint link matches a search criterion if any of its resource links matches it. </ins> Note that "href" is a valid search criterion and matches target references.  Like all search criteria, on a resource lookup it can
Code change:
... and a few other cases of example errors and use of unregistered names.

Related discussion:
text: identifiers; the precise semantics of such links are left to future specifications. <del> The following example shows a client performing an endpoint type (et) lookup with the value oic.d.sensor (which is currently a registered rt value): </del> <ins> The following example shows a client performing an endpoint lookup limited to endpoints of endpoint type "tag:example.com,2020:platform": </ins> 7.
Code change:
... and a few other cases of example errors and use of unregistered names.

Related discussion:
text: is specified in the coap-group resource. The presence sensor can learn the presence of groups that support <del> resources with rt=light in its own sector by sending the same request, as used by the luminary.  The presence sensor learns the multicast address to use for sending messages to the luminaries. </del> <ins> resources with rt=tag:example.com,2020:light in its own sector by sending the same request, as used by the luminary.  The presence sensor learns the multicast address to use for sending messages to the luminaries. </ins> 10.2.
Code change:
... and a few other cases of example errors and use of unregistered names.

Related discussion:
text: RDAO: Clarify that it is an option for RAs and not other ND messages. <ins> Examples: Use example URIs rather than unclear reg names (unless it's RFC6690 examples, which were kept for continuity) </ins> changes from -24 to -25 Large rework of section 7 (Security policies)
Code change:
Authentication alone is never sufficient; with the First-Come-Fist-Remembered policy of , it should be easier to see how this is still authorization. See-Also: URL Thanks for addressing my DISCUSS and COMMENT feedback

Related discussion:
text: at the CoAP layer then it may be inclined to use the endpoint name for looking up what information to provision to the malicious device. <del> Endpoint authentication needs to be checked independently of whether there are configured requirements on the credentials for a given endpoint name (secure-ep) or whether arbitrary names are accepted (arbitrary-ep). </del> <ins> Endpoint authorization needs to be checked on registration and registration resource operations independently of whether there are configured requirements on the credentials for a given endpoint name (secure-ep) or whether arbitrary names are accepted (arbitrary-ep). </ins> Simple registration could be used to circumvent address-based access control: An attacker would send a simple registration request with
Code change:
The SHOULD is not an interoperability requirement but a quality-of-implementation level recommendation; the MUST could have been read as a requirement to have parameters there and is more describing mechanism than compatibility. See-Also: URL Hi, Thank you for this document. I'm glad that the shepherd's writeup indicates that there are implementations since that indicates that there does appear to be value in standardizing this work, despite its long journey. My main comment (which I was considering raising as a discuss) is: Since this document is defining a new service, I think that this document would benefit on having a short later section on "Operations, Administration and Management". This document does seem to cover some management/administration considerations in various sections in a somewhat ad hoc way, but having a section highlighting those would potentially make it easier deploy.  Defining a common management model (or API) would potentially also make administration of the service easier, I don't know if that had been considered, and if useful could be done as a separate document. A few other comments: What happens if an endpoint is managing the registration and is upgraded to new hardware with a different certificate?  Would the updated endpoint expect to be able to update the registration?  Or would it have to wait for the existing registration to timeout (which could be a long time)? Nit: Perhaps reword the second sentence.  Otherwise it seems to conflict with the last sentence of the prior paragraph. The "SHOULD NOT" feels a bit strong to me, and I would prefer to see this as "MAY NOT".  In many cases, if the configuration is not too big then providing the full configuration makes it easy to guarantee that the receiver has exactly the correct configuration.  I appreciate that there are many cases where from an endpoint perspective it may want to keep the update small, but if I was doing this from a CT, I think that I would rather just resend the entire configuration, if it is not large. Just to check, is it correct that the anchor in the http link is also to coap://?  If this is wrong then there is a second example in the same section that also needs to be fixed.

Related discussion:
text: resource returned by the initial registration operation. An update MAY update registration parameters like lifetime, base URI <del> or others.  Parameters that are not being changed SHOULD NOT be </del> <ins> or others.  Parameters that are not being changed should not be </ins> included in an update.  Adding parameters that have not changed increases the size of the message but does not have any other <del> implications.  Parameters MUST be included as query parameters in an </del> <ins> implications.  Parameters are included as query parameters in an </ins> update operation as in registration. A registration update resets the timeout of the registration to the
Code change:
Some small mainly editorial fixes from Ben's review, to be merged soon.
From Ben's updated ballot: Good point, queued up.
From Ben's updated ballot:: → "The RD (always, but especially here) then needs to verify any lookup client's authorization before reveling this information directly (in resource lookup) or indirectly (when using it to satisfy a resource lookup search criterion)"
From follow-up on Ben's initial DISCUSS: → "regular registrations (i.e., per {{registration}})"
From follow-up on Ben's initial DISCUSS: It'd sound like abuse of semicolons to me; keeping it open to ask RFC editor for their technical writing expertise.

Related discussion:
text: A web entity that stores information about web resources and implements the REST interfaces defined in this specification for <del> discovery, for the creation, the maintenance and the removal of </del> <ins> discovery, for the creation, maintenance and removal of </ins> registrations, and for lookup of the registered resources.
Code change:
Some small mainly editorial fixes from Ben's review, to be merged soon.
From Ben's updated ballot: Good point, queued up.
From Ben's updated ballot:: → "The RD (always, but especially here) then needs to verify any lookup client's authorization before reveling this information directly (in resource lookup) or indirectly (when using it to satisfy a resource lookup search criterion)"
From follow-up on Ben's initial DISCUSS: → "regular registrations (i.e., per {{registration}})"
From follow-up on Ben's initial DISCUSS: It'd sound like abuse of semicolons to me; keeping it open to ask RFC editor for their technical writing expertise.

Related discussion:
text: format payload to register. The registrant-ep includes the same registration parameters in the <del> POST request as it would per registration.  The registration base URI of the registration is taken from the registrant-ep's network address (as is default with regular registrations). </del> <ins> POST request as it would with a regular registration per registration.  The registration base URI of the registration is taken from the registrant-ep's network address (as is default with regular registrations). </ins> Example request from registrant-EP to RD (unanswered until the next step):
Code change:
Some small mainly editorial fixes from Ben's review, to be merged soon.
From Ben's updated ballot: Good point, queued up.
From Ben's updated ballot:: → "The RD (always, but especially here) then needs to verify any lookup client's authorization before reveling this information directly (in resource lookup) or indirectly (when using it to satisfy a resource lookup search criterion)"
From follow-up on Ben's initial DISCUSS: → "regular registrations (i.e., per {{registration}})"
From follow-up on Ben's initial DISCUSS: It'd sound like abuse of semicolons to me; keeping it open to ask RFC editor for their technical writing expertise.

Related discussion:
text: lookup clients may access the information. In this case, the endpoint (and not the lookup clients) needs to be <del> careful to check the RD's authorization. </del> <ins> careful to check the RD's authorization.  The RD needs to check any lookup client's authorization before revealing information directly (in resource lookup) or indirectly (when using it to satisfy a resource lookup search criterion). </ins> 7.4.
Code change:
Some small mainly editorial fixes from Ben's review, to be merged soon.
From Ben's updated ballot: Good point, queued up.
From Ben's updated ballot:: → "The RD (always, but especially here) then needs to verify any lookup client's authorization before reveling this information directly (in resource lookup) or indirectly (when using it to satisfy a resource lookup search criterion)"
From follow-up on Ben's initial DISCUSS: → "regular registrations (i.e., per {{registration}})"
From follow-up on Ben's initial DISCUSS: It'd sound like abuse of semicolons to me; keeping it open to ask RFC editor for their technical writing expertise.

Related discussion:
text: If the client's credentials indicate any subject name that is certified by any authority which the RD recognizes (which may be <del> the system's trust anchor store), all those subject names are </del> <ins> the system's trust anchor store), all such subject names are </ins> stored.  With CWT or JWT based credentials (as common with ACE), the Subject (sub) claim is stored as a single name, if it exists. With X.509 certificates, the Common Name (CN) and the complete
Code change:
Some small mainly editorial fixes from Ben's review, to be merged soon.
From Ben's updated ballot: Good point, queued up.
From Ben's updated ballot:: → "The RD (always, but especially here) then needs to verify any lookup client's authorization before reveling this information directly (in resource lookup) or indirectly (when using it to satisfy a resource lookup search criterion)"
From follow-up on Ben's initial DISCUSS: → "regular registrations (i.e., per {{registration}})"
From follow-up on Ben's initial DISCUSS: It'd sound like abuse of semicolons to me; keeping it open to ask RFC editor for their technical writing expertise.

Related discussion:
text: 12. <ins> changes from -27 to -28 Security policies / link confidentiality: Point out the RD's obligations that follow from such a policy. Simple registration: clarify term "regular registration" by introducing it along with the reference to Wording fix in first-come-first-remembered Wording fixes in RD definition </ins> changes from -26 to -27 In general, this addresses the points that were pointed out in
Code change:
Closes: URL For immediate merging
... and other terms defined in terminology. Best addressed after and the anchor changes are through.

Related discussion:
text: operations on a registration. After the initial registration, the registering endpoint retains the <del> returned location of the Registration Resource for further </del> <ins> returned location of the registration resource for further </ins> operations, including refreshing the registration in order to extend the lifetime and "keep-alive" the registration.  When the lifetime of the registration has expired, the RD SHOULD NOT respond to discovery queries concerning this endpoint.  The RD SHOULD continue to provide <del> access to the Registration Resource after a registration time-out </del> <ins> access to the registration resource after a registration time-out </ins> occurs in order to enable the registering endpoint to eventually refresh the registration.  The RD MAY eventually remove the registration resource for the purpose of garbage collection.  If the <del> Registration Resource is removed, the corresponding endpoint will </del> <ins> registration resource is removed, the corresponding endpoint will </ins> need to be re-registered. <del> The Registration Resource may also be used cancel the registration </del> <ins> The registration resource may also be used cancel the registration </ins> using DELETE, and to perform further operations beyond the scope of this specification. <del> Operations on the Registration Resource are sensitive to reordering; </del> <ins> Operations on the registration resource are sensitive to reordering; </ins> freshness describes how order is restored. <del> The operations on the Registration Resource are described below. </del> <ins> The operations on the registration resource are described below. </ins> 5.3.1.
Code change:
Closes: URL For immediate merging
... and other terms defined in terminology. Best addressed after and the anchor changes are through.

Related discussion:
text: victim's /.well-known/core content in the RD.  Mitigation for this is recommended in simple. <del> The Registration Resource path is visible to any client that is </del> <ins> The registration resource path is visible to any client that is </ins> allowed endpoint lookup, and can be extracted by resource lookup clients as well.  The same goes for registration attributes that are shown as target attributes or lookup attributes.  The RD needs to <del> consider this in the choice of Registration Resource paths, and </del> <ins> consider this in the choice of registration resource paths, and </ins> administrators or endpoint in their choice of attributes. 8.3.
Code change:
I think there is a trivial typo in the first sentence of "Trade-offs".
thanks!

Related discussion:
text: the connection, the session is terminated. Trade-offs: RST Packet Injection has a few advantages that make it <del> extremely popular is a censorship technique.  RST Packet Injection is </del> <ins> extremely popular as a censorship technique.  RST Packet Injection is </ins> an out-of-band prevention mechanism, allowing the avoidance of the the QoS bottleneck one can encounter with inline techniques such as Packet Dropping.  This out-of-band property allows a censor to
Code change:
s/prevention/interference/ ... Censors can degrade performance to a particular site, or for a particular service, effectively making performance so bad for a site that users opt to use a different site or service. China is known to do this. Censors can try to have content removed via takedown requests, under the guise of laws that forbid certain content (e.g., hate speech or whatnot). The ANC is .za has been accused of using the laws in this fashion.
Will Scott also noted in feedback to me that throttling should get more of a call out than it currently does:

Related discussion:
text: 1. Censorship is where an entity in a position of power - such as a <del> government, organization, or individual - supresses communication </del> <ins> government, organization, or individual - suppresses communication </ins> that it considers objectionable, harmful, sensitive, politically incorrect or inconvenient.  (While censors that engage in censorship or establish censorship regimes must do so through legal, military,
Code change:
s/prevention/interference/ ... Censors can degrade performance to a particular site, or for a particular service, effectively making performance so bad for a site that users opt to use a different site or service. China is known to do this. Censors can try to have content removed via takedown requests, under the guise of laws that forbid certain content (e.g., hate speech or whatnot). The ANC is .za has been accused of using the laws in this fashion.
Will Scott also noted in feedback to me that throttling should get more of a call out than it currently does:

Related discussion:
text: interference.  Prescription is the process by which censors determine what types of material they should block, i.e. they decide to block a list of pornographic websites.  Identification is the process by <del> which censors classify specific traffic to be blocked or impaird, </del> <ins> which censors classify specific traffic to be blocked or impaired, </ins> i.e. the censor blocks or impairs all webpages containing "sex" in the title or traffic to sex.com.  Interference is the process by which the censor intercedes in communication and prevents access to
Code change:
s/prevention/interference/ ... Censors can degrade performance to a particular site, or for a particular service, effectively making performance so bad for a site that users opt to use a different site or service. China is known to do this. Censors can try to have content removed via takedown requests, under the guise of laws that forbid certain content (e.g., hate speech or whatnot). The ANC is .za has been accused of using the laws in this fashion.
Will Scott also noted in feedback to me that throttling should get more of a call out than it currently does:

Related discussion:
text: 4.1. <ins> While other interference techniques outlined in this section mostly focus on blocking or preventing access to content, it can be an effective censorship strategy in some cases to not entirely block access to a given destination, or service but instead degrade the performance of the relevant network connection.  The resulting user experience for a site or service under performance degradation can be so bad that users opt to use a different site, service, or method of communication, or may not engage in communication at all if there are no alternatives.  Traffic shaping techniques that rate-limit the bandwidth available to certain types of traffic is one example of a performance degradation. Trade offs: While implementing a performance degradation will not always eliminate the ability of people to access a desire resource, it may force them to use other means of communication where censorship (or surveillance) is more easily accomplished. Empirical examples: Iran is known to shape the bandwidth available to HTTPS traffic to encourage unencrypted HTTP traffic Aryan-2012. 4.2. </ins> Packet dropping is a simple mechanism to prevent undesirable traffic. The censor identifies undesirable traffic and chooses to not properly forward any packets it sees associated with the traversing
Code change:
s/prevention/interference/ ... Censors can degrade performance to a particular site, or for a particular service, effectively making performance so bad for a site that users opt to use a different site or service. China is known to do this. Censors can try to have content removed via takedown requests, under the guise of laws that forbid certain content (e.g., hate speech or whatnot). The ANC is .za has been accused of using the laws in this fashion.
Will Scott also noted in feedback to me that throttling should get more of a call out than it currently does:

Related discussion:
text: uses Packet Dropping as the mechanisms for throttling SSH Aryan-2012. These are but two examples of a ubiquitous censorship practice. <del> 4.2. </del> <ins> 4.3. </ins> Packet injection, generally, refers to a man-in-the-middle (MITM) network interference technique that spoofs packets in an established