[core] Second Resource Directory plug test: Report, part II

[Christian Amsüss <[e-mail]>]

Hello observers of the Resource Directory plug tests,

we have concluded part II of the second installment of the RD plug tests.

(DNS-SD: Report part I only went to CoRE as it was time critical
to an interim. The summary covers both, details on [1].)

Summary:

  Three implementations were tested, and all eventually passed the
  implemented subsets of RD. (Jim's covered everything, Christian's
  everything but groups, Hauke's embedded one acted as an endpoint).
  Four details that need claraification in the specification were
  discovered (handling of link-local addresses, and the below), but
  nothing major. Two implementations could not interoperate due to IPv6
  not having been universally deployed.

  No implementations of extensions to RD (like RD-DNS-SD) were known so
  none were tested. We hope for participation of implementing parties in
  future events.


Questions raised:

  * When matching against endpoint registrations, can an href filter
    query be matched as a relative reference (eg. /lkp/ep?href=/reg/1)?
  * Can a registration be "taken over" by a Commissioning Tool?
  * Is displaying the base of a registration mandated in EP lookup?

They're being taken up in the document's issue tracker for discussion
among the authors, and expected to be clarified in the next version of
the draft.

Details below.

Best regards
Christian

[1]: https://mailarchive.ietf.org/arch/msg/core/enMOFPTiK9qcS-lxpQ-VVyyKbuc


---
  

Implementations under test were:

* Jim Schaad's resource directory, implemented in C# and running on an
  unconstrained system.

* aiocoap's resource directory (see [1]; Christian)

* RIOT's registrant endpoint (see [1]; Hauke)


Test execution:

* Christian's server with Jim's registrant and lookup client

  Tests were executed in sequence and passed unless noted otherwise,
  with the following alterations and notes:

  * Test 1, 2: Unicast address used as devices were not in multicast
    range.
  * Tests 6-7, 9 and 14 (anything group related) were not supported by
    the server
  * Test 11 was not implemented on the server.
  * Bugs in the implementations were found in tests 1 (when modified by
    the client to include ct lookup; actually a bug in the server's
    implementation of RFC6690), 13 (client sent content-format
    indication payload while it shouldn't, due to a limitation of the
    underlying library).

* Jim's server with Hauke's client

  * Test could not be executed because the test sites did not share a
    common IP version.
  * Registration through a relay (see rd-relay description in [1]) was
    attempted but failed for reasons discovered later.

  The paring will be tried again in the next plug test, either with
  IPv6 everywhere or some sort of tunneling in place, possibly
  facilitated by F-Interop.

* Jim's server with Christian's client

  Tests were executed out of sequence because several tests are grouped
  together in a single client application run. All tests except where
  noted did pass, with several alterations and notes:

  * Test 1, 2: Unicast address used as devices were not in multicast
    range.
  * Tests 6-7, 9 and 14 (anything group related) were not supported by
    the client.
  * The .well-known/core resource was advertised in all registrations in
    addition to the prescribed resources, and consequently shown in the
    lookups.
  * In test 13, the wrong registration was updated. This was noticed in
    test 15; the lookup results were consequently in conflict with the
    test description, but consistent with the course of the experiment.

  * Bugs were found in tests 2 (the * in lookup was matched to "one or
    more characters", actually a bug in the server's implementation of
    RFC6690) and 4 (a slash was expected to trail the base value), and
    fixed before continuing.
  * The participants spent some time debugging the spurious absence of
    GET requests triggered by simple registration, which was actually an
    artifact of all network scanners having been configured to port 5683
    exclusively, and the registrant using a different port to avoid
    collision with an already active non-simple endpoint.

-- 
There's always a bigger fish.
  -- Qui-Gon Jinn