August 2007 - ogsa-wg - lists.ogf.org

[Fwd: IETF O&M Area MIB2RMDL proposal]
by Hiro Kishimoto 04 Feb '09

04 Feb '09

FYI Very interesting work on standardizing a methodology to convert SNMP MIBs to SOA/WS resource model artifacts (tagged as "MIB to Resource Model Description Language" (MIB2RMDL), using "Language" very loosely in this context). -- Hiro Kishimoto

2 2

Re: [ogsa-wg] OGSA Information Services
by Hiro Kishimoto 24 Sep '07

24 Sep '07

Hi all, Discussion material for Information Services by Laurence Field and Felix Ehm is now on the GridForge. https://forge.gridforum.org/sf/go/doc14692 > This document covers the problem description, experience in GIN, > overview of existing systems, generalized system and suggested > areas for standardization. Please have a look before the call today. Felix Ehm will lead the discussion. Thanks, ---- Hiro Kishimoto

10 18

RNS experiences document
by Andrew Grimshaw 19 Sep '07

19 Sep '07

All, We have done an implementation of RNS and have several observations before we write our experiences document. First, the version of the document I am referring to is the September 22, 2006 version. p.4 Add function We're fine with this BUT we had to make some assumptions. You'll note that the function returns an EPR. Our interpretation was: In the case that no EPR was passed in, i.e., I'm creating and linking a new directory, the function is to return an EPR of a new directory resource. If the case that an EPR was passed in, i.e., I'm adding a link to an existing EPR, the EPR that was passed in is returned. We'll call this the "obvious" implementation An alternative interpretation is that a new resource is created for the DIRECTORY ENTRY ITSELF. In this case the EPR of this entry is returned. We'll call this the "entry" implementation. Note that if the "entry" implementation is used, that after the "add" is performed there is no way to subsequently look up or find the EPR of the entry! We therefore use the "obvious" implementation. Both the "entry" and "obvious" implementations have ramifications and/or inconsistencies with later parts of the spec. Note on page 7 the pseudo schema for an entry (returned by "list") <rns:entry> <rns:entry_name> xsd:string </rns:entry_name> {any}* <rns:entry_reference> wsa:EndpointReferenceType </rns:entry_reference> </rns:entry>* This is consistent with our "obvious" interpretation. One of the things we have observed is that for very large directories this may create messages that are larger than the SOAP max - we may need to extend with an iterator. Also note on page 10 the query operation (which takes NO parameters) and returns <rns:EntryProperties> <rns:entry_parent> wsa:EndpointReferenceType </rns:entry_parent> <rns:entry_name> xsd:string </rns:entry_name> {any}* <rns:entry_reference> wsa:EndpointReferenceType </rns:entry_reference> </rns:EntryProperties> The implication of query is that the "entry" interpretation is being using because there is no way to tell the directory which entry to return data about therefore the SOAP headers contain the target in the form of a ws-addressing epr. In other words - this query seems to be targeted to an entry rather than a directory. The objective of the "entry" implementation seems to be to work with query. The only stuff that seems to be added is the concept on a "entry parent" EPR - which in our opinion could be placed in the {any}* part if needed (the whole notion of parents is a bit problematic; it is likely to be a list not a singleton, and using it for garbage collection is difficult in a distributed system.) Thus, query seems mostly to be a highly specific form of list. Thus, we have chosen the "obvious" implementation. That means that the query operation makes no sense by itself (beyond "list") and we have not implemented it. Page 8, move Move takes two parameters, a target directory and a "new" name for the entry, i.e., file1. This seems to imply an "entry" implementation. However, that means the client must be keeping track of the EPR's of the entries in order to do a move. That's the whole point of a directory services. Therefore, we believe that move should be an operation on a directory (i.e., the EPR of the directory is in the SOAP header) and take two parameters, the old name and the new name - in other words this is a rename. Finally, from a interoperability point of view the fact that the RNS spec does not include a normative specification of the schema/WSDL, we don't believe that it is likely for interoperable implementations to exist solely based on the spec. Modulo the above changes we have an implementation of RNS (we don't think that given the existing spec it is possible to completely implement RNS as specified) and a set of tools that interact with RNS name spaces, command line tools for ls, mkdir, etc, as well as a Linux file system software shim that intercepts file system calls and redirects (when appropriate) to RNS/ByteIO space. A

2 3

Bugfix for containers doc
by Donal K. Fellows 17 Sep '07

17 Sep '07

Title should end "OGSA Grids", not "OGSA Grid". Reads better that way. Donal.

7 7

Re: [ogsa-wg] OGSA/OGF URI for non-bound or non-functional EPRs
by Dave Berry 01 Sep '07

01 Sep '07

In ther OGSA Data Architecture document we suggest that URI's are needed to name transport protocols, access interfaces, and query languages. I would be surprised if this list were exhaustive. ByteIO, of course, have made a start on naming SOAP transport protocols (SwA, MTOM and DIME). Dave. -----Original Message----- From: ogsa-wg-bounces(a)ogf.org [mailto:ogsa-wg-bounces@ogf.org] On Behalf Of Andre Merzky Sent: 30 August 2007 12:01 To: Michel Drescher Cc: OGSA-DMI ML; OGSA-WG Subject: Re: [ogsa-wg] OGSA/OGF URI for non-bound or non-functional EPRs Hi Michel, Quoting [Michel Drescher] (Aug 30 2007): > > Folks, > > - apologies for cross-posting - > > [...] > > Also, while we were discussing this matter on the last DMI call, we > came up with the idea whether it is feasible to pull together a couple > of interested people and create an OGF Community Practice document > that may be based on > GFD.84: "Standardised Namespaces for XML infosets in OGF" > (http://www.ogf.org/documents/GFD.84.pdf) and defines, at an OGF level, > standardized URIs for things such as > - non-bound EPRs (as discussed) > - Data transport protocol identifies (GridFTP, HTTP, FTP, SRB, RFT, ...) > - ... > > Any ideas or comments? The SAGA groups would happily consume such a document - at the moment, we leave all these specification to either the implementors or (worse) to the end users, and are not satisfied with that solution. Cheers, Andre. > Cheers, > Michel -- "XML is like violence: if it does not help, use more." -- ogsa-wg mailing list ogsa-wg(a)ogf.org http://www.ogf.org/mailman/listinfo/ogsa-wg

