Subject: Re: [core] Adrian Farrel's No Objection on draft-ietf-core-observe-14: (with COMMENT)

From: Klaus Hartke <[email-masked]>
Date: Mon, 22 Sep 2014 16:23:13 +0200

Hi Adrian,

thank you for your review and suggestions.

Adrian Farrel wrote:
> Section 1.1 needs to explain what is a "resource". There is a special
> meaning in the context of this document (I think) that is not the same
> as the "network resource" that other people working in constrained
> networks might consider. You should be able to slot this in to...
>
>    The model of REST is that of a client exchanging representations of
>    resources with a server, where a representation captures the current
>    or intended state of a resource and the server is the authority for
>    representations of the resources in its namespace.  A client
>    interested in the state of a resource initiates a request to the
>    server; the server then returns a response with a representation of
>    the resource that is current at the time of the request.

The draft is an extension of CoAP, so readers are expected to be
familiar with the CoAP terminology. There is also a reference for REST
in the preceding paragraph which explains what a resource is in
detail. (Btw, neither RFC7252 nor RFC7230 contain a definition of the
term.)

> I was doing well in understanding how this protocol was a trade-off in
> optimization. A repeated Get/response exchange is heavy on network
> resources. A register/push system (like hear) addresses that but trades
> it for state on the server. You can't win, but you can choose, and this
> document appears to make a choice.
>
> And then, in Section 1.2...
>
>    A client remains on the list of observers as long as the server can
>    determine the client's continued interest in the resource.  The
>    interest is determined from the client's acknowledgement of
>    notifications sent in confirmable CoAP messages by the server.  When
>    the client deregisters, rejects a notification, or the transmission
>    of a notification times out after several transmission attempts, the
>    client is considered no longer interested and is removed from the
>    list of observers by the server.
>
> So this has two problems:
> 1. It appears to say that the Get/response mode is replaced with
>    register/push/ack which does not reduce the message flows and causes
>    the server to retain even more state :-(
> 2. "client's acknowledgement of notifications sent in confirmable CoAP
>    messages by the server" is ambiguous. It could be read to say that
>    the aknowledgements are sent in confirmable messages by the server!
>
> I think you need some more clarity in this paragraph. How about...
>
>    A client remains on the list of observers as long as the server can
>    determine the client's continued interest in the resource.  The may
>    server send a notification in a confirmable CoAP messages to request
>    an acknowledgement by the client.

Done.

>    When the client deregisters,
>    rejects a notification, _fails to respond to a confirmable CoAP
>    message_, or when the transmission of a notification by the server
>    times out after several transmission attempts, the client is
>    considered to be no longer interested and is removed from the list of
>    observers by the server.

The client is not removed immediately when it fails to respond -- the
server performs multiple transmission attempts to get the notification
to the client. Only if the client has not responded before the last
transmission attempt times out, the client is removed. There are
usually 5 transmission attempts [0].

[0] http://tools.ietf.org/html/rfc7252#section-4.8

> Maybe the document is also missing guidance about how often to seek
> confirmation.

There is some guidance in the last paragraph of section 4.5 [1] and in
the security considerations in section 7 [2]. Apart from this, the
choice is entirely up to the application.

[1] http://tools.ietf.org/html/draft-ietf-core-observe-14#section-4.5
[2] http://tools.ietf.org/html/draft-ietf-core-observe-14#section-7

> Section 2 jumps in a little with some assumptions of how much the reader
> knows about CoAP.  Of course, it is reasonable to assume familiarity,
> but maybe some references for what an Option is and how it is encoded?

The draft uses a lot of what's defined in the CoAP base specification
(options, option formats, confirmable and non-confirmable messages,
requests and responses, ...). Readers are really expected to be
familiar with CoAP before they implement this extension.

> 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.

> Section 3.3.1
>
>    A client MAY store a notification like a response in its cache and
>    use a stored notification that is fresh without contacting the
>    server.
>
> This reads very much like an implementation detail rather than a
> protocol specification.
>
> From a protocol point of view the information in the notification is
> fresh until it times out. What use the client makes of that is surely
> up to the client.

Section 5.6 of the CoAP base specification [3] says:

   "CoAP endpoints MAY cache responses in order to reduce the response
   time and network bandwidth consumption on future, equivalent
   requests."

The above sentence just extends this from responses to notifications
(although this is a bit redundant, because notifications are
responses). But I see what you mean. Does the following look better
you?

   A client MAY cache a notification like a response and MAY use
   a fresh notification to satisfy future, equivalent requests (with or
   without an Observe Option) without contacting the server.
   Like a response, a notification is considered fresh while
   its age is not greater than the value indicated by the Max-Age Option
   (and no newer notification/response has been received).

[3] http://tools.ietf.org/html/rfc7252#section-5.6

> Section 3.5
>
>    An acknowledgement message signals to the server that the client is
>    alive and interested in receiving further notifications; if the
>    server does not receive an acknowledgement in reply to a confirmable
>    notification, it will assume that the client is no longer interested
>    and will eventually remove the associated entry from the list of
>    observers.
>
> Now. Suppose the notification or acknowledgement is lost (I think
> message loss is possible in CoAP, right?). Or suppose there is
> reordering so that the confirmable notification is overtaken by a
> subsequent non-confirmable notification? Shouldn't the server have a
> slightly more rigorous approach to determining that a client is no
> longer interested in notifications to avoid falsely removing an
> interested client?
>
> Perhaps that is what "eventually" is supposed to convey, but that is
> not a suitable word for including in a protocol spec.

The normative requirements for the server are in section 4.5 [4] of
the draft. The above paragraph in section 3.5 is just a non-normative
summary of what to expect for implementers of the client side. I'm
adding a reference to section 4.5 so the normative text is easier to
be found.

[4] http://tools.ietf.org/html/draft-ietf-core-observe-14#section-4.5

Klaus

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 22 Sep 2014 19:02:05 +0100

Hi,

Thanks for engaging in this discussion.
My Comments are only comments and can be ignored.

> detail. (Btw, neither RFC7252 nor RFC7230 contain a definition of the

You make my point for me :-)
There is also no definition I can find in 6690.
7252 does have a reference to 2616 which has
   resource
      A network data object or service that can be identified by a URI,
      as defined in section 3.2. Resources may be available in multiple
      representations (e.g. multiple languages, data formats, size, and
      resolutions) or vary in other ways.

Of course, this is pretty damn general. Perhaps that is the intention. Or perhaps CORE is working on a subset of this definition.

(BTW, the use of "link" as in 6690 makes the whole discussion of "what is a resource?" even more amusing.)

> > resources. A register/push system (like here) addresses that but trades

Yeah, that's OK. But it is still a failure to respond. Just a different measure.

> [2] http://tools.ietf.org/html/draft-ietf-core-observe-14#section-7

If you're sure that this will not cause a problem with interoperability, then that is OK.
Maybe say that is it up to the application.

> familiar with CoAP before they implement this extension.

Sure, sure.
But it is nice to make a document a little more readable.

> different, though, this just wastes the server's resource. That's what

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

>    (and no newer notification/response has been received).

Yes. Nice.
Could also add something like "...as generally allowed in a CoAP implementation [RFC7252]..."
 
> adding a reference to section 4.5 so the normative text is easier to

OK

Thanks,
Adrian