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

[Osamu Tatebe]

Hi,

Here are more questions and comments for the document.

o 1.1.2.4 Alias Junction

It is better to mention the case when an entry referenced by an alias
junction is also an alias junction.  In this case, RNS can modify the
target path, or a client needs to traverse multiple aliases.

Moreover, when we allow an alias junction to a virtual directory,
there may be a loop in directory tree.  Since an alias junction only
points to an entry within the same service, we can check this in
create operation.

o 1.3.4 Context Operation

openContext requires IteratorContextID to create a context.  Why
should this IteratorContextID be specified?  How to ensure the
uniqueness of the ID not to conflict among clients?  EPR returned by
openContext cannot be used for this purpose?

o 1.5.1.1 Referral Messages

This functionality would be applied to Endpoint Reference Junction and
Virtualized Reference Junction when a path traverses a junction entry.
I believe it would be nice to extend this feature to them.

o '.' and '..'

This document does not mention about '.' and '..'.  These entries are
(automatically) included in Response of list operation?  Can we
include '.' and/or '..' in Path?

o Path and Name

As Ted also pointed out, I think Name is redundant and not necessary.
Is it better to omit Name in Input?

Regarding the teleconference, unfortunately I will be in Seattle in
that week.  Since it will be a very short stay, I am not sure I can
make it in this week.  Moreover, the deadline to submit a document is
May 27...

Thanks,
Osamu

>> On Thu, 19 May 2005 15:32:51 -0700, Manuel Pereira <mpereira at us.ibm.com> said:

>> Hello Osamu,
>> These are some good comments, and I will certainly respond to them as soon as
>> I am able. However, I will be unavailable for the next two weeks (starting
>> today).

>> I would like to request that we move the teleconference to Monday, June 6 or
>> later (once I have returned); I would greatly appreciate the opportunity to
>> participate in that discussion. I look forward to addressing these and any
>> other comments/questions, and advancing forward in the official public review
>> and submission process as soon as I return.

>> Best regards,
>> Manuel Pereira
>> ===============================
>> IBM Almaden Research Center
>> ===============================
>> 650 Harry Road, San Jose, CA 95120
>> 1-408-927-1935 [T/L 457]
>> Pager: 800-946-4646 1492425
>> http://mvp3.almaden.ibm.com
>> mpereira at us.ibm.com

>> Wednesday, May 18, 2005 8:41 PM
>> To: gfs-wg at ggf.org
>> cc:
>> From: Osamu Tatebe <o.tatebe at aist.go.jp>
>> Subject: [gfs-wg] Re: Proposed Final Draft for RNS v1.0

>> On Mon, 16 May 2005 11:42:13 -0700, Manuel Pereira
>> <mpereira at almaden.ibm.com> said:

>> The latest draft of the RNS specification is now posted to GridForge and
>> ready for review and comments.

>> Thanks for posting of the latest draft. I think it is better to have
>> teleconference next week to discuss this. Here are comments from my
>> group.

>> o Behavior of moving an entry whose AliasCount property is greater
>> than one.

>> This needs to be described in 1.1.1.2.4 same as the case of deletion.
>> Possible solution is we do not allow this, but optionally we allow
>> this if and only if TargetPath of all of alias entries is reassigned
>> to the new TargetPath.

>> o Should TargetType in QueryResponse for list and lookup be
>> TargetPath?

>> o Behavior of create without Type

>> Type is an optional property for create according the section 1.3.2.1.
>> If it is not specified, what entry is created?

>> o Value of AliasCount

>> In 1.1.2.4, there is a description '... greater than one ...'. This
>> means AliasCount is one even though there is no alias entry that
>> points to. For me, zero is fine in this case.

>> o SoftAlias, HardAlias, and PathAlias

>> In VFDS specification, there are SoftAlias, HardAlias, and PathAlias.
>> On the other hand, RNS specification only specifies Alias Junction.
>> Is it still possible to support these three types in VFDS based on
>> RNS?

>> Thanks,
>> Osamu