[ogsa-wg] RNS critique (new revision available)
Manuel Pereira
mpereira at almaden.ibm.com
Thu Jul 28 01:38:24 CDT 2005
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_Draft-v1.8/en/8
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 at us.ibm.com
owner-ogsa-naming-wg at 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 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/
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/ogsa-wg/attachments/20050727/7b1729b2/attachment.html
More information about the ogsa-wg
mailing list