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

[Osamu Tatebe]

Hi Manuel and all,

Thanks for the revised document.  Here are comments and issues need to
be clarified in the document from our group.  If there are more
comments from the GFS-WG, please post them to this mailing list before
GGF14.  We would like to finalize RNS specification document in GGF14
GFS-WG #1 session starting at 2pm on June 29.

Thanks,
Osamu

----------
* Update operation

'Type' needs to be described *not to be updated*.

* Symlink behavior for VFDS

We need to consider how to implement (or represent) a symbolic link
(aka PathAlias in VFDS) in RNS.  Possible solution is

1) to represent as 'Alias' but its targetPath is not updated when
   moving the target entry, or

2) to represent as 'Referral' but it has 'TargetPath' instead of
   'EPR'.

Unfortunately, either solution affects the RNS specification...

* IteratorContext

When IteratorContext is created as ResourceProperties in WS-Resource,
an EPR can specify the IteratorContext (as a WS-Resource).  This
means iteratorContextID is not necessary, does not it?

* Junction message

In the current document, a referral message is only used for a
referral junction.  On the other hand, this mechanism is quite useful
for other junctions; Endpoint Reference Junction and Virtualized
Reference Junction.  To do this, just add 'Type' and
'LogicelReferences' to QueryResponse and ChangeResponse.  'Type' needs
to be added to distinguish a type of junctions (or type of junction
messages).  In this case, 'baseDirectory' does not always refer to a
'directory'.  Maybe it is better to be renamed to 'basePath'.  Also,
'referralEPR' should be just 'EPRs' since it can refer to 'EPRs' in
Endpoint Reference Junction.

Moreover, 'remainingPath' (I am not sure this name is good or not) is
useful that represent a path to be traversed.  Of course, this can be
obtained by 'Path' and 'basePath', while it is useful.

* XML Structure of EPRs and LogicalReferences

EPRs and LogicalReferences are basically a list of EPR and
LogicalReference, while the structure is not known in the document.
This needs to be clarified.

* <Entry> and <Target> in example of QueryResponse

Neither <Entry> nor <Target> is introduced in the document.

* rename operation

Now 'update' does not have 'Name'.  Need to update the description.

* QueryInput in list operation

'EPR' and 'LogicalReference' seem to be missing QueryInput of list
operation.

* Error message

Error message (string) is better to be added in QueryResponse and
ChangeResponse.  Moreover, several typical error messages need to be
defined such as 'no such junction or virtual directory', 'not a
virtual directory', 'junction exists', 'is a virtual directory',
'virtual directory not empty', 'invalid argument', ....

* EPRs and LogicalReferences

How to update and delete entries in EPRs and LogicalReferences is not
well-defined.  For example, how to create a junction entry that has
two EPRs?  How to insert an EPR3 to a junction entry that already has
EPR1 and EPR2?  How to delete just EPR2 from a junction entry that has
EPR1 and EPR2?  Would you describe a procedure with an example of
setResourceProperties?

* In the case that the specified 'Path' is a junction

When the specified 'Path' is a junction, 'lookup', 'delete', and
'update' operations are for the specified junction itself, while
'list' and 'create' are not since these operations basically apply to
a sub entry (or entries) in the specified 'Path'.  This needs to be
clarified in the document.  In the list and create cases, a referral
message (or a above-mentioned junction message) could be returned as a
QueryResponse and ChangeResponse, respectively.

* In the case that the specified 'Path' in create operation is an
  alias to a virtual directory

When the specified 'Path' in create operation is an alias to a virtual
directory, how does the create operate?  Since 'Alias' can be resolved
within the service, it is reasonable to create a new entry under a
virtual directory pointed to the alias specified by 'Path'.  This
seems to be a special case enough to be described.