Original text:
The RD is primarily a tool to make discovery operations more efficient than querying /.well-known/core on all connected devices, <del> or across boundaries that would be limiting those operations. </del>  It provides information about resources hosted by other devices that could otherwise only be obtained by directly querying the /.well- 3.4. Registration Base URIs can contain link-local IP addresses.  To be <del> usable across hosts, those can not be serialized to contain zone </del>  identifiers (see RFC6874 Section 1). Link-local addresses can only be used on a single link (therefore RD <del> servers can not announce them when queried on a different link), and </del>  lookup clients using them need to keep track of which interface they got them from. 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 the base attribute (which is mandatory for HTTP) can not be used there.  In all definitions in </del>  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, it MUST include the base parameter in the registration to provide a valid network path. <del> A registrant that can not be reached by potential lookup clients at the address it registers from (e.g. because it is behind some form of Network Address Translation (NAT)) MUST provide a reachable base address with its registration. </del>  If the Base URI contains a link-local IP literal, it MUST NOT contain a Zone Identifier, and MUST be local to the link on which the registration request is received. Endpoints that register with a base that contains a path <del> component can not meaningfully use RFC6690 Link Format due to </del>  its prevalence of the Origin concept in relative reference resolution.  Those applications should use different representations of links to which limitedlinkformat is not using DELETE, and to perform further operations beyond the scope of this specification. <del> These operations are described below. </del>  5.3.1. given endpoint name.  This applies both to registration and later to operations on the registration resource.  It is immaterial whether the client is the registrant-ep itself or a CT is doing the <del> registration: The RD can not tell the difference, and CTs may use </del>  authorization credentials authorizing only operations on that particular endpoint name, or a wider range of endpoint names. In those situations, the registrant needs to be careful to authenticate the RD as well.  The registrant needs to know in advance which AS, audience and scope values indicate an RD it may trust for <del> this purpose, and can not rely on the RD to provide AS address and </del>  token details.  (In contrast, in the other scenarios it may try to register, and follow the pointers the RD gives it as to which credentials it needs to provide in order to perform its

Reviewer comments:
Will merge before the interim to have a discussion on the big stuff with the small stuff out of the way.

Revised text:
The RD is primarily a tool to make discovery operations more efficient than querying /.well-known/core on all connected devices,  <ins> or across boundaries that would limit those operations. </ins> It provides information about resources hosted by other devices that could otherwise only be obtained by directly querying the /.well- 3.4. Registration Base URIs can contain link-local IP addresses.  To be  <ins> usable across hosts, those cannot be serialized to contain zone </ins> identifiers (see RFC6874 Section 1). Link-local addresses can only be used on a single link (therefore RD  <ins> servers cannot announce them when queried on a different link), and </ins> lookup clients using them need to keep track of which interface they got them from. 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 cannot be executed as the base attribute (which is mandatory for HTTP) cannot be used there.  In all definitions in </ins> 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, it MUST include the base parameter in the registration to provide a valid network path.  <ins> A registrant that cannot be reached by potential lookup clients at the address it registers from (e.g. because it is behind some form of Network Address Translation (NAT)) MUST provide a reachable base address with its registration. </ins> If the Base URI contains a link-local IP literal, it MUST NOT contain a Zone Identifier, and MUST be local to the link on which the registration request is received. Endpoints that register with a base that contains a path  <ins> component cannot meaningfully use RFC6690 Link Format due to </ins> its prevalence of the Origin concept in relative reference resolution.  Those applications should use different representations of links to which limitedlinkformat is not using DELETE, and to perform further operations beyond the scope of this specification.  <ins> The operations on the Registration Resource are described below. </ins> 5.3.1. given endpoint name.  This applies both to registration and later to operations on the registration resource.  It is immaterial whether the client is the registrant-ep itself or a CT is doing the  <ins> registration: The RD cannot tell the difference, and CTs may use </ins> authorization credentials authorizing only operations on that particular endpoint name, or a wider range of endpoint names. In those situations, the registrant needs to be careful to authenticate the RD as well.  The registrant needs to know in advance which AS, audience and scope values indicate an RD it may trust for  <ins> this purpose, and cannot rely on the RD to provide AS address and </ins> token details.  (In contrast, in the other scenarios it may try to register, and follow the pointers the RD gives it as to which credentials it needs to provide in order to perform its