Change:
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> <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 <del> discoverable from querying the described device's /.well-known/core </del> <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 <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> <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 <del> Resource Directory (RD) is used as a repository for Web Links RFC5988 </del> <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 <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> <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. <del> Registration entries in the RD are soft state and need to be periodically refreshed. </del> <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 <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> <ins> registration.  It is also possible for an RD to fetch Web Links from endpoints and add their contents to resource directory registrations. </ins> <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> <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> <del> A lookup interface for discovering any of the Web Links held in the </del> <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

Discussion:
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?