Change:
When answering a multicast request directed at a link-local group, the RD may want to respond from a routable address; this makes it easier for registrants to use one of their own routable addresses for <del> registration. </del> <ins> registration.  When RFC6724 is used for source address selection, this can be achieved by applying the changes of its Section 10.4, picking public addresses in its Section 5 Rule 7, and superseding rule 8 with preferring the source address's precedence. </ins> 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

Discussion:
See-Also: URL I've gone though the rules of source address selection and think what I'm doing here is a) legal and b) produces the right results (this works is because 10.4 places fe80 and :: in the same label, and the the limited precedence for fe80 puts them out of the game in the modified rule 8), but I'll add this to the focus points of the 6man mail. 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.