[gfs-wg] Proposed Final Draft for RNS v1.0

[Ted Anderson]

On 5/16/2005 14:42, Manuel Pereira wrote:
> The latest draft of the RNS specification is now posted to GridForge and
> ready for review and comments.  Please send any comments and/or questions
> to the mailing list as soon as possible as we need to move forward in the
> submission process before GGF14.

Resource Namespace Service Specification, May 2005,
http://forge.gridforum.org/projects/gfs-wg/document/Resource_Namespace_Service_-_Proposed_Final_Draft_v1.0

Sec 1.1.2.2: Since virtualized reference junctions are a key component
in the three-level namespace architecture, it is rather dissatisfying
that the description here is so abstract.  At the very least, could we
make it clear that the target contains two parts: the logical name
itself and a reference to a resolver for that name?  Maybe an example
drawn from the earlier figure would be useful.  Ideally, it would be
nice to factor out the resolver reference, since typically it would be
shared by most virtualized reference junctions in a repository.

Sec 1.1.2.4: I'm afraid I still have problems with the alias
description.  It is misleading to say that an entry MUST NOT be deleted,
but then in the following section explain how they can be deleted after
all.  Better to explain that there are two alternatives up front and
give the two permissible alternatives.

The confusion related to identity of entries and aliases remains.  As
far as I can tell this is the only explanation of what an alias does or
how it works.  Later in the document there are only details of
properties and types.  How does lookup of an alias work, specifically,
how does it differ from looking up the target itself?  In other words,
is an alias visible to the casual user (i.e. lookup as opposed to create
or delete) and in what ways?

Sec 1.2.1: It may be burdensome for the server to implement a
point-in-time result-set over multiple messages to deliver a large
directory to a requester.  How can the server bound the resource demands
this imposes?  What if the requester makes a request for a large
directory and never responds with another request, but does use the
lifetime management to keep the IteratorContext state active?  What if
it very slowly reads the directory in tiny segments?  Can the directory
destroy the iterator context if resource demands get too much and force
the requester to start over?  Maybe this shouldn't be a "MUST"
requirement and instead include a modification timestamp or version
number with each returned listing segment?

Sec 1.2.2.1: Maybe the ChildCount should be optional
(i.e. minOccurs="0") and the server SHOULD provide one.  This would
facilitate situations where the server produces the directory listing as
requested and because it didn't have resources to create and store the
whole listing on the first list request.

What is the path separator character?  What about character restrictions
for entry names?

Sec 1.3.3.2: In rename, what is the rationale for providing the Path &
Name approach since the Path only mechanism seems perfectly sufficient.
In fact rename would seem to be a trivial subcase of move, described in
the previous section.  Maybe the Path & Name naming mechanism should be
eliminated all together.  The "Name" attribute is clearly necessary for
the "list" operation, but for others it would seem redundant.  Its use
is inconsistent anyway: why create but not delete?

Sec 1.3.5.4: Perhaps when inserting a new property, the DataType should
be mandatory.  Otherwise how can the property be given a value?  Is
there any way defining a new property could be useful without the
capability to giving it a value?  [Osamu mentioned this also.]

Sec 1.4: Given that it sounds like you are requiring the very demanding
perfect consistency for updates to a distributed namespace repository, I
think you need to be very clear.  This quote "This means that operations
like create, delete, and update MUST guarantee synchronized processing
that prevents update contingencies based on concurrent execution."  is
not at all clear.  What are "update contingencies"?  Are you really
demanding (MUST) strong consistency?  What is the escape clause for RNS
implementations that cannot provide this level of consistency?  Only
non-conformance?

Sec 2.3.2.5: How does updateEndpointReference work?  You provide an EPR
to update and the only new properties to specify is EPR.  Does an EPR
have a name in addition to its value or is this like a replace
operation?  Can one EPR be replaced with a list of EPRs?  Does an EPR
have any other properties?  Perhaps a description?  There doesn't seem
to be an insertEndpointReference operation, so I guess they are inserted
as a side-effect of other operations.

You say "Replication of RNS ... is indispensable. The consistency model
required by RNS needs to be investigated."  But in section 1.4 the
specification appears to call for strong, single system image
consistency.

Appendix GFS Profile:

Checksum is a required attribute to support, but does that mean it is
required of all entries?  I would imagine that some data sources would
not have checksums.  Perhaps in this case the ChecksumType could be
"none"?  Maybe it should say "if available" as you do for the Version
property.

What does ReplicaCopy mean to the client?  Does it imply ReadOnly?  Does
it control the validity of the Timestamp and Version properties
(i.e. are these properties invalid if ReplicaCopy is false)?  Is there a
way to find out the source from which the replica was obtained?

Ted Anderson