Draft: draft-ietf-core-resource-directory

Commentary: See This is a new version of ( and substitutes , without changes ) which did n'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  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  examples ' numbers : The full registration example attributes 1.7k of ROM and 1.8k of RAM to the endpoint (  , 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 did n't try to get numbers for simple as the  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 . I m 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 . 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 . 
 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 M2 M are more market identifiers . I seem to notice that Fairhair people tend to speak of IoT more than M2 M
Paragraph (version A):
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.
Paragraph (version B):
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.