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

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

Hello CoRE list,

we've just completed part I of the previously announced RD plug test
(between the RIOT and aiocoap implementations), and I'm sending the
results to the list right away to have them available in today's interim
meeting.

Summary:

  The tests that can be expected to be performed by a device implements
  the registrant-EP side of RD passed, with some changes due to limits
  of the underlying CoAP library. One test was missed because tests were
  executed out-of-order.

  So far, nothing group related has been tested as nothing has been
  implemented by either participant.

Details below.

Best regards
Christian


---


Implementations under test were:

* RIOT's built-in endpoint, where RIOT is an operating system for class
  C0 to C2 devices. The endpoint implementation is designed to do either
  a simple or a as a full registration, to keep both alive, and to
  explicitly deregister again. Due to limitations in the underlying CoAP
  library, it can not perform multicast discovery or send target
  attributes or an anchor in links yet. (Those features are being worked
  on.)

  The registrant EPs were run in iot-lab with full IPv6 connectivity and
  operated by Hauke Petersen; later tests also include an endpoint run
  locally at his site.

* aiocoap's resource directory, where aiocoap is a Python implementation
  of CoAP that ships several tools for use on unconstrained systems. It
  implements all components of the RD server except groups, as well as
  regular registrant endpoint. No commissioning tool (CT) is implemented
  per se, but it provides a program called rd-relay. The relay provides
  links to an RD proper in multicast lookups, and performs third party
  registration for local registrants that attempt simple registration.

  The RD server was run on a public IPv6 address and operated by
  yours truly.

Test execution:

* Test 3 passed. The execution deviated from the protocol by providing
  no additional link or target attributes (see above), a varied endpoint
  name and an unexpected Content-Format header sent by the registrant
  (fixed).

* Test 1 passed with modifications, test 4 passed. The target address in
  1 was changed from multicast to unicast to accomodate library
  limitations, and because the implementations were not colocated. In
  test 4, the same links as in test 3 were used (an oversight), and
  again no link attributes were present.

  The registrant provided an endpoint name varying from the test
  specification. The RD used a different registration path than the
  example path given in the test specification.

* Test 12 passed (the device was manually prompted to de-register).

* Test 13 was missed when going through the list, but a version of it
  (minus the new base address) was executed regularly by the active
  registrants.

* Tests 2, 5, 6, 7, 8, 9, 10, 11, 14 and 15 were not applicable to an
  endpoint-only client implmentation. Some of those steps were filled in
  by an aiocoap implementation for verification purposes:

  * Tests 2 and 5 were executed by running an rd-relay at Hauke's site,
    where he tasked an endpoint to simply register at the local
    rd-relay. The relay looked up the details of the RD server and then
    performed a thrid party registration.

  * Tests 10, 12 and 15 were executed continuously by means of an active
    observation on the server, and gave the expected results. As no link
    attributes were set by the registrants, the filter parameters were
    left out.

  As additional tests, the links produced in lookup were handed to an
  client to be dereferenced. Links from test 3 and 4 (simple and
  regular registration) could be read. Links from test 5 could not be
  read because the endpoint had no route to the internet; the CT thus
  entered them as
  <coap://[fe80::2c7c:b7ff:feac:bda8%tapbr0]/sensors/temp>. That might
  be an issue to consider during discovery, and was taken to the draft's
  issue tracker.

Various obervations:

* Sending more link attributes would make the link-format serialization
  on small devices hard in terms of flash size, link-format+cbor might
  be of help here and will require support by RDs.

* Issues discovered in the server were failure to deregister timed out
  simple registrations, and needless sending of observe notifications
  when nothing really changed.

* The GETs performed during simple registration were issued from a
  different IP address than the one targeted in the registration. That
  caused no trouble in the test, but might confuse readers of the logs.

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom