Code 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 endpoints MAY be hosted by a different RD than the the group hosting RD.  In that case the endpoint link points to the registration resource on the other RD. </del> <ins> 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. </ins> The commissioning tool SHOULD not send any target attributes with the links to the registration resources, and the resource directory

Related discussion:
text: This contains what I think of the easy fixes to the requirements of replicated RDs. See URL for more discussion, please comment on whether you think those changes are acceptable.
The minimum for interoperability IMO is that client's don't always pick the first choice -- because if they do, no fault tolerance is possible. Do you think that that even this is too much specification of behavior, or did I write more in the PR than what would be needed to satisfy that minimum requirement?
chrysn schreef op 2018-02-01 17:03: Is that so? The first choice of one client is not necessarily the first choice of another when we are confronted with RDs which have contact problems. Several protocols have handled this problem: like dhcp for example. Why not copy that behavior?
I think we're talking about different "first"s here. I'm not concerned with what happens when multiple servers answer the multicast CoAP request. (Led to an interesting chat with PIM people but is not a matter that should concern the RD). What I do think we should give guidance is what happens if the RDAO announces multiple addresses (something explicitly allowed in the current draft), or the URI discovery response contains more than one rt="URL" link Both are within what I think we describe as acceptable server behavior. If clients are unaware and just always pick the first line (because it looks like a zero-or-one situation to the implementers), interoperability issues will arise when two are announced an the first one fails.
Ok, got it, see below chrysn schreef op 2018-02-02 12:11: Yeah, that's a nuisance. Someone seems to know what they want that for, annd probably have some intelligent algorithm to break ties.......... One might say that client MAY choose their RD randomly. I assume that is a multicast response? Then the first response is probably the closest and the best choice. And when one MC response contains multiple RD links, We are not responsible, and something clever is being thought out somewhere, we hope. I think DHCP specifies clients to wait so many seconds before choosing a server. When the first one fails, the client will try the second one, und so weiter ... What am I missing still?
for interoperability, the client behavior when multiple URIs are discovered, or the RD does not answer, need not be specified. The text starts to look more and more like Bonjour