Subject: [core] #413 (resource-directory): Make Simple Directory Discovery really simple

From: "core issue tracker" <[email-masked]>
Date: Sat, 11 Jun 2016 15:28:23 -0000

#413: Make Simple Directory Discovery really simple

 Currently the Simple Directory Discovery allows two modes:

 * Empty POST and the RD takes care
 * POST with payload with only selected resources

 When the device is aware which resources it wants to expose and can
 perform POSTs with potentially large payloads (->Block1), it can be
 expected to perform a normal registration in my opinion. If some resources
 should be private/hidden, why have them in /.well-known/core (there is
 always the possibility for incremental discovery at other resources).

 Thus, I recommend to remove the second mode (POST with payload).

 Furthermore, I would move this "Simple Registration" into its own sub-
 section (after 4.1 Finding a Directory Server). There, we should also have
 some text that the RD then has to make some guesses about the lifetime an
 take care of such registrations by itself (periodic updates, de-
 registration).

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-core-resource-
  [email-masked]   |  [email-masked]
     Type:  protocol     |     Status:  new
  enhancement            |  Milestone:
 Priority:  minor        |    Version:
Component:  resource-    |   Keywords:
  directory              |
 Severity:  -            |
-------------------------+-------------------------------------------------

Ticket URL: <https://tools.ietf.org/wg/core/trac/ticket/413>
core <https://tools.ietf.org/core/>

---

From: peter van der Stok <[email-masked]>
Date: Mon, 13 Jun 2016 11:05:28 +0200

Hi Matthias,

thanks for your thoughts. See below.

>  always the possibility for incremental discovery at other resources).

I think the conclusion that it concerns hidden resources published in/. 
well-known/core a bit quick.
May be there are no resources at all in /.well-known/core, and the 
device can make a selection of resources for the destination of its 
choice.
And, indeed, we may talk security domains here.
In conclusion: I like to keep the 2nd mode.

