[gfs-wg] Minutes of GFS-WG #1 RNS at GGF13

[Osamu Tatebe]

Dear all,

Here is the minutes of GFS-WG Session #1 at GGF13, which has been put
on GridForge also.  If you have any comments or corrections, please
let me know.

Regarding the Resource Namespace Service (RNS), we will finalize and
submit the specification soon.  After that, a new WS naming WG
proposed at GGF13 is assumed to take over the revision if needed, as
discussed at GGF13.  GFS-WG takes the responsibility of standardizing
a file system profile based on RNS to provide full functionality of
file system directory service.

Revised document of RNS can be obtained by GridForge;

https://forge.gridforum.org/projects/gfs-wg/document/Resource_Namespace_Service_-_GGF13_Revised/en/2

Thanks,
Osamu

-----
GFS-WG #1 - Resource Namespace Service

Tuesday, March 15, 2005
5pm to 6:30pm

31 participants

Note taker: Osamu Tatebe

Agenda
------
 - Introduction               (by Osamu Tatebe)
 - Resource Namespace Service (by Manuel Pereira)
 - Status discussion about RNS

Meeting
-------
 - Introduction (by Osamu Tatebe)
   * VFDS -> RNS + file system profile
   * new naming WG

 Q: Why general service is necessary?
 A: We would like to create fundamental core service of naming for
    wide adaptibility from other services and wide use.
    VFDS functionality can be realized by defining a profile for
    virtual filesystem directory service.

 - Resource Namespace Service (by Manuel Pereira)

  * RNS 
    - A WSRF compliant Web Service that provides namespace services
      for any addressable entity
    - Easily accessible, hierarchical managed, name
    - document style messaging

  * Operation
    - very simple - create, delete, list, lookup, update
    - extensibility - deleteProperty, insertProperty, listProperties,
                      updateProperty

  * Components
    - Virtual Directories
    - Junctions (Virtualized Referenes, Endpoint References,
                 Referrals, Aliass)

  * Document Style Messaging
    - Beyond Traditional RPC
    - WSRF compliant
    - RNS IteratorContext
    - RNS Entry

 Q: Is it better to specify index for list operation by client rather
    than keeping it at the server side?
 A: There is a problem when entries of list are updated between two
    list opearations.  In this case, offset specified by a client may
    be not correct.

 Q: Is Alias a hard link?  Is reference count for a aliase? 
 A: Yes.  When a target entry (an owner of the property) of an alias
    is deleted, one of the aliases will become the owner of the
    property.

 Q: Can an alias point to another virtual directory. - Yes.
 Q: Is an alias possible to point to another service?  - No, it is referral.

 Q: If there are multiple aliases targetting to a specific virtual
    directory, how do you manage the DirectoryPath?
 A: Even alias entry has a PID (OID for the parent directory entry).
    It is different from a hardlink.

 Q: When there is a referral during directory path resolution, what happen?
 A: There are two ways; service referrals and delegate resolution.
    (See the section "Federation of Resource Namespace Services".)

 Q: How does client keep an appropreate server?
 A: The RNS specification does not specify implementation details nor
    does it describe client/application capabilities.  The
    specification only specifies a standard for the service and
    thereby describes the service's interface.  Implementation
    optimizations are certainly possible and are the responsibility of
    the client/application implementer.  A client may maintain a cache
    of path names, top level resolution service addresses, most
    appropriate RNS service address to exchange messages with, etc.

 Q: Does RNS support notification when something is changed to
    maintain consistency?
 A: No, not yet.  We are now considering.

 Q: How about the uniquness in namespace?
 A: All of entries in a directory should have an unique name.

 Q: How to specify unique abstract name?
 D: there is big discussion about abstract name.  The followings are
    just notes.
    o This is a issue of WS-naming not RNS.
    o how to guarantee the uniqueness (with extremely high probability)
    o GUID is not ensure the uniqueness
    o It is an extremely challenging issue to guarantee the uniquness.
    o MAC address is not unique.
    o There are several projects to see this issue. randum number
      generator, ...

 * RNS recent revision

 C: Many people use 'Logical Name' as a human readable name.
 C: 'Abstract name' is a subset of 'Logical Name'

 Q: How to differenciate a file and a collection?
 A: This may be solved by adding file system profile.

 Q: A client might want to know more information than Entry
    properties.
 A: It is not efficient to resolve all entries in a directory during
    the list operation.  This also may be solved by file system
    profile.

  - OID clarification

 D: OID is cachable, but it is not reliable.  Also, the semantics
    depends on implementation.  Is it better that OID is not exposed
    in the spec?

    There is a problem when OID is re-used.

    It is ok just to describe OID is not reliable in the spec.

 - Status discussion about RNS
   - Discussion points;
     o Is RNS specification general enough?
     o How much refinement may be needed?

 C: It is better to finalize the document now and submit it.  (And
    iterate the revision)
 C: RNS spec is almost complete.    

Q: Question
A: Answer
D: Discussion
C: Comment