- ogsa-bes-wg - lists.ogf.org

HPC Profile meeting *ONLY* on tomorrow (Wed), not Thursday too
by Marty Humphrey 12 Sep '06

12 Sep '06

Folks, Originally, we scheduled TWO meetings for the HPC Profile WG -- one for the GGF proper and the other for the subsequent F2F. We did this because we felt that we potentially had a lot to discuss. Over the past month or two, many of these issues have either (a) been resolved, or (b) properly delegated to the JSDL WG or BES WG as appropriate. In other words, we feel that it is appropriate to only have *ONE* session instead of two. Therefore, we are *CANCELING* the Thursday session in the OGSA F2F (which was supposed to meet Thursday at 3:30-5pm). Note that we decided to cancel Thursday's meeting as opposed to tomorrow's meeting because (a) we believe that discussions in the main GGF session would result in a larger and broader audience, and (b) both Marvin and I would have had to rush out of the meeting Thursday evening to try to satisfy travel constraints. We look forward to a productive meeting in our main GGF session, which is tomorrow 1:30 - 3:30 in 158 A-B. -- Marty Marty Humphrey Assistant Professor Department of Computer Science University of Virginia

1 0

Experiences Document
by Mark Morgan 09 Sep '06

09 Sep '06

Ladies and Gentlemen, Recently I was asked by members of the BES working group to describe some of the work that we (the VCGR group at Uva) have been doing on a project we call Genesis II. Specifically, the work is grid technology based on existing and emerging web and OGF standards and is of particular interest to BES because it uses WS-Naming and "proto"-RNS to easy job management and control. However, it's also relevant to ByteIO in so much as it also contains an implementation of some of the ByteIO port types and talks about possible uses for promoting better grid control and usability as well. Later I was asked by Hiro on the OGSA telecon about this as well, so here is a paper that I wrote which details experiences creating, and motivation behind Genesis II. The document contains more information than just the RNS/ByteIO/BES interactions, but those are included as well. This paper is in draft form and has been assigned a University of Virginia, Computer Science Department Tech. Report number of "CS-2006-16". Until the link for that comes up, but draft paper is available off of the VCGR web page at http://vcgr.cs.virginia.edu/genesisII/documents/GenII-Experience.pdf. -Mark -- Mark Morgan Research Scientist Department of Computer Science University of Virginia http://www.cs.virginia.edu mmm2a(a)virginia.edu (434) 982-2047

2 1

Tracker Resolution Descriptions
by Peter G. Lane 08 Sep '06

08 Sep '06

I'm having a lot of trouble understanding why certain decisions were made with respect to tracker resolution. The most verbose the descriptions seem to get are "assigned to so-and-so for clarification". There's no context, and since I've missed a few phone calls that dealt with objections I've had, I have no idea why the decisions were made. Could whoever is resolving these trackers kindly make an effort to include more context so people don't have to ask later why certain things are the way they are? I don't think it's appropriate to expect that everybody interested in BES should be able to attend every single telecon just to get information on tracker resolution. That's why Gridforge allows comments to be attached to trackers, IMHO. I'm not trying to be mean here. I just think we could do better from the "open process" point of view in explaining what we're doing and why. That said, I have a couple of questions about tracker resolutions that. I'd be grateful if anybody attending the associated telecon could answer them. 1) What was the reason for keeping ContainedResourceAttributes and not including attributes like ContainedStatuses and ContainedActivityDocuments? Was there a concensus on why the problems associated with aggregation of activity attributes should be ignored? 2) Why are we still essentially advocating WS-Transfer's attribute model by having the GetAttributesDocument operation? In my opinion it is not necessary for minimal interop, and makes WS-Transfer's Get operation redundant. Is part of the problem that we haven't defined any interop standards yet? Thanks! Peter

8 14

Version 26
by Andrew Grimshaw 07 Sep '06

07 Sep '06

All, I have placed v26 into grid forge. See comments. It is based on Peter's v25. Please in particular look at the sections in yellow and red. We need to decide what to do with them. A Andrew Grimshaw Professor of Computer Science University of Virginia 434-982-2204 grimshaw(a)cs.virginia.edu

1 0

Regrets - Quadruple booked....
by Maguire_Tom＠emc.com 07 Sep '06

07 Sep '06

