Change:
See URL This is a new version of (and substitutes, without changes) which didn't survive its branch switch.
From , again: That's not trivial to answer, given an RD endpoint should reuse much of existing CoAP infrastructure on a device. I'm looking through the RIOT example, but that's not particularly optimized and carries a command-line tool to manage the registration in a build that uses ~80k ROM and ~25k RAM, but that's largely package buffers (which are reasonably sized for additional applications but not required for the RD; RD itself consumes about 150 bytes RAM plus unknown on stack) and probably 1k of ROM from the RD application – I can try to refine those numbers, but anything more optimized would be better to look at. Does anyone have numbers on how constrained an RD client can be?
I've drilled down a bit more on the RIOT examples' numbers: The full registration example attributes 1.7k of ROM and 1.8k of RAM to the endpoint (RIOT 6886ca54, examples/cordep; ; ), whereof 1k RAM is default stack size that's barely used AFAICT. I'd be confident to claim that full registration "can be implemented using less than 2k of ROM and 1k of RAM on Class 1 devices if the rest of CoAP stack is in place". I didn't try to get numbers for simple as the RIOT implementation is still comparatively flexible. A minimal implementation would be more taxing in terms of timer slots (one) and messages-exchanged (2-4 more per interval) than on the simpler metrics of constrainedness (I'd say +100B ROM and no RAM but the timer), but that'd depend so much on the rest of the application that numbers really make no sense. Looking for where to best put that in, I found that the sentence in question is probably 1:1 from RFC7959 (blockwise) and just has not been updated to reference RFC7228 CoRE Terminology. That paragraph has become shorter over the WG's publication history. Im proposing a change to that paragraph that reflects the current state (things have been established since this draft was started) and give a concrete reference to constrained devices (RFC7228) without going into details on what's small (follow the link for that). IMO PR is sufficient to sketch "constrained" in this context; actually giving numbers would rather open up discussions about how good they are and what else is better, and the ones I've pulled out above are ballpark level only and not published "We've done X in Y bytes" level. NAME would you consider your concerns addressed with ?
The issue of how constrained devices can be, will fluctuate with time, technology and technology prices. I am usually amazed about what people consider as vital to introduce into the code; for example: database processing with synchronized backups. So no comment from me in general. Considering the RD. In my view, this will reside in the border router. Routers usually are fully equipped with all memory you need. I have seen proposals where the RD is separated from the registered devices by at least a border router. Think of an industrial PC.
Apart from the general matter of people building kitchen sinks, would you accept the text of (what is now) ? I'd classify it as editorial-only as it mainly puts a reference where before it said 8-bit microcontrollers, and says that CoRE has done rather than plans to do, but it's prominent enough in the document I'd prefer not to merge it w/o anyone else's Go.
NAME as far as I'm concerned the new changes look good to me, as they give some precision on a minimal implementation. If it is ok I will close the item.
as said before IoT and M2M are more market identifiers. I seem to notice that Fairhair people tend to speak of IoT more than M2M 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:
1. <del> The work on Constrained RESTful Environments (CoRE) aims at realizing the REST architecture in a suitable form for the most constrained nodes (e.g., 8-bit microcontrollers with limited RAM and ROM) and networks (e.g. 6LoWPAN).  CoRE is aimed at machine-to-machine (M2M) applications such as smart energy and building automation. </del> <ins> 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 established and is used in 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