Original text:
registration, update, lookup, and removal interfaces defined in this section.  5.1. Resource Directory implementations using this specification MUST including a Resource Type (rt) parameter RFC6690 with the value "core.rd" in the query string.  Likewise, a Resource Type parameter value of "core.rd-lookup*" is used to discover the URIs for RD Lookup <del> operations, and "core.gp" is used to discover the URI path for RD Group operations.  Upon success, the response will contain a payload with a link format entry for each RD function discovered, indicating the URI path of the RD function returned and the corresponding Resource Type.  When performing multicast discovery, the multicast IP address used will depend on the scope required and the multicast capabilities of the network. </del>  A Resource Directory MAY provide hints about the content-formats it supports in the links it exposes or registers, using the "ct" link registration may be created at any time to supersede an existing registration, replacing the registration parameters and links.  The registration request interface is specified as follows: EP -> RD 5.3.2. <del> An endpoint that wants to make itself discoverable occasionally sends a POST request to the "/.well-known/core" URI of any candidate directory server that it finds.  The body of the POST request is empty, which triggers the resource directory server to perform GET requests at the requesting server's default discovery URI to obtain the link-format payload to register. </del>  The endpoint MUST include the endpoint name and MAY include the registration parameters d, lt, and et, in the POST request as per registration.  The following example shows an endpoint using simple publishing, by simply sending an empty POST to a resource directory. registration with an RD.  To use the interface, the endpoint sends a POST request to the registration resource returned in the Location header option in the response returned from the intial registration <del> operation. </del>  An update MAY update the lifetime or context registration parameters "lt", "con" as in registration ) if the previous settings are to be shut-down).  This is accomplished using a removal interface on the RD by performing a DELETE on the endpoint resource.  The removal request interface is specified as follows: EP -> RD 11. Oscar Novo, Srdjan Krco, Szymon Sasin, Kerry Lynn, Esko Dijk, Anders <del> Brandt, Matthieu Vial, Mohit Sethi, Sampo Ukkola, Linyi Tian, Chistian Amsuss, and Jan Newmarch have provided helpful comments, </del>  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 12.  changes from -09 to -10 removed "ins" and "exp" link-format extensions.

Reviewer comments:
atomicity idempotency, Jim multiple query parameter, Fairhair deleted eps from group, Jim simple registration, hauke

Revised text:
registration, update, lookup, and removal interfaces defined in this section. <ins> All operations on the contents of the Resource Directory MUST be atomic and idempotent. A Resource Directory MUST accept query filtering with multiple query parameters in the URI. </ins> 5.1. Resource Directory implementations using this specification MUST including a Resource Type (rt) parameter RFC6690 with the value "core.rd" in the query string.  Likewise, a Resource Type parameter value of "core.rd-lookup*" is used to discover the URIs for RD Lookup  <ins> operations, and "core.rd-group" is used to discover the URI path for RD Group operations.  Upon success, the response will contain a payload with a link format entry for each RD function discovered, indicating the URI path of the RD function returned and the corresponding Resource Type.  When performing multicast discovery, the multicast IP address used will depend on the scope required and the multicast capabilities of the network. </ins> A Resource Directory MAY provide hints about the content-formats it supports in the links it exposes or registers, using the "ct" link registration may be created at any time to supersede an existing registration, replacing the registration parameters and links. <ins> An empty payload is considered a malformed request. </ins> The registration request interface is specified as follows: EP -> RD 5.3.2.  <ins> An endpoint that wants to make itself discoverable sends (and regularly refreshes with) a POST request to the "/.well-known/core" URI of any candidate directory server that it finds.  The body of the POST request is empty, which triggers the resource directory server to perform GET requests at the requesting server's default discovery URI to obtain the link-format payload to register. </ins> The endpoint MUST include the endpoint name and MAY include the registration parameters d, lt, and et, in the POST request as per registration. <ins> The endpoints MUST be deleted after the expiration of their lifetime. Additional operations cannot be executed because no registration location is returned. </ins> The following example shows an endpoint using simple publishing, by simply sending an empty POST to a resource directory. registration with an RD.  To use the interface, the endpoint sends a POST request to the registration resource returned in the Location header option in the response returned from the intial registration  <ins> operation.  The POST request (in contrats to PUT) allows replacing selection of a resource. </ins> An update MAY update the lifetime or context registration parameters "lt", "con" as in registration ) if the previous settings are to be shut-down).  This is accomplished using a removal interface on the RD by performing a DELETE on the endpoint resource. <ins> Removed endpoints are implicitly removed from the groups to which they belong. </ins> The removal request interface is specified as follows: EP -> RD 11. Oscar Novo, Srdjan Krco, Szymon Sasin, Kerry Lynn, Esko Dijk, Anders  <ins> Brandt, Matthieu Vial, Jim Schaad, Mohit Sethi, Hauke Petersen, Sampo Ukkola, Linyi Tian, and Jan Newmarch have provided helpful comments, </ins> 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 12. <ins> changes from -11 to -12 added ER diagram updated discovery text improved text on: atomicity, idempotency, multiple query, ep removal, simple registration </ins> changes from -09 to -10 removed "ins" and "exp" link-format extensions.