Subject: Re: [core] #204: Introduce a minimal version of Pledge

From: "core issue tracker" <[email-masked]>
Date: Wed, 04 Apr 2012 19:44:19 -0000

#204: Introduce a minimal version of Pledge

Comment (by cabo@…):

 When we briefly discussed this again during the Friday meeting, the sense
 of the room went towards:

 -- the basic mechanism (i.e., in the draft now) works for some, not all,
 applications
 -- any potential extensions should be done in a separate draft

 (The sense of the room is not a final WG decision of course, but a good
 indication of direction.)

 If we stay with this direction, we should review the text to make sure:
 -- it is clear about the way this works with non-cacheable resources
 -- the way max-age is used now can be made into a default behavior for the
 potential future options we have started to discuss

-- 
----------------------------------+----------------------------------------
 Reporter:  cabo@…                |       Owner:  draft-ietf-core-observe@…
     Type:  protocol enhancement  |      Status:  new
 Priority:  major                 |   Milestone:
Component:  observe               |     Version:
 Severity:  In WG Last Call       |  Resolution:
 Keywords:                        |
----------------------------------+----------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/204#comment:1>
core <http://tools.ietf.org/core/>

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 4 Apr 2012 22:15:37 +0200

>   indication of direction.)

the chairs have started a WG last call for the Observer draft
try to insert extensions (or make any significant technical changes) in 
a document
in last call is a *bad* thing at least IMO

as any technical change requires some time to be discussed, understood 
etc. etc.

>   If we stay with this direction, we should review the text to make sure:

are you talking of text in Observer draft (that is in WG Last Call =-O ) 
or in some other draft?

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 4 Apr 2012 22:35:45 +0200

On Apr 4, 2012, at 22:15, Salvatore Loreto wrote:

> try to insert extensions (or make any significant technical changes) in a document

Yes, I think in this case that was also the sense of the room, and I tried to document this direction in the ticket comment.
Any such extension would come later, on top of what we agree to do as the base mechanism now.
Sorry if I didn't make myself clear enough.

> as any technical change requires some time to be discussed, understood etc. etc.

Right.
So we decided*) to keep -observe as is, but make sure we can extend it later.
*) ...with the usual qualifications on how things are decided in the IETF.

> are you talking of text in Observer draft (that is in WG Last Call =-O ) 

Yes.
I wanted to make sure we capture in the ticket the specific need for looking at these two points.
Apologies if my summary was too brief.

Grüße, Carsten

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 4 Apr 2012 22:46:00 +0200

> *) ...with the usual qualifications on how things are decided in the IETF.

that is "rough consensus and running code"
as the IETF83 t-shirt reminds us

> Apologies if my summary was too brief.

this two points are quite important if not crucial as they (can) change 
somehow the mechanism !
are you thinking to include them in the draft version following up the 
WGLC ?

/Sal

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 4 Apr 2012 23:23:29 +0200

On Apr 4, 2012, at 22:46, Salvatore Loreto wrote:

> are you thinking to include them in the draft version following up the WGLC ?

I haven't done the review yet, so I don't know whether this will result in changes, editorial or even technical.
I just wanted to capture the points in the ticket, because they came up in the meeting and I wasn't sure they were discussed yet.

Grüße, Carsten

---

From: Jeroen Hoebeke <[email-masked]>
Date: Thu, 5 Apr 2012 10:00:58 +0200

Hi Salvatore,
> in last call is a *bad* thing at least IMO

I understand your concern. Extensions can be avoided and can go in a separate draft. Only thing is that IMHO the draft needs to be clear about the meaning of sentences like

"It will send a
   notification whenever the resource changes, or at latest when the age
   of the last notification becomes greater than its Max-Age"

in case max-age = 0. This would imply that a non-cacheable resource should send notifications at maximum frequency, i.e. every second? This is now the case in our implementation, but seems to us as undesired behavior in a constrained network.

Not clarifying these points would not be good for the final document. I hope ticket 204 can deal with this.

Kind regards,
Jeroen

---

From: "Angelo P. Castellani" <[email-masked]>
Date: Thu, 5 Apr 2012 10:15:10 +0200

> in case max-age = 0. This would imply that a non-cacheable resource should send notifications at maximum frequency, i.e. every second? This is now the case in our implementation, but seems to us as…

This problem is more related to the rate control of the observation
itself. I like your draft conditional that provides a way to both
avoid too frequent updates, and also because it provides an upper
bound to notifications.

I think that those two features are really important, and maybe a
variation of that features should be included in the Observe itself.

A solution to this could be to use the observe option in the
observation request to store two pseudo-FP containing minimum and
maximum time between observations.

The former helps avoiding too frequent updates, the latter to deal
with servers losing their state, so that the client is guaranteed that
at some time it will receive a notification anyway and react
consequently if this does not happen.

Best,
Angelo

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 6 Apr 2012 08:58:50 -0600

> as any technical change requires some time to be discussed, understood

The only thing worse that a big change in WGLC, is not making a cahnge that should be made. Part of the reasons for starting the WGLC was to find out if we are pretty much done or not. Many documents at IETF have a WGLC, then a bunch of work happends, then we have another WGLC. The pub/sub problem has turned out to be very difficutl in nearly everyon protcol that has done it so I really want us to make sure we are pretty happy with howerver do do Observe.

---

From: Salvatore Loreto <[email-masked]>
Date: Fri, 6 Apr 2012 17:15:11 +0200

On 4/6/12 4:58 PM, Cullen Jennings wrote:
> The only thing worse that a big change in WGLC, is not making a cahnge that should be made. Part of the reasons for starting the WGLC was to find out if we are pretty much done or not.
I concur ...

> Many documents at IETF have a WGLC, then a bunch of work happends, then we have another WGLC.

I was referring to the eventuality to produce a new version of the draft 
*while* the WGLC is running,
not to the fact that as result of WGLC we can need a bunch of work 
(technical changes) to address all the comments and then another WGLC 
etc.etc.

Sorry not to have been enough clear in expressing my thought.

> The pub/sub problem has turned out to be very difficutl in nearly everyon protcol that has done it so I really want us to make sure we are pretty happy with howerver do do Observe.
I know very well the difficulty, having participate somehow to the work 
done in SIP about pub/sub.

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 6 Apr 2012 18:57:45 +0200

On Apr 6, 2012, at 17:15, Salvatore Loreto wrote:

> I was referring to the eventuality to produce a new version of the draft *while* the WGLC is running,

Ah.

Let's not do that.

(But we can start collecting replacement text for potential areas of improvement.
The issue tracker can help with that.)

Grüße, Carsten

---

From: "core issue tracker" <[email-masked]>
Date: Fri, 20 Apr 2012 16:06:46 -0000

Comment (by cabo@…):

 Cullen comments (msg03073d):

     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.

 ->

 editorially separate the concepts of max-age (cache freshness) and pledge.
 For now, both have the same value, but future extensions might provide
 options to give them different values.

Ticket URL: <http://trac.tools.ietf.org/wg/core/trac/ticket/204#comment:2>
core <http://tools.ietf.org/core/>