Re: [core] Questions on draft-ietf-core-resource-directory-12

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

Hello Jim, Peter,

On Thu, Apr 05, 2018 at 09:51:25AM +0200, peter van der Stok wrote:
> Idempotency says that applying the same operation multiple times should lead
> to the same result independent of the number of times.
> The problem is: what is the same operation; If only ep and d are relevant
> then applying multiple times an operation (registration) with the same ep
> and d values indeed leads to the same result ignoring all other attribute
> values (including location)
> 
> If one says that the same operation implies that all other specification
> parameters are unchanged, then indeed location should not be changed in that
> case.
> 
> What view do you adhere to?
> 
> And do you suggest we should insert clarifying text?

We should look at why we are requiring idempotency here.

From what I can tell, this is because CoAP servers and clients are
easier to implement if they can rely on the operation to be idempotent,
but they are looking at the very same request being sent again in a
relatively short time frame.

An additional use case here is stability in presence of "semi-simple"
clients that POST their .well-known/core to the directory resource every
few hours and never try to parse the Location returned. If those change
the registration resource address every time, an observation on the
endpoint lookup becomes needlessly noisy.

As long as those are the cases we consider, I think that it is
sufficient to specify that the registration operation must return the
same response to a CoAP request with the same requester / security
context, code, options and payload within EXCHANGE_LIFETIME.

The concern for observation stability is more a matter of implementation
quality, where me can recommend but need not specify.

> > 3.  How are href comparisons done.
> > 	a) compare against what was registered
> > 	b) Resolve what was registered and the href in the current context
> > and compare
> > 	c) something I did not think of
> 
> probably someone else wants to react as well.
> The model in the RD stores the target as specified in /.well-known/core of
> the source.
> At lookup the links are resolved against con.
> Consequently, the comparison of href is the comparison versus the target as
> stored in the RD and as copied from /.well-knwon/core.

I think the more convenient thing to do is to say that resources are
compared against the full path, and registrations and group resources
(they can be matched too) are matched against whatever is returned in
endpoint lookup.

That would be more intuitive to the user of the lookup (matching against
what is returned).

> > If I do the lookup of
> > /rd/gp-lookup?rt=foobar
> > 
> > And one of the groups has the following
> > 
> > /rd-group/xxx
> > https://otherrd/rd-group/yyy
> > 
> > I would follow the local group definition to find out if the
> > resource type is defined on some resource in the group, however the
> > question is do I need to go and query the other group which is not
> > local in order to do the same tree walking when doing attribute
> > comparisons.  Not that this applies to remote endpoint registrations
> > in a group as well.
> 
> Thanks for the example.
> Indeed following the latest text, the comparison should include the remote
> registration.
> 
> The text could include words like tree walking is done locally only;
> personally I would not be too happy about that.
> Apparently the text should say something about remote groups and tree
> walking. I will add the issue to github.

I think that this is out of scope for RD itself. What I'd like to have
in RD is the text that ensures that clients will not get upset when they
see absolute URIs in group or endpoint lookups.

We are not actually describing a distributed RD here, this is only to
keep the door open for such extensions.

Would it help if we changed the example to say

GET coap://rd.example.com/ep?gp=lights1
Res: 2.05 Content
<coap+tcp://rd.example.com/rd/abcd>;con="coap://[2001:db8:3::123]:61616";
ep="node1";et="oic.d.sensor";ct="40";lt="600",
</rd/efgh>;con="coap://[2001:db8:3::124]:61616";
ep="node2";et="oic.d.sensor";ct="40";lt="600"

