on its configuration. The registration message is a list of links to registration resources <del> of the endpoints that belong to that group.  The registration resources MAY be located on different hosts than the group hosting RD.  In that case the endpoint link points to the registration resource on the other RD.  The commissioning tool SHOULD NOT attempt to enter a foreign registration in a group unless it found it in the group RD's lookup results, or has other reasons to assume that the foreign registration will be accepted. </del>  The commissioning tool SHOULD not send any target attributes with the links to the registration resources, and the resource directory attempt to dereference or manipulate them. A Resource Directory can report endpoints or groups in lookup that <del> are not hosted at the same address.  While the setup and management of such a distributed system is out of scope for this document, lookup clients MUST be prepared to see arbitrary URIs as registration or group resources in the results. </del>  For groups, a Resource Directory as specified here does not provide a lookup mechanism for the resources that can be accessed on a group's all groups: The following example shows a client performing a lookup for all <del> endpoints in a particular group, with one endpoint hosted by another RD: The following example shows a client performing a lookup for all </del> groups the endpoint "node1" belongs to: The following example shows a client performing a paginated resource

Both drafts for the examples (HEAD^ and [129]) contributed more to confusion than to clarification. Leaving absolute references in to have extensibility, but the text now says that it doesn't mean much until specified. (As discussed in Monday's telco). [129]: URL
Updated as I missed some text on the same topic.
Christian, thanks. this looks beter. schreef op 2018-06-27 15:47: Links: [1] URL [2] URL [3] URL
compare on group for remote endpoint. Should this do the remote lookup or can it just be ignored for attribute comparison I am not quite sure what you mean by attribute comparison. When it is about registration attributes, no remote lookup seems necessary to me. If I do the lookup of /rd/gp-lookup?rt=foobar And one of the groups has the following /rd-group/xxx https://otherrd/rd-group/yyy I would follow the local group definition to find out if the resource type is defined on some resource in the group, however the question is do I need to go and query the other group which is not local in order to do the same tree walking when doing attribute comparisons. Not that this applies to remote endpoint registrations in a group as well. Thanks for the example. Indeed following the latest text, the comparison should include the remote registration. The text could include words like tree walking is done locally only; personally I would not be too happy about that. Apparently the text should say something about remote groups and tree walking. I will add the issue to github.
Let's not go into specifying distributed RDs but just keep the door open to not have clients break when one is even though it behaves like a regular RD (see longer comment at ). Concrete proposal from there: Would it help if we changed the example to say GET URL Res: 2.05 Content ;con="coap://[2001:db8:3::123]:61616"; ep="node1";et="URL";ct="40";lt="600", ;con="coap://[2001:db8:3::124]:61616"; ep="node2";et="URL";ct="40";lt="600" ? It would just indicate that the registration resource is hosted by the same RD but on another protocol (presumably because the endpoint registered using coap+tcp, and that Location can't just jump protocols).
The semantics of having a foreign URI in the endpoint lookup or group are now completely left to further specification since / 20cf0880957eade1d8fee1c4cf0afcb3c2683849. Hello Jim, Peter, We should look at why we are requiring idempotency here. From what I can tell, this is because CoAP servers and clients are easier to implement if they can rely on the operation to be idempotent, but they are looking at the very same request being sent again in a relatively short time frame. An additional use case here is stability in presence of "semi-simple" clients that POST their .well-known/core to the directory resource every few hours and never try to parse the Location returned. If those change the registration resource address every time, an observation on the endpoint lookup becomes needlessly noisy. As long as those are the cases we consider, I think that it is sufficient to specify that the registration operation must return the same response to a CoAP request with the same requester / security context, code, options and payload within EXCHANGE_LIFETIME. The concern for observation stability is more a matter of implementation quality, where me can recommend but need not specify. I think the more convenient thing to do is to say that resources are compared against the full path, and registrations and group resources (they can be matched too) are matched against whatever is returned in endpoint lookup. That would be more intuitive to the user of the lookup (matching against what is returned). I think that this is out of scope for RD itself. What I'd like to have in RD is the text that ensures that clients will not get upset when they see absolute URIs in group or endpoint lookups. We are not actually describing a distributed RD here, this is only to keep the door open for such extensions. Would it help if we changed the example to say GET URL Res: 2.05 Content ;con="coap://[2001:db8:3::123]:61616"; ep="node1";et="URL";ct="40";lt="600", ;con="coap://[2001:db8:3::124]:61616"; ep="node2";et="URL";ct="40";lt="600" ? It would just indicate that the registration resource is hosted by the same RD but on another protocol (presumably because the endpoint registered using coap+tcp, and that Location can't just jump protocols). My expectation is that lt= is the registered value and never decreases. (For an additional value that indicates where the registration is in its lifetime, I've suggested lt-age in draft-amsuess-core-rd-replication-01 -- but only because there's an application for it there). Having lt decrease is problematic with caching (admittedly, so is lt-age). What use cases do we have for exposing a lifetime in the endpoint lookup at all? (If we have none, an RD might just as well not display a lifetime). ep=node1 would be URL not technically illegal (the template would put the ep in extra-attrs, and the server hopefully not store it there); it is an attribute that is not changing and therefore SHOULD NOT be included in the update by the client. A changed ep would not create a new registration (we're at a registration resource already), but simply be refused. The text is already pretty explicit: "If the parameter is set in an update, it is stored by the RD as the new Base URI under which to interpret the links of the registration, following the same restrictions as in the registration. If the parameter is not set and was set explicitly before, the previous context value is kept unmodified. If the parameter is not set and was not set explicitly before either, the source address and source port of the update request are stored as the context." This allows for clients that do not keep a good eye on their addresses but have their OS pick the latest one. Note that nobody other than the endpoint (or CT if created by one) may manipulate a registration resource. (If we wanted to allow other hosts to manipulate a different endpoint's registration, we'd need something like a ?ct=keep or change in semantics to allow that -- but I'd like to have a good reason to do that in the first place). It should be neither; that request is empty and so is the response. The RD will need to probe for the content format of its own (possibly trying its preferred content format first, falling back to an empty accept or 40). The best equivalent of "and look there expecting this content format" would be HTTP's link header (a la 'POST /.w-k/c?ep=node1, Link: ;ct="40 64 504"'), and we can't do that in CoAP, at the very least not in a simple registration. I think that the more important question behind is of whether the RD should (or may) wait with a response until it has fetched the .w-k/c of the endpoint. The example shows "respond first, then ask details", which we might consider prescribing given that highly constrained clients might not manage to multi-task the request and the response. (Dealing Sorry I'm Busy until their pending request is answered or expired). Best regards Christian (updating the issue tracker in parallel) To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom

on its configuration. The registration message is a list of links to registration resources  <ins> of the endpoints that belong to that group.  The CT can use any URI reference discovered using endpoint lookup from the same server or obtained by registering an endpoint using third party registration and enter it into a group.  The use of other URIs is not specified in this document and can be defined in others. </ins> The commissioning tool SHOULD not send any target attributes with the links to the registration resources, and the resource directory attempt to dereference or manipulate them. A Resource Directory can report endpoints or groups in lookup that  <ins> are not hosted at the same address.  Lookup clients MUST be prepared to see arbitrary URIs as registration or group resources in the results and treat them as opaque identifiers; the precise semantics of such links are left to future specifications. </ins> For groups, a Resource Directory as specified here does not provide a lookup mechanism for the resources that can be accessed on a group's all groups: The following example shows a client performing a lookup for all  groups the endpoint "node1" belongs to: The following example shows a client performing a paginated resource


optionally a sector (abbreviated "d" for historical reasons),  zero or one multicast addresses expressed as a base URI ("base"), and is composed of zero or more registrations (endpoints). a lifetime ("lt"), <del> a registration resource location inside the RD ("loc"), </del>  optionally a sector ("d")

This executes the renaming of con to base and domain to sector as agreed on in the last meeting. Two follow-up commits create consistency in the ER diagram (which had to be modified anyway for the renaming) and the accompanying text, both internally (describe groups the same way as resources) and within the document (we describe several properties of a group that the ER did not show).

optionally a sector (abbreviated "d" for historical reasons), <ins> a group resource location inside the RD ("href"), </ins> zero or one multicast addresses expressed as a base URI ("base"), and is composed of zero or more registrations (endpoints). a lifetime ("lt"),  <ins> a registration resource location inside the RD ("href"), </ins> optionally a sector ("d")


the registration or update interface.  The registration interface MUST be implemented to be idempotent, so that registering twice with the same endpoint parameters ep and d (sector) does not create <del> multiple registration resources.  A new registration resource may be created at any time to supersede an existing registration, replacing the registration parameters and links. </del>  The following rules apply for an update identified by a given (ep, d) value pair:

The rules laid out below the removed sentence are pretty clear, but the removed sentence itself can be read to contradict them ("may be created at any time to supersede an existing registration") or at best does not add anything. Assuming it was left over from an older version (before the rules were added), I suggest we remove it. NAME that's your section of expertise. Please merge if you agree or reject otherwise.

the registration or update interface.  The registration interface MUST be implemented to be idempotent, so that registering twice with the same endpoint parameters ep and d (sector) does not create  <ins> multiple registration resources. </ins> The following rules apply for an update identified by a given (ep, d) value pair:


Endpoint and group lookups result in links to registration resources and group resources, respectively.  Endpoint registration resources are annotated with their endpoint names (ep), domains (d, if present) <del> and context (con); the lifetime (lt) is not reported.  Additional endpoint attributes are added as link attributes to their endpoint link unless their specification says otherwise.  Group resources are annotated with their group names (gp), domain (d, if present) and multicast address (con, if present). </del>  While Endpoint Lookup does expose the registration resources, the RD does not need to make them accessible to clients.  Clients SHOULD NOT changes from -13 to -14  Registration management moved to appendix A Minor editorial changes

Populates missing descriptions in the IANA template for resource types, but primarily adds new resource types (URL and URL) to the lookup results.
(This was quickly but a bit vaguely agreed on in the last meeting; will merge if nobody objects.)
This was discussed in the last meeting but did not result in an action item; will check whether we agreed to do this (AFAIR we did) and add the text for it.
The right place is in the management example. I hesitated but did not do it chrysn schreef op 2018-06-27 11:51: Links: [1] URL [2] URL
Done with in 801a4352587f4354d57949ab7cb427600a139158.

Endpoint and group lookups result in links to registration resources and group resources, respectively.  Endpoint registration resources are annotated with their endpoint names (ep), domains (d, if present)  <ins> and context (con) as well as a constant resource type (rt="core.rd- ep"); the lifetime (lt) is not reported.  Additional endpoint attributes are added as link attributes to their endpoint link unless their specification says otherwise. Group resources are annotated with their group names (gp), domain (d, if present) and multicast address (con, if present) as well as a constant resource type (rt="core.rd-gp"). </ins> While Endpoint Lookup does expose the registration resources, the RD does not need to make them accessible to clients.  Clients SHOULD NOT changes from -13 to -14 <ins> Introduced resource types core.rd-ep and core.rd-gp </ins> Registration management moved to appendix A Minor editorial changes


_who_ "hosts" something. In link-format serialization, it is expressed in the "anchor" <del> attribute.  There, it can be a relative reference, in which case it gets resolved against the URI of the ".well-known/core" document it was obtained from.  It defaults to that document's URI. </del>  A link target URI: It defines the destination of the relation (eg. _what_ is hosted), and is the topic of all target attributes. In link-format serialization, it is expressed between angular brackets, and sometimes called the "href". <del> If there is an anchor attribute present and the link is serialized in RFC6690 link format, this document will require that the link is an absolute reference to avoid the ambiguities outlined in resolution- rules. Otherwise, it can be serialized as a relative URI, and gets resolved against the document's URI. </del> Other target attributes (eg. resource type (rt), interface (if), cor content-type (ct)).  These provide additional information about the target URI. parameter or constructed implicitly from the requester's network address. <del> Documents in RFC6690 Link Format SHOULD NOT contain links in which resolving the target literal against the base URI gives a different result than resolving it against the resolved anchor; this is to avoid the ambiguities described in resolution-rules. Entries in which there is no anchor attribute, entries in which the target is an absolute reference and entries in which both the target and the anchor start with a slash ("/") </del>  <del> never cause that kind of ambiguity. </del>  The registration request interface is specified as follows: persistent port for the outgoing registration in order to provide the NAT gateway with a valid network address for replies and incoming requests.  Endpoints that register with a <del> con that contains a path component need to carefully consider the rules of relative URI resolution.  Typically, links </del>  submitted by such an endpoint are of the "path-noscheme" (starts with a a path not preceded by a slash, precisely defined in RFC3986 Section 3.3) form.

This responds to a comment from Jim on the use of the term "Origin" in RFC6690 which I had previously missed. Given that the old 6690-style documents are thus a lot less powerful, the text goes from "Submitted documents should be the same in both interpretations, and the RD can use either" to "Submitted documents should be the same, and the RD interprets them 8288 style". A paragraph was added that defines precisely what it means to interpret it 8288 style. Several outdated references to where resolution happens have been removed. The "8288 style interpretation" is called Modernized Link Format; I'd be happy of any better names, but am convinced we need to name it somehow to avoid vaguely describing the same thing again and again.

_who_ "hosts" something. In link-format serialization, it is expressed in the "anchor"  <ins> attribute.  It defaults to that document's URI. </ins> A link target URI: It defines the destination of the relation (eg. _what_ is hosted), and is the topic of all target attributes. In link-format serialization, it is expressed between angular brackets, and sometimes called the "href".  Other target attributes (eg. resource type (rt), interface (if), cor content-type (ct)).  These provide additional information about the target URI. parameter or constructed implicitly from the requester's network address.  <ins> Link format documents submitted to the resource directory are interpreted as Modernized Link Format (see modern6690) by the RD.  A registree-ep SHOULD NOT submit documents those interpretation according to RFC6690 and modern6690 differs and RFC6690 interpretation is intended to avoid the ambiguities described in resolution-rules. </ins>  <ins> In practice, most links (precisely listed in modern-safe) can be submitted without consideration for those details. </ins> The registration request interface is specified as follows: persistent port for the outgoing registration in order to provide the NAT gateway with a valid network address for replies and incoming requests.  Endpoints that register with a  <ins> con that contains a path component can not meaningfully use RFC6690 Link Format due to its prevalence of the Origin concept in relative reference resolution; they can submit payloads for interpretation as Modernized Link Format.  Typically, links </ins> submitted by such an endpoint are of the "path-noscheme" (starts with a a path not preceded by a slash, precisely defined in RFC3986 Section 3.3) form.


luminaries can learn to which groups they belong, and enable their interface for the multicast address. <del> The luminary, knowing its sector, queries the RD for the endpoint with rt=light and d=R2-4-015.  The RD returns all endpoints in the sector. </del>  <del> Knowing its own IPv6 address, the luminary discovers its endpoint name.  With the endpoint name the luminary queries the RD for all groups to which the endpoint belongs. From the base parameter value, the luminary learns the multicast address of the multicast group. </del>  Alternatively, the CT can communicate the multicast address directly to the luminaries by using the "coap-group" resource specified in

The luminary of the example previously discovered its group addresses by looking up its own registration resource (which it did not know because it was entered by a CT), and via that its groups. As long as the device does not need to know its own registration resource, the same can be achieved in a single step by looking up groups that contain it directly, based on the address it would originally have compared the endpoint results against. Closes: URL Like with : NAME that's the example where you know all the rationales, feel free to merge or discard.
In the luminary example, the device first does an endpoint lookup to find its ep by comparing values, and then a group lookup to find its groups. That is unnecessary; by the rules of lookup, it could just do a group lookup with base= its own address and get the same result in one step.

luminaries can learn to which groups they belong, and enable their interface for the multicast address.  <ins> The luminary, knowing its sector and own IPv6 address, looks up the groups containing light resources it is assigned to: </ins>  <ins> From the returned base parameter value, the luminary learns the multicast address of the multicast group. </ins> Alternatively, the CT can communicate the multicast address directly to the luminaries by using the "coap-group" resource specified in


The expression "a URI-reference is _resolved against_ a base URI" is used to describe the process of RFC3986 Section 5.2. <del> Noteworthy corner cases are that resolving an absolute URI against any base URI gives the original URI, and that resolving an empty URI reference gives the base URI. </del>  A web entity that stores information about web resources and scheme and authority information about an Endpoint.  The Registration Base URI is provided by the Endpoint at registration time, and is used by the Resource Directory to resolve relative <del> references inside the registration into absolute URIs. </del>  The target of a link is the destination address (URI) of the link. While the link targets in this discovery step are often expressed in path-absolute form, this is not a requirement.  Clients SHOULD <del> therefore accept URIs of all schemes they support, both in absolute and relative forms, and not limit the set of discovered URIs to those hosted at the address used for URI discovery. </del>  The URI Discovery operation can yield multiple URIs of a given resource type.  The client can use any of the discovered addresses A relative href value denotes the path to the registration resource of the Endpoint.  When pointing to a registration resource on a <del> different RD, the href value is an absolute URI. </del>  6.2. Links that did not have an anchor attribute are therefore returned with the (explicitly or implicitly set) base URI of the registration <del> as the anchor.  Links whose href or anchor was submitted as an absolute URI are returned with respective attributes unmodified. </del>  Above rules allow the client to interpret the response as links without any further knowledge of what the RD does.  The Resource match the target reference of the resource link itself, but also the registration resource of the endpoint that registered it, or any group resource that endpoint is contained in.  Queries for resource <del> link targets MUST be in absolute form and are matched against a resolved link target.  Queries for groups and endpoints SHOULD be expressed in path-absolute form if possible and MUST be expressed in absolute form otherwise; the RD SHOULD recognize either. </del>  Clients that are interested in a lookup result repeatedly or continuously can use mechanisms like ETag caching, resource 13.  changes from -13 to -14 Rename "registration context" to "registration base URI" (and

The previous text did not match my intentions, back when I thought of "absolute URIs" as "URI references that are already in URI form", where actually they are a construct intended for protocols to express that the fragment part does not take part in the dereferencing process. Closes: URL Will merge soon unless it conflicts with someone's private branches or draws other negative comments.
+1 for awareness of the difference between a URI and a reference to a URI
Oh, I see. But then I've been using the term wrong. In ABNF terminology for RFC3986, there's a "URI" (thing-with-scheme), a "relative-ref" and a "URI-reference" (which can be relative or not). I had thought it wise to talk of absolute URIs when I mean thing-with-scheme to disambiguate "URI" from "URI-reference", unaware that "absolute-URI" is even stricter. As we are not designing a communication protocol, we should not use the term "absolute URI", but talk of "URI" or (if ambiguous) a "complete URI". I'll need to patch that in the draft, sorry for the mess and thanks for pointing it out.

The expression "a URI-reference is _resolved against_ a base URI" is used to describe the process of RFC3986 Section 5.2.  <ins> Noteworthy corner cases are that if the URI-reference is a (full) URI and resolved against any base URI, that gives the original full URI, and that resolving an empty URI reference gives the base URI without any fragment identifier. </ins> A web entity that stores information about web resources and scheme and authority information about an Endpoint.  The Registration Base URI is provided by the Endpoint at registration time, and is used by the Resource Directory to resolve relative  <ins> references inside the registration into URIs. </ins> The target of a link is the destination address (URI) of the link. While the link targets in this discovery step are often expressed in path-absolute form, this is not a requirement.  Clients SHOULD  <ins> therefore accept URIs of all schemes they support, both as URIs and relative references, and not limit the set of discovered URIs to those hosted at the address used for URI discovery. </ins> The URI Discovery operation can yield multiple URIs of a given resource type.  The client can use any of the discovered addresses A relative href value denotes the path to the registration resource of the Endpoint.  When pointing to a registration resource on a  <ins> different RD, the href value is a URI. </ins> 6.2. Links that did not have an anchor attribute are therefore returned with the (explicitly or implicitly set) base URI of the registration  <ins> as the anchor.  Links whose href or anchor was submitted as a (full) URI are returned with respective attributes unmodified. </ins> Above rules allow the client to interpret the response as links without any further knowledge of what the RD does.  The Resource match the target reference of the resource link itself, but also the registration resource of the endpoint that registered it, or any group resource that endpoint is contained in.  Queries for resource  <ins> link targets MUST be in URI form (ie. not relative references) and are matched against a resolved link target.  Queries for groups and endpoints SHOULD be expressed in path-absolute form if possible and MUST be expressed in URI form otherwise; the RD SHOULD recognize either. </ins> Clients that are interested in a lookup result repeatedly or continuously can use mechanisms like ETag caching, resource 13. <ins> changes from -14 to -15 Talk of "relative references" and "URIs" rather than "relative" and "absolute" URIs.  (The concept of "absolute URIs" of RFC3986 is not needed in RD). </ins> changes from -13 to -14 Rename "registration context" to "registration base URI" (and


RD is provided using the CoRE Link Format. A Registrant-EP MAY keep concurrent registrations to more than one RD <del> at the same time, but that is not expected to supported by typical EP implementations.  Any such registrations are independent of each other. For this case to occur, the EP would need to be explicitly configured to register multiple times: either by having multiple discovery mechanisms or addresses configured (which are not merely fallbacks to each other), or by having several sets of registration data to register with (eg. multiple endpoint names). </del>  3.3.

The implementors in RIOT asked about whether a registrant could possibly maintain multiple registrations at different RDs, and how they interact. I think what I'm saying in this PR is obvious (though not redundant, as we don't talk about that topic otherwise), but given it was asked about, it's probably not. What are your opinions?
(Text updated after I learned more about what they thought was expected from Registrant-EPs.)
Shortened and merged.
A registrant-ep cannot be forbidden to register with multiple RDs anyway. May be a bit too much text for an obvious fact.

RD is provided using the CoRE Link Format. A Registrant-EP MAY keep concurrent registrations to more than one RD  <ins> at the same time if explicitly configured to do so, but that is not expected to be supported by typical EP implementations.  Any such registrations are independent of each other.  The usual expectation when multiple discovery mechanisms or addresses are configured is that they constitute a fallback path for a single registration. </ins> 3.3.


GET <del> {+type-lookup-location}{?d,res,ep,gp,et,rt,page,count,resource- param} </del>  Domain (optional).  Used for domain, group, endpoint and resource lookups. <del> resource (optional).  Used for domain, group, endpoint and resource lookups. </del> gp := Group name (optional).  Used for endpoint, group and resource lookups.

This solves issue ("nobody really knows what the parameter is for") by removing the parameter altogether.
We are not clear on how to use "res"in a lookup query. For example, what does xx represent in this query? GET /example/rd-lookup-gp?res=xx I couldn't find text to explain. Is it expected to be the address of a resource, like href or anchor+href ?
Hi Michael, From version 04 to the current version the ?res has undergone a change In the -10 example the return is ;rt=sensor;ct=60 where I might have expected ;rt=sensor;ct=60 But I cannot check because we do not know the contents of the RD and hypothesizing now: ?res=xx would have returned nothing unless there was an entry like ;rt=sensor;ct=60 and even more confusing we have something called resource-param. In an earlier e-mail Christian already suggested to modify that to link-param if I remember correctly. So yes, I can concur with you and agreeing with the existence of confusion. Peter Michael Koster schreef op 2017-05-05 16:01:
The last I had in mind about the parameter a short mention in the phone call -- to me it looked like a relic whose role has been superseded by ins et al. It is now the first time I perceive it as a parameter that does anything with the path. What is the intended overall purpose of res=? And what do you mean by the contents of the RD?
Hi Chris, I assume this a sequel to my answer to Michael. May be not..... The contents of the RD are all the information about ep, resources, etc. stored into the RD by whatever means. My speculation about res=xx means that it indicates filtering on resource paths which start with /xx/...... Peter
For such filtering, there is already , which is covered by the query parameter referencing RFC 6690. NAME of the RD": I see. Going through all the references in the document, it seems to me that the examples you mentioned are not about the lookup parameter, but just the arbitrary resource names in the pagination example. I'd suggest removing the parameter altogether (PR ) unless its use resurfaces.
I think "res" (for resource) may be useful as a link target attribute for tagging resources, and in that context could also be used as a lookup parameter. If we don't plan to create "res" as a target attribute we should remove it from the document. If we do want to define a new target attribute, maybe we can come up with something more descriptive than "res"...

GET  <ins> {+type-lookup-location}{?d,ep,gp,et,rt,page,count,resource-param} </ins> Domain (optional).  Used for domain, group, endpoint and resource lookups.  gp := Group name (optional).  Used for endpoint, group and resource lookups.


important in machine-to-machine applications where there are no humans in the loop and static interfaces result in fragility.  The discovery of resources provided by an HTTP Web Server is typically <del> called Web Linking RFC5988.  The use of Web Linking for the </del>  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 synonym for "octet". This specification requires readers to be familiar with all the terms <del> and concepts that are discussed in RFC3986, RFC5988 and RFC6690. </del>  Readers should also be familiar with the terms and concepts discussed in RFC7252.  To describe the REST interfaces defined in this specification, the URI Template format is used RFC6570. 3.2. The resource directory architecture is illustrated in fig-arch.  A <del> Resource Directory (RD) is used as a repository for Web Links RFC5988 </del>  describing resources hosted on other web servers, also called endpoints (EP).  An endpoint is a web server associated with a scheme, IP address and port.  A physical node may host one or more 14).  The set does not necessarily contain links to all resources served by the host. <del> A link has the following attributes (see RFC5988): </del>  Zero or more link relations: They describe relations between the link context and the link target. 8. <del> The security considerations as described in Section 7 of RFC5988 and </del>  Section 6 of RFC6690 apply.  The "/.well-known/core" resource may be protected e.g. using DTLS when hosted on a CoAP server as described in RFC7252.  DTLS or TLS based security SHOULD be used on all a description. The query parameter MUST be both a valid URI query key RFC3986 and a <del> parmname as used in RFC5988. </del>  The description must give details on whether the parameter can be updated, and how it is to be processed in lookups.

Rather than redefining RFC6690, we now just allow the common subset. As this touched some 5988 references, I fixed the ref-to-obsolete-rfc issues right in here in a follow-up commit.
The outcome of the 2018-10-24 interim w/rt of the use of Modernized Link Format is what I'd outline like this: The WG has no interest in keeping 6690 alive by having a bis links-json/-cbor was pushed back to the WG, and it looks like it won't follow the troublesome parts of 6690 any more Therefore, my proposed course of action is to Remove Modernized Link Format, leaving it in only as a set of limitations the submitted links MUST follow. (Effectively creating a subset of Link Format that can be expected to be interoperable even as people implemented Modernized Link Format or similar, but not specifying any new behavior). currently we say that submitted documents SHOULD be in that subset, but mandate that Modernized Link Format be applied by the server in order to allow the rare 6690-impossible things. State that for some use cases, Link Format is therefore not suitable, and other formats (like links-json or CoRAL, both informative references) need to be used to be able to express some links. (Maybe in the interop spec) point out where variation is to be expected given widespread bugs in RFC6690 implementations. As Peter pointed out, that should be a matter of days to do plus something in the order of magnitude of a week for reviews -- I'll be starting to write the text Soon, so we'll have a proposed text for Bangkok. Any comments before I start?
HI Christian, Most of your conclusions I agree with. If there is no 6690bis, what will the value of 6690 be in the future? Indeed the RD will accept link format (MUST support) but with the cited restrictions. I prefer constraints (restrictions) over modernized link format. The RD recommends to follow links-json syntax; Once links-json is published , the RD should probably be updated as well. The new links-json document should explicitly cite that it follows RFC 3986 for URI evaluation; for the moment it is a bit vague about that. It is mainly a syntactical document. It provides an algorithm to map link-format to link-json and vice -versa but does not inform the reader about the associated rules change. Peter chrysn schreef op 2018-10-24 18:28: Links: [1] URL [2] URL [3] URL
I think it'll be just something one supports to accommodate old devices or devices built to match old requirements – and it's the only thing we have right now that's feasible on embedded. We could have something in that says "MUST support (limited) 6690 link-format, and SHOULD support other formats like links-json. It is expected that once the working group picks a successor to link-format, that document will update this to mandate support for the new format" (and probably downgrade MUST to SHOULD on 6690). Then, links-json when done would minimally update RD to say say that links-json is now a MUST. Yes; my request to to make it do that unfortunately hit it after WGLC, but now that IESG has passed it back and there's no WG drive to keep 6690 or full 6690 compatibility alive, I think we can make sure it does. The algorithm can stay valid for limited link-format, and I guess there won't be any published algorithm that covers all 6690 cases.
I forgot to reference this in PR , but this issue can be closed once that's merged. The parts about links-json were left out as PR goes in a different direction, given the general uncertainty of what new link format will be exactly. Christian Amsüss wrote: Adoption is now on the agenda of the T2TRG summary meeting in Bangkok [1]. The draft hasn't seen any significant reviews since March, though. While the default profile technically works, it's not as efficient as it can get since it doesn't assign numeric identifiers, e.g., to the "hosts" relation type and RFC 6690 link attributes. So there should be a profile that does for "Link Format in CoRAL" what draft-ietf-core-links-json-10#section-2.3 [2] does for "Link Format in CBOR". I don't know if that has to be a profile that is dedicated to this application or if it'd make sense, for example, to have a general "CoRE Profile" that works also for /.well-known/core and other CoRE WG specifications. Here's one example from RFC 6690 [3] expressed in CoRAL: OLD: ;ct=40;title="Sensor Index", ;rt="temperature-c";if="sensor", ;rt="light-lux";if="sensor", ;anchor="/sensors/temp";rel="describedby", ;anchor="/sensors/temp";rel="alternate" NEW: #using #using lf = hosts { lf:ct "40" } hosts { lf:rt "temperature-c" lf:if "sensor" describedby alternate } hosts { lf:rt "light-lux" lf:if "sensor" } I think it'd make sense to have at least one or two interop events, so it depends on how quickly the draft gets adopted, implementations created, interoperability confirmed, reviews done. While I think the draft is already in quite a good state, I would probably rather lean towards getting it right than rushing it out. RFC 8288 gives some license to deviate from the spec where it makes sense in different link serialization formats. For example, Atom allows IANA-registered link relation types to be serialized as URIs using the prefix "URL", which is specific to Atom (and adopted by CoRAL) and not part of RFC 8288 [4]. So I don't think there's a hard dependency on feedback from the RFC 8288 authors. Review from the RFC 8288 authors and other working groups would be welcome, of course. One thing that could raise eyebrows is if the CoRE WG started to assign numeric identifiers to all IANA-registered link relation types [5]. I thought of doing that in draft-hartke-core-apps-07 [6], but am now not so sure if that is the right path. Does anything else come to your mind that could lead to surprises at IESG review? Klaus [1] URL [2] URL [3] URL [4] URL [5] URL [6] URL

important in machine-to-machine applications where there are no humans in the loop and static interfaces result in fragility.  The discovery of resources provided by an HTTP Web Server is typically  <ins> called Web Linking RFC8288.  The use of Web Linking for the </ins> 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 synonym for "octet". This specification requires readers to be familiar with all the terms  <ins> and concepts that are discussed in RFC3986, RFC8288 and RFC6690. </ins> Readers should also be familiar with the terms and concepts discussed in RFC7252.  To describe the REST interfaces defined in this specification, the URI Template format is used RFC6570. 3.2. The resource directory architecture is illustrated in fig-arch.  A  <ins> Resource Directory (RD) is used as a repository for Web Links RFC8288 </ins> describing resources hosted on other web servers, also called endpoints (EP).  An endpoint is a web server associated with a scheme, IP address and port.  A physical node may host one or more 14).  The set does not necessarily contain links to all resources served by the host.  <ins> A link has the following attributes (see RFC8288): </ins> Zero or more link relations: They describe relations between the link context and the link target. 8.  <ins> The security considerations as described in Section 5 of RFC8288 and </ins> Section 6 of RFC6690 apply.  The "/.well-known/core" resource may be protected e.g. using DTLS when hosted on a CoAP server as described in RFC7252.  DTLS or TLS based security SHOULD be used on all a description. The query parameter MUST be both a valid URI query key RFC3986 and a  <ins> token as used in RFC8288. </ins> The description must give details on whether the parameter can be updated, and how it is to be processed in lookups.


