Re: [core] Resource Directory plugtest

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

Hello parties interested in the RD interop,

please fill out which dates would work for you for a first interop:

https://doodle.com/poll/hxx6ryh4359tsvnb

The times were chosen to accomodate participants from the the American
west coast and Europe, let's see if we find convenient overlap. We will
meet in voice chat (probably IETF's own Jitsi) and do all testing over
the Internet.

I've assembled a questionnaire at the end of the mail to help in setting
expectations and identifying problems ahead of time, please reply
off-list preferably before April 1st.


A first interop that will happen as doodled with whoever is ready to
do it by that time. There will not be a precise test specification for
that event, we'll just try out some operations driven by the client
implementor.

From the experience in that, we can develop a more formal test workflow
and have a second interop based on that, probably around June.

Best regards
Christian




Foreword to participant data
----------------------------

These questions are here to determine in advance whether we we will at
all have implementations that can interact meaningfully.

You are a perfectly good participant if you only tick one or two of the
feature options.

Older versions are OK too: a -00 client should be able to register with
a known -13 RD and vice versa.

The feature list is not a compliance check lists and implies nothing
about those things being optional.

Feel free to add free-form comments if you want to volunteer additional
information or think I missed a point.


Participant data
----------------

I implemnt RD as of draft version [ ] / as of a derived specification,
in particular [ ].

In terms of roles and features, I implement... 

[ ] an Endpoint that can do
  [ ] finding of the RD using
    [ ] a configured host name
    [ ] a configured IP address
    [ ] expicitly configured DNS-SD
    [ ] by receiving to a SLAAC RDAO option
    [ ] by falling back to a "close device" like a 6LBR
    [ ] by discoverying an RD using multicast
  [ ] simple registration
  [ ] do full registration
    [ ] execute URI discovery to find a registration resource
    [ ] send an explicit con or other registration parameters
    [ ] delete my own registration on shutdown
  [ ] any of the above with content formats other than link-format, in
      particular: [ ]
[ ] an RD that can
  [ ] send SLAAC RDAO announcements
  [ ] respond to multicast requests
  [ ] accepts simple registrations
  [ ] accepts regular registrations
  [ ] implements lookup, in particular
    [ ] endpoint lookuo
    [ ] resource lookup
    [ ] group lookup
  [ ] accept group registrations
  [ ] accept registration with another formats than link-format
  [ ] process generic registration parameters
  [ ] process specific registration parameters (RD extension), in
      particular 
    [ ] RD-DNS-SD
    [ ] proprietary
    [ ] other: [ ]
[ ] a lookup Client
  [ ] that can do endpoint lookups
  [ ] that can do resource lookups
  [ ] that can do group lookups
  [ ] that can observe lookups
  [ ] can deal with other formats than link-format
  [ ] that isn't actually a lookup client, but if you ask me to look
      something up during an interop, I have a client at hand to do it
      semi-manually
[ ] a Commissioning Tool

As schemes and authentication methods, I support...

[ ] coap
[ ] coaps
[ ] coap+tcp
[ ] coaps+tcp
[ ] http
[ ] OSCORE over any of the above

I will have a route to the general internet using...

[ ] IPv4
[ ] IPv6
[ ] my endpoint will have multiple addresses that are routable to the
    internet
[ ] my endpoint will have at least one routable address that is
    firewalled

Participant privacy:

[ ] I'm OK with being publically identified by name, email address and company in the course of this interop.
[ ] Please anonymize my participation.

-- 
I shouldn't have written all those tank programs.
  -- Kevin Flynn