[ogsa-wg] RNS critique

[Ted Anderson]

Here are a few responses to Andrew's critique.

On 7/20/2005 14:55, Andrew Grimshaw wrote:
> 1) The basic directory function is to provide a mapping handle f("string"),
> i.e., to map strings to some form of handle. 
> 
> Thus, in section 1.1.
> 
> Why do we need four different types of junctions? Should we not have one
> type of junction: mainly to an EPR. Thus a directory would map a string to
> an EPR.
> 
> EPR f("string"); 
> 
> Instead there are four "types" of junctions:
> 
>             EPR's
> 
>             Virtualized reference - either contains an EPR or a URL that
> points to some other service
> 
>             Referrals - point to another RNS service. Q: could this not be
> modeled as an EPR?
> 
>             Alias - points to another "entry" within the "same" RNS service.
> This seems to imply a container like model - more on this later.
> 
> I suggest that we need only ONE type of junction - an EPR. That will
> simplify client coding - and the model significantly. 

I don't think one type will do.  One of the key features of RNS is the
three level naming architecture.  The first level pathnames map to
logical names, which are subsequently mapped to resources in the form of
EPRs.  This level of indirection through logical names allows important
flexibility and separation of responsibility.  The "everything is a
resource" manta can be taken too far, however, and I don't think it
makes sense to have logical names be resources.  Thus one of these
junctions maps to a logical names.

Not everyone wants or needs a three level naming structure, so RNS has
provision for direct mapping from names to resources.  This would
justify another type of junction.

> 2) Implied model - Repositories
> 
> There is a notion in the spec of "same service instance" that in
> conversations has also been called a "repository". The basic idea is that an
> RNS service may "contain" a set of directories - and that the service has a
> root. Thus junction types distinguish, for example, between internal and
> external things that they point to.  Thus an RNS service is a rooted tree -
> that may point at the leaves to other rooted trees. So, first of all - it is
> implied. If we're going to have that model it should be right up front and
> discussed. What is a repository? What are it's special port types if any,
> etc. Second, I think that it is not the right way to think about the
> problem. Directories should be the resources - not collections of
> directories. If a particular implementation chooses to multiplex a large
> number of logically independent directories in a single container - great -
> we will certainly do that too. The issue is what is the model. I feel fairly
> strongly about this.

I agree that RNS instances, or repositories, should be given more
explicit treatment.  An RNS instance is a collection of namespace
objects and has some important properties that should be described and
motiviated more clearly.  I think this is a real and important concept
in the naming model and should not be hidden behind a directory-only
idealization.

In a hierarchical namespace each name represents a kind of delegation
for naming of subsequent components of a pathname.  Since each directory
can have different authorization rules (e.g. permissions, ACL), this
delegation has real meaning: someone else now controls the meaning of
all names with this path prefix.  An RNS instance is contained within a
single administrative domain, so delegation of namespace control within
an RNS instance is bounded by that domain.  When a namespace mapping
delegates to a different RNS instance, something important is happening.
 A whole new organization has received reponsibility for controlling the
meaning of subsequent pathnames.  This sort of transfer needs to have
explicit representation in the namespace and a specific junction type
seems like a reasonable way to do this.

> Links "into" other RNS servers:1.1.2.4 "Alias Junction" is restricted to
> pointing to entries in the same repository. I think they should be able to
> point to anything - including directories in "other" repositories. It has
> been claimed that using the EPR of the "repository" and a path you can get
> that effect. However, what if the path changes in the other container? My
> link would break - even if the directory itself still exists. 

Maintaining the hierarchical structure of the namespace means limiting
arbitrary connections between directories.  While using hierarchical
names is a restriction, it is also a valuable simplification.  It is
easier to understand and maintain.  It also follows an important aspect
of the real world, namely hierarchical control within organizations.

Clearly, non-hierarchical references are sometimes important, but it
makes sense to clearly identify these links so that can be treated
differently when the hierarchical nature of the namespace is important.
 Thus aliases that represent symlinks make sense as a separate junction
type.

Ted Anderson
IBM Almaden Research Center