In many M2M applications, 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 <del> employing an entity called a Resource Directory (RD), which hosts registrations of resources held on other servers, allowing lookups to be performed for those resources.  This document specifies the web </del>  interfaces that a Resource Directory supports for web servers to <del> discover the RD and to register, maintain, lookup and remove resource descriptions.  Furthermore, new link attributes useful in conjunction with an RD are defined. </del>  1. 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 <del> entity called a Resource Directory (RD), which hosts registrations of resources held on other servers, allowing lookups to be performed for those resources. </del>  This document specifies the web interfaces that a Resource Directory supports for web servers to discover the RD and to register, <del> maintain, lookup and remove resource descriptions.  Furthermore, new link attributes useful in conjunction with a Resource Directory are defined.  Although the examples in this document show the use of </del>  these interfaces with CoAP RFC7252, they can be applied in an equivalent manner to HTTP RFC7230. connected devices, or across boundaries that would be limiting those operations. <del> It provides a cache (in the high-level sense, not as defined in RFC7252/RFC2616) of data that could otherwise only be obtained by directly querying the /.well-known/core resource on the target device, or by accessing those resources with a multicast request. </del>  Only information SHOULD be stored in the resource directory that is <del> discoverable from querying the described device's /.well-known/core </del>  resource directly. Data in the resource directory can only be provided by the device which hosts those data or a dedicated Commissioning Tool (CT).  These CTs are thought to act on behalf of endpoints too constrained, or generally unable, to present that information themselves.  No other <del> client can modify data in the resource directory.  Changes in the Resource Directory do not propagate automatically back to the web server from where the links originated. </del>  3.2. The resource directory architecture is illustrated in fig-arch.  A <del> Resource Directory (RD) is used as a repository for Web Links RFC5988 </del>  describing resources hosted on other web servers, also called endpoints (EP).  An endpoint is a web server associated with a scheme, IP address and port.  A physical node may host one or more endpoints.  The RD implements a set of REST interfaces for endpoints <del> to register and maintain sets of Web Links (called resource directory registration entries), and for endpoints to lookup resources from the RD.  An RD can be logically segmented by the use of Sectors.  This information hierarchy is shown in fig-hierarchy. </del>  A mechanism to discover an RD using CoRE Link Format RFC6690 is defined. <del> Registration entries in the RD are soft state and need to be periodically refreshed. </del>  An endpoint uses specific interfaces to register, update and remove a <del> resource directory registration entry.  It is also possible for an RD to fetch Web Links from endpoints and add them as resource directory registration entries. </del>  <del> At the first registration of a set of entries, a "registration resource" is created, the location of which is returned to the registering endpoint.  The registering endpoint uses this registration resource to manage the contents of registration entries. </del>  <del> A lookup interface for discovering any of the Web Links held in the </del>  RD is provided using the CoRE Link Format. A Registrant-EP MAY keep concurrent registrations to more than one RD The model shown in fig-ER-RD models the contents of the resource directory which contains in addition to /.well-known/core: <del> 0 to n Registration (entries) of endpoints, </del>  A registration is associated with one endpoint.  A registration defines a set of links as defined for /.well-known/core.  A

