Subject: RE: [DNA] Re: MUST Store Lifetime and Last Refresh time? (draft-pentland-dna-protocol-00.txt)

From: [email-masked]
Date: Wed, 01 Jun 2005 08:36:54 +0300

Brett,

> Yes, that sounds reasonable.  Perhaps we need some text that states
> that how the information is stored internally is up to the implementor,
> as long as the result is the same as described.

It wouldn't hurt to mention the types of things that could be stored, without
using keywords, as a guide to implementors. IF you describe the reults needed,
implementers will come back asking what kind of things to store.  I think
Greg was just pointing out that the current text should be softened, explaining
that the things in the list are examples of what could be stored ...

John

> Greg Daley wrote:
> > My apologies, I forgot the section number:
> > 
> > That's in section 5.1.1
> > 
> > Greg Daley wrote:
> > 
> >> In the draft it states:
> >>
> >>   "The list will be
> >>    referred to in this document as "DNAPrefixList".  For 
> each prefix the
> >>    router MUST store the following information:
> >>
> >>    1.  Prefix
> >>
> >>    2.  Prefix length
> >>
> >>    3.  Valid lifetime
> >>
> >>    4.  Time last refreshed"
> >>
> >> In my (existing) implementation I'm storing the expiry time
> >> of the prefix (which is calculated based on the valid lifetime
> >> at the RA reception time).
> >>
> >> Is this insufficient?
> >>
> >> I can understand having an indication of when data expires,
> >> but it seems overkill explicitly pointing out which data types
> >> have to be internally stored in the host unless there's
> >> further reasons behind it.
> >>
> >> Would it be possible to make this descriptive and informational
> >> (being internal to the host) rather than prescriptive,
> >> using standards language?
> >>
> >> Greg
> >>
> 
> -- 
>   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>   Brett Pentland                  [email-masked]
>   CTIE - Centre for Telecommunications and Information Engineering
>   Department  of  Electrical  and   Computer  Systems  Engineering
>   Monash University, VIC, 3800,                          Australia
>   Phone : +61 3 9905-5245                    Fax : +61 3 9905-3454
>   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>

---

From: Brett Pentland <[email-masked]>
Date: Wed, 01 Jun 2005 15:44:50 +1000

I think there is a sort of middle ground that is needed.  There is
a MUST in the sense that the information represented in those four
points is essential to the operation of the protocol, but in the
case that Greg pointed out, it doesn't matter whether the time last
refreshed is stored and an expiry time calculated from that, or an
expiry time is stored explicitly, as long as the information goes
away when the expiry time arrives.

Brett.