Subject: [core] review draft-ietf-core-observe-02

From: Cullen Jennings <[email-masked]>
Date: Tue, 10 May 2011 07:56:33 -0700

My largest concern with this draft is around the state management. Both how often refreshes need to be done and when state can be removed. 

Consider a case of a light bulb that is subscribed to the value of a light switch. The max-age for that data is likely to be under 1 second. I would not want to see an implementation that thought it should refresh the subscription ever 1 second. I know the draft does not say this, but given what it does say, I can imagine implementers doing this. The really issues is when should the refresh be done. I don't think we are going to be able to define a default value for this that works in a wide range of cases so I think that the set up of the observation needs to negotiate a lower bound on the time. 

I understand the current draft tries to use error on notification as the signal that a subject can stop sending notifications. If there were no intermediaries and the addresses were not reused, I see how this would work but I can imagine cases where it will not work out well. One is when the notification goes to a proxy that always ACKs the notify. The proxy would then try to send the notify on and perhaps get an error but would have no way to communicate that back to the Subject. I can imagine a long list of other ways this could go wrong and result in subscription state that never got cleaned up. 

A observation implies substantial traffic over time - the overhead of having the initial set up negotiate an refresh does not seem like it uses up too many resources. I'd suggest the Observer suggests a time, then the Subject provides a time that is less than or equal to the suggestion. The Observer need to refresh before that point in time. 

Some smaller points ... 

When you talk about matching in section 3.2, I get what you mean by "same security context" but this needs to be carefully defined so there is no confusion.

I think the client, not the server, needs to be in control of if the notifications are sent confirmable or not. It's the client that understands what it is doing with this system and how important it is that it gets all the changes. 

section 3.2 - need to copy retransmission timer as well as the remaining attempts 

Reordering 

This is too much details that constrains the implementations more than needed. I would say that the counter MUST increate in modulo arithmetic and never increase my more than 2^15 in any 32 second period. Then go on to say one way to implement this for devices where the values did not change more frequently than 1ms was use use a 1kHz counter - or something like that. I'm just looking to see a normative statement around the real constraint and then an example of one simple strategy to implement that. 

Cullen <in my individual contributor role>