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@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/
> >
> >
>