Original text:
business to the new type of users: machines.  The machines are connected directly to a mobile network using an appropriate embedded wireless interface (GSM/GPRS, WCDMA, LTE) or via a gateway providing <del> short and wide range wireless interfaces.  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.  One of the crucial enablers of such design is the ability to discover resources (and thus the endpoints they are hosted on) capable of providing required information at a given time or acting on instructions from the end users. </del>  Imagine a scenario where endpoints installed on vehicles enable tracking of the position of these vehicles for fleet management Home and building automation use case: Tie in with RD  Simple registration: Rather than coopting POSTs to /.well-known/ core, a new resource /.well-known/rd is registered.  A historical note in the text documents the change.

Reviewer comments:
See-Also: URL (as per 2020-10-08 interim) 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:
business to the new type of users: machines.  The machines are connected directly to a mobile network using an appropriate embedded wireless interface (GSM/GPRS, WCDMA, LTE) or via a gateway providing  <ins> short and wide range wireless interfaces.  The ambition in such systems is to build them from reusable components.  These speed up development and deployment, and enable shared use of machines across different applications.  One crucial component of such systems is the discovery of resources (and thus the endpoints they are hosted on) capable of providing required information at a given time or acting on instructions from the end users. </ins> Imagine a scenario where endpoints installed on vehicles enable tracking of the position of these vehicles for fleet management Home and building automation use case: Tie in with RD <ins> M2M use case: Move system design paragraph towards the topic of reusability. </ins> Simple registration: Rather than coopting POSTs to /.well-known/ core, a new resource /.well-known/rd is registered.  A historical note in the text documents the change.