Re: [nbs] Name->Locator validation. (Was: Re: A suggestion for an "on-demand API".)

[Javier Ubillos <[e-mail]>]

On Wed, 2010-12-22 at 08:38 +1300, Brian E Carpenter wrote:
> ...
> > The basic question is, is it enough with the name->locator binding being
> > OK in the beginning of the connection or must it be valid throughout the
> > connection.
> > 
> > Having a "last verified time-stamp" makes it very explicit that the
> > name->locator binding was valid at that given point in time.
> > 
> > This leaves it open for a continual polling to the nameing system if
> > that is what is required by that nameing system and the application.
> > 
> > It also leaves it open to the application to decide whether or not it is
> > OK to have a valid name->locator binding at the beginning of the
> > connection or not.
> 
> As is noted in draft-carpenter-referral-ps, these bindings
> (and even nameless locators) have finite lifetimes, known at their
> point of origin (from DHCP, SLAAC, DNS TTL, etc.) The problem shouldn't
> be stated as timestamps or a need for polling. Quoting that draft:
> "A referral that does not convey the lifetime associated with
> an address is problematic." The lifetime should be carried with
> the binding, and counted down locally.
> 
>       Brian

That sounds great.
Given that the application (on either side) actually does want
authenticity in the name->locator binding:
Letting the naming-system/referral-mechanism manage this, and that a
client MUST verify and renew the lifetime of the name->locator binding
sounds healthy to me.

// Javier