Subject: [core] 🔔 WGLC of draft-ietf-core-observe-11

From: Carsten Bormann <[email-masked]>
Date: Tue, 15 Oct 2013 12:45:54 +0200

After this WG has focused on completing the base specification for a
while, it is time to finish the two complementing specifications,
-observe and -block.  -observe is first:

draft-ietf-core-observe-11 clears all remaining issues in the tracker.
Thanks go to Klaus for patiently addressing all those details.

This starts a second working group last call for -observe, ending on

	24:00 PDT on Tuesday, October 29, 2013.

Please start a new email thread for each major issues that will need
discussion and make sure the subject line includes the draft name and
some sort of name for the issue. For minor issues such as typos and
things that are not likely to lead to much discussion, it is probably
easier to group them all in to one email but again, please make sure
the subject line includes the draft name. If you read the draft and
think it looks fine, please send a one line email to the list or to
the chairs letting us know that so we can get a feel of how broad the
review has been.

We did an IPR call on the first WGLC, but since that some time has elapsed:

If you are aware of any patent claims that might apply to systems that
implement these drafts, please review BCP 78 and BCP 79 and make any
appropriate IPR declaration. If you are not sure whether you need to
make a declaration or not, please talk to the chairs and we will help
get you in touch with people that can provide appropriate advice.

While everyone may still be a bit tired from completing core-coap (and
we are still waiting for the two missing references to go to the RFC
editor), it is important that we all go and review -observe as well.
The people that have participated heavily have read the draft so many
times that they have a hard time noticing what is wrong or missing
from them but fresh eyes can help.  We know that everyone has many
documents to read for the upcoming IETF, but we would like to try and
convince you that reading drafts that are in WGLC is probably more
important than many others.  Please help us get this right.

Grüße, Carsten

---

From: "Rahman, Akbar" <[email-masked]>
Date: Wed, 16 Oct 2013 10:09:44 -0400

Hi Klaus,

Thanks for the good work on the observe draft.  In general, I support advancing the draft.  However, I did  have the following comments/questions:

1) Section 3.6 (Cancellation)
- The procedure for cancelling from a client point of view seems overly complex and inefficient.  Why can't a Reset message from the client always (SHALL) force the server to stop sending notifications?  I.E. Don't have different cases for the confirmable and non-confirmable notification cases.  It seems very risky that a "client may have to wait for a confirmable notification".

- Also wording in Section 3.6 seem somehow not 100% aligned with the text in the last paragraph of Section 1.2.

2) Section 6 (Web Linking)
- The comment in the second paragraph that "obs" should have "a suitable graphical representation in a user interface" was interesting.  This is the first time that I recall seeing user graphical interface references in CORE documents.  I am not objecting to this, but was there some special motivation for putting it?

3) Section 7 (Security Considerations)
- The following sentence should be re-worded for clarity: "The considerations about amplification attacks are somewhat amplified ..."

I am still (re-)reading the document but I thought that I would send you these initial comments in the interim.

Best Regard,

Akbar

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Carsten Bormann
Sent: Tuesday, October 15, 2013 6:46 AM
To: [email-masked] WG
Subject: [core] 🔔 WGLC of draft-ietf-core-observe-11

After this WG has focused on completing the base specification for a while, it is time to finish the two complementing specifications, -observe and -block.  -observe is first:

Please start a new email thread for each major issues that will need discussion and make sure the subject line includes the draft name and some sort of name for the issue. For minor issues such as typos and things that are not likely to lead to much discussion, it is probably easier to group them all in to one email but again, please make sure the subject line includes the draft name. If you read the draft and think it looks fine, please send a one line email to the list or to the chairs letting us know that so we can get a feel of how broad the review has been.

If you are aware of any patent claims that might apply to systems that implement these drafts, please review BCP 78 and BCP 79 and make any appropriate IPR declaration. If you are not sure whether you need to make a declaration or not, please talk to the chairs and we will help get you in touch with people that can provide appropriate advice.

While everyone may still be a bit tired from completing core-coap (and we are still waiting for the two missing references to go to the RFC editor), it is important that we all go and review -observe as well.
The people that have participated heavily have read the draft so many times that they have a hard time noticing what is wrong or missing from them but fresh eyes can help.  We know that everyone has many documents to read for the upcoming IETF, but we would like to try and convince you that reading drafts that are in WGLC is probably more important than many others.  Please help us get this right.

Grüße, Carsten

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

---

From: Klaus Hartke <[email-masked]>
Date: Wed, 16 Oct 2013 18:42:45 +0300

Hi Akbar,

thanks a lot for your review.

> - The procedure for cancelling from a client point of view seems overly complex and inefficient.  Why can't a Reset message from the client always (SHALL) force the server to stop sending notificat…

CoAP initially didn't have support for reset messages in reply to
non-confirmable messages, so a client had to wait for a confirmable
message to tell the server that was no longer interested. This was
changed in observe-04/coap-09, but it requires the server to keep
track of the message IDs of the non-confirmable notifications that it
sends, which is something it didn't have to do before. So the
consensus at that time was to make this requirement OPTIONAL.

I see no strong need to change it to REQUIRED (a client MUST reject
every unwanted non-confirmable notification with a reset message; a
server MUST remember message IDs of non-confirmable notifications for
cancellation): When a reset message doesn't reach the server because
of message loss, the client has to reject notifications anyway until
the server stops sending. And an implementer of a client already
doesn't have to distinguish between confirmable and non-confirmable
notifications if he doesn't want to.

> - The comment in the second paragraph that "obs" should have "a suitable graphical representation in a user interface" was interesting.  This is the first time that I recall seeing user graphical i…

Most clients know if they need a current resource representation over
a period time or not, so the "obs" attribute is mostly useful if the
client is an application-agnostic browser like Copper. So a graphical
representation in a user interface is basically the only known
use-case.

> - The following sentence should be re-worded for clarity: "The considerations about amplification attacks are somewhat amplified ..."

What do you propose?

> I am still (re-)reading the document but I thought that I would send you these initial comments in the interim.

I'm looking forward to further comments/questions from you :-)

Best regards,
Klaus

---

From: Zach Shelby <[email-masked]>
Date: Wed, 16 Oct 2013 08:51:09 -0700

> representation in a user interface is basically the only known

Definitely is a use case, but not the only one. Even though a client may know that it needs to observe a resource, the "obs" attribute tells it that the resource is actually observable in the first place. Otherwise the client would operate by trial and error? There may be other functionality in a client that depends on knowing a priori which resources are observable before trying. But let's not waste time on this one - I do remember having this same conversation before :-) Could be enough to say "graphical representation or other client functionality" or something like that.

Zach 

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com @SensinodeIoT
Mobile: +358 40 7796297
Twitter: @zach_shelby
LinkedIn: http://fi.linkedin.com/in/zachshelby
6LoWPAN Book: http://6lowpan.net

---

From: Klaus Hartke <[email-masked]>
Date: Wed, 16 Oct 2013 19:14:06 +0300

Zach Shelby wrote:
> Definitely is a use case, but not the only one.

So what are other good examples that could be mentioned in the draft?

> Even though a client may know that it needs to observe a resource, the "obs" attribute tells it that the resource is actually observable in the first place.

Every resource is observable, the same way as every resource can be
polled. That's not an interesting property. The interesting question
is whether a client needs a current representation of a resource over
a period of time or not.

> Otherwise the client would operate by trial and error?

If a client needs a current representation of a resource over a period
of time, it sends a GET request with Observe Option and receives a
snapshot of the resource state. Then, either the server supports the
option and has enough room for the client in the list of observers, so
the client is automatically provided with current representations, or
the client sends another GET request with Observe Option when Max-Age
expires to check if the representation is still current.

There is no try. There is only the goal to have a current
representation of a resource over a period of time, and two mechanisms
to achieve it. Do or Do not.

Best regards,
Klaus

---

From: "Rahman, Akbar" <[email-masked]>
Date: Wed, 16 Oct 2013 12:56:23 -0400

Hi Klaus,

For the comment:

>> - The following sentence should be re-worded for clarity: "The
considerations about amplification attacks are somewhat amplified ..."

>What do you propose?

How about:

FROM:
-----
The considerations about amplification attacks are somewhat amplified
when observing resources.

TO:
---
Observing resources can dramatically increase the negative effects of
amplification attacks.  That is, not only can the response packet be
significantly larger than the request packet, but the nature of observe
causes many response packets to be generated.

Best Regards,

Akbar

-----Original Message-----
From: Klaus Hartke [mailto:[email-masked]] 
Sent: Wednesday, October 16, 2013 11:43 AM
To: Rahman, Akbar
Cc: [email-masked] WG
Subject: Re: [core] Some initial comments on WGLC of
draft-ietf-core-observe-11

Hi Akbar,

> - The procedure for cancelling from a client point of view seems
overly complex and inefficient.  Why can't a Reset message from the
client always (SHALL) force the server to stop sending notifications?
I.E. Don't have different cases for the confirmable and non-confirmable
notification cases.  It seems very risky that a "client may have to wait
for a confirmable notification".

CoAP initially didn't have support for reset messages in reply to
non-confirmable messages, so a client had to wait for a confirmable
message to tell the server that was no longer interested. This was
changed in observe-04/coap-09, but it requires the server to keep track
of the message IDs of the non-confirmable notifications that it sends,
which is something it didn't have to do before. So the consensus at that
time was to make this requirement OPTIONAL.

I see no strong need to change it to REQUIRED (a client MUST reject
every unwanted non-confirmable notification with a reset message; a
server MUST remember message IDs of non-confirmable notifications for
cancellation): When a reset message doesn't reach the server because of
message loss, the client has to reject notifications anyway until the
server stops sending. And an implementer of a client already doesn't
have to distinguish between confirmable and non-confirmable
notifications if he doesn't want to.

> - The comment in the second paragraph that "obs" should have "a
suitable graphical representation in a user interface" was interesting.
This is the first time that I recall seeing user graphical interface
references in CORE documents.  I am not objecting to this, but was there
some special motivation for putting it?

Most clients know if they need a current resource representation over a
period time or not, so the "obs" attribute is mostly useful if the
client is an application-agnostic browser like Copper. So a graphical
representation in a user interface is basically the only known use-case.

> - The following sentence should be re-worded for clarity: "The
considerations about amplification attacks are somewhat amplified ..."

What do you propose?

> I am still (re-)reading the document but I thought that I would send
you these initial comments in the interim.

Best regards,
Klaus

---

From: "Rahman, Akbar" <[email-masked]>
Date: Wed, 16 Oct 2013 13:06:34 -0400

Hi Klaus,

Regarding my comment and your answer on section 3.6 (Cancellation).  My
main point was that it seems illogical that a constrained device cannot
always quickly prevent a server from sending it multiple (observe)
messages.   There may be historical reasons for how the Reset message
handling evolved but that shouldn't break the basic client-server
paradigm.  

(I.E. Client is initiating the request and shouldn't have to continually
receive messages that it doesn't want.  It shouldn't be the server that
gets to decide when to stop.  The Observe handling shouldn't break the
basic client-server model.)

But my comment is more a principled one so please ignore it if the
mechanics of the solution is too cumbersome.

Akbar

-----Original Message-----
From: Klaus Hartke [mailto:[email-masked]] 
Sent: Wednesday, October 16, 2013 11:43 AM
To: Rahman, Akbar
Cc: [email-masked] WG
Subject: Re: [core] Some initial comments on WGLC of

Hi Akbar,

What do you propose?

Best regards,
Klaus

---

From: "Peter A. Bigot" <[email-masked]>
Date: Wed, 16 Oct 2013 12:54:13 -0500

I agree with Akbar that it's irritating that a client might get spammed 
by unwanted notifications for up to 24 hours with no way to tell the 
server to stop it.  However I also agree with Klaus that the text as 
written is the best that can be done without providing an explicit 
mechanism to say "shut up already".

Perhaps a solution would be to say that when the server receives a RST 
from an endpoint that participates in observe it SHOULD (or MAY) 
automatically send the next notification to that endpoint as confirmable 
for each resource observed by that endpoint, thus shortening the 
response cycle.

Just a thought; I don't want to defend this approach too much.  Even if 
it doesn't make it into the spec, I think an implementation would still 
be conformant if it did react that way.

Peter

---

From: Klaus Hartke <[email-masked]>
Date: Wed, 16 Oct 2013 21:13:41 +0300

> causes many response packets to be generated.

Fixed in SVN. <http://trac.tools.ietf.org/wg/core/trac/changeset/1525>

Thanks!

- Klaus

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 16 Oct 2013 21:11:56 +0200

> causes many response packets to be generated.

Hmm.  That might be overstating it.
Or if that is not overstating it, maybe we don't pull enough stops.

As long as the server uses confirmable only, it will quickly learn about the disinterest of a spoofed "client".  So the amplification of the amplification will be on the order of MAX_RETRANSMIT.  This wouldn't justify this language.

On to Non-confirmable.  Here, with the current language:

-- we have the 24-hour limit (4.5).

-- we have the three-second limit (4.5), which however is phrased as a SHOULD.

So an attacker could spoof an observation relationship to a fast-changing resource F on S and get S to send 1/3 messages per second to C.  Since port numbers allow spoofing multiple clients at the same host, the actual limit is 2**16/3 messages per second per client host (for 2**16 attack packets).

The three-second limit is conditional on "If the server cannot maintain an RTT estimate for a client,".
If it can (advanced congestion control):

-- "The server SHOULD NOT send more than one non-confirmable notification
   per round-trip time (RTT) to a client on average." (I'm reading this as 1/RTT
   for all resources combined, but that may need to be made explicit.)

So an attacker that knows client C is observing slow-changing resource R on server S, which keeps an RTT estimator running, could spoof an observation relationship to a fast-changing resource F on S and, with a single attack packet, zap C at 1/RTT messages per second until the RTT estimator (run based on the notifications from R) tanks.

Of course nobody in their right mind would design a server this way, but we may need additional language explaining what we expect a server to do here.

Grüße, Carsten

---

From: "Rahman, Akbar" <[email-masked]>
Date: Wed, 16 Oct 2013 15:35:55 -0400

> ... but we may need additional language explaining what we expect a server to do here.

Yes, definitely.

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]] 
Sent: Wednesday, October 16, 2013 3:12 PM
To: Rahman, Akbar
Cc: Klaus Hartke; [email-masked]
Subject: Re: [core] Some initial comments on WGLC of draft-ietf-core-observe-11

On Oct 16, 2013, at 18:56, "Rahman, Akbar" <[email-masked]> wrote:

> significantly larger than the request packet, but the nature of 
> observe causes many response packets to be generated.

Grüße, Carsten

---

From: Klaus Hartke <[email-masked]>
Date: Fri, 18 Oct 2013 19:42:36 +0300

Hi Akbar,

> mechanics of the solution is too cumbersome.

After thinking a bit further about it, changing the client side
wouldn't actually be cumbersome at all, because it doesn't really
change anything. The text in Section 3.6 could be simplified by
removing the distinction between confirmable and non-confirmable
notifications, and a note would be added saying that, due to potential
loss of Reset messages, the client may have to reject multiple
notifications until the server finally removes the entry from the list
of observers.

Requiring the server to remember the message IDs of non-confirmable
notifications needs some discussion, but it's doable as well if there
is enough support in the working group. I guess a constrained server
could always pretend that a Reset message in reply to a
non-confirmable notification was lost. In my CoAP implementation, the
server currently remembers the message ID of a non-confirmable
notification until it starts to transmit the next message to the
client. I believe Erbium and Californium do something similar(?).

If you're asking for cancellation such that the client can actively
cancel an observation instead of only reactively by rejecting
notifications, then the consensus so far was that reactive/"garbage
collection" approach works well enough. We can certainly revisit that
decision, provided that we can make a final decision soon. We need an
alternative cancellation mechanism for some transports anyway (see,
for example, Section 2.4 of [1]). Note that over UDP this would be in
addition to the current mechanism, not in place of it, so it wouldn't
exactly make the protocol simpler.

Best regards,
Klaus

[1] http://tools.ietf.org/html/draft-savolainen-core-coap-websockets-01#section-2.4

---

From: "Rahman, Akbar" <[email-masked]>
Date: Fri, 18 Oct 2013 21:05:57 -0400

Hi Klaus,

Thanks for taking the time to research my question.  My FEEDBACK is
embedded below.

/Akbar

-----Original Message-----
From: Klaus Hartke [mailto:[email-masked]] 
Sent: Friday, October 18, 2013 12:43 PM
To: Rahman, Akbar
Cc: [email-masked] WG
Subject: Re: [core] Some initial comments on WGLC of

Hi Akbar,

> Regarding my comment and your answer on section 3.6 (Cancellation).  
> My main point was that it seems illogical that a constrained device 
> cannot always quickly prevent a server from sending it multiple
(observe)
> (I.E. Client is initiating the request and shouldn't have to 
> continually receive messages that it doesn't want.  It shouldn't be 
> the server that gets to decide when to stop.  The Observe handling 
> shouldn't break the basic client-server model.)
>
>

After thinking a bit further about it, changing the client side wouldn't
actually be cumbersome at all, because it doesn't really change
anything. The text in Section 3.6 could be simplified by removing the
distinction between confirmable and non-confirmable notifications, and a
note would be added saying that, due to potential loss of Reset
messages, the client may have to reject multiple notifications until the
server finally removes the entry from the list of observers.

AKBAR - THIS IS A NICE AND SIMPLE IMPROVEMENT, AND I SUPPORT IT.

Requiring the server to remember the message IDs of non-confirmable
notifications needs some discussion, but it's doable as well if there is
enough support in the working group. I guess a constrained server could
always pretend that a Reset message in reply to a non-confirmable
notification was lost. In my CoAP implementation, the server currently
remembers the message ID of a non-confirmable notification until it
starts to transmit the next message to the client. I believe Erbium and
Californium do something similar(?).

AKBAR - CAN WE JUST PUT IT AS AN IMPLEMENTATION NOTE THEN (AS A
SUGGESTION)?

If you're asking for cancellation such that the client can actively
cancel an observation instead of only reactively by rejecting
notifications, then the consensus so far was that reactive/"garbage
collection" approach works well enough. We can certainly revisit that
decision, provided that we can make a final decision soon. We need an
alternative cancellation mechanism for some transports anyway (see, for
example, Section 2.4 of [1]). Note that over UDP this would be in
addition to the current mechanism, not in place of it, so it wouldn't
exactly make the protocol simpler.

AKBAR - THIS WAS MY INITIAL WISH, BUT I DON'T WANT TO FORCE A DISRUPTIVE
CHANGE AT THIS TIME SINCE EVERYONE ELSE SEEMS OKAY WITH THE CURRENT
OPERATION.  IT SHOULD PROBABLY BE SOMETHING WE LOOK BACK AT WHEN WE
CONSIDER THE OTHER TRANSPORTS IN THE FUTURE.  SO LET'S JUST DROP THIS
ONE FOR NOW.

Best regards,
Klaus

[1]
http://tools.ietf.org/html/draft-savolainen-core-coap-websockets-01#sect
ion-2.4

---

From: Salvatore Loreto <[email-masked]>
Date: Mon, 21 Oct 2013 13:15:18 +0000

Hi Klaus

one comment in line

/Salvatore

> AKBAR - CAN WE JUST PUT IT AS AN IMPLEMENTATION NOTE THEN (AS A

[Salvatore] what if the server that receives a reset from a client for an non-confirmable notification
just set itself to send all the next notifications run to that client in a confirmable way?
that should even easier to implement that remember the message ID of a non-confirmable notification
..

---

From: Salvatore Loreto <[email-masked]>
Date: Mon, 21 Oct 2013 13:16:17 +0000

Hi there,

I have read the draft and I have the following comments

br
/Salvatore

1)
Section 1.1

   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 definitive

   source for representations of the resources in its namespace.

I would suggest to change

s/the server is the definitive source for representations of the resources in its namespace./
  the server is the authority for representations of the resources in its namespace.

aligned to RFC3986 e 6454

by the way in other part of the document it is referred as authority

for example in section 1.3

A CoAP server is the authority for determining

2) Section 2. The Observer option

   The list entry consists of the client

   endpoint and the token specified by the client in the request.

it is not clear if the client endpoint + token is an unique key or not.
It should be clear!

3)

   The Observe Option is not part of the cache-key: a cacheable response

   obtained with an Observe Option in the request can be used to satisfy

   a request without an Observe Option, and vice versa.  When a stored

   response that includes an Observe Option is used to satisfy a normal

   GET request, the option MUST be removed before the response is

   returned to the client.

which is the purpose to store the Observe Option in the cache?

4) Section 3.1

A client therefore MUST aggregate requests where possible, and MUST

   NOT register more than once for the same target resource.

what happens if the client does?
This actually can easily be used for a DoS attack

5) general comment about Caching…
Why we have almost the same text in 3.3 and in 4.3 and subsections?

6) Section 3.3.1

  Additionally,

   the client SHOULD wait for a random amount of time between 5 and 15

   seconds to avoid synchronicity with other clients.

it is not clear that the wait time is supposed to be counted from the moment the
content become stale (time> max-age)

7) 3.3.2 Validation

    this paragraph is not Observe specific, it is just a general rule
    I guess (not remember really) that the same text is already in the core-coap spec

8) Transmission
    Why we have almost the same text in 3.5 and in 4.5 and subsections?

Editorial comments

1) Section 1.3
pag 6 the third bullet has an "and/or" too much

   o  <coap://server/temperature/critical?above=45>, which changes its

      state based on the client-specified parameter value: every second

      to the current temperature reading if the temperature exceeds the

      threshold, or to "OK" when the reading drops below; and/or

On Oct 15, 2013, at 1:45 PM, Carsten Bormann <[email-masked]<mailto:[email-masked]>> wrote:

Grüße, Carsten

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

---

From: Klaus Hartke <[email-masked]>
Date: Mon, 21 Oct 2013 18:32:45 +0300

> AKBAR - THIS IS A NICE AND SIMPLE IMPROVEMENT, AND I SUPPORT IT.

I've created ticket #352 [1]. Of course, this can be further discussed
if other people want to chime in.

Best regards,
Klaus

[1] http://trac.tools.ietf.org/wg/core/trac/ticket/352

---

From: Klaus Hartke <[email-masked]>
Date: Mon, 21 Oct 2013 18:41:18 +0300

Hi Salvatore, Akbar,

>> notification was lost.

Sounds good. Are these implementation techniques something that should
be documented in draft-ietf-core-observe, or would perhaps a better
place be LWIG?

Best regards,
Klaus

---

From: "Rahman, Akbar" <[email-masked]>
Date: Mon, 21 Oct 2013 15:59:53 -0400

Hi Klaus,

My vote would be to put it in draft-ietf-core-observe (following the
esteemed example of core-coap-18 which has about a dozen such
implementation notes).