? It would just indicate that the registration resource is hosted by the
same RD but on another protocol (presumably because the endpoint
registered using coap+tcp, and that Location can't just jump protocols).


> > 5.  Value of lt = should it be the set parameter or the time left -
> > how would time left be represented outherwise - should it be represented.
> 
> Right on the nail. This is very vaguely specified. The unit is
> specified as seconds.
> In my expectation the returned lt value is the time in seconds
> from lookup till end.
> 
> Other opinions by my co-authors?  If we all agree, we specify it as
> such in the RD spec.

My expectation is that lt= is the registered value and never decreases.
(For an additional value that indicates where the registration is in its
lifetime, I've suggested lt-age in draft-amsuess-core-rd-replication-01
-- but only because there's an application for it there). Having lt
decrease is problematic with caching (admittedly, so is lt-age).

What use cases do we have for exposing a lifetime in the endpoint lookup
at all?

(If we have none, an RD might just as well not display a lifetime).

> > POST /rd?ep=node1
> >    - payload contains the set of resources the register.
> >    - returns a location of /rd/yyyy
> > 
> > POST /rd/yyyy?ep=node1
> >    - payload is empty.
> > 
> > In the first post, the rd will infer a context based on how the
> > registration is done.  The second post just says that the TTL value
> > is to be refreshed back to the life-time value.  However, the
> > inferred context could also be changed.
> 
> Thanks for the example; it would take me long to figure this out otherwise.
> 
> Reading the update specification, the ep=node1 is illegal in the update.
> Specifying ep means creating a new registration.

ep=node1 would be ...well not technically illegal (the template would
put the ep in extra-attrs, and the server hopefully not store it there);
it is an attribute that is not changing and therefore SHOULD NOT be
included in the update by the client.

A changed ep would not create a new registration (we're at a
registration resource already), but simply be refused.

> sending the update
> POST /rd/yyy will update the lt value.
> It is allowed to change the value of con in the update POST specification.
> The question is:
> When an updating ep, different from the registering one, sends the update of
> lt, does the context change to the hosts relation value of the updating ep.
> 
> My gut reaction is no. it does not change the context value in the RD
> because that needs an explicit ?con= in the update specification.
> 
> A warning in the RD text to this effect looks reasonable.

The text is already pretty explicit:

    "If the parameter is set in an update, it is stored by the RD as the
    new Base URI under which to interpret the links of the registration,
    following the same restrictions as in the registration.  If the
    parameter is not set and was set explicitly before, the previous
    context value is kept unmodified.  If the parameter is not set and
    was not set explicitly before either, the source address and source
    port of the update request are stored as the context."

This allows for clients that do not keep a good eye on their addresses
but have their OS pick the latest one.

Note that nobody other than the endpoint (or CT if created by one) may
manipulate a registration resource.

(If we wanted to allow other hosts to manipulate a different endpoint's
registration, we'd need something like a ?ct=keep or change in semantics
to allow that -- but I'd like to have a good reason to do that in the
first place).


> > 7.  I don't understand the presence of the content-format for the
> > empty message posted for simple registration.  This seems to be odd if
> > the content is empty.
>
> [...]
>
> Would accept be a better option to use?  This would allow for more than
> one value to be specified.

It should be neither; that request is empty and so is the response.

The RD will need to probe for the content format of its own (possibly
trying its preferred content format first, falling back to an empty
accept or 40).

The best equivalent of "and look there expecting this content format"
would be HTTP's link header (a la 'POST /.w-k/c?ep=node1, Link:
<coap://myself/.well-known/core>;ct="40 64 504"'), and we can't do that
in CoAP, at the very least not in a simple registration.


> > > 8  Is there supposed to be a way for simple registration to return an
> > > error message?  As written this is not necessarily done.
> > > Specifically, the response to the post can be executed before the
> > > query to /.well-known/core is done and the registration is attempted.
> > 
> > I see what you mean: also the return of 2.04 shows in the example
> > but not in the specification.
> > This warrants additional text to specify the simple registration text.
> 
> will add the simple registration template to the text.

I think that the more important question behind is of whether the RD
should (or may) wait with a response until it has fetched the .w-k/c of
the endpoint. The example shows "respond first, then ask details", which
we might consider prescribing given that highly constrained clients
might not manage to multi-task the request and the response. (Dealing
5.03 Sorry I'm Busy until their pending request is answered or expired).


Best regards
Christian

(updating the issue tracker in parallel)

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