[dnssd] Report on first Resource Directory plugtest

Christian Amsüss <christian@amsuess.com> Thu, 12 April 2018 21:12 UTC

Return-Path: <christian@amsuess.com>
X-Original-To: dnssd@ietfa.amsl.com
Delivered-To: dnssd@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id EA4C412DA12; Thu, 12 Apr 2018 14:12:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id gbqi4L0wuega; Thu, 12 Apr 2018 14:12:05 -0700 (PDT)
Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EC5212D941; Thu, 12 Apr 2018 14:12:04 -0700 (PDT)
Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id D357F49784; Thu, 12 Apr 2018 23:12:02 +0200 (CEST)
Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com []) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id CC62B17C; Thu, 12 Apr 2018 23:12:01 +0200 (CEST)
Received: from hephaistos.amsuess.com (hephaistos.amsuess.com [IPv6:2a02:b18:c13b:8010::db8]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 8B73641; Thu, 12 Apr 2018 23:12:01 +0200 (CEST)
Received: (nullmailer pid 5265 invoked by uid 1000); Thu, 12 Apr 2018 21:12:00 -0000
Date: Thu, 12 Apr 2018 23:12:00 +0200
From: Christian =?iso-8859-1?Q?Ams=FCss?= <christian@amsuess.com>
To: Core WG mailing list <core@ietf.org>
Cc: DNSSD WG mailing list <dnssd@ietf.org>, Ivaylo Petrov <ivaylo@ackl.io>, Jim Schaad <ietf@augustcellars.com>, Hauke Petersen <hauke.petersen@fu-berlin.de>
Message-ID: <20180412211159.GB20765@hephaistos.amsuess.com>
References: <20180322144452.GA13008@hephaistos.amsuess.com> <20180322150452.GA17015@hephaistos.amsuess.com> <20180403082122.GA30478@hephaistos.amsuess.com> <20180411103951.GC14388@hephaistos.amsuess.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="61jdw2sOBCFtR2d/"
Content-Disposition: inline
In-Reply-To: <20180411103951.GC14388@hephaistos.amsuess.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/pCIZ28bgzDNOXUtKb7BrEZQwYOE>
Subject: [dnssd] Report on first Resource Directory plugtest
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Apr 2018 21:12:08 -0000


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

  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

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

* 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

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
  * 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.