jiebi/TextFlow huggingface dataset:
Original text:
optionally a sector (abbreviated "d" for historical reasons),  zero or one multicast addresses expressed as a base URI ("base"), and is composed of zero or more registrations (endpoints). a lifetime ("lt"), <del> a registration resource location inside the RD ("loc"), </del>  optionally a sector ("d")

Reviewer comments:
This executes the renaming of con to base and domain to sector as agreed on in the last meeting. Two follow-up commits create consistency in the ER diagram (which had to be modified anyway for the renaming) and the accompanying text, both internally (describe groups the same way as resources) and within the document (we describe several properties of a group that the ER did not show).

Revised text:
optionally a sector (abbreviated "d" for historical reasons), <ins> a group resource location inside the RD ("href"), </ins> zero or one multicast addresses expressed as a base URI ("base"), and is composed of zero or more registrations (endpoints). a lifetime ("lt"),  <ins> a registration resource location inside the RD ("href"), </ins> optionally a sector ("d")
Original text:
the registration or update interface.  The registration interface MUST be implemented to be idempotent, so that registering twice with the same endpoint parameters ep and d (sector) does not create <del> multiple registration resources.  A new registration resource may be created at any time to supersede an existing registration, replacing the registration parameters and links. </del>  The following rules apply for an update identified by a given (ep, d) value pair:

Reviewer comments:
The rules laid out below the removed sentence are pretty clear, but the removed sentence itself can be read to contradict them ("may be created at any time to supersede an existing registration") or at best does not add anything. Assuming it was left over from an older version (before the rules were added), I suggest we remove it. NAME that's your section of expertise. Please merge if you agree or reject otherwise.

Revised text:
the registration or update interface.  The registration interface MUST be implemented to be idempotent, so that registering twice with the same endpoint parameters ep and d (sector) does not create  <ins> multiple registration resources. </ins> The following rules apply for an update identified by a given (ep, d) value pair:
Original text:
Endpoint and group lookups result in links to registration resources and group resources, respectively.  Endpoint registration resources are annotated with their endpoint names (ep), domains (d, if present) <del> and context (con); the lifetime (lt) is not reported.  Additional endpoint attributes are added as link attributes to their endpoint link unless their specification says otherwise.  Group resources are annotated with their group names (gp), domain (d, if present) and multicast address (con, if present). </del>  While Endpoint Lookup does expose the registration resources, the RD does not need to make them accessible to clients.  Clients SHOULD NOT changes from -13 to -14  Registration management moved to appendix A Minor editorial changes

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

Revised text:
Endpoint and group lookups result in links to registration resources and group resources, respectively.  Endpoint registration resources are annotated with their endpoint names (ep), domains (d, if present)  <ins> and context (con) as well as a constant resource type (rt="core.rd- ep"); the lifetime (lt) is not reported.  Additional endpoint attributes are added as link attributes to their endpoint link unless their specification says otherwise. Group resources are annotated with their group names (gp), domain (d, if present) and multicast address (con, if present) as well as a constant resource type (rt="core.rd-gp"). </ins> While Endpoint Lookup does expose the registration resources, the RD does not need to make them accessible to clients.  Clients SHOULD NOT 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
Original text:
luminaries can learn to which groups they belong, and enable their interface for the multicast address. <del> The luminary, knowing its sector, queries the RD for the endpoint with rt=light and d=R2-4-015.  The RD returns all endpoints in the sector. </del>  <del> Knowing its own IPv6 address, the luminary discovers its endpoint name.  With the endpoint name the luminary queries the RD for all groups to which the endpoint belongs. From the base parameter value, the luminary learns the multicast address of the multicast group. </del>  Alternatively, the CT can communicate the multicast address directly to the luminaries by using the "coap-group" resource specified in

Reviewer comments:
The luminary of the example previously discovered its group addresses by looking up its own registration resource (which it did not know because it was entered by a CT), and via that its groups. As long as the device does not need to know its own registration resource, the same can be achieved in a single step by looking up groups that contain it directly, based on the address it would originally have compared the endpoint results against. Closes: URL Like with : NAME that's the example where you know all the rationales, feel free to merge or discard.
In the luminary example, the device first does an endpoint lookup to find its ep by comparing values, and then a group lookup to find its groups. That is unnecessary; by the rules of lookup, it could just do a group lookup with base= its own address and get the same result in one step.

