Hello All, In light of Dave Berry?s comments and considering the work already done, I would like to propose that we keep the resolver operations, at least for now. If necessary, we can always factor them out into a separate document in a later revision, provided that there is an equivalent replacement. This implies the continued use of logical names (abstract names) within RNS and thus the inclusion and description of the logical reference (section 1.1.2.2). The latest revision has been posted to GridForge: https://forge.gridforum.org/projects/gfs-wg/document/RNS-Proposed_Final_Draf... Major revisions include: - Completely revised ?Alias Junction? description in section 1.1.2.4 - Revised section 1.1.2.2, previously ?Virtualized Reference Junction? now made consistent with other terminology to be ?Logical Reference Junction? - Section 1.2.2.2.1 updated to reflect revised property names and corresponding values for logical references - Updated all of the namespace and implicit operations to incorporate the said revisions - Updated section 2, with a particular emphasis in section 2.2.1.1 in an attempt to better describe the referral message - Updated the table in section 3.3.1 to reflect the use of the ?LogicalName? property throughout section 3 - Completely removed the Grid File System naming profile from the appendix - Absolute vs. Full Paths were elaborated and hopefully clarified - Description for mechanisms for namespace federation revised - Repository description explicitly clarified Best regards, Manuel Pereira =============================== IBM Almaden Research Center 1-408-927-1935 [T/L 457] mpereira@us.ibm.com owner-ogsa-naming-wg@ggf.org wrote on 07/22/2005 01:37:18 PM:
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@ggf.org [mailto:owner-gfs-wg@ggf.org] On Behalf Of Osamu Tatebe Sent: 22 July 2005 04:18 To: gfs-wg@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@aist.go.jp http://phase.hpcc.jp/people/tatebe/