Re: [mif] draft-ietf-mif-dhcpv6-route-option-04 published

[Alexandru Petrescu <[e-mail]>]

Le 16/03/2012 18:23, Ted Lemon a écrit :
> On Mar 16, 2012, at 11:56 AM, Alexandru
> Petrescu<[e-mail]>  wrote:
>> Not all plaforms benefit from the typical timer implementation as
>> a PC-class monolithic kernel offers.
>
> Platforms that cannot determine that time has passed won't be able to
> know that a prefix is deprecated, or no longer valid, correct.
>
>> SO there would _be_ a conversion needed, right?  This may need to
>> be specified.  Wouldn't be easier to specify that both lifetimes
>> (from ND and from DHCP) are represented in the same manner, thus no
>> conversion?
>
> The point is that neither the DHCP time nor the RA time is in the
> form needed to notice when a prefix has stopped being preferred, or
> has become invalid.   So in both cases, a conversion to absolute time
> will be necessary.   There is simply no way in which we can make the
> implementor's life easier by having the DHCP offset be 16 bits.

Well maybe there is.

A conversion in absolute time may indeed be necessary, provided systems
keep same time, that being another matter.

But the other conversion - between DHCP's way of representing lifetime
and ND's way of same could be avoided, simply by representing them in
the same manner (16bit length as ND does).  A single unique C function
could be used the same to convert the lifetime field from a DHCP message
to absolute time, and fro, ND message field to absolute time.  Otherwise
one would have to write two functions.

I find it strange that you oppose such an obvious thing to do -
represent lifetimes in the same manner across protocols.

What is the reason of _not_ representing lifetimes in the same manner
across protocols?  We do represent Types and other things in the same
manner, why not lifetimes?

Alex