Draft: draft-ietf-core-resource-directory

Commentary: This contains what I think of the easy fixes to the requirements of replicated RDs . See for more discussion , please comment on whether you think those changes are acceptable . 
 The minimum for interoperability IMO is that client 's do n'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  announces multiple addresses ( something explicitly allowed in the current draft ) , or the URI discovery response contains more than one rt= " " 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
Paragraph (version A):
Discovery of the RD registration URI path is performed by sending
either a multicast or unicast GET request to "/.well-known/core" and
including a Resource Type (rt) parameter RFC6690 with the value
"core.rd" in the query string.  Likewise, a Resource Type parameter
value of "core.rd-lookup*" is used to discover the URIs for RD Lookup
operations, and "core.rd-group" is used to discover the URI path for
RD Group operations.  Upon success, the response will contain a
payload with a link format entry for each RD function discovered,
indicating the URI path of the RD function returned and the
corresponding Resource Type.  When performing multicast discovery,
the multicast IP address used will depend on the scope required and
the multicast capabilities of the network.
Paragraph (version B):
Discovery of the RD registration URI path is performed by sending
either a multicast or unicast GET request to "/.well-known/core" and
including a Resource Type (rt) parameter RFC6690 with the value
"core.rd" in the query string.  Likewise, a Resource Type parameter
value of "core.rd-lookup*" is used to discover the URIs for RD Lookup
operations, and "core.rd-group" is used to discover the URI path for
RD Group operations.  Upon success, the response will contain a
payload with a link format entry for each RD function discovered,
indicating the URI of the RD function returned and the corresponding
Resource Type.  When performing multicast discovery, the multicast IP
address used will depend on the scope required and the multicast
capabilities of the network.
Paragraph (version B):
While the link targets in this discovery step are often expressed in
path-absolute form, this is not a requirement.  Clients SHOULD
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.
Paragraph (version A):
The registration message is a list of links to registration resources
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.
Paragraph (version B):
The registration message is a list of links to registration resources
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.
Paragraph (version B):
A Resource Directory can report endpoints or groups in lookup that
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.