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

From: Cullen Jennings <[email-masked]>
Date: Tue, 17 Apr 2012 22:58:18 -0600

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. 

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.

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 20 Apr 2012 18:34:10 +0200

> 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 that is an essential requirement if we have the aborting mechanism in place (which, in turn, I think is also an essential requirement).

Imagine the client goes away.
Without this, if a server has a new value for the resource every five seconds, it will send the new value and set back the binary exponential back-off to the first attempt.  It will

1) send retransmission packets at a rate of a packet every 2.5 seconds (OK, that is not yet a disaster)

2) it will never notice the client is gone.

Grüße, Carsten

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 20 Apr 2012 14:26:25 -0600

> 2) it will never notice the client is gone.

I certainly agree that we need a way to notice the client is gone. I would have proposed that if you abort the previous transaction, then you need to copy over the retransmit state to the new transaction. But if you don't cancel the old transaction, the device still finds out the device is gone.