Revised text:
luminaries can learn to which groups they belong, and enable their interface for the multicast address.  <ins> The luminary, knowing its sector and own IPv6 address, looks up the groups containing light resources it is assigned to: </ins>  <ins> From the returned base parameter value, the luminary learns the multicast address of the multicast group. </ins> Alternatively, the CT can communicate the multicast address directly to the luminaries by using the "coap-group" resource specified in
Original text:
RD is provided using the CoRE Link Format. A Registrant-EP MAY keep concurrent registrations to more than one RD <del> at the same time, but that is not expected to supported by typical EP implementations.  Any such registrations are independent of each other. For this case to occur, the EP would need to be explicitly configured to register multiple times: either by having multiple discovery mechanisms or addresses configured (which are not merely fallbacks to each other), or by having several sets of registration data to register with (eg. multiple endpoint names). </del>  3.3.

Reviewer comments:
The implementors in RIOT asked about whether a registrant could possibly maintain multiple registrations at different RDs, and how they interact. I think what I'm saying in this PR is obvious (though not redundant, as we don't talk about that topic otherwise), but given it was asked about, it's probably not. What are your opinions?
(Text updated after I learned more about what they thought was expected from Registrant-EPs.)
Shortened and merged.
A registrant-ep cannot be forbidden to register with multiple RDs anyway. May be a bit too much text for an obvious fact.

Revised text:
RD is provided using the CoRE Link Format. A Registrant-EP MAY keep concurrent registrations to more than one RD  <ins> at the same time if explicitly configured to do so, but that is not expected to be supported by typical EP implementations.  Any such registrations are independent of each other.  The usual expectation when multiple discovery mechanisms or addresses are configured is that they constitute a fallback path for a single registration. </ins> 3.3.
Original text:
GET <del> {+type-lookup-location}{?d,res,ep,gp,et,rt,page,count,resource- param} </del>  Domain (optional).  Used for domain, group, endpoint and resource lookups. <del> resource (optional).  Used for domain, group, endpoint and resource lookups. </del> gp := Group name (optional).  Used for endpoint, group and resource lookups.

Reviewer comments:
This solves issue ("nobody really knows what the parameter is for") by removing the parameter altogether.
We are not clear on how to use "res"in a lookup query. For example, what does xx represent in this query? GET /example/rd-lookup-gp?res=xx I couldn't find text to explain. Is it expected to be the address of a resource, like href or anchor+href ?
Hi Michael, From version 04 to the current version the ?res has undergone a change In the -10 example the return is ;rt=sensor;ct=60 where I might have expected ;rt=sensor;ct=60 But I cannot check because we do not know the contents of the RD and hypothesizing now: ?res=xx would have returned nothing unless there was an entry like ;rt=sensor;ct=60 and even more confusing we have something called resource-param. In an earlier e-mail Christian already suggested to modify that to link-param if I remember correctly. So yes, I can concur with you and agreeing with the existence of confusion. Peter Michael Koster schreef op 2017-05-05 16:01:
The last I had in mind about the parameter a short mention in the phone call -- to me it looked like a relic whose role has been superseded by ins et al. It is now the first time I perceive it as a parameter that does anything with the path. What is the intended overall purpose of res=? And what do you mean by the contents of the RD?
Hi Chris, I assume this a sequel to my answer to Michael. May be not..... The contents of the RD are all the information about ep, resources, etc. stored into the RD by whatever means. My speculation about res=xx means that it indicates filtering on resource paths which start with /xx/...... Peter
For such filtering, there is already , which is covered by the query parameter referencing RFC 6690. NAME of the RD": I see. Going through all the references in the document, it seems to me that the examples you mentioned are not about the lookup parameter, but just the arbitrary resource names in the pagination example. I'd suggest removing the parameter altogether (PR ) unless its use resurfaces.
I think "res" (for resource) may be useful as a link target attribute for tagging resources, and in that context could also be used as a lookup parameter. If we don't plan to create "res" as a target attribute we should remove it from the document. If we do want to define a new target attribute, maybe we can come up with something more descriptive than "res"...

Revised text:
GET  <ins> {+type-lookup-location}{?d,ep,gp,et,rt,page,count,resource-param} </ins> Domain (optional).  Used for domain, group, endpoint and resource lookups.  gp := Group name (optional).  Used for endpoint, group and resource lookups.
Original text:
The Registration Resource may also be used to inspect the registration resource using GET, update the registration link <del> contents using PATCH, or cancel the registration using DELETE. </del>  These operations are described in this section.

Reviewer comments:
The document uses the PATCH request method and the 4.09 response codes defined there. Closes: URL
This is needed for the 4.09 error code referenced.
Note to self: That draft is now
Looks good.

