Subject: Re: [dnssd] [core] Resource Directory plugtest

From: Christian Amsüss <[email-masked]>
Date: Tue, 3 Apr 2018 10:21:22 +0200

Hello parties interested in the RD interop,

we will have the plug test on April 10th, starting 14:00 UTC; a voice
and text chat room is available at IETF Jitsi[1] to coordinate, exchange
addresses and test results.

I've expressed the participant survey as an online questionnaire at [2];
participants that have not yet answered my plain text version please
fill this out before the 7th.

Best regards
Christian

[1]: https://jitsi.tools.ietf.org/rd-plugtest
[2]: https://chrysn.limequery.org/999235

-- 
You don't use science to show that you're right, you use science to
become right.
  -- Randall Munroe

---

From: Christian Amsüss <[email-masked]>
Date: Thu, 12 Apr 2018 23:12:00 +0200

Hello,

we have had a successful plug test in two sessions on Tuesday with a
total of 4 implementors[1], 3 resource directories and 7 endpoints
(counting full and simple endpoints independently), thereof 2 (one full
endpoint, one simple endpoint) on embedded (class C2) systems.

Most endpoints could register right away once configured properly, and
be looked up by other parties.

Issues we encountered were:

* Problems from lower layers[2]

* Various implementation bugs (programming errors, non-intuitive
  configuration)

  Most of these could be fixed ad-hoc by the participants.

* Incomplete implementations of RD functionality

  * Lookup: One server has not yet implemented support for
    arbitrary registration attributes at the lookup side, and only
    supports querying for known parameters without wildcards; this was a
    known limitation of this work-in-progress implementation.

  * Lookup: The requirements of -13 to have absolute references in both
    the href and anchor of resource lookup has only been implemented on
    one server. This was probably due to authors having carried over the
    behavior from earlier draft versions.

  * Discovery: The embedded endpoint implementation did not implement
    the discovery step but needed to be configured with a full
    registration URI.

* Only little unclear parts in the current RD draft

  * May a con= argument be present in a simple registration? (Probably
    not, though this precludes simple registration over TCP).

  * Can there be a Location-Query option in a registration response?
    (Probably not, we just didn't say that.)

  * Can a con= have query parameters? (Certainly not intended, it just
    didn't even occur to anyone before.)

  Those parts are being fed into the process of refinding the
  resource-directory document, in parallel to the other input we've been
  receiving.

All tested endpoints could register on the servers they were tested
against[3]. Endpoints for full registration did registration, updates
and removal of registrations (where supported; some endpoints (esp. the
embedded one) chose not to implement updates or removal). We found the
resources advertised by the endpoints in the resource looup interfaces
using the supported media types (application/link-format for all
involved, +cbor and +json where supported).

One of the registering endpoints has not seen any updates since at least
-11; that did not impede its ability to register.

All things considered, we regard these first tests as successful.

Topics we would like to explore in a future second round of this plug
test:

* see whether all participants can implent their missing features (esp.,
  see how well full URI discovery works from embedded systems)

* extensions to the RD (RD-DNS-SD, distributed RDs)

* groups (those are only supported by one implementation so far)

* actually accessing the advertised resources

Best regards
Christian

-- 
Ceterum censeo RFC6690 esse revidendam.

[1]: Test participants were Jim Schaad, Ivaylo Petrov (with ackl.io's
  resource directory), Hauke Petersen (with endpoints implemented on
  RIOT) and Christian Amsüss (with aiocoap)

[2]: In detail, those were:

  * Production and parsing of invalid RFC6690 (which link attributes
    need to be quoted, trailing commas, parsers expecting a '=' after
    'obs')
  * Errors on CoAP level (NON vs. ACK, Accept ignored)
  * URIs needing explicit port values
  * Incompatible TLS implementations (two participants have basic
    support for CoAP over TLS, but with disjoint authentication options)
  * Routing / name resolution problems

  Those problems were understood (with the help of the respective
  specifications, where needed), and are worked on by the authors.

  I've seen a similar class of issues during the OSCORE plug tests. We
  might consider collaborating on building a test suite for some of
  those so that future implementors can self-test their ground work
  during development.

[3]: Not all were tested against all due to a timezone mismatch that
  caused the test to be split in two sessions.

---

From: peter van der Stok <[email-masked]>
Date: Fri, 13 Apr 2018 09:04:33 +0200

Hi Christian,

thanks for this very useful work
Some questions/ remarks below.

>     not, though this precludes simple registration over TCP).
certainly not; it beats the purpose.
We may add text in RD to address the TCP part.
>     (Probably not, we just didn't say that.)
to what purpose?
>     didn't even occur to anyone before.)
It states explicitly that it is a scheme//authority string, no query 
parameters possible;
The simplicity helps to specify an already complex subject
> 
>   Those parts are being fed into the process of refining the

to be filled into the github, I hope.