jiebi/TextFlow huggingface dataset:
Original text:
[ The RFC editor is asked to replace MCD1 and MCD2 with the assigned addresses throughout the document. ]  10. Two examples are presented: a Lighting Installation example in lt-ex

Reviewer comments:
Closes: URL
Alexeys' review mentions IANA considerations for .well-known/, and while we don't have any from the sentence he referred to, we are adding to behavior of .well-known/core in the simple registration -- grabbing its POST behavior. Do we need to update the registration entry for that (or update 6690 for its registration)?

Revised text:
[ The RFC editor is asked to replace MCD1 and MCD2 with the assigned addresses throughout the document. ] <ins> 9.6. IANA is asked to extend the reference for the "core" URI suffix in the "Well-Known URIs" registry to reference this document next to RFC6690, as this defines the resource's behavior for POST requests. </ins> 10. Two examples are presented: a Lighting Installation example in lt-ex
Original text:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and <del> "OPTIONAL" in this document are to be interpreted as described in RFC2119.  The term "byte" is used in its now customary sense as a synonym for "octet". </del>  This specification requires readers to be familiar with all the terms and concepts that are discussed in RFC3986, RFC8288 and RFC6690.

Reviewer comments:
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.

Revised text:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and  <ins> "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. The term "byte" is used in its now customary sense as a synonym for "octet". </ins> This specification requires readers to be familiar with all the terms and concepts that are discussed in RFC3986, RFC8288 and RFC6690.
Original 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>  A resource directory MAY make the information submitted to it available to further directories, if it can ensure that a loop does

Reviewer comments:
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.

Revised text:
they do not limit what a server may respond under atypical circumstances.  <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
Original text:
8.1. <del> An Endpoint (name, sector) pair is unique within the et of endpoints </del>  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.

Reviewer comments:
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.

Revised text:
8.1.  <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.
Original 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>  IPv6 - "all CoRE resource directories" address MCD1 (suggestions FF0X::FE), from the "IPv6 Multicast Address Space Registry", in the

Reviewer comments:
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.

Revised 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  <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
Original 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>  Imagine a scenario where endpoints installed on vehicles enable tracking of the position of these vehicles for fleet management

Reviewer comments:
as suggested by Russ in the genart review: NAME did I get the intention of the expression right?
LGTM

Revised 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  <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
Original 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>  Note that "href" is a valid search criterion and matches target references.  Like all search criteria, on a resource lookup it can

Reviewer comments:
... and a few other cases of example errors and use of unregistered names.

Revised 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  <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
Original 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>  7.

Reviewer comments:
... and a few other cases of example errors and use of unregistered names.

Revised text:
identifiers; the precise semantics of such links are left to future specifications.  <ins> The following example shows a client performing an endpoint lookup limited to endpoints of endpoint type "tag:example.com,2020:platform": </ins> 7.
Original 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>  10.2.

Reviewer comments:
... and a few other cases of example errors and use of unregistered names.

Revised text:
is specified in the coap-group resource. The presence sensor can learn the presence of groups that support  <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.
Original text:
RDAO: Clarify that it is an option for RAs and not other ND messages.  changes from -24 to -25 Large rework of section 7 (Security policies)

Reviewer comments:
... and a few other cases of example errors and use of unregistered names.

Revised 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)
Original 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>  Simple registration could be used to circumvent address-based access control: An attacker would send a simple registration request with

Reviewer comments:
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

Revised 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.  <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
Original 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>  registrations, and for lookup of the registered resources.

Reviewer comments:
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.

Revised text:
A web entity that stores information about web resources and implements the REST interfaces defined in this specification for  <ins> discovery, for the creation, maintenance and removal of </ins> registrations, and for lookup of the registered resources.
Original 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>  Example request from registrant-EP to RD (unanswered until the next step):

Reviewer comments:
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.

Revised text:
format payload to register. The registrant-ep includes the same registration parameters in the  <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):
Original 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>  7.4.

Reviewer comments:
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.

Revised text:
lookup clients may access the information. In this case, the endpoint (and not the lookup clients) needs to be  <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.
Original 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>  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

Reviewer comments:
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.

Revised text:
If the client's credentials indicate any subject name that is certified by any authority which the RD recognizes (which may be  <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
Original text:
12.  changes from -26 to -27 In general, this addresses the points that were pointed out in

Reviewer comments:
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.

Revised 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
Original text:
operations on a registration. After the initial registration, the registering endpoint retains the <del> returned location of the Registration Resource for further </del>  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>  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>  need to be re-registered. <del> The Registration Resource may also be used cancel the registration </del>  using DELETE, and to perform further operations beyond the scope of this specification. <del> Operations on the Registration Resource are sensitive to reordering; </del>  freshness describes how order is restored. <del> The operations on the Registration Resource are described below. </del>  5.3.1.

Reviewer comments:
Closes: URL For immediate merging
... and other terms defined in terminology. Best addressed after and the anchor changes are through.

Revised text:
operations on a registration. After the initial registration, the registering endpoint retains the  <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  <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  <ins> registration resource is removed, the corresponding endpoint will </ins> need to be re-registered.  <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.  <ins> Operations on the registration resource are sensitive to reordering; </ins> freshness describes how order is restored.  <ins> The operations on the registration resource are described below. </ins> 5.3.1.
Original 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>  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>  administrators or endpoint in their choice of attributes. 8.3.

Reviewer comments:
Closes: URL For immediate merging
... and other terms defined in terminology. Best addressed after and the anchor changes are through.

Revised text:
victim's /.well-known/core content in the RD.  Mitigation for this is recommended in simple.  <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  <ins> consider this in the choice of registration resource paths, and </ins> administrators or endpoint in their choice of attributes. 8.3.
Original text:
Wording fixes in RD definition  changes from -26 to -27 In general, this addresses the points that were pointed out in

Reviewer comments:
Closes: URL For immediate merging
... and other terms defined in terminology. Best addressed after and the anchor changes are through.

Revised text:
Wording fixes in RD definition <ins> Capitalization: Consistently using "registration resource" </ins> changes from -26 to -27 In general, this addresses the points that were pointed out in
Original 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>  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

Reviewer comments:
I think there is a trivial typo in the first sentence of "Trade-offs".
thanks!

Revised text:
the connection, the session is terminated. Trade-offs: RST Packet Injection has a few advantages that make it  <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