0 *H÷ 010 +0 *H÷ $ëContent-Type: multipart/mixed; boundary="----=_NextPart_000_0026_01C6D271.887B30B0" X-MS-TNEF-Correlator: 70C3890F93D2C601 This is a multi-part message in MIME format. ------=_NextPart_000_0026_01C6D271.887B30B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Tom _______________________________________________ Tom Maguire Senior Technologist, Office of CTO EMC2 maguire_tom(a)emc.com +1(845) 729-4806 "The only difference between a rut and grave is the depth." - Ralph Waldo Emerson ------=_NextPart_000_0026_01C6D271.887B30B0 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="winmail.dat" eJ8+IggPAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQOQBgBEFQAAHwAAAAsAHw4BABIAAgH4DwEAAAAQAAAAGTFs0enA QU+TG+xdGMv50gIB+g8BAAAAEAAAAEcAeBfHkKxKr+8LploFF7ADAP4PBQAAAAMADTT9PwUAAwAP NP0/BQACARQ0AQAAABAAAABUlKHAKX8QG6WHCAArKiUXHgD6PwEAAAANAAAATWFndWlyZSwgVG9t AAAAAAsABIAIIAYAAAAAAMAAAAAAAABGAAAAAAaFAAAAAASAAwARgAggBgAAAAAAwAAAAAAAAEYA AAAAAYUAAAAAAABAABOACCAGAAAAAADAAAAAAAAARgAAAABghQAAAAjW6CkAAAALABCACCAGAAAA AADAAAAAAAAARgAAAAADhQAAAAAAAAsABoAIIAYAAAAAAMAAAAAAAABGAAAAAA6FAAAAAAAAAwAD gAggBgAAAAAAwAAAAAAAAEYAAAAAEIUAAAAAAAADAGqACCAGAAAAAADAAAAAAAAARgAAAAAYhQAA AAAAAAsAcIAIIAYAAAAAAMAAAAAAAABGAAAAAIKFAAABAAAAAgEJEAEAAAA4EgAANBIAAIkoAABM WkZ1Eb6jNgcABgEBC2BuZzEwMmY1AGQAcmNwDdAOADIdDGBjDUQBNAExc3Rz4mgFcGJjaBA1CQAQ x2ZoDrAQ1mJpAUMNpDPyMxLmZmUTYgH3AqQDY0cCABDACsBzZXQC0XAocnEyAAAqCqFuby0WICAN 8BdxNhNwMDWcMDQX8QHQF+A0fQdt3wKDAFAD1BXPFttiF7EYIJ8XghzEGKAHEwKDMzcaH18bLxw3 F+QcohigVgSQZNUAcGEd1DgVXjIich9yoiAHbSBDRR3UOSKfpxgQI88k1XlyAoM0GgG5FXwxNhoB Jx8DgkcJ0X5rKJQPICkfLFEqXwOCVM8IcCiUE5ASoWRpAzYpeA43HjEtvwOCKEhlYvkJcHcpKJQm 4S/PMNQjv38yRgcQAaAOsDMlDhAsfjjWNjVPJNRCB0B0DrAolF84wSkuL5E4/zJzVgiQdPsiAAeB ZTMlIoEebCOYBxN9JSY0JbE/DSbXQIUodTX/Gg8qCECEK6gPEUQvLYZAhH0vBjUvmEQ9MSdAhDK7 Ne8zmEoOQAw2uzU3kUQ9OLf7QIQ6STU4wUQ+PDZLhT3P3jA+3yOYIbVA1zBBbybI/1fnKHdEDyoI V+YrqQ7wW9/3LXdX5i8HMVAvOKhX5jpKfyoAYZ88J1fmVQwCkQjmO9UJbzBoT2UOADVpemqR/2pP a1lpZGuCae9tv219bP/nay9pfxQwMjhzSnRhdB//dSlpZHVSc793j3dNds90//14xDkPIHwUfXF1 k31wAoKpEFB5bAeQaAngdAAAenEDIWwSwQUQAUAD8GS4Y3RsCrGAUDbQcAEB7GF1OmAAYHMKsICw HuBRgbJudW0CAGGBcHQybw1RanUQUAUQZ2hfgaAFEAoBf+AKAWkBkHA2MAMwACBsEMAesXMx/QMw YQExhcAL8CbgB0ANtf9/wYOAhTSE0YYTEycT6AjQ5wnAM9CIE25wiGmKBAMw8HNuZXgfMAewBbAA wH8CcxbghXGE0Q1gM+A6cHbnF1AQQB8QbWkSAIzwCfCkIESBVCBQCsBhCcDxgSBoIEYCIYwkEGBb sTsQYANgdwswg4ABgHNX8TPQdGhCE5CDgAqwjPDubA3gIoCRlHKSCA2QkXYrAYCTd2KTd3KRcmNi /wqwKfCVYh9glcMCYAuACZEzlpR+8HBlkXEE8GVs3myAYZFAkOGW8XONQAAg/zpRj/Ey4JKQmVYJ UJl0DLHnmYOA4Jl0ZGeaVpvQm1b7hUCZdHYDMH+vgL+Bz4Lf/4PvhP+GAqLxhx2iQQ20iAT/FCKG MYlspgenhIs1W7CNbP+LxDygAaB/EIwnhuGM6KMtt6R8n6AI0GY8kBBAYp/g/wmAAiCMon7hHwAz 0BgADeH6M4WQSJeBmkALgCvjjGP+NquPrJ+tqq8irq+vt49g/5gQkIAJgLBPMRCxf4VXAFF/pD8Z 5AwBtD+NihBAsGFzzwIgQLEQQAWgbXAXMq9O9kUAwAMQU37yMRBncxbgPQtgdAnwEGB+853wc2Tz EFAHcGF4YXA4wMFxEVG2awmAAQEwjDNoYHYCUdgge1WwsBcgdxmhwxR/r5HDksSzI5A68B4wxVM2 1jY4sa+CODeAMSbgr4L/xwBD8C1xxVPGMA7wE5DH5O43DxAAUK+CM0lQxwDIdHHJgDY5Ng4Qr4Io 4DA/DfDGdDrwAdAPEctVNznzJbDKozg4sBDKhAHAsBC7OKDNVTg1IJ4hzXIzyRC9zIU4xwA4sMXU fXAwAcD/0AZQEMvVDeDOUSjhxzMB0P/IUccV0HGwEMh0DvAXwMpw/dOmN8sAznDHJM8RyODRZe8i cBfgzRDVNTnJgF6hxzRvPCA+wNOlyZE5UuHYRDnsNDfHtdlBOFAQzJQqAPcTcEFQ06U2L4BD8Npl NSD3deAeIdwEORgQ2YDctspg/9xgxyTdINxhxxXQYRew06X/ymDFwNjW3fHXAcVEF/DYsf/hJ8yA 1pXJEJIBylDitdcg/0FQySTIIBfixnSwAdCA29X9I5A32XA3gcVTL4DOkOTW/zeAx5HHFA4A03E6 8cX0SVD/ywDIdeWAKhDpV8XA4lHFRP/G0BOAzeV14MyAzxDGdBfg38yA2WDKhM0hxtAyzJSwEP8q ECWg7eUX4cxwxdQTgMpw/zrw7GUvgC+AymDJNMxR78H/yTTmIDeAhjHxxc8B72XI8P/IUfMmPCDK cMfEInA4sNRG/yJw1yLN9FYRzyHL5drB7dD/xdQsQOWAN4D3p+BByoXccf/YscqUGCDtkfYlGCAq EMe1/zOA2YAX0ctF25DmRsWx1mH/y+bG0syVAcAsQOiV8uKwEP/L5dowDfHKhdoxNSDJJD7A/zUg F8D2JeQQxkDaIAI22MD/DAGviQO1ATHZcAO125DZUP8FJtxR5BUPEMpQzwDGdElQ/wwA7BAEZc8Q zRDyVUlQ2WD/deAEZQ8QCUHIdFLgQVDQgP/MlOhQ3qHGUAO0zRATgDEh/wwEBkHS1Q0B/sHKhNlQ xcD/I5ALJcyAE3D51SoQzRBS4P/HxC1w2iDXIMZ025DIINlg/8cU25AIAfhVCtHTkNTgD7T/ASLV 1cpw92EOFcZAyOAsQP/IdOqhKgDdIBW14CHN5d4B/+eCFzXwgMxhD7TdIFjgInH/zWOIcNOQ0IAZ dewQzQHNVP8xEPCA11UHQcvBzUUo4A+B/xxmyPAXBuYg71AxEM6lAgH/LXDNRSoQfWHN9c6QL4DT lf/OgcpQTLEgRIrwOKDNRc/h/8pBIDXXIFYgIaXMgM8A5iD/xoTQge9QzqTg8c8Q0KXcYP/LAMjw yHT2oVYgzTULsTEg/wsVC7LaICSl4RD8ASYlBwH/HCHGhBSBJIfKcPRSxoTNoP99YOWAxoTOkN3x J6XjQf2G/80AzHDvAcaE1yDMcACV7BH/5LDcld0h25HHFDBiiIAxZ//PANjV3SDbkNuh0BTUAQWh /zO1sBAMkM305BDP4RHVfXD/EdAdkdAV25DUADFl/6EPhv/tAcZQ7BDQFMpw05D4VR5h/+8S0BQO keth0XWIcOYgXOH/0YTUANiB2mUiMeZQycUiI/9f0NFmYpALkc30hrFsAfnV/6/i3JDyVaXi2hFA 1wTApfL/0YQ04dTRQoa7IMgxQoYysf/mVYrw7cDtoTsm26E1gdF1/wrBIWHRdu8yQAbG0YhwPzX/ SIIR0NIlivDZYFzgQAVbsP/+AdUWPHHv0MZlS8H2ofGV/1uw79AysUnGMIHaR2FwIZD/JgZbsPvw A1HTpQKjW7FPlf/YwfAVW7DZgRMhSQXPsBDB/8cV ÅYpAiEcyFU+L7EEDGU/H/IYE/NQfhdeA/Jkvh BkHS5v/HAO9QBRU8cxqh0jUHEVD3/8jSkgJZVc+w3pFa5wyQPLb/N+FEwdFlN+EuIVx2+xEEwf9e Ju2gWEj+wfCAXubG8BVx/9Im9gEK4WCW2MDLANLm2hH/FtHTttOQEdBdRhJBwhDSJv/KcNZi1Hbk oe2g1HZMIOwQ/9LmIJHYx2hBAdJn5j1hVEb/zmHFoVx22iAxEUNFGgHksP8R1TTRzzHTljTh4RAs 1TTR/wxRIZU00dchbxcpkcbh1TX/xvDhonDWCiDqgXDWDUE7Fv/JgGOR7NBw1tER3EDVNd+Q/9jB a+bNoHCRcZbNoNfhdAb/MQIzldcB2ZDFoda22YA4xv/XARhR11fs0EcCxyVWUorw/3tm2kE1FXux 4CHSFiCw0ID/5YB7VjmBRzfboc/hf2fGQP+K8NjlZHEVcccWz9HZcNUl/xHQ3pLTpUixIBDKdcdy ATH/gQZ4oRkRhSftt9fB0hCCYf/XdieB35aH8guR13ZjgUTW/4KB7NCAJ9lgAfF7VtjA3EH/fcbY wINRg3bKYNaBQ0Wvwf/P4dUlBMAOkelVcVHLEEvB/4+255FiFskBFtKRVu/R2Bf/BxHicZFWGqFH RgOA0RH9lf9KgPaB9oGVZt0BV4ZPMdlR/9gmMIGFx9ExEBGUhhbB9tD/mWc4wVEGcuL2oZsWjBF4 Bv/toD1BU0CctlQBO+biYe/R/9sm4lHoUNUly6HswT5l35D/XoE9hspwEOGhd/SB2uDY5V9RwT7g yyV9cijhOarzeBhtbG7BAMURfVxwumGwYXdZkXtBpdNo7ZLjQ0C/gHJnbD7ghdGnUlpyp6d0gWGn NGKo42d0dXTAwHJDQLoRvkBj+nS58Hc7YLZwqqCwgLrA8HRuYmqy4MDQwsDCgIpcxBB4wKF0b3nA 0MBcZXhwc2iyMK0A38QQtACrQb0wrEBkwODFEDGlUGJkYqxRvTBhY9nC4G9ytAGvgW2tULgAKGVc aK+QeqwiZGd3p1K3ELDxaK8zp6Gw8Xb7scmwgWmxUR6BuuCyUbNFvykCsZKwgKYgskO1E2qtIX5h rACuUMKAv9C9QD5gdvBpZXdrsWAD8LbzveCXvaDAAIXRcKlgcmSm0E5lsEC4Za+Ab3S9IWx8eXTE MLFgsGCrgbn3aP50v4Cp4L0wrFGuoLtAsECyasUBXHW+QK3gYrgA/60AvQHFAbdRwjC6ALfxqqD9 xRB3vcPFAa1wqCDCMKugPHJrr6GwYMQQv4F3cvJwvGJzbqagrMCoIDtgW7OAr2Bsr8C4AGzEIGZ9 txBssFCsALyxqtDAYHD2dcFwubBh0ZC2ML+GO0JucrmRBAa6UHelcaVgeb2voXOsUaggqxC7cW/C IKGqsWZldDCk4neoIHBmZm10wiCt4KYAIPkEEDNmpbDIELmAqTC38PO+AK6gdXCqM6aQyFC5wL2q kWSqwKpVqkC6QXhDQP+r8bwApgCwYKqCy0LBIhwRf8pEr3C7cK3gyWC5wKuDIM2k4nClUKqQbHan kM7B/HVjsADOwrwgrXDPUrdRnazwdHYhzsGwMG5nzoGJztB0eLwgIC59pNP/ztY+YM9yreHP39Dv 0f/PMH87IM7QsFCsQNPP1N/V72y/QNDO0L4w04/YX9llKdJMj0AA1y/cH9lFYiAopNH/3U/PA0ww 2u/fv+DP4d/PIf900OMyz7/kn+Wv3b0/MOM//+jP6d/q788hPMDnz+1v7n//74WlwbigpcCskLOA yqPKAfxccaWQyzFDQfYBquHMYf/1csBQpqDNhcNhppD2wLAw//fCyYDxIM2gxoKr0LxAvKDvq0Cz YLtA9iFuqjH6EsbQXaagMKrArXC+MGiv0GNkczGqwGFmQ0D70HP/QMG4ANkBQgLKo/tE+uH8I9/8 hDsR/ILHEP5zY8Ei/iP8bnD+eQAUzoH7HLXQ/BJ/+uH9K7XQAoL/YPvhs4BzHwYExOT7QKdgBJkg DQr/9HIGRvRk9S/2P/dH+NX6Dv8BXjCRAn/G8TCRA9f8hf4U1/8CQMGsYHDEgWYEXc6DEGJrbWvx YyBfTSn08GxBxpFTs2B9VP/JAKTRAX/8IFNAAs8UsgQR70qBDu8P/wXOXxnPGt8bqv8Tf/uhFR0O rxd/GI8HAhzPvxSfFa8fPyBPBdYTQSASgK2p0GnMEAZVU6zwaa+QWygQqpBou9HBEGmlYCxUIE/H wGmvYCDGsCD4Q1RPIk8dzx7fJj8g/z8iDyMfJC8lPy6vEMtFTb5DMP8yDzMfNC9AwXPJkPemADVf BeUyNw8sfy2PNO/vL68wtcIjpOJmwlAEYaqwHz1vPn8/j0CfEMtIWVAARVJMSU5LICKzqTDIEW86 qTAog1+swIBtQGVtYy5jyQD+Ij1fRS9GP0dPBH8Fg2YR9ZjxMs6DZKyg+9DCMqrABmKzgKSwIADQ yeoAefm6zhGMggCAqgBLqQsCAFQgKgNUIeBTLTZUIW0AAGEAaQBsAHQAiG8AOlXDZwB1VgFgcgBl AF9WQ1XQQONXYVXQYwAuWGFX0lQg/9JAQuLCUFrwreBEHzgfOSr/r7E5707PELxKXxNR0kJLz/9M 303vXk9BzzDvWv85H2O/I2TPZdgrMSi0oDUp8iB28Dkti1B/QAZdZv+faA9pHGoPax9l2CJUuNB7 KvC6oSDBUMfAzAHBcSDSYscgd2Ws8CDZsK+gy6qwtjEgqCBhdirgKkAcIHR0kbBQwHBoLiKQIC0g UvgCIFe4AOurADbAbaYAc3TAbq9ib/9xf3KPZZ8G/wgMrGAI7wn//wsPAb96rw5ffH99j36ff6// CN/3f/iP+Z+DX/uk/QwEKf+mMP9AlHCZUBGHq/ESbIl2BH0AlYAeAHAAAQAAAB8AAABSZWdyZXRz IC0gUXVhZHJ1cGxlIGJvb2tlZC4uLi4AAAIBcQABAAAAFgAAAAHG0pMPdTqJTITBHEQFgsXJ1U9h AgMAAAMAJgAAAAAACwACAAEABIALAAEOAAAEgAIBCg4BAAAALgAAAAAAAABHAHgXx5CsSq/vC6Za BRewAQD8FU3Y73V5SocrBssEOJevAAAAA6wFAAAAAAMACVkDAAAAAwDeP59OAAACAX8AAQAAABEA AAA3MEMzODkwRjkzRDJDNjAxAAAAAAMABhDVPjhZAwAHEJEAAAADABAQAAAAAAMAERAAAAAAHgAI EAEAAABlAAAAVE9NVE9NTUFHVUlSRVNFTklPUlRFQ0hOT0xPR0lTVCxPRkZJQ0VPRkNUT0VNQzJN QUdVSVJFVE9NQEVNQ0NPTSsxKDg0NSk3MjktNDgwNiJUSEVPTkxZRElGRkVSRU5DRUJFVAAAAABu Sw== ------=_NextPart_000_0026_01C6D271.887B30B0-- Ê0=0ŠÍºVðßäŒTþ"¬³rªU0 *H÷ 0_10 UUS10U VeriSign, Inc.1705U.Class 1 Public Primary Certification Authority0 960129000000Z 280801235959Z0_10 UUS10U VeriSign, Inc.1705U.Class 1 Public Primary Certification Authority00 *H÷ 0å¿m£Va-HqögÞ¹ë· ú8%¯Fåsš $] Ìen°ÐV¡sßŽX9knÁöÕšš?ª1¬°4×4g ÍâNEVixÚÜG)»6Éc\Åà×-{¡·2°{0º*/1ªî£gÚÛ0 *H÷ L?žÆhßîC3]éŠËMz3ÿô6Ø"6hl|BÌó.Ä?°OÿvùâŒJéÍ ÷Å)ñ"]ž±Ý#£{%F0yøêKÂÈã·ô@<Ã_SèHäŽ{¡5°{%ºžÓ«?84óÑq0b0Ë ÚÁ?« tzŽÎ.30 *H÷ 0_10 UUS10U VeriSign, Inc.1705U.Class 1 Public Primary Certification Authority0 980512000000Z 080512235959Z0Ì10U VeriSign, Inc.10UVeriSign Trust Network1F0DU=www.verisign.com/repository/RPA Incorp. By Ref.,LIAB.LTD(c)981H0FU?VeriSign Class 1 CA Individual Subscriber-Persona Not Validated00 *H÷ 0»ZD»Uýz-Ox6ž J²oT¿Œèw*¹ðh»Ù1ApzK¹HV-ÇáB«À¢«D\ªBðé/ûÂ;»ŸÉ' ]¶°6B3µnTOJ¿Úùè¶ãÌÆj$ãüàeº§±~ïÉÛ7jÈJÈ ä£°00U0ÿ0GU @0>0<`HøE0-0++www.verisign.com/repository/RPA01U*0(0& $ " http://crl.verisign.com/pca1.crl0U0 `HøB0 *H÷ }oEK8 žÞéSd!ŒäL+þ@¬Ø 9j¡2!,«YþÒb}U8°7sÜôfcbœáSpRçšØRé[-ªáÞÏ¬1TÔÈØ#šï+2},È|š.wòDÑe MtµîÓst.;5rç@1Ó²Ä«çVŸãû00 aI±thÆãøSÈ¬1ÌÀ .0 *H÷ 0Ì10U VeriSign, Inc.10UVeriSign Trust Network1F0DU=www.verisign.com/repository/RPA Incorp. By Ref.,LIAB.LTD(c)981H0FU?VeriSign Class 1 CA Individual Subscriber-Persona Not Validated0 060419000000Z 070419235959Z010U VeriSign, Inc.10UVeriSign Trust Network1F0DU=www.verisign.com/repository/RPA Incorp. by Ref.,LIAB.LTD(c)9810UPersona Not Validated1402U+Digital ID Class 1 - Microsoft Full Service10UThomas Maguire1"0 *H÷ maguire_tom@emc.com00 *H÷ 0«ŒåO!² cuû!ç_ãÚFÒWðçínøíy>ÏŒ³$"ÎñÜeq¶Úß©Çï«t úK?@K¬þ[REæâËH¶#»ÇS1w\¯lúèŸa7Š)ì_eÎËê66$±s²ùxT¿4×íËª/ç£µ0²0 U00DU =0;09`HøE0*0(+https://www.verisign.com/rpa0U 0U%0++03U,0*0( & $"http://crl.verisign.com/class1.crl0 *H÷ <¢A·ë¡ø'¿ÎáÜßTî$ñ<Ü{nDa6gWÛÈØ¿€«ÉšO³Eq!ÛÃnw) Žæ5ÜÊ£Á×eF¹Dö¬«úÄ()ÌLç£4œä×Å²AÿÅ,^56¥¢Ò°®oI÷ñ¿AÿæÅ1>0:0á0Ì10U VeriSign, Inc.10UVeriSign Trust Network1F0DU=www.verisign.com/repository/RPA Incorp. By Ref.,LIAB.LTD(c)981H0FU?VeriSign Class 1 CA Individual Subscriber-Persona Not ValidatedaI±thÆãøSÈ¬1ÌÀ .0 + ²0 *H÷ 1 *H÷ 0 *H÷ 1 060907153408Z0# *H÷ 1g,€ÕQfuÞ+þ0g *H÷ 1Z0X0 *H÷ 0*H÷ 0 *H÷ @0+0 *H÷ (0+0 *H÷ 0ò +71ä0á0Ì10U VeriSign, Inc.10UVeriSign Trust Network1F0DU=www.verisign.com/repository/RPA Incorp. By Ref.,LIAB.LTD(c)981H0FU?VeriSign Class 1 CA Individual Subscriber-Persona Not ValidatedaI±thÆãøSÈ¬1ÌÀ .0ô*H÷ 1ä á0Ì10U VeriSign, Inc.10UVeriSign Trust Network1F0DU=www.verisign.com/repository/RPA Incorp. By Ref.,LIAB.LTD(c)981H0FU?VeriSign Class 1 CA Individual Subscriber-Persona Not ValidatedaI±thÆãøSÈ¬1ÌÀ .0 *H÷ $ >:ÑI.$ÒuŒ¯ßj*A§jÙ©ÁçÄ¥¡ª=ŠÛuT÷mÕábóŠV"È}ÿýMâ÷æ)eìÃÌÒBÉ«éÏÒd%þ^è}ì³SÎpsUøÊh úK£L£`èÔºAûÄ§"D:#§à

