Original text:
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 <del> Registration can not be executed as base attribute (which is </del>  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 In networks managed using DNS-SD, the use of DNS-SD for discovery as described in rd-using-dnssd is recommended. <del> The use of multicast discovery in mesh networks is NOT recommended. </del>  4.1.1. identify the components that constitute the RD server.  The identification refers to information about for example client-server incompatibilities, supported features, required updates and other <del> aspects.  The URI discovery address, a described in section 4 of </del>  RFC6690 can be used to find the identification. It would typically be stored in an implementation information link href or anchor was submitted as a (full) URI are returned with these attributes unmodified. <del> Above rules allow the client to interpret the response as links </del>  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 for endpoints SHOULD be expressed in path-absolute form if possible and MUST be expressed in URI form otherwise; the RD SHOULD recognize either.  The "anchor" attribute is usable for resource lookups, and, <del> if queried, MUST be for in URI form as well. </del>  Endpoints that are interested in a lookup result repeatedly or continuously can use mechanisms like ETag caching, resource As above, the impact of undesirable links depends on the extent to which the lookup client relies on the RD.  To avoid the limitations, <del> RD applications should consider prescribe that lookup clients only </del>  use the discovered information as hints, and describe which pieces of information need to be verified with the server because they impact the application's security. network manager. At the moment of installation, the network under installation is not <del> necessarily connected to the DNS infra structure.  Therefore, SLAAC </del>  IPv6 addresses are assigned to CT, RD, luminaries and sensor shown in interface-S below:

Reviewer comments:
Thanks, merged. (If questions come up around the normative-language RECOMMENDED: I agere that from the capitals NOT before it, this was already intended to be normative.)

Revised text:
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  <ins> Registration can not be executed as the base attribute (which is </ins> 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 In networks managed using DNS-SD, the use of DNS-SD for discovery as described in rd-using-dnssd is recommended.  <ins> The use of multicast discovery in mesh networks is NOT RECOMMENDED. </ins> 4.1.1. identify the components that constitute the RD server.  The identification refers to information about for example client-server incompatibilities, supported features, required updates and other  <ins> aspects.  The URI discovery address, as described in section 4 of </ins> RFC6690 can be used to find the identification. It would typically be stored in an implementation information link href or anchor was submitted as a (full) URI are returned with these attributes unmodified.  <ins> The above rules allow the client to interpret the response as links </ins> 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 for endpoints SHOULD be expressed in path-absolute form if possible and MUST be expressed in URI form otherwise; the RD SHOULD recognize either.  The "anchor" attribute is usable for resource lookups, and,  <ins> if queried, MUST be in URI form as well. </ins> Endpoints that are interested in a lookup result repeatedly or continuously can use mechanisms like ETag caching, resource As above, the impact of undesirable links depends on the extent to which the lookup client relies on the RD.  To avoid the limitations,  <ins> RD applications should consider prescribing that lookup clients only </ins> use the discovered information as hints, and describe which pieces of information need to be verified with the server because they impact the application's security. network manager. At the moment of installation, the network under installation is not  <ins> necessarily connected to the DNS infrastructure.  Therefore, SLAAC </ins> IPv6 addresses are assigned to CT, RD, luminaries and sensor shown in interface-S below: