[Federated-fs] Discussion of FSN resolution: what is required vswhat is expected

[Daniel Ellard]

Yes, sorry I forgot to note that.

The NSDB is a service.  The name is perhaps somewhat misleading (but it's
better than half a dozen names we came up with first...).

I think it's likely that we will need another term here, to distinguish the
name resolution service from the administration service for the individual
NSDBs.  When performing resolution, maybe it doesn't matter which NSDB
instance you ask -- it will either know the answer, or route your request
along to someone who does,  When performing admin tasks, I think it's more
likely that it does matter -- in this case it makes sense to talk directly
to the NSDB that owns the FSN.

The reason I think that there is a distinction here is because of the
different security models for the different kinds of queries.  It might be
OK for everyone to do resolution (and everyone else to know about it), but
admin operations might be more private and protected in a different manner.

What do you think?

Thanks,
    -Dan


On 5/2/07 9:37 AM, "Black_David at emc.com" <Black_David at emc.com> wrote:

> Dan,
> 
> As one of the people who had things to say about this, I think my
> primary
> concern is that the functionality provided by the NSDB should be
> architected
> and viewed as a "service" at this stage of the work, so as not to
> preclude
> distributed name resolution infrastructures, even though the easiest and
> most obvious implementation is to just go ask the responsible NSDB for
> the
> resolution.  We definitely need to allow for multiple name resolution
> "services" for the same reason that multiple NSDBs are allowed.
> 
> Beyond this, I don't have strong disagreements with most of what Dan
> wrote.
> 
> Thanks,
> --David