Summary: Has a DISCUSS. Needs 9 more YES or NO OBJECTION positions to pass.
Thank you for the work put into this document. I am little puzzled by the document shepherd's write-up dated more than one year ago (the responsible AD has even changed and the change is not reflected in the write-up)... while well-written this write-up seems to indicate neither a large consensus nor a deep interest by the CORE WG community. But, I am trusting the past and current responsible ADs on this aspect. Did the authors check with 6MAN WG about the new RDAO option for IPv6 NDP ? I was unable to find any 6MAN email related to this new NDP option and, after checking with the 6MAN WG chairs, they also do not remember any discussion. BTW, I appreciated the use of ASCII art to represent an entity-relationship diagram ! Please find below a couple of non-blocking COMMENTs (and I would appreciate a reply to each of my COMMENTs) and 2 blocking DISCUSS points (but only trivial actions/fixes are required). I hope that this helps to improve the document, Regards, -éric == DISCUSS == -- 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.
== COMMENTS == 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. == NITS == -- Section 2 -- The extra new lines when defining "Sector" are slighly confusing. Same applies to "Target" and "Context". This is cosmetic only.