Draft: draft-ietf-core-resource-directory

Commentary: I remember keeping web - links where it was beneficial to the text IMO OK with suggested change  chrysn schreef op 2018 - 11 - 09 16:43 : Links : [ 1 ] [ 2 ] [ 3 ] 
 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 ?
Paragraph (version A):
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
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
interfaces that a Resource Directory supports for web servers to
discover the RD and to register, maintain, lookup and remove resource
descriptions.  Furthermore, new link attributes useful in conjunction
with an RD are defined.
Paragraph (version B):
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
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
interfaces that a Resource Directory supports for web servers to
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.
Paragraph (version A):
entity called a Resource Directory (RD), which hosts registrations of
resources held on other servers, allowing lookups to be performed for
those resources.
Paragraph (version A):
This document specifies the web interfaces that a Resource Directory
supports for web servers to discover the RD and to register,
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
these interfaces with CoAP RFC7252, they can be applied in an
equivalent manner to HTTP RFC7230.
Paragraph (version B):
entity called a Resource Directory (RD), which contains information
about resources held on other servers, allowing lookups to be
performed for those resources.
Paragraph (version B):
This document specifies the web interfaces that a Resource Directory
supports for web servers to discover the RD and to register,
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
these interfaces with CoAP RFC7252, they can be applied in an
equivalent manner to HTTP RFC7230.
Paragraph (version A):
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.
Paragraph (version A):
Only information SHOULD be stored in the resource directory that is
discoverable from querying the described device's /.well-known/core
resource directly.
Paragraph (version A):
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
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.
Paragraph (version A):
The resource directory architecture is illustrated in fig-arch.  A
Resource Directory (RD) is used as a repository for Web Links RFC5988
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
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.
Paragraph (version A):
Registration entries in the RD are soft state and need to be
periodically refreshed.
Paragraph (version A):
An endpoint uses specific interfaces to register, update and remove a
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.
Paragraph (version A):
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.
Paragraph (version A):
A lookup interface for discovering any of the Web Links held in the
RD is provided using the CoRE Link Format.
Paragraph (version B):
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.
Paragraph (version B):
Only information SHOULD be stored in the resource directory that is
obtained by querying the described device's /.well-known/core
resource directly.
Paragraph (version B):
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
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.
Paragraph (version B):
The resource directory architecture is illustrated in fig-arch.  A
Resource Directory (RD) is used as a repository of registrations
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
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.
Paragraph (version B):
Registrations in the RD are soft state and need to be periodically
refreshed.
Paragraph (version B):
An endpoint uses specific interfaces to register, update and remove a
registration.  It is also possible for an RD to fetch Web Links from
endpoints and add their contents to resource directory registrations.
Paragraph (version B):
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.
Paragraph (version B):
A lookup interface for discovering any of the Web Links stored in the
RD is provided using the CoRE Link Format.
Paragraph (version A):
0 to n Registration (entries) of endpoints,
Paragraph (version B):
0 to n Registrations of endpoints,