>  take care of such registrations by itself (periodic updates, de-
The subsection makes sense, and will be done.

Peter

---

From: "Kovatsch, Matthias" <[email-masked]>
Date: Mon, 13 Jun 2016 12:32:33 +0000

> May be there are no resources at all in /.well-known/core, and the device can
> make a selection of resources for the destination of its choice.

My main question is: Isn't this case already beyond "Simple Directory Discovery"?
A device could use the normal Registration and simply ignore the returned handle resource (Location) and fully rely on the lifetime. So why do we need to define two modes in the "Simple" Directory Discovery? A simple device must be provided with the RD address in some way. I cannot see much difference between giving it the coap://rd/.well-known/core URI and the resolved (in terms of following the rt=core.rd link in link-format) URI coap://rd/rd. From there, the behavior is the same: POST your link-format.

Ciao
Matthias

---

From: Michael Koster <[email-masked]>
Date: Mon, 13 Jun 2016 05:54:47 -0700

First, we should combine 4.0 and 4.2 and add it to the registration section in 5. "Simple Discovery" is actually "Simple Registration" and should be renamed.

Let's discuss finding a directory server in section 4 before we discuss registration of resources in section 5.

Section 5 should start with the 2 types of registration and then describe discovery.

We have discussed these changes before and never made them. 

So:
--------
sec. 4 - finding a directory server

sec. 5 API functional description

5.1 registration (both methods) 

5.2 discovery

5.3 etc.
----------

I am ready to make these changes now if we agree. 

Best regards,

Michael

We are going to need both methods of registration
> On Jun 13, 2016, at 5:32 AM, Kovatsch, Matthias <[email-masked]> wrote:
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Michael Koster <[email-masked]>
Date: Mon, 13 Jun 2016 06:04:29 -0700

OK, I see that the current section 5.1 called "discovery" is also about finding an RD. 

Let's move the current 5.1 (discovery) to sec. 4 (finding an RD, discovering RD services) and keep it out of the API description.

So section 4 is about discovering or finding RD services, and section 5 is about how you interact with the RD using it's API once you find it.

Michael

4. finding al RD - service discovery

5. using an RD

5.1 registration

5.2 update registration

5.3 remove registration

5.4 read endpoint links

5.5 update endpoint links

6. lookup - resource discovery

etc. 

> On Jun 13, 2016, at 5:54 AM, Michael Koster <[email-masked]> wrote:
>

---

From: Michael Koster <[email-masked]>
Date: Mon, 13 Jun 2016 06:07:51 -0700

Do we need an issue written up for this?

Michael

> On Jun 13, 2016, at 6:04 AM, Michael Koster <[email-masked]> wrote:
>

---

From: "Kovatsch, Matthias" <[email-masked]>
Date: Mon, 13 Jun 2016 16:09:56 +0000

Hi Michael

I was slightly confused by the outline in your first mail, but the proposal below is clear. So you want to drop the separation between Simple and Normal RD usage?

I liked having the simple mode in its own section because both discovery and registration are different:

Simple mode:
	Discovery: The node learns about the RD address without support for Web Linking (i.e., evaluating the rt attribute and following links). The URI where to POST comes directly from some kind of bootstrapping (factory or commissioning tool).
	Registration: Empty POST to this URI

	Almost no processing required and no state to keep on the device.

Normal mode:
	Discovery: The node needs to understand Web Linking and find the rt=core.rd resource by following links.
	Registration: POST with payload and query parameters

Then there can be tradeoffs:
	Simple discovery with normal registration: Quite easy to implement in C / constrained devices
	Normal discovery with simple registration: Requires processing, but no state keeping on the device
	Any discovery with reduced normal registration: The device can register selective resources, but does not care about update and de-registration. Again no state keeping on the device.

Currently, I cannot decide how to put these two dimensions into the document structure. I thought it could give a clear message to implementers, when Simple Mode is in its own section. Due to the different combinations, your proposal is actually helpful, but needs a but more text about the choices, I guess.

What is your opinion on removing vs keeping the POST with payload to /.w-k/core?
How about having Simple Mode through an empty POST to the normal core.rd resource? To allow a normal registration with no resources (no idea when this is useful), we could differentiate through the presence of the ep query parameter. When it is missing, the RD has to get the links. This would even enable a more fine-grained adjustment of what to implement, since a device could send an empty POST, but still define the lifetime parameter.

Ciao
Matthias

---

From: Michael Koster <[email-masked]>
Date: Mon, 13 Jun 2016 14:14:13 -0700

Hi Matthias,

I see we could keep the simple stuff together, but in any case section 4.0 Simple Directory Discovery does not describe discovery at all. It describes simple registration.

I think the section about finding a RD should come first in section 4. In this we could describe pre-programmed URI vs. multicast discovery of the function set advertized in .w-k/core, vs some other method like dns or whatever.

Then we could describe simple registration in its own section 4.1 and commissioning tool registration in 4.2 as it is now. I think the POST of links to the RD at .w-k/core is still needed because someone has implemented it (from a previous request to the mailing list). 

----------

4.0 Finding a Directory Server 
how to find a Resource Directory, currently section 4.1

4.1 Simple Registration
how to use POST to the .well-known/core location of the RD, with payload (push) or without payload (pull) currently section 4.0

4.2 Registration using a Commissioning Tool
leave as is

5 how to use the Registration API (used to be called the RD function set) 

6 how to use the Group API

7 how to use the Lookup API

Does this make sense?

Best regards,

Michael

> On Jun 13, 2016, at 9:09 AM, Kovatsch, Matthias <[email-masked]> wrote:
> 
> Hi Michael
>

---

From: peter van der Stok <[email-masked]>
Date: Tue, 14 Jun 2016 09:15:51 +0200

Hi Matthias,

some micro comments:

  I thought it could give a clear message to
> implementers, when Simple Mode is in its own section.

Having done a bit of reorganization in the text, and looking at it, I 
tend to agree with keeping simple mode in a separate section.

> How about having Simple Mode through an empty POST to the normal
> core.rd resource? To allow a normal registration with no resources (no
> idea when this is useful), we could differentiate through the presence
> of the ep query parameter. When it is missing, the RD has to get the
> links. This would even enable a more fine-grained adjustment of what
> to implement, since a device could send an empty POST, but still
> define the lifetime parameter.

The differentiation through the ep parameter looks complex to me, and 
possibly difficult to use correctly in the applications.

peter

---

From: Michael Koster <[email-masked]>
Date: Tue, 14 Jun 2016 05:52:39 -0700

Yes, I agree with Matthias and Peter to keep the simple interaction described in section 4. 

I think, however, it needs to start with an overview of finding a directory server to be coherent.

I propose the following order:

4.1 Simple Registration

Is this OK? 

Michael

> On Jun 14, 2016, at 12:15 AM, peter van der Stok <[email-masked]> wrote:
> 
> Hi Matthias,
> 
> some micro comments:
> 
> 
> Having done a bit of reorganization in the text, and looking at it, I tend to agree with keeping simple mode in a separate section.
> 
> The differentiation through the ep parameter looks complex to me, and possibly difficult to use correctly in the applications.
> 
> peter

---

From: Michael Koster <[email-masked]>
Date: Tue, 14 Jun 2016 06:30:07 -0700

Hi,

My thoughts on extending the simple RD interaction model:

Empty POST to the registration API entry point (/rd) without ep looks the same as POST to .well-known/core. How is it better to use /rd? It seems like more overload of /rd to me.

I don't think registration with no links is useful because nothing wouold be returned on rd-lookup. A "self" link that describes the endpoint itself may be registered to be returned on rd-lookup. 

Lifetime may be useful to add for simple registration but there is no way to refresh in the "pull" pattern. Maybe repeating the POST and pulling the links each time? Also there's no way to delete or otherwise manage the registered links.

I have been thinking about the simple registration use case, and it seems like managing the lifetime out of band and using the source address for ep naming is simple and works in the use case of a simple statically configured system.

Is there a use case for doing more with simple registration?

Best regards,

Michael

[Matthias]
>> define the lifetime parameter.
[Peter]

---

From: peter van der Stok <[email-masked]>
Date: Tue, 14 Jun 2016 16:56:11 +0200

For me this is fine. A bit of overview as proposed by Mathias to show 
the implementation options is welcome.

Peter

Michael Koster schreef op 2016-06-14 14:52:
> how to use POST to the .well-known/core location of the RD, with
> payload (push) or without payload (pull) currently section 4.0
>

---

From: "Kovatsch, Matthias" <[email-masked]>
Date: Tue, 14 Jun 2016 15:13:46 +0000

Why not put
RD Discovery in 4
Simple Registration in 5
Registration API in 6

4.0, 4.1, 4.2 again mixes discovery with simple registration.

Matthias

> -----Ursprüngliche Nachricht-----
> Von: Michael Koster [mailto:[email-masked]]
> Gesendet: Dienstag, 14. Juni 2016 14:53
> An: [email-masked]
> Cc: Kovatsch, Matthias (CT RDA NEC EMB-DE); Kovatsch Matthias; draft-ietf-
> [email-masked]; [email-masked]
> Betreff: Re: [core] #413 (resource-directory): Make Simple Directory Discovery
> really simple
> 
> how to use POST to the .well-known/core location of the RD, with payload (push)
> or without payload (pull) currently section 4.0
> 
> 4.2 Registration using a Commissioning Tool leave as is
> 
> > Having done a bit of reorganization in the text, and looking at it, I tend to agree
> with keeping simple mode in a separate section.
> >
> >> core.rd resource? To allow a normal registration with no resources
> >> (no idea when this is useful), we could differentiate through the
> >> presence of the ep query parameter. When it is missing, the RD has to
> >> get the links. This would even enable a more fine-grained adjustment
> >> of what to implement, since a device could send an empty POST, but
> >> still define the lifetime parameter.
> >
> > The differentiation through the ep parameter looks complex to me, and possibly
> difficult to use correctly in the applications.
> >
> > peter

---

From: Michael Koster <[email-masked]>
Date: Tue, 14 Jun 2016 08:16:22 -0700

Good point. 

There is a lot about RD discovery in the current Registration section 5 that could be moved to the common RD discovery section. It's arguably not part of the registration API to discover the registration API.

Michael

> On Jun 14, 2016, at 8:13 AM, Kovatsch, Matthias <[email-masked]> wrote:
> 
> Why not put
> RD Discovery in 4
> Simple Registration in 5
> Registration API in 6
>

---

From: "Kovatsch, Matthias" <[email-masked]>
Date: Tue, 14 Jun 2016 15:23:13 +0000

Hi

I don't like the overloading when the POST has a payload and ./w-k/core basically has to accept data. If it is just a point to trigger the RD to read out the device, I can at least see picking .w-k/core because it should always be there.

There is also the ep lookup. OCF wants to use RD to resolve ocf://... URIs to actual transfer URIs, that is, the UUID to a transport address. When RD is used as name service, there might be a registration without resources maybe?

Lifetime would tell the RD when to drop the pulled links. To keep them alive, the device would need to trigger again.

When simple registration is used, the RD is in full control over the ep naming and lifetime (even if lt is given). RD could simply pull every time it is triggered, even if it already has entries for the source address. Of course a better implementation would make some checks on the source address.

I want to do less :P
Just triggering and the RD has to pull.
I actually think this would also be fine for the guy who sent the mail that we should not remove Simple Reg completely.

Ciao
Matthias

---

From: Michael Koster <[email-masked]>
Date: Tue, 14 Jun 2016 09:24:30 -0700

> I don’t like the overloading when the POST has a payload and ./w-k/core basically has to accept data. If it is just a point to trigger the RD to read out the device, I can at least see picking .w-k/core because it should always be there.

Right, /rd would already be designed to accept links. Less modification to the .well-known/core resource behavior. 

> There is also the ep lookup. OCF wants to use RD to resolve ocf://… URIs to actual transfer URIs, that is, the UUID to a transport address. When RD is used as name service, there might be a registration without resources maybe?

Thanks, I forgot about ep lookup, which would indeed return links describing endpoints that registered. We should write this in then. It also might be the way a pubsub client registers as an endpoint without exposed resources. et=core.pubsub

> Lifetime would tell the RD when to drop the pulled links. To keep them alive, the device would need to trigger again.

So POST with zero length payload to .well-known/core and query parameters optional, ep, et, lt will trigger a retrieve to the .well-known/core of the requesting endpoint and create a registration. I guess the RD could optionally return the location-path header option for the created links and allow link operations as per the registration API. Or in the simple case the client would need to trigger another retrieve and refresh.

> I actually think this would also be fine for the guy who sent the mail that we should not remove Simple Reg completely.

So, remove the option to push the link payload to .well-known/core; rather use the existing registration API to push links to /rd. This requires the client to do a little more work to find the registration API entry point rather than relying on .well-known/core if it wants to upload links using POST.

Keep the pull option using POST with zero-length payload to .well-known/core as a simple registration pattern. Allow ep, et, and lt parameters on the pull trigger. Allow the RD to return an optional location-path in response to pull trigger, to enable link operations. 

Allow registration of an empty link payload with ep, et, and lt options using both push and pull patterns, to enable endpoint registration and lookup.

This seems to hang together; is it what you had in mind?

Best regards,

Michael

---

From: "Kovatsch, Matthias" <[email-masked]>
Date: Tue, 21 Jun 2016 10:39:48 +0000

Hi Michael

Wow, another week passed again…

I don’t think the client has to do any more. If it is a simple device, some form of bootstrapping (e.g., hardcoding) would configure the /rd resource directly as one would configure /.w-k/core. No discovery needed, just a fire and forget POST with payload.

Yes, the pull option through POSTing to /.w-k/core relieves the device further -> simple registration. Returning a handle might not be useful for simple devices. It furthermore makes it more complicated for the RD: It needs to allocate something directly, answer with the Location handle, and only then starts to pull the resources. The RD could also use a separate response, but then the simple device must be aware that it might have to wait quite long until it receives a response, because the RD has to pull the links for the potentially slow device in the meantime.

I would go for a simple garbage collected solution here: the simple device triggers the pull, may set a lifetime and simply triggers the pull again after (or shortly before) the lifetime ends. The RD either overwrites an existing entry with that source address with the pulled links or creates a new registration if the source address changed; the old registration will be deleted automatically.

There is a small security consideration here: When the source address is spoofed, one could potentially mess up existing registrations. Thus, “pull registrations” must be handled separately from normal registrations.

+1

This sounds very good to me now :)

Best wishes
Matthias