RE: GGF/OGSA standards for hierarchical namespaces

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 (I don't seem to have any record of minutes having been taken or sent out for this session - if I'm wrong or just missed an e-mail in the endless shuffle of my inbox, feel free to correct me, but this document may be taken as a poor-man's minutes, rambling, incoherent, and just plain wrong though it may be in parts - I was calling in and so wasn't always able to catch all of the discussion.) First, I'd like to again thank all the participants in the e-mail and the F2F discussions for helping us to move this forward. Regarding the F2F Naming session, I think the RNS/WS-Directory portion was a very productive discussion, and it certainly seemed to me that there is general agreement on the need for a refactored or decomposed version of RNS, as well as agreement on the general components that will be required. I will refer to the portion of the re-factored RNS that provides the POSIX directory-like functionality RNS-Directory, for lack of a better term at this point. In fact, the sense I got was that not only is it generally agreed that this type of thing is needed, but that it is needed as soon as possible; I certainly feel this way, since much of the work of the GFS-WG should ideally consist of the definition of a "profile" for GFS usage of RNS- Directory. Mark Morgan made it abundantly clear that WS-Directory is not currently being offered as a proposed GGF standard document, but is merely intended to provide a somewhat simpler, and in fact quite minimal, example of a hierarchically structured set of human-readable names which are associated with XML documents containing at least an EPR and, as of the most recent version, arbitrary XML, as the entry document definition includes an "{xsd:any} *" component. I, for one, feel that WS-Directory will be a a valuable reference point in the development of the directory service component of RNS 2.0, or whatever it ends up being called. Initial action items coming out of the discussion were that Mark Morgan and Manuel Pereira were to do some communication to try and get synchronized on at least some initial ideas about what might need to come out of RNS and how it might need to be changed in order to get to this magical future invention I call RNS-Directory. I've offered to help in whatever capacity I can, including arranging for mailing lists and conference calls if necessary, in addition to offering my opinions, which by this point is probably assumed ;-). My personal feeling was that the most difficult issue to resolve was the question of where the re-factoring effort should live and how it should proceed; , but it seemed to be generally agreed that GFS-WG is too far down the GGF hierarchy to be responsible for something that, as someone put it most appropriately (sorry for not recognizing your voice), needs the level of visibility associated with being at the OGSA-* level. At the same time, Mark Morgan suggested that perhaps OGSA-Naming wasn't necessarily a perfect fit for this effort, as there isn't quite the right overlap with the efforts and individuals currently in OGSA-Naming. The last suggestion I heard clearly in toto was that it should be "officially" part of OGSA-Naming, but that it may need separate conference calls, GGF sessions, and other devices to maintain at least some separation from the mainstream OGSA-Naming work. Manuel explained to me, as a relative newcomer, the original agreement that the GFS-WG would be responsible for development of RNS, and that OGSA-Naming would then take over maintenance of it once it had become a GFD, and something like this still seems like a good idea, as long as we can maintain the required level of visibility. I'd appreciate it if someone who was there could let us all know what, if any, final decisions were made regarding how this process will proceed. I haven't had a chance to look at WS-Enumeration, but it's on my reading list - at the least, it should be useful in thinking about how to integrate the directory work with separate and more generally applicable iteration or enumeration standards. Thanks, On Apr 5, 2006, at 12:53 PM, Dave Berry wrote:
Hi Chris,
Thanks for this note. I hope the F2F discussion is productive.
I will repeat my suggestion that the naming team should look at WS-Enumeration to see if it, or an extension thereof, satisfies the requirements for an iteration interface. I have no idea whether it does meet those requirements but we should take a look. This is especially true given the MS/IBM/HP/Intel WS white paper, which has WS- Enumeration in at the bottom layer.
Another question I've had raised to me is whether we can use WSRF/WSRT to handle the properties associated with entries in the directory. I personally don't see how this would work, but given the context we're working in it would be helpful to establish what relationship exists, if any.
Best wishes,
Dave.
- ---------------------------------------------------- Chris Jordan HPC Systems Engineer High End Computing Systems Group San Diego Supercomputer Center ctjordan@sdsc.edu 858.534.8347 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFEOL5nPCVtcXn6kg8RAvUhAJoD9nu2O8c2sxUzDbFDkD0lrFziRQCeIqcX 8HpYq17rM4OSxlCXLV/VNFQ= =uKze -----END PGP SIGNATURE-----