Revised text:
The Registration Resource may also be used to inspect the registration resource using GET, update the registration link  <ins> contents using PATCH (as introduced in RFC8132), or cancel the registration using DELETE. </ins> These operations are described in this section.
Original text:
Oscar Novo, Srdjan Krco, Szymon Sasin, Kerry Lynn, Esko Dijk, Anders Brandt, Matthieu Vial, Jim Schaad, Mohit Sethi, Hauke Petersen, <del> Hannes Tschofenig, Sampo Ukkola, Linyi Tian, and Jan Newmarch have provided helpful comments, discussions and ideas to improve and shape this document.  Zach would also like to thank his colleagues from the EU FP7 SENSEI project, where many of the resource directory concepts were originally developed. </del>  12.

Reviewer comments:
Jaime provided a detailled review, and Matthias provided an interesting use case that helped shape the base parameter details Closes: URL Disposition: Merge with next batch
The Acknowledgements section has not been updated for quite a while; I'll update it with the reviewers before releasing -20.

Revised text:
Oscar Novo, Srdjan Krco, Szymon Sasin, Kerry Lynn, Esko Dijk, Anders Brandt, Matthieu Vial, Jim Schaad, Mohit Sethi, Hauke Petersen,  <ins> Hannes Tschofenig, Sampo Ukkola, Linyi Tian, Jan Newmarch, Matthias Kovatsch and Jaime Jimenez have provided helpful comments, discussions and ideas to improve and shape this document.  Zach would also like to thank his colleagues from the EU FP7 SENSEI project, where many of the resource directory concepts were originally developed. </ins> 12.
Original text:
authorization token. Lifetime (optional).  Lifetime of the registration in seconds. <del> Range of 60-4294967295.  If no lifetime is included in the </del>  initial registration, a default value of 90000 (25 hours) SHOULD be assumed. successful earlier registration. Lifetime (optional).  Lifetime of the registration in seconds. <del> Range of 60-4294967295.  If no lifetime is included, the </del>  previous last lifetime set on a previous update or the original registration (falling back to 90000) SHOULD be used.

Reviewer comments:
Not setting to 0 as this would require further explanation on what it means, and also leaves the 0 value usable as a sentinel in implementations for "no lt given" (although the same, with -1, could be achieved by reducing the range at the top end). Closes: URL
Feedback from LwM2M: Their testing takes long with the arbitrary limit of 60s. We found no technical reasons to keep it there, and it should probably be abolished in favor of the natural lower limit of 1 second.

Revised text:
authorization token. Lifetime (optional).  Lifetime of the registration in seconds.  <ins> Range of 1-4294967295.  If no lifetime is included in the </ins> initial registration, a default value of 90000 (25 hours) SHOULD be assumed. successful earlier registration. Lifetime (optional).  Lifetime of the registration in seconds.  <ins> Range of 1-4294967295.  If no lifetime is included, the </ins> previous last lifetime set on a previous update or the original registration (falling back to 90000) SHOULD be used.
Original text:
4.1.2. <del> A resource directory can advertise its resources in DNS-SD using the service names "_rd._udp", "_rd-lookup-res._udp" and "_rd_lookup- ep._udp" defined in this document for its Directory Resource, its resource lookup and endpoint lookup resource, respectively.  A "path" key SHOULD be set, and indicate the path on the server (starting with a slash). </del>  <del> The use of those service names implies that CoAP-over-UDP is used. With that information, the host name and port given in the SRV record and the path from the TXT record, the discovering client can perform RD and URI discovery in a single step. </del>  <del> When the "path" key is absent, the client MUST discovery the URIs on the server according to discovery. This section is a concrete application of the more generic mechanism that is being developed as I-D.ietf-core-rd-dns-sd. </del>  4.2. 9.7. <del> IANA is asked to enter two new items into the Service Names and Transport Protocol Port Number Registry, all with this document as a reference: Service name "rd" over protocol "udp", described as "Resource Directory Directory Resource accessed using CoAP" </del>  <del> Service name "rd-lookup-res" over protocol "udp", described as "Resource Directory resource lookup accessed using CoAP" </del>  <del> Service name "rd-lookup-ep" over protocol "udp", described as "Resource Directory endpoint lookup accessed using CoAP" </del>  <del> All share the same assignment note: </del>  <del> Defined TXT key: path (e.g. "path=/rd") </del>  10.

Reviewer comments:
Reviewing the discussion in [1] and [2], my original patch seems to have overshot. [1]: URL [2]: URL
Much more sensibleless ambitious and more correct. The outcome in discussion in the Friday meeting was that the resource-directory specification should simply define the small number of DNS-SD service types that are needed for resource directory discovery. We said details were to be taken to the list, which I want to initiate now. In the meeting, I gave the three examples core-URL, core-rd-URL, and core-URL — noting that while core-rd is a proper RD service type, core-rd-tls isn’t. To cover the six transports we have for CoAP today (coap, coaps, coap+tcp, coaps+tcp, coap+ws, coaps+ws), we would need four service types on top of tcp and could use two of them over udp? Grüße, Carsten

