Subject: Re: [core] WGLC comments on draft-ietf-core-observe-05

From: Ernesto Garcia <[email-masked]>
Date: Thu, 10 May 2012 12:46:54 +0200

On Wed, Apr 18, 2012 at 6:58 AM, Cullen Jennings <[email-masked]> wrote:

>
>
> Imagine a server that always sends non confirmable requests. Does it send
> forever? Even after client crashes and a new device that is not CoAP aware
> gets the same IP address?
>
>
> The condition in paragraph 2 of section 3.4 confuses me. Can you just
> explain what is going on and what the requirement for "not fresh" is.
>
> Section 3.5. I don't think you can remove a client from observer list
> based purely on source IP, you need to use source IP and source port.
> Without this two different clients behind a NAT would remove each other
> when talking to a server outside the NAT. Similar problems with moor than
> one coap client on the same host. Same issue in section 4.1 when adding a
> lint to lis of observers.
>
> Section 4.3 Using Max-Age to indicate when server will send next
> notification is just wrong. That's not what max-age means. We need separate
> control of how long data is fresh, and how often the client needs to
> refresh the subscription. There should be some limit, probably less than 24
> hours, on max lifetime of subscription without a refresh.
>

I agree with your comment, Cullen about section 4.3. We need a mechanism to
know if the client is gone, and other for refreshing data.  I would propose
a keep a live mechanism to keep in touch with the client.
But also I think the Max-age value should consider in some manner the delay
toward the client. I'm supposing if a client receives a max-age with a
value of 5 seconds, it supposes that the next data would be received not
latter than 5 seconds.

I'm basing my comments in the paragraph of section 4.3, it says:

If the client does not receive a new notification before Max-Age ends,
it will assume that it was removed
   from the list of observers (e.g., due to a loss of server state) and
   may issue a new GET request to re-register its interest.

But this value considers the delay or conditions of the network? I mean,
the value of Max-age could end while the notification is in transit to the
client depending on the network conditions.

>
> Last paragraph of section 4.2 says MAY remove but I think this needs to be
> a MUST remove.
>
> End of section 4.3. Could give a nice example here of an switch that
> return two different XML bodies that indicate if it is on or off but map to
> a ETAG or 0 and 1 and how that helps reduce bandwidth usage.
>
> Section 4.4 - I'm confused about the algorithm here. Does this mandate
> that the resource can ever changes more than once per second ? For many
> applications I want way faster updates than this. I don't think this works.
>
> Section 4.5, the stuff about stoping the old transmission and caring the
> retransmit count over to new transaction is hard to implement in some cases
> and often a minor optimization for an edge case. I think this house be MAY
> not MUST
>
> Section 8 - Nosec mode. Thought I agree with this, this is not clear how I
> could implement this. I think we need more detailed advice on what an
> implementer needs to do.
>
>
> Instead of _foo_ style, for words that you want to have a specific defined
> meaning in the doc, start them with a capital.
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>