Original text:
4. <del> Several mechanisms can be employed for discovering the RD, including assuming a default location (e.g. on an Edge Router in a LoWPAN), assigning an anycast address to the RD, using DHCP, or discovering the RD using .well-known/core and hyperlinks as specified in CoRE Link Format RFC6690.  Endpoints that want to contact a Resource Directory (RD) can obtain candidate IP addresses of RD servers dependent on the operational conditions.  It is assumed that the nodes looking for a Resource Directory are connected to a Border Router (6LBR).  Given the various existing network installation procedures, the 6LBR is either connected or disconnected from the Internet and its services like DHCP and DNS.  Two conditions are separately considered: (1) Internet services present, and (2) no Internet services present. When no Internet services are present, the following techniques are used (in random order): Sending a Multicast to [ff02::1]/.well-known/core with ?rt=core.rd*. The receiving RDs will answer the query. The Authoritative Border Router Option (ABRO) present in the Router Advertisements (RA), contains the address of the border router. Assuming that an RD is located at the 6LBR.  Confirmation can be obtained by sending a Unicast to [6LBR]/.well-known/core with ?rt=core.rd*. Address of 6LBR is obtained from ABRO. The 6LBR can send the Resource Directory Address Option (RDAO) during neighbour Discovery containing one or more RD addresses, as explained in The installation manager can decide to preconfigure an ANYCAST address with as destination the interface of the RDs.  Clients send a discovery message to the predefined RD anycast address. Each target network environment in which some of these preconfigured nodes are to be brought up is then configured with a route for this anycast address that leads to an appropriate RD. Instead of using an ANYCAST address, a multicast address can be preconfigured.  All RD directory servers need to configure one of their interfaces with this multicast address. After installation of mDNS on all nodes, mDNS can be queried for the IP-address of RD. When Internet services are present, the techniques cited above are still valid.  Using standard techniques to obtain the addresses of DNS or DHCP servers, the RD can be discovered in the following way: Using a DNSSD query to return the Resource Records (RR) describing </del>  the service with name rd._sub._coap._udp, preferably within the <del> domain of the querying nodes. Using DHCPv6 with options to be defined. Assisting the 9 techniques above, requires manual intervention or may be done automatically. Manual management: IP address of RD is present in each node. ANYCAST address or Multicast address of RD is present in each node [see 5,6]. 6LBR receives IP address of RD for distribution via RDAO [see 4]. RD address is configured in DHCP [see 9]. DNS is configured with Resource Record specifying address of RD service [see 8]. Automatic management Multicasting to all nodes to return IP address [see 1]. Querying mDNS to receive IP address [see 7]. 6LBR contains RD service [see 2, 3]. As some of these RD addresses are just (more or less educated) guesses, endpoints MUST make use of any error messages to very strictly rate-limit requests to candidate IP addresses that don't work out.  For example, an ICMP Destination Unreachable message (and, in particular, the port unreachable code for this message) may indicate the lack of a CoAP server on the candidate host, or a CoAP error response code such as 4.05 "Method Not Allowed" may indicate unwillingness of a CoAP server to act as a directory server. </del>  4.1.

Reviewer comments:
... as promised for yesterday (oops)
ad "what is sub": it's DNS-SD's syntax for subtypes (RFC6763 Section 7.1). Might also be URL ("Subtype strings are not required to begin with an underscore, though they often do").
Looks good to me.
There are several ways specified for finding a host serving an RD: static (unicast or anycast, addresses or DNS? could contain full RD path (as in LWM2M)?) various neighbor discovery derived RDAO the border router (ABRO) "other ND options that happen to point to servers (such as RDNSS)" might-be-defined DHCPv6 options multicast (all-coap-nodes + .well-known/core; serves the path by design) There is an open issue to describe how this can be used with DNS-SD (), and it came up 2017-04-07 that discovery via mDNS by those mechanisms might be possible but is not advisable. Can we give a set of discovery options that should be supported by all general-purpose clients and servers to avoid fragmentation where one vendor's clients expect an RDAO while the other vendor's server relies on clients doing a multicast? Can we say anything about which options are recommended to use, and which are rather to be viewed as shortcuts in extremely constrained cases? Using RDNSS would be a candidate for such a statement. Maybe those cases are better described as "explicitly configured to use whichever RDNSS is announced", so this is something that's better than static configuration but still not to be expected from a generic client.
The new section 4 introduced in URL takes care of this.

Revised text:
4.  <ins> A device coming up may want to find one or more resource directories to make itself known with. The device may be pre-configured to exercise specific mechanisms for finding the resource directory: It may be configured with a specific IP address for the RD.  That IP address may also be an anycast address, allowing the network to forward RD requests to an RD that is topologically close; each target network environment in which some of these preconfigured nodes are to be brought up is then configured with a route for this anycast address that leads to an appropriate RD.  (Instead of using an anycast address, a multicast address can also be preconfigured.  The RD directory servers then need to configure one of their interfaces with this multicast address.) It may be configured with a DNS name for the RD and a resource- record type to look up under this name; it can find a DNS server to perform the lookup using the usual mechanisms for finding DNS servers. It may be configured to use a service discovery mechanism such as DNS-SD RFC6763.  The present specification suggests configuring </ins> the service with name rd._sub._coap._udp, preferably within the  <ins> domain of the querying nodes.  [_1] 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. If the address configuration of the network is performed via SLAAC, this is provided by the RDAO option rdao. If the address configuration of the network is performed via DHCP, this could be provided via a DHCP option (no such option is defined at the time of writing). Finally, if neither the device nor the network offer any specific configuration, the device may want to employ heuristics to find a suitable resource directory. The present specification does not fully define these heuristics, but suggests a number of candidates: In a 6LoWPAN, just assume the Edge 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*`. In a network that supports multicast well, discovering the RD using a multicast query for /.well-known/core as specified in CoRE Link Format RFC6690: Sending a Multicast GET to "coap://[ff02::1]/.well-known/core?rt=core.rd*".  RDs within the multicast scope will answer the query. As some of the RD addresses obtained by the methods listed here are just (more or less educated) guesses, endpoints MUST make use of any error messages to very strictly rate-limit requests to candidate IP addresses that don't work out.  For example, an ICMP Destination Unreachable message (and, in particular, the port unreachable code for this message) may indicate the lack of a CoAP server on the candidate host, or a CoAP error response code such as 4.05 "Method Not Allowed" may indicate unwillingness of a CoAP server to act as a directory server. </ins> 4.1.