Subject: [core] resource-directory: notes from implementing

From: Christian Amsüss <[email-masked]>
Date: Mon, 5 Dec 2016 17:10:42 +0100

Hello RD authors,

as of bringing my current in-house pseudo-resource-directory up to spec
and thereby going through draft-ietf-core-resource-directory-09 in
detail, I noticed some minor issues:

* 6.2 URL template: This gives a {?rt} template with "MAY contain one or
  more of the values". By RFC6570 rules, this means that
  ?rt=core.rd-lookup,core.rd-group would be what multiple values look
  like.

  In contrast, RFC6690 gives the query string template as {?search*},
  which would normally expand to `?search=one&search=two`, but
  explicitly states that this is a 1-element list. Its matching criteria
  (Complete or Prefix Value String) have no consideration for any
  comma-splitting in the value string.

  Thus, the above example should, by the rules of RFC6690, produce an
  empty match.

  I suggest that the number of allowed values be reduced to one (whoever
  wants to query for both core.rd-lookup and core.rd-group should be
  able to deal with the overhead of querying for core.rd*).

* 6.2 "the resource is application.xml (ct=40)", probably should be
  application/link-format

* 6.4, lt definition: The text above says that unchanged lt should not
  be repeated; this implies that if ?lt=600 was sent in the original
  registration and updates omit lt, the updates are still only valid for
  10 minutes after the update was sent. The lt definition describes a
  default of 86400 (24h), which is only the default when no lt has ever
  been sent.

  Update suggestion: "If no lifetime is included, the previous last
  lifetime set on a previous update or the original registration
  (falling back to 86400) SHOULD be used." (Possibly also "MUST be used"
  or "is implied").

  Similar for con too.

* 6.7 modifying example: I assume that the quotes in `PATCH
  /rd/4521?href="/sensors/temp"` are an error.

* 8 uri template variables:

  * The `res` parameter is defined, but not part of the URI template.

  * The `resource-param` parameter was called `source*` in RFC6690. It
    might make sense to call it the same here or reference to it.
    
    Given that unlike RFC6690 (only one element, see above), here many
    filters can be given, it would make sense to suffix that parameter
    with a '*'.

  * Why is `rt` explicitly listed and not subsumed under
    `resource-param`? Granted, `rt` is defined for
    group/endpoint/resource lookups while `resoure-param` is only for
    endpoints, but why is that?

* I'm missing guidance on what constitutes the "registry-key" (a la
  "cache-key") of a registration. 6.3 says that "registering twice with
  the same endpoint parameter does not create multiple RD entries", but
  the description of the `ep` parameter later reasonably requires
  uniqueness only within a domain.

  What I'm using right now is keying registrations by (ep, d) tuples,
  where the d may be empty or default to a domain configured for the RD,
  but I could need some guidance on the intended operation here.

Best regards
Christian

-- 
Christian Amsüss                      | Energy Harvesting Solutions GmbH
founder, system architect             | headquarter:
mailto:[email-masked]  | Arbeitergasse 15, A-4400 Steyr
tel:+43-664-97-90-6-39                | http://www.energyharvesting.at/
                                      | ATU68476614

---

From: peter van der Stok <[email-masked]>
Date: Wed, 14 Dec 2016 10:13:58 +0100

Hi Christian,

thanks for your comments. Indeed some are easily repaired, and thanks 
for pointing them out.
I want to react to one specifically, having had problems with this issue 
as well.
>   but I could need some guidance on the intended operation here.
Usng the (ep, d) tuple as key for registration sounds difficult as d is 
optional; and d's may be generated after the generation of multiple 
ep's.
To which d do the earlier ep's belong to is then a valid question.

My suggestion is to use ep suffixed with domain name as key in that case 
"ep1" will be different from "ep1-d1" for example.
Zach always insisted that storage issues are the concern of the 
implementors, and they have the returned location (e.g. /rd/4521) to 
guide the implementation.
That subsumes (IMO) storage uniqueness within one registration and 
consecutive updates; while additional criteria can be checked without 
affecting the storage.

does that make sense to you?

I will react to the other issues later, unless my co-authors beat me to 
it.

Peter

---

