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

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

Hello Jim, hello RD authors,

On Sun, Apr 15, 2018 at 01:49:38PM -0700, Jim Schaad wrote:
> I am less worried about the observation jitter problems than I am about the
> turnover on groups.  Given that groups are defined in terms of the href
> returned from an endpoint registration this means that groups are going to
> be updated every time.  I really think that the location needs to not change
> for the lifetime of the registration not just the EXCHANGE_LIFETIME.  I am
> not sure that idempotent means anything useful when looking at doing
> registrations because I don't really know what it would mean to say
> something is idempotent here.   Does it mean that if nothing changes then
> nothing happens or just that if you register the same thing then the same
> set of events should happen w/ the same outcomes.

But the location does not change over the lifetime of the registration
(see also my parallel response to Peter at [1]) unless I got something
very wrong.

Only if an endpoint re-registers (ie. sends the same POST to /rd),
long-term idempotency does become the matter. But I'd argue that this is
close enough to situations of "the EP did not update its registration in
time and already got kicked out" than to regular updates.

Not that we'd already have an answer to how group management interacts
with temporarily timed-out clients; maybe we should solve that first and
then come back to the topic of idempotency.

[1]: https://mailarchive.ietf.org/arch/msg/core/IYkEs59MMdPWPH5nOjiYyO6juFY

> > > > 3.  How are href comparisons done.
> [...]
> 
> I am not sure what you are saying.  I do comparison followed by
> serialization at the moment.  I do the resolution during serialization and
> not during comparison.  This is the reason that I was asking the question.

I'd say "compare the resolved absolute references", in other words
"resolve, then compare, then serialize". That's more work for the RD
(and for you as an implementor), but matches more closely the
expectations of the client, and should be better suited for later steps
with protocol-negotiation.

> > 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).
> 
> Yeah, that whole question jumps back to the question - if it is on a
> different schema is it the same resource or a different resource.   I think
> that the example with the explanation would be better.

Unless something explicitly says that it is the same, it is not.

Text proposal at [2] for review by the other authors.

[2]: https://github.com/core-wg/resource-directory/pull/129

> > 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).
> 
> All of the cases that I can think of can be done with observe.  I think that
> this probably does not need to be discussed except to say that max-age
> should not be set to this value.

There is always a Max-Age, it has a default value of 60 (seconds).

> > 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).
> 
> I would have done an ACK (to stop resends) followed by a response when the
> resources had been queried rather than returning two different responses
> that are different and would need to have a pending.  If the client cannot
> wait for the response, it knows that the message is being processed.
> However it would know not to shutdown until it has gotten a final answer.  I
> don't see any need to return some type of busy.  The constrained client
> should be able to respond to questions while it is in the middle of asking
> one.

I was not so much thinking about returning "busy" than about returning
"Success" in the sense of "I've got your request; whatever happens
further is out of your control".

Given that two RDs are behaving observably different here, I'm opening
this as an issue (basically "should we manadate your behavior or is
either fine, and if the latter do we need to warn simple client
implementors?") at [3].

[3]: https://github.com/core-wg/resource-directory/issues/130

Thanks for your input
Christian

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