I remember keeping web-links where it was beneficial to the text IMO OK with suggested change Peter chrysn schreef op 2018-11-09 16:43: Links: [1] URL [2] URL [3] URL
I'm fine with "Web Links" not being that prominent in the architecture any more; however, two mentions have survived in the three paragraphs above fig-arch, was that intentional?

In many M2M applications, 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  <ins> employing an entity called a Resource Directory (RD), which contains information about resources held on other servers, allowing lookups to be performed for those resources.  The input to an RD is composed of links and the output is composed of links constructed from the information stored in the RD.  This document specifies the web </ins> interfaces that a Resource Directory supports for web servers to  <ins> discover the RD and to register, maintain, lookup and remove information on resources.  Furthermore, new link attributes useful in conjunction with an RD are defined. </ins> 1. 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  <ins> entity called a Resource Directory (RD), which contains information about resources held on other servers, allowing lookups to be performed for those resources. </ins> This document specifies the web interfaces that a Resource Directory supports for web servers to discover the RD and to register,  <ins> maintain, lookup and remove information on resources.  Furthermore, new link attributes useful in conjunction with a Resource Directory are defined.  Although the examples in this document show the use of </ins> these interfaces with CoAP RFC7252, they can be applied in an equivalent manner to HTTP RFC7230. connected devices, or across boundaries that would be limiting those operations.  <ins> It provides information about resources hosted by other devices that could otherwise only be obtained by directly querying the /.well- known/core resource on these other devicess, either by a unicast request or a multicast request. </ins> Only information SHOULD be stored in the resource directory that is  <ins> obtained by querying the described device's /.well-known/core </ins> resource directly. Data in the resource directory can only be provided by the device which hosts those data or a dedicated Commissioning Tool (CT).  These CTs are thought to act on behalf of endpoints too constrained, or generally unable, to present that information themselves.  No other  <ins> client can modify data in the resource directory.  Changes to the information in the Resource Directory do not propagate automatically back to the web servers from where the information originated. </ins> 3.2. The resource directory architecture is illustrated in fig-arch.  A  <ins> Resource Directory (RD) is used as a repository of registrations </ins> describing resources hosted on other web servers, also called endpoints (EP).  An endpoint is a web server associated with a scheme, IP address and port.  A physical node may host one or more endpoints.  The RD implements a set of REST interfaces for endpoints  <ins> to register and maintain resource directory registrations, and for endpoints to lookup resources from the RD.  An RD can be logically segmented by the use of Sectors.  This information hierarchy is shown in fig-hierarchy. </ins> A mechanism to discover an RD using CoRE Link Format RFC6690 is defined.  <ins> Registrations in the RD are soft state and need to be periodically refreshed. </ins> An endpoint uses specific interfaces to register, update and remove a  <ins> registration.  It is also possible for an RD to fetch Web Links from endpoints and add their contents to resource directory registrations. </ins>  <ins> At the first registration of an endpoint, a "registration resource" is created, the location of which is returned to the registering endpoint.  The registering endpoint uses this registration resource to manage the contents of registrations. </ins>  <ins> A lookup interface for discovering any of the Web Links stored in the </ins> RD is provided using the CoRE Link Format. A Registrant-EP MAY keep concurrent registrations to more than one RD The model shown in fig-ER-RD models the contents of the resource directory which contains in addition to /.well-known/core:  <ins> 0 to n Registrations of endpoints, </ins> A registration is associated with one endpoint.  A registration defines a set of links as defined for /.well-known/core.  A