Akbar 

-----Original Message-----
From: Klaus Hartke [mailto:[email-masked]] 
Sent: Monday, October 21, 2013 11:41 AM
To: Salvatore Loreto
Cc: Rahman, Akbar; <[email-masked]>
Subject: Re: [core] Some initial comments on WGLC of

Hi Salvatore, Akbar,

>> non-confirmable notification was lost.
>>
> [Salvatore] what if the server that receives a reset from a client for

> an non-confirmable notification just set itself to send all the next
notifications run to that client in a confirmable way?
> that should even easier to implement that remember the message ID of a

> non-confirmable notification

Best regards,
Klaus

---

From: "weigengyu" <[email-masked]>
Date: Wed, 30 Oct 2013 13:16:38 +0800

Hi, all, 

I have a question on  "2. The Observe Option" 

"The Observe Option, when present in a request, extends the GET method
so it does not only retrieve a current representation of the target
resource, but also requests the server to add a new entry to the list
of observers of the resource. The list entry consists of the client
endpoint and the token specified by the client in the request.

The value of the Observe Option in a request MUST be empty on
transmission and MUST be ignored on reception. " 

Why the Observe Option in a request MUST be empty ? 

It can be empty for the simplest request. 
And it can convey more information if being used. 

regards, 

Gengyu 

Network Technology Center,
School of Computer, 
Beijing University of Posts & Telecommunications.

---

From: Klaus Hartke <[email-masked]>
Date: Wed, 30 Oct 2013 07:22:18 +0200

Hi Salvatore,

thanks a lot for your review and sorry for the delayed response.

>   the server is the authority for representations of the resources in its

Fixed in SVN.

> it is not clear if the client endpoint + token is an unique key or not.

The text in section 4.1 says that

   If an entry with a matching endpoint/token pair is already
   present in the list [of observers of a resource] [...], the
   server MUST NOT add a new entry but MUST replace or
   update the existing one.

>From this follows that there are never two entries with the same
client endpoint and request token in the list of observers of a
resource.

How much of this needs to said in section 2?

> which is the purpose to store the Observe Option in the cache?

It doesn't really matter if an implementation keeps the Observe option
when storing a notification in a cache or not. What's important is
that a response returned in reply to a GET request without an Observe
option does not include an Observe option as well. The only situation
where this could happen is when the server keeps the Observe option in
a notification and uses the notification to satisfy a GET request
without an Observe option.

> 4) Section 3.1
>    A client [...] MUST NOT register more than once
>    for the same target resource.
>

The client receives the same notifications multiple times, which
unnecessarily wastes both the server's and the client's resources. It
also leads to a slot in the list of observers being occupied that
could otherwise be used by another client. The server is not required
to detect a violation of this requirement, though.

Should this be mentioned in the draft?

> This actually can easily be used for a DoS attack

Can you expand on this?

Should it be mentioned in the Security Considerations?

>     Why we have almost the same text in 3.5 and in 4.5 and subsections?

Until draft-ietf-core-observe-03, there was only one section that
contained the requirements for both client and server. This made the
text a bit difficult to read, so the whole document was split in
observe-04. In general, one section now contains the requirements for
one side, and the other section gives a short summary what the other
side can expect (and vice versa). As long as both sections are
consistent, I see no harm in a bit of redundancy.

> it is not clear that the wait time is supposed to be counted from the moment
> the content become stale (time> max-age)

Fixed in SVN.

>     I guess (not remember really) that the same text is already in the

It may not be entirely obvious that validation can be used in
conjunction with resource observation. So this section and section
4.3.2 provide a short summary of what's in draft-ietf-core-coap and
point out a few observation-specific details. For example, section
4.3.2 makes it clear (or hopefully clear enough) that a server can
only return a 2.03 (Valid) response if the ETag matches one of the
ETags in the request, and cannot return such a response if the ETag
just matches the ETag of a previous notification it sent.

