[core] draft-ietf-core-observe-16 / reregister observation after client restart

["Kraus Achim (INST/ESY4)" <[e-mail]>]

Hello,

analyzing the message flow of some restart/robustness scenarios I found some problems with section 3.1.

"A client MUST aggregate such requests and MUST NOT register more than once for the same target resource. The target resource is identified by all
options in the request that are part of the cache-key."

For a restarting client this is hard to fulfill. It's seems to be common in that case to use the same target resource (including the same "cache-key" options) but with a different random token. So, if such a request would be denied (caused by violating 3.1) , a client would not be able to reregister without storing the original token "restart save".

Searching the mail archive I found, some discussion on that topic (23.9.2014, Adrian Farrel and Klaus Hartke).

"> > Section 3.1
> >
> >    A client ... MUST NOT register more than once for the same target
> >    resource.
> >
> > So, suppose a client does register a second time for the same resource.
> > The server still has to handle it, notwithstanding the "MUST NOT".
> > It can handle it by saying:
> > - I see it is a duplicate, I'll ignore it
> > or
> > - I see it is a duplicate, I'll treat it as a protocol violation and
> >   reject it.
> >
> > But in Section 4.1
> >
> >    If an entry
> >    with a matching endpoint/token pair is already present in the list
> >    (which, for example, happens when the client wishes to reinforce its
> >    interest in a resource), the server MUST NOT add a new entry but MUST
> >    replace or update the existing one.
> >
> > So, you have written text to describe how a server handles this case and
> > you have even described why a client might send a second registration.
> >
> > Can you clarify?
>
> The client can send two things: a request with a token already in use,
> or a request with a new token. In the first case, the server sees it
> is a duplicate and proceeds as described in section 4.1. In the latter
> case, it's not a duplicate, because the token is different. It's also
> not a protocol violation, because we allow the client to observe the
> same resource if the cache-key is different. If the cache-key is not
> different, though, this just wastes the server's resource. That's what
> this MUST prevents.

That's nicely explained. Add it to the draft?"

But I still don't see, how the client restart and reregister should be handled (without storing the used token).

So any hints will be very welcome.

Mit freundlichen Grüßen / Best regards

Achim Kraus

Bosch Software Innovations GmbH
Communications (INST/ESY4)
Stuttgarter Straße 130
71332 Waiblingen
GERMANY
www.bosch-si.de
www.blog.bosch-si.com<http://www.blog.bosch-si.com>

[e-mail]<mailto:[e-mail]>

Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB 148411 B
Executives: Dr.-Ing. Rainer Kallenbach; Michael Hahn