The Registration Resource may also be used to inspect the registration resource using GET, update the registration link <del> contents using PATCH, or cancel the registration using DELETE. </del>  These operations are described in this section.

The document uses the PATCH request method and the 4.09 response codes defined there. Closes: URL
This is needed for the 4.09 error code referenced.
Note to self: That draft is now
Looks good.

The Registration Resource may also be used to inspect the registration resource using GET, update the registration link  <ins> contents using PATCH (as introduced in RFC8132), or cancel the registration using DELETE. </ins> These operations are described in this section.


information stored in the RD.  This document specifies the web interfaces that a Resource Directory supports for web servers to discover the RD and to register, maintain, lookup and remove <del> information on resources.  Furthermore, new link attributes useful in conjunction with an RD are defined. </del>  1. This document specifies the web interfaces that a Resource Directory supports for web servers to discover the RD and to register, maintain, lookup and remove information on resources.  Furthermore, <del> new link attributes useful in conjunction with a Resource Directory </del>  are defined.  Although the examples in this document show the use of these interfaces with CoAP RFC7252, they can be applied in an equivalent manner to HTTP RFC7230. the network (see mc-registration. A Resource Directory MAY provide hints about the content-formats it <del> supports in the links it exposes or registers, using the "ct" link </del>  attribute, as shown in the example below.  Clients MAY use these hints to select alternate content-formats for interaction with the Resource Directory. the human readable name of the parameter, <del> the short name as used in query parameters or link attributes, </del>  indication of whether it can be passed as a query parameter at registration of endpoints, as a query parameter in lookups, or be <del> expressed as a link attribute, </del>  validity requirements if any, and Initial entries in this sub-registry are as follows: <del> (Short: Short name used in query parameters or link attributes.  Use: R = used at registration, L = used at lookup, A = expressed in link attribute </del>  The descriptions for the options defined in this document are only summarized here.  To which registrations they apply and when they are described property actually a property of the endpoint and not a property of a particular resource, in which case it should go into the payload of the registration and need not be registered?), and the <del> potential for conflict with commonly used link attributes (For </del>  example, "if" could be used as a parameter for conditional registration if it were not to be used in lookup or attributes, but would make a bad parameter for lookup, because a resource lookup with an "if" query parameter could ambiguously filter by the registered <del> endpoint property or the RFC6690 link attribute).  It is expected </del>  that the registry will receive between 5 and 50 registrations in total over the next years.

None of those meant any of (anchor,rel,rev), and all the other attributes that come from serializations should be called by what they are. Closes: URL
Working with RFC8288 in CoRAL I noticed that we're a bit sloppy on some concepts of web linking. This manifests in two related issues: We're talking of link attributes, where that's a term nowhere defined. (Used by RFC6690, but possibly they mean "attributes of CoRE links" and not "Core's use of link attributes", and even there only in the chapter name.) The information model we describe is more the model of the serialized data; the data model makes no distinction, for example, between and . The latter is something we can IMO let slide on account of practical readers having both in mind. The former poses the danger of aggravating the careless use of "link attributes" that'd describe the link-as-a-whole (something not covered by the data model, and thus incompatible with different serializations), but can easily be fixed in a search-and-replace PR coming right up.

information stored in the RD.  This document specifies the web interfaces that a Resource Directory supports for web servers to discover the RD and to register, maintain, lookup and remove  <ins> information on resources.  Furthermore, new target attributes useful in conjunction with an RD are defined. </ins> 1. This document specifies the web interfaces that a Resource Directory supports for web servers to discover the RD and to register, maintain, lookup and remove information on resources.  Furthermore,  <ins> new target attributes useful in conjunction with a Resource Directory </ins> are defined.  Although the examples in this document show the use of these interfaces with CoAP RFC7252, they can be applied in an equivalent manner to HTTP RFC7230. the network (see mc-registration. A Resource Directory MAY provide hints about the content-formats it  <ins> supports in the links it exposes or registers, using the "ct" target </ins> attribute, as shown in the example below.  Clients MAY use these hints to select alternate content-formats for interaction with the Resource Directory. the human readable name of the parameter,  <ins> the short name as used in query parameters or target attributes, </ins> indication of whether it can be passed as a query parameter at registration of endpoints, as a query parameter in lookups, or be  <ins> expressed as a target attribute, </ins> validity requirements if any, and Initial entries in this sub-registry are as follows:  <ins> (Short: Short name used in query parameters or target attributes. Use: R = used at registration, L = used at lookup, A = expressed in target attribute </ins> The descriptions for the options defined in this document are only summarized here.  To which registrations they apply and when they are described property actually a property of the endpoint and not a property of a particular resource, in which case it should go into the payload of the registration and need not be registered?), and the  <ins> potential for conflict with commonly used target attributes (For </ins> example, "if" could be used as a parameter for conditional registration if it were not to be used in lookup or attributes, but would make a bad parameter for lookup, because a resource lookup with an "if" query parameter could ambiguously filter by the registered  <ins> endpoint property or the RFC6690 target attribute).  It is expected </ins> that the registry will receive between 5 and 50 registrations in total over the next years.


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>  The discovery of resources offered by a constrained server is very important in machine-to-machine applications where there are no

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

1.  <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


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

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

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


Oscar Novo, Srdjan Krco, Szymon Sasin, Kerry Lynn, Esko Dijk, Anders Brandt, Matthieu Vial, Jim Schaad, Mohit Sethi, Hauke Petersen, <del> Hannes Tschofenig, Sampo Ukkola, Linyi Tian, and Jan Newmarch have provided helpful comments, discussions and ideas to improve and shape this document.  Zach would also like to thank his colleagues from the EU FP7 SENSEI project, where many of the resource directory concepts were originally developed. </del>  12.

Jaime provided a detailled review, and Matthias provided an interesting use case that helped shape the base parameter details Closes: URL Disposition: Merge with next batch
The Acknowledgements section has not been updated for quite a while; I'll update it with the reviewers before releasing -20.

Oscar Novo, Srdjan Krco, Szymon Sasin, Kerry Lynn, Esko Dijk, Anders Brandt, Matthieu Vial, Jim Schaad, Mohit Sethi, Hauke Petersen,  <ins> Hannes Tschofenig, Sampo Ukkola, Linyi Tian, Jan Newmarch, Matthias Kovatsch and Jaime Jimenez have provided helpful comments, discussions and ideas to improve and shape this document.  Zach would also like to thank his colleagues from the EU FP7 SENSEI project, where many of the resource directory concepts were originally developed. </ins> 12.


defines a set of links as defined for /.well-known/core.  A Registration has six types of attributes: <del> a unique endpoint name ("ep") within a sector </del>  a Registration Base URI ("base", a URI typically describing the scheme://authority part) a registration resource location inside the RD ("href"), <del> optionally a sector ("d") </del>  optional additional endpoint attributes (from iana-registry) RD, as obtained from discovery. Endpoint name (mostly mandatory).  The endpoint name is an <del> identifier that MUST be unique within a sector.  The maximum length of this parameter is 63 bytes.  If the RD is configured to recognize the endpoint (e.g. based on its security context), the RD assigns an endpoint name based on a set of configuration parameter values. </del>  Sector (optional).  The sector to which this endpoint belongs. <del> The maximum length of this parameter is 63 bytes.  When this parameter is not present, the RD MAY associate the endpoint with a configured default sector or leave it empty.  The endpoint name and sector name are not set when one or both are set in an accompanying authorization token. </del>  Lifetime (optional).  Lifetime of the registration in seconds. Range of 60-4294967295.  If no lifetime is included in the

Contributes-To: URL WIP, will continue there tomorrow (checking whether any other place in the document needs adaption, whether there's any place where to reiterate RFC6690's "is not expected to validate UTF-8 encoding (but is not prohibited from doing so) and doesn't need to perform any UTF-8 normalization", and whether RD-DNS-SD still uses ep and d as it did where the 63 byte limit came from.
It seems no further changes are needed – when ep gets encoded it is passed into Link Format which is already Unicode; lookup filtering also draws from there; those references also pull in the no-need-to-decode parts (and when it comes to accepting endpoint names, that's a policy issue anyway). RD-DNS-SD still uses ep and d during DNS entry synthesis, so the 63 byte limit stays.
RD-DNS-SD still uses ep and d during DNS entry synthesis, so the 63 byte limit stays. actually that is explicitly mentioned, Peter chrysn schreef op 2019-03-11 10:12: Links: [1] URL [2] 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.
(via Jaime)
We certainly want to allow people to use license plate numbers as endpoint names, so at very least we need to support before they register as . More seriously, there are different uses of the endpoint name that may all warrant some restrictions to make them simpler (one could forbid the (quotation mark) character to ease RFC6690 serialization, the (ampersand) character to ease the representation of the registration operation's resource as a URI, forbid the (solidus) to allow RDs to use the ep in the registration URI, forbid the (full stop) character as DNS host names can contain dots but those can't be encoded in a URI), but at the same time there are applications for some of them (eg. dots are suggested in the NAI examples ). Limitations to which Unicode code points are there would be hard to enforce reliably, and I don't see a compelling reason to just "rule out everything that's not ASCII". If anything, one could think about the code points 0-31 (except some combinations of whitespace) and 127, which can't be represented in RFC6690 as they aren't part of RFC2616's TEXT (whoever then misses ANSI-colored endpoint names can fall back to QuakeIII style of – those examples may sound mocking, but serve to illustrate that we won't easily catch all the characters that are bad anywhere without becoming very restrictive). Being valid UTF8 is a requirement that we should just put in there (and check for others like sector). Any further limitations should IMO be policy-based, typically by the ep being limited to devices with known names anyway.
UTF-8 or even more restricted. Certainly not impose a structure.....
A suggestion from Wednesday's interim was to look into the URI/IRI ABNF rules for reasonable sets of characters. The sets in RFCs / are not directly helpful as their production rules either rule out the LwM2M patterns of using URNs in there (which require at least ":" to be permitted) or bring in URI structure which would be imposing structure – the "[i]query" rule, for example, would only permit many URNs, but contains the pct-encoded rule that says percent signs are only OK if followed by two hex digits. I've also looked into any restrictions we currently implicitly have would stem from there (given ep and d are passed in via URI template variable), but that's very relaxed, talks of strings and percent-encoding almost anything ("eplaced by its value as a string after pct-encoding any characters not in the set of unreserved URI characters"). For lack of better concrete options I'd reach into what can be used in link-format, phrased in RFC8288/7230 terms as HTAB / SP / 0x21-7E / 0x80-FF as long as it is valid UTF-8 (which is the innards of quoted-string with no exceptions for '"' or '' as those are escaping issues) and prepare text for that. (It also dawns to me that the cause of us having the problem of defining identifiers is that we did not think this with enough web in mind, that endpoint names should always be URIs (as that's the uniform identifier we have in the web) and that consequently a registration's endpoint name should not so much be an attribute but a typed link to the abstract definition of that endpoint – but given there are RDs out there already and we'd like to finish this draft, that can of worms stays closed for now.)
HT is evil. Must not be used. To me it now seems all of UTF-8 minus C0 (0x00..0x1f) minus 0x7F is desired. Or, if we also want to exclude C1, i.e. all 65 Unicode control characters:
Closed by d07dde44d4875091dcd8c7eb0380e3675e339d7a which should have said "Closes" rather than "Contributes-To" in retrospect.
I don't see any conflict with rd-dns-sd, a reference from rd-dns-sd to the RD draft looks appropriate.

defines a set of links as defined for /.well-known/core.  A Registration has six types of attributes:  <ins> an endpoint name ("ep", a Unicode string) unique within a sector </ins> a Registration Base URI ("base", a URI typically describing the scheme://authority part) a registration resource location inside the RD ("href"),  <ins> optionally a sector ("d", a Unicode string) </ins> optional additional endpoint attributes (from iana-registry) RD, as obtained from discovery. Endpoint name (mostly mandatory).  The endpoint name is an  <ins> identifier that MUST be unique within a sector.  As the endpoint name is a Unicode string, it is encoded in UTF-8 (and possibly pct-encoding) during variable expansion (see RFC6570 Section 3.2.1).  The endpoint name MUST NOT contain any character in the inclusive ranges 0-31 or 127-159.  The maximum length of this parameter is 63 UTF-8 encoded bytes.  If the RD is configured to recognize the endpoint (e.g. based on its security context), the RD assigns an endpoint name based on a set of configuration parameter values. </ins> Sector (optional).  The sector to which this endpoint belongs.  <ins> When this parameter is not present, the RD MAY associate the endpoint with a configured default sector or leave it empty. The sector is encoded like the ep parameter, and is limited to 63 UTF-8 encoded bytes as well.  The endpoint name and sector name are not set when one or both are set in an accompanying authorization token. </ins> Lifetime (optional).  Lifetime of the registration in seconds. Range of 60-4294967295.  If no lifetime is included in the


it MUST include the base parameter in the registration to provide a valid network path. <del> If the registrant-ep, located behind a NAT gateway, is registering with a Resource Directory which is on the network service side of the NAT gateway, the endpoint MUST use a persistent port for the outgoing registration in order to provide the NAT gateway with a valid network address for replies and incoming requests. </del>  If the Base URI contains a link-local IP literal, it MUST NOT contain a Zone Identifier, and MUST be local to the link on

The requirement was neither precise with current technology (requiring base= even for NAT with endpoint-independent filtering) nor particularly future-proof, and is replaced with a more general statement. While the previous paragraph (about ephemeral endpoints) could have been pulled into the new one, I decided against it as it'd be deeply nested ("(e.g. because of using ephemeral ports (which happens in TCP))") and would have borne the risk of implementors overlooking it because of that. Closes: URL Will merge soon given prior discussion in
The current text says "behind a NAT gateway" as one case in which is obligatory. Reviewing (esp. the part on making base mandatory all the time) I noticed that this should probably be made more precise (would have said "NAT other than full cone", but RFC 4787 has better terminology I'll yet need to go through).
other than full cone?
"Full cone" is an older term that AFAICT roughly means that for each inside port there's an outside port as well (a rather uncommon setup at least in the simple setups I've seen), but anyway that's neither the modern term nor the right criterion. The criterion is probably "If a registrant-ep residing on the internal side NAT that does not follow the recommendations of {{?RFC4787}} with no stringent filtering (in particular REQ-1 and the Endpoint-Independent Filtering of REQ-8) registers with a Resource Directory on its external side, it MUST NOT register with the RD unless it gives an explicit base address that is usable for the lifetime of the registration (e.g. using a configured forwarded port)." I've left the general requirement structure as it is, ie. from the normative language, the registrant has to know about the network. This is unreasonable to demand of the software implementation, and will need to be covered by the implementation's usage instructions or similar (a la "If you deploy this in behind a NAT, you have to add port forwarding and give the externally visible address in this configuration field (which becomes base), otherwise your endpoint would not be compliant") – but that does not change with this edit, and I still think it's good that way. Reading 4787 I also noted that the lifetime interacts with this as well; in the same vein as "if in a really-bad NAT then set base", there'd be a "if in a regular NAT, need to refresh often enough"; not sure which line that'd go into yet.
I would be carefull with any of these instructions because they arre very general and new boxes between communicating nodes may appear any time. chrysn schreef op 2019-03-05 17:16: Links: [1] URL [2] URL
Valid point; so can we put that more generally? Maybe ? Adding "or uses an ephemeral port to register" to the parentheses would even allow this to swallow the paragraph before as well. (Nitpickers might argue that this needs an exception for link-local addresses, but we're talking about them in the next paragraph). 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

it MUST include the base parameter in the registration to provide a valid network path.  <ins> A registrant that can not be reached by potential lookup clients at the address it registers from (e.g. because it is behind some form of Network Address Translation (NAT)) MUST provide a reachable base address with its registration. </ins> If the Base URI contains a link-local IP literal, it MUST NOT contain a Zone Identifier, and MUST be local to the link on


Update operation.  Therefore, the Location-Query option MUST NOT be present in a successful response. <del> If the registration fails with a Service Unavailable response and a Max-Age option or Retry-After header, the registering endpoint SHOULD retry the operation after the time indicated.  If the registration fails in another way, including request timeouts, or if the Service Unavailable error persists after several retries, or indicates a longer time than the endpoint is willing to wait, it SHOULD pick another registration URI from the "URI Discovery" step and if there is only one or the list is exhausted, pick other choices from the "Finding a Resource Directory" step.  Care has to be taken to </del>  consider the freshness of results obtained earlier, e.g. of the result of a "/.well-known/core" response, the lifetime of an RDAO option and of DNS responses.  Any rate limits and persistent errors 4.04 "Not Found" or 404 "Not Found".  Registration does not exist (e.g. may have been removed). <del> If the registration update fails with a "Service Unavailable" response and a Max-Age option or Retry-After header, the registering endpoint SHOULD retry the operation after the time indicated.  If the registration fails in another way, including request timeouts, or if the time indicated exceeds the remaining lifetime, the registering </del>  endpoint SHOULD attempt registration again. The following example shows how the registering endpoint updates its

This addresses . The net effect on word/line count is not large (saving ~60 lines and ~150 words), but it's less repetitive and IMO gives better guidance towards how to handle errors. Will merge into -20 today unless objected to.
The entries for "Failure" are quite repetitive for 4.00 and 5.03. Can we factor these out a bit? The entry "HTTP support" is surprising; maybe this item should be explained beforehand. (It seems all it is saying is that HTTP does not do multicast or /.well-known/core?) (via Jaime)
NAME and NAME AFAIR both of you argued for the interaction templates in the length they have now, but I failed to find the old arguments. (There were some unresolved points in and and , but they don't tell the whole story). I'd argue that most of the failure codes can be removed, for they can't be exhaustive anyway (would we need to add 4.01 for when the client would need to authenticate? 4.08 if a block was missed? 4.29 to throttle?) – handling those is part of CoAP and not the application. If I were to make a proposal, I'd replace all "Failure:" paragraphs (except 4.04 on update/removal, as that's particularly noteworthy) with a general note that Are the sections still justified to be that long, and if so, could you contribute a note on why that is for the review of ?
A point I missed that should go after that suggested paragraph, to fully cover Jaime's comment:
I have made no contribution to template length or format. I don't remeber arguments that support their length. Having written that, I like to idea of having templates. I like them to be stand-alone which makes them lengthy. I have enormous problems with the response codes. Their text never covers what you want to express, they remain approximations of the problem unless they are at the general server level. My sugesstion is not change what is there, but I will not oppose the general text although I consider it possibly too vague for standardization. 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

Update operation.  Therefore, the Location-Query option MUST NOT be present in a successful response.  <ins> If the registration fails, including request timeouts, or if delays from Service Unavailable responses with Max-Age or Retry-After accumulate to exceed the registrant's configured timeouts, it SHOULD pick another registration URI from the "URI Discovery" step and if there is only one or the list is exhausted, pick other choices from the "Finding a Resource Directory" step.  Care has to be taken to </ins> consider the freshness of results obtained earlier, e.g. of the result of a "/.well-known/core" response, the lifetime of an RDAO option and of DNS responses.  Any rate limits and persistent errors 4.04 "Not Found" or 404 "Not Found".  Registration does not exist (e.g. may have been removed).  <ins> If the registration fails in any way, including "Not Found" and request timeouts, or if the time indicated in a Service Unabailable Max-Age/Retry-After exceeds the remaining lifetime, the registering </ins> endpoint SHOULD attempt registration again. The following example shows how the registering endpoint updates its


Abstract <del> In many M2M applications, direct discovery of resources is not </del>  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>  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>  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

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

Abstract  <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  <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  <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