Change:
I had hoped we could come up with something that preserves HTML's semantics of both dd pertaining to the single dt, but this solves the ugly plain text newlines and is probably the best that can be done without larger changes in the RFC toolchain. Thanks, merged.
The nits of URL COMMENT can't currently be addressed easily; looking for help at URL which currently blocks this. Thank you for the work put into this document. As you can noticed, I have cleared my 2 DISCUSS points (kept below for archive) thank you also for replying to my comments over email. BTW, I appreciated the use of ASCII art to represent an entity-relationship diagram ! I hope that this helps to improve the document, -- Section 4.1 -- It will be trivial to fix, in IPv6 address configuration (SLAAC vs. DHCP) is orthogonal to DHCP 'other-information'. E.g., even if address is configured via SLAAC, DHCPv6 other-information can be used to configure the Recursive DNS Server (or possibly the RD). -- Section 4.1.1 -- Another trivial DISCUSS to fix: in which message is this RDAO sent ? I guess unicast Router Advertisement but this MUST be specified. In general, I wonder how much interactions and exchanges of ideas have happened in the long history of this document with the DNSSD (DNS Service Discovery) Working Group that has very similar constraints (sleeping nodes) and same objectives. -- Section 2 -- To be honest: I am not too much an APP person; therefore, I was surprised to see "source address (URI)" used to identify the "anchor="... I do not mind too much the use of "destination address (URI)" as it is really a destination but the anchor does not appear to me as a "source address". Is it common terminology ? If so, then ignore my COMMENT, else I suggest to change to "destination URI" and simply "anchor" ? -- Section 3.3 -- Should the lifetime be specified in seconds at first use in the text? -- Section 3.6 -- Is the use of "M2M" still current? I would suggest to use the word "IoT" esp when 6LBR (assuming it is 6LO Border Router) is cited later. Please expand and add reference for 6LBR. Using 'modern' technologies (cfr LP-WAN WG) could also add justification to section 3.5. -- Section 4.1 -- About "coap://[MCD1]/.well-known/core?rt=core.rd*", what is the value of MCD1 ? The IANA section discuss about it but it may help the reader to give a hint before (or simply use TBDx that is common in I-D). Any reason to use "address" rather than "group" in "When answering a multicast request directed at a link-local address" ? Later "to use one of their own routable addresses for registration." but there can be multiple configured prefixes... Which one should the RD select ? Should this be specified ? As a co-author of RFC 8801, I would have appreciated to read PvD option mentionned to discover the RD. Any reason why PvD Option cannot be used ? -- Section 4.1.1 -- I suggest to swap the reserved and lifetime fields in order to be able to use a lifetime in units of seconds (to be consistent with other NDP options). -- Section 5 -- May be I missed it, but, can an end-point register multiple base URI ? E.g., multiple IPv6 addresses. -- Section 9.2 -- For information, value 38 is already assigned to RFC 8781. -- Section 2 -- The extra new lines when defining "Sector" are slighly confusing. Same applies to "Target" and "Context". This is cosmetic only.

Discussion:
In the context of an RD, a sector is a logical grouping of <del> endpoints. The abbreviation "d=" is used for the sector in query parameters for compatibility with deployed implementations. </del> <ins> endpoints.  The abbreviation "d=" is used for the sector in query parameters for compatibility with deployed implementations. </ins> Endpoint (EP) is a term used to describe a web server or client in

The target of a link is the destination address (URI) of the link. It is sometimes identified with "href=", or displayed as "<target>".  Relative targets need resolving with respect to the <del> Base URI (section 5.2 of RFC3986). This use of the term Target is consistent with RFC8288's use of the term. </del> <ins> Base URI (section 5.2 of RFC3986).  This use of the term Target is consistent with RFC8288's use of the term. </ins> The context of a link is the source address (URI) of the link, and describes which resource is linked to the target.  A link's context is made explicit in serialized links as the "anchor=" <del> attribute. This use of the term Context is consistent with RFC8288's use of the term. </del> <ins> attribute.  This use of the term Context is consistent with RFC8288's use of the term. </ins> A resource in the RD containing registration resources.