Hello All, Thank you Chris for your comments, encouragement, and willingness to assist in moving forward. I do appreciate your contribution and assistance, and would like to also apologize for any perceived lack of response recently. I have been very busy and involved in a number of activities here at our lab, thereby finding it difficult to take the time to comment and respond to the many messages circulating. I would like to take this opportunity to clarify a couple of comments previously made:
I will refer to the portion of the re-factored RNS that provides the POSIX directory-like functionality RNS-Directory, for lack of a better term at this point. In fact, the sense I got was that not only is it generally agreed that this type of thing is needed, but that it is needed as soon as possible; I certainly feel this way, since much of the work of the GFS-WG should ideally consist of the definition of a "profile" for GFS usage of RNS- Directory.
This is a fair statement, however it may be misleading in this way: RNS currently covers all POSIX like hierarchical directory management of references to endpoints as well as nested "directories". To say that "this type of things is needed,...as soon as possible" may be interpreted to mean "we don't have this and we need it as soon as possible." This is not correct, RNS has for nearly 2 years proposed a solution to this obvious need and has been soliciting assistance (regardless of working group affiliation) to shape and mold it into the specification that would most practically meet the essential needs of hierarchical resource endpoint naming and location registration within the context of the Grid.
document definition includes an "{xsd:any} *" component. I, for one, feel that WS-Directory will be a a valuable reference point in the development of the directory service component of RNS 2.0, or whatever it ends up being called.
I don't quite understand this comment. First, what aspect of WS-Directory will be a valuable reference? What does it have that RNS doesn't? Second, I do not consider it the "development" of "the directory service component" of RNS, its fundamental function *is* a directory service.
to come out of RNS and how it might need to be changed in order to
This I agree, the effort to "refactor" RNS includes taking certian features out and changing other features to accommodate the refactored structure.
get to this magical future invention I call RNS-Directory. I've
Again, this is an interesting statement that implies the "development" of something new. By definition this is not exactly consistent with the terminology implying refinement or refactoring.
I've offered to help in whatever capacity I can, including arranging for mailing lists and conference calls if necessary, in addition to offering my opinions, which by this point is probably assumed ;-).
Thank you again!
My personal feeling was that the most difficult issue to resolve was the question of where the re-factoring effort should live and how it should proceed; , but it seemed to be generally agreed that GFS-WG is
I'm not sure I perceive the same degree of concern. For this effort to be successful and satisfy the requirements presented by the OGSA-WG, OGSA-Data, OGSA-Naming, GFS-WG, etc. this effort must proceed with participation by *all* interested parties (individuals); this is not an effort of "a" working group, but rather a collaboration of interested parties. The "official" charter held responsible for the current phase of this activity is GFS-WG, but this *should not* impose any lines of distinction between those who are interested, willing, and able to contribute and participate. It is not an issue of "what group" is responsible, if this is to be a specification that will strive to serve the hierarchical naming needs of the diverse Grid community, then we need participation from this same diverse community (represented by various individuals who have voiced opinions and convictions in the matter). Therefore, I suggest that the "forum" of discussion appeal to a higher, wider, and larger audience than GFS-WG, whilst the process responsibility remain with GFS-WG until it becomes a GFD at which time the refactored generalization core of the spec is adopted by OGSA-Naming. Discussion and ownership of the "factored-out" pieces and features will need a forum for discussion, it might be most appropriate to begin in GFS-WG with this as well. Does this make sense? Best regards, Manuel Pereira ------------------------------------------------------ IBM Almaden Research Center 1-408-927-1935 [Tieline: 457] mpereira@us.ibm.com ------------------------------------------------------
participants (2)
-
Christopher Jordan
-
Manuel Pereira