Draft: rfc9176

Commentary: Thanks , looks good .
Paragraph (version A):
Over the last few years, mobile operators around the world have
focused on development of M2M solutions in order to expand the
business to the new type of users: machines.  The machines are
connected directly to a mobile network using an appropriate embedded
wireless interface (GSM/General Packet Radio Service (GPRS), Wideband
Code Division Multiple Access (W-CDMA), LTE) or via a gateway
providing short- and wide-range wireless interfaces.  The ambition in
such systems is to build them from reusable components.  These speed
up development and deployment and enable shared use of machines
across different applications.  One crucial component of such systems
is the discovery of resources (and thus the endpoints they are hosted
on) capable of providing required information at a given time or
acting on instructions from the end users.
Paragraph (version B):
Over the last few years, mobile operators around the world have
focused on development of M2M solutions in order to expand the
business to the new type of users: machines.  The machines are
connected directly to a mobile network using an appropriate embedded
wireless interface (GSM/General Packet Radio Service (GPRS), Wideband
Code Division Multiple Access (W-CDMA), LTE, ...) or via a gateway
providing short- and wide-range wireless interfaces.  The ambition in
such systems is to build them from reusable components.  These speed
up development and deployment and enable shared use of machines
across different applications.  One crucial component of such systems
is the discovery of resources (and thus the endpoints they are hosted
on) capable of providing required information at a given time or
acting on instructions from the end users.
Paragraph (version A):
Metadata in web link formats like the one defined in 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):
Metadata in web link formats such as the one defined in 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 A):
For several operations, interface templates are given in list form;
those describe the operation participants, request codes, URIs,
content formats, and outcomes.  Sections of those templates contain
normative content about Interaction, Method, URI Template, and URI
Template Variables, as well as the details of the Success condition.
The additional sections for options (like Content-Format) and for
Failure codes give typical cases that an implementation of the RD
should deal with.  Those serve to illustrate the typical responses to
readers who are not yet familiar with all the details of CoAP-based
interfaces; they do not limit how a server may respond under atypical
circumstances.
Paragraph (version B):
For several operations, interface templates are given in list form;
those describe the operation participants, request codes, URIs,
content formats, and outcomes.  Sections of those templates contain
normative content about Interaction, Method, URI Template, and URI
Template Variables, as well as the details of the Success condition.
The additional sections for options (such as Content-Format) and for
Failure codes give typical cases that an implementation of the RD
should deal with.  Those serve to illustrate the typical responses to
readers who are not yet familiar with all the details of CoAP-based
interfaces; they do not limit how a server may respond under atypical
circumstances.
Paragraph (version A):
and 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
operations, and core.rd* is used to discover all URIs for RD
operations.  Upon success, the response will contain a payload with a
link format entry for each RD function discovered, indicating the URI
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 (see mc-registration).
Paragraph (version B):
and 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
operations, and "core.rd*" is used to discover all URIs for RD
operations.  Upon success, the response will contain a payload with a
link format entry for each RD function discovered, indicating the URI
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 (see mc-registration).
Paragraph (version A):
of the indicated host to obtain the resource type information from an
authorized source.
Paragraph (version A):
The URI discovery operation can yield multiple URIs of a given
resource type.  The client of the RD can use any of the discovered
addresses initially.
Paragraph (version B):
resource of the indicated host to obtain the resource type
information from an authorized source.
Paragraph (version B):
The URI discovery operation can yield multiple URIs of a given
resource type.  The client of the RD can try out any of the
discovered addresses.
Paragraph (version A):
It should be noted that the value of the "base" parameter applies to
all the links of the registration and has consequences for the anchor
value of the individual links, as exemplified in weblink.  An
eventual (currently nonexistent) "base" attribute of the link is not
affected by the value of "base" parameter in the registration.
Paragraph (version B):
It should be noted that the value of the "base" parameter applies to
all the links of the registration and has consequences for the anchor
value of the individual links, as exemplified in weblink.  A
potential (currently nonexistent) "base" attribute of the link is not
affected by the value of "base" parameter in the registration.
Paragraph (version A):
An update MAY update registration parameters like lifetime, base URI,
or others.  Parameters that are not being changed should not be
included in an update.  Adding parameters that have not changed
increases the size of the message but does not have any other
implications.  Parameters are included as query parameters in an
update operation, as in registration.
Paragraph (version B):
An update MAY update registration parameters such as lifetime, base
URI, or others.  Parameters that are not being changed should not be
included in an update.  Adding parameters that have not changed
increases the size of the message but does not have any other
implications.  Parameters are included as query parameters in an
update operation, as in registration.
Paragraph (version A):
Endpoints that are interested in a lookup result repeatedly or
continuously can use mechanisms like ETag caching, resource
observation RFC7641, or any future mechanism that might allow more
efficient observations of collections.  These are advertised,
detected, and used according to their own specifications and can be
used with the lookup interface as with any other resource.
Paragraph (version B):
Endpoints that are interested in a lookup result repeatedly or
continuously can use mechanisms such as ETag caching, resource
observation RFC7641, or any future mechanism that might allow more
efficient observations of collections.  These are advertised,
detected, and used according to their own specifications and can be
used with the lookup interface as with any other resource.
Paragraph (version A):
Registrants that are prepared to pick a different identifier when
their initial attempt (or attempts, in the unlikely case of two
subsequent collisions) at registration is unauthorized should pick an
identifier at least twice as long as the expected number of
registrants; registrants without any such recovery options should
pick significantly longer endpoint names (e.g., using Universally
Unique Identifier (UUID) URNs RFC4122).
Paragraph (version B):
Registrants that are prepared to pick a different identifier when
their initial attempt (or attempts, in the unlikely case of two
subsequent collisions) at registration is unauthorized should pick an
identifier at least twice as long as would be needed to enumerate the
expected number of registrants; registrants without any such recovery
options should pick significantly longer endpoint names (e.g., using
Universally Unique Identifier (UUID) URNs RFC4122).
Paragraph (version A):
The "First Come First Remembered" policy is provided both as a
reference example for a security policy definition and as a policy
that implementations may choose to use as default policy in the
absence of another configuration.  It is designed to enable efficient
discovery operations even in ad hoc settings.
Paragraph (version A):
Under this policy, the RD accepts registrations for any endpoint name
that is not assigned to an active registration resource and only
accepts registration updates from the same endpoint.  The policy is
minimal in that it does not make any promises to lookup clients about
the claims of Sections entered-resources and link-confidentiality,
and promises about the claims in secure-ep are limited to the
lifetime of that endpoint's registration.  It does however promise
the endpoint that, for the duration of its registration, its links
will be discoverable on the RD.
Paragraph (version B):
The "First Come First Remembered" policy is provided both as a
reference example for a security policy definition and as a policy
that implementations may choose to use as default policy in the
absence of any other configuration.  It is designed to enable
efficient discovery operations even in ad hoc settings.
Paragraph (version B):
Under this policy, the RD accepts registrations for any endpoint name
that is not assigned to an active registration resource and only
accepts registration updates from the same endpoint.  The policy is
minimal in that it does not make any promises to lookup clients about
the claims of Sections entered-links and link-confidentiality, and
promises about the claims in secure-ep are limited to the lifetime of
that endpoint's registration.  It does however promise the endpoint
that, for the duration of its registration, its links will be
discoverable on the RD.
Paragraph (version A):
To mitigate that, clients can retain the RD's address, use secure
discovery options like configured addresses, and send queries for RDs
in a very general form (e.g.,
Paragraph (version B):
To mitigate that, clients can retain the RD's address, use secure
discovery options such as configured addresses, and send queries for
RDs in a very general form (e.g.,
Paragraph (version A):
The registration resource path is visible to any client that is
allowed endpoint lookup and can be extracted by resource lookup
clients as well.  The same goes for registration attributes that are
shown as target attributes or lookup attributes.  The RD needs to
consider this in the choice of registration resource paths and
administrators or endpoint in their choice of attributes.
Paragraph (version B):
The registration resource path is visible to any client that is
allowed endpoint lookup and can be extracted by resource lookup
clients as well.  The same goes for registration attributes that are
shown as target attributes or lookup attributes.  The RD needs to
consider this in the choice of registration resource paths, as do
administrators or endpoints in their choice of attributes.
Paragraph (version A):
This example shows a simplified lighting installation that makes use
of the RD with a CoAP interface to facilitate the installation and
startup 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 that makes use
of the RD with a CoAP interface to facilitate the installation and
startup 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):
An LwM2M server is an instance of an LwM2M middleware service layer,
containing an RD (LwM2M, page 36f).
Paragraph (version B):
An LwM2M server is an instance of an LwM2M middleware service layer,
containing an RD (LwM2M, starting at page 36).