Original text:
In many M2M applications, direct discovery of resources is not practical due to sleeping nodes, disperse networks, or networks where multicast traffic is inefficient.  These problems can be solved by <del> employing an entity called a Resource Directory (RD), which hosts registrations of resources held on other servers, allowing lookups to be performed for those resources.  This document specifies the web </del>  interfaces that a Resource Directory supports for web servers to <del> discover the RD and to register, maintain, lookup and remove resource descriptions.  Furthermore, new link attributes useful in conjunction with an RD are defined. </del>  1. scenarios, direct discovery of resources is not practical due to sleeping nodes, disperse networks, or networks where multicast traffic is inefficient.  These problems can be solved by employing an <del> entity called a Resource Directory (RD), which hosts registrations of resources held on other servers, allowing lookups to be performed for those resources. </del>  This document specifies the web interfaces that a Resource Directory supports for web servers to discover the RD and to register, <del> maintain, lookup and remove resource descriptions.  Furthermore, new link attributes useful in conjunction with a Resource Directory are defined.  Although the examples in this document show the use of </del>  these interfaces with CoAP RFC7252, they can be applied in an equivalent manner to HTTP RFC7230. connected devices, or across boundaries that would be limiting those operations. <del> It provides a cache (in the high-level sense, not as defined in RFC7252/RFC2616) of data that could otherwise only be obtained by directly querying the /.well-known/core resource on the target device, or by accessing those resources with a multicast request. </del>  Only information SHOULD be stored in the resource directory that is <del> discoverable from querying the described device's /.well-known/core </del>  resource directly. Data in the resource directory can only be provided by the device which hosts those data or a dedicated Commissioning Tool (CT).  These CTs are thought to act on behalf of endpoints too constrained, or generally unable, to present that information themselves.  No other <del> client can modify data in the resource directory.  Changes in the Resource Directory do not propagate automatically back to the web server from where the links originated. </del>  3.2. The resource directory architecture is illustrated in fig-arch.  A <del> Resource Directory (RD) is used as a repository for Web Links RFC5988 </del>  describing resources hosted on other web servers, also called endpoints (EP).  An endpoint is a web server associated with a scheme, IP address and port.  A physical node may host one or more endpoints.  The RD implements a set of REST interfaces for endpoints <del> to register and maintain sets of Web Links (called resource directory registration entries), and for endpoints to lookup resources from the RD.  An RD can be logically segmented by the use of Sectors.  This information hierarchy is shown in fig-hierarchy. </del>  A mechanism to discover an RD using CoRE Link Format RFC6690 is defined. <del> Registration entries in the RD are soft state and need to be periodically refreshed. </del>  An endpoint uses specific interfaces to register, update and remove a <del> resource directory registration entry.  It is also possible for an RD to fetch Web Links from endpoints and add them as resource directory registration entries. </del>  <del> At the first registration of a set of entries, a "registration resource" is created, the location of which is returned to the registering endpoint.  The registering endpoint uses this registration resource to manage the contents of registration entries. </del>  <del> A lookup interface for discovering any of the Web Links held in the </del>  RD is provided using the CoRE Link Format. A Registrant-EP MAY keep concurrent registrations to more than one RD The model shown in fig-ER-RD models the contents of the resource directory which contains in addition to /.well-known/core: <del> 0 to n Registration (entries) of endpoints, </del>  A registration is associated with one endpoint.  A registration defines a set of links as defined for /.well-known/core.  A

Reviewer comments:
I remember keeping web-links where it was beneficial to the text IMO OK with suggested change Peter chrysn schreef op 2018-11-09 16:43: Links: [1] URL [2] URL [3] URL
I'm fine with "Web Links" not being that prominent in the architecture any more; however, two mentions have survived in the three paragraphs above fig-arch, was that intentional?

Revised text:
In many M2M applications, direct discovery of resources is not practical due to sleeping nodes, disperse networks, or networks where multicast traffic is inefficient.  These problems can be solved by  <ins> employing an entity called a Resource Directory (RD), which contains information about resources held on other servers, allowing lookups to be performed for those resources.  The input to an RD is composed of links and the output is composed of links constructed from the information stored in the RD.  This document specifies the web </ins> interfaces that a Resource Directory supports for web servers to  <ins> discover the RD and to register, maintain, lookup and remove information on resources.  Furthermore, new link attributes useful in conjunction with an RD are defined. </ins> 1. scenarios, direct discovery of resources is not practical due to sleeping nodes, disperse networks, or networks where multicast traffic is inefficient.  These problems can be solved by employing an  <ins> entity called a Resource Directory (RD), which contains information about resources held on other servers, allowing lookups to be performed for those resources. </ins> This document specifies the web interfaces that a Resource Directory supports for web servers to discover the RD and to register,  <ins> maintain, lookup and remove information on resources.  Furthermore, new link attributes useful in conjunction with a Resource Directory are defined.  Although the examples in this document show the use of </ins> these interfaces with CoAP RFC7252, they can be applied in an equivalent manner to HTTP RFC7230. connected devices, or across boundaries that would be limiting those operations.  <ins> It provides information about resources hosted by other devices that could otherwise only be obtained by directly querying the /.well- known/core resource on these other devicess, either by a unicast request or a multicast request. </ins> Only information SHOULD be stored in the resource directory that is  <ins> obtained by querying the described device's /.well-known/core </ins> resource directly. Data in the resource directory can only be provided by the device which hosts those data or a dedicated Commissioning Tool (CT).  These CTs are thought to act on behalf of endpoints too constrained, or generally unable, to present that information themselves.  No other  <ins> client can modify data in the resource directory.  Changes to the information in the Resource Directory do not propagate automatically back to the web servers from where the information originated. </ins> 3.2. The resource directory architecture is illustrated in fig-arch.  A  <ins> Resource Directory (RD) is used as a repository of registrations </ins> describing resources hosted on other web servers, also called endpoints (EP).  An endpoint is a web server associated with a scheme, IP address and port.  A physical node may host one or more endpoints.  The RD implements a set of REST interfaces for endpoints  <ins> to register and maintain resource directory registrations, and for endpoints to lookup resources from the RD.  An RD can be logically segmented by the use of Sectors.  This information hierarchy is shown in fig-hierarchy. </ins> A mechanism to discover an RD using CoRE Link Format RFC6690 is defined.  <ins> Registrations in the RD are soft state and need to be periodically refreshed. </ins> An endpoint uses specific interfaces to register, update and remove a  <ins> registration.  It is also possible for an RD to fetch Web Links from endpoints and add their contents to resource directory registrations. </ins>  <ins> At the first registration of an endpoint, a "registration resource" is created, the location of which is returned to the registering endpoint.  The registering endpoint uses this registration resource to manage the contents of registrations. </ins>  <ins> A lookup interface for discovering any of the Web Links stored in the </ins> RD is provided using the CoRE Link Format. A Registrant-EP MAY keep concurrent registrations to more than one RD The model shown in fig-ER-RD models the contents of the resource directory which contains in addition to /.well-known/core:  <ins> 0 to n Registrations of endpoints, </ins> A registration is associated with one endpoint.  A registration defines a set of links as defined for /.well-known/core.  A