2 2

Process Point
by David Snelling 07 Sep '06

07 Sep '06

Folks, I think the editors' list of BES needs updating. I would include Morgan, Theimer, Foster, and Puslipher. -- Take care: Dr. David Snelling < David . Snelling . UK . Fujitsu . com > Fujitsu Laboratories of Europe Hayes Park Central Hayes End Road Hayes, Middlesex UB4 8FE +44-208-606-4649 (Office) +44-208-606-4539 (Fax) +44-7768-807526 (Mobile)

2 1

Re: [OGSA-BES-WG] [ogsa-hpcp-wg] Revised version of BES draft specification
by Ian Foster 06 Sep '06

06 Sep '06

I can't be on the call tomorrow as I am at a conference in DC. Perhaps Peter Lane can make the call. Ian. At 11:29 AM 9/6/2006 -0700, Marvin Theimer wrote: >Content-Language: en-US >Content-Type: multipart/alternative; > >boundary="_000_8A89086DD69AD14899AD08D44A7F74021236D140DANAEXMSGC101Br_" > >Ian; > > > >I agree with your concern at least to the level that this needs to be >discussed and the material, if included, probably modified. I included it >in the draft as a place holder for future discussion. I think I also >added a tracker on the matter, but it was very late at night and I might >have forgotten to. > > > >This is a topic Id like to propose for discussion at tomorrows >teleconference call, if possible. > > > >Marvin. > > > >From: ogsa-hpcp-wg-bounces(a)ogf.org [mailto:ogsa-hpcp-wg-bounces@ogf.org] >On Behalf Of Ian Foster >Sent: Monday, September 04, 2006 8:05 PM >To: Mailing List for OGSA-HPCP-WG; Mailing List for OGSA-HPCP-WG; Peter G. >Lane >Cc: ogsa-bes-wg(a)ggf.org; ogsa-hpcp-wg(a)ggf.org >Subject: Re: [ogsa-hpcp-wg] Revised version of BES draft specification > > > >I'm concerned about the inclusion of the Appendix entitled "Container >Model." This looks like useful material that should be published, but I >don't believe it belongs in the BES specification. > > >At 06:30 PM 9/4/2006 -0500, Ian Foster wrote: > >I would like to claim the pen. > >Ian. > >At 02:56 PM 9/2/2006 -0600, Peter G. Lane wrote: > >I'm done with my changes for the moment. The sections I was tasked to fill >out were mostly done, so it was mostly just polish. I also did a lot of >polishing to the operations, especially the schemas and WSDLs. I'd really >appreciate it if people could look at this version before I put it up on >the BES documents page. I want to make sure everybody's ok with the >changes I made. Here is a general overview of what I did: > >- Changed all references to GetActivyStatus and GetActivitiesStatus (the >document inconsistently had both) to GetActivityStatuses to be both self >consistent and consistent with GetActivityDocuments (according to my >dictionary, this is the correct plural of "status"). >- Added myself to the authors list. >- Fixed some xsd:any element declarations in operation wrapper types. >- Removed "Type" suffix from all instance elements since they are not >complexTypes. >- General clean up of the schema to be consistent and more readable. >- Removed all minOccurs="1" and maxOccurs="1" element attributes since >these values are the default. >- Fixed the s12:Fault element declarations. >- Removed duplicate LocalResourceManagerType element from >BasicResourceAttributesDocumentType (also exists in >BESResourceAttributesDocumentType). >- Added fault element to the GetActivityDocuments response type >- Added explicit wsa:Action attributes to all input and output operation >elements >- Updated the non-normative message examples > >I should note that the section numbers seem quite messed up. Somebody who >has a better idea of where things are supposed to fit ought to make sure >the numbers are ok. I would have assumed that Word would take care of this >automatically, but I guess not. > >Peter > > > >Content-Type: application/x-pkcs7-signature; name="smime.p7s" >Content-Disposition: attachment; filename="smime.p7s" >Content-Description: S/MIME Cryptographic Signature > >0 *H÷ > 010 0 *H÷ > P0¦0 Ñ0 > *H÷ >0i10 &ò,dorg10 &ò,dDOEGrids1 0UCertificate Authorities10U >DOEGrids CA 10 >051111152456Z >061111152456Z0^10 &ò,dorg10 &ò,ddoegrids10 >UPeople10UPeter G Lane 3642430"0 > *H÷ >0»ÔäÓÎ<¹ÖM >Ù3¶é=vU5âHÚñz®w7¼AhÂÃCñ;Ud¥°%ólñß=hýÙmE[w"é!My"c<2n[dÿÞ¢fo®°5¶anWAoØÁaé:Yñbx=ÕÕ4ÝB©"L5@`?ÛÐ©Nk2Åûü°ÿ·Þø·=D` >É¦9æÑ³ùo¸ðÝ±Áä1éß¡ÔF®r8"[])}QJn>Õuï¯j^¸[Ñ½1¸Ùç5èfãIÞoÝÎ?~Ù|CUäÅÓº;ùDy£c0a0 >`HøBà0Uÿð0U#0Ên¤8]BÔ1ÛÙ >]0U0lane(a)mcs.anl.gov0 > *H÷ >|Âr >¹vçÞW29z¾MbÎí³þÐãsaTÝrÁx¶ >±<ð<]@Ígzñö#¬ûúÅÜpxÜÝ¯f^b"ÀcÖcX>¡ÞD"kPíòëSØ?ú¾=æ#Q¼×æóhé[½¯´á0{¡i >õâÀßó¨¾Î<â <üW0Pdæ-±Ú-Ðâ >Z}ÖÏ*%D6¸=iSpJ|µ0rÀi'LK×uOÌ/l ÆcÖFØ*í«ÁÐ`c >äÃ(¯¯â`G®{©æÐ>Ý¾_×÷4¯ÕÙ1÷ø ¦¢=ÿ9ÊJæðé¸¾ç0¦0 Ñ0 > *H÷ >0i10 &ò,dorg10 &ò,dDOEGrids1 0UCertificate Authorities10U >DOEGrids CA 10 >051111152456Z >061111152456Z0^10 &ò,dorg10 &ò,ddoegrids10 >UPeople10UPeter G Lane 3642430"0 > *H÷ >0»ÔäÓÎ<¹ÖM >Ù3¶é=vU5âHÚñz®w7¼AhÂÃCñ;Ud¥°%ólñß=hýÙmE[w"é!My"c<2n[dÿÞ¢fo®°5¶anWAoØÁaé:Yñbx=ÕÕ4ÝB©"L5@`?ÛÐ©Nk2Åûü°ÿ·Þø·=D` >É¦9æÑ³ùo¸ðÝ±Áä1éß¡ÔF®r8"[])}QJn>Õuï¯j^¸[Ñ½1¸Ùç5èfãIÞoÝÎ?~Ù|CUäÅÓº;ùDy£c0a0 >`HøBà0Uÿð0U#0Ên¤8]BÔ1ÛÙ >]0U0lane(a)mcs.anl.gov0 > *H÷ >|Âr >¹vçÞW29z¾MbÎí³þÐãsaTÝrÁx¶ >±<ð<]@Ígzñö#¬ûúÅÜpxÜÝ¯f^b"ÀcÖcX>¡ÞD"kPíòëSØ?ú¾=æ#Q¼×æóhé[½¯´á0{¡i >õâÀßó¨¾Î<â <üW0Pdæ-±Ú-Ðâ >Z}ÖÏ*%D6¸=iSpJ|µ0rÀi'LK×uOÌ/l ÆcÖFØ*í«ÁÐ`c >äÃ(¯¯â`G®{©æÐ>Ý¾_×÷4¯ÕÙ1÷ø ¦¢=ÿ9ÊJæðé¸¾ç0ø0à 0 > *H÷ >0u10 &ò,dnet10 &ò,dES10UESnet1 0UCertificate >Authorities10UESnet Root CA 10 >021205080000Z >080110080000Z0i10 &ò,dorg10 &ò,dDOEGrids1 0UCertificate >Authorities10U >DOEGrids CA 10"0 > *H÷ >0´õÖ#a£Û>fµ¸o²ß-jmr¢Èq÷¼.ËÛcâ,-ÿY"×d >n1ËË.kÙÉÊíºdÌ´ë`ß >IÔwÂáQHWKTo@lÖ²yþúq¥BÍ~!t.7«8ôÜ5ö^Õ6ZÝí\ö·<5y9%þgì²KÅ!k´ÈÍÈ_ú}!Á£Íç|%wÓÖøcC¸vQ[7ÎrÎoÓ³µQýlW7¾ÌÅlpk]-ðÖïcNßªæÑ-tö«Û°ÙZ®Ño«<¦¤@ºJ{Mø]Ì{êROÅÆQZ)ùcw¯?K£00 >`HøB0UÿÆ0UÊn¤8]BÔ1ÛÙ >]0U#0¼]MH/ø5Y«\K>Ñ²:ê0Uÿ0ÿ0%U0DOEGrids-CA-1@doegrids.org0 > *H÷ >*;b>3p{)5V#±¶(=vÎ53¡¿(B7â >xQ{Â¤´`-#gÝKøj1q.ãë8ÓÕ¶ÙðRa5Ôj½BF¹ÃãÚ]=Â£3NQëji_gkÝE´´ªxýÊ^Í¸¿´þBkêÛÎ¹ñî¥@Çwè¨(v¶c¶JÊHÕdjÝ1rI¥ÿ¿£°ôÎ¥½ÐÝ >u<iû²@x1îÀÑ¼¯;DÚê ©Zµk;>Õz[½TÙï<xG¸-*Õ#Å)eSÇ½º >·±ûþêß(ôüYy§@éÀGf¢åÿ.#A»1N0J0o0i10 &ò,dorg10 &ò,dDOEGrids1 >0UCertificate Authorities10U >DOEGrids CA 1Ñ0 ´0 *H÷ > 1 *H÷ >0 *H÷ > 1 >060902205636Z0# *H÷ > 1<úÍNþR[9£ì$2³S0R *H÷ > 1E0C0 *H÷ >0*H÷ >0 >*H÷ >@00 >*H÷ >(0~ 71q0o0i10 &ò,dorg10 &ò,dDOEGrids1 0UCertificate >Authorities10U >DOEGrids CA 1Ñ0*H÷ > 1q o0i10 &ò,dorg10 &ò,dDOEGrids1 0UCertificate > Authorities10U >DOEGrids CA 1Ñ0 > *H÷ >>ÇÏSm°dò;±Øþ--Ü|ÃËfï{qFé,±Çz¾ »UÔ®JÛ¢ÇLßHöá >ôDúWÉ±¹Æ¹öV¬µóïý2ÓÎ´5ò4§:¡²¸>bUVq ý¼®©ZøÔèO|ö«0 >:céA·Ðú%3äj1ÍGÍq&ºÞc >[ZÏÄ7§.FZY#É×¸X^¤lNxèSâWÃàêqØÔäÐçÜ*aÓêî/n3[m-Sí1p7-å¢:<üÎqµÅ9Ï >xFù<Èïâ;^¿t|G.¦Þÿ|0_6 >-- > ogsa-hpcp-wg mailing list > <mailto:ogsa-hpcp-wg@ogf.org>ogsa-hpcp-wg(a)ogf.org > http://www.ogf.org/mailman/listinfo/ogsa-hpcp-wg > > >_______________________________________________________________ >Ian Foster -- Weblog: ><http://ianfoster.typepad.com/>http://ianfoster.typepad.com >Computation Institute: <http://www.ci.uchicago.edu/>www.ci.uchicago.edu & >www.ci.anl.gov >Argonne: MCS/221, 9700 S. Cass Ave, Argonne, IL 60439 >Chicago: Rm 405, 5640 S. Ellis Ave, Chicago, IL 60637 >Tel: 1 630 252 4619 --- Globus Alliance: ><http://www.globus.org/>www.globus.org > > >-- > ogsa-hpcp-wg mailing list > <mailto:ogsa-hpcp-wg@ogf.org>ogsa-hpcp-wg(a)ogf.org > http://www.ogf.org/mailman/listinfo/ogsa-hpcp-wg > >_______________________________________________________________ >Ian Foster -- Weblog: ><http://ianfoster.typepad.com/>http://ianfoster.typepad.com >Computation Institute: <http://www.ci.uchicago.edu/>www.ci.uchicago.edu & >www.ci.anl.gov >Argonne: MCS/221, 9700 S. Cass Ave, Argonne, IL 60439 >Chicago: Rm 405, 5640 S. Ellis Ave, Chicago, IL 60637 >Tel: 1 630 252 4619 --- Globus Alliance: ><http://www.globus.org/>www.globus.org > > >-- > ogsa-hpcp-wg mailing list > ogsa-hpcp-wg(a)ogf.org > http://www.ogf.org/mailman/listinfo/ogsa-hpcp-wg _______________________________________________________________ Ian Foster -- Weblog: http://ianfoster.typepad.com Computation Institute: www.ci.uchicago.edu & www.ci.anl.gov Argonne: MCS/221, 9700 S. Cass Ave, Argonne, IL 60439 Chicago: Rm 405, 5640 S. Ellis Ave, Chicago, IL 60637 Tel: +1 630 252 4619 --- Globus Alliance: www.globus.org

2 1

Re: [OGSA-BES-WG] Tracker Resolution Descriptions
by Ian Foster 06 Sep '06

06 Sep '06

I think we have gotten ourselves a little confused here. The way I see the issue: this is not a question of WS-Transfer vs. WSRF, etc.--the point being raised is (as I initially said): "He [Peter] advocates (I believe) that we should not include the GetAttributesDocument operation in BES. Instead, any particular BES should choose (if they wish) to provide access to attributes via appropriate operation(s). * A WS-Transfer-based BES would use GET * A WSRF-based BES would use WS-ResourceProperties * A resource-model-free BES might define a GetAttributesDocument operation * etc." The point being that if we have GetAttributesDocument in BES, then anyone implementing a WS-Transfer-based version of BES will end up with two operations, Get and GetAttributesDocument, that basically do the same thing. Similarly for WSRF. Not fatal, but arguably rather inelegant. Ian. At 02:26 PM 9/6/2006 -0400, Maguire_Tom(a)emc.com wrote: >Content-class: urn:content-classes:message >Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; > micalg=SHA1; boundary="----=_NextPart_000_0063_01C6D1C0.5FDDB850" > >But the only reason we were resource agnostic was because there was >conflict. We didn't choose to be resource agnostic just because it seemed >like a good idea (did we?). There certainly was (are) some who argue >against any resource model (eg. Purely stateless services), vs those who >would encode some resource identity into an addressing scheme (WS-RF and >WS-Transfer). In the end most (all) of this discussion is about whether we >should encode identity of state in parameters in the body of the request or >we should encode identity of state in the headers not whether there is state >or not. >Personally, I think that WS-Addressing makes all of this pretty moot, but if >shouting at the wind makes us feel better, feel free.... > >Tom > >_______________________________________________ >Tom Maguire >+1(845) 729-4806 > > >-----Original Message----- >From: ogsa-bes-wg-bounces(a)ogf.org [mailto:ogsa-bes-wg-bounces@ogf.org] On >Behalf Of Andrew Grimshaw >Sent: Wednesday, September 06, 2006 1:48 PM >To: 'Mail list for ogsa-bes-wg working group' >Subject: Re: [OGSA-BES-WG] Tracker Resolution Descriptions > >I agree with Chris - I never thought of this as a WS-RF versus anything else >issue - more an issue with trying to be resource model agnostic. > >A > > > -----Original Message----- > > From: ogsa-bes-wg-bounces(a)ogf.org [mailto:ogsa-bes-wg-bounces@ogf.org] > > On Behalf Of Christopher Smith > > Sent: Wednesday, September 06, 2006 1:17 PM > > To: Mail list for ogsa-bes-wg working group > > Cc: ogsa-bes-wg(a)ggf.org > > Subject: Re: [OGSA-BES-WG] Tracker Resolution Descriptions > > > > Characterizing this issue as WS-RF vs WS-Transfer is misleading. I can't > > recall any discussions within this group where anybody advocated doing a > > WS-Transfer rendering for the BES interface. Well ... other than the WS- > > RF > > proponents who wrongly assumed that because some (like myself) were > > against > > the use of WS-RF, that must mean we were in favour of WS-Transfer. I > > also > > don't recall anybody advocating operations for modification, etc such as > > defined within WS-Transfer. To me this is a discussion of a resource > > modelling approach (built on WS-RF) vs a non resource modelling approach. > > > > My main reason for not wanting to make use of one of the resource > > modelling > > approaches has to do with the burden of implementation. If Platform buys > > into one of these resource models, we no longer have to implement one > > simple > > spec and test compliance of that specification, but we need to implement > > and > > test compliance on a suite of specifications, for (in my opinion) no > > extra > > benefit. You might say that once you've implemented a resource modelling > > suite of specifications, you can use it over and over and thus amortize > > the > > cost of this implementation. But even at a small cost, it's not one that > > I'm > > willing to take, as the implementation of standards specifications is > > one > > feature in a sea of features that we implement from product release to > > product release. > > > > -- Chris > > > > > > > > On 06/9/06 07:56, "Peter G. Lane" <lane(a)mcs.anl.gov> wrote: > > > > > If it's about fear of reopening the dialog, then I'd appreciate if > > someone > > > could at least add > > > comments to the two trackers addressing the issues raised. > > > > > > Ian can push for reopening this particular issue if he wants; but I > > just want > > > to know why we're > > > advocating WS-Transfer in spirit if not in name, and why aggregation > > of > > > resource attributes is not a > > > concern to anyone else. As long as someone has a reason for these > > issues that > > > I raised in the > > > tracker, I'm fine. I don't expect to get everything to go my way, and > > I'm open > > > to being convinced of > > > alternate points of view. I just don't like being ignorant, especially > > when > > > I'll have to implement > > > the spec someday. > > > > > > On the other hand, if nobody has a good answer for the issues, I think > > Ian is > > > perfectly valid in > > > asking for it to be reopened as apparently the issues weren't actually > > > addressed as they should have > > > been. > > > > > > Peter > > > > > > Mark Morgan wrote: > > >> Well, I guess the thing that confuses me is whether or not it is SOP > > to > > >> re-open an issue that was discussed previously because a new person > > has > > >> re-raised that issue. I'll bow to whatever the majority thinks is > > best of > > >> course, but it seems to me that you can't reopen an issue everytime a > > new > > >> person re-raises it or you risk the possibility of continuously > > cycling on > > >> it. New information should always be considered, but if an issue > > gets > > >> re-raised that has already been discussed fully and voted on, then it > > >> doesn't make sense to re-discuss it. Just my 2 cents worth... > > >> > > >> -Mark > > >> > > >>> -----Original Message----- > > >>> From: ogsa-bes-wg-bounces(a)ogf.org > > >>> [mailto:ogsa-bes-wg-bounces@ogf.org] On Behalf Of Ian Foster > > >>> Sent: Tuesday, September 05, 2006 9:39 PM > > >>> To: Mail list for ogsa-bes-wg working group; 'Mail list for > > >>> ogsa-bes-wg working group'; ogsa-bes-wg(a)ggf.org > > >>> Subject: Re: [OGSA-BES-WG] Tracker Resolution Descriptions > > >>> > > >>> Mark: > > >>> > > >>> I guess that I am asking that we re-open the issue, then. > > >>> > > >>> Ian. > > >>> > > >>> At 07:47 PM 9/5/2006 -0400, Mark Morgan wrote: > > >>> > > >>> > > >>> I'm not sure what level of "addressing" is meant here, but my > > >>> recollection/belief was that it was addressed in the > > >>> group in so much as the > > >>> topic was discussed at the last face-to-face and that > > >>> the appearance of the > > >>> GetAttributesDocument was the result of that > > >>> discussion. We haven't as a > > >>> group discussed the email that Peter sent out yet but > > >>> it is my belief that > > >>> doing so is essentially a rehash of discussions previously had. > > >>> > > >>> -Mark > > >>> > > >>>> -----Original Message----- > > >>>> From: ogsa-bes-wg-bounces(a)ogf.org > > >>>> [mailto:ogsa-bes-wg-bounces@ogf.org] On Behalf Of Ian Foster > > >>>> Sent: Tuesday, September 05, 2006 1:42 PM > > >>>> To: Mail list for ogsa-bes-wg working group; > > >>> ogsa-bes-wg(a)ggf.org > > >>>> Subject: Re: [OGSA-BES-WG] Tracker Resolution Descriptions > > >>>> > > >>>> Has Peter's comment been discussed? > > >>>> > > >>>> He advocates (I believe) that we should not include the > > >>>> GetAttributesDocument operation. Instead, any particular BES > > >>>> should choose (if they wish) to provide access to attributes > > >>>> via an appropriate resource model-specific operations. > > >>>> > > >>>> * A WS-Transfer-based BES would use GET > > >>>> * A WSRF-based BES would use WS-ResourceProperties > > >>>> * A resource-model-free BES might define a > > >>>> GetAttributesDocument operation > > >>>> * etc. > > >>>> > > >>>> This seems a good proposal to me. > > >>>> > > >>>> Ian. > > >>>> > > >>>> At 03:09 PM 9/2/2006 -0600, Peter G. Lane wrote: > > >>>> > > >>>> > > >>>> 2) Why are we still essentially advocating > > >>>> WS-Transfer's attribute model by having the > > >>>> GetAttributesDocument operation? In my opinion it is not > > >>>> necessary for minimal interop, and makes WS-Transfer's Get > > >>>> operation redundant. Is part of the problem that we haven't > > >>>> defined any interop standards yet? > > >>>> > > >>>> > > >>> _______________________________________________________________ > > >>>> Ian Foster -- Weblog: http://ianfoster.typepad.com > > >>> <http://ianfoster.typepad.com/> > > >>>> <http://ianfoster.typepad.com/> Computation Institute: > > >>>> www.ci.uchicago.edu <http://www.ci.uchicago.edu/> > > >>> <http://www.ci.uchicago.edu/> & > > >>>> www.ci.anl.gov <http://www.ci.anl.gov/> > > >>> <http://www.ci.anl.gov/> > > >>>> Argonne: MCS/221, 9700 S. Cass Ave, Argonne, IL 60439 > > >>>> Chicago: Rm 405, 5640 S. Ellis Ave, Chicago, IL 60637 > > >>>> Tel: +1 630 252 4619 --- Globus Alliance: > > >>> www.globus.org <http://www.globus.org/> > > >>>> <http://www.globus.org/> > > >>>> > > >>>> > > >>>> > > >>>> > > >>> > > >>> -- > > >>> ogsa-bes-wg mailing list > > >>> ogsa-bes-wg(a)ogf.org > > >>> http://www.ogf.org/mailman/listinfo/ogsa-bes-wg > > >>> > > >>> _______________________________________________________________ > > >>> Ian Foster -- Weblog: http://ianfoster.typepad.com > > >>> <http://ianfoster.typepad.com/> Computation Institute: > > >>> www.ci.uchicago.edu <http://www.ci.uchicago.edu/> & > > >>> www.ci.anl.gov <http://www.ci.anl.gov/> > > >>> Argonne: MCS/221, 9700 S. Cass Ave, Argonne, IL 60439 > > >>> Chicago: Rm 405, 5640 S. Ellis Ave, Chicago, IL 60637 > > >>> Tel: +1 630 252 4619 --- Globus Alliance: www.globus.org > > >>> <http://www.globus.org/> > > >>> > > >>> > > >>> > > >>> > > >> > > >> -- > > >> ogsa-bes-wg mailing list > > >> ogsa-bes-wg(a)ogf.org > > >> http://www.ogf.org/mailman/listinfo/ogsa-bes-wg > > >> > > > > > > -- > > > ogsa-bes-wg mailing list > > > ogsa-bes-wg(a)ogf.org > > > http://www.ogf.org/mailman/listinfo/ogsa-bes-wg > > > > -- > > ogsa-bes-wg mailing list > > ogsa-bes-wg(a)ogf.org > > http://www.ogf.org/mailman/listinfo/ogsa-bes-wg > >-- > ogsa-bes-wg mailing list > ogsa-bes-wg(a)ogf.org > http://www.ogf.org/mailman/listinfo/ogsa-bes-wg >Content-Type: application/x-pkcs7-signature; > name="smime.p7s" >Content-Disposition: attachment; > filename="smime.p7s" > >0 *H÷ > 010 +0 *H÷ > Ê0=0¦ÍºVðßä¼Tþ"¬³rªU0 > *H÷ >0_10 UUS10UVeriSign, Inc.1705U.Class 1 Public Primary Certification >Authority0 >960129000000Z >280801235959Z0_10 UUS10UVeriSign, Inc.1705U.Class 1 Public Primary >Certification Authority00 > *H÷ >0å¿m£Va-HqögÞ¹ë· ú8%¯Fås¨ $] >Ìen°ÐV¡sß´X9knÁöÕ¨¨?ª1¬°4×4g >ÍâNEVixÚÜG)»6Éc\Åà×-{¡·2°{0º*/1ªî£gÚÛ0 > *H÷ >L?¸ÆhßîC3]é¦ËMz3ÿô6Ø"6hl|BÌó.Ä?°Oÿvùâ¼JéÍ >÷Å)ñ"]¸±Ý#£{%F0yøêKÂÈã·ô@<Ã_SèHä´{¡5°{%º¸Ó«?84óÑq0b0Ë >ÚÁ?« tz´Î.30 > *H÷ >0_10 UUS10UVeriSign, Inc.1705U.Class 1 Public Primary Certification >Authority0 >980512000000Z >080512235959Z0Ì10UVeriSign, Inc.10UVeriSign Trust >Network1F0DU=www.verisign.com/repository/RPA Incorp. By >Ref.,LIAB.LTD(c)981H0FU?VeriSign Class 1 CA Individual Subscriber-Persona >Not Validated00 > *H÷ >0»ZD»Uýz-Ox6¸ >J²oT¿¼èw*¹ðh»Ù1ApzK¹HV-ÇáB«À¢«D\ªBðé/ûÂ;»¾É' >]¶°6B3µnTOJ¿Úùè¶ãÌÆj$ãüàeº§±~ïÉÛ7jÈJÈ >ä£°00U0ÿ0GU@0>0<`HøE0-0++www.verisign.com/repository/RPA01U*0(0& $ >" http://crl.verisign.com/pca1.crl0U0 `HøB0 > *H÷ >}oEK8 ¸ÞéSd!¼äL+þ@¬Ø >9j¡2!,«YþÓb}U8°7sÜôfcb½áSpRç¨ØRé[-ªáÞÏ¬1TÔÈØ#¨ï+2},È|¨.wòDÑe >MtµîÓst.;5rç@1Ó²Ä«çV¾ãû00 aI±thÆãøSÈ¬1ÌÀ .0 > *H÷ >0Ì10UVeriSign, Inc.10UVeriSign Trust >Network1F0DU=www.verisign.com/repository/RPA Incorp. By >Ref.,LIAB.LTD(c)981H0FU?VeriSign Class 1 CA Individual Subscriber-Persona >Not Validated0 >060419000000Z >070419235959Z010UVeriSign, Inc.10UVeriSign Trust >Network1F0DU=www.verisign.com/repository/RPA Incorp. by >Ref.,LIAB.LTD(c)9810UPersona Not Validated1402U+Digital ID Class 1 - >Microsoft Full Service10UThomas Maguire1"0 *H÷ > maguire_tom@emc.com00 > *H÷ >0«¼åO!² >cuû!ç_ãÚFÓWðçínøíy>Ï¼³$"ÎñÜeq¶Úß©Çï«túK?@K¬þ[REæâËH¶#»ÇS1w\¯lúè¾a7¦)ì_eÎËê66$±s²ùxT¿4×íËª/ç£µ0²0 >U00DU=0;09`HøE0*0(+https://www.verisign.com/rpa0U 0U%0++03U,0*0( & >$"http://crl.verisign.com/class1.crl0 > *H÷ ><¢A·ë¡ø'¿ÎáÜßTî$ñ<Ü{nDa6gWÛÈØ¿¤«É¨O³Eq!ÛÃnw) >´æ5ÜÊ£Á×eF¹Dö¬«úÄ()ÌLç£4½ä×Å²AÿÅ,^56¥¢Ó°®oI÷ñ¿AÿæÅ1>0:0á0Ì10UVeriSign, >Inc.10UVeriSign Trust Network1F0DU=www.verisign.com/repository/RPA Incorp. >By Ref.,LIAB.LTD(c)981H0FU?VeriSign Class 1 CA Individual >Subscriber-Persona Not ValidatedaI±thÆãøSÈ¬1ÌÀ .0 + ²0 *H÷ > 1 *H÷ >0 *H÷ > 1 >060906182559Z0# *H÷ > 1j._±¿ÛáâVº«0g *H÷ > 1Z0X0 *H÷ >0*H÷ >0 >*H÷ >@0+0 >*H÷ >(0+0 *H÷ >0ò +71ä0á0Ì10UVeriSign, Inc.10UVeriSign Trust >Network1F0DU=www.verisign.com/repository/RPA Incorp. By >Ref.,LIAB.LTD(c)981H0FU?VeriSign Class 1 CA Individual Subscriber-Persona >Not ValidatedaI±thÆãøSÈ¬1ÌÀ .0ô*H÷ > 1ä á0Ì10UVeriSign, Inc.10UVeriSign Trust > Network1F0DU=www.verisign.com/repository/RPA Incorp. By > Ref.,LIAB.LTD(c)981H0FU?VeriSign Class 1 CA Individual Subscriber-Persona > Not ValidatedaI±thÆãøSÈ¬1ÌÀ .0 > *H÷ >úëÜãû´6óÝK?Ü¦W¼]ÀêÐã¶1VzìWú`=®îBÎä¬RÉ/ >H+AN½Ü¸üßÏ©sÕ©JHs«Â´¾k\=` >1ÔUoéûãókñ?v¦p¬Dí©|)ú´!É1#ÙñÂ1ê5þ >-- > ogsa-bes-wg mailing list > ogsa-bes-wg(a)ogf.org > http://www.ogf.org/mailman/listinfo/ogsa-bes-wg _______________________________________________________________ Ian Foster -- Weblog: http://ianfoster.typepad.com Computation Institute: www.ci.uchicago.edu & www.ci.anl.gov Argonne: MCS/221, 9700 S. Cass Ave, Argonne, IL 60439 Chicago: Rm 405, 5640 S. Ellis Ave, Chicago, IL 60637 Tel: +1 630 252 4619 --- Globus Alliance: www.globus.org

1 0

Revised version of BES draft specification
by Marvin Theimer 06 Sep '06

06 Sep '06

Hi; I have finished all the edits that I intended to make and have uploaded my work to gridforge as version 22 of the BES draft document: https://forge.gridforum.org/sf/go/doc13783?nav=1 The document is also attached to this email. A summary of the changes I've made is the following: Refactored BES-Management and BES-Factory port types. Promoted Cancelled and Failed to first-class states in the base state diagram. Moved material in Appendix A on renderings to introduction. Changed names of some of the operations. Completely rewrote section 4 on the extensible state model, including adding more examples. Moved things around in sections 5 & 6 to reflect the refactored port types. Clarified the vector-length return values from GetActivitiesStatus, TerminateActivities, and GetActivityDocuments operations. Added a wrapper to the input argument to CreateActivity so that BES-specific inputs can be provided along-side a JSDL document. Clarified the semantics of TerminateActivities. Added an embrionic extensions section. Added myself to the author list. Fixed up the appendices to reflect the other changes to the document. Replaced the use of WS-BaseFault with Soap-1.2 faults. Added Ellen Stokes' container material as an appendix. I hereby relinquish the pen (and associated lock) on this document. Marvin.

4 10

Accepted: Updated: OGSA BES Meeting
by Mark Morgan 06 Sep '06

06 Sep '06

BEGIN:VCALENDAR PRODID:-//Microsoft Corporation//Outlook 11.0 MIMEDIR//EN VERSION:2.0 METHOD:REPLY BEGIN:VEVENT ORGANIZER:MAILTO:ogsa-bes-wg@ogf.org DTSTART:20060907T153000Z DTEND:20060907T163000Z LOCATION:On Line TRANSP:OPAQUE SEQUENCE:0 UID:040000008200E00074C5B7101A82E00800000000405377BFA2C5C6010000000000000000100 00000CE23706D3100764EBAB9FBBF39A55849 DTSTAMP:20060906T181637Z SUMMARY:Accepted: Updated: OGSA BES Meeting PRIORITY:5 X-MICROSOFT-CDO-IMPORTANCE:1 CLASS:PUBLIC ATTENDEE;PARTSTAT=ACCEPTED:MAILTO:mmm2a@virginia.edu END:VEVENT END:VCALENDAR

1 0