1. Dereference access control
In order to do the LoST lookup, a LoST server would have to be
allowed to dereference the location reference. Given that most of
the LoST infrastructure (e.g. the trees) is pretty static, it
doesn't seem difficult to provide authentication credentials for
LoST servers and require that they be able to dereference (just
Unfortunately, every resolver and forest guide would have to
dereference. Resolvers and forest guides will be operated by numerous
entities, including companies. There is no trust relationship between
the Columbia LoST resolver (VSP, in my case) and the access provider.
If any resolver can get the location information, you might as well
hand it out to the client to begin with. Saves you the extra effort.
Thus, this is a non-starter.
2. Extra time/complication
It's correct that it would not be feasible for every LoST server
involved in an LbyR-based query to dereference the location
reference. However, this can be avoided if the resolver doing the
recursive queries is allowed to do a dereference, since it can then
just include the location by value in subsequent queries. This may
cover most cases, e.g., if a local LoST resolver is provided by the
access network (as is often the case with DNS).
In many cases, the LoST resolver will be provided by the VSP,
including non-traditional VSPs. Are you suggesting we restrict the
LoST architecture to cater to this particular need?
I thought we agreed that the business practices of some ISPs should
not burden the rest of the infrastructure?
There's a lot of overlap between LoST/LbyR and what you propose.
If the access network provides a resolver, then the two are
essentially the same, except that if LoST/LbyR is used, then the
client sends an extra query. However, extending LoST seems to
maintain a better separation of the location configuration and
Ecrit mailing list