2 1

OGSA/OGF URI for non-bound or non-functional EPRs
by Michel Drescher 30 Aug '07

30 Aug '07

Folks, - apologies for cross-posting - at the last OGSA-F2F, and during the follow-up weeks in the DMI WG we agreed upon and worked on a common URI for the wsa:Address field of an EPR that is either a) unbound to a service (late binding, from GenesisII @ UVa), or b) non-functional at all and merely meant as a container (OGSA-DMI 1.0) Attached is the latest draft of the OGSA-DMI specification containing the first attempt to standardize that URI. I would like to draw your attention to section 4.2.2.2 (page 10 ff.) and in particular to the description of "/dmi:DataEPR/wsa:Address". We would like to invite you to make comments on that section, and actually on the specification at large. Also, while we were discussing this matter on the last DMI call, we came up with the idea whether it is feasible to pull together a couple of interested people and create an OGF Community Practice document that may be based on GFD.84: "Standardised Namespaces for XML infosets in OGF" (http://www.ogf.org/documents/GFD.84.pdf) and defines, at an OGF level, standardized URIs for things such as - non-bound EPRs (as discussed) - Data transport protocol identifies (GridFTP, HTTP, FTP, SRB, RFT, ...) - ... Any ideas or comments? Cheers, Michel

2 1

F2F after ogf21?
by Andrew Grimshaw 29 Aug '07

29 Aug '07

Is there an OGSA F2F on Friday after ogf? A

2 1

[Invitation] Express AuthN Profile @ 2007-08-30 08:00 - 09:00 ()
by Hiro Kishimoto 28 Aug '07

28 Aug '07

ogsa-wg(a)ogf.org, you are invited to Title: Express AuthN Profile Time: 2007-08-30 08:00 - 09:00 (Central Time) Calendar: Description: When: 9-10am EDT, 8-9am CDT, 6-7am PDT, 10-11pm JST, 2-3pm UK Dial-in numbers for Thursday: Free: +1-888-452-0308 Intl/Toll: +(210) 234-7446 PIN: 71815 See more information: - https://forge.gridforum.org/sf/go/wiki1477 Screen share service: URL: http://ogsa.glance.net/ Usage: https://forge.gridforum.org/sf/go/wiki1584 Note: ** OGF IPR POLICY APPLIES ** http://www.ogf.org/About/abt_policies.php 1) Early discussion Social study notification - https://forge.gridforum.org/sf/go/wiki1717 Note taker assignment Roll call Agenda bashing 2) OGSA Express AuthN profiles (Duane) Having a last-call vote the following week for progression to public comment Any comments/suggestions/issues that have cropped up now that we've been socializing and reading the documents with a sharper eye for detail - http://forge.ogf.org/short/ogsa-wg/spuc - Issue tracker - http://forge.ogf.org/short/ogsa-wg/isuc - http://forge.ogf.org/short/ogsa-wg/spsa - http://forge.ogf.org/short/ogsa-wg/spss - http://forge.ogf.org/short/ogsa-wg/spst Minutes approval July 30 telcon: (Chris Kantarjiev?) Aug. 14 F3F: https://forge.gridforum.org/sf/go/doc14713 Action Item review You can view this event at http://www.google.com/calendar/event?action=VIEW&eid=dG0wYnZmcXJvNmg4ZG10Zn… You are receiving this courtesy email at the account ogsa-wg(a)ogf.org because you are an attendee of this event. To stop receiving future notifications for this event, decline this event. Alternatively you can sign up for a Google Calendar account at http://www.google.com/calendar/ and control your notification settings for your entire calendar.

1 0

Notes from OGSA roadmap call on August 27
by Hiro Kishimoto 28 Aug '07

28 Aug '07

Hi all, Notes from OGSA roadmap call on August 27. Also available on GridForge. https://forge.gridforum.org/sf/go/doc14741 Thanks, ---- Hiro Kishimoto ---------------------------------------------------------------------- OGSA Teleconference - 27 August 2007 - roadmap ============================================== * Participants Chris Jordan (SDSC) Hiro Kishimoto (Fujitsu) Michael Behrens (R2AD, LLC) Minutes: Hiro Kishimoto * roadmap document final review Since we don't have a quorum, we've reviewed Chris's latest draft and issue tracker. Confirm and close issue #5842 and #5970. #5948: JSDL HPC Profile Application Extension, V1.0. GFD-R-P.111 should be added to reference table. #5645: Hiro will send text on NAREGI and BG to Chris. OGSA AuthN profiles refer to working group draft version of WS-I BSP. WS-I already published final material. Hiro to ask authors which version AuthN profiles refer to. * Next steps We will do the following on the mailing list. (1) Incorporate all necessary edits into the document and close all issues on tracker. (2) Accept all changes and clean up document (3) Make final call on the mailing list for editor submission

1 0

Revised roadmap document
by Hiro Kishimoto 27 Aug '07

27 Aug '07

Hi all, Chris Jordan has made and uploaded revised roadmap draft onto the GridForge. We will review this draft at the call Today starting 6pm CDT. https://forge.gridforum.org/sf/go/doc13733 Thanks Chris! Talk to you very soon, -- Hiro Kishimoto

1 0