Subject: [core] Comments on draft-ietf-core-observer-05

From: Avi Lior <[email-masked]>
Date: Thu, 14 Jun 2012 22:55:11 -0400

Hi

I am reading draft-ietf-core-observer-05 and I have a couple of comments.

First comment:
Figure 2 shows Observe to have a value of 0 (during registration) but later in the document it is stated that Observe should have no value. If that is true you need to correct the figure.

Second comment:

In 3.5. Cancellation  I have an issue with:

"or when it performs a GET request without an Observe Option for a
currently observed resource, the server will remove the client from
the list of observers for this resource."

Unless I am missing something the above logic will force the server for every request for a resource to check whether or not the requestor is actively observing the resource.  This seems highly inefficient right?

---

From: Klaus Hartke <[email-masked]>
Date: Fri, 15 Jun 2012 10:46:40 +0200

Avi Lior wrote:
> First comment:
> Figure 2 shows Observe to have a value of 0 (during registration) but later
> in the document it is stated that Observe should have no value. If that is
> true you need to correct the figure.

A 'uint' value of 0 is usually encoded with 0 bytes, so the result is
the same as having no value.

It could be clarified that the value of 0 MUST be encoded with 0 bytes
(the 'uint' type also allows other ways), and the two places in the
document should be made consistent.

> Unless I am missing something the above logic will force the server for
> every request for a resource to check whether or not the requestor is
> actively observing the resource.

Right.

> This seems highly inefficient right?

It adds a small overhead when processing a GET request, but I don't
think this overhead is very high. It's usually just a lookup in a hash
table or in a short linked list.

Do you have a specific scenario where the overhead becomes unacceptable?

Klaus

---

From: Avi Lior <[email-masked]>
Date: Fri, 15 Jun 2012 06:23:12 -0400

Hi Klaus,

Please see below.

> document should be made consistent.

AL]  I think it should be clarified.
> Do you have a specific scenario where the overhead becomes unacceptable?

AL]  I don't have a specific scenario. But nevertheless it is sloppy.  If it was the only way you could do it then perhaps, but you are offering two ways of cancelling.  Is there any harm in remove this behaviour and sticking with the more explicit method?

> 
> 
> Klaus
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Klaus Hartke <[email-masked]>
Date: Fri, 15 Jun 2012 12:38:22 +0200

> AL]  I don't have a specific scenario. But nevertheless it is sloppy.  If it was the only way you could do it then perhaps, but you are offering two ways of cancelling.  Is there any harm in remove…

What should be the behaviour when the server promised the client to
notify it when the resource state changes, and the client asks for the
resource state? There are two options: (a) The server tells the client
the current resource state and continues to notify the client of state
changes, or (b) the server tells the client the current resource state
and stops notifying the client of state changes.

-observe eliminates any ambiguity by specifying that a GET request
with an Observe Option always causes (a), and a GET request without an
Observe Option always causes (b). I wouldn't want to see a GET request
without an Observe sometimes cause (a) and sometimes cause (b)
depending on some server state the client cannot see.

Klaus

---

From: Lishitao <[email-masked]>
Date: Mon, 18 Jun 2012 01:43:47 +0000

hi  Avi

If you see my latest draft for draft-li-core-conditional-observe-02, the url is http://datatracker.ietf.org/doc/draft-li-core-conditional-observe/
in this draft it defined an explicit method for cancellation. Actually it has two alternatives that defined in this draft. One way is to use condition type  "Cancellation" to cancel an existing observe relationship that is in 6.1. 
another way is defined in annex A.1, by using cancellation flag that defined in Condition option. 
 Hope that fit your requirements.

Regards
shitao

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Avi Lior
发送时间: 2012年6月15日 18:23
收件人: Klaus Hartke
抄送: [email-masked]
主题: Re: [core] Comments on draft-ietf-core-observer-05

Hi Klaus,

Please see below.