> pag 6 the third bullet has an "and/or" too much

Fixed in SVN.

Best regards,
Klaus

---

From: Klaus Hartke <[email-masked]>
Date: Wed, 30 Oct 2013 07:29:09 +0200

weigengyu wrote:
> "The value of the Observe Option in a request MUST be empty on
> It can be empty for the simplest request. And it can convey more information
> if being used.

draft-ietf-core-observe currently defines no information that could be
used as a value of the Observe Option. So, to preserve the opportunity
to define such information later, the current version of the protocol
requires that the option value is empty.

Best regards,
Klaus

---

From: "weigengyu" <[email-masked]>
Date: Thu, 31 Oct 2013 10:59:23 +0800

Hi，Claus，

Thank you for your answers.
And the mail is CCed to the mailing list.

>>  Then the intermediary polls the next hop or polls the other next hop?
> I'm not sure which other hop you mean, but the intermediary polls the next 
> hop.

What I want to ask is that the intermeidiary has only one the next hop, or 
has some next hops (neighbors).
If there is only one next hop, it is assumed that the chain formed by 
intermediaries between the  client and the server is a single chain.

Then,question about Observe Option and Polling.
In the core-observe-11,
" In a response, the Observe Option identifies the message as a
notification. This implies that the server has added the client to
the list of observers and that it will notify the client of changes
to the resource state. "

If an response is without  the Observe Option, what does it implicitly or 
explicitly tell "the client" ?
Probably the draft means that the response message identifies
(1) it is a notification containing the server's current value (maybe 
cached);
(2) the server has NOT added the client to the list of observers, and that 
it will NOT notify further.

The POLLING is required because notifications will not actively send out to 
"the client".

The response without the Observe Option may come from the original server or 
from a intermediary.
After it can get "the response without the Observe Option",
the original client will proactively send request of GET, but it may  get a 
cached value within a intermediary.
The POLLING frequency of the intermediary will affect the value of response,
the value may not represents the server's change instantly, or the 
up-to-date value of the original client request.

I guess, wether the cach mechanism could be suspended in this case or the 
original client has to tolerance the delay.

And if there are two or more intermediaries,
the intermediary of most near to the original server send the response 
without the Observe Option,
and the following intermediarie should send the response without the Observe 
Option too untile to the original client.
Polling messages may occure between intermediaries.
Without clear objective, the Polling messages between intermediaries are 
useless.

regards,

gengyu

Network Technology Center,
School of Computer,
Beijing University of Posts & Telecommunications

-----原始邮件----- 
From: Klaus Hartke
Sent: Thursday, October 31, 2013 3:38 AM
To: weigengyu
Subject: Re: [core] Some initial comments on WGLC of 

Hi Gengyu,

thank you for your excellent questions. (Why didn't you send them to
the mailing list?)

> Does the draft mean "the next hop does not response" or "the next hop
> returns a response without an Observe Option"?

The draft means "the next hop returns a response without an Observe
Option". I will clarify this in the next update of the draft.

> Then the intermediary polls the next hop or polls the other next hop?

I'm not sure which other hop you mean, but the intermediary polls the next 
hop.

> Because the intermediary does not understand the applicatoin semantics
> according to core-CoAP-18, how often to poll is unclear.

draft-ietf-core-coap-18 and draft-ietf-core-observe-11 indeed state no
explicit requirements on polling.

It depends a bit on the client (or intermediary in the role of the
client) how often it needs to poll to make sure it has a fresh
representation of the target resource. As long as the client has a
fresh representation, there is probably little need to poll the next
hop. So the following recommendations from section 3.3.1 of
draft-ietf-core-observe-11 could be applied to polling as well:

   It is RECOMMENDED
   that the client does not issue the request while it still has a fresh
   notification/response for the resource in its cache.  Additionally,
   the client SHOULD wait for a random amount of time between 5 and 15
   seconds to avoid synchronicity with other clients.

Best regards,
Klaus