Original text:
This and the following sections define the required set of REST interfaces between a Resource Directory (RD), endpoints and lookup <del> clients.  Although the examples throughout theses sections assume the </del>  use of CoAP RFC7252, these REST interfaces can also be realized using HTTP RFC7230.  In all definitions in these sections, both CoAP response codes (with dot notation) and HTTP response codes (without

Reviewer comments:
See . 03e31b84a3e77fbcc2fc131f2cf8d6c3a4b83be3 might be worth reading in patch form, for the rest the preview at https://core-URL is probably better suited for reviewing.
: He has a point; if we're to change that, it could be General operation (would get the general text of what was 5. Resource Directory) 4.1 (was 4) Finding a Resource Directory .. Resource Directory Address Option (RDAO) 4.2 (was 5.1) Payload Content Formats 4.3 (was 5.2) URI Discovery (was 5.3.) Registration 5.1 (was 5.3.1) Simple Registration 5.2 (was 5.3.2) Third-party registration 5.3 (was 5.4) Operations on the Registration Resource .. Registration Update .. Registration Removal .. Further operations (as it was) RD Lookup .. Resource lookup .. Lookup filtering .. Resource lookup examples Yay or nay?
Puts lookup and regitration at same level. That is good. Title of 4 : It is a bit of a hodge-podge, RD discovery and syntax?
Readability is improved. 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

Revised text:
This and the following sections define the required set of REST interfaces between a Resource Directory (RD), endpoints and lookup  <ins> clients.  Although the examples throughout these sections assume the </ins> use of CoAP RFC7252, these REST interfaces can also be realized using HTTP RFC7230.  In all definitions in these sections, both CoAP response codes (with dot notation) and HTTP response codes (without