Revised text:
4.1.2.  <ins> A resource directory can advertise its presence in DNS-SD using the service name "_core-rd._udp" defined in this document. </ins>  <ins> The use of that service names implies that CoAP-over-UDP is used. The SRV record points the client to a host name and port to use as a starting point for the URI discovery steps of discovery. </ins>  <ins> This section is a simplified concrete application of the more generic mechanism specified in I-D.ietf-core-rd-dns-sd. </ins> 4.2. 9.7.  <ins> IANA is asked to enter a new item into the Service Names and Transport Protocol Port Number Registry: </ins>  <ins> Service name: "core-rd" </ins>  <ins> Protocol: "udp" </ins>  <ins> Description: "Resource Directory accessed using CoAP" </ins>  <ins> Reference: this document </ins> 10.
Original text:
available), the use of a preconfigured anycast address is recommended (e.g. installation phase described in automation). <del> The use of DNS facilities is described in I-D.ietf-core-rd-dns-sd. </del>  The use of multicast discovery in mesh networks is NOT recommended.

Reviewer comments:
This was missed in the original pull of mechanism from RD-DNS-SD into here; its wording was brought in line with the other recommendations ("In case X, Y is recommended") and now goes to the internal section rather than the external document. Will be merged on Monday before submission unless spoken against.

Revised text:
available), the use of a preconfigured anycast address is recommended (e.g. installation phase described in automation).  <ins> In networks managed using DNS-SD, the use of DNS-SD for discovery as described in rd-using-dnssd is recommended. </ins> The use of multicast discovery in mesh networks is NOT recommended.
Original text:
4.1.2. A resource directory can advertise its presence in DNS-SD using the <del> service name "_core-rd._udp" defined in this document. </del>  <del> The use of that service names implies that CoAP-over-UDP is used. The SRV record points the client to a host name and port to use as a starting point for the URI discovery steps of discovery. </del>  This section is a simplified concrete application of the more generic mechanism specified in I-D.ietf-core-rd-dns-sd. 9.7. <del> IANA is asked to enter a new item into the Service Names and </del>  Transport Protocol Port Number Registry: <del> Service name: "core-rd" </del>  <del> Protocol: "udp" </del>  <del> Description: "Resource Directory accessed using CoAP" </del>  <del> Reference: this document </del>  10.

Reviewer comments:
Those were in the original proposals during IETF / on the list, but not in the text yet. Depends on for practical merging purposes.

Revised text:
4.1.2. A resource directory can advertise its presence in DNS-SD using the  <ins> service name "_core-rd._udp" (for CoAP), "_core-rd-dtls._udp" (for CoAP over UDP), "_core-rd._tcp" (for CoAP over TCP) or "_core-rd- tls._tcp" (for CoAP over TLS)` defined in this document.  (For the WebSocket transports of CoAP, no service is defined as DNS-SD is typically unavailable in environments where CoAP over WebSockets). </ins>  <ins> The selection of the service indicates the protocol used, and the SRV record points the client to a host name and port to use as a starting point for the URI discovery steps of discovery. </ins> This section is a simplified concrete application of the more generic mechanism specified in I-D.ietf-core-rd-dns-sd. 9.7.  <ins> IANA is asked to enter four new items into the Service Names and </ins> Transport Protocol Port Number Registry:  <ins> Service name: "core-rd", Protocol: "udp", Description: "Resource Directory accessed using CoAP" </ins>  <ins> Service name "core-rd-dtls", Protocol: "udp", Description: "Resource Directory accedded using CoAP over DTLS" </ins>  <ins> Service name: "core-rd", Protocol: "tcp", Description: "Resource Directory accessed using CoAP over TCP" </ins>  <ins> Service name "core-rd-tls", Protocol: "tcp", Description: "Resource Directory accedded using CoAP over TLS" All in common have this document as their reference. </ins> 10.
Original text:
A web entity that stores information about web resources and implements the REST interfaces defined in this specification for <del> registration and lookup of those resources. </del>  In the context of a Resource Directory, a sector is a logical

Reviewer comments:
This is to address Russ's genart comment:
The reflowing commit went here by accident (wrong branch / didn't check on upload). I'm pushing it to master, hoping this makes the PR's diff show only what's intended.

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, the maintenance and the removal of registrations, and for lookup of the registered resources. </ins> In the context of a Resource Directory, a sector is a logical