Original text:
querying the described device's /.well-known/core resource directly. Data in the RD can only be provided by the device which hosts those <del> data or a dedicated Commissioning Tool (CT).  These CTs are thought to act on behalf of endpoints too constrained, or generally unable, to present that information themselves.  No other client can modify data in the RD.  Changes to the information in the RD do not propagate automatically back to the web servers from where the information originated. </del>  3.2. 4.1. <del> A (re-)starting device may want to find one or more RDs for discovery purposes.  Dependent on the operational conditions, one or more of the techniques below apply. </del>  The device may be pre-configured to exercise specific mechanisms for finding the RD:

Reviewer comments:
See-Also: URL Thank you -- I found this document to be a very friendly read. The Terminology section in particular was one of the best in recent memory. Comments: 1: "These CTs arethought to act on behalf of endpoints too constrained, or generally unable, to present that information themselves. " This reads very oddly - "thought to act on" sounds like we've seen some of these in the wild, and only have a vague idea about how they work. Does "These CTs act on behalf of endpoints too constrained, or generally unable, to present that information themselves. " work? 2: "From the system design point of view, the ambition is to design horizontal solutions that  can enable utilization of machines in different applications depending on their current availability and capabilities as well as application requirements, thus avoiding silo like solutions" - this is very buzzwordy, and I have no idea what it is actually trying to say... 3: "  A (re-)starting device may want to find one or more RDs for discovery purposes." Either I don't understand what this sentence is  trying to say, or "for discovery purposes" should be dropped....  4: "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. " What happens if device A discovers RD X, and device B discovers RD Y? Surely there has to be some sort of deterministic method so that one doesn't end up in a "split brain" type outcome? Nits: 1: " The input to an RD is composed of links and the output is composed of links constructed from the information stored in the RD." While  true, this sentence doesn't actually communicate anything useful to the reader -- I'd suggest removing it from the Abstract (note that this is just a nit). 2: "The RD is primarily a tool to make discovery operations more efficient than querying /.well-known/core on all connected devices, or across boundaries that would be limiting those operations." s/would be limiting those/that would limit those/

Revised text:
querying the described device's /.well-known/core resource directly. Data in the RD can only be provided by the device which hosts those  <ins> data or a dedicated Commissioning Tool (CT).  These CTs act on behalf of endpoints too constrained, or generally unable, to present that information themselves.  No other client can modify data in the RD. Changes to the information in the RD do not propagate automatically back to the web servers from where the information originated. </ins> 3.2. 4.1.  <ins> A (re-)starting device may want to find one or more RDs before it can discover their URIs.  Dependent on the operational conditions, one or more of the techniques below apply. </ins> The device may be pre-configured to exercise specific mechanisms for finding the RD: