[ogsa-naming-wg] RE: [gfs-wg] Minutes of 7/20,21 GFS-WG Conference call

[Dave Berry]

I'm a bit concerned about removing the mapping to logical names.  I
thought the e-mail reply to Andrew's criticism seemed valid - we have a
three-tier naming system in OGSA, so it makes sense for RNS to support a
mapping to logical names.  This remains true even if the spec for these
logical names is provided by a different group.

I know that WS-Names are likely to be EPRs, which perhaps simplifies the
system.  Is it sufficient for RNS to support mappings to EPRs and for
the context to determine whether those EPRs are logical names or
physical names? 

Dave.

> -----Original Message-----
> From: owner-gfs-wg at ggf.org [mailto:owner-gfs-wg at ggf.org] On 
> Behalf Of Osamu Tatebe
> Sent: 22 July 2005 04:18
> To: gfs-wg at ggf.org
> Subject: [gfs-wg] Minutes of 7/20,21 GFS-WG Conference call
> 
> Hi all,
> 
> Please look at minutes of the last conference call.  The discussion
> includes several changes and decisions for the final RNS document.
> 
> Thanks,
> Osamu
> 
> ---
> GFS-WG conference call
> Wednesday, July 20, 2005
> 3:30pm to 5pm (PDT)
> 
> Note taker: Osamu Tatebe (AIST)
> 
> Participants
> ------------
> Manuel Pereira
> Ken Wood
> Arun Jagatheesan
> Osamu Tatebe
> 
> Agenda
> ------
> Introduction & agenda bushing ( 5min)
> Recent change                 (10min)
> Alias junction issues         (30min)
> Other minor issues            (15min)
> 
> Meeting
> -------
> * Recent change from the document on July 8
>   
> https://forge.gridforum.org/projects/gfs-wg/document/RNS-Propo
sed_Final_Draft-v1.7/en/7
> 
>  - reflect comments from OGSA-WG
> 
>   o Appendix of Grid File System Profile
> 
>    - better to focus RNS.  keeping consistency level is important.
>      basically, appendix is not so important.
> 
>    - we will start Grid File System Profile document as a separate
>      document from next week.
> 
>    -> The appendix will be taken out
> 
>   o Section 3 "Resource Endpoint Resolution Service"
> 
>    - this part will be taken over by OGSA Naming WG.
> 
>    -> The Section 3 will be taken out
> 
>   o WS-enumeration
> 
>    - Microsoft proposes WS-enumeration that provides similar
>      functionality of iterator in list operation.
> 
>    -> WS-enumeration specification is not standardized yet.  it lacks
>       features to improve performance.  we can follow the spec once it
>       is standardized.
> 
> * Alias junction issues
> 
>  - Background: alias junction emulates a hardlink functionality.
>    Once, we are using OID to specify a target of an alias junction.
>    In this case, we just care about AliasCount of the target entry to
>    avoid to be a broken reference.  On the other hand, we take out OID
>    completely in the document, and use pathname to specify a target
>    entry instead.  In this case, an alias junction may be orphaned
>    when one of entries in the pathname is moved or renamed.  Section
>    1.1.2.4 "Alias Junction" needs to be modified.
> 
>  - Two options;
> 
>   (1) add the above constraint in the third paragraph "Prohibit
>       modification of the target"
> 
>   (2) make alias junction an optional feature of RNS, while the
>       service needs to update the TargetPath property dynamically if
>       it supports the alias junction.
> 
>   -> We choose (2) since it is simpler and reasonable.
> 
> * Other issues in RNS Specification
> 
>  - There is a comment from OGSA-WG such that RNS should be simple and
>    does not need to have several types in Junction.
> 
>   o Since we take out the RNS Resolver in Section 3, logical name does
>     not make sence so much.  So, we can collapse Endpoint Reference
>     Junction and Virtualized Reference Junction.  Also, Alias Junction
>     is now an optional junction.
> 
>   -> We will have three types of junctions;
> 
>    o Endpoint Reference Junction
>    o Referral Junction
>    o Alias Junction [optional]
> 
>    Referral Junction is a special type of Endpoint Reference Junction,
>    which points to an entry in (separate) RNS.  On the other hand, for
>    easy federation of RNSs (this is quite a typical usage of RNS), to
>    have a separate type is reasonable.
> 
>  - In Figure 2 in Section 2 "Federation of Resource Namespace
>    Service", Path specified in list operation to the RNS
>    (research.acme.org) seems to be a full path not an absolute path.
>    Need to clarify this.
> 
> * Submission plan
> 
>  - After reflecting above changes, we will distribute the final
>    release candidate.  We will submit it in the *first week of
>    August*, although we try to reflect every comments from now to the
>    submission date.
> 
> * Architecture Informational Document
> 
>  - soon, it will be in 30-days public comment phase.
>  - Osamu suggests strongly to take out the Section 4.5 Standard
>    Interfaces since it is confusing.
> 
>  - we need to start architectural sketch for every POSIX I/O
>    operations as soon as possible.
> 
> * F2F meeting
> 
>  - for further collaboration with SNIA and other groups, we will set
>    up a f2f meeting in August.  Details are discussed later.
> 
> ---
> Osamu Tatebe, Ph.D.   Tel: +81-29-861-5844  FAX: +81-29-862-6601
> Grid Technology Research Center,
> National Institute of Advanced Industrial Science and 
> Technology (AIST)
> AIST Tsukuba Central 2, 1-1-1 Umezono, Tsukuba, Ibaraki 3058568 JAPAN
> E-mail: o.tatebe at aist.go.jp     http://phase.hpcc.jp/people/tatebe/
> 
>