From: peter van der Stok <[email-masked]>
Date: Wed, 14 Dec 2016 11:34:25 +0100

Hello Christian,

>   able to deal with the overhead of querying for core.rd*).

I agree, That is how I interpreted the text up till now, where more than 
one stands for the wild card *.

> * 6.2 "the resource is application.xml (ct=40)", probably should be
thanks, that is a clear omission.

>   (falling back to 86400) SHOULD be used." (Possibly also "MUST be 

This is fine with me. Reads better.
>   /rd/4521?href="/sensors/temp"` are an error.

And another omission. thanks.

>   * The `res` parameter is defined, but not part of the URI template.
yeah, Noticed this earlier and then forgot.
>     filters can be given, it would make sense to suffix that parameter

I don't follow; I dont see the similarity between source and 
resource-param; can you explain a bit more?
>     endpoints, but why is that?

No answer yet. will look into it.
Greetings and thanks,

Peter

---

From: peter van der Stok <[email-masked]>
Date: Wed, 14 Dec 2016 12:50:21 +0100

Hi Christian
>     endpoints, but why is that?
I think you answered your own question.
Subsuming rt under resource-param will not make the text more readable 
(the contrary I would say)

Peter

---

From: Christian Amsüss <[email-masked]>
Date: Tue, 20 Dec 2016 21:01:41 +0100

On Wed, Dec 14, 2016 at 10:13:58AM +0100, peter van der Stok wrote:
> optional; and d's may be generated after the generation of multiple ep's.

That the d may be changed (or created) later is a point I did miss. I
suppose such a thing could happen if a commissioning tool took up a
registration and POSTed an update to its +location with a new d= query
parameter.

> implementors, and they have the returned location (e.g. /rd/4521) to guide
> the implementation.

Sure, storage is a different issue.

> does that make sense to you?

Frankly, no :-/. The question to me remains open what should happen
after

* my-device POSTs /rd?ep=number41 (-> location /reg-12345)

* some tool POSTs /reg-12345?d=example.com

* my-device reboots and POSTs /rd?ep=number41 again

. My conclusion from this is that I'll make sure my devices register
with their configured domain, but for implementing the server this
leaves me none the wiser. Reading through the draft again, I read

> The registration interface MUST be implemented to be idempotent, so
> that registering twice with the same endpoint parameter does not
> create multiple RD entries.

which might even imply that two different devices registeringin at
/rd?ep=number41&d=example.com and /rd?ep=number41&d=other.network
should be smushed into one registration, but I don't think that's what's
actually meant.

Best regards
Christian

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

---

From: Michael Koster <[email-masked]>
Date: Tue, 20 Dec 2016 12:13:27 -0800

We need to make it clear that if a previous registration or update has set a lifetime value for a particular registration, it must not be reverted to the default.

best regards,

Michael

> On Dec 5, 2016, at 8:10 AM, Christian Amsüss <[email-masked]> wrote:
>

---

From: Christian Amsüss <[email-masked]>
Date: Tue, 20 Dec 2016 21:14:27 +0100

On Wed, Dec 14, 2016 at 11:34:25AM +0100, peter van der Stok wrote:
> I don't follow; I dont see the similarity between source and resource-param;
> can you explain a bit more?

I seem to have mixed up terms a little here, let me try again:

RFC6690/4.1 defines a {?search*} query which is a generic argument for
filtering by arbitary properties of link-format entries. The
resource-param of resource-directory seems to serve the very same
purpose, and could thus be similarly named.

Best regards
Christian

---

From: Christian Amsüss <[email-masked]>
Date: Tue, 20 Dec 2016 21:37:22 +0100

Hello Peter,

On Wed, Dec 14, 2016 at 12:50:21PM +0100, peter van der Stok wrote:
> Subsuming rt under resource-param will not make the text more readable (the
> contrary I would say)

Follow-up question, as I just implemented a no-op there: What does a
/rd/ep?rt=something query actually mean? Is it just a "match an endpoint
iff any of its resources have that rt"? Does that have actual
applications (given that the resource with the rt could not be used
until a second /rd/res?rt= query is issued)? If yes, why does the same
not apply to resource-param so it could be used for /rd/ep queries too?

Best regards
Christian

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