Draft: draft-ietf-core-resource-directory

Commentary: Exceptions are : first mentions in abstract and text terminology headings identifiers exported to IANA registries references to the above Occasional wording changes were made where things would have looked weird with the abbreviation in place . Closes : Will merge this right away as I really do n't to manage something like this concurrently with any other PR ; resolution path was already discussed in the issue . 
 From  ' genart review , three related points : I 'd go for " RD " throughout , with the first mentions in abstract , introduction and obviously terminology spelt out . On the phrases I 'd prefer " RDs implementing this specification " . 
 agree with Christian 's suggestion ,  chrysn schreef op 2020 - 04 - 15 17:25 : Links : [ 1 ] [ 2 ]
Paragraph (version A):
In many IoT 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 target attributes useful
in conjunction with an RD are defined.
Paragraph (version B):
In many IoT 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 an RD supports for web servers to discover the RD and
to register, maintain, lookup and remove information on resources.
Furthermore, new target attributes useful in conjunction with an RD
are defined.
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 information on resources.  Furthermore,
new target 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):
This document specifies the web interfaces that an RD supports for
web servers to discover the RD and to register, maintain, lookup and
remove information on resources.  Furthermore, new target attributes
useful in conjunction with an RD 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):
In the context of a Resource Directory, a sector is a logical
grouping of endpoints.
Paragraph (version B):
In the context of an RD, a sector is a logical grouping of
endpoints.
Paragraph (version A):
Endpoint (EP) is a term used to describe a web server or client in
RFC7252.  In the context of this specification an endpoint is used
to describe a web server that registers resources to the Resource
Directory.  An endpoint is identified by its endpoint name, which
is included during registration, and has a unique name within the
associated sector of the registration.
Paragraph (version A):
The Base URI of a Registration is a URI that typically gives
scheme and authority information about an Endpoint.  The
Registration Base URI is provided at registration time, and is
used by the Resource Directory to resolve relative references of
the registration into URIs.
Paragraph (version B):
Endpoint (EP) is a term used to describe a web server or client in
RFC7252.  In the context of this specification an endpoint is used
to describe a web server that registers resources to the RD.  An
endpoint is identified by its endpoint name, which is included
during registration, and has a unique name within the associated
sector of the registration.
Paragraph (version B):
The Base URI of a Registration is a URI that typically gives
scheme and authority information about an Endpoint.  The
Registration Base URI is provided at registration time, and is
used by the RD to resolve relative references of the registration
into URIs.
Paragraph (version A):
A resource in the Resource Directory (RD) containing registration
resources.
Paragraph (version B):
A resource in the RD containing registration resources.
Paragraph (version A):
Resource Directory Address Option.  A new IPv6 Neighbor Discovery
option defined for announcing a Resource Directory's address.
Paragraph (version A):
The Resource Directory is primarily a tool to make discovery
operations more efficient than querying /.well-known/core on all
connected devices, or across boundaries that would be limiting those
operations.
Paragraph (version A):
Information SHOULD only be stored in the resource directory if it can
be obtained by 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 to the
information in the Resource Directory do not propagate automatically
back to the web servers from where the information originated.
Paragraph (version A):
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.
Paragraph (version B):
Resource Directory Address Option.  A new IPv6 Neighbor Discovery
option defined for announcing an RD's address.
Paragraph (version B):
The RD is primarily a tool to make discovery operations more
efficient than querying /.well-known/core on all connected devices,
or across boundaries that would be limiting those operations.
Paragraph (version B):
Information SHOULD only be stored in the RD if it can be obtained by
querying the described device's /.well-known/core resource directly.
Paragraph (version B):
Data in the RD 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 RD.  Changes to the information in the RD do not
propagate automatically back to the web servers from where the
information originated.
Paragraph (version B):
The RD architecture is illustrated in fig-arch.  An 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 RD registrations,
and for endpoints to lookup resources from the RD.  An RD can be
logically segmented by the use of Sectors.
Paragraph (version A):
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):
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 its registrations.
Paragraph (version A):
The Entity-Relationship (ER) models shown in fig-ER-WKC and fig-ER-RD
model the contents of /.well-known/core and the resource directory
respectively, with entity-relationship diagrams ER.  Entities
(rectangles) are used for concepts that exist independently.
Attributes (ovals) are used for concepts that exist only in
connection with a related entity.  Relations (diamonds) give a
semantic meaning to the relation between entities.  Numbers specify
the cardinality of the relations.
Paragraph (version B):
The Entity-Relationship (ER) models shown in fig-ER-WKC and fig-ER-RD
model the contents of /.well-known/core and the RD respectively, with
entity-relationship diagrams ER.  Entities (rectangles) are used for
concepts that exist independently.  Attributes (ovals) are used for
concepts that exist only in connection with a related entity.
Relations (diamonds) give a semantic meaning to the relation between
entities.  Numbers specify the cardinality of the relations.
Paragraph (version A):
These models provide an abstract view of the information expressed in
link-format documents and a Resource Directory.  They cover the
concepts, but not necessarily all details of an RD's operation; they
are meant to give an overview, and not be a template for
implementations.
Paragraph (version B):
These models provide an abstract view of the information expressed in
link-format documents and an RD.  They cover the concepts, but not
necessarily all details of an RD's operation; they are meant to give
an overview, and not be a template for implementations.
Paragraph (version A):
Imagine a scenario where endpoints installed on vehicles enable
tracking of the position of these vehicles for fleet management
purposes and allow monitoring of environment parameters.  During the
boot-up process endpoints register with a Resource Directory, which
is hosted by the mobile operator or somewhere in the cloud.
Periodically, these endpoints update their registration and may
modify resources they offer.
Paragraph (version B):
Imagine a scenario where endpoints installed on vehicles enable
tracking of the position of these vehicles for fleet management
purposes and allow monitoring of environment parameters.  During the
boot-up process endpoints register with an RD, which is hosted by the
mobile operator or somewhere in the cloud.  Periodically, these
endpoints update their registration and may modify resources they
offer.
Paragraph (version A):
Resources may be shared through data brokers that have no knowledge
beforehand of who is going to consume the data.  Resource Directory
can be used to hold links about resources and services hosted
anywhere to make them discoverable by a general class of
applications.
Paragraph (version A):
For example, environmental and weather sensors that generate data for
public consumption may provide data to an intermediary server, or
broker.  Sensor data are published to the intermediary upon changes
or at regular intervals.  Descriptions of the sensors that resolve to
links to sensor data may be published to a Resource Directory.
Applications wishing to consume the data can use RD Lookup to
discover and resolve links to the desired resources and endpoints.
The Resource Directory service need not be coupled with the data
intermediary service.  Mapping of Resource Directories to data
intermediaries may be many-to-many.
Paragraph (version A):
Metadata in web link formats like RFC6690 which may be internally
stored as triples, or relation/attribute pairs providing metadata
about resource links, need to be supported by Resource Directories .
External catalogues that are represented in other formats may be
converted to common web linking formats for storage and access by
Resource Directories.  Since it is common practice for these to be
encoded in URNs RFC8141, simple and lossless structural transforms
should generally be sufficient to store external metadata in Resource
Directories.
Paragraph (version A):
The additional features of Resource Directory allow sectors to be
defined to enable access to a particular set of resources from
particular applications.  This provides isolation and protection of
sensitive data when needed.  Application groups with multicast
addresses may be defined to support efficient data transport.
Paragraph (version A):
This and the following sections define the required set of REST
interfaces between a Resource Directory (RD), endpoints and lookup
clients.  Although the examples throughout these sections assume the
use of CoAP RFC7252, these REST interfaces can also be realized using
HTTP RFC7230.  Only multicast discovery operations are not possible
on HTTP, and Simple Registration can not be executed as base
attribute (which is mandatory for HTTP) can not be used there.  In
all definitions in these sections, both CoAP response codes (with dot
notation) and HTTP response codes (without dot notation) are shown.
An RD implementing this specification MUST support the discovery,
registration, update, lookup, and removal interfaces.
Paragraph (version A):
All operations on the contents of the Resource Directory MUST be
atomic and idempotent.
Paragraph (version B):
Resources may be shared through data brokers that have no knowledge
beforehand of who is going to consume the data.  An RD can be used to
hold links about resources and services hosted anywhere to make them
discoverable by a general class of applications.
Paragraph (version B):
For example, environmental and weather sensors that generate data for
public consumption may provide data to an intermediary server, or
broker.  Sensor data are published to the intermediary upon changes
or at regular intervals.  Descriptions of the sensors that resolve to
links to sensor data may be published to an RD.  Applications wishing
to consume the data can use RD Lookup to discover and resolve links
to the desired resources and endpoints.  The RD service need not be
coupled with the data intermediary service.  Mapping of RDs to data
intermediaries may be many-to-many.
Paragraph (version B):
Metadata in web link formats like RFC6690 which may be internally
stored as triples, or relation/attribute pairs providing metadata
about resource links, need to be supported by RDs.  External
catalogues that are represented in other formats may be converted to
common web linking formats for storage and access by RDs.  Since it
is common practice for these to be encoded in URNs RFC8141, simple
and lossless structural transforms should generally be sufficient to
store external metadata in RDs.
Paragraph (version B):
The additional features of an RD allow sectors to be defined to
enable access to a particular set of resources from particular
applications.  This provides isolation and protection of sensitive
data when needed.  Application groups with multicast addresses may be
defined to support efficient data transport.
Paragraph (version B):
This and the following sections define the required set of REST
interfaces between an RD, endpoints and lookup clients.  Although the
examples throughout these sections assume the use of CoAP RFC7252,
these REST interfaces can also be realized using HTTP RFC7230.  Only
multicast discovery operations are not possible on HTTP, and Simple
Registration can not be executed as base attribute (which is
mandatory for HTTP) can not be used there.  In all definitions in
these sections, both CoAP response codes (with dot notation) and HTTP
response codes (without dot notation) are shown.  An RD implementing
this specification MUST support the discovery, registration, update,
lookup, and removal interfaces.
Paragraph (version B):
All operations on the contents of the RD MUST be atomic and
idempotent.
Paragraph (version A):
A resource directory MAY make the information submitted to it
available to further directories, if it can ensure that a loop does
not form.  The protocol used between directories to ensure loop-free
operation is outside the scope of this document.
Paragraph (version A):
A (re-)starting device may want to find one or more resource
directories for discovery purposes.  Dependent on the operational
conditions, one or more of the techniques below apply.
Paragraph (version B):
An RD MAY make the information submitted to it available to further
directories, if it can ensure that a loop does not form.  The
protocol used between directories to ensure loop-free operation is
outside the scope of this document.
Paragraph (version B):
A (re-)starting device may want to find one or more RDs for discovery
purposes.  Dependent on the operational conditions, one or more of
the techniques below apply.
Paragraph (version A):
For cases where the device is not specifically configured with a way
to find a resource directory, the network may want to provide a
suitable default.
Paragraph (version B):
For cases where the device is not specifically configured with a way
to find an RD, the network may want to provide a suitable default.
Paragraph (version A):
Finally, if neither the device nor the network offers any specific
configuration, the device may want to employ heuristics to find a
suitable resource directory.
Paragraph (version A):
In a 6LoWPAN, just assume the Border Router (6LBR) can act as a
resource directory (using the ABRO option to find that RFC6775).
Confirmation can be obtained by sending a Unicast to
"coap://[6LBR]/.well-known/core?rt=core.rd*".
Paragraph (version B):
Finally, if neither the device nor the network offers any specific
configuration, the device may want to employ heuristics to find a
suitable RD.
Paragraph (version B):
In a 6LoWPAN, just assume the Border Router (6LBR) can act as an
RD (using the ABRO option to find that RFC6775).  Confirmation can
be obtained by sending a Unicast to "coap://[6LBR]/.well-known/
core?rt=core.rd*".
Paragraph (version A):
The Resource Directory Address Option (RDAO) using IPv6 Neighbor
Discovery (ND) carries information about the address of the Resource
Directory (RD).  This information is needed when endpoints cannot
discover the Resource Directory with a link-local or realm-local
scope multicast address, for instance because the endpoint and the RD
are separated by a Border Router (6LBR).  In many circumstances the
availability of DHCP cannot be guaranteed either during commissioning
of the network.  The presence and the use of the RD is essential
during commissioning.
Paragraph (version A):
It is possible to send multiple RDAO options in one message,
indicating as many resource directory addresses.
Paragraph (version A):
A resource directory can advertise its presence in DNS-SD RFC6763
using the service name "_core-rd._udp" (for CoAP), "_core-rd-
dtls._udp" (for CoAP over DTLS), "_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 is used).
Paragraph (version B):
The Resource Directory Address Option (RDAO) using IPv6 Neighbor
Discovery (ND) carries information about the address of the RD.  This
information is needed when endpoints cannot discover the RD with a
link-local or realm-local scope multicast address, for instance
because the endpoint and the RD are separated by a Border Router
(6LBR).  In many circumstances the availability of DHCP cannot be
guaranteed either during commissioning of the network.  The presence
and the use of the RD is essential during commissioning.
Paragraph (version B):
It is possible to send multiple RDAO options in one message,
indicating as many RD addresses.
Paragraph (version B):
An RD can advertise its presence in DNS-SD RFC6763 using the service
name "_core-rd._udp" (for CoAP), "_core-rd-dtls._udp" (for CoAP over
DTLS), "_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 is used).
Paragraph (version A):
Resource Directory implementations using this specification MUST
support the application/link-format content format (ct=40).
Paragraph (version A):
Resource Directories implementing this specification MAY support
additional content formats.
Paragraph (version A):
Any additional content format supported by a Resource Directory
implementing this specification SHOULD be able to express all the
information expressible in link-format.  It MAY be able to express
information that is inexpressible in link-format, but those
expressions SHOULD be avoided where possible.
Paragraph (version B):
RDs implementing this specification MUST support the application/
link-format content format (ct=40).
Paragraph (version B):
RDs implementing this specification MAY support additional content
formats.
Paragraph (version B):
Any additional content format supported by an RD implementing this
specification SHOULD be able to express all the information
expressible in link-format.  It MAY be able to express information
that is inexpressible in link-format, but those expressions SHOULD be
avoided where possible.
Paragraph (version A):
A Resource Directory MAY provide hints about the content-formats it
supports in the links it exposes or registers, using the "ct" target
attribute, as shown in the example below.  Clients MAY use these
hints to select alternate content-formats for interaction with the
Resource Directory.
Paragraph (version A):
An implementation of this resource directory specification MUST
support query filtering for the rt parameter as defined in RFC6690.
Paragraph (version B):
An RD MAY provide hints about the content-formats it supports in the
links it exposes or registers, using the "ct" target attribute, as
shown in the example below.  Clients MAY use these hints to select
alternate content-formats for interaction with the RD.
Paragraph (version B):
RDs implementing this specification MUST support query filtering for
the rt parameter as defined in RFC6690.
Paragraph (version A):
A Resource Directory may optionally support HTTP.  Here is an example
of almost the same registration operation above, when done using
HTTP.
Paragraph (version B):
An RD may optionally support HTTP.  Here is an example of almost the
same registration operation above, when done using HTTP.
Paragraph (version A):
The Resource Directory queries the registrant-ep's discovery
resource to determine the success of the operation.  It SHOULD
keep a cache of the discovery resource and not query it again as
long as it is fresh.
Paragraph (version B):
The RD queries the registrant-ep's discovery resource to determine
the success of the operation.  It SHOULD keep a cache of the
discovery resource and not query it again as long as it is fresh.
Paragraph (version A):
In a controlled environment (e.g. building control), the Resource
Directory can be filled by a third party device, called a
Commissioning Tool (CT).  The commissioning tool can fill the
Resource Directory from a database or other means.  For that purpose
scheme, IP address and port of the URI of the registered device is
the value of the "base" parameter of the registration described in
registration.
Paragraph (version B):
In a controlled environment (e.g. building control), the RD can be
filled by a third party device, called a Commissioning Tool (CT).
The commissioning tool can fill the RD from a database or other
means.  For that purpose scheme, IP address and port of the URI of
the registered device is the value of the "base" parameter of the
registration described in registration.
Paragraph (version A):
Above rules allow the client to interpret the response as links
without any further knowledge of the storage conventions of the RD.
The Resource Directory MAY replace the registration base URIs with a
configured intermediate proxy, e.g. in the case of an HTTP lookup
interface for CoAP endpoints.
Paragraph (version B):
Above rules allow the client to interpret the response as links
without any further knowledge of the storage conventions of the RD.
The RD MAY replace the registration base URIs with a configured
intermediate proxy, e.g. in the case of an HTTP lookup interface for
CoAP endpoints.
Paragraph (version A):
Multiple search criteria MAY be included in a lookup.  All included
criteria MUST match for a link to be returned.  The Resource
Directory MUST support matching with multiple search criteria.
Paragraph (version B):
Multiple search criteria MAY be included in a lookup.  All included
criteria MUST match for a link to be returned.  The RD MUST support
matching with multiple search criteria.
Paragraph (version A):
A Resource Directory can report endpoints in lookup that are not
hosted at the same address.  Lookup clients MUST be prepared to see
arbitrary URIs as registration resources in the results and treat
them as opaque identifiers; the precise semantics of such links are
left to future specifications.
Paragraph (version B):
An RD can report endpoints in lookup that are not hosted at the same
address.  Lookup clients MUST be prepared to see arbitrary URIs as
registration resources in the results and treat them as opaque
identifiers; the precise semantics of such links are left to future
specifications.
Paragraph (version A):
The Resource Directory (RD) provides assistance to applications
situated on a selection of nodes to discover endpoints on connected
nodes.  This section discusses different security aspects of
accessing the RD.
Paragraph (version B):
The RD provides assistance to applications situated on a selection of
nodes to discover endpoints on connected nodes.  This section
discusses different security aspects of accessing the RD.
Paragraph (version A):
Every operation performed by an Endpoint on a resource directory
SHOULD be mutually authenticated using Pre-Shared Key, Raw Public Key
or Certificate based security.
Paragraph (version B):
Every operation performed by an Endpoint on an RD SHOULD be mutually
authenticated using Pre-Shared Key, Raw Public Key or Certificate
based security.
Paragraph (version A):
were found to be 19 times larger than the request.  A Resource
Directory (RD) which responds to wild-card lookups is potentially
vulnerable if run with CoAP over UDP.  Since there is no return
routability check and the responses can be significantly larger than
requests, RDs can unknowingly become part of a DDoS amplification
attack.
Paragraph (version B):
were found to be 19 times larger than the request.  An RD which
responds to wild-card lookups is potentially vulnerable if run with
CoAP over UDP.  Since there is no return routability check and the
responses can be significantly larger than requests, RDs can
unknowingly become part of a DDoS amplification attack.
Paragraph (version A):
Note that Endpoint Type differs from Resource Type in that it uses
multiple attributes rather than space separated values.  As a result,
Resource Directory implementations automatically support correct
filtering in the lookup interfaces from the rules for unknown
endpoint attributes.
Paragraph (version B):
Note that Endpoint Type differs from Resource Type in that it uses
multiple attributes rather than space separated values.  As a result,
RDs implementing this specification automatically support correct
filtering in the lookup interfaces from the rules for unknown
endpoint attributes.
Paragraph (version A):
This example shows a simplified lighting installation which makes use
of the Resource Directory (RD) with a CoAP interface to facilitate
the installation and start-up of the application code in the lights
and sensors.  In particular, the example leads to the definition of a
group and the enabling of the corresponding multicast address as
described in groups.  No conclusions must be drawn on the realization
of actual installation or naming procedures, because the example only
"emphasizes" some of the issues that may influence the use of the RD
and does not pretend to be normative.
Paragraph (version B):
This example shows a simplified lighting installation which makes use
of the RD with a CoAP interface to facilitate the installation and
start-up of the application code in the lights and sensors.  In
particular, the example leads to the definition of a group and the
enabling of the corresponding multicast address as described in
groups.  No conclusions must be drawn on the realization of actual
installation or naming procedures, because the example only
"emphasizes" some of the issues that may influence the use of the RD
and does not pretend to be normative.
Paragraph (version A):
In rd-en the use of resource directory during installation is
presented.
Paragraph (version B):
In rd-en the use of RD during installation is presented.
Paragraph (version A):
This example shows how the OMA LWM2M specification makes use of
Resource Directory (RD).
Paragraph (version B):
This example shows how the OMA LWM2M specification makes use of RDs.
Paragraph (version A):
An LWM2M server is an instance of an LWM2M middleware service layer,
containing a Resource Directory along with other LWM2M interfaces
defined by the LWM2M specification.
Paragraph (version A):
CoRE Resource Directory (RD) is used to provide the LWM2M
Registration interface.
Paragraph (version B):
An LWM2M server is an instance of an LWM2M middleware service layer,
containing an RD along with other LWM2M interfaces defined by the
LWM2M specification.
Paragraph (version B):
The registration interface of this specification is used to provide
the LWM2M Registration interface.
Paragraph (version A):
LWM2M defines a registration interface based on the REST API,
described in registration.  The RD registration URI path of the LWM2M
Resource Directory is specified to be "/rd".
Paragraph (version B):
LWM2M defines a registration interface based on the REST API,
described in registration.  The RD registration URI path of the LWM2M
RD is specified to be "/rd".
Paragraph (version A):
Oscar Novo, Srdjan Krco, Szymon Sasin, Kerry Lynn, Esko Dijk, Anders
Brandt, Matthieu Vial, Jim Schaad, Mohit Sethi, Hauke Petersen,
Hannes Tschofenig, Sampo Ukkola, Linyi Tian, Jan Newmarch, Matthias
Kovatsch, Jaime Jimenez and Ted Lemon 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.
Paragraph (version B):
Oscar Novo, Srdjan Krco, Szymon Sasin, Kerry Lynn, Esko Dijk, Anders
Brandt, Matthieu Vial, Jim Schaad, Mohit Sethi, Hauke Petersen,
Hannes Tschofenig, Sampo Ukkola, Linyi Tian, Jan Newmarch, Matthias
Kovatsch, Jaime Jimenez and Ted Lemon 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 RD concepts were originally developed.