Subject: [pcp] renewal time

From: Francis Dupont <[email-masked]>
Date: Thu, 13 Oct 2011 23:33:17 +0200

I don't know what is the "renewal time" in (base 14 9.2.1):

   Regardless of the assigned lifetime of a mapping, the PCP client
   SHOULD impose an upper limit on the renewal time it uses for
   mappings.  A maximum renewal time of 2 hours is RECOMMENDED.

it seems it is the time before the expiry, i.e., the difference
between the expiry date and the renewal date, but IMHO a clarification
will be wellcome.

Regards

[email-masked]

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 13 Oct 2011 15:31:43 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Francis Dupont
> Sent: Thursday, October 13, 2011 2:33 PM
> To: [email-masked]
> Subject: [pcp] renewal time
> 

New text:

        Regardless of the Assigned Lifetime of a mapping, the PCP
        client SHOULD impose an upper limit on this returned value,
        and 2 hours is RECOMMENDED.  This means if the PCP server
        returns an absurdly long Assigned Lifetime (e.g., 5 years),
        the PCP client will behave as if it received a more sane value
        (e.g., 2 hours).

-d

---

From: Reinaldo Penno <[email-masked]>
Date: Thu, 13 Oct 2011 18:33:40 -0400

This is confusing. Does it mean that lifetimes > 2 hours are no-op?

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 13 Oct 2011 15:39:37 -0700

> From: Reinaldo Penno [mailto:[email-masked]]
> Sent: Thursday, October 13, 2011 3:34 PM
> To: Dan Wing; 'Francis Dupont'; [email-masked]
> Subject: Re: [pcp] renewal time
> 

We clearly need some sort of min() function on the returned Lifetime --
a lifetime of 5 years is a good example of an absurd value that
can legally be returned by the PCP server.

Do you want a higher value, such as 24 hours?

-d

---

From: Reinaldo Penno <[email-masked]>
Date: Thu, 13 Oct 2011 19:41:28 -0400

24 hrs is better.

---

From: Francis Dupont <[email-masked]>
Date: Fri, 14 Oct 2011 10:41:29 +0200

In your previous mail you wrote:

   New text:

=> fine if you add "but not 4294967295 (0xFFFFFFFF)" and something
explaining than anyway to renew a static mapping doesn't make sense.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Fri, 14 Oct 2011 10:46:14 +0200

=> with the context I believe the renewal timer should be set
to not more than 2 hours, i.e., if you get a 5 day lifetime
you schedule the renewal for now + 2 hours, not for between now + 2.5
and now + 3.125 days.

Regards

---

From: Francis Dupont <[email-masked]>
Date: Fri, 14 Oct 2011 10:49:32 +0200

=> IMHO it is not a good idea as it is fine to assure the PCP server
is still alive. BTW we had the same kind of discussion about the
TCP "keepalive" which finished by an agreement for 2 hours too!

Regards

---

From: Reinaldo Penno <[email-masked]>
Date: Fri, 14 Oct 2011 05:23:13 -0400

If the lifetime returned by the PCP Server is going to be discarded, do
still need a lifetime field?  We can convey 'deletion' by a single bit in
the header if necessary.

---

From: Francis Dupont <[email-masked]>
Date: Fri, 14 Oct 2011 17:44:38 +0200

If the lifetime returned by the PCP Server is going to be discarded

=> it is not discarded, it is round down to the 2 hour value for
the renewal, if the client wants to renew...

Regards

---

From: Reinaldo Penno <[email-masked]>
Date: Fri, 14 Oct 2011 12:10:52 -0400

So, if it is 5 years, it is 'rounded' to 2 hours?

---

From: Francis Dupont <[email-masked]>
Date: Fri, 14 Oct 2011 18:33:30 +0200

=> so if it is 5 years you launch an expire timer for in 5 years
and eventually a renew timer for in 2 hours.
As far as I can understand it is the meaning of the word "renewal"
and obviously I was right when I asked for a clarification (:-).
   
Regards

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 14 Oct 2011 10:00:37 -0700

> Sent: Friday, October 14, 2011 9:11 AM
> To: Francis Dupont
> Cc: Dan Wing; [email-masked]

Let's back up a minute.  

The maximum value for Lifetime is about 130 years, give or take a few years.
That's longer than any of our human lifetimes, and certainly longer than any
equipment will actually maintain state before crashing, losing power, or
getting swapped out with some fancy new equipment.

If the PCP server sends a large value of 130 years, do you find it
reasonable or unreasonable for the PCP client to accept that value as The
Truth?

Myself, I find it unreasonable to accept such a large value on its face.
Almost all DNS implementations, for example, provide a way for the DNS
administrator to enforce both a minimum TTL (to avoid thrashing with too
many DNS queries for the same RR) and a maximum TTL (to avoid consuming
memory for seldom-queried RRs).  The text in the document encourages
implementations to provide similar sanity checks on their implementations,
on both the PCP server (which nobody has complained about) and on the PCP
client (which you, Francis, and Keith all seem to object to).

-d

---

From: Reinaldo Penno <[email-masked]>
Date: Fri, 14 Oct 2011 13:31:02 -0400

> reasonable or unreasonable for the PCP client to accept that value as The

Certainly not and I agree with both you and Francis but the point is: what
is reasonable? 

If we define that 86400 is the threshold of reasonable, then the follow up
question is: what happens if the client receives a lifetime greater than
that? I'm okay with rounding down to 24 hrs but as the same time some kind
of warning must the exposed such that a problematic PCP server is fixed as
opposed to the PCP Client masking it out by silently 'fixing' the issue.

Thanks,

Reinaldo

---

From: Francis Dupont <[email-masked]>
Date: Sat, 15 Oct 2011 13:16:57 +0200

=> in fact I complained not about the principle but about the
proposed value which is not compatible with UPnP IGD v2.

=> in fact I don't object yet, I am still trying to understand.
But about the principle I don't believe the client side should
overwrite what the server returns about the expiry (but as the
renewal responsability is a client one if the proposal is about
the renewal only it doesn't apply).
   
Regards