Change:
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> <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

Discussion:
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