Change:
This should catch users of either term, without moving away from M2M in use cases where it might be the more popular term within the field (car park management, building automation). Closes: URL
From : If we want to change that, the M2M (machine to machine) references would largely be replaced with IoT (Internet of Things) in abstract, introduction and use cases (LWM2M obviously unaffected), where "new users: machines" could be replaced with "new users: devices without physical operator interaction". NAME you wrote those texts and are probably more up to date with widespread terminology than I am – keep or change?
I don't care too much about this terminology. IoT or LWM2M are used to address a market segment. From that point of view we need to keep them both, Dear authors, below are some of the comments to the draft, they are mostly editorials with few ones that may warrant further discussion. p1 - "Web interfaces" is often used interchangeably with "REST interfaces" it'd be better to use one only, maybe the latter. p3 - "with limited RAM and ROM" Adding a reference to the expected RAM and ROM would be good. URL provides an estimation of : -> : : Which in markdown would look like: ~ p22 - Endpoint Name "mostly mandatory" is ambiguous. If the ep name is not needed to register to an RD then it is optional. If, on the other hand the RD needs an ep name and assigns one then it is mandatory ( btw if the RD assigns the ep name, shouldn't it return that information to the ep, together with the location within the rd, once the registration is successful? ) Github Issue 190 (below) raises the need to define a bit better what the ep name is supposed to contain. To me, we could keep it mandatory and add some guidelines for its creation, in OMA for example they are defined as an URN URL p22 - URL "All we know from the draft is that it is ≤ 63 bytes. But we need to say that it is a UTF-8 string. Not entirely sure we want as an endpoint name either. Same for sector." p23 - Sorry for asking, but why is base URI only mandatory when filled by the Commissioning Tool? Wouldn't it be better to make it always mandatory to avoid the differentiation? p26 - Section 5.3.1 seems like could use a bit of reordering, I can explain this in another email or call with the authors. p30 - lt, base and extra-attrs were already explained in 5.3 you might want to keep it as it is or change it by adding a reference to 5.3 and comment on the changes that the Registration Update has over the Registration. p33 - As per the document structure, there are two interfaces: registration and lookup. Shouldn't they be at the same level in the document? Registration is 5.3, shouldn't lookup be 5.5 instead of 6? p41 p42 - Just to clarify, is then the tuple [endpoint,sector] the way RD identifies endpoints? Or is it derived from the device's credentials? "A given endpoint that registers itself, needs to proof its possession of its unique (endpoint name, sector) value pair." - "An Endpoint (name, sector) pair is unique within the et of endpoints registered by the RD. An Endpoint MUST NOT be identified by its protocol, port or IP address as these may change over the lifetime of an Endpoint." p44 - typo address/Address

Discussion:
Abstract <del> In many M2M applications, direct discovery of resources is not </del> <ins> In many IoT applications, direct discovery of resources is not </ins> practical due to sleeping nodes, disperse networks, or networks where multicast traffic is inefficient.  These problems can be solved by employing an entity called a Resource Directory (RD), which contains

In the work on Constrained RESTful Environments (CoRE), a REST architecture suitable for constrained nodes (e.g. with limited RAM and ROM RFC7228) and networks (e.g. 6LoWPAN RFC4944) has been <del> established and is used in machine-to-machine (M2M) applications such as smart energy and building automation. </del> <ins> established and is used in Internet-of-Things (IoT) or machine-to- machine (M2M) applications such as smart energy and building automation. </ins> The discovery of resources offered by a constrained server is very important in machine-to-machine applications where there are no

description and discovery of resources hosted by constrained web servers is specified by the CoRE Link Format RFC6690.  However, RFC6690 only describes how to discover resources from the web server <del> that hosts them by querying "/.well-known/core".  In many M2M </del> <ins> that hosts them by querying "/.well-known/core".  In many constrained </ins> scenarios, direct discovery of resources is not practical due to sleeping nodes, disperse networks, or networks where multicast traffic is inefficient.  These problems can be solved by employing an